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

Genel Bakış

Aptos laboratuvarları, DAG BFT'deki iki önemli açık sorunu çözdü, gecikmeyi büyük ölçüde azalttı ve ilk kez, deterministik gerçek protokollerde duraklama 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ü (, DAG-Rider, Tusk, Bullshark ) gibi, boru hattı ve lider itibarı artırarak bir çerçevedir. Boru hattı, her turda referans noktaları getirerek DAG sıralama gecikmesini azaltır; lider itibarı, referans noktalarının en hızlı doğrulama düğümleri ile ilişkili olmasını sağlayarak gecikme sorununu daha da geliştirir. Ayrıca, lider itibarı, Shoal'ın tüm senaryolarda zaman aşımını ortadan kaldırmak için asenkron DAG yapısını kullanmasını sağlar. Bu, Shoal'ın genel yanıt verme özellikleri sunmasını sağlar ve genellikle gerekli olan iyimser yanıtları içerir.

Bu teknoloji çok basit, temel protokollerin birden fazla örneğini sırayla çalıştırmayı içeriyor. Bu nedenle, Bullshark ile örneklendirildiğinde, elde edilen, bir bayrak yarışı yapan "köpekbalıkları" grubudur.

Motivasyon

Blockchain ağlarının yüksek performansını hedeflerken, insanlar iletişim karmaşıklığını azaltmaya odaklandılar. Ancak, bu yaklaşım önemli bir üretkenlik artışı sağlamadı. Örneğin, Diem'in erken sürümünde uygulanan Hotstuff yalnızca 3500 TPS sağladı; bu, 100k+ TPS hedefine çok uzak.

Son zamanlarda, veri yayılmasının liderlik protokollerine dayalı ana darboğaz olduğunu anlamaktan kaynaklanan bir atılım gerçekleşti ve paralelleşmeden yararlanılabilir. Narwhal sistemi, veri yayılımını çekirdek konsensüs mantığından ayırarak, tüm doğrulayıcıların aynı anda veri yaydığı ve konsensüs bileşeninin yalnızca az miktarda meta veriyi sıraladığı bir yapı önerdi. Narwhal belgesi, 160.000 TPS'lik bir işleme kapasitesini rapor etti.

Daha önce tanıtılan Quorum Store, mevcut konsensüs protokolü Jolteon'u genişletmek için veri yayılımı ve konsensüsü ayırmıştır. 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 ve Hotstuff gecikmesini %33 oranında azaltır. Ancak, lider tabanlı konsensüs protokolleri Narwhal'ın verimlilik potansiyelinden tam olarak yararlanamaz. Veri yayılımını ve konsensüsü ayırmış olmasına rağmen, verimlilik arttıkça Hotstuff/Jolteon'un lideri hala sınırlıdır.

Bu nedenle, Narwhal DAG'ı üzerinde, sıfır iletişim maliyeti olan bir konsensüs protokolü olan Bullshark konuşlandırılmıştır. Ne yazık ki, Jolteon ile karşılaştırıldığında, Bullshark'ın yüksek throughput'u destekleyen DAG yapısının %50'lik bir gecikme maliyeti vardır.

Bu makale, Shoal'un Bullshark gecikmesini nasıl önemli ölçüde azalttığını açıklamaktadır.

DAG-BFT Arka Planı

Narwhal DAG'daki her bir köşe, tur sayısı ile ilişkilidir. r. tura girmeden önce, doğrulayıcıların önceki r-1 turundaki n-f köşeyi elde etmeleri gerekir. Her doğrulayıcı, her turda bir köşe yayınlayabilir ve her köşe, en azından önceki turdaki n-f köşeyi 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 belirsiz değildir: Eğer iki doğrulayıcı düğüm DAG'ın yerel görünümünde aynı tepe noktasına v sahipse, o zaman v'nin neden-sonuç geçmişi tamamen aynıdır.

Toplam Sıra

Tüm DAG köşelerinin toplam sıralamasında ek iletişim maliyeti olmadan uzlaşma sağlanabilir. Bunun için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar DAG yapısını bir konsensüs protokolü olarak yorumlar; köşeler önerileri, kenarlar ise oylamayı 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. Belirlenmiş Aşama: Her birkaç turda önceden belirlenmiş bir lider vardır, bu liderin zirvesine aşama denir.

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

3. Nedensellik Tarihini Sıralama: Doğrulayıcılar, sıralı referans noktası listesini tek tek işler ve her referans noktasının neden-sonuç tarihindeki ö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 oluşturduğu sıralı sabit nokta 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ında hemfikirdir.

Bullshark Gecikmesi

Bullshark'ın gecikmesi, DAG'daki sıralı referans noktaları arasındaki tur sayısına bağlıdır. Bullshark'ın en pratik kısım senkron versiyonları asenkron versiyonlardan daha iyi bir gecikmeye sahip olsa da, bu en iyi durum değildir.

Soru 1: Ortalama blok gecikmesi. Bullshark'ta, her çift turda bir köşe noktası vardır, tek turlardaki zirveler oy verme olarak yorumlanır. Genel durumda, köşe noktalarını sıralamak için iki tur DAG gereklidir, ancak köşe noktalarının sebep-sonuç geçmişindeki zirvelerin sıralanması için daha fazla tur beklenmesi gerekir. Genellikle, tek turlardaki zirveler üç tur, çift turlardaki köşe olmayan zirveler ise dört tur beklemektedir.

Soru 2: Arıza durumu gecikmesi. Yukarıdaki gecikme analizi arızasız durumlar için geçerlidir, diğer yandan, eğer bir lider yeterince hızlı bir şekilde anahtarı yayınlayamazsa, anahtarın sıralanması mümkün olmayacaktır ( bu nedenle atlanır ), önceki turlardaki sıralanmamış tüm düğümlerin bir sonraki anahtar sıralanana kadar beklemesi gerekecektir. Bu, coğrafi çoğaltma ağının performansını önemli ölçüde azaltacaktır, özellikle Bullshark liderin zaman aşımına uğramasını beklediği için.

Shoal çerçevesi

Shoal, bu iki gecikme sorununu çözdü, Bullshark( veya diğer Narwhal tabanlı BFT protokollerinin ) güçlendirilmesi için bir boru hattı aracılığıyla, her turda bir referans noktası olmasına izin vererek, DAG'daki tüm referans noktasına sahip olmayan düğümlerin gecikmesini üç tura düşürüyor. Shoal ayrıca DAG'da sıfır maliyetli lider itibar mekanizmasını tanıtarak, hızlı liderlere yönelmiş bir seçim yapmaktadır.

Mücadele

DAG protokolü bağlamında, boru hattı ve liderin itibarının zorlu sorunlar olarak kabul edilmesinin nedenleri şunlardır:

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'ye dahil edilmiştir ve Carousel'de resmileştirilmiştir, doğrulayıcıların geçmiş performansına göre gelecekteki liderleri dinamik olarak seçmektedir (Bullshark'taki çapa ). Liderlik statüsünde bir anlaşmazlık olmasına rağmen, bu protokollerin güvenliğini ihlal etmemektedir, ancak Bullshark'ta tamamen farklı sıralamalara yol açabilir, bu da sorunun özünü ortaya koymaktadır: dinamik ve belirleyici bir şekilde çark çapasını seçmek, konsensüsü çözmek için gereklidir, doğrulayıcılar gelecekteki çapa seçmek için sıralı tarih üzerinde uzlaşmalıdır.

Sorun zorluğunun kanıtı olarak, Bullshark'ın uygulaması (, mevcut üretim ortamındaki uygulama ) bu özellikleri desteklemiyor.

Protokol

Yukarıda belirtilen zorluklara rağmen, çözüm basitlikte gizlidir.

Shoal'da, DAG üzerinde yerel hesaplama yapabilme yeteneğimize dayanarak, önceki tur bilgilerini saklama ve yeniden yorumlama yeteneği sağladık. Tüm doğrulayıcıların ilk sıralı referans noktasını kabul etmesi gerektiği temel anlayışı ile, Shoal, birden fazla Bullshark örneğini ardışık işleme almak için sıralı bir şekilde birleştirir, böylece ( ilk sıralı referans noktası örneklerin geçiş noktasıdır, ) referans noktasının nedensel geçmişi liderin itibarını hesaplamak için kullanılır.

Montaj Hattı

V haritası vardır. Shoal, her birinin sabitinin F haritası tarafından önceden belirlendiği Bullshark örneklerini birer birer çalıştırır. Her örnek bir sabit sipariş eder ve bir sonraki örneğe geçişi tetikler.

İlk olarak, Shoal DAG'ın ilk aşamasında Bullshark'ın ilk örneğini başlatır ve ilk sıralı bağlantıyı belirleyene kadar çalışır, örneğin r. aşamada. Tüm doğrulayıcılar bu bağlantıyı kabul eder. Bu nedenle, tüm doğrulayıcılar r+1. aşamadan itibaren DAG'ı yeniden yorumlamayı kesin olarak kabul edebilir. Shoal, r+1. aşamada yeni bir Bullshark örneğini başlatır.

En iyi durumda, bu, Shoal'ın her turda bir çapa sipariş etmesine olanak tanır. İ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 kendine ait bir çapa noktası vardır, bu çapa örneğe göre sıralanır, ardından üçüncü turda başka bir yeni örnek çapa noktası sipariş eder, süreç devam eder.

Liderlerin İtibarı

Bullshark sıralama sırasında ankraj noktalarının atlanması durumunda gecikme artar. Bu durumda, önceki örnek ankraj noktası sipariş edilmeden yeni örneğin başlatılması mümkün olmadığından, boru hattı teknolojisi çaresiz kalır. Shoal, her doğrulama düğümünün en son faaliyet geçmişine dayanarak puanlar atayarak, gelecekte ilgili liderlerin kaybolan ankraj noktalarını işleme alması olasılığının azalmasını sağlamak için bir itibar mekanizması kullanı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şlık veya kötü niyetli davranış sergileyebilir.

Felsefesi, her puan güncellemesinde, liderin önceden tanımlanmış haritası F üzerinden, daha yüksek puan alan liderlere yönelerek, belirli bir şekilde yeniden hesaplanmasını sağlamaktır. Doğrulayıcıların yeni harita üzerinde uzlaşabilmeleri için, puan üzerinde uzlaşmaları ve böylece puanların türetilmesi için kullanılan geçmişte uzlaşmaları gerekir.

Shoal'da, akış şeması ve liderlik itibarı doğal olarak bir araya gelebilir, çü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ıralaması yapıldıktan sonra, doğrulayıcıların yalnızca r. turdaki sıralı referans noktalarının neden-sonuç tarihine dayanarak yeni bir F' haritalaması hesaplamaları 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 örneğini uygular.

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ç durum sayısını artırmakta, bu da hata ayıklama sürecinin karmaşıklığını artırmakta ve daha fazla gözlemleme tekniği gerektirmektedir.

Zaman aşımı gecikmeyi önemli ölçüde artırabilir, çünkü bunların uygun şekilde yapılandırılması çok önemlidir ve genellikle dinamik olarak ayarlanması gerekir, çünkü bu, çevre ( ağına ) son derece bağımlıdır. Protokol, bir sonraki liderliğe geçmeden önce arızalı liderler için tam zaman aşımı gecikme cezası ödeyecektir. Bu nedenle, zaman aşımı ayarları fazla temkinli olmamalıdır, ancak zaman aşımı süresi çok kısa olursa, protokol iyi liderleri atlayabilir. Örneğin, yüksek yük altında, Jolteon/Hotstuff'taki liderlerin aşırı yüklendiğini ve ilerlemeyi desteklemeden önce zaman aşımının sona erdiğini gözlemledik.

Maalesef, liderlerin protokolü (, Hotstuff ve Jolteon) gibi, her seferinde lider başarısız olduğunda protokolün ilerlemesini sağlamak için zaman aşımına ihtiyaç duyar. Zaman aşımı olmadan, çöküşte olan bir lider bile protokolü sonsuza kadar durdurabilir. Asenkron dönemde arızalı liderler ile yavaş liderler arasında ayrım yapılamadığı için, zaman aşımı, doğrulama düğümlerinin konsensüs aktifliği olmadan tüm liderlerin değişikliklerini gözlemlemesine neden olabilir.

Bullshark'ta, DAG inşası için zaman aşımı kullanılır, böylece senkronizasyon sırasında dürüst liderler DAG'a referans noktaları ekler.