Shoal Çerçevesi: Aptos'taki Bullshark Gecikmesini Nasıl Azaltabiliriz?
Genel Bakış
Aptos labları, DAG BFT'deki iki önemli açık sorunu çözerek gecikmeyi önemli ölçüde azalttı ve ilk kez belirli gerçek protokollerde duraklama gereksinimini ortadan kaldırdı. Genel olarak, sorunsuz durumlarda Bullshark'ın gecikmesini %40, arızalı durumlarda ise %80 oranında iyileştirdi.
Shoal, Narwhal tabanlı konsensüs protokollerini ( (DAG-Rider, Tusk, Bullshark ) gibi) geliştirmek için bir iş akışı ve lider itibarı mekanizması aracılığıyla bir çerçevedir. İş akışı, her turda bir referans noktası ekleyerek DAG sıralama gecikmesini azaltır, lider itibarı ise referans noktalarının en hızlı doğrulama düğümleriyle ilişkili olmasını sağlayarak gecikme sorununu daha da geliştirir. Ayrıca, lider itibarı Shoal'un tüm senaryolardaki zaman aşımını ortadan kaldırmak için asenkron DAG yapısını kullanmasına olanak tanır. Bu, Shoal'un genellikle gerekli olan iyimser yanıtı içeren, evrensel yanıt olarak adlandırdığımız bir özelliği sunmasını sağlar.
Bu teknoloji oldukça basit olup, temel protokollerin birden fazla örneğini sırayla çalıştırmayı içerir. Bu nedenle, Bullshark ile örnekleme yapıldığında, bir grup "köpekbalığı"nın bayrak yarışı yaptığı bir durum elde ederiz.
Motivasyon
Blok zinciri ağlarının yüksek performansını hedeflerken, insanlar iletişim karmaşıklığını azaltmaya dikkat ettiler. Ancak, bu yaklaşım belirgin bir işlem hacmi artışı sağlamadı. Örneğin, Diem'in erken sürümünde uygulanan Hotstuff yalnızca 3500 TPS'e ulaşabildi, bu da 100k+ TPS hedefine göre oldukça düşük.
Son dönemdeki atılım, veri yayılımının liderlik protokollerinin temel darboğazı olduğu ve burada paralelleşmeden faydalanılabileceğini anlamaktan kaynaklanıyor. 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 verimliliği rapor ediyor.
Daha önce tanıtılan Quorum Store, verilerin yayılmasını ve uzlaşmayı ayıran Narwhal'ın bir uygulamasıdır ve mevcut uzlaşma protokolü Jolteon'un ölçeklenmesi için kullanılır. Jolteon, Tendermint'in doğrusal hızlı yolları ve PBFT tarzı görünüm değişikliklerini birleştiren, lider temelli bir protokoldür ve Hotstuff'un gecikmesini %33 oranında azaltabilir. Ancak, lider temelli uzlaşma protokolleri Narwhal'ın verimlilik potansiyelini tam olarak kullanamaz. Veri yayılımı ve uzlaşma ayrılsa da, verimlilik arttıkça Hotstuff/Jolteon'un lideri hâlâ sınırlıdır.
Bu nedenle, Bullshark'ı, sıfır iletişim maliyeti olan bir konsensüs protokolü olan Narwhal DAG'ın üzerine konuşlandırmaya karar verildi. Ne yazık ki, Jolteon ile karşılaştırıldığında, Bullshark'ı destekleyen yüksek verimlilikteki DAG yapısı %50 gecikme maliyeti getirdi.
Bu makale, Shoal'ın Bullshark gecikmesini nasıl büyük ölçüde azalttığını anlatmaktadır.
DAG-BFT Arka Planı
Narwhal DAG'daki her bir doruk, bir tur ile ilişkilidir. r. tura girmek için, doğrulayıcıların öncelikle r-1. turdaki n-f doruğunu elde etmeleri gerekir. Her doğrulayıcı her turda bir doruk yayınlayabilir, her doruk en az bir önceki turdaki n-f doruğunu referans almalıdır. Ağın asenkronluğundan dolayı, farklı doğrulayıcılar herhangi bir zamanda DAG'ın farklı yerel görünümlerini gözlemleyebilir.
DAG'ın bir ana özelliği belirsiz olmamasıdır: Eğer iki doğrulayıcı düğüm, DAG'larındaki yerel görüntülerinde aynı v tepe noktasına sahipse, o zaman v'nin neden-sonuç geçmişleri tamamen aynıdır.
Toplam Sıra
Tüm düğümlerin toplam sırasının DAG'de ek iletişim maliyetleri olmadan uzlaşmasını sağlamak mümkündür. Bunu yapmak için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar, DAG'ın yapısını, düğümlerin önerileri temsil ettiği ve kenarların oyları temsil ettiği bir konsensüs protokolü olarak yorumlar.
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:
Önceden belirlenmiş lider: Her birkaç turda önceden belirlenmiş bir lider olacaktır, liderin zirvesine ise "ankraj noktası" denir;
Sıralama Bağlantı Noktaları: Doğrulayıcılar bağımsız ancak belirleyici bir şekilde hangi bağlantı noktalarının sıralanacağına ve hangilerinin atlanacağına karar verir.
Nedensellik Tarihini Sıralama: Doğrulayıcılar, sıralı referans noktası listesini tek tek işler ve her bir referans noktasının neden-sonuç 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 oluşturduğu sıralı referans noktası listesinin aynı öneki paylaşmasını sağlamaktır. Shoal'da, yukarıda belirtilen tüm protokoller hakkında aşağıdaki gözlemleri yaptık:
Tüm doğrulayıcılar ilk sıralı ankraj noktasında uzlaşır.
Bullshark Gecikmesi
Bullshark’ın gecikmesi, DAG içindeki sıralı ankraj noktaları arasındaki turların sayısına bağlıdır. Bullshark’ın en pratik kısım senkron sürümleri, asenkron sürümlerden daha iyi bir gecikmeye sahip olmasına rağmen, yine de en iyi durumdan uzaktır.
Soru 1: Ortalama blok gecikmesi. Bullshark'ta, her çift turda bir referans noktası vardır, her tek turdaki zirve ise oy verme olarak yorumlanır. Genel durumda, referans noktalarını sıralamak için iki DAG turuna ihtiyaç vardır, ancak referans noktasının nedensel tarihindeki zirvelerin referans noktalarının sıralanmasını beklemek için daha fazla tura ihtiyaç vardır. Genel durumda, tek turlardaki zirveler üç tura, çift turlardaki referans olmayan zirveler ise dört tura ihtiyaç duyar.
Soru 2: Arıza vakası 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 noktasını yayamazsa, referans noktası sıralanamaz ( bu nedenle atlanır ), bu nedenle önceki turlardaki sıralanmamış tüm zirveler bir sonraki referans noktasının sıralanmasını beklemek zorunda kalı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ığı için.
Shoal çerçevesi
Shoal, Bullshark( veya Narwhal tabanlı herhangi bir BFT protokolünü ), her turda bir referans noktası olmasını sağlayarak ve DAG'daki tüm referans noktası olmayan düğümlerin gecikmesini üç tura indirerek akış hattı işleme ile geliştirmiştir. Shoal ayrıca DAG içinde sıfır maliyetli lider itibar mekanizması getirerek, seçimi hızlı liderler lehine yönlendirmektedir.
Mücadele
DAG protokolü bağlamında, boru hattı işleme ve liderin itibarı zor sorunlar olarak kabul edilmektedir, sebepleri şunlardır:
Önceki akış hattı işlemleri, temel Bullshark mantığını değiştirmeye çalıştı, ancak bu temelde imkansız gibi görünüyor.
Liderlerin itibarı DiemBFT'ye entegre edilip Carousel'de resmileştirildi, bu geçmişteki doğrulayıcı performansına göre gelecekteki liderlerin dinamik olarak seçilmesi fikridir (Bullshark'taki çark ). Liderlik statüsünde farklılıkların bu protokollerin güvenliğini ihlal etmemesi rağmen, Bullshark'ta bu tamamen farklı sıralamalara yol açabilir; bu durumun özü, çarkın dinamik ve belirleyici bir şekilde seçilmesinin konsensüsü sağlamak için gerekli olduğu ve doğrulayıcıların gelecekteki çarkları seçmek için düzenli bir geçmiş üzerinde mutabık kalmaları gerektiğidir.
Soru zorluğunun bir kanıtı olarak, Bullshark'ın mevcut üretim ortamındaki uygulamasının bu özellikleri desteklemediğini gözlemliyoruz.
Protokol
Yukarıda belirtilen zorluklara rağmen, çözüm basitlikte gizlidir.
Shoal'da, DAG üzerinde yerel hesaplama yapma yeteneğine güveniyoruz ve önceki tur bilgilerini saklama ve yeniden yorumlama yeteneğini gerçekleştirdik. Tüm doğrulayıcıların ilk sıralı çivi noktasını kabul etmesiyle elde edilen temel kavrayış sayesinde, Shoal birden fazla Bullshark örneğini sırayla birleştirerek bunları ardışık işleme tabi tutuyor, böylece (1) ilk sıralı çivi noktası örneklerin geçiş noktasıdır ve (2) çivi noktasının nedensel geçmişi liderin itibarını hesaplamak için kullanılır.
Akış Şeridi İşlemi
V vardır. Shoal, her bir örnekte F haritalaması ile önceden belirlenen bir ana nokta ile Bullshark örneklerini birer birer çalıştırır. Her bir örnek bir ana nokta sipariş eder, bu da bir sonraki örneğe geçişi tetikler.
Başlangıçta, Shoal DAG'ın ilk turunda Bullshark'ın ilk örneğini başlattı ve ilk sıralı ankraj noktası belirlendiği zamana kadar bunu çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu ankraj noktasında hemfikirdi. Böylece, tüm doğrulayıcılar r+1. turdan itibaren DAG'ı yeniden yorumlamak konusunda kesin bir şekilde hemfikir olabilirler. Shoal, sadece r+1. turda yeni bir Bullshark örneği başlattı.
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 o örneğe göre sıralanır ve ardından üçüncü turda başka bir yeni örnek çapa noktası sipariş eder, bu süreç devam eder.
Liderlerin İtibarı
Bullshark sıralama sırasında öncelik noktaları atlandığında, gecikme artar. Bu durumda, önceki örneğin öncelik noktası sipariş edilmeden yeni bir örnek başlatılamayacağı için boru hattı işleme tekniği işe yaramaz. Shoal, her doğrulayıcı düğümün son etkinlik geçmişine göre bir puan atayarak, gelecekte kaybolan öncelik noktalarını işlemek için ilgili liderlerin seçilme olasılığını azaltmayı garanti eder. Protokole yanıt veren ve katılan doğrulayıcılar yüksek puan alırken, aksi takdirde doğrulayıcı düğüm düşük puan alır çünkü çökebilir, yavaşlayabilir veya kötü niyetli olabilir.
Bu anlayış, her puan güncellemesinde, puanı yüksek olan liderleri tercih ederek, turdan lidere önceden tanımlanmış F haritalamasını belirli bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni haritalama üzerinde uzlaşabilmeleri için, puanlar üzerinde uzlaşmaları ve böylece türetilmiş puanlar için kullanılan tarihte de uzlaşmaları gerekir.
Shoal'da, akış hattı işleme ve liderin itibarı doğal olarak bir araya gelebilir, çünkü her ikisi de ilk sıralı ayak noktası üzerinde uzlaşma sağlandıktan sonra DAG'ı yeniden yorumlamak için aynı temel teknolojiyi kullanır.
Aslında, tek fark, r. turda sabit noktaların sıralanmasının ardından, doğrulayıcıların sadece r. turda sıralı sabit noktaların nedensel geçmişine dayanarak r+1. turdan itibaren yeni bir haritalama F' hesaplaması gerektiğidir. Ardından, doğrulama düğümleri r+1. turdan itibaren güncellenmiş sabit nokta seçim fonksiyonu F' kullanarak Bullshark'ın yeni örneğini gerçekleştirir.
Daha fazla zaman aşımı yok
Zaman aşımı, lider tabanlı belirleyici kısmi senkron BFT uygulamalarındaki kritik bir rol oynamaktadır. Ancak, getirdikleri 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ı son derece önemli olduğu için gecikmeyi önemli ölçüde artırabilir ve genellikle dinamik olarak ayarlamalar gerektirir, çünkü bu, ( ağına ) yüksek derecede bağımlıdır. Protokol, bir sonraki liderine geçmeden önce arızalı lider 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 durumlarında, Jolteon/Hotstuff'taki liderlerin aşırı yüklendiğini ve ilerlemeyi sağlamak için zaman aşımına uğramadan önce zorlandıklarını 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.
21 Likes
Reward
21
9
Share
Comment
0/400
RektCoaster
· 08-03 07:00
gecikme süresi bu kadar mı düştü? boğa!
View OriginalReply0
Degen4Breakfast
· 08-02 20:25
Boşver, demirleme için bu kadar zahmete gerek yok.
View OriginalReply0
SatoshiLegend
· 08-02 17:14
DAG optimizasyonu ne kadar iyi olursa olsun, değişmeden kalmak gerekir. Kaynak kodunun altında sır yoktur.
View OriginalReply0
NonFungibleDegen
· 08-01 16:37
bullish af aptos rn üzerinde... %80 daha hızlı mı? muhtemelen hiçbir şey ser
Shoal çerçevesi, Aptos zincirindeki Bullshark performansını önemli ölçüde artırarak gecikmeyi %80'e kadar azaltmaktadır.
Shoal Çerçevesi: Aptos'taki Bullshark Gecikmesini Nasıl Azaltabiliriz?
Genel Bakış
Aptos labları, DAG BFT'deki iki önemli açık sorunu çözerek gecikmeyi önemli ölçüde azalttı ve ilk kez belirli gerçek protokollerde duraklama gereksinimini ortadan kaldırdı. Genel olarak, sorunsuz durumlarda Bullshark'ın gecikmesini %40, arızalı durumlarda ise %80 oranında iyileştirdi.
Shoal, Narwhal tabanlı konsensüs protokollerini ( (DAG-Rider, Tusk, Bullshark ) gibi) geliştirmek için bir iş akışı ve lider itibarı mekanizması aracılığıyla bir çerçevedir. İş akışı, her turda bir referans noktası ekleyerek DAG sıralama gecikmesini azaltır, lider itibarı ise referans noktalarının en hızlı doğrulama düğümleriyle ilişkili olmasını sağlayarak gecikme sorununu daha da geliştirir. Ayrıca, lider itibarı Shoal'un tüm senaryolardaki zaman aşımını ortadan kaldırmak için asenkron DAG yapısını kullanmasına olanak tanır. Bu, Shoal'un genellikle gerekli olan iyimser yanıtı içeren, evrensel yanıt olarak adlandırdığımız bir özelliği sunmasını sağlar.
Bu teknoloji oldukça basit olup, temel protokollerin birden fazla örneğini sırayla çalıştırmayı içerir. Bu nedenle, Bullshark ile örnekleme yapıldığında, bir grup "köpekbalığı"nın bayrak yarışı yaptığı bir durum elde ederiz.
Motivasyon
Blok zinciri ağlarının yüksek performansını hedeflerken, insanlar iletişim karmaşıklığını azaltmaya dikkat ettiler. Ancak, bu yaklaşım belirgin bir işlem hacmi artışı sağlamadı. Örneğin, Diem'in erken sürümünde uygulanan Hotstuff yalnızca 3500 TPS'e ulaşabildi, bu da 100k+ TPS hedefine göre oldukça düşük.
Son dönemdeki atılım, veri yayılımının liderlik protokollerinin temel darboğazı olduğu ve burada paralelleşmeden faydalanılabileceğini anlamaktan kaynaklanıyor. 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 verimliliği rapor ediyor.
Daha önce tanıtılan Quorum Store, verilerin yayılmasını ve uzlaşmayı ayıran Narwhal'ın bir uygulamasıdır ve mevcut uzlaşma protokolü Jolteon'un ölçeklenmesi için kullanılır. Jolteon, Tendermint'in doğrusal hızlı yolları ve PBFT tarzı görünüm değişikliklerini birleştiren, lider temelli bir protokoldür ve Hotstuff'un gecikmesini %33 oranında azaltabilir. Ancak, lider temelli uzlaşma protokolleri Narwhal'ın verimlilik potansiyelini tam olarak kullanamaz. Veri yayılımı ve uzlaşma ayrılsa da, verimlilik arttıkça Hotstuff/Jolteon'un lideri hâlâ sınırlıdır.
Bu nedenle, Bullshark'ı, sıfır iletişim maliyeti olan bir konsensüs protokolü olan Narwhal DAG'ın üzerine konuşlandırmaya karar verildi. Ne yazık ki, Jolteon ile karşılaştırıldığında, Bullshark'ı destekleyen yüksek verimlilikteki DAG yapısı %50 gecikme maliyeti getirdi.
Bu makale, Shoal'ın Bullshark gecikmesini nasıl büyük ölçüde azalttığını anlatmaktadır.
DAG-BFT Arka Planı
Narwhal DAG'daki her bir doruk, bir tur ile ilişkilidir. r. tura girmek için, doğrulayıcıların öncelikle r-1. turdaki n-f doruğunu elde etmeleri gerekir. Her doğrulayıcı her turda bir doruk yayınlayabilir, her doruk en az bir önceki turdaki n-f doruğunu referans almalıdır. Ağın asenkronluğundan dolayı, farklı doğrulayıcılar herhangi bir zamanda DAG'ın farklı yerel görünümlerini gözlemleyebilir.
DAG'ın bir ana özelliği belirsiz olmamasıdır: Eğer iki doğrulayıcı düğüm, DAG'larındaki yerel görüntülerinde aynı v tepe noktasına sahipse, o zaman v'nin neden-sonuç geçmişleri tamamen aynıdır.
Toplam Sıra
Tüm düğümlerin toplam sırasının DAG'de ek iletişim maliyetleri olmadan uzlaşmasını sağlamak mümkündür. Bunu yapmak için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar, DAG'ın yapısını, düğümlerin önerileri temsil ettiği ve kenarların oyları temsil ettiği bir konsensüs protokolü olarak yorumlar.
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:
Önceden belirlenmiş lider: Her birkaç turda önceden belirlenmiş bir lider olacaktır, liderin zirvesine ise "ankraj noktası" denir;
Sıralama Bağlantı Noktaları: Doğrulayıcılar bağımsız ancak belirleyici bir şekilde hangi bağlantı noktalarının sıralanacağına ve hangilerinin atlanacağına karar verir.
Nedensellik Tarihini Sıralama: Doğrulayıcılar, sıralı referans noktası listesini tek tek işler ve her bir referans noktasının neden-sonuç 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 oluşturduğu sıralı referans noktası listesinin aynı öneki paylaşmasını sağlamaktır. Shoal'da, yukarıda belirtilen tüm protokoller hakkında aşağıdaki gözlemleri yaptık:
Tüm doğrulayıcılar ilk sıralı ankraj noktasında uzlaşır.
Bullshark Gecikmesi
Bullshark’ın gecikmesi, DAG içindeki sıralı ankraj noktaları arasındaki turların sayısına bağlıdır. Bullshark’ın en pratik kısım senkron sürümleri, asenkron sürümlerden daha iyi bir gecikmeye sahip olmasına rağmen, yine de en iyi durumdan uzaktır.
Soru 1: Ortalama blok gecikmesi. Bullshark'ta, her çift turda bir referans noktası vardır, her tek turdaki zirve ise oy verme olarak yorumlanır. Genel durumda, referans noktalarını sıralamak için iki DAG turuna ihtiyaç vardır, ancak referans noktasının nedensel tarihindeki zirvelerin referans noktalarının sıralanmasını beklemek için daha fazla tura ihtiyaç vardır. Genel durumda, tek turlardaki zirveler üç tura, çift turlardaki referans olmayan zirveler ise dört tura ihtiyaç duyar.
Soru 2: Arıza vakası 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 noktasını yayamazsa, referans noktası sıralanamaz ( bu nedenle atlanır ), bu nedenle önceki turlardaki sıralanmamış tüm zirveler bir sonraki referans noktasının sıralanmasını beklemek zorunda kalı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ığı için.
Shoal çerçevesi
Shoal, Bullshark( veya Narwhal tabanlı herhangi bir BFT protokolünü ), her turda bir referans noktası olmasını sağlayarak ve DAG'daki tüm referans noktası olmayan düğümlerin gecikmesini üç tura indirerek akış hattı işleme ile geliştirmiştir. Shoal ayrıca DAG içinde sıfır maliyetli lider itibar mekanizması getirerek, seçimi hızlı liderler lehine yönlendirmektedir.
Mücadele
DAG protokolü bağlamında, boru hattı işleme ve liderin itibarı zor sorunlar olarak kabul edilmektedir, sebepleri şunlardır:
Önceki akış hattı işlemleri, temel Bullshark mantığını değiştirmeye çalıştı, ancak bu temelde imkansız gibi görünüyor.
Liderlerin itibarı DiemBFT'ye entegre edilip Carousel'de resmileştirildi, bu geçmişteki doğrulayıcı performansına göre gelecekteki liderlerin dinamik olarak seçilmesi fikridir (Bullshark'taki çark ). Liderlik statüsünde farklılıkların bu protokollerin güvenliğini ihlal etmemesi rağmen, Bullshark'ta bu tamamen farklı sıralamalara yol açabilir; bu durumun özü, çarkın dinamik ve belirleyici bir şekilde seçilmesinin konsensüsü sağlamak için gerekli olduğu ve doğrulayıcıların gelecekteki çarkları seçmek için düzenli bir geçmiş üzerinde mutabık kalmaları gerektiğidir.
Soru zorluğunun bir kanıtı olarak, Bullshark'ın mevcut üretim ortamındaki uygulamasının bu özellikleri desteklemediğini gözlemliyoruz.
Protokol
Yukarıda belirtilen zorluklara rağmen, çözüm basitlikte gizlidir.
Shoal'da, DAG üzerinde yerel hesaplama yapma yeteneğine güveniyoruz ve önceki tur bilgilerini saklama ve yeniden yorumlama yeteneğini gerçekleştirdik. Tüm doğrulayıcıların ilk sıralı çivi noktasını kabul etmesiyle elde edilen temel kavrayış sayesinde, Shoal birden fazla Bullshark örneğini sırayla birleştirerek bunları ardışık işleme tabi tutuyor, böylece (1) ilk sıralı çivi noktası örneklerin geçiş noktasıdır ve (2) çivi noktasının nedensel geçmişi liderin itibarını hesaplamak için kullanılır.
Akış Şeridi İşlemi
V vardır. Shoal, her bir örnekte F haritalaması ile önceden belirlenen bir ana nokta ile Bullshark örneklerini birer birer çalıştırır. Her bir örnek bir ana nokta sipariş eder, bu da bir sonraki örneğe geçişi tetikler.
Başlangıçta, Shoal DAG'ın ilk turunda Bullshark'ın ilk örneğini başlattı ve ilk sıralı ankraj noktası belirlendiği zamana kadar bunu çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu ankraj noktasında hemfikirdi. Böylece, tüm doğrulayıcılar r+1. turdan itibaren DAG'ı yeniden yorumlamak konusunda kesin bir şekilde hemfikir olabilirler. Shoal, sadece r+1. turda yeni bir Bullshark örneği başlattı.
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 o örneğe göre sıralanır ve ardından üçüncü turda başka bir yeni örnek çapa noktası sipariş eder, bu süreç devam eder.
Liderlerin İtibarı
Bullshark sıralama sırasında öncelik noktaları atlandığında, gecikme artar. Bu durumda, önceki örneğin öncelik noktası sipariş edilmeden yeni bir örnek başlatılamayacağı için boru hattı işleme tekniği işe yaramaz. Shoal, her doğrulayıcı düğümün son etkinlik geçmişine göre bir puan atayarak, gelecekte kaybolan öncelik noktalarını işlemek için ilgili liderlerin seçilme olasılığını azaltmayı garanti eder. Protokole yanıt veren ve katılan doğrulayıcılar yüksek puan alırken, aksi takdirde doğrulayıcı düğüm düşük puan alır çünkü çökebilir, yavaşlayabilir veya kötü niyetli olabilir.
Bu anlayış, her puan güncellemesinde, puanı yüksek olan liderleri tercih ederek, turdan lidere önceden tanımlanmış F haritalamasını belirli bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni haritalama üzerinde uzlaşabilmeleri için, puanlar üzerinde uzlaşmaları ve böylece türetilmiş puanlar için kullanılan tarihte de uzlaşmaları gerekir.
Shoal'da, akış hattı işleme ve liderin itibarı doğal olarak bir araya gelebilir, çünkü her ikisi de ilk sıralı ayak noktası üzerinde uzlaşma sağlandıktan sonra DAG'ı yeniden yorumlamak için aynı temel teknolojiyi kullanır.
Aslında, tek fark, r. turda sabit noktaların sıralanmasının ardından, doğrulayıcıların sadece r. turda sıralı sabit noktaların nedensel geçmişine dayanarak r+1. turdan itibaren yeni bir haritalama F' hesaplaması gerektiğidir. Ardından, doğrulama düğümleri r+1. turdan itibaren güncellenmiş sabit nokta seçim fonksiyonu F' kullanarak Bullshark'ın yeni örneğini gerçekleştirir.
Daha fazla zaman aşımı yok
Zaman aşımı, lider tabanlı belirleyici kısmi senkron BFT uygulamalarındaki kritik bir rol oynamaktadır. Ancak, getirdikleri 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ı son derece önemli olduğu için gecikmeyi önemli ölçüde artırabilir ve genellikle dinamik olarak ayarlamalar gerektirir, çünkü bu, ( ağına ) yüksek derecede bağımlıdır. Protokol, bir sonraki liderine geçmeden önce arızalı lider 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 durumlarında, Jolteon/Hotstuff'taki liderlerin aşırı yüklendiğini ve ilerlemeyi sağlamak için zaman aşımına uğramadan önce zorlandıklarını gözlemledik.