Paradigm menemukan mekanisme baru, pajak MEV, yang dapat mengubah lanskap DeFi yang ada

11,522 0 7

Artikel ini dari Prioritas Adalah Semua Yang Anda Butuhkan

Penulis asli: Dan Robinson, Dave White

Disusun oleh: Suami Harian Odaily Planet

Paradigm menerbitkan artikel Priority Is All You Need pada tanggal 4 Juni, yang memperkenalkan mekanisme baru pajak MEV secara rinci.

Pajak MEV adalah mekanisme baru yang memungkinkan aplikasi untuk menangkap MEV yang mereka hasilkan sendiri, daripada membocorkannya ke pengusul blok (lihat catatan kaki di akhir artikel untuk informasi lebih lanjut tentang pengusul blok). Mekanisme ini memanfaatkan penyortiran prioritas kompetitif selama konstruksi blok. Dalam metode penyortiran ini, transaksi diurutkan dalam urutan menurun dari biaya prioritas, dan transaksi dengan prioritas lebih tinggi dikemas dalam blok terlebih dahulu. Pajak MEV diimplementasikan dengan menambahkan biaya tambahan ke biaya prioritas transaksi. Aplikasi dapat menetapkan biaya mereka sendiri berdasarkan biaya prioritas transaksi, sehingga menangkap sebagian besar atau bahkan semua MEV. Ini berarti bahwa aplikasi dapat menjalankan lelang MEV kustom mereka sendiri dengan berpartisipasi dalam satu lelang bersama yang dijalankan oleh pengusul blok tanpa memerlukan infrastruktur off-chain apa pun.

Kelahiran mekanisme pajak MEV mungkin berdampak pada ekosistem DeFi yang ada:

Mengubah cara MEV tradisional didistribusikan: Secara tradisional, sebagian besar MEV mengalir ke pengusul blok, dan pajak MEV memungkinkan aplikasi untuk menangkap nilai ini dan mendistribusikannya kembali ke penggunanya atau menggunakannya untuk tujuan lain.
Peningkatan pendapatan aplikasi dan pengalaman pengguna: Aplikasi dapat meningkatkan pendapatannya dengan menerapkan pajak MEV sambil memberikan pengalaman pengguna yang lebih baik karena pengguna dapat memperoleh efisiensi eksekusi transaksi yang lebih tinggi dan harga transaksi yang lebih baik.
Menyelesaikan beberapa permasalahan di DeFi: M seperti mengoptimalkan perutean DEX, mengurangi kerugian AMM akibat arbitrase, mengurangi kebocoran MEV dari pengguna dompet, dll. Dengan memperkenalkan pajak MEV, aplikasi dapat meningkatkan produk dan layanannya, sehingga meningkatkan efisiensi dan keberlanjutan ekosistem DeFi.

Kutipan

Dalam makalah ini, kami memperkenalkan pajak MEV, sebuah mekanisme yang memungkinkan aplikasi apa pun untuk menangkap MEV (Nilai Ekstraksi Maksimum) miliknya sendiri.

Mekanisme ini dapat langsung digunakan pada rantai OP Stack L2 seperti OP Mainnet, Base, dan Blast, karena pengusul blok pada rantai ini mengikuti serangkaian aturan yang kami sebut prioritas pertentangan.

Untuk menerapkan pajak MEV pada rantai ini, kontrak pintar mengenakan biaya berdasarkan biaya prioritas transaksi. Kami menunjukkan bahwa jika aplikasi mengenakan pajak MEV sebesar $99 untuk setiap $1 biaya prioritas yang dibayarkan oleh pencari, aplikasi tersebut dapat memperoleh 99% dari MEV pesaing untuk transaksi tersebut.

Pajak MEV adalah teknik sederhana yang membuka ruang desain yang luas. Anda dapat menganggapnya sebagai mengizinkan aplikasi apa pun pada rantai untuk menjalankan lelang MEV kustomnya sendiri tanpa memerlukan infrastruktur di luar rantai itu sendiri, cukup dengan menghubungkan ke lelang bersama yang dijalankan oleh pengusul blok.

Kami menunjukkan bagaimana pajak MEV dapat digunakan untuk menjawab tiga pertanyaan utama dalam penelitian MEV:

Router pertukaran terdesentralisasi (DEX) yang mengoptimalkan harga yang diterima oleh penukar

Pembuat Pasar Otomatis (AMM) yang meminimalkan kerugian penyedia likuiditas (LVR) karena penyeimbangan kembali

Dompet yang memungkinkan pengguna menangkap MEV “fallback” apa pun yang dihasilkan oleh transaksi mereka

Namun, ada kendala. Pajak MEV hanya berlaku jika pengusul blok benar-benar mengikuti aturan prioritas kompetitif, termasuk mengurutkan transaksi berdasarkan biaya prioritas tanpa penyensoran, pengintaian, atau penundaan. Jika pengusul blok menyimpang dari aturan ini, mereka dapat menghindari pajak MEV untuk mendapatkan nilai. Akibatnya, pajak MEV saat ini bergantung pada kepercayaan terhadap sequencer L2, dan mungkin tidak berlaku sama sekali pada Ethereum L1, di mana konstruksi blok pada mainnet Ethereum didominasi oleh lelang pembangun kompetitif yang memaksimalkan pendapatan pengusul.

Meskipun demikian, kekuatan dan fleksibilitas pajak MEV menunjukkan bahwa penentuan prioritas mungkin merupakan pilihan yang tepat bagi platform yang saat ini menawarkannya. Dan penentuan prioritas kompetitif yang relatif sederhana menunjukkan bahwa mungkin ada cara yang layak untuk memberlakukannya secara terdesentralisasi tanpa mempercayai satu pun sequencer. Kami berharap artikel ini menginspirasi penelitian lebih lanjut tentang masalah ini.

Pemesanan prioritas

Ketika seseorang mengirim transaksi di mainnet Ethereum atau L2, mereka menentukan biaya prioritas yang dibayarkan kepada pengusul blok. Anda dapat membayangkan ini ditentukan melalui priorityFeePerGas, yang merupakan angka yang dikalikan dengan gas yang digunakan dalam transaksi untuk mendapatkan builderPriorityFee, jumlah total pembayaran dalam ETH.

Tidak ada persyaratan dalam protokol Ethereum bahwa transaksi dalam satu blok harus diurutkan dengan cermat dalam urutan prioritasFeePerGas yang menurun. Namun, ini adalah cara yang populer untuk membangun blok. Misalnya, ini adalah algoritma default yang digunakan oleh sequencer rantai OP Stack dan geth dan reth. Penyortiran prioritas tidak hanya memungkinkan para pelaku transaksi untuk mengekspresikan urgensi transaksi mereka secara efektif, tetapi juga secara alami mengarahkan jenis MEV tertentu ke pengusul blok.

Hal ini terjadi karena penyortiran prioritas mengubah persaingan untuk MEV menjadi lelang gas prioritas. Ketika ada peluang untuk mendapatkan keuntungan dari interaksi dengan rantai, seperti melalui arbitrase antara AMM dan bursa terpusat, para pencari bersaing untuk merebut peluang ini terlebih dahulu. Jika rantai menggunakan penyortiran prioritas untuk menentukan pengemasan dan pemesanan transaksi, para pencari akan bersaing dengan menetapkan biaya prioritas tinggi dalam transaksi mereka.

Dalam skenario kompetitif di mana laba bebas risiko ditekan hingga nol oleh persaingan, pencari yang menang pada akhirnya harus membayar jumlah penuh MEV sebagai biaya prioritas. Jadi, jika ada laba sebesar 100 ETH yang bisa diperoleh dengan berinteraksi dengan kontrak, transaksi pertama yang memanfaatkan peluang akan menetapkan biaya prioritas sebesar 100 ETH. (Kami membahas beberapa peringatan untuk ini di bagian Keterbatasan).

Pajak MEV

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

Namun pada kenyataannya, kita tidak perlu mengetahui hal-hal spesifik apa pun tentang aplikasi tersebut. Jika kita mengetahui bahwa blok dibangun melalui prioritas kompetitif, maka kita memiliki sinyal terpadu untuk jumlah MEV dalam suatu transaksi: biaya prioritas.

Kami mengusulkan agar kontrak pintar dapat melihat biaya prioritas transaksi dan mengenakan biaya mereka sendiri berdasarkan biaya tersebut, yang merupakan fungsi peningkatan biaya prioritas. Misalnya, suatu kontrak mungkin mengharuskan orang yang memanggilnya untuk mentransfer applicationPriorityFee = 99 * proposerPriorityFee ETH ke kontrak.

Biaya baru ini dibayarkan oleh pencari yang mengirim transaksi, sehingga memengaruhi perilaku pencari tersebut. Jika ada 100 ETH MEV dalam suatu peluang, transaksi yang menang sekarang hanya akan menetapkan biaya prioritas sebesar 1 ETH, karena ini akan menghasilkan total pembayaran sebesar 100 ETH (1 ETH untuk pengusul blok, 99 ETH untuk kontrak pintar). Biaya prioritas yang lebih tinggi akan membuat transaksi tidak menguntungkan; biaya prioritas yang lebih rendah akan menyebabkan peluang direnggut oleh pesaing yang menetapkan biaya yang lebih tinggi. Ini berarti bahwa kontrak pintar memperoleh 99% MEV dalam transaksi.

Kami menyebut biaya tambahan yang dikenakan oleh kontrak pintar ini sebagai pajak MEV. Pajak MEV memungkinkan aplikasi membajak penentuan prioritas demi keuntungan mereka sendiri, sehingga mereka dapat memperoleh kembali MEV bagi penggunanya alih-alih membiarkannya bocor untuk memblokir pengusul.

Jika biaya ini tumbuh cukup cepat sebagai fungsi priorityFeePerGas, maka hanya MEV yang dapat diabaikan yang akan diperoleh pengusul. Karena priorityFeePerGas didenominasikan dalam wei (seratus juta ETH), kami memiliki banyak presisi untuk dieksploitasi. Misalnya, selama sensitivitas pajak MEV cukup tinggi sehingga priorityFeePerGas sebesar 50.000 menghasilkan pajak yang sangat tinggi, maka jumlah total yang dibayarkan kepada pengusul akan kurang dari $0.01.

Namun, ada peringatan penting. Seperti yang dibahas di bagian “Keterbatasan”, pajak MEV hanya berlaku jika pengusul blok mengikuti aturan tertentu (yang kami sebut “prioritas kompetitif”) dan tidak menyimpang dari aturan tersebut untuk memaksimalkan pendapatan mereka sendiri. Menegakkan aturan ini dengan cara yang tidak dapat dipercaya merupakan masalah yang terbuka.

Penangkapan MEV untuk satu aplikasi

Pada rantai yang menjamin blok dibangun menggunakan prioritas kompetitif, pajak MEV dapat digunakan untuk meringankan tiga masalah penting dengan MEV: memungkinkan antarmuka DEX untuk meningkatkan eksekusi perdagangan bagi penukar; memungkinkan AMM untuk mengurangi kerugian arbitrase untuk LP mereka; dan memungkinkan dompet untuk mengurangi kebocoran MEV pengguna dengan menjual hak untuk menjalankan kembali kepada pengguna.

Pencari router DEX

Dalam protokol perutean DEX berbasis maksud seperti UniswapX dan 1inch Fusion, pengguna (Alice) menandatangani maksud pertukaran dan pencari bersaing untuk merutekan atau memenuhi maksud tersebut dengan harga terbaik.

Versi UniswapX saat ini menggunakan dua mekanisme untuk menjalankan kompetisi ini: lelang Belanda, di mana harga batas Alice berubah seiring waktu hingga diisi oleh pencari, dan lelang permintaan penawaran (RFQ) awal di luar rantai untuk menetapkan harga awal lelang Belanda ini.

Pada platform yang menjamin prioritas kompetitif, UniswapX dapat menggantinya dengan mekanisme: pajak MEV. Hal ini dapat diterapkan dengan meminta pengguna menandatangani pesanan yang dapat segera diisi oleh siapa saja, tetapi harga eksekusi merupakan fungsi dari biaya prioritas transaksi.

Misalnya, jika Alice memiliki pesanan UniswapX untuk menjual 1 ETH, dia dapat menentukan harga eksekusi pesanan tersebut sebesar minimumPrice + ($ 0,01 * priorityFeePerGas). minimumPrice dapat berupa nilai tetap yang dia harapkan akan jauh lebih rendah daripada harga saat ini.

Para pencari akan bersaing untuk memenuhi pesanan Alice dengan mengirimkan transaksi. Setiap transaksi dengan biaya prioritas tertinggi yang tidak mengalami kemunduran akan memenuhi pesanan, yang seharusnya menjamin bahwa pedagang mendapatkan harga terbaik yang dapat ditemukan oleh pencari. (Beberapa pengecualian untuk hal ini dibahas di bagian Keterbatasan.)

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

Hal ini memiliki beberapa keunggulan 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 dijelaskan dalam artikel, lelang Belanda on-chain membocorkan sebagian nilai ke MEV karena perubahan harga antar blok, dan mungkin memerlukan beberapa blok untuk diselesaikan. Sebaliknya, pesanan yang menggunakan pajak MEV sering kali dapat diselesaikan di blok berikutnya sambil memperoleh sebagian besar MEV mereka.

Tidak seperti RFQ off-chain, lelang yang memenuhi pesanan menggunakan pajak MEV akan terjadi secara atomik saat transaksi on-chain dieksekusi. Ini berarti bahwa penawar yang menang dapat menjamin bahwa pesanan hanya akan dipenuhi jika transaksi on-chain-nya berhasil. Hal ini dapat membuat likuiditas on-chain (seperti AMM) lebih mudah bersaing dengan likuiditas off-chain, yang berarti UniswapX dapat berfungsi sebagai router yang lebih efisien untuk subsistem multi-pool (seperti Uniswap v4).

Pembuat Pasar Otomatis (AMM)

Biasanya, AMM mengalami kebocoran nilai karena pelaku arbitrase melakukan perdagangan dengan harga yang sudah tidak berlaku di puncak blok, seperti yang dibahas dalam kerugian-vs-penyeimbangan kembali makalah. Kita dapat menggunakan pajak MEV untuk memungkinkan AMM menangkap MEV ini. Untuk mempermudah, kita akan membahas cara melakukannya pada AMM tanpa likuiditas terpusat. (Jika Anda tertarik dengan cara mengatasi masalah ini saat ada likuiditas terpusat, Sorella akan segera merilis solusinya.)

AMM dapat memperoleh MEV dengan mengenakan biaya tambahan berdasarkan biaya prioritas transaksi, yang memungkinkannya melelang hak untuk memprioritaskan transaksi dalam satu blok. Ada banyak cara untuk menghitung dan menentukan nominal biaya ini. Kami akan membahas metode yang bisa dibilang netral – mengekspresikannya dalam satuan likuiditas pool sqrt(xy). Transaksi yang menang adalah transaksi yang paling meningkatkan likuiditas pool.

Ketika transaksi pertama dieksekusi pada pool dalam satu blok, pool dapat memberlakukan kondisi x_end * y_end > x_start * y_start (sebagai beberapa konstanta untuk a ):

x_end * y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^ 2 Rumus ini akan memberi insentif kepada pedagang arbitrase untuk berdagang pada harga sebenarnya, setelah itu harga titik tengah kumpulan harus menjadi harga sebenarnya.

Setelah perdagangan pertama, perdagangan dapat berjalan seperti di Uniswap v2, dengan menggunakan biaya swap tetap. Pedagang yang tidak memiliki informasi yang ingin berdagang tanpa membayar pajak MEV tambahan akan menetapkan biaya preferensial yang lebih rendah.

Ada banyak cara lain untuk menerapkan pajak MEV pada AMM, dengan efek yang berbeda-beda. Misalnya, pajak MEV dapat dinyatakan dalam token input atau output dari suatu bursa, dapat memengaruhi persentase biaya bursa yang diterapkan oleh suatu pool, atau dapat menentukan harga minimum di mana pengguna dapat melakukan perdagangan. Kami pikir ini adalah ruang desain yang menarik dan layak untuk dieksplorasi.

Lelang mundur

Uraian di atas menunjukkan bagaimana aplikasi tertentu dapat dirancang untuk menghindari kebocoran MEV. Namun, bagaimana jika dompet ingin membantu penggunanya memperoleh MEV yang mereka hasilkan saat berinteraksi dengan aplikasi apa pun melalui transaksi apa pun, bahkan jika aplikasi tersebut tidak menyertakan pajak MEV?

Misalnya, ketika Alice melakukan perdagangan besar pada AMM, ia terkadang menciptakan peluang arbitrase bagi "backrunners" untuk mengembalikan harga ke normal. Sering kali, peluang ini bocor ke MEV, bukan ke Alice.

MEV-Bagikan Dan Pemblokir MEV ada dua protokol yang memungkinkan pengguna untuk menangkap MEV dari transaksi mereka, tetapi mereka bergantung pada sistem lelang off-chain yang kompleks. Ruang Desain Lelang Orderflow menjelaskan beberapa solusi lainnya.

Bila pajak MEV digabungkan dengan dompet kontrak pintar berbasis maksud, kita dapat membangun sistem alternatif untuk menangkap MEV Alice yang tertinggal. Misalkan Alice tidak membuat transaksi untuk diperdagangkan di AMM, tetapi malah menandatangani maksud yang dapat diajukan siapa saja ke dompet kontrak pintar Alice agar dompet tersebut melakukan tindakan tersebut. Dompet kontrak pintar Alice mengenakan pajak MEV kepada orang yang mengajukan transaksi tersebut, yang dibayarkan kepada Alice.

Pencari yang mengirimkan maksud Alice memiliki hak eksklusif untuk mengikutinya, karena mereka dapat melakukannya secara atomik dalam transaksi yang sama. Oleh karena itu, jika persaingan pencarian tinggi, semua keuntungan dari mengikuti Alice harus diberikan kepada Alice melalui pajak MEV-nya.

Penting untuk dicatat bahwa sistem ini mungkin tidak sepenuhnya melindungi pengguna dari serangan front-running, karena front-runner mungkin dapat menghindari pembayaran pajak MEV kepada pengguna. Masalah ini (dan beberapa kemungkinan mitigasinya) dibahas secara terperinci di bagian Keterbatasan di bawah ini. Namun, setidaknya ini merupakan peningkatan dibandingkan sistem mempool publik tanpa mitigasi apa pun.

Kasus Penggunaan Lainnya

Selain contoh-contoh ini, penggunaan potensial lain dari pajak MEV mencakup hampir semua skenario yang saat ini menggunakan lelang off-chain atau lelang Belanda, seperti:

Protokol seperti Oval bekerja dengan menangkap nilai ekstraksi oracle (OEV) yang mereka buat.
Lelang pembiayaan kembali dalam protokol pinjaman beragunan NFT seperti Blend.
Likuidasi protokol peminjaman menghasilkan nilai yang lebih rendah dibandingkan lelang Belanda.

Penangkapan MEV lintas aplikasi

Solusi di atas dirancang untuk menangkap MEV yang dihasilkan saat berinteraksi dengan satu aplikasi. Namun, terkadang seorang pencari dapat menangkap lebih banyak nilai dengan berinteraksi dengan beberapa aplikasi dalam transaksi yang sama.

Jika hanya satu dari aplikasi ini yang menggunakan pajak MEV, maka semua MEV dari transaksi harus diatribusikan ke aplikasi yang menggunakan pajak MEV, terlepas dari seberapa tinggi atau rendahnya pajak MEV tersebut.

Namun, bagaimana jika transaksi pencari berinteraksi dengan dua aplikasi yang menggunakan pajak MEV? Misalnya, jika beberapa MEV hanya dapat diperoleh dengan mengisi pesanan UniswapX yang dikenakan pajak MEV terhadap AMM yang dikenakan pajak MEV?

Dalam kasus ini, jumlah relatif kelebihan MEV yang diperoleh oleh setiap aplikasi ditentukan oleh pajak MEV yang ditetapkan oleh aplikasi tersebut. Jika nilai app_i sebagai pajak MEV diberikan oleh fungsi tax_i(priority), prioritas transaksi yang menang dapat ditentukan dengan menyelesaikan prioritas dalam persamaan berikut: pajak_1(prioritasPerGas) + pajak_2(prioritasPerGas) = total MEV

(Secara teknis, kita dapat menambahkan istilah ketiga priorityPerGas * gasUsed untuk memperhitungkan biaya prioritas yang dibayarkan kepada pengusul blok, tetapi kita akan mengabaikannya karena, sebagaimana dibahas dalam Lampiran A, biaya prioritas kemungkinan besar dapat diabaikan dalam keadaan normal.)

Dalam kasus sederhana pajak MEV yang linier dalam prioritasPerGas (jadi tax_ 1(priorityPerGas) = a_ 1 * priorityPerGas ), Anda dapat menghitung bagian MEV yang diterima setiap aplikasi:

a_1 * prioritasPerGas + a_2 * prioritasPerGas = MEV

prioritasPerGas = MEV/(a_ 1 + a_ 2)

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

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

Aplikasi menghadapi dilema saat menetapkan pajak MEV-nya sendiri – tarif pajak yang lebih tinggi memungkinkannya untuk memperoleh bagian yang lebih besar dari MEV lintas aplikasi saat hal itu terjadi, tetapi itu berarti aplikasi tersebut mungkin kehilangan beberapa MEV lintas aplikasi jika ada metode ekstraksi yang bersaing. Misalnya, jika ada AMM yang mengenakan pajak MEV pada setiap perdagangan, maka buku pesanan UniswapX yang dikenakan pajak MEV dapat diisi oleh AMM yang berbeda atau pengisi di luar jaringan.

Dalam banyak kasus, mungkin ada keseimbangan di mana dua aplikasi merancang pajak MEV mereka untuk berbagi MEV dengan cara yang memaksimalkan kesejahteraan masing-masing. Misalnya, AMM yang mengenakan pajak MEV mungkin ingin menangkap nilai dari satu pedagang yang terinformasi di dekat bagian atas blok, tetapi kemudian ingin memberikan likuiditas kepada pedagang dan aplikasi lain (termasuk yang menggunakan pajak MEV) dengan biaya tetap yang lebih rendah. Dalam kasus ini, AMM mungkin menetapkan pajak MEV yang relatif rendah (misalnya, $0.00001 * priorityFeePerGas ) sehingga perdagangan arbitrase (jika ada) terjadi di awal blok, dan kemudian tidak membebankan pajak MEV untuk perdagangan berikutnya di blok tersebut. Aplikasi seperti UniswapX yang ingin berinteraksi dengan AMM dapat menetapkan pajak MEV yang lebih tinggi (seperti $0.01 * priorityFeePerGas ) untuk memastikan bahwa perdagangan mereka disertakan setelah pool telah diarbitrase. Dengan pajak relatif ini, AMM pada akhirnya akan diarbitrase terlebih dahulu meskipun hanya ada $1 MEV dan $50.000 MEV dalam buku pesanan UniswapX.

Kami yakin ini adalah ruang desain yang luas yang layak untuk penelitian di masa mendatang.

keterbatasan

Ada beberapa kerumitan dan kelemahan dalam pajak MEV. Kami pikir ini adalah area yang menarik untuk penelitian di masa mendatang.

Ketidakcocokan Insentif

Pajak MEV tidak sesuai dengan insentif bagi pengusul blok monopoli. Pajak ini hanya berlaku jika ada persaingan yang adil untuk penyertaan transaksi, yang hanya terjadi jika pengusul blok mengikuti aturan yang kami sebut "prioritas kompetitif" alih-alih memaksimalkan pendapatan mereka sendiri. Kami merekomendasikan agar aturan ini mencakup:

Penyortiran prioritas: Transaksi dalam satu blok harus diurutkan dalam urutan prioritasFeePerGas yang menurun.
Resistensi sensor: Jika pengusul blok menerima transaksi t 1 saat membangun blok, dan blok tersebut tidak penuh atau berisi transaksi t 2 , dan t 2.priorityFeePerGas
Privasi pra-transaksi: Pengusul blok harus menerima transaksi melalui titik akhir pribadi dan tidak boleh membagikan transaksi ini dengan siapa pun sebelum mengirimkan blok, mereka juga tidak boleh menggunakan konten transaksi ini untuk membuat transaksi mereka sendiri.
Tidak ada finalitas. Pengusul blok harus menetapkan waktu tertentu (blockTime) sebelum mereka menerima transaksi dari siapa pun dan setelah itu mereka tidak menerima transaksi dari siapa pun.

Jika satu atau beberapa properti ini dilanggar, hal itu dapat melemahkan efektivitas pajak MEV. Pengusul blok yang melanggar ketahanan sensor dapat memanfaatkan peluang tersebut dengan mengecualikan transaksi yang bersaing dan mengajukan transaksi tanpa prioritas untuk menghindari sebagian besar pajak MEV. Pengusul blok yang melanggar privasi pratransaksi dapat mencuri MEV dari transaksi lain, atau mengintip biaya prioritas mereka untuk mengetahui seberapa tinggi yang perlu mereka tetapkan untuk mengalahkan yang lain, sementara pengusul yang dapat mengajukan transaksi lebih lambat daripada yang lain bebas untuk memutuskan apakah akan mengalahkan yang lain, yang menyebabkan masalah seleksi yang merugikan yang pada akhirnya menghambat persaingan.

Sayangnya, meskipun properti pertama mudah ditegakkan pada lapisan protokol, menegakkan properti lainnya dengan cara tanpa kepercayaan merupakan masalah yang terbuka.

Jika tidak ada penegakan di tingkat protokol, sequencer yang berkomitmen pada aturan ini perlu dipercaya untuk tidak menyimpang dari aturan tersebut, dan blok mungkin tidak mengikutinya jika pengusul mengalihdayakan konstruksi blok ke lelang kompetitif yang memaksimalkan pendapatan (seperti MEV-Boost di mainnet Ethereum).

Masalah-masalah ini dapat "diselesaikan" oleh satu pemesan tepercaya yang berkomitmen untuk membangun blok-blok menggunakan prioritas kompetitif. Atau masalah-masalah ini dapat diselesaikan dengan mekanisme-mekanisme terdesentralisasi menggunakan beberapa kombinasi dari konsensus, kriptografi, dan/atau lingkungan-lingkungan eksekusi tepercaya, seperti Angstrom milik Sorella, SUAVE milik Flashbots, Leaderless Auctions, atau Multiplicity.

Blok Penuh

Pengecualian terhadap operasi normal pajak MEV terjadi saat blok benar-benar penuh. Dalam kasus ini, pengusul blok mungkin harus mengecualikan transaksi dengan prioritas rendah daripada hanya memasukkannya nanti di blok. Karena transaksi yang berinteraksi dengan aplikasi yang menggunakan pajak MEV cenderung memiliki biaya prioritas yang sangat rendah, aplikasi ini dapat disingkirkan oleh aplikasi yang tidak menggunakan pajak MEV atau aplikasi yang menggunakan pajak MEV yang sangat rendah. Namun, pada rantai yang menggunakan mekanisme seperti EIP-1559 untuk menetapkan biaya dasar yang terpisah, blok yang benar-benar penuh seharusnya jarang terjadi. Lebih jauh, mengingat beberapa transaksi perlu ditunda saat blok penuh, menunda transaksi yang menunjukkan urgensi yang lebih rendah dengan menetapkan pajak MEV yang lebih tinggi mungkin merupakan hasil yang wajar.

Transaksi pembatalan

Pajak MEV pada dasarnya bergantung pada lelang blok tunggal, di mana setiap tawaran merupakan transaksi. Kelemahan dari lelang tersebut adalah tawaran yang tidak berhasil sering kali mengakibatkan transaksi pembatalan disertakan di dalam rantai, yang mengakibatkan pembayaran sejumlah biaya dasar dan membuat rantai menjadi padat.

Jika sequencer dapat mengecualikan transaksi yang gagal sepenuhnya, ini akan meringankan masalah ini, meskipun ini sulit dicapai bahkan dengan sequencer terpusat. (Ini juga tidak sepenuhnya mematuhi properti ketahanan penyensoran yang dijelaskan di atas, meskipun definisi itu dapat disesuaikan.) Sequencer yang lebih canggih mungkin dapat mengoptimalkan proses ini dengan memungkinkan transaksi untuk menentukan lelang sengketa tempat mereka berpartisipasi, sehingga memungkinkan sequencer untuk melewati transaksi berikutnya yang diketahuinya akan gagal.

Mengungkapkan maksud pengguna

Pajak MEV hanya berlaku jika ada persaingan antara para pencari, yang berarti peluang tersebut perlu diketahui sampai tingkat tertentu. Untuk aplikasi seperti AMM, di mana peluang tersebut terlihat di rantai, hal ini seharusnya terjadi secara alami. Namun untuk aplikasi seperti perutean berbasis maksud atau penawaran ekor, ini berarti aplikasi tersebut mungkin perlu membagikan maksud pengguna dengan para pencari.

Dalam beberapa kasus, privasi sementara yang hilang karena menyiarkan maksud pengguna sebelum memenuhinya dapat membocorkan nilai dengan cara yang tidak dapat dipulihkan oleh pajak MEV.

Misalnya, anggaplah Alice ingin membeli token dengan likuiditas rendah menggunakan protokol lelang trailing yang dijelaskan di atas. Dia menerbitkan maksud yang ditandatangani untuk dompet kontrak pintarnya untuk membeli token tersebut di AMM, dan menetapkan beberapa toleransi slippage. Pencari dapat berlomba untuk mendorong harga token tersebut hingga ke toleransi slippage miliknya dalam transaksi berprioritas tinggi tanpa memenuhi pesanan pengguna. Pemenangnya, Bob, kemudian dapat secara non-kompetitif memenuhi maksud Alice dengan memasukkan dan menjalankan kembali maksud Alice dalam transaksi berprioritas rendah, dengan demikian menjepit transaksi Alice dan memberinya harga yang lebih buruk sambil menghindari pajak MEV miliknya. Masalah serupa dapat terjadi saat membeli NFT.

Perhatikan bahwa serangan semacam itu berisiko bagi Bob, karena ia tidak dapat menjamin atomicity antara pembelian token dan penjualannya kepada Alice. Bob yang naif dapat menjadi korban perangkap tearing sandwich, di mana Alice memposting maksud untuk membeli token yang tidak berharga dari dirinya sendiri, yang menyebabkan Bob membelinya dengan harapan dapat menjepitnya dalam transaksinya, tetapi Alice mencabut maksudnya sebelum Bob dapat menyelesaikan sandwich tersebut.

Aplikasi juga dapat mengurangi masalah ini dengan membatasi sekumpulan pencari yang memiliki maksud yang sama dan memantau perilaku mereka, seperti yang dilakukan pada banyak lelang aliran pesanan saat ini.

Memungkinkan juga untuk menggabungkan pajak MEV dengan fitur pembangun yang mengutamakan privasi, seperti yang dibayangkan dalam desain SUAVE Flashbots.

Akhirnya, jika Alice memutuskan bahwa biaya untuk berbagi maksudnya lebih besar daripada manfaat pencarian kompetitif, ia dapat membuat sendiri transaksi dan mengirimkannya langsung ke blok. Seperti dijelaskan di atas, penerapan prioritas kompetitif yang ideal akan memberikan privasi pratransaksi bagi pengusul blok.

Diskusi dan pekerjaan awal

Lelang Gas Prioritas. Anak Flash 2.0 makalah, yang menciptakan istilah “nilai yang dapat diekstraksi oleh penambang,” meneliti beberapa dinamika prioritas dalam blockchain yang terdesentralisasi. Makalah tersebut mengamati bahwa penambang Ethereum (ketika jaringan menggunakan proof-of-work) sudah memprioritaskan transaksi, dan bahwa pelaku arbitrase mengandalkan perilaku ini untuk berpartisipasi dalam “lelang gas prioritas,” di mana mereka mengajukan tawaran untuk hak untuk dimasukkan dalam blok terlebih dahulu, yang mengakibatkan mayoritas MEV dari arbitrase bursa terdesentralisasi jatuh ke tangan penambang.

Siapa cepat dia dapat. Melalui aturan urutan transaksi (seperti Themis atau Sequencer Arbitrum One saat ini Beberapa upaya untuk mengurangi MEV berfokus pada penerapan aturan pemesanan yang berbeda, yaitu siapa cepat dia dapat (yang terkadang disebut “pemesanan yang adil”), di mana pengusul blok harus memesan transaksi sesuai urutan yang mereka lihat.

Prioritas mengambil pendekatan yang berbeda – memperlakukan transaksi yang masuk dalam periode waktu tertentu secara sama dan mengurutkannya berdasarkan prioritas yang dinyatakan.

"Pemesanan yang adil" sulit untuk ditegakkan atau bahkan didefinisikan dalam lingkungan jaringan nyata dengan beberapa validator. Hal ini juga dapat menyebabkan perlombaan latensi yang boros dan spam, bahkan dengan satu sequencer tepercaya. Terakhir, pajak MEV mungkin dapat menghilangkan beberapa MEV "siapa cepat dia dapat", seperti keuntungan arbitrase dari "lonjakan" harga aset yang tidak berkesinambungan. Keuntungan potensial dari pemesanan prioritas dibandingkan pemesanan siapa cepat dia dapat agak terkait dengan keuntungan pertukaran waktu diskrit dibandingkan waktu kontinu yang dibahas dalam Budish, Cramton, dan Shim (2015) .

Pada saat yang sama, sementara penentuan prioritas tampaknya membocorkan nilai ke MEV secara default, artikel ini menunjukkan bagaimana aplikasi dapat dirancang untuk mendapatkannya kembali.

Pembagian biaya. Blast adalah Ethereum L2 yang membagi sebagian prioritas dan biaya dasar dengan kontrak pintar yang diakses dalam transaksi.

Pajak MEV memungkinkan hal serupa (setidaknya untuk biaya prioritas), tetapi dapat diterapkan pada lapisan aplikasi pada rantai mana pun yang menggunakan prioritas kompetitif, tanpa memerlukan dukungan khusus untuk pembagian biaya. Pajak MEV juga memungkinkan aplikasi untuk menentukan pajak mereka sendiri sebagai fungsi khusus dari biaya prioritas, yang memungkinkan fleksibilitas yang lebih besar dan kemungkinan peningkatan komposisi aplikasi yang mendukung MEV.

Solusi Tanpa Kepercayaan. Tulisan ini berfokus pada insentif bagi platform untuk menggunakan prioritas kompetitif, dan metode untuk memanfaatkan platform prioritas kompetitif, alih-alih membahas cara menjalankannya tanpa kepercayaan.

Masing-masing properti lain yang diperlukan untuk penentuan prioritas kompetitif telah dibahas secara luas sebelumnya. Misalnya, dalam Fox, Pai, dan Resnick (2023) , para penulis membahas kerentanan dalam lelang on-chain tanpa resistensi sensor dan menjelaskan desain untuk lelang yang tahan sensor menggunakan beberapa pengusul bersamaan. Namun, mereka tidak merekomendasikan urutan transaksi tertentu.

Ada penelitian lain tentang membangun mekanisme konstruksi blok yang meminimalkan kepercayaan, termasuk SUAVE milik Flashbots, Angstrom milik Sorella, Leaderless Auctions, Timeboost terdesentralisasi milik Espresso dan Offchain Labs, dan pengemasan transaksi publik paksa milik Péter Szilági.

Kesimpulannya

Kami berharap postingan ini mendorong L2 untuk mempertimbangkan penggunaan prioritas (didukung secara default dalam tumpukan OP), dan memberi insentif kepada aplikasi untuk mencoba pajak MEV jika didukung.

Kami juga berharap hal ini akan menginspirasi penelitian lebih lanjut tentang protokol penentuan prioritas pertikaian yang meminimalkan kepercayaan pada L1 dan L2.

catatan kaki

Dalam posting ini, kami menggunakan "pengusul" untuk merujuk pada partisipan atau proses yang menentukan transaksi mana yang termasuk dalam blok tertentu. Pada Ethereum L2, peran ini biasanya diisi oleh "sequencer". Pada Ethereum L1, peran ini diisi oleh validator Ethereum tertentu, yang disebut pengusul, meskipun pengusul biasanya mengalihdayakan tugas membangun blok ke lelang kompetitif yang melibatkan "relay" dan "builder". Rincian tentang bagaimana tanggung jawab ini dibagi berada di luar cakupan posting ini.
Biaya prioritas per Gas sebenarnya tidak secara eksplisit ditentukan dalam transaksi, tetapi dapat dihitung dalam transaksi. Transaksi menentukan harga Gas, tetapi Ethereum juga mengenakan biaya dasar, yang diambil dari harga Gas dan dimusnahkan. Untuk tujuan pajak MEV, biaya dasar harus diabaikan karena tidak dikendalikan oleh pedagang. Biaya prioritas per Gas (yaitu harga porsi biaya transaksi yang diberikan kepada pengusul blok) dapat dihitung dalam Solidity sebagai priorityGasPrice = tx.gasprice – block.basefee.
Kita dapat mendefinisikan “MEV” secara sederhana untuk mengecualikan keuntungan pencari dan hanya merujuk pada nilai yang akan mengalir ke validator.
Perhatikan bahwa proposerPriorityFee sebenarnya tidak dapat dihitung sebagai kelipatan jumlah priorityFeePerGas (sama dengan total Gas yang digunakan dalam transaksi) selama kontrak, karena tidak ada cara untuk mengetahui berapa banyak Gas yang pada akhirnya akan digunakan transaksi tersebut. Namun, ini biasanya tidak menjadi masalah, karena yang kita perlukan hanyalah batas atasnya. Agar aman, Anda dapat mengalikan priorityFeePerGas dengan 30 juta – Gas maksimum saat ini dalam satu blok Ethereum. Melebih-lebihkan nilai ini hanya akan berarti bahwa pajak MEV mencakup proporsi MEV yang lebih besar.
Dengan asumsi transaksi tidak dapat melebihi 30 juta Gas, priorityFeePerGas sebesar 50.000 akan menghasilkan pembayaran Gas sebesar 1500 gwei — sekitar $0,006 pada harga ETH sebesar $4.000.
Jika priorityFeePerGas ditetapkan sehingga laba pelaku arbitrase adalah nol, maka perdagangan arbitrase yang memaksimalkan laba harus sesuai dengan perdagangan yang sama pada AMM yang memaksimalkan fungsi.
Arbitrum telah membahas penggantian ini dengan bentuk prioritas yang disebut Timeboost, tetapi hingga tulisan ini dibuat, ini belum diproduksi.

Artikel ini bersumber dari internet: Paradigm menemukan mekanisme baru, pajak MEV, yang dapat mengubah lanskap DeFi yang ada

Terkait: Bitget Research Institute: Sektor meme turun tajam selama akhir pekan, LayerZero dan zkSync diperkirakan akan menerbitkan token

Dalam 24 jam terakhir, banyak mata uang dan topik baru yang sedang hangat muncul di pasar, dan sangat mungkin itu akan menjadi peluang berikutnya untuk menghasilkan uang. Sektor-sektor berikut perlu diperhatikan: Sektor meme, sektor token penggemar Token dan topik yang sedang hangat dicari oleh pengguna: Scroll, Manta Network, BONK Peluang potensial untuk mendapatkan airdrop meliputi: Scroll, Orbiter Finance Waktu statistik data: 20 Mei 2024 4:00 (UTC+0) 1. Lingkungan pasar Minggu lalu, ETF spot BTC mengalami arus masuk bersih selama 5 hari berturut-turut. Arus masuk dana dalam dua minggu terakhir telah mengimbangi semua arus keluar pada bulan April. BTC naik 9% dalam seminggu, dan harganya berfluktuasi sekitar 67.000. Data pengamatan Federal Reserve CME menunjukkan bahwa kemungkinan Federal…

Analisis #