Shoal Çerçevesi: Aptos'taki Bullshark Gecikmesini Nasıl Azaltırız?

Genel Bakış

Aptos laboratuvarları, DAG BFT'deki iki önemli açık sorunu çözdü, gecikmeyi büyük ölçüde azalttı ve ilk kez belirli gerçek protokollerde duraklama gereksinimini ortadan kaldırdı. Genel olarak, arızasız durumlarda Bullshark'ın gecikmesini %40, arıza durumunda ise %80 oranında iyileştirdi.

Shoal, Narwhal tabanlı konsensüs protokollerini (, DAG-Rider, Tusk, Bullshark ) gibi, akış hattı ve liderin itibarı ile güçlendiren bir çerçevedir. Akış hattı, her turda bir referans noktası tanıtarak DAG sıralama gecikmesini azaltır; liderin itibarı 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, liderin itibarı, Shoal'ın tüm senaryolarda zaman aşımını ortadan kaldırmak için asenkron DAG inşasını kullanmasına olanak tanır. Bu, Shoal'ın genellikle gereken iyimser yanıtları içeren evrensel yanıt olarak adlandırdığımız özelliği sunmasına olanak tanır.

Bu teknoloji oldukça basit, temel protokollerin birden fazla örneğini sırayla çalıştırmayı içeriyor. Dolayısıyla, Bullshark ile örneklendirildiğinde, bir grup "köpekbalığı"nın bayrak yarışı yaptığı bir durumla karşılaşıyoruz.

Motivasyon

Blok zinciri ağlarının yüksek performansını hedeflerken, insanlar iletişim karmaşıklığını azaltmaya odaklandılar. Ancak, bu yaklaşım, önemli bir işlem hacmi artışı sağlamadı. Örneğin, Diem'in erken sürümünde uygulanan Hotstuff yalnızca 3500 TPS gerçekleştirdi, bu da hedeflenen 100k+ TPS'nin oldukça altında.

Son dönemdeki atılım, veri yayılımının liderlerin protokollerine dayanan ana bir darboğaz olduğunu anlamaktan kaynaklanıyor ve paralelleşmeden faydalanabiliyor. Narwhal sistemi, veri yayılımını temel konsensüs mantığından ayırarak, tüm doğrulayıcıların aynı anda veri yaydığı ve konsensüs bileşeninin yalnızca daha az miktarda meta veriyi sıraladığı bir mimari öneriyor. Narwhal belgesi, 160.000 TPS'lik bir verimlilik rapor ediyor.

Daha önce, Quorum Store - Narwhal'ın veri yayılımını ve uzlaşmayı nasıl ayırdığını ve bunu mevcut uzlaşma protokolü Jolteon'u genişletmek için nasıl kullanacağınızı tanıttık. Jolteon, Tendermint'in doğrusal hızlı yolu ile PBFT tarzı görünüm değişikliklerini birleştiren lider tabanlı bir protokoldür ve Hotstuff'un gecikmesini %33 oranında azaltır. Ancak, lider tabanlı uzlaşma protokollerinin Narwhal'ın işlem hacmi potansiyelini yeterince kullanamadığı açıktır. Veri yayılımını uzlaşmadan ayırmış olsak da, işlem hacmindeki artışla birlikte, Hotstuff/Jolteon'un liderleri hala sınırlıdır.

Bu nedenle, Bullshark'ı, sıfır iletişim maliyeti olan bir konsensüs protokolü olarak Narwhal DAG'ın üzerine dağıtmaya karar verildi. Ne yazık ki, Jolteon ile karşılaştırıldığında, Bullshark'a yüksek verimlilik sağlayan DAG yapısı %50'lik bir gecikme maliyeti getirdi.

Bu makalede Shoal'un Bullshark gecikmesini nasıl büyük ölçüde azalttığı anlatılmaktadır.

DAG-BFT Arka Planı

Narwhal DAG'daki her tepe noktası bir tura ilişkilidir. r. tura girmek için, doğrulayıcılar önce 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 turdaki n-f tepe noktasını referans almalıdır. Ağın asenkron yapısı 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 değildir: Eğer iki doğrulayıcı düğümü DAG yerel görünümünde aynı doruk v'ye sahipse, o zaman v'nin neden-sonuç geçmişi tamamen aynıdır.

Tam Sıra

DAG'daki tüm düğümlerin toplam sırasının, ek iletişim maliyetleri olmadan uzlaşmasını sağlamak mümkündür. Bunun için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar, DAG yapısını bir konsensüs 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. Rezervasyon Bağı: Her birkaç turda önceden belirlenmiş bir lider olacak, liderin zirvesine bağ denir;

2. Sıralama Bağlantı Noktası: Doğrulayıcılar bağımsız ancak kesin bir şekilde hangi bağlantı noktalarının sıralanacağına ve hangilerinin atlanacağına karar verir;

3. Sıralı Nedensel Tarih: Doğrulayıcılar, sıralı sabit nokta listelerini birer birer işlerler ve her sabit nokta için, nedensel tarihindeki tüm önceki düzensiz noktaları bazı deterministik kurallara göre sıralarlar.

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 sabitleme listesinin oluşturulmasını sağlamaktır. Shoal'da yukarıda belirtilen tüm protokollere aşağıdaki gözlemler yapılmaktadır:

Tüm doğrulayıcılar, ilk sıralı referansı kabul etti.

Bullshark Gecikmesi

Bullshark'ın gecikmesi, DAG'daki sıralı sabit noktalar arasındaki döngü sayısına bağlıdır. Bullshark'ın en pratik kısım senkron versiyonu, asenkron versiyona göre daha iyi bir gecikmeye sahip olsa da, en iyi seçenek değildir.

Soru 1: Ortalama blok gecikmesi. Bullshark'ta, her çift turda bir referans noktası vardır, her tek turda ise zirveler oy verme 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ı için daha fazla tura ihtiyaç vardır. Yaygın durumlarda, tek turdaki zirveler üç tura, çift turdaki referans noktasına ait olmayan zirveler ise 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, eğer bir tur lideri yeterince hızlı bir şekilde referans noktasını yayınlayamazsa, referans noktası sıralanamaz ( bu nedenle atlanır ), bu nedenle önceki turlardaki sıralanmamış tüm 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 zaman aşımının lideri beklemek için kullanıldığı durumlarda.

Shoal çerçevesi

Shoal, bu iki gecikme sorununu çözdü, Bullshark( veya Narwhal tabanlı herhangi bir BFT protokolünü), her bir turda bir referans noktası olmasını sağlayarak ve DAG içindeki tüm referans noktasız düğümlerin gecikmesini üç tura indirerek güçlendirdi. Shoal ayrıca DAG'da sıfır maliyetli lider itibar mekanizması tanıttı, bu da seçimlerin hızlı liderlere yönelmesini sağladı.

Mücadele

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

1. Önceki üretim hattı, temel Bullshark mantığını değiştirmeye çalıştı, ancak bu özünde 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 dayalı olarak gelecekteki liderlerin dinamik olarak seçilmesi fikridir. Liderlik statüsünde bir ayrımın bu protokollerin güvenliğini ihlal etmemesi gerekir, ancak Bullshark'ta, bu tamamen farklı bir sıralamaya yol açabilir, bu da sorunun özüne işaret eder; yani, döngüsel bağlantıyı dinamik ve kesin bir şekilde seçmek, uzlaşı sağlamak için gereklidir ve doğrulayıcılar, gelecekteki bağlantıları seçmek için sıralı geçmişte uzlaşmalıdır.

Sorun zorluğunun kanıtı olarak, Bullshark'ın uygulanması, şu anda üretim ortamında olan uygulama dahil, bu özellikleri desteklememektedir.

Protokol

Yukarıda belirtilen zorluklara rağmen, çözüm basitliğin ardında gizlidir.

Shoal'da, DAG üzerinde yerel hesaplama yapma yeteneğine dayanarak, önceki turların bilgilerini saklama ve yeniden yorumlama yeteneği sağlandı. Tüm doğrulayıcıların ilk sıralı referans noktasını kabul etmesiyle elde edilen temel içgörü sayesinde, Shoal birden fazla Bullshark örneğini sıralı bir şekilde bir araya getirerek bunları boru hattı işlemine tabi tutar; ( ilk sıralı referans noktası örneklerin geçiş noktasıdır ve ) referans noktasının nedensel tarihi liderin itibarını hesaplamak için kullanılır.

Akış Hattı

V haritası vardır. Shoal, her bir örnek için F haritasıyla önceden belirlenen bir sabit nokta olacak şekilde Bullshark'ın örneklerini birer birer çalıştırır. Her bir örnek bir sabit nokta sipariş eder, bu da bir sonraki örneğe geçişi tetikler.

Başlangıçta, Shoal, DAG'nin ilk turunda Bullshark'ın ilk örneğini başlattı ve bunu ilk sıralı sabit nokta belirlenene kadar çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu sabit noktayı kabul etti. Böylece, tüm doğrulayıcılar r+1. turdan itibaren DAG'ı yeniden yorumlamayı kesin bir şekilde kabul edebilir. Shoal, yalnızca r+1. turda yeni bir Bullshark örneği başlattı.

En iyi durumda, bu, Shoal'un 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 kendisi bir çapa noktasına sahiptir ve bu çapa o örneğe göre sıralanır, sonra üçüncü turda başka bir yeni örnek çapa noktası sipariş eder, ardından süreç devam eder.

Liderlerin İtibarı

Bullshark sıralama sürecinde, referans noktalarını atlarken gecikme artar. Bu durumda, önceki örnekte referans noktası sipariş edilmeden yeni bir örnek başlatılamayacağı için hat çekme tekniği işe yaramaz. Shoal, her doğrulama düğümünün en son etkinlik geçmişine dayalı olarak her doğrulama düğümüne bir puan atayarak, gelecekte kaybolan referans noktalarını işlemek için ilgili liderlerin seçilme olasılığının düşük olmasını sağlar. Protokole yanıt veren ve katılan doğrulayıcılar yüksek puan alacak, aksi takdirde, doğrulama düğümü düşük puan alacaktır çünkü çökebilir, yavaşlayabilir veya kötü niyetli olabilir.

Bu ilke, her puan güncellemesinde, yüksek puan alan liderlere yönelik olarak, turdan lidere önceden tanımlanmış F eşleme fonksiyonunun belirli bir şekilde yeniden hesaplanmasını sağlamaktır. Doğrulayıcıların yeni eşleme üzerinde uzlaşabilmesi için, puanlar üzerinde uzlaşmaları ve böylece puan türetimi için geçmişte bir uzlaşmaya varmaları gerekmektedir.

Shoal'da, akış hattı ve liderlik itibarı doğal olarak birleşebilir, çünkü her ikisi de DAG'ı ilk sıralı sabit noktasında uzlaşma sağlandıktan sonra 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ıların r. turda sıralı referans noktalarının nedensel geçmişine dayanarak r+1. turdan itibaren yeni bir eşleme F' hesaplaması gerektiğidir. Ardından, doğrulama düğümleri r+1. turdan itibaren güncellenmiş referans noktası seçme fonksiyonu F'yi 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, getirdikleri 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 tekniği gerektirmektedir.

Zaman aşımı aynı zamanda gecikmeyi de önemli ölçüde artırır, çünkü bunları uygun şekilde yapılandırmak çok önemlidir ve genellikle dinamik olarak ayarlamak gerekir, çünkü bu, çevre ( ağına ) yüksek derecede bağımlıdır. Protokol, bir sonraki liderine geçmeden önce,