Shoal çerçevesi: Aptos üzerinde Bullshark'ın düşüşünü nasıl azaltırız

Aptos Labs, DAG BFT'deki iki önemli açık problemi çözdü, gecikme süresini büyük ölçüde düşürdü ve belirsiz gerçek protokollerde zaman aşımı gereksinimini ilk kez ortadan kaldırdı. Genel olarak, hatasız durumlarda Bullshark'ın gecikme süresini %40, arızalı durumlarda ise %80 oranında geliştirdi.

Shoal, Narwhal tabanlı konsensüs protokollerini ( gibi DAG-Rider, Tusk, Bullshark) güçlendirmek için bir çerçeve olup, akış hattı ve liderin itibarı aracılığıyla geliştirilmiştir. Akış hattı, her turda referans noktaları getirerek DAG sıralama gecikme süresini azaltır, liderin itibarı ise referans noktalarının en hızlı doğrulama düğümleriyle ilişkili olmasını sağlayarak gecikme sorununu daha da iyileştirir. Ayrıca, liderin itibarı, Shoal'ın tüm senaryolarda zaman aşımını ortadan kaldırmak için asenkron DAG yapılarını kullanmasını sağlar. Bu, Shoal'ın genellikle gereken iyimser yanıtları içeren evrensel yanıt özellikleri sunmasına olanak tanır.

Bu teknoloji oldukça basit, temel protokollerin birden fazla örneğini sıralı bir şekilde çalıştırmayı içeriyor. Bu nedenle, Bullshark örneği kullanıldığında, "köpekbalıkları"nın bir bayrak yarışı yapıyor olduğu bir grup elde ediyoruz.

Arka Plan

Blok zinciri ağlarının yüksek performansını ararken, insanlar iletişim karmaşıklığını azaltmaya odaklanmışlardır. Ancak, bu yöntem önemli bir verim artışı sağlamamıştır. Örneğin, Diem'in erken sürümünde uygulanan Hotstuff yalnızca 3500 TPS gerçekleştirmiştir, bu da 100k+ TPS hedefine oldukça düşüktür.

Son dönemdeki atılım, veri iletiminde liderlik protokolünün ana darboğaz olduğunu ve paralelleşmeden fayda sağlanabileceğini anlamaktan kaynaklanıyor. Narwhal sistemi, veri iletimini çekirdek konsensüs mantığından ayırarak, tüm doğrulayıcıların aynı anda veri yaymasını ve konsensüs bileşeninin yalnızca az sayıda meta veriyi sıraladığı bir mimari öneriyor. Narwhal belgesi, 160.000 TPS'lik bir verimlilik rapor ediyor.

Daha önce tanıtılan Quorum Store, Narwhal'ın bir uygulamasıdır; veri yayılımını konsensustan ayırarak mevcut konsensüs protokolü Jolteon'u genişletmek için kullanılır. Jolteon, lider tabanlı bir protokoldür ve Tendermint'in lineer hızlı yolunu PBFT tarzı görünüm değişiklikleriyle birleştirerek Hotstuff gecikmesini %33 oranında düşürür. Ancak, lider tabanlı konsensüs protokolleri Narwhal'ın işlem hacmi potansiyelinden tam olarak yararlanamaz.

Bu nedenle, Narwhal DAG üzerinde Bullshark'ı dağıtma kararı alındı, bu da sıfır iletişim maliyetine sahip bir konsensüs protokolüdür. Ne yazık ki, Bullshark'ın yüksek verimliliğini destekleyen DAG yapısı, Jolteon'a kıyasla %50'lik bir düşüş maliyeti getirmektedir.

Bu makale, Shoal'ın Bullshark gecikme süresini nasıl önemli ölçüde azaltacağını açıklamaktadır.

DAG-BFT Arka Planı

Narwhal DAG'daki her bir tepe noktası bir tur ile ilişkilidir. r. tura girmek için, doğrulayıcı öncelikle r-1. turun n-f tepe noktasını elde etmelidir. Her doğrulayıcı her turda bir tepe noktasını yayınlayabilir ve her tepe noktası en az bir önceki turun n-f tepe noktasını referans almalıdır. Ağın asenkronluğu nedeniyle, farklı doğrulayıcılar herhangi bir zamanda DAG'ın farklı yerel görünümlerini gözlemleyebilir.

DAG'ın bir ana özelliği belirsizlik olmamasıdır: Eğer iki doğrulama düğümü DAG'ın yerel görünümünde aynı tepe noktası v'ye sahipse, o zaman v'nin nedensel geçmişleri tamamen aynıdır.

Tam Sıra

DAG'daki tüm noktaların tam sıralı birliğe ulaşılması, ek iletişim maliyeti olmadan mümkündür. Bunun için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar, DAG yapısını bir konsensüs protokolü olarak yorumlar; burada noktalar önerileri, kenarlar ise oylamayı temsil eder.

Tüm mevcut Narwhal tabanlı konsensüs protokolleri aşağıdaki yapıya sahiptir:

1. Rezervasyon noktası: Her birkaç turda önceden belirlenmiş bir lider vardır, liderin zirvesine rezervasyon noktası denir.

2. Sıralama Ankraj Noktası: Doğrulayıcılar bağımsız ancak belirleyici bir şekilde hangi ankraj noktalarını sıralayacaklarına ve hangi ankraj noktalarını atlayacaklarına karar verir.

3. Nedensellik geçmişini sıralama: Doğrulayıcılar, sıralı referans noktası listesini tek tek işlerler ve her referans noktasının nedensellik geçmişindeki tüm önceki düzensiz köşe noktalarını belirleyici kurallara göre sıralarlar.

Güvenliğin sağlanmasının anahtarı, adım (2)'de, tüm dürüst doğrulama düğümleri tarafından oluşturulan sıralı sabit nokta listesinin aynı ön eki paylaşmasını sağlamaktır. Shoal, bu protokollerin hepsi için aşağıdaki gözlemleri yapmaktadır:

Tüm doğrulayıcılar ilk sıralı bağlantı noktasında hemfikir.

Bullshark gecikme süresi

Bullshark'ın gecikme süresi, DAG'daki sıralı sabit noktalar arasındaki döngü sayısına bağlıdır. Bazı senkron versiyonlar, asenkron versiyonlardan daha iyi bir gecikme süresine sahip olsa da, bu kesinlikle en iyi değildir.

Soru 1: Ortalama blok gecikmesi. Bullshark'ta her çift turda bir çapa noktası, her tek turda ise bir tepe noktası olarak yorumlanır. Genel durumlarda çapa noktalarını sıralamak için iki tur DAG gereklidir, ancak çapa noktasının nedensel geçmişindeki tepe noktalarının çapa noktası sıralaması için daha fazla tura beklemesi gerekir. Genellikle tek tur tepe noktaları üç tur, çift tur çapa noktası olmayan tepe noktaları ise dört tur beklemelidir.

Soru 2: Arıza Durumu gecikmesi. Eğer bir lider yeterince hızlı bir şekilde referans noktasını yayınlayamazsa, referans noktası sıralanamaz ( atlanır ), önceki turlardaki tüm sıralanmamış köşe noktaları bir sonraki referans noktasının sıralanmasını beklemek zorundadır. Bu, coğrafi çoğaltma ağının performansını önemli ölçüde düşürmektedir, özellikle de Bullshark lideri beklemek için zaman aşımı kullanıyorsa.

Shoal çerçevesi

Shoal, Bullshark( veya diğer herhangi bir Narwhal tabanlı BFT protokolünü güçlendirmek için bir hattı kullanarak, her turda bir referans noktasının olmasına izin verir ve DAG'daki tüm referans noktası olmayan düğümlerin gecikme süresini üç tura düşürür. Shoal ayrıca DAG'da sıfır maliyetli lider itibarı mekanizmasını tanıtarak hızlı liderlerin seçimini tercih eder.

Mücadele

DAG protokolü bağlamında, boru hattı ve liderin itibarı zorlayıcı sorunlar olarak kabul edilmektedir, nedenleri şunlardır:

1. Önceki üretim hattı, temel Bullshark mantığını değiştirmeye çalıştı, ancak bu esasen mümkün gibi görünmüyor.

2. Liderlerin itibarı DiemBFT'ye entegre edildi ve Carousel'de resmileştirildi, doğrulayıcıların geçmiş performansına göre gelecekteki liderler dinamik olarak seçiliyor )Bullshark'taki çapa (. Liderlik kimliği üzerindeki anlaşmazlıkların bu protokollerin güvenliğini ihlal etmediği durumlarda, Bullshark'ta tamamen farklı bir sıralama ile sonuçlanabilir, bu da sorunun özünü ortaya çıkarır: Dinamik deterministik seçim döngüsü çapasının konsensüsü sağlamak için gerekli olduğu ve doğrulayıcıların gelecekteki çapanın seçimi için sıralı tarih üzerinde uzlaşması gerektiği.

Soru zorluğunun kanıtı olarak, Bullshark'ın uygulanması ), mevcut üretim ortamındaki ( bu özellikleri desteklememektedir.

Protokol

Shoal, DAG üzerinde yerel hesaplama yeteneğine dayanarak, önceki turların bilgilerini saklama ve yeniden yorumlama yeteneğini gerçekleştirmiştir. Tüm doğrulayıcıların ilk sıralı sabit noktanın içgörüsünde hemfikir olmasıyla, Shoal, bir dizi Bullshark örneğini ardışık işleme için sırayla birleştirir, böylece )1( ilk sıralı sabit nokta örnek geçiş noktasıdır, )2( sabit noktanın nedensel geçmişi liderin itibarını hesaplamak için kullanılır.

) akış şeridi

V haritası vardır. Shoal, her bir örneğin ankra noktasının F haritası ile önceden belirlendiği Bullshark örneklerini birer birer çalıştırır. Her bir örnek bir ankra sipariş eder ve bir sonraki örneğe geçişi tetikler.

Başlangıçta, Shoal DAG'ın ilk turunda Bullshark'ın ilk örneğini başlattı ve ilk sıralı çakışma noktasını belirleyene kadar çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu çakışma noktasında hemfikirdi. Bu nedenle, tüm doğrulayıcılar r+1. turdan itibaren DAG'ı yeniden yorumlamayı kesin bir şekilde kabul edebilir. Shoal, yalnızca r+1. turda yeni bir Bullshark örneğini başlatır.

En iyi senaryoda, bu Shoal'ın her turda bir çapa sipariş etmesine olanak tanır. İlk tur çapa noktası, ilk örneğin sıralamasıyla belirlenir. Ardından, Shoal ikinci turda yeni bir örnek başlatır, bu örneğin kendine ait bir çapa noktası vardır, bu çapa o örnek tarafından sıralanır ve ardından üçüncü turda başka bir yeni örnek çapa noktası sipariş eder, süreç devam eder.

![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？]###https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(

) liderlik itibarı

Bullshark sıralaması sırasında sabit noktaların atlanması durumunda gecikme süresi artar. Bu durumda, önceki örnekte sabit nokta sipariş edilmeden yeni bir örnek başlatılamaz, bu yüzden boru hattı çaresiz kalır. Shoal, her doğrulayıcı düğümünün en son etkinlik geçmişine göre puanlar dağıtarak, gelecekte kaybolan sabit noktaları işlemek için ilgili liderlerin seçilme olasılığının düşük olmasını sağlamaktadır. Protokole yanıt veren ve katılan doğrulayıcılar yüksek puan alırken, aksi takdirde düşük puan dağıtılır çünkü bu durum çökebilir, yavaşlayabilir veya kötü niyetli olabilir.

Bu yaklaşım, her puan güncellemesinde, yüksek puan alan liderlere yönelerek, turlardan liderlere önceden tanımlanmış F haritalarını belirli bir şekilde yeniden hesaplamayı hedeflemektedir. Doğrulayıcıların yeni haritalar üzerinde uzlaşabilmesi için puanlar üzerinde uzlaşmaları gerekmektedir, böylece türetilen puanların tarihi üzerinde de uzlaşma sağlanmış olur.

Shoal'da, hatlar ve liderlik itibarı doğal olarak birleşebilir, çünkü her ikisi de ilk sıralı bağlantı noktasında uzlaşma sağlandıktan sonra DAG'ı yeniden yorumlamak için aynı temel teknolojiyi kullanır.

Tek fark, r. turda referans noktalarının sıralanmasının ardından, doğrulayıcıların yalnızca r. turda sıralı referans noktalarının nedensel geçmişine dayanarak r+1. turdan itibaren yeni bir haritalama F' hesaplamaları gerektiğidir. Ardından, doğrulama düğümleri r+1. turdan itibaren güncellenmiş referans noktası seçim fonksiyonu F' ile Bullshark'ın yeni örneğini yürütür.

![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？]###https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(

) zaman aşımı yok

Zaman aşımı, tüm lider tabanlı belirleyici kısmi senkronize BFT uygulamalarında kritik bir rol oynamaktadır. Ancak, bunların getirdiği karmaşıklık, yönetilmesi ve gözlemlenmesi gereken iç durum sayısını artırmakta, hata ayıklama karmaşıklığını artırmakta ve daha fazla gözlemlenebilirlik tekniği gerektirmektedir.

Zaman aşımı da gecikmeyi önemli ölçüde artırır, çünkü bunları doğru yapılandırmak önemlidir, genellikle dinamik ayarlamalar gerektirir ve çevreye büyük ölçüde bağımlıdır ### ağ (. Bir sonraki lidere geçmeden önce, protokol arızalı liderler için tam zaman aşımı gecikme cezası ödeyecektir. Bu nedenle, zaman aşımı ayarları çok temkinli olmamalıdır, ancak çok kısa olursa, protokol iyi liderleri atlayabilir. Örneğin, yüksek yük altında, Jolteon/Hotstuff'taki liderlerin aşırı yüklendiğini ve ilerlemeyi teşvik etmeden önce zaman aşımının sona erdiğini gözlemledik.

Ne yazık ki, lider protokolü ) gibi Hotstuff ve Jolteon( temelde bir gecikme süresi gerektirir, böylece her lider arızasında protokol ilerleme kaydedebilir. Gecikme süresi olmadan, çöküş yaşayan lider bile protokolü sonsuza dek durdurabilir. Asenkron dönemde arızalı lider ile yavaş lider arasında ayrım yapılamadığı için, gecikme süresi doğrulama düğümlerinin tüm liderleri, konsensüs etkinliği olmadan değiştirmesine neden olabilir.

Bullshark'ta, DAG yapısı için zaman aşımı, senkronizasyon sırasında dürüst liderlerin sıralama için DAG'a yeterince hızlı bir şekilde sabit noktalar eklemesini sağlamak amacıyla kullanılır.

DAG yapısının ağ hızını tahmin eden bir "saat" sağladığını gözlemliyoruz. Kesintisiz durumlarda, n-f kadar dürüst doğrulayıcı DAG'a zirveler eklemeye devam ettiği sürece, turlar devam edecektir. Bullshark, liderlik sorunları nedeniyle ) ağ hızında sıralama yapamayabilir, ancak DAG hala ağ hızında büyümektedir, bazı liderlerin sorunları veya ağın asenkron olmasına rağmen. Sonunda, hatasız liderler yeterince hızlı bir şekilde bağlantı noktalarını yayınladığında, bağlantı noktalarının tüm nedensel geçmişi sıralanacaktır.

Değerlendirmemizde, Bullshark'ın aşağıdaki durumlarda zaman aşımına uğrayıp uğramadığı karşılaştırılmıştır:

1. Hızlı lider: Diğer doğrulayıcılardan en az bir tık daha hızlı. İki yöntem aynı gecikme süresi sağlar çünkü ankraj sıralıdır ve zaman aşımı kullanmaz.

2. Hatalı lider: Süresiz Bullshark, doğrulama düğümleri hemen atladığı için daha iyi gecikme süresi sağlar.