Aptos Labs, yakın zamanda DAG BFT konsensüsündeki iki ana sorunu çözmek amacıyla Shoal çerçevesini sundu, gecikmeyi önemli ölçüde azalttı ve belirleyici asenkron protokollerde zaman aşımına olan bağımlılığı ilk kez ortadan kaldırdı. Genel olarak, Shoal, hatasız durumlarda Bullshark'ın gecikmesini %40 artırırken, arızalı durumlarda %80 artırdı.
Shoal, Narwhal tabanlı konsensüs protokolünü ( DAG-Rider, Tusk, Bullshark gibi projelerle güçlendirmek için sıralı işlem ve liderin itibar mekanizmasını kullanır. Sıralı işlem teknolojisi, her turda bir referans noktası ekleyerek DAG sıralama gecikmesini azaltır, liderin itibar mekanizması ise referans noktasının en hızlı doğrulama düğümleri ile ilişkilendirilmesini sağlayarak gecikmeyi daha da iyileş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ını sağlar ve böylece evrensel bir yanıt verme yeteneği elde edilir.
Shoal'un temel fikri, alt protokollerin birden fazla örneğini sıralı olarak çalıştırmaktır. Bullshark örneğinde olduğu gibi, bunu bir grup "köpekbalığı"nın bayrak yarışı koştuğu gibi düşünebilirsiniz.
![Binlerce kelimeyle Shoal çerçevesi: Aptos üzerindeki Bullshark gecikmesini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Motivasyon
Blok zinciri ağı, daha yüksek bir performans peşinde koşmaktadır, başlangıçta iletişim karmaşıklığını azaltmaya odaklanmıştır. Ancak, bu yaklaşım belirgin bir işlem hacmi artışı sağlamamıştır. Örneğin, Diem'in erken versiyonunda uygulanan Hotstuff yalnızca 3500 TPS'ye ulaşabilmiş, bu da 100.000+ TPS hedefinin oldukça altındadır.
Son dönemdeki atılımlar, veri yayılımının liderlik protokollerine dayalı ana darboğaz olduğunu anlamaktan kaynaklanmaktadır ve paralelleşme ile fayda sağlanabilir. Narwhal sistemi, veri yayılımını çekirdek mutabakat mantığından ayırarak, tüm doğrulayıcıların aynı anda veri yaydığı ve mutabakat bileşeninin yalnızca az miktarda meta veriyi sıraladığı bir mimari önerdi ve 160.000 TPS'lik bir iş hacmi sağladı.
Aptos daha önce Quorum Store'u, yani Narwhal'ın uygulamasını tanıttı; verilerin yayılmasını ve konsensüsü ayırarak mevcut konsensüs protokolü Jolteon'un ölçeklenmesine yardımcı oluyor. Jolteon, Tendermint'in lineer hızlı yolunu ve PBFT tarzı görünüm değişikliklerini birleştirerek Hotstuff'un gecikmesini %33 oranında azaltıyor. Ancak, lider temelli konsensüs protokolleri Narwhal'ın verimlilik potansiyelini yeterince kullanamıyor.
Bu nedenle, Aptos, Narwhal DAG'ı üzerinde, sıfır iletişim maliyeti olan bir konsensüs protokolü olan Bullshark'ı dağıtmaya karar verdi. Ancak, Bullshark'ın yüksek verimlilikteki DAG yapısını desteklemesi %50'lik bir gecikme maliyeti getirdi. Shoal çerçevesinin amacı, Bullshark'ın gecikmesini önemli ölçüde azaltmaktır.
![Bin kelime ile Shoal çerçevesinin detaylı açıklaması: Aptos'taki Bullshark gecikmesini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
DAG-BFT Arka Planı
Narwhal DAG'daki her bir tepe noktası bir tur ile ilişkilidir. r. tura girmek için öncelikle r-1. turdaki n-f tepe noktasını elde etmek gerekir. Her doğrulayıcı her turda bir tepe noktası yayabilir, 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 farklı DAG yerel görünümleri gözlemleyebilir.
DAG'ın bir ana özelliği belirsizlik olmamasıdır: Eğer iki doğrulama düğümü yerel DAG görünümünde aynı tepe v'ye sahipse, o zaman v'nin neden-sonuç geçmişi tamamen aynıdır.
![Yüzlerce kelimeyle Shoal çerçevesi: Aptos'taki Bullshark gecikmesini nasıl azaltabilirsiniz?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Tam Sıralama
DAG üzerindeki tüm düğümlerin toplam sırasını ek iletişim maliyeti olmadan uzlaşmak mümkündür. DAG-Rider, Tusk ve Bullshark gibi protokoller, DAG yapısını bir uzlaşma protokolü olarak yorumlar; burada düğümler önerileri, kenarlar ise oylamayı temsil eder.
Narwhal tabanlı konsensüs protokollerinin hepsi aşağıdaki yapıya sahiptir, ancak belirli mantık farklıdır:
Önceden Belirlenmiş Ağırlık Noktası: Her birkaç turda önceden belirlenmiş bir lider vardır, bu liderin zirvesine ağırlık noktası denir.
Sıralama Mankeni: Doğrulayıcılar, hangi mankenlerin sıralanacağına veya atlanacağına bağımsız ancak belirleyici bir şekilde karar verir.
Neden-sonuç tarihini sıralama: Doğrulayıcılar sırasıyla düzenli bir referans noktası listesini işler, her referans noktasının neden-sonuç tarihindeki daha önce sıralanmamış düğümleri sıralar.
Güvenliğin anahtarı, tüm dürüst doğrulayıcı düğümlerin oluşturduğu sıralı referans noktası listesinin aynı öneki paylaşmasını sağlamaktır. Shoal, bu protokollerin hepsi hakkında önemli bir gözlemde bulunur: Tüm doğrulayıcılar ilk sıralı referans noktasında hemfikirdir.
Bullshark'ın Gecikme Sorunu
Bullshark'ın gecikmesi, DAG'deki sıralı referans noktaları arasındaki döngü sayısına bağlıdır. Kısmi senkronize versiyonlar, asenkron versiyonlardan daha düşük gecikmeye sahip olsa da, yine de optimumdan uzak.
İki ana sorun var:
Ortalama blok gecikmesi: Yaygın durumlarda, tek sıra noktalarının sıralanması için üç tur, çift sıra olmayan noktaların sıralanması için dört tur gerekmektedir.
Arıza Durumu Gecikmesi: Eğer bir turdaki lider, sabit noktayı zamanında yayınlayamazsa, bu sabit nokta atlanacaktır ve önceki turlardaki sıralanmamış tüm köşe noktaları bir sonraki sabit noktanın sıralanmasını beklemek zorunda kalacaktır. Bu, coğrafi olarak dağıtılmış ağın performansını önemli ölçüde düşürmektedir, özellikle de Bullshark lideri beklemek için zaman aşımını kullandığı için.
Shoal, Bullshark) veya herhangi bir Narwhal tabanlı BFT protokolünü ( güçlendirmek için bir hattın akışını kullanarak her turda bir referans noktası olmasını sağlar ve tüm referans noktası olmayan düğümlerin gecikmesini üç tura düşürür. Shoal ayrıca DAG içinde sıfır maliyetli bir lider itibar mekanizması tanıtarak hızlı liderlerin seçilmesini teşvik eder.
) meydan okuma
DAG protokolünde boru hattı ve liderin itibarını uygulamak zor olarak kabul edilmektedir:
Daha önce Bullshark'ın temel mantığını değiştirmeye çalışmak mümkün görünmüyordu.
Liderlerin itibarları farklı sıralamalara neden olabilir ve doğrulayıcıların, gelecek referans noktalarını seçmek için sıralı bir tarih üzerinde uzlaşmaları gerekmektedir.
Bir sorun zorluğu kanıtı olarak, mevcut üretim ortamındaki Bullshark uygulamaları bu özellikleri desteklememektedir.
Protokol
Shoal'un çözümü oldukça basittir. Yerel hesaplamaların DAG üzerinde gerçekleştirilme yeteneğinden yararlanarak, önceki turların bilgilerini saklama ve yeniden yorumlama işlevini yerine getirir. Tüm doğrulayıcıların ilk sıralı çivinin içgörüsüne katılmasına dayanan Shoal, birden fazla Bullshark örneğini sıralı olarak birleştirerek boru hattı işlemi gerçekleştirir, bu da:
İlk sıralı referans noktası örneğin geçiş noktasıdır.
Aşama noktasıyla ilgili neden-sonuç geçmişi, liderin itibarını hesaplamak için kullanılır.
Akış Hattı
V. Shoal, her bir örneğin bir sabit nokta sıraladığı ve bir sonraki örneğe geçişi tetiklediği Bullshark örneklerini sıralı bir şekilde çalıştırır.
Shoal, DAG'ın ilk turunda Bullshark'ın ilk örneğini başlatarak, ilk sıralı ankraj noktası ###'i belirleyene kadar devam eder ve r turunda ( varsayılır. Tüm doğrulayıcılar bu ankraj noktasında hemfikir olduğundan, r+1 turundan itibaren DAG'ı yeniden yorumlamak için kesin bir şekilde hemfikir olabilirler. Shoal, r+1 turunda yeni bir Bullshark örneğini başlatır.
İdeal koşullarda, bu Shoal'in her turda bir referans noktası sıralamasına izin verir. İlk tur referans noktası ilk örnek tarafından sıralanır, ardından ikinci turda yeni örnek o tur referans noktasını sıralar, böylece devam eder.
Bullshark, ankraj noktasını atladığında gecikme artar. Bu durumda, önceki örneğin sıralama noktasını beklemek zorunda olduğundan, hat çekme tekniği etkisizdir. Shoal, her doğrulayıcı düğüm için son etkinlik tarihine göre bir puan tahsis etmek için bir itibar mekanizması kullanır. Hızlı yanıt veren doğrulayıcılar yüksek puan alırken, aksi takdirde düşük puan alır.
Felsefe, her puan güncellemesinde, yüksek puan liderlerine yönelerek, turlar ile liderler arasındaki F haritasını belirli bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni harita üzerinde uzlaşabilmeleri için puan üzerinde uzlaşmaları ve ardından puan türetmek için kullanılan geçmişte uzlaşmaları gerekmektedir.
Shoal'da, akış hattı ve liderin itibarı doğal olarak birleşebilir, çünkü her ikisi de ilk sıralı sabit nokta üzerinde uzlaşıldıktan sonra DAG'ı yeniden yorumlamaya dayanmaktadır. Tek fark, r'inci tur sabit noktasından sonra, doğrulayıcılar bu sabit noktanın nedensel tarihine göre r+1'inci turdan itibaren yeni haritalama F'yi hesaplamaya başlamasıdır. Ardından r+1'inci turdan itibaren güncellenmiş F' ile yeni Bullshark örnekleri uygulanır.
![Binlerce kelimeyle Shoal çerçevesi: Aptos'taki Bullshark gecikmesini nasıl azaltır?]###https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
) Zaman aşımını kaldır
Zaman aşımı, tüm lider tabanlı belirleyici kısmi senkronize BFT uygulamalarında kritik öneme sahiptir. Ancak, bunlar karmaşıklığı artırır, daha fazla iç durum yönetimi ve gözlem gerektirir, bu da hata ayıklamayı daha zor hale getirir.
Zaman aşımı, doğru yapılandırmanın önemli olmasından ve genellikle dinamik ayarlamalar gerektirmesinden dolayı gecikmeyi önemli ölçüde artıracaktır. Protokol, bir sonraki lider değişimine geçmeden önce arızalı lider için tam zaman aşımı gecikme cezasını ödemek zorundadır. Bu nedenle, zaman aşımı ayarları çok temkinli olmamalıdır, ancak çok kısa olursa iyi liderlerin atlanmasına neden olabilir.
Ne yazık ki, lider bazlı protokoller ###, Hotstuff ve Jolteon ( esasen ilerleme sağlamak için zaman aşımına ihtiyaç duyar. Zaman aşımı olmadan, çökme durumundaki bir lider bile protokolü sonsuza dek durdurabilir. Asenkron dönemlerde, çökme ile yavaş lideri ayırt edilemediğinden, zaman aşımı, doğrulama düğümlerinin konsensüs aktifliği olmadan tüm liderleri değiştirmesine neden olabilir.
Bullshark'ta, DAG yapımı için zaman aşımı kullanılır, böylece senkronizasyon sırasında dürüst liderlerin sıralama için DAG'a yeterince hızlı şekilde referans noktaları eklemesini sağlar.
DAG inşa etmenin bir "saat" olarak ağ hızını tahmin ettiğini gözlemledik. n-f kadar dürüst doğrulayıcı DAG'a zirve eklemeye devam ettiği sürece, turlar ilerleyecektir. Bullshark ağ hızında sıralama yapamayabilir, ancak DAG hala ağ hızında büyümektedir. Sonunda, hatasız bir lider yeterince hızlı bir şekilde referans noktalarını yayınladığında, referans noktasının tüm nedensel tarihi sıralanacak.
Değerlendirme sırasında, zaman aşımı olup olmadığını Bullshark ile karşılaştırdık:
Hızlı Liderler: İki yöntem aynı gecikmeyi gösterir, çünkü referans noktaları sıralanmıştır ve zaman aşımı kullanılmamaktadır.
Yanlış Liderler: Süresiz Bullshark gecikmesi daha düşük, çünkü doğrulayıcı düğümler hemen sabit noktalarını atlayacak.
Yavaş liderler: Süre aşımı olan Bullshark daha iyi performans gösterir, çünkü doğrulayıcılar referans noktasını beklerken, süre aşımı olmayanlar referans noktasını atlayabilir.
Shoal'da, zaman aşımından kaçınmak liderlerin itibarı ile yakından ilişkilidir. Yavaş liderleri beklemek, gecikmeyi artırırken, itibar mekanizması yavaş doğrulayıcıların lider olarak seçilmesini dışlar. Böylece, sistem tüm gerçek senaryolarda ağ hızında çalışabilir.
Dikkat edilmesi gereken nokta, FLP imkansızlık sonucunun belirli bir konsensüs protokolünün zaman aşımını tamamen önleyemeyeceğini göstermesidir. Shoal bu sonucu aşamaz, çünkü teorik olarak tüm köprü noktalarının sıralanmasını engelleyebilecek düşmanca olay zaman çizelgeleri vardır. Aksine, yapılandırılabilir sürekli atlanan köprü noktası sayısından sonra, Shoal zaman aşımına geri döner. Ancak pratikte bu durumun meydana gelmesi son derece olası değildir.
) Genel Yanıt Verme
Hotstuff makalesi, iyimser yanıt kavramını yaygınlaştırdı; bu, protokolün iyi koşullarda ### hızlı liderler ve senkronize ağlar içerebileceği anlamına gelir ve ( ağ hızında çalışır.
Shoal, evrensel yanıt verme adı verilen daha iyi bir özellik sunar. Özellikle, Hotstuff ile karşılaştırıldığında, lider belirli bir yapılandırılabilir ardışık tur sayısı içinde başarısız olsa bile veya ağ asenkron dönemler yaşasa bile, Shoal ağ hızında çalışmaya devam eder.
Yaygın yanıt verilebilirlik, asenkron dönemlerde ve lider arızaları sırasında katı bir şekilde daha iyi ilerleme garantisi sağlar. Yavaş liderle senkronize olurken, bu özellikler doğrudan karşılaştırılamaz, çünkü liderin hızına bağlıdır. Ancak liderin itibar mekanizması göz önüne alındığında, Shoal'daki yavaş liderlerin çok az ortaya çıkması gerekir.
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.
21 Likes
Reward
21
9
Repost
Share
Comment
0/400
SelfStaking
· 08-14 15:54
Bu Aptos'u kurtarabilir mi?
View OriginalReply0
ForkItAll
· 08-14 11:50
Aman Tanrım, gecikme süresi %40 arttı.
View OriginalReply0
GasGrillMaster
· 08-13 08:06
Aman Tanrım gecikme süresi yarıya indi boğa mı
View OriginalReply0
MysteriousZhang
· 08-12 04:51
Kırk yüzde cesaret mi var? kkk
View OriginalReply0
SerumSquirter
· 08-12 04:50
Sonunda buraya para yatırmaya devam edebiliyorum.
View OriginalReply0
ContractCollector
· 08-12 04:48
Bu gecikme süresi optimizasyonu çok etkileyici!
View OriginalReply0
LiquidityWitch
· 08-12 04:44
Bu çok sert, gecikme süresi %40 arttı.
View OriginalReply0
GateUser-26d7f434
· 08-12 04:41
Ana Ağ ile yarışmak için %40 hızlanmak mı?
View OriginalReply0
YieldHunter
· 08-12 04:41
teknik olarak konuşursak... %40 fena değil ama bana getiri istatistiklerini göster.
Shoal çerçevesi: Aptos zinciri %40 gecikme süresi artırımı ve zaman aşımı bağımlılığının ortadan kaldırılması
Shoal Çerçevesi: Aptos Blok Zinciri Performansını Artıran Yenilikçi Çözüm
Aptos Labs, yakın zamanda DAG BFT konsensüsündeki iki ana sorunu çözmek amacıyla Shoal çerçevesini sundu, gecikmeyi önemli ölçüde azalttı ve belirleyici asenkron protokollerde zaman aşımına olan bağımlılığı ilk kez ortadan kaldırdı. Genel olarak, Shoal, hatasız durumlarda Bullshark'ın gecikmesini %40 artırırken, arızalı durumlarda %80 artırdı.
Shoal, Narwhal tabanlı konsensüs protokolünü ( DAG-Rider, Tusk, Bullshark gibi projelerle güçlendirmek için sıralı işlem ve liderin itibar mekanizmasını kullanır. Sıralı işlem teknolojisi, her turda bir referans noktası ekleyerek DAG sıralama gecikmesini azaltır, liderin itibar mekanizması ise referans noktasının en hızlı doğrulama düğümleri ile ilişkilendirilmesini sağlayarak gecikmeyi daha da iyileş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ını sağlar ve böylece evrensel bir yanıt verme yeteneği elde edilir.
Shoal'un temel fikri, alt protokollerin birden fazla örneğini sıralı olarak çalıştırmaktır. Bullshark örneğinde olduğu gibi, bunu bir grup "köpekbalığı"nın bayrak yarışı koştuğu gibi düşünebilirsiniz.
![Binlerce kelimeyle Shoal çerçevesi: Aptos üzerindeki Bullshark gecikmesini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Motivasyon
Blok zinciri ağı, daha yüksek bir performans peşinde koşmaktadır, başlangıçta iletişim karmaşıklığını azaltmaya odaklanmıştır. Ancak, bu yaklaşım belirgin bir işlem hacmi artışı sağlamamıştır. Örneğin, Diem'in erken versiyonunda uygulanan Hotstuff yalnızca 3500 TPS'ye ulaşabilmiş, bu da 100.000+ TPS hedefinin oldukça altındadır.
Son dönemdeki atılımlar, veri yayılımının liderlik protokollerine dayalı ana darboğaz olduğunu anlamaktan kaynaklanmaktadır ve paralelleşme ile fayda sağlanabilir. Narwhal sistemi, veri yayılımını çekirdek mutabakat mantığından ayırarak, tüm doğrulayıcıların aynı anda veri yaydığı ve mutabakat bileşeninin yalnızca az miktarda meta veriyi sıraladığı bir mimari önerdi ve 160.000 TPS'lik bir iş hacmi sağladı.
Aptos daha önce Quorum Store'u, yani Narwhal'ın uygulamasını tanıttı; verilerin yayılmasını ve konsensüsü ayırarak mevcut konsensüs protokolü Jolteon'un ölçeklenmesine yardımcı oluyor. Jolteon, Tendermint'in lineer hızlı yolunu ve PBFT tarzı görünüm değişikliklerini birleştirerek Hotstuff'un gecikmesini %33 oranında azaltıyor. Ancak, lider temelli konsensüs protokolleri Narwhal'ın verimlilik potansiyelini yeterince kullanamıyor.
Bu nedenle, Aptos, Narwhal DAG'ı üzerinde, sıfır iletişim maliyeti olan bir konsensüs protokolü olan Bullshark'ı dağıtmaya karar verdi. Ancak, Bullshark'ın yüksek verimlilikteki DAG yapısını desteklemesi %50'lik bir gecikme maliyeti getirdi. Shoal çerçevesinin amacı, Bullshark'ın gecikmesini önemli ölçüde azaltmaktır.
![Bin kelime ile Shoal çerçevesinin detaylı açıklaması: Aptos'taki Bullshark gecikmesini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
DAG-BFT Arka Planı
Narwhal DAG'daki her bir tepe noktası bir tur ile ilişkilidir. r. tura girmek için öncelikle r-1. turdaki n-f tepe noktasını elde etmek gerekir. Her doğrulayıcı her turda bir tepe noktası yayabilir, 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 farklı DAG yerel görünümleri gözlemleyebilir.
DAG'ın bir ana özelliği belirsizlik olmamasıdır: Eğer iki doğrulama düğümü yerel DAG görünümünde aynı tepe v'ye sahipse, o zaman v'nin neden-sonuç geçmişi tamamen aynıdır.
![Yüzlerce kelimeyle Shoal çerçevesi: Aptos'taki Bullshark gecikmesini nasıl azaltabilirsiniz?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Tam Sıralama
DAG üzerindeki tüm düğümlerin toplam sırasını ek iletişim maliyeti olmadan uzlaşmak mümkündür. DAG-Rider, Tusk ve Bullshark gibi protokoller, DAG yapısını bir uzlaşma protokolü olarak yorumlar; burada düğümler önerileri, kenarlar ise oylamayı temsil eder.
Narwhal tabanlı konsensüs protokollerinin hepsi aşağıdaki yapıya sahiptir, ancak belirli mantık farklıdır:
Önceden Belirlenmiş Ağırlık Noktası: Her birkaç turda önceden belirlenmiş bir lider vardır, bu liderin zirvesine ağırlık noktası denir.
Sıralama Mankeni: Doğrulayıcılar, hangi mankenlerin sıralanacağına veya atlanacağına bağımsız ancak belirleyici bir şekilde karar verir.
Neden-sonuç tarihini sıralama: Doğrulayıcılar sırasıyla düzenli bir referans noktası listesini işler, her referans noktasının neden-sonuç tarihindeki daha önce sıralanmamış düğümleri sıralar.
Güvenliğin anahtarı, tüm dürüst doğrulayıcı düğümlerin oluşturduğu sıralı referans noktası listesinin aynı öneki paylaşmasını sağlamaktır. Shoal, bu protokollerin hepsi hakkında önemli bir gözlemde bulunur: Tüm doğrulayıcılar ilk sıralı referans noktasında hemfikirdir.
Bullshark'ın Gecikme Sorunu
Bullshark'ın gecikmesi, DAG'deki sıralı referans noktaları arasındaki döngü sayısına bağlıdır. Kısmi senkronize versiyonlar, asenkron versiyonlardan daha düşük gecikmeye sahip olsa da, yine de optimumdan uzak.
İki ana sorun var:
Ortalama blok gecikmesi: Yaygın durumlarda, tek sıra noktalarının sıralanması için üç tur, çift sıra olmayan noktaların sıralanması için dört tur gerekmektedir.
Arıza Durumu Gecikmesi: Eğer bir turdaki lider, sabit noktayı zamanında yayınlayamazsa, bu sabit nokta atlanacaktır ve önceki turlardaki sıralanmamış tüm köşe noktaları bir sonraki sabit noktanın sıralanmasını beklemek zorunda kalacaktır. Bu, coğrafi olarak dağıtılmış ağın performansını önemli ölçüde düşürmektedir, özellikle de Bullshark lideri beklemek için zaman aşımını kullandığı için.
![Binlerce kelimeyle Shoal çerçevesinin ayrıntılı açıklaması: Aptos'taki Bullshark gecikmesini nasıl azaltır?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Shoal Çerçevesi
Shoal, Bullshark) veya herhangi bir Narwhal tabanlı BFT protokolünü ( güçlendirmek için bir hattın akışını kullanarak her turda bir referans noktası olmasını sağlar ve tüm referans noktası olmayan düğümlerin gecikmesini üç tura düşürür. Shoal ayrıca DAG içinde sıfır maliyetli bir lider itibar mekanizması tanıtarak hızlı liderlerin seçilmesini teşvik eder.
) meydan okuma
DAG protokolünde boru hattı ve liderin itibarını uygulamak zor olarak kabul edilmektedir:
Daha önce Bullshark'ın temel mantığını değiştirmeye çalışmak mümkün görünmüyordu.
Liderlerin itibarları farklı sıralamalara neden olabilir ve doğrulayıcıların, gelecek referans noktalarını seçmek için sıralı bir tarih üzerinde uzlaşmaları gerekmektedir.
Bir sorun zorluğu kanıtı olarak, mevcut üretim ortamındaki Bullshark uygulamaları bu özellikleri desteklememektedir.
Protokol
Shoal'un çözümü oldukça basittir. Yerel hesaplamaların DAG üzerinde gerçekleştirilme yeteneğinden yararlanarak, önceki turların bilgilerini saklama ve yeniden yorumlama işlevini yerine getirir. Tüm doğrulayıcıların ilk sıralı çivinin içgörüsüne katılmasına dayanan Shoal, birden fazla Bullshark örneğini sıralı olarak birleştirerek boru hattı işlemi gerçekleştirir, bu da:
Akış Hattı
V. Shoal, her bir örneğin bir sabit nokta sıraladığı ve bir sonraki örneğe geçişi tetiklediği Bullshark örneklerini sıralı bir şekilde çalıştırır.
Shoal, DAG'ın ilk turunda Bullshark'ın ilk örneğini başlatarak, ilk sıralı ankraj noktası ###'i belirleyene kadar devam eder ve r turunda ( varsayılır. Tüm doğrulayıcılar bu ankraj noktasında hemfikir olduğundan, r+1 turundan itibaren DAG'ı yeniden yorumlamak için kesin bir şekilde hemfikir olabilirler. Shoal, r+1 turunda yeni bir Bullshark örneğini başlatır.
İdeal koşullarda, bu Shoal'in her turda bir referans noktası sıralamasına izin verir. İlk tur referans noktası ilk örnek tarafından sıralanır, ardından ikinci turda yeni örnek o tur referans noktasını sıralar, böylece devam eder.
![万字详解Shoal框架：如何减少Aptos上的Bullshark延迟？])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
) Lider Reputasyonu
Bullshark, ankraj noktasını atladığında gecikme artar. Bu durumda, önceki örneğin sıralama noktasını beklemek zorunda olduğundan, hat çekme tekniği etkisizdir. Shoal, her doğrulayıcı düğüm için son etkinlik tarihine göre bir puan tahsis etmek için bir itibar mekanizması kullanır. Hızlı yanıt veren doğrulayıcılar yüksek puan alırken, aksi takdirde düşük puan alır.
Felsefe, her puan güncellemesinde, yüksek puan liderlerine yönelerek, turlar ile liderler arasındaki F haritasını belirli bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni harita üzerinde uzlaşabilmeleri için puan üzerinde uzlaşmaları ve ardından puan türetmek için kullanılan geçmişte uzlaşmaları gerekmektedir.
Shoal'da, akış hattı ve liderin itibarı doğal olarak birleşebilir, çünkü her ikisi de ilk sıralı sabit nokta üzerinde uzlaşıldıktan sonra DAG'ı yeniden yorumlamaya dayanmaktadır. Tek fark, r'inci tur sabit noktasından sonra, doğrulayıcılar bu sabit noktanın nedensel tarihine göre r+1'inci turdan itibaren yeni haritalama F'yi hesaplamaya başlamasıdır. Ardından r+1'inci turdan itibaren güncellenmiş F' ile yeni Bullshark örnekleri uygulanır.
![Binlerce kelimeyle Shoal çerçevesi: Aptos'taki Bullshark gecikmesini nasıl azaltır?]###https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
) Zaman aşımını kaldır
Zaman aşımı, tüm lider tabanlı belirleyici kısmi senkronize BFT uygulamalarında kritik öneme sahiptir. Ancak, bunlar karmaşıklığı artırır, daha fazla iç durum yönetimi ve gözlem gerektirir, bu da hata ayıklamayı daha zor hale getirir.
Zaman aşımı, doğru yapılandırmanın önemli olmasından ve genellikle dinamik ayarlamalar gerektirmesinden dolayı gecikmeyi önemli ölçüde artıracaktır. Protokol, bir sonraki lider değişimine geçmeden önce arızalı lider için tam zaman aşımı gecikme cezasını ödemek zorundadır. Bu nedenle, zaman aşımı ayarları çok temkinli olmamalıdır, ancak çok kısa olursa iyi liderlerin atlanmasına neden olabilir.
Ne yazık ki, lider bazlı protokoller ###, Hotstuff ve Jolteon ( esasen ilerleme sağlamak için zaman aşımına ihtiyaç duyar. Zaman aşımı olmadan, çökme durumundaki bir lider bile protokolü sonsuza dek durdurabilir. Asenkron dönemlerde, çökme ile yavaş lideri ayırt edilemediğinden, zaman aşımı, doğrulama düğümlerinin konsensüs aktifliği olmadan tüm liderleri değiştirmesine neden olabilir.
Bullshark'ta, DAG yapımı için zaman aşımı kullanılır, böylece senkronizasyon sırasında dürüst liderlerin sıralama için DAG'a yeterince hızlı şekilde referans noktaları eklemesini sağlar.
DAG inşa etmenin bir "saat" olarak ağ hızını tahmin ettiğini gözlemledik. n-f kadar dürüst doğrulayıcı DAG'a zirve eklemeye devam ettiği sürece, turlar ilerleyecektir. Bullshark ağ hızında sıralama yapamayabilir, ancak DAG hala ağ hızında büyümektedir. Sonunda, hatasız bir lider yeterince hızlı bir şekilde referans noktalarını yayınladığında, referans noktasının tüm nedensel tarihi sıralanacak.
Değerlendirme sırasında, zaman aşımı olup olmadığını Bullshark ile karşılaştırdık:
Hızlı Liderler: İki yöntem aynı gecikmeyi gösterir, çünkü referans noktaları sıralanmıştır ve zaman aşımı kullanılmamaktadır.
Yanlış Liderler: Süresiz Bullshark gecikmesi daha düşük, çünkü doğrulayıcı düğümler hemen sabit noktalarını atlayacak.
Yavaş liderler: Süre aşımı olan Bullshark daha iyi performans gösterir, çünkü doğrulayıcılar referans noktasını beklerken, süre aşımı olmayanlar referans noktasını atlayabilir.
Shoal'da, zaman aşımından kaçınmak liderlerin itibarı ile yakından ilişkilidir. Yavaş liderleri beklemek, gecikmeyi artırırken, itibar mekanizması yavaş doğrulayıcıların lider olarak seçilmesini dışlar. Böylece, sistem tüm gerçek senaryolarda ağ hızında çalışabilir.
Dikkat edilmesi gereken nokta, FLP imkansızlık sonucunun belirli bir konsensüs protokolünün zaman aşımını tamamen önleyemeyeceğini göstermesidir. Shoal bu sonucu aşamaz, çünkü teorik olarak tüm köprü noktalarının sıralanmasını engelleyebilecek düşmanca olay zaman çizelgeleri vardır. Aksine, yapılandırılabilir sürekli atlanan köprü noktası sayısından sonra, Shoal zaman aşımına geri döner. Ancak pratikte bu durumun meydana gelmesi son derece olası değildir.
) Genel Yanıt Verme
Hotstuff makalesi, iyimser yanıt kavramını yaygınlaştırdı; bu, protokolün iyi koşullarda ### hızlı liderler ve senkronize ağlar içerebileceği anlamına gelir ve ( ağ hızında çalışır.
Shoal, evrensel yanıt verme adı verilen daha iyi bir özellik sunar. Özellikle, Hotstuff ile karşılaştırıldığında, lider belirli bir yapılandırılabilir ardışık tur sayısı içinde başarısız olsa bile veya ağ asenkron dönemler yaşasa bile, Shoal ağ hızında çalışmaya devam eder.
Yaygın yanıt verilebilirlik, asenkron dönemlerde ve lider arızaları sırasında katı bir şekilde daha iyi ilerleme garantisi sağlar. Yavaş liderle senkronize olurken, bu özellikler doğrudan karşılaştırılamaz, çünkü liderin hızına bağlıdır. Ancak liderin itibar mekanizması göz önüne alındığında, Shoal'daki yavaş liderlerin çok az ortaya çıkması gerekir.
![Bin kelime ile Shoal çerçevesi: Nasıl azalt