Shoal çerçevesi: Aptos'ta Bullshark'ın düşüşünü nasıl azaltır
Aptos laboratuvarları, DAG BFT'deki iki önemli açık sorunu çözdü, gecikme süresini büyük ölçüde düşürdü ve deterministik gerçek protokoller için zaman aşımı gereksinimini ilk kez ortadan kaldırdı. Genel olarak, Shoal çerçevesi, hatasız durumlarda Bullshark'ın gecikme süresini %40 oranında iyileştirirken, arızalı durumlarda %80 oranında iyileştirdi.
Shoal, DAG-Rider, Tusk, Bullshark ( gibi çerçevelerin temelinde yer alan Narwhal tabanlı konsensüs protokolünü, akış hatları ve liderlerin itibarını kullanarak geliştiren bir sistemdir. Akış hattı, her turda bir referans noktası tanıtarak DAG sıralama gecikmesini azaltır, liderlerin itibarı 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, liderlerin itibarı, Shoal'ın tüm senaryolarda zaman aşımını ortadan kaldırmak için asenkron DAG yapısını kullanmasına olanak tanır. Bu, Shoal'ın genellikle gerekli olan iyimser yanıtları içeren evrensel yanıt olarak adlandırdığımız özelliği sunmasını sağlar.
Shoal'un teknolojisi oldukça basittir, bu, alt protokollerin birden fazla örneğini sırayla çalıştırmayı içerir. Bu nedenle, Bullshark örneği kullanıldığında, bir grup "köpekbalığı" bayrak yarışı yapar.
Blok zinciri ağlarının yüksek performansını hedeflerken, insanlar iletişim karmaşıklığını azaltmaya odaklandılar. Ancak, bu yöntem önemli bir düşüşe yol açmadı. Örneğin, erken sürüm Diem'de uygulanan Hotstuff yalnızca 3500 TPS gerçekleştirdi, bu da 100k+ TPS hedefinin oldukça altında.
Son zamanlardaki突破, veri iletiminin liderlik protokollerine dayanan ana darboğaz olduğunu ve paralelleşmeden faydalanabileceğini anlamaktan kaynaklandı. Narwhal sistemi, veri iletimini ana 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 daha az miktarda meta veriyi sıraladığı bir mimari önerdi. Narwhal belgesi, 160.000 TPS'lik bir throughput bildirmektedir.
Aptos daha önce Quorum Store'u tanıttı, bu onların Narwhal uygulaması, veri yayılımını konsensüsten ayırıyor ve mevcut konsensüs protokolü Jolteon'u ölçeklendirmek için kullanılıyor. Jolteon, Tendermint'in lineer hızlı yolu ile PBFT tarzı görünüm değişikliklerini birleştiren lider tabanlı bir protokoldür ve Hotstuff'un gecikmesini %33 oranında düşürür. Ancak, lider tabanlı konsensüs protokolleri Narwhal'ın verimlilik potansiyelinden tam olarak yararlanamaz. Veri yayılımı ile konsensüsü ayırmış olmasına rağmen, verimlilik arttıkça Hotstuff/Jolteon'un liderleri hala sınırlıdır.
Bu nedenle, Aptos, Narwhal DAG üzerinde, sıfır iletişim maliyetine sahip bir konsensüs protokolü olan Bullshark'ı dağıtmaya karar verdi. Ne yazık ki, Jolteon ile karşılaştırıldığında, Bullshark yüksek throughput'u destekleyen DAG yapısı %50 gecikme süresi maliyeti getirdi.
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 tepe noktası bir tur ile ilişkilidir. r. tura girmek için, doğrulayıcıların öncelikle r-1. tura ait n-f tepe noktasını elde etmeleri gerekir. Her doğrulayıcı her turda bir tepe noktası yayınlayabilir, her tepe noktası en az bir önceki turdaki n-f tepe noktasını referans almalıdır. Ağın asenkron olması nedeniyle, 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 değildir: Eğer iki doğrulayıcı düğüm, DAG'larının yerel görünümünde aynı tepe noktası v'ye sahipse, o zaman v'nin nedensel geçmişi tamamen aynıdır.
![Shoal çerçevesinin detaylı açıklaması: Aptos'taki Bullshark gecikme süresini nasıl azaltırız?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Genel Sıralama
DAG'daki tüm düğümlerin toplam sırasının ekstra iletişim maliyeti olmadan uzlaşmaya varılması mümkündür. 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, kenarlar ise oylamayı temsil eder.
DAG yapısındaki grup kesişim mantığı farklı olsa da, mevcut tüm Narwhal tabanlı konsensüs protokolleri aşağıdaki yapıya sahiptir:
belirlenen referans noktası: Her birkaç turda ), Bullshark'taki iki turda ( önceden belirlenmiş bir lider olacak, liderin zirvesine referans noktası denir.
sıralama bağlantı noktası: doğrulayıcılar bağımsız fakat kesin bir şekilde hangi bağlantı noktalarının sıralanacağına ve hangi bağlantı noktalarının atlanacağına karar verir.
sıralama nedensellik geçmişi: doğrulayıcılar, sıralı bağlam listelerini birer birer işler ve her bağlam için, nedensellik geçmişlerinde daha önceki düzensiz noktaları bazı belirleyici kurallara göre sıralar.
Güvenliğin sağlanmasının anahtarı, yukarıdaki adımda )2(, tüm dürüst doğrulayıcı düğümlerin ortak bir ön ek paylaşması için sıralı bir referans noktası listesi oluşturduğundan emin olmaktır. Shoal'da, yukarıdaki tüm protokollerle ilgili şu gözlemler yapılmıştır:
Tüm doğrulayıcılar ilk sıralı bağlantıyı kabul eder.
Bullshark'ın gecikme süresi, DAG'daki sıralı ana noktalar arasındaki döngü sayısına bağlıdır. Bullshark'ın en kullanışlı kısmi senkron versiyonu, asenkron versiyona göre daha iyi bir gecikmeye sahip olmasına rağmen, bu durumda en iyi değildir.
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. Yaygın durumlarda, referans noktalarını sıralamak için iki tur DAG gereklidir, ancak referansın nedensel geçmişindeki zirvelerin referansın sıralanmasını beklemek için daha fazla tura ihtiyacı vardır. Yaygın durumlarda, tek turdaki zirvelerin üç tura, çift turdaki referans olmayan zirvelerin ise dört tura ihtiyacı vardır.
Soru 2: Arıza durumu gecikmesi, yukarıdaki gecikme analizi arıza durumu olmayan durumlar için geçerlidir. Öte yandan, eğer bir turdaki lider yeterince hızlı bir şekilde referans noktalarını yayınlayamazsa, referans noktaları sıralanamaz ve 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 düşürür, özellikle de lideri beklemek için kullanılan Bullshark zaman aşımı nedeniyle.
Shoal çerçevesi
Shoal, bu iki gecikme süresini çözdü, Bullshark( veya diğer Narwhal tabanlı BFT protokolleri) üzerinde bir boru hattı ile güçlendirdi, 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ı tanıttı, bu da seçimlerin hızlı liderlere yönelmesini sağladı.
Mücadele
DAG protokolü bağlamında, boru hattı ve liderin itibarı zor bir sorun olarak kabul edilmektedir, sebepleri ise şunlardır:
1( Önceki üretim hattı, temel Bullshark mantığını değiştirmeye çalıştı, ancak bu temelde imkansız gibi görünüyor.
Liderlerin itibarı DiemBFT'ye entegre edildi ve Carousel'de resmileştirildi, bu, doğrulayıcıların geçmiş performansına dayalı olarak gelecekteki liderlerin dinamik olarak seçilmesi fikridir )Bullshark içindeki çark ). Liderlik kimliğinde var olan anlaşmazlık bu protokollerin güvenliğini ihlal etmemekle birlikte, Bullshark'ta tamamen farklı sıralamalara yol açabilir, bu da sorunun özünü ortaya koymaktadır; yani çarkın dinamik ve belirleyici bir şekilde seçilmesi konsensüsü sağlamak için gereklidir ve doğrulayıcıların gelecekteki çarkı seçmek için sıralı tarihte uzlaşması gerekir.
Sorun zorluğunun kanıtı olarak, Bullshark'ın uygulanması, şu anda üretim ortamında bulunan uygulama dahil, bu özellikleri desteklememektedir.
Protokol
Yukarıda belirtilen zorluklara rağmen, bir atasözünde olduğu gibi, çözümlerin basitliğin arkasında gizli olduğu kanıtlanmıştır.
Shoal'da, DAG üzerinde yerel hesaplama yapabilme yeteneğine güveniyoruz ve önceki turların bilgilerini saklayıp yeniden yorumlama yeteneğini gerçekleştiriyoruz. Tüm doğrulayıcıların ilk sıralı ana nokta üzerindeki temel içgörüye katılmasıyla, Shoal birden fazla Bullshark örneğini sırayla birleştirerek onları sıralı işleme tabi tutuyor, bu nedenle ( ilk sıralı ana nokta, örneklerin geçiş noktasıdır ve ) ana noktasının nedensel tarihi liderin itibarını hesaplamak için kullanılır.
( akış hattı
V haritası vardır. Shoal, her bir örnekte F haritası tarafından önceden belirlenen bir bağlantı ile Bullshark örneklerini birer birer çalıştırır. Her örnek bir bağlantıyı sıralar ve bu, 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ı referans noktasını belirleyene kadar çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu referans noktasında hemfikirdi. Bu nedenle, tüm doğrulayıcılar r+1. turdan itibaren DAG'ı yeniden yorumlamayı güvenle kabul edebilirler. Shoal, sadece r+1. turda yeni bir Bullshark örneği başlattı.
En iyi durumda, bu, Shoal'a her turda bir çapa sıralama imkanı verir. İlk turdaki çapa noktaları, ilk örneğe göre sıralanır. Ardından, Shoal ikinci turda, kendinde bir çapa noktası olan yeni bir örnek başlatır; bu çapa, o örneğe göre sıralanır, ardından üçüncü turda başka bir yeni örnek çapa noktasını sıralar ve bu süreç devam eder.
Bullshark sıralama sırasında sabit noktaları atladığınızda, gecikme süresi artar. Bu durumda, önceki örnek sıralama sabit noktasından önce yeni bir örneğin başlatılması mümkün olmadığı için, hatırlama teknolojisi etkisizdir. Shoal, her doğrulama düğümünün son etkinlik geçmişine dayalı olarak her doğrulama düğümüne bir puan atayarak, gelecekte kaybolan sabit noktaları işlemek için ilgili liderlerin seçilme olasılığının daha düşük olmasını sağlamak için bir itibar mekanizması kullanır. Protokole yanıt veren ve katılan doğrulayıcılar yüksek puan alacak, aksi takdirde doğrulama düğümleri çökebilir, yavaşlayabilir veya kötü niyetli olabilir, bu nedenle düşük puan alacaklardır.
Felsefesi, her puan güncellemesinde, daha yüksek puana sahip liderlere doğru bir şekilde yönlendirilmiş, tura göre liderlere önceden tanımlanmış F haritalarını yeniden hesaplamaktır. Doğrulayıcıların yeni harita üzerinde uzlaşabilmesi için, puan üzerinde uzlaşmaları ve böylece puan türetiminde kullanılan geçmiş üzerinde de uzlaşmaları gerekir.
Shoal'da, akış şeması ve liderlik itibarı doğal olarak birleşebilir, çünkü her ikisi de ilk sıralı bağlantı noktasında uzlaşma sağlandıktan sonra DAG'ı yeniden yorumlamak için aynı çekirdek teknolojiyi kullanır.
Aslında, tek fark, r. turda ankrajların sıralanmasından sonra, doğrulayıcıların sadece r. turda sıralı ankrajları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ş ankraj seçim fonksiyonu F' ile Bullshark'ın yeni örneğini gerçekleştirir.
![Bin kelimelik Shoal çerçevesi: Aptos üzerindeki Bullshark gecikme süresini nasıl azaltabiliriz?]###https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
) Daha fazla gecikme süresi yok
Zaman aşımı, lider tabanlı belirleyici parçalı senkron 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özlemlenebilirlik teknikleri gerektirmektedir.
Timeout aynı zamanda gecikmeyi de ö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 liderine geçmeden önce arızalı lider için tam süre 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
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.
11 Likes
Reward
11
8
Share
Comment
0/400
CryptoGoldmine
· 16h ago
%80 gecikme süresi optimizasyonu teknik olarak mükemmel maliyet-fayda oranına yakın.
View OriginalReply0
just_here_for_vibes
· 07-27 18:20
Bu kadar performans artışı mı? Hadi bakalım.
View OriginalReply0
BridgeNomad
· 07-26 20:35
hmm... iyileştirilmiş gecikme süresi iyi görünüyor ama dürüst olmak gerekirse bu güven vektörlerini hala doğrulamam gerekiyor
View OriginalReply0
BearMarketHustler
· 07-26 20:30
Vay canına, Aptos gerçekten yetenekli!
View OriginalReply0
Whale_Whisperer
· 07-26 20:28
Bu geliştirme harika! Önce biraz apt biriktireyim.
View OriginalReply0
CryptoMotivator
· 07-26 20:17
Aptos gogo~gecikme süresi %80 gerçekten etkileyici
View OriginalReply0
StakeHouseDirector
· 07-26 20:17
pro ah bu performans optimizasyonu gerçekten harika
View OriginalReply0
Layer2Observer
· 07-26 20:08
gecikme süresi %80 artırmak biraz sert çekirdek. Test verilerini dört gözle bekliyorum.
Shoal çerçevesi, Aptos on-chain Bullshark gecikme süresini büyük ölçüde düşürdü.
Shoal çerçevesi: Aptos'ta Bullshark'ın düşüşünü nasıl azaltır
Aptos laboratuvarları, DAG BFT'deki iki önemli açık sorunu çözdü, gecikme süresini büyük ölçüde düşürdü ve deterministik gerçek protokoller için zaman aşımı gereksinimini ilk kez ortadan kaldırdı. Genel olarak, Shoal çerçevesi, hatasız durumlarda Bullshark'ın gecikme süresini %40 oranında iyileştirirken, arızalı durumlarda %80 oranında iyileştirdi.
Shoal, DAG-Rider, Tusk, Bullshark ( gibi çerçevelerin temelinde yer alan Narwhal tabanlı konsensüs protokolünü, akış hatları ve liderlerin itibarını kullanarak geliştiren bir sistemdir. Akış hattı, her turda bir referans noktası tanıtarak DAG sıralama gecikmesini azaltır, liderlerin itibarı 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, liderlerin itibarı, Shoal'ın tüm senaryolarda zaman aşımını ortadan kaldırmak için asenkron DAG yapısını kullanmasına olanak tanır. Bu, Shoal'ın genellikle gerekli olan iyimser yanıtları içeren evrensel yanıt olarak adlandırdığımız özelliği sunmasını sağlar.
Shoal'un teknolojisi oldukça basittir, bu, alt protokollerin birden fazla örneğini sırayla çalıştırmayı içerir. Bu nedenle, Bullshark örneği kullanıldığında, bir grup "köpekbalığı" bayrak yarışı yapar.
![万字详解Shoal框架:如何减少Aptos上的Bullshark gecikme süresi?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Arka Plan
Blok zinciri ağlarının yüksek performansını hedeflerken, insanlar iletişim karmaşıklığını azaltmaya odaklandılar. Ancak, bu yöntem önemli bir düşüşe yol açmadı. Örneğin, erken sürüm Diem'de uygulanan Hotstuff yalnızca 3500 TPS gerçekleştirdi, bu da 100k+ TPS hedefinin oldukça altında.
Son zamanlardaki突破, veri iletiminin liderlik protokollerine dayanan ana darboğaz olduğunu ve paralelleşmeden faydalanabileceğini anlamaktan kaynaklandı. Narwhal sistemi, veri iletimini ana 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 daha az miktarda meta veriyi sıraladığı bir mimari önerdi. Narwhal belgesi, 160.000 TPS'lik bir throughput bildirmektedir.
Aptos daha önce Quorum Store'u tanıttı, bu onların Narwhal uygulaması, veri yayılımını konsensüsten ayırıyor ve mevcut konsensüs protokolü Jolteon'u ölçeklendirmek için kullanılıyor. Jolteon, Tendermint'in lineer hızlı yolu ile PBFT tarzı görünüm değişikliklerini birleştiren lider tabanlı bir protokoldür ve Hotstuff'un gecikmesini %33 oranında düşürür. Ancak, lider tabanlı konsensüs protokolleri Narwhal'ın verimlilik potansiyelinden tam olarak yararlanamaz. Veri yayılımı ile konsensüsü ayırmış olmasına rağmen, verimlilik arttıkça Hotstuff/Jolteon'un liderleri hala sınırlıdır.
Bu nedenle, Aptos, Narwhal DAG üzerinde, sıfır iletişim maliyetine sahip bir konsensüs protokolü olan Bullshark'ı dağıtmaya karar verdi. Ne yazık ki, Jolteon ile karşılaştırıldığında, Bullshark yüksek throughput'u destekleyen DAG yapısı %50 gecikme süresi maliyeti getirdi.
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 tepe noktası bir tur ile ilişkilidir. r. tura girmek için, doğrulayıcıların öncelikle r-1. tura ait n-f tepe noktasını elde etmeleri gerekir. Her doğrulayıcı her turda bir tepe noktası yayınlayabilir, her tepe noktası en az bir önceki turdaki n-f tepe noktasını referans almalıdır. Ağın asenkron olması nedeniyle, 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 değildir: Eğer iki doğrulayıcı düğüm, DAG'larının yerel görünümünde aynı tepe noktası v'ye sahipse, o zaman v'nin nedensel geçmişi tamamen aynıdır.
![Shoal çerçevesinin detaylı açıklaması: Aptos'taki Bullshark gecikme süresini nasıl azaltırız?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Genel Sıralama
DAG'daki tüm düğümlerin toplam sırasının ekstra iletişim maliyeti olmadan uzlaşmaya varılması mümkündür. 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, kenarlar ise oylamayı temsil eder.
DAG yapısındaki grup kesişim mantığı farklı olsa da, mevcut tüm Narwhal tabanlı konsensüs protokolleri aşağıdaki yapıya sahiptir:
belirlenen referans noktası: Her birkaç turda ), Bullshark'taki iki turda ( önceden belirlenmiş bir lider olacak, liderin zirvesine referans noktası denir.
sıralama bağlantı noktası: doğrulayıcılar bağımsız fakat kesin bir şekilde hangi bağlantı noktalarının sıralanacağına ve hangi bağlantı noktalarının atlanacağına karar verir.
sıralama nedensellik geçmişi: doğrulayıcılar, sıralı bağlam listelerini birer birer işler ve her bağlam için, nedensellik geçmişlerinde daha önceki düzensiz noktaları bazı belirleyici kurallara göre sıralar.
Güvenliğin sağlanmasının anahtarı, yukarıdaki adımda )2(, tüm dürüst doğrulayıcı düğümlerin ortak bir ön ek paylaşması için sıralı bir referans noktası listesi oluşturduğundan emin olmaktır. Shoal'da, yukarıdaki tüm protokollerle ilgili şu gözlemler yapılmıştır:
Tüm doğrulayıcılar ilk sıralı bağlantıyı kabul eder.
![万字详解Shoal框架:如何减少Aptos上的Bullshark gecikme süresi?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Bullshark gecikme süresi
Bullshark'ın gecikme süresi, DAG'daki sıralı ana noktalar arasındaki döngü sayısına bağlıdır. Bullshark'ın en kullanışlı kısmi senkron versiyonu, asenkron versiyona göre daha iyi bir gecikmeye sahip olmasına rağmen, bu durumda en iyi değildir.
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. Yaygın durumlarda, referans noktalarını sıralamak için iki tur DAG gereklidir, ancak referansın nedensel geçmişindeki zirvelerin referansın sıralanmasını beklemek için daha fazla tura ihtiyacı vardır. Yaygın durumlarda, tek turdaki zirvelerin üç tura, çift turdaki referans olmayan zirvelerin ise dört tura ihtiyacı vardır.
Soru 2: Arıza durumu gecikmesi, yukarıdaki gecikme analizi arıza durumu olmayan durumlar için geçerlidir. Öte yandan, eğer bir turdaki lider yeterince hızlı bir şekilde referans noktalarını yayınlayamazsa, referans noktaları sıralanamaz ve 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 düşürür, özellikle de lideri beklemek için kullanılan Bullshark zaman aşımı nedeniyle.
Shoal çerçevesi
Shoal, bu iki gecikme süresini çözdü, Bullshark( veya diğer Narwhal tabanlı BFT protokolleri) üzerinde bir boru hattı ile güçlendirdi, 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ı tanıttı, bu da seçimlerin hızlı liderlere yönelmesini sağladı.
Mücadele
DAG protokolü bağlamında, boru hattı ve liderin itibarı zor bir sorun olarak kabul edilmektedir, sebepleri ise şunlardır:
1( Önceki üretim hattı, temel Bullshark mantığını değiştirmeye çalıştı, ancak bu temelde imkansız gibi görünüyor.
Sorun zorluğunun kanıtı olarak, Bullshark'ın uygulanması, şu anda üretim ortamında bulunan uygulama dahil, bu özellikleri desteklememektedir.
Protokol
Yukarıda belirtilen zorluklara rağmen, bir atasözünde olduğu gibi, çözümlerin basitliğin arkasında gizli olduğu kanıtlanmıştır.
Shoal'da, DAG üzerinde yerel hesaplama yapabilme yeteneğine güveniyoruz ve önceki turların bilgilerini saklayıp yeniden yorumlama yeteneğini gerçekleştiriyoruz. Tüm doğrulayıcıların ilk sıralı ana nokta üzerindeki temel içgörüye katılmasıyla, Shoal birden fazla Bullshark örneğini sırayla birleştirerek onları sıralı işleme tabi tutuyor, bu nedenle ( ilk sıralı ana nokta, örneklerin geçiş noktasıdır ve ) ana noktasının nedensel tarihi liderin itibarını hesaplamak için kullanılır.
( akış hattı
V haritası vardır. Shoal, her bir örnekte F haritası tarafından önceden belirlenen bir bağlantı ile Bullshark örneklerini birer birer çalıştırır. Her örnek bir bağlantıyı sıralar ve bu, 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ı referans noktasını belirleyene kadar çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu referans noktasında hemfikirdi. Bu nedenle, tüm doğrulayıcılar r+1. turdan itibaren DAG'ı yeniden yorumlamayı güvenle kabul edebilirler. Shoal, sadece r+1. turda yeni bir Bullshark örneği başlattı.
En iyi durumda, bu, Shoal'a her turda bir çapa sıralama imkanı verir. İlk turdaki çapa noktaları, ilk örneğe göre sıralanır. Ardından, Shoal ikinci turda, kendinde bir çapa noktası olan yeni bir örnek başlatır; bu çapa, o örneğe göre sıralanır, ardından üçüncü turda başka bir yeni örnek ç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-859e732e16c3eee0e2c93422474debc2.webp(
) lider itibarı
Bullshark sıralama sırasında sabit noktaları atladığınızda, gecikme süresi artar. Bu durumda, önceki örnek sıralama sabit noktasından önce yeni bir örneğin başlatılması mümkün olmadığı için, hatırlama teknolojisi etkisizdir. Shoal, her doğrulama düğümünün son etkinlik geçmişine dayalı olarak her doğrulama düğümüne bir puan atayarak, gelecekte kaybolan sabit noktaları işlemek için ilgili liderlerin seçilme olasılığının daha düşük olmasını sağlamak için bir itibar mekanizması kullanır. Protokole yanıt veren ve katılan doğrulayıcılar yüksek puan alacak, aksi takdirde doğrulama düğümleri çökebilir, yavaşlayabilir veya kötü niyetli olabilir, bu nedenle düşük puan alacaklardır.
Felsefesi, her puan güncellemesinde, daha yüksek puana sahip liderlere doğru bir şekilde yönlendirilmiş, tura göre liderlere önceden tanımlanmış F haritalarını yeniden hesaplamaktır. Doğrulayıcıların yeni harita üzerinde uzlaşabilmesi için, puan üzerinde uzlaşmaları ve böylece puan türetiminde kullanılan geçmiş üzerinde de uzlaşmaları gerekir.
Shoal'da, akış şeması ve liderlik itibarı doğal olarak birleşebilir, çünkü her ikisi de ilk sıralı bağlantı noktasında uzlaşma sağlandıktan sonra DAG'ı yeniden yorumlamak için aynı çekirdek teknolojiyi kullanır.
Aslında, tek fark, r. turda ankrajların sıralanmasından sonra, doğrulayıcıların sadece r. turda sıralı ankrajları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ş ankraj seçim fonksiyonu F' ile Bullshark'ın yeni örneğini gerçekleştirir.
![Bin kelimelik Shoal çerçevesi: Aptos üzerindeki Bullshark gecikme süresini nasıl azaltabiliriz?]###https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
) Daha fazla gecikme süresi yok
Zaman aşımı, lider tabanlı belirleyici parçalı senkron 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özlemlenebilirlik teknikleri gerektirmektedir.
Timeout aynı zamanda gecikmeyi de ö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 liderine geçmeden önce arızalı lider için tam süre 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