Shoal çerçevesi: Aptos'taki Bullshark gecikme süresini büyük ölçüde azaltma
Genel Bakış
Aptos laboratuvarları, DAG BFT içindeki iki önemli açık sorunu çözdü, gecikme süresini önemli ölçüde azalttı ve ilk kez, belirleyici gerçek protokollerde zaman aşımı gereksinimini ortadan kaldırdı. Genel olarak, hatasız durumlarda Bullshark'ın gecikme süresini %40 oranında iyileştirirken, arızalı durumlarda %80 oranında iyileştirdi.
Shoal, Narwhal tabanlı herhangi bir konsensüs protokolünü güçlendiren bir çerçevedir; bu çerçeve, her turda bir referans noktası tanıtarak DAG sıralama gecikmesini azaltmak için bir akış hattı kullanır. Liderin itibarı, referans noktasının en hızlı doğrulama düğümleri ile ilişkilendirilmesini sağlayarak gecikme sorununu 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. Bu, Shoal'ın genellikle gerekli olan iyimser yanıtlarla birlikte evrensel yanıt özellikleri sunmasına olanak tanır.
Bu teknoloji oldukça basit, alt protokollerin birden fazla örneğinin sırayla çalıştırılmasını içeriyor. Bu nedenle, Bullshark ile örneklendirildiğinde, bir grup devam eden bayrak yarışı yapan "köpekbalığı" elde ediyoruz.
Motivasyon
Blok zinciri ağlarının yüksek performansını hedeflerken, insanlar iletişim karmaşıklığını azaltmaya odaklanmışlardır. Ancak, bu yaklaşım önemli bir throughput artışı sağlamamıştır. Örneğin, Diem'in erken versiyonlarında uygulanan Hotstuff yalnızca 3500 TPS'ye ulaşmış, 100k+ TPS hedefinin oldukça altında kalmıştır.
Son zamanlardaki atılım, veri yayılımının liderlik protokollerine dayalı ana darboğaz olduğunu anlamaktan kaynaklanmaktadır ve paralelleşmeden faydalanabilir. Narwhal sistemi, veri yayılımını konsensüs mantığından ayırarak, tüm doğrulayıcıların aynı anda veri yaydığı bir mimari önermektedir; konsensüs bileşeni yalnızca az sayıda meta veriyi sıralar. Narwhal makalesi, 160.000 TPS'lik bir verimliliği rapor etmektedir.
Daha önce Quorum Store'u tanıttık, Narwhal uygulamamız verilerin yayılmasını ve konsensüsü ayırıyor ve bunu mevcut konsensüs protokolü Jolteon'u ölçeklendirmek için nasıl kullanacağımızı anlattı. Jolteon, Tendermint'in lineer hızlı yolu ve PBFT tarzı görünüm değişikliklerini birleştiren liderlik tabanlı bir protokoldür ve Hotstuff gecikmesini %33 oranında azaltır. Ancak, liderlik tabanlı konsensüs protokolleri Narwhal'ın işlem hacmi potansiyelinden yeterince yararlanamaz. Verilerin yayılmasını ve konsensüsü ayırmış olsak da, işlem hacmi arttıkça Hotstuff/Jolteon'un liderleri hala sınırlı kalmaktadır.
Bu nedenle, Bullshark'ı, sıfır iletişim maliyetine sahip bir konsensüs protokolü olan Narwhal DAG'ın üzerine dağıtmaya karar verdik. Ne yazık ki, Jolteon'a kıyasla, Bullshark'ı destekleyen yüksek verimlilikteki DAG yapısı %50 gecikme süresi maliyeti getirdi.
Bu makalede Shoal'ın Bullshark gecikme süresini önemli ölçüde nasıl azalttığı anlatılmaktadır.
DAG-BFT Arka Planı
Narwhal DAG'daki her bir zirve, bir tur ile ilişkilendirilmiştir. r. tura girmek için, doğrulayıcıların öncelikle r-1. tura ait n-f kadar zirve edinmesi gerekmektedir. Her doğrulayıcı her turda bir zirve yayınlayabilir ve her zirve, en azından bir önceki turun n-f kadar zirvesini referans almalıdır. Ağın asenkron olması nedeniyle, farklı doğrulayıcılar herhangi bir anda 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ına v sahipse, o zaman v'nin neden-sonuç geçmişleri tamamen aynıdır.
Genel Giriş
Tüm DAG düğümlerinin toplam sırası üzerinde ek iletişim maliyeti olmadan mutabakata varılabilir. 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 oylamaları 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:
Rezervasyon noktası: Her birkaç turda bir önceden belirlenmiş bir lider vardır, liderin zirvesine rezervasyon noktası denir;
Sipariş Düğümü: Doğrulayıcılar bağımsız ancak belirleyici bir şekilde hangi düğümleri sipariş edeceklerine ve hangi düğümleri atlayacaklarına karar verir;
Sipariş Nedensellik Tarihi: Doğrulayıcılar sırayla her bir sabit nokta listesini işler ve her sabit noktanın nedensellik 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 listesi oluşturmasını sağlamaktır. Shoal'da, yukarıda belirtilen tüm protokollerle ilgili aşağıdaki gözlemleri yaptık:
Tüm doğrulayıcılar ilk sıralı referans noktasını kabul eder.
Bullshark gecikme süresi
Bullshark'ın gecikme süresi, DAG'daki sıralı çapa noktaları arasındaki tur sayısına bağlıdır. Bullshark'ın en kullanışlı kısım senkron sürümünün, asenkron sürüme göre daha iyi bir gecikmeye sahip olmasına rağmen, en iyi durumdan uzak.
Soru 1: Ortalama blok gecikme süresi. Bullshark'ta her çift turda bir ana nokta vardır, her tek turda ise zirve oylama olarak yorumlanır. Yaygın durumda, 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 durumda, tek turlardaki zirveler üç tura, çift turlardaki ana nokta 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ı yayamazsa, referans noktası sıralanamaz ( bu nedenle atlanır ), bu nedenle önceki turlardaki sıralanmamış tüm zirvelerin bir sonraki referans noktasının sıralanmasını beklemesi gerekir. Bu, coğrafi çoğaltma ağının performansını önemli ölçüde azaltır, özellikle Bullshark zaman aşımı lideri beklemek için kullanıldığında.
Shoal çerçevesi
Shoal, bu iki gecikme süresi sorununu çözdü. Bullshark( veya diğer Narwhal tabanlı BFT protokollerini ), her turda bir ana nokta olmasını sağlayarak ve DAG'deki tüm ana nokta olmayan düğümlerin gecikmesini üç tura indirerek iyileştirdi. Shoal ayrıca DAG'de sıfır maliyetli lider itibar mekanizmasını tanıttı, bu da seçimin hızlı liderler lehine olmasını sağladı.
Mücadele
DAG protokolü bağlamında, boru hattı ve liderin itibarı zor bir sorun olarak kabul edilmektedir, nedenleri şunlardır:
Önceki hattaki denemeler, temel Bullshark mantığını değiştirmeye çalıştı, ancak bu özünde imkansız gibi görünüyor.
Liderlerin itibarı DiemBFT'ye entegre edilmiş ve Carousel'de resmileştirilmiştir; bu, doğrulayıcıların geçmiş performanslarına dayalı olarak gelecekteki liderleri dinamik olarak seçme fikridir. Liderlik kimliğinde bir ayrımcılığın bu protokollerin güvenliğini ihlal etmemesi mümkündür, ancak Bullshark'ta bu tamamen farklı bir sıralama ile sonuçlanabilir. Bu, sorunun özüne işaret eder; yani, döngüsel referansları dinamik ve belirli bir şekilde seçmek konsensüs sağlamak için gereklidir ve doğrulayıcıların gelecekteki referansları seçmek için sıralı tarih üzerinde uzlaşmaları gerekir.
Soru zorluğunun bir kanıtı olarak, Bullshark'ın uygulamasına dikkat çekiyoruz; şu anda üretim ortamında bulunan uygulama, bu özellikleri desteklememektedir.
Protokol
Yukarıda belirtilen zorluklara rağmen, eski bir deyimde 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 saklama ve yeniden yorumlama yeteneğini gerçekleştirdik. Tüm doğrulayıcıların ilk sıralı referans noktasını kabul etmesiyle Shoal, birden fazla Bullshark örneğini sıralı bir şekilde birleştirerek onları işleme alır; böylece ( ilk sıralı referans noktası örneklerin geçiş noktasıdır ve ) referans noktası için nedensel tarih liderin itibarını hesaplamak için kullanılır.
Akış Hattı
V fonksiyonu vardır. Shoal, her bir örnek için F haritası ile önceden belirlenen bir bağlantı ile Bullshark'ın örneklerini sırayla çalıştırır. Her örnek bir bağlantı sipariş eder ve bu, bir sonraki örneğe geçişi tetikler.
Başlangıçta, Shoal, DAG'ın ilk aşamasında Bullshark'ın ilk örneğini başlattı ve bu örneği ilk sıralı bağlantı noktası belirlenene kadar çalıştırdı, örneğin r. aşamada. Tüm doğrulayıcılar bu bağlantı noktasında hemfikir oldu. Bu nedenle, tüm doğrulayıcılar, r+1. aşamadan itibaren DAG'ı yeniden yorumlamak konusunda kesin bir şekilde hemfikir olabilirler. Shoal, yalnızca r+1. aşamada 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 örnek kendi içinde bir çapa noktası bulundurur, bu çapa da o örneğe göre sıralanır, sonra üçüncü turda başka bir yeni örnek çapa noktası sipariş eder ve süreç devam eder.
Liderlerin İtibarı
Bullshark sıralama sürecinde bir ankraj noktası atlandığında, gecikme süresi artar. Bu durumda, önceki örnekteki ankraj noktasından önce yeni bir örneğin başlatılması mümkün olmadığından, boru hattı teknolojisi etkisizdir. Shoal, her doğrulama düğümünün en son etkinlik tarihine göre 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 alırken, aksi takdirde doğrulama düğümleri düşük puan alacaktır, çünkü bu düğümler çökmüş, yavaş veya kötü niyetli olabilir.
Bu yaklaşım, her puan güncellemesi sırasında, daha yüksek puan alan liderlere eğilim göstererek, tura göre liderlere önceden tanımlanmış F eşlemesini belirli bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni eşleme üzerinde uzlaşabilmeleri için, puanlar üzerinde uzlaşmaları ve böylece puan türetme tarihinde uzlaşmaları gerekmektedir.
Shoal'da, hat ve liderlik itibarı doğal olarak bir araya gelebilir, çünkü her ikisi de ilk sıralı ayak noktasında uzlaşma sağlandı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 yalnızca r. turda sıralı referans noktalarının nedensel tarihine dayanarak r+1. turdan itibaren yeni bir F' haritalaması hesaplaması gerektiğidir. Ardından, doğrulayıcı düğümleri r+1. turdan itibaren güncellenmiş referans noktası seçim fonksiyonu F'yi kullanarak Bullshark'ın yeni bir örneğini gerçekleştirir.
Daha fazla zaman aşımı yok
Zaman aşımı, lider bazlı 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ı, gecikme süresini önemli ölçüde artırabilir, çünkü bunları uygun şekilde yapılandırmak çok önemlidir ve genellikle dinamik olarak ayarlamak gerekir, çünkü bu, çevre ( ağına ) büyük ölçüde bağımlıdır. Protokol, bir sonraki liderliğe geçmeden önce arızalı lider için tam zaman aşımı gecikme cezası öder. Bu nedenle, zaman aşımı ayarları fazla temkinli olmamalıdır, ancak eğer zaman aşımı süresi çok kısa olursa, protokol iyi liderleri atlayabilir. Örneğin, yüksek yük durumlarında, Jolteon/Hotstuff içindeki liderlerin aşırı yüklendiğini ve ilerlemeyi sağlamadan önce zaman aşımının sona erdiğini gözlemledik.
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.
7 Likes
Reward
7
5
Share
Comment
0/400
SchrodingersFOMO
· 08-05 13:55
gecikme süresi düşüyor bu kadar boğa boğa
View OriginalReply0
SchroedingerMiner
· 08-05 12:20
Bu hız, evdeki Mining Ekipmanı'nın sıcaklığından daha hızlı yükseliyor.
View OriginalReply0
MEVSandwich
· 08-03 18:14
gecikme süresi bu kadar düştü, Aya doğru gidiyor gibi hissediyorum.
Shoal çerçevesi Aptos üzerindeki Bullshark performansını büyük ölçüde artırdı, gecikme süresi %40-80 düştü.
Shoal çerçevesi: Aptos'taki Bullshark gecikme süresini büyük ölçüde azaltma
Genel Bakış
Aptos laboratuvarları, DAG BFT içindeki iki önemli açık sorunu çözdü, gecikme süresini önemli ölçüde azalttı ve ilk kez, belirleyici gerçek protokollerde zaman aşımı gereksinimini ortadan kaldırdı. Genel olarak, hatasız durumlarda Bullshark'ın gecikme süresini %40 oranında iyileştirirken, arızalı durumlarda %80 oranında iyileştirdi.
Shoal, Narwhal tabanlı herhangi bir konsensüs protokolünü güçlendiren bir çerçevedir; bu çerçeve, her turda bir referans noktası tanıtarak DAG sıralama gecikmesini azaltmak için bir akış hattı kullanır. Liderin itibarı, referans noktasının en hızlı doğrulama düğümleri ile ilişkilendirilmesini sağlayarak gecikme sorununu 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. Bu, Shoal'ın genellikle gerekli olan iyimser yanıtlarla birlikte evrensel yanıt özellikleri sunmasına olanak tanır.
Bu teknoloji oldukça basit, alt protokollerin birden fazla örneğinin sırayla çalıştırılmasını içeriyor. Bu nedenle, Bullshark ile örneklendirildiğinde, bir grup devam eden bayrak yarışı yapan "köpekbalığı" elde ediyoruz.
Motivasyon
Blok zinciri ağlarının yüksek performansını hedeflerken, insanlar iletişim karmaşıklığını azaltmaya odaklanmışlardır. Ancak, bu yaklaşım önemli bir throughput artışı sağlamamıştır. Örneğin, Diem'in erken versiyonlarında uygulanan Hotstuff yalnızca 3500 TPS'ye ulaşmış, 100k+ TPS hedefinin oldukça altında kalmıştır.
Son zamanlardaki atılım, veri yayılımının liderlik protokollerine dayalı ana darboğaz olduğunu anlamaktan kaynaklanmaktadır ve paralelleşmeden faydalanabilir. Narwhal sistemi, veri yayılımını konsensüs mantığından ayırarak, tüm doğrulayıcıların aynı anda veri yaydığı bir mimari önermektedir; konsensüs bileşeni yalnızca az sayıda meta veriyi sıralar. Narwhal makalesi, 160.000 TPS'lik bir verimliliği rapor etmektedir.
Daha önce Quorum Store'u tanıttık, Narwhal uygulamamız verilerin yayılmasını ve konsensüsü ayırıyor ve bunu mevcut konsensüs protokolü Jolteon'u ölçeklendirmek için nasıl kullanacağımızı anlattı. Jolteon, Tendermint'in lineer hızlı yolu ve PBFT tarzı görünüm değişikliklerini birleştiren liderlik tabanlı bir protokoldür ve Hotstuff gecikmesini %33 oranında azaltır. Ancak, liderlik tabanlı konsensüs protokolleri Narwhal'ın işlem hacmi potansiyelinden yeterince yararlanamaz. Verilerin yayılmasını ve konsensüsü ayırmış olsak da, işlem hacmi arttıkça Hotstuff/Jolteon'un liderleri hala sınırlı kalmaktadır.
Bu nedenle, Bullshark'ı, sıfır iletişim maliyetine sahip bir konsensüs protokolü olan Narwhal DAG'ın üzerine dağıtmaya karar verdik. Ne yazık ki, Jolteon'a kıyasla, Bullshark'ı destekleyen yüksek verimlilikteki DAG yapısı %50 gecikme süresi maliyeti getirdi.
Bu makalede Shoal'ın Bullshark gecikme süresini önemli ölçüde nasıl azalttığı anlatılmaktadır.
DAG-BFT Arka Planı
Narwhal DAG'daki her bir zirve, bir tur ile ilişkilendirilmiştir. r. tura girmek için, doğrulayıcıların öncelikle r-1. tura ait n-f kadar zirve edinmesi gerekmektedir. Her doğrulayıcı her turda bir zirve yayınlayabilir ve her zirve, en azından bir önceki turun n-f kadar zirvesini referans almalıdır. Ağın asenkron olması nedeniyle, farklı doğrulayıcılar herhangi bir anda 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ına v sahipse, o zaman v'nin neden-sonuç geçmişleri tamamen aynıdır.
Genel Giriş
Tüm DAG düğümlerinin toplam sırası üzerinde ek iletişim maliyeti olmadan mutabakata varılabilir. 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 oylamaları 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:
Rezervasyon noktası: Her birkaç turda bir önceden belirlenmiş bir lider vardır, liderin zirvesine rezervasyon noktası denir;
Sipariş Düğümü: Doğrulayıcılar bağımsız ancak belirleyici bir şekilde hangi düğümleri sipariş edeceklerine ve hangi düğümleri atlayacaklarına karar verir;
Sipariş Nedensellik Tarihi: Doğrulayıcılar sırayla her bir sabit nokta listesini işler ve her sabit noktanın nedensellik 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 listesi oluşturmasını sağlamaktır. Shoal'da, yukarıda belirtilen tüm protokollerle ilgili aşağıdaki gözlemleri yaptık:
Tüm doğrulayıcılar ilk sıralı referans noktasını kabul eder.
Bullshark gecikme süresi
Bullshark'ın gecikme süresi, DAG'daki sıralı çapa noktaları arasındaki tur sayısına bağlıdır. Bullshark'ın en kullanışlı kısım senkron sürümünün, asenkron sürüme göre daha iyi bir gecikmeye sahip olmasına rağmen, en iyi durumdan uzak.
Soru 1: Ortalama blok gecikme süresi. Bullshark'ta her çift turda bir ana nokta vardır, her tek turda ise zirve oylama olarak yorumlanır. Yaygın durumda, 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 durumda, tek turlardaki zirveler üç tura, çift turlardaki ana nokta 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ı yayamazsa, referans noktası sıralanamaz ( bu nedenle atlanır ), bu nedenle önceki turlardaki sıralanmamış tüm zirvelerin bir sonraki referans noktasının sıralanmasını beklemesi gerekir. Bu, coğrafi çoğaltma ağının performansını önemli ölçüde azaltır, özellikle Bullshark zaman aşımı lideri beklemek için kullanıldığında.
Shoal çerçevesi
Shoal, bu iki gecikme süresi sorununu çözdü. Bullshark( veya diğer Narwhal tabanlı BFT protokollerini ), her turda bir ana nokta olmasını sağlayarak ve DAG'deki tüm ana nokta olmayan düğümlerin gecikmesini üç tura indirerek iyileştirdi. Shoal ayrıca DAG'de sıfır maliyetli lider itibar mekanizmasını tanıttı, bu da seçimin hızlı liderler lehine olmasını sağladı.
Mücadele
DAG protokolü bağlamında, boru hattı ve liderin itibarı zor bir sorun olarak kabul edilmektedir, nedenleri şunlardır:
Önceki hattaki denemeler, temel Bullshark mantığını değiştirmeye çalıştı, ancak bu özünde imkansız gibi görünüyor.
Liderlerin itibarı DiemBFT'ye entegre edilmiş ve Carousel'de resmileştirilmiştir; bu, doğrulayıcıların geçmiş performanslarına dayalı olarak gelecekteki liderleri dinamik olarak seçme fikridir. Liderlik kimliğinde bir ayrımcılığın bu protokollerin güvenliğini ihlal etmemesi mümkündür, ancak Bullshark'ta bu tamamen farklı bir sıralama ile sonuçlanabilir. Bu, sorunun özüne işaret eder; yani, döngüsel referansları dinamik ve belirli bir şekilde seçmek konsensüs sağlamak için gereklidir ve doğrulayıcıların gelecekteki referansları seçmek için sıralı tarih üzerinde uzlaşmaları gerekir.
Soru zorluğunun bir kanıtı olarak, Bullshark'ın uygulamasına dikkat çekiyoruz; şu anda üretim ortamında bulunan uygulama, bu özellikleri desteklememektedir.
Protokol
Yukarıda belirtilen zorluklara rağmen, eski bir deyimde 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 saklama ve yeniden yorumlama yeteneğini gerçekleştirdik. Tüm doğrulayıcıların ilk sıralı referans noktasını kabul etmesiyle Shoal, birden fazla Bullshark örneğini sıralı bir şekilde birleştirerek onları işleme alır; böylece ( ilk sıralı referans noktası örneklerin geçiş noktasıdır ve ) referans noktası için nedensel tarih liderin itibarını hesaplamak için kullanılır.
Akış Hattı
V fonksiyonu vardır. Shoal, her bir örnek için F haritası ile önceden belirlenen bir bağlantı ile Bullshark'ın örneklerini sırayla çalıştırır. Her örnek bir bağlantı sipariş eder ve bu, bir sonraki örneğe geçişi tetikler.
Başlangıçta, Shoal, DAG'ın ilk aşamasında Bullshark'ın ilk örneğini başlattı ve bu örneği ilk sıralı bağlantı noktası belirlenene kadar çalıştırdı, örneğin r. aşamada. Tüm doğrulayıcılar bu bağlantı noktasında hemfikir oldu. Bu nedenle, tüm doğrulayıcılar, r+1. aşamadan itibaren DAG'ı yeniden yorumlamak konusunda kesin bir şekilde hemfikir olabilirler. Shoal, yalnızca r+1. aşamada 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 örnek kendi içinde bir çapa noktası bulundurur, bu çapa da o örneğe göre sıralanır, sonra üçüncü turda başka bir yeni örnek çapa noktası sipariş eder ve süreç devam eder.
Liderlerin İtibarı
Bullshark sıralama sürecinde bir ankraj noktası atlandığında, gecikme süresi artar. Bu durumda, önceki örnekteki ankraj noktasından önce yeni bir örneğin başlatılması mümkün olmadığından, boru hattı teknolojisi etkisizdir. Shoal, her doğrulama düğümünün en son etkinlik tarihine göre 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 alırken, aksi takdirde doğrulama düğümleri düşük puan alacaktır, çünkü bu düğümler çökmüş, yavaş veya kötü niyetli olabilir.
Bu yaklaşım, her puan güncellemesi sırasında, daha yüksek puan alan liderlere eğilim göstererek, tura göre liderlere önceden tanımlanmış F eşlemesini belirli bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni eşleme üzerinde uzlaşabilmeleri için, puanlar üzerinde uzlaşmaları ve böylece puan türetme tarihinde uzlaşmaları gerekmektedir.
Shoal'da, hat ve liderlik itibarı doğal olarak bir araya gelebilir, çünkü her ikisi de ilk sıralı ayak noktasında uzlaşma sağlandı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 yalnızca r. turda sıralı referans noktalarının nedensel tarihine dayanarak r+1. turdan itibaren yeni bir F' haritalaması hesaplaması gerektiğidir. Ardından, doğrulayıcı düğümleri r+1. turdan itibaren güncellenmiş referans noktası seçim fonksiyonu F'yi kullanarak Bullshark'ın yeni bir örneğini gerçekleştirir.
Daha fazla zaman aşımı yok
Zaman aşımı, lider bazlı 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ı, gecikme süresini önemli ölçüde artırabilir, çünkü bunları uygun şekilde yapılandırmak çok önemlidir ve genellikle dinamik olarak ayarlamak gerekir, çünkü bu, çevre ( ağına ) büyük ölçüde bağımlıdır. Protokol, bir sonraki liderliğe geçmeden önce arızalı lider için tam zaman aşımı gecikme cezası öder. Bu nedenle, zaman aşımı ayarları fazla temkinli olmamalıdır, ancak eğer zaman aşımı süresi çok kısa olursa, protokol iyi liderleri atlayabilir. Örneğin, yüksek yük durumlarında, Jolteon/Hotstuff içindeki liderlerin aşırı yüklendiğini ve ilerlemeyi sağlamadan önce zaman aşımının sona erdiğini gözlemledik.
talihsiz