Shoal çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl düşürebiliriz?

Genel Bakış

Aptos labs, DAG BFT'deki iki önemli açık sorunu çözdü, gecikme süresini büyük ölçüde düşürdü ve ilk kez deterministik 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, DAG-Rider, Tusk, Bullshark ( gibi çerçeveler için Narwhal tabanlı uzlaşma protokolünü ), akış hatları ve liderin itibarını kullanarak geliştiren bir yapıdır. Akış hattı, her turda bir referans noktası ekleyerek DAG sıralama gecikmesini azaltır, liderin itibarı ise referans noktalarını en hızlı doğrulama düğümleri ile ilişkilendirerek gecikme sorununu daha da iyileştirir. Ayrıca, liderin itibarı Shoal'un tüm senaryolarında zaman aşımını ortadan kaldırmak için asenkron DAG yapılarını kullanmasına olanak tanır. Bu, Shoal'un genellikle gerekli olan iyimser yanıtları içeren evrensel yanıt olarak adlandırılan bir özelliği sunmasını sağlar.

Bu teknoloji oldukça basit olup, alt protokollerin birden fazla örneğinin sırayla çalıştırılmasını içerir. Bu nedenle, Bullshark ile örneklendirildiğinde, "köpekbalıkları" olan bir grup bayrak yarışı yapmaktadır.

Motivasyon

Blockchain ağı yüksek performansını hedeflerken, iletişim karmaşıklığını azaltmaya yönelik sürekli bir ilgi olmuştur. Ancak, bu yaklaşım, önemli bir throughput 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突破, veri iletiminin liderlik protokolüne dayalı ana darboğaz olduğunu anlamaktan ve paralelleşmeden fayda sağlanabileceğinden kaynaklanıyor. 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 öneriyor. Narwhal belgesi, 160.000 TPS'lik bir verimlilik rapor ediyor.

Daha önceki makalemizde 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 doğrusal 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ür. Ancak, lider tabanlı konsensüs protokollerinin Narwhal'ın işlem hacmi potansiyelinden tam olarak yararlanamadığı açık. Veri yayılımını konsensustan ayırmış olsak da, işlem hacmi arttıkça Hotstuff/Jolteon liderleri hala sınırlı kalmaktadır.

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

Bu makale, Shoal'un Bullshark gecikme süresini önemli ölçüde nasıl azalttığı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. tura ait n-f tepe noktasını elde etmelidir. Her doğrulayıcı her turda bir tepe noktası yayınlayabilir ve her tepe noktası en az bir ö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ğrulayıcı düğüm, DAG yerel görünümlerinde aynı v tepe noktasına sahipse, o zaman tamamen aynı v nedensel geçmişine sahiptirler.

Genel Sıralama

DAG'daki tüm düğümlerin toplam sırası üzerinde ek iletişim yükü olmadan uzlaşmaya varılabilir. 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 protokollerinin aşağıdaki yapıya sahip olduğu görülmektedir:

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

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

3. sıralama nedensel tarih: doğrulayıcılar birer birer sıralı ankraj listelerini işlerler ve her bir ankraj için, nedensel tarihindeki tüm önceki düzensiz zirveleri bazı 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üğümlerinin ortak bir ön ek paylaşmaları için 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 yapıyoruz:

Tüm doğrulayıcılar ilk sıralı referans noktasını kabul eder.

Bullshark gecikme süresi

Bullshark'ın gecikme süresi, DAG'daki sıralı ankra noktaları arasındaki tur 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 durum en iyi değildir.

Soru 1: Ortalama Blok Gecikme Süresi. Bullshark'ta, her çift turda bir ana nokta bulunur, her tek turda ise zirveler oy verme olarak yorumlanır. Yaygın durumlarda, ana noktaları sıralamak için iki tur DAG gereklidir, ancak ana noktanın nedensel tarihindeki zirvelerin sıralanması için daha fazla tura ihtiyaç vardır. Yaygın durumlarda, tek turdaki zirveler üç tura, çift turdaki ana olmayan zirveler ise dört tura ihtiyaç duyar.

Soru 2: Arıza vakası gecikmesi, yukarıdaki gecikme analizi arızasız durumlar için geçerlidir, öte yandan, eğer bir tur lideri yeterince hızlı bir şekilde sabit noktayı yayınlamazsa, sabit nokta sıralanamaz ( bu nedenle atlanır ), bu nedenle önceki turlardaki tüm sıralanmamış zirveler 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ığı düşünüldüğünde.

Shoal çerçevesi

Shoal, bu iki gecikme süresini çözdü, Bullshark( veya Narwhal tabanlı herhangi bir BFT protokolü) üzerinden boru hattını güçlendirerek, her turda bir referans noktasının olmasına izin verir ve DAG'daki tüm referans noktası olmayan düğümlerin gecikmesini üç tura düşürür. Shoal ayrıca DAG'da sıfır maliyetli lider itibar mekanizmasını tanıtarak, seçimlerin hızlı liderlere yönlenmesini sağlar.

Zorluk

DAG protokolü bağlamında, boru hattı ve liderlerin itibarı zor bir sorun olarak kabul edilmektedir, nedenleri aşağıdaki gibidir:

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

2. Liderlerin itibarı DiemBFT'ye dahil edildi ve Carousel'de resmileştirildi, bu, doğrulayıcıların geçmiş performansına göre gelecekteki liderlerin dinamik olarak seçilmesinin ( Bullshark'taki halka ) ile ilgili bir fikridir. Liderlik statüsünde bir görüş ayrılığı olması, bu protokollerin güvenliğini ihlal etmezken, Bullshark'ta tamamen farklı sıralamalara yol açabilir, bu da meselenin özünü ortaya çıkarır; dinamik ve belirleyici bir şekilde halka seçimi, mutabakatı sağlamak için gereklidir ve doğrulayıcıların gelecekteki halkayı seçmek için sıralı tarih üzerinde anlaşmaya varması gerekir.

Soru zorluğunun kanıtı olarak, Bullshark'ın uygulamasını, şu anda üretim ortamında bulunan uygulamalar dahil, bu özellikleri desteklemediğini fark ettik.

Protokol

Bu yukarıdaki zorluklara rağmen, dediği gibi, çözümlerin basit şeylerin içinde gizli olduğu kanıtlanmıştır.

Shoal'da, DAG üzerinde yerel hesaplama yapabilme yeteneğine güveniyoruz ve önceki turların bilgilerini saklama ve yeniden yorumlama yeteneğini gerçekleştirdik. Tüm doğrulayıcıların ilk sıralı çivi noktasının temel içgörüsünde mutabık kaldığına dayanarak, Shoal birden fazla Bullshark örneğini sıralı bir şekilde birleştirerek bunları işleme alır, böylece ( ilk sıralı çivi noktası örneklerin geçiş noktasıdır ve ) çivi noktasının neden-sonuç geçmişi liderin itibarını hesaplamak için kullanılır.

Akış Hattı

V dönüşümü vardır. Shoal, her bir örnek için sabitin F dönüşümü ile önceden belirlendiği şekilde, Bullshark'ın örneklerini birer birer çalıştırır. Her örnek bir sabit sipariş 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 ilk sıralı çapa belirlenene kadar bunu çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu çapa katılıyor. Bu nedenle, tüm doğrulayıcılar r+1. turdan itibaren DAG'ı yeniden yorumlama konusunda kesin bir şekilde hemfikir olabilir. Shoal, sadece r+1. 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 yeni bir örnek başlatır, bu örneğin kendisinin bir çapa noktası vardır, bu çapa o örneğe göre sıralanır, sonra üçüncü turda başka bir yeni örnek çapa noktası sipariş eder ve bu süreç devam eder.

Liderlerin İtibarı

Bullshark sıralama sırasında sabitleyici atlandığında, gecikme süresi artar. Bu durumda, boru hattı teknolojisi etkisizdir, çünkü yeni bir örneği başlatmadan önce önceki örneğin sabitleyicisini sipariş etmek mümkün değildir. Shoal, her doğrulama düğümünün son etkinlik geçmişine dayalı olarak her doğrulama düğümüne bir puan atayarak, gelecekte kaybolan sabitleyicileri işlemek için ilgili liderin seçilme olasılığının düşük olmasını garanti eder. 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ş olabilir veya kötü niyetli davranabilir.

Temel ilke, her puan güncellemesinde, yüksek puan alan liderlere yanlılık göstererek, tura liderine belirlenmiş bir F haritalamasını kesin bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni haritalama üzerinde uzlaşabilmesi için, puanlar üzerinde uzlaşmaları ve böylece puan türetiminde kullanılan geçmişte bir uzlaşma sağlamaları gerekir.

Shoal'da, akış hatları ve liderlik itibarı 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ının ardından, doğrulayıcının sadece r. turda sıralı referans noktalarının nedensel tarihine dayanarak, r+1. turdan itibaren yeni bir eşleme F' hesaplaması gerektiğidir. Daha sonra, doğrulama düğümü r+1. turdan itibaren güncellenmiş referans noktası seçim fonksiyonu F' kullanarak Bullshark'ın yeni bir örneğini gerçekleştirir.

Daha fazla zaman aşımı yok

Zaman aşımı, lider tabanlı belirleyici kısmi senkron BFT uygulamalarının hepsinde 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, bu da hata ayıklama sürecinin karmaşıklığını artırmakta ve daha fazla gözlemlenebilirlik tekniği gerektirmektedir.

Zaman aşımı da gecikme süresini önemli ölçüde artırabilir, çünkü bunların uygun şekilde yapılandırılması çok önemlidir ve genellikle dinamik ayarlamaları gerektirir, çünkü bu ortam( ağına) son derece bağımlıdır. Protokol, bir sonraki liderine geçmeden önce arızalı lider için tam zaman aşımı gecikme cezası öder. Bu nedenle, zaman aşımı ayarları fazla temkinli olmamalıdır, ancak eğer