MEV-Boost, protokol sidecar saat ini untuk ekstraksi MEV di Ethereum, sangat bergantung pada aktor pusat yang disebut relay.
Kami mengusulkan arsitektur alternatif yang memungkinkan komunikasi langsung, kriptografi privat antara pembangun dan penawar. Ini didasarkan pada bentuk enkripsi ambang 'diam' yang baru, non-interaktif yang dapat menggunakan pasangan kunci BLS validator yang ada.
Secara prinsip, kami memanfaatkan komite penyetujuan untuk privasi dan ketersediaan data dengan melakukan enkripsi ambang batas pada proposal blok ke sebagian penyetuju untuk slot tersebut. Attestasi mereka membentuk kunci dekripsi; setelah ambang batas yang diinginkan telah diattestasi, blok dapat didekripsi.
Konstruksi kami mengatasi privasi antara pembangun dan pengusul tetapi tidak sendirian menjamin validitas blok. Ini dapat dikombinasikan dengan mekanisme lain untuk sepenuhnya mereplikasi fungsi yang disediakan oleh relay - baik privasi maupun validitas blok. Sebagai contoh, skema bukti seperti Lingkungan Eksekusi Terpercaya (TEE) atau bukti Zero-Knowledge (ZK), atau mekanisme kriptoekonomi untuk mempertaruhkan pembangun.
Dengan menghilangkan kebutuhan relai untuk menyediakan privasi pembangun dan memastikan validitas blok, kami bertujuan untuk mengurangi laten dan meningkatkan desentralisasi dan ketahanan sensor Ethereum.
Privasi untuk Pembangun: Relay memastikan bahwa para proposer tidak dapat melihat isi blok dan mencuri MEV yang ditemukan oleh pembangun.- Keamanan untuk Pemohon: Relay menjamin bahwa pembangun membayar nilai yang dijanjikan kepada pemohon dalam tawaran pembangun dan bahwa blok tersebut valid (misalnya, semua transaksi membayar gas intrinsik).Ketergantungan pada relay, namun, memperkenalkan sentralisasi yang signifikan. Sekitar 90% blok di Ethereum disampaikan melalui hanya beberapa relay. Ini memunculkan beberapa risiko:
Pusat: Pemilik dapat mencapai efisiensi laten dengan mendekatkan dengan relay daripada mencerminkan distribusi geografis penawar. Ini secara langsung menghancurkan desentralisasi geografis dan resistensi sensor kami yang seharusnya didapatkan dari kumpulan validator yang besar dan tersebar di seluruh dunia.- Pendapatan: Rata-rata laten pemrosesan blok ujung-ke-ujung dari relay yang efisien adalah sekitar 5-20 milidetik. Kemudian, ada laten komunikasi antara penyarankan dan pembangun. Melewati relay akan mengurangi laten, menurunkan risiko eksekusi lintas domain (misalnya CEX/DEX), dan pada akhirnya meningkatkan penghargaan MEV penyarankan.## TEE-MeningkatkanSalah satu proposal terkemuka untuk menggantikan relai adalah "TEE-Boost“, yang bergantung pada TEE (Lingkungan Eksekusi Terpercaya). Perlu dicatat bahwa TEE tidak penting untuk skema kami; hanya membantu menggunakan TEE-Boost sebagai contoh pedagogis dari masalah yang ingin kami selesaikan.
Konkretnya, TEE-Boost memiliki pembangun menggunakan TEE untuk membuat bukti yang menunjukkan kepada pengusul kejujuran tawaran mereka dan validitas blok mereka tanpa mengungkapkan isi blok yang sebenarnya kepada pengusul. Pengusul dapat memeriksa bukti-bukti ini tanpa menjalankan TEE sendiri pada perangkat keras komoditas.
Namun, TEE-Boost memiliki masalah ketersediaan data: pembangun hanya berbagi bukti TEE dan header blok dengan penyarankan, bukan konten blok yang sebenarnya,[1]dan mungkin memilih untuk tidak mengeluarkan konten blok bahkan setelah proposer menandatangani header (misalnya, jika kondisi pasar berubah tidak menguntungkan). Pendekatan yang disarankan untuk memecahkan masalah DA ini adalah:
[ ] TEE-Escrow: TEE-escrow mendapatkan blok dari pembangun sebelum proposer menandatanganinya dan melepaskannya begitu mereka melihat header yang ditandatangani.- [ ] Lapisan Ketersediaan Data: Para pembangun mengirimkan muatan blok yang terenkripsi ke lapisan Ketersediaan Data (DA).Kedua pendekatan memiliki kekurangan. Solusi TEE-escrow mereplikasi dinamika laten sentralisasi yang serupa dengan relay yang ada.[2]Menggunakan lapisan DA eksternal memperkenalkan asumsi ekstra-protokol dan memikul dinamika laten dari protokol eksternal tersebut (yang juga kemungkinan tidak menguntungkan).
Secara teori, jika para penyarankan juga memiliki akses ke TEE, para pembangun dapat mengenkripsi blok mereka ke TEE yang dijalankan oleh penyarankan. TEE penyarankan hanya akan mendekripsi blok setelah mereka telah menandatanganinya. Namun, kami berpikir TEE-Boost tidak mempertimbangkan desain ini karena akan memerlukan penyarankan (validator) untuk menjalankan TEE. Kami ingin validator dapat berjalan pada perangkat keras komoditas.↩
Dinamika keterlambatan dapat dihindari jika para proposer menjalankan TEE-Escrow sebagai sampingan yang terletak di dekat node validator mereka. Namun, sekali lagi, kami tidak ingin membuat validator menjalankan TEE.↩
Teknologi yang memungkinkan inti adalah Enkripsi Ambang Senyap. Teknik kriptografi ini memungkinkan enkripsi ambang batas tanpa memerlukan fase setup Distributed Key Generation (DKG) yang interaktif, yang dibutuhkan oleh konstruksi sebelumnya. Sebaliknya, kunci publik bersama dihitung secara deterministik dari kunci publik BLS yang sudah ada dari pengesahan ditambah beberapa "petunjuk" (dibahas nanti).
Ini mencapai komunikasi langsung satu langkah antara pembangun dan validator dengan privasi kriptografis. Validator tidak perlu menjalankan TEE sendiri atau mengelola materi kunci baru apa pun.
Mekanik:
Pembangun membangun sebuah blok dan mengenkripsi nya ke komite pemeriksa.
Pembangun membuat bukti TEE yang menunjukkan tiga hal kepada komite penguji: bahwa penawaran jujur, blok valid, dan terenkripsi dengan benar.
Pembangun mengkomunikasikan blok terenkripsi ambang batas dan bukti TEE (yang mencakup nilai tawaran) kepada pemberi tawaran.[3]
Penyarankan menandatangani blok terenkripsi dari pemenang pembangun dan menyebarkan proposal ini ke set validator.
Setelah komite attester yang ditentukan (misalnya n/2 atau 2n/3) untuk slot memberikan bukti pada blok, maka blok tersebut akan didekripsi.
Blok yang terdekripsi berlanjut ke penyelesaian secara normal.
n adalah ukuran maksimum komite yang ingin kami dukung dan t adalah ambang batas untuk dekripsi.
Baik enkripsi maupun dekripsi sebagian dilakukan dalam waktu konstan. Dengan implementasi yang sederhana, enkripsi membutuhkan waktu kurang dari 7 ms - dan ini dapat dilakukan secara paralel. Dekripsi sebagian membutuhkan waktu kurang dari 1 ms.
Ukuran sandi teks adalah faktor penambahan konstan, 768 byte, lebih besar dari teks biasa (untuk setiap n dan t).
Penggabungan dekripsi parsial (yaitu, dekripsi) bergantung pada ukuran komite. Dengan n=1024, implementasi naif membutuhkan τ,gτ2,...,gτn−t), mirip dengan yang digunakan untuk skema komitmen polinomial KZG.
Selain itu, setiap validator dengan kunci publik BLS berupa gsk menerbitkan seperangkat elemen grup yang kami sebut "petunjuk": (gsk⋅τ,...,gsk⋅τn−t). Petunjuk ini hanya diperlukan untuk mengumpulkan kunci publik aggreGate dan mendekripsi teks terenkripsi. Enkripsi hanya menggunakan kunci publik aggreGate dengan ukuran tetap.
Saat ini, terdapat sekitar 1 juta validator. Jika kita mengatur n=128 dan t=n/2, setiap validator perlu memposting ≈ 3 KB petunjuk. Dengan demikian, menyimpan petunjuk dari semua validator membutuhkan 3 GB.
Persyaratan ini kemungkinan akan menurun secara signifikan dengan aktivasi MaxEB, yang memungkinkan validator yang mengendalikan >32 ETH untuk memiliki saldo yang lebih besar di bawah kunci yang sama (daripada membaginya menjadi beberapa deposit 32 ETH). Pengurangan dalam kumpulan validator yang akan terjadi masih diperdebatkan. Kemungkinan kita bisa mencapai sekitar ~1GB.
Terakhir, tergantung pada perubahan masa depan dalam arsitektur konsensus Ethereum (misalnya, pengurangan lebih lanjut dalam ukuran set validator, atau pipelining finalitas alternatif), ukuran petunjuk yang harus disimpan dapat semakin berkurang.
Salah satu solusinya adalah membiarkan pembangun memutuskan fraksi yang dapat diterima (𝑡) dari komite untuk dekripsi. Ada tradeoff antara privasi (kemungkinan unbundling dan MEV-stealing) dan kemungkinan ambang komite online. Ini mengoptimalkan pendapatan bagi pembangun untuk memasukkan blok mereka, daripada di-fork, sehingga mereka harus mencari pengaturan ambang yang dioptimalkan.[4]
Selain itu, penggunaan skema enkripsi ini sebaiknya menjadi pilihan. Di bawah kondisi jaringan yang buruk, di mana tidak ada komite dengan ukuran yang dapat diterima yang tersedia secara konsisten, para pengusul dan pembangun dapat kembali menggunakan relay, membangun sendiri, atau mekanisme lain yang lebih disukai sesuai dengan sifat lingkungan yang buruk.
Dari perspektif protokol, tidak masalah untuk bercabang keluar dari blok-blok ini. Sekadar validator yang lebih luas mungkin tidak bisa memberikan kesaksian terhadap mereka atau terhadap blok-blok yang mengacu pada mereka. Cara terbaik untuk menangani jenis kesalahan ini kemungkinan membuat klien konsensus menyadari kemungkinan tersebut dan mampu gagal dengan lembut. Studi lebih lanjut tentang bagaimana tepatnya diperlukan.
Pendekatan terbaik kemungkinan akan menjadi upgrade bersama atau setelah MaxEB di mana klien konsensus diberitahu tentang kemungkinan semantik blok terenkripsi dan validator didorong untuk mempublikasikan petunjuk. Sebagai contoh, setelah MaxEB, mungkin diperlukan agar validator yang baru masuk mempublikasikan petunjuk, dan validator yang lebih lama dapat diberi insentif untuk upgrade.
Pembangun akan mulai menggunakan mekanisme tersebut begitu sebagian cukup dari kumpulan validator mengadopsinya untuk memiliki ukuran komite yang memadai (yaitu, baik privasi yang dapat diterima maupun kemungkinan dekripsi yang memadai).
Jika pendekatan kami memang memiliki laten yang menguntungkan dibandingkan dengan relay multi-hop, pasar harus mengadopsinya tanpa perlu protokol untuk menegakkan penggunaan atau mengabadikan parameterisasi tertentu.
Kita perlu menghapus relai dan berpikir bahwa ini adalah cara yang cukup elegan untuk melakukannya. Ini memerlukan perubahan pada lapisan konsensus, tetapi tidak ada perangkat keras atau materi kunci baru yang diperlukan dari pihak validator.
Kekurangannya adalah bahwa ini adalah perubahan kompleks pada lapisan konsensus untuk mekanisme yang (jika opt-in, seperti yang disarankan) mungkin atau mungkin tidak diadopsi oleh pasar. Namun, banyak perubahan potensial pada pipa MEV memiliki pertanyaan adopsi dan optimasi pendapatan yang sama (misalnya, daftar inklusi). Dan mungkin ada kasus penggunaan masa depan lain yang bergantung pada infrastruktur enkripsi ambang batas yang tersedia bagi himpunan validator.





