Pengantar

Dalam pos ini, kami memperkenalkan pajak MEV, sebuah mekanisme yang dapat digunakan oleh aplikasi sembarang untuk menangkap MEV mereka sendiri.

Mekanisme ini bisa digunakan hari ini pada OP Stack L2s seperti OP Mainnet, Base, dan Blast, karena para pembuat blok pada rantai-rantai tersebut mengikuti serangkaian aturan yang kami sebut dengan urutan prioritas kompetitif.

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

Pajak MEV adalah teknik sederhana yang membuka ruang desain yang luas. Anda dapat menganggapnya sebagai memungkinkan setiap aplikasi pada rantai untuk menjalankan lelang MEV khususnya sendiri, tanpa memerlukan infrastruktur offchainnya sendiri, hanya dengan menyambungkan ke satu lelang bersama yang dijalankan oleh penyarankan blok.

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

• Pengalihan pertukaran terdesentralisasi (DEX) yang mengoptimalkan harga yang diterima oleh penukar
• Pembuat pasar otomatis (AMM) yang meminimalkan kerugian-vs-rebalancing (LVR) yang dialami oleh penyedia likuiditas
• Dompet yang memungkinkan pengguna mereka menangkap MEV "backrunning" yang diciptakan oleh transaksi mereka

Tetapi ada yang harus diperhatikan. Pajak MEV hanya berfungsi jika para proposer blok secara ketat mengikuti aturan urutan prioritas yang kompetitif, yang mencakup pengurutan transaksi berdasarkan biaya prioritas tanpa sensor, melihat secara sembunyi-sembunyi, atau menunda apapun. Jika para proposer blok menyimpang dari aturan tersebut, mereka dapat menghindari pajak MEV untuk menangkap nilai itu untuk diri mereka sendiri. Oleh karena itu, saat ini, pajak MEV bergantung pada kepercayaan pada pengurut L2, dan kemungkinan besar tidak akan berfungsi sama sekali pada Ethereum L1, di mana pembangunan blok didominasi oleh seorang lelang pembangun kompetitifyang memaksimalkan pendapatan bagi penawar.

Namun, kekuatan dan fleksibilitas pajak MEV menunjukkan bahwa urutan prioritas mungkin merupakan pilihan yang tepat untuk platform yang dapat menyediakannya hari ini. Dan kesederhanaan relatif dari urutan prioritas yang kompetitif menunjukkan bahwa mungkin ada cara yang layak untuk menegakkannya dengan cara terdesentralisasi, tanpa harus mempercayai satu penentu tunggal. Kami berharap pos ini mendorong kerja lebih lanjut tentang masalah itu.

Pemesanan Prioritas

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

Tidak ada aturan dalam protokol Ethereum bahwa transaksi dalam blok harus diurutkan dengan rakus berdasarkan priorityFeePerGas yang menurun. Namun, itu adalah cara populer untuk membangun blok—misalnya, itu adalah algoritma default yang digunakan oleh sequencer dari Tumpukan OPrantai, serta geth dan reth. Tidak hanya urutan prioritas memungkinkan transactor untuk secara efisien mengekspresikan urgensi transaksi mereka, itu juga secara alami mengalirkan jenis MEV tertentu ke proposer blok.

Hal itu terjadi karena pengurutan prioritas mengubah persaingan untuk MEV menjadi sebuahlelang gas prioritasKetika ada kesempatan untuk mendapatkan keuntungan dari berinteraksi dengan rantai, seperti dengan arbitrase AMM terhadap pertukaran terpusat, pencari bersaing untuk mengklaim kesempatan tersebut terlebih dahulu. Jika rantai menggunakan urutan prioritas untuk menentukan inklusi dan urutan transaksi, para pencari bersaing dengan menetapkan biaya prioritas tinggi pada transaksi mereka.

Dalam skenario kompetitif di mana keuntungan tanpa risiko bersaing hingga nol, pencari yang menang seharusnya akhirnya membayar jumlah penuh MEV dalam biaya prioritas.3Jadi jika ada 100 ETH keuntungan yang bisa didapatkan dari berinteraksi dengan kontrak, transaksi pertama untuk mengklaimnya akan menetapkan biaya prioritas sebesar 100 ETH. (Kami membahas beberapa catatan kaki terkait hal ini di bagian Batasan).

Pajak MEV

Misalkan sebuah kontrak pintar ingin menangkap MEV dari setiap transaksi yang berinteraksi dengannya. Ada perpustakaan besar penelitian tentang berbagai cara aplikasi khusus di mana kontrak pintar bisa mencoba menangkap MEV mereka sendiri.

Tapi sebenarnya, kita tidak perlu tahu apa pun tentang aplikasi. Jika kita tahu bahwa blok sedang dibangun melalui urutan prioritas yang kompetitif, maka kita memiliki satu sinyal universal untuk jumlah MEV dalam transaksi: biaya prioritas.

Kami menyarankan agar kontrak pintar dapat melihat biaya prioritas transaksi dan mengenakan biaya sendiri sebagai fungsi peningkatan dari itu. Sebagai contoh, kontrak mungkin memerlukan siapa pun yang memanggilnya untuk mentransfer applicationPriorityFee = 99 * proposerPriorityFee dalam ETH ke kontrak.4

Biaya baru ini dibayar oleh pencari yang mengirim transaksi, sehingga memengaruhi perilaku pencari tersebut. Jika ada 100 MEV dalam sebuah peluang, transaksi pemenang sekarang hanya akan menetapkan biaya prioritas sebesar 1 ETH, karena itu akan menghasilkan pembayaran total sebesar 100 ETH (1 ETH untuk proposer blok, dan 99 ETH untuk kontrak pintar). Biaya prioritas yang lebih tinggi akan membuat transaksi tidak menguntungkan; biaya prioritas yang lebih rendah akan menyebabkan kehilangan peluang kepada pesaing yang menetapkan biaya lebih tinggi. Ini berarti kontrak pintar telah menangkap 99% dari MEV dalam transaksi tersebut.

Kami menyebut biaya tambahan ini yang dikenakan oleh kontrak pintar sebagai pajak MEV. Pajak MEV memungkinkan sebuah aplikasi untuk merampas urutan prioritas demi keuntungannya sendiri, memungkinkannya untuk merebut kembali MEV untuk penggunanya daripada bocor ke proposer blok.

Jika biaya ini meningkat dengan cukup cepat sebagai fungsi dari priorityFeePerGas, maka hanya jumlah MEV yang dapat diabaikan yang akan mengakumulasi pada penawar. Karena priorityFeePerGas dihitung dalam wei (satu miliar dari satu miliar dari satu ETH), kita memiliki banyak presisi untuk bekerja. Misalnya, selama pajak MEV cukup sensitif sehingga priorityFeePerGas sebesar 50.000 akan menghasilkan pajak yang sangat tinggi, maka total pembayaran kepada penawar akan kurang dari $0.01.5

Namun, ada pengecualian penting. Seperti yang dibahas dalam bagian Batasan, pajak MEV hanya berfungsi jika para pembuat blok mengikuti aturan tertentu—apa yang kami sebut sebagai “urutan prioritas yang kompetitif”—daripada menyimpang dari aturan tersebut untuk memaksimalkan pendapatan mereka sendiri. Menegakkan aturan-aturan ini secara tidak dapat dipercaya merupakan masalah yang terbuka.

Penangkapan MEV aplikasi tunggal

Di sini kami menguraikan bagaimana, pada rantai yang dijamin menggunakan urutan prioritas kompetitif untuk membangun blok, pajak MEV dapat digunakan untuk mengatasi tiga masalah penting dalam MEV: memungkinkan antarmuka DEX meningkatkan pelaksanaan perdagangan untuk swapper, memungkinkan AMM mengurangi kerugian arbitrase untuk LP mereka, dan memungkinkan dompet mengurangi kebocoran MEV untuk pengguna mereka dengan menjual hak untuk backrun pengguna.

router DEX

Dalam protokol routing DEX berbasis tujuan seperti UniswapXdan1inch Fusion, seorang pengguna (Alice) menandatangani niat untuk menukar, dan pencari bersaing untuk mengarahkan atau mengisi niat tersebut dengan harga terbaik untuk Alice.

Versi terbaru UniswapX menggunakan dua mekanisme untuk menjalankan kompetisi tersebut: lelang Belanda di mana harga batas Alice berubah seiring waktu sampai seorang pencari mengisinya, dan lelang permintaan penawaran awal (RFQ) di luar rantai untuk menetapkan harga awal lelang Belanda tersebut.

Di platform yang menjamin pengaturan prioritas yang kompetitif, UniswapX dapat menggantikan hal ini dengan mekanisme tunggal: pajak MEV. Ini bisa diimplementasikan dengan membuat pengguna menandatangani pesanan yang dapat segera diisi oleh siapa pun, tetapi dengan harga eksekusi yang diatur sebagai fungsi dari prioritas transaksi.

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

Pencari akan bersaing untuk mengisi pesanan Alice dengan mengirimkan transaksi. Transaksi mana pun yang memiliki biaya prioritas tertinggi dan tidak membatalkan akan mendapatkan kesempatan untuk mengisi pesanan, yang seharusnya menjamin bahwa penukar mendapatkan harga terbaik yang dapat ditemukan oleh para pencari. (Beberapa pengecualian untuk ini dibahas dalam bagian Batasan.)

Jika harga minimum Alice adalah $3,000 dan harga saat ini dari ETH adalah $3,500, priorityFeePerGas dalam transaksi pemenang akan menjadi sekitar 50,000. (Perhatikan bahwa dalam transaksi yang membutuhkan 200,000 gas, ini akan menghasilkan pembayaran hanya sekitar 10 miliar wei—sekitar $0.000035—kepada proposer blok.)

Ini memiliki beberapa manfaat potensial dibandingkan dengan mekanisme yang digunakan dalam UniswapX saat ini.

Pesanan yang menggunakan pajak MEV bisa diselesaikan lebih cepat dan dengan harga yang lebih baik dibandingkan dengan pesanan yang menggunakan lelang Belanda. Seperti yang dibahas di kertas ini, lelang Dutch onchain bocor sedikit nilai ke MEV karena pergerakan harga antara blok, dan mungkin memerlukan banyak blok untuk diselesaikan. Sebaliknya, pesanan yang menggunakan pajak MEV biasanya dapat diselesaikan dalam blok berikutnya sambil menangkap sebagian besar MEV mereka.

Berbeda dengan RFQ di luar rantai, pelelangan untuk mengisi pesanan yang menggunakan pajak MEV akan terjadi secara atomik bersamaan dengan eksekusi transaksi di rantai. Ini berarti bahwa penawar pemenang dapat dipastikan bahwa mereka hanya berkewajiban untuk mengisi pesanan jika transaksi mereka di rantai berhasil. Hal ini bisa memudahkan likuiditas di rantai seperti AMM untuk bersaing dengan likuiditas di luar rantai, artinya UniswapX bisa berfungsi sebagai router yang lebih efektif untuk sistem multi-pool seperti Uniswap v4.

AMM

Biasanya, AMM bocor nilai ke para arbitrager yang bertransaksi melawan harga yang sudah basi di puncak blok, seperti yang dibahas di kerugian-vs-rebalancing kertasKami dapat menggunakan pajak MEV untuk membuat AMM menangkap MEV tersebut. Untuk menjaga agar hal-hal tetap sederhana, kita akan membahas bagaimana ini mungkin berfungsi pada AMM tanpa likuiditas terkonsentrasi. (Jika Anda tertarik dengan bagaimana masalah semacam ini dapat dipecahkan dengan likuiditas terkonsentrasi, Sorellaakan segera mempublikasikan satu solusi.)

Sebuah AMM dapat menangkap MEV dengan cara membebankan biaya ekstra sebagai fungsi dari biaya prioritas pada transaksi, memungkinkannya untuk melelang hak untuk melakukan perdagangan pertama dalam blok. Ada banyak cara untuk menghitung dan menetapkan biaya tersebut. Kita akan membahas salah satu yang mungkin netral—menetapkannya dalam unit likuiditas pool, sqrt(xy). Transaksi pemenang akan menjadi transaksi yang paling meningkatkan likuiditas pool.

Ketika mengeksekusi transaksi pertama di sebuah pool dalam sebuah blok, alih-alih menegakkan kondisi x_endy_end > x_startpada awalnya, kolam renang bisa menegakkan kondisi (dengan a sebagai beberapa konstanta):

x_endy_end > (akar kuadrat(x_starty_start) + a*priorityFeePerGas)^2

Rumus ini akan memberikan insentif kepada pedagang arbitrase untuk melakukan perdagangan pada harga sebenarnya, dan setelah perdagangan tersebut, harga tengah di kolam seharusnya adalah harga sebenarnya.6

Setelah transaksi pertama itu, perdagangan bisa berjalan seperti yang terjadi di Uniswap v2, dengan biaya tukar tetap. Transaksi yang tidak terinformasi yang ingin berdagang di dalam kolam tanpa membayar pajak MEV tambahan akan menetapkan biaya prioritas rendah.

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

Lelang backrunning

Deskripsi di atas menunjukkan bagaimana beberapa aplikasi tertentu bisa dirancang untuk menghindari kebocoran MEV. Namun, bagaimana jika sebuah dompet ingin mencoba membantu pengguna agar dapat menangkap MEV yang mereka hasilkan dari transaksi sembarangan yang berinteraksi dengan aplikasi apa pun, bahkan yang tidak menggabungkan pajak MEV?

Sebagai contoh, ketika Alice melakukan transaksi besar di sebuah AMM, terkadang dia menciptakan peluang arbitrase bagi "backrunners" untuk mengembalikan harga. Hal ini biasanya bocor ke MEV, daripada pergi ke Alice.

MEV-SharedanPenghalang MEVadalah dua protokol yang memungkinkan pengguna untuk menangkap MEV dari transaksi mereka, tetapi mereka bergantung pada sistem lelang offchain yang kompleks.Ruang Desain Lelang Aliran Pesananmendeskripsikan beberapa solusi lainnya.

Pajak MEV, ketika digabungkan 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 diperdagangkan di AMM, Alice menandatangani niat yang bisa diajukan oleh siapa pun ke dompet kontrak pintar Alice untuk menyebabkannya melakukan tindakan tersebut. Dompet kontrak pintar Alice mengenakan pajak MEV kepada siapa pun yang mengirimkan transaksi tersebut, yang dibayarkan kepada Alice.

Pencari yang mengirimkan niat Alice akan memiliki hak eksklusif untuk kembali menjalankannya, karena mereka dapat melakukannya secara atomik dalam transaksi yang sama. Akibatnya, jika pencarian bersifat kompetitif, seluruh keuntungan dari kembali menjalankan Alice seharusnya diperoleh oleh Alice melalui pajak MEV-nya.

Perlu diingat bahwa sistem ini mungkin tidak selalu melindungi pengguna dari serangan yang melibatkan frontrunning transaksi pengguna, karena transaksi yang melibatkan frontrunning pengguna mungkin dapat menghindari membayar pajak MEV kepada pengguna tersebut. Masalah ini (dan beberapa mitigasi yang mungkin dilakukan) dibahas secara lebih detail dalam bagian Pembatasan di bawah ini. Meskipun demikian, ini setidaknya dapat menjadi penyempurnaan pada sistem yang menggunakan mempool publik tanpa adanya mitigasi apapun.

Penggunaan lain

Selain contoh-contoh ini, penggunaan potensial lain dari pajak MEV bisa mencakup hampir segala hal yang saat ini menggunakan lelang offchain atau Belanda, seperti:

• Protokol untuk orakel untuk menangkap nilai ekstraksi orakel yang mereka buat, sepertiOval
• Lelang Refinancing di protokol peminjaman yang dijaminkan NFT seperti Campuran
• Likuidasi protokol peminjaman yang kebocoran nilai yang lebih sedikitdari lelang Belanda

Pengambilan MEV lintas-aplikasi

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

Jika hanya satu dari aplikasi tersebut memiliki pajak MEV, maka seluruh MEV dari transaksi tersebut harus masuk ke aplikasi dengan pajak MEV, terlepas dari seberapa tinggi atau rendahnya pajak MEV tersebut.

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 yang dikenai pajak MEV seperti yang dijelaskan di atas melawan AMM yang dikenai pajak MEV?

Dalam kasus tersebut, jumlah relatif dari MEV berlebih yang ditangkap oleh setiap aplikasi ditentukan oleh bagaimana aplikasi tersebut mengatur pajak MEV mereka. Jika nilai app_i yang dikenakan pajak MEV diberikan oleh fungsi pajak_i(prioritas), maka prioritas transaksi pemenang dapat ditentukan dengan memecahkan prioritas dalam persamaan ini:

pajak_1(priorityPerGas) + pajak_2(priorityPerGas) = total MEV

(Secara teknis, kita bisa menambahkan satu istilah ketiga untuk priorityPerGas * gasUsed untuk menghitung biaya prioritas yang dibayarkan kepada pembuat blok, tetapi kita akan mengabaikannya karena, seperti yang dibahas dalam Lampiran A, kemungkinan besar akan diabaikan dalam kondisi normal.)

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

a_1 prioritasPerGas + a_2prioritasPerGas = MEV

prioritasPerGas = MEV/(a_1 + a_2)

pajak_1(prioritasPerGas) = (a_1/(a_1+a_2))*MEV

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

Ketika menetapkan pajak MEV sendiri, sebuah aplikasi menghadapi tradeoff—pajak yang lebih tinggi memungkinkannya untuk menangkap bagian yang lebih besar dari MEV lintas-aplikasi saat terjadi, tetapi berarti aplikasi tersebut bisa kehilangan sebagian MEV lintas-aplikasi jika ada cara bersaing untuk mengekstraknya. Sebagai contoh, jika terdapat AMM yang mengenakan pajak MEV pada setiap perdagangan, maka pesanan UniswapX dengan pajak MEV mungkin lebih mungkin diisi oleh AMM yang berbeda atau oleh pengisi offchain.

Dalam banyak kasus, mungkin ada keseimbangan di mana dua aplikasi merancang pajak MEV mereka untuk berbagi MEV dengan cara yang memaksimalkan kesejahteraan masing-masing. Sebagai contoh, AMM pajak MEV kemungkinan besar ingin menangkap nilai dari seorang pedagang yang terinformasi tunggal di dekat puncak blok, tetapi kemudian ingin memberikan likuiditas kepada pedagang dan aplikasi lainnya (termasuk yang menggunakan pajak MEV) dengan biaya tetap rendah. Dalam hal itu, AMM kemungkinan akan menetapkan pajak MEV yang relatif rendah (misalnya, $0.00001(priorityFeePerGas), sehingga transaksi arbitrase (jika ada) terjadi lebih awal dalam blok, dan kemudian tidak dikenakan pajak MEV pada transaksi berikutnya dalam blok tersebut. Aplikasi seperti UniswapX yang ingin berinteraksi dengan AMM dapat menetapkan pajak MEV yang jauh lebih tinggi (misalnya $0.01 priorityFeePerGas), untuk memastikan bahwa transaksi mereka disertakan setelah kolam sudah diarbitrase. Dengan pajak relatif tersebut, AMM akan berakhir diarbed terlebih dahulu bahkan jika hanya ada $1 MEV di dalamnya dan $50,000 MEV dalam pesanan UniswapX.

Kami berpikir ini adalah ruang desain yang luas layak untuk studi masa depan.

Batasan

Pajak MEV memiliki beberapa komplikasi dan kekurangan. Kami pikir masing-masing ini adalah area yang menarik untuk penelitian masa depan.

Incentive incompatibility

Pajak MEV tidaklah sesuai insentif bagi penyarankan blok yang monopoli. Mereka hanya berfungsi jika ada kompetisi yang adil untuk inklusi transaksi, yang hanya dapat terjadi jika penyarankan blok mengikuti aturan yang kita sebut sebagai “urutan prioritas kompetitif,” daripada memaksimalkan pendapatan mereka sendiri. Secara informal dan tidak lengkap, kami menyarankan bahwa aturan-aturan ini harus mencakup:

• Pemesanan prioritas. Transaksi dalam blok harus diurutkan secara menurun berdasarkan priorityFeePerGas.
• Ketahanan sensor. Jika proposer blok menerima transaksi t1 selama blok, dan blok tersebut entah tidak penuh atau termasuk beberapa transaksi t2 sedemikian rupa sehingga t2.priorityFeePerGas < t1.priorityFeePerGas, maka blok harus menyertakan transaksi t1.
• Privasi sebelum transaksi. Penyedia blok harus menerima transaksi melalui ujung pribadi dan tidak boleh membagikan transaksi tersebut kepada siapa pun sebelum mengikatkan pada blok, atau menggunakan konten dari transaksi tersebut sebagai input dalam membangun transaksi mereka sendiri.
• Tidak ada peninjauan terakhir. Penyedia blok harus menetapkan waktu blok yang pasti sebelumnya di mana 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 yang bersaing 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 "tampilan 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 lapisan protokol, menegakkan properti lainnya tanpa kepercayaan adalah masalah terbuka.

Tanpa penegakan di lapisan protokol, seorang urutkan tunggal yang berkomitmen pada aturan-aturan ini perlu dipercayai untuk tidak menyimpang darinya, dan jika proposer menyewa pembangunan blok ke lelang maksimal pendapatan yang kompetitif (seperti Ethereum L1’s MEV-Boost) blocks kemungkinan besar tidak akan mengikuti mereka.

Masalah-masalah ini dapat "diselesaikan" dengan seorang urutan tunggal yang tepercaya yang berkomitmen untuk menggunakan urutan prioritas kompetitif untuk membangun blok. Mereka juga dapat diselesaikan dengan mekanisme terdesentralisasi menggunakan beberapa kombinasi konsensus, kriptografi, dan/atau lingkungan eksekusi tepercaya, seperti Sorella's Angstrom, SUAVE Flashbots, Lelang Tanpa Pemimpin, atau Kelipatan.

Blok penuh

Salah satu pengecualian dari operasi normal pajak MEV terjadi ketika blok-blok benar-benar penuh. Dalam kasus tersebut, proposer blok mungkin harus meninggalkan transaksi-transaksi dengan prioritas lebih rendah, daripada hanya menyertakan mereka secara terlambat dalam blok. Karena transaksi yang berinteraksi dengan aplikasi yang dikenai pajak MEV cenderung memiliki biaya prioritas yang sangat rendah, aplikasi-aplikasi itu cenderung terdesak oleh aplikasi-aplikasi yang tidak menggunakan pajak MEV, atau yang memiliki pajak MEV yang sangat rendah. Namun, dalam rantai yang menggunakan mekanisme serupa EIP-1559 untuk menetapkan basefee terpisah, seharusnya cukup jarang untuk blok-blok benar-benar penuh. Selain itu, mengingat bahwa beberapa transaksi perlu ditunda ketika blok-blok penuh, menunda transaksi yang mengekspresikan urgensi yang lebih rendah dengan menetapkan pajak MEV yang lebih tinggi mungkin merupakan hasil yang wajar.

Transaksi yang dibalik

Pajak MEV sebenarnya bergantung pada lelang blok tunggal di mana setiap "penawaran" adalah transaksi. Salah satu kelemahan dari lelang tersebut adalah bahwa penawaran yang kalah umumnya akan mengakibatkan transaksi yang dibatalkan termasuk dalam rantai, membayar beberapa basefee dan mengganggu rantai.

Jika sebuah pengurutan dapat sepenuhnya mengesampingkan transaksi yang gagal, hal itu dapat mengurangi masalah ini, meskipun hal tersebut dapat sulit untuk diimplementasikan bahkan dengan pengurutan yang terpusat. (Ini juga tidak akan secara ketat mematuhi properti ketahanan terhadap sensorship yang dijelaskan di atas, meskipun definisi tersebut dapat disesuaikan.) Sebuah pengurutan yang lebih canggih mungkin dapat mengoptimalkan proses ini dengan memungkinkan transaksi untuk menentukan lelang yang kontroversial yang mereka ikuti, memberikan informasi yang cukup kepada pengurut untuk melewati transaksi berikutnya yang diketahuinya akan gagal.

Bocornya niat pengguna

Pajak MEV hanya akan berfungsi jika ada persaingan di antara pencari, yang berarti kesempatan tersebut perlu agak dikenal secara luas. Untuk aplikasi seperti AMM, di mana kesempatan tersebut terlihat di onchain, hal itu seharusnya terjadi secara alami. Tetapi untuk aplikasi seperti routing berbasis tujuan atau lelang backrunning, itu berarti aplikasi mungkin perlu membagikan niat pengguna dengan pencari.

Dalam beberapa kasus, kehilangan privasi sementara dari penyiaran niat pengguna sebelum terpenuhi dapat bocor nilai dengan cara yang tidak dapat diambil kembali oleh pajak MEV.

Sebagai contoh, misalkan Alice ingin membeli token dengan likuiditas rendah menggunakan protokol pelelangan backrunning yang dijelaskan di atas. Dia mempublikasikan niat yang ditandatangani untuk dompet kontrak pintarnya untuk membeli token tersebut di AMM, menetapkan beberapa toleransi slippage. Pencari bisa berlomba-lomba mendorong harga token tersebut ke toleransi slippage-nya dalam transaksi prioritas tinggi, tanpa mengisi pesanan pengguna. Pemenang, Bob, kemudian bisa mengisi niat Alice tanpa bersaing dengan menyertakannya dan backrunning dalam transaksi prioritas rendah, dengan demikian menjepit perdagangan Alice dan memberinya harga yang lebih buruk sambil menghindari pajak MEV-nya. Masalah serupa bisa terjadi dengan pembelian NFT.

Perlu diperhatikan bahwa serangan semacam itu akan berisiko bagi Bob, karena dia tidak akan dapat menjamin atomisitas antara pembelian token dan penjualannya kepada Alice. Seorang Bob yang naif bisa menjadi korban perangkap 'sandwich ripping' di mana Alice mempublikasikan niat untuk membeli token tak berharga dari dirinya sendiri, menyebabkan Bob membelinya dengan harapan akan menyandwich perdagangannya, tetapi Alice mencabut niatnya sebelum Bob dapat menyelesaikan sandwich.

Aplikasi mungkin juga dapat meredakan hal ini dengan membatasi sekelompok pencari dengan siapa mereka berbagi niat dan memantau perilaku mereka, seperti yang dilakukan banyak lelang aliran pesanan yang ada.

Mungkin juga memungkinkan untuk menggabungkan pajak MEV dengan fitur pembangun yang peka privasi seperti yang diharapkan dalam desain Flashbots untuk ELEGAN.

Akhirnya, dalam kasus di mana Alice memutuskan bahwa biaya berbagi niatnya melebihi manfaat dari pencarian kompetitif, dia bisa membuat transaksi sendiri dan mengirimkannya langsung ke dalam blok. Seperti yang dibahas di atas, implementasi ideal dari urutan prioritas kompetitif akan memberikan privasi sebelum transaksi dari proposer blok.

Diskusi dan pekerjaan sebelumnya

Lelang gas prioritas. Beberapa dinamika urutan prioritas dalam blockchain terdesentralisasi telah diteliti di Flash Boys 2.0paper, yang menciptakan istilah “nilai ekstraksi penambang.” Makalah tersebut mengamati bahwa penambang Ethereum (saat jaringan tersebut menggunakan proof-of-work) sudah mengurutkan transaksi berdasarkan prioritas, dan para arbitraser mengandalkan perilaku tersebut untuk berpartisipasi dalam “lelang gas prioritas” di mana mereka menawar untuk hak untuk dimasukkan pertama dalam sebuah blok, yang menyebabkan sebagian besar MEV dari arbitrasi pertukaran terdesentralisasi mengalir ke penambang.

Siapa cepat dia dapat. Beberapa upaya dalam mitigasi MEV melalui aturan pemesanan transaksi, seperti ThemisatauSequencer saat ini dari Arbitrum One,7Telah berfokus pada memberlakukan aturan pemesanan yang berbeda, pertama datang, pertama dilayani (kadang-kadang disebut sebagai "urutan yang adil") di mana para penyusun blok harus memesan transaksi sesuai dengan urutan yang mereka lihat.

Pemesanan prioritas mengambil pendekatan yang berbeda—memperlakukan transaksi yang tiba dalam periode tertentu secara sama, dan mengurutkannya 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 menghasilkan balapan latensi yang boros dan spam bahkan dengan satu sequencer tepercaya. Akhirnya, pajak MEV mungkin dapat menghilangkan beberapa jenis MEV 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 dibandingkan pemesanan siapa cepat dia dapat agak terkait dengan keuntungan dari pertukaran waktu diskrit dibandingkan pertukaran waktu berkelanjutan yang dibahas dalam Budish, Cramton, Shim (2015).

Sementara itu, meskipun pemesanan prioritas tampaknya bocor nilai ke MEV secara default, posting ini menunjukkan bagaimana aplikasi dapat dirancang untuk mendapatkannya kembali.

Berbagi biaya. Blast, sebuah Ethereum L2,sahamsebagian dari biaya prioritas dan dasar dengan kontrak pintar yang diakses dalam sebuah transaksi.

Pajak MEV memungkinkan hal yang serupa (setidaknya untuk biaya prioritas), tetapi dapat diimplementasikan di lapisan aplikasi pada rantai apa pun yang menggunakan urutan prioritas yang kompetitif, tanpa dukungan khusus untuk berbagi biaya. Mereka juga memungkinkan aplikasi untuk menentukan pajak mereka sendiri sebagai fungsi kustom biaya prioritas, memberikan fleksibilitas lebih dan berpotensi menghasilkan komposisi yang lebih besar dari aplikasi yang sadar MEV.

Solusi tanpa kepercayaan. Pos ini berfokus pada motivasi untuk platform menggunakan urutan prioritas kompetitif—dan cara memanfaatkan platform yang melakukannya—daripada membahas cara menegakkannya tanpa kepercayaan.

Telah ada diskusi sebelumnya yang signifikan mengenai setiap properti lain yang diperlukan untuk urutan prioritas kompetitif. Sebagai contoh, di Fox, Pai, Resnick (2023), para penulis membahas kerentanan dalam lelang onchain dalam ketiadaan ketahanan sensor, dan menjelaskan desain untuk lelang tahan sensor menggunakan beberapa penawar bersamaan. Namun, mereka tidak menyarankan urutan spesifik untuk transaksi.

Telah ada penelitian lain tentang pembangunan mekanisme untuk pembangunan blok yang minim kepercayaan, termasuk Flashbots’sELEGAN, SorellaAngstrom Lelang Tanpa Pemimpin, Espresso dan Offchain Labs' @espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">decentralized Timeboost, dan pencantuman transaksi publik yang diwajibkanoleh Péter Szilági.

Kesimpulan

Kami berharap posting ini mendorong L2s untuk mempertimbangkan penggunaan pemesanan prioritas (sebagaimana didukung secara default di OP Stack) dan menginspirasi aplikasi untuk mencoba pajak MEV di tempat yang mendukung.

Kami juga berharap hal itu mendorong penelitian lebih lanjut tentang protokol untuk urutan prioritas kompetitif yang minim kepercayaan baik di L1 maupun L2. Jika Anda tertarik untuk berkolaborasi dalam masalah tersebut, dan sedang membaca ini sebelum Kamis, 6 Juni, Anda masih dapat mengajukan permohonan untuk menjadi Rekan TLDR untuk bekerja padaPengurutan L2 tahan MEVdengan Dan. Atau jangan ragu untuk menghubungi dan@paradigm.xyzdandave@paradigm.xyzdengan ide-ide!

Catatan kaki

1. Dalam posting ini, kami menggunakan istilah “proposer” untuk merujuk pada pelaku atau proses yang menentukan transaksi mana yang disertakan dalam blok tertentu. Pada Ethereum L2s, peran ini biasanya diisi oleh seorang “sequencer.” Pada Ethereum L1, peran ini diisi oleh validator Ethereum tertentu yang disebut proposer, meskipun seringkali proposer mengalihkan tugas membangun blok ke pelelangan kompetitif di mana “relayers” dan “builders” berpartisipasi. Detail bagaimana tanggung jawab ini dibagi di luar cakupan posting ini.↩
2. Biaya prioritas per gas sebenarnya tidak secara eksplisit ditentukan dalam transaksi, tetapi dapat dihitung di dalamnya. Transaksi menentukan harga gas, namun Ethereum juga menagih biaya dasar, yang diambil dari harga gas dan dibakar. Biaya dasar seharusnya diabaikan untuk tujuan pajak MEV, karena tidak berada di bawah kendali pengirim transaksi. Biaya prioritas per gas—harga untuk bagian dari biaya transaksi yang diberikan kepada pengusul blok—dapat dihitung dalam Solidity sebagai priorityGasPrice = tx.gasprice - block.basefee.↩
3. Atau, kita bisa dengan mudah mendefinisikan “MEV” untuk tidak termasuk keuntungan pencari apa pun dan hanya merujuk pada nilai yang akan diberikan kepada validator.↩
4. Perlu diperhatikan bahwa proposerPriorityFee—setara 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 oleh transaksi. Namun, hal ini umumnya tidak akan menjadi masalah, karena yang kita butuhkan hanyalah batas atasnya. Untuk lebih amannya, Anda bisa mengalikan priorityFeePerGas dengan 30 juta—gas maksimum saat ini dalam satu blok Ethereum. Memperkirakan nilai ini secara berlebihan hanya berarti bahwa pajak MEV akan menangkap persentase MEV yang lebih besar.↩
5. Dengan asumsi bahwa transaksi tidak dapat menggunakan lebih dari 30 juta gas, prioritasFeePerGas sebesar 50.000 akan menghasilkan pembayaran gas sebesar 1500 gwei—sekitar $0.006 pada harga ETH sebesar $4000.↩
6. Dalam kasus di mana priorityFeePerGas diatur sehingga keuntungan arbitrase adalah nol, perdagangan arbitrase yang memaksimalkan keuntungan seharusnya sesuai dengan perdagangan yang sama pada fungsi maksimalisasi AMM. Membuktikan hal ini dibiarkan sebagai latihan bagi pembaca. ↩
7. Arbitrum memiliki membahasmenggantikan ini dengan bentuk pengurutan prioritas yang disebut Timeboost, namun hal itu belum diimplementasikan hingga tulisan ini dibuat.

Penafian:

1. Artikel ini diambil dari [Gateparadigma], Semua hak cipta milik penulis asli [Dan Robinson, Dave White]. Jika ada keberatan terhadap cetakan ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penyangkalan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata merupakan milik penulis dan tidak merupakan saran investasi.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.