İlk bölümde, klasik PBFT (pratik Bizans hata toleransı) konsensüsünün çalışma prensiplerini ve erken sürüm HotStuff'un nasıl çalıştığını inceledik. Ayrıca, MonadBFT'nin HotStuff'un kuyruk çatalı sorununu, yani boru hattı sistemlerinde geçerli blokların bazen nasıl atılabildiğini nasıl çözdüğünü öğrendik.
Bu son çatal problemi iki ana soruna neden oluyor: 1) Dürüst blok yapıcılarının ödüllerini bozuyor, 2) Ağı duraksatabilir.
MonadBFT, son çatal problemini ortadan kaldırmak için yeniden öneri kurallarını ve arka planda onay gerektirmeyen oylama mekanizmasını tanıttı; bu sayede dürüst önericilerden uygun şekilde onaylanan blokların zincire girmesini sağlıyor.
İkinci bölümde, MonadBFT'nin iki ek özelliğini inceleyeceğiz: 1) spekülatif nihai ve 2) iyimser yanıt verme. Ayrıca MonadBFT'nin geliştiriciler üzerindeki etkisini de ele alacağız.
Tek tur spekülasyon nihai
MonadBFT'nin bir diğer ana özelliği, yalnızca son kısım çatalına karşı direnç değil, aynı zamanda tek tur spekülatif nihai olmaktır.
Pratik uygulamada, bu, istemcilerin ve kullanıcıların blok büyük çoğunlukta oy aldıktan sonra hemen işlem onayı alabilecekleri, hatta bir sonraki tur tamamlanmadan önce.
Geçmişe baktığımızda, temel HotStuff protokolünde bir blok genellikle nihai olarak onaylanması (geri alınamaz) için en az iki aşamadan geçmesi gerekir (örneğin Fast-Hotstuff ve Diem-BFT): bir aşama, yasal kişi sertifikası (QC) almak (≥2f+1 oy ile blok kilitlemek), ikinci aşama ise bir sonraki liderin bu yasal kişi sertifikası (QC) temelinde blok oluşturup göndermesidir.
Bu iki aşamalı onay, güvenliği sağlamak için gereklidir: Yeterince dürüst düğüm bir bloğu kilitlediğinde, onunla çelişen blok yasal çoğunluğu elde edemez ve bir sonraki onay bunu kalıcı hale getirecektir. Bu nedenle, istemcilerin genellikle bir sonraki bloğu veya bir sonraki turu beklemesi gerekebilir, böylece bir önceki işlemin kesinleşip kesinleşmediğini öğrenebilirler.
MonadBFT temelde, işlemlerin sadece bir tur oylama ile yeterince nihai olarak kabul edilmesine izin verir (güvenli bir şekilde işlem yapılabilir). Buna spekülatif nihayetlik denir.
Bir lider bir blok sunduğunda, doğrulayıcılar o bloğun QC'sini oyladıklarında, o blok oylama durumuna (gerekli çoğunlukla kilitlenmiş) geçer. MonadBFT'de, doğrulayıcılar bir kez QC oluşturduğunda, hemen o bloğun işlemlerini gerçekleştirir ve hatta istemciye, o bloğun (spekülatif olarak) kabul edildiğini belirten ön onay gönderir. Bu, "Bu bloğu kabul eden çok büyük bir çoğunluğumuz var. Çok beklenmedik bir durum olmadıkça, bu bloğun onaylanmış olduğunu varsayabiliriz." demek gibidir.
Bu anlık onay iyimserdir. Blok henüz defterde sunulmamıştır. Bu, bir sonraki öneri ortaya çıkıp onu en iyi şekilde onayladığında (QC-on QC) olacaktır, ancak normal koşullarda, bunu iptal edecek bir şey yoktur. Spekülatif olarak yürütülen blokları iptal edebilecek tek durum, liderin eşdeğer bir saldırıya uğramasıdır (yani aynı yükseklikte iki farklı blok önerip oylamayı dağıtmak).
Spekülatif kesinliği, kuyruk çatallarına karşı direncin iyi bir yan ürünü olarak düşünebilirsiniz. Kuyruk çatalına direnmek, bir sonraki lider çökse bile mevcut teklifin atılmayacağını garanti eder (yeniden teklif ve NEC kuralı sayesinde). Spekülatif olarak yürütülen bir bloğun bırakıldığı tek durum, orijinal teklif sahibi tarafından bir eşdeğerlik saldırısı (kanıtlanabilir şekilde kötü niyetli bir çift imza hatası) olduğu durumdur, burada: 1) çakışan bir QC tarafından tespit edilebilir; 2) cezalandırılabilir; 3) Son derece nadir.
Önceki protokollerde, bir sonraki liderin önceki bloğu yeniden sunacağını garanti etmezler, bu nedenle son çatalın mümkün olduğu ve spekülasyon varsayımının kırıldığı anlamına gelir.
İyimser yanıt verme
Çoğu konsensüs protokolünde, her turdan sonra yerleşik bir bekleme süresi vardır, örneğin bir tampon süresi veya zaman aşımı. Bu, tüm mesajların ilerlemeye devam etmeden önce ulaştığından emin olmak içindir. Bu, liderin çökmesi veya hiç bilgi göndermemesi gibi en kötü durumları ele almak için tasarlanmış bir koruma mekanizmasıdır.
Bu zaman aşım süreleri genellikle aşırı temkinlidir. Ağ düzgün çalışıyorsa ve tüm doğrulayıcılar doğru davranıyorsa, sabit bekleme gereksiz bir maliyet haline gelecektir. Blok daha hızlı tamamlanabilirdi, ancak protokol her ihtimale karşı gecikmeye neden oldu.
MonadBFT, iyimser yanıt verme yeteneğini getiriyor, bu da protokolün ağ bilgilerine dayanarak hemen ilerleyebileceği anlamına geliyor, sabit bir zamanlayıcıya daima bağımlı olmadan. Buradaki tasarım prensibi "Hızlı olabiliyorsa hızlı ol, sabırlı olmak gerektiğinde sabırlı ol" şeklinde özetlenebilir.
MonadBFT'nin tasarımı, normal durumlarda ve hatta arıza kurtarma sırasında, eğer gerek yoksa, belirlenen zaman aşımını beklemek için duraksamaması içindir.
Mutlu yolda (bu, dürüst bir liderimiz olduğu anlamına gelir): Teklif veya oylamada yerleşik bir gecikme yoktur. Liderin sırası geldiğinde, bir blok önerir. Doğrulayıcılar geçerli bir öneriyi aldıklarında hemen oy kullanır. Lider (veya daha doğrusu, bir sonraki lider, çünkü HotStuff boru hattında, oy bir sonraki teklif sahibine gönderilir) 2f+1 oy topladığında, QC oluşur ve yayılabilir. İyimser yanıt tasarımında, bu hemen bir sonraki aşamayı tetikler.
Pratikte, bu, eğer düğümler arasındaki ağ gecikmesi 100 milisaniye ise, konsensüsün yalnızca birkaç yüz milisaniye içinde bir turu tamamlayabileceği anlamına gelir (hesaplama ve toplama maliyetleri eklenmiştir).
Eğer gerek yoksa, beklemeyecek, örneğin tam bir saniyelik "zaman dilimi". Bu, Ethereum ana ağının benimsediği slot ve dönem modelinden farklıdır. Ethereum'da blok üretim zaman aralığı sabit olarak 12 saniyedir. Herkes önceden hazır olsa bile, protokol bekleyecektir.
MonadBFT yöntemi gereksiz gecikmeleri ortadan kaldırır. Normalde "Δ saniye beklemek zorundasınız" katı kuralını kaldırarak HotStuff yapısını korur. Bu, güvenlikten ödün vermeden, zaman kısıtlı sistemlere göre yanıt verme açısından daha iyi performans gösterebileceği anlamına gelir.
Kötü bir yol üzerinde (liderin başarısızlığı): Birçok konsensüs protokolünde, lider blok öneremediğinde, diğer düğümler ancak Δ süresi dolduktan sonra bunun farkına varır. Örneğin, Δ 1 saniye ise, bu süre esasen boşa harcanmış olur. MonadBFT'nin yaklaşımı buna göre farklıdır. Doğrulayıcılar öneri kaybını tespit ettiklerinde, hemen zaman aşımı mesajı (TC veya zaman aşımı sertifikası) yayarlar. 2f+1 kez zaman aşımı meydana geldiğinde, bir sonraki lider devralır. Yeni bir bakış açısına geçiş, saat tarafından değil, nitelikli çoğunluk temelli kanıtlarla tetiklenir.
hotstuff-family Konsensüs ile karşılaştırma
MonadBFT, HotStuff serisi Konsensüs protokollerinin temeli üzerine inşa edilmiştir, ancak bir dizi ideal özelliğin birleşimini gerçekleştirerek öne çıkmaktadır. Erken protokoller genellikle belirli boyutlar üzerinde optimize edilirler, örneğin, akışkan verim veya lineer iletişim, ancak diğer alanlardan ödün vermek zorunda kalırlardı. MonadBFT, lineer mesaj karmaşıklığı, akışkan onay, güçlü son çatal direnci, sabit gecikme olmaksızın anlık yanıt verme yeteneği ve etkili iyileştirme mekanizmalarını bir araya getirirken, hızlı nihai belirleme ve yüksek kullanılabilirlik garantilerini de korumaktadır. Aşağıdaki tablo, MonadBFT'nin diğer döngüsel lider BFT protokolleriyle bu ana boyutlar üzerindeki karşılaştırmasını özetlemektedir:
Bu, geliştiriciler ve kullanıcılar için ne anlama geliyor?
Geliştiriciler için MonadBFT birkaç anlam ifade eder:
Daha basit bir nihai belirleme modeli: MonadBFT kullanarak, QC (nitelikli çoğunluk oyu) olan blokları gerçekte nihai olarak belirlenmiş olarak görebilirsiniz, çünkü protokol bunu nihai olarak belirleyecek veya ceza verecektir. Geliştiriciler, 1 blok onayı güvenli bir şekilde işletme konusunda son derece emin olabilirler.
Uygulamanın kullanıcı deneyimini iyileştirme: Eğer yüksek verimliliğe sahip bir uygulama (borsa, oyun vb.) inşa ediyorsanız, MonadBFT'nin düşük gecikme süresi ve çatal direnci özellikleri daha akıcı bir kullanıcı deneyimine dönüşecektir. Kullanıcılar, işlemlerinin onaylandığını neredeyse anında görebilir ve sık sık kafa karıştırıcı yeniden yapılandırmalar veya geri dönüşlerle karşılaşmazlar. Böylece, nihai kesinlik ve hızlı güncellemeler sunan uygulamalar tasarlayabilirsiniz.
Kesinlik davranışı: MonadBFT'nin daha katı kuralları (örneğin, yeniden önerme gereksinimleri) blokların içermekte olduğu belirsizliği azaltır. Oyların veya zaman aşımının liderine ne zaman ulaşacağı gibi ince zaman faktörleri nedeniyle blokların dahil edilmesi veya atlanmasıyla ilgili "kenar durumlar" daha azdır. MonadBFT, bu zamana duyarlı belirsizliği açık kurallar ve doğrulanabilir kanıtlarla değiştirmiştir. Bu, akıl yürütme protokollerinin doğruluğunu ve test edilmesini daha kolay hale getirir. Ayrıca, arızalı düğümlerin tanımlanması için açık bir temel sağlar (örneğin, biri yeniden önerme yapmadıysa veya çelişkili bir blok önerdiyse, protokole ihanet ettiklerini bilirsiniz).
Genişletilebilirlik alanı: Eğer genişletilebilirliğe önem veren bir geliştiriciyseniz, MonadBFT size darboğaza girmeden önce daha fazla alan sunar. İkincil protokollere kıyasla, blok boyutunu veya doğrulayıcı sayısını artırmak çok daha kolaydır. Ayrıca, silme kodlama blok yayılımı gibi işlevler, tek bir düğümü aşırı tüketmeden ağ üzerinden büyük miktarda veri göndermenizi sağlar. Bu, daha yüksek bir throughput hedeflemeyi mümkün kılarak daha iddialı zincir üzerindeki uygulamalar için tasarım alanı açar.
Son kullanıcılar için: Normal kullanıcılar burada tartıştığımız herhangi bir şeyi anlamayacaklar ama etkilerini hissedecekler. MonadBFT, Monad zincirinin temeli olarak, kullanıcıların merkezileşmeden ve sansüre karşı koyma hakkından ödün vermeden aşağıdaki tüm iyi özellikleri bekleyebilecekleri anlamına geliyor.
Daha hızlı onay: İşlemler (token gönderme, varlık değiştirme, NFT basma, ticaret gerçekleştirme gibi) hızlı bir şekilde onaylanacaktır.
Beklenmedik durumları azaltmak: Blok durumunun tutarlılığı daha yüksektir çünkü kuyruk çatalı gibi esasen yeniden yapılandırmaya ait olan şeyler ortadan kaldırılmıştır.
Adil ve şeffaf: Konsensüsün iyileşmesi, zincirin çalışmasının daha adil olduğu anlamına gelir. Herhangi bir bireysel doğrulayıcı, işlemleri kolayca denetleyemez veya bloklar arasındaki sıralama üzerinde hile yapamaz.
Sonuç
Özetle, MonadBFT, akış hattı HotStuff tarzı konsensüs temelinde dört ana yenilik getirmiştir:
Kuyrukta çatalı önleme: MonadBFT, kuyruğu çatal saldırılarını ortadan kaldıran ilk sıralı BFT protokolüdür. Bu hedefe, bir önceki liderin başarısız olması durumunda bir sonraki liderin son oylanan bloğu yeniden sunması veya destek eksik olduğunu kanıtlamak için onaysız sertifika (NEC) göstermesi ile ulaşılır. Bu, büyük bir destek alan herhangi bir bloğun atılmayacağını garanti eder, böylece dürüst liderlerin ödüllerini korur ve kötü niyetli yeniden yapılandırma ile bloklar arası MEV çıkarımını önler.
Tek tur spekülasyon nihai: Doğrulayıcılar, tek tur iletişimi (bir liderin öneride bulunması ve oylama) sonrasında blokları onaylayarak istemcilere anında içerik garantisi sağlar. Bu spekülatif onay, yalnızca lider eşdeğer saldırısı (kanıtlanabilir ve cezalandırılabilir bir eylem) durumunda geri yüklenir, bu da onu pratikte güvenli bir varsayım haline getirir.
İyimser yanıt verme: Protokol, ağ hızında çalışır, yerleşik gecikme yoktur. Lider, gerekli oylamaları aldıktan sonra hemen konsensüsü ilerletir, görünüm değişiklikleri, yeterli sayıda katılımcının zaman aşımına uğramasından sonra hemen gerçekleşir, sabit bir zaman aralığını beklemek yerine. Bu iyimser yanıt verme tasarımı, bekleme süresini en aza indirirken, aynı zamanda verimliliği maksimize eder ve asenkron ve arızalar meydana geldiğinde bile sağlam bir şekilde işleyebilir.
Doğrusal iletişim: Mutlu yolda (yani lider dürüst olduğunda), mesaj ve doğrulama karmaşıklığı doğrulayıcı sayısıyla doğrusal bir ilişkiye sahiptir. MonadBFT, HotStuff'un etkili iletişim modelini korur, toplu imzalar ve basit lider doğrulayıcı yayımlama kullanarak protokolün yüzlerce doğrulayıcıya ölçeklenmesini sağlar ve performans darboğazı oluşmaz.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
MonadBFT Analizi (2. Kısım): Geliştiriciler ve Kullanıcılar İçin Ne Anlama Geliyor
İlk bölümde, klasik PBFT (pratik Bizans hata toleransı) konsensüsünün çalışma prensiplerini ve erken sürüm HotStuff'un nasıl çalıştığını inceledik. Ayrıca, MonadBFT'nin HotStuff'un kuyruk çatalı sorununu, yani boru hattı sistemlerinde geçerli blokların bazen nasıl atılabildiğini nasıl çözdüğünü öğrendik.
Bu son çatal problemi iki ana soruna neden oluyor: 1) Dürüst blok yapıcılarının ödüllerini bozuyor, 2) Ağı duraksatabilir.
MonadBFT, son çatal problemini ortadan kaldırmak için yeniden öneri kurallarını ve arka planda onay gerektirmeyen oylama mekanizmasını tanıttı; bu sayede dürüst önericilerden uygun şekilde onaylanan blokların zincire girmesini sağlıyor.
İkinci bölümde, MonadBFT'nin iki ek özelliğini inceleyeceğiz: 1) spekülatif nihai ve 2) iyimser yanıt verme. Ayrıca MonadBFT'nin geliştiriciler üzerindeki etkisini de ele alacağız.
Tek tur spekülasyon nihai
MonadBFT'nin bir diğer ana özelliği, yalnızca son kısım çatalına karşı direnç değil, aynı zamanda tek tur spekülatif nihai olmaktır.
Pratik uygulamada, bu, istemcilerin ve kullanıcıların blok büyük çoğunlukta oy aldıktan sonra hemen işlem onayı alabilecekleri, hatta bir sonraki tur tamamlanmadan önce.
Geçmişe baktığımızda, temel HotStuff protokolünde bir blok genellikle nihai olarak onaylanması (geri alınamaz) için en az iki aşamadan geçmesi gerekir (örneğin Fast-Hotstuff ve Diem-BFT): bir aşama, yasal kişi sertifikası (QC) almak (≥2f+1 oy ile blok kilitlemek), ikinci aşama ise bir sonraki liderin bu yasal kişi sertifikası (QC) temelinde blok oluşturup göndermesidir.
Bu iki aşamalı onay, güvenliği sağlamak için gereklidir: Yeterince dürüst düğüm bir bloğu kilitlediğinde, onunla çelişen blok yasal çoğunluğu elde edemez ve bir sonraki onay bunu kalıcı hale getirecektir. Bu nedenle, istemcilerin genellikle bir sonraki bloğu veya bir sonraki turu beklemesi gerekebilir, böylece bir önceki işlemin kesinleşip kesinleşmediğini öğrenebilirler.
MonadBFT temelde, işlemlerin sadece bir tur oylama ile yeterince nihai olarak kabul edilmesine izin verir (güvenli bir şekilde işlem yapılabilir). Buna spekülatif nihayetlik denir.
Bir lider bir blok sunduğunda, doğrulayıcılar o bloğun QC'sini oyladıklarında, o blok oylama durumuna (gerekli çoğunlukla kilitlenmiş) geçer. MonadBFT'de, doğrulayıcılar bir kez QC oluşturduğunda, hemen o bloğun işlemlerini gerçekleştirir ve hatta istemciye, o bloğun (spekülatif olarak) kabul edildiğini belirten ön onay gönderir. Bu, "Bu bloğu kabul eden çok büyük bir çoğunluğumuz var. Çok beklenmedik bir durum olmadıkça, bu bloğun onaylanmış olduğunu varsayabiliriz." demek gibidir.
Bu anlık onay iyimserdir. Blok henüz defterde sunulmamıştır. Bu, bir sonraki öneri ortaya çıkıp onu en iyi şekilde onayladığında (QC-on QC) olacaktır, ancak normal koşullarda, bunu iptal edecek bir şey yoktur. Spekülatif olarak yürütülen blokları iptal edebilecek tek durum, liderin eşdeğer bir saldırıya uğramasıdır (yani aynı yükseklikte iki farklı blok önerip oylamayı dağıtmak).
Spekülatif kesinliği, kuyruk çatallarına karşı direncin iyi bir yan ürünü olarak düşünebilirsiniz. Kuyruk çatalına direnmek, bir sonraki lider çökse bile mevcut teklifin atılmayacağını garanti eder (yeniden teklif ve NEC kuralı sayesinde). Spekülatif olarak yürütülen bir bloğun bırakıldığı tek durum, orijinal teklif sahibi tarafından bir eşdeğerlik saldırısı (kanıtlanabilir şekilde kötü niyetli bir çift imza hatası) olduğu durumdur, burada: 1) çakışan bir QC tarafından tespit edilebilir; 2) cezalandırılabilir; 3) Son derece nadir.
Önceki protokollerde, bir sonraki liderin önceki bloğu yeniden sunacağını garanti etmezler, bu nedenle son çatalın mümkün olduğu ve spekülasyon varsayımının kırıldığı anlamına gelir.
İyimser yanıt verme
Çoğu konsensüs protokolünde, her turdan sonra yerleşik bir bekleme süresi vardır, örneğin bir tampon süresi veya zaman aşımı. Bu, tüm mesajların ilerlemeye devam etmeden önce ulaştığından emin olmak içindir. Bu, liderin çökmesi veya hiç bilgi göndermemesi gibi en kötü durumları ele almak için tasarlanmış bir koruma mekanizmasıdır.
Bu zaman aşım süreleri genellikle aşırı temkinlidir. Ağ düzgün çalışıyorsa ve tüm doğrulayıcılar doğru davranıyorsa, sabit bekleme gereksiz bir maliyet haline gelecektir. Blok daha hızlı tamamlanabilirdi, ancak protokol her ihtimale karşı gecikmeye neden oldu.
MonadBFT, iyimser yanıt verme yeteneğini getiriyor, bu da protokolün ağ bilgilerine dayanarak hemen ilerleyebileceği anlamına geliyor, sabit bir zamanlayıcıya daima bağımlı olmadan. Buradaki tasarım prensibi "Hızlı olabiliyorsa hızlı ol, sabırlı olmak gerektiğinde sabırlı ol" şeklinde özetlenebilir.
MonadBFT'nin tasarımı, normal durumlarda ve hatta arıza kurtarma sırasında, eğer gerek yoksa, belirlenen zaman aşımını beklemek için duraksamaması içindir.
Mutlu yolda (bu, dürüst bir liderimiz olduğu anlamına gelir): Teklif veya oylamada yerleşik bir gecikme yoktur. Liderin sırası geldiğinde, bir blok önerir. Doğrulayıcılar geçerli bir öneriyi aldıklarında hemen oy kullanır. Lider (veya daha doğrusu, bir sonraki lider, çünkü HotStuff boru hattında, oy bir sonraki teklif sahibine gönderilir) 2f+1 oy topladığında, QC oluşur ve yayılabilir. İyimser yanıt tasarımında, bu hemen bir sonraki aşamayı tetikler.
Pratikte, bu, eğer düğümler arasındaki ağ gecikmesi 100 milisaniye ise, konsensüsün yalnızca birkaç yüz milisaniye içinde bir turu tamamlayabileceği anlamına gelir (hesaplama ve toplama maliyetleri eklenmiştir).
Eğer gerek yoksa, beklemeyecek, örneğin tam bir saniyelik "zaman dilimi". Bu, Ethereum ana ağının benimsediği slot ve dönem modelinden farklıdır. Ethereum'da blok üretim zaman aralığı sabit olarak 12 saniyedir. Herkes önceden hazır olsa bile, protokol bekleyecektir.
MonadBFT yöntemi gereksiz gecikmeleri ortadan kaldırır. Normalde "Δ saniye beklemek zorundasınız" katı kuralını kaldırarak HotStuff yapısını korur. Bu, güvenlikten ödün vermeden, zaman kısıtlı sistemlere göre yanıt verme açısından daha iyi performans gösterebileceği anlamına gelir.
Kötü bir yol üzerinde (liderin başarısızlığı): Birçok konsensüs protokolünde, lider blok öneremediğinde, diğer düğümler ancak Δ süresi dolduktan sonra bunun farkına varır. Örneğin, Δ 1 saniye ise, bu süre esasen boşa harcanmış olur. MonadBFT'nin yaklaşımı buna göre farklıdır. Doğrulayıcılar öneri kaybını tespit ettiklerinde, hemen zaman aşımı mesajı (TC veya zaman aşımı sertifikası) yayarlar. 2f+1 kez zaman aşımı meydana geldiğinde, bir sonraki lider devralır. Yeni bir bakış açısına geçiş, saat tarafından değil, nitelikli çoğunluk temelli kanıtlarla tetiklenir.
hotstuff-family Konsensüs ile karşılaştırma
MonadBFT, HotStuff serisi Konsensüs protokollerinin temeli üzerine inşa edilmiştir, ancak bir dizi ideal özelliğin birleşimini gerçekleştirerek öne çıkmaktadır. Erken protokoller genellikle belirli boyutlar üzerinde optimize edilirler, örneğin, akışkan verim veya lineer iletişim, ancak diğer alanlardan ödün vermek zorunda kalırlardı. MonadBFT, lineer mesaj karmaşıklığı, akışkan onay, güçlü son çatal direnci, sabit gecikme olmaksızın anlık yanıt verme yeteneği ve etkili iyileştirme mekanizmalarını bir araya getirirken, hızlı nihai belirleme ve yüksek kullanılabilirlik garantilerini de korumaktadır. Aşağıdaki tablo, MonadBFT'nin diğer döngüsel lider BFT protokolleriyle bu ana boyutlar üzerindeki karşılaştırmasını özetlemektedir:
Bu, geliştiriciler ve kullanıcılar için ne anlama geliyor?
Geliştiriciler için MonadBFT birkaç anlam ifade eder:
Daha basit bir nihai belirleme modeli: MonadBFT kullanarak, QC (nitelikli çoğunluk oyu) olan blokları gerçekte nihai olarak belirlenmiş olarak görebilirsiniz, çünkü protokol bunu nihai olarak belirleyecek veya ceza verecektir. Geliştiriciler, 1 blok onayı güvenli bir şekilde işletme konusunda son derece emin olabilirler.
Uygulamanın kullanıcı deneyimini iyileştirme: Eğer yüksek verimliliğe sahip bir uygulama (borsa, oyun vb.) inşa ediyorsanız, MonadBFT'nin düşük gecikme süresi ve çatal direnci özellikleri daha akıcı bir kullanıcı deneyimine dönüşecektir. Kullanıcılar, işlemlerinin onaylandığını neredeyse anında görebilir ve sık sık kafa karıştırıcı yeniden yapılandırmalar veya geri dönüşlerle karşılaşmazlar. Böylece, nihai kesinlik ve hızlı güncellemeler sunan uygulamalar tasarlayabilirsiniz.
Kesinlik davranışı: MonadBFT'nin daha katı kuralları (örneğin, yeniden önerme gereksinimleri) blokların içermekte olduğu belirsizliği azaltır. Oyların veya zaman aşımının liderine ne zaman ulaşacağı gibi ince zaman faktörleri nedeniyle blokların dahil edilmesi veya atlanmasıyla ilgili "kenar durumlar" daha azdır. MonadBFT, bu zamana duyarlı belirsizliği açık kurallar ve doğrulanabilir kanıtlarla değiştirmiştir. Bu, akıl yürütme protokollerinin doğruluğunu ve test edilmesini daha kolay hale getirir. Ayrıca, arızalı düğümlerin tanımlanması için açık bir temel sağlar (örneğin, biri yeniden önerme yapmadıysa veya çelişkili bir blok önerdiyse, protokole ihanet ettiklerini bilirsiniz).
Genişletilebilirlik alanı: Eğer genişletilebilirliğe önem veren bir geliştiriciyseniz, MonadBFT size darboğaza girmeden önce daha fazla alan sunar. İkincil protokollere kıyasla, blok boyutunu veya doğrulayıcı sayısını artırmak çok daha kolaydır. Ayrıca, silme kodlama blok yayılımı gibi işlevler, tek bir düğümü aşırı tüketmeden ağ üzerinden büyük miktarda veri göndermenizi sağlar. Bu, daha yüksek bir throughput hedeflemeyi mümkün kılarak daha iddialı zincir üzerindeki uygulamalar için tasarım alanı açar.
Son kullanıcılar için: Normal kullanıcılar burada tartıştığımız herhangi bir şeyi anlamayacaklar ama etkilerini hissedecekler. MonadBFT, Monad zincirinin temeli olarak, kullanıcıların merkezileşmeden ve sansüre karşı koyma hakkından ödün vermeden aşağıdaki tüm iyi özellikleri bekleyebilecekleri anlamına geliyor.
Daha hızlı onay: İşlemler (token gönderme, varlık değiştirme, NFT basma, ticaret gerçekleştirme gibi) hızlı bir şekilde onaylanacaktır.
Beklenmedik durumları azaltmak: Blok durumunun tutarlılığı daha yüksektir çünkü kuyruk çatalı gibi esasen yeniden yapılandırmaya ait olan şeyler ortadan kaldırılmıştır.
Adil ve şeffaf: Konsensüsün iyileşmesi, zincirin çalışmasının daha adil olduğu anlamına gelir. Herhangi bir bireysel doğrulayıcı, işlemleri kolayca denetleyemez veya bloklar arasındaki sıralama üzerinde hile yapamaz.
Sonuç
Özetle, MonadBFT, akış hattı HotStuff tarzı konsensüs temelinde dört ana yenilik getirmiştir:
Kuyrukta çatalı önleme: MonadBFT, kuyruğu çatal saldırılarını ortadan kaldıran ilk sıralı BFT protokolüdür. Bu hedefe, bir önceki liderin başarısız olması durumunda bir sonraki liderin son oylanan bloğu yeniden sunması veya destek eksik olduğunu kanıtlamak için onaysız sertifika (NEC) göstermesi ile ulaşılır. Bu, büyük bir destek alan herhangi bir bloğun atılmayacağını garanti eder, böylece dürüst liderlerin ödüllerini korur ve kötü niyetli yeniden yapılandırma ile bloklar arası MEV çıkarımını önler.
Tek tur spekülasyon nihai: Doğrulayıcılar, tek tur iletişimi (bir liderin öneride bulunması ve oylama) sonrasında blokları onaylayarak istemcilere anında içerik garantisi sağlar. Bu spekülatif onay, yalnızca lider eşdeğer saldırısı (kanıtlanabilir ve cezalandırılabilir bir eylem) durumunda geri yüklenir, bu da onu pratikte güvenli bir varsayım haline getirir.
İyimser yanıt verme: Protokol, ağ hızında çalışır, yerleşik gecikme yoktur. Lider, gerekli oylamaları aldıktan sonra hemen konsensüsü ilerletir, görünüm değişiklikleri, yeterli sayıda katılımcının zaman aşımına uğramasından sonra hemen gerçekleşir, sabit bir zaman aralığını beklemek yerine. Bu iyimser yanıt verme tasarımı, bekleme süresini en aza indirirken, aynı zamanda verimliliği maksimize eder ve asenkron ve arızalar meydana geldiğinde bile sağlam bir şekilde işleyebilir.
Doğrusal iletişim: Mutlu yolda (yani lider dürüst olduğunda), mesaj ve doğrulama karmaşıklığı doğrulayıcı sayısıyla doğrusal bir ilişkiye sahiptir. MonadBFT, HotStuff'un etkili iletişim modelini korur, toplu imzalar ve basit lider doğrulayıcı yayımlama kullanarak protokolün yüzlerce doğrulayıcıya ölçeklenmesini sağlar ve performans darboğazı oluşmaz.