Pengantar: mengapa transaksi saya tidak disertakan?

Transaksi Solana perjalanandari pengajuan pengguna hingga inklusi blok dapat menjadi melelahkan. Bahkan setelah transaksi mencapai pemimpin saat ini, itu harus bersaing dengan transaksi lain untuk ruang blok terbatas. Termasuk transaksi dalam mode first-come-first-served murni mendorong spam dan dapat memblokir transaksi bernilai tinggi dari pengguna biasa. Untuk mengatasi masalah ini, kita perlu mekanisme biaya.

Biaya prioritas menyelamatkan?​

Biaya prioritas memecahkan masalah ini, bukan? Sayangnya, tidak untuk sebagian besar pengguna.

Bayangkan skenario ini. Anda ingin pergi ke bioskop 100 kursi di kota Anda tetapi teater memiliki sistem tiket yang tidak normal: mereka tidak mempublikasikan harga tiket. Sebaliknya, Anda harus memberi tahu mereka berapa banyak Anda bersedia membayar. (Katakanlah itu $ 50.) Jika permintaan tinggi dan setidaknya 100 orang lainnya mengajukan harga yang lebih tinggi, nasib buruk. Jika permintaan rendah, Anda masuk! Tangkapannya: Anda membayar $ 50 bahkan jika teater kosong. Tetapi pengalaman membeli tiket tidak berakhir di situ. Sistem ini memiliki keanehan lain: Anda harus memberi tahu teater kesediaan Anda untuk membayar sebelum meninggalkan rumah. Jelas, mendapatkan tiket teater dalam sistem ini adalah pengalaman yang berpotensi penuh bagi rata-rata individu. Individu yang kaya dan canggih, di sisi lain, dapat secara akurat memperkirakan harga tiket. Mereka dapat memasang kamera di sebelah bioskop untuk memantau lalu lintas secara real-time. Mereka dapat menggunakan lalu lintas ini dan mengumpulkan data historis untuk memperkirakan permintaan pada hari tertentu. Dan mereka bahkan dapat membeli helikopter untuk melakukan perjalanan ke teater lebih cepat setelah memberi tahu teater kesediaan mereka untuk membayar. Meskipun dimungkinkan untuk menggunakan sistem tiket ini secara efektif, pengalaman itu mengerikan bagi kebanyakan orang yang ingin pergi ke teater. Ketika teater penuh sesak, banyak dari orang-orang ini mungkin tidak repot-repot mencoba pergi sama sekali.

Demikian pula, biaya prioritas “benar” yang diperlukan untuk transaksi Solana sulit untuk diperkirakan.Ini fluktuasi banyakSelama periode kemacetan tinggi, dompet yang menggunakan rata-rata terbaru kemungkinan akan memperkirakan biaya yang diperlukan terlalu tinggi, menyebabkan pengguna membayar terlalu mahal untuk inklusi transaksi. (Dan bahkan dengan biaya prioritas tinggi, sebuah transaksi mungkin masih belum termasukkarena sifat produksi blok berkelanjutan multi-threaded.) Secara teori, biaya prioritas dapat mengalokasikan ruang blok secara optimal. Secara praktis, mereka benar-benar gagal. Untungnya, ada cara untuk memecahkan masalah ini, yang pada akhirnya menghasilkan transaksi lebih murah dengan peluang inklusi yang lebih baik untuk sebagian besar pengguna. Sebelum menyelam ke dalam solusinya, mari kita telaah beberapa properti dari sumber daya yang ingin kita alokasikan: ruang blok.

Blockspace: pasokan tetap, permintaan yang sangat fluktuatif​

Transaksi di Solana diverifikasi dan dieksekusi secara independen oleh jaringan validator terdesentralisasi. Karena validator ini memiliki sumber daya komputasi yang terbatas, Solana membatasi total sumber daya komputasi, diukur dalam unit komputasi (CUs) yang dapat digunakan per blok. Ketika permintaan ruang blok melonjak melebihi pasokan yang terbatas, sumber daya tetap ini harus dialokasikan di antara transaksi yang bersaing.

Dalam beberapa hal, pasar dapat menangani alokasi ruang blok melalui penetapan harga; transaksi dengan utilitas yang lebih tinggi bagi pengirim bersedia membayar harga yang lebih tinggi. Namun, mekanisme ini tidak berfungsi ketika pengguna tidak tahu berapa harga ruang blok! Seperti yang dibahas di atas, biaya prioritas saja menyebabkan harga transaksi sulit diestimasi bagi sebagian besar pengguna dan menawarkan jaminan inklusi transaksi yang buruk. Blockchain lain telah mengatasi masalah ini dengan menerapkan mekanisme biaya transaksi (misalnya, EIP-1559 di Ethereum, dan biaya multidimensi di AvalanchedanPenumbraMekanisme biaya ini menerapkan biaya dasar yang mudah diestimasi yang memberikan 'biaya masuk' yang dapat diprediksi untuk jaringan; biaya dasar ini mendekati harga sebenarnya untuk inklusi transaksi.

Ulasan: Biaya Solana hari ini​

Solana saat ini menerapkan dua mekanisme biaya: biaya dasar dan biaya prioritas. Kita dapat menganggap biaya dasar sebagai 'biaya masuk' untuk menggunakan jaringan dan biaya prioritas sebagai tip ekstra untuk mendorong validator untuk menyertakan satu transaksi daripada yang lain. Biaya dasar Solana adalah tetap 5000 lamports per tanda tangan (biasanya satu per transaksi). Akibatnya, pengguna yang mengirimkan transfer sederhana membayar biaya dasar yang sama dengan pengguna yang bermain game on-chain yang berat komputasi dan pencari yang mencoba mengejar peluang MEV yang rumit. Dengan demikian, biaya dasar saat ini yang dibebankan tidak secara akurat menangkap penggunaan sumber daya transaksi (dan 'eksternalitas,' dalam bahasa ekonomi), yang berpotensi.digunakan dengan buruk ruang blok.

Dalam contoh teater kita, biaya dasar yang sama akan dikenakan kepada penonton yang membeli 1 kursi dan yang membeli semua 100 kursi dengan harga yang sama.

Mengapa mekanisme biaya dasar?​

Biaya dasar seharusnya menjadi fungsi dari sumber daya yang digunakan. Konsumsi ini saat ini diukur dalam unit komputasi (CUs) tetapi juga dapat mencakup sumber daya lain seperti akses akun. Kami ingin pengguna memiliki biaya partisipasi yang lebih dapat diprediksi, diberikan oleh biaya dasar dinamis. Biaya ini sulit ditetapkan dengan benar. (Ada banyak penelitian akademis, termasuk milik kita sendiri, mencoba mengatasi ini!) Namun, siapa pun yang pernah menderita dari transaksi gagal karena kemacetan jaringan tahu bahwa biaya juga penting untuk diselesaikan dengan benar jika kita ingin jaringan tumbuh.

Pada akhirnya, banyak pengguna yang ingin mengirimkan transaksi tidak yakin harus membayar biaya prioritas berapa. Jika memperkirakan biaya ini terlalu tinggi, mereka akan membayar terlalu banyak. Jika memperkirakan terlalu rendah, transaksi tidak akan disertakan. Sebaliknya, untuk biaya dasar, pengguna membayar tepat dengan biaya yang saat ini dipublikasikan. Kami ingin biaya dasar ini secara akurat mencerminkan biaya sebenarnya untuk menyertakan transaksi. Di sini, kami mengasumsikan semua transaksi mencapai penjadwal tetapi bersaing untuk ruang blok terbatas, termasuk komputasi dan akses akun. Selama periode permintaan tinggi, tidak semua transaksi dapat disertakan. Dalam posting ini, kami menjabarkan langkah-langkah menuju mekanisme biaya dasar dinamis yang dapat membantu membersihkan jaringan dan menyediakan inklusi transaksi yang lebih dapat diprediksi.

Selain itu: Biaya prioritas dan MEV​

Biaya prioritas juga dapat dilihat sebagai pembayaran untuk peluang-peluang tertentu yang terbatas oleh sesuatu selain konsumsi sumber daya. Misalnya, jika dua pencari secara bersamaan mengirimkan transaksi untuk melikuidasi pinjaman tertentu, hanya satu dari transaksi tersebut yang dapat berhasil dieksekusi; hanya transaksi pertama dalam blok yang berhasil melikuidasi pinjaman. Oleh karena itu, biaya prioritas seringkali membayar pengurutan transaksi daripada hanya inklusi saja. Penggunaan biaya prioritas untuk menangkap peluang MEV ini agak ortogonal dengan posting ini—lihatMEV di Solanauntuk diskusi lebih lanjut. Dalam posting ini, kami fokus pada biaya dasar dan inklusi transaksi.

Blok optimal

Sebelum membahas cara menetapkan biaya dasar, kita akan mempertimbangkan mekanisme fiktif untuk inklusi blok: seorang perancang jaringan yang omniscient memilih transaksi untuk setiap blok yang memaksimalkan kesejahteraan pengguna (total utilitas atau 'kebahagiaan' dari transaksi yang disertakan), dikurangi biaya konsumsi sumber daya jaringan, dengan memperhatikan batasan transaksi (misalnya, batasan kontrak pintar, batasan komputasi, dll.). Tentu saja, kesejahteraan pengguna tidak diketahui dan tidak dapat diukur oleh perancang jaringan dalam praktiknya, dan perancang jaringan tidak membangun blok-blok tersebut. Namun, kita dapat menggunakan masalah ini sebagai patokan mental untuk blok 'optimal' yang dibangun dari transaksi yang mencapai penjadwal. Tujuan kita adalah merancang mekanisme biaya yang mendekati patokan ini.

Meskipun mekanisme pembangunan blok fiktif ini sulit dipecahkan, ternyata kita dapat menemukan mekanisme setara yang dapat diterapkan dalam praktik. Mekanisme yang setara ini berusaha untuk menemukan harga sumber daya yang meminimalkan kesenjangan antara kesejahteraan jaringan dan penggunanya. Mengatur harga sumber daya dengan benar menyelaraskan insentif sedemikian rupa sehingga biaya sumber daya ke jaringan persis seimbang dengan utilitas yang diperoleh oleh pengguna dan validator, meskipun jaringan tidak tahu apa utilitas ini dan pengguna tidak pernah secara eksplisit menentukannya. Harga-harga ini kemudian mengarah ke blok yang rata-rata "optimal". Dengan demikian, kita bisa fokus hanya pada penetapan harga tersebut. (Untuk detail teknis selengkapnya, lihat kertas ini.)

Menuju sebuah mekanisme

Bagaimana cara kita menetapkan harga untuk mendorong blok optimal, seperti yang dibahas di atas? Pendekatan pertama mungkin adalah membebankan jumlah tetap per unit komputasi yang digunakan oleh transaksi. Sayangnya, pendekatan ini tidak akan berhasil. Jika permintaan rendah, maka harga tetap per CU ini akan menyebabkan pengguna tidak mengirimkan transaksi, dan blok mungkin hampir kosong. Jika permintaan tinggi, maka harga tetap ini mungkin terlalu rendah dan, akibatnya, tidak akan melakukan apa-apa untuk mengurangi kemacetan jaringan atau mendekati biaya sebenarnya dari inklusi transaksi (tujuan asli kita!). Dengan demikian, kita perlu memiliki cara untuk meningkatkan dan mengurangi biaya dasar berdasarkan permintaan jaringan, dan juga beberapa cara untuk memperkirakan permintaan ini.

Biaya dasar dinamis​

Langkah selanjutnya adalah menambahkan pengendali yang menyesuaikan biaya per unit komputasi berdasarkan penggunaan yang telah terjadi. Sebagai contoh, jika terdapat target penggunaan per blok (yaitu, penggunaan ideal 'steady state' untuk rantai), kita dapat meningkatkan atau menurunkan biaya dasar berdasarkan pemanfaatan atau deviasi dari target ini. Banyak mekanisme, termasuk yang seperti EIP-1559, terapkan ide ini. Kita mungkin tergoda untuk secara dinamis memperbarui biaya dasar dalam satu blok menggunakan permintaan real-time, atau untuk mendorong setiap pemimpin untuk memilih aturan pembaruan biaya mereka sendiri. Namun, perubahan ini akan mengurangi prediktabilitas biaya dasar, mengalahkan tujuan asli dari mekanisme biaya ini. Pilihan mekanisme pada akhirnya menentukan pengalaman pengguna.

Untungnya, waktu blok cepat Solana memungkinkan algoritma agresif untuk menetapkan biaya dasar. Sebagai contoh, kita dapat dengan cepat meningkatkan harga selama periode permintaan tinggi (misalnya, menggandakan harga untuk setiap blok penuh), dan kemudian secara lebih lambat menurunkan harga saat permintaan menurun. Harga tetap akan turun cukup cepat karena waktu blok Solana yang singkat. Secara intuitif, ketika sumber daya tertentu mencapai batas maksimum, jaringan secara signifikan menetapkan harga terlalu rendah dan mendapatkan informasi yang lebih sedikit tentang apa seharusnya harga optimalnya. Jenis algoritma serupa digunakan dalam praktek di Kontrol kemacetan TCP, lapisan data-link komunikasi nirkabeldanoptimasi pasar.

Biaya multidimensional: pasar biaya lokal​

Diskusi sebelumnya mempertimbangkan satu sumber daya bersama yang dibagikan oleh semua transaksi: unit komputasi (global). Namun, akses keadaan di Solana juga secara signifikan memengaruhi penggunaan sumber daya transaksi. Jika banyak transaksi mengakses bagian keadaan yang sama, mereka tidak dapat dieksekusi secara paralel dan, oleh karena itu, mengurangi throughput jaringan. Secara alami, kita ingin transaksi ini membayar biaya dasar yang lebih tinggi, memotivasi pasar biaya per-akun (lokal). (Pertanyaan tentang siapa yang mendapatkan biaya ini berada di luar lingkup pos ini; lebih banyak tentang itu di masa depan.)

Sebagai contoh konkret, mari kita pertimbangkan peluncuran NFT yang populer. Tanpa pasar biaya per-akun, peluncuran ini akan meningkatkan biaya dasar secara signifikan untuk semua transaksi lainnya. Dengan biaya per-akun, biaya mengirimkan transaksi untuk mengklaim sebuah NFT (dan mengakses bagian dari status tersebut) bisa meningkat sementara biaya untuk transaksi lainnya (seperti menambahkan jaminan pada pinjaman) tetap relatif tidak berubah. Jenis desain pasar biaya lokal per-akun ini sedang dipertimbangkan dalam Dokumen Peningkatan Solana IMprovement.

Biaya multidimensional ini juga dapat memperhitungkan korelasi antara kontrak. Misalnya, jika dua pertukaran cNFT melakukan banyak perdagangan koleksi yang sama, kontrak mereka memerlukan akses ke banyak akun yang sama. Jika volume perdagangan meningkat secara dramatis untuk koleksi tertentu di salah satu pertukaran ini, maka biaya dasar akan meningkat untuk koleksi tersebut di pertukaran lainnya, karena biaya untuk akun yang mendasarinya telah meningkat untuk keduanya. Dengan cara ini, biaya per-akun 'lokal' secara tepat berkorelasi secara 'global,' dan biaya multidimensional mencegah permainan sistem dengan melepaskan beberapa kontrak untuk aplikasi yang sama.

Di sisi lain, jika keadaan aplikasi itu sendiri diparalelkan, biaya akan lebih rendah. Properti ini diinginkan; paralelisasi meningkatkan throughput karena memungkinkan transaksi yang berbeda mengakses aplikasi yang sama ditempatkan pada thread yang berbeda ketika akun yang mendasarinya tidak tumpang tindih (lihatSiklus Transaksi Solana).

Kontroler harga untuk pasar biaya lokal per akun ini mungkin berbeda dengan yang digunakan untuk unit komputasi. Barangkali untuk akun-akun tersebut kami tidak mengenakan biaya sama sekali sampai statusnya secara signifikan dipertentangkan, pada saat itu biaya akan naik dengan cepat. Analisis periode kemacetan sebelumnya dapat membantu membentuk keputusan desain tersebut.

Mekanisme alternatif​

Opsi yang dibahas di atas bukan satu-satunya cara untuk menetapkan biaya. Sebagian besar mekanisme biaya dasar mengikuti prosedur iteratif yang sama: di setiap blok...

1. lihatlah konsumsi sumber daya dari blok-blok terbaru (sebuah hasil dari transaksi yang disertakan);
2. menghitung fungsi dari konsumsi ini (misalnya, deviasi dari target);
3. dan kemudian memperbarui harga sumber daya menggunakan output langkah 2 dan aturan sederhana.

Dalam contoh-contoh yang dibahas di atas, kami menggunakan pilihan yang berbeda untuk sumber daya dalam langkah 1 dan mekanisme pembaruan dalam langkah 2 dan 3. Metode untuk mengubah preferensi pemanfaatan sumber daya menjadi aturan pembaruan biaya konkret dibahas dalamkertas ini.

Apakah hal multidimensional ini berfungsi?

Meskipun pekerjaan akademis kami sebagian besar bersifat teoritis, contoh mainan sederhana menunjukkan bahwa membandingkan sumber daya, seperti akun, secara terpisah dapat meningkatkan efisiensi jaringan dan membuat jaringan lebih tangguh terhadap serangan DoS atau perubahan dalam jenis transaksi yang diajukan. Dalam bagian ini, kami menyoroti perbedaan antara mekanisme biaya satu dimensi dan multi-dimensi yang sederhana (lihat bagian 4 darikertas kamiuntuk detail).

Perilaku keadaan tetap​

Kami pertama kali mensimulasikan perilaku keadaan tetap dari mekanisme biaya multidimensi dengan transaksi yang memerlukan jumlah sumber daya yang kurang lebih sama dari sumber daya 1 dan sumber daya 2. Di bawah perilaku keadaan tetap, penetapan harga seragam menyebabkan deviasi yang lebih tinggi dari target penggunaan sumber daya (kiri). Penggunaan yang kurang efisien juga menyebabkan throughput yang lebih rendah (kanan).

Pergeseran distribusi​

Kami juga menguji perilaku mekanisme di bawah pergeseran distribusi: kami menambahkan 150 transaksi di blok 10 yang memerlukan jumlah sumber daya yang signifikan 2. Skenario ini mungkin muncul dalam pencetakan NFT, misalnya. Penetapan harga multidimensional menyebabkan throughput yang jauh lebih tinggi ketika distribusi bergeser (kiri) dengan menyesuaikan harga sumber daya disesuaikan secara tepat (kanan).

Melihat penggunaan sumber daya individu, kami melihat bahwa penetapan harga multidimensional (kiri) memfasilitasi kapasitas lonjakan singkat, sedangkan penetapan harga seragam (kanan) tidak.

Kesimpulan

Blockchain memiliki sumber daya komputasi yang terbatas. Ketika permintaan pengguna tinggi, ini memerlukan alokasi sumber daya terbatas ini di antara transaksi pengguna yang bersaing dengan cara yang dapat diprediksi. Alokasi ini harus dilakukan secara implisit melalui biaya dasar transaksi dinamis.

Kami mengusulkan mekanisme yang didasarkan pada teori untuk menetapkan biaya ini, yang tidak hanya dapat meningkatkan throughput jaringan selama periode permintaan tinggi tetapi juga meningkatkan pengalaman pengguna dengan memisahkan transaksi yang tidak terkait dan menyediakan biaya inklusi transaksi yang dapat diprediksi. Untuk lebih detail tentang mekanisme ini, lihat Pembicaraan Tarun di Breakpointdankertas kami!

Penafian:

1. Artikel ini dicetak ulang dari [ umbraresearchMeneruskan Judul Asli 'Menuju Biaya Solana Multidimensi', Semua hak cipta milik penulis asli@theo_diamandis、@tarunchitra、@0xShitTrader]. Jika ada keberatan terhadap pencetakan ulang ini, silakan hubungi Belajar Gatetim, dan mereka akan menanganinya dengan cepat.

2. Penolakan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata merupakan milik penulis dan tidak merupakan nasihat investasi apa pun.

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