MEV-Boost adalah protokol sampingan dalam Ethereum saat ini untuk mengekstraksi MEV yang sangat bergantung pada partisipan terpusat yang disebut Relay. Kami mengusulkan arsitektur alternatif yang memungkinkan komunikasi langsung dan rahasia kriptografi antara pembangun dan pemohon. Arsitektur ini didasarkan pada bentuk enkripsi ambang batas non-interaktif 'diam' yang baru dan menggunakan Kunci Rahasia BLS validator yang ada.

Pada dasarnya, kami mengusulkan enkripsi Blok ambang batas dan mengirimkannya kepada sebagian peserta melalui komite sertifikasi untuk mencapai privasi dan ketersediaan data. Bukti mereka membentuk dekripsi Kunci Rahasia; begitu ambang batas yang dibutuhkan tercapai, Blok dapat didekripsi.

Rencana konstruksi kami mengatasi masalah privasi antara pembangun dan pengusul, tetapi tidak dapat menjamin keefektifan Blok secara mandiri. Ini dapat digabungkan dengan mekanisme lain untuk sepenuhnya mereplikasi fungsi Relay, termasuk privasi dan keefektifan Blok. Misalnya, dapat menggunakan lingkungan eksekusi tepercaya (TEE) atau bukti pengetahuan nol (ZK), atau dengan mekanisme enkripsi untuk memberikan jaminan bagi pembangun.

Dengan menghilangkan kebutuhan untuk Relay sebagai pembangun privasi dan memastikan keefektifan Blok, kami bertujuan untuk mengurangi latensi, meningkatkan Desentralisasi dan kemampuan anti-pemeriksaan Ethereum.

Peran MEV-Boost dan Relay

MEV-Boost adalah sebuah protokol sampingan, bertindak sebagai perantara antara pembangun Blok dan pengusul. Peran utama Relay adalah memberikan dua jaminan: peran Relay saat ini

• Privasi Pembangun: Relay memastikan bahwa para pengusul tidak dapat melihat konten Blok dan juga tidak dapat mencuri MEV yang ditemukan oleh para pembangun.
• Keamanan Penyaji: Relay memastikan bahwa pembangun membayar nilai yang dijanjikan kepada penyaji sesuai penawarannya, dan memastikan Blok valid (misalnya, semua transaksi membayar biaya Gas internal).

Namun, ketergantungan pada Relay menghadirkan sentralisasi yang signifikan. Sekitar 90% blok Ethereum dikirim melalui hanya beberapa Relay. Ini membawa beberapa risiko:

• Desentralisasi: Pembangun dapat meningkatkan efisiensi latensi dengan berkolaborasi dengan Relay daripada mempertimbangkan distribusi geografis proposer. Hal ini secara langsung melemahkan kemampuan Desentralisasi dan ketahanan sensor yang seharusnya kita dapatkan dari kumpulan validator yang tersebar secara global dalam skala besar.
• Pendapatan: Rata-rata latensi pemrosesan blok end-to-end yang efisien dari Relay adalah sekitar 5-20 milidetik. Selain itu, ada juga latensi komunikasi antara pembangun dan pengusul. Melewati Relay akan mengurangi latensi, mengurangi risiko eksekusi lintas domain (misalnya CEX/DEX), dan pada akhirnya meningkatkan imbalan MEV pengusul.

TEE-Boost

Salah satu proposal utama pengganti Relay adalah "TEE-Boost" (https://collective.flashbots.net/t/tee-boost/3741), yang bergantung pada lingkungan eksekusi yang terpercaya (TEEs). Penting untuk dicatat bahwa TEEs bukanlah inti dari solusi kami; menggunakan TEE-Boost sebagai contoh pembelajaran untuk masalah yang ingin kami selesaikan sangat membantu.

Secara khusus, TEE-Boost memerlukan pembangun untuk menggunakan TEEs untuk membuat bukti, menunjukkan kejujuran dan validitas Blok penawarannya kepada penawar tanpa perlu mengungkapkan konten Blok yang sebenarnya kepada penawar. Penawar dapat memeriksa bukti ini di perangkat keras biasa tanpa perlu menjalankan TEEs sendiri.

Namun, TEE-Boost mengalami masalah ketersediaan data: pembangun hanya berbagi bukti TEE dan header Blok dengan pengusul, bukan konten Blok yang sebenarnya[1], dan mungkin memilih untuk tidak melepaskan konten Blok setelah penandatanganan proposer's head (misalnya, jika kondisi pasar mengalami perubahan yang merugikan). Metode saran untuk mengatasi masalah ketersediaan data ini termasuk:

TEE-Penyimpanan: TEE-Penyimpanan mengambil Blok dari pembangun sebelum penandatangan proposal dan melepaskan Blok tersebut setelah melihat tanda tangan.

Lapisan Ketersediaan Data: Pembangun akan mempublikasikan muatan Blok yang dienkripsi ke lapisan Ketersediaan Data (DA).

Kedua metode ini memiliki kekurangan. Solusi Penyimpanan TEE-Tiruan menggandakan latensi sentralisasi yang mirip dengan Relai yang ada [2]. Jika menggunakan lapisan DA eksternal, itu akan memperkenalkan asumsi protokol tambahan dan menerima latensi dinamis dari protokol eksternal tersebut (dinamika ini juga mungkin tidak menguntungkan).

1. Secara teori, jika penyarankan juga dapat mengakses TEE, pembangun dapat mengenkripsi Blok ke dalam TEE yang dijalankan oleh penyarankan. TEE penyarankan hanya akan mendekripsi Blok setelah ditandatangani. Namun, kami menganggap bahwa TEE-Boost tidak mempertimbangkan desain ini, karena hal ini akan meminta penyarankan (validator) untuk menjalankan TEE. Kami berharap validator dapat berjalan pada perangkat keras biasa.

2. Jika penyarankan itu sendiri menjalankan TEE-Penjaga sebagai operasi sampingan yang dideploy bersama validatorNodenya, maka dapat menghindari latensi dinamis

态。然而，我们同样不希望使validator运行TEEs。↩

Kriptografi Ambang untuk Mewujudkan Privasi Pembangun

Kami telah mengusulkan solusi yang elegan untuk mengatasi masalah ketersediaan data TEE-Boost: menerapkan enkripsi ambang batas pada komite verifikasi. Secara khusus, pembangun akan mengenkripsi Blok dengan ambang batas ke komite verifikasi dalam proporsi yang ditentukan untuk slot waktu tersebut. Setelah jumlah verifikasi yang cukup terkumpul, Blok dapat didekripsi dan tersedia.

Teknologi inti yang memungkinkan adalah silent gating enkripsi. Teknik kriptografi ini [memungkinkan enkripsi terjaga keamanannya] (https://eprint.iacr.org/2024/263) tanpa memerlukan tahap penyiapan Kunci Rahasia Generation (DKG) terdistribusi interaktif yang diperlukan untuk build sebelumnya. Sebaliknya, Kunci Publik bersama dihitung berdasarkan BLSKunci Publik yang sudah ada dari validator dan beberapa kepastian "petunjuk" (dibahas nanti).

Ini mengimplementasikan komunikasi langsung satu-per-satu antara pembangun dan validator, dengan privasi kriptografi. validator tidak perlu menjalankan TEEs sendiri atau mengelola bahan Kunci Rahasia baru apa pun.

Mekanisme:

Builder membangun sebuah Blok dan mengenkripsi-nya ke dalam komite verifikasi.

Konstruktor membangun bukti TEE untuk membuktikan kepada komite verifikasi tiga hal: penawaran yang jujur, Blok yang valid, dan enkripsi yang benar.

Pembangun akan mengirimkan bukti enkripsi Blok dan TEE dengan batas Blok kepada proposer (termasuk nilai penawaran). SUP[3]

Pengusul menandatangani enkripsiBlok pembangun pemenang dan menyebarkan proposal kepada kumpulan validator.

Setelah diperiksa oleh komite verifikasi dengan rasio tertentu (misalnya n/2 atau 2n/3), Blok akan didekripsi.

Blok yang telah didekripsi akan dijamin untuk konfirmasi akhir yang normal.

3. Diperlukan penelitian tentang dampak kebutuhan bandwidth proposer. Proposer dengan bandwidth rendah dapat membatasi kebutuhan dengan melakukan proof of validarion sebelum meminta blok utama, atau menggunakan teknik filter heuristik dan unduhan cerdas lainnya. Ini adalah masalah terbuka, tetapi tampaknya tidak lebih sulit untuk diselesaikan daripada masalah menyebarkan sampah ke memori pool secara normal. ↩

Catatan Penting

Performa

Karakteristik kinerja enkripsi ambang batas yang tidak berbunyi sangat menguntungkan. Di sini, n adalah skala maksimum komite yang ingin kami dukung, t adalah ambang batas dekripsi.

Waktu enkripsi dan dekripsi parsial adalah waktu konstan. Dengan implementasi sederhana, enkripsi membutuhkan waktu kurang dari 7 milidetik dan dapat dilakukan secara paralel. Dekripsi parsial membutuhkan waktu kurang dari 1 milidetik.

Ciphertext lebih besar 768 byte dari Plaintext, ini adalah faktor tambahan yang konstan (untuk setiap n dan t).

Bagian dekripsi agregat (yaitu dekripsi) tergantung pada ukuran komite. Ketika n = 1024, implementasi sederhana membutuhkan waktu kurang dari 200 milidetik. Kami perkirakan bahwa waktu ini akan berkurang 10 kali lipat ketika n = 128 (ukuran komite otorisasi per slot), dan implementasi dapat ditingkatkan lebih lanjut.

Yang penting, waktu enkripsi adalah parameter kinerja kunci yang dibandingkan dengan latensi Relay. Ini adalah konten yang harus dihitung oleh pembangun dalam 'jalur kritis' yang dihasilkan oleh Blok. Waktu ini lebih rendah dari latensi pemrosesan Blok Relay yang ada dan menghindari komunikasi melalui beberapa langkah.

Penyebaran Data

Batas pintu tak berbunyi enkripsi tidak benar-benar gratis. Memang memerlukan string referensi bersama, dalam bentuk: (g, gτ, gτ², …, gτⁿ⁻ᵗ), mirip dengan yang digunakan dalam skema komitmen polinomial KZG.

Selain itu, setiap validator dengan bentuk BLS Kunci Publik yang dinyatakan sebagai g⁽ˢᵏ⁾ mengeluarkan serangkaian elemen grup yang kami sebut sebagai "petunjuk": (g⁽ˢᵏ⁾⋅τ, …, g⁽ˢᵏ⁾⋅τⁿ⁻ᵗ). Petunjuk ini hanya diperlukan saat menggabungkan Kunci Publik dan mendekripsi Ciphertext. Enkripsi hanya menggunakan Kunci Publik yang diagregasi dengan ukuran konstan.

Saat ini, ada sekitar 1 juta validator. Jika kita mengatur n=128 dan t=n/2, maka setiap validator perlu memposting petunjuk sekitar 3KB. Oleh karena itu, menyimpan semua petunjuk validator membutuhkan ruang sekitar 3GB.

Dengan aktivasi MaxEB, persyaratan ini mungkin akan menurun secara signifikan, MaxEB memungkinkan pengendalian validator dengan lebih dari 32 ETH untuk memegang saldo yang lebih besar di bawah satu Kunci Rahasia (daripada mendispersikannya ke beberapa deposit 32 ETH). Pengurangan kumpulan validator yang akan diimplementasikan masih perlu dibahas. Kami mungkin akan menurunkannya menjadi sekitar 1GB.

Terakhir, berdasarkan perubahan masa depan dalam arsitektur Konsensus Ethereum (misalnya, penurunan skala validator atau penggantian pipa akhir), ukuran petunjuk yang harus disimpan mungkin akan lebih lanjut berkurang.

Energi

Etherum Blok berharap untuk tetap online dalam kondisi jaringan yang tidak menguntungkan. Salah satu masalah dari skema ini adalah bahwa karena komite dalam proporsi tertentu berada dalam keadaan offline, Blok mungkin tidak dapat dipecahkan.

Salah satu solusi adalah memungkinkan pembangun untuk menentukan rasio komite yang dapat diterima (t) untuk dekripsi. Ada keseimbangan antara privasi (potensi pembongkaran dan pencurian MEV) dan kemungkinan ambang batas komite. Bagi pembangun, memastikan bahwa Blok mereka disertakan dalam rantai daripada di-fork adalah cara untuk memaksimalkan pendapatan, sehingga mereka harus mencari pengaturan ambang yang dioptimalkan.[4]

Selain itu, penggunaan skema enkripsi ini harus menjadi pilihan sukarela. Dalam kondisi jaringan yang tidak menguntungkan, jika tidak ada komite dalam skala yang dapat diterima yang dapat beroperasi secara online secara berkelanjutan, para pengusul dan pembangun dapat beralih ke Relay, membangun sendiri, atau mekanisme lain yang dipilih berdasarkan sifat lingkungan yang tidak menguntungkan.

Secara khusus, nilai harapan Blok pembangun yang diforkan keluar adalah negatif (mereka tidak mendapatkan penghasilan dari itu), sementara nilai harapan yang dibuka sangat negatif. Jika pembangun memilih t di antara [0, 128], mereka seharusnya secara alami dimotivasi untuk memilih t yang cukup tinggi untuk menurunkan risiko Drop dan meningkatkan probabilitas dipenuhi (setidaknya t anggota komite online). Dalam kondisi jaringan normal, beberapa Blok mungkin akan diforkan, tetapi kami mencatat bahwa ini sudah terjadi dalam permainan waktu, dan keaktifan jaringan masih dapat diterima. [↩] (https://www.paradigm.xyz/2024/10/removing-the-relays#fn-ref-Liveness)

Blok yang Tidak Tersedia

Selain itu, komite mungkin online, tetapi pembangun mungkin dapat menciptakan situasi di mana Blok tidak dapat didekripsi atau tidak valid saat didekripsi (misalnya, dengan menggunakan bukti penipuan).

Dari sudut pandang protokol, Blok fork ini dapat dilakukan. Koleksi validator yang lebih luas secara sederhana tidak dapat membuktikan Blok semacam itu atau Blok yang merujuk pada mereka. Cara terbaik untuk menangani kesalahan ini mungkin adalah membuat klien Konsensus menyadari kemungkinan ini dan dapat gagal dengan elegan. Diperlukan penelitian lebih lanjut mengenai ini.

Struktur Pasar

Pemenang pembangun mengetahui konten Blok sebelum mencapai ambang batas, yang mungkin menyebabkan keunggulan yang tidak adil dalam periode berikutnya. Namun, komite bukti harus bertindak sebelum akhir periode berikutnya, sementara sebagian besar nilai Blok terkonsentrasi pada akhir periode, sehingga dampak keunggulan ini harus diminimalkan sebisa mungkin.

Bukti Kriptografi Murni

Dalam jangka panjang, ada kemungkinan untuk menggantikan bukti TEE dengan Bukti Zero-Knowledge (ZK). Saat ini, kecepatan ZK masih terlalu lambat, tetapi kemajuan dalam kriptografi, perangkat lunak, dan perangkat keras khusus (ASICs) mungkin akhirnya akan membuat generasi ZK menjadi layak dalam batasan latensi yang diperlukan. Perlu dicatat bahwa Bukti ZK bersama dengan Blok sudah menjadi bagian inti dari peta jalan panjang Ethereum.

Mengadopsi

Berdasarkan skala dan laju pertumbuhan validator saat ini, solusi ini mungkin tidak layak untuk jumlah data yang diperlukan untuk diluncurkan di L1. Namun, ETH telah merencanakan untuk secara signifikan mengurangi jumlah validator melalui MaxEB.

Metode terbaik mungkin adalah melakukan upgrade sebelum atau setelah MaxEB, sehingga klien Konsensus dapat menyadari kemungkinan semantik enkripsi Blok dan mendorong validator untuk merilis petunjuk. Misalnya, setelah MaxEB, validator yang baru bergabung dapat diminta untuk merilis petunjuk, sedangkan validator yang sudah ada dapat menerima insentif upgrade.

Saat sejumlah besar validator mengadopsi mekanisme ini, pembangun akan mulai menggunakannya untuk memastikan skala komite yang memadai (yaitu, mempertimbangkan kemungkinan privasi dan dekripsi yang memadai).

Jika metode kami benar-benar lebih unggul dari multi-hop forwarding dalam hal latensi, pasar harus secara spontan mengadopsinya tanpa perlu menggunakan protokol secara paksa atau mengatur pengaturan parameter tertentu.

Prinsip Dasar

Relay adalah salah satu sumber terpenting yang terpusat dalam Ethereum, menyebabkan kesempatan sewa dan merusak Desentralisasi protokol secara geografis. Kita perlu menghapus Relay dan menganggapnya sebagai solusi yang relatif elegan. Ini memerlukan perubahan pada lapisan konsensus, tetapi validator tidak perlu menyediakan perangkat keras atau material Kunci Rahasia baru.

Kekurangannya adalah bahwa ini merupakan perubahan yang kompleks pada lapisan konsensus, dan mekanisme ini (jika diadopsi secara selektif seperti yang disarankan) mungkin akan diterima oleh pasar, atau mungkin juga tidak. Namun, banyak perubahan potensial pada saluran MEV juga menghadapi masalah adopsi dan optimasi keuntungan yang serupa (misalnya, termasuk daftar). Selain itu, di masa depan, mungkin akan ada kasus penggunaan lain yang bergantung pada infrastruktur enkripsi validator set memiliki ambang batas.

Pernyataan:

1. Artikel ini diambil dari[paradigm], hak cipta milik pemilik asli [Charlie NoyesGuru, Vamsi Policharla], jika Anda memiliki keberatan terhadap penggunaan ulang, silakan hubungi tim Gate Learn, tim akan segera menanganinya sesuai prosedur yang berlaku.
2. Penyangkalan Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini hanya mewakili pandangan pribadi penulis dan tidak merupakan saran investasi apa pun.
3. Versi bahasa lain dari artikel diterjemahkan oleh tim Gate Learn, tidak boleh disalin, disebarkan, atau ditiru tanpa menyebutkan Gate.io.