Aptos, Shoal çerçevesini tanıtarak Bullshark gecikmesini önemli ölçüde düşürmekte ve zaman aşımı gereksinimini ortadan kaldırmaktadır.

Aptos'ta Bullshark Gecikmesini Azaltma: Shoal Çerçevesinin Detayları

Aptos labları, DAG BFT'deki iki önemli açık sorunu çözdü, gecikmeyi büyük ölçüde azalttı ve ilk kez kesinlik sağlayan gerçek protokollerde duraklama gereksinimini ortadan kaldırdı. Genel olarak, hatasız durumlarda Bullshark'ın gecikmesini %40, arızalı durumlarda ise %80 oranında iyileştirdi.

Shoal çerçevesi, Narwhal tabanlı konsensüs protokolünü (, DAG-Rider, Tusk, Bullshark ) gibi güçlendirir. Her turda bir referans noktası tanıtarak DAG sıralama gecikmesini azaltan bir boru hattı kullanılır; liderin itibarı, referans noktalarının en hızlı doğrulama düğümleri ile ilişkilendirilmesini sağlar ve böylece gecikmeyi daha da iyileştirir. Ayrıca, liderin itibarı, Shoal'un tüm senaryolarda zaman aşımını ortadan kaldırmak için asenkron DAG yapılarını kullanmasını sağlar, bu da evrensel yanıt verme özelliği sağlar.

Shoal'un teknolojisi oldukça basittir, temel protokollerin birden fazla örneğini sırayla çalıştırır. Bullshark ile örneklendiğinde, sanki bir bayrak yarışı yapan "köpekbalıkları" grubudur.

Tam açıklama Shoal çerçevesi: Aptos üzerindeki Bullshark gecikmesini nasıl azaltır?

Arka Plan

Blok zinciri ağlarının yüksek performansını hedeflerken, insanlar iletişim karmaşıklığını azaltmaya odaklandılar, ancak bu, önemli bir throughput artışına yol açmadı. Örneğin, erken Diiem'de uygulanan Hotstuff yalnızca 3500 TPS'e ulaşabildi ve bu, 100k+ TPS hedefine kıyasla çok düşük.

Son zamanlarda, veri yayılımının liderlik protokollerine dayanan ana darboğaz olduğunu anlamaktan kaynaklanan bir sıçrama yaşandı ve bu, paralelleşmeden fayda sağlayabilir. Narwhal sistemi, veri yayılımını çekirdek uzlaşma mantığından ayırır, tüm doğrulayıcılar aynı anda veri yayar, uzlaşma bileşeni yalnızca az miktarda meta veriyi sıralar. Narwhal makalesi, 160.000 TPS'lik bir iş hacmini rapor etmiştir.

Aptos, Quorum Store'u, yani Narwhal uygulamasını tanıttı; bu uygulama veri yayılımını konsensustan ayırır ve mevcut konsensüs protokolü Jolteon'u genişletmek için kullanılır. Jolteon, Tendermint'in lineer hızlı yolu ile PBFT tarzı görünüm değişikliklerini birleştirerek Hotstuff'un gecikmesini %33 oranında azaltır. Ancak, lider tabanlı konsensüs protokolleri, Narwhal'ın verimlilik potansiyelinden tam olarak yararlanamaz.

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, Bullshark yüksek throughput'u destekleyen DAG yapısı %50'lik bir gecikme maliyeti getirdi.

Bu makale, Shoal'un Bullshark gecikmesini nasıl önemli ölçüde azaltacağını tanıtmaktadır.

DAG-BFT Arka Planı

Narwhal DAG'daki her tepe, bir tur ile ilişkilidir. r. tura girmek için, doğrulayıcıların r-1. turdaki n-f tepesini elde etmesi gerekir. Her doğrulayıcı her turda bir tepe yayabilir, her tepe en az bir önceki turun n-f tepesine atıfta bulunmalıdır. Ağın asenkronluğu nedeniyle, farklı doğrulayıcılar 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ü yerel DAG görünümünde aynı tepe noktası v'ye sahipse, o zaman v'nin neden-sonuç geçmişi tamamen aynıdır.

Aptos'ta Bullshark gecikmesini nasıl azaltırız? Shoal çerçevesi hakkında detaylı açıklama

Genel Sıralama

DAG'daki tüm dorukların toplam sırasını ek iletişim maliyeti olmadan uzlaşmak mümkündür. DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar, DAG yapısını bir konsensüs protokolü olarak yorumlar; doruklar önerileri, kenarlar ise oylamayı temsil eder.

DAG yapısındaki topluluk kesişim mantığı farklı olsa da, Narwhal tabanlı tüm konsensüs protokolleri aşağıdaki yapıya sahiptir:

  1. Önceden belirlenmiş lider: Her birkaç turda, önceden belirlenmiş bir lider vardır, bu liderin zirvesine ise "açık nokta" denir.

  2. Sıralama Ankraj Noktaları: Doğrulayıcılar, hangi ankraj noktalarının sıralanacağına ve hangilerinin atlanacağına bağımsız ancak belirleyici bir şekilde karar verir.

  3. Nedensellik Tarihini Sıralama: Doğrulayıcılar, her bir ankraj noktasının nedensellik tarihindeki önceki düzensiz zirveleri sıralamak için sıralı ankraj noktaları listesini teker teker işler.

Güvenliğin sağlanmasının anahtarı, adım (2)'de, tüm dürüst doğrulayıcı düğümleri tarafından oluşturulan sıralı anahtar listesinin aynı ön eki paylaşmasını sağlamaktır. Shoal'da, gözlemlediğimiz:

Tüm doğrulayıcılar ilk sıralı referansı kabul eder.

Bullshark Gecikmesi

Bullshark'ın gecikmesi, DAG'daki sıralı sabit noktalar arasındaki döngü sayısına bağlıdır. Kısmi senkronizasyon sürümlerinin gecikmesi, asenkron sürümlere göre daha iyidir, ancak yine de en iyi değildir.

Soru 1: Ortalama blok gecikmesi. Bullshark'ta, her çift turda bir ana nokta vardır, tek turda ise zirve oylama olarak yorumlanır. Genel durumlarda, ana noktaları sıralamak için iki tur DAG gereklidir, ancak ana noktanın nedensel tarihindeki zirvelerin sıralanmasını beklemek için daha fazla tura ihtiyaç vardır. Genel durumlarda, tek tur zirvelerinin üç tura, çift tur ana nokta olmayan zirvelerinin ise dört tura ihtiyacı vardır.

Soru 2: Arıza durumu gecikmesi. Eğer bir lider turu zamanında referans noktasını yayamazsa, ( sıralanamaz ve ), önceki turlardaki sıralanmayan tüm tepe noktaları, bir sonraki referans noktasının sıralanmasını beklemek zorundadır. Bu, özellikle Bullshark liderin zaman aşımını beklemesi nedeniyle, coğrafi kopyalama ağının performansını önemli ölçüde düşürmektedir.

Binlerce kelime ile Shoal çerçevesi: Aptos'taki Bullshark gecikmesini nasıl azaltır?

Shoal çerçevesi

Shoal, Bullshark( veya herhangi bir Narwhal tabanlı BFT protokolünü ) güçlendiren bir üretim hattı aracılığıyla, her turda bir referans noktası olmasını sağlar ve DAG'daki tüm referans noktası olmayan düğümlerin gecikmesini üç tura indirir. Shoal ayrıca DAG'da sıfır maliyetli bir lider güven mekanizması tanıtarak hızlı liderlerin seçilmesine öncelik verir.

meydan okuma

DAG protokolünde, boru hattı ve liderin itibarı zorlu sorunlar olarak kabul edilmektedir, nedenleri şunlardır:

  1. Önceki üretim hattı, temel Bullshark mantığını değiştirmeyi denedi, ancak bu temelde mümkün gibi görünmüyor.

  2. Liderlerin itibarı DiemBFT'ye entegre edilmiş ve Carousel'de resmileştirilmiştir. Geçmiş performanslarına göre dinamik olarak gelecekteki liderleri seçmek için (Bullshark'taki çapa ). Lider kimliğindeki farklılıklar bu protokollerin güvenliğini ihlal etmemesine rağmen, Bullshark'ta tamamen farklı bir sıralama ile sonuçlanabilir. Bu, sorunun özünü ortaya koyar: dinamik ve belirleyici bir şekilde çapa seçmek, konsensüsü çözmek için gereklidir; doğrulayıcıların gelecekteki çapayı seçmek için sıralı tarih üzerinde uzlaşmaları gerekir.

Bir sorun zorluğunun kanıtı olarak, Bullshark'ın uygulaması (, mevcut üretim ortamındaki )'in bu özellikleri desteklemediğini göstermektedir.

Protokol

Yukarıda belirtilen zorluklara rağmen, çözüm basitlikte gizlidir.

Shoal, DAG üzerinde yerel hesaplama yeteneğine dayanarak, önceki turların bilgilerini saklama ve yeniden yorumlama yeteneğini gerçekleştirdi. Tüm doğrulayıcıların ilk sıralı referans noktasının içgörüsünde hemfikir olması temelinde, Shoal, bir dizi Bullshark örneğini ardışık işleme almak için sıralı bir şekilde birleştirir, böylece ( ilk sıralı referans noktası örneklerin geçiş noktasıdır, ) referans noktasının nedensel geçmişi liderlik kredibilitesini hesaplamak için kullanılır.

( montaj hattı

V haritası vardır. Shoal, her bir örneğin sabit noktasının F haritası ile önceden belirlendiği Bullshark örneklerini sıralı bir şekilde çalıştırır. Her bir örnek bir sabit nokta sıralar ve bir sonraki örneğe geçişi tetikler.

İlk olarak, Shoal, DAG'ın ilk aşamasında Bullshark'ın ilk örneğini başlattı ve ilk sıralı ankraj noktası ) belirlendiği güne kadar çalıştı, bu da r. aşaması ### olarak belirlendi. Tüm doğrulayıcılar bu ankraj noktasında hemfikir oldu, bu nedenle r+1. aşamadan itibaren DAG'ın yeniden yorumlanmasında kesin bir şekilde hemfikir olunabilir. Shoal, r+1. aşamada yeni bir Bullshark örneğini başlattı.

En iyi durumda, bu Shoal'ın her turda bir çivi sıralamasına izin verir. İlk tur çivisi ilk örnek tarafından sıralanır. Sonra, Shoal ikinci turda yeni bir örnek başlatır, kendi çivisi vardır ve o örnek tarafından sıralanır, sonra üçüncü turda başka bir yeni örnek çivi sıralar, bu şekilde devam eder.

Shoal çerçevesinin detaylı açıklaması: Aptos'taki Bullshark gecikmesini nasıl azaltırız?

( Lider Güvencesi

Bullshark sıralaması, ana noktalardan atladığında, gecikme artar. Bu durumda, boru hattı çaresizdir, çünkü yeni bir örneği başlatmak, önceki örneğin ana noktasının sıralanmasından önce mümkün değildir. Shoal, her doğrulayıcı düğümüne, en son etkinlik tarihine göre, kaybolan ana noktaları işlemek için liderlerin gelecekte seçilme olasılığının daha düşük olmasını sağlamak üzere bir puan atar. Protokole yanıt veren ve katılan doğrulayıcılar yüksek puan alırken, aksi takdirde düşük puan alırlar. ) çökebilir, yavaşlayabilir veya kötü niyetli olabilir ###.

İlkeler, her puan güncellemesinde, yüksek puan liderlerine yönelik olarak, tura liderine kadar önceden tanımlanmış F haritalamasını kesin olarak yeniden hesaplamaktır. Doğrulayıcıların yeni harita üzerinde uzlaşabilmesi için, puan üzerinde uzlaşmaları ve böylece türetilen puanların tarihine uyum sağlamaları gerekmektedir.

Shoal'da, hatlar ve liderlerin itibarı doğal olarak birleşir, çünkü aynı temel teknolojiyi kullanırlar: ilk sıralı sabit noktada uzlaşma sağlandıktan sonra DAG'ı yeniden yorumlamak.

Tek fark, r. tur sıralama referans noktasından sonra, doğrulayıcıların r. tur sıralı referans noktalarının neden-sonuç geçmişine dayanarak, r+1. turdan itibaren yeni bir eşleme F' hesaplamasıdır. Ardından, doğrulama düğümleri r+1. turdan itibaren güncellenmiş referans noktası seçim fonksiyonu F' kullanarak Bullshark'ın yeni örneğini yürütür.

Binlerce kelimeyle Shoal çerçevesi: Aptos üzerindeki Bullshark gecikmesini nasıl azaltır?

( Daha fazla zaman aşımına gerek yok

Lider temelli belirleyici kısmi senkron BFT uygulamalarında zaman aşımı kritik öneme sahiptir. Ancak, bunların getirdiği karmaşıklık, yönetilmesi ve gözlemlenmesi gereken iç durum sayısını artırarak hata ayıklama sürecinin karmaşıklığını artırmakta ve daha fazla gözlemlenebilirlik teknolojisi gerektirmektedir.

Zaman aşımı aynı zamanda gecikmeleri de önemli ölçüde artırır, çünkü bunların uygun şekilde yapılandırılması önemlidir, genellikle dinamik ayarlamalar gerektirir ve çevreye yüksek derecede bağımlıdır ) ağ ###. Bir sonraki liderine geçmeden önce, protokol başarısız olan lider için tam zaman aşımı gecikme cezası öder. Bu nedenle, zaman aşımı ayarları çok temkinli olmamalıdır, ancak çok kısa olursa, protokol iyi bir lideri atlayabilir. Örneğin, yüksek yük altında, Jolteon/Hotstuff içindeki liderin aşırı yüklendiğini ve ilerlemeyi sağlamadan önce zaman aşımının sona erdiğini gözlemledik.

Ne yazık ki, liderin protokolü ( gibi Hotstuff ve Jolteon) esasen zaman aşımını gerektirir, böylece her lider arızalandığında protokol ilerleyebilir. Zaman aşımı olmadan, çökme yaşayan bir lider bile protokolü sonsuza dek durdurabilir. Asenkron dönemlerde arızalı ve yavaş liderleri ayırt edemediğimizden, zaman aşımı doğrulayıcı düğümlerin tüm liderlerde konsensüs aktifliği olmadan değişikliklere bakmasına neden olabilir.

Bullshark'ta, DAG yapısı için zaman aşımı kullanılır, böylece senkronizasyon sırasında dürüst liderlerin, DAG'a eklenen sabit noktaları sıralamak için yeterince hızlı bir şekilde eklemeleri sağlanır.

DAG yapısının ağ hızını tahmin eden bir "saat" sağladığını gözlemledik. Kesinti olmadan, n-f kadar dürüst doğrulayıcı DAG'a tepe eklemeye devam ettiği sürece, turlar ilerlemeye devam edecektir. Bullshark, liderlik sorunları nedeniyle ( ağ hızında sıralama yapamasa da, DAG bazı liderlerin sorunları veya ağın asenkron olmasına rağmen ağ hızında büyümeye devam etmektedir. Sonunda, hatasız liderler yeterince hızlı bir şekilde bağ noktalarını yaydığında, bağ noktasının tüm nedensel geçmişi sıralanacaktır.

Değerlendiriliyor, Bullshark'ın aşağıdaki durumlarda zaman aşımına uğrayıp uğramadığını karşılaştırdık:

  1. Hızlı lider, en azından diğer doğrulayıcılardan daha hızlıdır. Bu durumda, iki yöntem de aynı gecikmeyi sağlar, çünkü çapa sıralıdır ve zaman aşımı kullanmaz.

  2. Yanlış liderler, bu durumda duraksamayan Bullshark daha iyi gecikme sağlar, çünkü doğrulama düğümleri hemen ankraj noktalarını atlayacakken, duraksayan doğrulayıcılar devam etmeden önce bunların süresinin dolmasını bekleyecektir.

  3. Yavaş liderler, Bullshark'ın zaman aşımı performansının daha iyi olduğu tek durumdur. Çünkü duraksama olmadığında, lider yeterince hızlı yayın yapamadığı için referans noktası atlanabilir, ancak duraksama olduğunda, doğrulayıcılar referans noktasını bekleyecektir.

Shoal'da, zaman aşımını ve liderin itibarını önlemek önemlidir. Tekrar beklemek

APT-2.69%
View Original
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.
  • Reward
  • 8
  • Share
Comment
0/400
MevWhisperervip
· 4h ago
Optimizasyon artırma çok etkili.
View OriginalReply0
MEVictimvip
· 16h ago
Optimizasyon verimliliği önemli ölçüde artırdı
View OriginalReply0
LiquidationWatchervip
· 16h ago
Performans optimizasyonu oldukça etkili
View OriginalReply0
FarmHoppervip
· 16h ago
Aptos gerçekten çok sağlam!
View OriginalReply0
OfflineValidatorvip
· 16h ago
Teknoloji insanlığa fayda sağlar
View OriginalReply0
PortfolioAlertvip
· 16h ago
Veri destekleme iyileştirmesi
View OriginalReply0
CompoundPersonalityvip
· 16h ago
Aptos çok iyi.
View OriginalReply0
NewPumpamentalsvip
· 16h ago
Aptos büyük güncellemesi
View OriginalReply0
  • Pin
Trade Crypto Anywhere Anytime
qrCode
Scan to download Gate app
Community
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)