Blok zincirinin özü, katı bir küresel konsensüs sağlamaktır: yani, ağ düğümlerinin hangi ülkede veya hangi zaman diliminde bulunduğuna bakılmaksızın, tüm katılımcıların sonunda bir dizi nesnel sonuç üzerinde hemfikir olmaları gerekir.
Ama gerçek hayattaki dağıtık ağlar pek de ideal değil: bazı düğümler çevrimdışı kalıyor, bazı düğümler yalan söylüyor, hatta bazı insanlar kasıtlı olarak zarar veriyor. Bu durumda sistem "birçok ağızdan tek söz" nasıl tutuyor, nasıl tutarlılığı sağlıyor?
Konsensüs protokollerinin çözmek için tasarlandığı sorun budur. Esasen, tam olarak güvenilmese de bir grup bağımsız düğüme, her işlemin sırası ve içeriği hakkında birleşik kararlar almaları için rehberlik eden bir dizi kuraldır.
Bu "katı fikir birliği" kurulduktan sonra, blok zinciri dijital mülk koruması, enflasyona dayanıklı parasal modeller ve ölçeklenebilir sosyal işbirliği yapıları gibi bir dizi temel özelliğin kilidini açar. Ancak öncül, konsensüs protokolünün kendisinin aynı anda iki temeli garanti etmesi gerektiğidir:
İki çelişkili bloğun aynı anda onaylanması mümkün değildir;
Ağ ilerlemeye devam etmeli ve takılıp kalmamalı veya kapanmamalıdır.
MonadBFT, bu yönde yapılan en son teknik atılımdır.
Konsensüs protokolünün kısa evrimi incelemesi
Konsensüs mekanizması alanında aslında on yıllardır araştırma yapılmaktadır. En erken protokollerden biri olan PBFT (Pratik Bizans Hata Toleransı), belirli bir gerçek durumu işleyebilme yeteneğine sahiptir: ağda bazı düğümler koparsa, kötü niyetli davranırsa veya saçmalarsa, toplam sayının %1'inden fazlası olmadıkça sistem yine de bir uzlaşmaya varabilir.
Bu erken protokollerin tasarım biçimi daha "geleneksel": Her turda bir lider seçilir, o öneriyi başlatır, diğer doğrulayıcılar bu öneri üzerinde çoklu oylamalar yaparak işlem sırasını adım adım onaylar.
Oylama süreci genellikle birkaç aşamadan oluşur, örneğin pre-prepare, prepare, commit, reply. Her aşamada, tüm doğrulayıcıların birbirleriyle iletişim kurması gerekir. Diğer bir deyişle, herkesin herkesle bir kez konuşması gerekir, bu da mesaj miktarının "ağ" şeklinde patlayıcı bir şekilde artmasına neden olur.
Bu iletişim yapısının karmaşıklığı n²'dir - yani eğer ağda 100 doğrulayıcı varsa, her konsensüs turunda neredeyse 10.000 mesaj iletilmesi gerekebilir.
Bu, küçük bir ağda büyük bir sorun değildir, ancak doğrulayıcı sayısı arttığında, sistem üzerindeki iletişim yükü hızla dayanılmaz hale gelebilir ve verimlilik doğrudan azalacaktır.
Kaynak:
Bu "herkesin herkesle iletişim kurması gerektiği" ikincil iletişim yapısı aslında oldukça verimsizdir. Örneğin, 100 doğrulayıcıdan oluşan bir ağda, her konsensüs turunda on binlerce mesaj işlenmesi gerekebilir.
Bu, küçük bir çevrede yönetilebilir, ancak küresel ölçekte, açık bir zincir ağına yerleştirildiğinde, iletişim yükü hemen kabul edilemez hale gelir. Bu nedenle, PBFT ve Tendermint gibi erken dönem BFT protokolleri genellikle izinli senaryolar (permissioned network) veya çok az sayıda doğrulayıcıya sahip sistemlerde kullanılmakta, ancak ancak bu şekilde çalıştırılabilmektedir.
BFT protokolünün izin gerektirmeyen, halka açık bir ortamda da uyum sağlaması için, bazı yeni nesil tasarımlar daha hafif iletişim yollarına yönelmeye başladı: Her bir doğrulayıcının yalnızca liderle iletişim kurması, herkesin birbirine veri iletmesi yerine.
Bu, mesaj karmaşıklığını n²'den n'ye optimize eder ve sistem üzerindeki yükü büyük ölçüde azaltır.
HotStuff protokolü, 2018 yılında ortaya atılmıştır ve bu ölçeklenebilirlik sorununu çözmek amacıyla tasarlanmıştır. Tasarım felsefesi oldukça nettir: Daha basit, lider odaklı bir iletişim yapısı ile PBFT'nin karmaşık oylama sürecinin yerini almasıdır.
HotStuff'un ana özelliklerinden biri, sözde doğrusal iletişimdir (linear communication). Mekanizmasında, her doğrulayıcı yalnızca kendi oyunu mevcut liderine iletmek zorundadır, lider bu oyları paketleyerek bir Quorum Sertifikası (QC, yasal çoğunluk belgesi) oluşturur.
Bu QC aslında bir toplu imza olup, tüm ağa şu şekilde kanıtlar: "Çoğu düğüm bu teklifi kabul etti."
Buna karşılık, PBFT'nin iletişim modeli "tam yayın"dır; herkes grupta konuşur ve ortam bir anda oldukça kaotik hale gelir. HotStuff'un modeli ise "bir kişi toplar, bir seferde paketler" gibidir; ağda ne kadar çok insan olursa olsun, yüksek verimlilikle çalışmaya devam edebilir.
Yukarıdaki resim, HotStuff'un fan-out iletişim yapısını PBFT'nin küresel bağlantı modeli ile karşılaştırmaktadır.
Kaynak:
Doğrusal iletişimin yanı sıra, HotStuff daha fazla verimlilik artırmak için bir akış versiyonuna (pipelined HotStuff) yükseltilebilir.
Orijinal HotStuff'ta, aynı doğrulayıcı bir blok tamamen onaylanana kadar ardışık olarak birçok tur lideri olarak görev yapar. Bu süreç, "her turda bir blok işlemek" şeklindedir ve tüm enerji mevcut olanı ilerletmeye odaklanır.
Ve HotStuff akışında, mekanizma daha esnek hale geliyor: Her turun yeni bir lider seçmesini sağlıyor ve her liderin iki görevi var:
Bir yandan önceki oylamanın Quorum Certificate (QC) haline getirilmesi ve tüm ağa yayınlanması;
Yeni bir blok önerirken, bir sonraki turu başlatmaya hazırlanıyor.
Yani, artık "birini onayladıktan sonra diğerine geçmek" yok, bunun yerine bir üretim hattı gibi, farklı liderler her aşamada sırayla sorumluluk alıyor. Önceki kişi bloğu öneriyor, sonraki kişi onu onaylıyor ve yeni bloklar önermeye devam ediyor, zincir üzerindeki konsensüs bir bayrak yarışı gibi devam ediyor.
Bu, "montaj hattı" metaforunun kökenidir: mevcut blok hala onay sürecinden geçmektedir ve bir sonraki, verim verimliliğini artırmak için paralel olarak birden fazla adımla zaten hazırlık aşamasındadır.
Özetle, HotStuff gibi protokoller geleneksel BFT'ye göre iki boyutta önemli iyileştirmeler yapmıştır:
Birincisi, iletişim daha hafif, her bir doğrulayıcı yalnızca liderle iletişim kurması yeterlidir;
İkincisi, işleme verimliliği daha yüksektir, birden fazla blok onay süreci paralel olarak gerçekleştirilebilir.
Bu, HotStuff'u birçok modern PoS blok zinciri konsensüs mekanizmasının tasarım şablonu haline getirdi. Ancak her şeyde olduğu gibi, avantajlar ve dezavantajlar vardır - akış şeması yapısı güçlü bir performans sunarken, aynı zamanda kolayca fark edilmeyen bir yapısal risk de getirmektedir.
Şimdi bu temel konuyu derinlemesine tartışacağız: Kuyruk Dallanması (Tail Forking).
Kuyruk Dallanma Sorunu (Tail-Forking)
HotStuff, özellikle de onun boru hattı versiyonu, konsensüs protokollerinin ölçeklenebilirlik sorununu çözmesine rağmen, bazı yeni zorluklar da getirmiştir. Bunların en kritik ve en kolay gözden kaçanı ise "kuyruk bölünmesi" (Tail Forking) sorunudur.
Kuyruk bölünmesi nedir? Basitçe şöyle anlaşılabilir: Blok zincirinde "kuyrukta" beklenmedik bir blok yeniden düzenlemesi meydana geldi (reorg).
Özellikle, geçerli olan ve çoğu doğrulayıcıya başarıyla ulaştırılmış bir blok var, yeterli oy desteği de almış durumda. Normalde, hemen onaylanması ve ana zincire yazılması gerekiyordu. Ancak sonunda, "atlandı" ve terk edildi (yani orphaned), yerine aynı yükseklikteki başka bir yeni blok geçti.
Bu bir hata değil, saldırı da değil, bunun nedeni protokolün kendisinin tasarım yapısında "ağ kopma" olasılığının bulunmasıdır. Bu biraz adaletsiz gibi mi geliyor? Peki, bu tam olarak nasıl oluyor?
Daha önce bahsettiğimiz gibi, HotStuff hattındaki her liderin iki görevi vardır:
A. Yeni bir blok öner (örneğin Bₙ₊₁)
B. Önceki liderin blok için oy toplaması, QC oluşturması (örneğin Bₙ için nihai onay tamamlanması)
Bu iki görev paralel olarak, sırayla gerçekleştiriliyor. Ama sorun burada ortaya çıkıyor.
Bir örnek vermek gerekirse: Diyelim ki Alice liderdir, n. yükseklikte Bₙ bloğunu önerdi, bu blok süper çoğunluk oyunu aldı ve "neredeyse onaylandı".
Sonraki adımda Bob lider olarak görev almalı ve zincirin bir sonraki bloğu Bₙ₊₁'i ilerletmelidir. Aynı zamanda, Bₙ'in QC'sini (yasal çoğunluk kanıtı) teklifine eklemeli ve Bₙ'in nihai onayını tamamlamalıdır.
Ancak eğer Bob bu sırada çevrimdışıysa ya da Bₙ'in QC'sini kasten sunmuyorsa, o zaman sorun çıkacaktır.
Alice'in bloğu için QC paketini tamamlayacak kimse olmadığı için Bₙ'in oy kayıtları yayılamadı. Bu, onaylanması gereken bir bloktu ve böylece "soğuk işlem" gördü ve nihayetinde tüm ağ tarafından göz ardı edildi.
İşte bu, son bölünmenin özüdür: Önceki liderin bloğu, bir sonraki liderin ihmali veya kötü niyeti nedeniyle atlanır.
Neden kuyruk bölümü ciddi şekilde ayrılıyor?
Son dal probleminin temel olarak iki yönü vardır: 1) Teşvik mekanizması zarar görür, 2) Sistemin aktifliği tehdit altındadır.
Birincisi, ödüller yutuldu:
Bir blok terk edilirse, onu öneren lider hiçbir ödül almaz. Ne blok ödülü ne de işlem ücreti. Örneğin, Alice geçerli bir blok önerdi ve süper çoğunluğun desteğini aldı, ancak Bob'un hatası veya kötü niyetli eylemi nedeniyle bu blok onaylanmadı, Alice sonunda bir kuruş bile kazanamaz. Bu yanlış bir teşvik yapısı yaratır: Bob gibi kötü niyetli düğümler, rakiplerinin bloklarını atlayarak onların ödül kaynaklarını "kestirebilirler". Bu tür bir davranış teknik bir saldırı gerektirmez, sadece kasıtlı olarak "işbirliği yapmamak" yeterlidir ve rakiplerin kazançlarını zayıflatabilir. Eğer bu tür olaylar sürekli olarak yaşanırsa, zamanla sistemin katılım oranı ve adaleti düşer ve hatta düğümler arasında komplo kurulmasına yol açabilir.
İkincisi, MEV saldırı alanı genişliyor:
Son dallanma, daha gizli ama ciddi bir sorunu da beraberinde getiriyor: MEV (Maksimum Elde Edilebilir Değer) kötü niyetli manipülasyona açık hale geliyor. Örnek vermek gerekirse: Alice'in bloğunda son derece değerli bir arbitraj işlemi olduğunu varsayalım. Bob, bir şekilde karıştırmak isterse, bir sonraki lider Carol ile anlaşarak Alice'in bloğunu kasıtlı olarak yayımlamayabilir. Ardından Carol, aynı yükseklikte yeni bir blok inşa ederek Alice'in o arbitraj işlemini "çalabilir" - MEV kazancını kendine dönüştürür. Bu "zincir başı yeniden sıralama + komplo ile ele geçirme" uygulaması, yüzeyde hala kurallara göre blok oluşturuyormuş gibi görünse de, aslında özenle tasarlanmış bir yağmadır. Daha kötüsü, bu durum liderler arasında bir "komploluk ilişkisi" kurmaya teşvik edebilir, böylece blok onayı bir çıkar dağıtım oyununa dönüşür, kamu hizmeti değil.
Nakamoto benzeri protokollere kıyasla, BFT'nin en büyük avantajlarından biri belirleyici sonluktur: Bir blok gönderildiğinde, geri alınamaz. Ancak, son kısımda oluşan çatlak bu garantiyi bozmakta, özellikle "oy alınmış ancak henüz resmen onaylanmamış" bloklar üzerinde. Bazı yüksek verimli dapp'ler, genellikle blok oyu geçtikten sonra verileri hemen okumak isteyerek gecikmeyi azaltmayı hedeflerler ve eğer bu blok aniden atılırsa, kullanıcı durumunun geri alınmasına neden olabilir - örneğin, hesap bakiyesinin anormal olması, yeni tamamlanmış yüksek kaldıraçlı işlemlerin kaybolması, oyun durumunun aniden sıfırlanması gibi.
Dördüncü, zincirleme arızalara neden olabilecek:
Genel olarak, son bölgedeki çatallanma sadece bir bloğun bir tur daha geç onaylanmasına neden olabilir, bu da pek büyük bir etki yaratmaz. Ancak bazı kenar senaryolarında, eğer ardışık birkaç lider bir önceki bloğu atlamayı seçerse, sistem duraksama durumuna girebilir; kimse "önceki bloğu üstlenmek" istemez. Tüm zincirin ilerleyişi böylece durur, ta ki sonunda "sorumluluğu üstlenmeye istekli" bir lider ortaya çıkana kadar, ağ ancak o zaman ilerlemeye devam edecektir.
Önceden BeeGees protokolü tarafından önerilen son çataldan kaçınma mekanizması gibi bazı çözümler olsa da, genellikle performanstan fedakarlık yapmayı gerektirir, örneğin ikincil iletişim karmaşıklığını yeniden getirerek, bu da zarar getiren bir durumdur.
MonadBFT nedir?
MonadBFT, son dal parçalanma problemini çözmek için tasarlanmış yeni nesil bir konsensüs protokolüdür. Gücü, yapılandırma risklerini çözerken HotStuff'ın sağladığı performans avantajlarından taviz vermemesindedir. Diğer bir deyişle, MonadBFT tamamen sıfırdan başlamaz, HotStuff'ın temel çerçevesine dayanarak optimizasyon yapmaya devam eder. Üç temel özelliği korur:
Dönüşümlü liderlik (rotating leader): Her turda zinciri ilerletmek için yeni bir lider seçilir;
Boru hattı ile gönderim (pipelined commits): Birden fazla blok onay süreci üst üste yapılabilir;
Doğrusal iletişim (linear messaging): Her bir doğrulayıcı sadece liderle iletişim kurması yeterli olup, bu da büyük miktarda ağ maliyetinden tasarruf sağlar.
Ancak bu üç noktaya dayanarak güvenlik yeterli değildir. MonadBFT, bu yapısal açığı kapatmak için iki kritik mekanizma ekledi:
Zorunlu Yeniden Teklif Mekanizması (Re-Proposal)
2）Onay Belgesi Olmadan (NEC, No-Endorsement Certificate)
Yeniden Öneri Mekanizması (Re-Proposal)
BFT protokolünde, zaman birer birer turlara (view olarak adlandırılır) bölünmüştür ve her turda yeni blok önermekle sorumlu bir lider vardır. Eğer lider başarısız olursa (örneğin, zamanında blok öneremezse veya öneri geçersizse), sistem bir sonraki tura geçer ve yeni bir lider seçer.
MonadBFT, view geçişi sırasında, dürüst bir şekilde önerilen blokların lider değişimi nedeniyle "aksamaması" için bir mekanizma eklemiştir.
Geçerli tur lideri başarısız olduğunda, doğrulayıcı, mevcut turun zaman aşımına uğradığını belirten imzalı bir tur değiştirme mesajı (view change) gönderir.
Özellikle, bu mesaj sadece "zaman aşımına uğradı" demekle kalmaz, aynı zamanda bu doğrulayıcının en son oy kullandığı blok bilgilerini de içermelidir. Bu, "Geçerli bir öneri almadım, bu benim şu anda gördüğüm en son blok." demektir.
Yeni bir lider, süper çoğunluktan (2f+1) doğrulayıcıdan bu zaman aşımı mesajlarını toplayacak ve bunları bir zaman aşımı belgesi (Timeout Certificate, TC) haline getirecektir. Bu TC, bir önceki tur başarısız olduğunda, tüm ağın "zincir baş blok" üzerindeki ortak kavrayış anlık görüntüsünü temsil eder. Yeni lider, buradan en yüksek yüksekliği (veya en son görünüm numarasını) olan bloğu, yani sözde high_tip'i seçecektir.
MonadBFT gereksinimleri: Yeni liderin önerisi, geçerli bir TC içermeli ve TC'deki en yüksek bekleyen bloğun tekrar önerilmesi gerekmektedir, böylece bu bloğun onaylanma şansı tekrar elde edilmiştir.
Neden? Daha önce de belirttiğimiz gibi: Onaylanmak üzere olan bir bloğun kaybolmasını istemiyoruz.
Bir örnek verelim: Diyelim ki Alice, view 5'in lideridir, geçerli bir blok önerir ve çoğunluk oyunu alır. Sonrasında, view 6'nın lideri Bob çevrimdışıdır ve zincir sürecini ilerletemez. Carol, view 7'nin lideri olduğunda, MonadBFT kurallarına göre, TC'yi içermesi ve Alice'in bloğunu yeniden önermesi gerekir. Böylece, Alice'in dürüst çalışmaları boşa gitmemiş olur.
Eğer Carol'un Alice'in blokları yoksa, diğer düğümlerden isteyebilir. Düğüm şunları yapabilir:
Bu bloğu sağlayın ya da
Bir imzalı "desteksiz mesaj" (No-Endorsement, NE) döndürün, bu mesaj kendisinin bu bloğa sahip olmadığını belirtir (mekanizması daha sonra açıklanacaktır). (En fazla f adet Byzantium düğümü isteği göz ardı etmeyi ve yanıt vermemeyi seçebilir.)
Carol, Alice'nin bloğunu yeniden önerdiğinde, bir ek öneri şansı kazanacak ve önceki tur liderinin başarısızlığından dolayı "birlikte cezalandırılmayacak".
Bu yeniden öneri mekanizmasının amacı açıktır: zincirin ilerlemesini adil bir şekilde sağlamak, herhangi bir geçerli çalışmanın şanssızlık veya birinin müdahalesi nedeniyle gizlice terk edilmemesini temin etmektir.
Arka Belgesi Olmayan Sertifika (NEC)
Devam eden örnek: Bob'un tur süresi dolduktan sonra, Carol diğer doğrulayıcılardan high_tip bloğunu (yani Alice'in bloğunu) istemektedir. Bu durumda, en az 2f+1 doğrulayıcı yanıt verecektir:
Ya Alice'in bloğunu sağlayın.
Ya Alice'in bloğunu almadığını belirten imzalı NE mesajı gönder ya da
Carol, Alice'nin blokunu aldıktan sonra, kurallara göre onu yeniden önermek zorundadır. Sadece en az f+1 doğrulayıcı NE mesajına imza attığında, Carol bu bloğu atlayabilir ve yeni bir blok önerebilir.
Neden f+1? 3f+1 doğrulayıcıdan oluşan bir BFT sisteminde, en fazla f kadar kötü niyetli olabilir. Eğer Alice'in bloğu gerçekten de süper çoğunluk oyu aldıysa, en az 2f+1 dürüst düğüm onu almıştır.
Bu nedenle, eğer Carol "Alice'in bloğunu alamıyorum" diyorsa, bu kişilerin hepsinin almadığını kanıtlamak için f+1 adet doğrulayıcı imzası getirmesi gerekir. Bu, bir No-Endorsement Certificate (NEC) oluşturur.
NEC, liderlerin "sorumluluktan muaf" belgesidir: Önceki blok henüz onaylanmaya hazır olmadığını gösteren, kötü niyetli bir şekilde atlanmadığını, aksine mantıklı bir şekilde "vazgeçildiğini" belirten doğrulanabilir bir kanıttır.
Yeniden öneri + arka planda onay belgesi yok = son çatallanmayı çözme
MonadBFT, yeniden öneri mekanizması (Re-Proposal) ve desteklenmeyen sertifika (NEC, No-Endorsement Certificate) getirerek, katı ve net bir zincir başı işleme kuralı seti oluşturmuştur:
Ya da "onaylanmaya yakın" blokları nihai olarak tamamlayın;
Yeterli kanıt sağlamalısınız ki bu blok, onaylanma koşullarını taşımaz.
Aksi takdirde, önceki blok atlanamaz veya değiştirilemez.
Bu mekanizma, yasal çoğunluk oyu almış herhangi bir bloğun liderin hatası veya kasıtlı olarak göz ardı edilmesi nedeniyle terk edilmeyeceğini garanti eder.
Kuyruğun bölünme yapısal riski sistematik olarak çözüme kavuşturulmuş, protokol uygunsuz atlama eylemlerine karşı belirgin bir kısıtlama getirebilmektedir.
Eğer bir lider nedensiz yere bir önceki bloğu atlamaya çalışırsa ve NEC kanıtı sunamazsa, protokol bu durumu hemen tanıyacak ve reddedecektir. Kripto kanıtı olmayan atlama eylemleri yasadışı sayılacak ve ağ konsensüsü desteği almayacaktır.
Ekonomik teşvikler açısından, bu tasarım doğrulayıcılara net bir koruma sunmaktadır:
Dürüst bir şekilde önerilen ve oy desteği alan blokların ödülü, sonraki aşamalarda meydana gelen arızalardan dolayı alınamaz.
Aşırı durumlarda bile, örneğin bir düğümün kendi teklif turunu kasten atlayarak başkalarının önceki bloktaki MEV'yi ele geçirmesine yardımcı olmaya çalışması durumunda, protokol, sonraki liderin öncelikle orijinal bloğu yeniden önermesini zorunlu kılacak, bu da saldırganların süreci atlayarak ekonomik kazanç elde etmesini engelleyecektir.
Önemli olan, MonadBFT'nin güvenliği artırmak için protokolün performansından ödün vermemiş olmasıdır.
Önceki bazı uç bölünme ile başa çıkma tasarımları (örneğin BeeGees protokolü) belirli bir koruma kapasitesine sahip olsa da, genellikle yüksek iletişim karmaşıklığına (n²) veya her turda yeniden iletişim sürecinin etkinleştirilmesine dayanır; bu da pratikte sistem yükünü önemli ölçüde artırır.
MonadBFT'nin tasarım stratejisi daha zekice:
Sadece görünüm başarısız olduğunda veya bir anomali olduğunda ek iletişim başlatılır (örneğin zaman aşımı mesajları, blok yeniden önerme). Çoğu dürüst liderin sürekli blok oluşturduğu normal yol üzerinde, protokol hala hafif ve verimli bir çalışma durumunu korumaktadır.
Bu performans ve güvenlik arasındaki dinamik denge, MonadBFT'nin önceki protokollere göre en önemli avantajlarından biridir.
Özet
Bu makale, geleneksel PBFT konsensüsünün temel mekanizmalarını gözden geçirmekte, HotStuff protokolünün gelişim yolunu incelemekte ve özellikle MonadBFT'nin protokol katmanı yapısı açısından, boru hattı HotStuff'un içsel son dalgalanma sorununu nasıl çözdüğünü açıklamaktadır.
Son kısım dalgalanması, blok önericisinin ekonomik teşviklerini çarpıtabilir ve ağa yönelik potansiyel bir tehdit oluşturabilir. MonadBFT, yeniden öneri mekanizması ve arka planda desteklenmeyen sertifikalar (NEC) getirerek, dürüst liderler tarafından önerilen ve yasal çoğunluk oyu alan blokların terkedilmeyeceğini veya atlanmayacağını garanti eder.
Bir sonraki yazıda, MonadBFT'nin diğer iki temel özelliğini keşfetmeye devam edeceğiz:
Kesin Sonuç (Speculative Finality)
İyimser Yanıt Verme (Optimistic Responsiveness)
Ve bu mekanizmaların doğrulayıcılar ve geliştiriciler için pratik anlamını daha da analiz edin.
Devam edecek.
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: Blok Zinciri Konsensüs güvenliğini yeniden tanımlamak, son çatal riskine veda etmek
Yazar: michaellwy
Blok zincirinin özü, katı bir küresel konsensüs sağlamaktır: yani, ağ düğümlerinin hangi ülkede veya hangi zaman diliminde bulunduğuna bakılmaksızın, tüm katılımcıların sonunda bir dizi nesnel sonuç üzerinde hemfikir olmaları gerekir.
Ama gerçek hayattaki dağıtık ağlar pek de ideal değil: bazı düğümler çevrimdışı kalıyor, bazı düğümler yalan söylüyor, hatta bazı insanlar kasıtlı olarak zarar veriyor. Bu durumda sistem "birçok ağızdan tek söz" nasıl tutuyor, nasıl tutarlılığı sağlıyor?
Konsensüs protokollerinin çözmek için tasarlandığı sorun budur. Esasen, tam olarak güvenilmese de bir grup bağımsız düğüme, her işlemin sırası ve içeriği hakkında birleşik kararlar almaları için rehberlik eden bir dizi kuraldır.
Bu "katı fikir birliği" kurulduktan sonra, blok zinciri dijital mülk koruması, enflasyona dayanıklı parasal modeller ve ölçeklenebilir sosyal işbirliği yapıları gibi bir dizi temel özelliğin kilidini açar. Ancak öncül, konsensüs protokolünün kendisinin aynı anda iki temeli garanti etmesi gerektiğidir:
İki çelişkili bloğun aynı anda onaylanması mümkün değildir;
Ağ ilerlemeye devam etmeli ve takılıp kalmamalı veya kapanmamalıdır.
MonadBFT, bu yönde yapılan en son teknik atılımdır.
Konsensüs protokolünün kısa evrimi incelemesi
Konsensüs mekanizması alanında aslında on yıllardır araştırma yapılmaktadır. En erken protokollerden biri olan PBFT (Pratik Bizans Hata Toleransı), belirli bir gerçek durumu işleyebilme yeteneğine sahiptir: ağda bazı düğümler koparsa, kötü niyetli davranırsa veya saçmalarsa, toplam sayının %1'inden fazlası olmadıkça sistem yine de bir uzlaşmaya varabilir.
Bu erken protokollerin tasarım biçimi daha "geleneksel": Her turda bir lider seçilir, o öneriyi başlatır, diğer doğrulayıcılar bu öneri üzerinde çoklu oylamalar yaparak işlem sırasını adım adım onaylar.
Oylama süreci genellikle birkaç aşamadan oluşur, örneğin pre-prepare, prepare, commit, reply. Her aşamada, tüm doğrulayıcıların birbirleriyle iletişim kurması gerekir. Diğer bir deyişle, herkesin herkesle bir kez konuşması gerekir, bu da mesaj miktarının "ağ" şeklinde patlayıcı bir şekilde artmasına neden olur.
Bu iletişim yapısının karmaşıklığı n²'dir - yani eğer ağda 100 doğrulayıcı varsa, her konsensüs turunda neredeyse 10.000 mesaj iletilmesi gerekebilir.
Bu, küçük bir ağda büyük bir sorun değildir, ancak doğrulayıcı sayısı arttığında, sistem üzerindeki iletişim yükü hızla dayanılmaz hale gelebilir ve verimlilik doğrudan azalacaktır.
Kaynak:
Bu "herkesin herkesle iletişim kurması gerektiği" ikincil iletişim yapısı aslında oldukça verimsizdir. Örneğin, 100 doğrulayıcıdan oluşan bir ağda, her konsensüs turunda on binlerce mesaj işlenmesi gerekebilir.
Bu, küçük bir çevrede yönetilebilir, ancak küresel ölçekte, açık bir zincir ağına yerleştirildiğinde, iletişim yükü hemen kabul edilemez hale gelir. Bu nedenle, PBFT ve Tendermint gibi erken dönem BFT protokolleri genellikle izinli senaryolar (permissioned network) veya çok az sayıda doğrulayıcıya sahip sistemlerde kullanılmakta, ancak ancak bu şekilde çalıştırılabilmektedir.
BFT protokolünün izin gerektirmeyen, halka açık bir ortamda da uyum sağlaması için, bazı yeni nesil tasarımlar daha hafif iletişim yollarına yönelmeye başladı: Her bir doğrulayıcının yalnızca liderle iletişim kurması, herkesin birbirine veri iletmesi yerine.
Bu, mesaj karmaşıklığını n²'den n'ye optimize eder ve sistem üzerindeki yükü büyük ölçüde azaltır.
HotStuff protokolü, 2018 yılında ortaya atılmıştır ve bu ölçeklenebilirlik sorununu çözmek amacıyla tasarlanmıştır. Tasarım felsefesi oldukça nettir: Daha basit, lider odaklı bir iletişim yapısı ile PBFT'nin karmaşık oylama sürecinin yerini almasıdır.
HotStuff'un ana özelliklerinden biri, sözde doğrusal iletişimdir (linear communication). Mekanizmasında, her doğrulayıcı yalnızca kendi oyunu mevcut liderine iletmek zorundadır, lider bu oyları paketleyerek bir Quorum Sertifikası (QC, yasal çoğunluk belgesi) oluşturur.
Bu QC aslında bir toplu imza olup, tüm ağa şu şekilde kanıtlar: "Çoğu düğüm bu teklifi kabul etti."
Buna karşılık, PBFT'nin iletişim modeli "tam yayın"dır; herkes grupta konuşur ve ortam bir anda oldukça kaotik hale gelir. HotStuff'un modeli ise "bir kişi toplar, bir seferde paketler" gibidir; ağda ne kadar çok insan olursa olsun, yüksek verimlilikle çalışmaya devam edebilir.
Yukarıdaki resim, HotStuff'un fan-out iletişim yapısını PBFT'nin küresel bağlantı modeli ile karşılaştırmaktadır.
Kaynak:
Doğrusal iletişimin yanı sıra, HotStuff daha fazla verimlilik artırmak için bir akış versiyonuna (pipelined HotStuff) yükseltilebilir.
Orijinal HotStuff'ta, aynı doğrulayıcı bir blok tamamen onaylanana kadar ardışık olarak birçok tur lideri olarak görev yapar. Bu süreç, "her turda bir blok işlemek" şeklindedir ve tüm enerji mevcut olanı ilerletmeye odaklanır.
Ve HotStuff akışında, mekanizma daha esnek hale geliyor: Her turun yeni bir lider seçmesini sağlıyor ve her liderin iki görevi var:
Bir yandan önceki oylamanın Quorum Certificate (QC) haline getirilmesi ve tüm ağa yayınlanması;
Yeni bir blok önerirken, bir sonraki turu başlatmaya hazırlanıyor.
Yani, artık "birini onayladıktan sonra diğerine geçmek" yok, bunun yerine bir üretim hattı gibi, farklı liderler her aşamada sırayla sorumluluk alıyor. Önceki kişi bloğu öneriyor, sonraki kişi onu onaylıyor ve yeni bloklar önermeye devam ediyor, zincir üzerindeki konsensüs bir bayrak yarışı gibi devam ediyor.
Bu, "montaj hattı" metaforunun kökenidir: mevcut blok hala onay sürecinden geçmektedir ve bir sonraki, verim verimliliğini artırmak için paralel olarak birden fazla adımla zaten hazırlık aşamasındadır.
Özetle, HotStuff gibi protokoller geleneksel BFT'ye göre iki boyutta önemli iyileştirmeler yapmıştır:
Birincisi, iletişim daha hafif, her bir doğrulayıcı yalnızca liderle iletişim kurması yeterlidir;
İkincisi, işleme verimliliği daha yüksektir, birden fazla blok onay süreci paralel olarak gerçekleştirilebilir.
Bu, HotStuff'u birçok modern PoS blok zinciri konsensüs mekanizmasının tasarım şablonu haline getirdi. Ancak her şeyde olduğu gibi, avantajlar ve dezavantajlar vardır - akış şeması yapısı güçlü bir performans sunarken, aynı zamanda kolayca fark edilmeyen bir yapısal risk de getirmektedir.
Şimdi bu temel konuyu derinlemesine tartışacağız: Kuyruk Dallanması (Tail Forking).
Kuyruk Dallanma Sorunu (Tail-Forking)
HotStuff, özellikle de onun boru hattı versiyonu, konsensüs protokollerinin ölçeklenebilirlik sorununu çözmesine rağmen, bazı yeni zorluklar da getirmiştir. Bunların en kritik ve en kolay gözden kaçanı ise "kuyruk bölünmesi" (Tail Forking) sorunudur.
Kuyruk bölünmesi nedir? Basitçe şöyle anlaşılabilir: Blok zincirinde "kuyrukta" beklenmedik bir blok yeniden düzenlemesi meydana geldi (reorg).
Özellikle, geçerli olan ve çoğu doğrulayıcıya başarıyla ulaştırılmış bir blok var, yeterli oy desteği de almış durumda. Normalde, hemen onaylanması ve ana zincire yazılması gerekiyordu. Ancak sonunda, "atlandı" ve terk edildi (yani orphaned), yerine aynı yükseklikteki başka bir yeni blok geçti.
Bu bir hata değil, saldırı da değil, bunun nedeni protokolün kendisinin tasarım yapısında "ağ kopma" olasılığının bulunmasıdır. Bu biraz adaletsiz gibi mi geliyor? Peki, bu tam olarak nasıl oluyor?
Daha önce bahsettiğimiz gibi, HotStuff hattındaki her liderin iki görevi vardır:
A. Yeni bir blok öner (örneğin Bₙ₊₁)
B. Önceki liderin blok için oy toplaması, QC oluşturması (örneğin Bₙ için nihai onay tamamlanması)
Bu iki görev paralel olarak, sırayla gerçekleştiriliyor. Ama sorun burada ortaya çıkıyor.
Bir örnek vermek gerekirse: Diyelim ki Alice liderdir, n. yükseklikte Bₙ bloğunu önerdi, bu blok süper çoğunluk oyunu aldı ve "neredeyse onaylandı".
Sonraki adımda Bob lider olarak görev almalı ve zincirin bir sonraki bloğu Bₙ₊₁'i ilerletmelidir. Aynı zamanda, Bₙ'in QC'sini (yasal çoğunluk kanıtı) teklifine eklemeli ve Bₙ'in nihai onayını tamamlamalıdır.
Ancak eğer Bob bu sırada çevrimdışıysa ya da Bₙ'in QC'sini kasten sunmuyorsa, o zaman sorun çıkacaktır.
Alice'in bloğu için QC paketini tamamlayacak kimse olmadığı için Bₙ'in oy kayıtları yayılamadı. Bu, onaylanması gereken bir bloktu ve böylece "soğuk işlem" gördü ve nihayetinde tüm ağ tarafından göz ardı edildi.
İşte bu, son bölünmenin özüdür: Önceki liderin bloğu, bir sonraki liderin ihmali veya kötü niyeti nedeniyle atlanır.
Neden kuyruk bölümü ciddi şekilde ayrılıyor?
Son dal probleminin temel olarak iki yönü vardır: 1) Teşvik mekanizması zarar görür, 2) Sistemin aktifliği tehdit altındadır.
Birincisi, ödüller yutuldu:
Bir blok terk edilirse, onu öneren lider hiçbir ödül almaz. Ne blok ödülü ne de işlem ücreti. Örneğin, Alice geçerli bir blok önerdi ve süper çoğunluğun desteğini aldı, ancak Bob'un hatası veya kötü niyetli eylemi nedeniyle bu blok onaylanmadı, Alice sonunda bir kuruş bile kazanamaz. Bu yanlış bir teşvik yapısı yaratır: Bob gibi kötü niyetli düğümler, rakiplerinin bloklarını atlayarak onların ödül kaynaklarını "kestirebilirler". Bu tür bir davranış teknik bir saldırı gerektirmez, sadece kasıtlı olarak "işbirliği yapmamak" yeterlidir ve rakiplerin kazançlarını zayıflatabilir. Eğer bu tür olaylar sürekli olarak yaşanırsa, zamanla sistemin katılım oranı ve adaleti düşer ve hatta düğümler arasında komplo kurulmasına yol açabilir.
İkincisi, MEV saldırı alanı genişliyor:
Son dallanma, daha gizli ama ciddi bir sorunu da beraberinde getiriyor: MEV (Maksimum Elde Edilebilir Değer) kötü niyetli manipülasyona açık hale geliyor. Örnek vermek gerekirse: Alice'in bloğunda son derece değerli bir arbitraj işlemi olduğunu varsayalım. Bob, bir şekilde karıştırmak isterse, bir sonraki lider Carol ile anlaşarak Alice'in bloğunu kasıtlı olarak yayımlamayabilir. Ardından Carol, aynı yükseklikte yeni bir blok inşa ederek Alice'in o arbitraj işlemini "çalabilir" - MEV kazancını kendine dönüştürür. Bu "zincir başı yeniden sıralama + komplo ile ele geçirme" uygulaması, yüzeyde hala kurallara göre blok oluşturuyormuş gibi görünse de, aslında özenle tasarlanmış bir yağmadır. Daha kötüsü, bu durum liderler arasında bir "komploluk ilişkisi" kurmaya teşvik edebilir, böylece blok onayı bir çıkar dağıtım oyununa dönüşür, kamu hizmeti değil.
Üçüncüsü, nihai güvenliği bozmak, kullanıcı deneyimini etkilemek:
Nakamoto benzeri protokollere kıyasla, BFT'nin en büyük avantajlarından biri belirleyici sonluktur: Bir blok gönderildiğinde, geri alınamaz. Ancak, son kısımda oluşan çatlak bu garantiyi bozmakta, özellikle "oy alınmış ancak henüz resmen onaylanmamış" bloklar üzerinde. Bazı yüksek verimli dapp'ler, genellikle blok oyu geçtikten sonra verileri hemen okumak isteyerek gecikmeyi azaltmayı hedeflerler ve eğer bu blok aniden atılırsa, kullanıcı durumunun geri alınmasına neden olabilir - örneğin, hesap bakiyesinin anormal olması, yeni tamamlanmış yüksek kaldıraçlı işlemlerin kaybolması, oyun durumunun aniden sıfırlanması gibi.
Dördüncü, zincirleme arızalara neden olabilecek:
Genel olarak, son bölgedeki çatallanma sadece bir bloğun bir tur daha geç onaylanmasına neden olabilir, bu da pek büyük bir etki yaratmaz. Ancak bazı kenar senaryolarında, eğer ardışık birkaç lider bir önceki bloğu atlamayı seçerse, sistem duraksama durumuna girebilir; kimse "önceki bloğu üstlenmek" istemez. Tüm zincirin ilerleyişi böylece durur, ta ki sonunda "sorumluluğu üstlenmeye istekli" bir lider ortaya çıkana kadar, ağ ancak o zaman ilerlemeye devam edecektir.
Önceden BeeGees protokolü tarafından önerilen son çataldan kaçınma mekanizması gibi bazı çözümler olsa da, genellikle performanstan fedakarlık yapmayı gerektirir, örneğin ikincil iletişim karmaşıklığını yeniden getirerek, bu da zarar getiren bir durumdur.
MonadBFT nedir?
MonadBFT, son dal parçalanma problemini çözmek için tasarlanmış yeni nesil bir konsensüs protokolüdür. Gücü, yapılandırma risklerini çözerken HotStuff'ın sağladığı performans avantajlarından taviz vermemesindedir. Diğer bir deyişle, MonadBFT tamamen sıfırdan başlamaz, HotStuff'ın temel çerçevesine dayanarak optimizasyon yapmaya devam eder. Üç temel özelliği korur:
Dönüşümlü liderlik (rotating leader): Her turda zinciri ilerletmek için yeni bir lider seçilir;
Boru hattı ile gönderim (pipelined commits): Birden fazla blok onay süreci üst üste yapılabilir;
Doğrusal iletişim (linear messaging): Her bir doğrulayıcı sadece liderle iletişim kurması yeterli olup, bu da büyük miktarda ağ maliyetinden tasarruf sağlar.
Ancak bu üç noktaya dayanarak güvenlik yeterli değildir. MonadBFT, bu yapısal açığı kapatmak için iki kritik mekanizma ekledi:
2）Onay Belgesi Olmadan (NEC, No-Endorsement Certificate)
Yeniden Öneri Mekanizması (Re-Proposal)
BFT protokolünde, zaman birer birer turlara (view olarak adlandırılır) bölünmüştür ve her turda yeni blok önermekle sorumlu bir lider vardır. Eğer lider başarısız olursa (örneğin, zamanında blok öneremezse veya öneri geçersizse), sistem bir sonraki tura geçer ve yeni bir lider seçer.
MonadBFT, view geçişi sırasında, dürüst bir şekilde önerilen blokların lider değişimi nedeniyle "aksamaması" için bir mekanizma eklemiştir.
Geçerli tur lideri başarısız olduğunda, doğrulayıcı, mevcut turun zaman aşımına uğradığını belirten imzalı bir tur değiştirme mesajı (view change) gönderir.
Özellikle, bu mesaj sadece "zaman aşımına uğradı" demekle kalmaz, aynı zamanda bu doğrulayıcının en son oy kullandığı blok bilgilerini de içermelidir. Bu, "Geçerli bir öneri almadım, bu benim şu anda gördüğüm en son blok." demektir.
Yeni bir lider, süper çoğunluktan (2f+1) doğrulayıcıdan bu zaman aşımı mesajlarını toplayacak ve bunları bir zaman aşımı belgesi (Timeout Certificate, TC) haline getirecektir. Bu TC, bir önceki tur başarısız olduğunda, tüm ağın "zincir baş blok" üzerindeki ortak kavrayış anlık görüntüsünü temsil eder. Yeni lider, buradan en yüksek yüksekliği (veya en son görünüm numarasını) olan bloğu, yani sözde high_tip'i seçecektir.
MonadBFT gereksinimleri: Yeni liderin önerisi, geçerli bir TC içermeli ve TC'deki en yüksek bekleyen bloğun tekrar önerilmesi gerekmektedir, böylece bu bloğun onaylanma şansı tekrar elde edilmiştir.
Neden? Daha önce de belirttiğimiz gibi: Onaylanmak üzere olan bir bloğun kaybolmasını istemiyoruz.
Bir örnek verelim: Diyelim ki Alice, view 5'in lideridir, geçerli bir blok önerir ve çoğunluk oyunu alır. Sonrasında, view 6'nın lideri Bob çevrimdışıdır ve zincir sürecini ilerletemez. Carol, view 7'nin lideri olduğunda, MonadBFT kurallarına göre, TC'yi içermesi ve Alice'in bloğunu yeniden önermesi gerekir. Böylece, Alice'in dürüst çalışmaları boşa gitmemiş olur.
Eğer Carol'un Alice'in blokları yoksa, diğer düğümlerden isteyebilir. Düğüm şunları yapabilir:
Bu bloğu sağlayın ya da
Bir imzalı "desteksiz mesaj" (No-Endorsement, NE) döndürün, bu mesaj kendisinin bu bloğa sahip olmadığını belirtir (mekanizması daha sonra açıklanacaktır). (En fazla f adet Byzantium düğümü isteği göz ardı etmeyi ve yanıt vermemeyi seçebilir.)
Carol, Alice'nin bloğunu yeniden önerdiğinde, bir ek öneri şansı kazanacak ve önceki tur liderinin başarısızlığından dolayı "birlikte cezalandırılmayacak".
Bu yeniden öneri mekanizmasının amacı açıktır: zincirin ilerlemesini adil bir şekilde sağlamak, herhangi bir geçerli çalışmanın şanssızlık veya birinin müdahalesi nedeniyle gizlice terk edilmemesini temin etmektir.
Arka Belgesi Olmayan Sertifika (NEC)
Devam eden örnek: Bob'un tur süresi dolduktan sonra, Carol diğer doğrulayıcılardan high_tip bloğunu (yani Alice'in bloğunu) istemektedir. Bu durumda, en az 2f+1 doğrulayıcı yanıt verecektir:
Ya Alice'in bloğunu sağlayın.
Ya Alice'in bloğunu almadığını belirten imzalı NE mesajı gönder ya da
Carol, Alice'nin blokunu aldıktan sonra, kurallara göre onu yeniden önermek zorundadır. Sadece en az f+1 doğrulayıcı NE mesajına imza attığında, Carol bu bloğu atlayabilir ve yeni bir blok önerebilir.
Neden f+1? 3f+1 doğrulayıcıdan oluşan bir BFT sisteminde, en fazla f kadar kötü niyetli olabilir. Eğer Alice'in bloğu gerçekten de süper çoğunluk oyu aldıysa, en az 2f+1 dürüst düğüm onu almıştır.
Bu nedenle, eğer Carol "Alice'in bloğunu alamıyorum" diyorsa, bu kişilerin hepsinin almadığını kanıtlamak için f+1 adet doğrulayıcı imzası getirmesi gerekir. Bu, bir No-Endorsement Certificate (NEC) oluşturur.
NEC, liderlerin "sorumluluktan muaf" belgesidir: Önceki blok henüz onaylanmaya hazır olmadığını gösteren, kötü niyetli bir şekilde atlanmadığını, aksine mantıklı bir şekilde "vazgeçildiğini" belirten doğrulanabilir bir kanıttır.
Yeniden öneri + arka planda onay belgesi yok = son çatallanmayı çözme
MonadBFT, yeniden öneri mekanizması (Re-Proposal) ve desteklenmeyen sertifika (NEC, No-Endorsement Certificate) getirerek, katı ve net bir zincir başı işleme kuralı seti oluşturmuştur:
Ya da "onaylanmaya yakın" blokları nihai olarak tamamlayın;
Yeterli kanıt sağlamalısınız ki bu blok, onaylanma koşullarını taşımaz.
Aksi takdirde, önceki blok atlanamaz veya değiştirilemez.
Bu mekanizma, yasal çoğunluk oyu almış herhangi bir bloğun liderin hatası veya kasıtlı olarak göz ardı edilmesi nedeniyle terk edilmeyeceğini garanti eder.
Kuyruğun bölünme yapısal riski sistematik olarak çözüme kavuşturulmuş, protokol uygunsuz atlama eylemlerine karşı belirgin bir kısıtlama getirebilmektedir.
Eğer bir lider nedensiz yere bir önceki bloğu atlamaya çalışırsa ve NEC kanıtı sunamazsa, protokol bu durumu hemen tanıyacak ve reddedecektir. Kripto kanıtı olmayan atlama eylemleri yasadışı sayılacak ve ağ konsensüsü desteği almayacaktır.
Ekonomik teşvikler açısından, bu tasarım doğrulayıcılara net bir koruma sunmaktadır:
Dürüst bir şekilde önerilen ve oy desteği alan blokların ödülü, sonraki aşamalarda meydana gelen arızalardan dolayı alınamaz.
Aşırı durumlarda bile, örneğin bir düğümün kendi teklif turunu kasten atlayarak başkalarının önceki bloktaki MEV'yi ele geçirmesine yardımcı olmaya çalışması durumunda, protokol, sonraki liderin öncelikle orijinal bloğu yeniden önermesini zorunlu kılacak, bu da saldırganların süreci atlayarak ekonomik kazanç elde etmesini engelleyecektir.
Önemli olan, MonadBFT'nin güvenliği artırmak için protokolün performansından ödün vermemiş olmasıdır.
Önceki bazı uç bölünme ile başa çıkma tasarımları (örneğin BeeGees protokolü) belirli bir koruma kapasitesine sahip olsa da, genellikle yüksek iletişim karmaşıklığına (n²) veya her turda yeniden iletişim sürecinin etkinleştirilmesine dayanır; bu da pratikte sistem yükünü önemli ölçüde artırır.
MonadBFT'nin tasarım stratejisi daha zekice:
Sadece görünüm başarısız olduğunda veya bir anomali olduğunda ek iletişim başlatılır (örneğin zaman aşımı mesajları, blok yeniden önerme). Çoğu dürüst liderin sürekli blok oluşturduğu normal yol üzerinde, protokol hala hafif ve verimli bir çalışma durumunu korumaktadır.
Bu performans ve güvenlik arasındaki dinamik denge, MonadBFT'nin önceki protokollere göre en önemli avantajlarından biridir.
Özet
Bu makale, geleneksel PBFT konsensüsünün temel mekanizmalarını gözden geçirmekte, HotStuff protokolünün gelişim yolunu incelemekte ve özellikle MonadBFT'nin protokol katmanı yapısı açısından, boru hattı HotStuff'un içsel son dalgalanma sorununu nasıl çözdüğünü açıklamaktadır.
Son kısım dalgalanması, blok önericisinin ekonomik teşviklerini çarpıtabilir ve ağa yönelik potansiyel bir tehdit oluşturabilir. MonadBFT, yeniden öneri mekanizması ve arka planda desteklenmeyen sertifikalar (NEC) getirerek, dürüst liderler tarafından önerilen ve yasal çoğunluk oyu alan blokların terkedilmeyeceğini veya atlanmayacağını garanti eder.
Bir sonraki yazıda, MonadBFT'nin diğer iki temel özelliğini keşfetmeye devam edeceğiz:
Kesin Sonuç (Speculative Finality)
İyimser Yanıt Verme (Optimistic Responsiveness)
Ve bu mekanizmaların doğrulayıcılar ve geliştiriciler için pratik anlamını daha da analiz edin.
Devam edecek.