Analisis Desain dan Arsitektur Solana Kedalaman

Penulis: Pavel Paramonov Sumber: X, @paramonoww Terjemahan: Golden Finance

Selama enam bulan terakhir, saya telah membaca banyak artikel dan dokumen tentang desain mekanisme dan arsitektur Solana. Saya merangkum informasi paling penting dalam satu artikel panjang yang mencakup topik desain mekanisme, pasar biaya, MEV, dan sebagainya.

Berikut adalah jawaban untuk semua pertanyaan:

Model Konsensus Solana:

Model Konsensus Proof of History (Proof of History, PoH) dari Solana pada dasarnya adalah kombinasi antara "Proof of Stake (Proof of Stake) + variabel waktu".

‣ PoH pada dasarnya adalah jam tangan jaringan yang digunakan untuk melacak acara dan urutannya (tidak perlu validator untuk mencapai Konsensus waktu).

‣ Solana tidak memiliki memory pool（mempool）。

‣ Saat ini, sebagian besar validator menggunakan scheduler dalam klien Solana yang disediakan oleh @solanalabs. Namun, validator juga dapat memilih untuk menjalankan Algoritme Blok yang berbeda.

‣ Variabel waktu memungkinkan penugasan pemimpin untuk setiap putaran, pemimpin ini akan bertanggung jawab untuk memproduksi Blok.

Mekanisme Detail:

• Ketika seorang validator dipilih sebagai pemimpin, ia bertanggung jawab untuk menghasilkan blok baru dan mengusulkannya ke jaringan.
• Kepemimpinan bergantian dengan interval tetap (disebut sebagai slot) di antara validator.
• Setiap slot berlangsung selama 400 milidetik, di mana validator dapat menghasilkan sebuah Blok. Slot berjalan secara berurutan satu demi satu.
• Setiap slot akan diberikan validator pemimpin untuk mengusulkan Blok baru, validator lain akan memberikan suara untuk validitas Blok, dan akhirnya Blok dikonfirmasi.
• Jika validator melewatkan slot yang ditugaskan, jaringan akan terus memproses slot berikutnya.

Fitur dan Proses:

• Solana menggunakan mekanisme pemungutan suara berbasis garpu alih-alih memilih blok individu. Validator menghasilkan blok secara terus menerus dan menambahkan suara yang valid secara real-time.
• validator dan delegator dapat melakukan staking atau menarik staking SOL Token dalam satu periode (epoch).
• Berdasarkan jumlah SOL yang dipertaruhkan, tingkat partisipasi validator dalam proses Konsensus akan ditentukan pada awal periode.

Model staking Solana:

‣ Solana mengurus pembaruan stake pada akhir setiap epoch, dengan setiap epoch berlangsung sekitar 2-3 hari dan terdiri dari 432,000 Blok (slot).

‣ Jadwal validator untuk periode berikutnya ditentukan berdasarkan informasi stake yang diperbarui.

Tiga sumber pendapatan utama validator:

• Biaya Transaksi
• protokol reward (inflasi)
• maximal extractable value（MEV）

Pemimpin menerima Hadiah Blok yang mencakup 50% biaya dasar dan biaya prioritas (50% sisanya dihancurkan).

‣ Waktu blok yang lebih lama mungkin akan mengurangi hadiah tahunan karena jumlah siklus berkurang, yang akan memengaruhi alokasi total $SOL.

‣ Solana menghitung pool hadiah SOL yang dihasilkan oleh inflasi untuk setiap periode, dan mendistribusikan hadiah kepada validator dan stakeholder berdasarkan pemungutan suara dan status staking periode sebelumnya.

Model staking Solana:

‣ Solana mengurus pembaruan stake pada akhir setiap epoch, dengan setiap epoch berlangsung sekitar 2-3 hari dan terdiri dari 432,000 Blok (slot).

‣ Jadwal validator untuk periode berikutnya ditentukan berdasarkan informasi stake yang diperbarui.

Tiga sumber pendapatan utama validator:

• Biaya Transaksi
• protokol reward (inflasi)
• maximal extractable value（MEV）

Pemimpin menerima Hadiah Blok yang mencakup 50% biaya dasar dan biaya prioritas (50% sisanya dihancurkan).

‣ Waktu blok yang lebih lama mungkin akan mengurangi hadiah tahunan karena jumlah siklus berkurang, yang akan memengaruhi alokasi total $SOL.

‣ Solana menghitung pool hadiah SOL yang dihasilkan oleh inflasi untuk setiap periode, dan mendistribusikan hadiah kepada validator dan stakeholder berdasarkan pemungutan suara dan status staking periode sebelumnya.

Model Voting Solana:

‣ Solana tidak memiliki persyaratan SOL minimum yang ketat untuk validator, tetapi partisipasi dalam Konsensus memerlukan akun voting.

‣ validator memilih proposal dari pemimpin slot, ini memerlukan akun voting dan membayar Pencucian Uang setiap kali memilih.

Mekanisme pemungutan suara on-chain Solana membebankan biaya Pencucian Uang setiap kali pemungutan suara dilakukan. Harga $SOL yang tinggi akan meningkatkan biaya operasional pemilih verifikator karena biaya transaksi meningkat.

Rincian Biaya:

• Biaya setiap voting adalah 0.000005 SOL, validator menghabiskan sekitar 2-3 SOL untuk voting setiap periode.
• Satu siklus berlangsung selama 2-3 hari, dengan biaya sekitar 300-350 SOL per tahun, setara dengan sekitar 1 SOL per hari.

Pasar Biaya Solana:

Mekanisme biaya Solana terdiri dari dua bagian: biaya dasar dan biaya prioritas.

‣ Biaya dibagi menjadi bagian yang dialokasikan ke validator dan bagian yang dihancurkan, tetapi mekanisme yang ada memiliki beberapa keterbatasan:

• It has failed to incentivize efficient resource utilization or align incentives for all parties.

‣ Membuat akun baru memerlukan pembayaran biaya (pembebasan sewa).

• Biaya dihitung dengan tarif tetap, setiap MB penyimpanan memerlukan pembayaran sebesar 6.96 SOL.
• Biaya ini akan dialokasikan ke akun yang baru dibuat, jika akun tersebut dihapus maka dapat diambil kembali.

Keterbatasan:

Mengakibatkan pemborosan sumber daya hanya efektif saat lalu lintas padat insentif kurang (tergantung subsidi inflasi)

Kualitas Layanan Berbasis Bobot Penyetoran (SWQoS):

‣ Dalam keadaan lalu lintas jaringan yang padat, mekanisme SWQoS dapat digunakan untuk memprioritaskan pemrosesan jenis transaksi tertentu.

‣ SWQoS memprioritaskan lalu lintas jaringan berdasarkan jumlah staking validator untuk mencegah jaringan dibanjiri oleh transaksi sampah dengan stake yang rendah.

Jenis Koneksi:

• Koneksi Terbuka: Penggunaan Publik
• Koneksi berbasis bobot staking: Tetap disediakan untuk digunakan oleh validator, RPC Node dapat menggunakan koneksi validator melalui hubungan kepercayaan.

Keuntungan:

• Meningkatkan kinerja transaksi dengan stakevalidator
• Meningkatkan Ketahanan Jaringan
• Meningkatkan Ketahanan Serangan Sybil

Tantangan:

• risiko sentralisasi stake
• Masalah kepercayaan antara validator dan RPC Node
• Hambatan Masuk untuk Validator Kecil

‣ SWQoS memprioritaskan akses jaringan daripada urutan transaksi yang memprioritaskan biaya

Tentang Node dan validator：

‣ Semua validator adalah Node, tapi tidak semua Node adalah validator.

Jenis Node:

• Node Verifikasi: Bertanggung jawab untuk menandatangani dan memilih
• Node RPC: Menangani permintaan Dompet dan DEX

‣ Pertukaran akan menunjuk akun yang dapat ditulis:

• Transaksi yang mempengaruhi akun yang sama akan diproses secara berurutan;
• Pengaruhnya dapat mengatur urutan atau pemrosesan paralel dari transaksi pada akun yang berbeda.

Stake likuid Solana:

‣ Solana menggunakan Delegated Proof of Stake (DPoS).

‣ Pengguna akan stake SOL ke dalam pool validator, dan dapat memperoleh LST (Token stake yang dapat dialihkan).

• Hadiah staking bersaing langsung dengan pendapatan pinjaman:

• Jika pendapatan pinjaman lebih tinggi dari imbalan stake, validator mungkin akan menarik dana, yang mungkin berdampak pada keamanan jaringan.

Dua jenis Token LST:

1. Token dengan jenis imbalan atau token dasar lagi.

• Pengguna stake 10 SOL ke dalam kolam stake, mendapatkan 10 token LST.
• pool staking akan mendistribusikan SOL ini ke beberapa validator, dan mendapat vSOL.
• vSOL ini mewakili imbal hasil staking validator.
• Token LST didukung oleh vSOL ini.

• validator LST Token（Token khusus）。

• Pengguna melakukan staking 10 SOL pada validator LST dan mendapatkan Token v_lstSOL, yang mewakili kepentingan staking SOL mereka.
• validator akan melakukan stake SOL di dalam pool ke jaringan Solana dan mendapatkan sSOL.
• SOL ini mewakili SOL saham validator dan hadiah terkait.

MEV Solana:

Pemimpin Blok saat ini memiliki kontrol penuh atas produksi dan penjadwalan Blok.

Pemimpin didorong untuk memproses transaksi dengan biaya prioritas, tetapi tidak selalu diterapkan secara paksa.

‣ Dampak Negatif MEV pada Solana:

• Lebih dari 50% sumber daya komputasi terbuang untuk percobaan Arbitrase yang gagal.

‣ Solana tidak memiliki memory pool publik (mempool), transaksi langsung diteruskan ke pemimpin saat ini dan pemimpin berikutnya.

Perbedaan Ethereum MEV dan Solana MEV:

Cara Produksi Blok:

• Default validator Solana terus memproduksi Blok, mengatasi dan memproses transaksi dengan lancar.
• Ethereum memproses transaksi dalam kelompok-kelompok dengan interval 12 detik.

Dampak MEV:

• ETH坊：

• Biaya Jaringan High
• Blok space berkurang
• Pengguna Terjepit dan Kabur

• Solana：

• Penelusur mencoba menyusup ke transaksi dengan menggunakan transaksi sampah.
• Transaksi gagal menyia-nyiakan sumber daya komputasi.
• Sebagian kecil pencari mendapatkan sebagian besar keuntungan.