Blok zincirinin özü, katı bir küresel konsensüs sağlamaktır: yani, ağ düğümleri hangi ülkede veya hangi zaman diliminde bulunursa bulunsun, tüm katılımcıların sonunda bir grup nesnel sonuç üzerinde uzlaşmaları gerekmektedir.
Ama gerçek hayattaki dağıtık ağlar ideal değil: Düğümler kopuyor, Düğümler yalan söylüyor, hatta bazıları kasıtlı olarak zarar veriyor. Bu durumda, sistem nasıl "ortak bir görüşte" kalıyor ve tutarlılığı sağlıyor?
Bu, konsensüs protokolünün çözmesi gereken bir sorundur. Temelde, birbirinden bağımsız ve hatta tamamen güvenilir olmayan bir grup düğümün, her işlem için sıralama ve içerik konusunda nasıl ortak bir karar alacaklarını belirten bir dizi kuraldır.
Ve bu tür "katı konsensüs" kurulduğunda, blok zinciri birçok kritik özelliği açığa çıkarabilir, örneğin dijital mülkiyet güvencesi, enflasyona karşı para modeli ve ölçeklenebilir sosyal işbirliği yapısı. Ancak öncelikle, konsensüs protokolü kendisi iki temel unsuru aynı anda garanti etmelidir:
İki çelişen blokların aynı anda onaylanması mümkün değildir;
Ağ sürekli ilerlemeli, durmamalı veya takılmamalı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ı bu alanda aslında on yıllardır araştırılıyor. En erken protokollerden biri olan PBFT (Pratik Bizans Hatası Toleransı) bile oldukça gerçekçi bir durumu işleyebiliyor: Ağı içindeki bazı Düğümler arızalanır, kötü niyetli davranır veya saçmalarsa, eğer bunlar toplam sayının 1/3'ünden fazlasını geçmiyorsa, sistem yine de uzlaşabilir.
Bu erken protokollerin tasarım şekli oldukça "geleneksel": Her turda bir lider seçilir, o öneri başlatır, diğer doğrulayıcılar bu öneriye birçok turda oy verir ve işlem sırasını adım adım doğrular.
Tüm oylama süreci genellikle birkaç aşamadan geçer, örneğin pre-prepare, prepare, commit, reply. Her aşamada, tüm doğrulayıcılar birbirleriyle iletişim kurmalıdır. Diğer bir deyişle, herkesin herkesle bir kez konuşması gerekir, mesaj miktarı "ağ" şeklinde patlayıcı bir şekilde artar.
Bu iletişim yapısının karmaşıklığı n²'dir—yani, eğer ağda 100 doğrulayıcı varsa, her bir konsensüs turunda neredeyse 10.000 mesaj iletilmesi gerekebilir.
Bu, küçük ağlarda büyük bir sorun değildir, ancak doğrulayıcı sayısı arttığında, sistemin iletişim yükü hızla dayanılmaz hale gelecek ve verimlilik doğrudan düşecektir.
Bu tür "herkesin herkesle iletişim kurması gereken" ikincil iletişim yapısı aslında çok 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 idare edilebilir, ancak küresel ölçekte, açık bir zincir ağına yerleştirildiğinde, iletişim yükü hemen kabul edilemez hale geliyor. Bu nedenle, PBFT, Tendermint gibi erken BFT protokolleri genellikle izinli senaryolar (permissioned network) veya çok az sayıda doğrulayıcı bulunan sistemlerde kullanılmakta, ancak zorla çalıştırılabilmektedir.
BFT protokolünün izin gerektirmeyen, kamu blok zinciri ortamına da uyum sağlaması için, yeni nesil bazı tasarımlar daha hafif bir iletişim yoluna yönelmeye başladı: Her doğrulayıcının yalnızca liderle iletişim kurması, tüm katılımcılar arasında iletişim kurmak yerine.
Bu, mesaj karmaşıklığını başlangıçtaki n²'den n'ye optimize etti - sistemi büyük ölçüde hafifletti.
HotStuff protokolü, 2018 yılında önerilmiştir ve bu ölçeklenebilirlik sorununu çözmek amacıyla geliştirilmiştir. Tasarım felsefesi oldukça net: PBFT'nin karmaşık oylama sürecinin yerini daha basit, lider odaklı bir iletişim yapısı almalıdır.
HotStuff'un ana özelliği, sözde lineer iletişimdir. Mekanizmasında, her bir doğrulayıcı yalnızca kendi oyunu mevcut liderine göndermelidir, lider daha sonra bu oyları paketleyerek bir Quorum Sertifikası (QC, yasal çoğunluk kanıtı) oluşturur.
Bu QC, esasen bir toplu imza olup tüm ağa "Çoğu Düğüm bu öneriyi kabul etti." şeklinde kanıtlar.
Buna karşılık, PBFT'nin iletişim modeli "tam bir yayılma"dır, herkes grupta konuşur ve ortam bir ara oldukça karmaşık hale gelir. HotStuff'un modeli ise "bir kişi toplar, bir paket yapar" gibidir, ağda kaç kişi olursa olsun yine de yüksek verimlilikle çalışmaya devam edebilir.
Lineer iletişimin yanı sıra, HotStuff ayrıca verimliliği artırmak için bir boru hattı versiyonuna (pipelined HotStuff) yükseltilebilir.
Orijinal HotStuff'ta, aynı doğrulayıcı birden fazla tur lider olarak görev yapar, ta ki bir blok tamamen onaylanana kadar. Bu süreç "her turda bir blok işlemek" şeklindedir ve tüm enerji mevcut olanda ilerlemeye odaklanır.
Ve HotStuff akışında, mekanizma daha esnek hale geldi: her turda yeni bir lider seçilir ve her liderin iki görevi vardır:
Bir yandan bir önceki tur oylamasını Quorum Sertifikası (QC) haline getirip tüm ağa yayınlamak;
Yeni bir blok önerirken, bir sonraki tura hazırlık yapılıyor.
Yani, artık "birini onayladıktan sonra bir sonraki ile ilgilenmek" yok, bunun yerine bir üretim hattı gibi, farklı liderler her aşamada sırayla sorumluluk alıyor. Önceki kişi bir blok öneriyor, sonraki kişi onu onaylıyor ve yeni bloklar önermeye devam ediyor, zincir üzerindeki konsensüs bir bayrak yarışı gibi devam ediyor.
İşte "işlem hattı" benzetmesinin kökeni: Mevcut blok henüz onay sürecinde, bir sonraki blok ise hazırlanıyor, çoklu adımlar paralel olarak ilerliyor, işlem verimliliğini artırıyor.
Özetle, HotStuff gibi protokoller, geleneksel BFT'ye göre iki boyutta önemli iyileştirmeler sağlıyor:
Birincisi, iletişim daha hafif, her doğrulayıcı yalnızca liderle iletişim kurar;
İkincisi, işleme verimliliği daha yüksektir, birden fazla blok onay süreci paralel olarak gerçekleştirilebilir.
Bu, HotStuff'un birçok modern PoS Blok Zinciri konsensüs mekanizmasının tasarım şablonu olmasını sağladı. Ancak her şeyin avantajları ve dezavantajları vardır - hat yapısı güçlü bir performansa sahip olsa da, aynı zamanda kolayca fark edilmeyen bir yapısal riski de gizlice ortaya çıkarıyor.
Şimdi bu temel konuyu derinlemesine ele alacağız: Kuyruk Çatallanması (Tail Forking).
Kuyruk Çatal Sorunu (Tail-Forking)
HotStuff'un, özellikle de onun boru hattı versiyonunun, konsensüs protokolünün ölçeklenebilirlik sorununu çözmesine rağmen, bazı yeni zorluklar da getirdi. Bunların en kritik ve en kolay gözden kaçırılanı, sözde "Kuyruk Dallanması" (Tail Forking) sorunudur.
Son çatallanma nedir? Basitçe şu şekilde anlaşılabilir: Blok zincirinde "zincirin ucu"nda beklenmedik bir blok yeniden yapılandırması gerçekleşti (reorg).
Spesifik olarak, geçerli bir blok var, bu blok çoğu doğrulayıcıya başarıyla yayıldı ve yeterli oy desteği aldı, bu nedenle hemen onaylanması ve ana zincire yazılması gerekiyordu. Ancak sonunda, "atlandı" ve terkedildi (orphaned), yerine aynı yükseklikte başka bir yeni blok geçti.
Bu bir hata değil, saldırı da değil, aksine protokolün tasarım yapısında "zincir uçma" olasılığının bulunmasından kaynaklanıyor. Bu biraz adaletsiz gibi mi geliyor? Peki, bu nasıl oluyor?
Daha önce söylediğimiz gibi, HotStuff akış hattındaki her liderin iki görevi vardır:
A. Yeni bir blok önerin (örneğin Bₙ₊₁)
B. Önceki liderin blokuna oy toplamak, QC oluşturmak (örneğin Bₙ'nin nihai onayını tamamlamak)
Bu iki görev paraleldir, dönüşümlü olarak devralınır. Ama sorun burada ortaya çıkıyor.
Bir örnek vermek gerekirse: Alice lider olsun, o n. yükseklikte Bₙ blokunu önerdi, bu blok süper çoğunluğun oyunu aldı ve "neredeyse onaylandı". Sonrasında Bob lider olarak Bₙ₊₁ blokunu ilerletmeye devam etmelidir, aynı zamanda Bₙ'nin QC'sini (yasal çoğunluk kanıtı) teklifine dahil etmeli, böylece Bₙ'nin nihai onayını tamamlamalıdır.
Ama eğer Bob bu sırada çevrimdışıysa veya kasıtlı olarak Bₙ'in QC'sini sunmazsa, o zaman sorun çıkar.
Çünkü Alice'in blokunu QC paketlemek için kimse yoktu, Bₙ'nin oy kaydı yayılamadı, bu doğrulanması gereken blok böylece "soğuk işlem" olarak kaldı ve nihayetinde tüm ağ tarafından görmezden gelindi.
Bu, son kısmın ayrılmasının özüdür: Önceki liderin bloğu, bir sonraki liderin ihmal veya kötü niyeti nedeniyle atlanmıştır.
Neden uç bölümü ciddi şekilde ayrılıyor?
Son bölünme sorunları iki ana noktada yoğunlaşmaktadır: 1) Teşvik mekanizması bozuldu, 2) Sistemin etkinliği tehdit altında.
İlk olarak, ödüller yutuldu: Bir blok eğer atılırsa, onu öneren lider hiçbir ödül alamaz. Ne blok ödülü ne de işlem ücreti. Örneğin, Alice geçerli bir blok önerdi ve süper çoğunluk oyu aldı, ancak Bob'un hatası veya kötü niyetli eylemi nedeniyle bu blok onaylanmadı, Alice sonunda hiçbir şey kazanamaz. Bu, yanlış bir teşvik yapısına yol açar: Bob gibi kötü niyetli düğümler, rakiplerinin bloklarını atlayarak, onların ödül kaynaklarını "kesebilirler". Bu tür bir davranış teknik bir saldırı gerektirmez, sadece kasıtlı olarak "işbirliği yapmamak" yeterlidir, bu da rakiplerin kazançlarını azaltır. Bu tür durumlar tekrar tekrar meydana gelirse, zamanla tüm sistemin katılımı ve adaleti azalır ve hatta düğümler arasında bir komplo oluşmasına neden olabilir.
İkincisi, MEV saldırı alanı genişliyor: Son kısım dallanması daha gizli ama ciddi bir sorunu da beraberinde getiriyor: MEV (maksimum çıkarılabilir değer) kötü niyetle manipüle edilme alanı büyüdü. Bir örnek vermek gerekirse: Alice'in bloğunda son derece değerli bir arbitraj işlemi var. Bob, eğer bir sorun çıkarmak isterse, bir sonraki lider Carol ile iş birliği yapabilir ve Alice'in bloğunu kasıtlı olarak yaymamayı seçebilir. Ardından Carol, aynı yükseklikte yeni bir blok oluşturarak Alice’in orijinal arbitraj işlemini "kopyalayabilir" - MEV kazancını kendine alabilir. Bu tür "blok başı yeniden sıralama + iş birliği ile el koyma" yaklaşımı, yüzeyde blok üretme kurallarına uymak gibi görünse de, aslında özenle tasarlanmış bir yağmadır. Daha kötüsü, bu durum liderler arasında "konsensüs ilişkileri" kurmaya teşvik eder ve blok onayını bir çıkar dağıtım oyununa dönüştürür, kamu hizmeti olmaktan çıkarır.
Üçüncüsü, kesinlik garantisini bozar ve kullanıcı deneyimini etkiler: BFT'nin Nakamoto benzeri protokollere göre en büyük avantajlarından biri deterministik kesinliktir: bir blok işlendikten sonra geri alınamaz. Ancak kuyruk çatalları, özellikle "oylanmış ancak resmi olarak onaylanmamış" bloklarda bu garantiyi baltalıyor. Bazı yüksek verimli dapp'ler genellikle gecikmeyi azaltmak için bir blok oylandıktan hemen sonra verileri okuyabilmek ister ve blok aniden atılırsa, anormal bir hesap bakiyesi, yeni tamamlanan yüksek kaldıraçlı bir işlemin sebepsiz yere kaybolması, oyun durumunun aniden sıfırlanması vb. gibi kullanıcının durumunun geri alınmasına yol açabilir.
Dördüncü, zincirleme arızalara yol açabilir: Genel olarak, kuyruk bölgesindeki çatallanma sadece bir bloğun bir tur geç onaylanmasına neden olabilir, bu da büyük bir etki yaratmaz. Ancak bazı kenar senaryolarında, ardışık birkaç lider önceki bloğu atlamayı seçerse, sistem duraklama durumuna girebilir ve kimse "önceki bloğu almayı" istemez. Tüm zincirin ilerleyişi böylece sıkışır, ta ki sonunda "sorumluluğu üstlenmek isteyen" bir lider ortaya çıkana kadar, ağ devam edemez.
Önceki bazı çözümler olsa da, örneğin BeeGees protokolünün önerdiği son bölünme kaçınma mekanizması, genellikle performanstan ödün vermeyi gerektirir; örneğin, yeniden ikincil iletişim karmaşıklığını geri getirmek gibi, bu da elde edilen sonuçların kaybedilmesine yol açar.
MonadBFT nedir?
MonadBFT, uç birim ayrışma sorununu çözmek için tasarlanmış yeni nesil bir konsensüs protokolüdür. Onun etkileyici yanı, yapısal tehlikeleri çözerken HotStuff'un sağladığı performans avantajını feda etmemesidir. Diğer bir deyişle, MonadBFT sıfırdan başlamaz, HotStuff'un temel çerçevesi üzerine inşa edilerek optimizasyon yapmaya devam eder. Üç ana özelliği korur:
Lider Değişimi (rotating leader): Her turda zinciri ilerletmek için yeni bir lider seçilir;
Pipelined commits: Birden fazla blok onay süreci üst üste yapılabilir;
Doğrulayıcıların yalnızca liderle iletişim kurması gerektiği için büyük miktarda ağ gideri tasarrufu sağlar.
Ama sadece bu üç nokta, güvenlik için yeterli değil. MonadBFT, bu yapısal açığı kapatmak için iki kritik mekanizma ekledi:
Zorunlu Yeniden Öneri Mekanizması (Re-Proposal)
Tasdik Belgesi Olmadan (NEC, Onay Belgesi Yok)
Yeniden Öneri Mekanı (Re-Proposal)
BFT protokolünde, zaman bir dizi tura (view olarak adlandırılır) bölünmüştür ve her turda yeni bloklar önermekle sorumlu bir lider vardır. Eğer lider başarısız olursa (örneğin, blokları zamanında önermiyor 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 sunulan herhangi bir bloğun lider değişimi nedeniyle "kopmaması" için bir mekanizma ekledi.
Geçerli turdaki lider başarısız olduğunda, doğrulayıcılar geçerli turun süresinin dolduğunu belirtmek için imzalı bir tur geçiş mesajı (view change) gönderir.
Özellikle, bu mesaj sadece "zaman aşımına uğradı" demekle kalmıyor, aynı zamanda bu doğrulayıcının en son oy kullandığı blok bilgilerini de içermelidir, bu da "Geçerli bir öneri almadım, bu benim şu anda gördüğüm en son blok." demektir.
Yeni bir lider, bu zaman aşımı mesajlarını süper çoğunluk (2f+1) doğrulayıcısından toplayacak ve bunları bir zaman aşımı sertifikası (Timeout Certificate, TC) haline getirecektir. Bu TC, önceki tur başarısız olduğunda, tüm ağın "zincir başı blok" üzerindeki ortak anlayış anlık görüntüsünü temsil eder. Yeni lider, buradan en yüksek yükseklik (veya en son görünüm numarası) olan bloğu, yani sözde high_tip'i seçecektir.
MonadBFT gereksinimleri: Yeni liderin önerisi, geçerli bir TC içermeli ve en yüksek bekleyen blok olan TC'yi yeniden önermelidir, böylece bu blok yeniden onaylanma fırsatı bulabilir.
Neden? Önceden bahsettiğ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 önermiş ve çoğunluk oyunu almıştır. Sonrasında, view 6'nın lideri Bob çevrimdışı kalır ve zincir sürecini ilerletemez. Carol, view 7'nin lideri olduğunda MonadBFT kurallarına göre, TC'yi dahil etmeli ve Alice'in bloğunu yeniden önermelidir. Böylece, Alice'in dürüst çabası boşa gitmeyecektir.
Eğer Carol'un Alice'in Bloku yoksa, diğer Düğümlerden talep edebilir. Düğümler şunları yapabilir:
Bu bloğu sağlayın, ya da
İmzalı bir "arka plan belgesi olmayan mesaj" (No-Endorsement, NE) geri döndürün, bu da bu bloğa sahip olmadığınızı belirtir (mekanizması daha sonra tanıtılacaktır). (En fazla f adet Bizans düğümü, isteği göz ardı etmeyi ve yanıt vermemeyi seçebilir.)
Carol, Alice'in blokunu yeniden önerdiğinde, önceki tur liderinin başarısızlığından dolayı "birlikte cezalandırma" riski olmadan ek bir öneri fırsatı elde edecektir.
Bu yeniden öneri mekanizmasının rolü nettir: Zincirin ilerlemesini adil bir şekilde sağlamak ve herhangi bir geçerli çalışmanın şanssızlık veya birinin karışması nedeniyle gizlice terk edilmemesini güvence altına almak.
Arka Belge Sertifikası (NEC)
Devam eden örneğe göre: Bob'un tur süresi dolduktan sonra, Carol diğer doğrulayıcılardan high_tip blokunu (yani Alice'in bloğunu) talep eder. Bu aşamada, en az 2f+1 doğrulayıcı yanıt verecektir:
Ya da Alice'in blokunu sağla
Ya da Alice'in blokunu almadığını belirtmek için imzalı NE mesajı gönderin.
Carol, Alice'in Blok'unu aldığında, bunu kurallara göre yeniden önermelidir. Sadece en az f+1 doğrulayıcının NE mesajını imzaladığı durumlarda, Carol bu Blok'u atlayabilir ve yeni bir öneride bulunabilir.
Neden f+1? 3f+1 doğrulayıcıdan oluşan bir BFT sisteminde, en fazla f kötüye gidebilir. Eğer Alice'in bloku gerçekten 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 blokunu alamıyorum" iddiasında bulunuyorsa, o zaman bu kişilerin hiçbiri tarafından alınmadığını kanıtlamak için f+1 tane doğrulayıcı imzası sunmak zorundadır. Bu, bir No-Endorsement Certificate (NEC) oluşturur.
NEC, lider "sorumluluktan muafiyet" belgesidir: Bu, önceki blokun onaylanmaya henüz hazır olmadığını gösteren doğrulanabilir bir kanıttır; kötü niyetli bir şekilde atlanmadığını, aksine mantıklı ve makul bir şekilde "vazgeçildiğini" ifade eder.
Yeniden öneri + Desteksiz sertifika = Son çatallanmaların çözümü
MonadBFT, yeniden öneri mekanizmasını (Re-Proposal) ve arka planda onay sertifikası bulunmayan (NEC, No-Endorsement Certificate) işleyerek, sağlam ve net bir zincir başı işleme kuralı oluşturmuştur:
Ya "onaylanmaya yakın" bir blok için nihai teslimat tamamlanmalı; ya da bu blok için onaylanma koşullarını sağlamadığını kanıtlamak için yeterli kanıt sunulmalı, aksi takdirde önceki bloğu atlamak veya değiştirmek yasaktır.
Bu mekanizma, yasal çoğunluk oyu almış herhangi bir blokun, liderin hata yapması veya kasıtlı olarak atlanması nedeniyle terk edilmeyeceğini sağlar. Kuyruk kısmındaki çatalın yapısal riski sistematik olarak ortadan kaldırılır, protokol, uygunsuz atlama davranışlarına karşı açık bir kısıtlama oluşturabilir.
Eğer bir lider, üstteki bloku sebepsiz yere atlamaya çalışırsa ancak NEC kanıtı sunamazsa, protokol bu durumu hemen tanıyacak ve bu eylemi reddedecektir. Kripto kanıtı olmayan atlama eylemleri yasa dışı olarak kabul edilecek ve ağ konsensüs desteği almayacaktır.
Ekonomik teşvikler açısından, bu tasarım doğrulayıcılara açık bir koruma sağlamaktadır:
Sadece dürüst bir şekilde önerilen ve oy desteği alan blokların ödülleri, sonraki aşamalardaki arızalardan dolayı geri alınamaz;
Aşırı durumlarda bile, örneğin bir düğüm kasıtlı olarak kendi öneri sırasını atlayıp başkalarının önceki bloktaki MEV'yi kapmasına yardımcı olmaya çalıştığında, protokol ardışık liderlerin orijinal bloğu yeniden önermesini zorunlu kılar, böylece saldırganların süreci atlayarak ekonomik kazanç elde etmesine izin verilmez.
Daha önemlisi, MonadBFT protokolün performansını feda etmeden güvenliği artırmayı amaçlamaktadı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üreçlerini başlatmaya bağımlıdır ki bu da pratikte sistem yükünü önemli ölçüde artırır.
MonadBFT'nin tasarım stratejisi daha da ince.
Sadece görünüm başarısız olduğunda veya bir istisna olduğunda ek iletişim başlatılır (örneğin, zaman aşımı mesajları, blok yeniden önerimi). Çoğu dürüst liderin sürekli blok çıkardığı normal yolda, protokol hala hafif ve verimli bir çalışma durumunu sürdürmektedir.
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 mekanizmasını gözden geçiriyor, HotStuff protokolünün gelişim yolunu inceliyor ve MonadBFT'nin, protokol katmanı yapısı açısından, sıralı HotStuff'un doğasında bulunan son bölünme sorununu nasıl çözdüğünü vurguluyor.
Kuyruk bölünmesi, blok önericilerinin ekonomik teşviklerini çarpıtabilir ve ağa karşı potansiyel bir tehdit oluşturur. MonadBFT, yeniden öneri mekanizması ve arka planda onay belgesi (NEC) tanıtarak, dürüst liderler tarafından önerilen ve yasal çoğunluk oyu alan blokların terk edilmeyeceğini veya atlanmayacağını garanti eder.
Bir sonraki yazıda, MonadBFT'nin iki temel özelliğini daha incelemeye devam edeceğiz:
Spekülatif Nihayetçilik
İyimser Tepkiselik
Ve bu mekanizmaların doğrulayıcılar ve geliştiriciler için pratik anlamını daha da analiz etmek.
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 Analizi (1): Kuyruk Çatal Sorununu Nasıl Çözebiliriz
Blok zincirinin özü, katı bir küresel konsensüs sağlamaktır: yani, ağ düğümleri hangi ülkede veya hangi zaman diliminde bulunursa bulunsun, tüm katılımcıların sonunda bir grup nesnel sonuç üzerinde uzlaşmaları gerekmektedir.
Ama gerçek hayattaki dağıtık ağlar ideal değil: Düğümler kopuyor, Düğümler yalan söylüyor, hatta bazıları kasıtlı olarak zarar veriyor. Bu durumda, sistem nasıl "ortak bir görüşte" kalıyor ve tutarlılığı sağlıyor?
Bu, konsensüs protokolünün çözmesi gereken bir sorundur. Temelde, birbirinden bağımsız ve hatta tamamen güvenilir olmayan bir grup düğümün, her işlem için sıralama ve içerik konusunda nasıl ortak bir karar alacaklarını belirten bir dizi kuraldır.
Ve bu tür "katı konsensüs" kurulduğunda, blok zinciri birçok kritik özelliği açığa çıkarabilir, örneğin dijital mülkiyet güvencesi, enflasyona karşı para modeli ve ölçeklenebilir sosyal işbirliği yapısı. Ancak öncelikle, konsensüs protokolü kendisi iki temel unsuru aynı anda garanti etmelidir:
İki çelişen blokların aynı anda onaylanması mümkün değildir;
Ağ sürekli ilerlemeli, durmamalı veya takılmamalı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ı bu alanda aslında on yıllardır araştırılıyor. En erken protokollerden biri olan PBFT (Pratik Bizans Hatası Toleransı) bile oldukça gerçekçi bir durumu işleyebiliyor: Ağı içindeki bazı Düğümler arızalanır, kötü niyetli davranır veya saçmalarsa, eğer bunlar toplam sayının 1/3'ünden fazlasını geçmiyorsa, sistem yine de uzlaşabilir.
Bu erken protokollerin tasarım şekli oldukça "geleneksel": Her turda bir lider seçilir, o öneri başlatır, diğer doğrulayıcılar bu öneriye birçok turda oy verir ve işlem sırasını adım adım doğrular.
Tüm oylama süreci genellikle birkaç aşamadan geçer, örneğin pre-prepare, prepare, commit, reply. Her aşamada, tüm doğrulayıcılar birbirleriyle iletişim kurmalıdır. Diğer bir deyişle, herkesin herkesle bir kez konuşması gerekir, mesaj miktarı "ağ" şeklinde patlayıcı bir şekilde artar.
Bu iletişim yapısının karmaşıklığı n²'dir—yani, eğer ağda 100 doğrulayıcı varsa, her bir konsensüs turunda neredeyse 10.000 mesaj iletilmesi gerekebilir.
Bu, küçük ağlarda büyük bir sorun değildir, ancak doğrulayıcı sayısı arttığında, sistemin iletişim yükü hızla dayanılmaz hale gelecek ve verimlilik doğrudan düşecektir.
Bu tür "herkesin herkesle iletişim kurması gereken" ikincil iletişim yapısı aslında çok 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 idare edilebilir, ancak küresel ölçekte, açık bir zincir ağına yerleştirildiğinde, iletişim yükü hemen kabul edilemez hale geliyor. Bu nedenle, PBFT, Tendermint gibi erken BFT protokolleri genellikle izinli senaryolar (permissioned network) veya çok az sayıda doğrulayıcı bulunan sistemlerde kullanılmakta, ancak zorla çalıştırılabilmektedir.
BFT protokolünün izin gerektirmeyen, kamu blok zinciri ortamına da uyum sağlaması için, yeni nesil bazı tasarımlar daha hafif bir iletişim yoluna yönelmeye başladı: Her doğrulayıcının yalnızca liderle iletişim kurması, tüm katılımcılar arasında iletişim kurmak yerine.
Bu, mesaj karmaşıklığını başlangıçtaki n²'den n'ye optimize etti - sistemi büyük ölçüde hafifletti.
HotStuff protokolü, 2018 yılında önerilmiştir ve bu ölçeklenebilirlik sorununu çözmek amacıyla geliştirilmiştir. Tasarım felsefesi oldukça net: PBFT'nin karmaşık oylama sürecinin yerini daha basit, lider odaklı bir iletişim yapısı almalıdır.
HotStuff'un ana özelliği, sözde lineer iletişimdir. Mekanizmasında, her bir doğrulayıcı yalnızca kendi oyunu mevcut liderine göndermelidir, lider daha sonra bu oyları paketleyerek bir Quorum Sertifikası (QC, yasal çoğunluk kanıtı) oluşturur.
Bu QC, esasen bir toplu imza olup tüm ağa "Çoğu Düğüm bu öneriyi kabul etti." şeklinde kanıtlar.
Buna karşılık, PBFT'nin iletişim modeli "tam bir yayılma"dır, herkes grupta konuşur ve ortam bir ara oldukça karmaşık hale gelir. HotStuff'un modeli ise "bir kişi toplar, bir paket yapar" gibidir, ağda kaç kişi olursa olsun yine de yüksek verimlilikle çalışmaya devam edebilir.
Lineer iletişimin yanı sıra, HotStuff ayrıca verimliliği artırmak için bir boru hattı versiyonuna (pipelined HotStuff) yükseltilebilir.
Orijinal HotStuff'ta, aynı doğrulayıcı birden fazla tur lider olarak görev yapar, ta ki bir blok tamamen onaylanana kadar. Bu süreç "her turda bir blok işlemek" şeklindedir ve tüm enerji mevcut olanda ilerlemeye odaklanır.
Ve HotStuff akışında, mekanizma daha esnek hale geldi: her turda yeni bir lider seçilir ve her liderin iki görevi vardır:
Bir yandan bir önceki tur oylamasını Quorum Sertifikası (QC) haline getirip tüm ağa yayınlamak;
Yeni bir blok önerirken, bir sonraki tura hazırlık yapılıyor.
Yani, artık "birini onayladıktan sonra bir sonraki ile ilgilenmek" yok, bunun yerine bir üretim hattı gibi, farklı liderler her aşamada sırayla sorumluluk alıyor. Önceki kişi bir blok öneriyor, sonraki kişi onu onaylıyor ve yeni bloklar önermeye devam ediyor, zincir üzerindeki konsensüs bir bayrak yarışı gibi devam ediyor.
İşte "işlem hattı" benzetmesinin kökeni: Mevcut blok henüz onay sürecinde, bir sonraki blok ise hazırlanıyor, çoklu adımlar paralel olarak ilerliyor, işlem verimliliğini artırıyor.
Özetle, HotStuff gibi protokoller, geleneksel BFT'ye göre iki boyutta önemli iyileştirmeler sağlıyor:
Birincisi, iletişim daha hafif, her doğrulayıcı yalnızca liderle iletişim kurar;
İkincisi, işleme verimliliği daha yüksektir, birden fazla blok onay süreci paralel olarak gerçekleştirilebilir.
Bu, HotStuff'un birçok modern PoS Blok Zinciri konsensüs mekanizmasının tasarım şablonu olmasını sağladı. Ancak her şeyin avantajları ve dezavantajları vardır - hat yapısı güçlü bir performansa sahip olsa da, aynı zamanda kolayca fark edilmeyen bir yapısal riski de gizlice ortaya çıkarıyor.
Şimdi bu temel konuyu derinlemesine ele alacağız: Kuyruk Çatallanması (Tail Forking).
Kuyruk Çatal Sorunu (Tail-Forking)
HotStuff'un, özellikle de onun boru hattı versiyonunun, konsensüs protokolünün ölçeklenebilirlik sorununu çözmesine rağmen, bazı yeni zorluklar da getirdi. Bunların en kritik ve en kolay gözden kaçırılanı, sözde "Kuyruk Dallanması" (Tail Forking) sorunudur.
Son çatallanma nedir? Basitçe şu şekilde anlaşılabilir: Blok zincirinde "zincirin ucu"nda beklenmedik bir blok yeniden yapılandırması gerçekleşti (reorg).
Spesifik olarak, geçerli bir blok var, bu blok çoğu doğrulayıcıya başarıyla yayıldı ve yeterli oy desteği aldı, bu nedenle hemen onaylanması ve ana zincire yazılması gerekiyordu. Ancak sonunda, "atlandı" ve terkedildi (orphaned), yerine aynı yükseklikte başka bir yeni blok geçti.
Bu bir hata değil, saldırı da değil, aksine protokolün tasarım yapısında "zincir uçma" olasılığının bulunmasından kaynaklanıyor. Bu biraz adaletsiz gibi mi geliyor? Peki, bu nasıl oluyor?
Daha önce söylediğimiz gibi, HotStuff akış hattındaki her liderin iki görevi vardır:
A. Yeni bir blok önerin (örneğin Bₙ₊₁)
B. Önceki liderin blokuna oy toplamak, QC oluşturmak (örneğin Bₙ'nin nihai onayını tamamlamak)
Bu iki görev paraleldir, dönüşümlü olarak devralınır. Ama sorun burada ortaya çıkıyor.
Bir örnek vermek gerekirse: Alice lider olsun, o n. yükseklikte Bₙ blokunu önerdi, bu blok süper çoğunluğun oyunu aldı ve "neredeyse onaylandı". Sonrasında Bob lider olarak Bₙ₊₁ blokunu ilerletmeye devam etmelidir, aynı zamanda Bₙ'nin QC'sini (yasal çoğunluk kanıtı) teklifine dahil etmeli, böylece Bₙ'nin nihai onayını tamamlamalıdır.
Ama eğer Bob bu sırada çevrimdışıysa veya kasıtlı olarak Bₙ'in QC'sini sunmazsa, o zaman sorun çıkar.
Çünkü Alice'in blokunu QC paketlemek için kimse yoktu, Bₙ'nin oy kaydı yayılamadı, bu doğrulanması gereken blok böylece "soğuk işlem" olarak kaldı ve nihayetinde tüm ağ tarafından görmezden gelindi.
Bu, son kısmın ayrılmasının özüdür: Önceki liderin bloğu, bir sonraki liderin ihmal veya kötü niyeti nedeniyle atlanmıştır.
Neden uç bölümü ciddi şekilde ayrılıyor?
Son bölünme sorunları iki ana noktada yoğunlaşmaktadır: 1) Teşvik mekanizması bozuldu, 2) Sistemin etkinliği tehdit altında.
İlk olarak, ödüller yutuldu: Bir blok eğer atılırsa, onu öneren lider hiçbir ödül alamaz. Ne blok ödülü ne de işlem ücreti. Örneğin, Alice geçerli bir blok önerdi ve süper çoğunluk oyu aldı, ancak Bob'un hatası veya kötü niyetli eylemi nedeniyle bu blok onaylanmadı, Alice sonunda hiçbir şey kazanamaz. Bu, yanlış bir teşvik yapısına yol açar: Bob gibi kötü niyetli düğümler, rakiplerinin bloklarını atlayarak, onların ödül kaynaklarını "kesebilirler". Bu tür bir davranış teknik bir saldırı gerektirmez, sadece kasıtlı olarak "işbirliği yapmamak" yeterlidir, bu da rakiplerin kazançlarını azaltır. Bu tür durumlar tekrar tekrar meydana gelirse, zamanla tüm sistemin katılımı ve adaleti azalır ve hatta düğümler arasında bir komplo oluşmasına neden olabilir.
İkincisi, MEV saldırı alanı genişliyor: Son kısım dallanması daha gizli ama ciddi bir sorunu da beraberinde getiriyor: MEV (maksimum çıkarılabilir değer) kötü niyetle manipüle edilme alanı büyüdü. Bir örnek vermek gerekirse: Alice'in bloğunda son derece değerli bir arbitraj işlemi var. Bob, eğer bir sorun çıkarmak isterse, bir sonraki lider Carol ile iş birliği yapabilir ve Alice'in bloğunu kasıtlı olarak yaymamayı seçebilir. Ardından Carol, aynı yükseklikte yeni bir blok oluşturarak Alice’in orijinal arbitraj işlemini "kopyalayabilir" - MEV kazancını kendine alabilir. Bu tür "blok başı yeniden sıralama + iş birliği ile el koyma" yaklaşımı, yüzeyde blok üretme kurallarına uymak gibi görünse de, aslında özenle tasarlanmış bir yağmadır. Daha kötüsü, bu durum liderler arasında "konsensüs ilişkileri" kurmaya teşvik eder ve blok onayını bir çıkar dağıtım oyununa dönüştürür, kamu hizmeti olmaktan çıkarır.
Üçüncüsü, kesinlik garantisini bozar ve kullanıcı deneyimini etkiler: BFT'nin Nakamoto benzeri protokollere göre en büyük avantajlarından biri deterministik kesinliktir: bir blok işlendikten sonra geri alınamaz. Ancak kuyruk çatalları, özellikle "oylanmış ancak resmi olarak onaylanmamış" bloklarda bu garantiyi baltalıyor. Bazı yüksek verimli dapp'ler genellikle gecikmeyi azaltmak için bir blok oylandıktan hemen sonra verileri okuyabilmek ister ve blok aniden atılırsa, anormal bir hesap bakiyesi, yeni tamamlanan yüksek kaldıraçlı bir işlemin sebepsiz yere kaybolması, oyun durumunun aniden sıfırlanması vb. gibi kullanıcının durumunun geri alınmasına yol açabilir.
Dördüncü, zincirleme arızalara yol açabilir: Genel olarak, kuyruk bölgesindeki çatallanma sadece bir bloğun bir tur geç onaylanmasına neden olabilir, bu da büyük bir etki yaratmaz. Ancak bazı kenar senaryolarında, ardışık birkaç lider önceki bloğu atlamayı seçerse, sistem duraklama durumuna girebilir ve kimse "önceki bloğu almayı" istemez. Tüm zincirin ilerleyişi böylece sıkışır, ta ki sonunda "sorumluluğu üstlenmek isteyen" bir lider ortaya çıkana kadar, ağ devam edemez.
Önceki bazı çözümler olsa da, örneğin BeeGees protokolünün önerdiği son bölünme kaçınma mekanizması, genellikle performanstan ödün vermeyi gerektirir; örneğin, yeniden ikincil iletişim karmaşıklığını geri getirmek gibi, bu da elde edilen sonuçların kaybedilmesine yol açar.
MonadBFT nedir?
MonadBFT, uç birim ayrışma sorununu çözmek için tasarlanmış yeni nesil bir konsensüs protokolüdür. Onun etkileyici yanı, yapısal tehlikeleri çözerken HotStuff'un sağladığı performans avantajını feda etmemesidir. Diğer bir deyişle, MonadBFT sıfırdan başlamaz, HotStuff'un temel çerçevesi üzerine inşa edilerek optimizasyon yapmaya devam eder. Üç ana özelliği korur:
Lider Değişimi (rotating leader): Her turda zinciri ilerletmek için yeni bir lider seçilir;
Pipelined commits: Birden fazla blok onay süreci üst üste yapılabilir;
Doğrulayıcıların yalnızca liderle iletişim kurması gerektiği için büyük miktarda ağ gideri tasarrufu sağlar.
Ama sadece bu üç nokta, güvenlik için yeterli değil. MonadBFT, bu yapısal açığı kapatmak için iki kritik mekanizma ekledi:
Zorunlu Yeniden Öneri Mekanizması (Re-Proposal)
Tasdik Belgesi Olmadan (NEC, Onay Belgesi Yok)
Yeniden Öneri Mekanı (Re-Proposal)
BFT protokolünde, zaman bir dizi tura (view olarak adlandırılır) bölünmüştür ve her turda yeni bloklar önermekle sorumlu bir lider vardır. Eğer lider başarısız olursa (örneğin, blokları zamanında önermiyor 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 sunulan herhangi bir bloğun lider değişimi nedeniyle "kopmaması" için bir mekanizma ekledi.
Geçerli turdaki lider başarısız olduğunda, doğrulayıcılar geçerli turun süresinin dolduğunu belirtmek için imzalı bir tur geçiş mesajı (view change) gönderir.
Özellikle, bu mesaj sadece "zaman aşımına uğradı" demekle kalmıyor, aynı zamanda bu doğrulayıcının en son oy kullandığı blok bilgilerini de içermelidir, bu da "Geçerli bir öneri almadım, bu benim şu anda gördüğüm en son blok." demektir.
Yeni bir lider, bu zaman aşımı mesajlarını süper çoğunluk (2f+1) doğrulayıcısından toplayacak ve bunları bir zaman aşımı sertifikası (Timeout Certificate, TC) haline getirecektir. Bu TC, önceki tur başarısız olduğunda, tüm ağın "zincir başı blok" üzerindeki ortak anlayış anlık görüntüsünü temsil eder. Yeni lider, buradan en yüksek yükseklik (veya en son görünüm numarası) olan bloğu, yani sözde high_tip'i seçecektir.
MonadBFT gereksinimleri: Yeni liderin önerisi, geçerli bir TC içermeli ve en yüksek bekleyen blok olan TC'yi yeniden önermelidir, böylece bu blok yeniden onaylanma fırsatı bulabilir.
Neden? Önceden bahsettiğ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 önermiş ve çoğunluk oyunu almıştır. Sonrasında, view 6'nın lideri Bob çevrimdışı kalır ve zincir sürecini ilerletemez. Carol, view 7'nin lideri olduğunda MonadBFT kurallarına göre, TC'yi dahil etmeli ve Alice'in bloğunu yeniden önermelidir. Böylece, Alice'in dürüst çabası boşa gitmeyecektir.
Eğer Carol'un Alice'in Bloku yoksa, diğer Düğümlerden talep edebilir. Düğümler şunları yapabilir:
Bu bloğu sağlayın, ya da
İmzalı bir "arka plan belgesi olmayan mesaj" (No-Endorsement, NE) geri döndürün, bu da bu bloğa sahip olmadığınızı belirtir (mekanizması daha sonra tanıtılacaktır). (En fazla f adet Bizans düğümü, isteği göz ardı etmeyi ve yanıt vermemeyi seçebilir.)
Carol, Alice'in blokunu yeniden önerdiğinde, önceki tur liderinin başarısızlığından dolayı "birlikte cezalandırma" riski olmadan ek bir öneri fırsatı elde edecektir.
Bu yeniden öneri mekanizmasının rolü nettir: Zincirin ilerlemesini adil bir şekilde sağlamak ve herhangi bir geçerli çalışmanın şanssızlık veya birinin karışması nedeniyle gizlice terk edilmemesini güvence altına almak.
Arka Belge Sertifikası (NEC)
Devam eden örneğe göre: Bob'un tur süresi dolduktan sonra, Carol diğer doğrulayıcılardan high_tip blokunu (yani Alice'in bloğunu) talep eder. Bu aşamada, en az 2f+1 doğrulayıcı yanıt verecektir:
Ya da Alice'in blokunu sağla
Ya da Alice'in blokunu almadığını belirtmek için imzalı NE mesajı gönderin.
Carol, Alice'in Blok'unu aldığında, bunu kurallara göre yeniden önermelidir. Sadece en az f+1 doğrulayıcının NE mesajını imzaladığı durumlarda, Carol bu Blok'u atlayabilir ve yeni bir öneride bulunabilir.
Neden f+1? 3f+1 doğrulayıcıdan oluşan bir BFT sisteminde, en fazla f kötüye gidebilir. Eğer Alice'in bloku gerçekten 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 blokunu alamıyorum" iddiasında bulunuyorsa, o zaman bu kişilerin hiçbiri tarafından alınmadığını kanıtlamak için f+1 tane doğrulayıcı imzası sunmak zorundadır. Bu, bir No-Endorsement Certificate (NEC) oluşturur.
NEC, lider "sorumluluktan muafiyet" belgesidir: Bu, önceki blokun onaylanmaya henüz hazır olmadığını gösteren doğrulanabilir bir kanıttır; kötü niyetli bir şekilde atlanmadığını, aksine mantıklı ve makul bir şekilde "vazgeçildiğini" ifade eder.
Yeniden öneri + Desteksiz sertifika = Son çatallanmaların çözümü
MonadBFT, yeniden öneri mekanizmasını (Re-Proposal) ve arka planda onay sertifikası bulunmayan (NEC, No-Endorsement Certificate) işleyerek, sağlam ve net bir zincir başı işleme kuralı oluşturmuştur:
Ya "onaylanmaya yakın" bir blok için nihai teslimat tamamlanmalı; ya da bu blok için onaylanma koşullarını sağlamadığını kanıtlamak için yeterli kanıt sunulmalı, aksi takdirde önceki bloğu atlamak veya değiştirmek yasaktır.
Bu mekanizma, yasal çoğunluk oyu almış herhangi bir blokun, liderin hata yapması veya kasıtlı olarak atlanması nedeniyle terk edilmeyeceğini sağlar. Kuyruk kısmındaki çatalın yapısal riski sistematik olarak ortadan kaldırılır, protokol, uygunsuz atlama davranışlarına karşı açık bir kısıtlama oluşturabilir.
Eğer bir lider, üstteki bloku sebepsiz yere atlamaya çalışırsa ancak NEC kanıtı sunamazsa, protokol bu durumu hemen tanıyacak ve bu eylemi reddedecektir. Kripto kanıtı olmayan atlama eylemleri yasa dışı olarak kabul edilecek ve ağ konsensüs desteği almayacaktır.
Ekonomik teşvikler açısından, bu tasarım doğrulayıcılara açık bir koruma sağlamaktadır:
Sadece dürüst bir şekilde önerilen ve oy desteği alan blokların ödülleri, sonraki aşamalardaki arızalardan dolayı geri alınamaz;
Aşırı durumlarda bile, örneğin bir düğüm kasıtlı olarak kendi öneri sırasını atlayıp başkalarının önceki bloktaki MEV'yi kapmasına yardımcı olmaya çalıştığında, protokol ardışık liderlerin orijinal bloğu yeniden önermesini zorunlu kılar, böylece saldırganların süreci atlayarak ekonomik kazanç elde etmesine izin verilmez.
Daha önemlisi, MonadBFT protokolün performansını feda etmeden güvenliği artırmayı amaçlamaktadı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üreçlerini başlatmaya bağımlıdır ki bu da pratikte sistem yükünü önemli ölçüde artırır.
MonadBFT'nin tasarım stratejisi daha da ince.
Sadece görünüm başarısız olduğunda veya bir istisna olduğunda ek iletişim başlatılır (örneğin, zaman aşımı mesajları, blok yeniden önerimi). Çoğu dürüst liderin sürekli blok çıkardığı normal yolda, protokol hala hafif ve verimli bir çalışma durumunu sürdürmektedir.
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 mekanizmasını gözden geçiriyor, HotStuff protokolünün gelişim yolunu inceliyor ve MonadBFT'nin, protokol katmanı yapısı açısından, sıralı HotStuff'un doğasında bulunan son bölünme sorununu nasıl çözdüğünü vurguluyor.
Kuyruk bölünmesi, blok önericilerinin ekonomik teşviklerini çarpıtabilir ve ağa karşı potansiyel bir tehdit oluşturur. MonadBFT, yeniden öneri mekanizması ve arka planda onay belgesi (NEC) tanıtarak, dürüst liderler tarafından önerilen ve yasal çoğunluk oyu alan blokların terk edilmeyeceğini veya atlanmayacağını garanti eder.
Bir sonraki yazıda, MonadBFT'nin iki temel özelliğini daha incelemeye devam edeceğiz:
Spekülatif Nihayetçilik
İyimser Tepkiselik
Ve bu mekanizmaların doğrulayıcılar ve geliştiriciler için pratik anlamını daha da analiz etmek.
Devam edecek.