Shoal çerçevesi: Aptos üzerindeki Bullshark gecikme süresinde büyük düşüş

Aptos Labs, DAG BFT'deki iki önemli açık problemi yakın zamanda çözdü, gecikme süresini önemli ölçüde düşürdü ve belirleyici gerçek protokolde zaman aşımına olan ihtiyacı ortadan kaldırdı. Genel olarak, hatasız durumlarda Bullshark'ın gecikme süresini %40 oranında iyileştirirken, arızalı durumlarda %80 oranında iyileştirdi.

Shoal, Narwhal tabanlı konsensüs protokollerini (, DAG-Rider, Tusk, Bullshark ) gibi 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ı en hızlı doğrulayıcı düğümleri ile ilişkilendirerek gecikmeyi daha da iyileştirir. Ayrıca, liderin itibarı, Shoal'ın tüm senaryolar için zaman aşımını ortadan kaldırmak üzere asenkron DAG yapısını kullanmasına olanak tanır. Bu, Shoal'ın genellikle gerekli olan iyimser yanıt verme ile birlikte, sözde evrensel yanıt verme sunmasına olanak tanır.

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

Motivasyon

Blok zinciri ağlarının yüksek performansını hedeflerken, insanlar iletişim karmaşıklığını azaltmaya her zaman odaklandılar. Ancak, bu yaklaşım önemli bir düşüşe yol açmadı. Örneğin, erken sürüm Diem'de uygulanan Hotstuff yalnızca 3500 TPS gerçekleştirdi, bu da 100k+ TPS hedefimize kıyasla oldukça düşük.

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 yararlanabilir. 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 az sayıda meta veriyi sıraladığı bir mimari öneriyor. Narwhal belgesi, 160.000 TPS'lik bir iş hacmini rapor ediyor.

Daha önceki makalelerde Quorum Store'u tanıttık. Narwhal uygulamamız, veri yayılımını konsensustan ayırır ve bunu mevcut konsensüs protokolü Jolteon'u genişletmek için nasıl kullanacağımızı gösterir. Jolteon, Tendermint'in lineer 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üşürmektedir. Ancak, lider tabanlı konsensüs protokollerinin Narwhal'ın işlem kapasite potansiyelinden yararlanamadığı açıktır. Veri yayılımı ile konsensüsü ayırmış olsak bile, işlem kapasitesi arttıkça, Hotstuff/Jolteon'un liderleri hâlâ sınırlıdır.

Bu nedenle, Bullshark'ı Narwhal DAG üzerinde dağıtmaya karar verdik, bu, sıfır iletişim maliyetine sahip bir konsensüs protokolüdür. Ne yazık ki, Jolteon ile karşılaştırıldığında, Bullshark'ı destekleyen yüksek verimlilikteki DAG yapısı %50'lik bir gecikme süresi maliyeti getirmektedir.

Bu makalede, Shoal'ın Bullshark gecikme süresini nasıl büyük ölçüde düşürdüğü anlatılmaktadı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ıların öncelikle r-1 turuna ait n-f köşesini elde etmeleri gerekir. Her doğrulayıcı her turda bir köşe yayınlayabilir, her köşe en az bir önceki turun n-f köşesini referans almalıdır. Ağın asenkronluğu 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ğrulama düğümü kendi DAG yerel görünümünde aynı tepe v'ye sahipse, o zaman tamamen aynı v nedensellik geçmişine sahiptirler.

Genel Giriş

DAG'daki tüm düğümlerin toplam sırasını ek iletişim maliyeti olmadan uzlaşmaya varmak mümkündür. Bunun için, DAG-Rider, Tusk ve Bullshark içindeki doğrulayıcılar DAG yapısını bir konsensüs protokolü olarak yorumlar; burada düğümler önerileri, kenarlar ise oylamaları temsil eder.

DAG yapısındaki grup kesişim mantığı farklı olsa da, mevcut tüm Narwhal tabanlı konsensüs protokolleri aşağıdaki yapıya sahiptir:

1. Rezervasyon Ağı: Her birkaç turda ( örneğin, Bullshark'taki iki turda ) önceden belirlenmiş bir lider vardır, liderin zirvesi ise ağ noktası olarak adlandırılır;

2. Sıralama Bağlantısı: Doğrulayıcılar bağımsız ancak belirleyici bir şekilde hangi bağlantıları sipariş edeceklerini ve hangi bağlantıları atlayacaklarını karar verir;

3. Sıralama Nedensel Tarih: Doğrulayıcılar sırayla sıralı referans noktası listesini işler, her bir referans noktası için, bazı belirleyici kurallar aracılığıyla onun nedensel tarihindeki tüm önceki düzensiz köşeleri sıralar.

Güvenliğin sağlanmasının anahtarı, adım (2)'de tüm dürüst doğrulayıcı düğümlerin sıralı bir referans noktası listesi oluşturmasını sağlamaktır, böylece tüm listeler aynı öneki paylaşır. Shoal'da, yukarıdaki tüm protokoller hakkında aşağıdaki gözlemleri yapıyoruz:

Tüm doğrulayıcılar ilk sıralı ulaşım noktasında hemfikir.

Bullshark gecikme süresi

Bullshark'ın gecikme süresi, DAG'deki sıralı sabit noktalar arasındaki döngü sayısına bağlıdır. Bullshark'ın en kullanışlı kısmi senkronizasyon versiyonu, asenkron versiyona göre daha iyi bir gecikmeye sahip olsa da, en iyi değildir.

Soru 1: Ortalama blok gecikmesi. Bullshark'ta, her çift turda bir ankra noktası vardır, her tek turun zirvesi ise oy verme olarak yorumlanır. Yaygın durumlarda, ankra noktalarını sıralamak için iki tur DAG gerekir, ancak ankra'nın nedensel tarihindeki zirvelerin, ankra'nın sıralanmasını beklemek için daha fazla tura ihtiyacı vardır. Yaygın durumlarda, tek turlardaki zirveler üç tura, çift turlardaki ankra olmayan zirveler ise dört tura ihtiyaç duyar.

Soru 2: Arıza durumlarının gecikmesi. Yukarıdaki gecikme analizi arızasız durumlar için geçerlidir, diğer yandan, eğer bir tur lideri yeterince hızlı bir şekilde referans noktasını yayınlayamazsa, referans noktasının sıralanması mümkün olmayacaktır ( 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 kopyalama ağının performansını önemli ölçüde düşürecektir, özellikle de Bullshark lideri beklemek için zaman aşımını kullandığından.

Shoal çerçevesi

Shoal, bu iki gecikme sorununu çözdü, Bullshark( veya herhangi bir Narwhal tabanlı BFT protokolü)'yi artırarak bir akış hattı aracılığıyla her bir turda bir referans noktası olmasını sağlıyor ve DAG'daki tüm referans noktası olmayan köşelerin gecikmesini üç tura indiriyor. Shoal ayrıca DAG'da sıfır maliyetli lider itibar mekanizmasını tanıtarak, hızlı liderlere yönelik bir seçim eğilimi oluşturuyor.

Zorluk

DAG protokolü bağlamında, boru hattı ve liderin itibarı zor sorunlar olarak kabul edilmektedir, sebepleri ise şunlardır:

1. Önceki üretim hattı denemeleri, 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 edilerek Carousel'de resmileştirildi ve bu, doğrulayıcıların geçmiş performansına dayalı olarak gelecekteki liderlerin dinamik seçim fikridir. Liderlik kimliği üzerinde bir ayrımcılık olması, bu protokollerin güvenliğini ihlal etmez, ancak Bullshark'ta, tamamen farklı bir sıralama ile sonuçlanabilir. Bu, sorunun merkezine işaret eder; yani, dinamik ve belirleyici bir şekilde tekerlekli ankrajları seçmek, uzlaşmayı sağlamak için gereklidir ve doğrulayıcıların gelecekteki ankrajları seçmek için sıralı tarihte uzlaşmaları gerekmektedir.

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

Protokol

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

Shoal'da, DAG üzerinde yerel hesaplamalar yapma yeteneğine güveniyoruz ve önceki tur bilgilerini saklama ve yeniden yorumlama yeteneği sağlıyoruz. Tüm doğrulayıcıların ilk sıralı referans noktası üzerinde hemfikir olduğu temel içgörü ile, Shoal birden fazla Bullshark örneğini sıralı bir şekilde birleştirerek bunları işleme sokar, böylece (1) ilk sıralı referans noktası örneklerin geçiş noktasıdır ve (2) referans noktası için nedensel tarih liderin itibarını hesaplamak için kullanılır.

Akış Hattı

V haritası vardır. Shoal, Bullshark'ın örneklerini birer birer çalıştırır, böylece her örnekte, sabit nokta F haritası tarafından önceden belirlenir. Her örnek bir sabit nokta sipariş eder, bu da bir sonraki örneğe geçişi tetikler.

Başlangıçta, Shoal DAG'ın ilk aşamasında Bullshark'ın ilk örneğini başlattı ve ilk sıralı sabit nokta belirlenene kadar bunu çalıştırdı, örneğin r. aşamada. Tüm doğrulayıcılar bu sabit nokta üzerinde hemfikirdi. Bu nedenle, tüm doğrulayıcılar r+1. aşamadan itibaren DAG'ı yeniden yorumlayacaklarına kesin olarak katılabilirler. Shoal, yalnızca r+1. aşamada yeni bir Bullshark örneği başlattı.

En iyi durumda, bu, Shoal'in her turda bir çapa sipariş etmesine olanak tanır. İlk turdaki çapa noktaları, ilk örneğe göre sıralanır. Daha sonra, Shoal ikinci turda yeni bir örnek başlatır, bunun kendisine ait bir çapa noktası vardır, bu çapa, o örneğe göre sıralanır, ardından üçüncü turda başka bir yeni örnek çapa noktası sipariş eder ve süreç devam eder.

Liderlerin İtibarı

Bullshark sıralama süresi boyunca sabit noktaları atladığınızda, gecikme süresi artacaktır. Bu durumda, önceki örneğin sabit noktası sipariş edilmeden yeni bir örneğin başlatılması mümkün olmadığından, boru hattı teknolojisi etkisiz kalır. 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 ilgili liderlerin kaybolan sabit noktaları işleme olasılığının daha düşük olması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ü çökebilir, yavaşlayabilir veya kötüye kullanılabilir.

Felsefesi, her puan güncellemesinde, daha yüksek puan alan liderlere yönelik olarak, tura belirlenmiş haritalama F'yi kesin bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni haritalama üzerinde uzlaşabilmesi için, puan üzerinde uzlaşmaları ve böylece türetilen puanların geçmişinde uzlaşmaları gerekmektedir.

Shoal'da, akış hattı ve liderlik itibarı doğal olarak bir araya gelebilir, çünkü her ikisi de aynı temel teknolojiyi kullanır, yani ilk sıralı ayak noktasında uzlaşma sağlandıktan sonra DAG'ı yeniden yorumlamak.

Aslında, tek fark, r. turda sabit noktaların sıralanmasından sonra, doğrulayıcıların yalnızca r. turda sıralı sabit noktaların nedensel tarihine dayanarak r+1. turdan itibaren yeni bir haritalama F' hesaplamalarıdır. Ardından, doğrulama düğümleri r+1. turdan itibaren güncellenmiş sabit nokta 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 senkronize 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ç 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ı, uygun şekilde yapılandırılmaları çok önemli olduğu için gecikmeyi de önemli ölçüde artırabilir ve genellikle dinamik olarak ayarlanması gerekir, çünkü bu, ortam( ağı) üzerinde yüksek derecede bağımlıdır. Protokol, bir sonraki liderliğe geçmeden önce arızalı lider için tam zaman aşımı gecikme cezası ödeyecektir. Bu nedenle, zaman aşımı ayarları çok temkinli olmamalıdır, ancak zaman aşımı süresi çok kısa olursa, protokol iyi liderleri atlayabilir. Örneğin, yüksek yük durumlarında, Jolteon/