Shoal çerçevesi: Aptos'ta Bullshark'ın gecikme süresini nasıl azaltır?

Aptos Labs, yakın zamanda DAG BFT'deki iki önemli açık sorunu çözdü, gecikme süresini önemli ölçüde azalttı ve ilk kez belirli gerçek protokollerde zaman aşımı gereksinimini ortadan kaldırdı. Genel olarak, hatasız durumlarda Bullshark'ın gecikme süresini %40, arızalı durumlarda ise %80 oranında iyileştirdi.

Shoal, Narwhal tabanlı konsensüs protokolünü ( gibi DAG-Rider, Tusk, Bullshark ) artırmak için bir çerçevedir ve akış hattı işleme ile liderin itibar mekanizmasını kullanır. Akış hattı işleme, her turda bir referans noktası ekleyerek DAG sıralama gecikmesini azaltır, liderin itibar mekanizması ise referans noktalarının en hızlı doğrulama düğümleri ile ilişkilendirilmesini sağlayarak gecikme sorununu daha da iyileştirir. Ayrıca, liderin itibar mekanizması, Shoal'ın tüm senaryolar içinde zaman aşımını ortadan kaldırmak için asenkron DAG yapılandırmasını kullanmasına olanak tanır. Bu, Shoal'ın genellikle gereken iyimser yanıtları içeren evrensel yanıt özellikleri sunmasını sağlar.

Bu teknoloji oldukça basit olup, alt protokollerin birden fazla örneğinin sıralı bir şekilde çalıştırılmasını içerir. Bu nedenle, Bullshark örneği kullanıldığında, bir grup "köpekbalığı"nın bayrak yarışı yaptığı bir durumla karşılaşıyoruz.

Arka plan

Blok zinciri ağlarının yüksek performansını hedeflerken, iletişim karmaşıklığını azaltmaya yönelik bir ilgi olmuştur. Ancak, bu yaklaşım belirgin bir işlem hacmi artışı sağlamamıştır. Örneğin, Diem'in erken versiyonunda uygulanan Hotstuff sadece 3500 TPS'ye ulaşmış, 100.000+ TPS hedefine çok uzak kalmıştır.

Son dönemdeki atılım, veri yayılımının liderlerin protokollerine dayandığını ve paralelleşmeden fayda sağlanabileceğ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 aynı anda veri yaydığı ve konsensüs bileşeninin yalnızca az sayıda meta veriyi sıraladığı bir mimari öneriyor. Narwhal makalesi, 160.000 TPS'lik bir verimlilik rapor ediyor.

Aptos daha önce Quorum Store'u, yani Narwhal'ın uygulamasını tanıttı, verilerin yayılması ile mutabakatı ayırarak ve bunu mevcut mutabakat protokolü Jolteon'u genişletmek için nasıl kullanacağını açıkladı. Jolteon, Tendermint'in doğrusal hızlı yolu ile PBFT tarzı görünüm değişikliklerini birleştiren lider tabanlı bir protokoldür ve Hotstuff gecikmesini %33 oranında azaltabilir. Ancak, lider tabanlı mutabakat protokolleri, Narwhal'ın işlem hacmi potansiyelini tam olarak kullanamıyor. Verilerin yayılmasını ve mutabakatı ayırmış olsalar da, işlem hacmi arttıkça, Hotstuff/Jolteon'un liderleri hala sınırlı kalmaktadır.

Bu nedenle, Aptos, sıfır iletişim maliyetine sahip bir konsensüs protokolü olan Bullshark'ı Narwhal DAG'ın üzerine dağıtmaya karar verdi. Ne yazık ki, Jolteon'a kıyasla, Bullshark yüksek throughput'u destekleyen DAG yapısı %50 gecikme süresi maliyeti getirdi.

Bu makalede Shoal'ın Bullshark gecikme süresini nasıl önemli ölçüde azalttığı anlatılmaktadır.

DAG-BFT Arka Planı

Narwhal DAG'daki her bir tepe noktası bir tur ile ilişkilidir. r turuna girmek için, doğrulayıcı öncelikle r-1 turuna ait n-f tepe noktasını elde etmelidir. 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 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 belirsizlik olmamasıdır: Eğer iki doğrulayıcı düğüm, DAG yerel görünümlerinde aynı tepe v'ye sahipse, o zaman v'nin nedensel tarihi tamamen aynıdır.

Genel Giriş

DAG'daki tüm düğümlerin toplam sırası, ek iletişim maliyeti olmadan bir araya getirilebilir. Bunun için, DAG-Rider, Tusk ve Bullshark'taki doğrulayıcılar, DAG yapısını bir konsensüs protokolü olarak yorumlar; burada düğümler önerileri, kenarlar ise oyları temsil eder.

DAG yapısındaki topluluk kesişim mantığı farklı olsa da, mevcut tüm Narwhal tabanlı konsensüs protokollerinin aşağıdaki yapıya sahip olduğu söylenebilir:

1. Ayarlanmış Aşama: Belirli aralıklarla ( örneğin, Bullshark'taki iki tur )'da önceden belirlenmiş bir lider olacak, liderin zirvesine aşama denir.

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

3. Neden-sonuç tarihini sıralama: Doğrulayıcılar, sıralı anahtar noktası listesini birer birer işler ve her anahtar noktas için belirli kurallar aracılığıyla neden-sonuç tarihindeki tüm önceki düzensiz noktaları sıralar.

Güvenliğin anahtarı, adım (2)'de, tüm dürüst doğrulayıcı düğümlerin aynı ön eki paylaşmak üzere sıralı bir çapa listesi oluşturması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ı ankraj noktasında hemfikir.

Bullshark gecikme süresi

Bullshark'ın gecikme süresi, DAG'daki sıralı referans noktaları arasındaki döngü sayısına bağlıdır. Bullshark'ın en pratik kısım senkron versiyonu, asenkron versiyonuna göre daha iyi bir gecikme süresine sahip olsa da, bu kesinlikle en iyi değildir.

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

Soru 2: Arıza durumu gecikme süresi. Yukarıdaki gecikme analizi arıza durumu olmayan durumlar için geçerlidir, diğer 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 yüzden önceki turlardaki tüm sıralanmamış noktalar 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üşürür, özellikle de Bullshark lideri beklemek için zaman aşımını kullandığı için.

Shoal çerçevesi

Shoal, bu iki gecikme süresi sorununu çözdü; Bullshark( veya başka herhangi bir Narwhal tabanlı BFT protokolünü ), her turda bir referans noktası olmasına izin vererek, ve DAG'daki tüm referans noktası olmayan düğümlerin gecikmesini üç tura indirgeyerek, işleme hattı işleme ile güçlendirdi. Shoal ayrıca DAG'da sıfır maliyetli liderlik itibar mekanizmasını tanıttı, bu da seçimi hızlı liderlere yönlendirdi.

Mücadele

DAG protokolü bağlamında, boru hattı işleme ve liderlerin itibarı zorlu sorunlar olarak kabul edilmektedir, sebepleri şunlardır:

1. Önceki akış hattı işlemleri, çekirdek Bullshark mantığını değiştirmeye çalıştı, ancak bu esasen mümkün gibi görünmüyor.

2. Liderlerin itibarı DiemBFT'ye entegre edildi ve Carousel'de resmileştirildi, bu, doğrulayıcıların geçmiş performanslarına dayanarak gelecekteki liderlerin dinamik bir şekilde seçilmesi fikridir (Bullshark'taki çark ). Liderlik statüsünde bir anlaşmazlık olması bu protokollerin güvenliğini ihlal etmez, ancak Bullshark'ta tamamen farklı bir sıralama ile sonuçlanabilir; bu, dinamik ve belirleyici bir şekilde çarkın sabitini seçmenin konsensüsü sağlamak için gerekli olduğunu ortaya çıkarır ve doğrulayıcıların gelecekteki sabitleri seçmek için sıralı tarih üzerinde uzlaşmaları gerekir.

Sorun zorluğunun kanıtı olarak, Bullshark'ın uygulanması, şu anda üretim ortamında bulunan uygulaması da dahil olmak üzere, bu özellikleri desteklememektedir.

Protokol

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

Shoal'da, DAG üzerinde yerel hesaplama yapma yeteneğine dayanıyoruz ve önceki turların bilgilerini saklayıp yeniden yorumlama yeteneğini gerçekleştirdik. Tüm doğrulayıcıların ilk sıralı sabit noktanın temel içgörüsünde hemfikir olduğu göz önüne alındığında, Shoal birden fazla Bullshark örneğini sıralı bir şekilde birleştirir ve bunları ardışık işleme tabi tutar, böylece ( 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.

Akış Hattı İşleme

V var. Shoal, her bir örnek için F haritalaması ile önceden belirlenen bir ankrajın olduğu şekilde Bullshark'ın örneklerini birbiri ardına çalıştırır. Her bir örnek bir ankraj sıralar, bu da 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 ilk sıralı referans noktasının belirlendiği zamana kadar çalıştırdı, örneğin r. aşamasında. Tüm doğrulayıcılar bu referans noktasında hemfikirdi. Bu nedenle, tüm doğrulayıcılar r+1. aşamadan itibaren DAG'ı yeniden yorumlama konusunda kesin bir şekilde hemfikir olabilir. Shoal, yalnızca r+1. aşamada yeni bir Bullshark örneği başlattı.

En iyi senaryoda, bu, Shoal'ın her turda bir çiviyi sıralamasına izin verir. İlk turda çivi, 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 çivisi vardır, bu çivi bu örneğe göre sıralanır, ardından başka bir yeni örnek üçüncü turda çivi sıralar ve süreç devam eder.

Liderlerin İtibarı

Bullshark sıralama sırasında sabit noktaları atlarken, gecikme süresi artar. Bu durumda, önceki örnek sıralama sabit noktası öncesinde yeni bir örneği başlatmak imkansız olduğundan, boru hattı işleme tekniği etkisizdir. Shoal, her doğrulama düğümünün son etkinlik geçmişine dayanarak her doğrulama düğümüne bir puan atamak için bir itibar mekanizması kullanarak gelecekte ilgili liderlerin kaybolan sabit noktaları işleme 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ü çökebilir, yavaşlayabilir veya kötü niyetli olabilir.

Bu ilke, her puan güncellemesinde, yüksek puan alan liderleri tercih eden, tura göre liderlere önceden tanımlanmış F haritasını belirli bir şekilde yeniden hesaplamaktır. Doğrulayıcıların yeni harita üzerinde uzlaşabilmesi için, puanlar üzerinde uzlaşmaları ve böylece puan türetiminde kullanılan geçmiş üzerinde uzlaşmaları gerekir.

Shoal'da, boru hattı işleme ve liderin itibarı doğal olarak bir araya gelebilir, çünkü her ikisi de DAG üzerinde ilk sıralı ana noktada uzlaşma sağlandıktan sonra yeniden yorumlama için aynı temel teknolojiyi kullanır.

Aslında, tek fark, r. turda referans noktalarının sıralandıktan sonra, doğrulayıcıların yalnızca 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.

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ı, gecikme süresini önemli ölçüde artırabilir, çünkü bunların uygun şekilde yapılandırılması çok önemlidir ve genellikle dinamik ayarlamalar gerektirir, çünkü bu durum ortam ( ağ )'a son derece bağımlıdır. Protokol, bir sonraki liderine geçmeden önce, arızalı liderler için tam zaman aşımı gecikme cezası öder. 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 altında, Jolteon/Hotstuff'taki liderlerin aşırı yüke maruz kaldığını ve ilerlemeyi sağlamadan önce zaman aşımının sona erdiğini gözlemledik.

Ne yazık ki, liderlerin protokolüne dayalı olarak ( gibi