Shoal çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltır
Genel Bakış
Aptos Labs, DAG BFT'deki iki önemli açık sorunu çözdü, gecikme süresini büyük ölçüde azalttı ve ilk kez, belirleyici gerçek protokollerde zaman aşımı gereksinimini ortadan kaldırdı. Genel olarak, arızasız durumda Bullshark'ın gecikme süresini %40, arıza durumunda ise %80 oranında iyileştirdi.
Shoal, DAG-Rider, Tusk, Bullshark ( çerçevesindeki Narwhal tabanlı konsensüs protokolünü güçlendirmek için bir akış hattı ve lider itibarını kullanan bir sistemdir. Akış hattı, her turda bir referans noktası ekleyerek DAG sıralama gecikme süresini azaltır; lider itibarı, referans noktalarının en hızlı doğrulama düğümleri ile ilişkilendirilmesini sağlayarak gecikmeyi daha da iyileştirir. Ayrıca, lider 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 bir özelliği sağlamasına izin verir.
Bu teknoloji oldukça basit olup, alt protokollerin birden fazla örneğini sırayla çalıştırmayı içeriyor. Bu nedenle, Bullshark ile örneklendirildiğinde, bir grup "köpek balığı"nın bayrak yarışı yaptığı bir durum elde ediyoruz.
Blockchain ağlarının yüksek performansını ararken, insanlar iletişim karmaşıklığını azaltmaya sürekli olarak odaklanmışlardır. Ancak, bu yaklaşım, belirgin bir throughput artışı sağlamamıştır. Örneğin, erken versiyonlarındaki Diem'de uygulanan Hotstuff sadece 3500 TPS gerçekleştirmiştir, bu da 100k+ TPS hedefine göre çok daha düşüktür.
Son dönemdeki atılım, veri yayılımının liderlerin protokollerine dayandığını ve paralelleşmeden fayda sağlayabileceğ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 verileri aynı anda yaydığı ve konsensüs bileşeninin yalnızca daha az miktarda meta veriyi sıraladığı bir mimari öneriyor. Narwhal belgesi, 160.000 TPS'lik bir verimliliği rapor ediyor.
Daha önce Quorum Store'dan, yani Narwhal'ın verileri yayma ve konsensüsü ayırma uygulamasından ve bunun mevcut konsensüs protokolü Jolteon'u nasıl ölçeklendirmek için kullanıldığından bahsedilmiştir. Jolteon, Tendermint'in lineer hızlı yolunu ve PBFT tarzı görünüm değişikliklerini birleştiren lider temelli bir protokoldür ve Hotstuff gecikmesini %33 oranında azaltabilir. Ancak, lider temelli konsensüs protokolünün Narwhal'ın işlem hacmi potansiyelinden tam olarak yararlanamadığı açıktır. Verilerin yayılmasını konsensüsten ayırmış olsak da, işlem hacmi arttıkça Hotstuff/Jolteon'un lideri hala sınırlıdır.
Bu nedenle, sıfır iletişim maliyetine sahip bir konsensüs protokolü olan Bullshark'ı Narwhal DAG'ının üzerine dağıtmaya karar verildi. Ne yazık ki, Jolteon'a kıyasla, Bullshark'ın yüksek verimliliği destekleyen DAG yapısı %50 gecikme süresi maliyeti getirmektedir.
Bu makalede, Shoal'un Bullshark gecikme süresini nasıl büyük ölçüde azalttığı anlatılmaktadır.
Narwhal DAG'daki her bir köşe bir tur ile ilişkilidir. r. tura girmek için, doğrulayıcının önce r-1. tura ait n-f köşeyi elde etmesi gerekmektedir. Her doğrulayıcı her turda bir köşe yayımlayabilir ve her köşe en az bir önceki turdaki n-f köşeyi referans almalıdır. Ağın asenkronluğu nedeniyle, farklı doğrulayıcılar herhangi bir anda DAG'ın farklı yerel görünümlerini gözlemleyebilir.
DAG'ın bir anahtarı özelliği belirsiz değildir: Eğer iki doğrulayıcı düğüm, DAG yerel görünümlerinde aynı tepe v'ye sahipse, o zaman tamamen aynı v nedensellik geçmişine sahiptirler.
![Bin kelimelik Shoal çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Genel Sıra
DAG içindeki tüm noktaların 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 konsensüs protokolü olarak yorumlar; burada noktalar önerileri, kenarlar ise oyları 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:
Rezervasyon Ağı: Her birkaç turda önceden belirlenmiş bir lider olacak, liderin zirvesine ankraj noktası denir;
Sıralama Bağlantıları: Doğrulayıcılar, bağımsız ancak belirleyici bir şekilde hangi bağlantıların sıralanacağını ve hangi bağlantıların atlanacağını karar verir;
Neden-sonuç tarihini sıralama: Doğrulayıcılar, sıralı ayak noktası listelerini birer birer işler ve her ayak 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 aynı ön eki paylaşacak şekilde sıralı bir referans noktası listesi oluşturmalarını sağlamaktır. Shoal'da yukarıda belirtilen tüm protokoller hakkında aşağıdaki gözlemler yapılmıştır:
Tüm doğrulayıcılar ilk sıralı sabit noktada hemfikirdir.
![Bin kelimelik Shoal çerçevesi: Aptos üzerindeki Bullshark gecikme süresini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Bullshark gecikme süresi
Bullshark'ın gecikme süresi, DAG'daki sıralı kilit noktaları arasındaki döngü sayısına bağlıdır. Bullshark'ın en pratik kısım senkron versiyonları, asenkron versiyonlara göre daha iyi bir gecikme süresine sahip olsa da, bu kesinlikle en iyi değildir.
Soru 1: Ortalama blok gecikmesi. Bullshark'ta, her bir çift turda bir sabit nokta vardır, her bir tek turun zirvesi ise oy verme olarak yorumlanır. Yaygın durumlarda, sabit noktaları sıralamak için iki tur DAG gerekmektedir, ancak sabit noktanın nedensel tarihindeki zirvelerin sıralanması için daha fazla tura ihtiyaç vardır. Yaygın durumlarda, tek turdaki zirveler üç tura, çift turdaki sabit olmayan zirveler ise dört tura ihtiyaç duyar.
Soru 2: Arıza durumu gecikme süresi, 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 nedenle atlanır (, bu nedenle önceki turlardaki tüm sıralanmamış 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 azaltır, özellikle de lideri beklemek için kullanılan Bullshark zaman aşımı nedeniyle.
Shoal, Bullshark) veya Narwhal tabanlı herhangi bir BFT protokolü( üzerinde bir hat ile güçlendirilmiş, her turda bir referans noktası bulunmasına izin vermekte ve DAG'deki tüm referans noktası olmayan düğümlerin gecikme süresini üç tura indirmektedir. Shoal ayrıca, hızlı liderleri tercih eden bir lider reputasyon mekanizması ekleyerek DAG'de sıfır maliyetli bir lider reputasyon mekanizması tanıtmaktadır.
Mücadele
DAG protokolü bağlamında, boru hattı ve liderin itibarı zorlayıcı sorunlar olarak kabul edilmektedir, nedenleri ise şunlardır:
Önceki akış şeması, ana Bullshark mantığını değiştirmeye çalıştı, ancak bu doğası gereği imkansız gibi görünüyor.
Liderlerin itibarı, DiemBFT'ye dahil edilmiştir 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 anlaşmazlık olmasının bu protokollerin güvenliğini ihlal etmemesine rağmen, Bullshark'ta bu tamamen farklı bir sıralama ile sonuçlanabilir. Bu, sorunun özüne işaret eder; yani tekerlekler için dinamik ve belirleyici bir şekilde seçim yapmak, uzlaşımın sağlanması için gereklidir ve doğrulayıcıların, gelecekteki ankrajı seçmek için sıralı tarih üzerinde mutabık kalmaları gerekir.
Bir sorun zorluğu kanıtı olarak, Bullshark'ın uygulanması ), şu anda üretim ortamında bulunan ( uygulamaları bu özellikleri desteklememektedir.
![Bin kelimeyle Shoal çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Protokol
Shoal'da, DAG üzerinde yerel hesaplama yapabilme yeteneğine dayanıyoruz ve önceki turların bilgilerini saklama ve yeniden yorumlama yeteneğini sağlıyoruz. Tüm doğrulayıcıların ilk sıralı sabit noktanın temel içgörüsünde hemfikir olmasıyla, Shoal birden fazla Bullshark örneğini sıralı bir şekilde birleştirerek bunları boru hattı işlemeye tabi tutar; böylece )1( ilk sıralı sabit nokta, örneklerin geçiş noktasıdır ve )2( sabit noktanın nedensel tarihi, liderin itibarını hesaplamak için kullanılır.
Akış Şeridi
V vardır. Shoal, Bullshark'ın örneklerini birer birer çalıştırır, böylece her örnek için, ana nokta harita F tarafından önceden belirlenir. Her ö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ı bağlama noktası belirlendiği güne kadar bunu çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu bağlama noktasını kabul etti. Böylece, tüm doğrulayıcılar r+1. turdan itibaren DAG'ı yeniden yorumlamayı kesin olarak kabul edebilirler. 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 sonra üçüncü turda başka bir yeni örnek çapa noktası sipariş eder, ardından bu süreç devam eder.
![Bin kelimelerle Shoal çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltabiliriz?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Liderlerin İtibarı
Bullshark sıralama sırasında dengeleme noktalarını atladığınızda, gecikme süresi artar. Bu durumda, önceki örneğin dengeleme noktasını sipariş etmeden yeni bir örneği başlatmak mümkün olmadığından, boru hattı teknolojisi etkisizdir. Shoal, her doğrulama düğümünün en son etkinlik geçmişine göre her doğrulama düğümüne bir puan atayarak, gelecekte kaybolan dengeleme noktalarını 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 düşük puan alacak, çünkü çökme, yavaşlık veya kötü niyetli davranış sergileyebilirler.
Felsefesi, her puan güncellemesinde, daha yüksek puana sahip liderlere eğilim gösteren, turdan lidere önceden tanımlanmış F haritasını kesin bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni harita üzerinde uzlaşabilmeleri için, puanlar üzerinde uzlaşmaları ve böylece puan türetmek için kullanılan geçmişte 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 anlaş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 dayanarak r+1. turdan itibaren yeni bir haritalama F' hesaplaması gerektiğidir. Ardından, doğrulama düğümleri r+1. turdan itibaren güncellenmiş referans noktası seçim fonksiyonu F' kullanarak Bullshark'ın yeni bir örneğini gerçekleştirir.
![Milyon Kelime Detaylı Shoal Çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltabiliriz?])https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.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 tekniği gerektirmektedir.
Zaman aşımı, uygun bir şekilde yapılandırılmasının çok önemli olduğu ve genellikle dinamik olarak ayarlanması gereken bir şey olduğundan, gecikme süresini önemli ölçüde artırabilir, çünkü bu durum çevre ) ağı ( üzerinde yüksek derecede 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ı fazla temkinli olmamalıdır, ancak zaman aşımı süresi çok kısa olursa, protokol iyi liderleri atlayabilir. Örneğin, gözlemliyoruz.
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 üzerindeki Bullshark Konsensüs gecikme süresini büyük ölçüde düşürerek %40-%80 oranında artırdı.
Shoal çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltır
Genel Bakış
Aptos Labs, DAG BFT'deki iki önemli açık sorunu çözdü, gecikme süresini büyük ölçüde azalttı ve ilk kez, belirleyici gerçek protokollerde zaman aşımı gereksinimini ortadan kaldırdı. Genel olarak, arızasız durumda Bullshark'ın gecikme süresini %40, arıza durumunda ise %80 oranında iyileştirdi.
Shoal, DAG-Rider, Tusk, Bullshark ( çerçevesindeki Narwhal tabanlı konsensüs protokolünü güçlendirmek için bir akış hattı ve lider itibarını kullanan bir sistemdir. Akış hattı, her turda bir referans noktası ekleyerek DAG sıralama gecikme süresini azaltır; lider itibarı, referans noktalarının en hızlı doğrulama düğümleri ile ilişkilendirilmesini sağlayarak gecikmeyi daha da iyileştirir. Ayrıca, lider 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 bir özelliği sağlamasına izin verir.
Bu teknoloji oldukça basit olup, alt protokollerin birden fazla örneğini sırayla çalıştırmayı içeriyor. Bu nedenle, Bullshark ile örneklendirildiğinde, bir grup "köpek balığı"nın bayrak yarışı yaptığı bir durum elde ediyoruz.
![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Motivasyon
Blockchain ağlarının yüksek performansını ararken, insanlar iletişim karmaşıklığını azaltmaya sürekli olarak odaklanmışlardır. Ancak, bu yaklaşım, belirgin bir throughput artışı sağlamamıştır. Örneğin, erken versiyonlarındaki Diem'de uygulanan Hotstuff sadece 3500 TPS gerçekleştirmiştir, bu da 100k+ TPS hedefine göre çok daha düşüktür.
Son dönemdeki atılım, veri yayılımının liderlerin protokollerine dayandığını ve paralelleşmeden fayda sağlayabileceğ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 verileri aynı anda yaydığı ve konsensüs bileşeninin yalnızca daha az miktarda meta veriyi sıraladığı bir mimari öneriyor. Narwhal belgesi, 160.000 TPS'lik bir verimliliği rapor ediyor.
Daha önce Quorum Store'dan, yani Narwhal'ın verileri yayma ve konsensüsü ayırma uygulamasından ve bunun mevcut konsensüs protokolü Jolteon'u nasıl ölçeklendirmek için kullanıldığından bahsedilmiştir. Jolteon, Tendermint'in lineer hızlı yolunu ve PBFT tarzı görünüm değişikliklerini birleştiren lider temelli bir protokoldür ve Hotstuff gecikmesini %33 oranında azaltabilir. Ancak, lider temelli konsensüs protokolünün Narwhal'ın işlem hacmi potansiyelinden tam olarak yararlanamadığı açıktır. Verilerin yayılmasını konsensüsten ayırmış olsak da, işlem hacmi arttıkça Hotstuff/Jolteon'un lideri hala sınırlıdır.
Bu nedenle, sıfır iletişim maliyetine sahip bir konsensüs protokolü olan Bullshark'ı Narwhal DAG'ının üzerine dağıtmaya karar verildi. Ne yazık ki, Jolteon'a kıyasla, Bullshark'ın yüksek verimliliği destekleyen DAG yapısı %50 gecikme süresi maliyeti getirmektedir.
Bu makalede, Shoal'un Bullshark gecikme süresini nasıl büyük ölçüde azalttığı anlatılmaktadır.
![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
DAG-BFT Arka Planı
Narwhal DAG'daki her bir köşe bir tur ile ilişkilidir. r. tura girmek için, doğrulayıcının önce r-1. tura ait n-f köşeyi elde etmesi gerekmektedir. Her doğrulayıcı her turda bir köşe yayımlayabilir ve her köşe en az bir önceki turdaki n-f köşeyi referans almalıdır. Ağın asenkronluğu nedeniyle, farklı doğrulayıcılar herhangi bir anda DAG'ın farklı yerel görünümlerini gözlemleyebilir.
DAG'ın bir anahtarı özelliği belirsiz değildir: Eğer iki doğrulayıcı düğüm, DAG yerel görünümlerinde aynı tepe v'ye sahipse, o zaman tamamen aynı v nedensellik geçmişine sahiptirler.
![Bin kelimelik Shoal çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Genel Sıra
DAG içindeki tüm noktaların 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 konsensüs protokolü olarak yorumlar; burada noktalar önerileri, kenarlar ise oyları 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:
Rezervasyon Ağı: Her birkaç turda önceden belirlenmiş bir lider olacak, liderin zirvesine ankraj noktası denir;
Sıralama Bağlantıları: Doğrulayıcılar, bağımsız ancak belirleyici bir şekilde hangi bağlantıların sıralanacağını ve hangi bağlantıların atlanacağını karar verir;
Neden-sonuç tarihini sıralama: Doğrulayıcılar, sıralı ayak noktası listelerini birer birer işler ve her ayak 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 aynı ön eki paylaşacak şekilde sıralı bir referans noktası listesi oluşturmalarını sağlamaktır. Shoal'da yukarıda belirtilen tüm protokoller hakkında aşağıdaki gözlemler yapılmıştır:
Tüm doğrulayıcılar ilk sıralı sabit noktada hemfikirdir.
![Bin kelimelik Shoal çerçevesi: Aptos üzerindeki Bullshark gecikme süresini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Bullshark gecikme süresi
Bullshark'ın gecikme süresi, DAG'daki sıralı kilit noktaları arasındaki döngü sayısına bağlıdır. Bullshark'ın en pratik kısım senkron versiyonları, asenkron versiyonlara göre daha iyi bir gecikme süresine sahip olsa da, bu kesinlikle en iyi değildir.
Soru 1: Ortalama blok gecikmesi. Bullshark'ta, her bir çift turda bir sabit nokta vardır, her bir tek turun zirvesi ise oy verme olarak yorumlanır. Yaygın durumlarda, sabit noktaları sıralamak için iki tur DAG gerekmektedir, ancak sabit noktanın nedensel tarihindeki zirvelerin sıralanması için daha fazla tura ihtiyaç vardır. Yaygın durumlarda, tek turdaki zirveler üç tura, çift turdaki sabit olmayan zirveler ise dört tura ihtiyaç duyar.
Soru 2: Arıza durumu gecikme süresi, 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 nedenle atlanır (, bu nedenle önceki turlardaki tüm sıralanmamış 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 azaltır, özellikle de lideri beklemek için kullanılan Bullshark zaman aşımı nedeniyle.
![万字详解Shoal框架：如何减少Aptos上的Bullshark gecikme süresi？])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Shoal çerçevesi
Shoal, Bullshark) veya Narwhal tabanlı herhangi bir BFT protokolü( üzerinde bir hat ile güçlendirilmiş, her turda bir referans noktası bulunmasına izin vermekte ve DAG'deki tüm referans noktası olmayan düğümlerin gecikme süresini üç tura indirmektedir. Shoal ayrıca, hızlı liderleri tercih eden bir lider reputasyon mekanizması ekleyerek DAG'de sıfır maliyetli bir lider reputasyon mekanizması tanıtmaktadır.
Mücadele
DAG protokolü bağlamında, boru hattı ve liderin itibarı zorlayıcı sorunlar olarak kabul edilmektedir, nedenleri ise şunlardır:
Önceki akış şeması, ana Bullshark mantığını değiştirmeye çalıştı, ancak bu doğası gereği imkansız gibi görünüyor.
Liderlerin itibarı, DiemBFT'ye dahil edilmiştir 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 anlaşmazlık olmasının bu protokollerin güvenliğini ihlal etmemesine rağmen, Bullshark'ta bu tamamen farklı bir sıralama ile sonuçlanabilir. Bu, sorunun özüne işaret eder; yani tekerlekler için dinamik ve belirleyici bir şekilde seçim yapmak, uzlaşımın sağlanması için gereklidir ve doğrulayıcıların, gelecekteki ankrajı seçmek için sıralı tarih üzerinde mutabık kalmaları gerekir.
Bir sorun zorluğu kanıtı olarak, Bullshark'ın uygulanması ), şu anda üretim ortamında bulunan ( uygulamaları bu özellikleri desteklememektedir.
![Bin kelimeyle Shoal çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Protokol
Shoal'da, DAG üzerinde yerel hesaplama yapabilme yeteneğine dayanıyoruz ve önceki turların bilgilerini saklama ve yeniden yorumlama yeteneğini sağlıyoruz. Tüm doğrulayıcıların ilk sıralı sabit noktanın temel içgörüsünde hemfikir olmasıyla, Shoal birden fazla Bullshark örneğini sıralı bir şekilde birleştirerek bunları boru hattı işlemeye tabi tutar; böylece )1( ilk sıralı sabit nokta, örneklerin geçiş noktasıdır ve )2( sabit noktanın nedensel tarihi, liderin itibarını hesaplamak için kullanılır.
Akış Şeridi
V vardır. Shoal, Bullshark'ın örneklerini birer birer çalıştırır, böylece her örnek için, ana nokta harita F tarafından önceden belirlenir. Her ö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ı bağlama noktası belirlendiği güne kadar bunu çalıştırdı, örneğin r. turda. Tüm doğrulayıcılar bu bağlama noktasını kabul etti. Böylece, tüm doğrulayıcılar r+1. turdan itibaren DAG'ı yeniden yorumlamayı kesin olarak kabul edebilirler. 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 sonra üçüncü turda başka bir yeni örnek çapa noktası sipariş eder, ardından bu süreç devam eder.
![Bin kelimelerle Shoal çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltabiliriz?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Liderlerin İtibarı
Bullshark sıralama sırasında dengeleme noktalarını atladığınızda, gecikme süresi artar. Bu durumda, önceki örneğin dengeleme noktasını sipariş etmeden yeni bir örneği başlatmak mümkün olmadığından, boru hattı teknolojisi etkisizdir. Shoal, her doğrulama düğümünün en son etkinlik geçmişine göre her doğrulama düğümüne bir puan atayarak, gelecekte kaybolan dengeleme noktalarını 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 düşük puan alacak, çünkü çökme, yavaşlık veya kötü niyetli davranış sergileyebilirler.
Felsefesi, her puan güncellemesinde, daha yüksek puana sahip liderlere eğilim gösteren, turdan lidere önceden tanımlanmış F haritasını kesin bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni harita üzerinde uzlaşabilmeleri için, puanlar üzerinde uzlaşmaları ve böylece puan türetmek için kullanılan geçmişte 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 anlaş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 dayanarak r+1. turdan itibaren yeni bir haritalama F' hesaplaması gerektiğidir. Ardından, doğrulama düğümleri r+1. turdan itibaren güncellenmiş referans noktası seçim fonksiyonu F' kullanarak Bullshark'ın yeni bir örneğini gerçekleştirir.
![Milyon Kelime Detaylı Shoal Çerçevesi: Aptos'taki Bullshark gecikme süresini nasıl azaltabiliriz?])https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.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 tekniği gerektirmektedir.
Zaman aşımı, uygun bir şekilde yapılandırılmasının çok önemli olduğu ve genellikle dinamik olarak ayarlanması gereken bir şey olduğundan, gecikme süresini önemli ölçüde artırabilir, çünkü bu durum çevre ) ağı ( üzerinde yüksek derecede 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ı fazla temkinli olmamalıdır, ancak zaman aşımı süresi çok kısa olursa, protokol iyi liderleri atlayabilir. Örneğin, gözlemliyoruz.