Seberapa Banyak Kita Dapat Membatasi Pembangun?

https://ethresear.ch/t/how-much-can-we-constrain-builders-without-bringing-back-heavy-burdens-to-proposers/13808

Seberapa Banyak Kita Dapat Membatasi Pembangun Tanpa Membawa Kembali Beban Berat kepada Pengusul?

Salah satu respons alami terhadap risiko sentralisasi pembangun (terutama penyensoran, tetapi juga berbagai bentuk eksploitasi ekonomi) adalah mencoba membatasi kekuasaan yang dimiliki pembangun. Alih-alih pembangun memiliki kendali penuh untuk membangunseluruh memblokir jika mereka memenangkan lelang, pembangun akan memiliki kekuatan yang lebih terbatas. Kekuatan ini seharusnya masih cukup untuk menangkap hampir semua MEV yang dapat ditangkap, dan idealnya masih cukup untuk menangkap manfaat lain dari PBS, tetapi harus dilemahkan untuk membatasi peluang penyalahgunaan.

Ide ini terkadang disebut lelang blok parsial: alih-alih melelang hak untuk memutuskan segala sesuatu dalam satu blok, melelang hak untuk memutuskanbeberapa hal , di mana "beberapa hal" itu bisa lebih bernuansa daripada misalnya. "pembangun memilih paruh pertama blok dan bukan yang kedua": Anda dapat memberikan hak kepada pembangun untuk menyusun ulang, menambahkan, menambahkan, dan Anda bahkan dapat membatasi pengusul. Posting ini masuk ke beberapa cara yang mungkin untuk melakukan ini, dan beberapa pengorbanan yang dihasilkan.

Daftar inklusi

Dalam paradigma daftar inklusi, pengusul memberikandaftar inklusi , daftar transaksi yang mereka minta harus dimasukkan ke dalam blok, kecuali pembangun dapat mengisi satu bloksama sekali dengan transaksi lainnya.

Untuk pembangun yang memaksimalkan keuntungan yang tidak terpengaruh oleh insentif eksternal yang tidak biasa, daftar penyertaan bukanlah kendala sama sekali: menambahkan transaksi tambahan di akhir blok selalu memberi pembangun bahwa biaya prioritas transaksi sebagai keuntungan tambahan.

Dalam kasus di mana blok diisi hingga batas gas penuh (2x target), sehingga pembangun harus memilih antara transaksi tersebut dan transaksi lainnya, kendala dinonaktifkan. Hal ini tidak memengaruhi inklusi dalam jangka panjang, karena blok penuh hanya dapat dipertahankan sebentar karena membuat biaya dasar naik secara eksponensial (~2,02x setiap 6 blok).

Namun, jika pembangun memang memiliki keinginan untuk menolak memasukkan transaksi tertentu yang tidak disetujui atau diberi insentif untuk dikecualikan, pembangun tersebut akan dipaksa untuk tidak berpartisipasi dalam pelelangan.

Desain ini cukup sederhana, tetapi penting untuk menjelaskan beberapa kelemahannya:

• Masalah kompatibilitas insentif : pembuat melihat daftar penyertaan sebelumnya, dan pembuat dapat menolak untuk membuat blok yang berisi daftar penyertaan yang tidak ingin mereka buat. Hal ini menciptakan insentif langsung bagi pengusul untuk memiliki daftar penyertaan kosong, untuk memaksimalkan kemungkinan pembangun membangun blok untuk mereka.
• Beban ekstra bagi pengusul : pengusul harus mampu mengidentifikasi transaksi pembayaran fee. Ini membutuhkan (i) akses ke mempool dan (ii) kemampuan membaca negara bagian untuk menentukan pembayaran biaya, atau saksi yang melekat pada transaksi. Saksi lebih disukai, karena mereka akan menjaga properti PBS bahwa validator dapat menjadi klien tanpa kewarganegaraan.
• Pembangun masih dapat terlibat dalam beberapa pelanggaran : terutama serangan sandwich. Namun tidak jelas bagaimana mungkin untuk menghapus masalah ini tanpa pendekatan ekstrem seperti menggunakan kriptografi canggih untuk mengenkripsi mempools, karena jika tidak mengambil kekuatan ini dari pembangun berarti memberikannya kepada pengusul, yang akan memberi insentif bagi pengusul yang bergabung dengan kumpulan saham.
• Memerlukan pengabadian sebagian agar abstraksi akun berfungsi: melihatJalan menuju abstraksi akun - HackMD

Sarankan akhiran

Konstruksi alternatif adalah mengizinkan pengusul untuk membuat akhiran untuk blok tersebut. Pembangun tidak akan melihat informasi tentang niat pengusul ketika mereka membangun blok, dan pengusul akan dapat menambahkan transaksi apa pun yang terlewatkan oleh pembuat.

• Mengurangi masalah kompatibilitas insentif : pembangun masih dapat secara surut menghukum pengusul (mis. dengan menolak membangun untuk mereka di masa depan) yang mencakup transaksi yang tidak disetujui oleh pembangun, dan mengirimkan root ke pembangun. Ini tidak dapat dihindari, tetapi ini jauh lebih ramah pengusul daripada pembangun yang dapat menolak untuk membangun blok secara real time (terutama karena setiap pengusul individu hanya mengusulkan sesekali, hari ini setiap ~ 2 bulan).
• Bahkan lebih membebani pengusul - pengusul sekarang harus menghitung post-state root, yang berarti pengusul harus menyimpan seluruh status. Oleh karena itu, tidak ada keadaan tanpa kewarganegaraan yang dimungkinkan, kecuali pengusul mengalihdayakan tugas ini ke amemisahkan perantara.
• Pengusul mendapatkan beberapa peluang MEV antara mendapatkan respons dari pembuat dan harus menerbitkan blok. Ini mungkin hanya bernilai setengah detik, tetapi ini masih merupakan peningkatan insentif bagi validator untuk bergabung dengan kumpulan pasak agar dapat mengoptimalkan secara internal.
• Pembangun masih dapat melakukan beberapa pelanggaran, seperti sebelumnya
• Memerlukan pengabadian sebagian agar abstraksi akun berfungsi, seperti sebelumnya

Perbaiki sufiks pengusul: pra-komitmen

Pengusul melakukan pra-komitmen ke pohon Merkle atau komitmen KZG atau akumulator lain dari kumpulan tx yang ingin mereka sertakan. Pembangun membuat blok mereka sendiri. Pengusul kemudian harus menambahkan akhiran yang terdiri persis dari subset dari pohon Merkle yang belum dimasukkan oleh pembangun, dan bahwa batas gas memungkinkan mereka untuk memasukkan, memesan dengan txhash atau pesanan standar lainnya (jika mereka menambahkan yang lain akhiran, mereka disayat).

Detail penegakan pemotongan agak terlibat, terutama jika Anda ingin menghindari meletakkan pohon inklusi pengusul di tempat yang jelas. Ini dapat dengan mudah dilakukan dengan komitmen KZG dan ZK-SNARK tujuan khusus, menggunakan persamaan polinomial khusus untuk memverifikasi konsep “jika Anda memulai dari himpunan dengan komitmen X, dan menghapus semua yang ada di Y, maka himpunan yang tersisa adalah Z ”.

Ini menghilangkan peluang MEV pengusul, karena pengusul memiliki tingkat kebebasan nol dalam blok apa yang akan dipublikasikan setelah pembangun membalas dengan konten blok mereka sendiri, tetapi membiarkan masalah lain tidak terselesaikan.

Tujuan jangka panjang: bagaimana kita membatasi pembangunDan meminimalkan tanggung jawab pengusul?

Peran pengusul idealnya dijaga seminimal mungkin: hanya mengidentifikasi transaksi yang pantas untuk disertakan. Meminimalkan peran pengusul memastikan bahwa peran tersebut tetap mudah diakses. Peran pembangun idealnya dijaga seminimal mungkin: pembangun harus memiliki hak untuk mengatur ulang transaksi dari mempool dan memasukkan transaksi mereka sendiri untuk mengumpulkan MEV, tanpa dapat mendiskriminasi blok berdasarkan transaksi mana yang akan mereka sertakan.

Tapi ini membuat banyak tugas penting lainnya tidak terisi, terutama tugas yang akan diperlukan di masa depan:

• Tugas menghitung root post-state
• Tugas menghitung dan menerbitkan saksi
• Tugas membuat ZK-SNARK membuktikan kebenaran blok

Jika tugas-tugas ini tidak diberikan kepada pembangun, atau pengusul, maka mereka harus pergi ke beberapa orangketiga aktor. Ada beberapa cara yang mungkin untuk menerapkan ini:

• Kami membuat kelas terpisah dari perantara seperti pembangun, yang dikontrak oleh pengusul, dan yang menganggap dirinya hanya sebagai penyedia komputasi awan khusus yang tugasnya menghitung keluaran fungsi (pembuatan ZK SNARK, perhitungan akar negara, dll), dan tidak terlibat dalam memilih isi blok
• Kami membutuhkanBerikutnya blok berisi nilai-nilai ini untuk blok sebelumnya. Terserah pengusul blok berikutnya untuk menemukan perantara untuk membangun nilai-nilai ini dan jika diperlukan untuk memverifikasinya.
• Kami mengabadikan kelas terpisah dari protokol perantara dan menambahkan insentif dalam protokol untuk mereka
• Kami menyerahkannya kepada aktor altruistik dalam jaringan untuk mempublikasikan nilai-nilai ini (sehingga mereka tidak di-hash ke dalam blok). Attesters hanya membuktikan setelah mereka melihat nilai yang benar disediakan.

Bagaimanapun, kebutuhan simultan untuk meminimalkan kekuatan dan informasi yang tersedia untuk pembangun, dan beban yang dikenakan pada pengusul, tampaknya dengan jelas menunjukkan perlunya aktor ketiga dalam pipa produksi blok (kecuali kita menggigit peluru dan menerimanya). bahwa pembangun memiliki hak untuk melihat daftar penyertaan, dan karenanya mendiskriminasikan transaksi tertentu yang dimasukkan ke dalam slot yang sama). Kita harus mulai berpikir lebih dalam tentang bagaimana tepatnya hal ini akan ditangani.