Mekanisme biaya transaksi telah menjadi model pekerja keras untuk memahami intermediasi produsen blok antara pengguna yang ingin bertransaksi dan "rantai" (atau "protokol") tempat pengguna bertransaksi. Mengingat kemampuan untuk menggunakan beberapa pasokan yang disediakan oleh rantai, produsen blok harus menengahi pengguna mana yang akan memiliki kemampuan untuk menggunakan sumber daya yang langka dari eksekusi on-chain, dan berapa biayanya. Di Ethereum, untuk pertanyaan tentang biaya, produsen blok dibatasi oleh mekanisme biaya EIP-1559, yang secara dinamis menetapkan harga cadangan blok-ke-blok, yang disebut "biaya dasar". Biaya dasar adalah harga, dinyatakan per unit gas, yang harus dibayar oleh transaksi pengguna untuk dimasukkan dan dieksekusi. Pengguna dapat memberikan apa yang disebut "biaya prioritas" di luar biaya dasar, untuk lebih memberi insentif kepada produsen blok pada saat kemacetan.

Dalam catatan ini, kami menyelidiki pertanyaan tentang pasar biaya yang tertanam, yaitu pasar biaya yang 'hidup' di dalam pasar biaya lainnya. Pertanyaan ini dibahas dalam konteks yang berbeda dalam sebuah makalah baru-baru ini oleh Maryam Bahrani, Pranav Garimidi, dan Tim Roughgarden,Desain Mekanisme Biaya Transaksi di Dunia Pasca-MEV 9”. Dalam makalah ini, penulis memodelkan penggunaan pencari, akses perantara lebih lanjut ke rantai antara pengguna dan produsen blok. Produsen blok menerima "petunjuk" dari pencari, yang diwujudkan oleh bundel atom transaksi yang akan dimasukkan oleh rantai. Pasar biaya pencari didorong oleh tujuan maksimalisasi kuantitas yang dikenal sebagai MEV, atau nilai maksimal yang dapat diekstraksi.

Dalam pengaturan kami, pengguna ingin mengakses rantai tetapi tidak menyatakan permintaan mereka menggunakan transaksi yang dapat dibaca protokol. Sebaliknya, pengguna menghasilkan 'operasi', yang akan dikumpulkan oleh entitas yang dikenal sebagai 'pengumpul', yang kemudian menghasilkan transaksi yang dapat dibaca protokol yang mengemas operasi bersama untuk dieksekusi. Dengan demikian, untuk mekanisme biaya EIP-1559, pengumpul adalah pengguna rantai, namun pengguna sebenarnya harus terlebih dahulu memperoleh inklusi dalam pengumpulan pengumpul sebelum mereka dapat memperoleh inklusi dalam rantai. Dengan kata lain, kita dapat melihat pengaturan ini sebagai bagian dari pertanyaan yang lebih besar mengenai penciptaan blok bersama, yang muncul dengan (sebagian) builders/searchers serta daftar inklusi.

Harapan kami adalah agar dinamika-dinamika ini menjadi transparan sebanyak mungkin, sehingga tidak ada beban kognitif yang lebih besar atau peluang bagi pengguna untuk dieksploitasi secara tidak sah oleh pengelompok, dibandingkan dengan melakukan transaksi langsung di rantai. Kami berharap untuk hasil yang lebih kuat, kasus di mana pengguna memperoleh manfaat dari perantara pengelompokan, ketika biaya diamortisasi memungkinkan pengguna menikmati kesejahteraan yang lebih besar.

Untuk menyelidiki perbedaan antara pasar biaya langsung dan mekanisme (sub-) yang terkandung di dalamnya, kita harus memperjelas kendala ekonomi yang diikuti oleh pengikat. Pada bagian berikutnya, kami menawarkan model fungsi biaya pengikat yang sederhana yang didorong oleh praktik, terutama pengikat yang berpartisipasi dalam protokol ERC-4337, yang kami ringkas secara singkat.

Model

Pengikatan dalam ERC-4337

Seorang pengguna yang ingin melakukan beberapa aktivitas on-chain melalui bundler mengeluarkan Operasi Pengguna (UserOp, atau operasi). UserOp ini dipancarkan dari dompet pengguna, misalnya, setelah berinteraksi dengan DApp. Setelah UserOp disiarkan, beberapa bundler yang menerima operasi dapat memutuskan untuk memasukkannya ke dalam bundel. Bundel adalah meta-transaksi "akun milik eksternal" (EOA), yang menulis data UserOps yang disertakan di bidang bundle.calldata-nya. Bundler mengeluarkan bundle menuju penyertaan dalam blok oleh produsen blok (kami membahas hubungan antara bundler dan produsen blok dalam catatan mendatang).

Setelah bundel dimasukkan ke dalam blok, dan blok menuju ke rantai, bundel tersebut dieksekusi bersama dengan transaksi lainnya dalam blok. Pada dasarnya, langkah-langkah eksekusi bundel adalah sebagai berikut:

• Pra-verifikasi: Transaksi EOA bundler akan mengonsumsi 21.000 gas, dan panggilan ke kontrak EntryPoint akan mengatur variabel kunci untuk melacak eksekusi operasi dalam loop operasi.
• Operasi loop 3Untuk setiap operasi yang termasuk dalam bundel, dua langkah berikut ini dilakukan:
  • Langkah verifikasi: UserOps melakukan operasi yang mengandung langkah verifikasi, yang dienkripsi dalam sebuah “smart contract wallet” yang dideploy awal oleh pengguna (selama sebuah UserOp awal). Langkah verifikasi mungkin hanya memeriksa tanda tangan, atau melakukan operasi yang lebih kompleks untuk “memberikan” hak bagi UserOp untuk melanjutkan eksekusinya. Langkah verifikasi diukur oleh op.verificationGasLimit.
  • Langkah eksekusi: Inti dari UserOp, langkah eksekusi melakukan operasi yang dijelaskan dalam op.callData. Langkah ini juga diukur, menggunakan op.callGasLimit.

Seperti yang dijelaskan oleh dekomposisi sebelumnya, langkah pra-verifikasi dieksekusi sekali, menawarkan kemungkinan untuk mengamortisasi biaya pra-verifikasi di seluruh pengguna yang disertakan. Ketika bundel dieksekusi, semua biaya (misalnya, block.basefee + biaya prioritas yang dibayar oleh pengikat kepada produsen blok yang menyertakannya) dibebankan kepada pengikat, yang harus memastikan bahwa operasi pengguna menggantinya cukup untuk biaya yang dikeluarkan. Kami menjelaskan pernyataan ini dengan tepat dalam bagian berikutnya.

Model pasar biaya untuk bundle

Kami berusaha untuk tetap konsisten dengan model pasar biaya klasik. Pengguna t yang ingin mengeluarkan operasi memiliki nilai vt untuk pelaksanaan operasi tersebut. Kami mengasumsikan semua operasi memiliki ukuran yang sama S (yaitu, gas yang sama digunakan untuk tahap verifikasi dan pelaksanaan), dan kami mengungkapkan semua kuantitas sebagai harga per unit gas.

Pengguna mengungkapkan keinginan mereka untuk disertakan dengan mengeluarkan tawaran bt bersama dengan operasi mereka. Untuk saat ini, kami tidak mengasumsikan tata bahasa khusus bagi pengguna untuk mengungkapkan penawaran mereka untuk disertakan, misalnya, kemampuan untuk mengungkapkan biaya maksimum dan biaya prioritas bersama dengan operasi mereka, seperti yang mereka lakukan dengan EIP-1559. Operasi pengguna dikumpulkan dalam mempool M, yang mewakili status tertunda dari operasi-operasi ini sampai disertakan.

Pasar biaya EIP-1559 mengekspos harga cadangan r yang dikenal sebagai "biaya dasar", yang harus ditanggung oleh pengikat ketika bundel mereka dieksekusi. Jika bundel tersebut berisi n operasi, maka pengikat harus menanggung setidaknya n × S × r. Selain itu, karena bundel mengonsumsi "gas pra-verifikasi", katakanlah, sejumlah F, maka pengikat juga akan membayar F × r tambahan

. Operasi yang termasuk dalam bundel diberikan oleh himpunan B.

Fungsi Biaya Bundler

Kami sekarang mempertimbangkan biaya yang ditanggung oleh bundler untuk menyertakan bundel mereka dalam blok.

Fungsi biaya on-chain: Seorang pengebundel mengeluarkan bundel B ketika biaya dasar adalah r mengeluarkan biaya:

Masalah bundler mencerminkan masalah produsen blok yang diungkapkan dalam[Roughgarden 2021] 3Di sana, produsen blok harus memastikan penyediaan beberapa nilai μ mengganti biayanya untuk menyertakan transaksi tambahan ke blok mereka (mis., μ dapat mengganti biaya tambahan blok, yang menunda penyebarannya dan dengan demikian meningkatkan risiko re-org). Pasar biaya tingkat blok kemudian harus memastikan bahwa produsen blok setidaknya dibayar untuk biaya total n × S × μ, jika produsen blok menyertakan n transaksi dalam blok mereka. Pasar biaya tingkat bundler akan membutuhkan setidaknya mengganti bundler untuk biaya eksogen

Con-chain(B,r) yang mereka tanggung dari pasar biaya yang lebih besar di mana mereka terbenam.

ERC-4337 menawarkan kemungkinan mengamortisasi biaya di luar berbagi biaya gas pra-verifikasi. Apakah semua operasi menggunakan skema tanda tangan yang sama untuk langkah verifikasinya, tanda tangan operasi-operasi ini mungkintergabung 2oleh bundler, sehingga daripada memverifikasi n tanda tangan di rantai, satu tanda tangan dapat diverifikasi. Dalam hal ini, fungsi biaya bundler perlu memperhitungkan biaya di luar rantai yang ditanggung bundler saat melakukan agregasi. Selanjutnya, kita mengasumsikan bahwa biaya tersebut berbanding lurus dengan jumlah operasi, asumsi serupa dengan [Wang et al., 2024] 2, dengan biaya marginal ω.

Kami juga memperhitungkan konsumsi gas yang berkurang dari setiap operasi, karena penghematan dari agregasi. Ketika diagregat, operasi tidak perlu mempublikasikan tanda tangan mereka, tetapi mereka memerlukan operasi pasangan tambahan. Pada rantai di mana biaya calldata mahal, tetapi operasi pasangan / komputasi murah, agregasi memberikan penghematan per operasi. Dalam hal ini, kami menunjukkan dengan S' < S ukuran yang berkurang dari transaksi. Kami juga perlu memperhitungkan penggunaan gas pre-verifikasi yang meningkat F' > F, yang sekarang berisi publikasi dan verifikasi tanda tangan agregat tunggal on-chain.

Fungsi biaya teragregasi: Seorang penggabung mengeluarkan bundel B dengan tanda tangan teragregasi ketika biaya dasar adalah r, mengeluarkan biaya:

Dalam catatan ini, kami tidak akan membahas lebih lanjut, tetapi seseorang juga dapat mempertimbangkan biaya publikasi data yang mungkin perlu dikeluarkan oleh pembungkus ketika bundel mereka diselesaikan pada rollup. Kami menyarankan dua cara untuk memodelkan ini dan meninggalkan pertanyaan ini untuk pekerjaan masa depan:

• Entah si bundler sendiri yang bertanggung jawab atas publikasi data (misalnya, sebagai sekuenser), dan dengan demikian memerlukan untuk memperoleh dari pengguna jumlah dana yang diperlukan untuk membayar biaya publikasi data yang eventual.
• Atau pasar biaya level bundle tertanam dalam pasar biaya level batch yang lebih besar, melalui mana rollup mengekspos kepada pengguna rollup (termasuk bundler) jumlah yang harus mereka bayar karena kemacetan (misalnya, biaya dasar) dan biaya publikasi data akhir. Dalam hal ini, rollup bertanggung jawab untuk menyeimbangkan biaya masa depan mereka dengan pendapatan saat ini.

Mengunjungi kembali jumlah pasar biaya

Sekarang kita dapat secara resmi mengekspresikan konsep-konsep yang relevan untuk pasar biaya level bundel, menurunkannya secara langsung dari literatur sebelumnya, sambil memperhitungkan penyisipan.

Aturan alokasi level-pak: Alokasi (level-pak) x memutuskan kumpulan operasi pengguna yang dibundel termasuk di dalamnya, dengan mempertimbangkan mempool M saat ini dan biaya dasar r.

Aturan pembayaran tingkat bundel: Diberikan kumpulan operasi yang dipilih B, aturan pembayaran menetapkan biaya untuk setiap pengguna yang disertakan:

Fungsi utilitas pengguna:

Pada prinsipnya, kami dapat mengizinkan adanya aturan pembakaran qt(B) yang mengungkapkan fakta bahwa bundler mungkin tidak menerima totalitas semua pembayaran pengguna yang disertakan. Namun kami tidak mempertimbangkannya dalam catatan ini.

Fungsi utilitas pengikat (miopia):

Sebuah TFM level bundel (x,p) adalah insentif-kompatibel untuk bundler myopic (MBIC) jika, untuk setiap mempool M dan biaya dasar r, seorang bundler myopic memaksimalkan utilitasnya dengan mengikuti saran aturan alokasi x (yaitu, menetapkan B = x(M,r)).

Membentuk beberapa bundel

Dalam bagian sebelumnya, kita hanya mempertimbangkan kemungkinan bagi bundler untuk mengeluarkan satu bundel. Namun, kita mungkin tertarik pada kemungkinan bagi bundler untuk membuat lebih dari satu bundel dari operasi yang tersedia di mempool. Diberikan mempool M, mari P(M) mewakili himpunan partisi dari mempool, menugaskan setiap operasi ke satu bundel (kita mungkin mengasumsikan bahwa untuk setiap partisi, ada himpunan yang diindeks 0 yang berisi semua operasi yang tidak ditugaskan ke bundel untuk inklusi). Aturan alokasi kemudian mengembalikan indeks set di partisi ke mana operasi ditugaskan.

Kami dapat menulis set bundel yang dihasilkan oleh partisi x(M,β) sebagai B(x(M,r)). Secara intuitif, bundel-bundel ini terdiri dari operasi yang tidak termasuk dalam set yang diindeks 0. Diberikan set bundel B, aturan pembayaran adalah:

Fungsi utilitas pengguna menjadi:

dan fungsi utilitas pembundel menjadi:

Permainan bundler

Pemasukan transaksi dalam blok harus memberikan imbalan sejumlah μ kepada para produsen blok, yang diasumsikan linear terhadap ukuran transaksi misalnya, [Roughgarden, 2021] 3. Jumlah ini menunjukkan biaya kesempatan bagi produsen blok untuk menambahkan transaksi tambahan ke blok mereka, misalnya, meningkatkan keterlambatan gosip mereka dan dengan demikian meningkatkan peluang blok untuk dire-orged. Dalam Proof-of-Stake, meskipun jadwal protokol memungkinkan waktu yang cukup untuk mempropaGate blok penuh, permainan waktutelah menyebabkan dinamika propagasi "terakhir detik" yang sekali lagi membuat parameter μ ini relevan.

Bagaimanapun, kita dapat mengamati bahwa masalah pembagian biaya di tingkat blok dan di tingkat bundel sangat berbeda. Pada tingkat blok, transaksi tidak perlu tahu apa lagi yang terjadi di dalam blok untuk merancang tawaran inklusi sesuai dengan EIP-1559 (mungkin ingin tahu apa yang terjadi sehubungan dengan MEV [Bahrani et al., 2024] 9, tetapi kami akan mempertimbangkan masalah ini secara terpisah untuk saat ini). Pada tingkat bundel, biaya overhead bundel tidak lagi linear terhadap jumlah transaksi, tetapi biaya overhead tetap dapat diamortisasi oleh banyak transaksi. Selain itu, jika biaya agregasi dari operasi pengguna tidak linear terhadap jumlah transaksi (misalnya, beberapa bukti efektif sub-linear terhadap ukuran yang dibuktikan), memberikan kemungkinan untuk diamortisasi total biaya melalui banyak pengguna.

Ini mengarah pada permainan berikutnya: Si penggabung ingin pengguna menempatkan penawaran mereka seolah-olah mereka menawar untuk kasus terburuk, di mana pengguna sendirian dalam bundel dan harus mengganti sendiri biaya gas penuh F. Secara praktis, pengguna akan menghadapi masalah mengatur tiga parameter yang relevan dalam operasi mereka:

• op.maxPriorityFeePerGas dan op.maxFeePerGas dapat diatur sesuai dengan heuristik yang akan digunakan oleh pengguna di bawah EIP-1559, yaitu, dengan memperkirakan jumlah gas yang akan digunakan dalam operasi mereka, pengguna akan mengatur atribut ini untuk mengkalibrasi berapa banyak yang mereka bersedia bayar dalam kasus terburuk (maxFee) dan berapa banyak yang mereka bersedia tambahkan untuk membayar produsen blok pada akhirnya (maxPriority). Tetapi bagaimana pengguna mengestimasi gas?
• op.preVerificationGas adalah atribut UserOperation yang harus diatur untuk menunjukkan jumlah "gas ekstra" yang direncanakan untuk dikonsumsi oleh operasi pengguna. Dalam model kami, kami membiarkan
• F menunjukkan “fixed gas overhead”. Jika n pengguna termasuk dalam bundel, setiap pengguna seharusnya menetapkan preVerificationGas = F / n. Namun, jika pengguna mempersiapkan operasinya dengan skenario terburuk dalam pikiran, mereka akan menetapkan preVerificationGas = F.

preVerificationGas kemudian menjadi vektor utama melalui mana pengguna memediasi tawaran mereka dan berusaha memperhitungkan amortisasi biaya oleh bundler. Asumsikan n pengguna datang ke pasar dengan operasi mereka, dan semua yakin oleh bundler untuk menawar dalam kasus terburuk menjadi sendirian dalam bundel. Kita juga akan mengasumsikan bahwa pengguna mengatur maxPriorityFeePerGas mereka menjadi nol untuk contoh ini. Kemudian n pengguna ini semua mengatur preVerificationGas = F, dan bundler mampu menghasilkan bundel yang memberi imbalan kepada mereka dengan:

sedangkan mereka harus menanggung biaya:

setelah mereka menerbitkan bundel yang menggabungkan semua operasi n bersama-sama dalam satu blok. Ini menghasilkan keuntungan bundler π = (n−1)×F×r.

Sitasi ini dapat diwakili oleh permainan dua tahap, di mana pengguna pertama-tama menghasilkan operasi pengguna mereka, dan bundler kemudian memutuskan untuk menggabungkannya. Kami berasumsi bahwa pengguna tidak memiliki informasi tentang jumlah pengguna yang tertunda saat ini, dan oleh karena itu tidak dapat memperkirakan kemampuan sebenarnya dari bundler untuk mengamortisasi biaya tetap mereka.

Pada tahap pertama, pengguna mengirimkan operasi mereka, yang berkomitmen pada atribut-atribut mereka seperti preVerificationGas. Pada tahap kedua, bundler setelah menerima semua transaksi pengguna, memutuskan untuk menghasilkan bundel atau kumpulan bundel. Menariknya, meskipun pengguna mengetahui berapa banyak pengguna lain yang akan bermain di tahap pertama, yaitu jika n adalah pengetahuan umum di antara semua pengguna, bundler dapat memaksa pengguna untuk mengatur preVerificationGas = F dalam kasus terburuk dengan mengancam akan bermain.

, yaitu mengancam untuk menjaga setiap pengguna dalam paket terpisah mereka sendiri dan mengenakan mereka maksimum jumlah gas F.

Perhatikan bahwa ancaman ini mungkin tidak dapat dipercaya, karena pengguna akan mengharapkan bundler untuk lebih memilih bermain

, yaitu, menghasilkan satu bundel tunggal dengan semua operasi yang disertakan di sana, menyadari π. Namun, pengguna mungkin tidak memiliki akses ke nilai sebenarnya dari n, dan oleh karena itu mereka tidak dapat mengatur preVerificationGas mereka dengan cara yang memaksa bundler untuk menggabungkan ideal semua dari mereka.

Kasus ideal: biaya dibagi di antara pengguna dalam paket. Kasus pesimis: pengguna membayar lebih, dan biaya tidak dibagi. 731×755 77.6 KB

Sebuah perluasan dari model ini dapat mempertimbangkan kasus Bayesian, di mana pengguna memiliki akses ke distribusi atas n, yaitu, mereka dapat mengantisipasi beberapa variabel acak n pengguna untuk muncul pada setiap langkah waktu yang diberikan, sesuai dengan beberapa distribusi (misalnya, kedatangan Poisson), bahkan jika mereka tidak tahu sebelumnya hasil dari variabel acak. Ini dapat menyebabkan hasil yang tidak efisien, seperti yang ditunjukkan oleh contoh berikut:

Alice mengharapkan 9 pengguna lainnya selain dirinya sendiri, dan karena itu dia mengatur preVerificationGas-nya menjadi 1 karena dia tahu F = 10. Nilai Alice dan nilai semua pengguna lainnya kompatibel dengan mereka mengatur preVerificationGas = 3, tetapi dia mencoba membayar jumlah yang paling sedikit mungkin untuk inklusinya. Ternyata, hanya ada 5 pengguna yang muncul di pasar, yang semuanya mengatur preVerificationGas mereka menjadi 1 juga. Pembundler tidak akan diberi kompensasi untuk F = 10 unit gas, sehingga pembundler tidak mengeluarkan bundle dan pengguna menerima utilitas 0. Ini jelas suboptimal, karena pengguna dapat mengatur preVerificationGas = 2 misalnya dan menerima utilitas 1 (preVerificationGas maksimum yang mereka bersedia tetap dikurangi preVerificationGas aktual yang mereka bayar untuk dimasukkan).

Pekerjaan masa depan

Seperti yang ditunjukkan dalam permainan bundler, masalah alokasi dihadapi oleh pengguna yang ingin dimasukkan oleh bundler. Pada catatan berikutnya, kami akan membahas pendekatan yang berbeda untuk memulihkan “pengalaman pengguna yang baik” agar pengguna tidak membayar terlalu mahal kepada bundler yang lebih terinformasi tentang permintaan kapasitas bundelnya. Eksplorasi selanjutnya akan membutuhkan pemahaman tentang struktur pasar yang menghubungkan pengguna, bundler, dan pembangun / produsen blok bersama.

Penyangkalan:

1. Artikel ini dipublikasikan ulang dari [ ethresear], Semua hak cipta milik penulis asli [ DavideRezzoli]. Jika ada keberatan terhadap cetak ulang ini, harap hubungi Gate Belajartim kami akan menanganinya dengan segera.
2. Penyangkalan Tanggung Jawab: Pandangan dan pendapat yang tercantum dalam artikel ini semata-mata merupakan milik penulis dan tidak menjadi nasihat investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau melakukan plagiarisme terhadap artikel yang diterjemahkan dilarang.