Shoal çerçevesi: Aptos üzerindeki Bullshark'ın gecikme süresini büyük ölçüde azaltma

Aptos Labs, yakın zamanda DAG BFT'deki iki önemli açık sorunu çözdü, gecikme süresini önemli ölçüde azalttı ve deterministik pratik protokolde zaman aşımına olan ihtiyacı ilk kez ortadan kaldırdı. Genel olarak, arıza olmadığında Bullshark'ın gecikmesi %40 oranında iyileşti, arıza durumunda ise %80 oranında iyileşti.

Shoal, Narwhal tabanlı konsensüs protokolünü ( DAG-Rider, Tusk, Bullshark ) gibi güçlendirmek için bir çerçevedir. Boru hattı, her turda bir referans noktası ekleyerek DAG sıralama gecikmesini azaltırken, lider itibar sistemi referans noktalarının en hızlı doğrulama düğümleriyle ilişkilendirilmesini sağlayarak gecikme sorununu daha da iyileştirir. Ayrıca, lider itibar sistemi, 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 gerekli olan iyimser yanıtları içeren genel yanıt verme özelliklerini sağlamasını mümkün kılar.

Bu teknoloji oldukça basit olup, temel protokollerin birden fazla örneğini sırayla çalıştırmayı içerir. Bu nedenle, Bullshark ile örneklendirildiğinde, devam eden bir bayrak yarışı yapan bir grup "köpek balığı" elde ederiz.

Arka Plan

Blok zinciri ağlarının yüksek performansını hedeflerken, insanları iletişim karmaşıklığını azaltmaya odaklanmıştır. Ancak bu yaklaşım, throughput'ta kayda değer bir artış sağlamadı. Örneğin, Diem'in erken sürümlerinde uygulanan Hotstuff yalnızca 3500 TPS'e ulaştı, bu da 100.000+ TPS hedefinin çok altında.

Son dönemdeki atılım, veri yayılımının liderlik protokolüne dayalı ana darboğaz olduğunu anlamaktan kaynaklanıyor ve paralelleşmeden faydalanabilir. Narwhal sistemi veri yayılımını temel konsensüs mantığından ayırarak, tüm doğrulayıcıların aynı anda veri yayımladığı 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 hacmini rapor ediyor.

Daha önce Quorum Store'u, yani Narwhal uygulamamızı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 kullanabileceğimizi tanıttık. Jolteon, Tendermint'in lineer hızlı yolunu ve PBFT tarzı görünüm değişimlerini birleştiren lider tabanlı bir protokoldür ve Hotstuff gecikmesini %33 oranında azaltabilir. Ancak, lider tabanlı uzlaşma protokollerinin Narwhal'ın verimlilik potansiyelinden tam olarak yararlanamadığı açıktır. Veri yayılımını uzlaşmadan ayırmış olmasına rağmen, verimlilik arttıkça Hotstuff/Jolteon'un lideri hala sınırlıdır.

Bu nedenle, Bullshark'ı, sıfır iletişim maliyetine sahip bir konsensüs protokolü olan Narwhal DAG'ın üzerine konuşlandırmaya karar verdik. Ne yazık ki, Jolteon'a kıyasla, Bullshark'ın yüksek işlem hacmini destekleyen DAG yapısı %50 gecikme süresi maliyeti getirmektedir.

Bu makale, Shoal'ın Bullshark gecikme süresini nasıl büyük ölçüde azalttığını tanıtmaktadır.

DAG-BFT Arka Planı

Narwhal DAG'daki her bir köşe bir tur ile ilişkilidir. r turuna girmek için, doğrulayıcı öncelikle r-1 turuna ait n-f köşeyi elde etmelidir. Her doğrulayıcı her turda bir köşe yayınlayabilir ve her köşe en az bir önceki turun n-f köşesini referans almalıdır. Ağın asenkron olması nedeniyle, farklı doğrulayıcılar herhangi bir anda DAG'ın farklı yerel görüntülerini 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ümünde aynı v tepe noktasına sahipse, o zaman v'nin nedensel geçmişi tamamen aynıdır.

Genel Giriş

DAG'daki tüm tepe noktalarının toplam sırası, ek iletişim maliyeti olmadan uzlaşmaya varılabilir. Bunun için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar, DAG'ın yapısını, tepe noktalarının önerileri ve kenarların oyları temsil ettiği bir uzlaşma protokolü olarak yorumlamaktadır.

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ş referans noktası: Her birkaç turda (, Bullshark'taki iki turda ) gibi, önceden belirlenmiş bir lider vardır ve liderin zirvesine referans noktası denir.

2. Sıralama Anahtarları: Doğrulayıcılar, bağımsız ancak kesin bir şekilde hangi anahtarların sıralanacağına ve hangi anahtarların atlanacağına karar verir.

3. Neden-sonuç tarihini sıralama: Doğrulayıcılar sırasıyla sıralı sabit nokta listesini işler, her sabit nokta için belirli deterministik kurallar aracılığıyla neden-sonuç tarihindeki tüm önceki düzensiz düğümleri sıralar.

Güvenliğin sağlanmasının anahtarı, adım (2)'de tüm dürüst doğrulayıcı düğümler tarafından oluşturulan sıralı referans noktası listesinin aynı öneki paylaşmasını sağlamaktır. Shoal'da, bu protokollerin her biri 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ı referans 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 olsa da, bu en iyi seçenek 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 noktası neden-sonuç tarihindeki zirvelerin sıralanması için daha fazla tur beklemesi gerekir. Yaygın durumlarda, tek turlardaki zirveler üç tur, çift turlardaki referans olmayan zirveler ise dört tur gerektirir.

Soru 2: Arıza durumu gecikme süresi. 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ı yayamazsa, o 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üşü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 Narwhal tabanlı herhangi bir BFT protokolü) aracılığıyla hatları güçlendirerek her turda bir referans noktası olmasını sağladı ve DAG'daki tüm referans noktası olmayan düğümlerin gecikmesini üç tura indirdi. Shoal, DAG içinde sıfır maliyetli lider itibar mekanizması da tanıttı, bu da seçimi hızlı liderler lehine kaydırdı.

Mücadele

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

1. Önceki akış şeması, temel Bullshark mantığını değiştirmeye çalıştı, ancak bu esasen 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 dayanarak gelecekteki liderleri dinamik olarak seçme fikridir. Liderlik kimliğinde var olan anlaşmazlık bu protokollerin güvenliğini ihlal etmemekte, ancak Bullshark'ta, tamamen farklı bir sıralamaya yol açabilir ki bu, sorunun özünü ortaya çıkarır; yani dinamik ve belirleyici bir şekilde döngüsel bağlayıcıları seçmek, uzlaşım sağlamak için gereklidir ve doğrulayıcıların gelecekteki bağlayıcıları seçmek için sıralı tarih üzerinde uzlaşmaları gerekmektedir.

Sorunun zorluğuna dair bir kanıt olarak, Bullshark'ın uygulanmasına dikkat çekiyoruz; bu uygulama, şu anda üretim ortamında bulunan uygulama, bu özellikleri desteklememektedir.

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ı ankraj noktasının temel içgörüsünde hemfikir olmasıyla, Shoal birden fazla Bullshark örneğini sıralı olarak birleştirir ve bunları işleme alır, böylece ( ilk sıralı ankraj noktası örneklerin geçiş noktasıdır ve ) ankraj noktasının nedensel geçmişi liderin itibarını hesaplamak için kullanılır.

Akış Hattı

V vardır. Shoal, Bullshark'ın örneklerini birer birer çalıştırır, böylece her örnekte, ankraj F haritalaması ile önceden belirlenir. Her örnek bir ankraj sıralar ve bu, bir sonraki örneğe geçişi tetikler.

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

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

Liderlerin İtibarı

Bullshark sıralaması sırasında, ankraj noktalarını atlamak gecikme süresini artırır. Bu durumda, önceki örnek sıralama ankraj noktasından önce yeni bir örnek başlatılamadığı için, boru hattı teknolojisi işe yaramaz. Shoal, her doğrulama düğümünün son etkinlik geçmişine göre 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 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 alacak, çünkü çökme, yavaşlama veya kötü niyetli davranış sergileme olasılıkları vardır.

Felsefesi, her puan güncellemesinde, tura göre liderin önceden tanımlanmış haritasını F, daha yüksek puan alan liderlere yönelerek kesin olarak yeniden hesaplamaktır. Doğrulayıcıların yeni harita üzerinde uzlaşabilmeleri için, puan üzerinde uzlaşmaları ve böylece türetilen puanlar için tarihte uzlaşmaları gerekir.

Shoal'da, akış hattı ve liderlik itibarı doğal olarak bir araya gelebilir, çünkü her ikisi de ilk sıralı sabit noktada 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ıların yalnızca r. turda sıralı referans noktalarının nedensel geçmişine dayanarak r+1. turdan itibaren yeni haritalama F'yi hesaplaması gerektiğidir. Ardından, doğrulama düğümleri r+1. turdan itibaren güncellenmiş referans noktası seçim 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ı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 tekniği gerektirmektedir.

Zaman aşımı da gecikme süresini önemli ölçüde artırır, çünkü bunları uygun şekilde yapılandırmak çok önemlidir ve genellikle dinamik olarak ayarlanması gerekir, çünkü bu, ortam( ağına) yüksek derecede bağlıdır. Protokol, bir sonraki lidere geçmeden önce arızalı lider için tam zaman aşımı gecikme cezası ödeyecektir.