Shoal çerçevesi: Aptos üzerinde Bullshark gecikme süresini azaltma için yenilikçi bir çözüm
Aptos Labs son zamanlarda DAG BFT alanında önemli bir atılım yaptı, iki ana sorunu çözdü, gecikme süresini önemli ölçüde azalttı ve ilk kez belirlenmiş protokollerde zaman aşımına ihtiyaç duymadı. Genel olarak, hatasız durumlarda Bullshark'ın gecikme süresi %40, hatalı durumlarda ise %80 oranında arttı.
Shoal, DAG-Rider, Tusk, Bullshark ( gibi Narwhal tabanlı konsensüs protokolünü güçlendirmek için akış hattı işleme ve liderin itibarını kullanan bir çerçevedir. Akış hattı işleme, her turda referans noktaları 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 gecikmeyi daha da iyileştirir. Ayrıca, liderin itibarı, Shoal'ın tüm senaryolardaki zaman aşımını ortadan kaldırmak için asenkron DAG oluşturma yeteneğinden yararlanmasını sağlar. Bu, Shoal'ın genellikle gerekli olan iyimser yanıt verebilirlik ile birlikte "evrensel yanıt verebilirlik" olarak adlandırdığımız özelliği sunmasını sağlar.
Tekniğimiz oldukça basit, temelde alt protokollerin birden fazla örneğini sıralı olarak çalıştırmaktır. Bu nedenle, Bullshark ile örneklendirildiğinde, bir bayrak yarışı sırasında koşan bir grup "köpek balığı" elde ediyoruz.
![Kapsamlı Shoal Çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Arka Plan ve Motivasyon
Blockchain ağlarının yüksek performansını sağlama çabasında, iletişim karmaşıklığını azaltmak her zaman bir odak noktası olmuştur, ancak bu yaklaşım belirgin bir işlem hacmi artışı sağlamamıştır. Örneğin, erken dönem Diem versiyonları tarafından uygulanan Hotstuff yalnızca 3500 TPS'ye ulaşmış, 100,000+ TPS hedefinin oldukça altında kalmıştır.
Son dönemdeki atılımlar, veri iletiminin liderlerin protokollerine dayandığını ve paralelleşmeden faydalanabileceğini anlamaktan kaynaklanıyor. Narwhal sistemi, veri iletimini ana konsensüs mantığından ayırarak, tüm doğrulayıcıların verileri aynı anda iletebileceği bir mimari öneriyor, konsensüs bileşeni yalnızca az miktarda meta veriyi sıralıyor. Narwhal belgesi, 160.000 TPS'lik bir verimlilik bildirmektedir.
Daha önce Quorum Store'u tanıttık, Narwhal uygulamamız veri yayılımını ve konsensüsü ayırıyor ve bunu mevcut konsensüs protokolü Jolteon'u genişletmek için nasıl kullanacağımızı gösteriyor. 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 gecikmesini %33 oranında azaltabilir. Ancak, lider tabanlı konsensüs protokolleri, Narwhal'ın işlem hacmi potansiyelinden tam olarak yararlanamamaktadır. Veri yayılımını ve konsensüsü ayırmış olmasına rağmen, işlem hacmi arttıkça Hotstuff/Jolteon'un liderleri hala sınırlı kalmaktadır.
Bu nedenle, Bullshark'ı, sıfır iletişim maliyetine sahip bir konsensüs protokolü olarak Narwhal DAG üzerinde dağıtmaya karar verdik. Ne yazık ki, Bullshark'ın yüksek işlem hacmini destekleyen DAG yapısı, Jolteon ile karşılaştırıldığında %50 gecikme süresi maliyeti getirmektedir.
Bu makalede, Shoal'ın Bullshark gecikme süresini nasıl büyük ölçüde azalttığı 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 turundaki n-f köşesini elde etmesi gerekir. Her doğrulayıcı her turda bir köşe yayabilir ve her köşe en az bir önceki turdaki 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ünümlerini gözlemleyebilir.
DAG'ın bir ana özelliği belirsizliğin olmamasıdır: Eğer iki doğrulama düğümü kendi DAG yerel görüntülerinde aynı tepe v'ye sahipse, o zaman v'nin tam olarak aynı nedensel tarihine sahiptirler.
DAG'daki tüm düğümlerin toplam sırası üzerinde 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ı 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:
Belirlenmiş Aşama: Her birkaç turda ), Bullshark'taki iki turda ( gibi, önceden belirlenmiş bir lider olacak ve bu liderin zirvesine aşama denir.
Sıralama Bağlantıları: Doğrulayıcılar, bağımsız ama belirleyici bir şekilde hangi bağlantıların sıralanacağına ve hangi bağlantıların atlanacağına karar verir.
Nedensellik tarihini sıralama: Doğrulayıcılar, sıralı referans noktası listesini tek tek işler; her referans noktası için, nedensellik tarihindeki tüm önceki düzensiz zirveleri bazı deterministik kurallara göre 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ı sabitleme noktası listesinin aynı öneki paylaşmasını sağlamaktır. Shoal'da, yukarıdaki tüm protokoller hakkında şu gözlemleri yapıyoruz:
Tüm doğrulayıcılar ilk sıralı bağlantıya katılıyor.
Bullshark gecikme süresi
Bullshark'ın gecikme süresi, DAG'daki sıralı sabit noktalar arasındaki tur sayısına bağlıdır. Bullshark'ın en kullanışlı kısım senkron versiyonu, asenkron versiyona göre daha iyi bir gecikme süresine sahip olmasına rağmen, 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 oylama olarak yorumlanır. Yaygın durumlarda, referans noktalarını sıralamak için iki tur DAG gerekir, ancak referans noktasının nedensel tarihindeki zirvelerin referans noktalarının sıralanmasını beklemek için daha fazla tura ihtiyacı vardır. Yaygın durumlarda, tek turdaki zirvelerin üç tura, çift turdaki referans noktasına ait olmayan zirvelerin ise dört tura ihtiyacı vardır.
Soru 2: Arıza durumu gecikme süresi. Yukarıdaki gecikme analizi, arıza durumu yokken geçerlidir; diğer taraftan, eğer bir tur lideri yeterince hızlı bir şekilde referans noktasını yayamazsa, referans noktası sıralanamaz ) bu nedenle atlanır (, bu nedenle önceki turlardaki tüm sıralanmamış 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ını kullandığından.
Shoal, akış hattı işleme ile Bullshark) veya başka herhangi bir Narwhal tabanlı BFT protokolünü( güçlendirdi ve her turda bir referans noktası olmasını sağladı, ayrıca DAG'daki tüm referans noktası olmayan düğümlerin gecikme süresini üç tura düşürdü. Shoal, DAG'da sıfır maliyetli lider itibarı mekanizmasını da tanıtarak, seçimin hızlı liderlere yönelmesini sağladı.
Mücadele
DAG protokolü bağlamında, boru hattı işleme ve liderin itibarı zor sorunlar olarak kabul edilmektedir, nedenleri aşağıdaki gibidir:
Önceki üretim hatları, temel Bullshark mantığını değiştirmeye çalıştı, ancak bu temelde imkansız gibi görünüyor.
Liderlerin itibarı, DiemBFT'de tanıtılmış ve Carousel'de resmileştirilmiştir, bu da doğrulayıcıların geçmiş performansına dayanarak gelecekteki liderleri dinamik bir şekilde seçme fikridir )Bullshark içindeki referans noktası (. Liderlik kimliği üzerinde bir anlaşmazlık olması bu protokollerin güvenliğini ihlal etmez, ancak Bullshark'ta, tamamen farklı bir sıralama ile sonuçlanabilir, bu da sorunların özüne işaret eder; dinamik ve belirleyici bir şekilde döngü referansını seçmek konsensüs sağlamak için gereklidir ve doğrulayıcıların gelecekteki referansları seçmek için sıralı geçmiş üzerinde uzlaşmaları gerekmektedir.
Sorunun zorluğuna dair bir kanıt olarak, Bullshark'ın uygulanmasına dikkat çekiyoruz; şu anda üretim ortamında bulunan uygulama bu özellikleri desteklememektedir.
Protokol
Yukarıda belirtilen zorluklara rağmen, çözüm basitlikte gizlidir.
Shoal'da, DAG üzerinde yerel hesaplama yapabilme yeteneğine güveniyoruz ve önceki turların bilgilerini saklama ve yeniden yorumlama yeteneğini gerçekleştirdik. Tüm doğrulayıcıların ilk sıralı referans noktasını kabul etmesiyle, Shoal birden fazla Bullshark örneğini sıralı bir şekilde birleştirerek bunları işleme alır, böylece ) ilk sıralı referans noktası, örneklerin geçiş noktasıdır ve ( referans noktasının nedensel geçmişi liderin itibarını hesaplamak için kullanılır.
![Bin kelimeyle Shoal çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
) akış hattı işleme
V vardır. Shoal, Bullshark'ın örneklerini birer birer çalıştırır, böylece her bir örnek için, bağlantı harita F tarafından önceden belirlenir. Her bir örnek bir bağlantı sıralar, 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 bunu ilk sıralı referans noktası belirlendiği zamana kadar çalıştırdı, örneğin r. aşamada. Tüm doğrulayıcılar bu referans noktasında hemfikirdi. Böylece, tüm doğrulayıcılar r+1. aşamadan itibaren DAG'ı yeniden yorumlamak konusunda kesin bir şekilde hemfikir olabilirler. Shoal, sadece r+1. aşamada yeni bir Bullshark örneği başlattı.
En iyi durumda, bu, Shoal'ın 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. Sonra, üçüncü turda başka bir yeni örnek çapa noktasını sıralar ve bu süreç devam eder.
lider itibarı
Bullshark sıralama sırasında ankraj noktasını atladığınızda, gecikme süresi artar. Bu durumda, boru hattı işleme tekniği etkisizdir, çünkü önceki örnek sıralama ankraj noktasından önce yeni bir örnek başlatılamaz. Shoal, her bir doğrulama düğümünün son etkinlik geçmişine dayanarak her bir doğrulama düğümüne bir puan atamak için bir itibar mekanizması kullanarak, kaybolan ankraj noktalarını işlemek için ilgili liderlerin gelecekte seçilme olasılığını azaltır. Protokole yanıt veren ve katılan doğrulayıcılar yüksek puan alırken, aksi takdirde doğrulama düğümü düşük puan alır, çünkü çökebilir, yavaşlayabilir veya kötü niyetli olabilir.
Felsefesi, her puan güncellemesinde, puanları yüksek olan liderlere yönlendirilerek, turdan lidere önceden tanımlanmış F haritasını kesin bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni haritada uzlaşabilmesi için, puanlar üzerinde uzlaşmaları ve böylece türetilen puanların tarihi üzerinde uzlaşmaları gerekmektedir.
Shoal'da, akış hattı işleme ve liderin itibarı doğal olarak birleşebilir, çünkü her ikisi de ilk sıralı sabit nokta üzerinde 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ından sonra, doğrulayıcıların yalnızca r. turdaki sıralı referans noktalarının sebep-sonuç geçmişine göre yeni haritalama F'yi r+1. turdan itibaren hesaplaması gerektiğidir. Daha sonra, 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 gecikme süresi yok
Zaman aşımı, lider tabanlı belirleyici kısmi senkron BFT uygulamalarında kritik bir rol oynamaktadır. Ancak, getirdikleri karmaşıklık, yönetilmesi ve gözlemlenmesi gereken iç durumların sayısını artırarak hata ayıklama sürecinin karmaşıklığını artırmakta ve daha fazla gözlemlenebilirlik tekniği gerektirmektedir.
Zaman aşımı gecikmeyi de ö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ğımlıdır). Bir sonraki liderliğe geçmeden önce, protokol arızalı lider için tam zaman aşımı gecikme cezası öder. Bu nedenle, zaman aşımı ayarları çok temkinli olmamalıdır, ancak eğer zaman aşımı süresi çok kısa olursa, protokol iyi liderleri atlayabilir. Örneğin, yüksek yük durumlarında, Jolteon/Hotstuff'taki liderlerin aşırı yüklendiğini ve ilerlemeyi sağlamadan önce zaman aşımının sona erdiğini gözlemledik.
Ne yazık ki, lider protokolleri ### gibi Hotstuff ve Jolteon( esasen her liderin arızalandığında zaman aşımını sağlamayı gerektiriyor.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
13 Likes
Reward
13
6
Repost
Share
Comment
0/400
SandwichDetector
· 14h ago
Performans artışı gerçekten boğa, %80 artış harika.
View OriginalReply0
NFTRegretful
· 14h ago
Güzel görünüyor, sadece hız yeterince hızlı değil.
View OriginalReply0
BearMarketSurvivor
· 15h ago
gecikme süresi düşüşü %80 Bu, konuşlandırma sahasının sert gücü, gerçek savaş performansını bekliyorum.
View OriginalReply0
CoinBasedThinking
· 15h ago
Güvenilir proje teknik yükseltme umarım başı büyük ama sonu küçük olmaz.
View OriginalReply0
MeaninglessGwei
· 15h ago
gecikme süresi %80 azaldı mı? Aptos bu sefer boğa gibi!
Shoal çerçevesi Aptos konsensüs verimliliğini artırıyor Bullshark gecikme süresi %80 düşüş sağlıyor
Shoal çerçevesi: Aptos üzerinde Bullshark gecikme süresini azaltma için yenilikçi bir çözüm
Aptos Labs son zamanlarda DAG BFT alanında önemli bir atılım yaptı, iki ana sorunu çözdü, gecikme süresini önemli ölçüde azalttı ve ilk kez belirlenmiş protokollerde zaman aşımına ihtiyaç duymadı. Genel olarak, hatasız durumlarda Bullshark'ın gecikme süresi %40, hatalı durumlarda ise %80 oranında arttı.
Shoal, DAG-Rider, Tusk, Bullshark ( gibi Narwhal tabanlı konsensüs protokolünü güçlendirmek için akış hattı işleme ve liderin itibarını kullanan bir çerçevedir. Akış hattı işleme, her turda referans noktaları 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 gecikmeyi daha da iyileştirir. Ayrıca, liderin itibarı, Shoal'ın tüm senaryolardaki zaman aşımını ortadan kaldırmak için asenkron DAG oluşturma yeteneğinden yararlanmasını sağlar. Bu, Shoal'ın genellikle gerekli olan iyimser yanıt verebilirlik ile birlikte "evrensel yanıt verebilirlik" olarak adlandırdığımız özelliği sunmasını sağlar.
Tekniğimiz oldukça basit, temelde alt protokollerin birden fazla örneğini sıralı olarak çalıştırmaktır. Bu nedenle, Bullshark ile örneklendirildiğinde, bir bayrak yarışı sırasında koşan bir grup "köpek balığı" elde ediyoruz.
![Kapsamlı Shoal Çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Arka Plan ve Motivasyon
Blockchain ağlarının yüksek performansını sağlama çabasında, iletişim karmaşıklığını azaltmak her zaman bir odak noktası olmuştur, ancak bu yaklaşım belirgin bir işlem hacmi artışı sağlamamıştır. Örneğin, erken dönem Diem versiyonları tarafından uygulanan Hotstuff yalnızca 3500 TPS'ye ulaşmış, 100,000+ TPS hedefinin oldukça altında kalmıştır.
Son dönemdeki atılımlar, veri iletiminin liderlerin protokollerine dayandığını ve paralelleşmeden faydalanabileceğini anlamaktan kaynaklanıyor. Narwhal sistemi, veri iletimini ana konsensüs mantığından ayırarak, tüm doğrulayıcıların verileri aynı anda iletebileceği bir mimari öneriyor, konsensüs bileşeni yalnızca az miktarda meta veriyi sıralıyor. Narwhal belgesi, 160.000 TPS'lik bir verimlilik bildirmektedir.
Daha önce Quorum Store'u tanıttık, Narwhal uygulamamız veri yayılımını ve konsensüsü ayırıyor ve bunu mevcut konsensüs protokolü Jolteon'u genişletmek için nasıl kullanacağımızı gösteriyor. 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 gecikmesini %33 oranında azaltabilir. Ancak, lider tabanlı konsensüs protokolleri, Narwhal'ın işlem hacmi potansiyelinden tam olarak yararlanamamaktadır. Veri yayılımını ve konsensüsü ayırmış olmasına rağmen, işlem hacmi arttıkça Hotstuff/Jolteon'un liderleri hala sınırlı kalmaktadır.
Bu nedenle, Bullshark'ı, sıfır iletişim maliyetine sahip bir konsensüs protokolü olarak Narwhal DAG üzerinde dağıtmaya karar verdik. Ne yazık ki, Bullshark'ın yüksek işlem hacmini destekleyen DAG yapısı, Jolteon ile karşılaştırıldığında %50 gecikme süresi maliyeti getirmektedir.
Bu makalede, Shoal'ın Bullshark gecikme süresini nasıl büyük ölçüde azalttığı 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 turundaki n-f köşesini elde etmesi gerekir. Her doğrulayıcı her turda bir köşe yayabilir ve her köşe en az bir önceki turdaki 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ünümlerini gözlemleyebilir.
DAG'ın bir ana özelliği belirsizliğin olmamasıdır: Eğer iki doğrulama düğümü kendi DAG yerel görüntülerinde aynı tepe v'ye sahipse, o zaman v'nin tam olarak aynı nedensel tarihine sahiptirler.
![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Genel Sıra
DAG'daki tüm düğümlerin toplam sırası üzerinde 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ı 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:
Belirlenmiş Aşama: Her birkaç turda ), Bullshark'taki iki turda ( gibi, önceden belirlenmiş bir lider olacak ve bu liderin zirvesine aşama denir.
Sıralama Bağlantıları: Doğrulayıcılar, bağımsız ama belirleyici bir şekilde hangi bağlantıların sıralanacağına ve hangi bağlantıların atlanacağına karar verir.
Nedensellik tarihini sıralama: Doğrulayıcılar, sıralı referans noktası listesini tek tek işler; her referans noktası için, nedensellik tarihindeki tüm önceki düzensiz zirveleri bazı deterministik kurallara göre 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ı sabitleme noktası listesinin aynı öneki paylaşmasını sağlamaktır. Shoal'da, yukarıdaki tüm protokoller hakkında şu gözlemleri yapıyoruz:
Tüm doğrulayıcılar ilk sıralı bağlantıya katılıyor.
Bullshark gecikme süresi
Bullshark'ın gecikme süresi, DAG'daki sıralı sabit noktalar arasındaki tur sayısına bağlıdır. Bullshark'ın en kullanışlı kısım senkron versiyonu, asenkron versiyona göre daha iyi bir gecikme süresine sahip olmasına rağmen, 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 oylama olarak yorumlanır. Yaygın durumlarda, referans noktalarını sıralamak için iki tur DAG gerekir, ancak referans noktasının nedensel tarihindeki zirvelerin referans noktalarının sıralanmasını beklemek için daha fazla tura ihtiyacı vardır. Yaygın durumlarda, tek turdaki zirvelerin üç tura, çift turdaki referans noktasına ait olmayan zirvelerin ise dört tura ihtiyacı vardır.
Soru 2: Arıza durumu gecikme süresi. Yukarıdaki gecikme analizi, arıza durumu yokken geçerlidir; diğer taraftan, eğer bir tur lideri yeterince hızlı bir şekilde referans noktasını yayamazsa, referans noktası sıralanamaz ) bu nedenle atlanır (, bu nedenle önceki turlardaki tüm sıralanmamış 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ını kullandığından.
![Bin kelimeyle açıklama Shoal çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Shoal çerçevesi
Shoal, akış hattı işleme ile Bullshark) veya başka herhangi bir Narwhal tabanlı BFT protokolünü( güçlendirdi ve her turda bir referans noktası olmasını sağladı, ayrıca DAG'daki tüm referans noktası olmayan düğümlerin gecikme süresini üç tura düşürdü. Shoal, DAG'da sıfır maliyetli lider itibarı mekanizmasını da tanıtarak, seçimin hızlı liderlere yönelmesini sağladı.
Mücadele
DAG protokolü bağlamında, boru hattı işleme ve liderin itibarı zor sorunlar olarak kabul edilmektedir, nedenleri aşağıdaki gibidir:
Önceki üretim hatları, temel Bullshark mantığını değiştirmeye çalıştı, ancak bu temelde imkansız gibi görünüyor.
Liderlerin itibarı, DiemBFT'de tanıtılmış ve Carousel'de resmileştirilmiştir, bu da doğrulayıcıların geçmiş performansına dayanarak gelecekteki liderleri dinamik bir şekilde seçme fikridir )Bullshark içindeki referans noktası (. Liderlik kimliği üzerinde bir anlaşmazlık olması bu protokollerin güvenliğini ihlal etmez, ancak Bullshark'ta, tamamen farklı bir sıralama ile sonuçlanabilir, bu da sorunların özüne işaret eder; dinamik ve belirleyici bir şekilde döngü referansını seçmek konsensüs sağlamak için gereklidir ve doğrulayıcıların gelecekteki referansları seçmek için sıralı geçmiş üzerinde uzlaşmaları gerekmektedir.
Sorunun zorluğuna dair bir kanıt olarak, Bullshark'ın uygulanmasına dikkat çekiyoruz; şu anda üretim ortamında bulunan uygulama bu özellikleri desteklememektedir.
Protokol
Yukarıda belirtilen zorluklara rağmen, çözüm basitlikte gizlidir.
Shoal'da, DAG üzerinde yerel hesaplama yapabilme yeteneğine güveniyoruz ve önceki turların bilgilerini saklama ve yeniden yorumlama yeteneğini gerçekleştirdik. Tüm doğrulayıcıların ilk sıralı referans noktasını kabul etmesiyle, Shoal birden fazla Bullshark örneğini sıralı bir şekilde birleştirerek bunları işleme alır, böylece ) ilk sıralı referans noktası, örneklerin geçiş noktasıdır ve ( referans noktasının nedensel geçmişi liderin itibarını hesaplamak için kullanılır.
![Bin kelimeyle Shoal çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
) akış hattı işleme
V vardır. Shoal, Bullshark'ın örneklerini birer birer çalıştırır, böylece her bir örnek için, bağlantı harita F tarafından önceden belirlenir. Her bir örnek bir bağlantı sıralar, 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 bunu ilk sıralı referans noktası belirlendiği zamana kadar çalıştırdı, örneğin r. aşamada. Tüm doğrulayıcılar bu referans noktasında hemfikirdi. Böylece, tüm doğrulayıcılar r+1. aşamadan itibaren DAG'ı yeniden yorumlamak konusunda kesin bir şekilde hemfikir olabilirler. Shoal, sadece r+1. aşamada yeni bir Bullshark örneği başlattı.
En iyi durumda, bu, Shoal'ın 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. Sonra, üçüncü turda başka bir yeni örnek çapa noktasını sıralar ve bu süreç devam eder.
lider itibarı
Bullshark sıralama sırasında ankraj noktasını atladığınızda, gecikme süresi artar. Bu durumda, boru hattı işleme tekniği etkisizdir, çünkü önceki örnek sıralama ankraj noktasından önce yeni bir örnek başlatılamaz. Shoal, her bir doğrulama düğümünün son etkinlik geçmişine dayanarak her bir doğrulama düğümüne bir puan atamak için bir itibar mekanizması kullanarak, kaybolan ankraj noktalarını işlemek için ilgili liderlerin gelecekte seçilme olasılığını azaltır. Protokole yanıt veren ve katılan doğrulayıcılar yüksek puan alırken, aksi takdirde doğrulama düğümü düşük puan alır, çünkü çökebilir, yavaşlayabilir veya kötü niyetli olabilir.
Felsefesi, her puan güncellemesinde, puanları yüksek olan liderlere yönlendirilerek, turdan lidere önceden tanımlanmış F haritasını kesin bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni haritada uzlaşabilmesi için, puanlar üzerinde uzlaşmaları ve böylece türetilen puanların tarihi üzerinde uzlaşmaları gerekmektedir.
Shoal'da, akış hattı işleme ve liderin itibarı doğal olarak birleşebilir, çünkü her ikisi de ilk sıralı sabit nokta üzerinde 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ından sonra, doğrulayıcıların yalnızca r. turdaki sıralı referans noktalarının sebep-sonuç geçmişine göre yeni haritalama F'yi r+1. turdan itibaren hesaplaması gerektiğidir. Daha sonra, 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 gecikme süresi yok
Zaman aşımı, lider tabanlı belirleyici kısmi senkron BFT uygulamalarında kritik bir rol oynamaktadır. Ancak, getirdikleri karmaşıklık, yönetilmesi ve gözlemlenmesi gereken iç durumların sayısını artırarak hata ayıklama sürecinin karmaşıklığını artırmakta ve daha fazla gözlemlenebilirlik tekniği gerektirmektedir.
Zaman aşımı gecikmeyi de ö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ğımlıdır). Bir sonraki liderliğe geçmeden önce, protokol arızalı lider için tam zaman aşımı gecikme cezası öder. Bu nedenle, zaman aşımı ayarları çok temkinli olmamalıdır, ancak eğer zaman aşımı süresi çok kısa olursa, protokol iyi liderleri atlayabilir. Örneğin, yüksek yük durumlarında, Jolteon/Hotstuff'taki liderlerin aşırı yüklendiğini ve ilerlemeyi sağlamadan önce zaman aşımının sona erdiğini gözlemledik.
Ne yazık ki, lider protokolleri ### gibi Hotstuff ve Jolteon( esasen her liderin arızalandığında zaman aşımını sağlamayı gerektiriyor.