Shoal çerçevesi: Aptos üzerindeki Bullshark Konsensüs gecikme süresi optimizasyonu

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

Shoal, Narwhal tabanlı Konsensüs protokolünü ( gibi DAG-Rider, Tusk, Bullshark) güçlendirmek için boru hattı işleme ve lider reputasyon mekanizması aracılığıyla bir çerçevedir. Boru hattı, her turda bir referans noktası tanıtarak DAG sıralama gecikmesini azaltır, lider reputasyonu ise referans noktalarının en hızlı doğrulama düğümleri ile ilişkilendirilmesini sağlayarak gecikme sorununu daha da iyileştirir. Ayrıca, lider reputasyonu, Shoal'ın tüm senaryolardaki zaman aşımını ortadan kaldırmak için asenkron DAG yapısını kullanmasına olanak tanır. Bu, Shoal'ın genellikle gereken iyimser yanıtları içeren evrensel bir yanıt verme özelliği sunmasını sağlar.

Shoal'un teknolojisi nispeten basittir, esasen alt protokollerin birden fazla örneğini sırayla birbiri ardına çalıştırmak üzerine kuruludur. Bullshark ile örneklendiğinde, bir grup "köpekbalığı" bayrak yarışı yapar.

Arka Plan ve Motivasyon

Blok zinciri ağlarının yüksek performansını hedeflerken, iletişim karmaşıklığını azaltmak her zaman bir odak noktası olmuştur. Ancak, bu yaklaşım önemli bir işlem hacmi artışı sağlamamıştır. Örneğin, ilk versiyonundaki Diem'de uygulanan Hotstuff yalnızca 3500 TPS'ye ulaşabilmiştir, bu da 100k+ TPS hedefinin çok altındadır.

Son dönemdeki atılım, veri yayılımının liderlerin protokollerine dayalı ana engel olduğunu anlamaktan ve paralelleşmeden faydalanabileceğinden kaynaklanıyor. Narwhal sistemi, veri yayılımını temel Konsensüs mantığından ayırmakta ve tüm doğrulayıcıların aynı anda veri yaydığı, konsensüs bileşeninin yalnızca az sayıda meta veriyi sıraladığı bir mimari önermektedir. Narwhal belgesi, 160,000 TPS'lik bir iş hacmini rapor etmiştir.

Aptos daha önce Quorum Store'u, yani Narwhal'in uygulamasını tanıttı, verilerin yayılmasını konsensüsten ayırdı ve mevcut konsensüs protokolü Jolteon'u nasıl ölçeklendireceğini açıkladı. Jolteon, Tendermint'in doğrusal hızlı yolu ve PBFT tarzı görünüm değişikliklerini birleştiren lider tabanlı bir protokoldür, Hotstuff gecikmesini %33 oranında azaltabilir. Ancak, açıkça lider tabanlı konsensüs protokolleri, Narwhal'ın işlem hacmi potansiyelinden tam olarak yararlanamaz. Verilerin yayılmasını konsensüsten ayırmış olsalar da, işlem hacminin artmasıyla Hotstuff/Jolteon'un lideri hala sınırlıdır.

Bu nedenle, Aptos, Narwhal DAG'ın üzerine, sıfır iletişim maliyetine sahip bir konsensüs protokolü olan Bullshark'ı dağıtmaya karar verdi. Ne yazık ki, Jolteon ile karşılaştırıldığında, Bullshark'ın yüksek işlem hacmini destekleyen DAG yapısı %50 gecikme süresi maliyeti getirdi.

DAG-BFT Arka Planı

Narwhal DAG'daki her bir tepe, bir tur ile ilişkilidir. r. tura girmek için, doğrulayıcının önce r-1. tura ait n-f tepeyi edinmesi gerekmektedir. Her doğrulayıcı, her turda bir tepe yayınlayabilir ve her tepe en az önceki turdaki n-f tepeyi 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 belirsizliğin olmamasıdır: Eğer iki doğrulama düğümü kendi DAG yerel görünümünde aynı v tepe noktasına sahipse, o zaman bu düğümler tamamen aynı v nedensel geçmişine sahiptir.

Genel Giriş

DAG'daki tüm düğümlerin toplam sırasını ek iletişim maliyeti olmadan uzlaşma sağlamak mümkündür. Bunun için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar, DAG'ın yapısını, düğümlerin önerileri temsil ettiği ve kenarların oylamayı temsil ettiği bir Konsensüs protokolü olarak yorumlar.

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

1. Önceden belirlenmiş sabit nokta: Her birkaç turda ( örneğin, Bullshark'taki iki turda ) önceden belirlenmiş bir lider olacaktır, liderin zirvesine sabit nokta denir.

2. Sıralama bağlantı noktası: doğrulayıcılar bağımsız ancak belirleyici bir şekilde hangi bağlantı noktalarının sıralanacağına ve hangi bağlantı noktalarının atlanacağına karar verir.

3. Nedensellik tarihini sıralama: Doğrulayıcılar birer birer sıralı referans noktasını işler, her referans noktası için, belirleyici kurallarla önceden düzensiz olan tüm zirveleri nedensellik tarihine göre sıralar.

Güvenliğin sağlanmasının anahtarı, adım 2'de, tüm dürüst doğrulayıcı düğümlerin aynı ön eki paylaşacak şekilde sıralı bir sabit nokta listesi oluşturduğundan emin olmaktır. Shoal'da, yukarıda belirtilen tüm protokollerle ilgili şu gözlemler yapılmıştır: Tüm doğrulayıcılar, ilk sıralı sabit nokta üzerinde hemfikirdir.

Bullshark gecikme süresi

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

Başlıca iki sorun var:

1. Ortalama blok gecikmesi: Bullshark'ta her çift turda bir referans noktası bulunur, her tek turun zirvesi ise oylama olarak yorumlanır. Yaygın durumlarda, referans noktalarını sıralamak için iki DAG turu gerekir, ancak referans noktasının nedensel tarihindeki zirvelerin sıralanmasını beklemek için daha fazla tura ihtiyaç vardır. Yaygın durumlarda, tek turlardaki zirvelerin üç tura, çift turlardaki referans noktası olmayan zirvelerin ise dört tura ihtiyacı vardır.

2. Arıza durumu gecikmesi: Eğer bir tur lideri yeterince hızlı bir şekilde referans noktasını yayamazsa, referans noktası sıralanamaz ( bu nedenle atlanır ), önceki turlardaki tüm sıralanmamış zirveler 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üşürür, özellikle Bullshark lideri beklemek için zaman aşımı kullanıyor olduğundan.

Shoal çerçevesi

Shoal, Bullshark( veya diğer herhangi bir Narwhal tabanlı BFT protokolünü ) ile her bir turda bir referans noktası olmasına izin verecek şekilde akış hattı işlemesiyle güçlendirdi ve DAG'daki tüm referans dışı zirvelerin gecikme süresini üç tura düşürdü. Shoal ayrıca DAG'da sıfır maliyetli lider itibar mekanizması tanıtarak seçimleri hızlı liderlere yönlendirdi.

Mücadele

DAG protokolü bağlamında, boru hattı işleme ve liderin itibarı zor sorunlar olarak kabul edilmektedir, nedenleri aşağıdaki gibidir:

1. Önceki akış hattı işlemleri, temel Bullshark mantığını değiştirmeye çalıştı, ancak bu esasen imkansız 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 fikridir. Liderlik kimliğinde bir anlaşmazlık olması bu protokollerin güvenliğini ihlal etmez, ancak Bullshark'ta tamamen farklı sıralamalara yol açabilir. Bu, dinamik ve belirleyici bir şekilde döngüsel zıpkınların seçilmesinin konsensüsü sağlamak için gerekli olduğu ve doğrulayıcıların gelecekteki zıpkınları seçmek amacıyla sıralı geçmiş üzerinde uzlaşması gerektiği sorunun özüne işaret eder.

Protokol

Yukarıda belirtilen zorluklara rağmen, çözüm basitlikte gizlidir. Shoal'da, DAG üzerinde yerel hesaplama yapma yeteneğinden yararlanarak, önceki turların bilgilerini saklama ve yeniden yorumlama yeteneği sağlanmıştır. Tüm doğrulayıcıların ilk sıralı referans noktasında uzlaşmasıyla elde edilen temel içgörü ile, Shoal birden fazla Bullshark örneğini sıralı işleme için birleştirir, böylece:

1. İlk sıralı ayak noktası, örneğin geçiş noktasıdır.
2. Ağırlık noktalarının neden-sonuç geçmişi liderin itibarını hesaplamak için kullanılır.

( Akış Hattı İşlemi

V vardır. Shoal, Bullshark'ın örneklerini birer birer çalıştırır, böylece her örnek için, bağlantı noktası F haritası tarafından önceden belirlenir. Her örnek bir bağlantı noktası sıralar, 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ı ankraj noktasının belirlendiği ana kadar çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu ankraj noktasında hemfikir oldu. Bu nedenle, tüm doğrulayıcılar, r+1. turdan itibaren DAG'ı yeniden yorumlamayı kesin bir şekilde kabul edebilir. Shoal, sadece r+1. turda yeni bir Bullshark örneğini başlattı.

En iyi durumda, bu, Shoal'ın her turda bir çapa sıralamasına olanak tanır. İlk turdaki çapa noktaları, ilk örneğe göre sıralanır. Ardından, Shoal ikinci turda kendine ait bir çapa noktası olan yeni bir örnek başlatır, bu çapa bu örneğe göre sıralanır, sonra üçüncü turda başka bir yeni örnek çapa noktası sıralar ve süreç devam eder.

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

( Liderlerin itibarı

Bullshark sıralama sırasında ankraj noktaları atlandığında, gecikme süresi artar. Bu durumda, önceki örneğin sıralama ankraj noktasından önce yeni örnek başlatılamayacağı için, boru hattı işleme tekniği etkisiz kalır. Shoal, her doğrulama düğümünün en son etkinlik tarihine dayanarak her doğrulama düğümüne bir puan atamak için bir itibar mekanizması kullanarak, gelecekte ilgili liderlerin kaybolan ankraj noktalarını işleme almasının olasılığını azaltı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 alacaktır, çünkü bu düğümler çökebilir, yavaşlayabilir veya kötü niyetli davranabilir.

Bu ilkeler, her puan güncellemesinde, yüksek puan alan liderlere yönelerek, tura kadar olan önceden tanımlanmış F haritalamasını belirli bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni haritalama üzerinde uzlaşabilmesi için, puanlar üzerinde uzlaşmaları gerekir ve böylece puan türetimi için kullanılan tarihte uzlaşmış olurlar.

Shoal'da, hat akışı işleme ve liderlik itibarı doğal olarak bir araya gelebilir, çünkü her ikisi de aynı temel teknolojiyi kullanmaktadır, yani ilk sıralı sabit noktada konsensüs sağlandıktan sonra DAG'ı yeniden yorumlamak.

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 haritalama F' 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 azaltır?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp###

( gereksiz gecikme süresi

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

Zaman aşımı da gecikme süresini önemli ölçüde artıracaktır, çünkü bunların uygun şekilde yapılandırılması çok önemlidir ve genellikle dinamik olarak ayarlanması gerekir, çünkü bu yüksek derecede ortama bağlıdır ) ağ ###. Bir sonraki liderliğe geçmeden önce, protokol arızalı lider için tam zaman aşımı gecikme cezası ödeyecektir. Bu nedenle, zaman aşımı ayarları çok ihtiyatlı olmamalıdır, ancak eğer zaman aşımı süresi çok kısaysa, protokol iyi liderleri atlayabilir.

Ne yazık ki, lider tabanlı protokoller ( gibi Hotstuff ve Jolteon ) esasen gecikme süresi gerektirir, böylece her liderin arızalandığında protokolün ilerlemesini garanti altına alır. Gecikme süresi olmadan, çöküşte olan bir lider bile protokolü sonsuza dek durdurabilir. Asenkron dönemlerde arızalı lider ile yavaş lider arasında ayrım yapılamadığından, gecikme süresi doğrulama düğümlerinin hiç Konsensüs aktifliği olmadan tüm liderleri değiştirmesine neden olabilir.

Bullshark'ta, DAG yapımı için gecikme süresi kullanılır, böylece senkronizasyon sırasında dürüst liderler DA'ya sabit noktalar ekleyebilir.