Shoal çerçevesi: Aptos üzerindeki Bullshark için düşüş gecikme süresi inovasyon çözümü

Aptos Labs, son zamanlarda DAG BFT'deki iki önemli açık problemi çözdü, gecikmeyi önemli ölçüde azalttı ve ilk kez belirleyici gerçek protokollerde zaman aşımı gereksinimini ortadan kaldırdı. Genel olarak, hatasız durumlarda Bullshark'ın gecikmesini %40, arızalı durumlarda ise %80 oranında iyileştirdi.

Shoal, DAG-Rider, Tusk, Bullshark( gibi çerçevelerle ) üzerinden Narwhal tabanlı konsensüs protokolünü güçlendirmek için bir akış hattı işleme ve lider itibarı mekanizması kullanır. Akış hattı işlemesi, her turda bir referans noktası getirerek DAG sıralama gecikmesini azaltır, lider itibarı mekanizması ise referans noktasının en hızlı doğrulama düğümleri ile ilişkilendirilmesini sağlayarak gecikme sorununu daha da geliştirir. Ayrıca, lider itibarı, Shoal'ın tüm senaryolarında zaman aşımı mekanizmalarını ortadan kaldırmak için asenkron DAG yapısını kullanmasına olanak tanır. Bu, Shoal'ın genellikle gereken iyimser yanıt özelliklerini içeren "evrensel yanıt" olarak adlandırdığımız bir özelliği sunmasını sağlar.

Shoal'un teknolojisi oldukça basit olup, alt protokollerin birden fazla örneğini sırasıyla çalıştırmayı içerir. Bu nedenle, Bullshark ile örnekleme yaptığımızda, elde ettiğimiz etki, bir grup "köpekbalığı"nın bayrak yarışı yaptığı gibi olur.

Arka Plan ve Motivasyon

Blockchain ağlarının yüksek performansını hedeflerken, insanların iletişim karmaşıklığını azaltmaya odaklandıkları bir süreç olmuştur. Ancak, bu yöntem önemli bir artışa yol açmamıştır. Örneğin, Diem'in erken sürümünde uygulanan Hotstuff yalnızca 3500 TPS gerçekleştirmiştir, bu da 100.000+ TPS hedefimizin oldukça altındadır.

Son dönemdeki atılım, veri iletiminin liderlerin protokollerine dayanan ana darboğaz olduğunu anlamaktan ve paralelleşmeden faydalanmaktan kaynaklanmaktadır. Narwhal sistemi, veri iletimini çekirdek konsensüs mantığından ayırarak, tüm doğrulayıcıların aynı anda veri ilettiği ve konsensüs bileşeninin yalnızca az sayıda meta veriyi sıraladığı bir mimari önermektedir. Narwhal belgesi, 160.000 TPS’lik bir işleme kapasitesini rapor etmiştir.

Önceki yazılarda, verilerin iletimini konsensüsten ayıran Narwhal uygulamamız olan Quorum Store'u tanıttık ve bunu mevcut konsensüs protokolü Jolteon'u genişletmek için nasıl kullandığımızı açıkladık. Jolteon, Tendermint'in doğrusal hızlı yolunu ve PBFT tarzı görünüm değişikliklerini birleştiren lider tabanlı bir protokoldür ve Hotstuff gecikmesini %33 oranında düşürmektedir. Ancak, lider tabanlı konsensüs protokollerinin Narwhal'ın işlem hacmi potansiyelinden tam anlamıyla faydalanamadığı açıktır. Verilerin iletimini ve konsensüsü ayırmış olsak da, işlem hacmi arttıkça, Hotstuff/Jolteon'un liderleri hala sınırlı kalmaktadır.

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

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

DAG-BFT Arka Planı

Narwhal DAG'daki her bir köşe bir tur ile ilişkilidir. r. tura girmek için, doğrulayıcıların öncelikle r-1. tura ait n-f köşesini elde etmesi gerekmektedir. Her doğrulayıcı her turda bir köşe yayınlayabilir ve her köşe, en azından bir önceki turun n-f köşesini referans almalıdır. Ağın asenkron olmasından dolayı, farklı doğrulayıcılar herhangi bir anda 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ü kendi DAG yerel görünümünde aynı tepe noktası v'ye sahipse, o zaman v'nin neden-sonuç tarihleri tamamen aynıdır.

Genel Sıralama

Tüm düğümlerin toplam sırası üzerinde ek iletişim maliyeti olmadan uzlaşmak mümkündür. Bunun için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar, DAG'ın yapısını bir uzlaşma protokolü olarak yorumlar; burada düğümler önerileri, kenarlar ise oyları temsil eder.

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. Rezerv noktasını belirleme: Her birkaç turda (, Bullshark'taki iki turda ) olduğu gibi, önceden belirlenmiş bir lider olacaktır, liderin zirvesine rezerv noktası denir.

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

3. Nedensel Tarihi Sıralama: Doğrulayıcılar sıralı sabit nokta listesini tek tek işler, her sabit nokta için, belirli deterministik kurallar aracılığıyla nedensel tarihindeki tüm önceki düzensiz zirveleri 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ı öneki paylaşacak şekilde sıralı bir referans noktası listesi oluşturmasını sağlamaktır. Shoal'da yukarıda belirtilen tüm protokoller hakkında aşağıdaki gözlemleri yaptık:

Tüm doğrulayıcılar ilk sıralı bağlantıyı kabul eder.

Bullshark gecikme süresi

Bullshark'ın gecikme süresi, DAG'daki sıralı ankraj noktaları arasındaki döngü sayısına bağlıdır. Bullshark'ın en kullanışlı kısmi senkron sürümü, asenkron sürümden daha iyi bir gecikme süresine sahip olmasına rağmen, en iyi değildir.

Soru 1: Ortalama blok gecikme süresi. Bullshark'ta, her çift turda bir referans noktası vardır, her tek turdaki zirve ise oy verme olarak yorumlanır. Yaygın durumlarda, referans noktalarını sıralamak için iki tur DAG gereklidir, ancak referans noktalarının nedensel geçmişindeki zirvelerin referans noktalarının sıralanmasını beklemek için daha fazla tura ihtiyacı vardır. Yaygın durumlarda, tek turdaki zirvelerin üç tura, çift turdaki referans olmayan zirvelerin ise dört tura ihtiyacı vardır.

Soru 2: Arıza durumu gecikmesi. Yukarıdaki gecikme analizi arızasız durumlar için geçerlidir; diğer yandan, eğer bir turdaki lider yeterince hızlı bir şekilde referans noktasını yayınlayamazsa, referans noktası sıralanamaz ( bu nedenle atlanır ), bu da önceki turlardaki sıralanmamış tüm zirvelerin bir sonraki referans noktasının sıralanmasını beklemek zorunda kalmasına neden olur. Bu, coğrafi çoğaltma ağının performansını önemli ölçüde düşürecektir, özellikle Bullshark lideri beklemek için zaman aşımı kullandığından.

Shoal çerçevesi

Shoal, bu iki gecikme süresi sorununu çözdü; Bullshark ( veya diğer Narwhal tabanlı BFT protokollerini ) güçlendiren bir işlem hattı aracılığıyla, her turda bir referans noktası olmasına izin vererek, DAG'daki tüm referans noktası olmayan düğümlerin gecikme süresini üç tura düşürüyor. Shoal ayrıca DAG'da sıfır maliyetli bir lider itibar mekanizması tanıtarak, hızlı liderlerin seçilme eğilimini artırıyor.

Zorluk

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

1. Önceki hat akışı işlemleri, temel Bullshark mantığını değiştirmeye çalıştı, ancak bu özünde imkansız gibi görünüyor.

2. Liderlerin itibarı, DiemBFT'ye entegre edilmiş ve Carousel'de resmileştirilmiştir; bu, doğrulayıcıların geçmiş performanslarına dayanarak gelecekteki liderlerin dinamik bir şekilde seçilmesi ve Bullshark'taki ( referans noktası fikridir. Liderlik kimliğinde var olan ayrılıklar bu protokollerin güvenliğini ihlal etmemekle birlikte, Bullshark'ta tamamen farklı bir sıralama ile sonuçlanabilir; bu, sorunların özüne götürür. Yani, döngü referanslarını dinamik ve belirli bir şekilde seçmek, konsensüsü sağlamak için gereklidir ve doğrulayıcıların, gelecekteki referans noktalarını seçmek için sıralı bir tarih üzerinde uzlaşmaları gerekmektedir.

Soru zorluğunun kanıtı olarak, Bullshark'ın uygulamasının, şu anda üretim ortamında bulunan uygulamanın, bu özellikleri desteklemediğini dikkate alıyoruz.

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

Protokol

Yukarıda belirtilen zorluklara rağmen, çözümlerin basitlikte gizli olduğu kanıtlanmıştır.

Shoal'da, yerel hesaplamaları DAG üzerinde gerçekleştirme yeteneğine güveniyoruz ve önceki turların bilgilerini saklama ve yeniden yorumlama yeteneğini sağlıyoruz. Tüm doğrulayıcıların ilk sıralı referans noktasına dair ortak anlayışıyla, Shoal, birden fazla Bullshark örneğini sıralı olarak birleştirip onları işleme alarak, ) ilk sıralı referans noktasının örneklerin değiştirme noktası olduğu ve ( referans noktasının nedensel tarihinin liderlerin itibarını hesaplamak için kullanıldığı bir akış sağlıyor.

) akış hattı işleme

V haritası vardır. Shoal, her bir örnek için sabit noktanın harita F ile önceden belirlendiği şekilde, Bullshark'ın örneklerini birbiri ardına çalıştırır. Her örnek bir sabit noktayı sıralar, bu da bir sonraki örneğe geçişi tetikler.

İlk olarak, Shoal, DAG'ın ilk turunda Bullshark'ın ilk örneğini başlattı ve ilk sıralı ayak noktasının belirlendiği ana kadar bunu çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu ayak noktasında hemfikirdir. Bu nedenle, tüm doğrulayıcılar, r+1. turdan itibaren DAG'ı yeniden yorumlama konusunda kesin bir şekilde hemfikir olabilirler. Shoal, yalnızca r+1. turda yeni bir Bullshark örneğini başlattı.

En iyi durumda, bu, Shoal'ın her turda bir referans noktasını sıralamasına olanak tanır. İlk turdaki referans noktası, ilk örnek tarafından sıralanır. Ardından, Shoal ikinci turda yeni bir örnek başlatır, bu örneğin kendisine ait bir referans noktası vardır ve bu referans noktası o örnek tarafından sıralanır, ardından başka bir yeni örnek üçüncü turda referans noktasını sıralar, bu süreç devam eder.

liderlik itibarı

Bullshark sıralama sırasında ankraj noktalarını atladığınızda, gecikme süresi artar. Bu durumda, önceki örnek sıralama ankraj noktasından önce 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 kaybolan ankraj noktalarını işlemek için ilgili liderlerin seçilme olasılığının daha düşük olmasını sağlamaktadı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 olabilir.

Felsefesi, her puan güncellemesinde, tura liderliğe yönelik önceden tanımlanmış haritalama F'yi kesin bir şekilde yeniden hesaplamaktır ve daha yüksek puan alan liderlere yöneliktir. Doğrulayıcıların yeni haritalama üzerinde uzlaşabilmeleri için puanlar üzerinde uzlaşmaları ve böylece puanların türetilmesi için tarihsel bir uzlaşma sağlamaları gerekir.

Shoal'da, akış işleme ve liderin itibarının doğal olarak bir araya gelmesi mümkündür çünkü her ikisi de ilk sıralı sabit nokta üzerinde uzlaşma sağlandıktan sonra DAG'ı yeniden yorumlayan aynı temel teknolojiyi kullanır.

Aslında, tek fark, r. turda referans noktalarının sıralanmasının ardından, doğrulayıcıların yalnızca r. turdaki sıralı referans noktalarının nedensel tarihine dayanarak, r+1. turdan itibaren yeni bir haritalama F' hesaplamaları gerektiğidir. Ardından, doğrulayıcı düğümleri r+1. turdan itibaren güncellenmiş referans noktası seçim fonksiyonu F' kullanarak Bullshark'ın yeni bir örneğini gerçekleştirir.

zaman aşımını ortadan kaldırma

Zaman aşı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ırır, bu da hata ayıklama sürecinin karmaşıklığını artırır ve daha fazla gözlemlenebilirlik teknikleri gerektirir.

Aşım aynı zamanda gecikme süresini de önemli ölçüde artıracaktır.