Ethereum’un Sansür Direncine Giden Yolu: BRAID vs. FOCIL
Ethereum’un gelişen ortamında, sansüre karşı direnç için verilen savaş birçok yenilikçi mekanizma getirmiştir. Bunlar arasında BRAID ve FOCIL, işlem sansürü riskini en aza indirerek ağın bütünlüğünü korumak için tasarlanmış iki umut verici yaklaşım olarak öne çıkmaktadır.
Bu çözümlerin her ikisi de blok teklif sürecindeki kritik sorunları ele almakta ancak hedeflerine ulaşmak için temelde farklı yaklaşımlar benimsemektedir. Bu makale, bu iki mekanizmanın nüanslarını incelemekte ve sonuçta hangisinin daha etkili olabileceğini araştırmaktadır.
Ethereum’da Sansür Tehdidini Anlamak
Ethereum’un blok oluşturma ve doğrulama sürecinin merkezinde iki temel aktör yer alır: oluşturucular ve teklifçiler. Oluşturucular, işlemleri sıralamaktan ve bir bloğu teklif edenlere göndermekten sorumludur; bunlar daha sonra imzalamak ve blockchain.
Ancak bu süreç potansiyel bir güvenlik açığı yaratmaktadır. Teklif sahipleri hangi bloğun teklif edileceği konusunda son söze sahip olduğundan, teklif sahipleri ve kurucular arasında belirli işlemleri sansürlemek için gizli anlaşma riski vardır ve bu da Ethereum’un sansüre direnç ilkesini tehdit eder.
Sansüre direnç, blok zincirinin adilliğini ve şeffaflığını korumak için çok önemlidir. Eğer teklif sahipleri işlemleri seçerek dahil edebilir ya da hariç tutabilirse, bu durum ağın merkezi olmayan yapısını zayıflatır ve işlem sıralamasının istismar edilmesine yol açarak Miner Extractable Value (MEV) gibi sorunlara neden olabilir.
Mevcut Çözümler: MCP ve FOCIL
Bu zorluğun üstesinden gelmek için sansüre dirençli çeşitli çözümler önerilmiştir; bunlardan en çok tartışılan iki tanesi Force Inclusion List (FOCIL) ve Multi-Concurrent Proposer (MCP) mekanizmalarıdır.
Kuvvet Dahil Etme Listesi (FOCIL)
FOCIL, her zaman diliminde rastgele seçilen bir doğrulayıcılar komitesini dahil ederek adaleti sağlamak üzere tasarlanmıştır.
Bu doğrulayıcılar, mempool hakkındaki görüşlerine dayanarak yerel dahil etme listeleri oluşturur ve bu listeleri yayınlar.
Teklif sahibi daha sonra bu yerel listeleri bloğa eklenen nihai bir dahil edilme listesinde toplar.
Bu mekanizma, tek bir teklif sahibinin bir blokta yer alan işlemler üzerinde tam kontrole sahip olmamasını sağlar ve böylece sansür riskini azaltır.
Doğrulayıcılar, bloğu blok zincirine kabul etmeden önce mutabakat kurallarına uyduğunu doğrular.
Çok Eşzamanlı Teklif Sahibi (MCP)
MCP, ilk olarak Max Resnick tarafından Multiplicity mekanizmasında önerilen çoklu eşzamanlı teklif sahipleri kavramını ortaya koymaktadır.
Bu sistemde, her biri mempool’dan işlemlerin bir kısmını seçen birkaç teklif sahibi paralel olarak çalışır.
Bu işlemler “özel işlem demetleri” halinde paketlenir ve teklif sahipleri tarafından imzalanır. Teklifin geçerli sayılabilmesi için baş teklif sahibinin bu paketlerin en az üçte ikisini teklif bloğuna dahil etmesi gerekir.
Bu yöntem, tek bir teklif sahibinin gücünü merkezsizleştirir ve işlem sansürü olasılığını önemli ölçüde azaltır.
BRAID: Geliştirilmiş Bir MCP Uygulaması
MCP konseptini temel alan Max Resnick, daha sofistike ve eksiksiz bir MCP uygulaması olan BRAID’i geliştirdi.
Paradigm tarafından düzenlenen “MEV Çağında DeFi” seminerinde tanıtılan BRAID, birden fazla teklif sahibinin aynı anda farklı paralel zincirlerde bloklar önermesine olanak tanıyor.
Bu bloklar daha sonra zincirler arasında tutarlılığı sağlamak için bir mutabakat mekanizması aracılığıyla senkronize edilir.
Ethereum’un yürütme katmanı, slot içinde oluşturulan tüm blokları, işlemlerin tekilleştirildiği, sıralandığı ve önceden tanımlanmış kurallara göre yürütüldüğü tek bir yürütme bloğunda birleştirir.
Bu yaklaşım, tek bir kuruluşun işlem kayıtlarını manipüle etme gücünü önemli ölçüde azaltır.
BRAID’in önemli bir avantajı, karmaşıklığı artırabilecek ek rollerden veya karmaşık teşvik yapılarından kaçınmasıdır.
Bununla birlikte, birden fazla alt zincir arasında senkronizasyonu koordine etmek ve veri işlemeyi ele almak kendi zorluklarını ortaya koymaktadır.
BRAID’de Zorluklar ve Dikkat Edilmesi Gerekenler
Güçlü yönlerine rağmen BRAID’in sorunları da yok değil. Dikkate değer bir zorluk, kullanıcıların işlemlerinin sansüre dayanıklı olmasını sağlamak için likiditeye sahip olmalarını gerektiren “koşullu bahşiş” modelidir. Kullanıcılar işlem gönderirken iki bahşiş değeri belirlemelidir:
- Daha Yüksek Uç (T): Bir kullanıcının, sansür girişiminde bulunulsa bile işleminin dahil edilmesini sağlamak için ödemeye razı olduğu maksimum tutar. Yalnızca bir teklif sahibi işlemi dahil ederse, T miktarının tamamını alırlar.
- Alt Uç (t): Birden fazla teklif sahibinin işlemi dahil etmesi durumunda ödenen daha küçük bir bahşiş. Bu durumda, bahşiş işlemi dahil eden teklif sahipleri arasında dağıtılır.
Bu model, sansürü caydırmada etkili olmakla birlikte, kullanıcılar için ek karmaşıklık ve maliyetler getirmektedir. İşlem sırasında ekstra likidite ayırmaları gerekir ve bu likidite, ihtiyaç duyulup duyulmayacağı belirlenene kadar dondurulabilir.
Bu sorunları ele almak için Blockchain Capital’den Jonahb iki potansiyel çözüm öneriyor:
- Devlet Sonrası Likidite Kanıtı: Bu yaklaşım, kullanıcıların işlem gerçekleştirildikten sonra daha yüksek bahşişi ödemek için yeterli likiditeye sahip olacaklarını kanıtlamalarına olanak tanır. Ancak bu, teklif sahiplerinin işlem sonrası durumu anlamasını gerektirir ki bu da paylaşılan durum veya karmaşık finansal işlemleri içeren işlemlerde zordur.
- Sansür Sigortası: Bu konsept, bir ücret karşılığında kullanıcının bahşişini garanti eden üçüncü taraf Sansür Sigortası (CI) sağlayıcılarını tanıtmaktadır. Bu, kullanıcılar üzerindeki acil likidite yükünü azaltır ancak kullanıcılar ve CI sağlayıcıları arasında bir pazarın geliştirilmesini gerektirir.
Toplum Perspektifleri: FOCIL vs. BRAID
Ethereum topluluğu FOCIL ve BRAID’in göreceli değerleri konusunda ikiye bölünmüş durumda. Ethereum istemcisi Prysm’in geliştiricisi Terence, BRAID’in ek katılımcı gerektirmemesini ve dahil etme listelerinin sunulması ve doğrulanması için ekstra zaman kısıtlamaları getiren FOCIL’e kıyasla süreci basitleştirmesini takdir ediyor. Bununla birlikte, FOCIL’in genellikle daha kolay uygulanabilir ve daha esnek olduğu düşünülmektedir.
Paradigm’de araştırmacı olan Dan Robinson, BRAID’i işlemlere öncelik verme yaklaşımı ve MEV risklerini etkin bir şekilde azaltması nedeniyle övmektedir. Ayrıca koşullu bahşiş mekanizmasını sansüre karşı güçlü bir teşvik olarak vurguluyor – FOCIL’in sahip olmadığı bir özellik.
Buna karşılık, geliştirici Dev, FOCIL’in daha az komplikasyonla daha basit bir uygulama sunduğunu öne sürerek, basitliği ve sağlam sansür direnci nedeniyle FOCIL’i tercih etmektedir.
Ethereum araştırmacısı barnabe.eth, BRAID’in belirli alanlarda iyileştirmeler sunabileceğini kabul etmekle birlikte, FOCIL ve diğer IL tasarımlarının üzerine inşa edildiği lider tabanlı modeli tamamen terk etme konusunda temkinli davranmakta ve BRAID’in uygulanabilirliğini doğrulamak için daha fazla araştırma ve kanıta ihtiyaç duyulduğunu belirtmektedir.
Sonuç: Hangi Mekanizma Daha Üstün?
BRAID ve FOCIL arasındaki tartışma, Ethereum’da sansüre karşı direnç elde etmenin karmaşıklığının altını çizmektedir. BRAID’in öneren gücünü merkezsizleştirmeye ve MEV riskini azaltmaya yönelik yenilikçi yaklaşımı ilgi çekicidir, ancak önemli uygulama zorluklarıyla birlikte gelir ve daha fazla geliştirme gerektirir.
FOCIL, daha basit ve daha esnek olmakla birlikte, sofistike sansür girişimlerine karşı aynı düzeyde sağlamlık sunmayabilir.
Nihayetinde, BRAID ve FOCIL arasındaki seçim, Ethereum ağının herhangi bir zamandaki belirli önceliklerine bağlı olabilir. Ekosistem gelişmeye devam ettikçe, her iki mekanizma da Ethereum’un sansüre karşı direncini güçlendirmede rol oynayabilir ve ağın merkezi olmayan ilkelerine sadık kalmasını sağlayabilir.