Teruskan Judul Asli: Solana & Mekanisme Biaya Transaksi Ethereum: Proposal untuk Meningkatkan TFM Solana

Terima kasih kepada Andrew Fitzgerald, Harsh Patel, Jon Charbonneau, Kevin Galler, Lanre Ige, Mert Mumtaz, Pranav Garimidi, Ryan Chern, Tao Zhu, dan Tarun Chitra atas umpan balik dan tinjauannya.

Pengantar

Eclipse adalah SVM L2 pertama Ethereum. Kami sangat bersemangat untuk menghadirkan kekuatan SVM yang ada kepada lebih banyak pengguna, tetapi kami juga berdedikasi untuk mendorong pengembangan R&D yang sedang berlangsung di sekitar SVM itu sendiri. Kami fokus untuk memastikan bahwa pengembangan Eclipse tidak dapat disangkal lagi mengembalikan nilai ke semua rantai SVM, terutama Solana.

Sebagai pendahulu dari artikel-artikel selanjutnya mengenai pemikiran kami mengenai pasar biaya, artikel ini akan menganalisis pasar biaya Solana yang sudah ada dan usulan-usulan yang terkait untuk memperbaikinya. Kami menyusun proposal ini bersama dengan tujuan teoritis utama untuk setiap Mekanisme Biaya Transaksi (TFM), dengan meminjam banyak dari karya Tim Roughgarden, Maryam Bahrani, Pranav Garimidi, Hao Chung, Elaine Shi, dan lainnya. Kami akan menunjukkan definisi inti di seluruh bagian dengan **.

Secara umum, TFM yang menentukan:

1. Transaksi mana yang termasuk dalam blok tertentu,
2. Biaya yang dibayarkan oleh transaksi tertentu, dan
3. Bagaimana (dan kepada siapa) akumulasi biaya transaksi didistribusikan.

Pada akhirnya, artikel ini bertujuan untuk menggabungkan kekayaan penelitian TFM yang berpusat pada Ethereum dengan rekayasa inovatif Solana.

Gambaran Umum Solana & TFM Ethereum Saat Ini

Dasar-dasar Solana vs Ethereum

Kita akan mulai dengan tinjauan umum tentang TFM Solana dan membandingkannya dengan Ethereum. Hal ini akan memberikan kontekstualisasi yang lebih baik terhadap proposal yang relevan sehingga kami dapat bekerja untuk memodifikasi dan meningkatkan TFM. Sebagai permulaan:

Biaya dasar Solana adalah 5.000 lamport (0,000005 SOL) per tanda tangan, dan sebagian besar transaksi memiliki satu tanda tangan. Ini tidak memperhitungkan sumber daya komputasi transaksi yang lebih luas (yang diukur dengan CU).

Biaya Dasar Solana Tx = (5.000 Lamport) x (Jumlah Tanda Tangan di Tx)

Mekanisme biaya dasar Ethereum berbeda dalam dua cara utama:

1. Dinamis - Biaya dasar Ethereum (yang diukur dengan gwei per unit gas) mengambang berdasarkan permintaan pasar.
2. Biaya yang lebih terperinci per unit komputasi - Biaya dasar per transaksi Ethereum adalah linier dalam jumlah gas yang dikonsumsi.

Jadi, biaya dasar per transaksi Ethereum adalah:

Biaya Dasar Ethereum Tx =(Harga gas yang berlaku dalam gwei) x (gas yang digunakan dalam tx)

Pengguna Solana juga dapat menambahkan biaya prioritas opsional untuk meningkatkan probabilitas inklusi mereka. Berbeda dengan biaya dasar, biaya prioritas ditetapkan per CU yang diminta untuk suatu transaksi. Transaksi Solana dapat menyertakan instruksi Hitung Anggaran berikut ini:

1. SetComputeUnitLimit - Transaksi dapat menetapkan jumlah maksimum CU yang dapat digunakan (dengan maksimum 1,4 juta CU per transaksi). Ketika dieksekusi, transaksi dapat menggunakan hingga batas CU yang diminta. Jika tidak ada instruksi SetComputeUnitLimit yang diberikan, batas CU transaksi dihitung sebagai (jumlah instruksi dalam transaksi) x(200k CU).
2. SetComputeUnitPrice - Jumlah lampu mikro per CU yang diminta oleh transaksi untuk membayar biaya prioritas.

Menyatukan mereka:

Biaya Prioritas Tx = (Batas CU Tx) x (Harga CU)

Perhatikan bahwa biaya prioritas ini dibayarkan terhadap seluruh CU yang diminta (terlepas dari apakah transaksi menggunakan jumlah total yang diminta), tidak seperti di Ethereum, di mana biaya merupakan fungsi dari berapa banyak gas yang sebenarnya digunakan oleh transaksi.

Pembakaran Biaya vs Imbalan Validator

Meskipun insentif bagi validator untuk memprioritaskan transaksi dengan biaya tinggi berada di luar konsensus, namun hal ini diberlakukan dalam konsensus bahwa biaya dasar dan biaya prioritas dibakar/dikirimkan 50/50 kepada pemimpin (produsen blok saat ini) di Solana:

1. Biaya Dasar - Wajib untuk penyertaan blok. Transaksi yang tidak memiliki biaya dasar yang disyaratkan akan ditolak.
2. Biaya Prioritas - Tidak wajib untuk penyertaan blok. Digunakan untuk memprioritaskan transaksi secara opsional yang ingin meningkatkan probabilitas inklusi cepat.

Pengguna tidak dapat menghindari pembayaran biaya dasar, tetapi pengguna dapat menghindari biaya prioritas dan menandakan keinginan mereka untuk diprioritaskan dengan cara lain. Kami sudah melihat hal ini dalam praktiknya - lelang Jito-Solana membayar 100% (dikurangi biaya) kepada pemimpin lelang. SIMD-0096 menawarkan perbaikan sederhana untuk masalah ini, dengan memberikan 100% biaya prioritas kepada validator.

Transfer Langsung*: Dikoordinasikan melalui lelang MEV-Boost / Jito-Solana

Yang terpenting, validator Solana memberikan suara untuk setiap blok dengan transaksi on-chain. Mereka membayar biaya dasar untuk setiap transaksi ini.

Solana telah menghasilkan biaya jaringan tertinggi sepanjang masa akhir-akhir ini, didorong oleh peningkatan tajam dalam biaya prioritas. Pembagian biaya terbaru ditunjukkan di bawah ini:

Sumber: Solana Compass

Pembangun Blok Ethereum vs Penjadwal Solana

Produksi blok Ethereum secara umum lebih mudah dipahami, jadi kita akan mulai dari sana. Hampir semua validator (alias pengusul) mengalihdayakan produksi blok ke pembuat di luar protokol melalui MEV-Boost. Pembangun membuat blok setiap 12 detik (waktu slot Ethereum) dan meneruskan seluruh blok ini ke pengusul (melalui relai), yang memilih blok dengan nilai tertinggi.

Baik di Ethereum maupun Solana, produsen blok memiliki kekuatan untuk memerintahkan transaksi secara sewenang-wenang di dalam blok. Mereka diberi insentif untuk melakukannya dengan cara yang memaksimalkan keuntungan mereka. Sebagai contoh, pembangun Ethereum yang berbeda dapat bersaing dengan menjalankan algoritme eksklusif yang lebih efektif memaksimalkan keuntungan dibandingkan pesaing.

Ini berarti bahwa bahkan dalam Ethereum, mengirimkan biaya prioritas tinggi tidak mencapai jaminan deterministik dalam protokol untuk inklusi atau pemesanan blok. Akan tetapi, hal ini sangat mungkin untuk mencapai hasil yang diharapkan karena sifat dari proses pembangunan blok Ethereum saat ini di mana pembuat blok membangun blok yang memaksimalkan keuntungan secara penuh pada akhir setiap slot diskrit.

Sebagai contoh, pencari dapat mengirimkan transaksi arbitrase dengan biaya prioritas yang sangat tinggi (misalnya, lebih tinggi dari semua transaksi lain yang memenuhi syarat digabungkan) kepada pembuat, meminta untuk dimasukkan ke bagian atas blok dan untuk mengecualikan transaksi tersebut dari blok sepenuhnya jika tidak mendapatkan posisi teratas blok. Dalam kasus ini, seorang pembangun yang memaksimalkan keuntungan secara rasional akan memasukkan transaksi ini di bagian atas blok meskipun mereka hanya menerimanya tepat di akhir slot 12 detik mereka.

Anda akan melihat bahwa ada dua jaminan berbeda yang ingin dicapai oleh biaya di sini:

1. Penyertaan - Seorang pengguna ingin agar transaksi mereka disertakan dalam blok ini, tetapi mereka tidak peduli di mana transaksi tersebut berada dalam blok.
2. Pemesanan - Seorang pengguna tidak hanya ingin dimasukkan ke dalam blok di mana saja; mereka menginginkan akses prioritas ke status tertentu pada waktu tertentu.

Mekanisme EIP-1559 Ethereum telah terbukti cukup efektif dalam memungkinkan pengguna untuk dengan mudah mengajukan penawaran untuk penyertaan blok dengan probabilitas keberhasilan yang tinggi. Ada harga cadangan global yang semua orang tahu harus dibayar, dan membayarnya (biasanya bersama dengan biaya prioritas nominal) akan membuat transaksi pengguna segera dimasukkan. Namun, mekanisme ini tidak berusaha untuk memberikan jaminan apa pun seputar pemesanan (yaitu, akses prioritas ke state), sedangkan mekanisme di luar protokol dapat diandalkan untuk pengguna yang mencari jaminan seperti itu (langsung dari pembuat, misalnya).

Proses pembangunan blok Solana bekerja dengan cara yang sangat berbeda. Validator tidak mengalihdayakan produksi blok penuh dalam slot waktu diskrit ke pembuat di luar protokol. "Penjadwal" adalah algoritme default yang disertakan dalam klien validator Solana Labs, yang menjadwalkan transaksi untuk dieksekusi dan membangun blok secara terus menerus.

Selain itu, transaksi Solana menentukan akun apa saja yang harus dikunci baca dan tulisnya untuk dieksekusi. Hal ini memungkinkan penjadwal untuk mengurutkan transaksi mana yang dapat dieksekusi secara bersamaan secara berulang - karena transaksi yang tidak menyentuh state yang sama dapat dieksekusi secara paralel.

Dalam satu blok, maksimum 12.000.000 CU dapat digunakan untuk penulisan berurutan ke satu akun ("potongan negara"). Ini kira-kira jumlah CU yang dapat diproses oleh satu thread per slot 400ms pada persyaratan node yang wajar. Batas per blok Solana kemudian menjadi 48.000.000 CU. Implementasi penjadwal saat ini menggunakan empat utas untuk transaksi non-vote, dan 12 juta x 4 = 48 juta. Secara teori, ini berarti menggunakan lebih banyak core = meningkatkan batas CU. Penskalaan dengan perangkat keras.

Penjadwal secara non-deterministik memprioritaskan transaksi dengan biaya prioritas yang lebih tinggi. Akan tetapi, hal ini secara umum memberikan jaminan prioritas yang kurang dapat diandalkan dibandingkan dengan mekanisme seperti yang dijelaskan dalam kasus Ethereum saat ini.

Di Solana, validator menjalankan penjadwal default membangun blok secara terus menerus, sehingga transaksi dapat ditambahkan ke blok yang sedang berjalan dan dieksekusi sebelum menunggu hingga akhir slot untuk mengaturnya hanya dengan biaya prioritas. Tujuannya adalah agar penjadwal dapat memaksimalkan keuntungan secara kasar dengan memprioritaskan transaksi berdasarkan total harga CU.

Penjadwal multi-threaded default Solana juga memperkenalkan "jitter" tambahan. Transaksi ditugaskan secara acak ke salah satu dari empat thread, dengan setiap thread mempertahankan antrian transaksinya sendiri yang menunggu eksekusi. Biaya prioritas kemudian digunakan untuk memprioritaskan transaksi intra-thread. Namun, mereka tidak membantu memprioritaskan transaksi antar-benang.

Sebagai contoh, dua pencari dapat mengirimkan transaksi secara bersamaan untuk mendapatkan peluang arbitrase yang sama, dan yang mengirimkan biaya prioritas yang lebih rendah bahkan dapat menang karena secara kebetulan berada di antrian yang tidak terlalu padat. Hal ini mengurangi keefektifan biaya prioritas dan meningkatkan insentif untuk melakukan spam relatif terhadap Ethereum - terutama karena penyertaan untuk transaksi juga bergantung pada kapan, dalam slot tertentu, sebuah transaksi sampai ke produsen blok saat ini.

Perhatikan bahwa ada perubahan yang direncanakan pada penjadwal default Solana, yang bertujuan untuk mengatasi beberapa masalah dengan implementasi saat ini dengan mengandalkan grafik ketergantungan transaksi dan menjadwalkan transaksi yang tidak diblokir (non-write-locked) dengan prioritas tertinggi dalam grafik - kita akan membahasnya nanti dalam artikel ini.

Meskipun sebagian besar berada di luar cakupan artikel ini, klien Jito-Solana memungkinkan para pencari untuk menangkap penambang/nilai maksimal yang dapat diekstrak (MEV) secara lebih efisien dengan cara yang meminimalkan eksternalitas negatif pada Solana. Jito-Solana menyimpang dari penjadwal default Solana dengan memperkenalkan lelang bundel diskrit 200 milidetik Flashbots-esque di luar protokol, yang dijalankan secara paralel dengan produksi blok kontinu default dan mempool pribadi (yang sekali lagi menyimpang dari TFM default Solana). Pengadopsian klien Jito-Solana oleh para validator Solana (>50% validator menjalankannya saat ini) telah membantu mengatasi beberapa masalah dengan TFM Solana yang sudah ada - yaitu, prevalensi spam yang digerakkan oleh MEV.

Kekurangan dari TFM Solana saat ini

Meskipun TFM Solana sangat menjanjikan, TFM ini juga memiliki beberapa potensi kekurangan untuk saat ini:

Insentif untuk Spam

Seperti yang disebutkan di atas, transaksi diurutkan dengan cara masuk pertama, keluar pertama (FIFO) segera setelah mereka mencapai produsen blok. Selain itu, mereka tunduk pada ketidakpastian dari jitter jaringan dan alokasi thread secara acak dari penjadwal default. Meskipun biaya prioritas dapat membantu probabilitas inklusi dalam keadaan tertentu, insentif yang substansial masih ada untuk transaksi spam untuk memaksimalkan probabilitas inklusi tercepat (misalnya, pencari yang berlomba untuk melikuidasi posisi in-default di pasar pinjaman). Gambar di bawah ini dari Jito Labs membantu menunjukkan sifat transaksi spam yang tidak optimal.

Sumber: Yayasan Jito

Lelang Harga Pertama

Dalam lelang harga pertama (FPA) yang naif, pengguna hanya mengirimkan penawaran, dengan penawaran tertinggi yang akan dimasukkan ke dalam blok. Satu masalah dengan FPA adalah bahwa mereka tidak terlalu ramah pengguna. Pengguna harus menebak apa yang ditawar oleh pengguna lain, memikirkan berapa banyak yang bersedia mereka tawar, sehingga berpotensi membuat tawaran mereka lebih rendah agar tidak membayar lebih berdasarkan apa yang mereka yakini sebagai tawaran pengguna lain, misalnya.

Secara lebih formal, model FPA adalah non-DSIC:

**Dominant Strategy Incentive Compatible (DSIC): Dengan asumsi bahwa produsen blok mengimplementasikan TFM dengan jujur, maka strategi penawaran yang ditentukan harus menjadi strategi yang dominan bagi pengguna. Ini berarti pengguna akan menawar (dalam biaya transaksi) pada nilai yang sama persis dengan nilai yang mereka anggap sebagai inklusi transaksi [Chu22].

DSIC adalah salah satu properti utama yang ingin diperkenalkan oleh pencipta EIP-1559 ke dalam TFM Ethereum dengan implementasinya, dan seperti yang telah kami jelaskan sebelumnya, hal ini dapat dikatakan sukses. Pengguna lebih mudah mengetahui harga cadangan publik yang akan dimasukkan ke dalam blok pada waktu tertentu (melalui biaya dasar dinamis), sehingga membayarnya (ditambah dengan biaya prioritas nominal) hampir selalu akan membuat transaksi Anda dimasukkan dengan cepat.

Sebaliknya, TFM Solana adalah FPA yang naif. Tidak ada mekanisme yang dapat diandalkan bagi pengguna untuk mengekspresikan preferensi mereka secara akurat untuk penyertaan blok dan non-DSIC. Dalam praktiknya, mencoba menetapkan biaya prioritas yang tepat pada waktu yang tepat sangatlah menantang. Hal ini secara tidak proporsional menguntungkan peserta yang canggih yang lebih mampu melewati jitter jaringan dan penjadwal (misalnya, melalui lokasi bersama atau transaksi spamming).

50/50 Pembayaran Burn/Validator

Seperti yang telah disebutkan sebelumnya, Ethereum membakar 100% dari biaya dasar dan mengirimkan 100% dari biaya prioritas kepada produsen blok, sedangkan untuk Solana, biaya dasar dan biaya prioritas dibakar/dibayarkan 50/50 kepada produsen blok. Sebagai akibatnya, Solana TFM tidak tahan terhadap OCA:

**Kebenaran Perjanjian Off-Chain (OCA-proofness atau SCP): Tidak ada perjanjian off-chain antara pengguna dan produsen blok yang dapat secara Pareto meningkatkan hasil TFM untuk blok tertentu [Rou21]. Protokol c-SCP tahan terhadap koalisi produsen blok dan hingga c pengguna yang dapat mengambil keuntungan dengan menyimpang dari pelaporan yang benar.

Kami melihat contoh yang jelas tentang hal ini dengan lelang di luar protokol Jito-Solana yang membayar 100% dari penawaran (dikurangi potongan Jito) kepada produsen blok, daripada membakar 50% - Jito-Solana adalah contoh Perjanjian Off-Chain yang digunakan oleh produsen blok. Namun, kami mencatat bahwa tip Jito-Solana tidak sama dengan biaya prioritas, karena biaya prioritas hanya dibayarkan jika transaksi (dan bundel) yang terkait berhasil dieksekusi.

SIMD-0109 yang baru-baru ini diusulkan akan memperkenalkan mekanisme tipping (mirip dengan yang digunakan oleh lelang out-protocol Jito-Solana) ke dalam protokol sebagai instruksi asli.

Kurangnya Jenis Transaksi yang Diistimewakan

Transaksi suara Solana diposting secara on-chain dan harus dimasukkan ke dalam blok, namun setiap validator harus membayar biaya transaksi tersebut. Ini merupakan biaya tetap yang signifikan (dibayar secara pribadi oleh validator) meskipun ada eksternalitas positif dari penyertaan transaksi suara. Biaya ini diperparah oleh fakta bahwa transaksi suara dibebankan secara berlebihan dibandingkan dengan CU yang digunakan (yaitu, mereka menggunakan CU yang relatif sedikit dibandingkan dengan rata-rata transaksi). Ekonomi menciptakan efek sentralisasi di sini, karena total biaya pemungutan suara kurang lebih konstan untuk semua validator, sementara hadiah yang diperoleh sebanding dengan bobot taruhan.

Sumber: Ceteris, Solana sang Monolit

Sebagai tambahan, logika yang sama dapat diperluas untuk menyertakan pembaruan oracle yang dapat diandalkan, yang biasanya dibebankan pada jaringan meskipun ada eksternalitas positif dari umpan harga on-chain yang akurat. Rantai yang lebih banyak berpendapat yang memperoleh nilai tinggi dari oracle kuat tertentu dapat memilih untuk mengabadikan mekanisme yang mensubsidi biayanya.

Pasar Biaya Lokal Solana

Perkiraan Solana tentang mekanisme biaya lokal ada karena tidak ada akun yang dapat menulis lebih dari 12 juta CU per batas blok 48 juta. Hal ini, bersama dengan sifat multi-threaded dari penjadwal default Solana, berarti bahwa maksimum 25% transaksi dalam satu blok dapat berhubungan dengan satu bagian dari status permintaan. Secara teori, pengguna dengan status kurang diminati seharusnya tidak perlu meningkatkan biaya prioritas mereka untuk mendapatkan jaminan inklusi yang kuat dibandingkan dengan pengguna dengan status diminati.

Ini bisa dibilang bukan mekanisme biaya lokal yang asli. Mekanisme ini tidak ditegakkan oleh konsensus (hanya pada tingkat penjadwal), dan hubungan antara biaya prioritas dan penyertaan blok agak tidak deterministik (seperti yang telah disebutkan sebelumnya). Ini juga tidak memiliki gagasan 'elastisitas' di mana target dan batas sumber daya maksimum ada.

Penggunaan CU yang tidak efisien & Permintaan

Karena biaya dasar Solana tidak memperhitungkan CU, maka Solana tidak memberikan insentif untuk transaksi:

1. Gunakan CU secara efisien - Transaksi dengan 1,4 juta CU memiliki biaya dasar yang sama dengan transaksi dengan 100 ribu CU, dengan catatan semua biaya lainnya sama.
2. Meminta CU secara efisien - Meskipun transaksi menggunakan 50 ribu CU, biaya dasar yang dikenakan tetap sama, baik saat meminta 100 ribu CU atau 1 juta CU.

Hal ini dapat menyebabkan estimasi yang terlalu tinggi dari komputasi yang dibutuhkan dalam blok yang diberikan oleh penjadwal dan kehilangan efisiensi dibandingkan dengan sumber daya yang dibutuhkan oleh produsen blok pada slot yang diberikan. TFM DSIC akan mengatasi masalah ini karena strategi dominan pengguna adalah strategi penawaran yang ditentukan - dalam hal ini, secara akurat mewakili penggunaan CU yang diharapkan.

Tanpa Biaya untuk Menulis Akun Kunci

Seperti yang telah disebutkan sebelumnya, transaksi Solana menentukan di awal semua akun yang akan dibaca atau ditulis saat dieksekusi. Namun, mekanisme ini dapat disalahgunakan saat ini untuk mengunci akun apa pun secara global tanpa biaya. Sebagai contoh:

1. Saya mengirim_TxA yang menentukan bahwa ia akan menulis ke_AccountA.
2. Pemimpin menerima_TxA, menjadwalkannya, dan mulai menjalankannya. _AccountA sekarang terkunci - tidak ada transaksi lain yang menyentuh_AccountA yang dapat dieksekusi sampai_TxA selesai dieksekusi.

Masalahnya berasal dari fakta bahwa siapa pun dapat mengirim transaksi yang mengunci akun apa pun yang mereka inginkan. Tidak ada biaya untuk mengunci akun, dan transaksi bahkan dapat mengunci akun yang tidak mereka gunakan, yang merupakan vektor serangan spam yang jelas. Selain itu, pemilik akun tidak memiliki kendali atas siapa yang dapat mengunci akun mereka sendiri.

Proposal TFM & Kerangka Kerja

Setiap blockchain pada akhirnya harus memutuskan bagaimana cara mengalokasikan sumber daya yang langka dari ruang blok yang terbatas di antara para pengguna, yang dilakukan melalui TFM-nya. Di bawah ini, kami akan membahas beberapa proposal dan kerangka kerja TFM yang relevan yang mungkin bermanfaat bagi Solana.

Pasar Biaya Blockchain Multidimensi

Sebagian besar pasar biaya yang ada saat ini adalah satu dimensi, dibangun di sekitar satu unit akun yang dapat dipertukarkan (misalnya, gas dalam Ethereum). Namun, sumber daya tunggal yang dibeli ini merupakan proksi untuk banyak sumber daya yang tidak dapat dipertukarkan (misalnya, bandwidth, komputasi, dan penyimpanan).

Sebagai contoh, setiap opcode Ethereum membawa jumlah gas tertentu yang tetap yang dikonsumsinya (misalnya, ADD menggunakan 3 gas, sedangkan MUL menggunakan 5). Harga gas untuk setiap opcode ditetapkan sebagai perkiraan kasar dari sumber daya dasar yang mereka gunakan dan seberapa mahal harga tersebut untuk node dalam jaringan. Sebagai contoh, ukuran implisit dari biaya operasi ini dapat ditentukan dengan menjalankan tolok ukur pada perangkat keras dunia nyata.

Namun, dimungkinkan juga untuk membangun pasar biaya multidimensi yang secara individual memberi harga pada sumber daya yang tidak dapat dipertukarkan ini daripada menggabungkannya ke dalam satu unit. EIP-4844 adalah pasar biaya dua dimensi langsung, karena gumpalan data memiliki pasar biaya sendiri yang tidak bergantung pada gas eksekusi Ethereum.

Makalah tahun 2022 oleh Diamandis, Evans, Chitra, dan Angeris ini menganalisis bagaimana membangun pasar biaya multidimensi seperti ini. Pekerjaan mereka membingkai masalah konstruksi TFM dari sudut pandang perancang jaringan yang bertujuan untuk memaksimalkan kesejahteraan (atau utilitas total) pengguna blockchain dikurangi konsumsi sumber daya dari pengguna tersebut, tunduk pada transaksi rantai dan batasan blok (misalnya, batas kontrak pintar atau batas CU/gas). Hasil utama dari makalah ini adalah bahwa meskipun kesejahteraan tidak diketahui, mereka merancang sebuah mekanisme yang memaksimalkannya dan menunjukkan bagaimana membangun mekanisme tersebut secara eksplisit.

**Memaksimalkan Kesejahteraan: Aturan alokasi dan pembayaran yang dimaksudkan menyiratkan bahwa jumlah surplus konsumen dan penambang (kurang lebih) dimaksimalkan.

Temuan utama mereka adalah bahwa TFM yang setara dapat diimplementasikan, yaitu di mana harga sumber daya ditetapkan untuk meminimalkan perbedaan antara kesejahteraan validator dan penggunanya - harga seperti itu seharusnya mengarah pada blok yang, secara teori, optimal dari sudut pandang pemaksimalan kesejahteraan. Walaupun pekerjaan ini dapat dilihat lebih sebagai sebuah kerangka kerja akademis untuk mendesain TFM yang optimal, hal ini membantu untuk menunjukkan bahwa penetapan harga sumber daya secara terpisah dapat membuat blockchain lebih efisien dan lebih tahan terhadap periode kemacetan atau spam yang tinggi. Mekanisme biaya dasar berbasis pengontrol, seperti EIP-1559, disorot sebagai pendekatan potensial yang dapat bekerja dengan sangat baik pada rantai Solana dan SVM, mengingat waktu blok yang singkat, memungkinkan biaya dasar untuk menyesuaikan dengan cepat terhadap perubahan permintaan pengguna dan ketersediaan sumber daya.

Seperti yang telah disebutkan sebelumnya, salah satu kesimpulan dari makalah ini adalah bahwa sangat mungkin untuk merancang cara yang sistematis dan efisien secara komputasi untuk membantu mendefinisikan dan memperbarui harga sumber daya multidimensi untuk blockchain. Namun, pertanyaan yang wajar adalah: sumber daya apa yang masuk akal untuk diberi harga yang berbeda? Beberapa pekerjaan praktis telah dilakukan dalam konteks blockchain lainnya untuk membuat keputusan seperti itu. Sebagai contoh, Penumbra telah menerapkan sebuah bentuk penetapan harga sumber daya multidimensi untuk menetapkan harga sumber daya yang digunakan oleh node penuh dan perangkat pengguna akhir secara terpisah pada blockchain yang berpusat pada privasi.

Meskipun makalah 2022 secara umum membahas penetapan harga multidimensi sumber daya dasar (misalnya, komputasi, bandwidth, penyimpanan), namun juga memungkinkan untuk menerapkan penetapan harga sumber daya multidimensi per akun (misalnya, per "piece of state"). Setiap akun diperlakukan sebagai sumber daya yang berbeda. Hal ini dibahas dalam artikel terbaru ini, yang dikembangkan dari makalah aslinya. Penetapan harga akun secara individual (bukan komputasi, penyimpanan, bandwidth, dll.) sebagai sumber daya yang mendasari mungkin juga lebih mudah untuk diterapkan dengan mengurangi risiko serangan kehabisan sumber daya.

Biaya Eksponensial untuk Akun Write Lock

Menyusul postingan Anatoly baru-baru ini tentang SVM Execution Economics, Tao Zhu, berkolaborasi dengan Anatoly, mengusulkan SIMD-0110. Motivasi utamanya adalah untuk mencegah spam dengan tekanan ekonomi (yaitu, meningkatkan biaya dengan cara yang ditargetkan dari waktu ke waktu untuk mengurangi insentif untuk spam), sehingga menghasilkan pemanfaatan sumber daya jaringan yang lebih efisien. Transaksi arbitrase yang gagal terus mengisi sekitar setengah (atau lebih) dari ruang blok Solana karena rasional dan sangat murah untuk menjadi spam.

Proposal tersebut merekomendasikan untuk melacak Exponential Moving Average (EMA) dari penggunaan CU setiap akun per blok untuk mencapai hal ini. Biaya untuk mengunci akun akan meningkat secara eksponensial berdasarkan penggunaan CU yang tertinggal, sehingga dapat mencegah spam. Logika intinya mirip dengan bagaimana EIP-1559 menetapkan biaya dasar global Ethereum sebagai fungsi dari penggunaan gas di blok-blok yang tertinggal. Namun, SIMD ini jauh lebih terperinci dalam menetapkan pasar biaya dasar lokal per akun.

Ide implementasi dasar untuk biaya penguncian tulis bervariasi berbasis akun adalah sebagai berikut:

1. Lacak penggunaan unit komputasi EMA setiap akun yang diperdebatkan selama 150 slot terakhir.
2. Jumlah maksimum akun yang akan dilacak adalah 2048, di mana hanya akun yang paling banyak diperdebatkan dengan tingkat biaya penguncian tulis tertinggi yang akan dilacak.
3. Jika penggunaan unit komputasi EMA akun adalah >50% dari batas maksimum CU-nya, tarif biaya penguncian tulis akan meningkat sebesar X%. Jika <50% dari batasnya, tarif biaya akan turun sebesar X%.
4. V0 merekomendasikan tingkat biaya write-lock awal sebesar 1000 micro-lamport/CU dan tingkat penyesuaian tingkat biaya sebesar 1% per slot (harap diperhatikan bahwa persentase yang tepat di sini dapat berubah karena sifatnya yang masih awal).
5. Biaya penguncian tulis untuk suatu akun pada blok tertentu dihitung dengan mengalikan tarif biaya penguncian tulis dengan CU yang diminta oleh transaksi.
6. Transaksi tetap membayar biaya tanda tangan, dan biaya prioritas opsional juga tetap ada.
7. Biaya write-lock yang terkumpul 100% dibakar.
8. Biaya prioritas yang terkumpul akan dihargai 100%.
9. Biaya tanda tangan yang terkumpul adalah 50% dibakar dan 50% dihargai.

Proposal ini akan membuat fitur write-lock dari Solana (biasanya) DSIC mirip dengan bagaimana EIP-1559 membuat TFM Ethereum (biasanya) DSIC dan MMIC [Rou23 ] - kecuali dengan adanya lonjakan biaya yang tiba-tiba.

Kita dapat mendefinisikan properti MMIC sebagai berikut:

**Kompatibilitas Insentif Penambang Myopic (MMIC): Produsen blok memaksimalkan kegunaannya dengan tidak membuat transaksi palsu dan mengikuti aturan TFM yang telah ditetapkan. Myopic berarti tujuan ini hanya memperhatikan blok saat ini ketika menilai maksimalisasi utilitas [Rou21].

Setiap mekanisme trailing tidak sempurna karena mungkin tidak secara akurat mewakili kondisi permintaan saat ini. Misalnya, permintaan mungkin rendah untuk jangka waktu yang lama (dan dengan demikian, biaya dasar dinamis menjadi rendah), kemudian melonjak secara tiba-tiba untuk pencetakan NFT. Hal ini dapat terjadi di tingkat global (seperti di TFM Ethereum) dan mungkin lebih tidak stabil di tingkat lokal per akun (seperti yang dipertimbangkan dalam SIMD-0110).

Namun, Solana juga diuntungkan dengan waktu blok yang sangat rendah di sini. Hal ini dapat memungkinkan biaya dasar untuk menyesuaikan lebih cepat terhadap guncangan permintaan yang tiba-tiba, tergantung pada seberapa agresif kurva diatur untuk bergerak. Bentuk pengendali biaya di sini sangat penting.

Fakta bahwa biaya penguncian tulis ini dibebankan pada CU yang diminta juga memberikan insentif yang tepat bagi pengguna dan pengembang untuk memperkirakan penggunaan CU transaksi secara akurat. Hal ini menghindari masalah yang telah kita bahas sebelumnya, di mana basis tanda tangan datar saat ini tidak memiliki penalti untuk meminta lebih banyak CU daripada yang diperlukan (bahkan hingga maksimal 1,4mm CU). Jika tidak, hanya biaya prioritas yang mendapatkan insentif ini hari ini (karena biaya ini juga dibebankan oleh CU yang meminta).

Salah satu kritik potensial di sini adalah bahwa pasar biaya lokal berbasis akun (terutama proposal ini, yang mengharuskan EMA yang sedang berlangsung untuk dihitung untuk setiap akun) dapat menjadi mahal secara komputasi. Jenis biaya multidimensi ini tidak terbatas, mengingat bahwa setiap akun dapat mengalami kemacetan, yang kemungkinan akan menimbulkan kesulitan bagi TFM semacam itu. Namun, dalam kasus SIMD-0110, hal ini dihindari dengan menetapkan batas atas pada jumlah akun yang EMA penggunaan CU-nya dapat dilacak pada waktu tertentu.

** Dapat Dihitung Secara Efisien: Mekanisme lelang blok harus dirancang sedemikian rupa sehingga dapat dikomputasi secara efisien untuk produsen (atau pembuat) blok tertentu - slot Eclipse dan Solana kurang dari 400ms, yang memberikan batasan ketat pada waktu komputasi maksimum untuk blok tertentu.

Mengingat bahwa penyertaan blok Solana masih akan bersifat non-deterministik bahkan dengan penerapan proposal ini, masih ada potensi masalah dengan pengguna yang secara akurat memperbarui penawaran mereka secara real-time untuk memastikan transaksi mereka disertakan dalam blok. Untuk mengatasi hal ini lebih lanjut, diperlukan perubahan pada penjadwal seperti yang akan kita bahas pada bagian berikutnya.

Perubahan pada Penjadwal Default Solana

Seperti yang telah dibahas sebelumnya, "scheduler" adalah algoritma default yang disertakan dalam klien validator Solana Labs, yang menjadwalkan transaksi untuk dieksekusi dan membangun blok secara terus menerus. Ini memainkan peran yang sangat penting dalam pasar biaya Solana meskipun perilaku defaultnya tidak diberlakukan dalam protokol karena validator dapat memilih untuk menjalankan algoritme lain. Di sini kita akan fokus pada penjadwal saat ini dan perubahan yang diusulkan yang akan datang, yang sedang dikerjakan oleh Andrew Fitzgerald.

Penjadwal Solana saat ini memperkenalkan "jitter" dalam penanganan transaksi pengguna dengan secara acak menempatkan mereka ke salah satu dari empat thread transaksi non-vote (dua thread tambahan dicadangkan untuk memproses transaksi vote) sebelum mencoba mengurutkan transaksi yang belum terselesaikan berdasarkan biaya prioritas dan memeriksa kunci yang relevan ('lock grab'), seperti yang ditunjukkan pada diagram di bawah ini. Beberapa batch transaksi ditarik untuk dialokasikan ke thread selama "Banking Stage" - proses yang dijalankan oleh validator Solana di mana transaksi diproses dan di mana proses penjadwalan terjadi.

Sumber: Andrew Fitzgerald, Panggung dan Penjadwal Perbankan Solana

Salah satu masalah signifikan dengan penjadwal default adalah bahwa selama periode aktivitas jaringan yang intens, antrean setiap thread sering kali diisi dengan transaksi yang saling bertentangan (misalnya sebelum pencetakan NFT atau acara pembuatan token yang diantisipasi secara luas). Setiap thread dapat berisi transaksi dengan kunci baca atau tulis yang sama atau tumpang tindih, yang berarti transaksi tersebut harus dijadwalkan ulang untuk dieksekusi nanti. Akan tetapi, hasil dari hal ini adalah bahwa dalam kasus terburuk yang ekstrim, hanya satu dari empat thread penjadwal default yang dapat mengeksekusi transaksi pada waktu tertentu.

Inti dari peningkatan ke penjadwal default Solana terletak pada transisi dari pendekatan lama (dinamai mode ThreadLocalMultiIterator) ke pendekatan baru untuk penjadwalan, yang dinamai mode CentralScheduler. Artikel ini hanya akan memberikan gambaran umum dan analisis perubahannya. Namun, informasi lebih lanjut dapat ditemukan di artikel Andrew Fitzgerald dan artikel yang menyertainya <a href="https://medium.com/@harshpatel_36138/apa-yang-baru-dengan-solana-s-transaction-scheduler-bcf79a7d33f7"> rangkuman blogpost oleh Harsh Patel dari tim Tiny Dancer. Gambaran umum proses penjadwalan yang baru ditunjukkan di bawah ini.

Sumber: Andrew Fitzgerald, Panggung dan Penjadwal Perbankan Solana

Penjadwal baru ini melibatkan penjadwal tunggal pusat yang menerima transaksi dari saluran sebelum memeriksa kunci yang relevan. Setelah titik ini, transaksi ditugaskan ke thread pekerja paralel tertentu untuk dieksekusi. Penjadwal pusat memiliki pandangan tentang berbagai kunci baca dan tulis yang digunakan oleh thread pekerja tertentu, yang memungkinkannya untuk menentukan thread terbaik untuk transaksi baru. Ketika transaksi dieksekusi dan diproses oleh thread pekerja yang diberikan, sebuah pesan dikirim kembali ke penjadwal pusat sehingga dapat mengevaluasi kembali bagian mana dari state Solana yang dianggap terkunci.

Penjadwal menggunakan algoritma yang disebut sebagai "prio-graph," yang merupakan grafik akrilik langsung yang dimulai dengan transaksi prioritas (biaya) tertinggi dan garis (atau, lebih tepatnya, tepi) antara transaksi prioritas tertinggi yang diberikan dan transaksi prioritas tertinggi berikutnya yang bertentangan dengannya karena kunci yang tumpang tindih. Hal ini (sementara) dilakukan untuk jendela "look-ahead" dengan ukuran yang sudah dikonfigurasikan sebelumnya yaitu 2.048 (dapat berubah) transaksi, yang dapat ditambahkan ke dalam grafik - grafik berikut ini menunjukkan bagaimana prio-grafik bekerja untuk sekumpulan transaksi tertentu di mana sisi-sisi di antaranya mewakili kunci yang saling bertentangan.

Selain mengadopsi penjadwal prio-grafik, versi ini memperkenalkan efisiensi tambahan untuk membantu mengurangi overhead pemrosesan, seperti menghapus elemen yang berlebihan dari tahap perbankan. Penjadwal yang baru seharusnya dapat meningkatkan dengan secara signifikan mengurangi kemungkinan kegagalan penulisan dan penguncian baca selama periode aktivitas yang tinggi di Solana. Kita bisa mengharapkan pengurangan jitter karena penjadwal default yang baru. Namun, mengingat sifat berkelanjutan dari proses pembangunan blok, akan terus ada non-determinisme dalam inklusi blok.

Biaya Program Rebatable Account Write (PRAW)

Ditulis oleh Godmode Galactus dan Max Schneider, SIMD-0016 mengusulkan biaya Program Rebatable Account Write (PRAW). Mereka akan memberikan kontrol yang signifikan kepada pengembang aplikasi, karena mereka dapat menetapkan kriteria pembayaran dan potongan harga dari biaya-biaya ini, yang memungkinkan mereka untuk memberikan insentif dan disinsentif terhadap perilaku pengguna sesuai keinginan mereka.

Saat ini, program Solana tidak memiliki kemampuan untuk menghukum transaksi yang mendapatkan kunci tulis atas statusnya. Biaya PRAW akan memungkinkan pemilik akun Solana untuk menagih biaya atas transaksi yang gagal yang mengunci status mereka. Biaya ini akan ditransfer ke akun yang dapat ditulis yang mereka kunci. Namun, pemilik akun dapat mengatur biaya ini sedemikian rupa sehingga biaya tersebut akan dikembalikan kepada pengguna di akhir transaksi jika memenuhi kriteria yang ditentukan.

Secara khusus, hal ini dapat mencegah pengguna untuk mengunci akun yang sebenarnya tidak mereka gunakan dalam eksekusi transaksi. Hal ini saat ini dimungkinkan karena Solana saat ini tidak memiliki pemeriksaan untuk melihat apakah akun tertentu akan digunakan, secara apriori, oleh transaksi tertentu yang telah menguncinya. PRAW menawarkan program sebuah cara untuk memberikan disinsentif pada transaksi yang mengunci status program dalam upaya untuk mengidentifikasi peluang dengan tujuan untuk kembali jika peluang tersebut tidak lagi valid pada saat eksekusi. Biaya ini akan diberlakukan bahkan jika transaksi gagal selama eksekusi.

Sebaliknya, pengguna dapat menentukan jumlah maksimum biaya PRAW yang ingin mereka bayarkan dalam sebuah transaksi. Setiap biaya yang ditentukan dalam transaksi di atas biaya PRAW saat ini untuk akun yang dikunci tulis akan dikembalikan.

Anggota komunitas Solana menandai beberapa masalah dengan proposal ini: kemampuan berbagai program untuk beroperasi sepenuhnya secara otonom tampaknya kurang optimal, dan kemampuan untuk memperkirakan biaya secara akurat akan sulit dilakukan. Selain itu, ada cara yang berpotensi lebih sederhana dan lebih seragam untuk menangani masalah duka seputar akun yang dikunci tulis, seperti SIMD-0110.

**Resistensi Duka Cita (Griefing Resistance): Sebuah subset dari DSIC di mana pengguna tidak diberi insentif untuk salah mengartikan daftar akses mereka - salah menyatakan sumber daya yang dibutuhkan untuk transaksi mereka[Gar23].

Proposal PRAW berpotensi gagal untuk mencegah spam karena proposal ini cukup bergantung pada pengembang aplikasi: 1) mampu membedakan spam dari "perilaku normal" dan 2) secara sukarela memilih untuk mengenakan biaya lebih untuk eksternalitas negatif yang menjadi tanggung jawab mereka sebagian, padahal hal itu mungkin bukan merupakan kepentingan terbaik mereka, dan mereka bisa memilih untuk tidak melakukannya.

Sebaliknya, meskipun anggota komunitas riset Solana tidak dapat disangkal terpecah dalam hal pengenalan biaya dasar EMA, secara umum terdapat kesepakatan untuk menambahkan beberapa komponen biaya dasar yang disesuaikan dengan CU. Hal ini dapat mendorong estimasi CU yang akurat dan penggunaan CU yang efisien oleh pengembang.

Pikiran Perpisahan

Tujuan teknik dan kinerja Solana yang unik membutuhkan pertimbangan TFM yang unik. Hanya dengan memindahkan pasar biaya Ethereum yang sudah ada ke Solana, tentu saja, bukanlah solusi di sini, tetapi ada pelajaran berharga yang dapat dipetik darinya. Hal ini sangat relevan untuk mekanisme keduanya:

1. Dalam protokol - TFM yang ditegakkan berdasarkan konsensus (misalnya, EIP-1559 dan SIMD-0110)
2. Di luar protokol - PBS melalui MEV-Boost, peningkatan penjadwalan Solana, dan lelang Jito

Untuk Solana dan Ethereum, mekanisme dalam protokol dan di luar protokol tampaknya akan hidup berdampingan dan berkembang bersama di masa depan. Keseimbangan di antara keduanya adalah salah satu pertanyaan mendasar dalam merancang sistem ini. Perdebatan seputar SIMD-0110 sering kali berpusat pada dua pandangan yang berlawanan:

1. Peningkatan penjadwal dan jaringan untuk mengurangi jitter akan cukup mengatasi masalah yang dijelaskan di sini, sehingga perubahan besar pada TFM dalam protokol tidak diperlukan.
2. Meskipun penjadwal di luar protokol dan peningkatan jaringan diperlukan, pada dasarnya hal itu tidak cukup. Diperlukan tekanan balik ekonomi dalam protokol.

Penetapan harga sumber daya multidimensi dalam beberapa bentuk jelas sangat berharga dalam kedua kasus tersebut. Ethereum mulai mengejar TFM seperti itu di tingkat sumber daya dasar, dengan EIP-4844 yang memisahkan data gumpalan dari pasar eksekusi. Sebaliknya, Solana mendorong penetapan harga sumber daya multidimensi di tingkat akun individu untuk memelopori "pasar biaya lokal".

Penelitian TFM di sini sangat mutakhir, dan para peneliti terus menemukan cara-cara baru dan inovatif untuk meningkatkan cara kerja biaya di Solana dan rantai lainnya. Kami optimis bahwa semua proposal yang dibahas di sini akan terus membuat Solana menjadi lebih efisien, terukur, ramah pengguna, dan berkelanjutan secara ekonomi.

Seiring dengan semakin dekatnya Eclipse dengan peluncuran mainnet kami, kami juga bersemangat untuk berbagi lebih banyak tentang bagaimana kami akan menerapkan pekerjaan yang sudah ada ini pada TFM kami sendiri, yang tentunya akan terus berkembang di tahun-tahun mendatang. Kami bermaksud untuk bereksperimen dan mendorong mekanisme di bidang ini. Manfaat penting dari paradigma modular adalah memungkinkan penyerbukan silang yang lebih mudah dari penelitian dan rekayasa dari ekosistem yang berbeda. Tingkat eksperimen ini sekarang akan terus meningkat, menguntungkan semua orang yang membangun di sini untuk jangka panjang.

Penafian: Penafian

1. Artikel ini dicetak ulang dari[Eclipse], Meneruskan Judul Asli 'Solana & Mekanisme Biaya Transaksi Ethereum: Proposal untuk Meningkatkan TFM Solana', Semua hak cipta adalah milik penulis asli[Eclipse]. Jika ada keberatan dengan pencetakan ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata merupakan pandangan dan pendapat penulis dan bukan merupakan saran investasi.
3. Penerjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel terjemahan dilarang.