Pendahuluan

Dalam posting ini, kami memperkenalkan pajak MEV, mekanisme yang dapat digunakan aplikasi sewenang-wenang untuk menangkap MEV mereka sendiri.

Mekanisme ini dapat digunakan hari ini pada OP Stack L2 seperti OP Mainnet, Base, dan Blast, karena pengusul blok pada rantai tersebut mengikuti seperangkat aturan yang kami sebut pemesanan prioritas kompetitif.

Untuk menerapkan pajak MEV pada salah satu rantai ini, kontrak pintar membebankan biaya yang merupakan fungsi dari biaya prioritas transaksi. Kami menunjukkan bahwa jika aplikasi membebankan pajak MEV kepada pencari sebesar (katakanlah) $ 99 untuk setiap $ 1 dari biaya prioritas, itu dapat menangkap 99% dari MEV kompetitif untuk transaksi itu.

MEV pajak adalah teknik sederhana yang membuka ruang desain yang luas. Anda dapat menganggapnya memungkinkan aplikasi apa pun pada rantai untuk menjalankan lelang MEV kustomnya sendiri, tanpa memerlukan infrastruktur offchain sendiri, hanya dengan mengaitkan ke satu lelang bersama yang dijalankan oleh pengusul blok.

Kami menunjukkan bagaimana pajak MEV dapat digunakan untuk memecahkan tiga masalah utama dalam penelitian MEV:

• Router pertukaran terdesentralisasi (DEX) yang mengoptimalkan harga yang diterima oleh swapper
• Pembuat pasar otomatis (AMM) yang meminimalkan loss-vs-rebalancing (LVR) yang dialami oleh penyedia likuiditas
• Dompet yang memungkinkan penggunanya menangkap MEV "backrunning" apa pun yang dibuat oleh transaksi mereka

Tapi ada tangkapan. MEV pajak hanya berfungsi jika pengusul blok secara ketat mengikuti aturan pemesanan prioritas kompetitif, yang mencakup menyortir transaksi berdasarkan biaya prioritas tanpa menyensor, mengintip, atau menunda apa pun. Jika pengusul blok menyimpang dari aturan tersebut, mereka dapat menghindari pajak MEV untuk menangkap nilai bagi diri mereka sendiri. Hari ini, oleh karena itu, pajak MEV bergantung pada mempercayai sequencer L2, dan kemungkinan tidak akan bekerja sama sekali pada Ethereum L1, di mana bangunan blok didominasi oleh lelang pembangun kompetitif yang memaksimalkan pendapatan bagi pengusul.

Namun, kekuatan dan fleksibilitas pajak MEV menunjukkan bahwa pemesanan prioritas mungkin merupakan pilihan yang tepat untuk platform yang dapat menyediakannya hari ini. Dan kesederhanaan relatif dari pemesanan prioritas kompetitif menunjukkan bahwa mungkin ada cara yang layak untuk menegakkannya dengan cara yang terdesentralisasi, tanpa harus mempercayai sequencer tunggal. Kami berharap posting ini memotivasi pekerjaan lebih lanjut pada masalah itu.

Pemesanan prioritas

Ketika seseorang mengirim transaksi pada Ethereum L1 atau L2, mereka menentukan biaya prioritas, yang mereka bayarkan kepada pengusul blok.1 Anda dapat membayangkan ini ditentukan sebagai priorityFeePerGas, angka yang dikalikan dengan gas yang digunakan dalam transaksi untuk mendapatkan builderPriorityFee—total pembayaran dalam ETH. 2

Tidak ada aturan dalam Ethereum protokol bahwa transaksi dalam blok harus dipesan dengan rakus dengan menurunkan priorityFeePerGas. Namun, itu adalah cara populer untuk membangun blok — misalnya, ini adalah algoritme default yang digunakan oleh sequencer rantai OP Stack, serta geth dan reth. Pemesanan prioritas tidak hanya memungkinkan transaktor secara efisien mengekspresikan urgensi transaksi mereka, tetapi juga secara alami menyalurkan jenis MEV tertentu kepada pengusul blok.

Itu terjadi karena pemesanan prioritas mengubah persaingan untuk MEV menjadi lelang priority gas. Ketika ada peluang untuk mendapatkan keuntungan dari berinteraksi dengan rantai, seperti dengan menengahi AMM terhadap pertukaran terpusat, pencari bersaing untuk mengklaim peluang itu terlebih dahulu. Jika rantai menggunakan pemesanan prioritas untuk menentukan penyertaan dan pemesanan transaksi, para pencari bersaing dengan menetapkan biaya prioritas tinggi pada transaksi mereka.

Dalam skenario kompetitif di mana keuntungan bebas risiko dikompetisikan ke nol, pencari yang menang harus membayar jumlah penuh MEV dalam biaya prioritas. 3 Jadi jika ada keuntungan 100 ETH yang bisa diperoleh dari berinteraksi dengan kontrak, transaksi pertama yang mengklaimnya akan menetapkan biaya prioritas 100 ETH. (Kami membahas beberapa peringatan untuk ini di bagian Pembatasan).

MEV pajak

Misalkan kontrak pintar ingin menangkap MEV dari transaksi apa pun yang berinteraksi dengannya. Ada perpustakaan penelitian yang luas tentang berbagai cara khusus aplikasi yang dapat smart contract coba untuk menangkap MEV mereka sendiri.

Namun pada kenyataannya, kita tidak perlu tahu apa-apa tentang aplikasi tersebut. Jika kita tahu bahwa blok sedang dibangun melalui pemesanan prioritas kompetitif, maka kita memiliki satu sinyal universal untuk jumlah MEV dalam transaksi: biaya prioritas.

Kami mengusulkan agar kontrak pintar dapat melihat biaya prioritas transaksi dan membebankan biayanya sendiri sebagai beberapa fungsi yang meningkat. Misalnya, kontrak mungkin mengharuskan siapa pun yang memanggilnya untuk mentransfer applicationPriorityFee = 99 * proposerPriorityFee dalam ETH ke kontrak. 4

Biaya baru ini dibayar oleh pencari yang mengirim transaksi, sehingga mempengaruhi perilaku pencari itu. Jika ada 100 MEV dalam satu kesempatan, transaksi yang menang sekarang hanya akan menetapkan biaya prioritas 1 ETH, karena itu akan menghasilkan total pembayaran 100 ETH (1 ETH ke pengusul blok, dan 99 ETH ke kontrak pintar). Biaya prioritas yang lebih tinggi akan membuat transaksi tidak menguntungkan; Biaya prioritas yang lebih rendah akan mengakibatkan hilangnya kesempatan bagi pesaing yang menetapkan biaya lebih tinggi. Ini berarti kontrak pintar telah menangkap 99% MEV dalam transaksi.

Kami menyebut biaya tambahan yang dikenakan oleh kontrak pintar ini sebagai pajak MEV. MEV pajak memungkinkan aplikasi membajak pemesanan prioritas untuk keuntungannya sendiri, memungkinkannya untuk menangkap kembali MEV bagi penggunanya daripada membocorkannya ke pengusul blok.

Jika biaya ini meningkat cukup cepat sebagai fungsi priorityFeePerGas, maka hanya jumlah MEV yang dapat diabaikan yang akan bertambah kepada pengusul. Karena priorityFeePerGas didenominasi dalam wei (sepersejuta dari sepersejuta satu ETH), kami memiliki banyak presisi untuk dikerjakan. Misalnya, long pajak MEV cukup sensitif sehingga prioritasFeePerGas sebesar 50.000 akan menghasilkan pajak yang sangat tinggi, maka total pembayaran kepada pengusul akan kurang dari $ 0,01. 5

Namun, ada peringatan penting. Seperti yang dibahas di bagian Pembatasan, pajak MEV hanya berfungsi jika pengusul blok mengikuti aturan tertentu — apa yang kami sebut "pemesanan prioritas kompetitif" — daripada menyimpang dari aturan tersebut dalam pesanan untuk memaksimalkan pendapatan mereka sendiri. Menegakkan aturan-aturan ini dengan cara yang tidak dapat dipercaya adalah masalah terbuka.

Single-application MEV capture

Di sini kami membuat sketsa bagaimana, pada rantai yang dijamin menggunakan pemesanan prioritas kompetitif untuk pembangunan blok, pajak MEV dapat digunakan untuk mengurangi tiga masalah penting dalam MEV: membiarkan antarmuka DEX meningkatkan eksekusi perdagangan untuk swappers, membiarkan AMM mengurangi kerugian arbitrase untuk LP mereka, dan membiarkan dompet mengurangi kebocoran MEV bagi pengguna mereka dengan menjual hak untuk backrun pengguna.

DEX router

Dalam protokol perutean DEX berbasis intent seperti UniswapX dan 1inch Fusion, pengguna (Alice) menandatangani niat untuk bertukar, dan pencari bersaing untuk merutekan atau mengisi maksud itu dengan harga terbaik untuk Alice.

Versi UniswapX saat ini menggunakan dua mekanisme untuk menjalankan kompetisi itu: lelang Belanda di mana harga batas Alice berubah dari waktu ke waktu sampai pencari mengisinya, dan lelang permintaan-untuk-kutipan offchain awal (RFQ) untuk menetapkan harga awal lelang Belanda itu.

Pada platform yang menjamin pemesanan prioritas kompetitif, UniswapX dapat menggantinya dengan mekanisme tunggal: pajak MEV. Ini bisa menerapkan ini dengan meminta pengguna menandatangani pesanan yang dapat segera diisi oleh siapa saja, tetapi dengan harga eksekusi yang ditetapkan sebagai fungsi prioritas transaksi.

Misalnya, jika Alice memiliki pesanan UniswapX untuk menjual 1 ETH, dia dapat menentukan harga eksekusi pesanan menjadi minimumPrice + ($0.01 * priorityFeePerGas). minimumPrice bisa menjadi nilai tetap yang dia harapkan jauh lebih rendah dari harga saat ini.

Para pencari akan bersaing untuk mengisi pesanan Alice dengan mengirimkan transaksi. Transaksi mana pun yang memiliki biaya prioritas tertinggi dan tidak dikembalikan akan dapat mengisi pesanan, yang harus menjamin bahwa swapper mendapatkan harga terbaik yang dapat ditemukan oleh pencari. (Beberapa pengecualian untuk ini dibahas di bagian Pembatasan.)

Jika harga minimum Alice adalah $ 3.000 dan harga ETH saat ini adalah $ 3.500, priorityFeePerGas dalam transaksi yang menang adalah sekitar 50.000. (Perhatikan bahwa dalam transaksi yang menelan biaya 200.000 gas, ini akan menghasilkan pembayaran hanya sekitar 10 miliar wei — sekitar $ 0,000035 — kepada pengusul blok.)

Ini memiliki beberapa manfaat potensial dibandingkan mekanisme yang ada yang digunakan di UniswapX.

Pesanan yang menggunakan pajak MEV dapat diselesaikan lebih cepat dan dengan harga yang lebih baik daripada pesanan yang menggunakan lelang Belanda. Seperti yang dibahas dalam makalah ini, lelang Belanda onchain membocorkan beberapa nilai ke MEV karena pergerakan harga antar blok, dan mungkin memerlukan banyak blok untuk menyelesaikannya. Sebaliknya, pesanan yang menggunakan pajak MEV biasanya dapat diselesaikan di blok berikutnya sambil menangkap sebagian besar MEV mereka.

Tidak seperti RFQ offchain, lelang untuk mengisi pesanan yang menggunakan pajak MEV akan terjadi secara atomik dengan eksekusi transaksi onchain. Ini berarti bahwa penawar yang menang dapat dijamin bahwa mereka hanya berkomitmen untuk mengisi pesanan jika transaksi onchain mereka berhasil. Itu dapat memudahkan likuiditas onchain seperti AMM untuk bersaing dengan likuiditas offchain, yang berarti UniswapX dapat berfungsi sebagai router yang lebih efektif untuk sistem multi-pool seperti Uniswap v4.

AMMs

Biasanya, AMM membocorkan nilai ke arbitrase yang berdagang melawan harga basi di bagian atas blok, seperti yang dibahas dalam loss-vs-rebalancing papers. Kita dapat menggunakan pajak MEV agar AMM menangkap MEV itu. Untuk menjaga hal-hal sederhana, kita akan membahas bagaimana ini bisa bekerja pada AMM tanpa likuiditas terkonsentrasi. (Jika Anda tertarik pada bagaimana masalah semacam ini dapat diselesaikan dengan likuiditas terkonsentrasi, Sorella akan segera menerbitkan satu solusi.)

Seorang AMM dapat menangkap MEV dengan membebankan biaya tambahan sebagai fungsi dari biaya prioritas pada transaksi, yang memungkinkannya untuk melelang hak untuk berdagang terlebih dahulu di blok. Ada banyak cara untuk menghitung dan mendenominasi biaya itu. Kita akan membahas satu yang bisa dibilang netral — mendenominasikannya dalam satuan likuiditas kumpulan, sqrt (xy). Transaksi yang menang akan menjadi salah satu yang paling meningkatkan likuiditas kumpulan.

Saat mengeksekusi transaksi pertama pada pool di blok, alih-alih menegakkan kondisi x_end y_end > x_start y_start, pool dapat memberlakukan kondisi (dengan beberapa konstanta):

x_end y_end > (sqrt(x_start y_start) + a*priorityFeePerGas)^2

Formula ini akan memberi insentif kepada pedagang arbitrase untuk berdagang dengan harga sebenarnya, dan setelah perdagangan itu, harga titik tengah di kolam harus menjadi harga sebenarnya. 6

Setelah transaksi pertama itu, perdagangan dapat bekerja seperti yang mereka lakukan di Uniswap v2, dengan biaya swap tetap. Transaksi tanpa informasi yang ingin berdagang di kolam renang tanpa membayar pajak MEV tambahan akan menetapkan biaya prioritas rendah.

Ada banyak cara lain untuk menerapkan pajak MEV pada AMM yang akan memiliki efek berbeda. Misalnya, pajak MEV dapat didenominasi dalam token input atau output swap, dapat mempengaruhi persentase biaya swap yang diterapkan oleh pool, atau dapat menentukan harga minimum perdagangan pengguna. Kami pikir ini adalah ruang desain yang menarik untuk dijelajahi.

Lelang backrunning

Deskripsi di atas menunjukkan bagaimana aplikasi tertentu dapat dirancang untuk menghindari kebocoran MEV. Namun, bagaimana jika dompet ingin mencoba membantu penggunanya menangkap MEV yang mereka buat dari transaksi sewenang-wenang yang berinteraksi dengan aplikasi apa pun, bahkan yang tidak memasukkan pajak MEV?

Misalnya, ketika Alice melakukan transaksi besar di AMM, dia terkadang menciptakan peluang arbitrase bagi "backrunners" untuk memindahkan harga kembali. Ini biasanya bocor ke MEV, daripada pergi ke Alice.

MEV-Share dan MEVBlocker adalah dua protokol yang memungkinkan pengguna untuk menangkap MEV dari transaksi mereka, tetapi mereka bergantung pada sistem lelang offchain yang kompleks. Ruang Desain Lelang Orderflow menjelaskan beberapa solusi lain.

MEV pajak, bila dikombinasikan dengan dompet kontrak pintar berbasis niat, dapat memungkinkan kita untuk membangun sistem alternatif untuk menangkap MEV backrunning untuk Alice. Misalkan alih-alih membuat transaksi yang berdagang di AMM, Alice menandatangani niat bahwa siapa pun dapat tunduk pada dompet kontrak pintar Alice untuk menyebabkannya mengambil tindakan itu. Dompet kontrak pintar Alice membebankan pajak MEV kepada siapa pun yang mengirimkan transaksi itu, yang dibayarkan kepada Alice.

Pencari yang mengirimkan niat Alice akan memiliki hak eksklusif untuk mendukungnya, karena mereka dapat melakukannya secara atomik dalam transaksi yang sama. Akibatnya, jika pencarian kompetitif, semua keuntungan dari backrunning Alice harus bertambah ke Alice melalui pajaknya yang MEV.

Perhatikan bahwa sistem ini mungkin belum tentu melindungi pengguna dari serangan yang melibatkan transaksi pengguna frontrunning, karena transaksi yang melakukan frontrunning pengguna mungkin dapat menghindari pembayaran pajak MEV kepada pengguna tersebut. Masalah ini (dan beberapa kemungkinan mitigasi untuk itu) dibahas secara lebih rinci di bagian Batasan di bawah ini. Namun demikian, ini setidaknya bisa menjadi perbaikan pada sistem yang menggunakan mempool publik tanpa mitigasi apa pun.

Kasus penggunaan lainnya

Selain contoh-contoh ini, potensi penggunaan pajak MEV lainnya dapat mencakup hampir semua hal yang saat ini menggunakan lelang offchain atau Belanda, seperti:

• Protokol untuk oracle untuk menangkap nilai oracle yang dapat diekstraksi yang mereka buat, seperti Oval
• Lelang pembiayaan kembali dalam protokol pinjaman dengan jaminan NFT seperti Blend
• Lending protokol likuidasi yang leak lebih sedikit nilai dari lelang Belanda

Cross-application MEV capture

Solusi di atas dirancang untuk menangkap MEV dari berinteraksi dengan satu aplikasi. Tetapi kadang-kadang mungkin bagi pencari untuk menangkap nilai lebih dengan berinteraksi dengan beberapa aplikasi dalam transaksi yang sama.

Jika hanya satu dari aplikasi tersebut yang memiliki pajak MEV, maka semua MEV dari transaksi harus masuk ke aplikasi dengan pajak MEV, terlepas dari seberapa tinggi atau rendah pajak MEV itu.

Tetapi bagaimana jika transaksi pencari berinteraksi dengan dua aplikasi yang menggunakan pajak MEV? Misalnya, bagaimana jika ada beberapa MEV yang hanya dapat ditangkap dengan mengisi salah satu pesanan UniswapX dengan pajak MEV yang dijelaskan di atas terhadap AMM yang dikenai pajak MEV?

Dalam hal ini, jumlah relatif kelebihan MEV yang ditangkap oleh setiap aplikasi ditentukan oleh bagaimana aplikasi tersebut menetapkan pajak MEV mereka. Jika nilai yang app_i bebankan sebagai pajak MEV diberikan oleh fungsi tax_i (prioritas), maka prioritas transaksi yang menang dapat ditentukan dengan menyelesaikan prioritas dalam persamaan ini:

tax_1(priorityPerGas) + tax_2(priorityPerGas) = total MEV

(Secara teknis, kita dapat menambahkan istilah ketiga untuk priorityPerGas * gasDigunakan untuk akun biaya prioritas yang dibayarkan kepada pengusul blok, tetapi kita akan mengabaikannya karena, seperti yang dibahas dalam Lampiran A, kemungkinan akan diabaikan dalam kondisi normal.)

Dalam kasus sederhana pajak MEV yang linier dalam priorityPerGas (jadi tax_1(priorityPerGas) = a_1 * priorityPerGas), Anda dapat menyelesaikan bagian MEV yang diterima oleh setiap aplikasi:

a_1 priorityPerGas + a_2 priorityPerGas = MEV

priorityPerGas = MEV/(a_1 + a_2)

tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV

tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV

Ketika menetapkan pajak MEV sendiri, aplikasi menghadapi tradeoff — pajak yang lebih tinggi memungkinkannya menangkap bagian yang lebih besar dari MEV aplikasi silang ketika itu terjadi, tetapi berarti itu bisa kehilangan beberapa MEV aplikasi silang jika ada cara bersaing untuk mengekstraknya. Misalnya, jika ada AMM yang membebankan pajak MEV pada setiap perdagangan, maka pesanan UniswapX MEV pajak mungkin lebih mungkin diisi oleh AMM yang berbeda atau pengisi offchain.

Dalam banyak kasus, mungkin ada keseimbangan di mana dua aplikasi merancang pajak MEV mereka secara pesanan untuk berbagi MEV dengan cara yang memaksimalkan masing-masing kesejahteraan mereka. Misalnya, AMM pajak MEV kemungkinan ingin menangkap nilai dari satu pedagang yang mendapat informasi di dekat bagian atas blok, tetapi kemudian ingin menyediakan likuiditas kepada pedagang dan aplikasi lain (termasuk yang menggunakan pajak MEV) dengan biaya tetap yang rendah. Dalam hal ini, AMM cenderung menetapkan pajak MEV yang relatif rendah (katakanlah, $ 0,00001 priorityFeePerGas), sehingga transaksi arbitrase (jika ada) terjadi di awal blok, dan kemudian tidak membebankan pajak MEV atas transaksi berikutnya di blok. Aplikasi seperti UniswapX yang ingin berinteraksi dengan AMM dapat menetapkan pajak MEV yang jauh lebih tinggi (katakanlah $0,01 priorityFeePerGas), untuk memastikan bahwa transaksi mereka disertakan setelah kumpulan sudah diarbitrase. Dengan pajak relatif tersebut, AMM akan berakhir lebih dulu meskipun hanya ada $1 MEV di atasnya dan $50.000 MEV dalam pesanan UniswapX.

Kami pikir ini adalah ruang desain luas yang layak untuk dipelajari di masa depan.

Batasan

MEV pajak memiliki beberapa komplikasi dan kelemahan. Kami pikir masing-masing adalah area yang menarik untuk penelitian di masa depan.

Ketidakcocokan insentif

MEV pajak tidak kompatibel dengan insentif untuk pengusul blok monopolistik. Mereka hanya bekerja jika ada persaingan yang adil untuk penyertaan transaksi, yang hanya dapat terjadi jika pengusul blok mengikuti aturan yang akan kita sebut "pemesanan prioritas kompetitif," daripada memaksimalkan pendapatan mereka sendiri. Secara informal dan tidak lengkap, kami menyarankan agar aturan ini mencakup:

• Urutan prioritas. Transaksi dalam blok harus dipesan dalam pesanan menurun dari priorityFeePerGas.
• Sensor-resistensi. Jika pengusul blok menerima transaksi t1 selama blok, dan blok tidak penuh atau mencakup beberapa transaksi t2 sehingga t2.priorityFeePerGas < t1.priorityFeePerGas, maka blok harus menyertakan transaksi t1.
• Privasi pra-transaksi. Pengusul blok harus menerima transaksi melalui titik akhir privat dan tidak boleh membagikan transaksi tersebut dengan orang lain sebelum melakukan blok, atau menggunakan konten transaksi tersebut sebagai input dalam membangun transaksinya sendiri.
• Tidak ada tampilan terakhir. Pengusul blok harus menetapkan waktu yang pasti sebelum mereka menerima transaksi dari siapa pun, dan setelah itu mereka tidak menerima transaksi dari siapa pun.

Jika satu atau lebih dari properti ini dilanggar, itu dapat melemahkan efektivitas pajak MEV. Pengusul blok yang melanggar resistensi sensor dapat menghindari sebagian besar pajak MEV dengan mengecualikan transaksi pesaing dan mengirimkan transaksi tanpa prioritas yang mengambil kesempatan untuk dirinya sendiri. Pengusul blok yang melanggar privasi pra-transaksi dapat mencuri MEV dari transaksi lain atau mengintip biaya prioritas mereka untuk mengetahui dengan tepat seberapa tinggi yang perlu ditetapkan sendiri, sementara yang mampu mengirimkan transaksi lebih lambat dari orang lain akan memiliki "pandangan terakhir" gratis tentang apakah akan mengalahkan tawaran orang lain untuk suatu peluang, Salah satunya dapat menciptakan masalah seleksi yang merugikan yang pada akhirnya menghambat persaingan.

Sayangnya, sementara properti pertama akan mudah ditegakkan di layer protokol, menegakkan properti lain tanpa kepercayaan adalah masalah terbuka.

Dengan tidak adanya penegakan di layer protokol, sequencer tunggal yang berkomitmen pada aturan-aturan ini perlu dipercaya untuk tidak menyimpang dari mereka, dan jika pengusul mengalihdayakan pembangunan blok ke lelang memaksimalkan pendapatan yang kompetitif (seperti Ethereum L1 MEV-Boost), blok kemungkinan tidak akan mengikuti mereka.

Masalah-masalah ini dapat "diselesaikan" dengan sequencer tepercaya tunggal yang berkomitmen untuk menggunakan pemesanan prioritas kompetitif untuk pembangunan blok. Mereka juga dapat dipecahkan dengan mekanisme terdesentralisasi menggunakan beberapa kombinasi konsensus, kriptografi, dan / atau lingkungan eksekusi tepercaya, seperti Angstrom Sorella, SUAVE Flashbots, Leaderless Auctions, atau Multiplicity.

Blok penuh

Satu pengecualian untuk operasi normal pajak MEV terjadi ketika blok benar-benar penuh. Dalam hal ini, pengusul blok mungkin harus meninggalkan transaksi dengan prioritas lebih rendah, daripada hanya memasukkannya di akhir blok. Karena transaksi yang berinteraksi dengan aplikasi MEV-pajak cenderung memiliki biaya prioritas yang sangat rendah, aplikasi tersebut cenderung ramai oleh aplikasi yang tidak menggunakan pajak MEV, atau yang memiliki pajak MEV sangat rendah. Namun, dalam rantai yang menggunakan mekanisme seperti EIP-1559 untuk menetapkan biaya dasar terpisah, seharusnya relatif jarang blok benar-benar penuh. Selain itu, mengingat bahwa beberapa transaksi perlu ditunda ketika blok penuh, menunda transaksi yang menyatakan urgensi yang lebih rendah dengan menetapkan pajak MEV yang lebih tinggi mungkin merupakan hasil yang wajar.

Transaksi yang dikembalikan

MEV pajak secara efektif bergantung pada lelang blok tunggal di mana setiap "tawaran" adalah transaksi. Salah satu kelemahan dari lelang tersebut adalah bahwa kehilangan tawaran umumnya akan mengakibatkan transaksi yang dikembalikan dimasukkan secara onchain, membayar sejumlah biaya dasar dan membuat rantai padat.

Jika sequencer dapat mengecualikan transaksi yang gagal sepenuhnya, itu akan meringankan masalah ini, meskipun itu bisa sulit diterapkan bahkan dengan sequencer terpusat. (Itu juga tidak akan secara ketat mematuhi properti sensor-resistensi yang dijelaskan di atas, meskipun definisi itu dapat disesuaikan.) Sequencer yang lebih canggih mungkin dapat mengoptimalkan proses ini dengan memungkinkan transaksi untuk menentukan lelang kontroversial mana yang mereka ikuti, memberikan informasi yang cukup kepada sequencer untuk melewati transaksi berikutnya yang diketahuinya akan gagal.

Membocorkan maksud pengguna

MEV pajak hanya berfungsi jika ada persaingan di antara pencari, yang berarti peluang perlu diketahui secara luas. Untuk aplikasi seperti AMM, di mana peluang terlihat onchain, itu harus terjadi secara alami. Tetapi untuk aplikasi seperti perutean berbasis niat atau lelang backrunning, itu berarti aplikasi mungkin perlu membagikan maksud pengguna dengan pencari.

Dalam beberapa kasus, privasi sementara yang hilang dari penyiaran maksud pengguna sebelum dipenuhi dapat membocorkan nilai dengan cara yang tidak dapat ditangkap kembali oleh pajak MEV.

Misalnya, Alice ingin membeli token likuiditas rendah menggunakan lelang backrunning protokol dijelaskan di atas. Dia menerbitkan niat yang ditandatangani untuk dompet kontrak pintarnya untuk membeli token itu di AMM, menetapkan beberapa toleransi selip. Pencari dapat berlomba untuk mendorong harga token itu ke toleransi slippage-nya dalam transaksi prioritas tinggi, tanpa mengisi pesanan pengguna. Pemenangnya, Bob, kemudian dapat secara non-kompetitif mengisi niat Alice dengan memasukkan dan menjalankannya kembali dalam transaksi prioritas rendah, sehingga mengapit perdagangan Alice dan memberinya harga yang lebih buruk sambil menghindari pajaknya yang MEV. Masalah serupa dapat terjadi dengan pembelian NFT.

Perhatikan bahwa serangan seperti itu akan berisiko bagi Bob, karena dia tidak akan dapat menjamin atomisitas antara membeli token dan menjualnya kepada Alice. Bob yang naif bisa turun menjadi korban jebakan "sandwich ripping" di mana Alice menerbitkan niat untuk membeli token yang tidak berharga dari dirinya sendiri, menyebabkan Bob membelinya untuk mengantisipasi mengapit perdagangannya, tetapi Alice mencabut niatnya sebelum Bob dapat menyelesaikan sandwich.

Aplikasi mungkin juga dapat mengurangi ini dengan membatasi set pencari dengan mana mereka berbagi maksud dan memantau perilaku mereka, seperti yang dilakukan oleh banyak lelang orderflow yang ada.

Dimungkinkan juga untuk menggabungkan pajak MEV dengan fitur pembangun yang sadar privasi seperti yang dibayangkan dalam desain Flashbots untuk SUAVE.

Akhirnya, dalam kasus di mana Alice memutuskan bahwa biaya berbagi niatnya lebih besar daripada manfaat dari pencarian kompetitif, dia dapat membangun transaksi sendiri dan mengirimkannya langsung ke blok. Seperti dibahas di atas, implementasi ideal pemesanan prioritas kompetitif akan memberikan privasi pra-transaksi dari pengusul blok.

Diskusi dan pekerjaan sebelumnya

Lelang gas prioritas. Beberapa dinamika pemesanan prioritas dalam blockchain terdesentralisasi dipelajari dalam makalah Flash Boys 2.0, yang menciptakan istilah "nilai yang dapat diekstraksi penambang." Makalah itu mengamati bahwa Ethereum penambang (ketika jaringan itu menggunakan proof-of-work) sudah memesan transaksi berdasarkan prioritas, dan bahwa arbitrase mengandalkan perilaku itu untuk berpartisipasi dalam "lelang gas prioritas" di mana mereka menawar hak untuk dimasukkan pertama dalam blok, yang menyebabkan banyak MEV dari arbitrase pertukaran terdesentralisasi yang diperoleh penambang.

Pertama datang, pertama dilayani. Beberapa upaya mitigasi MEV melalui aturan pemesanan transaksi, seperti Themis atau Arbitrum One's current sequencer,7 telah berfokus pada penegakan aturan pemesanan yang berbeda, pertama datang, pertama dilayani (kadang-kadang disebut "pemesanan adil") di mana pengusul blok harus pesanan transaksi di pesanan di mana mereka melihatnya.

Urutan prioritas mengambil pendekatan yang berbeda — memperlakukan transaksi yang tiba dalam periode tertentu secara setara, dan memesannya berdasarkan prioritas yang dinyatakan.

Pertama datang, pertama dilayani sulit untuk menegakkan atau bahkan mendefinisikan dalam lingkungan jaringan nyata dengan lebih dari satu validator. Ini juga dapat mengakibatkan balapan latensi yang boros dan spam bahkan dengan satu sequencer tepercaya. Akhirnya, pajak MEV mungkin dapat menghilangkan jenis MEV tertentu yang tidak dapat dilakukan oleh pemesanan siapa cepat dia dapat, seperti keuntungan arbitrase dari "lompatan" harga aset yang terputus-putus. Keuntungan potensial dari pemesanan prioritas atas pemesanan pertama datang pertama dilayani agak terkait dengan keuntungan dari waktu diskrit dibandingkan pertukaran waktu berkelanjutan yang dibahas dalam Budish, Cramton, Shim (2015).

Sementara itu, sementara urutan prioritas tampaknya membocorkan nilai ke MEV secara default, posting ini menunjukkan bagaimana aplikasi dapat dirancang untuk menangkapnya kembali.

Pembagian biaya. Blast, sebuah Ethereum L2, berbagi sebagian dari biaya prioritas dan biaya dasar dengan smart contract yang diakses dalam transaksi.

MEV pajak memungkinkan sesuatu yang serupa (setidaknya untuk biaya prioritas), tetapi dapat diimplementasikan pada lapisan aplikasi pada rantai apa pun yang menggunakan pemesanan prioritas kompetitif, tanpa dukungan khusus untuk pembagian biaya. Mereka juga memungkinkan aplikasi untuk mendefinisikan pajak mereka sendiri sebagai fungsi khusus dari biaya prioritas, memberikan lebih banyak fleksibilitas dan berpotensi menghasilkan komposabilitas yang lebih besar dari aplikasi yang sadar MEV.

Trustless solusi. Posting ini berfokus pada motivasi bagi platform untuk menggunakan urutan prioritas kompetitif — dan cara untuk memanfaatkan platform yang melakukannya — daripada membahas cara menegakkannya tanpa kepercayaan.

Telah ada diskusi sebelumnya yang signifikan dari masing-masing properti lain yang diperlukan untuk pemesanan prioritas kompetitif. Misalnya, dalam Fox, Pai, Resnick (2023), penulis membahas kerentanan dalam lelang onchain tanpa adanya resistensi pensensoran, dan menggambarkan desain untuk lelang tahan sensor menggunakan beberapa pengusul bersamaan. Namun, mereka tidak menyarankan pemesanan khusus untuk transaksi.

Ada penelitian lain tentang membangun mekanisme untuk membangun blok yang diminimalkan kepercayaan, termasuk Flashbots's SUAVE, Sorella's Angstrom, Leaderless Auctions, Espresso and Offchain Labs' @espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">decentralized Timeboost, dan mengamanatkan penyertaan transaksi publik oleh Péter Szilági.

Kesimpulan

Kami berharap posting ini mendorong L2 untuk mempertimbangkan menggunakan pemesanan prioritas (seperti yang didukung secara default di OP Stack) dan menginspirasi aplikasi untuk mencoba pajak MEV jika didukung.

Kami juga berharap ini memotivasi penelitian lebih lanjut tentang protokol untuk pemesanan prioritas kompetitif yang diminimalkan kepercayaan pada L1 dan L2. Jika Anda tertarik untuk berkolaborasi dalam masalah itu, dan membaca ini sebelum Kamis, 6 Juni, Anda masih dapat mengajukan permohonan TLDR Fellowship untuk mengerjakan sequencer L2 tahan >MEV dengan Dan. Atau jangan ragu untuk menghubungi dan@paradigm.xyz dan dave@paradigm.xyz dengan ide-ide!

Catatan

kaki
1. Dalam posting ini, kami menggunakan "pengusul" untuk merujuk pada aktor atau proses yang menentukan transaksi apa yang termasuk dalam blok tertentu. Pada Ethereum L2, peran ini biasanya diisi oleh "sequencer." Pada Ethereum L1, diisi oleh validator Ethereum khusus yang disebut pengusul, meskipun seringkali pengusul mengalihdayakan tugas membangun blok ke lelang kompetitif di mana "relayer" dan "pembangun" berpartisipasi. Rincian tentang bagaimana tanggung jawab ini dibagi berada di luar cakupan posting ini. ↩
2. Biaya prioritas per gas sebenarnya tidak ditentukan secara eksplisit dalam transaksi, tetapi dapat dihitung di dalamnya. Transaksi menentukan harga gas, tetapi Ethereum juga membebankan biaya dasar, yang diambil dari harga gas dan dibakar. Biaya dasar harus diabaikan untuk tujuan pajak MEV, karena tidak berada di bawah kendali transaktor. Biaya prioritas per gas — harga untuk bagian dari biaya transaksi yang masuk ke pengusul blok — dapat dihitung dalam Solidity sebagai priorityGasPrice = tx.gasprice - block.basefee. ↩
3. Atau, kita bisa mendefinisikan "MEV" untuk mengecualikan keuntungan pencari dan hanya merujuk pada nilai yang akan masuk ke validator. ↩
4. Perhatikan bahwa proposerPriorityFee — sama dengan priorityFeePerGas kali total gas yang digunakan dalam transaksi — sebenarnya tidak dapat dihitung selama kontrak, karena tidak ada cara untuk mengetahui berapa banyak gas yang akan digunakan transaksi. Namun, ini umumnya tidak masalah, karena yang kita butuhkan hanyalah batas atas untuk itu. Agar aman, Anda dapat melipatgandakan priorityFeePerGas dengan 30 juta — gas maksimum saat ini dalam blok Ethereum. Melebih-lebihkan nilai ini hanya akan berarti bahwa pajak MEV menangkap persentase MEV yang lebih besar. ↩
5. Dengan asumsi transaksi tidak boleh lebih dari 30 juta gas, prioritasFeePerGas sebesar 50.000 akan menghasilkan pembayaran gas sebesar 1500 gwei — sekitar $ 0,006 dengan harga ETH $ 4000. ↩
6. Dalam kasus di mana priorityFeePerGas ditetapkan sehingga keuntungan arbitrageur adalah nol, perdagangan arbitrase memaksimalkan keuntungan harus sesuai dengan perdagangan yang sama pada AMM memaksimalkan fungsi. Membuktikan ini dibiarkan sebagai latihan bagi pembaca. ↩
7. Arbitrum telah membahas mengganti ini dengan bentuk pemesanan prioritas yang disebut Timeboost, tetapi itu belum dimasukkan ke dalam produksi pada tulisan ini. ↩

Penafian:

1. Artikel ini dicetak ulang dari [paradigma]. Semua hak cipta adalah milik penulis asli [Dan Robinson &; Dave White]. Jika ada keberatan dengan cetak ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.

2. Penafian Kewajiban: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata milik penulis dan bukan merupakan saran investasi.

3. Penerjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.