Shoal çerçevesi: Aptos'ta Bullshark'ın düşüşünü nasıl azaltırız
Aptos Labs, son zamanlarda DAG BFT'deki iki önemli açık sorunu çözdü, gecikmeyi büyük ölçüde düşürdü ve ilk kez belirleyici gerçek protokolde zaman aşımı gereksinimini ortadan kaldırdı. Genel olarak, hatasız durumlarda Bullshark'ın gecikmesini %40, hatalı durumlarda ise %80 oranında iyileştirdi.
Shoal, Narwhal tabanlı konsensüs protokollerini, örneğin DAG-Rider, Tusk, Bullshark gibi, (, herhangi bir çerçeveyi güçlendirmek için bir sistemdir. Akış şeması, her turda bir referans noktası ekleyerek DAG sıralama gecikmesini azaltır, liderin itibarı ise referans noktalarının en hızlı doğrulayıcı düğümlerle ilişkili olmasını sağlayarak gecikme sorununu daha da geliştirir. Ayrıca, liderin 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 gereken iyimser yanıtları içeren evrensel yanıt adı verilen bir özellik 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 örneklendirildiğinde, "köpekbalıkları" olan bir grup bayrak yarışı yapmaktadır.
Blockchain ağlarının yüksek performansını hedeflerken, insanlar iletişim karmaşıklığını azaltmaya odaklandılar. Ancak, bu yöntem önemli ölçüde bir düşüşe yol açmadı. Örneğin, erken sürümlerdeki Diem'de uygulanan Hotstuff yalnızca 3500 TPS gerçekleştirdi, bu da 100k+ TPS hedefine kıyasla çok daha düşük.
Son zamanlardaki atılım, veri yayılımının liderlerin protokollerine dayanan ana darboğaz olduğunu anlamaktan kaynaklanıyor ve bunun paralelleşmeden faydalanabileceği ortaya çıkıyor. 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 miktarda meta veriyi sıraladığı bir mimari öneriyor. Narwhal belgesi, 160,000 TPS'lik bir verimlilik bildirmektedir.
Daha önceki yazılarda, Narwhal'ın veri yayılımını ve konsensüsü ayıran uygulaması olan Quorum Store'dan bahsedilmiştir ve bunun mevcut konsensus protokolü Jolteon'u nasıl ölçeklendirebileceği ele alınmıştır. Jolteon, Tendermint'in lineer hızlı yolunu ve PBFT tarzı görünüm değişikliklerini birleştiren lider tabanlı bir protokoldür ve Hotstuff'un gecikmesini %33 oranında düşürmektedir. Ancak, lider tabanlı konsensüs protokolleri, Narwhal'ın işleme potansiyelinden yeterince faydalanamamaktadır. Veri yayılımını ve konsensüsü ayırmış olsalar da, işleme arttıkça Hotstuff/Jolteon'un liderleri hala sınırlıdır.
Bu nedenle, Bullshark'ı, sıfır iletişim maliyetine sahip bir konsensüs protokolü olan Narwhal DAG'ın üzerine dağıtmayı karar verdik. Ne yazık ki, Jolteon'a kıyasla, Bullshark yüksek throughput'u destekleyen DAG yapısı %50'lik bir düşüş maliyeti getirdi.
Bu makale, Shoal'un Bullshark gecikme süresini nasıl büyük ölçüde azaltacağını açıklamaktadı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 önce r-1. turda bulunan n-f tepe noktasını elde etmeleri gerekir. Her doğrulayıcı her turda bir tepe noktası yayınlayabilir ve her tepe noktası en az bir önceki turdaki n-f tepe noktasını referans almalıdır. Ağın asenkronluğu nedeniyle, farklı doğrulayıcılar herhangi bir zamanda DAG'ın farklı yerel görüntülerini 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ümünde aynı v tepe noktasına sahipse, o zaman tamamen aynı v nedensel geçmişine sahiptirler.
DAG'daki tüm düğümlerin toplam sırasını ek iletişim maliyeti olmadan uzlaşmaya varmak mümkündür. Bunun için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar DAG yapısını bir uzlaşma protokolü olarak yorumlar; burada düğümler önerileri, 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 belirlenmiş lider: Belirli aralıklarla önceden belirlenmiş bir lider olacak, liderin zirvesine ise ankraj noktası denir;
Sıralama Ankraj Noktası: Doğrulayıcılar bağımsız ancak belirli bir şekilde hangi ankraj noktalarının sıralanacağına ve hangi ankraj noktalarının atlanacağına karar verir.
Nedensel Tarihin Sıralanması: Doğrulayıcılar, sıralı çakışma noktası listesini birer birer işler ve her çakışma noktası için, belirli kurallar aracılığıyla 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ğrulama düğümlerinin ortak bir ön ek paylaşabilmesi için sıralı bir referans noktası listesi oluşturduklarından emin olmaktır. Shoal'da, tüm protokoller hakkında aşağıdaki gözlemler yapılmıştır:
Tüm doğrulayıcılar ilk sıralı referans noktasında hemfikirdir.
Bullshark gecikme süresi
Bullshark'ın gecikme süresi, DAG'daki sıralı anahtar noktaları arasındaki turların sayısına bağlıdır. Bullshark'ın en kullanışlı kısmi senkron versiyonu, asenkron versiyondan daha iyi bir gecikmeye sahip olmasına rağmen, en iyi olanı değildir.
Soru 1: Ortalama blok gecikmesi. Bullshark'ta, her çift turda bir ana nokta vardır, her tek turda ise zirve oy verme olarak yorumlanır. Yaygın durumlarda, ana noktaların sıralanması için iki tur DAG gereklidir, ancak ana noktanın nedensel tarihindeki zirvelerin sıralanması için daha fazla tura ihtiyaç vardır. Yaygın durumlarda, tek turdaki zirveler üç tura, çift turdaki ana nokta olmayan zirveler ise dört tura ihtiyaç duyar.
Soru 2: Arıza durumu gecikmesi, yukarıdaki gecikme analizi arızasız durumlar için geçerlidir, öte yandan, eğer bir turdaki lider yeterince hızlı bir şekilde referans noktasını yayınlayamazsa, referans noktası sıralanamaz ) bu yüzden atlanır (, bu nedenle önceki turlardaki sıralanmamış tüm zirveler, 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üşürecektir, özellikle Bullshark zaman aşımı lideri beklemek için kullanıldığı için.
Shoal, bu iki gecikme süresi sorununu çözdü; Bullshark) veya diğer herhangi bir Narwhal tabanlı BFT protokolünü (, her turda bir referans noktası olmasına olanak tanıyarak ve DAG'daki tüm referans noktası olmayan düğümlerin gecikme süresini üç tura düşürerek, ardışık olarak güçlendirdi. Shoal ayrıca DAG'da sıfır maliyetli lider itibar mekanizması getirdi, bu da seçimlerin hızlı liderlere yönelmesini sağladı.
Mücadele
DAG protokolü bağlamında, boru hattı ve liderin itibarı zor sorunlar olarak kabul edilmektedir, sebepleri şunlardır:
Önceki akış şeması, 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 farklılıkların bu protokollerin güvenliğini ihlal etmemesi söz konusu olsa da, Bullshark'ta bu tamamen farklı bir sıralamaya yol açabilir. Bu, sorunların kalbini ortaya çıkarır; yani, dinamik ve belirleyici bir şekilde döngü çapa seçimi, konsensüsün sağlanması için gereklidir ve doğrulayıcıların gelecekteki çapa seçmek için sıralı tarih üzerinde anlaşmaları gerekir.
Sorun zorluğunun kanıtı olarak, Bullshark'ın uygulaması, şu anda üretim ortamında bulunan uygulamalar dahil, bu özellikleri desteklememektedir.
Protokol
Yukarıda belirtilen zorluklara rağmen, çözümün basitliğin ardında gizli olduğu kanıtlanmıştır.
Shoal'da, DAG üzerinde yerel hesaplama yapma yeteneğine dayanarak, önceki turların bilgilerini saklama ve yeniden yorumlama yeteneği gerçekleştirilmiştir. Tüm doğrulayıcıların ilk sıralı sabit nokta konusunda hemfikir olduğu temel içgörü ile, Shoal birden fazla Bullshark örneğini sırayla birleştirip bunları önce işlemeye tabi tutarak, ) ilk sıralı sabit nokta örneklerin geçiş noktasıdır ve ( sabit noktasının nedensel tarihi liderin itibarını hesaplamak için kullanılır.
V vardır. Shoal, Bullshark'ın örneklerini birer birer çalıştırır, böylece her örnek için, ankranın F eşlemesi ile önceden belirlenmiştir. Her örnek bir ankra siparişi verir, 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ı bağlantıyı belirleyene kadar çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu bağlantıyı kabul etti. Bu nedenle, tüm doğrulayıcılar r+1. turdan itibaren DAG'ı yeniden yorumlamayı kesin olarak kabul edebilir. Shoal sadece r+1. turda yeni bir Bullshark örneği başlattı.
En iyi durumda, bu, Shoal'in her turda bir çapa sipariş etmesine olanak tanır. İlk turdaki çapa noktaları, ilk örneğe göre sıralanır. Daha sonra, 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. Ardından, üçüncü turda başka bir yeni örnek çapa noktası sipariş eder ve süreç devam eder.
Bullshark sıralama sırasında ankraj noktalarını atladığınızda, gecikme süresi artar. Bu durumda, pipeline teknolojisi etkisizdir, çünkü yeni bir örneği başlatmak, önceki örnek ankraj noktası sipariş edilmeden mümkün değildir. Shoal, her bir doğrulama düğümünün son faaliyet geçmişine dayalı olarak her bir doğrulama düğümüne bir puan atayarak, gelecekte kaybolan ankraj noktalarını işlemek için ilgili liderlerin seçilme 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 alacak, çünkü çökme, yavaşlama veya kötüye kullanma durumu olabilir.
Felsefesi, her puan güncellemesinde, yüksek puanlı liderlere eğilimli olan, turlar ile liderler arasındaki önceden tanımlanmış F haritalarını belirli bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni haritalar üzerinde uzlaşabilmeleri için puanlar üzerinde uzlaşmaları, böylece türetilen puanların tarihi üzerinde uzlaşmaları gerekir.
Shoal'da, akış hattı ve liderlik itibarı doğal olarak bir araya gelebilir, çünkü her ikisi de ilk sıralı sabit nokta üzerinde uzlaşma sağlandıktan sonra DAG'yi yeniden yorumlamak için aynı temel teknolojiyi kullanır.
Aslında tek fark, r. turda aygıtların sıralanmasından sonra, doğrulayıcının sadece r. turda sıralı aygıtların nedensel tarihine dayanarak r+1. turdan itibaren yeni eşleme F'yi hesaplaması gerektiğidir. Ardından, doğrulama düğümleri r+1. turdan itibaren güncellenmiş aygıt seçim fonksiyonu F'yi kullanarak Bullshark'ın yeni bir örneğini gerçekleştirir.
![Bin kelime ile Shoal çerçevesi: Aptos'taki Bullshark gecikmesini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
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, 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.
Zaman aşımı, uygun bir şekilde yapılandırılmasının çok önemli olduğu ve genellikle ortamdan yüksek ölçüde bağımlı olduğu için, gecikmeyi önemli ölçüde artırır ) ağ (. 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 koşullarında, Jolteon/Hotstuff'taki liderlerin aşırı yüklendiğini ve ilerlemeyi sağlamadan önce zaman aşımının süresinin dolduğunu gözlemledik.
Ne yazık ki, liderlere dayalı protokol ), Hotstuff ve Jolteon( gibi, her seferinde liderin doğrulanmasını sağlamak için temel olarak bir gecikme süresi gerektirir.
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.
Shoal çerçevesi, Aptos'taki Bullshark gecikme süresini %40-%80 oranında düşürdü.
Shoal çerçevesi: Aptos'ta Bullshark'ın düşüşünü nasıl azaltırız
Aptos Labs, son zamanlarda DAG BFT'deki iki önemli açık sorunu çözdü, gecikmeyi büyük ölçüde düşürdü ve ilk kez belirleyici gerçek protokolde zaman aşımı gereksinimini ortadan kaldırdı. Genel olarak, hatasız durumlarda Bullshark'ın gecikmesini %40, hatalı durumlarda ise %80 oranında iyileştirdi.
Shoal, Narwhal tabanlı konsensüs protokollerini, örneğin DAG-Rider, Tusk, Bullshark gibi, (, herhangi bir çerçeveyi güçlendirmek için bir sistemdir. Akış şeması, her turda bir referans noktası ekleyerek DAG sıralama gecikmesini azaltır, liderin itibarı ise referans noktalarının en hızlı doğrulayıcı düğümlerle ilişkili olmasını sağlayarak gecikme sorununu daha da geliştirir. Ayrıca, liderin 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 gereken iyimser yanıtları içeren evrensel yanıt adı verilen bir özellik 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 örneklendirildiğinde, "köpekbalıkları" olan bir grup bayrak yarışı yapmaktadır.
![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Arka Plan
Blockchain ağlarının yüksek performansını hedeflerken, insanlar iletişim karmaşıklığını azaltmaya odaklandılar. Ancak, bu yöntem önemli ölçüde bir düşüşe yol açmadı. Örneğin, erken sürümlerdeki Diem'de uygulanan Hotstuff yalnızca 3500 TPS gerçekleştirdi, bu da 100k+ TPS hedefine kıyasla çok daha düşük.
Son zamanlardaki atılım, veri yayılımının liderlerin protokollerine dayanan ana darboğaz olduğunu anlamaktan kaynaklanıyor ve bunun paralelleşmeden faydalanabileceği ortaya çıkıyor. 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 miktarda meta veriyi sıraladığı bir mimari öneriyor. Narwhal belgesi, 160,000 TPS'lik bir verimlilik bildirmektedir.
Daha önceki yazılarda, Narwhal'ın veri yayılımını ve konsensüsü ayıran uygulaması olan Quorum Store'dan bahsedilmiştir ve bunun mevcut konsensus protokolü Jolteon'u nasıl ölçeklendirebileceği ele alınmıştır. Jolteon, Tendermint'in lineer hızlı yolunu ve PBFT tarzı görünüm değişikliklerini birleştiren lider tabanlı bir protokoldür ve Hotstuff'un gecikmesini %33 oranında düşürmektedir. Ancak, lider tabanlı konsensüs protokolleri, Narwhal'ın işleme potansiyelinden yeterince faydalanamamaktadır. Veri yayılımını ve konsensüsü ayırmış olsalar da, işleme arttıkça Hotstuff/Jolteon'un liderleri hala sınırlıdır.
Bu nedenle, Bullshark'ı, sıfır iletişim maliyetine sahip bir konsensüs protokolü olan Narwhal DAG'ın üzerine dağıtmayı karar verdik. Ne yazık ki, Jolteon'a kıyasla, Bullshark yüksek throughput'u destekleyen DAG yapısı %50'lik bir düşüş maliyeti getirdi.
Bu makale, Shoal'un Bullshark gecikme süresini nasıl büyük ölçüde azaltacağını açıklamaktadı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 önce r-1. turda bulunan n-f tepe noktasını elde etmeleri gerekir. Her doğrulayıcı her turda bir tepe noktası yayınlayabilir ve her tepe noktası en az bir önceki turdaki n-f tepe noktasını referans almalıdır. Ağın asenkronluğu nedeniyle, farklı doğrulayıcılar herhangi bir zamanda DAG'ın farklı yerel görüntülerini 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ümünde aynı v tepe noktasına sahipse, o zaman tamamen aynı v nedensel geçmişine sahiptirler.
![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Toplam Sıra
DAG'daki tüm düğümlerin toplam sırasını ek iletişim maliyeti olmadan uzlaşmaya varmak mümkündür. Bunun için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar DAG yapısını bir uzlaşma protokolü olarak yorumlar; burada düğümler önerileri, 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 belirlenmiş lider: Belirli aralıklarla önceden belirlenmiş bir lider olacak, liderin zirvesine ise ankraj noktası denir;
Sıralama Ankraj Noktası: Doğrulayıcılar bağımsız ancak belirli bir şekilde hangi ankraj noktalarının sıralanacağına ve hangi ankraj noktalarının atlanacağına karar verir.
Nedensel Tarihin Sıralanması: Doğrulayıcılar, sıralı çakışma noktası listesini birer birer işler ve her çakışma noktası için, belirli kurallar aracılığıyla 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ğrulama düğümlerinin ortak bir ön ek paylaşabilmesi için sıralı bir referans noktası listesi oluşturduklarından emin olmaktır. Shoal'da, tüm protokoller hakkında aşağıdaki gözlemler yapılmıştır:
Tüm doğrulayıcılar ilk sıralı referans noktasında hemfikirdir.
Bullshark gecikme süresi
Bullshark'ın gecikme süresi, DAG'daki sıralı anahtar noktaları arasındaki turların sayısına bağlıdır. Bullshark'ın en kullanışlı kısmi senkron versiyonu, asenkron versiyondan daha iyi bir gecikmeye sahip olmasına rağmen, en iyi olanı değildir.
Soru 1: Ortalama blok gecikmesi. Bullshark'ta, her çift turda bir ana nokta vardır, her tek turda ise zirve oy verme olarak yorumlanır. Yaygın durumlarda, ana noktaların sıralanması için iki tur DAG gereklidir, ancak ana noktanın nedensel tarihindeki zirvelerin sıralanması için daha fazla tura ihtiyaç vardır. Yaygın durumlarda, tek turdaki zirveler üç tura, çift turdaki ana nokta olmayan zirveler ise dört tura ihtiyaç duyar.
Soru 2: Arıza durumu gecikmesi, yukarıdaki gecikme analizi arızasız durumlar için geçerlidir, öte yandan, eğer bir turdaki lider yeterince hızlı bir şekilde referans noktasını yayınlayamazsa, referans noktası sıralanamaz ) bu yüzden atlanır (, bu nedenle önceki turlardaki sıralanmamış tüm zirveler, 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üşürecektir, özellikle Bullshark zaman aşımı lideri beklemek için kullanıldığı için.
![Bin kelimeyle açıklama Shoal çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Shoal çerçevesi
Shoal, bu iki gecikme süresi sorununu çözdü; Bullshark) veya diğer herhangi bir Narwhal tabanlı BFT protokolünü (, her turda bir referans noktası olmasına olanak tanıyarak ve DAG'daki tüm referans noktası olmayan düğümlerin gecikme süresini üç tura düşürerek, ardışık olarak güçlendirdi. Shoal ayrıca DAG'da sıfır maliyetli lider itibar mekanizması getirdi, bu da seçimlerin hızlı liderlere yönelmesini sağladı.
Mücadele
DAG protokolü bağlamında, boru hattı ve liderin itibarı zor sorunlar olarak kabul edilmektedir, sebepleri şunlardır:
Önceki akış şeması, 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 farklılıkların bu protokollerin güvenliğini ihlal etmemesi söz konusu olsa da, Bullshark'ta bu tamamen farklı bir sıralamaya yol açabilir. Bu, sorunların kalbini ortaya çıkarır; yani, dinamik ve belirleyici bir şekilde döngü çapa seçimi, konsensüsün sağlanması için gereklidir ve doğrulayıcıların gelecekteki çapa seçmek için sıralı tarih üzerinde anlaşmaları gerekir.
Sorun zorluğunun kanıtı olarak, Bullshark'ın uygulaması, şu anda üretim ortamında bulunan uygulamalar dahil, bu özellikleri desteklememektedir.
Protokol
Yukarıda belirtilen zorluklara rağmen, çözümün basitliğin ardında gizli olduğu kanıtlanmıştır.
Shoal'da, DAG üzerinde yerel hesaplama yapma yeteneğine dayanarak, önceki turların bilgilerini saklama ve yeniden yorumlama yeteneği gerçekleştirilmiştir. Tüm doğrulayıcıların ilk sıralı sabit nokta konusunda hemfikir olduğu temel içgörü ile, Shoal birden fazla Bullshark örneğini sırayla birleştirip bunları önce işlemeye tabi tutarak, ) ilk sıralı sabit nokta örneklerin geçiş noktasıdır ve ( sabit noktasının nedensel tarihi liderin itibarını hesaplamak için kullanılır.
![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Akış Hattı
V vardır. Shoal, Bullshark'ın örneklerini birer birer çalıştırır, böylece her örnek için, ankranın F eşlemesi ile önceden belirlenmiştir. Her örnek bir ankra siparişi verir, 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ı bağlantıyı belirleyene kadar çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu bağlantıyı kabul etti. Bu nedenle, tüm doğrulayıcılar r+1. turdan itibaren DAG'ı yeniden yorumlamayı kesin olarak kabul edebilir. Shoal sadece r+1. turda yeni bir Bullshark örneği başlattı.
En iyi durumda, bu, Shoal'in her turda bir çapa sipariş etmesine olanak tanır. İlk turdaki çapa noktaları, ilk örneğe göre sıralanır. Daha sonra, 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. Ardından, üçüncü turda başka bir yeni örnek çapa noktası sipariş eder ve süreç devam eder.
![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Liderlerin İtibarı
Bullshark sıralama sırasında ankraj noktalarını atladığınızda, gecikme süresi artar. Bu durumda, pipeline teknolojisi etkisizdir, çünkü yeni bir örneği başlatmak, önceki örnek ankraj noktası sipariş edilmeden mümkün değildir. Shoal, her bir doğrulama düğümünün son faaliyet geçmişine dayalı olarak her bir doğrulama düğümüne bir puan atayarak, gelecekte kaybolan ankraj noktalarını işlemek için ilgili liderlerin seçilme 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 alacak, çünkü çökme, yavaşlama veya kötüye kullanma durumu olabilir.
Felsefesi, her puan güncellemesinde, yüksek puanlı liderlere eğilimli olan, turlar ile liderler arasındaki önceden tanımlanmış F haritalarını belirli bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni haritalar üzerinde uzlaşabilmeleri için puanlar üzerinde uzlaşmaları, böylece türetilen puanların tarihi üzerinde uzlaşmaları gerekir.
Shoal'da, akış hattı ve liderlik itibarı doğal olarak bir araya gelebilir, çünkü her ikisi de ilk sıralı sabit nokta üzerinde uzlaşma sağlandıktan sonra DAG'yi yeniden yorumlamak için aynı temel teknolojiyi kullanır.
Aslında tek fark, r. turda aygıtların sıralanmasından sonra, doğrulayıcının sadece r. turda sıralı aygıtların nedensel tarihine dayanarak r+1. turdan itibaren yeni eşleme F'yi hesaplaması gerektiğidir. Ardından, doğrulama düğümleri r+1. turdan itibaren güncellenmiş aygıt seçim fonksiyonu F'yi kullanarak Bullshark'ın yeni bir örneğini gerçekleştirir.
![Bin kelime ile Shoal çerçevesi: Aptos'taki Bullshark gecikmesini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
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, 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.
Zaman aşımı, uygun bir şekilde yapılandırılmasının çok önemli olduğu ve genellikle ortamdan yüksek ölçüde bağımlı olduğu için, gecikmeyi önemli ölçüde artırır ) ağ (. 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 koşullarında, Jolteon/Hotstuff'taki liderlerin aşırı yüklendiğini ve ilerlemeyi sağlamadan önce zaman aşımının süresinin dolduğunu gözlemledik.
Ne yazık ki, liderlere dayalı protokol ), Hotstuff ve Jolteon( gibi, her seferinde liderin doğrulanmasını sağlamak için temel olarak bir gecikme süresi gerektirir.