DAG Konsensüsünü Optimize Etme: Shoal Çerçevesi Aptos Üzerindeki Bullshark Gecikme Süresini Nasıl Düşürür

Aptos Labs son zamanlarda DAG BFT'deki iki önemli açık sorunu çözdü, gecikmeyi önemli ölçüde düşürdü ve ilk kez belirleyici asenkron protokollerde zaman aşımına ihtiyaç duyulmasını ortadan kaldırdı. Genel olarak, Shoal çerçevesi arızasız durumda Bullshark'ın gecikmesini %40, arızalı durumda ise %80 oranında iyileştirdi.

Shoal, DAG-Rider, Tusk, Bullshark ( çerçevesindeki Narwhal tabanlı konsensüs protokolünü, akış hattı ve lider itibarını kullanarak güçlendiren bir sistemdir. Akış hattı, her turda bir referans noktası getirerek DAG sıralama gecikmesini azaltır, lider itibarı ise referans noktalarının en hızlı doğrulama düğümleri ile ilişkilendirilmesini sağlayarak gecikmeyi daha da iyileş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 evrensel bir yanıt sağlama yeteneğini geliştirir ve genellikle gereken iyimser yanıtı içerir.

Shoal'un teknolojisi görece basittir ve temel protokollerin birden fazla örneğini sırayla çalıştırmayı içerir. Bullshark ile örnekleme yapıldığında, bir grup "köpek balığı"nın bayrak yarışı yaptığı bir durum elde ederiz.

![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(

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 artışa yol açmadı. Örneğin, Diem'in erken versiyonlarında uygulanan Hotstuff yalnızca 3500 TPS sağladı, bu da 100k+ TPS hedefinin çok altında.

Son dönemdeki atılım, veri iletiminin liderlik protokolüne dayalı ana darboğaz olduğunu anlamaktan kaynaklanıyor ve paralelleşmeden faydalanabilir. Narwhal sistemi veri iletimini merkezi 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 miktarda meta veriyi sıraladığı bir mimari öneriyor. Narwhal makalesi, 160.000 TPS'lik bir verimlilik bildirmektedir.

Daha önceki makalemizde, Quorum Store'u tanıttık. Narwhal uygulamamız, veri yayılımını konsensüsten ayırır ve bunu mevcut konsensüs protokolü Jolteon'u ölçeklendirmek için nasıl kullanabileceğimizi açıklar. 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'un gecikmesini %33 oranında düşürür. Ancak, lider tabanlı konsensüs protokolleri, Narwhal'ın throughput potansiyelinden tam olarak yararlanamamaktadır. Veri yayılımını konsensüsten ayırmamıza rağmen, throughput arttıkça Hotstuff/Jolteon'un liderleri hala sınırlıdır.

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

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 önce r-1 turuna ait n-f köşeyi elde etmesi gerekir. Her doğrulayıcı her turda bir köşe yayınlayabilir, her köşe en az önceki turdaki n-f köşeyi referans almalıdır. Ağın asenkron olması nedeniyle, farklı doğrulayıcılar herhangi bir zaman noktasında DAG'ın farklı yerel görünümlerini gözlemleyebilir.

DAG'ın bir ana özelliği belirsizlik olmamasıdır: Eğer iki doğrulayıcı düğüm DAG'ın yerel görünümünde aynı tepe noktası v'ye sahipse, o zaman tamamen aynı v nedensel geçmişine sahiptirler.

![Binlerce kelime ile Shoal çerçevesinin detaylı açıklaması: Aptos'taki Bullshark gecikmesini nasıl azaltabiliriz?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(

Tam Sıra

DAG'daki tüm dorukların toplam sıralamasında, ek iletişim maliyeti olmadan uzlaşma sağlanabilir. Bunun için, DAG-Rider, Tusk ve Bullshark içindeki doğrulayıcılar, DAG yapısını, dorukların teklifleri, kenarların ise oyları temsil ettiği bir konsensüs protokolü olarak yorumlar.

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. Tahsis Edilen Aşama: Her birkaç turda önceden belirlenmiş bir lider vardır, bu liderin tepe noktası aşama olarak adlandırılır.

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

3. Nedensel tarih sıralaması: Doğrulayıcılar sırasıyla sıralı sabit nokta listesini işler, her sabit noktanın nedensel tarihindeki tüm önceki düzensiz noktaları sıralar.

Güvenliğin sağlanmasının anahtarı, adım )2('de, tüm dürüst doğrulama düğümlerinin oluşturduğu sıralı sabit nokta listesinin aynı ön eki paylaşmasını sağlamaktır. Shoal'da, bu protokollerin tümü için aşağıdaki gözlemleri yapıyoruz:

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

Bullshark gecikme süresi

Bullshark'ın gecikme süresi, DAG'daki sıralı ankraj noktaları arasındaki döngü sayısına bağlıdır. Bullshark'ın en kullanışlı kısmı, senkronize sürümünün asenkron sürümden daha iyi bir gecikmeye sahip olmasına rağmen, bu en iyi değildir.

Soru 1: Ortalama blok gecikme süresi. Bullshark'ta, her çift turda bir referans noktası vardır, her tek turda ise zirve oy olarak yorumlanır. Yaygın durumlarda, referans noktalarını sıralamak için iki tur DAG gereklidir, ancak referans noktası nedensel tarihindeki zirvelerin sıralanması için daha fazla tur beklenmesi gerekir. Genellikle, tek turdaki zirvelerin üç tura, çift turdaki referans noktasına ait olmayan zirvelerin ise dört tura ihtiyacı vardır.

Soru 2: Arıza durumu gecikmesi. Eğer bir turdaki lider, yeterince hızlı bir şekilde referans noktalarını yayınlayamazsa, referans noktaları sıralanamaz ) bu nedenle atlanır (, önceki turlardaki tüm sıralanmamış noktalar, bir sonraki referans noktasının sıralanmasını beklemek zorundadır. Bu, coğrafi çoğaltma ağlarının performansını önemli ölçüde düşürecektir, özellikle Bullshark lideri beklemek için zaman aşımı kullanıyorsa.

![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(

Shoal çerçevesi

Shoal, Bullshark) veya herhangi bir Narwhal tabanlı BFT protokolünü ( güçlendirmek için bir akış hattı aracılığıyla, her turda bir referans noktası olmasını sağlamakta ve DAG'daki tüm referans noktası olmayan düğümlerin gecikme süresini üç tura indirmektedir. Shoal ayrıca DAG'da sıfır maliyetli lider itibar mekanizmasını tanıtarak, seçimlerin hızlı liderlere yönelmesini sağlamaktadır.

Zorluk

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

1. Önceki hat akışı, 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 edilmiştir ve Carousel'de resmileştirilmiştir; bu, doğrulayıcıların geçmiş performanslarına dayanarak gelecekteki liderleri dinamik olarak seçme fikridir. )Bullshark içindeki ('ün çivisi. Liderlik kimliği ayrılıkları bu protokollerin güvenliğini ihlal etmemekle birlikte, Bullshark'ta tamamen farklı sıralamalara yol açabilir; bu, sorunun özünü ortaya koyar: Dinamik ve belirleyici bir şekilde döngü çivilerini seçmek konsensüsü sağlamak için gereklidir ve doğrulayıcıların gelecekteki çivileri seçmek için sıralı tarihi üzerinde uzlaşmaları gerekir.

Bir sorun zorluğu kanıtı olarak, Bullshark'ın uygulamasının, mevcut üretim ortamındaki uygulama dahil, bu özellikleri desteklemediğini gözlemliyoruz.

Protokol

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

Shoal'da, DAG üzerinde yerel hesaplama yapabilme yeteneğine güveniyoruz ve önceki tur bilgilerini saklayıp yeniden yorumlama yeteneğini gerçekleştiriyoruz. Tüm doğrulayıcıların ilk sıralı referans noktasının temel anlayışında hemfikir olmasıyla, Shoal, birden fazla Bullshark örneğini sıralı olarak birleştirerek boru hattı işlemi gerçekleştiriyor; bu nedenle )1( ilk sıralı referans noktası örneklerin geçiş noktasıdır ve )2( referans noktasının nedensel tarihi liderlerin itibarını hesaplamak için kullanılmaktadır.

![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(

Akış Şeması

V haritası vardır. Shoal, her bir örnek için önceden belirlenen bir ankra ile Bullshark örneklerini birer birer çalıştırır. Her örnek bir ankra sıralar, bir sonraki örneğe geçişi tetikler.

İlk olarak, Shoal DAG'ın ilk turunda Bullshark'ın ilk örneğini başlattı ve ilk sıralı çiviyi, örneğin r. turda belirleyene kadar çalıştırdı. Tüm doğrulayıcılar bu çiviyi kabul etti. Bu nedenle, tüm doğrulayıcılar r+1. turdan itibaren DAG'ın yeniden yorumlanmasını kesin bir şekilde kabul edebilirler. Shoal, yalnızca r+1. turda yeni bir Bullshark örneğini başlattı.

En iyi durumda, bu Shoal'ın her turda bir çiviyi sıralamasına olanak tanır. İlk turdaki çivi, ilk örnek tarafından sıralanır. Ardından, Shoal ikinci turda yeni bir örnek başlatır, bunun kendine ait bir çivisi vardır, bu çivi o örnek tarafından sıralanır, ardından üçüncü turda başka bir yeni örnek çivi sıralar, sonrasında süreç devam eder.

![Kapsamlı Shoal Çerçevesi: Aptos'taki Bullshark gecikmesini nasıl azaltırız?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(

Liderlerin İtibarı

Bullshark sıralama sürecinde bir ankraj noktasını atladığınızda, gecikme süresi artar. Bu durumda, boru hatları teknolojisi etkisizdir, çünkü yeni bir örneği başlatmak, önceki örnek sıralama ankraj noktasından önce mümkün değildir. Shoal, her doğrulama düğümünün en son etkinlik geçmişine dayalı olarak her doğrulama düğümüne puan atayarak, gelecekte ilgili liderlerin kaybolan ankraj noktalarını işlemek için seçilme 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üğümü çökebilir, yavaşlayabilir veya kötü niyetli olabilir, bu nedenle düşük puan verilecektir.

Felsefesi, her puan güncellemesinde, yüksek puanlı liderlere yönelerek, turdan liderlere önceden tanımlanmış F haritalamasını belirleyerek kesin olarak yeniden hesaplamaktır. Doğrulayıcıların yeni haritalama üzerinde uzlaşabilmeleri için, puan üzerinde uzlaşmaları ve böylece puanları türetmek için geçmişte 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 Konsensüs sağlandıktan sonra DAG'ı yeniden yorumlamak için aynı temel teknolojiyi kullanır.

Aslında, tek fark, r. turda bağlantı noktalarının sıralanmasından sonra, doğrulayıcıların yalnızca r. turdaki sıralı bağlantı noktalarının nedensel geçmişine dayanarak r+1. turdan itibaren yeni F' eşlemesini hesaplamasıdır. Ardından, doğrulama düğümleri r+1. turdan itibaren güncellenmiş bağlantı noktası seçim fonksiyonu F' ile Bullshark'ın yeni örneğini uygular.

![Bin kelimeyle Shoal çerçevesi: Aptos üzerindeki Bullshark gecikmesini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(

Daha fazla zaman aşımı yok

Zaman aşımı, lider tabanlı belirleyici kısmi senkron BFT uygulamalarının tamamı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.

Aşırı süre de gecikmeyi önemli ölçüde artırır, çünkü bunların uygun bir şekilde yapılandırılması çok önemlidir ve genellikle dinamik ayarlamalar gerektirir, çünkü bu ortam) ağ( üzerinde yüksek derecede bağımlıdır. Protokol, bir sonraki liderliğe geçmeden önce, arızalı liderler için tam süre aşımı gecikme cezası ödeyecektir. Bu nedenle, süre aşımı ayarları çok temkinli olmamalıdır, ancak süre 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üklenmiş olduğunu ve ilerlemeyi sağlamadan önce süre aşımının dolduğunu gözlemledik.

Ne yazık ki, lider tabanlı protokoller ) gibi Hotstuff ve Jolteon( esasen zaman aşımına ihtiyaç duyar, böylece her seferinde liderin başarısız olması durumunda protokol ilerleyebilir. Zaman aşımı olmadan, çöküş yaşayan bir lider bile protokolü sonsuza kadar durdurabilir. Asenkron dönemde arızalı lider ile yavaş lider arasında ayrım yapılamadığı için, zaman aşımı doğrulama düğümlerinin konsensüs aktifliği olmadan tüm liderleri değiştirmesine neden olabilir.

Bullshark'ta, DAG yapımı için gecikme süresi kullanılır, böylece senkronizasyon sırasında dürüst liderler referans noktalarını ekleyebilir.