Ethereum blok üretimi ve doğrulama sürecinde, yapımcılar işlemleri sıralamak ve blokları teklif verme mekanizması aracılığıyla teklif verenlere sunmakla sorumludur. Teklif verenler daha sonra bir blok seçer, imzalar ve blokzincirine teklif eder. Teklif verenlerin tek bir varlık olarak son söz hakkı olduğundan, teklif verenler ve yapımcılar arasında işlemleri sansürlemek için işbirliği riski bulunmaktadır.

Bloğ zincirinin temel değerlerinden biri sansür direncidir, yani işlemler merkezi otoritelerin müdahalesi olmadan gerçekleştirilebilir. Önerenlerin bir blokta hangi işlemlerin yer alacağını kontrol ettiği durumlarda, bu özellik tehdit altındadır ve adil ve şeffaflığı tehlikeye sokar. Ayrıca, bu güç, işlemlerin blok içindeki sırasını manipüle etmek için sömürülebilir, ekonomik kazanımlara yol açabilir ve Madenci Çıkarılabilir Değer (MEV) ile ilgili sorunları ortaya çıkarabilir.

Mevcut sansür dirençli çözümler

Bu zorluğa çözüm olarak, topluluk zorla dahil etme listeleri (FOCILFOCIL mekanizmasında her yuva için rastgele bir dizi doğrulayıcı seçilir ve bir dahil olma listesi komitesi oluşturmak için. Bu komite üyeleri, mempool'un öznel görüşüne dayalı olarak yerel dahil etme listeleri oluştururlar ve bunları yayınlırlar. Daha sonra önerenler, bu yerel listeleri toplamak ve birleştirmekten sorumludur, tek bir birleşik liste oluşturmak ve bloğa dahil etmek. Bu mekanizma, doğrulayıcıların daha önce yayınlanan yerel listelere karşı birleşik listeyi doğrulamasını sağlayarak blok dahilinde adil bir durumu garanti eder ve yalnızca uzlaşma kurallarına uygun bloklar kabul edilir ve blokzincir'e eklenir.

FOCIL'ın yanı sıra, topluluk aynı zamanda Çoklu Eş Zamanlı Önericiler (MCP) şemalarını da tartışmıştır. Bu kavram başlangıçta önerildi.Max ResnickiçindeÇeşitlilik birden fazla paralel blok önereni tanıtarak gücü dağıtmayı amaçlayan mekanizma, herhangi bir tek düğümün işlemleri sansürleme yeteneğini azaltır. Çokluk mekanizmasında, her doğrulayıcı "özel bir işlem paketi" oluşturmak için kendi mempool'undan işlemlerin bir kısmını seçer. Bu doğrulayıcılar, seçtikleri işlem paketlerini imzalar ve mevcut turun teklif sahibine gönderir. Teklif sahibi, geçerli sayılabilmesi için bu işlem paketlerinin en az 2/3'ünü önerdiği bloğa dahil etmelidir. Bu mekanizma, teklif sahiplerinin bloğun içeriğine tek taraflı olarak karar verememesini sağlar ve böylece sansür olasılığını azaltır. Teklif sahiplerini işlemleri adil bir şekilde dahil etmeye daha fazla teşvik etmek için bu mekanizma, yalnızca işlemi içeren teklif sahiplerinin işlem ücretlerini aldığı bir "koşullu bahşiş" kuralı uygular. İşlem ücretleri, işlemi dahil etmek için ilk teklif sahibine otomatik olarak verilmez, ancak belirli koşullara dayalı olarak işlemi fiilen dahil eden tüm teklif sahiplerine dağıtılır. Bu, işlemi içeren tüm teklif sahiplerine rüşvet vermek gerekeceğinden, sansür maliyetini artırır.

BRAID: Geliştirilmiş bir MCP uygulaması

Çokluk kavramını temel alan Max Resnick, MCP'nin daha karmaşık ve rafine bir uygulaması olan BRAID'i tanıttı. Max sundu BRAIDParadigm tarafından düzenlenen “MEV Çağında DeFi” seminerinde BRAID MCP'yi birden fazla önerenin farklı paralel zincirlerde blok önermesine izin vererek ve bu zincirler arasındaki tutarlılığı korumak için bir senkronizasyon mutabakat mekanizması kullanarak başarır. Her zincirin kendi önereni vardır ve tüm önerenler aynı yuva içinde aynı anda bloklarını serbest bırakır. Ethereum yürütme katmanı, o yuvada tüm alt zincirler tarafından oluşturulan blokları birleştirerek bir yürütme bloğu oluşturur. Ardından bu işlemleri önceden belirlenmiş kurallara göre tekrarlamaz, sıralar ve yürütür, böylece herhangi bir tek varlığın işlem kayıtlarını manipüle etme yeteneğini azaltır.

BRAID tasarımı, teşvik/ceza mekanizmalarıyla ilişkili karmaşıklıklardan kaçınmak için ek rollerin tanıtılmasını önler. Bununla birlikte, uygulaması nispeten karmaşıktır ve birden fazla alt zincirin senkronizasyonu ve veri işlemesinin koordinasyonunu gerektirir.

BRAID mekanizmasında sorunlar

JonahbBlockchain Capital ekibinden biri belirtti sorunBRAID mekanizması ile: “koşullu bahşiş” modeli likidite gereksinimleri uygular, kullanıcı deneyimini etkiler. Bu model, işlem sansür direncini sağlamak için kullanıcıların belirli bir likidite miktarı sağlamasını gerektiren dinamik bir fiyatlandırma stratejisidir. Bir işlem gönderirken, kullanıcılar iki bahşiş değeri (T ve t) belirlemelidir. Gerçek ödenen bahşiş, işlemi dahil eden önerenlerin sayısına bağlıdır.

1. Daha yüksek bir ipucu değeri, T, bir kullanıcının işleminin sansürlenmemesi için ödemeyi kabul etmeye istekli olduğu maksimum ücreti temsil eder. Amaç, diğer önericilerin böyle yapmaya istekli olmasa bile işlemi dahil etmeleri için önericileri teşvik etmektir. Eğer sadece bir önerici işlemi dahil ederse, tam miktarı, T alırlar.
2. Daha düşük bir ipucu değeri, t, kullanıcı tarafından belirlenen minimum miktarı temsil eder. İşlem aynı anda birden fazla önerici tarafından dahil edilirse, kullanıcı sadece t ödemek zorundadır ve bu miktar önericiler arasında paylaşılır. Kullanıcı sansür direncine daha az önem veriyorsa, T'yi t'ye eşit olarak ayarlayabilir ve işlemini yalnızca bir önericiye gönderebilir.

Ancak, bu ek likidite gereksinimi, blok zinciri işlemlerine katılmanın karmaşıklığını ve maliyetini artırır. Kullanıcılar, sansür direncini sağlamak için işlem sırasında ekstra fon ayırmalıdır. Bu ayrılmış fonlar, gerçekten kullanılana kadar donmuş kalır.

Bu sorunu çözmek için, Jonahb iki çözüm önerdi:

• Post-State Likiditesinin Kanıtı: Kullanıcılar, işlem gönderiminde, işlem gerçekleştirildikten sonra T'yi ödemek için yeterli likiditeye sahip olacaklarını gösteren bir kanıt sağlarlar (örneğin, kullanıcının işlem sonrası 1M dolarlık likiditesi olacak). Bu yöntem, kullanıcıların işlem öncesinde yeterli fonları olmasa bile ilerlemelerine izin verir. Bu yaklaşımın zorluğu, teklif verenlerin işlemin nihai durumunu işlem öncesinde bilmeleri gerektiğidir. Bununla birlikte, birçok mali işlem paylaşılan durumları içerir (örneğin, aynı hesap bakiyesini etkileyen birden fazla işlem), bu da teklif verenlerin işlem sırasının kesinleştirilmesinden önce işlem sonrası durumu doğru bir şekilde belirlemesini zorlaştırır. Bu yaklaşım, her işlem türü için özelleştirilmiş kanıtlar gerektirir, bu da daha az pratik olmasına neden olur.
• Sansür Sigortası: Kullanıcının T'sini garanti altına almak için üçüncü taraf sansür sigortası sağlayıcıları (SS sağlayıcıları) tanıtır. Kullanıcılar, işlemin sansürlenme olasılığına dayalı olarak bir sigorta primi olan rT öder. Bu yaklaşım, kullanıcıların hemen yüksek miktarda likidite hazırlaması ihtiyacını azaltır ve T'sinin çok düşük ve sansür riski yüksek olduğunda kullanıcıları uyarabilir. Bununla birlikte, kullanıcılar ve SS sağlayıcıları arasında bir pazar oluşturmak zaman alır.

FOCIL vs. BRAID Hakkında Topluluk Düşünceleri

Ethereum istemcisi Prysm geliştirici Terence notlarBRAID'ın önemli bir avantajının ek katılımcı gerektirmemesi olduğu gerçeği, FOCIL dahil olmak üzere çoğu İçerme Listesi (IL) tasarımının Ethereum slotları içinde zaman kısıtlamaları eklemesi gerektiğidir, örneğin IL'nin sunulma süresi, tekliflerin güncellenmesi ve doğrulayıcıların IL'yi kontrol etme süresi. Bununla birlikte, FOCIL, BRAID'e göre daha basit ve uygulanabilir bir yapıya sahiptir.

Paradigm araştırmacı Dan Robinsontakdir ederBRAID'ın işlem önceliklendirme tasarımı, tek bir lider (teklif veren) tarafından belirlenmeyen ve böylece MEV'yi etkin bir şekilde azaltan bir mekanizma içerir. Ayrıca, BRAID'ın koşullu bahşiş mekanizması, sansürsüz davranışı teşvik eder ve FOCIL'de bulunmayan bir özelliktir.

GeliştiriciGeliştirici tercih ederMCP'ye göre FOCIL, sansüre karşı daha güçlü bir direnç sunduğuna ve uygulanması daha basit olduğuna inanıyor. Ayrıca FOCIL'in daha kolay dağıtılabilmesi için bazı iyileştirmeler öneriyor.

Ethereum araştırmacısıbarnabe.ethgörüşlerFOCIL oldukça genel ve ölçeklenebilir bir mekanizma olarak kabul ediyor. BRAID'ın FOCIL tarafından sağlanan bazı garantileri iyileştirebileceğini kabul ediyor, ancak lider tabanlı modeli tamamen terk etme konusunda dikkatli davranıyor. BRAID'ın uygulanabilirliğini kanıtlamak için daha fazla çalışmanın gerekliliğine inanıyor.

açıklama:

1. Bu makale şuradan alıntıdır [ChainFeeds Araştırma], orijinal başlık “Ethereum'un sansür direncine giden yolu: BRAID mı yoksa FOCIL mi daha iyi?”dır, telif hakkı orijinal yazarına aittir [0XNATALIE], eğer yeniden basım konusunda herhangi bir itirazınız varsa, lütfen iletişime geçin Gate Learn Team , takım ilgili prosedürlere göre en kısa sürede bununla ilgilenecek.

2. Açıklama: Bu makalede yer alan görüşler yalnızca yazarın kişisel görüşlerini yansıtmakta olup herhangi bir yatırım tavsiyesi teşkil etmemektedir.

3. Makalenin diğer dil sürümleri Gate Learn ekibi tarafından çevrilmekte olup, bahsedilmemektedir.Gate.io, çevrilen makale çoğaltılamaz, dağıtılamaz veya kopyalanamaz.