Shoal çerçevesi: Aptos'taki Bullshark Konsensüs gecikme süresi
Aptos Labs son zamanlarda DAG BFT'deki iki önemli açık sorunu çözdü, gecikme süresini büyük ölçüde azalttı ve belirleyici asenkron protokolde zaman aşımına olan ihtiyacı ilk kez ortadan kaldırdı. Genel olarak, arızasız durumda Bullshark'ın gecikme süresini %40, arızalı durumda ise %80 oranında iyileştirdi.
Shoal, DAG-Rider, Tusk, Bullshark ( gibi çerçeveler için Narwhal tabanlı Konsensüs protokolünü güçlendiren bir akış işleme ve lider itibarı mekanizmasıdır. Akış işleme, her turda bir referans noktası ekleyerek DAG sıralama gecikmesini azaltır, lider itibarı mekanizması ise referans noktalarının en hızlı doğrulama düğümleri ile ilişkilendirilmesini sağlayarak gecikme sorununu 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 genellikle gerekli olan iyimser yanıtları içeren evrensel yanıt olarak adlandırılan bir özellik sunmasına olanak tanır.
Shoal'un teknolojisi oldukça basit olup, temel protokollerin birden fazla örneğinin sırayla çalıştırılmasını içerir. Bullshark örneği kullanıldığında, bir dizi "köpek balığı"nın devam eden bir bayrak yarışında yer aldığını görüyoruz.
![Kapsamlı Açıklama 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 peşinde koşarken, insanlar iletişim karmaşıklığını azaltmaya odaklandılar. Ancak, bu yaklaşım belirgin bir işleme kapasitesi artışı sağlamadı. Örneğin, Diem'in erken sürümünde gerçekleştirilen Hotstuff sadece 3500 TPS'ye ulaştı, bu da 100k+ TPS hedefinin çok altında.
Son dönemdeki atılım, veri iletiminin liderlerin protokollerine dayandığını anlayarak ana darboğazın paralelleşmeden yararlanabileceğini tespit etmekten kaynaklanmaktadır. Narwhal sistemi veri iletimini çekirdek 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 sayıda meta veriyi sıraladığı bir mimari önermektedir. Narwhal belgesi 160.000 TPS throughput bildirmektedir.
Daha önceki makalemizde Quorum Store'u tanıttık. Narwhal, veri yayılımını Konsensüs'ten ayırmayı ve bunu mevcut Konsensüs protokolü Jolteon'u genişletmek için nasıl kullanabileceğimizi gerçekleştirmektedir. Jolteon, Tendermint'in lineer 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 azaltabilir. Ancak, lider tabanlı konsensüs protokolleri Narwhal'ın işlem hacmi potansiyelinden tam olarak yararlanamaz. Veri yayılımı ile konsensüsü ayırmış olsalar da, işlem hacminin artmasıyla Hotstuff/Jolteon liderleri hala sınırlı kalmaktadır.
Bu nedenle, Bullshark'ı, iletişim maliyeti olmayan bir konsensüs protokolü olan Narwhal DAG'ın üzerinde dağıtmaya karar verdik. Maalesef, Jolteon'a kıyasla, Bullshark'ın yüksek işlem hacmini destekleyen DAG yapısı %50 gecikme süresi maliyetine yol açtı.
Bu makalede, Shoal'ın Bullshark gecikme süresini nasıl önemli ölçüde azaltacağı anlatılacaktır.
DAG-BFT Arka Planı
Narwhal DAG'daki her bir tepe noktası bir tur ile ilişkilidir. r turuna girmek için, doğrulayıcı öncelikle r-1 turuna ait n-f tepe noktasını elde etmelidir. Her doğrulayıcı her turda bir tepe noktası yayınlayabilir ve her tepe noktası en az önceki turdan n-f tepe noktasını referans almalıdır. Ağın asenkronluğu nedeniyle, farklı doğrulayıcılar her zaman 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ümlerinde aynı v tepe noktasına sahipse, o zaman tam olarak aynı v nedensellik tarihine sahiptirler.
DAG'daki tüm düğümlerin toplam sırasının ek iletişim maliyetleri olmadan uzlaşmasına varılabilir. Bunun için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar, DAG'ın yapısını bir konsensüs protokolü olarak yorumlar; burada düğümler önerileri temsil eder, kenarlar ise oylamaları 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:
Önceden belirlenen referans noktası: Her birkaç turda bir önceden belirlenmiş bir lider olacaktır, liderin zirvesine referans noktası denir.
Sabit Nokta Sıralaması: Doğrulayıcılar, bağımsız ancak belirleyici bir şekilde hangi sabit noktaların sıralanacağına ve hangi sabit noktaların atlanacağına karar verir.
Nedensel tarih sıralaması: Doğrulayıcılar, sıralı referans noktası listesini birer birer işler ve her referans noktasının nedensel tarihindeki tüm ö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 ortak bir ön ek paylaşabilmeleri için düzenli bir referans noktası listesi oluşturmaları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ı referans noktasını kabul etti.
![On bin kelimeyle Shoal çerçevesi: Aptos'taki Bullshark gecikmesini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
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 pratik kısım senkron versiyonu, asenkron versiyona göre daha iyi bir gecikme süresine sahip olsa da, bu hala en iyi değildir.
Soru 1: Ortalama blok gecikmesi. Bullshark'ta, her çift turda bir referans noktası vardır, her tek turun zirvesi ise oy verme olarak yorumlanır. Yaygın durumlarda, referans noktalarını sıralamak için iki tur DAG gereklidir, ancak referans noktasının nedensel tarihindeki zirvelerin sıralanması için daha fazla tura ihtiyaç vardır. Yaygın durumlarda, tek turlardaki zirvelerin sıralanması için üç tura, çift turlardaki referans olmayan zirvelerin sıralanması için ise dört tura ihtiyaç vardır.
Soru 2: Arıza durumu gecikmesi. 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 noktalarını yayınlayamazsa, referans noktaları sıralanamaz ) bu nedenle atlanır (, bu nedenle önceki turlardaki sıralanmamış tüm tepe noktaları 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 azaltır, özellikle Bullshark lideri beklemek için zaman aşımı kullandığı için.
Shoal, bu iki gecikme süresi sorununu çözdü, Bullshark) veya diğer Narwhal tabanlı BFT protokolleri( için işlem sıralaması ile güçlendirerek, her turda bir referans noktası olmasını sağladı ve DAG'daki tüm referans noktası olmayan düğümlerin gecikmesini üç tura düşürdü. Shoal ayrıca DAG'da sıfır maliyetli lider itibar mekanizmasını tanıttı, bu da seçimi hızlı liderlere yönlendirdi.
) meydan okuma
DAG protokolü bağlamında, boru hattı işleme ve liderin itibarı zor sorunlar olarak kabul edilmektedir, nedenleri aşağıdaki gibidir:
Önceki akış hattı işlemleri, temel Bullshark mantığını değiştirmeye çalıştı, ancak bu esasen imkansız gibi görünüyor.
Liderlerin itibarı DiemBFT'ye dahil edilmiştir ve Carousel'de resmileştirilmiştir, bu, doğrulayıcıların geçmiş performansına göre gelecekteki liderlerin dinamik olarak seçilmesi fikridir ###Bullshark'taki çark ( içindir. Liderlik kimliğinde farklılıkların bu protokollerin güvenliğini ihlal etmemesi, ancak Bullshark'ta tamamen farklı sıralamalara yol açabilmesi, sorunun özüne, yani çarkın dinamik ve belirleyici olarak seçilmesinin Konsensüs'ü sağlamak için gerekli olduğunu ve doğrulayıcıların gelecekteki çarkları seçmek için sıralı geçmiş üzerinde uzlaşmaları gerektiğini ortaya koymaktadır.
Soru zorluğunun kanıtı olarak, Bullshark'ın uygulanışına dikkat ediyoruz; şu anda üretim ortamında bulunan uygulama bu özellikleri desteklemiyor.
) protokol
Yukarıda belirtilen zorluklara rağmen, çözüm basitlikte gizlidir. Shoal'da, DAG üzerinde yerel hesaplama yapabilme yeteneğine güveniyoruz ve önceki tur bilgilerini saklama ve yeniden yorumlama yeteneği sağladık. Tüm doğrulayıcıların ilk sıralı referans noktasında mutabık kalmasıyla, Shoal birden fazla Bullshark örneğini sıralı olarak birleştirip, ###1( ilk sıralı referans noktasının örneklerin geçiş noktası olduğu ve )2( referans noktasının liderin itibarını hesaplamak için kullanılan nedensel geçmişi ile bu örnekleri ardışık bir şekilde işleme alıyor.
) Akış hattı işleme
V eşlemesi vardır. Shoal, Bullshark'ın örneklerini tek tek çalıştırır, bu şekilde her bir örnekte, bağlantı F eşlemesi tarafından önceden belirlenir. Her örnek bir bağlantı sıralar, bu da bir sonraki örneğe geçişi tetikler.
İlk olarak, Shoal, DAG'ın ilk turunda Bullshark'ın ilk örneğini başlattı ve bunu ilk sıralı referans noktasının belirlendiği ana kadar çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu referans noktasında hemfikirdir. Bu nedenle, tüm doğrulayıcılar r+1. turdan itibaren DAG'ı yeniden yorumlamak için kesin bir şekilde hemfikir olabilirler. Shoal, r+1. turda 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 noktaları, ilk örneğe göre sıralanır. Ardından, Shoal ikinci turda yeni bir örnek başlatır, bu örneğin kendi çapa noktası vardır, bu çapa bu örneğe göre sıralanır, sonra başka bir yeni örnek üçüncü turda çapa noktasını sıralar ve bu süreç devam eder.
Bullshark sıralama sırasında sabit noktaların atlanması durumunda, gecikme süresi artar. Bu durumda, boru hattı işleme tekniği etkisizdir, çünkü yeni bir örneği başlatmak, önceki örneğin sıralama sabit noktasından önce mümkün değildir. Shoal, her doğrulama düğümünün en son etkinlik geçmişine dayanarak, bir itibar mekanizması kullanarak her doğrulama düğümüne bir puan atayarak, gelecekte ilgili liderlerin kaybolan sabit noktaları işleme olasılığının düşük olmasını sağlar. Protokole yanıt veren ve katılan doğrulayıcılar yüksek puan alacak, aksi takdirde doğrulama düğümleri düşük puan alacaktır çünkü çökebilir, yavaşlayabilir veya kötü niyetli olabilir.
Bu yaklaşım, her puan güncellemesinde, yüksek puan alan liderlere yönelerek, turdan lidere önceden tanımlanmış F haritalarını belirli bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni haritalarda konsensüs sağlaması için, puanlar üzerinde uzlaşmaları ve böylece puanların türetildiği tarih üzerinde de uzlaşmaları gerekmektedir.
Shoal'da, akış hattı işleme ve liderlerin itibarı doğal olarak birleşebilir, çünkü her ikisi de DAG'ı ilk sıralı sabit nokta üzerinde konsensüs sağlandıktan sonra 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ının yalnızca r. turda sıralı referans noktalarının nedensel tarihine dayanarak, r+1. turdan itibaren yeni bir F' haritası hesaplaması gerektiğidir. Ardından, doğrulama düğümleri r+1. turdan itibaren güncellenmiş referans noktası seçim fonksiyonu F' kullanarak Bullshark'ın yeni bir örneğini gerçekleştirir.
![Bin kelime ile Shoal çerçevesinin ayrıntılı açıklaması: Aptos'taki Bullshark gecikmesini nasıl azaltabiliriz?]###https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
) Daha fazla gecikme süresi yok
Zaman aşımı, tüm lider tabanlı belirleyici kısmi senkronize 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özlemleme tekniği gerektirmektedir.
Zaman aşımı, gecikmeyi önemli ölçüde artırabilir, çünkü bunları uygun şekilde yapılandırmak çok önemlidir ve genellikle dinamik olarak ayarlanması gerekir, çünkü bu, ortam ### ağı ( üzerinde yüksek derecede bağımlıdır. Protokol, bir sonraki lidere geçmeden önce arızalı lider için tam zaman aşımı gecikme cezası öder. 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 altında, Jolteon/Hotstuff'taki liderlerin aşırı yüklendiğini ve ilerlemeyi sağlamak için zaman aşımının dolduğunu gözlemledik.
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.
9 Likes
Reward
9
6
Repost
Share
Comment
0/400
SchrodingerProfit
· 14h ago
Bu sefer aptos Aya doğru gidecek.
View OriginalReply0
CodeAuditQueen
· 20h ago
Karmaşık algoritma optimizasyonunun aynı zamanda Bilgi İşlem Gücü yeniden giriş riski de bulunmaktadır. Umarım bu, bir felaketle sonuçlanmaz.
Shoal çerçevesi Aptos konsensüs verimliliğini artırıyor: Bullshark gecikme süresi %40-80 oranında büyük ölçüde düşüyor.
Shoal çerçevesi: Aptos'taki Bullshark Konsensüs gecikme süresi
Aptos Labs son zamanlarda DAG BFT'deki iki önemli açık sorunu çözdü, gecikme süresini büyük ölçüde azalttı ve belirleyici asenkron protokolde zaman aşımına olan ihtiyacı ilk kez ortadan kaldırdı. Genel olarak, arızasız durumda Bullshark'ın gecikme süresini %40, arızalı durumda ise %80 oranında iyileştirdi.
Shoal, DAG-Rider, Tusk, Bullshark ( gibi çerçeveler için Narwhal tabanlı Konsensüs protokolünü güçlendiren bir akış işleme ve lider itibarı mekanizmasıdır. Akış işleme, her turda bir referans noktası ekleyerek DAG sıralama gecikmesini azaltır, lider itibarı mekanizması ise referans noktalarının en hızlı doğrulama düğümleri ile ilişkilendirilmesini sağlayarak gecikme sorununu 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 genellikle gerekli olan iyimser yanıtları içeren evrensel yanıt olarak adlandırılan bir özellik sunmasına olanak tanır.
Shoal'un teknolojisi oldukça basit olup, temel protokollerin birden fazla örneğinin sırayla çalıştırılmasını içerir. Bullshark örneği kullanıldığında, bir dizi "köpek balığı"nın devam eden bir bayrak yarışında yer aldığını görüyoruz.
![Kapsamlı Açıklama 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 peşinde koşarken, insanlar iletişim karmaşıklığını azaltmaya odaklandılar. Ancak, bu yaklaşım belirgin bir işleme kapasitesi artışı sağlamadı. Örneğin, Diem'in erken sürümünde gerçekleştirilen Hotstuff sadece 3500 TPS'ye ulaştı, bu da 100k+ TPS hedefinin çok altında.
Son dönemdeki atılım, veri iletiminin liderlerin protokollerine dayandığını anlayarak ana darboğazın paralelleşmeden yararlanabileceğini tespit etmekten kaynaklanmaktadır. Narwhal sistemi veri iletimini çekirdek 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 sayıda meta veriyi sıraladığı bir mimari önermektedir. Narwhal belgesi 160.000 TPS throughput bildirmektedir.
Daha önceki makalemizde Quorum Store'u tanıttık. Narwhal, veri yayılımını Konsensüs'ten ayırmayı ve bunu mevcut Konsensüs protokolü Jolteon'u genişletmek için nasıl kullanabileceğimizi gerçekleştirmektedir. Jolteon, Tendermint'in lineer 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 azaltabilir. Ancak, lider tabanlı konsensüs protokolleri Narwhal'ın işlem hacmi potansiyelinden tam olarak yararlanamaz. Veri yayılımı ile konsensüsü ayırmış olsalar da, işlem hacminin artmasıyla Hotstuff/Jolteon liderleri hala sınırlı kalmaktadır.
Bu nedenle, Bullshark'ı, iletişim maliyeti olmayan bir konsensüs protokolü olan Narwhal DAG'ın üzerinde dağıtmaya karar verdik. Maalesef, Jolteon'a kıyasla, Bullshark'ın yüksek işlem hacmini destekleyen DAG yapısı %50 gecikme süresi maliyetine yol açtı.
Bu makalede, Shoal'ın Bullshark gecikme süresini nasıl önemli ölçüde azaltacağı anlatılacaktır.
DAG-BFT Arka Planı
Narwhal DAG'daki her bir tepe noktası bir tur ile ilişkilidir. r turuna girmek için, doğrulayıcı öncelikle r-1 turuna ait n-f tepe noktasını elde etmelidir. Her doğrulayıcı her turda bir tepe noktası yayınlayabilir ve her tepe noktası en az önceki turdan n-f tepe noktasını referans almalıdır. Ağın asenkronluğu nedeniyle, farklı doğrulayıcılar her zaman 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ümlerinde aynı v tepe noktasına sahipse, o zaman tam olarak aynı v nedensellik tarihine sahiptirler.
![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Genel Sıralama
DAG'daki tüm düğümlerin toplam sırasının ek iletişim maliyetleri olmadan uzlaşmasına varılabilir. Bunun için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar, DAG'ın yapısını bir konsensüs protokolü olarak yorumlar; burada düğümler önerileri temsil eder, kenarlar ise oylamaları 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:
Önceden belirlenen referans noktası: Her birkaç turda bir önceden belirlenmiş bir lider olacaktır, liderin zirvesine referans noktası denir.
Sabit Nokta Sıralaması: Doğrulayıcılar, bağımsız ancak belirleyici bir şekilde hangi sabit noktaların sıralanacağına ve hangi sabit noktaların atlanacağına karar verir.
Nedensel tarih sıralaması: Doğrulayıcılar, sıralı referans noktası listesini birer birer işler ve her referans noktasının nedensel tarihindeki tüm ö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 ortak bir ön ek paylaşabilmeleri için düzenli bir referans noktası listesi oluşturmaları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ı referans noktasını kabul etti.
![On bin kelimeyle Shoal çerçevesi: Aptos'taki Bullshark gecikmesini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
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 pratik kısım senkron versiyonu, asenkron versiyona göre daha iyi bir gecikme süresine sahip olsa da, bu hala en iyi değildir.
Soru 1: Ortalama blok gecikmesi. Bullshark'ta, her çift turda bir referans noktası vardır, her tek turun zirvesi ise oy verme olarak yorumlanır. Yaygın durumlarda, referans noktalarını sıralamak için iki tur DAG gereklidir, ancak referans noktasının nedensel tarihindeki zirvelerin sıralanması için daha fazla tura ihtiyaç vardır. Yaygın durumlarda, tek turlardaki zirvelerin sıralanması için üç tura, çift turlardaki referans olmayan zirvelerin sıralanması için ise dört tura ihtiyaç vardır.
Soru 2: Arıza durumu gecikmesi. 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 noktalarını yayınlayamazsa, referans noktaları sıralanamaz ) bu nedenle atlanır (, bu nedenle önceki turlardaki sıralanmamış tüm tepe noktaları 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 azaltır, özellikle Bullshark lideri beklemek için zaman aşımı kullandığı için.
![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Shoal çerçevesi
Shoal, bu iki gecikme süresi sorununu çözdü, Bullshark) veya diğer Narwhal tabanlı BFT protokolleri( için işlem sıralaması ile güçlendirerek, her turda bir referans noktası olmasını sağladı ve DAG'daki tüm referans noktası olmayan düğümlerin gecikmesini üç tura düşürdü. Shoal ayrıca DAG'da sıfır maliyetli lider itibar mekanizmasını tanıttı, bu da seçimi hızlı liderlere yönlendirdi.
) meydan okuma
DAG protokolü bağlamında, boru hattı işleme ve liderin itibarı zor sorunlar olarak kabul edilmektedir, nedenleri aşağıdaki gibidir:
Önceki akış hattı işlemleri, temel Bullshark mantığını değiştirmeye çalıştı, ancak bu esasen imkansız gibi görünüyor.
Liderlerin itibarı DiemBFT'ye dahil edilmiştir ve Carousel'de resmileştirilmiştir, bu, doğrulayıcıların geçmiş performansına göre gelecekteki liderlerin dinamik olarak seçilmesi fikridir ###Bullshark'taki çark ( içindir. Liderlik kimliğinde farklılıkların bu protokollerin güvenliğini ihlal etmemesi, ancak Bullshark'ta tamamen farklı sıralamalara yol açabilmesi, sorunun özüne, yani çarkın dinamik ve belirleyici olarak seçilmesinin Konsensüs'ü sağlamak için gerekli olduğunu ve doğrulayıcıların gelecekteki çarkları seçmek için sıralı geçmiş üzerinde uzlaşmaları gerektiğini ortaya koymaktadır.
Soru zorluğunun kanıtı olarak, Bullshark'ın uygulanışına dikkat ediyoruz; şu anda üretim ortamında bulunan uygulama bu özellikleri desteklemiyor.
) protokol
Yukarıda belirtilen zorluklara rağmen, çözüm basitlikte gizlidir. Shoal'da, DAG üzerinde yerel hesaplama yapabilme yeteneğine güveniyoruz ve önceki tur bilgilerini saklama ve yeniden yorumlama yeteneği sağladık. Tüm doğrulayıcıların ilk sıralı referans noktasında mutabık kalmasıyla, Shoal birden fazla Bullshark örneğini sıralı olarak birleştirip, ###1( ilk sıralı referans noktasının örneklerin geçiş noktası olduğu ve )2( referans noktasının liderin itibarını hesaplamak için kullanılan nedensel geçmişi ile bu örnekleri ardışık bir şekilde işleme alıyor.
) Akış hattı işleme
V eşlemesi vardır. Shoal, Bullshark'ın örneklerini tek tek çalıştırır, bu şekilde her bir örnekte, bağlantı F eşlemesi tarafından önceden belirlenir. Her örnek bir bağlantı sıralar, bu da bir sonraki örneğe geçişi tetikler.
İlk olarak, Shoal, DAG'ın ilk turunda Bullshark'ın ilk örneğini başlattı ve bunu ilk sıralı referans noktasının belirlendiği ana kadar çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu referans noktasında hemfikirdir. Bu nedenle, tüm doğrulayıcılar r+1. turdan itibaren DAG'ı yeniden yorumlamak için kesin bir şekilde hemfikir olabilirler. Shoal, r+1. turda 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 noktaları, ilk örneğe göre sıralanır. Ardından, Shoal ikinci turda yeni bir örnek başlatır, bu örneğin kendi çapa noktası vardır, bu çapa bu örneğe göre sıralanır, sonra başka bir yeni örnek üçüncü turda çapa noktasını sıralar ve bu süreç devam eder.
![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？]###https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
) Liderlerin itibarı
Bullshark sıralama sırasında sabit noktaların atlanması durumunda, gecikme süresi artar. Bu durumda, boru hattı işleme tekniği etkisizdir, çünkü yeni bir örneği başlatmak, önceki örneğin sıralama sabit noktasından önce mümkün değildir. Shoal, her doğrulama düğümünün en son etkinlik geçmişine dayanarak, bir itibar mekanizması kullanarak her doğrulama düğümüne bir puan atayarak, gelecekte ilgili liderlerin kaybolan sabit noktaları işleme olasılığının düşük olmasını sağlar. Protokole yanıt veren ve katılan doğrulayıcılar yüksek puan alacak, aksi takdirde doğrulama düğümleri düşük puan alacaktır çünkü çökebilir, yavaşlayabilir veya kötü niyetli olabilir.
Bu yaklaşım, her puan güncellemesinde, yüksek puan alan liderlere yönelerek, turdan lidere önceden tanımlanmış F haritalarını belirli bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni haritalarda konsensüs sağlaması için, puanlar üzerinde uzlaşmaları ve böylece puanların türetildiği tarih üzerinde de uzlaşmaları gerekmektedir.
Shoal'da, akış hattı işleme ve liderlerin itibarı doğal olarak birleşebilir, çünkü her ikisi de DAG'ı ilk sıralı sabit nokta üzerinde konsensüs sağlandıktan sonra 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ının yalnızca r. turda sıralı referans noktalarının nedensel tarihine dayanarak, r+1. turdan itibaren yeni bir F' haritası hesaplaması gerektiğidir. Ardından, doğrulama düğümleri r+1. turdan itibaren güncellenmiş referans noktası seçim fonksiyonu F' kullanarak Bullshark'ın yeni bir örneğini gerçekleştirir.
![Bin kelime ile Shoal çerçevesinin ayrıntılı açıklaması: Aptos'taki Bullshark gecikmesini nasıl azaltabiliriz?]###https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
) Daha fazla gecikme süresi yok
Zaman aşımı, tüm lider tabanlı belirleyici kısmi senkronize 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özlemleme tekniği gerektirmektedir.
Zaman aşımı, gecikmeyi önemli ölçüde artırabilir, çünkü bunları uygun şekilde yapılandırmak çok önemlidir ve genellikle dinamik olarak ayarlanması gerekir, çünkü bu, ortam ### ağı ( üzerinde yüksek derecede bağımlıdır. Protokol, bir sonraki lidere geçmeden önce arızalı lider için tam zaman aşımı gecikme cezası öder. 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 altında, Jolteon/Hotstuff'taki liderlerin aşırı yüklendiğini ve ilerlemeyi sağlamak için zaman aşımının dolduğunu gözlemledik.
Maalesef, lider tabanlı protokol ) gibi Hotstuff