MEV-Boost, Ethereum'da MEV çıkarma için mevcut yan ara protokolü, Röle adı verilen merkezi aktörlere ağır bir şekilde bağımlıdır.

Doğrudan, kriptografik olarak özel iletişime izin veren alternatif bir mimari öneriyoruz, bu mimari inşaatçılar ve önerenler arasında. Bu, mevcut BLS anahtar çiftlerini kullanabilen, yeni, etkileşimsiz bir 'sessiz' eşik şifreleme biçimine dayanmaktadır.

Temelde, gizlilik ve veri erişilebilirliği için onay komitesine röle yaparak blok tekliflerini eşik şifreleyerek slot için onaylayıcıların bir kısmına yükleniriz. Onların onaylamaları şifre çözme anahtarı oluşturur; istenen eşik onayladıktan sonra blok çözümlenebilir.

İnşamız, yapımcılar ve teklif sahipleri arasındaki gizliliği ele alır, ancak yalnızca blok geçerliliğini garanti etmez. Tamamen röleler tarafından sağlanan işlevleri tam olarak çoğaltmak için diğer mekanizmalarla birleştirilebilir. Örneğin, Güvenilir Yürütme Ortamı (TEE) kanıtları veya Sıfır-Bilgi (ZK) kanıtları gibi kanıt şemaları veya yapımcıları teminat altına almak için kriptoekonomik mekanizmalar.

Yapımcı gizliliğini sağlamak ve blok geçerliliğini garanti etmek için rölelere ihtiyaç duyulmasını ortadan kaldırarak, gecikmeleri azaltmayı ve Ethereum'un merkeziyetsizleştirilmesini ve sansür direncini artırmayı hedefliyoruz.

MEV-Boost ve Röle'lerin Rolü

MEV-Boost, blok oluşturucular ve teklif verenler arasında aracılık yapan bir sepet protokolüdür. bu ana rolRölenin iki garantiyi sağlaması amaçlanmaktadır:

• Yapımcılar için Gizlilik: Röle, önerenlerin blok içeriğini görmesini ve yapımcı tarafından bulunan MEV'yi çalmasını engeller.
• Teklif Verenler için Güvenlik: Röle, yapımcının teklif verene vaat ettiği değeri ödemesini ve bloğun geçerli olduğunu (örneğin, tüm işlemlerin içsel gaz ödemesini) garanti eder.

Ancak, rölelere dayanma, önemli bir merkezileşmeyi beraberinde getiriyor. Ethereum'daki blokların yaklaşık %90'ı sadece birkaç röle aracılığıyla iletilmektedir. Bu bazı riskler ortaya çıkarır:

• Merkezileştirme: Oluşturucular, önericilerin coğrafi dağılımını yansıtmak yerine rölelerle birlikte yerleşerek gecikme açısından verimli olabilirler. Bu, büyük, küresel olarak dağıtılmış bir doğrulayıcı kümesinden elde edeceğimiz coğrafi merkeziyeti ve sansür direncini doğrudan zayıflatır.
• Gelir: Verimli rölelerin ortalama uçtan uca blok işleme gecikmesi yaklaşık 5-20 milisaniye civarındadır. Ardından, öneren ve oluşturucu arasında iletişim gecikmesi bulunmaktadır. Röleleri atlamak gecikmeyi azaltacak, çapraz etki risklerini düşürecek (örneğin, CEX/DEX) ve nihayetinde önerenlerin MEV ödüllerini artıracaktır.

TEE-Güçlendirme

Röleleri değiştirmek için önde gelen önerilerden biri "TEE-Boost“, TEE'ler (Güvenilir Yürütme Ortamları) üzerine dayanan bir şemaya dayanmaktadır. TEE'lerin şemamız için gerekli olmadığını unutmayın; sadece çözmeyi amaçladığımız sorunların pedagojik bir örneği olarak TEE-Boost kullanmak faydalıdır.

Somut olarak, TEE-Boost, yapımcıların tekliflerinin dürüstlüğünü ve bloklarının geçerliliğini önerenlere gerçek blok içeriğini ifşa etmeden kanıtlayan TEE'leri kullanmasını sağlar. Önerenler, TEE'leri kendileri çalıştırmadan bu kanıtları kontrol edebilirler.

Ancak, TEE-Boost'un bir veri erişilebilirlik sorunu vardır: inşaatçılar yalnızca TEE kanıtlarını ve blok başlıklarını önericilerle paylaşırlar, gerçek blok içeriğini değil,^[1]ve öneren başlık imzaladıktan sonra bile blok içeriğini yayınlamama seçebilir (örneğin, piyasa koşulları olumsuz değişirse). Bu DA sorununun çözümü için önerilen yaklaşımlar şunlardır:

• [ ] TEE-Escrow: Bir TEE-kefaleti, öneren tarafından imzalanmadan önce bloğu oluşturucudan alır ve imzalanmış başlığı gördükten sonra serbest bırakır.
• [ ] Veri Erişilebilirlik Katmanları: Oluşturucular şifrelenmiş blok yüklerini Veri Erişilebilirlik (VE) katmanına gönderir.

Her iki yaklaşımın da dezavantajları vardır. TEE-emanet çözümü, mevcut rölelerin benzer şekilde merkeziyetçi gecikme dinamiklerini çoğaltır.^[2] Harici bir DA katmanı kullanmak, ekstra bir protokol varsayımı getirir ve bu harici protokolün gecikme dinamiklerini taşır (ki bu da muhtemelen elverişsizdir).

1. Teorik olarak, önericiler de TEE'lere erişimleri olsaydı, yapımcılar bloklarını önerici tarafından çalıştırılan bir TEE'ye şifreleyebilirlerdi. Önericinin TEE'si, yalnızca onayladıktan sonra bloku çözerdi. Ancak, TEE-Boost'un bu tasarımı dikkate almadığını düşünüyoruz çünkü önericilerin (doğrulayıcıların) TEE'leri çalıştırması gerekecek. Doğrulayıcıların ticari donanımlarda çalıştırabilmesini istiyoruz.↩

2. Gecikme dinamiklerinden kaçınılabilir, eğer önericiler kendi doğrulayıcı düğümüne yan yana yerleştirilmiş bir yan araba olarak TEE-Escrow çalıştırırlarsa. Ancak yine de, doğrulayıcıların TEE çalıştırmasını istemiyoruz.↩

Yapımcı Gizliliği Sağlamak İçin Eşik Kriptografisi

TEE-Boost'ın DA sorununa zarif bir çözüm öneriyoruz: Eşik şifreleme ile doğrulayıcı komitesine. Özellikle, inşaatçı bloğu belirli bir yüzdeye kadar doğrulayıcı komitesine şifreler. Yeterli doğrulamalar toplandığında, blok şifresi çözülebilir ve kullanılabilir hale gelir.

Temel olanak sağlayan teknolojiSessiz Eşik ŞifrelemeBu kriptografik teknik, önceki yapılandırmaların gerektirdiği etkileşimli Dağıtılmış Anahtar Oluşturma (DKG) kurulum aşamasını gerektirmeksizin eşik şifrelemesine izin verir. Bunun yerine, ortak genel anahtar, belgelerin zaten mevcut olan BLS genel anahtarlarından deterministik olarak ve bazı "ipuçları" (daha sonra tartışılacaktır) eklenerek hesaplanır.

Bu, oluşturucu ile doğrulayıcı arasında kriptografik gizlilikle doğrudan tek atlama iletişim sağlar. Doğrulayıcıların kendileri TEE'leri çalıştırmak zorunda değildir veya herhangi yeni anahtar malzemesini yönetmek zorunda değildir.

Mekanik:

Yapımcı bir blok oluşturur ve onu doğrulayıcı komitesine şifreler.

Yapımcı, teklifin dürüst olduğunu, bloğun geçerli olduğunu ve doğru bir şekilde şifrelendiğini gösteren bir TEE kanıtı oluşturur ve bunu belirleyici komitesine sunar.

İnşaatçı eşikli şifreli bloğu ve TEE kanıtını (teklif değerini içeren) önericiye iletiyor.^[3]

Teklif sahibi, kazanan inşaatçının şifrelenmiş bloğunu imzalar ve bu teklifi doğrulayıcı takıma yayınlar.

Belirtilen kesrin (örneğin n/2 veya 2n/3) yargıç komitesi, yuva için onay verdiğinde blok çözümlenir.

Şifrelenmiş blok normal şekilde finalizasyona devam eder.

1. Öneren bant genişliği gereksinimlerine etkisi incelenmelidir. Düşük bant genişliğine sahip önerenler, blok gövdesini istemeden önce kanıtları doğrulayarak veya diğer sezgisel filtreleme ve akıllı indirme teknikleriyle ihtiyaçları sınırlayabilir. Bu açık bir sorundur, ancak normal mempool söylenti spam sorunlarından çözülmesi muhtemelen daha zor değildir.↩

Düşünceler

Performans

Sessiz Eşik Şifreleme'nin performans özellikleri oldukça olumlu. Burada

n, desteklemek istediğimiz komitenin maksimum boyutudur ve t, şifre çözümlemesi için eşik değeridir.

Hem şifreleme hem de kısmi şifre çözme sürekli zamanlıdır. Saf bir uygulama ile şifreleme <7 ms sürer - ve bu paralel hale getirilebilir. Kısmi şifre çözme <1 ms sürer.

Şifreli metin boyutu, herhangi bir n ve t için, 768 bayt olan düz metinden daha büyük bir sabit ek faktördür.

Kısmi şifre çözümlerinin toplanması (yani, şifre çözme işlemi), komitenin boyutuna bağlıdır. n=1024 için, basit bir uygulama <200ms alır. Her yuva için belirtilen komite boyutu olan n=128 ile bu değerin 10 katına düşeceğini ve uygulamanın daha da optimize edilebileceğini bekliyoruz.

Önemli olan, şifreleme süresi, röle gecikmesiyle karşılaştırmak için ana performans numarasıdır. Bu, yapımcının blok üretiminin "kritik yolunda" hesaplaması gereken şeydir. Varolan rölenin blok işleme gecikmesinden daha düşüktür ve çoklu atlamalı iletişimi önler.

Veri Yayını

Sessiz Eşik Şifreleme tamamen ücretsiz değil. (g,g^τ,g^τ2,...,g^τn−t), KZG polinom taahhüt şeması için kullanılanla benzer.

Ek olarak, gsk biçiminde bir BLS açık anahtarına sahip her doğrulayıcı, "ipuçları" olarak adlandırdığımız bir dizi grup öğesi yayınlar: (g^sk⋅τ,…,g^sk⋅τn−t). Bu ipuçları yalnızca toplu anahtarları birleştirmek ve şifreli metinleri çözmek için gereklidir. Şifreleme yalnızca sabit boyutlu birleştirilmiş bir halka açık anahtar kullanır.

Bu yazıyı yazarken yaklaşık olarak 1 milyon doğrulayıcı bulunmaktadır. Eğer n=128 ve t=n/2 olarak ayarlanırsa, her doğrulayıcının yaklaşık olarak 3 KB ipucu yayınlaması gerekmektedir. Bu nedenle, tüm doğrulayıcıların ipuçlarının saklanması 3 GB gerektirir.

Bu gereksinim olası olarak önemli ölçüde azalacak.MaxEB'nin etkinleştirilmesi, aynı anahtar çifti altında daha büyük bakiyeler tutmasına izin veren ve 32 ETH'den fazla kontrol eden doğrulayıcılarla (bunları birden fazla 32 ETH yatırımına bölmek yerine) ilgili olan. Gerçekleştirilecek doğrulayıcı setindeki azalma tartışmalıdır. ~1GB'ye kadar düşülebileceği görünmektedir.

Son olarak, Ethereum'un farklılaşma boru hattı gibi gelecekteki değişikliklere bağlı olarak (örneğin, doğrulayıcı kümesinin boyutunda daha fazla azalma veya alternatif kesinlik boru hattı gibi) depolanması gereken ipuçlarının boyutu daha da azalabilir.

Canlılık

Ethereum, olumsuz ağ koşullarında bile işlemeye devam etmek istiyor. Bu düzenin bir sorunu, belirtilen komitenin çevrimdışı olması nedeniyle şifrelenemeyen blokların olasılığıdır.

Bir çözüm, yapının şifre çözme için kabul edilebilir komite kesir (𝑡) üzerinde karar vermesine izin vermektir. Gizlilik (ayrıştırma ve MEV çalma olasılığı) ile komite eşiği çevrimiçi olma olasılığı arasında bir ticaret-off vardır. Bloklarının dahil edilmesi, çatallanmış olmaktan ziyade gelirleri maksimuma çıkarmak için inşaatçılar için önemlidir, bu nedenle optimize edilmiş bir eşik ayarı bulmaları gerekmektedir.^[4]

Ayrıca, bu şifreleme şemasının kullanımı tercihe bağlı olmalıdır. Kabul edilebilir boyuttaki bir komite herhangi bir tutarlılıkla mevcut olmadığında, önerenler ve inşaatçılar, röleleri, kendi kendine inşa etmeyi veya olumsuz ortamın doğasına göre tercih edilen herhangi başka bir mekanizmayı kullanmaya geri düşebilir.

1. Burada özel iddia edilen şey, bir yapımcı bloğunun çatallaşması negatif EV olduğu (onlardan gelir almadığı) ve çözülmesi çok negatif EV olduğudur. Yapımcıya [0,128] arasında t seçme yeteneği verirseniz, çok düşük çözülme riski ve memnun olunacak yüksek olasılık olacak şekilde t yeterince yüksek seçmeye teşvik edilmelidir (en az t komitesinin üyeleri çevrimiçi olacaktır). Bazı bloklar normal ağ koşulları altında bile çatallaşabilir, ancak bunun zamanlama oyunlarıyla zaten olduğunu belirtiyoruz ve zincirin canlılığı kabul edilebilir kalır.↩

Kullanılamayan Bloklar

Ayrıca, komite çevrimiçi olabilir, ancak bir inşaatçı blok çözülemez veya geçersiz hale getirilebilecek bir durum yaratabilir (örneğin, sahte kanıtlarla)

Protokolün perspektifinden bakıldığında, bu blokları fork etmek sorun değil. Daha geniş bir doğrulayıcı seti sadece onlara veya onlara referans veren herhangi bir bloğa tanıklık edemezdi. Bu tür bir hatayı ele almanın en iyi yolu, muhtemelen uzlaşma istemcisini olası durumdan haberdar etmek ve düşüşü zarif bir şekilde yapabilmektir. Bunun tam olarak nasıl yapılacağı konusunda daha fazla çalışma gerekecektir.

Piyasa Yapısı

Kazanan inşaatçı, eşik noktasına ulaşılıncaya kadar diğerleri öncesinde blok içeriğini bilir, bu sonraki slotlarda adil olmayan bir avantaj yaratabilir. Ancak, doğrulayıcı komitesinin bir sonraki slota kadar hareket etmesi gerekiyor ve blok değerinin çoğunluğu slota sonunda olduğundan, bu avantajın etkileri mümkün olduğunca az olmalıdır.

Sadece Kriptografik Kanıtlar

Uzun vadede, TEE kanıtlarının yerini Zero-Knowledge (ZK) kanıtlarıyla değiştirmek mümkün olabilir. Şu anda, ZK kanıtları çok yavaş, ancak kriptografi, yazılım ve özel donanım (ASIC'ler) alanındaki ilerlemeler, ZK kanıt oluşturmanın gerekli gecikme kısıtlamaları içinde uygulanabilir hale gelmesini sağlayabilir. Özellikle, bloklara eşlik eden ZK kanıtları zaten mevcuttur.Ethereum'ın uzun vadeli yol haritasının temel parçası.

Benimseme

Mevcut doğrulayıcı set boyutu ve büyüme hızı ile bu düzen, L1'de yayınlanması gereken veri miktarının değerinin olmayabileceğini gösteriyor. Bununla birlikte, Ethereum zaten MaxEB ile doğrulayıcı set sayısını önemli ölçüde azaltmayı planlıyor.

Muhtemelen en iyi yaklaşım, olasılığı şifreli blok semantiği ve doğrulayıcıların ipuçları yayınlaması konusunda farkındalık kazandırılan bir yükseltme yanı sıra veya MaxEB'den sonra gerçekleşecektir. Örneğin, MaxEB'den sonra, yeni katılan doğrulayıcıların ipuçları yayınlamaları gerekebilir ve eski doğrulayıcılara yükseltme teşviki verilebilir.

İnşaatçılar, yeterli bir kesim tarafından kabul edildiğinde (yani, hem kabul edilebilir gizlilik hem de şifre çözme olasılığı) için yeterli komite boyutlarına sahip olması durumunda mekanizmayı kullanmaya başlarlar.

Eğer yaklaşımımız gerçekten çoklu-hop rölelemeye göre olumlu gecikmeye sahipse, pazarın bunu protokolün kullanımını zorunlu kılmadan veya belirli bir parametreyi yüceltmeden benimsemesi gerekir.

Mantıksal gerekçe

Röleler, merkezileşmenin Ethereum'un en önemli kaynaklarından biri olup, kiralama arayışlarına olanak tanıyor ve protokolün coğrafi merkezi olmayan yapısını bozuyor.

Röleleri kaldırmamız gerekiyor ve bunun nispeten zarif bir yol olduğunu düşünüyoruz. Bu, fikir birliği katmanında değişiklikler gerektirir, ancak doğrulayıcıların tarafında yeni donanım veya anahtar malzemeleri gerektirmez.

Olumsuz tarafı, pazar tarafından benimsenip benimsenmeyeceği (önerildiği gibi isteğe bağlı olarak) belirsiz bir mekanizma için konsensüs katmanında karmaşık bir değişiklik olmasıdır. Bununla birlikte, MEV boru hattına potansiyel değişikliklerin çoğu benzer benimsenme ve gelir optimizasyonu sorularını beraberinde getirir (örneğin, )dahil edilme listeleri). Ve validator setinin eşik şifreleme altyapısına sahip olmasına bağlı olan diğer gelecekteki kullanım durumları da olabilir.

Feragatname:

1. Bu makale [paradigma]. Tüm telif hakları orijinal yazarına aittir [ Charlie NoyesGuru, Vamsi Policharla]. Eğer bu yeniden basım ile ilgili itirazlarınız varsa, lütfen iletişime geçinGate Learnekip, ve hızla ele alacaklar.
2. Sorumluluk Reddi: Bu makalede yer alan görüşler yalnızca yazarın görüşleridir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalelerin diğer dillere çevirileri, Gate Learn ekibi tarafından yapılır. Belirtilmedikçe, çevrilen makalelerin kopyalanması, dağıtılması veya kopyalanması yasaktır.