Biaya Solana, Bagian 1

Pemula1/10/2024, 4:21:28 PM
Artikel ini mengeksplorasi mekanisme biaya Solana saat ini, memformalkan ruang desain untuk mekanisme biaya, dan menganalisis beberapa usulan perubahan pada mekanisme biaya Solana.

Pengantar

Mekanisme biaya adalah fitur penting dari blockchain. Pengelola jaringan seperti validator memiliki sumber daya yang terbatas, jadi penting untuk mengenakan biaya untuk sumber daya yang langka dengan cara yang mencerminkan biaya pada jaringan. Biaya juga menciptakan insentif bagi peserta jaringan, seperti pengguna, pengembang aplikasi, dan validator.

Dalam seri ini, kita akan mengeksplorasi mekanisme biaya Solana saat ini, memformalkan ruang desain untuk mekanisme biaya, dan menganalisis beberapa usulan perubahan pada mekanisme biaya Solana.

Karya ini adalah yang pertama dalam seri ini. Di sini kami menjelaskan cara kerja biaya Solana saat ini, dengan fokus pada biaya berbasis transaksi.

Definisi

Ini adalah definisi khusus Solana yang diperlukan untuk memahami mekanisme biaya.

Tanda tangan: setidaknya satu, dan biasanya tepat satu disertakan per transaksi.

Lamport: unit atom terkecil SOL. 1 SOL sama dengan satu miliar (10^9) laport.

Unit komputasi (CU): unit komputasi, per instruksi Solana-BPF, yang dimaksudkan untuk memperkirakan biaya pelaksanaan instruksi. Mirip dengan unit gas di Ethereum.

CU yang digunakan: jumlah unit komputasi yang digunakan untuk menjalankan transaksi. Hanya diketahui setelah eksekusi.

CU diminta: ditentukan oleh transaksi; jika transaksi melebihi anggaran komputasi ini selama eksekusi, eksekusi akan terhenti dan transaksi gagal. Maksimum CU yang diminta (dan digunakan) per transaksi adalah 1.400.000 CU.

Akun: satu bagian negara di blockchain Solana.

Penjadwal: mekanisme pembuatan blok berkelanjutan, disertakan secara default di klien Solana yang dibuat oleh Solana Labs.

Biaya Solana

Biaya transaksi

Saat ini, transaksi Solana mencakup dua biaya: biaya dasar dan biaya prioritas.

Biaya dasar ditetapkan per tanda tangan sebesar 5000 laport (0,000005 SOL, $0,0003 pada $60/SOL) per tanda tangan; sebagian besar transaksi Solana memiliki satu tanda tangan.

Biaya prioritas opsional ditentukan dalam transaksi, dan dinyatakan dalam microlamports per CU yang diminta. Perhatikan bahwa ini bukan per CU yang digunakan, karena CU yang digunakan tidak diketahui sampai suatu transaksi dieksekusi. Transaksi dengan biaya prioritas lebih tinggi tidak diprioritaskan secara deterministik oleh penjadwal. Mekanisme spesifiknya dijelaskan dalam Siklus Hidup Transaksi Solana.

Biaya didebit dari pembayar biaya pada awal pelaksanaan transaksi. Jika pembayar tidak dapat membayar biaya yang diperlukan, eksekusi dilewati, transaksi dianggap tidak sah, dan tidak disertakan.

Baik untuk biaya dasar maupun biaya prioritas, 50% disimpan oleh pemimpin sebagai insentif untuk memasukkan transaksi dalam blok, dan 50% dibakar.

Dalam contoh transaksi ini, transaksi meminta 600.000 unit komputasi, dan menetapkan biaya prioritas sebesar 2500 mikrolamport per CU yang diminta. Karena transaksi memiliki satu tanda tangan, maka total biaya transaksi adalah 5000 laports + 600,000 CU yang diminta * 2500 microlamports / CU yang diminta = 6500 laports, atau 0,0000065 SOL.

Biaya Negara

Solana juga mengenakan biaya untuk membuat negara bagian baru yang disebut pembebasan sewa (istilah lama). Pembebasan biaya sewa saat ini adalah 6,96 SOL statis per MB. Ketika akun baru dibuat, biaya dibebankan ke akun tersebut; ketika akun dihapus, biaya pembebasan sewa dapat dikumpulkan kembali.

Komentar

Insentif untuk Efisiensi

Karena biaya dasar tidak sensitif terhadap CU yang digunakan atau CU yang diminta, tidak ada insentif pada biaya dasar untuk mengoptimalkan penggunaan komputasi, atau meminta CU mendekati jumlah yang sebenarnya digunakan. Dalam praktiknya, banyak transaksi di Solana meminta CU yang jauh lebih banyak daripada yang digunakan. Hal ini menciptakan inefisiensi dalam penjadwal.

Dalam contoh transaksi di atas, transaksi meminta 600.000 CU tetapi menggunakan kurang dari 250.000.

Meskipun biaya prioritas mencakup insentif untuk mengurangi CU yang diminta dan oleh karena itu CU digunakan, insentif ini sering kali lemah dan hanya berlaku pada saat kemacetan. Salah satu modifikasi sederhana adalah dengan memperluas biaya dasar sehingga juga memerlukan biaya per CU yang diminta. Hal ini akan memberikan insentif kepada pengembang dan pengirim transaksi untuk mengurangi penggunaan komputasi mereka, dan hanya meminta sumber daya yang diperlukan.

Kompatibilitas Insentif

Suatu mekanisme dikatakan kompatibel dengan insentif jika semua peserta dalam mekanisme mencapai hasil terbaik mereka dengan bertindak sesuai dengan preferensi mereka yang sebenarnya. Dalam konteks mekanisme biaya, hal ini berarti validator memaksimalkan biaya dengan menjalankan algoritme pembuatan blok default, dan pengirim transaksi memaksimalkan kesejahteraan dengan mengirimkan transaksi dengan biaya prioritas sesuai dengan kesediaan mereka untuk membayar.

Mekanisme biaya Solana tidak sesuai dengan insentif untuk validator dan pengirim transaksi saat ini. Seperti dijelaskan di atas, 50% dari biaya transaksi disimpan oleh pemimpin dan 50% dibakar. Karena tidak semua biaya masuk ke pimpinan, hal ini menciptakan insentif bagi pengirim transaksi untuk berkolusi dengan pimpinan: alih-alih menentukan biaya prioritas untuk mendapatkan penyertaan prioritas, pengirim malah dapat membuat kesepakatan sampingan dengan pimpinan untuk membayar biaya prioritas di luar jaringan, menghilangkan pembakaran sambil tetap menerima prioritas.

Validator yang menjalankan mekanisme seperti itu secara teori menerima lebih banyak biaya dan dengan demikian dapat menawarkan imbalan yang lebih tinggi kepada pemangku kepentingan yang didelegasikan, sehingga menciptakan kekuatan terpusat.

Selain integrasi vertikal langsung, cara utama kita melihat kesepakatan sampingan ini di pasar saat ini adalah melalui lelang Jito. Validator yang menjalankan Jito-Solana (modifikasi pada klien Solana Labs) mematahkan mekanisme pembuatan blok berkelanjutan, menjalankan lelang ruang blok di paruh pertama slot mereka.

Kami belum melihat transaksi sampingan lainnya di pasar saat ini. Hal ini dikarenakan:

  • Klien validator dan penjadwalnya sulit untuk dimodifikasi, sehingga biaya pembuatan pengaturan seperti itu memerlukan biaya tetap yang tinggi. Perangkat lunak di luar protokol seperti Jito-Solana dan pengaturan pembangunan blok yang didelegasikan seperti PBS di Ethereum mengamortisasi biaya tetap di semua validator yang berpartisipasi.
  • Sebagian besar pendapatan validator berasal dari imbalan inflasi, bukan biaya transaksi, sehingga manfaatnya relatif rendah.

Pasar Biaya Lokal

Tidak seperti kebanyakan blockchain lainnya, Solana mengharuskan pengirim transaksi untuk menentukan negara bagian mana yang diperlukan untuk mengeksekusi transaksi. Hal ini membuka eksekusi transaksi paralel dan pasar biaya yang terlokalisasi, di mana setiap negara bagian mempunyai biaya yang berbeda berdasarkan seberapa kontroversial suatu negara bagian. Hotspot negara bagian yang terlokalisasi tidak perlu meningkatkan perselisihan atau biaya di seluruh blockchain.

Salah satu kesalahpahaman umum tentang Solana adalah bahwa Solana menampilkan pasar biaya lokal saat ini. Meskipun transaksi yang membayar biaya prioritas lebih tinggi kemungkinan besar akan dimasukkan lebih tinggi ke dalam blok, dan negara bagian yang diperebutkan kemungkinan memerlukan prioritas lebih tinggi, perilaku ini bersifat non-deterministik dan merupakan akibat dari penerapan default Solana. algoritma penjadwalan. Kami mengeksplorasi hal ini lebih lanjut di Siklus Hidup Transaksi Solana.

Secara khusus, perilaku ini tidak ditegakkan berdasarkan konsensus, dan pemesanan deterministik berdasarkan biaya prioritas tidak dijamin, baik melalui konsensus maupun implementasi penjadwal. Pembuatan blok dan propagasi blok Solana yang berkelanjutan mencegah pengurutan deterministik, kecuali jika ada perubahan besar (mis pemesanan deterministik dan eksekusi asinkron) diimplementasikan.

Biaya dasar yang dapat diprediksi dan ditegakkan secara konsensus untuk akses negara, berdasarkan pendapat historis, dapat meningkatkan efisiensi dan UX untuk mengakses negara bagian yang sangat diperebutkan. Hal ini akan meningkatkan biaya spam, sekaligus memberikan insentif kepada pengirim transaksi untuk mengunci jumlah minimum status yang sebenarnya mereka perlukan. Ini tidak akan mengatasi akar penyebab spam, yang berasal dari pembangunan blok terus menerus (jadi latensi penting) dan jitter. Kita akan mengeksplorasi desain ini nanti di seri ini.

Eksternalitas

Karena transaksi terutama diurutkan berdasarkan kapan transaksi tersebut mencapai pemimpin (penjadwal), dan urutan ini tunduk pada jitter dan jitter jaringan karena penerapan penjadwal yang diparalelkan, terdapat insentif untuk melakukan transaksi spam ketika pengirim menginginkan transaksi dimasukkan secepat mungkin. mungkin. Transaksi semacam itu membawa eksternalitas negatif pada jaringan dalam bentuk spam yang mendarat secara on-chain (per Januari 2023, 58% komputasi on-chain Solana digunakan untuk mengembalikan transaksi) dan spam mencapai pemimpinnya.

Dari Jito Labs

Kesimpulan

Pada bagian ini, kami menjelaskan cara kerja mekanisme biaya Solana saat ini, dan implikasinya terhadap jaringan. Kami telah mengisyaratkan beberapa properti yang dapat dipenuhi oleh mekanisme biaya yang ideal, seperti petunjuk akurat untuk penjadwal (diminta CU), kompatibilitas insentif, dan pasar biaya lokal yang sebenarnya. Pada bagian selanjutnya, kami akan mendefinisikan formalisme untuk tujuan yang harus dioptimalkan oleh mekanisme biaya. Hal ini akan digunakan untuk menganalisis mekanisme biaya yang ada saat ini, serta usulan modifikasi terhadap mekanisme tersebut, dengan lebih teliti daripada yang diungkapkan di sini.

Penafian:

  1. Artikel ini dicetak ulang dari [Umbra Research]. Semua hak cipta milik penulis asli [@0xShitTrader]. Jika ada keberatan terhadap cetak ulang ini, silakan menghubungi tim Gate Learn , dan mereka akan segera menanganinya.
  2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini adalah sepenuhnya milik penulis dan bukan merupakan nasihat investasi apa pun.
  3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.

Biaya Solana, Bagian 1

Pemula1/10/2024, 4:21:28 PM
Artikel ini mengeksplorasi mekanisme biaya Solana saat ini, memformalkan ruang desain untuk mekanisme biaya, dan menganalisis beberapa usulan perubahan pada mekanisme biaya Solana.

Pengantar

Mekanisme biaya adalah fitur penting dari blockchain. Pengelola jaringan seperti validator memiliki sumber daya yang terbatas, jadi penting untuk mengenakan biaya untuk sumber daya yang langka dengan cara yang mencerminkan biaya pada jaringan. Biaya juga menciptakan insentif bagi peserta jaringan, seperti pengguna, pengembang aplikasi, dan validator.

Dalam seri ini, kita akan mengeksplorasi mekanisme biaya Solana saat ini, memformalkan ruang desain untuk mekanisme biaya, dan menganalisis beberapa usulan perubahan pada mekanisme biaya Solana.

Karya ini adalah yang pertama dalam seri ini. Di sini kami menjelaskan cara kerja biaya Solana saat ini, dengan fokus pada biaya berbasis transaksi.

Definisi

Ini adalah definisi khusus Solana yang diperlukan untuk memahami mekanisme biaya.

Tanda tangan: setidaknya satu, dan biasanya tepat satu disertakan per transaksi.

Lamport: unit atom terkecil SOL. 1 SOL sama dengan satu miliar (10^9) laport.

Unit komputasi (CU): unit komputasi, per instruksi Solana-BPF, yang dimaksudkan untuk memperkirakan biaya pelaksanaan instruksi. Mirip dengan unit gas di Ethereum.

CU yang digunakan: jumlah unit komputasi yang digunakan untuk menjalankan transaksi. Hanya diketahui setelah eksekusi.

CU diminta: ditentukan oleh transaksi; jika transaksi melebihi anggaran komputasi ini selama eksekusi, eksekusi akan terhenti dan transaksi gagal. Maksimum CU yang diminta (dan digunakan) per transaksi adalah 1.400.000 CU.

Akun: satu bagian negara di blockchain Solana.

Penjadwal: mekanisme pembuatan blok berkelanjutan, disertakan secara default di klien Solana yang dibuat oleh Solana Labs.

Biaya Solana

Biaya transaksi

Saat ini, transaksi Solana mencakup dua biaya: biaya dasar dan biaya prioritas.

Biaya dasar ditetapkan per tanda tangan sebesar 5000 laport (0,000005 SOL, $0,0003 pada $60/SOL) per tanda tangan; sebagian besar transaksi Solana memiliki satu tanda tangan.

Biaya prioritas opsional ditentukan dalam transaksi, dan dinyatakan dalam microlamports per CU yang diminta. Perhatikan bahwa ini bukan per CU yang digunakan, karena CU yang digunakan tidak diketahui sampai suatu transaksi dieksekusi. Transaksi dengan biaya prioritas lebih tinggi tidak diprioritaskan secara deterministik oleh penjadwal. Mekanisme spesifiknya dijelaskan dalam Siklus Hidup Transaksi Solana.

Biaya didebit dari pembayar biaya pada awal pelaksanaan transaksi. Jika pembayar tidak dapat membayar biaya yang diperlukan, eksekusi dilewati, transaksi dianggap tidak sah, dan tidak disertakan.

Baik untuk biaya dasar maupun biaya prioritas, 50% disimpan oleh pemimpin sebagai insentif untuk memasukkan transaksi dalam blok, dan 50% dibakar.

Dalam contoh transaksi ini, transaksi meminta 600.000 unit komputasi, dan menetapkan biaya prioritas sebesar 2500 mikrolamport per CU yang diminta. Karena transaksi memiliki satu tanda tangan, maka total biaya transaksi adalah 5000 laports + 600,000 CU yang diminta * 2500 microlamports / CU yang diminta = 6500 laports, atau 0,0000065 SOL.

Biaya Negara

Solana juga mengenakan biaya untuk membuat negara bagian baru yang disebut pembebasan sewa (istilah lama). Pembebasan biaya sewa saat ini adalah 6,96 SOL statis per MB. Ketika akun baru dibuat, biaya dibebankan ke akun tersebut; ketika akun dihapus, biaya pembebasan sewa dapat dikumpulkan kembali.

Komentar

Insentif untuk Efisiensi

Karena biaya dasar tidak sensitif terhadap CU yang digunakan atau CU yang diminta, tidak ada insentif pada biaya dasar untuk mengoptimalkan penggunaan komputasi, atau meminta CU mendekati jumlah yang sebenarnya digunakan. Dalam praktiknya, banyak transaksi di Solana meminta CU yang jauh lebih banyak daripada yang digunakan. Hal ini menciptakan inefisiensi dalam penjadwal.

Dalam contoh transaksi di atas, transaksi meminta 600.000 CU tetapi menggunakan kurang dari 250.000.

Meskipun biaya prioritas mencakup insentif untuk mengurangi CU yang diminta dan oleh karena itu CU digunakan, insentif ini sering kali lemah dan hanya berlaku pada saat kemacetan. Salah satu modifikasi sederhana adalah dengan memperluas biaya dasar sehingga juga memerlukan biaya per CU yang diminta. Hal ini akan memberikan insentif kepada pengembang dan pengirim transaksi untuk mengurangi penggunaan komputasi mereka, dan hanya meminta sumber daya yang diperlukan.

Kompatibilitas Insentif

Suatu mekanisme dikatakan kompatibel dengan insentif jika semua peserta dalam mekanisme mencapai hasil terbaik mereka dengan bertindak sesuai dengan preferensi mereka yang sebenarnya. Dalam konteks mekanisme biaya, hal ini berarti validator memaksimalkan biaya dengan menjalankan algoritme pembuatan blok default, dan pengirim transaksi memaksimalkan kesejahteraan dengan mengirimkan transaksi dengan biaya prioritas sesuai dengan kesediaan mereka untuk membayar.

Mekanisme biaya Solana tidak sesuai dengan insentif untuk validator dan pengirim transaksi saat ini. Seperti dijelaskan di atas, 50% dari biaya transaksi disimpan oleh pemimpin dan 50% dibakar. Karena tidak semua biaya masuk ke pimpinan, hal ini menciptakan insentif bagi pengirim transaksi untuk berkolusi dengan pimpinan: alih-alih menentukan biaya prioritas untuk mendapatkan penyertaan prioritas, pengirim malah dapat membuat kesepakatan sampingan dengan pimpinan untuk membayar biaya prioritas di luar jaringan, menghilangkan pembakaran sambil tetap menerima prioritas.

Validator yang menjalankan mekanisme seperti itu secara teori menerima lebih banyak biaya dan dengan demikian dapat menawarkan imbalan yang lebih tinggi kepada pemangku kepentingan yang didelegasikan, sehingga menciptakan kekuatan terpusat.

Selain integrasi vertikal langsung, cara utama kita melihat kesepakatan sampingan ini di pasar saat ini adalah melalui lelang Jito. Validator yang menjalankan Jito-Solana (modifikasi pada klien Solana Labs) mematahkan mekanisme pembuatan blok berkelanjutan, menjalankan lelang ruang blok di paruh pertama slot mereka.

Kami belum melihat transaksi sampingan lainnya di pasar saat ini. Hal ini dikarenakan:

  • Klien validator dan penjadwalnya sulit untuk dimodifikasi, sehingga biaya pembuatan pengaturan seperti itu memerlukan biaya tetap yang tinggi. Perangkat lunak di luar protokol seperti Jito-Solana dan pengaturan pembangunan blok yang didelegasikan seperti PBS di Ethereum mengamortisasi biaya tetap di semua validator yang berpartisipasi.
  • Sebagian besar pendapatan validator berasal dari imbalan inflasi, bukan biaya transaksi, sehingga manfaatnya relatif rendah.

Pasar Biaya Lokal

Tidak seperti kebanyakan blockchain lainnya, Solana mengharuskan pengirim transaksi untuk menentukan negara bagian mana yang diperlukan untuk mengeksekusi transaksi. Hal ini membuka eksekusi transaksi paralel dan pasar biaya yang terlokalisasi, di mana setiap negara bagian mempunyai biaya yang berbeda berdasarkan seberapa kontroversial suatu negara bagian. Hotspot negara bagian yang terlokalisasi tidak perlu meningkatkan perselisihan atau biaya di seluruh blockchain.

Salah satu kesalahpahaman umum tentang Solana adalah bahwa Solana menampilkan pasar biaya lokal saat ini. Meskipun transaksi yang membayar biaya prioritas lebih tinggi kemungkinan besar akan dimasukkan lebih tinggi ke dalam blok, dan negara bagian yang diperebutkan kemungkinan memerlukan prioritas lebih tinggi, perilaku ini bersifat non-deterministik dan merupakan akibat dari penerapan default Solana. algoritma penjadwalan. Kami mengeksplorasi hal ini lebih lanjut di Siklus Hidup Transaksi Solana.

Secara khusus, perilaku ini tidak ditegakkan berdasarkan konsensus, dan pemesanan deterministik berdasarkan biaya prioritas tidak dijamin, baik melalui konsensus maupun implementasi penjadwal. Pembuatan blok dan propagasi blok Solana yang berkelanjutan mencegah pengurutan deterministik, kecuali jika ada perubahan besar (mis pemesanan deterministik dan eksekusi asinkron) diimplementasikan.

Biaya dasar yang dapat diprediksi dan ditegakkan secara konsensus untuk akses negara, berdasarkan pendapat historis, dapat meningkatkan efisiensi dan UX untuk mengakses negara bagian yang sangat diperebutkan. Hal ini akan meningkatkan biaya spam, sekaligus memberikan insentif kepada pengirim transaksi untuk mengunci jumlah minimum status yang sebenarnya mereka perlukan. Ini tidak akan mengatasi akar penyebab spam, yang berasal dari pembangunan blok terus menerus (jadi latensi penting) dan jitter. Kita akan mengeksplorasi desain ini nanti di seri ini.

Eksternalitas

Karena transaksi terutama diurutkan berdasarkan kapan transaksi tersebut mencapai pemimpin (penjadwal), dan urutan ini tunduk pada jitter dan jitter jaringan karena penerapan penjadwal yang diparalelkan, terdapat insentif untuk melakukan transaksi spam ketika pengirim menginginkan transaksi dimasukkan secepat mungkin. mungkin. Transaksi semacam itu membawa eksternalitas negatif pada jaringan dalam bentuk spam yang mendarat secara on-chain (per Januari 2023, 58% komputasi on-chain Solana digunakan untuk mengembalikan transaksi) dan spam mencapai pemimpinnya.

Dari Jito Labs

Kesimpulan

Pada bagian ini, kami menjelaskan cara kerja mekanisme biaya Solana saat ini, dan implikasinya terhadap jaringan. Kami telah mengisyaratkan beberapa properti yang dapat dipenuhi oleh mekanisme biaya yang ideal, seperti petunjuk akurat untuk penjadwal (diminta CU), kompatibilitas insentif, dan pasar biaya lokal yang sebenarnya. Pada bagian selanjutnya, kami akan mendefinisikan formalisme untuk tujuan yang harus dioptimalkan oleh mekanisme biaya. Hal ini akan digunakan untuk menganalisis mekanisme biaya yang ada saat ini, serta usulan modifikasi terhadap mekanisme tersebut, dengan lebih teliti daripada yang diungkapkan di sini.

Penafian:

  1. Artikel ini dicetak ulang dari [Umbra Research]. Semua hak cipta milik penulis asli [@0xShitTrader]. Jika ada keberatan terhadap cetak ulang ini, silakan menghubungi tim Gate Learn , dan mereka akan segera menanganinya.
  2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini adalah sepenuhnya milik penulis dan bukan merupakan nasihat investasi apa pun.
  3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.
Mulai Sekarang
Daftar dan dapatkan Voucher
$100
!