Permainan antara Konsensus Ethereum saat ini dengan MEV dimulai pada hari transisi dari PoW ke PoS...

Ditulis oleh: Tia, Techub News

Proses penyelesaian masalah MEV sebenarnya melibatkan penyusunan ulang aturan alokasi Blok. Mengenai MEV, saya yakin semua orang sudah tidak asing lagi, tetapi jika ingin tahu tentang apa yang dibicarakan proposal pengaturan MEV pada Ethereum, mungkin masih memerlukan beberapa tambahan data latar belakang, oleh karena itu, artikel ini merangkum serangkaian proposal pengaturan MEV setelah Ethereum beralih ke PoS seperti PBS, ePBS, PEPC, dengan harapan dapat memberikan beberapa informasi latar belakang.

PBS（Proposer Builder Seperatioin）

Sebelum penggabungan ETH, cara untuk menyelesaikan MEV adalah dengan menggunakan MEV-Geth yang dikembangkan oleh Flashbots, MEV-Geth adalah versi modifikasi dari klien go-ethereum. Konsep intinya adalah agar para penambang fokus pada tugas utama mereka yaitu penambangan, dan bukan terlibat dalam persaingan MEV, sehingga menghindari kemungkinan terjadinya reorganisasi yang dapat terjadi. Mekanisme MEV-Geth sangat sederhana, yaitu solusi yang berbasis pasar di mana penambang dapat memilih untuk memasukkan bundle berdasarkan keuntungan yang diajukan oleh pencari. Melalui mekanisme pasar yang cerdik ini, semua pihak mendapatkan keuntungan sambil membentuk keterikatan tertentu. Meskipun pencari harus membagi sebagian keuntungannya dengan penambang, ini memberikan jaminan keamanan terhadap pencurian oleh penambang. Ketika pencari menjadi sumber utama keuntungan yang terkunci, penambang juga akan secara pasif menggunakan MEV-Geth dan terikat oleh mekanisme MEV-Geth. MEV-Geth akan menjaga Allowlist penambang, hanya penambang yang terdaftar dalam Allowlist yang dapat menerima bundle dari pencari. Dengan membatasi reputasi penambang, yaitu dengan mengeluarkan penambang yang mencuri keuntungan dari Allowlist, dapat mencegah penambang merampas keuntungan MEV dari pencari.

Namun setelah penggabungan, karena cara pembuatan Blok berubah menjadi proposer dipilih secara acak dari validator untuk mengusulkan Blok, maka cara pembatasan reputasi untuk mencegah proposer merebut MEV menjadi tidak dapat dilakukan.

Solusi yang mungkin adalah membuat Blok tidak terlihat oleh validator. Melanjutkan ide ini, langkah selanjutnya adalah PBS (Proposer Builder Seperatioin, pemisahan pembangun proposer). PBS akan membagi tugas validator sebagai pembangun dan pengusul Blok, dengan memberikan tugas kompleks dalam pembangunan kepada pembangun. Dengan demikian, pekerjaan proposer menjadi lebih sederhana, hanya perlu memilih dan mengusulkan Blok berdasarkan keuntungan yang diajukan oleh pembangun.

Pada awalnya, ETH Blok ingin menyisipkan PBS ke dalam protokol saat merge, tetapi karena kompleksitas potensial, proses ini ditunda, sehingga memberikan kesempatan bagi MEV-Boost untuk terlibat dalam PBS. Saat ini, PBS diimplementasikan melalui MEV-Boost yang dikembangkan oleh Flashbots. Selain builder dan proposer, ada peran penting lainnya - relay. Builder tidak langsung mengirimkan Blok ke proposer, tetapi melalui peran ketiga yaitu relay.

Karena masih perlu menyelesaikan beberapa masalah lain, seperti bagaimana memastikan bahwa builder pasti akan membayar biaya kepada proposer, dan pasti akan mengungkapkan konten Blok kepada proposer pada akhirnya untuk menghindari slashing proposer karena mengirimkan Blok kosong; misalnya, bagaimana memastikan bahwa Blok yang diajukan oleh builder pasti akan dimasukkan ke dalam beacon chain, dll. Masalah-masalah yang melindungi kepentingan builder dan proposer ini utamanya diimplementasikan melalui relay.

builder akan mengirim Blok ke relay, kemudian relay akan mengurutkan Blok berdasarkan keuntungan yang bisa didapatkan oleh setiap Blok, lalu mengirimkan kepala Blok dengan keuntungan tertinggi ke proposer, untuk memastikan proposer tidak dapat melihat isi Blok. Setelah proposer berkomitmen terhadap proposal Blok (membuat tanda tangan pada kepala Blok tersebut), relay baru akan mengungkapkan Blok yang lengkap kepada proposer. Pembayaran biaya yang dilakukan oleh builder kepada proposer juga harus melalui relay untuk memastikan penyelesaiannya. Transaksi pembayaran kepada proposer tersebut akan dimasukkan dalam Blok yang dikirim, tetapi karena proposer tidak dapat melihat isi Blok, relay masih perlu melakukan konfirmasi sebelumnya.

Di dalam protokol & di luar protokol

Untuk dapat berpartisipasi dalam pasar yang dibangun oleh MEV-Boost, validator perlu menjalankan klien Konsensus ETH dan menjalankan program MEV-Boost pihak ketiga yang bukan ETH secara bersamaan. ** Ini adalah keajaiban dari PBS yang saat ini berjalan, yang memungkinkan pihak ketiga di luar protokol untuk berpartisipasi dalam desain aturan yang dibentuk oleh Konsensus ETH. ** Dari sudut pandang kepemilikan, ini sangat mengejutkan.

Ini juga memicu pemikiran tentang ‘kepercayaan’ mekanisme protokol, bagaimana kepercayaan diperkuat dan bagaimana juga dapat terkikis melalui mekanisme lain. MEV-Boost adalah contoh yang bagus, karena mungkin ada protokol eksternal yang akan mengubah mekanisme yang ada. Ketika protokol sendiri mulai mengalami keterlambatan, perubahan semacam ini mungkin muncul dari luar, dan perkembangan mekanisme eksternal pasti sesuai dengan kebutuhan pasar saat ini, tetapi apakah mekanisme eksternal dapat dipercaya, apakah telah dirancang dengan ketat untuk mencegah kemungkinan masalah, bahkan mekanisme eksternal dapat merusak protokol, semua ini masih belum diketahui.

Relay Terdesentralisasi

Salah satu hal yang paling dikritik dari MEV-Boost adalah keberadaan pasar relay yang terdesentralisasi. Namun, pengaturan ini memperkenalkan masalah kepercayaan. Builder harus percaya bahwa relay tidak akan mencuri MEV mereka. Proposer juga harus percaya bahwa header Blok yang mereka terima dan tandatangani dari relay adalah valid. Namun, meskipun berperan sangat penting, Relay tidak memiliki insentif ekonomi apa pun, dan menjalankan relay juga membutuhkan biaya yang tidak sedikit. Tahun lalu, ada 11 relay yang mendukung jaringan Ethereum, namun sekarang hanya ada 9 relay yang masih menyediakan layanan.

Perlu diperhatikan bahwa relay bukanlah tanpa akses, seperti Eden yang hanya merelay builder-nya sendiri. Beberapa relay seperti bloXroute mengklaim akan menyaring transaksi terkait serangan race condition dan sandwich. Secara beberapa aspek, relay juga memiliki hak untuk membuat aturan.

Data berasal dari Rated Network

Selain itu, dari perspektif Liveness, keberadaan relay membuat builder dan proposer tidak dapat memberikan konfirmasi tingkat atomik. Misalnya ketika proposer menandatangani commitment pada header blok, dan builder juga menyediakan konten payload, tetapi karena kesalahan relay (baik itu disengaja maupun tidak disengaja), konten tersebut tidak dapat disampaikan tepat waktu, yang akan menyebabkan builder dan proposer menanggung kerugian.

ePBS: Mengepak PBS ke dalam Ethereum

Baik itu untuk memecahkan masalah desentralisasi relay, atau untuk memindahkan bagian di luar protokol ke dalam protokol, sepertinya menyematkan PBS ke dalam ePBS di Ethereum menjadi pilihan yang wajib. Saat ini, ePBS bukan lagi proposal yang dibahas, editor EIP Ethereum telah menetapkan nomor untuknya - EIP-7732.

ePBS menyediakan infrastruktur yang tidak perlu dipercaya untuk proposer dan builder dalam menyelesaikan pengadaan hak Blok. Peran builder yang sebelumnya diluar protokol, sekarang telah dimasukkan ke dalam protokol, yaitu sebagai builder dalam validator yang juga perlu melakukan stake di Ethereum. Karena pemisahan tugas proposer dalam lapisan Konsensus, diperlukan perubahan pada lapisan Konsensus untuk menyelesaikan ePBS. Builder bertanggung jawab dalam membangun payload ution (daftar akhir transaksi yang akan dieksekusi dalam Blok). Proposer bertugas mengusulkan Blok bendera sinyal. Prosesnya sebagai berikut:

1. Setelah mengetahui dipilih sebagai Proposer, buat dan siarkan Daftar Inklusi (IL, yaitu transaksi yang harus disertakan dalam slot tersebut).
2. builder mengirimkan Blokhash yang menyertakan payload eksekusi dan janji pembayaran kepada proposer SignedutionPayloadHeader ke proposer (payload eksekusi harus memenuhi IL)
3. proposer memilih satu dari ‘SignedutionPayloadHeader’ yang dikirim dari builders dan memasukkannya (biasanya memilih yang memiliki harga tertinggi yang dibayarkan ke proposer). Dan menyiaran ‘SignedBeaconBlock’ blok tanda tangan yang diusulkan.
4. Pemegang saksi melaksanakan tugas saksi
5. agregator mengirimkan agregat atasannya; sementara itu, builder menyiarkan muatan ution
6. Komite Keteraturan Payload (PTC, dalam setiap slot, 512 validator akan dipilih sebagai anggota PTC) memeriksa apakah builder mengungkapkan payload ution tepat waktu dan menyiarkan hasilnya.

ePBS mengalami beberapa kali diskusi sejak diajukan hingga akhirnya mendapatkan nomor EIP. Awalnya, PBS diajukan oleh Vitalik pada Juni 2021, 4 bulan kemudian disempurnakan dengan skema Two-slot, dan setelah 3 bulan lagi, Single-slot PBS diperkenalkan, baru pada Juli 2023, ide PTC secara resmi diajukan.

PEPC（Protocol-Enforced Proposer Commitments）

Tentu saja, ada juga yang tidak setuju dengan ePBS dan ingin menggantinya dengan solusi lain. Itulah mengapa ada PEPC. ePBS menyematkan aturan yang ditentukan ke dalam protokol, tetapi di PEPC, proposer menjual hak membangun Blok yang dapat diprogram.

PEPC diajukan oleh barnabe pada bulan Oktober 2022. barnabe percaya bahwa untuk mengimplementasikan mekanisme PBS ke dalam protokol, perlu dipertimbangkan implementasi mekanisme umum untuk pengiriman sinyal tepercaya, bukan implementasi mekanisme sinyal tepercaya tertentu (misalnya, jika saya membangun Blok, saya akan mengembalikan xx ETH kepada Anda).

Sama seperti namanya, PEPC (Protocol-Enforced Proposer Commitments), beberapa mekanisme yang memastikan hak builder dan proposer dilakukan melalui komitmen yang diajukan oleh proposer di dalam protokol. Komitmen ini dapat diverifikasi on-chain dan diimplementasikan oleh Kode Operasi ‘BEACONROOT’. Ini adalah mekanisme yang lebih umum di mana komitmen dapat berupa outsourcing seluruh hak membangun Blok atau outsourcing sebagian saja, yaitu hak membangun Blok yang dapat diprogramkan yang dijual oleh proposer.

Kesimpulan

Di atas adalah penjelasan singkat tentang PBS, ePBS, dan PEPC. Dari sudut pandang desain protokol, tidak hanya perlu merancang mekanisme pasar yang mengalokasikan kembali MEV, tetapi juga perlu mempertimbangkan bagaimana membuat validator lebih terdesentralisasi, serta bagaimana meningkatkan resistensi terhadap sensor. Selain itu, desain protokol juga melibatkan banyak pengorbanan. Mengambil contoh ePBS yang sudah mendapatkan nomor EIP, meskipun desain ePBS memecahkan masalah relay terpusat, apakah benar-benar hanya memiliki dampak negatif sebagai peran kunci pihak ketiga di luar protokol? Dari segi mekanisme pembayaran bagi builder, penggunaan relay justru lebih unggul daripada mekanisme ePBS, karena ePBS menggunakan mekanisme pembayaran di muka. Jika builder mengemas suatu Blok dengan keuntungan yang sangat tinggi, maka dalam mekanisme pembayaran di muka, builder tidak dapat memberikan imbalan yang tinggi kepada proposer.