Shoal çerçevesi: Aptos üzerindeki Bullshark gecikme süresini nasıl düşürebiliriz?
Genel Bakış
Aptos laboratuvarları, DAG BFT'deki iki önemli açık sorunu çözdü, gecikmeyi önemli ölçüde azalttı ve ilk kez, belirleyici gerçek protokolde zaman aşımı gereksinimini ortadan kaldırdı. Genel olarak, hatasız durumlarda Bullshark'ın gecikmesini %40 oranında, hatalı durumlarda ise %80 oranında iyileştirdi.
Shoal, Narwhal tabanlı konsensüs protokollerini ( DAG-Rider, Tusk, Bullshark ) gibi güçlendirmek için bir çerçevedir. Pipeline, her turda bir referans noktası tanıtarak DAG sıralama gecikmesini azaltır, liderin itibarı ise referans noktalarını en hızlı doğrulama düğümleriyle ilişkilendirerek gecikme sorununu daha da iyileştirir. Ayrıca, liderin itibarı, Shoal'ın tüm senaryolardaki zaman aşımını ortadan kaldırmak için asenkron DAG yapısını kullanmasını sağlar. Bu, Shoal'ın, genellikle gereken iyimser yanıtları içeren evrensel bir yanıt özelliği sunmasını sağlar.
Bu teknoloji oldukça basit olup, temel protokollerin birden fazla örneğinin sırasıyla çalıştırılmasını içerir. Bu nedenle, Bullshark ile örneklendiğinde, bir grup "köpekbalığı"nın bayrak yarışı yaptığı bir durum elde ediyoruz.
Motivasyon
Blok zinciri ağlarının yüksek performansını hedeflerken, iletişim karmaşıklığını azaltmaya sürekli odaklanıldı. Ancak, bu yöntem, çıktı miktarında belirgin bir artış sağlamadı. Örneğin, erken versiyon Diem'de uygulanan Hotstuff sadece 3500 TPS sağladı, bu da 100k+ TPS hedefinin çok altında.
Son zamanlarda yapılan atılım, veri yayılımının liderlik protokolüne dayanan ana engel olduğunu anlamaktan kaynaklanmaktadır ve bu durum paralelleşmeden fayda sağlayabilir. Narwhal sistemi, veri yayılımını ana 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 etmektedir.
Daha önce Quorum Store'dan bahsedilmişti, verilerin yayılmasını ve konsensüsü ayırarak mevcut konsensüs protokolü Jolteon'u nasıl ölçeklendirebileceğiniz. Jolteon, lider tabanlı bir protokoldür, Tendermint'in lineer hızlı yolu ve PBFT tarzı görünüm değişikliklerini birleştirerek Hotstuff gecikmesini %33 oranında düşürür. Ancak, lider tabanlı konsensüs protokolü Narwhal'ın verimlilik potansiyelinden tam olarak yararlanamaz. Verilerin yayılmasını ve konsensüsü ayırmış olmasına rağmen, verimlilik arttıkça Hotstuff/Jolteon'un liderleri hala sınırlıdır.
Bu nedenle, Narwhal DAG'ı üzerinde, sıfır iletişim maliyeti olan Bullshark adlı bir konsensüs protokolü uygulamaya karar verildi. Ne yazık ki, Jolteon ile karşılaştırıldığında, Bullshark yüksek verimliliği destekleyen DAG yapısı %50'lik bir düşüş maliyeti getirdi.
Bu makale, Shoal'ın Bullshark gecikme süresini nasıl önemli ölçüde azalttığını tanıtmaktadır.
DAG-BFT Arka Planı
Narwhal DAG'daki her bir nokta, tur ile ilişkilidir. r. tura girmek için, doğrulayıcının önce r-1. tura ait n-f adet noktayı alması gerekmektedir. Her doğrulayıcı her turda bir nokta yayınlayabilir ve her nokta en az önceki turdaki n-f adet noktayı referans almalıdır. Ağın asenkron doğası nedeniyle, farklı doğrulayıcılar herhangi bir anda DAG'ın farklı yerel görünümlerini gözlemleyebilir.
DAG'ın önemli bir özelliği belirsizlik olmamasıdır: Eğer iki doğrulayıcı düğüm DAG yerel görünümünde aynı tepe noktası v'ye sahipse, o zaman v'nin nedensel geçmişi tamamen aynıdır.
Genel Sıra
DAG'daki tüm düğümlerin toplam sırasının ek iletişim maliyeti olmadan uzlaşmasını sağlamak mümkündür. Bunun için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar DAG yapısını bir konsensüs protokolü olarak yorumlar, düğümler önerileri temsil ederken, kenarlar oylamayı 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 belirlenmiş referans noktası: Her birkaç turda (, Bullshark içindeki iki turda ) önceden belirlenmiş bir lider vardır, bu liderin zirvesine referans noktası denir.
Sıralama bağlantı noktası: Doğrulayıcılar bağımsız ama kararlı bir şekilde hangi bağlantı noktalarını sipariş edeceğine ve hangilerini atlayacağına karar verir.
Nedensel tarih sıralaması: Doğrulayıcılar, sıralı referans noktası listesini tek tek işler; her referans noktası için, deterministik kurallar aracılığıyla, onun 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ğrulayıcı düğümlerin sıralı sabit nokta listeleri oluşturduğundan emin olmaktır; böylece tüm listeler aynı öneki paylaşır. Shoal'da yukarıdaki tüm protokoller hakkında aşağıdaki gözlemler yapılmıştır:
Tüm doğrulayıcılar ilk sıralı referansa katılıyor.
Bullshark gecikme süresi
Bullshark'ın gecikme süresi, DAG'daki sıralı sabit noktalar arasındaki döngü sayısına bağlıdır. Bullshark'ın en kullanışlı kısmi senkron versiyonu, asenkron versiyondan daha iyi bir gecikmeye sahip olsa da, en iyisi değildir.
Soru 1: Ortalama blok gecikmesi. Bullshark'ta, her çift turda bir sabit nokta, her tek turda ise zirve oylama olarak yorumlanır. Yaygın durumlarda, sabit noktaları sıralamak için iki tur DAG gereklidir, ancak sabit nokta nedensel geçmişindeki zirveler, sabit noktaların sıralanmasını beklemek için daha fazla tura ihtiyaç duyar. Yaygın durumda, tek turlardaki zirvelerin üç tura, çift turlardaki sabit olmayan zirvelerin ise dört tura ihtiyacı 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 tur lideri yeterince hızlı bir şekilde sabit noktaları yayınlayamazsa, sabit noktalar sıralanamaz ( bu nedenle atlanır ), önceki turlardaki tüm sıralanmamış zirveler bir sonraki sabit noktanın sıralanmasını beklemek zorundadır. Bu, coğrafi kopyalama ağının performansını önemli ölçüde düşürmektedir, özellikle çünkü Bullshark liderin zaman aşımını beklemesini kullanır.
Shoal çerçevesi
Shoal, bu iki gecikme süresini çözmüştür; Bullshark( veya başka herhangi bir Narwhal tabanlı BFT protokolünü ), her turda bir referans noktası olmasını sağlayarak ve DAG'daki tüm referans noktası olmayan düğümlerin gecikmesini üç tura düşürerek iyileştirmiştir. Shoal ayrıca DAG'da sıfır maliyetli lider itibar mekanizmasını tanıtarak, seçimi hızlı liderler lehine kaydırmaktadır.
Mücadele
DAG protokolü bağlamında, boru hattı ve liderin itibarı zor sorunlar olarak kabul edilmektedir, nedenleri şunlardır:
Önceki üretim hattı, 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ş ve Carousel'de resmileştirilmiştir; bu, doğrulayıcıların geçmiş performanslarına dayanarak gelecekteki liderleri dinamik olarak seçme fikridir. Liderlik kimliğinde bir ayrımcılık bulunması 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 olarak döngüsel bağlayıcıların seçilmesi, uzlaşmayı sağlamak için gereklidir ve doğrulayıcılar, gelecekteki bağlayıcıları seçmek için düzenli bir geçmiş üzerinde uzlaşmalıdır.
Soru zorluğunun kanıtı olarak, Bullshark'ın uygulanması, şu anda üretim ortamındaki uygulama dahil, bu özellikleri desteklememektedir.
Protokol
Yukarıda belirtilen zorluklara rağmen, çözüm basitliğin arkasında gizlidir.
Shoal'da, DAG üzerinde yerel hesaplama yapabilme 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ının temel içgörüsünde hemfikir olmasıyla, Shoal birden fazla Bullshark örneğini sıralı bir şekilde birleştirerek bunları ardışık işleme tabi tutuyor, 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.
Akış Hattı
V haritası vardır. Shoal, Bullshark'ın örneklerini birer birer çalıştırır, böylece her örnek için, ankraj F haritası tarafından önceden belirlenir. Her örnek bir ankraj sipariş eder, 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ı sabit nokta belirlendiği zamana kadar çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu sabit noktayı kabul etti. Bu nedenle, tüm doğrulayıcılar r+1. turdan itibaren DAG'ı yeniden yorumlamayı kesin bir şekilde kabul edebilirler. Shoal, yalnızca r+1. turda yeni bir Bullshark örneğini başlattı.
En iyi senaryoda, bu, Shoal'ın her turda bir çapa sipariş etmesine izin verir. İlk turun çapa noktaları, ilk örneğe göre sıralanır. Ardından, Shoal ikinci turda yeni bir örnek başlatır, bu örnek kendi çapa noktasına sahiptir, bu çapa o örnek tarafından sıralanır, ardından üçüncü turda başka bir yeni örnek çapa noktası sipariş eder ve bu süreç devam eder.
Liderlerin İtibarı
Bullshark sıralama sırasında ankra noktasını atladığınızda, gecikme süresi artar. Bu durumda, önceki örneğin sıralanmasından önce yeni bir örneği başlatmak mümkün olmadığı için, hat geçişi teknolojisi etkisizdir. Shoal, her doğrulama düğümünün son etkinlik geçmişine dayalı olarak her doğrulama düğümüne puan vererek, gelecekte kaybolan ankra noktalarını işlemek için ilgili liderlerin seçilme olasılığının daha 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ü çökmekte, yavaşlamakta veya kötü niyetli davranmaktadırlar.
Felsefesi, her puan güncellemesinde, yüksek puan alan liderlere eğilimli olarak turdan liderlere önceden tanımlanmış F eşlemesini belirli bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni eşleme üzerinde uzlaşabilmesi için, puan üzerinde uzlaşmaları ve böylece türetilmiş puanlar için kullanılan tarih üzerinde uzlaşmaları gerekir.
Shoal'da, akış hattı ve liderlik itibarı doğal olarak birleşebilir, çünkü ikisi de ilk sıralı sabit noktada uzlaşmaya varıldı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 sadece r. turda sıralı referans noktalarının nedensel geçmişine göre, r+1. turdan itibaren yeni eşleme F'yi hesaplaması gerektiğidir. Ardından, 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 zaman aşımı yok
Zaman aşımı, tü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ç durum sayısını artırmakta, bu da hata ayıklama sürecinin karmaşıklığını artırmakta ve daha fazla gözlemlenebilirlik teknikleri gerektirmektedir.
Zaman aşımı, uygun şekilde yapılandırılmaları çok önemli olduğundan ve genellikle dinamik ayarlamalar gerektirdiğinden, gecikmeyi de önemli ölçüde artıracaktır, çünkü bu, ortam( ağına) yüksek oranda bağımlıdır. Protokol, bir sonraki lidere 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/Hotstuff'taki liderlerin aşırı yüklenme yaşadığını ve ilerlemeyi sağlamadan önce zaman aşımının süresi dolduğunu gözlemledik.
Ne yazık ki, lider protokolleri ( gibi Hotstuff ve Jolteon) esasen zaman aşımına ihtiyaç duyar, böylece her seferinde lider başarısız olduğunda protokol ilerleme kaydedebilir. Zaman aşımı olmadan, çöküş yaşayan bir lider bile protokolü sonsuza dek durdurabilir. Asenkron dönemlerde başarısız bir liderin varlığını ayırt etmek mümkün olmadığından...
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.
23 Likes
Reward
23
6
Share
Comment
0/400
VirtualRichDream
· 07-25 11:15
gecikme süresi bu kadar azaldı, Aptos aya doğru uçacak.
View OriginalReply0
CoffeeNFTs
· 07-22 19:02
Bu gecikme süresi düşüşü biraz hoş.
View OriginalReply0
RugDocDetective
· 07-22 19:01
Harika! Uzun süredir bekliyordum, Aptos planı nihayet çıktı.
View OriginalReply0
RuntimeError
· 07-22 19:00
aptos bu yeni numara gerçekten işe yarıyor mu?
View OriginalReply0
UnluckyValidator
· 07-22 18:58
gecikme süresi yüksek olan günler sonunda sona erdi. Altı ay boyunca dondum.
Shoal çerçevesi, Aptos on-chain Bullshark gecikme süresini büyük ölçüde düşürerek %40-80 artırdı.
Shoal çerçevesi: Aptos üzerindeki Bullshark gecikme süresini nasıl düşürebiliriz?
Genel Bakış
Aptos laboratuvarları, DAG BFT'deki iki önemli açık sorunu çözdü, gecikmeyi önemli ölçüde azalttı ve ilk kez, belirleyici gerçek protokolde zaman aşımı gereksinimini ortadan kaldırdı. Genel olarak, hatasız durumlarda Bullshark'ın gecikmesini %40 oranında, hatalı durumlarda ise %80 oranında iyileştirdi.
Shoal, Narwhal tabanlı konsensüs protokollerini ( DAG-Rider, Tusk, Bullshark ) gibi güçlendirmek için bir çerçevedir. Pipeline, her turda bir referans noktası tanıtarak DAG sıralama gecikmesini azaltır, liderin itibarı ise referans noktalarını en hızlı doğrulama düğümleriyle ilişkilendirerek gecikme sorununu daha da iyileştirir. Ayrıca, liderin itibarı, Shoal'ın tüm senaryolardaki zaman aşımını ortadan kaldırmak için asenkron DAG yapısını kullanmasını sağlar. Bu, Shoal'ın, genellikle gereken iyimser yanıtları içeren evrensel bir yanıt özelliği sunmasını sağlar.
Bu teknoloji oldukça basit olup, temel protokollerin birden fazla örneğinin sırasıyla çalıştırılmasını içerir. Bu nedenle, Bullshark ile örneklendiğinde, bir grup "köpekbalığı"nın bayrak yarışı yaptığı bir durum elde ediyoruz.
Motivasyon
Blok zinciri ağlarının yüksek performansını hedeflerken, iletişim karmaşıklığını azaltmaya sürekli odaklanıldı. Ancak, bu yöntem, çıktı miktarında belirgin bir artış sağlamadı. Örneğin, erken versiyon Diem'de uygulanan Hotstuff sadece 3500 TPS sağladı, bu da 100k+ TPS hedefinin çok altında.
Son zamanlarda yapılan atılım, veri yayılımının liderlik protokolüne dayanan ana engel olduğunu anlamaktan kaynaklanmaktadır ve bu durum paralelleşmeden fayda sağlayabilir. Narwhal sistemi, veri yayılımını ana 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 etmektedir.
Daha önce Quorum Store'dan bahsedilmişti, verilerin yayılmasını ve konsensüsü ayırarak mevcut konsensüs protokolü Jolteon'u nasıl ölçeklendirebileceğiniz. Jolteon, lider tabanlı bir protokoldür, Tendermint'in lineer hızlı yolu ve PBFT tarzı görünüm değişikliklerini birleştirerek Hotstuff gecikmesini %33 oranında düşürür. Ancak, lider tabanlı konsensüs protokolü Narwhal'ın verimlilik potansiyelinden tam olarak yararlanamaz. Verilerin yayılmasını ve konsensüsü ayırmış olmasına rağmen, verimlilik arttıkça Hotstuff/Jolteon'un liderleri hala sınırlıdır.
Bu nedenle, Narwhal DAG'ı üzerinde, sıfır iletişim maliyeti olan Bullshark adlı bir konsensüs protokolü uygulamaya karar verildi. Ne yazık ki, Jolteon ile karşılaştırıldığında, Bullshark yüksek verimliliği destekleyen DAG yapısı %50'lik bir düşüş maliyeti getirdi.
Bu makale, Shoal'ın Bullshark gecikme süresini nasıl önemli ölçüde azalttığını tanıtmaktadır.
DAG-BFT Arka Planı
Narwhal DAG'daki her bir nokta, tur ile ilişkilidir. r. tura girmek için, doğrulayıcının önce r-1. tura ait n-f adet noktayı alması gerekmektedir. Her doğrulayıcı her turda bir nokta yayınlayabilir ve her nokta en az önceki turdaki n-f adet noktayı referans almalıdır. Ağın asenkron doğası nedeniyle, farklı doğrulayıcılar herhangi bir anda DAG'ın farklı yerel görünümlerini gözlemleyebilir.
DAG'ın önemli bir özelliği belirsizlik olmamasıdır: Eğer iki doğrulayıcı düğüm DAG yerel görünümünde aynı tepe noktası v'ye sahipse, o zaman v'nin nedensel geçmişi tamamen aynıdır.
Genel Sıra
DAG'daki tüm düğümlerin toplam sırasının ek iletişim maliyeti olmadan uzlaşmasını sağlamak mümkündür. Bunun için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar DAG yapısını bir konsensüs protokolü olarak yorumlar, düğümler önerileri temsil ederken, kenarlar oylamayı 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 belirlenmiş referans noktası: Her birkaç turda (, Bullshark içindeki iki turda ) önceden belirlenmiş bir lider vardır, bu liderin zirvesine referans noktası denir.
Sıralama bağlantı noktası: Doğrulayıcılar bağımsız ama kararlı bir şekilde hangi bağlantı noktalarını sipariş edeceğine ve hangilerini atlayacağına karar verir.
Nedensel tarih sıralaması: Doğrulayıcılar, sıralı referans noktası listesini tek tek işler; her referans noktası için, deterministik kurallar aracılığıyla, onun 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ğrulayıcı düğümlerin sıralı sabit nokta listeleri oluşturduğundan emin olmaktır; böylece tüm listeler aynı öneki paylaşır. Shoal'da yukarıdaki tüm protokoller hakkında aşağıdaki gözlemler yapılmıştır:
Tüm doğrulayıcılar ilk sıralı referansa katılıyor.
Bullshark gecikme süresi
Bullshark'ın gecikme süresi, DAG'daki sıralı sabit noktalar arasındaki döngü sayısına bağlıdır. Bullshark'ın en kullanışlı kısmi senkron versiyonu, asenkron versiyondan daha iyi bir gecikmeye sahip olsa da, en iyisi değildir.
Soru 1: Ortalama blok gecikmesi. Bullshark'ta, her çift turda bir sabit nokta, her tek turda ise zirve oylama olarak yorumlanır. Yaygın durumlarda, sabit noktaları sıralamak için iki tur DAG gereklidir, ancak sabit nokta nedensel geçmişindeki zirveler, sabit noktaların sıralanmasını beklemek için daha fazla tura ihtiyaç duyar. Yaygın durumda, tek turlardaki zirvelerin üç tura, çift turlardaki sabit olmayan zirvelerin ise dört tura ihtiyacı 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 tur lideri yeterince hızlı bir şekilde sabit noktaları yayınlayamazsa, sabit noktalar sıralanamaz ( bu nedenle atlanır ), önceki turlardaki tüm sıralanmamış zirveler bir sonraki sabit noktanın sıralanmasını beklemek zorundadır. Bu, coğrafi kopyalama ağının performansını önemli ölçüde düşürmektedir, özellikle çünkü Bullshark liderin zaman aşımını beklemesini kullanır.
Shoal çerçevesi
Shoal, bu iki gecikme süresini çözmüştür; Bullshark( veya başka herhangi bir Narwhal tabanlı BFT protokolünü ), her turda bir referans noktası olmasını sağlayarak ve DAG'daki tüm referans noktası olmayan düğümlerin gecikmesini üç tura düşürerek iyileştirmiştir. Shoal ayrıca DAG'da sıfır maliyetli lider itibar mekanizmasını tanıtarak, seçimi hızlı liderler lehine kaydırmaktadır.
Mücadele
DAG protokolü bağlamında, boru hattı ve liderin itibarı zor sorunlar olarak kabul edilmektedir, nedenleri şunlardır:
Önceki üretim hattı, 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ş ve Carousel'de resmileştirilmiştir; bu, doğrulayıcıların geçmiş performanslarına dayanarak gelecekteki liderleri dinamik olarak seçme fikridir. Liderlik kimliğinde bir ayrımcılık bulunması 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 olarak döngüsel bağlayıcıların seçilmesi, uzlaşmayı sağlamak için gereklidir ve doğrulayıcılar, gelecekteki bağlayıcıları seçmek için düzenli bir geçmiş üzerinde uzlaşmalıdır.
Soru zorluğunun kanıtı olarak, Bullshark'ın uygulanması, şu anda üretim ortamındaki uygulama dahil, bu özellikleri desteklememektedir.
Protokol
Yukarıda belirtilen zorluklara rağmen, çözüm basitliğin arkasında gizlidir.
Shoal'da, DAG üzerinde yerel hesaplama yapabilme 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ının temel içgörüsünde hemfikir olmasıyla, Shoal birden fazla Bullshark örneğini sıralı bir şekilde birleştirerek bunları ardışık işleme tabi tutuyor, 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.
Akış Hattı
V haritası vardır. Shoal, Bullshark'ın örneklerini birer birer çalıştırır, böylece her örnek için, ankraj F haritası tarafından önceden belirlenir. Her örnek bir ankraj sipariş eder, 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ı sabit nokta belirlendiği zamana kadar çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu sabit noktayı kabul etti. Bu nedenle, tüm doğrulayıcılar r+1. turdan itibaren DAG'ı yeniden yorumlamayı kesin bir şekilde kabul edebilirler. Shoal, yalnızca r+1. turda yeni bir Bullshark örneğini başlattı.
En iyi senaryoda, bu, Shoal'ın her turda bir çapa sipariş etmesine izin verir. İlk turun çapa noktaları, ilk örneğe göre sıralanır. Ardından, Shoal ikinci turda yeni bir örnek başlatır, bu örnek kendi çapa noktasına sahiptir, bu çapa o örnek tarafından sıralanır, ardından üçüncü turda başka bir yeni örnek çapa noktası sipariş eder ve bu süreç devam eder.
Liderlerin İtibarı
Bullshark sıralama sırasında ankra noktasını atladığınızda, gecikme süresi artar. Bu durumda, önceki örneğin sıralanmasından önce yeni bir örneği başlatmak mümkün olmadığı için, hat geçişi teknolojisi etkisizdir. Shoal, her doğrulama düğümünün son etkinlik geçmişine dayalı olarak her doğrulama düğümüne puan vererek, gelecekte kaybolan ankra noktalarını işlemek için ilgili liderlerin seçilme olasılığının daha 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ü çökmekte, yavaşlamakta veya kötü niyetli davranmaktadırlar.
Felsefesi, her puan güncellemesinde, yüksek puan alan liderlere eğilimli olarak turdan liderlere önceden tanımlanmış F eşlemesini belirli bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni eşleme üzerinde uzlaşabilmesi için, puan üzerinde uzlaşmaları ve böylece türetilmiş puanlar için kullanılan tarih üzerinde uzlaşmaları gerekir.
Shoal'da, akış hattı ve liderlik itibarı doğal olarak birleşebilir, çünkü ikisi de ilk sıralı sabit noktada uzlaşmaya varıldı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 sadece r. turda sıralı referans noktalarının nedensel geçmişine göre, r+1. turdan itibaren yeni eşleme F'yi hesaplaması gerektiğidir. Ardından, 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 zaman aşımı yok
Zaman aşımı, tü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ç durum sayısını artırmakta, bu da hata ayıklama sürecinin karmaşıklığını artırmakta ve daha fazla gözlemlenebilirlik teknikleri gerektirmektedir.
Zaman aşımı, uygun şekilde yapılandırılmaları çok önemli olduğundan ve genellikle dinamik ayarlamalar gerektirdiğinden, gecikmeyi de önemli ölçüde artıracaktır, çünkü bu, ortam( ağına) yüksek oranda bağımlıdır. Protokol, bir sonraki lidere 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/Hotstuff'taki liderlerin aşırı yüklenme yaşadığını ve ilerlemeyi sağlamadan önce zaman aşımının süresi dolduğunu gözlemledik.
Ne yazık ki, lider protokolleri ( gibi Hotstuff ve Jolteon) esasen zaman aşımına ihtiyaç duyar, böylece her seferinde lider başarısız olduğunda protokol ilerleme kaydedebilir. Zaman aşımı olmadan, çöküş yaşayan bir lider bile protokolü sonsuza dek durdurabilir. Asenkron dönemlerde başarısız bir liderin varlığını ayırt etmek mümkün olmadığından...