Shoal çerçevesi: Aptos'un Bullshark gecikme süresini nasıl düşürülür

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

Shoal, herhangi bir Narwhal tabanlı konsensüs protokolünü ( güçlendirmek için bir çerçevedir; bu protokoller arasında DAG-Rider, Tusk, Bullshark ) bulunmaktadır. Pipelineler, her turda bir referans noktası getirerek DAG sıralama gecikmesini azaltır ve liderin itibarı, referans noktalarının en hızlı doğrulayıcı düğümleriyle ilişkilendirilmesini sağlayarak gecikme sorununu daha da iyileştirir. Ayrıca, liderin itibarı, Shoal'ın tüm senaryolarında zaman aşımını ortadan kaldırmak için asenkron DAG yapısını kullanmasına olanak tanır. Bu, Shoal'ın genellikle gerekli olan iyimser yanıtları içeren evrensel yanıt olarak adlandırdığımız bir özellik sunmasını sağlar.

Tekniğimiz oldukça basit, temel protokollerin birden fazla örneğini sırayla çalıştırmayı içeriyor. Bu nedenle, Bullshark'ı örneklediğimizde, devam eden bir bayrak yarışı yapan "köpekbalıkları" grubunu elde ediyoruz.

motivasyon

Blok zinciri ağlarının yüksek performansını sağlama çabasında, insanlar iletişim karmaşıklığını azaltmaya odaklandılar. Ancak, bu yöntem önemli bir throughput artışı sağlamadı. Örneğin, Diem'in erken sürümünde uygulanan Hotstuff yalnızca 3500 TPS sağladı, bu da 100.000+ TPS hedefimizin oldukça altında.

Ancak son dönemdeki atılım, veri yayılımının liderlik protokollerine dayalı ana darboğaz olduğunu ve paralelleşmeden fayda sağlanabileceğini anlamaktan kaynaklanıyor. Narwhal sistemi veri yayılımını çekirdek konsensüs mantığından ayırarak, tüm doğrulayıcıların aynı anda veri yaydığı ve konsensüs bileşeninin yalnızca az sayıda meta veriyi sıraladığı bir mimari öneriyor. Narwhal belgesi 160.000 TPS'lik bir işlem hacmi bildirmektedir.

Daha önceki makalede, Quorum Store'u tanıttık. Narwhal uygulamamız, veri yayılımını konsensustan ayırıyor ve bunu mevcut konsensüs protokolü Jolteon'u genişletmek için nasıl kullandığımızı gösteriyor. Jolteon, Tendermint'in lineer hızlı yolunu ve PBFT tarzı görünüm değişikliklerini birleştiren lider tabanlı bir protokoldür ve Hotstuff'un gecikmesini %33 oranında düşürüyor. Ancak, lider tabanlı konsensüs protokollerinin Narwhal'ın işlem hacmi potansiyelinden tam olarak yararlanamadığı açıktır. Veri yayılımının konsensustan ayrılmasına rağmen, işlem hacmi arttıkça Hotstuff/Jolteon'un liderleri hala sınırlıdır.

Bu nedenle, Bullshark'ı Narwhal DAG'ın üzerinde dağıtmaya karar verdik, bu sıfır iletişim maliyetine sahip bir konsensüs protokolüdür. Ne yazık ki, Jolteon ile karşılaştırıldığında, Bullshark'ın yüksek işlem hacmini destekleyen DAG yapısı %50'lik bir düşüş maliyeti getirmektedir.

Bu makalede, Shoal'ın Bullshark gecikme süresini nasıl büyük ölçüde düşürdüğü anlatılacaktır.

DAG-BFT arka planı

Öncelikle ilgili arka planı anlayalım. Narwhal ve Bullshark hakkında ayrıntılı bilgi için DAG meets BFT makalesine bakın.

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

DAG'ın bir ana özelliği belirsiz olmamasıdır: Eğer iki doğrulama düğümü DAG yerel görünümlerinde aynı tepe v'ye sahipse, o zaman v'nin neden-sonuç tarihi tamamen aynıdır.

tam sıra

DAG'daki tüm noktaların toplam sırasını ek iletişim maliyeti olmadan uzlaştırmak mümkündür. Bunun için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar, DAG'ın yapısını, noktaların teklifleri temsil ettiği ve kenarların oyları temsil ettiği bir konsensüs protokolü olarak yorumlamaktadır.

DAG yapısındaki grup kesişim mantığı farklı olsa da, mevcut tüm Narwhal tabanlı konsensüs protokolleri aşağıdaki yapıya sahiptir:

1. tahsis edilmiş ankraj noktası: her birkaç turda ( gibi Bullshark'taki iki turda ) önceden belirlenmiş bir lider olacaktır, liderin zirvesine ankraj noktası denir;

2. sıralama sabiti: doğrulayıcılar bağımsız ama belirleyici bir şekilde hangi sabitleri sipariş edeceklerine ve hangi sabitleri atlayacaklarına karar verir;

3. Sıralama nedensellik tarihi: doğrulayıcılar, sıralı kilit noktaları listesini tek tek işler; her kilit noktasında, bazı belirleyici kurallar aracılığıyla onun nedensellik tarihindeki tüm önceki düzensiz noktaları sıralar.

Güvenliğin sağlanmasının anahtarı, adım (2)'de tüm dürüst doğrulayıcı düğümlerin ortak bir ön ek paylaşacak şekilde sıralı bir sabit liste oluşturmasını sağlamaktır. Shoal'da yukarıdaki tüm protokollerle ilgili aşağıdaki gözlemleri yapıyoruz:

Tüm doğrulayıcılar ilk sıralı ankra noktası üzerinde hemfikir.

Bullshark gecikme süresi

Bullshark'ın gecikme süresi, DAG'daki sıralı referans noktaları arasındaki dönüş sayısına bağlıdır. Bullshark'ın en pratik kısım senkron versiyonu asenkron versiyona göre daha iyi bir gecikme süresine sahip olsa da, bu en iyi olanı değildir.

Soru 1: Ortalama blok gecikme süresi. Bullshark'ta, her çift turda bir ana nokta vardır, her tek turda ise tepe noktası oylama olarak yorumlanır. Yaygın durumlarda, ana noktaları sıralamak için iki tur DAG gereklidir, ancak ana noktanın nedensel tarihindeki tepe noktalarının ana noktanın sıralanmasını beklemek için daha fazla tura ihtiyacı vardır. Yaygın durumlarda, tek turdaki tepe noktaları üç tura ihtiyaç duyarken, çift turdaki ana nokta olmayan tepe noktaları dört tura ihtiyaç duyar.

Soru 2: Arıza durumu gecikmesi, yukarıdaki gecikme analizi arızasız durumlar için geçerlidir, öte yandan, bir turdaki lider yeterince hızlı bir şekilde sabit noktaları yayınlayamazsa, sabit noktaların sıralanması mümkün olamaz ( bu nedenle atlanır ), bu nedenle önceki turlardaki sıralanmamış tüm doruklar bir sonraki sabit noktanın sıralanmasını beklemek zorundadır. Bu, coğrafi çoğaltma ağının performansını önemli ölçüde düşürecektir, özellikle Bullshark zaman aşımının lideri beklemek için kullanıldığından.

Shoal çerçevesi

Shoal, bu iki gecikme süresi sorununu çözdü; Bullshark( veya herhangi bir Narwhal tabanlı BFT protokolünü) güçlendirmek için bir boru hattı aracılığıyla, her turda bir sabit nokta olmasına olanak tanır ve DAG'daki tüm sabit olmayan tepe noktalarının gecikmesini üç tura indirir. Shoal ayrıca DAG'da sıfır maliyetli lider itibarı mekanizması tanıttı, bu da hızlı liderlere yönelimi artırır.

zorluk

DAG protokolü bağlamında, pipelining ve liderlerin itibarı zor sorunlar olarak kabul edilmektedir, nedenleri ise şunlardır:

1. Önceki akış hattı işlemleri, temel Bullshark mantığını değiştirmeyi denedi, ancak bu temelde imkansız gibi görünüyor.

2. Liderlerin itibarı, DiemBFT'de tanıtılmış ve Carousel'de resmileştirilmiştir; bu, doğrulayıcıların geçmiş performansına göre gelecekteki liderlerin dinamik olarak seçilmesi fikrine dayanmaktadır. Liderlik kimliğinde bir ihtilafın bu protokollerin güvenliğini ihlal etmemesi mümkündür, ancak Bullshark'ta bu, tamamen farklı bir sıralama ile sonuçlanabilir. Bu, sorunun merkezine işaret eder; döngüsel ankörlerin dinamik ve belirleyici bir şekilde seçilmesi, fikir birliğini sağlamak için gereklidir ve doğrulayıcıların gelecekteki ankörleri seçmek için sıralı geçmiş üzerinde uzlaşmaları gerekmektedir.

Soru zorluğunun kanıtı olarak, Bullshark'ın uygulanışına dikkat ettik; şu anki üretim ortamındaki uygulanışı bu özellikleri desteklemiyor.

( protokol

Yukarıda belirtilen zorluklara rağmen, atasözüne göre, çözümün basitlikte gizli olduğu kanıtlanmıştır.

Shoal'da, DAG üzerinde yerel hesaplama yapabilme yeteneğine güveniyoruz ve önceki tur bilgilerini saklayıp yeniden yorumlama yeteneğini gerçekleştirdik. Tüm doğrulayıcıların ilk sıralı noktanın temel içgörüsünde hemfikir olmasıyla, Shoal birden fazla Bullshark örneğini sıralı bir şekilde birleştirip bunları işleme alır; bu sayede ) ilk sıralı nokta örneklerin geçiş noktasıdır ve ### sıralı noktanın nedensel geçmişi, liderin itibarı hesaplanmak için kullanılır.

( akış hattı işlemi

V haritası vardır. Shoal, her bir örnek için referansın F haritası tarafından önceden belirlendiği Bullshark örneklerini birer birer çalıştırır. Her örnek bir referans talep eder, bu da bir sonraki örneğe geçişi tetikler.

Başlangıçta, Shoal DAG'ın ilk turunda Bullshark'ın ilk örneğini başlattı ve bunu ilk sıralı referans noktasının belirlendiği ana kadar çalıştırdı, örneğin r'inci turda. Tüm doğrulayıcılar bu referans noktasında hemfikir oldular. Bu nedenle, tüm doğrulayıcılar r+1'inci turdan itibaren DAG'ı yeniden yorumlamayı kesin olarak kabul edebilirler. Shoal sadece r+1'inci turda yeni bir Bullshark örneği başlattı.

En iyi durumda, bu Shoal'ın her turda bir çapa sipariş etmesine izin verir. İlk turdaki çapa noktaları ilk örneğe göre sıralanır. Ardından, Shoal ikinci turda kendine ait bir çapa noktası bulunan yeni bir örnek başlatır, bu çapa o örneğe göre sıralanır; ardından üçüncü turda başka bir yeni örnek çapa noktası sipariş eder ve bu süreç devam eder.

![Aptos'taki Bullshark gecikme süresini nasıl azaltırız? Shoal çerçevesinin detaylı açıklaması])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(

) liderlik itibarı

Bullshark sıralaması sırasında ankraj noktalarını atlamak, gecikmeyi artırır. Bu durumda, bir önceki örneğin ankraj noktasını sipariş etmeden yeni bir örneği başlatmak mümkün olmadığından, boru hattı işleme tekniği etkisizdir. Shoal, her doğrulama düğümünün en son etkinlik geçmişine dayanarak her doğrulama düğümüne bir puan atayarak, gelecekte ilgili liderlerin kaybolan ankraj noktalarını işleme almasının olası olmadığını sağlamak için bir itibar mekanizması kullanır. Protokole yanıt veren ve katılan doğrulayıcılar yüksek puan alacak, aksi takdirde doğrulama düğümleri düşük puan alacak, çünkü çökebilir, yavaşlayabilir veya kötü niyetli davranabilir.

Bu yaklaşım, her puan güncellemesinde, daha yüksek puanlı liderlere yönelik olarak, turlar ile liderler arasındaki önceden tanımlanmış F haritalamasını belirleyerek kesin bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni haritalama üzerinde uzlaşabilmeleri için, puanlar üzerinde uzlaşmaları ve dolayısıyla puan türetmek için kullanılan tarihler üzerinde de uzlaşmaları gerekir.

Shoal'da, boru hatları ve liderlik itibarları doğal olarak bir araya gelebilir, çünkü her ikisi de ilk sıralı sabit nokta üzerinde uzlaşma sağlandıktan sonra DAG'ı yeniden yorumlamak için aynı temel teknolojiyi kullanır.

Aslında, tek fark, r. turda referans noktalarının sıralanmasından sonra, 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 F' eşlemesi hesaplaması gerektiğidir. Ardından, doğrulama düğümleri r+1. turdan itibaren güncellenmiş referans noktası seçim fonksiyonu F' kullanarak Bullshark'ın yeni bir örneğini gerçekleştirir.

![Bin kelimeyle Shoal çerçevesi: Aptos'taki Bullshark gecikmesini nasıl azaltabiliriz?]###https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(

) Daha fazla gecikme süresi yok

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

Zaman aşımı, uygun şekilde yapılandırılmalarının çok önemli olduğu ve genellikle dinamik olarak ayarlanması gereken bir durum olduğundan dolayı, gecikmeyi de önemli ölçüde artırabilir, çünkü bu, ortam ### ağı ( ile yüksek derecede bağımlıdır. Protokol, bir sonraki liderine geçmeden önce arızalı lider için tam zaman aşımı gecikme cezası ödeyecektir. Bu nedenle, zaman aşımı ayarları çok temkinli olmamalıdır; ancak zaman aşımı süresi çok kısa olursa, protokol iyi liderleri atlayabilir. Örneğin, yüksek yük koşullarında Jolt'u gözlemledik.