Pengantar

"Kami tahu yang lebih kecil, lebih cepat, lebih murah lebih baik dari siapa pun di dunia, dan sekarang kami menerapkan konsep-konsep itu ke blockchain." — Greg Fitzgerald, salah satu pendiri Solana

Solana adalah blockchain berkinerja tinggi dan rendah latency yang terkenal karena kecepatannya, efisiensi, dan fokus pada pengalaman pengguna. Arsitektur terintegrasi uniknya memungkinkan ribuan transaksi per detik di seluruh jaringan terdesentralisasi secara global. Dengan waktu blok 400 milidetik dan biaya transaksi yang hanya pecahan sen, Solana memberikan kecepatan dan efisiensi biaya. Laporan ini menggali lebih dalam tentang desain dan operasi Solana, menjelajahi mekanisme kunci dan topologi jaringan yang berkontribusi pada kemampuannya.

Solana mengambil pendekatan terintegrasi dalam pengembangan blockchain, dengan memanfaatkan pengalaman puluhan tahun tim pendiri dalam membangun sistem terdistribusi. Salah satu prinsip inti Solana adalah bahwa perangkat lunak tidak boleh menghambat perangkat keras. Ini berarti bahwa perangkat lunak memaksimalkan pemanfaatan perangkat keras tempat ia berjalan dan berkembang bersamanya. Sebagai ekosistem yang terpadu, semua aplikasi yang dibangun di atas blockchain tunggal ini mewarisi komposabilitas, memungkinkan interaksi dan pengembangan bersama tanpa hambatan. Arsitektur ini juga memastikan pengalaman pengguna yang langsung dan intuitif tanpa perlu jembatan, ID rantai terpisah, atau fragmentasi likuiditas.

Solana berkembang dengan cepat, dengan perkembangan terbaru termasuk SVM rollups danKompresi ZKsebagai solusi penskalaan yang penting. Sementara proyek-proyek ini mungkin suatu hari nanti akan membentuk persepsi masa depan kita tentang Solana, saat ini mereka masih dalam tahap awal pengembangan atau adopsi dan tidak akan dibahas dalam laporan ini.

Siklus Transaksi

Lens utama kami untuk memahami Solana dalam laporan ini akan menjadi siklus hidup transaksi yang khas. Untuk membuat model dasar untuk memahami transaksi Solana, kita dapat menguraikan prosesnya sebagai berikut:

• Pengguna menginisiasi transaksi, yang semuanya dikirim ke produsen blok pemimpin saat ini (dikenal sebagai pemimpin). Pemimpin menyusun transaksi-transaksi ini ke dalam blok, menjalankannya dan dengan demikian memperbarui status lokal mereka.
• Blok transaksi ini kemudian disebarkan ke seluruh jaringan untuk dieksekusi dan dikonfirmasi oleh validator lain.

Bagian-bagian berikut dari laporan ini akan mengembangkan model ini dan menyelami proses ini dengan lebih detail, dimulai dengan peserta kunci—pengguna.

Ingat

Perubahan substansial terhadap protokol inti Solana melalui proses formal, transparanprosesdari mengajukan Dokumen Peningkatan Solana (SIMD) yang akan dikritik secara publik oleh anggota komunitas dan inti rekayasa. SIMD kemudian dipilih oleh jaringan.

Enam tahap

Kami akan merujuk pada visual enam tahap yang ditunjukkan di atas sepanjang laporan ini, karena memberikan kerangka kerja yang konsisten bagi kami untuk memahami hubungan antara elemen inti Solana.

Bab-bab sebelumnya disusun sesuai dengan enam tahap ini. Bab-bab terakhir—Gosip, Arsip, Ekonomi, dan Jito—mengikat semua ujung yang terlepas. Penting untuk dicatat bahwa beberapa bab akan melintasi beberapa tahap, dan beberapa tahap akan muncul di beberapa bab.

Tumpang tindih ini tidak dapat dihindari karena kerangka kerja enam tahap memiliki keterbatasan. Secara realitas, Solana adalah sistem terdistribusi yang kompleks dengan banyak elemen yang saling bergantung.

Pengguna

“Solana memiliki potensi untuk menjadi Apple di dunia kripto” — Raj Gokal, pendiri Solana

Perjalanan seorang pengguna biasanya dimulai dengan menyiapkan dan mendanai aplikasi dompet. Beberapa aplikasi dompet populer tersedia untuk Solana, baik sebagai aplikasi seluler asli maupun ekstensi browser.

Dompet menghasilkan pasangan kunci pengguna secara kriptografis, terdiri dari kunci publik dan pribadi. Kunci publik berfungsi sebagai pengidentifikasi unik untuk akun mereka dan dikenal oleh semua peserta dalam jaringan. Akun pengguna di Solana dapat dianggap sebagai struktur data yang menyimpan informasi dan status terkait dengan interaksi mereka dengan blockchain Solana. Dengan cara ini, kunci publik mirip dengan nama file: sama seperti nama file mengidentifikasi file secara unik dalam sistem file, kunci publik Solana mengidentifikasi akun secara unik dalam blockchain Solana. Kunci publik di Solana diwakili sebagai string Base58 32 byte.

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

Kunci pribadi — juga dikenal sebagai kunci rahasia — dapat dianggap sebagai kata sandi atau kunci akses yang memberikan izin untuk mengakses dan memodifikasi akun. Menandatangani dengan kunci pribadi adalah cara blockchains menangani otorisasi. Pengetahuan tentang kunci pribadi memberikan wewenang mutlak atas akun. Kunci pribadi Solana juga memiliki panjang 32 byte. Pasangan kunci adalah kombinasi 64 byte dari kunci publik (setengah pertama) dan kunci pribadi (setengah kedua). Contoh:

3j15jr41S9KmdfughusutvvqBjAeEDbU5sDQp8EbwQ3Hify2pfM1hiEsuFFAVq8bwGywnZpswrbDzPENbBZbd5nj

[63,107,47,255,141,135,58,142,191,245,78,18,90,162,107,197,8,33,211,15,228,235,250,30,185,122,105,23,147,115,115,86,8,155,67,155,110,51,117,0,19,150,143,217,132,205,122,91,167,61,6,246,107,39,51,110,185,81,13,81,16,182,30,71]

Kunci privat juga dapat diturunkan dari frasa bijak mnemonik, biasanya terdiri dari 12 atau 24 kata. Format ini sering digunakan dalam dompet untuk pencadangan dan pemulihan yang lebih mudah. Beberapa kunci dapat diturunkan secara deterministik dari satu frasa bijak.

Solana menggunakanEd25519, algoritma tanda tangan digital kurva eliptik yang banyak digunakan, untuk kebutuhan kriptografi kunci publiknya. Ed25519 disukai karena ukuran kuncinya kecil, ukuran tanda tangannya kecil, perhitungan cepat, dan kekebalan terhadap banyak serangan umum. Setiap alamat dompet Solana mewakili sebuah titik pada kurva eliptik Ed25519.

Pengguna menandatangani transaksi dengan kunci pribadi mereka. Tanda tangan ini disertakan dengan data transaksi dan dapat diverifikasi oleh peserta lain menggunakan kunci publik pengirim. Proses ini memastikan transaksi tidak dimanipulasi dan diotorisasi oleh pemilik kunci pribadi yang sesuai. Tanda tangan juga berfungsi sebagai pengidentifikasi unik untuk transaksi tersebut.

Transaksi Solana

Mengirimkan transaksi adalah satu-satunya cara untuk mengubah status di Solana. Setiap operasi penulisan dilakukan melalui transaksi, dan transaksi bersifat atomis—entah semua yang dicoba transaksi lakukan berhasil atau transaksi gagal. Sebuah transaksi, lebih dikenal secara formal sebagai “pesan transaksi,” terdiri dari empat bagian: sebuah header, daftar alamat akun, hash blok terbaru, dan instruksi.

• Header: Header berisi referensi ke daftar alamat rekening, menunjukkan rekening mana yang harus menandatangani transaksi.
• Alamat Akun: Daftar ini mencakup semua akun yang akan dibaca atau ditulis selama transaksi. Membangun daftar seperti itu untuk setiap transaksi merupakan persyaratan unik untuk Solana dan bisa menjadi tantangan bagi pengembang. Namun, mengetahui sebelumnya bagian mana dari status transaksi akan berinteraksi memungkinkan optimasi yang tidak mungkin dilakukan di banyak blockchain lainnya.
• Recent Blockhash: Ini digunakan untuk mencegah transaksi ganda dan kadaluarsa. Sebuah recent blockhash kedaluwarsa setelah 150 blok (sekitar 1 menit). Secara default, RPC mencoba meneruskan transaksi setiap 2 detik sampai transaksi tersebut entah difinalisasi atau recent blockhash kedaluwarsa, pada titik tersebut transaksi tersebut dibatalkan.
• Petunjuk: Ini membentuk bagian inti dari transaksi. Setiap petunjuk mewakili operasi spesifik (misalnya, transfer, mint, burn, buat akun, tutup akun). Setiap petunjuk menentukan program yang akan dieksekusi, akun yang diperlukan, dan data yang diperlukan untuk eksekusi petunjuk tersebut.

Jumlah instruksi dalam sebuah transaksi pertama kali dibatasi oleh ukurannya, yang dapat mencapai hingga 1.232 byte. Ada juga batasan seputar jumlah akun yang dapat dirujuk. Terakhir, ada batasan kompleksitas transaksi yang diukur dalam unit komputasi (CUs). CUs mengukur sumber daya komputasi yang dikeluarkan dalam memproses transaksi.

Ingat

Satuan terkecil dari SOL dikenal sebagai "lamport," setara dengan satu miliar bagian dari SOL, mirip dengan satoshi dalam Bitcoin. Lamport dinamai sesuaiLeslie Lamport, seorang ilmuwan komputer dan matematikawan yang penelitiannya menetapkan banyak dasar teoretis sistem terdistribusi modern.

Biaya dalam SOL untuk mengeksekusi transaksi dibagi menjadi 2 bagian - biaya dasar dan biaya prioritas. Biaya dasar adalah biaya tetap 5000 lamports per biaya tanda tangan terlepas dari kompleksitas transaksi—biasanya, ada 1 tanda tangan per transaksi.

Biaya prioritas sebenarnya opsional secara teknis, tetapi selama periode permintaan ruang blok yang tinggi menjadi penting. Biaya ini dihargai dalam mikro-lamport (sejuta lamport) per unit komputasi. Tujuan mereka adalah bertindak sebagai sinyal harga, membuat transaksi lebih menarik secara ekonomi bagi node validator untuk dimasukkan dalam blok mereka.

total biaya = biaya prioritas + biaya dasar

prioritization fee = harga unit komputasi (mikro-lamport) x batas unit komputasi

Saat ini, 50% dari semua biaya terkait transaksi terbakar, secara permanen menghapus SOL ini dari peredaran dengan 50% sisanya diberikan kepada produsen blok. Perubahan baru (SIMD 96) segera akan diperkenalkan yang memungkinkan 100% dari biaya prioritas untuk diberikan kepada produsen blok. Biaya dasar tetap tidak berubah.

‍

Mengirim transaksi

Seorang pengguna menghubungkan dompet mereka ke aplikasi, memungkinkan aplikasi untuk membaca kunci publik pengguna. Kunci privat tetap terenkripsi dan aman di dalam lingkungan terpisah dari aplikasi.

Aplikasi membangun parameter pesan transaksi berdasarkan interaksi pengguna. Misalnya, jika seorang pengguna ingin menukar dua token, mereka akan menentukan jumlah token yang ingin dibeli, token yang sesuai untuk dijual, dan slippage transaksi yang dapat diterima.

Setelah pesan transaksi siap, pesan tersebut dikirimkan ke dompet untuk ditandatangani dengan kunci pribadi pengguna. Pada titik ini, pengguna diminta dengan popup untuk mengonfirmasi keinginan mereka untuk bertransaksi. Pop-up ini mungkin termasuk simulasi hasil transaksi. Setelah ditandatangani, pesan transaksi dan tanda tangan dikembalikan ke aplikasi, yang kemudian dapat meneruskan transaksi ke penyedia RPC pilihan mereka, baik menggunakan penyedia mereka sendiri atau dengan menggunakan penyedia dompet.

Penyedia RPC (Remote Procedure Call) bertindak sebagai perantara antara aplikasi dan validator yang membangun blok. Mereka adalah layanan penting yang memungkinkan aplikasi untuksubmitatau mensimulasikan transaksi yang ditandatangani dan mendapatkan data on-chain dengan efisien. Aplikasi yang ingin berinteraksi dengan jaringan melakukannya melalui titik akhir JSON-RPC atau WebSocket (dokumen.

Ingat

Istilah "transaksi gagal" di Solana menyesatkan dan telah menyebabkan kebingungan yang cukup besar. Transaksi ini dikenakan biaya dan berhasil dieksekusi oleh runtime persis seperti yang dimaksudkan penandatangan. Mereka "gagal" karena logika transaksi itu sendiri mengharuskan mereka untuk melakukannya. +80% transaksi "gagal" berasal dari kode kesalahan 0x1771, kode untuk melebihi jumlah slippage (data). Secara signifikan, 95% dari transaksi ini diajukan oleh hanya 0,1% dari alamat Solana aktif, terutama bot otomatis yang mencoba memanfaatkan peluang arbitrase harga yang sensitif terhadap waktu.

Arus Teluk

Secara harfiah tujuan Solana adalah untuk melakukan transaksi secepat berita beredar di seluruh dunia — secepat cahaya melalui serat optik. Lawan yang kita hadapi adalah NASDAQ dan Bursa Saham New York.

RPC (Remote Procedure Calls) merujuk pada node RPC. Node-node ini dapat dianggap sebagai gerbang untuk berinteraksi dengan dan membaca data dari jaringan. Mereka menjalankan perangkat lunak yang sama dengan validator penuh tetapi dengan pengaturan yang berbeda, memungkinkan mereka untuk mensimulasikan transaksi dengan akurat dan mempertahankan pandangan yang terkini dari keadaan saat ini. Saat ini, ada lebih dari 4.000 node RPC di jaringan Solana.

Berbeda dengan node validator penuh, node RPC tidak memegang saham dalam jaringan. Tanpa saham, mereka tidak dapat memberikan suara atau membangun blok. Penyiapan ini berbeda dari kebanyakan blockchain lain, di mana node validator dan RPC biasanya sama. Karena node RPC tidak menerima imbalan staking, ekonomi menjalankan node RPC berbeda dari node validator dengan banyak yang beroperasi sebagai layanan berbayar untuk pengembang yang menjalankan aplikasi Solana.

Solana menonjol karena dirancang dari awal untuk beroperasi tanpa mempool. Berbeda dengan blockchain tradisional yang menggunakan protokol gossip untuk secara acak dan luas menyebarkan transaksi di seluruh jaringan, Solana meneruskan semua transaksi ke validator pemimpin yang telah ditentukan sebelumnya, yang dikenal sebagai pemimpin, untuk setiap slot.

Panggilan

Solana mengoperasikan empat cluster: Localnet, Testnet, Devnet, dan Mainnet-Beta. Ketika orang merujuk pada Solana atau jaringan Solana, mereka hampir selalu merujuk pada Mainnet-Beta. Mainnet-Beta adalah satu-satunya cluster di mana token memiliki nilai riil, sementara cluster lainnya digunakan semata-mata untuk tujuan pengujian.

Setelah RPC menerima pesan transaksi untuk dimasukkan dalam blok, RPC harus diteruskan ke pemimpin. Jadwal pemimpin dibuat sebelum setiap zaman (kira-kira setiap dua hari). Zaman yang akan datang dibagi menjadi slot, masing-masing ditetapkan pada 400 milidetik, dan seorang pemimpin dipilih untuk setiap slot. Validator dengan taruhan yang lebih tinggi akan dipilih lebih sering untuk menjadi pemimpin dalam setiap zaman. Selama setiap slot, pesan transaksi diteruskan ke pemimpin, yang memiliki kesempatan untuk menghasilkan blok. Ketika giliran validator, mereka beralih ke "mode pemimpin," mulai aktif memproses transaksi dan menyiarkan blok ke seluruh jaringan.

Stake-Weighted Quality of Service - SWQoS

Pada awal 2024, Solana memperkenalkan mekanisme baru yang bertujuan untuk mencegah spam dan meningkatkan ketahanan Sybil, yang dikenal sebagai “Stake-Weighted Quality of Service” (SWQoS). Sistem ini memungkinkan pemimpin untuk memprioritaskan pesan transaksi yang diproksikan melalui validator yang dipertaruhkan lainnya. Di sini, validator dengan taruhan lebih tinggi diberikan kapasitas yang proporsional lebih tinggi untuk mengirimkan paket pesan transaksi ke pemimpin. Pendekatan ini efektif mengurangi serangan Sybil dari node-node tanpa taruhan di seluruh jaringan.

Dalam model ini, validator juga dapat melakukan kesepakatan untuk menyewakan kapasitas mereka yang ditimbang berdasarkan taruhan kepada node RPC. Sebagai imbalannya, node RPC memperoleh peningkatan bandwidth, memungkinkan mereka untuk mencapai tingkat inklusi transaksi yang lebih tinggi dalam blok. Dapat diperhatikan, 80% dari kapasitas pemimpin (2.000 koneksi) disediakan untuk SWQoS. Sementara 20% sisanya (500 koneksi) dialokasikan untuk pesan transaksi dari node non-taruh. Strategi alokasi ini mencerminkan jalur prioritas di jalan raya, di mana pengemudi membayar tol untuk menghindari kemacetan.

SWQoS telah memengaruhi ekosistem Solana dengan meningkatkan persyaratan untuk meneruskan transaksi ke pemimpin dan mengurangi efektivitas serangan spam. Perubahan ini mendorong aplikasi dengan lalu lintas tinggi untuk mengintegrasikan operasi mereka secara vertikal. Dengan menjalankan node validator mereka sendiri, atau dengan memiliki akses ke koneksi yang dipertaruhkan, aplikasi dapat memastikan akses istimewa ke pemimpin, dengan demikian meningkatkan kemampuan pemrosesan transaksi mereka.

Sebuah Catatan Singkat QUIC

Pada akhir 2022, Solana mengadopsiprotokol jaringan QUICuntuk mengelola transmisi pesan transaksi ke pemimpin. Transisi ini dipicu oleh gangguan jaringan yang disebabkan oleh bot-bots spamming di rantai NFT. QUIC memfasilitasi komunikasi yang cepat dan asinkron.

Awalnya dikembangkan olehGooglePada tahun 2012, QUIC berusaha menawarkan yang terbaik dari kedua dunia. Ini memfasilitasi komunikasi cepat, asinkron yang mirip dengan UDP, tetapi dengan sesi yang aman dan strategi kontrol aliran canggih dari TCP. Ini memungkinkan batasan ditempatkan pada sumber individual lalu lintas sehingga jaringan dapat fokus pada pemrosesan transaksi yang asli. Ini juga memiliki konsep aliran terpisah; jadi jika satu transaksi ditolak, itu tidak perlu memblokir yang tersisa. Singkatnya, QUIC dapat dianggap sebagai upaya untuk menggabungkan karakteristik terbaik dari TCP dan UDP.

Kotak pemanggilan

Bobot penimbangan adalah prinsip yang berulang yang ditemukan di seluruh sistem Solana, mencakup reward voting, pohon turbin, jadwal pemimpin, Gulf Stream, dan jaringan gosip. Validator dengan penimbangan yang lebih besar diberikan kepercayaan yang lebih tinggi dan peran yang diprioritaskan dalam jaringan.

Pembangunan Blok

“Kami menganggap SVM (Solana Virtual Machine) sebagai yang terbaik dalam hal teknologi mesin virtual saat ini.” — Andre Cronje, Fantom Foundation

Banyak jaringan blockchain membangun blok-blok secara menyeluruh sebelum menyiarkannya, yang dikenal sebagai pembangunan blok diskrit. Solana, sebaliknya, menggunakan pembangunan blok kontinu yang melibatkan perakitan dan streaming blok secara dinamis saat blok-blok tersebut dibuat selama slot waktu yang dialokasikan, secara signifikan mengurangi laten.

Setiap slot berlangsung selama 400 milidetik, dan setiap pemimpin diberi empat slot berturut-turut (1,6 detik) sebelum beralih ke pemimpin berikutnya. Agar blok diterima, semua transaksi di dalamnya harus valid dan dapat direproduksi oleh node lain.

Dua slot sebelum mengasumsikan kepemimpinan, validator menghentikan pengalihan transaksi untuk mempersiapkan beban kerja yang akan datang. Selama interval ini, lalu lintas masuk melonjak, mencapai lebih dari satu gigabyte per detik saat seluruh jaringan mengarahkan paket ke pemimpin yang akan datang.

Setelah diterima, pesan transaksi memasuki Unit Pemrosesan Transaksi (TPU), logika inti validator yang bertanggung jawab untuk produksi blok. Di sini, urutan pemrosesan transaksi dimulai dengan Tahap Pengambilan, di mana transaksi diterima melalui QUIC. Selanjutnya, transaksi berkembang ke Tahap SigVerify, menjalani pemeriksaan validasi yang ketat. Di sini validator memverifikasi kevalidan tanda tangan, memeriksa jumlah tanda tangan yang benar, dan menghilangkan transaksi ganda.

Tahapan Perbankan

Tahap perbankan dapat dijelaskan sebagai tahap pembangunan blok. Ini adalah tahap paling penting dari TPU, yang mendapatkan namanya dari 'bank'. Sebuah bank hanyalah keadaan pada blok tertentu. Untuk setiap blok, Solana memiliki sebuah bank yang digunakan untuk mengakses keadaan pada blok tersebut. Ketika sebuah blok menjadi final setelah validator yang cukup memberikan suara, mereka akan menyimpan pembaruan akun dari bank ke disk, membuatnya permanen. Keadaan final rantai adalah hasil dari semua transaksi yang dikonfirmasi. Keadaan ini selalu bisa direkonstruksi dari sejarah blockchain secara deterministik.

Transaksi diproses secara paralel dan dikemas ke dalam "entri" ledger, yang merupakan batch dari 64 transaksi yang tidak saling bertentangan. Proses transaksi paralel di Solana menjadi mudah karena setiap transaksi harus mencakup daftar lengkap dari semua akun yang akan dibaca dan ditulis. Pilihan desain ini menempatkan beban pada pengembang namun memungkinkan validator untuk menghindari kondisi perlombaan dengan mudah memilih hanya transaksi yang tidak bertentangan untuk dieksekusi dalam setiap entri. Transaksi bertentangan jika keduanya mencoba untuk menulis ke akun yang sama (dua penulisan) atau jika satu mencoba untuk membaca dari dan yang lain menulis ke akun yang sama (baca + tulis). Dengan demikian, transaksi yang bertentangan masuk ke entri yang berbeda dan dieksekusi secara berurutan, sementara transaksi yang tidak bertentangan dieksekusi secara paralel.

Ada enam utas yang memproses transaksi secara paralel, dengan empat di antaranya diperuntukkan khusus untuk transaksi normal dan dua di antaranya secara eksklusif menangani transaksi suara yang merupakan bagian integral dari mekanisme konsensus Solana. Semua pemrosesan paralel ini dicapai melalui beberapa inti CPU; validator tidak memiliki persyaratan GPU.dokumen.

Setelah transaksi telah dikelompokkan ke dalam entri, mereka siap untuk dieksekusi oleh Mesin Virtual Solana (SVM). Akun yang diperlukan untuk transaksi dikunci; pemeriksaan dijalankan untuk mengonfirmasi transaksi baru tetapi belum diproses. Akun dimuat, dan logika transaksi dieksekusi, memperbarui status akun. Hash dari entri akan dikirim ke layanan Proof of History untuk direkam (lebih lanjut tentang ini akan dibahas di bagian berikutnya). Jika proses perekaman berhasil, semua perubahan akan di-commit ke bank, dan kunci pada setiap akun yang ditempatkan pada langkah pertama akan dilepaskan. Eksekusi dilakukan oleh SVM, mesin virtual yang dibangun menggunakan fork Solana darirBPF, perpustakaan untuk bekerja dengan kompilasi JIT, dan mesin virtual untuk program eBPF. Perhatikan bahwa Solana tidak memaksa validator untuk memilih cara mengurutkan transaksi dalam blok. Fleksibilitas ini adalah titik penting yang akan kita bahas lebih lanjut di bagian Ekonomi + Jito dari laporan ini.

Ingat

Istilah SVM dapat menjadi ambigu, karena dapat merujuk baik pada "Mesin Virtual Solana" atau "Mesin Virtual Sealevel." Kedua istilah tersebut menggambarkan konsep yang sama, dengan Sealevel menjadi nama lingkungan runtime Solana. Istilah SVM terus digunakan secara longgar meskipun upaya terbaru untuk dengan tepatmendefinisikan batasnya.

Klien

Solana adalah jaringan yang terdiri dari ribuan node yang dioperasikan secara independen bekerja sama untuk mempertahankan ledger tunggal yang terpadu. Setiap node merupakan mesin kinerja tinggi yang menjalankan perangkat lunak sumber terbuka yang sama yang dikenal sebagai "klien".

Solana diluncurkan dengan perangkat lunak klien validator tunggal — awalnya klien Solana Labs, sekarang dikenal sebagaiklien Agave—ditulis dalam Rust. Meningkatkan keragaman klien telah menjadi prioritas sejak awal dan hal ini akan benar-benar terwujud dengan diluncurkannyaklien FiredancerFiredancer adalah penulisan ulang lengkap dari klien asli dalam bahasa pemrograman C. Dibangun oleh tim berpengalaman dari perusahaan perdagangan frekuensi tinggi Jump, ini menjanjikan menjadi klien validator paling performant di semua blockchain.

Bukti Sejarah

“Saya minum dua cangkir kopi dan sebotol bir, dan saya tidak tidur sampai pukul 4:00 pagi. Saya merasakan momen eureka bahwa teka-teki [sic] mirip dengan bukti kerja menggunakan fungsi hash SHA-256 yang tahan terhadap preimage yang sama... Saya tahu bahwa saya memiliki panah waktu ini.” — Anatoly Yakovenko, pendiri Solana

Proof of History (PoH) adalah saus rahasia Solana, berfungsi seperti jam khusus di setiap validator yang memfasilitasi sinkronisasi di seluruh jaringan. PoH membentuk sumber kebenaran yang dapat diandalkan untuk urutan peristiwa dan berlalunya waktu. Yang paling penting adalah memastikan kepatuhan terhadap jadwal pemimpin. Meskipun memiliki nama yang mirip, Proof of History bukanlah algoritma konsensus seperti Proof of Work.

Overhead komunikasi antara node biasanya meningkat ketika jaringan berkembang, dan koordinasi menjadi semakin rumit. Solana mengurangi hal ini dengan menggantikan komunikasi node-to-node dengan komputasi lokal PoH. Ini berarti validator dapat mengkonfirmasi blok hanya dengan satu putaran voting. Timestamp terpercaya dalam pesan memastikan bahwa validator tidak dapat melangkahi satu sama lain dan memulai blok mereka terlalu dini.

Di bawahnya, PoH adalah properti unik dari algoritma hashing, secara khususSHA256:

• Deterministik: Input yang sama akan selalu menghasilkan hash yang sama.
• Ukuran Tetap: Terlepas dari ukuran input, hash output selalu 256 bit.
• Efisien: Cepat menghitung hash untuk setiap input yang diberikan.
• Ketahanan Preimage: Menemukan input asli dari output hash adalah tidak mungkin secara komputasi.
• Efek Longsor: Perubahan kecil pada input (bahkan hanya satu bit) menghasilkan hash yang sangat berbeda, sebuah sifat yang dikenal sebagai efek longsor.
• Ketahanan TabrakanSangat tidak mungkin untuk menemukan dua input yang berbeda yang menghasilkan output hash yang sama.

Dalam setiap klien validator, layanan "Proof of History" yang didedikasikan terus-menerus menjalankan algoritma hash SHA256 menciptakan rantai hash. Input setiap hash adalah output hash sebelumnya. Rantai ini berfungsi sama seperti fungsi keterlambatan yang dapat diverifikasi, mengingat pekerjaan penghasingan harus dilakukan secara berurutan dan hasil hash di masa depan tidak dapat diketahui sebelumnya. Jika layanan PoH menciptakan rantai ribuan hash, kita tahu waktu telah berlalu untuk menghitung setiap hash secara berurutan — ini dapat dianggap sebagai "bukti kerja mikro." Namun, validator lain dapat memverifikasi kebenaran ribuan hash tersebut secara paralel dengan kecepatan yang jauh lebih cepat daripada yang diproduksi karena input dan output setiap hash telah disiarkan ke jaringan. Oleh karena itu, PoH sulit diproduksi tetapi mudah diverifikasi.

Rentang kinerja dalam menghitung SHA-256 di berbagai CPU sangatlah sempit, dengan perbedaan kecil di antara mesin tercepat. Batas atas umum telah mencapai titik maksimal, meskipun waktu dan usaha yang signifikan diinvestasikan dalam mengoptimalkan fungsi ini, terutama karena ketergantungan Bitcoin padanya.

Selama slot pemimpin, layanan PoH akan menerima entri yang baru diproses dari tahap perbankan. Hash PoH saat ini ditambah hash dari semua transaksi dalam entri digabungkan menjadi hash PoH berikutnya. Ini berfungsi sebagai cap waktu yang memasukkan entri ke dalam rantai hash, membuktikan urutan di mana transaksi diproses. Proses ini tidak hanya mengonfirmasi berlalunya waktu tetapi juga berfungsi sebagai catatan kriptografis dari transaksi.

Dalam satu blok, terdapat 800.000 hash. Aliran PoH juga mencakup “ticks,” yang merupakan entri kosong yang menunjukkan kehidupan pemimpin dan berlalunya waktu yang mendekati sebagian kecil dari detik. Satu tick terjadi setiap 6,25 milidetik, menghasilkan 64 tick per blok dan total waktu blok sebesar 400 milidetik.

Validator terus menjalankan jam PoH bahkan ketika mereka bukan pemimpin karena peran penting dalam proses sinkronisasi antara node.

Ingat

Manfaat utama dari PoH adalah memastikan jadwal pemimpin yang benar harus ditaati, bahkan jika seorang produsen blok sedang offline - suatu keadaan yang dikenal sebagai "pelanggaran". PoH mencegah validator jahat untuk memproduksi blok sebelum gilirannya.

Model Akun

Memisahkan kode dan status dalam SVM adalah keputusan desain terbaik. Diberkati para pengembang sistem embedded yang dengan tekun membakar konsep ini ke dalam pikiranku.” — Anatoly Yakovenko, salah satu pendiri Solana

Dalam validator Solana, status global dipertahankan dalam database akun yang dikenal sebagai AccountsDB. Database ini bertanggung jawab untuk menyimpan semua akun, baik di memori maupun di disk. Struktur data utama dalam indeks akun adalah hashmap, menjadikan AccountsDB pada dasarnya sangat luastoko kunci-nilaiDi sini, kunci adalah alamat akun, dan nilai adalah data akun.

Seiring berjalannya waktu, jumlah akun Solana melonjak menjadi ratusan juta. Jumlah besar ini sebagian karena, seperti yang disukai oleh pengembang Solana, "Semua di Solana adalah akun!"

akun Solana

Akun adalah wadah yang secara persisten menyimpan data, mirip dengan file di komputer. Mereka hadir dalam berbagai bentuk:

• Akun pengguna: Akun-akun ini memiliki kunci pribadi dan biasanya dihasilkan oleh perangkat lunak dompet untuk pengguna.
• Akun data: Akun-akun ini menyimpan informasi status, seperti jumlah token spesifik yang dimiliki pengguna.
• Akun program: Ini adalah akun yang lebih besar yang berisi bytecode yang dapat dieksekusi, agak mirip dengan file .exe di Windows atau file .app di Mac.
• Akun program asli: Ini adalah akun program yang telah dipasang sebelumnya yang melakukan berbagai fungsionalitas inti jaringan.Contohtermasuk Program Vote dan Pemuat BPF.

Semua akun memiliki bidang-bidang berikut:

Program

Akun program Solana hanya berisi logika yang dapat dieksekusi. Ini berarti ketika sebuah program dijalankan, ia mengubah status akun lain tetapi tetap tidak berubah sendiri. Pemisahan kode dan status ini membedakan Solana dari blockchain lain dan mendukung banyak optimasinya. Pengembang utamanya menulis program-program ini dalam Rust, bahasa pemrograman umum.dikenalkarena fokusnya yang kuat pada keamanan dan kinerja. Selain itu, beberapa SDK dalam TypeScript dan Python tersedia untuk memudahkan pembuatan tampilan aplikasi dan memungkinkan interaksi program dengan jaringan.

Banyak fungsi umum disediakan secara otomatis oleh program asli. Misalnya, Solana tidak memerlukan pengembang untuk mendeploy kode untuk membuat token. Sebaliknya, instruksi dikirim ke program asli yang telah didaftarkan sebelumnya yang akan menyiapkan akun untuk menyimpan metadata token, secara efektif menciptakan token baru.

Sewa

Sewa adalah mekanisme yang dirancang untuk mendorong pengguna menutup akun dan mengurangi pembengkakan status. Untuk membuat akun baru, saldo minimum SOL, yang dikenal sebagai jumlah "bebas sewa", harus dipegang oleh akun. Ini dapat dianggap sebagai biaya penyimpanan yang dikeluarkan untuk menjaga agar akun tetap aktif dalam memori validator. Jika ukuran data akun meningkat, persyaratan sewa saldo minimum juga meningkat secara proporsional. Ketika akun tidak lagi diperlukan, akun dapat ditutup, dan uang sewa dikembalikan kepada pemilik akun.

Sebagai contoh, jika seorang pengguna memiliki stablecoin yang dinyatakan dalam dolar, keadaan ini disimpan dalam akun token. Saat ini, jumlah yang dibebaskan dari sewa untuk akun token adalah 0,002 SOL. Jika pengguna mentransfer seluruh saldo stablecoin mereka ke seorang teman, akun token dapat ditutup, dan pengguna akan menerima kembali 0,002 SOL mereka. Program sering kali menangani penutupan akun secara otomatis untuk pengguna. Beberapa aplikasi tersedia untuk membantu pengguna membersihkan akun lama yang tidak terpakai dan mendapatkan kembali jumlah kecil SOL yang disimpan di dalamnya.

Kepemilikan

Meskipun membaca data akun diizinkan secara universal, model kepemilikan Solana meningkatkan keamanan dengan membatasi siapa yang dapat mengubah (menulis) data akun. Konsep ini sangat penting untuk menegakkan aturan dan izin pada blockchain Solana. Setiap akun memiliki "pemilik" program. Pemilik akun bertanggung jawab untuk mengaturnya, memastikan bahwa hanya program resmi yang dapat mengubah data akun. Pengecualian penting untuk aturan ini adalah transfer lamports (unit terkecil dari SOL)—meningkatkan saldo lamports akun diizinkan secara universal, terlepas dari kepemilikannya.

Penyimpanan Status

Program Solana, yang merupakan file executable hanya-baca, harus menyimpan status menggunakan “Program Derived Addresses” (PDAs). PDAs adalah jenis akun khusus yang terkait dengan dan dimiliki oleh program daripada pengguna tertentu. Sementara alamat pengguna Solana normal berasal dari kunci publik dari pasangan kunci Ed25519, PDAs tidak memiliki kunci pribadi. Sebaliknya, kunci publik mereka berasal dari kombinasi parameter—seringkali kata kunci atau alamat akun lain—bersama dengan ID program (alamat) dari program yang memiliki.

Alamat PDA ada di luar kurva, artinya tidak berada di atas kurva Ed25519 seperti alamat normal. Hanya program yang memiliki PDA yang dapat secara programatik menghasilkan tanda tangan untuknya, memastikan bahwa hanya itu yang dapat memodifikasi status PDA.

Di atas: Akun token Solana adalah contoh spesifik dari Program Derived Addresses (PDAs). Mereka digunakan untuk menyimpan token dan hidup di luar kurva. Program Akun Token Terkait (ATA) memastikan bahwa setiap dompet hanya dapat memiliki satu akun token terkait untuk setiap jenis token, memberikan cara standar untuk mengelola akun token.

Turbine

Bagian paling menarik tentang Solana bukanlah paralelisasi, SVM, atau twit dari Toly. Ini adalah sesuatu yang mungkin belum pernah Anda dengar: Turbine.

Selama tahap perbankan, transaksi diatur ke dalam entri dan dikirim ke aliran Proof of History untuk penanda waktu. Bank blok diperbarui, dan entri sekarang siap untuk fase berikutnya—Turbine.

Turbine adalah proses di mana pemimpin menyebarkan blok mereka ke seluruh jaringan. Terinspirasi olehBitTorrent, ini dirancang untuk menjadi cepat dan efisien, mengurangi overhead komunikasi dan meminimalkan jumlah data yang perlu dikirim pemimpin.

Turbine mencapai ini dengan memecah data transaksi menjadi “shreds” melalui proses yang disebut “shredding.” Shreds adalah paket data kecil, hingga 1280 byte, mirip dengan frame individu dalam aliran video. Saat dirangkai kembali, shreds ini memungkinkan validator untuk memutar ulang seluruh blok. Shreds dikirim melalui internet antara validator menggunakan UDP dan memanfaatkan pengodean erasure untuk menangani kehilangan paket atau penurunan paket yang jahat.Pengkodean Erasure, apolinomialSkema deteksi dan koreksi kesalahan berbasis, memastikan integritas data. Bahkan jika beberapa serpihan hilang, blok masih dapat direkonstruksi.

Shreds dikelompokkan ke dalam batch yang dikenal sebagai batch koreksi kesalahan maju (FEC). Secara default, batch ini terdiri dari 64 shreds (32 shred data + 32 shred pemulihan). Pemulihan data terjadi per batch FEC, yang berarti bahwa hingga separuh paket dalam satu batch dapat hilang atau rusak, namun semua data masih dapat dipulihkan. Setiap batch 64 shred di-merkelize dengan akar yang ditandatangani oleh pemimpin, dan dihubungkan ke batch sebelumnya. Proses ini memastikan bahwa shreds dapat diperoleh dengan aman dari node apa pun di jaringan yang memiliki mereka, karena rantai akar Merkle menyediakan jalur otentikasi dan integritas yang dapat diverifikasi.

Pemimpin awalnya melakukan siaran ke simpul akar tunggal, yang menyebarkan serpihan ke semua simpul validator lainnya. Simpul akar ini berubah dengan setiap serpihan. Validator diatur ke dalam lapisan, membentuk “Pohon Turbin.” Validator dengan jumlah taruhan yang lebih besar biasanya ditempatkan di bagian atas pohon, sementara yang dengan taruhan lebih rendah ditempatkan di bagian bawah.

Pohon biasanya melintasi dua atau tiga loncatan, tergantung pada jumlah validator aktif. Untuk kesederhanaan visual, fanout 3 digambarkan di atas, tetapi nilai fanout aktual Solana saat ini diatur hingga 200. Untuk alasan keamanan, urutan pohon diputar untuk setiap set baru shred.

Tujuan utama dari sistem tersebut adalah untuk mengurangi tekanan pengeluaran data keluar pada node pemimpin dan node root. Dengan memanfaatkan sistem transmisi dan pengulangan, beban didistribusikan antara pemimpin dan pengulang, mengurangi tekanan pada setiap node tunggal.

Konsensus

"Beberapa orang pintar memberi tahu saya bahwa ada komunitas pengembang pintar yang sungguh-sungguh di Solana... Saya harap komunitas tersebut mendapatkan kesempatan yang adil untuk berkembang" — Vitalik Buterin, pendiri Ethereum

Saat validator menerima blok baru dari pemimpin melalui Turbine, ia harus memvalidasi semua transaksi dalam setiap entri. Ini melibatkan memutar ulang seluruh blok, memvalidasi hash PoH secara paralel, membuat ulang transaksi sesuai urutan yang ditentukan oleh PoH, dan memperbarui bank lokalnya.

Proses ini ditangani oleh Unit Validasi Transaksi (TVU), yang analog dengan Unit Pemrosesan Transaksi (TPU) pemimpin, berfungsi sebagai logika inti yang bertanggung jawab untuk memproses serpihan dan validasi blok. Seperti TPU, alur TVU dibagi menjadi beberapa tahap, dimulai dengan Tahap Pengambilan Serpihan di mana serpihan diterima melalui Turbine. Pada Tahap Verifikasi Tanda Tangan Pemimpin Serpihan berikutnya, serpihan menjalani beberapa pemeriksaan kewarasan, terutama verifikasi tanda tangan pemimpin, yang memastikan bahwa serpihan yang diterima berasal dari pemimpin.

Pada Tahap Pengulang, validator, berdasarkan lokasinya dalam pohon Turbine, meneruskan serpihan ke validator downstream yang sesuai. Pada Tahap Putar Ulang, validator menciptakan kembali setiap transaksi secara tepat dan dalam urutan yang benar sambil memperbarui versi lokal banknya.

Tahap Replay analog dengan tahap perbankan dalam TPU; itu adalah tahap paling penting dan dapat lebih langsung dijelaskan sebagai tahap validasi blok. Replay adalah proses loop berulir tunggal yang mengatur banyak operasi kunci, termasuk pemungutan suara, mereset jam PoH, dan beralih bank.

Di atas: panggung ulang bertanggung jawab untuk beralih validator ke mode pemimpin dan memulai produksi blok. Visual asli: Justin Starry, Anza

Konsensus

Untuk mencapai konsensus, Solana menggunakan Tower BFT (TBFT), sebuah implementasi kustom dari Practical yang terkenalKesalahan BizantiumAlgoritma Toleransi (PBFT), yang umum digunakan oleh sebagian besar blockchain untuk menyetujui status rantai. Seperti halnya semua blockchain, Solana mengasumsikan adanya node jahat dalam jaringan, sehingga sistem harus mampu menahan tidak hanya kegagalan node tetapi juga tingkat serangan tertentu.

Tower BFT membedakan diri dari rantai lain dengan memanfaatkan jam yang disinkronkan yang disediakan oleh Proof of History. Sementara PBFT tradisional memerlukan beberapa putaran komunikasi untuk setuju pada urutan transaksi, node Solana memanfaatkan urutan peristiwa yang telah ditetapkan sebelumnya, secara signifikan mengurangi overhead pesan.

Voting

Untuk berpartisipasi dalam konsensus dan mendapatkan imbalan, validator mengirimkan suara untuk blok yang mereka yakini valid (yaitu bebas dari masalah seperti pengeluaran ganda atau tanda tangan yang tidak benar) dan seharusnya dianggap kanon. Validator membayar biaya transaksi untuk suara ini, yang diproses oleh pemimpin dan dimasukkan dalam blok bersama transaksi pengguna reguler. Inilah mengapa transaksi Solana sering dikategorikan menjadi transaksi suara dan non-suara. Ketika validator mengirimkan suara yang benar dan berhasil, mereka mendapatkan kredit. Mekanisme ini mendorong validator untuk memberikan suara pada fork yang diyakini memiliki peluang terbaik untuk disertakan, yaitu fork yang “paling berat”.

Forks

Bagian dari desain Solana, yang membuatnya begitu cepat, adalah bahwa jaringan tidak menunggu semua validator setuju pada blok yang baru diproduksi sebelum memproduksi yang berikutnya. Akibatnya, tidak jarang dua blok yang berbeda terhubung ke blok induk yang sama, menciptakan fork.

Validator Solana harus memberikan suara pada fork-fork ini dan menggunakan algoritma konsensus untuk menentukan yang mana yang akan diadopsi. Ketika fork-fork bersaing ada, hanya satu fork yang akhirnya akan difinalisasi oleh jaringan, sementara blok-blok dalam fork-fork yang dibuang ditinggalkan.

Setiap slot memiliki pemimpin yang telah ditentukan di mana hanya blok pemimpin itu yang akan diterima; tidak dapat ada dua blok yang diusulkan untuk satu slot. Oleh karena itu jumlah garpu potensial terbatas pada daftar putar 'ada/tidak ada' garpu yang dapat muncul di batas-batas slot rotasi pemimpin. Setelah seorang validator memilih sebuah garpu, ia berkomitmen pada garpu ini hingga waktu kunci terkunci berakhir, yang berarti ia harus tetap pada pilihannya untuk jangka waktu minimum.

“Laju lewati” Solana – persentase slot di mana blok tidak diproduksi – bervariasi dari 2% hingga 10%, dengan fork menjadi alasan utama untuk slot yang dilewati ini. Alasan lain yang mungkin untuk slot yang dilewati termasuk dimulainya epoch baru, pemimpin sedang offline, atau produksi blok yang tidak valid.

Ingat

Status transaksi di Solana bervariasi tergantung pada tahap saat ini dalam proses konsensus:

• Diproses: Transaksi telah dimasukkan ke dalam blok.

• Terkonfirmasi: Blok transaksi telah disetujui oleh supermayoritas dua pertiga.

• Terkonfirmasi: Lebih dari 31 blok telah dibangun di atas blok transaksi.

Hingga saat ini, belum pernah terjadi kejadian dalam sejarah Solana di mana sebuah blok yang (secara optimis) dikonfirmasi tidak menjadi final.

Untuk setiap blok, Solana menggunakan bank untuk mengakses status pada blok tersebut. Ketika sebuah bank difinalisasi, pembaruan akun dari bank tersebut dan leluhurnya disimpan ke disk. Selain itu, semua pembaruan akun dari bank-bank sebelumnya yang bukan leluhur dari bank yang difinalisasi dipangkas. Proses ini memungkinkan Solana untuk menjaga beberapa status potensial secara efisien.

Gosip + Arsip

“Sebuah blockchain membutuhkan kombinasi cerdas dari kriptografi, sistem terdistribusi, sistem operasi, dan bahasa pemrograman. Kekuatan luar biasa Solana adalah keinginan untuk lari sambil berteriak dari masalah paling menarik dalam setiap disiplin.” — Greg Fitzgerald, salah satu pendiri Solana

Gosip

Jaringan gosip dapat dianggap sebagaicontrol planeuntuk jaringan Solana. Berbeda dengan data plane, yang mengelola aliran transaksi, control plane menyebarkan metadata penting tentang status blockchain, seperti informasi kontak, tinggi ledger, dan informasi pemungutan suara. Tanpa gossip, validator dan RPC tidak akan tahu alamat dan port mana yang terbuka untuk komunikasi di berbagai layanan. Node baru juga bergantung pada gossip untuk bergabung dengan jaringan.

Protokol gosip Solana menggunakan komunikasi informal antar rekan dengan pendekatan siaran pohon yang terinspirasi dari algoritma PlumTree yang dimodifikasi. Metode ini secara efisien menyebarkan informasi tanpa mengandalkan sumber pusat mana pun.

Gossip beroperasi agak sebagai sistem yang terisolasi, independen dari sebagian besar komponen validator lainnya. Validator dan RPC berbagi objek data yang ditandatangani setiap 0,1 detik melalui UDP melalui gosip, memastikan ketersediaan informasi di seluruh jaringan. Semua pesan gosip harus kurang dari atau sama dengan unit transmisi maksimum (MTU) 1280 byte, disebut sebagai "packet struct" di basis kode.

Catatan gosip adalah objek data aktual yang dibagikan antara node. Ada sekitar 10 jenis catatan yang berbeda, masing-masing melayani tujuan yang berbeda. Catatan gosip ditandatangani, diberi versi, dan ditandai waktu untuk memastikan integritas dan kekinian.

Ada empat jenis pesan gosip:

• Push: Pesan-pesan paling umum, berbagi informasi dengan sebagian kecil "rekan push."
• Pull & Pull Response: Secara berkala memeriksa pesan yang terlewat, dengan respons tarik mengirim kembali informasi bahwa node tidak memiliki.
• Prune: Memungkinkan node untuk secara selektif mengurangi jumlah koneksi yang mereka pertahankan.
• Ping & Pong: Pemeriksaan kesehatan untuk node - jika ping dikirim, pong diharapkan kembali, menunjukkan node rekan masih aktif.

Data gosip disimpan dalam Cluster Replicated Data Store (CrdsTable). Struktur data ini dapat tumbuh sangat besar dan perlu dipangkas secara berkala.

Arsip

Solana menonjol dari blockchain lain dengan tidak memerlukan sejarah lengkap untuk menentukan keadaan terkini dari sebuah akun. Model akun Solana memastikan bahwa keadaan pada slot tertentu diketahui, memungkinkan validator untuk menyimpan keadaan terkini dari setiap akun tanpa memproses semua blok historis. RPC dan validator, secara desain, tidak menyimpan ledger historis secara keseluruhan. Sebaliknya, biasanya mereka hanya menyimpan data transaksi selama 1 atau 2 epoch (2-4 hari), yang cukup untuk memvalidasi ujung rantai.

Arsip saat ini dikelola oleh “node gudang,” yang dioperasikan oleh penyedia layanan RPC profesional, Yayasan Solana, dan peserta ekosistem lain yang tertarik untuk memastikan riwayat transaksi tersedia. Node gudang biasanya memelihara salah satu atau kedua hal berikut:

1. Arsip Ledger: Mengunggah ledger mentah dan snapshot AccountsDB yang sesuai untuk diputar ulang dari awal.

2. Instance Google Bigtable: Menyimpan data blok mulai dari blok genesis ke depan, diformat untuk melayani permintaan RPC.

Ekonomi + Jito

"Orang-orang menyadari bahwa Solana adalah satu-satunya rantai yang tersedia saat ini yang akan mendukung aplikasi konsumen arus utama." - Ted Livingston, pendiri Code

Solana menggunakan inflasi untuk mendistribusikan imbalan staking dengan menghasilkan token SOL baru setiap epoch. Proses ini menyebabkan bagian jaringan non-staker menurun relatif terhadap staker, menyebabkan transfer kekayaan dari non-staker ke staker. Inflasi dimulai pada awal 2021 pada tingkat awal 8% yang turun 15% setiap tahun hingga stabil pada tingkat jangka panjang 1,5%.

Setiap pemegang token SOL dapat memperoleh imbalan dan membantu mengamankan jaringan dengan melakukan staking token ke satu atau lebih validator. Mengalokasikan token ke validator dikenal sebagai delegasi. Delegasi token ke validator menunjukkan kepercayaan pada validator tersebut. Namun, hal ini tidak memberikan kepemilikan atau kontrol atas token kepada validator. Semua tindakan staking, pembatalan staking, dan delegasi dilaksanakan pada awal epoch baru berikutnya.

‍

Hadiah Voting

Ketika seorang validator mengirimkan suara, mereka mendapatkan kredit jika suara tersebut akurat dan sukses. Biaya transaksi voting sebesar 0.000005 SOL dan tidak dikenakan biaya prioritas. Biaya voting sekitar 1 SOL per hari per validator, membuatnya menjadi biaya operasional utama dalam menjalankan validator. Selama satu epoch, validator mengumpulkan kredit dari voting, yang dapat mereka tukarkan dengan bagian dari inflasi pada akhir epoch.

Validator teratas berhasil memilih sekitar 90% slot. Perlu diperhatikan bahwa persentase slot tanpa blok (tingkat slot terlewatkan) berkisar dari 2% hingga lebih dari 10%, dan slot-slot ini tidak dapat dipilih. Rata-rata validator berhasil memilih sekitar 80% slot, menghasilkan 345.600 kredit dalam satu epoch dari 432.000 slot.

Total pot inflasi pertama dibagi berdasarkan kredit yang diperoleh untuk zaman tersebut. Bagian validator dari total kredit (kredit mereka dibagi dengan jumlah semua kredit validator) menentukan imbalan proporsional mereka. Ini selanjutnya ditimbang oleh pasak.

Oleh karena itu, seorang validator dengan 1% dari total staking seharusnya mendapatkan sekitar 1% dari inflasi total jika mereka memiliki jumlah kredit rata-rata. Jika mereka memiliki di atas atau di bawah jumlah kredit rata-rata, imbalan mereka akan fluktuatif sesuai.

Perbedaan dalam kinerja pemungutan suara adalah salah satu alasan mengapa pengembalian (diukur dalam APY) yang ditawarkan validator kepada pemegang koin berbeda. Faktor lainnya adalah tingkat komisi yang dibebankan oleh validator, yang merupakan persentase dari total imbalan inflasi yang diarahkan ke validator mereka. Selain itu, validator yang offline atau tidak sinkron dengan blockchain (dikenal sebagai kelalaian) berdampak signifikan pada pengembalian.

Hadiah blok

Validator yang ditunjuk sebagai pemimpin untuk blok tertentu menerima imbalan blok tambahan. Imbalan ini terdiri dari 50% biaya dasar dan 50% biaya prioritas dari semua transaksi dalam blok, dengan sisa biaya dibakar. Hanya validator yang memproduksi blok yang menerima imbalan ini. Tidak seperti imbalan staking yang didistribusikan per epoch, imbalan blok langsung dikreditkan ke akun identitas validator ketika blok diproduksi.

Staking cair

Staking likuid telah menjadi alternatif populer untuk staking asli. Peserta menerima token, yang dikenal sebagai Liquid Staking Token (LST) atau Turunan Staking Likuid (LSD), sebagai imbalan atas staking SOL mereka, biasanya di dalam kolam staking yang mengalihkan token mereka di sejumlah validator. Token LST yang baru diterima mewakili bagian pengguna dari SOL yang distaking. Token-token ini dapat diperdagangkan, digunakan di aplikasi, atau ditransfer ke orang lain sambil tetap mendapatkan imbalan staking. Keuntungan utama dari sistem ini adalah meningkatkan secara signifikan efisiensi modal.

Harga LST = (total SOL yang dipertaruhkan di kolam * harga SOL) / total LST yang dimintakan

Dengan pengepungan asli tradisional, dari waktu ke waktu, pengepungan akan langsung mengakumulasi lebih banyak SOL. Sedangkan dengan pengepungan cair, imbalan diinvestasikan kembali ke dalam kolam meningkatkan nilai wajar LST. Selama ada mekanisme untuk menebus LST untuk SOL yang dipertaruhkan yang mendasari, pedagang arbitrase akan memastikan bahwa harga token tetap rasional.

Jito

Saat ini, lebih dari 80% ( sumber) dari stake di Solana menggunakan perangkat lunak validator klien Jito. Klien ini, cabang dari klien Agave asli, memperkenalkan pelelangan ruang blok di luar protokol yang memberikan insentif ekonomi tambahan kepada validator melalui tips. Insentif tambahan ini adalah faktor utama dalam adopsi luas klien Jito di kalangan validator.

Ketika pemimpin menggunakan klien validator Jito, transaksi mereka pada awalnya diarahkan ke Jito-Relayer. Perangkat lunak sumber terbuka ini berfungsi sebagai router proxy transaksi. Node jaringan lain tetap tidak sadar akan keberadaan Jito-Relayer, karena mereka hanya mengirim transaksi ke konfigurasi alamat dan port yang pemimpin telah iklankan melalui jaringan gossip sebagai ingress_socket mereka, menganggapnya sebagai pemimpin.

Relayer menahan semua transaksi selama 200 milidetik sebelum meneruskannya ke pemimpin. Mekanisme "speed bump" ini menunda pesan transaksi masuk, memberikan jendela singkat untuk melakukan lelang. Setelah 200 milidetik, relayer dengan optimis melepaskan transaksi terlepas dari hasil lelang.

Lelang ruang blok terjadi di luar rantai melalui Jito Block Engine, memungkinkan pencari dan aplikasi untuk mengirimkan kelompok transaksi yang dieksekusi secara atomik yang dikenal sebagai bundel. Bundel-bundel ini biasanya berisi transaksi yang bersifat waktu-sensitif seperti arbitrase atau likuidasi. Jito menagih biaya 5% pada semua tips, dengan tip minimum sebesar 10.000 lamports. Tips beroperasi sepenuhnya di luar protokol, terpisah dari prioritas dalam protokol dan biaya dasar. Sebelumnya, Jito mengoperasikan layanan mem-pool luar protokol kanonikal, yang sekarang sudah usang.

Disclaimer：

1. Artikel ini diambil dari [helius]. Semua hak cipta dimiliki oleh penulis asli [Hilang]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Pintu Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penyangkalan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang telah diterjemahkan dilarang.