Aptos labs, DAG BFT'de iki önemli açık sorunu çözerek gecikmeyi büyük ölçüde azalttı ve ilk kez deterministik pratik protokollerdeki duraklama ihtiyacını ortadan kaldırdı. Genel olarak bu, Bullshark gecikmesini arıza olmaması durumunda %40 ve arıza durumunda %80 oranında iyileştirir.
Shoal, ardışık düzen ve lider itibarı yoluyla Narwhal tabanlı herhangi bir konsensüs protokolünü (örn. DAG-Rider, Tusk, Bullshark) geliştiren bir çerçevedir. Ardışık düzen oluşturma, tur başına bir çapa ekleyerek DAG sıralama gecikmesini azaltır ve lider itibarı, bağlantıların en hızlı doğrulayıcılarla ilişkilendirilmesini sağlayarak gecikmeyi daha da artırır. Ek olarak, lider itibarı, Shoal'ın tüm senaryolarda zaman aşımlarını ortadan kaldırmak için eşzamansız DAG yapısından yararlanmasını sağlar. Bu, Shoal'ın genellikle gerekli olan İyimser Tepkiyi içeren Evrensel Tepki adını verdiğimiz bir özelliği sağlamasına olanak tanır.
Tekniğimiz çok basit, temel protokolün birden çok örneğini birbiri ardına sırayla çalıştırmayı içeriyor. Böylece, Bullshark ile örneklendiğinde, bayrak yarışı yapan bir grup "köpekbalığı" elde ederiz.
Motivasyon
Blockchain ağlarında yüksek performans arayışında, iletişim karmaşıklığını azaltmaya sürekli olarak odaklanılmıştır. Ancak, bu yaklaşım verimde önemli bir artışa neden olmadı. Örneğin, Diem'in ilk sürümündeki Hotstuff uygulaması yalnızca 3500 TPS'ye ulaştı, bu da 100k+ TPS'ye ulaşma hedefimizin çok altında.
Bununla birlikte, son atılımlar, veri yayılımının lider tabanlı protokollerin ana darboğazı olduğunun ve paralelleştirmeden fayda sağlayabileceğinin fark edilmesinden kaynaklanmaktadır. Narwhal sistemi, veri yayılımını çekirdek konsensüs mantığından ayırır ve tüm doğrulayıcıların verileri aynı anda yaydığı, konsensüs bileşenlerinin ise yalnızca daha küçük miktarda meta veri sipariş ettiği bir mimari önerir. Narwhal makalesi, 160.000 TPS'lik bir iş hacmi bildiriyor.
Bir önceki yazımızda Quorum Store'u tanıtmıştık. Narwhal uygulamamız, veri yayılımını konsensüsten ve bunu mevcut konsensüs protokolümüz Jolteon'u genişletmek için nasıl kullandığımızı ayırır. Jolteon, Hotstuff gecikmesini %33 oranında azaltmak için Tendermint'in doğrusal hızlı yolunu PBFT tarzı görünüm değişiklikleriyle birleştiren lider tabanlı bir protokoldür. Ancak, lider tabanlı bir konsensüs protokolünün Narwhal'ın verim potansiyelinden tam olarak yararlanamayacağı açıktır. Veri yayılımını fikir birliğinden ayırmasına rağmen, iş hacmi arttıkça Hotstuff/Jolteon liderleri hala sınırlıdır.
Bu nedenle, Narwhal DAG'ın üzerine sıfır iletişim ek yüküne sahip bir konsensüs protokolü olan Bullshark'ı dağıtmaya karar verdik. Ne yazık ki, Bullshark'ın yüksek verimini destekleyen DAG yapısı, Jolteon'a kıyasla %50 gecikme cezasıyla geliyor.
Bu yazıda, Shoal'ın Bullshark gecikmesinde nasıl çarpıcı bir azalma elde ettiğini açıklıyoruz.
DAG-BFT arka planı
Bu makalenin ilgili arka planını anlayarak başlayalım. Narwhal ve Bullshark'ın ayrıntılı açıklaması için lütfen DAG BFT ile buluşuyor gönderisine bakın.
Narwhal DAG'deki her köşe, bir yuvarlak sayı ile ilişkilendirilir. r turuna girmek için, bir doğrulayıcı önce r-1 turuna ait nf köşeleri elde etmelidir. Her doğrulayıcı, tur başına bir tepe noktası yayınlayabilir ve her tepe noktası, bir önceki turdaki en az nf tepe noktasına atıfta bulunur. Ağ eşzamansızlığı nedeniyle, farklı doğrulayıcılar herhangi bir zamanda DAG'ın farklı yerel görünümlerini gözlemleyebilir. İşte olası bir kısmi görünümün bir örneği:
Şekil 1: 2. tur doğrulama düğümü 2 tarafından tanımlanan köşe noktalarının nedensel geçmişi yeşil renkle vurgulanmıştır
DAG'lerin önemli bir özelliği belirsizlik değildir: iki doğrulayıcı, yerel DAG görünümlerinde aynı v tepe noktasına sahiplerse, v'nin tam olarak aynı nedensel geçmişine sahiptir.
Genel sipariş toplamı
Ek iletişim ek yükü olmadan bir DAG'deki tüm köşelerin toplam sırası üzerinde anlaşmak mümkündür. Bu amaçla, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar, DAG'nin yapısını, köşelerin önerileri ve kenarların oyları temsil ettiği bir fikir birliği protokolü olarak yorumlar.
Grup kesişme mantığı DAG yapısında farklılık gösterse de, mevcut tüm Narwhal tabanlı mutabakat protokolleri aşağıdaki yapıya sahiptir:
Önceden belirlenmiş çapalar, birkaç turda bir önceden belirlenmiş bir lider olacaktır (örneğin, Bullshark'ta iki tur) ve liderin köşelerine çapa denir;
Çapaların sıralanması, doğrulayıcı bağımsız olarak ancak belirleyici olarak hangi ankrajların sipariş edileceğine ve hangi ankrajların atlanacağına karar verir;
Doğrulayıcıların sıralı çapa listelerini birer birer işlediği ve her bir çapa için nedensel geçmişindeki önceden sıralanmamış tüm köşeleri bazı deterministik kurallara göre sıraladığı nedensel geçmişleri sıralayın.
Şekil 2: Bullshark protokolündeki bir DAG'nin olası bir kısmi görünümünün gösterimi. Bu örnekte, kırmızı ve sarı çapalar sıralanırken yeşil (DAG'de değil) atlanır. Bu nedenle, DAG'yi sıralamak için doğrulayıcılar, belirleyici bir şekilde önce kırmızı çapaların nedensel geçmişlerini, ardından sarı çapaları sıralar.
Güvenliği sağlamanın anahtarı, yukarıdaki (2) adımında, tüm dürüst doğrulayıcıların, tüm listelerin aynı öneki paylaşacağı şekilde sıralı bir bağlantı listesi oluşturmasını sağlamaktır. Shoal'da, yukarıdaki protokollerin tümü için aşağıdaki gözlemleri yapıyoruz:
** Tüm doğrulayıcılar, ilk sipariş edilen çapa üzerinde hemfikirdir. **
Bullshark Gecikmesi
Bullshark'ın gecikme süresi, DAG'deki sıralı çapalar arasındaki tur sayısına bağlıdır. Bullshark'ın en yararlı kısmen senkronize sürümü, eşzamansız sürümden daha iyi gecikme süresine sahip olsa da, optimal olmaktan uzaktır.
Sorun 1: Ortalama blok gecikmesi. Bullshark'ta her çift turun bir çapası vardır ve her tek turun köşeleri oy olarak yorumlanır. Tipik olarak, çapaları sıralamak için iki DAG turu gerekir, ancak bir çapanın nedensel geçmişindeki köşe noktaları, bir çapanın sıralanmasını beklemek için çok daha fazla tur alır. Yaygın durumda, tek turlardaki köşeler üç tur gerektirirken, çift turlardaki çapa olmayan köşeler dört tur gerektirir (bkz. Şekil 3).
Şekil 3: Genel durumda, i+1 turundaki çıpaların iki tur için sıralanması gerekir. Tur i'deki köşeler aynı anda sıralanır, dolayısıyla gecikmeleri üç turdur. Bununla birlikte, i+1 turundaki köşeler sıralanacak bir sonraki çıpayı (i+3 turundaki) beklemek zorundadır, dolayısıyla sıralama gecikmeleri dört turdur.
Problem 2: Başarısızlık durumu gecikmesi, yukarıdaki gecikme analizi başarısızlık durumu için geçerlidir, öte yandan, bir turun lideri çapaları yeterince hızlı yayınlayamazsa, çapalar sıralanamaz (ve bu nedenle atlanır), yani Hepsi önceki turlarda sıralanmamış köşeler sıralanacak bir sonraki çapayı beklemelidir. Bu, özellikle Bullshark lideri beklerken zaman aşımlarını kullandığından, coğrafi olarak çoğaltılmış bir ağın performansını önemli ölçüde azaltabilir.
Sürü Çerçevesi
Shoal, Bullshark'ı (veya diğer herhangi bir Narwhal tabanlı BFT protokolünü) ardışık düzen yoluyla geliştirerek, her turda bir bağlantıya izin vererek ve DAG'deki tüm bağlantı noktası olmayan köşelerin gecikmesini üç tura düşürerek bu gecikme sorunlarının her ikisini de çözer. Shoal ayrıca DAG'de, seçimi hızlı liderler lehine yönlendiren sıfır ek yük lider itibar mekanizması sunar.
meydan okumak
DAG protokolleri bağlamında, boru hattı oluşturma ve lider itibarı, aşağıdaki nedenlerden dolayı zor sorunlar olarak kabul edilir:
Önceki ardışık düzen, temel Bullshark mantığını değiştirmeye çalışıyor, ancak bu, doğası gereği imkansız görünüyor
DiemBFT'de tanıtılan ve Carousel'de resmileştirilen Lider İtibarı, doğrulayıcıların geçmiş performansına dayalı olarak geleceğin liderlerini (Bullshark'taki çapalar) dinamik olarak seçme fikridir. Lider kimliği konusundaki anlaşmazlık, bu protokollerde güvenliği ihlal etmese de, Bullshark'ta tamamen farklı bir sıralamaya yol açabilir; , doğrulayıcıların ise gelecekteki çapaları seçmek için sıralı bir geçmiş üzerinde anlaşması gerekir.
Sorunun zorluğunun kanıtı olarak, üretimdeki mevcut uygulama da dahil olmak üzere Bullshark'ın uygulamasının bu özellikleri desteklemediğini not ediyoruz.
protokol
Yukarıda belirtilen zorluklara rağmen, deyim yerindeyse çözümlerin basitliğin arkasında yattığı ortaya çıktı.
Shoal'da, DAG üzerinde yerel hesaplamalar yapma ve önceki turlardaki bilgileri koruma ve yeniden yorumlama becerisini uygulama becerisine güveniyoruz. Tüm doğrulayıcıların ilk sıralı çapa üzerinde hemfikir olduğu temel içgörüyle Shoal, (1) ilk sıralı çapa örnekler için anahtarlama noktası olacak ve (2) Çapalar liderin itibarını hesaplamak için kullanılır.
ardışık düzen
Bullshark'a benzer şekilde, doğrulayıcılar potansiyel çapalar üzerinde önceden hemfikirdir, yani liderlere bilinen bir F: R -> V eşleme turları vardır. Shoal, Bullshark örneklerini birbiri ardına çalıştırır, öyle ki her örnek için çapa F haritası tarafından önceden belirlenir. Her örnek, bir sonraki örneğe geçişi tetikleyen bir çapa sipariş eder.
Başlangıçta Shoal, Bullshark'ın ilk örneğini DAG'nin ilk turunda başlatır ve ilk sıralı çapa belirlenene kadar, örneğin r turunda çalıştırır. Tüm doğrulayıcılar bu çapa üzerinde hemfikirdir. Bu nedenle, tüm doğrulayıcılar, r+1 turundan başlayarak DAG'yi yeniden yorumlamayı deterministik olarak kabul edebilir. Shoal, r+1 turunda yeni bir Bullshark örneği başlatıyor.
En iyi senaryoda, bu, Shoal'ın her turda bir çapa sipariş etmesine izin verir. İlk tur için çapalar ilk örneğe göre sıralanır. Ardından Shoal, ikinci turda, örnek tarafından sıralanan bir çapa sahip olan yeni bir örnek başlatır, ardından üçüncü turda başka bir yeni örnek, çapaları sipariş eder ve süreç devam eder. Lütfen aşağıdaki resme bakın:
Şekil 4: F tarafından belirlenen liderlere karşılık gelen köşeler bir taç ile işaretlenmiştir.Bullshark'ın ilk örneği DAG'yi ilk olarak 1., 3. ve 5. turdaki çıpalarla yorumlar. Bullshark 1. turdaki çıpaları belirler (yeşil onay işaretiyle) işareti) ilk örnekte sıralanacak olandır. (Genel durumda, bu çıpa atlanabilirken diğer bazı çıpalar önce sıralanır.) Ardından, ilk örneğin geri kalanı göz ardı edilir ve 2. turdan itibaren yeni bir Bullshark örneği başlar, Bağlantı noktaları işaretlenir 2. ve 4. turlarda.
Lider itibarı
Bullshark sıralaması sırasında çapaları atlarken artan gecikme süresi. Bu durumda, Ardışık Düzen oluşturma tekniği güçsüzdür çünkü önceki örnek bir bağlantı sipariş edene kadar yeni bir örnek başlatılamaz. Shoal, her doğrulayıcıya son faaliyet geçmişine dayalı bir puan atamak için bir itibar mekanizması kullanarak, uygun liderin gelecekte kayıp bir çıpa ile başa çıkmak için seçilme olasılığının düşük olmasını sağlar. Protokole yanıt veren ve katılan bir doğrulayıcıya yüksek puan verilir, aksi takdirde bir doğrulayıcıya düşük puan atanır çünkü çökebilir, yavaş olabilir veya kötü amaçlı olabilir.
Buradaki fikir, her puan güncellemesinde turlardan liderlere önceden tanımlanmış F eşlemesini deterministik olarak yeniden hesaplamak ve daha yüksek puanlara sahip liderleri tercih etmektir. Doğrulayıcıların yeni eşleme üzerinde anlaşmaları için puan ve dolayısıyla puanı elde etmek için kullanılan geçmiş üzerinde anlaşmaları gerekir.
Shoal'da ardışık düzen ve liderlik itibarı doğal olarak birleştirilebilir çünkü her ikisi de ilk sıralı çapa üzerinde anlaştıktan sonra DAG'yi yeniden yorumlamak için aynı temel tekniği kullanır.
Aslında tek fark, r turundaki çapaları sıraladıktan sonra, doğrulayıcının yalnızca r turundaki sıralı çapaların nedensel geçmişine dayalı olarak r+1 turundan yeni bir F' eşlemesi hesaplaması yeterli olmasıdır. Ardından doğrulayıcı, güncellenmiş çapa seçim işlevini F' kullanarak r+1 turundan başlayarak yeni bir Bullshark örneğini yürütür. Aşağıdaki resme bakın:
Şekil 5. F ile tanımlanan liderlere karşılık gelen köşeler şeffaf taçlarla işaretlenmiştir. Bullshark'ın ilk örneği, 1. turda yeşil bir onay işaretiyle işaretlenmiş bir çapa sipariş eder ve ardından çapanın nedensel geçmişindeki bilgilere dayalı olarak yeni bir F' eşlemesini hesaplar. F' ile belirlenen liderler renkli taçlarla işaretlenmiştir.
Artık zaman aşımı yok
Zaman aşımları, tüm lider tabanlı deterministik kısmen senkronize BFT uygulamalarında çok önemli bir rol oynar. Ancak getirdikleri karmaşıklık, yönetilmesi ve gözlemlenmesi gereken dahili durum miktarını artırır, bu da hata giderme sürecini karmaşıklaştırır ve daha fazla gözlemlenebilirlik tekniği gerektirir.
Zaman aşımları ayrıca gecikmeyi önemli ölçüde artırabilir, çünkü bunları uygun şekilde yapılandırmak önemlidir ve büyük ölçüde ortama (ağa) bağlı olduğu için genellikle dinamik olarak ayarlanması gerekir. Protokol, bir sonraki lidere geçmeden önce hatalı lidere tam mola geciktirme cezasını öder. Bu nedenle, zaman aşımı ayarı çok muhafazakar olamaz, ancak zaman aşımı çok kısaysa, protokol iyi liderleri atlayabilir. Örneğin, Jolteon/Hotstuff'taki liderlerin yüksek yük altında bunaldıklarını ve ilerlemeyi hızlandıramadan zaman aşımlarının sona erdiğini gözlemledik.
Ne yazık ki, Hotstuff ve Jolteon gibi lider tabanlı protokoller, liderin her başarısızlığında protokolün ilerleme kaydedebilmesini sağlamak için doğal olarak zaman aşımlarına ihtiyaç duyar. Zaman aşımı olmadan, çökmüş bir lider bile protokolü sonsuza kadar durdurabilir. Eşzamansız bir lider ile yavaş bir lider arasında ayrım yapamama nedeniyle zaman aşımları, doğrulayıcıların fikir birliği canlılığı olmadan tüm liderlerdeki değişiklikleri görmesine neden olabilir.
Bullshark'ta, senkronizasyon sırasında dürüst bir liderin DAG'a çapaları sıralanacak kadar hızlı eklemesini sağlamak için DAG yapımında zaman aşımları kullanılır.
DAG yapısının ağın hızını tahmin etmek için bir "saat" sağladığını gözlemliyoruz. Duraklamalar olmadığında, nf dürüst doğrulayıcılar DAG'a tepe noktaları eklemeye devam ettiği sürece turlar ilerlemeye devam eder. Bullshark ağ hızında sıralama yapamasa da (sorunlu liderler nedeniyle), bazı lider sorunlarına veya ağın eşzamansız olmasına rağmen DAG yine de ağ hızında büyüyor. Sonunda, hatasız bir lider çapaları yeterince hızlı yayınladığında, çapaların tüm nedensel geçmişi sıralanacaktır.
Değerlendirmemizde, Bullshark'ı molalı ve molasız olarak aşağıdaki durumlarda karşılaştırdık:
Hızlı lider, yani en azından diğer doğrulayıcılardan daha hızlı. Bu durumda, çapalar sıralandığı ve zaman aşımları kullanılmadığı için her iki yöntem de aynı gecikmeyi sağlar.
Yanlış lider, bu durumda duraklamalar olmadan Bullshark daha iyi gecikme sağlar, çünkü doğrulayıcılar hemen çapalarını atlarken, duraklamaları olan doğrulayıcılar devam etmeden önce onların gelişini bekleyecektir.
Yavaş lider, Bullshark'ın daha iyi mola performansına sahip olduğu tek durum budur. Bunun nedeni, bir duraklama olmadan, lider yeterince hızlı yayınlayamadığı için çapa atlanabilirken, bir duraklama ile doğrulayıcılar çapa için bekleyecektir.
Shoal'da molalardan kaçınmak ve liderlik itibarı el ele gider. Yavaş bir lideri tekrar tekrar beklemek gecikmeyi artırır ve lider itibar mekanizması, yavaş doğrulayıcıların lider olarak seçilmesini engeller. Bu şekilde sistem, tüm gerçek dünya senaryolarında ağ hızında çalışmak için hızlı doğrulama düğümlerini kullanır.
FLP imkansızlığı sonucunun, hiçbir deterministik konsensüs protokolünün zaman aşımlarını önleyemeyeceğini gösterdiğine dikkat edin. Shoal bu sonucu atlatamaz çünkü tüm çıpaların komuta edilmesini önleyecek düşmanca olayların teorik bir programı vardır. Bunun yerine, Shoal, yapılandırılabilir sayıda ardışık çapa atlamasından sonra bir zaman aşımına geri döner. Uygulamada, bunun gerçekleşmesi son derece olası değildir.
Genel Yanıt
Hotstuff makalesi, resmi olarak tanımlanmamış olsa da sezgisel olarak protokolün hızlı bir lider ve senkronize bir ağ da dahil olmak üzere iyi koşullar altında ağ hızında çalışabileceği anlamına gelen iyimser yanıt kavramını popüler hale getirdi.
Shoal, Universal Response adını verdiğimiz daha da iyi bir özellik sağlar. Spesifik olarak, Hotstuff'ın aksine Shoal, lider yapılandırılabilir sayıda ardışık tur veya ağın içinden geçtiği eşzamansız döngüler için başarısız olsa bile ağ hızında çalışmaya devam eder. Aşağıdaki tabloda daha ayrıntılı bir karşılaştırmaya bakın.
Evrensel yanıt verebilirliğin, eşzamansız dönemlerde ve liderin başarısız olduğu durumlarda kesinlikle daha iyi ilerleme garantileri sağladığını unutmayın. Yavaş bir liderle senkronizasyon sırasında, liderin ne kadar yavaş olduğuna bağlı olduğundan bu özellikler karşılaştırılabilir değildir. Ancak liderin itibarı göz önüne alındığında, yavaş hareket eden liderler Shoal'da nadiren görünmelidir.
Değerlendirmek
Narwhal uygulamamız Quorum Store'a ek olarak Bullshark ve Shoal'ı uyguladık. Shoal, Bullshark ve Jolteon arasındaki ayrıntılı bir karşılaştırma, Shoal raporunun bazı önemli noktalara yer verdiğimiz değerlendirme bölümünde bulunabilir.
İlk olarak, eşzamansız DAG yapısının gücünü göstermek için Bullshark'ı duraklamalı ve duraklamasız olarak karşılaştırıyoruz. Tam Bullshark makalesi, eşzamansız bir ağ varsayar, ancak hızlı yol modu sağlar, bu nedenle tüm turlar sırasında duraklamalar gerektirir. Bu versiyona Vanilla Bullshark diyoruz. Bağımsız kısmen senkronize ağ varsayımsal versiyonları için oylama turlarında herhangi bir duraklama gerekmediğini gözlemliyoruz. Bu sürüme Vanilla Bullshark, oylama zaman aşımı olmadan Oylama zaman aşımı diyoruz, Baseline Bullshark herhangi bir zaman aşımı olmayan sürümdür.
Aşağıdaki grafik, arızalı ve hatasız zaman aşımlarının Bullshark gecikme süresi üzerindeki etkisini karşılaştırmaktadır. Görünüşe göre Baseline Bullshark (zaman aşımı yok), bir arıza durumunda en iyi performansı gösteriyor. Hiçbir başarısızlık olmadan, Baseline Bullshark, oylama askıya alınmadan Vanilla Bullshark ile karşılaştırılabilir. Bunun nedeni, daha önce de belirtildiği gibi, bir lider itibar mekanizması olmadan, liderin iyi ama yavaş olduğu durumlarda molaların bir avantaja sahip olabilmesidir.
Şekil 6.: Arıza durumunda 50 doğrulayıcı ile hatasız (solda) ve hatasız (sağda) zaman aşımlarının Bullshark gecikme süresi üzerindeki etkisi
Ardından, Baseline Bullshark'ı (zaman aşımı olmadan) kullanarak Shoal'ı başlatıyoruz ve ardışık düzendeki gecikme iyileştirmelerini ve lider itibar mekanizmasını hatasız ve hatasız olarak gösteriyoruz ve eksiksizlik için bunu Jolteon ile hatasız ve hatasız olarak karşılaştırıyoruz.
Aşağıdaki Şekil 7 başarısızlıksızlık durumunu göstermektedir ve hem ardışık düzen hem de liderin itibarı gecikmeyi ayrı ayrı azaltabilirken, bunların birleştirilmesi en iyi gecikmeyle sonuçlanır.
Jolteon'a gelince, 20'den fazla doğrulayıcıya ölçeklenemez ve Quorum Store'da çalışsa bile, veri yayma darboğazını ortadan kaldıran Bullshark/Shoal'ın iş hacminin yalnızca yaklaşık yarısına ulaşabilir.
Sonuçlar, Shoal'ın Bullshark gecikmesini büyük ölçüde iyileştirdiğini gösteriyor. Jolteon'a gelince, sadece konsensüs gecikmesini ölçmüş olmamıza rağmen şunu not etmek önemlidir. Jolteon, yerel olarak bir DAG üzerinde çalışamayacağından, veri yayılımını ayrıştırmak için ölçmediğimiz ek gecikme süresi gerektirir. Bu nedenle, yüksek yük altında Shoal, Jolteon'un uçtan uca gecikme süresiyle eşleşmelidir.
Şekil 7: Başarısız verim ve gecikme, Shoal PL ve Shaol LR sırasıyla yalnızca boru hattını ve lider itibarını destekler.
Aşağıdaki Şekil 8, lider itibar mekanizmasının başarısız bir doğrulayıcının lider olarak seçilme olasılığını azaltarak gecikmeyi önemli ölçüde iyileştirdiği 50 doğrulayıcı ile bir başarısızlık durumunu göstermektedir. 50 başarısızlıktan 16'sında Shoal'ın gecikme süresinin Baseline Bullshark'tan %65 daha düşük olduğuna dikkat edin.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
4D Shoal Çerçevesi Açıklandı: Aptos'ta Bullshark Gecikmesi Nasıl Azaltılır?
Orijinal: Aptos Laboratuvarları
Derleme: Aptos Global
Genel Bakış
Aptos labs, DAG BFT'de iki önemli açık sorunu çözerek gecikmeyi büyük ölçüde azalttı ve ilk kez deterministik pratik protokollerdeki duraklama ihtiyacını ortadan kaldırdı. Genel olarak bu, Bullshark gecikmesini arıza olmaması durumunda %40 ve arıza durumunda %80 oranında iyileştirir.
Shoal, ardışık düzen ve lider itibarı yoluyla Narwhal tabanlı herhangi bir konsensüs protokolünü (örn. DAG-Rider, Tusk, Bullshark) geliştiren bir çerçevedir. Ardışık düzen oluşturma, tur başına bir çapa ekleyerek DAG sıralama gecikmesini azaltır ve lider itibarı, bağlantıların en hızlı doğrulayıcılarla ilişkilendirilmesini sağlayarak gecikmeyi daha da artırır. Ek olarak, lider itibarı, Shoal'ın tüm senaryolarda zaman aşımlarını ortadan kaldırmak için eşzamansız DAG yapısından yararlanmasını sağlar. Bu, Shoal'ın genellikle gerekli olan İyimser Tepkiyi içeren Evrensel Tepki adını verdiğimiz bir özelliği sağlamasına olanak tanır.
Tekniğimiz çok basit, temel protokolün birden çok örneğini birbiri ardına sırayla çalıştırmayı içeriyor. Böylece, Bullshark ile örneklendiğinde, bayrak yarışı yapan bir grup "köpekbalığı" elde ederiz.
Motivasyon
Blockchain ağlarında yüksek performans arayışında, iletişim karmaşıklığını azaltmaya sürekli olarak odaklanılmıştır. Ancak, bu yaklaşım verimde önemli bir artışa neden olmadı. Örneğin, Diem'in ilk sürümündeki Hotstuff uygulaması yalnızca 3500 TPS'ye ulaştı, bu da 100k+ TPS'ye ulaşma hedefimizin çok altında.
Bununla birlikte, son atılımlar, veri yayılımının lider tabanlı protokollerin ana darboğazı olduğunun ve paralelleştirmeden fayda sağlayabileceğinin fark edilmesinden kaynaklanmaktadır. Narwhal sistemi, veri yayılımını çekirdek konsensüs mantığından ayırır ve tüm doğrulayıcıların verileri aynı anda yaydığı, konsensüs bileşenlerinin ise yalnızca daha küçük miktarda meta veri sipariş ettiği bir mimari önerir. Narwhal makalesi, 160.000 TPS'lik bir iş hacmi bildiriyor.
Bir önceki yazımızda Quorum Store'u tanıtmıştık. Narwhal uygulamamız, veri yayılımını konsensüsten ve bunu mevcut konsensüs protokolümüz Jolteon'u genişletmek için nasıl kullandığımızı ayırır. Jolteon, Hotstuff gecikmesini %33 oranında azaltmak için Tendermint'in doğrusal hızlı yolunu PBFT tarzı görünüm değişiklikleriyle birleştiren lider tabanlı bir protokoldür. Ancak, lider tabanlı bir konsensüs protokolünün Narwhal'ın verim potansiyelinden tam olarak yararlanamayacağı açıktır. Veri yayılımını fikir birliğinden ayırmasına rağmen, iş hacmi arttıkça Hotstuff/Jolteon liderleri hala sınırlıdır.
Bu nedenle, Narwhal DAG'ın üzerine sıfır iletişim ek yüküne sahip bir konsensüs protokolü olan Bullshark'ı dağıtmaya karar verdik. Ne yazık ki, Bullshark'ın yüksek verimini destekleyen DAG yapısı, Jolteon'a kıyasla %50 gecikme cezasıyla geliyor.
Bu yazıda, Shoal'ın Bullshark gecikmesinde nasıl çarpıcı bir azalma elde ettiğini açıklıyoruz.
DAG-BFT arka planı
Bu makalenin ilgili arka planını anlayarak başlayalım. Narwhal ve Bullshark'ın ayrıntılı açıklaması için lütfen DAG BFT ile buluşuyor gönderisine bakın.
Narwhal DAG'deki her köşe, bir yuvarlak sayı ile ilişkilendirilir. r turuna girmek için, bir doğrulayıcı önce r-1 turuna ait nf köşeleri elde etmelidir. Her doğrulayıcı, tur başına bir tepe noktası yayınlayabilir ve her tepe noktası, bir önceki turdaki en az nf tepe noktasına atıfta bulunur. Ağ eşzamansızlığı nedeniyle, farklı doğrulayıcılar herhangi bir zamanda DAG'ın farklı yerel görünümlerini gözlemleyebilir. İşte olası bir kısmi görünümün bir örneği:
Şekil 1: 2. tur doğrulama düğümü 2 tarafından tanımlanan köşe noktalarının nedensel geçmişi yeşil renkle vurgulanmıştır
DAG'lerin önemli bir özelliği belirsizlik değildir: iki doğrulayıcı, yerel DAG görünümlerinde aynı v tepe noktasına sahiplerse, v'nin tam olarak aynı nedensel geçmişine sahiptir.
Genel sipariş toplamı
Ek iletişim ek yükü olmadan bir DAG'deki tüm köşelerin toplam sırası üzerinde anlaşmak mümkündür. Bu amaçla, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar, DAG'nin yapısını, köşelerin önerileri ve kenarların oyları temsil ettiği bir fikir birliği protokolü olarak yorumlar.
Grup kesişme mantığı DAG yapısında farklılık gösterse de, mevcut tüm Narwhal tabanlı mutabakat protokolleri aşağıdaki yapıya sahiptir:
Önceden belirlenmiş çapalar, birkaç turda bir önceden belirlenmiş bir lider olacaktır (örneğin, Bullshark'ta iki tur) ve liderin köşelerine çapa denir;
Çapaların sıralanması, doğrulayıcı bağımsız olarak ancak belirleyici olarak hangi ankrajların sipariş edileceğine ve hangi ankrajların atlanacağına karar verir;
Doğrulayıcıların sıralı çapa listelerini birer birer işlediği ve her bir çapa için nedensel geçmişindeki önceden sıralanmamış tüm köşeleri bazı deterministik kurallara göre sıraladığı nedensel geçmişleri sıralayın.
Şekil 2: Bullshark protokolündeki bir DAG'nin olası bir kısmi görünümünün gösterimi. Bu örnekte, kırmızı ve sarı çapalar sıralanırken yeşil (DAG'de değil) atlanır. Bu nedenle, DAG'yi sıralamak için doğrulayıcılar, belirleyici bir şekilde önce kırmızı çapaların nedensel geçmişlerini, ardından sarı çapaları sıralar.
Güvenliği sağlamanın anahtarı, yukarıdaki (2) adımında, tüm dürüst doğrulayıcıların, tüm listelerin aynı öneki paylaşacağı şekilde sıralı bir bağlantı listesi oluşturmasını sağlamaktır. Shoal'da, yukarıdaki protokollerin tümü için aşağıdaki gözlemleri yapıyoruz:
** Tüm doğrulayıcılar, ilk sipariş edilen çapa üzerinde hemfikirdir. **
Bullshark Gecikmesi
Bullshark'ın gecikme süresi, DAG'deki sıralı çapalar arasındaki tur sayısına bağlıdır. Bullshark'ın en yararlı kısmen senkronize sürümü, eşzamansız sürümden daha iyi gecikme süresine sahip olsa da, optimal olmaktan uzaktır.
Sorun 1: Ortalama blok gecikmesi. Bullshark'ta her çift turun bir çapası vardır ve her tek turun köşeleri oy olarak yorumlanır. Tipik olarak, çapaları sıralamak için iki DAG turu gerekir, ancak bir çapanın nedensel geçmişindeki köşe noktaları, bir çapanın sıralanmasını beklemek için çok daha fazla tur alır. Yaygın durumda, tek turlardaki köşeler üç tur gerektirirken, çift turlardaki çapa olmayan köşeler dört tur gerektirir (bkz. Şekil 3).
Şekil 3: Genel durumda, i+1 turundaki çıpaların iki tur için sıralanması gerekir. Tur i'deki köşeler aynı anda sıralanır, dolayısıyla gecikmeleri üç turdur. Bununla birlikte, i+1 turundaki köşeler sıralanacak bir sonraki çıpayı (i+3 turundaki) beklemek zorundadır, dolayısıyla sıralama gecikmeleri dört turdur.
Problem 2: Başarısızlık durumu gecikmesi, yukarıdaki gecikme analizi başarısızlık durumu için geçerlidir, öte yandan, bir turun lideri çapaları yeterince hızlı yayınlayamazsa, çapalar sıralanamaz (ve bu nedenle atlanır), yani Hepsi önceki turlarda sıralanmamış köşeler sıralanacak bir sonraki çapayı beklemelidir. Bu, özellikle Bullshark lideri beklerken zaman aşımlarını kullandığından, coğrafi olarak çoğaltılmış bir ağın performansını önemli ölçüde azaltabilir.
Sürü Çerçevesi
Shoal, Bullshark'ı (veya diğer herhangi bir Narwhal tabanlı BFT protokolünü) ardışık düzen yoluyla geliştirerek, her turda bir bağlantıya izin vererek ve DAG'deki tüm bağlantı noktası olmayan köşelerin gecikmesini üç tura düşürerek bu gecikme sorunlarının her ikisini de çözer. Shoal ayrıca DAG'de, seçimi hızlı liderler lehine yönlendiren sıfır ek yük lider itibar mekanizması sunar.
meydan okumak
DAG protokolleri bağlamında, boru hattı oluşturma ve lider itibarı, aşağıdaki nedenlerden dolayı zor sorunlar olarak kabul edilir:
Önceki ardışık düzen, temel Bullshark mantığını değiştirmeye çalışıyor, ancak bu, doğası gereği imkansız görünüyor
DiemBFT'de tanıtılan ve Carousel'de resmileştirilen Lider İtibarı, doğrulayıcıların geçmiş performansına dayalı olarak geleceğin liderlerini (Bullshark'taki çapalar) dinamik olarak seçme fikridir. Lider kimliği konusundaki anlaşmazlık, bu protokollerde güvenliği ihlal etmese de, Bullshark'ta tamamen farklı bir sıralamaya yol açabilir; , doğrulayıcıların ise gelecekteki çapaları seçmek için sıralı bir geçmiş üzerinde anlaşması gerekir.
Sorunun zorluğunun kanıtı olarak, üretimdeki mevcut uygulama da dahil olmak üzere Bullshark'ın uygulamasının bu özellikleri desteklemediğini not ediyoruz.
protokol
Yukarıda belirtilen zorluklara rağmen, deyim yerindeyse çözümlerin basitliğin arkasında yattığı ortaya çıktı.
Shoal'da, DAG üzerinde yerel hesaplamalar yapma ve önceki turlardaki bilgileri koruma ve yeniden yorumlama becerisini uygulama becerisine güveniyoruz. Tüm doğrulayıcıların ilk sıralı çapa üzerinde hemfikir olduğu temel içgörüyle Shoal, (1) ilk sıralı çapa örnekler için anahtarlama noktası olacak ve (2) Çapalar liderin itibarını hesaplamak için kullanılır.
ardışık düzen
Bullshark'a benzer şekilde, doğrulayıcılar potansiyel çapalar üzerinde önceden hemfikirdir, yani liderlere bilinen bir F: R -> V eşleme turları vardır. Shoal, Bullshark örneklerini birbiri ardına çalıştırır, öyle ki her örnek için çapa F haritası tarafından önceden belirlenir. Her örnek, bir sonraki örneğe geçişi tetikleyen bir çapa sipariş eder.
Başlangıçta Shoal, Bullshark'ın ilk örneğini DAG'nin ilk turunda başlatır ve ilk sıralı çapa belirlenene kadar, örneğin r turunda çalıştırır. Tüm doğrulayıcılar bu çapa üzerinde hemfikirdir. Bu nedenle, tüm doğrulayıcılar, r+1 turundan başlayarak DAG'yi yeniden yorumlamayı deterministik olarak kabul edebilir. Shoal, r+1 turunda yeni bir Bullshark örneği başlatıyor.
En iyi senaryoda, bu, Shoal'ın her turda bir çapa sipariş etmesine izin verir. İlk tur için çapalar ilk örneğe göre sıralanır. Ardından Shoal, ikinci turda, örnek tarafından sıralanan bir çapa sahip olan yeni bir örnek başlatır, ardından üçüncü turda başka bir yeni örnek, çapaları sipariş eder ve süreç devam eder. Lütfen aşağıdaki resme bakın:
Şekil 4: F tarafından belirlenen liderlere karşılık gelen köşeler bir taç ile işaretlenmiştir.Bullshark'ın ilk örneği DAG'yi ilk olarak 1., 3. ve 5. turdaki çıpalarla yorumlar. Bullshark 1. turdaki çıpaları belirler (yeşil onay işaretiyle) işareti) ilk örnekte sıralanacak olandır. (Genel durumda, bu çıpa atlanabilirken diğer bazı çıpalar önce sıralanır.) Ardından, ilk örneğin geri kalanı göz ardı edilir ve 2. turdan itibaren yeni bir Bullshark örneği başlar, Bağlantı noktaları işaretlenir 2. ve 4. turlarda.
Lider itibarı
Bullshark sıralaması sırasında çapaları atlarken artan gecikme süresi. Bu durumda, Ardışık Düzen oluşturma tekniği güçsüzdür çünkü önceki örnek bir bağlantı sipariş edene kadar yeni bir örnek başlatılamaz. Shoal, her doğrulayıcıya son faaliyet geçmişine dayalı bir puan atamak için bir itibar mekanizması kullanarak, uygun liderin gelecekte kayıp bir çıpa ile başa çıkmak için seçilme olasılığının düşük olmasını sağlar. Protokole yanıt veren ve katılan bir doğrulayıcıya yüksek puan verilir, aksi takdirde bir doğrulayıcıya düşük puan atanır çünkü çökebilir, yavaş olabilir veya kötü amaçlı olabilir.
Buradaki fikir, her puan güncellemesinde turlardan liderlere önceden tanımlanmış F eşlemesini deterministik olarak yeniden hesaplamak ve daha yüksek puanlara sahip liderleri tercih etmektir. Doğrulayıcıların yeni eşleme üzerinde anlaşmaları için puan ve dolayısıyla puanı elde etmek için kullanılan geçmiş üzerinde anlaşmaları gerekir.
Shoal'da ardışık düzen ve liderlik itibarı doğal olarak birleştirilebilir çünkü her ikisi de ilk sıralı çapa üzerinde anlaştıktan sonra DAG'yi yeniden yorumlamak için aynı temel tekniği kullanır.
Aslında tek fark, r turundaki çapaları sıraladıktan sonra, doğrulayıcının yalnızca r turundaki sıralı çapaların nedensel geçmişine dayalı olarak r+1 turundan yeni bir F' eşlemesi hesaplaması yeterli olmasıdır. Ardından doğrulayıcı, güncellenmiş çapa seçim işlevini F' kullanarak r+1 turundan başlayarak yeni bir Bullshark örneğini yürütür. Aşağıdaki resme bakın:
Şekil 5. F ile tanımlanan liderlere karşılık gelen köşeler şeffaf taçlarla işaretlenmiştir. Bullshark'ın ilk örneği, 1. turda yeşil bir onay işaretiyle işaretlenmiş bir çapa sipariş eder ve ardından çapanın nedensel geçmişindeki bilgilere dayalı olarak yeni bir F' eşlemesini hesaplar. F' ile belirlenen liderler renkli taçlarla işaretlenmiştir.
Artık zaman aşımı yok
Zaman aşımları, tüm lider tabanlı deterministik kısmen senkronize BFT uygulamalarında çok önemli bir rol oynar. Ancak getirdikleri karmaşıklık, yönetilmesi ve gözlemlenmesi gereken dahili durum miktarını artırır, bu da hata giderme sürecini karmaşıklaştırır ve daha fazla gözlemlenebilirlik tekniği gerektirir.
Zaman aşımları ayrıca gecikmeyi önemli ölçüde artırabilir, çünkü bunları uygun şekilde yapılandırmak önemlidir ve büyük ölçüde ortama (ağa) bağlı olduğu için genellikle dinamik olarak ayarlanması gerekir. Protokol, bir sonraki lidere geçmeden önce hatalı lidere tam mola geciktirme cezasını öder. Bu nedenle, zaman aşımı ayarı çok muhafazakar olamaz, ancak zaman aşımı çok kısaysa, protokol iyi liderleri atlayabilir. Örneğin, Jolteon/Hotstuff'taki liderlerin yüksek yük altında bunaldıklarını ve ilerlemeyi hızlandıramadan zaman aşımlarının sona erdiğini gözlemledik.
Ne yazık ki, Hotstuff ve Jolteon gibi lider tabanlı protokoller, liderin her başarısızlığında protokolün ilerleme kaydedebilmesini sağlamak için doğal olarak zaman aşımlarına ihtiyaç duyar. Zaman aşımı olmadan, çökmüş bir lider bile protokolü sonsuza kadar durdurabilir. Eşzamansız bir lider ile yavaş bir lider arasında ayrım yapamama nedeniyle zaman aşımları, doğrulayıcıların fikir birliği canlılığı olmadan tüm liderlerdeki değişiklikleri görmesine neden olabilir.
Bullshark'ta, senkronizasyon sırasında dürüst bir liderin DAG'a çapaları sıralanacak kadar hızlı eklemesini sağlamak için DAG yapımında zaman aşımları kullanılır.
DAG yapısının ağın hızını tahmin etmek için bir "saat" sağladığını gözlemliyoruz. Duraklamalar olmadığında, nf dürüst doğrulayıcılar DAG'a tepe noktaları eklemeye devam ettiği sürece turlar ilerlemeye devam eder. Bullshark ağ hızında sıralama yapamasa da (sorunlu liderler nedeniyle), bazı lider sorunlarına veya ağın eşzamansız olmasına rağmen DAG yine de ağ hızında büyüyor. Sonunda, hatasız bir lider çapaları yeterince hızlı yayınladığında, çapaların tüm nedensel geçmişi sıralanacaktır.
Değerlendirmemizde, Bullshark'ı molalı ve molasız olarak aşağıdaki durumlarda karşılaştırdık:
Hızlı lider, yani en azından diğer doğrulayıcılardan daha hızlı. Bu durumda, çapalar sıralandığı ve zaman aşımları kullanılmadığı için her iki yöntem de aynı gecikmeyi sağlar.
Yanlış lider, bu durumda duraklamalar olmadan Bullshark daha iyi gecikme sağlar, çünkü doğrulayıcılar hemen çapalarını atlarken, duraklamaları olan doğrulayıcılar devam etmeden önce onların gelişini bekleyecektir.
Yavaş lider, Bullshark'ın daha iyi mola performansına sahip olduğu tek durum budur. Bunun nedeni, bir duraklama olmadan, lider yeterince hızlı yayınlayamadığı için çapa atlanabilirken, bir duraklama ile doğrulayıcılar çapa için bekleyecektir.
Shoal'da molalardan kaçınmak ve liderlik itibarı el ele gider. Yavaş bir lideri tekrar tekrar beklemek gecikmeyi artırır ve lider itibar mekanizması, yavaş doğrulayıcıların lider olarak seçilmesini engeller. Bu şekilde sistem, tüm gerçek dünya senaryolarında ağ hızında çalışmak için hızlı doğrulama düğümlerini kullanır.
FLP imkansızlığı sonucunun, hiçbir deterministik konsensüs protokolünün zaman aşımlarını önleyemeyeceğini gösterdiğine dikkat edin. Shoal bu sonucu atlatamaz çünkü tüm çıpaların komuta edilmesini önleyecek düşmanca olayların teorik bir programı vardır. Bunun yerine, Shoal, yapılandırılabilir sayıda ardışık çapa atlamasından sonra bir zaman aşımına geri döner. Uygulamada, bunun gerçekleşmesi son derece olası değildir.
Genel Yanıt
Hotstuff makalesi, resmi olarak tanımlanmamış olsa da sezgisel olarak protokolün hızlı bir lider ve senkronize bir ağ da dahil olmak üzere iyi koşullar altında ağ hızında çalışabileceği anlamına gelen iyimser yanıt kavramını popüler hale getirdi.
Shoal, Universal Response adını verdiğimiz daha da iyi bir özellik sağlar. Spesifik olarak, Hotstuff'ın aksine Shoal, lider yapılandırılabilir sayıda ardışık tur veya ağın içinden geçtiği eşzamansız döngüler için başarısız olsa bile ağ hızında çalışmaya devam eder. Aşağıdaki tabloda daha ayrıntılı bir karşılaştırmaya bakın.
Evrensel yanıt verebilirliğin, eşzamansız dönemlerde ve liderin başarısız olduğu durumlarda kesinlikle daha iyi ilerleme garantileri sağladığını unutmayın. Yavaş bir liderle senkronizasyon sırasında, liderin ne kadar yavaş olduğuna bağlı olduğundan bu özellikler karşılaştırılabilir değildir. Ancak liderin itibarı göz önüne alındığında, yavaş hareket eden liderler Shoal'da nadiren görünmelidir.
Değerlendirmek
Narwhal uygulamamız Quorum Store'a ek olarak Bullshark ve Shoal'ı uyguladık. Shoal, Bullshark ve Jolteon arasındaki ayrıntılı bir karşılaştırma, Shoal raporunun bazı önemli noktalara yer verdiğimiz değerlendirme bölümünde bulunabilir.
İlk olarak, eşzamansız DAG yapısının gücünü göstermek için Bullshark'ı duraklamalı ve duraklamasız olarak karşılaştırıyoruz. Tam Bullshark makalesi, eşzamansız bir ağ varsayar, ancak hızlı yol modu sağlar, bu nedenle tüm turlar sırasında duraklamalar gerektirir. Bu versiyona Vanilla Bullshark diyoruz. Bağımsız kısmen senkronize ağ varsayımsal versiyonları için oylama turlarında herhangi bir duraklama gerekmediğini gözlemliyoruz. Bu sürüme Vanilla Bullshark, oylama zaman aşımı olmadan Oylama zaman aşımı diyoruz, Baseline Bullshark herhangi bir zaman aşımı olmayan sürümdür.
Aşağıdaki grafik, arızalı ve hatasız zaman aşımlarının Bullshark gecikme süresi üzerindeki etkisini karşılaştırmaktadır. Görünüşe göre Baseline Bullshark (zaman aşımı yok), bir arıza durumunda en iyi performansı gösteriyor. Hiçbir başarısızlık olmadan, Baseline Bullshark, oylama askıya alınmadan Vanilla Bullshark ile karşılaştırılabilir. Bunun nedeni, daha önce de belirtildiği gibi, bir lider itibar mekanizması olmadan, liderin iyi ama yavaş olduğu durumlarda molaların bir avantaja sahip olabilmesidir.
Şekil 6.: Arıza durumunda 50 doğrulayıcı ile hatasız (solda) ve hatasız (sağda) zaman aşımlarının Bullshark gecikme süresi üzerindeki etkisi
Ardından, Baseline Bullshark'ı (zaman aşımı olmadan) kullanarak Shoal'ı başlatıyoruz ve ardışık düzendeki gecikme iyileştirmelerini ve lider itibar mekanizmasını hatasız ve hatasız olarak gösteriyoruz ve eksiksizlik için bunu Jolteon ile hatasız ve hatasız olarak karşılaştırıyoruz.
Aşağıdaki Şekil 7 başarısızlıksızlık durumunu göstermektedir ve hem ardışık düzen hem de liderin itibarı gecikmeyi ayrı ayrı azaltabilirken, bunların birleştirilmesi en iyi gecikmeyle sonuçlanır.
Jolteon'a gelince, 20'den fazla doğrulayıcıya ölçeklenemez ve Quorum Store'da çalışsa bile, veri yayma darboğazını ortadan kaldıran Bullshark/Shoal'ın iş hacminin yalnızca yaklaşık yarısına ulaşabilir.
Sonuçlar, Shoal'ın Bullshark gecikmesini büyük ölçüde iyileştirdiğini gösteriyor. Jolteon'a gelince, sadece konsensüs gecikmesini ölçmüş olmamıza rağmen şunu not etmek önemlidir. Jolteon, yerel olarak bir DAG üzerinde çalışamayacağından, veri yayılımını ayrıştırmak için ölçmediğimiz ek gecikme süresi gerektirir. Bu nedenle, yüksek yük altında Shoal, Jolteon'un uçtan uca gecikme süresiyle eşleşmelidir.
Şekil 7: Başarısız verim ve gecikme, Shoal PL ve Shaol LR sırasıyla yalnızca boru hattını ve lider itibarını destekler.
Aşağıdaki Şekil 8, lider itibar mekanizmasının başarısız bir doğrulayıcının lider olarak seçilme olasılığını azaltarak gecikmeyi önemli ölçüde iyileştirdiği 50 doğrulayıcı ile bir başarısızlık durumunu göstermektedir. 50 başarısızlıktan 16'sında Shoal'ın gecikme süresinin Baseline Bullshark'tan %65 daha düşük olduğuna dikkat edin.