Protokol Ethereum dan ekosistem yang lebih luas terus berupaya untuk meningkatkan nilai yang dapat diberikan oleh Ethereum. Engsel utama dalam ekosistem untuk meningkatkan Ethereum telah menjadi Nilai yang Dapat Diekstrak Maksimal (MEV)MEV). MEV mengacu pada nilai maksimum yang dapat diekstraksi oleh agen protokol yang bertanggung jawab untuk menyertakan, mengurutkan, dan mengecualikan transaksi dalam sebuah blok dari sistem. Pos ini merangkum metode yang diusulkan untuk mengurangi efek negatif MEV pada aplikasi dan protokol serta menyelidiki arah penelitian di masa depan.
Pos ini disusun sebagai berikut:
Bagian pertama mengusulkan kategorisasi 2 dimensi dari teknik mitigasi MEV di luar protokol. Contoh dari setiap kategori dieksplorasi.
Bagian setelah itu menjelaskan mengapa protokol Ethereum tidak dapat berfungsi sebagai infrastruktur yang mencegah atau mengembalikan MEV.
Ketiga, kami menjelajahi apa yang dilakukan protokol Ethereum untuk mencegah eksternalitas negatif dari MEV.
Akhirnya, kami berpendapat bahwa tidak satupun teknik mitigasi MEV yang dibahas, baik dalam protokol maupun di luar protokol, dapat menyelesaikan semua masalah yang disebabkan oleh MEV secara bersamaan.
Awal dari postingan ini bertindak sebagai sistematisasi pengetahuan mitigasi MEV yang parsial. Namun, bagian keempat menyajikan argumen yang relatif baru bahwa mitigasi MEV di luar protokol tidak memecahkan masalah MEV dalam protokol. Argumen ini didasarkan pada kertasolehDavide Crapisdan saya.
Pos ini mengacu pada teknik mitigasi dalam dan luar protokol. Dengan teknik mitigasi MEV dalam protokol, kami maksud mekanisme yang merupakan bagian dari aturan protokol Ethereum atau yang akan memerlukan perubahan aturan protokol Ethereum. Teknik mitigasi di luar protokol adalah semua mekanisme yang tidak ada dalam protokol.
MEV memberlakukan sewa kepada pengguna yang berinteraksi dengan blockchain. Untuk meningkatkan nilai yang difasilitasi oleh Ethereum, adalah intuitif untuk mengurangi sewa yang MEV wakili. Mandat teknik mitigasi MEV di luar protokol adalah untuk mengurangi efek penghambat nilai yang MEV timbulkan tanpa mengubah aturan protokol Ethereum.
Kami akan menggunakan bagaimana MEV diekstrak pada Automated Market Makers (AMM) dan, sebagai akibatnya, bagaimana hal itu dapat dikurangi sebagai contoh. Banyak AMM bekerja sebagai berikut:
Penyedia likuiditas (LP) menyediakan beberapa token berbeda ke AMM dan membiarkan AMM menetapkan harga terhadapnya yang digunakan pengguna untuk bertransaksi dengan token LP.
Sebuah AMM menyesuaikan harga hanya sebagai respons terhadap transaksi yang disertakan dalam blok baru. Penyesuaian diskrit ini berbeda dengan fluktuasi harga kontinu dari token yang mendasar di pasar eksternal.
Ketika blok perlu diajukan, produsen blok dapat menyertakan transaksi yang menggunakan harga pasar eksternal yang dapat diamati secara publik untuk arbitrase penawaran yang kadaluwarsa pada AMM, dengan demikian mengekstraksi MEV.
Bentuk MEV ini dikenal sebagai Loss-Versus-Rebalancing (LVR), adalah biaya bagi penyedia likuiditas. Dengan menjaga biaya yang diperoleh oleh penyedia likuiditas tetap konstan, jumlah likuiditas yang disediakan akan berkurang dengan jumlah LVR yang diekstrak dari AMM. Likuiditas yang lebih sedikit berarti perdagangan pengguna memiliki dampak harga yang lebih tinggi, yang berarti lebih mahal bagi pengguna untuk berdagang di AMM. Tujuan dari desain AMM adalah untuk mengurangi biaya yang dikenakan LVR pada AMM. Demikian pula, tujuan dari desain aplikasi, secara umum, adalah untuk mengurangi biaya MEV pada pengguna.
Ada banyak cara di mana biaya MEV dapat dikurangi. Secara kasar, teknik mitigasi MEV di luar protokol dibagi menjadi dua sumbu:
Sumbu pertama adalah apakah suatu aplikasi mengurangi MEV sendiri atau mengandalkan infrastruktur bersama. Sumbu kedua lebih rumit. Sebuah aplikasi bisa dirancang untuk mencegah paparan MEV pada awalnya, atau bisa menjual hak untuk mengekstrak MEV dan mengembalikan pendapatan penjualan kepada yang diekstrak. Mengembalikan MEV sedikit salah menggunakan definisi MEV, yang merupakan nilai yang bisa diekstrak oleh aktor yang bertanggung jawab atas inklusi, pengurutan, dan pengecualian transaksi dari sistem. MEV yang dikembalikan tidak diekstrak dari sistem dan dengan demikian tidak sepenuhnya sesuai dengan definisi MEV. Namun, menggunakan istilah MEV mungkin membantu karena semua konsep yang terkait dengan MEV berlaku untuk nilai yang dikembalikan, kecuali dari mana pendapatan tersebut pergi. Kami akan melihat contoh dari keempat kemungkinan tersebut dan membahas keuntungan relatif mereka.
Gambar 1: Kategorisasi 2 dimensi teknik mitigasi MEV di luar protokol dengan contoh untuk setiap kategori.
Aplikasi-Spesifik dan Mencegah MEV: Fungsi Maksimalkan AMM.
Teknik mitigasi MEV yang biasanya paling intuitif secara konseptual bagi mereka yang pertama kali mendengar tentang MEV adalah aplikasi yang mencegah paparan MEV. Contoh menariknya adalah fungsi memaksimalkan AMMdiproposikan olehAndrea CanidiodanRobin Fritsch. Ini memadatkan perdagangan yang dikumpulkan selama periode waktu tertentu dan mengeksekusinya semua dengan harga clearing yang seragam. Penulis menunjukkan bahwa hal ini menghilangkan LVR dan sandwiching, bentuk MEV lainnya. Intuisinya adalah bahwa semua peserta berdagang pada harga marjinal dari kolam renang setelah batch dan bahwa arbitraseur diincentivasi untuk berdagang sampai titik di mana harga ini sama dengan harga pasar eksternal. Sistem ini mirip dengan lelang batch yang sering diusulkan oleh gate.io.Budish, Cramton, dan Shim (2015)dalam literatur keuangan tradisional. Sebagai tambahan, ini adalah contoh yang sangat baik dari sinergi antara keuangan terdesentralisasi dan tradisional. Ide-ide keuangan tradisional dapat diimplementasikan dalam keuangan terdesentralisasi; pembelajaran dari implementasidapat digunakan untuk memberi tahu keuangan tradisional.
MEV Khusus Aplikasi dan Rabat : MEV menangkap AMM.
The Menangkap MEV AMM (McAMM)adalah contoh mitigasi MEV yang spesifik aplikasi yang mengandalkan pengembalian. McAMM melelang hak untuk menjadi pedagang pertama yang berinteraksi dengan AMM dalam satu blok, sehingga memungkinkan pedagang ini untuk mengambil arbitrase yang mungkin. Hasil lelang kemudian didistribusikan di antara penyedia likuiditas yang diarbitrasi. Jika lelang efisien, hasilnya harus sama dengan nilai arbitrase yang diekstraksi dari penyedia likuiditas. Desain ini bisa menyebabkan penghapusan LVR yang sama seperti fungsi AMM yang memaksimalkan yang dibahas di atas, meskipun pendekatan ini sangat berbeda. Apakah hal ini akan terjadi dalam praktek sangat bergantung pada implementasi lelang yang spesifik.
Infrastruktur dan Pengembalian MEV: MEV-Share.
Pemberian diskon tidak harus spesifik untuk suatu aplikasi. Flashbots, sebuah perusahaan yang beroperasi di ruang konstruksi blok, telah mengembangkan MEV-Bagikan. Ini memungkinkan pengguna memilih data transaksi mana yang akan dibagikan secara pribadi dalam pelelangan. Penawar menawar untuk mendapatkan hak menempatkan transaksi ini dalam satu paket dan dengan demikian mengambil MEV darinya. Pengguna dapat menerima hasil lelang. Infrastruktur ini tidak spesifik untuk aplikasi tertentu, karena transaksi dapat berinteraksi dengan aplikasi apa pun.
Infrastruktur dan Pencegahan MEV: Aliran Pesanan yang Dilindungi di Dunia yang Mencari Keuntungan.
Akhirnya, ada mekanisme infrastruktur yang bertujuan untuk mencegah ekstraksi MEV. Sebagai contoh adalah Aliran Pesanan yang Dilindungi di Dunia yang Mencari Keuntungan (PROF).PROF mengandalkan produsen blok dalam Lingkungan Eksekusi Terpercaya (TEE) yang meyakinkan untuk mengikat aturan, misalnya, first-come, first-serve. TEE memiliki dua sifat penting yang membuat komitmen ini meyakinkan, yaitu:
Setiap pengguna yang mengirim transaksinya ke produsen blok yang berkomitmen untuk menjalankan aturan pengurutan tahu bahwa produsen blok di TEE akan melakukannya. Oleh karena itu, PROF dapat mencegah jenis ekstraksi MEV tertentu, seperti front-running untuk aplikasi apa pun, tanpa mengubah aturan protokol Ethereum.
Teknik mitigasi MEV yang berbeda memiliki kelebihan dan kekurangan yang berbeda. Teknik pencegahan MEV khusus aplikasi sulit ditemukan karena membutuhkan banyak penelitian dan implementasi per aplikasi. Di sisi lain, pencegahan MEV infrastruktural membutuhkan banyak biaya. Misalnya, beberapa teknik pencegahan MEV infrastruktur memerlukan penggunaan perangkat keras yang mahal dan banyak pengembangan bisnis. Apakah pengembalian efektif tergantung pada apakah lelang bersifat kompetitif, yang bergantung pada detail lelang seperti formatnya dan kapan dilaksanakan.
Keempat teknik mitigasi MEV ini mungkin tidak sepenuhnya saling melengkapi atau sepenuhnya eksklusif. Perlu diperhatikan juga bahwa dimensi-dimensinya menyerupai spektrum dan bukan biner, seperti yang ditunjukkan pada Gambar 1. Sebagai contoh, beberapa teknik mitigasi MEV mungkin lebih bersifat infrastruktur daripada yang lainnya. Bidang ini bergerak sangat cepat, yang membuat setiap kategorisasi menjadi sulit. Akhirnya, ruangannya terasa optimis, dan banyak yang mungkin berbagi pendapat bahwa MEV sebagai persentase nilai total yang difasilitasi.akan menyusut dengan cepat.
Teknik mitigasi MEV ini mungkin terlihat tidak memuaskan bagi beberapa orang. Mengapa Ethereum tidak dapat menjadi infrastruktur protokol yang secara menyeluruh memecahkan MEV? Mungkin beberapa pembaca akan menyarankan untuk menggunakan aturan pengurutan tertentu. Proposal untuk menegakkan aturan pengurutan tertentu di Ethereum, seperti first-come-first-serve, belum mendapatkan dukungan luas. Saya percaya ada dua alasan mendasar mengapa protokol ini tidak dapat secara holistik memecahkan beban MEV yang diletakkan pada pengguna akhir dan aplikasi - keduanya terkait dengan batasan netralitas kredibel Ethereum.
Pertama, Ethereum tidak dapat memperoleh urutan global transitive yang memuaskan 'keadilan'. Ethereum menjadi tuan rumah bagi berbagai aplikasi yang masing-masing mungkin mendapatkan manfaat dari aturan urutan yang berbeda. Sementara urutan pertama datang, pertama dilayani mungkin membantu beberapa aplikasi, itu mungkin menghambat pertumbuhan orang lain. Oleh karena itu, sulit bagi ekosistem untuk sepakat tentang apa yang adil. Selain itu, bahkan jika ekosistem sepakat pada satu aturan pemesanan yang adil, sulit untuk mendapatkan aturan pemesanan transitatif global karena transaksi dapat tiba di node yang berbeda pada waktu yang berbeda.
Ketidaksesuaian ini menyebabkan masalah dalam protokol pemesanan first-come, first-serve. Secara khusus, meskipun urutan di mana setiap simpul individual menerima transaksi adalah transitif, itu tidak berarti bahwa urutan agregat juga transitif. Aturan pemesanan first-come, first-serve dapat terjebak dalam siklus untuk mengembalikan transitivitas, dan terkadang, siklus ini harus diselesaikan dengan aturan sembarang, seperti memilih urutan total secara alfabetis. Ini dapat berarti bahwa transaksi untuk yang urutannya sangat penting, seperti transaksi arbitrase yang sensitif terhadap waktu, tidak diurutkan dengan cara ini tetapi secara sembarang.
Gambar 2: Slide yang menunjukkan siklus Condorcet aturan pemesanan first-come, first-serve mungkin macet. Slide diambil dari presentasi tentang Themis oleh Mahimna Kelkar.
Selain fakta bahwa aturan pemesanan first-come, first-serve memiliki masalah teoritis, tidak jelasapakah mereka diinginkandi tempat pertama. Aturan pemesanan ini menguntungkan mereka dengan koneksi lebih cepat. Jika koneksi cepat cukup berharga, hal ini bisa menyebabkan perlombaan laten, seperti yang terlihat di keuangan tradisionaldengan investasi besar dalam teknologi kecepatan. Teknologi kecepatan bisa merusak netralitas yang kredibel dalam blockchain karena mendorong adanya sentralisasi geografis.
Pandangan yang tidak konsisten tentang kapan transaksi tiba menyebabkan masalah untuk aturan pemesanan siapa cepat dia dapat, dan untuk setiap aturan pemesanan. Aturan pemesanan biasanya bertujuan untuk mencapai beberapa properti ekonomi. Misalnya, pemesanan gas prioritas berusaha untuk memasukkan transaksi-transaksi tersebut dalam urutan berapa banyak nilainya dimasukkan terlebih dahulu. Biasanya, desiderata ekonomi ini terpenuhi hanya jika ada pandangan global tentang transaksi mana yang harus dipesan. Karena sulit untuk mendapatkan pandangan global transitif dari pandangan lokal transitif, sulit untuk mendapatkan pandangan global seperti itu. Dengan kata lain, beberapa validator akan berpikir transaksi harus dipesan dalam satu slot, dan yang lain berpikir itu harus di slot lain, menurunkan properti ekonomi yang dapat diharapkan ekosistem untuk menerima dari aturan pemesanan tetap.
Kedua, protokol konsensus tidak menyadari permainan MEV yang dimainkan pada lapisan eksekusi. Hal ini akan membuat sulit untuk merancang skema rebate dalam protokol karena protokol saat ini tidak akan memahami nilai MEV dan kepada siapa seharusnya direbater. Terakhir, protokol harus tetap netral secara kredibel. Protokol tidak boleh berada dalam posisi di mana harus membuat pilihan yang didasarkan pada opini tentang kepada siapa seharusnya direbater MEV, bahkan jika bisa, juga tidak boleh memilih teknik pencegahan MEV yang mendukung aplikasi tertentu dibandingkan dengan yang lain.
Sebuah contoh menarik yang mendekati teknik rebate MEV dalam protokol adalah Pajak MEV, diusulkan oleh Dan RobinsondanDave White. Ini memungkinkan aplikasi apa pun untuk membebani biaya prioritas dalam protokol dengan mengatur parameter, katakanlah $k$. Setiap pengguna yang berinteraksi dengan aplikasi tersebut harus membayar biaya prioritas sebesar $k$ kali lebih besar dari biaya prioritas yang dibayarkannya kepada validator konsensus untuk aplikasi tersebut. Anda dapat melihat bagaimana sistem ini dapat mengembalikan hasil MEV ke aplikasi secara umum. Misalnya, jika ada 10 ETH dari MEV yang akan diekstraksi dari aplikasi, dengan $k = 9$, dengan menjadi yang pertama berinteraksi dengannya, pengguna dapat membayar biaya prioritas sebesar 1 ETH kepada validator dan 9 ETH kepada aplikasi, dengan asumsi bahwa transaksi diurutkan berdasarkan biaya prioritas.
Pajak MEV adalah arah yang menjanjikan, tetapi seperti yang dinyatakan oleh penulisnya, itu harus dieksplorasi lebih lanjut untuk memahami bagaimana cara kerjanya di Ethereum. Salah satu aspek yang menantang mungkin adalah bahwa pajak MEV menganggap biaya prioritas adalah sinyal universal untuk jumlah MEV. Meskipun ini mungkin benar jika pesanan prioritas diberlakukan, pemesanan itu sendiri dapat menurunkan jumlah total MEV, mirip dengan bagaimana lelang harga pertama multi-unit mungkin memiliki pendapatan yang lebih rendah daripada lelang kombinatorial. Flashbots' SUAVESepertinya sedang menuju ke arah yang berlawanan, yang memungkinkan preferensi yang lebih ekspresif. SUAVE saat ini belum aktif tetapi bertujuan untuk membangun pembangun blok terdesentralisasi yang menggabungkan bundel secara optimal tanpa aturan pengurutan tertentu.
Biaya prioritas mungkin tidak mencerminkan MEV dengan baik ketika pencari ingin mengekspresikan preferensi mereka untuk dimasukkan secara lebih kompleks daripada biaya prioritas satu dimensi. Mungkin pencari ingin dimasukkan ke dalam blok sebelum paket pencari pesaing lainnya tetapi tidak peduli tentang posisi absolut di dalam blok. Menggunakan biaya prioritas berarti pencari bersaing untuk posisi dengan semua pengguna, terlepas dari relevansinya dengan pencari ini.
Ada cara lain untuk mengurangi MEV yang diekstraksi dari pengguna selain aturan pemesanan. Salah satu arah penelitian adalah Mempools terenkripsi. Ini berarti bahwa pengguna menyiarkan transaksi dalam bentuk terenkripsi. Hanya setelah inklusi transaksi didekripsi. Produsen blok, dengan demikian, tidak mengetahui konten transaksi, sehingga tidak mungkin melakukan transaksi front-run berdasarkan data yang sekarang terlindungi.
Mempools yang dienkripsi sudah aktif di Gnosis Chain, sebuah blockchain yang memiliki arsitektur serupa dengan Ethereum. Para peserta ekosistem, terutama Jaringan Shutter, bertujuan untuk membawa mempool terenkripsi ke Ethereum mainnet. Beberapa faktor pembatas saat ini adalah asumsi kepercayaan yang diperlukan dengan teknik kriptografi berbasis enkripsi ambang batas,keadaan Fungsi Penundaan yang Dapat Diverifikasi, dan masalah ketersediaan data gratisterkait dengan mempool terenkripsi.
Secara ringkas, Ethereum tidak dapat menjadi infrastruktur yang mencegah MEV karena ekosistem belum dapat sepakat pada aturan pemesanan yang adil dan sulit untuk mencapai pemesanan global transitive yang memuaskan aturan apa pun. Beberapa proposal untuk aturan pemesanan, seperti contoh pajak MEV yang diberikan di atas dan peningkatan protokol, telah dibahas yang dapat memfasilitasi pemesanan global transitive yang memenuhi kriteria "keadilan". Namun, saat ini tidak ada konsensus kasar tentang apakah hal ini diinginkan. Ethereum tidak dapat menjadi infrastruktur yang memberikan rebate MEV karena lapisan konsensus tidak menyadari apa yang terjadi pada lapisan pelaksanaan dan Ethereum tidak dapat memilih di antara aplikasi karena harus tetap netral.
Paragraf sebelumnya menampilkan betapa sulitnya bagi protokol untuk menghilangkan beban MEV yang ditempatkan pada pengguna. Namun, banyak mekanisme protokol menangani MEV, dan seluruh bagian dari peta jalan Vitalikdalam hal ini. Apa yang dilakukan mekanisme ini?
Mekanisme dalam protokol ini bertujuan untuk memecahkan masalah yang berbeda dari teknik mitigasi yang dibahas sebelumnya. Alih-alih memaksimalkan nilai yang difasilitasi Ethereum dengan meminimalkan MEV yang diekstraksi dari pengguna, mekanisme dalam protokol ini bertujuan untuk memaksimalkan netralitas kredibel Ethereum dengan meminimalkan dampak negatif dari MEV. MEV tidak hanya mengurangi utilitas bagi mereka yang diekstraksi, tetapi juga sangat mengganggu perilaku pengekstrak, misalnya, mendorong sentralisasi melalui ekonomi skala dan menyebabkan ketidakstabilan konsensus.
Kekuatan ekonomi adalah risiko sentralisasi besar untuk konsensus Ethereum dan secara transitif untuk netralitasnya yang kredibel. Jika ada skala ekonomi, agen konsensus kecil dapat diharapkan untuk bergabung dengan agen besar untuk mendapatkan keuntungan. Jika ada pengembalian ke kecanggihan, validator rasional mungkin berperilaku berbeda dari spesifikasi jujur. Skala ekonomi atau kembali ke kecanggihan untuk agen konsensus adalah eksternalitas negatif MEV.
Protokol bertujuan untuk mencegah eksternalitas negatif dengan memisahkan peran agen konsensus dalam Ethereum dan memisahkan mereka satu sama lain. Saat ini, Ethereum menugaskan semua peran berikut kepada satu agen, tetapi pada prinsipnya, ini adalah peran yang terpisah. Tiga peran yang telah diidentifikasi sejauh ini adalah sebagai berikut:
Ekosistem Ethereum bertujuan untuk mengisolasi ketiga peran ini sehingga insentif yang berasal dari satu peran tidak mempengaruhi insentif mereka yang memenuhi peran lain. Beberapa peran, seperti pemesanan transaksi, dapat lebih terpusat selama validasi blok tidak dapat dipercaya dan sangat terdesentralisasi, dan serangkaian peserta yang terdesentralisasi dapat memastikan resistensi sensor, seperti yang dinyatakan Vitalik dalam bukunya yang berpengaruh Postingan akhir permainan.
Pemisahan Penyusun-Pembangun (PBS)bertujuan untuk memisahkan peran mengusulkan dan membangun payload eksekusi. Ini adalah filosofi desain yang mengakui peran yang berbeda dan memfasilitasi pelepasan tugas membangun blok proposer ke pihak khusus. MEV-Boost adalah instansi di luar protokol saat ini dari PBS. Ini memungkinkan semua proposer, terlepas dari kecanggihannya, mengakses pasar MEV yang sama. Secara konkret, ini memastikan bahwa builder menerima hak untuk membangun blok dan bahwa proposer menerima pembayaran mereka atas penjualan hak ini. Dengan MEV-Boost, proposer tidak mendapatkan keuntungan lebih dengan berinvestasi dalam teknik ekstraksi MEV yang canggih tetapi dapat tetap relatif tidak canggih dalam area ini dan menikmati imbalan yang sama dengan proposer yang lebih canggih.
Pemisahan Attester-Proposer (APS) secara konseptual mirip dengan PBS. Ini juga mengakui perbedaan antara dua peran: membuktikan & mengusulkan blok konsensus dan mengusulkan blok eksekusi. APS saat ini sedang dalam tahap penelitian dan tidak ada versi out-of-protocol yang aktif. Pengusul mungkin ingin cepatkarena itu memungkinkan mereka untuk mengirim blok mereka lebih lambat, yang berarti mereka mungkin dapat menyertakan lebih banyak transaksi. Sangat penting bagi protokol konsensus untuk tidak mendorong keterlambatan karena hal ini menyebabkan sentralisasi geografis. APS kadang-kadang dianggap sebagai garis terakhir pertahanan untuk protokol Ethereum.
PBS dan APS menunjukkan bagaimana tiga peran ini dapat diisolasi. Namun, menerapkan dua upgrade protokol ini juga berarti bahwa para peserta yang membuat blok akan sangat terpusat, yang sangat buruk untuk ketahanan sensor. Ethereum bertujuan untuk mengatasi masalah ini dengan membangun katup satu arah antara peran-peran ini. Protokol dapat membebani peran memberi saksi kepada blok dengan memberi saksi kepada transaksi yang tertunda di mempool. Sebuah komite saksi kemudian bertanggung jawab untuk membuat daftar transaksi yang harus disertakan oleh produsen blok, atau blok mereka akan diabaikan oleh para saksi. Jenis mekanisme ini disebutdaftar inklusi.
Klep-klep ini menantang pemisahan peran. Itu adalah sangat sulit untuk merancangkatup yang secara signifikan menggunakan sifat-sifat satu set peserta, misalnya, membatasi satu set peserta lainnya, sambil juga memastikan bahwa peserta di ujung katup lainnya tidak mempengaruhi peserta yang mempengaruhi mereka. Sebagai contoh, kumpulan pemeriksa terdesentralisasi akan bertanggung jawab untuk membuat daftar inklusi. Kami tidak ingin produsen blok atau insentif sentralisasi terkait produksi blok mempengaruhi pemeriksa.
Gambar 3: Pembagian kerja oleh Attester-Proposer Separation (APS) dan Proposer-Builder Separation (PBS) dengan daftar inklusi dan hak bangunan yang dijual sebagai katup satu arah antara peran.
Tujuan utama dari mekanisme MEV dalam protokol secara fundamental berbeda dari teknik mitigasi MEV aplikasi dan infrastruktur. Teknik mitigasi di luar protokol umumnya bertujuan untuk mengurangi MEV per unit nilai yang difasilitasi. Sebaliknya, teknik mitigasi dalam protokol bertujuan untuk mencegah eksternalitas negatif MEV yang mengkonsolidasikan agen konsensus Ethereum. Teknik mitigasi MEV tertentu dapat berkontribusi pada kedua tujuan tersebut. MEV-Boost, sebagai contoh, secara teknis berada di luar protokol, namun tujuan utamanya adalah mencegah eksternalitas negatif MEV.
Selain itu, batasan dalam dua masalah tersebut berbeda. Mekanisme in-protocol harus dirancang dengan persyaratan perangkat keras dan protokol netral. Sebaliknya, batasan teknik mitigasi MEV di luar protokol tergantung pada keinginan para desainer aplikasi atau infrastruktur, yang dapat cocok untuk kasus penggunaan tertentu.
Karena masalah-masalah ini memiliki tujuan dan batasan yang berbeda, adalah intuitif bahwa tidak ada solusi tunggal yang dapat menangani keduanya. Selain itu, mungkin ada dikotomi yang lebih mendasar antara kedua masalah tersebut. Bagian ini menguraikan sebuah argumen untuk dikotomi ini, juga disajikan dalam sebuahmakalah oleh Davide Crapis dan saya sendiri.
Para perancang aplikasi ingin mengurangi MEV per unit nilai karena hal tersebut akan menarik lebih banyak pengguna dan dengan demikian meningkatkan total nilai yang difasilitasi oleh aplikasi ini. Jika MEV per unit nilai menurun tetapi total nilai yang difasilitasi meningkat, jumlah total MEV bisa menurun tetapi juga bisa meningkat. Mekanisme MEV dalam protokol peduli pada jumlah total MEV yang agen konsensus dapat ekstraksi. Bahkan jika jumlah total MEV hanya merupakan fraksi yang dapat diabaikan dari nilai yang difasilitasi oleh Ethereum, tidak jelas apakah protokol masih perlu memisahkan peran konsensus yang berbeda yang diperlukan untuk mencegah sentralisasi pada peserta konsensus Ethereum.
Sebagai contoh dari argumen ini, pertimbangkan kasus Loss-Versus-Rebalancing(LVR), diperkenalkan sebelumnya sebagai kerugian arbitrase laten para penyedia likuiditas di AMM karena penawaran mereka di rantai tetap ketinggalan zaman antar blok dibandingkan dengan pasar eksternal yang terus diperbarui. Dalam penelitian mereka, Milionis dkk. menemukan bahwa LVR kumulatif selama slot proporsional dengan waktu slot hingga kekuatan 3/2.
Pada pemeriksaan pertama, hal ini akan menunjukkan bahwa mengurangi waktu slot juga mengurangi MEV. LVR, namun, adalah kerugian arbitrase per unit likuiditas. Selain itu, Joel Hasbrouck, Thomas Rivera, dan Fahad Saleh menunjukkanbahwa posisi LP individu dapat dianggap sebagai aset yang dapat diinvestasikan. Pengembalian yang diharapkan dari aset biasanya didasarkan pada risikonya. Tidak jelas bagaimana risiko dari posisi LP akan berubah saat waktu slot berkurang, tetapi untuk tujuan perdebatan, asumsikan risikonya tetap konstan. Maka, pengembalian dari posisi LP seharusnya tetap konstan terlepas dari waktu slot; oleh karena itu, jika biaya per unit likuiditas berkurang, pendapatan per unit likuiditas juga harus berkurang. Dalam AMM, pendapatan akan berkurang karena likuiditas yang lebih banyak mengalir ke AMM. Likuiditas yang lebih banyak berarti lebih banyak unit likuiditas menghadapi LVR. Oleh karena itu, efek agregatnya ambigu. Jadi, tidak jelas bagaimana total jumlah MEV yang berasal dari LVR akan berubah jika waktu slot berubah, meskipun MEV per unit nilai dapat berkurang.
Selain itu, penurunan LVR akan membuat AMM menjadi tempat yang lebih menarik untuk diperdagangkan karena ada lebih banyak likuiditas, yang berarti bahwa lebih banyak pedagang yang membayar biaya menggunakan AMM, menyebabkan likuiditas yang lebih banyak. Selain itu, pengalaman pengguna mendapat manfaat dari waktu slot yang lebih singkat, dan jumlah total MEV yang berasal dari LVR dapat meningkat dengan waktu slot. Ini merupakan masalah bagi protokol, meskipun pengguna menikmati perdagangan yang lebih efisien.
Tabel 1: Dampak waktu slot terhadap LVR, jumlah likuiditas, dan jumlah total MEV. Tabel ini menunjukkan bagaimana waktu slot memengaruhi LVR per slot dan faktor dengan mana likuiditas dikalikan. Ini mengasumsikan bahwa pendapatan biaya tetap konstan dan biaya kesempatan per slot adalah nol. Hasilnya dinormalisasi dengan nilai yang sesuai dengan waktu slot 12 detik yang digunakan sebagai dasar.
Tabel 1 menunjukkan bahwa jumlah total MEV yang berasal dari LVR mungkin tetap sama meskipun waktu slot berkurang. Nilai-nilai dalam tabel ini dihasilkan dengan mengasumsikan bahwa biaya adalah satu-satunya pendapatan, arbitrase latency adalah satu-satunya biaya bagi penyedia likuiditas, dan biaya kesempatan per-slot tetap konstan pada nol. Asumsi-asumsi ini terlalu sederhana. Oleh karena itu, angka-angka ini mungkin menyajikan batas atas pada likuiditas yang meningkat per slot dan, dengan demikian, pada jumlah total MEV.
Sulit untuk mengatakan bagaimana prediksi ini akan bertahan. Ekosistem tahu sedikit tentang motivasi penyedia likuiditas dan trade-off risiko-imbalan.bahkan lebih sedikit tentang perilaku trader likuiditas. Mungkin LP mempertimbangkan risiko posisi LP dengan cara yang berbeda tergantung pada waktu slot, yang dapat membantu memprediksi apa yang terjadi dengan total jumlah MEV saat waktu slot berkurang.
Potensialnya, contoh ini dapat digeneralisasikan. Teknik mitigasi MEV di luar protokol yang bertujuan untuk meminimalkan MEV per unit nilai secara simultan menginduksi lebih banyak nilai yang mengalir melalui sistem; oleh karena itu, dampak mitigasi MEV terhadap jumlah total MEV menjadi ambigu. Oleh karena itu, saya percaya bahwa Ethereum tidak dapat mengandalkan mitigasi MEV di luar protokol untuk mencegah dampak negatif MEV pada agen konsensus.
Protokol Ethereum dan ekosistem yang lebih luas terus berupaya untuk meningkatkan nilai yang dapat diberikan oleh Ethereum. Engsel utama dalam ekosistem untuk meningkatkan Ethereum telah menjadi Nilai yang Dapat Diekstrak Maksimal (MEV)MEV). MEV mengacu pada nilai maksimum yang dapat diekstraksi oleh agen protokol yang bertanggung jawab untuk menyertakan, mengurutkan, dan mengecualikan transaksi dalam sebuah blok dari sistem. Pos ini merangkum metode yang diusulkan untuk mengurangi efek negatif MEV pada aplikasi dan protokol serta menyelidiki arah penelitian di masa depan.
Pos ini disusun sebagai berikut:
Bagian pertama mengusulkan kategorisasi 2 dimensi dari teknik mitigasi MEV di luar protokol. Contoh dari setiap kategori dieksplorasi.
Bagian setelah itu menjelaskan mengapa protokol Ethereum tidak dapat berfungsi sebagai infrastruktur yang mencegah atau mengembalikan MEV.
Ketiga, kami menjelajahi apa yang dilakukan protokol Ethereum untuk mencegah eksternalitas negatif dari MEV.
Akhirnya, kami berpendapat bahwa tidak satupun teknik mitigasi MEV yang dibahas, baik dalam protokol maupun di luar protokol, dapat menyelesaikan semua masalah yang disebabkan oleh MEV secara bersamaan.
Awal dari postingan ini bertindak sebagai sistematisasi pengetahuan mitigasi MEV yang parsial. Namun, bagian keempat menyajikan argumen yang relatif baru bahwa mitigasi MEV di luar protokol tidak memecahkan masalah MEV dalam protokol. Argumen ini didasarkan pada kertasolehDavide Crapisdan saya.
Pos ini mengacu pada teknik mitigasi dalam dan luar protokol. Dengan teknik mitigasi MEV dalam protokol, kami maksud mekanisme yang merupakan bagian dari aturan protokol Ethereum atau yang akan memerlukan perubahan aturan protokol Ethereum. Teknik mitigasi di luar protokol adalah semua mekanisme yang tidak ada dalam protokol.
MEV memberlakukan sewa kepada pengguna yang berinteraksi dengan blockchain. Untuk meningkatkan nilai yang difasilitasi oleh Ethereum, adalah intuitif untuk mengurangi sewa yang MEV wakili. Mandat teknik mitigasi MEV di luar protokol adalah untuk mengurangi efek penghambat nilai yang MEV timbulkan tanpa mengubah aturan protokol Ethereum.
Kami akan menggunakan bagaimana MEV diekstrak pada Automated Market Makers (AMM) dan, sebagai akibatnya, bagaimana hal itu dapat dikurangi sebagai contoh. Banyak AMM bekerja sebagai berikut:
Penyedia likuiditas (LP) menyediakan beberapa token berbeda ke AMM dan membiarkan AMM menetapkan harga terhadapnya yang digunakan pengguna untuk bertransaksi dengan token LP.
Sebuah AMM menyesuaikan harga hanya sebagai respons terhadap transaksi yang disertakan dalam blok baru. Penyesuaian diskrit ini berbeda dengan fluktuasi harga kontinu dari token yang mendasar di pasar eksternal.
Ketika blok perlu diajukan, produsen blok dapat menyertakan transaksi yang menggunakan harga pasar eksternal yang dapat diamati secara publik untuk arbitrase penawaran yang kadaluwarsa pada AMM, dengan demikian mengekstraksi MEV.
Bentuk MEV ini dikenal sebagai Loss-Versus-Rebalancing (LVR), adalah biaya bagi penyedia likuiditas. Dengan menjaga biaya yang diperoleh oleh penyedia likuiditas tetap konstan, jumlah likuiditas yang disediakan akan berkurang dengan jumlah LVR yang diekstrak dari AMM. Likuiditas yang lebih sedikit berarti perdagangan pengguna memiliki dampak harga yang lebih tinggi, yang berarti lebih mahal bagi pengguna untuk berdagang di AMM. Tujuan dari desain AMM adalah untuk mengurangi biaya yang dikenakan LVR pada AMM. Demikian pula, tujuan dari desain aplikasi, secara umum, adalah untuk mengurangi biaya MEV pada pengguna.
Ada banyak cara di mana biaya MEV dapat dikurangi. Secara kasar, teknik mitigasi MEV di luar protokol dibagi menjadi dua sumbu:
Sumbu pertama adalah apakah suatu aplikasi mengurangi MEV sendiri atau mengandalkan infrastruktur bersama. Sumbu kedua lebih rumit. Sebuah aplikasi bisa dirancang untuk mencegah paparan MEV pada awalnya, atau bisa menjual hak untuk mengekstrak MEV dan mengembalikan pendapatan penjualan kepada yang diekstrak. Mengembalikan MEV sedikit salah menggunakan definisi MEV, yang merupakan nilai yang bisa diekstrak oleh aktor yang bertanggung jawab atas inklusi, pengurutan, dan pengecualian transaksi dari sistem. MEV yang dikembalikan tidak diekstrak dari sistem dan dengan demikian tidak sepenuhnya sesuai dengan definisi MEV. Namun, menggunakan istilah MEV mungkin membantu karena semua konsep yang terkait dengan MEV berlaku untuk nilai yang dikembalikan, kecuali dari mana pendapatan tersebut pergi. Kami akan melihat contoh dari keempat kemungkinan tersebut dan membahas keuntungan relatif mereka.
Gambar 1: Kategorisasi 2 dimensi teknik mitigasi MEV di luar protokol dengan contoh untuk setiap kategori.
Aplikasi-Spesifik dan Mencegah MEV: Fungsi Maksimalkan AMM.
Teknik mitigasi MEV yang biasanya paling intuitif secara konseptual bagi mereka yang pertama kali mendengar tentang MEV adalah aplikasi yang mencegah paparan MEV. Contoh menariknya adalah fungsi memaksimalkan AMMdiproposikan olehAndrea CanidiodanRobin Fritsch. Ini memadatkan perdagangan yang dikumpulkan selama periode waktu tertentu dan mengeksekusinya semua dengan harga clearing yang seragam. Penulis menunjukkan bahwa hal ini menghilangkan LVR dan sandwiching, bentuk MEV lainnya. Intuisinya adalah bahwa semua peserta berdagang pada harga marjinal dari kolam renang setelah batch dan bahwa arbitraseur diincentivasi untuk berdagang sampai titik di mana harga ini sama dengan harga pasar eksternal. Sistem ini mirip dengan lelang batch yang sering diusulkan oleh gate.io.Budish, Cramton, dan Shim (2015)dalam literatur keuangan tradisional. Sebagai tambahan, ini adalah contoh yang sangat baik dari sinergi antara keuangan terdesentralisasi dan tradisional. Ide-ide keuangan tradisional dapat diimplementasikan dalam keuangan terdesentralisasi; pembelajaran dari implementasidapat digunakan untuk memberi tahu keuangan tradisional.
MEV Khusus Aplikasi dan Rabat : MEV menangkap AMM.
The Menangkap MEV AMM (McAMM)adalah contoh mitigasi MEV yang spesifik aplikasi yang mengandalkan pengembalian. McAMM melelang hak untuk menjadi pedagang pertama yang berinteraksi dengan AMM dalam satu blok, sehingga memungkinkan pedagang ini untuk mengambil arbitrase yang mungkin. Hasil lelang kemudian didistribusikan di antara penyedia likuiditas yang diarbitrasi. Jika lelang efisien, hasilnya harus sama dengan nilai arbitrase yang diekstraksi dari penyedia likuiditas. Desain ini bisa menyebabkan penghapusan LVR yang sama seperti fungsi AMM yang memaksimalkan yang dibahas di atas, meskipun pendekatan ini sangat berbeda. Apakah hal ini akan terjadi dalam praktek sangat bergantung pada implementasi lelang yang spesifik.
Infrastruktur dan Pengembalian MEV: MEV-Share.
Pemberian diskon tidak harus spesifik untuk suatu aplikasi. Flashbots, sebuah perusahaan yang beroperasi di ruang konstruksi blok, telah mengembangkan MEV-Bagikan. Ini memungkinkan pengguna memilih data transaksi mana yang akan dibagikan secara pribadi dalam pelelangan. Penawar menawar untuk mendapatkan hak menempatkan transaksi ini dalam satu paket dan dengan demikian mengambil MEV darinya. Pengguna dapat menerima hasil lelang. Infrastruktur ini tidak spesifik untuk aplikasi tertentu, karena transaksi dapat berinteraksi dengan aplikasi apa pun.
Infrastruktur dan Pencegahan MEV: Aliran Pesanan yang Dilindungi di Dunia yang Mencari Keuntungan.
Akhirnya, ada mekanisme infrastruktur yang bertujuan untuk mencegah ekstraksi MEV. Sebagai contoh adalah Aliran Pesanan yang Dilindungi di Dunia yang Mencari Keuntungan (PROF).PROF mengandalkan produsen blok dalam Lingkungan Eksekusi Terpercaya (TEE) yang meyakinkan untuk mengikat aturan, misalnya, first-come, first-serve. TEE memiliki dua sifat penting yang membuat komitmen ini meyakinkan, yaitu:
Setiap pengguna yang mengirim transaksinya ke produsen blok yang berkomitmen untuk menjalankan aturan pengurutan tahu bahwa produsen blok di TEE akan melakukannya. Oleh karena itu, PROF dapat mencegah jenis ekstraksi MEV tertentu, seperti front-running untuk aplikasi apa pun, tanpa mengubah aturan protokol Ethereum.
Teknik mitigasi MEV yang berbeda memiliki kelebihan dan kekurangan yang berbeda. Teknik pencegahan MEV khusus aplikasi sulit ditemukan karena membutuhkan banyak penelitian dan implementasi per aplikasi. Di sisi lain, pencegahan MEV infrastruktural membutuhkan banyak biaya. Misalnya, beberapa teknik pencegahan MEV infrastruktur memerlukan penggunaan perangkat keras yang mahal dan banyak pengembangan bisnis. Apakah pengembalian efektif tergantung pada apakah lelang bersifat kompetitif, yang bergantung pada detail lelang seperti formatnya dan kapan dilaksanakan.
Keempat teknik mitigasi MEV ini mungkin tidak sepenuhnya saling melengkapi atau sepenuhnya eksklusif. Perlu diperhatikan juga bahwa dimensi-dimensinya menyerupai spektrum dan bukan biner, seperti yang ditunjukkan pada Gambar 1. Sebagai contoh, beberapa teknik mitigasi MEV mungkin lebih bersifat infrastruktur daripada yang lainnya. Bidang ini bergerak sangat cepat, yang membuat setiap kategorisasi menjadi sulit. Akhirnya, ruangannya terasa optimis, dan banyak yang mungkin berbagi pendapat bahwa MEV sebagai persentase nilai total yang difasilitasi.akan menyusut dengan cepat.
Teknik mitigasi MEV ini mungkin terlihat tidak memuaskan bagi beberapa orang. Mengapa Ethereum tidak dapat menjadi infrastruktur protokol yang secara menyeluruh memecahkan MEV? Mungkin beberapa pembaca akan menyarankan untuk menggunakan aturan pengurutan tertentu. Proposal untuk menegakkan aturan pengurutan tertentu di Ethereum, seperti first-come-first-serve, belum mendapatkan dukungan luas. Saya percaya ada dua alasan mendasar mengapa protokol ini tidak dapat secara holistik memecahkan beban MEV yang diletakkan pada pengguna akhir dan aplikasi - keduanya terkait dengan batasan netralitas kredibel Ethereum.
Pertama, Ethereum tidak dapat memperoleh urutan global transitive yang memuaskan 'keadilan'. Ethereum menjadi tuan rumah bagi berbagai aplikasi yang masing-masing mungkin mendapatkan manfaat dari aturan urutan yang berbeda. Sementara urutan pertama datang, pertama dilayani mungkin membantu beberapa aplikasi, itu mungkin menghambat pertumbuhan orang lain. Oleh karena itu, sulit bagi ekosistem untuk sepakat tentang apa yang adil. Selain itu, bahkan jika ekosistem sepakat pada satu aturan pemesanan yang adil, sulit untuk mendapatkan aturan pemesanan transitatif global karena transaksi dapat tiba di node yang berbeda pada waktu yang berbeda.
Ketidaksesuaian ini menyebabkan masalah dalam protokol pemesanan first-come, first-serve. Secara khusus, meskipun urutan di mana setiap simpul individual menerima transaksi adalah transitif, itu tidak berarti bahwa urutan agregat juga transitif. Aturan pemesanan first-come, first-serve dapat terjebak dalam siklus untuk mengembalikan transitivitas, dan terkadang, siklus ini harus diselesaikan dengan aturan sembarang, seperti memilih urutan total secara alfabetis. Ini dapat berarti bahwa transaksi untuk yang urutannya sangat penting, seperti transaksi arbitrase yang sensitif terhadap waktu, tidak diurutkan dengan cara ini tetapi secara sembarang.
Gambar 2: Slide yang menunjukkan siklus Condorcet aturan pemesanan first-come, first-serve mungkin macet. Slide diambil dari presentasi tentang Themis oleh Mahimna Kelkar.
Selain fakta bahwa aturan pemesanan first-come, first-serve memiliki masalah teoritis, tidak jelasapakah mereka diinginkandi tempat pertama. Aturan pemesanan ini menguntungkan mereka dengan koneksi lebih cepat. Jika koneksi cepat cukup berharga, hal ini bisa menyebabkan perlombaan laten, seperti yang terlihat di keuangan tradisionaldengan investasi besar dalam teknologi kecepatan. Teknologi kecepatan bisa merusak netralitas yang kredibel dalam blockchain karena mendorong adanya sentralisasi geografis.
Pandangan yang tidak konsisten tentang kapan transaksi tiba menyebabkan masalah untuk aturan pemesanan siapa cepat dia dapat, dan untuk setiap aturan pemesanan. Aturan pemesanan biasanya bertujuan untuk mencapai beberapa properti ekonomi. Misalnya, pemesanan gas prioritas berusaha untuk memasukkan transaksi-transaksi tersebut dalam urutan berapa banyak nilainya dimasukkan terlebih dahulu. Biasanya, desiderata ekonomi ini terpenuhi hanya jika ada pandangan global tentang transaksi mana yang harus dipesan. Karena sulit untuk mendapatkan pandangan global transitif dari pandangan lokal transitif, sulit untuk mendapatkan pandangan global seperti itu. Dengan kata lain, beberapa validator akan berpikir transaksi harus dipesan dalam satu slot, dan yang lain berpikir itu harus di slot lain, menurunkan properti ekonomi yang dapat diharapkan ekosistem untuk menerima dari aturan pemesanan tetap.
Kedua, protokol konsensus tidak menyadari permainan MEV yang dimainkan pada lapisan eksekusi. Hal ini akan membuat sulit untuk merancang skema rebate dalam protokol karena protokol saat ini tidak akan memahami nilai MEV dan kepada siapa seharusnya direbater. Terakhir, protokol harus tetap netral secara kredibel. Protokol tidak boleh berada dalam posisi di mana harus membuat pilihan yang didasarkan pada opini tentang kepada siapa seharusnya direbater MEV, bahkan jika bisa, juga tidak boleh memilih teknik pencegahan MEV yang mendukung aplikasi tertentu dibandingkan dengan yang lain.
Sebuah contoh menarik yang mendekati teknik rebate MEV dalam protokol adalah Pajak MEV, diusulkan oleh Dan RobinsondanDave White. Ini memungkinkan aplikasi apa pun untuk membebani biaya prioritas dalam protokol dengan mengatur parameter, katakanlah $k$. Setiap pengguna yang berinteraksi dengan aplikasi tersebut harus membayar biaya prioritas sebesar $k$ kali lebih besar dari biaya prioritas yang dibayarkannya kepada validator konsensus untuk aplikasi tersebut. Anda dapat melihat bagaimana sistem ini dapat mengembalikan hasil MEV ke aplikasi secara umum. Misalnya, jika ada 10 ETH dari MEV yang akan diekstraksi dari aplikasi, dengan $k = 9$, dengan menjadi yang pertama berinteraksi dengannya, pengguna dapat membayar biaya prioritas sebesar 1 ETH kepada validator dan 9 ETH kepada aplikasi, dengan asumsi bahwa transaksi diurutkan berdasarkan biaya prioritas.
Pajak MEV adalah arah yang menjanjikan, tetapi seperti yang dinyatakan oleh penulisnya, itu harus dieksplorasi lebih lanjut untuk memahami bagaimana cara kerjanya di Ethereum. Salah satu aspek yang menantang mungkin adalah bahwa pajak MEV menganggap biaya prioritas adalah sinyal universal untuk jumlah MEV. Meskipun ini mungkin benar jika pesanan prioritas diberlakukan, pemesanan itu sendiri dapat menurunkan jumlah total MEV, mirip dengan bagaimana lelang harga pertama multi-unit mungkin memiliki pendapatan yang lebih rendah daripada lelang kombinatorial. Flashbots' SUAVESepertinya sedang menuju ke arah yang berlawanan, yang memungkinkan preferensi yang lebih ekspresif. SUAVE saat ini belum aktif tetapi bertujuan untuk membangun pembangun blok terdesentralisasi yang menggabungkan bundel secara optimal tanpa aturan pengurutan tertentu.
Biaya prioritas mungkin tidak mencerminkan MEV dengan baik ketika pencari ingin mengekspresikan preferensi mereka untuk dimasukkan secara lebih kompleks daripada biaya prioritas satu dimensi. Mungkin pencari ingin dimasukkan ke dalam blok sebelum paket pencari pesaing lainnya tetapi tidak peduli tentang posisi absolut di dalam blok. Menggunakan biaya prioritas berarti pencari bersaing untuk posisi dengan semua pengguna, terlepas dari relevansinya dengan pencari ini.
Ada cara lain untuk mengurangi MEV yang diekstraksi dari pengguna selain aturan pemesanan. Salah satu arah penelitian adalah Mempools terenkripsi. Ini berarti bahwa pengguna menyiarkan transaksi dalam bentuk terenkripsi. Hanya setelah inklusi transaksi didekripsi. Produsen blok, dengan demikian, tidak mengetahui konten transaksi, sehingga tidak mungkin melakukan transaksi front-run berdasarkan data yang sekarang terlindungi.
Mempools yang dienkripsi sudah aktif di Gnosis Chain, sebuah blockchain yang memiliki arsitektur serupa dengan Ethereum. Para peserta ekosistem, terutama Jaringan Shutter, bertujuan untuk membawa mempool terenkripsi ke Ethereum mainnet. Beberapa faktor pembatas saat ini adalah asumsi kepercayaan yang diperlukan dengan teknik kriptografi berbasis enkripsi ambang batas,keadaan Fungsi Penundaan yang Dapat Diverifikasi, dan masalah ketersediaan data gratisterkait dengan mempool terenkripsi.
Secara ringkas, Ethereum tidak dapat menjadi infrastruktur yang mencegah MEV karena ekosistem belum dapat sepakat pada aturan pemesanan yang adil dan sulit untuk mencapai pemesanan global transitive yang memuaskan aturan apa pun. Beberapa proposal untuk aturan pemesanan, seperti contoh pajak MEV yang diberikan di atas dan peningkatan protokol, telah dibahas yang dapat memfasilitasi pemesanan global transitive yang memenuhi kriteria "keadilan". Namun, saat ini tidak ada konsensus kasar tentang apakah hal ini diinginkan. Ethereum tidak dapat menjadi infrastruktur yang memberikan rebate MEV karena lapisan konsensus tidak menyadari apa yang terjadi pada lapisan pelaksanaan dan Ethereum tidak dapat memilih di antara aplikasi karena harus tetap netral.
Paragraf sebelumnya menampilkan betapa sulitnya bagi protokol untuk menghilangkan beban MEV yang ditempatkan pada pengguna. Namun, banyak mekanisme protokol menangani MEV, dan seluruh bagian dari peta jalan Vitalikdalam hal ini. Apa yang dilakukan mekanisme ini?
Mekanisme dalam protokol ini bertujuan untuk memecahkan masalah yang berbeda dari teknik mitigasi yang dibahas sebelumnya. Alih-alih memaksimalkan nilai yang difasilitasi Ethereum dengan meminimalkan MEV yang diekstraksi dari pengguna, mekanisme dalam protokol ini bertujuan untuk memaksimalkan netralitas kredibel Ethereum dengan meminimalkan dampak negatif dari MEV. MEV tidak hanya mengurangi utilitas bagi mereka yang diekstraksi, tetapi juga sangat mengganggu perilaku pengekstrak, misalnya, mendorong sentralisasi melalui ekonomi skala dan menyebabkan ketidakstabilan konsensus.
Kekuatan ekonomi adalah risiko sentralisasi besar untuk konsensus Ethereum dan secara transitif untuk netralitasnya yang kredibel. Jika ada skala ekonomi, agen konsensus kecil dapat diharapkan untuk bergabung dengan agen besar untuk mendapatkan keuntungan. Jika ada pengembalian ke kecanggihan, validator rasional mungkin berperilaku berbeda dari spesifikasi jujur. Skala ekonomi atau kembali ke kecanggihan untuk agen konsensus adalah eksternalitas negatif MEV.
Protokol bertujuan untuk mencegah eksternalitas negatif dengan memisahkan peran agen konsensus dalam Ethereum dan memisahkan mereka satu sama lain. Saat ini, Ethereum menugaskan semua peran berikut kepada satu agen, tetapi pada prinsipnya, ini adalah peran yang terpisah. Tiga peran yang telah diidentifikasi sejauh ini adalah sebagai berikut:
Ekosistem Ethereum bertujuan untuk mengisolasi ketiga peran ini sehingga insentif yang berasal dari satu peran tidak mempengaruhi insentif mereka yang memenuhi peran lain. Beberapa peran, seperti pemesanan transaksi, dapat lebih terpusat selama validasi blok tidak dapat dipercaya dan sangat terdesentralisasi, dan serangkaian peserta yang terdesentralisasi dapat memastikan resistensi sensor, seperti yang dinyatakan Vitalik dalam bukunya yang berpengaruh Postingan akhir permainan.
Pemisahan Penyusun-Pembangun (PBS)bertujuan untuk memisahkan peran mengusulkan dan membangun payload eksekusi. Ini adalah filosofi desain yang mengakui peran yang berbeda dan memfasilitasi pelepasan tugas membangun blok proposer ke pihak khusus. MEV-Boost adalah instansi di luar protokol saat ini dari PBS. Ini memungkinkan semua proposer, terlepas dari kecanggihannya, mengakses pasar MEV yang sama. Secara konkret, ini memastikan bahwa builder menerima hak untuk membangun blok dan bahwa proposer menerima pembayaran mereka atas penjualan hak ini. Dengan MEV-Boost, proposer tidak mendapatkan keuntungan lebih dengan berinvestasi dalam teknik ekstraksi MEV yang canggih tetapi dapat tetap relatif tidak canggih dalam area ini dan menikmati imbalan yang sama dengan proposer yang lebih canggih.
Pemisahan Attester-Proposer (APS) secara konseptual mirip dengan PBS. Ini juga mengakui perbedaan antara dua peran: membuktikan & mengusulkan blok konsensus dan mengusulkan blok eksekusi. APS saat ini sedang dalam tahap penelitian dan tidak ada versi out-of-protocol yang aktif. Pengusul mungkin ingin cepatkarena itu memungkinkan mereka untuk mengirim blok mereka lebih lambat, yang berarti mereka mungkin dapat menyertakan lebih banyak transaksi. Sangat penting bagi protokol konsensus untuk tidak mendorong keterlambatan karena hal ini menyebabkan sentralisasi geografis. APS kadang-kadang dianggap sebagai garis terakhir pertahanan untuk protokol Ethereum.
PBS dan APS menunjukkan bagaimana tiga peran ini dapat diisolasi. Namun, menerapkan dua upgrade protokol ini juga berarti bahwa para peserta yang membuat blok akan sangat terpusat, yang sangat buruk untuk ketahanan sensor. Ethereum bertujuan untuk mengatasi masalah ini dengan membangun katup satu arah antara peran-peran ini. Protokol dapat membebani peran memberi saksi kepada blok dengan memberi saksi kepada transaksi yang tertunda di mempool. Sebuah komite saksi kemudian bertanggung jawab untuk membuat daftar transaksi yang harus disertakan oleh produsen blok, atau blok mereka akan diabaikan oleh para saksi. Jenis mekanisme ini disebutdaftar inklusi.
Klep-klep ini menantang pemisahan peran. Itu adalah sangat sulit untuk merancangkatup yang secara signifikan menggunakan sifat-sifat satu set peserta, misalnya, membatasi satu set peserta lainnya, sambil juga memastikan bahwa peserta di ujung katup lainnya tidak mempengaruhi peserta yang mempengaruhi mereka. Sebagai contoh, kumpulan pemeriksa terdesentralisasi akan bertanggung jawab untuk membuat daftar inklusi. Kami tidak ingin produsen blok atau insentif sentralisasi terkait produksi blok mempengaruhi pemeriksa.
Gambar 3: Pembagian kerja oleh Attester-Proposer Separation (APS) dan Proposer-Builder Separation (PBS) dengan daftar inklusi dan hak bangunan yang dijual sebagai katup satu arah antara peran.
Tujuan utama dari mekanisme MEV dalam protokol secara fundamental berbeda dari teknik mitigasi MEV aplikasi dan infrastruktur. Teknik mitigasi di luar protokol umumnya bertujuan untuk mengurangi MEV per unit nilai yang difasilitasi. Sebaliknya, teknik mitigasi dalam protokol bertujuan untuk mencegah eksternalitas negatif MEV yang mengkonsolidasikan agen konsensus Ethereum. Teknik mitigasi MEV tertentu dapat berkontribusi pada kedua tujuan tersebut. MEV-Boost, sebagai contoh, secara teknis berada di luar protokol, namun tujuan utamanya adalah mencegah eksternalitas negatif MEV.
Selain itu, batasan dalam dua masalah tersebut berbeda. Mekanisme in-protocol harus dirancang dengan persyaratan perangkat keras dan protokol netral. Sebaliknya, batasan teknik mitigasi MEV di luar protokol tergantung pada keinginan para desainer aplikasi atau infrastruktur, yang dapat cocok untuk kasus penggunaan tertentu.
Karena masalah-masalah ini memiliki tujuan dan batasan yang berbeda, adalah intuitif bahwa tidak ada solusi tunggal yang dapat menangani keduanya. Selain itu, mungkin ada dikotomi yang lebih mendasar antara kedua masalah tersebut. Bagian ini menguraikan sebuah argumen untuk dikotomi ini, juga disajikan dalam sebuahmakalah oleh Davide Crapis dan saya sendiri.
Para perancang aplikasi ingin mengurangi MEV per unit nilai karena hal tersebut akan menarik lebih banyak pengguna dan dengan demikian meningkatkan total nilai yang difasilitasi oleh aplikasi ini. Jika MEV per unit nilai menurun tetapi total nilai yang difasilitasi meningkat, jumlah total MEV bisa menurun tetapi juga bisa meningkat. Mekanisme MEV dalam protokol peduli pada jumlah total MEV yang agen konsensus dapat ekstraksi. Bahkan jika jumlah total MEV hanya merupakan fraksi yang dapat diabaikan dari nilai yang difasilitasi oleh Ethereum, tidak jelas apakah protokol masih perlu memisahkan peran konsensus yang berbeda yang diperlukan untuk mencegah sentralisasi pada peserta konsensus Ethereum.
Sebagai contoh dari argumen ini, pertimbangkan kasus Loss-Versus-Rebalancing(LVR), diperkenalkan sebelumnya sebagai kerugian arbitrase laten para penyedia likuiditas di AMM karena penawaran mereka di rantai tetap ketinggalan zaman antar blok dibandingkan dengan pasar eksternal yang terus diperbarui. Dalam penelitian mereka, Milionis dkk. menemukan bahwa LVR kumulatif selama slot proporsional dengan waktu slot hingga kekuatan 3/2.
Pada pemeriksaan pertama, hal ini akan menunjukkan bahwa mengurangi waktu slot juga mengurangi MEV. LVR, namun, adalah kerugian arbitrase per unit likuiditas. Selain itu, Joel Hasbrouck, Thomas Rivera, dan Fahad Saleh menunjukkanbahwa posisi LP individu dapat dianggap sebagai aset yang dapat diinvestasikan. Pengembalian yang diharapkan dari aset biasanya didasarkan pada risikonya. Tidak jelas bagaimana risiko dari posisi LP akan berubah saat waktu slot berkurang, tetapi untuk tujuan perdebatan, asumsikan risikonya tetap konstan. Maka, pengembalian dari posisi LP seharusnya tetap konstan terlepas dari waktu slot; oleh karena itu, jika biaya per unit likuiditas berkurang, pendapatan per unit likuiditas juga harus berkurang. Dalam AMM, pendapatan akan berkurang karena likuiditas yang lebih banyak mengalir ke AMM. Likuiditas yang lebih banyak berarti lebih banyak unit likuiditas menghadapi LVR. Oleh karena itu, efek agregatnya ambigu. Jadi, tidak jelas bagaimana total jumlah MEV yang berasal dari LVR akan berubah jika waktu slot berubah, meskipun MEV per unit nilai dapat berkurang.
Selain itu, penurunan LVR akan membuat AMM menjadi tempat yang lebih menarik untuk diperdagangkan karena ada lebih banyak likuiditas, yang berarti bahwa lebih banyak pedagang yang membayar biaya menggunakan AMM, menyebabkan likuiditas yang lebih banyak. Selain itu, pengalaman pengguna mendapat manfaat dari waktu slot yang lebih singkat, dan jumlah total MEV yang berasal dari LVR dapat meningkat dengan waktu slot. Ini merupakan masalah bagi protokol, meskipun pengguna menikmati perdagangan yang lebih efisien.
Tabel 1: Dampak waktu slot terhadap LVR, jumlah likuiditas, dan jumlah total MEV. Tabel ini menunjukkan bagaimana waktu slot memengaruhi LVR per slot dan faktor dengan mana likuiditas dikalikan. Ini mengasumsikan bahwa pendapatan biaya tetap konstan dan biaya kesempatan per slot adalah nol. Hasilnya dinormalisasi dengan nilai yang sesuai dengan waktu slot 12 detik yang digunakan sebagai dasar.
Tabel 1 menunjukkan bahwa jumlah total MEV yang berasal dari LVR mungkin tetap sama meskipun waktu slot berkurang. Nilai-nilai dalam tabel ini dihasilkan dengan mengasumsikan bahwa biaya adalah satu-satunya pendapatan, arbitrase latency adalah satu-satunya biaya bagi penyedia likuiditas, dan biaya kesempatan per-slot tetap konstan pada nol. Asumsi-asumsi ini terlalu sederhana. Oleh karena itu, angka-angka ini mungkin menyajikan batas atas pada likuiditas yang meningkat per slot dan, dengan demikian, pada jumlah total MEV.
Sulit untuk mengatakan bagaimana prediksi ini akan bertahan. Ekosistem tahu sedikit tentang motivasi penyedia likuiditas dan trade-off risiko-imbalan.bahkan lebih sedikit tentang perilaku trader likuiditas. Mungkin LP mempertimbangkan risiko posisi LP dengan cara yang berbeda tergantung pada waktu slot, yang dapat membantu memprediksi apa yang terjadi dengan total jumlah MEV saat waktu slot berkurang.
Potensialnya, contoh ini dapat digeneralisasikan. Teknik mitigasi MEV di luar protokol yang bertujuan untuk meminimalkan MEV per unit nilai secara simultan menginduksi lebih banyak nilai yang mengalir melalui sistem; oleh karena itu, dampak mitigasi MEV terhadap jumlah total MEV menjadi ambigu. Oleh karena itu, saya percaya bahwa Ethereum tidak dapat mengandalkan mitigasi MEV di luar protokol untuk mencegah dampak negatif MEV pada agen konsensus.