Ikhtisar Eksekutif Solana

Pendahuluan

Solana adalah blockchain berkinerja tinggi dan berlatensi rendah yang dikenal berkat kecepatan, efisiensi, dan fokusnya pada pengalaman pengguna. Arsitektur terintegrasinya yang unik memungkinkan ribuan transaksi per detik di seluruh jaringan yang terdesentralisasi secara global. Dengan waktu blok 400 milidetik dan biaya transaksi yang hanya sepersekian sen, Solana menghadirkan kecepatan sekaligus efisiensi biaya. Laporan ini mengulas secara mendalam seluk-beluk desain dan pengoperasian Solana serta menjelajahi mekanisme utama dan topologi jaringan yang mendukung kemampuannya.

Solana menerapkan pendekatan terintegrasi pada pengembangan blockchain dengan memanfaatkan pengalaman tim pendirinya selama puluhan tahun dalam membangun sistem terdistribusi. Salah satu prinsip inti Solana adalah bahwa perangkat lunak tidak boleh menghambat perangkat keras. Artinya, perangkat lunak memanfaatkan semaksimal mungkin perangkat keras tempatnya berjalan dan berkembang seiring dengannya. Sebagai ekosistem terpadu, semua aplikasi yang dibangun di atas blockchain tunggal ini mewarisi komposabilitas sehingga dapat berinteraksi dan saling dikembangkan dengan lancar. Arsitektur ini juga memastikan pengalaman pengguna yang mudah dan intuitif tanpa memerlukan bridging, ID chain terpisah, atau fragmentasi likuiditas.

Solana berkembang pesat, dengan perkembangan terbaru yang mencakup rollup SVM dan ZK Compression sebagai solusi penskalaan penting. Meskipun proyek-proyek ini suatu hari nanti mungkin membentuk persepsi kita tentang Solana, saat ini proyek tersebut masih berada pada tahap pengembangan atau adopsi yang sangat awal dan tidak akan dibahas dalam laporan ini.

Siklus Hidup Transaksi

Sudut pandang utama yang akan digunakan untuk memahami Solana dalam laporan ini adalah siklus hidup transaksi pada umumnya. Untuk menyusun model dasar guna memahami transaksi Solana, kita dapat menguraikan prosesnya sebagai berikut: 

• Pengguna memulai transaksi, yang semuanya dikirim ke produsen blok utama saat ini (disebut leader). Leader menyusun transaksi ini menjadi sebuah blok, mengeksekusinya, lalu memperbarui state lokalnya.
• Blok transaksi ini kemudian disebarkan ke seluruh jaringan agar validator lain dapat mengeksekusi dan mengonfirmasinya.‍

Bagian-bagian berikutnya dalam laporan ini akan memperluas model tersebut dan mengulas proses ini dengan jauh lebih terperinci, dimulai dari peserta utama—para pengguna.

Enam Tahap

Sepanjang laporan ini, kami akan merujuk visual enam tahap di atas karena visual tersebut menyediakan kerangka kerja yang konsisten untuk memahami hubungan antara elemen-elemen inti Solana.

Bab-bab awal disusun berdasarkan enam tahap ini. Bab-bab terakhir—Gossip, Arsip, Ekonomi, dan Jito—menuntaskan pembahasan yang tersisa. Perlu diperhatikan bahwa beberapa bab mencakup beberapa tahap dan beberapa tahap akan muncul dalam beberapa bab.

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

Pengguna

Perjalanan pengguna biasanya dimulai dengan menyiapkan dan mengisi dana ke aplikasi dompet. Berbagai aplikasi dompet populer tersedia untuk Solana, baik sebagai aplikasi seluler native maupun ekstensi browser.

Dompet menghasilkan pasangan kunci pengguna secara kriptografis, yang terdiri dari kunci publik dan privat. Kunci publik berfungsi sebagai pengenal unik untuk account mereka dan diketahui oleh semua peserta di jaringan. Account pengguna di Solana dapat dianggap sebagai struktur data yang menyimpan informasi dan state terkait interaksi mereka dengan blockchain Solana. Dengan demikian, kunci publik menyerupai nama file: seperti nama file yang secara unik mengidentifikasi file dalam sistem file, kunci publik Solana secara unik mengidentifikasi account di blockchain Solana. Kunci publik di Solana direpresentasikan sebagai string 32 byte yang dikodekan dengan Base58.

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

Kunci privat—yang juga dikenal sebagai kunci rahasia—dapat dianggap sebagai kata sandi atau kunci akses yang memberikan izin untuk mengakses dan mengubah account. Penandatanganan dengan kunci privat adalah cara blockchain menangani otorisasi. Siapa pun yang mengetahui kunci privat memiliki kendali mutlak atas account tersebut. Kunci privat Solana juga memiliki panjang 32 byte. Pasangan kunci merupakan kombinasi 64 byte dari kunci publik (paruh pertama) dan privat (paruh 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 seed mnemonik, yang biasanya terdiri dari 12 atau 24 kata. Format ini sering digunakan dalam dompet agar pencadangan dan pemulihan lebih mudah. Beberapa kunci dapat diturunkan secara deterministik dari satu frasa seed.

Solana menggunakan Ed25519, algoritma tanda tangan digital kurva eliptik yang banyak digunakan, untuk kebutuhan kriptografi kunci publiknya. Ed25519 dipilih karena ukuran kunci dan tanda tangannya yang kecil, komputasinya yang cepat, serta ketahanannya terhadap banyak serangan umum. Setiap alamat dompet Solana merepresentasikan sebuah titik pada kurva eliptik Ed25519.

Pengguna menandatangani transaksi dengan kunci privatnya. Tanda tangan ini disertakan bersama data transaksi dan dapat diverifikasi oleh peserta lain menggunakan kunci publik pengirim. Proses ini memastikan bahwa transaksi tidak dimanipulasi dan telah diotorisasi oleh pemilik kunci privat yang sesuai. Tanda tangan tersebut juga berfungsi sebagai pengenal unik untuk transaksi.

Transaksi Solana‍

Mengirim transaksi adalah satu-satunya cara untuk mengubah state di Solana. Setiap operasi tulis dilakukan melalui transaksi, dan transaksi bersifat atomik—semua tindakan yang dicoba oleh transaksi akan terjadi atau transaksi akan gagal. Transaksi, yang secara lebih formal dikenal sebagai "pesan transaksi", terdiri dari empat bagian: header, daftar alamat account, blockhash terbaru, dan instruksi.

Header

Header berisi referensi ke daftar alamat account, yang menunjukkan account mana saja yang harus menandatangani transaksi.

Alamat Account

Daftar ini mencakup semua account yang akan dibaca atau ditulis selama transaksi. Menyusun daftar seperti ini untuk setiap transaksi merupakan persyaratan unik Solana dan dapat menjadi tantangan bagi developer. Namun, mengetahui sebelumnya bagian state mana yang akan berinteraksi dengan transaksi memungkinkan pengoptimalan yang tidak tersedia di banyak blockchain lain.

Blockhash Terbaru

Ini digunakan untuk mencegah transaksi duplikat dan kedaluwarsa. Blockhash terbaru kedaluwarsa setelah 150 blok (sekitar 1 menit). Secara default, RPC mencoba meneruskan transaksi setiap 2 detik hingga transaksi diselesaikan atau blockhash terbaru kedaluwarsa. Setelah itu, transaksi dibatalkan.

Instruksi

Instruksi merupakan bagian inti transaksi. Setiap instruksi merepresentasikan operasi tertentu (misalnya transfer, mint, burn, membuat account, atau menutup account). Setiap instruksi menentukan program yang akan dieksekusi, account yang diperlukan, dan data yang dibutuhkan untuk menjalankan instruksi tersebut.

Jumlah instruksi dalam suatu transaksi pertama-tama dibatasi oleh ukurannya, yang dapat mencapai 1.232 byte. Jumlah account yang dapat dirujuk juga dibatasi. Terakhir, kompleksitas transaksi dibatasi berdasarkan unit komputasi (CU). CU mengukur sumber daya komputasi yang digunakan untuk memproses transaksi.

Biaya dalam SOL untuk mengeksekusi transaksi dibagi menjadi 2 bagian—biaya dasar dan biaya prioritas. Biaya dasar ditetapkan sebesar 5.000 lamport per tanda tangan, terlepas dari kompleksitas transaksi. Biasanya, terdapat 1 tanda tangan per transaksi.

Secara teknis, biaya prioritas bersifat opsional, tetapi menjadi penting saat permintaan ruang blok tinggi. Biaya ini dihitung dalam mikro-lamport (sepersejuta lamport) per unit komputasi. Tujuannya adalah menjadi sinyal harga yang membuat penyertaan transaksi dalam blok lebih menarik secara ekonomi bagi node validator. ‍

total fee = prioritization fee + base fee

prioritization fee = compute unit price (micro-lamports) x compute unit limit

Saat ini, 50% dari semua biaya terkait transaksi dibakar sehingga SOL tersebut dihapus secara permanen dari peredaran, sedangkan 50% sisanya diberikan kepada produsen blok. Perubahan baru (SIMD 96) akan segera diperkenalkan agar 100% biaya prioritas dapat diberikan kepada produsen blok. Biaya dasar tetap tidak berubah.

Mengirim Transaksi

Pengguna menghubungkan dompetnya ke aplikasi sehingga aplikasi dapat membaca kunci publik pengguna. Kunci privat tetap dienkripsi dan diisolasi dengan aman dalam lingkungan yang terpisah dari aplikasi.

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

Setelah pesan transaksi siap, pesan tersebut dikirim ke dompet untuk ditandatangani dengan kunci privat pengguna. Pada tahap ini, popup ditampilkan kepada pengguna untuk mengonfirmasi kesediaannya melakukan transaksi. Popup ini dapat menyertakan simulasi hasil transaksi. Setelah ditandatangani, pesan transaksi dan tanda tangan dikembalikan ke aplikasi. Aplikasi kemudian dapat meneruskan transaksi ke penyedia RPC pilihan, baik milik sendiri maupun penyedia yang digunakan oleh dompet.

Penyedia RPC (Remote Procedure Call) bertindak sebagai perantara antara aplikasi dan validator yang membangun blok. Penyedia ini merupakan layanan penting yang memungkinkan aplikasi mengirimkan atau menyimulasikan transaksi yang telah ditandatangani serta mengambil data on-chain secara efisien. Aplikasi berinteraksi dengan jaringan melalui endpoint JSON-RPC atau WebSocket (dokumentasi).

Gulf Stream

RPC (Remote Procedure Call) merujuk pada node RPC. Node ini dapat dianggap sebagai gateway untuk berinteraksi dengan jaringan dan membaca data darinya. Node RPC menjalankan perangkat lunak yang sama seperti validator penuh, tetapi dengan pengaturan berbeda, sehingga dapat menyimulasikan transaksi secara akurat dan mempertahankan tampilan state terkini. Saat tulisan ini dibuat, terdapat lebih dari 4.000 node RPC di jaringan Solana.

Berbeda dengan node validator penuh, node RPC tidak memiliki stake di jaringan. Tanpa stake, node tersebut tidak dapat memberikan suara atau membangun blok. Konfigurasi ini berbeda dari sebagian besar blockchain lain, yang biasanya menggunakan node yang sama sebagai validator dan RPC. Karena node RPC tidak menerima imbalan staking, aspek ekonomi dalam menjalankan node RPC berbeda dari validator. Banyak node RPC dioperasikan sebagai layanan berbayar bagi developer yang menjalankan aplikasi Solana.

Solana berbeda karena sejak awal dirancang untuk beroperasi tanpa mempool. Tidak seperti blockchain tradisional yang menggunakan protokol gossip untuk menyebarkan transaksi secara acak dan luas di seluruh jaringan, Solana meneruskan semua transaksi kepada validator utama yang telah ditentukan, yang disebut leader, untuk setiap slot.

Setelah RPC menerima pesan transaksi untuk disertakan dalam blok, pesan tersebut harus diteruskan kepada leader. Jadwal leader dibuat sebelum setiap epoch (sekitar dua hari sekali). Epoch berikutnya dibagi menjadi slot yang masing-masing memiliki durasi tetap 400 milidetik, dan satu leader dipilih untuk setiap slot. Validator dengan stake lebih besar akan lebih sering dipilih menjadi leader dalam setiap epoch. Selama setiap slot, pesan transaksi diteruskan kepada leader, yang berkesempatan memproduksi blok. Saat giliran validator tiba, validator beralih ke "mode leader", mulai memproses transaksi secara aktif, dan menyiarkan blok ke seluruh jaringan.

Kualitas Layanan Berbobot Stake - SWQoS

Pada awal 2024, Solana memperkenalkan mekanisme baru untuk mencegah spam dan meningkatkan ketahanan terhadap Sybil, yang disebut Stake-Weighted Quality of Service (SWQoS). Sistem ini memungkinkan leader memprioritaskan pesan transaksi yang diteruskan melalui validator lain yang memiliki stake. Dalam sistem ini, validator dengan stake lebih besar memperoleh kapasitas yang secara proporsional lebih tinggi untuk mengirimkan paket pesan transaksi kepada leader. Pendekatan ini secara efektif memitigasi serangan Sybil dari node tanpa stake di seluruh jaringan.

‍Dalam model ini, validator juga dapat membuat perjanjian untuk menyewakan kapasitas berbobot stake kepada node RPC. Sebagai imbalannya, node RPC memperoleh bandwidth lebih besar sehingga dapat meningkatkan tingkat penyertaan transaksi dalam blok. Sebanyak 80% kapasitas leader (2.000 koneksi) dicadangkan untuk SWQoS. Sisa 20% (500 koneksi) dialokasikan untuk pesan transaksi dari node tanpa stake. Strategi alokasi ini menyerupai jalur prioritas di jalan raya, tempat pengemudi membayar tol untuk menghindari kemacetan.

SWQoS memengaruhi ekosistem Solana dengan meningkatkan persyaratan untuk meneruskan transaksi kepada leader dan mengurangi efektivitas serangan spam. Perubahan ini mendorong aplikasi dengan lalu lintas tinggi untuk mengintegrasikan operasinya secara vertikal. Dengan menjalankan node validator sendiri atau mengakses koneksi yang memiliki stake, aplikasi dapat memastikan akses istimewa kepada leader sehingga meningkatkan kemampuan pemrosesan transaksinya.

Catatan tentang QUIC

Pada akhir 2022, Solana mengadopsi protokol jaringan QUIC untuk mengelola pengiriman pesan transaksi kepada leader. Transisi ini dipicu oleh gangguan jaringan akibat bot yang membanjiri proses mint NFT on-chain dengan spam. QUIC memfasilitasi komunikasi asinkron berkecepatan tinggi.

‍QUIC awalnya dikembangkan oleh Google pada 2012 dan berupaya menawarkan keunggulan dari kedua pendekatan. QUIC memfasilitasi komunikasi asinkron berkecepatan tinggi seperti UDP, tetapi dengan sesi aman dan strategi kontrol aliran canggih milik TCP. Dengan demikian, batas dapat diterapkan pada setiap sumber lalu lintas agar jaringan dapat berfokus memproses transaksi yang valid. QUIC juga memiliki konsep stream terpisah. Jadi, jika satu transaksi dibatalkan, transaksi tersebut tidak perlu memblokir transaksi lainnya. Singkatnya, QUIC dapat dianggap sebagai upaya menggabungkan karakteristik terbaik TCP dan UDP.

Pembangunan Blok

Banyak jaringan blockchain menyusun seluruh blok sebelum menyiarkannya, yang disebut pembangunan blok diskret. Sebaliknya, Solana menggunakan pembangunan blok berkelanjutan dengan menyusun dan mengalirkan blok secara dinamis saat dibuat dalam slot waktu yang dialokasikan. Pendekatan ini secara signifikan mengurangi latensi.

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

Dua slot sebelum mengambil alih kepemimpinan, validator menghentikan penerusan transaksi untuk mempersiapkan beban kerja yang akan datang. Selama interval ini, lalu lintas masuk melonjak hingga lebih dari satu gigabyte per detik karena seluruh jaringan mengarahkan paket kepada leader yang akan bertugas.

Setelah diterima, pesan transaksi memasuki Transaction Processing Unit (TPU), yaitu logika inti validator yang bertanggung jawab atas produksi blok. Di sini, urutan pemrosesan transaksi dimulai dengan Fetch Stage, tempat transaksi diterima melalui QUIC. Selanjutnya, transaksi diteruskan ke SigVerify Stage untuk menjalani pemeriksaan validasi yang ketat. Pada tahap ini, validator memverifikasi keabsahan tanda tangan, memeriksa jumlah tanda tangan yang benar, dan menghapus transaksi duplikat.

‍Banking Stage

Banking stage dapat digambarkan sebagai tahap pembangunan blok. Ini merupakan tahap terpenting dalam TPU dan namanya berasal dari “bank”. Bank hanyalah state pada blok tertentu. Untuk setiap blok, Solana memiliki bank yang digunakan untuk mengakses state pada blok tersebut. Ketika blok difinalisasi setelah mendapatkan cukup suara dari validator, pembaruan account akan dikeluarkan dari bank dan ditulis ke disk sehingga menjadi permanen. State akhir chain merupakan hasil dari semua transaksi yang telah dikonfirmasi. State ini selalu dapat dibuat ulang secara deterministik dari riwayat blockchain.‍

Transaksi diproses secara paralel dan dikemas menjadi “entri” ledger, yaitu batch berisi 64 transaksi yang tidak saling berkonflik. Pemrosesan transaksi secara paralel di Solana dimudahkan karena setiap transaksi wajib menyertakan daftar lengkap semua account yang akan dibaca dan ditulis. Keputusan desain ini membebani developer, tetapi memungkinkan validator menghindari race condition dengan mudah memilih transaksi yang tidak saling berkonflik untuk dieksekusi dalam setiap entri. Transaksi berkonflik jika keduanya mencoba menulis ke account yang sama (dua penulisan), atau jika satu transaksi mencoba membaca dan transaksi lainnya menulis ke account yang sama (baca + tulis). Karena itu, transaksi yang berkonflik dimasukkan ke entri berbeda dan dieksekusi secara berurutan, sedangkan transaksi yang tidak berkonflik dieksekusi secara paralel.

Terdapat enam thread yang memproses transaksi secara paralel, dengan empat thread dikhususkan untuk transaksi biasa dan dua lainnya secara eksklusif menangani transaksi voting yang menjadi bagian integral dari mekanisme konsensus Solana. Seluruh paralelisasi pemrosesan dilakukan melalui beberapa core CPU. Validator tidak memerlukan GPU (dokumentasi).‍

Setelah transaksi dikelompokkan menjadi entri, transaksi siap dieksekusi oleh Solana Virtual Machine (SVM). Account yang diperlukan untuk transaksi dikunci. Pemeriksaan dilakukan untuk memastikan transaksi masih baru dan belum pernah diproses. Account dimuat, lalu logika transaksi dieksekusi sehingga memperbarui state account. Hash entri akan dikirim ke layanan Proof of History untuk dicatat (selengkapnya di bagian berikutnya). Jika proses pencatatan berhasil, semua perubahan akan diterapkan ke bank dan kunci pada setiap account yang dipasang pada langkah pertama akan dilepas. Eksekusi dilakukan oleh SVM, mesin virtual yang dibuat menggunakan fork Solana dari rBPF, yaitu library untuk bekerja dengan kompilasi JIT dan mesin virtual bagi program eBPF. Perlu diperhatikan bahwa Solana tidak menentukan cara validator mengurutkan transaksi dalam suatu blok. Fleksibilitas ini merupakan poin penting yang akan dibahas kembali nanti dalam bagian Ekonomi + Jito pada laporan ini.‍

Client

Solana adalah jaringan yang terdiri dari ribuan node yang dioperasikan secara independen dan bekerja sama untuk mempertahankan satu ledger terpadu. Setiap node merupakan mesin berkinerja tinggi yang menjalankan perangkat lunak sumber terbuka yang sama, yang disebut “client”.

Solana diluncurkan dengan satu perangkat lunak client validator—awalnya bernama client Solana Labs dan kini dikenal sebagai client Agave —yang ditulis dalam Rust. Sejak saat itu, memperluas keragaman client menjadi prioritas dan akan benar-benar terwujud dengan peluncuran client Firedancer. Firedancer adalah penulisan ulang menyeluruh dari awal terhadap client asli dalam bahasa pemrograman C. Dibangun oleh tim berpengalaman dari perusahaan perdagangan berfrekuensi tinggi Jump, Firedancer diproyeksikan menjadi client validator dengan performa tertinggi di antara semua blockchain.

Proof of History

Proof of History (PoH) adalah resep rahasia Solana yang berfungsi seperti jam khusus di setiap validator untuk memfasilitasi sinkronisasi di seluruh jaringan. PoH menetapkan sumber kebenaran yang andal untuk urutan peristiwa dan berlalunya waktu. Yang paling penting, PoH memastikan jadwal pemimpin dipatuhi. Meski namanya mirip, Proof of History bukanlah algoritma konsensus seperti Proof of Work.

‍Overhead komunikasi antar-node biasanya meningkat seiring jaringan berkembang, dan koordinasi menjadi makin rumit. Solana mengatasinya dengan mengganti komunikasi antar-node dengan komputasi PoH lokal. Artinya, validator dapat melakukan commit pada sebuah blok hanya dengan satu putaran pemungutan suara. Stempel waktu tepercaya dalam pesan memastikan validator tidak saling mendahului dan memulai bloknya terlalu dini.

PoH didasari oleh sifat unik algoritma hashing, khususnya SHA256:

• Deterministik: Input yang sama akan selalu menghasilkan hash yang sama.
• Ukuran Tetap: Berapa pun ukuran inputnya, hash output selalu berukuran 256 bit.
• Efisien: Hash untuk input apa pun dapat dihitung dengan cepat.
• Ketahanan Preimage: Menemukan input asli dari output hash tidak layak dilakukan secara komputasional.
• Efek Longsoran: Perubahan kecil pada input, bahkan hanya satu bit, menghasilkan hash yang sangat berbeda. Sifat ini dikenal sebagai efek longsoran.
• Ketahanan Tabrakan: Menemukan dua input berbeda yang menghasilkan output hash yang sama tidak layak dilakukan.

Di dalam setiap klien validator, sebuah "layanan Proof of History" khusus terus menjalankan algoritma hash SHA256 untuk membuat rantai hash. Input setiap hash adalah output hash sebelumnya. Rantai ini berfungsi seperti fungsi penundaan yang dapat diverifikasi karena proses hashing harus dilakukan secara berurutan dan hasil hash mendatang tidak dapat diketahui sebelumnya. Jika layanan PoH membuat rantai berisi seribu hash, kita tahu waktu telah berlalu untuk menghitung setiap hash secara berurutan—hal ini dapat dianggap sebagai “proof of work mikro.” Namun, validator lain dapat memverifikasi kebenaran seribu hash tersebut secara paralel dengan jauh lebih cepat daripada waktu pembuatannya karena input dan output setiap hash telah disiarkan ke jaringan. Karena itu, PoH sulit dibuat tetapi mudah diverifikasi.

Rentang performa komputasi SHA-256 di berbagai CPU ternyata sangat sempit, dengan perbedaan kecil saja di antara mesin tercepat. Batas atas yang umum telah tercapai meskipun banyak waktu dan upaya telah diinvestasikan untuk mengoptimalkan fungsi ini, terutama karena Bitcoin mengandalkannya.

‍Selama slot seorang pemimpin, layanan PoH akan menerima entri yang baru diproses dari tahap banking. Hash PoH saat ini dan hash dari semua transaksi dalam entri digabungkan menjadi hash PoH berikutnya. Hash ini berfungsi sebagai stempel waktu yang memasukkan entri ke dalam rantai hash, sekaligus membuktikan urutan pemrosesan transaksi. Proses ini tidak hanya mengonfirmasi berlalunya waktu, tetapi juga berfungsi sebagai catatan kriptografis transaksi.

Dalam satu blok terdapat 800.000 hash. Stream PoH juga mencakup "tick", yaitu entri kosong yang menunjukkan bahwa pemimpin masih aktif dan menandai berlalunya waktu dalam kisaran sebagian kecil detik. Satu tick terjadi setiap 6,25 milidetik sehingga menghasilkan 64 tick per blok dan total waktu blok 400 milidetik.

Validator terus menjalankan jam PoH meskipun sedang tidak menjadi pemimpin karena jam ini berperan penting dalam proses sinkronisasi antar-node.

Model Akun

Di dalam validator Solana, state global dipertahankan dalam basis data akun yang dikenal sebagai AccountsDB. Basis data ini bertanggung jawab menyimpan semua akun, baik di memori maupun disk. Struktur data utama dalam indeks akun adalah hashmap, sehingga AccountsDB pada dasarnya merupakan penyimpanan nilai-kunci yang sangat besar. Di sini, kuncinya adalah alamat akun dan nilainya adalah data akun.

Seiring waktu, jumlah akun Solana melonjak hingga ratusan juta. Jumlah yang besar ini antara lain disebabkan oleh ungkapan yang disukai para developer Solana, "Semua yang ada di Solana adalah akun!"

Akun Solana

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

• Akun pengguna: Akun ini memiliki kunci privat dan biasanya dibuat oleh perangkat lunak dompet untuk pengguna.
• Akun data: Akun ini menyimpan informasi state, seperti jumlah token tertentu yang dimiliki pengguna.
• Akun program: Ini adalah akun lebih besar yang berisi bytecode yang dapat dieksekusi, kurang lebih setara dengan file .exe di Windows atau file .app di Mac.
• Akun program native: Ini adalah akun program khusus yang telah diterapkan sebelumnya dan menjalankan berbagai fungsi inti jaringan. Contohnya mencakup Vote Program dan BPF Loader.

Semua akun memiliki kolom berikut:

Program‍

Akun program Solana hanya berisi logika yang dapat dieksekusi. Artinya, saat dijalankan, program mengubah state akun lain tetapi dirinya sendiri tidak berubah. Pemisahan kode dan state ini membedakan Solana dari blockchain lain serta mendukung banyak pengoptimalannya. Developer terutama menulis program ini dalam Rust, bahasa pemrograman serbaguna yang dikenal sangat mengutamakan keamanan dan performa. Selain itu, tersedia beberapa SDK dalam TypeScript dan Python untuk memudahkan pembuatan front-end aplikasi serta memungkinkan interaksi terprogram dengan jaringan.

Banyak fungsi umum telah disediakan langsung oleh program native. Sebagai contoh, Solana tidak mengharuskan developer menerapkan kode untuk membuat token. Sebaliknya, instruksi dikirim ke program native yang telah diterapkan sebelumnya. Program tersebut akan menyiapkan akun untuk menyimpan metadata token, sehingga secara efektif membuat token baru.

Sewa

Sewa adalah mekanisme yang dirancang untuk mendorong pengguna menutup akun dan mengurangi pembengkakan state. Untuk membuat akun baru, akun tersebut harus menyimpan saldo minimum SOL yang dikenal sebagai jumlah "bebas sewa". Jumlah ini dapat dianggap sebagai biaya penyimpanan untuk mempertahankan akun di memori validator. Jika ukuran data akun bertambah, persyaratan saldo minimum sewanya meningkat secara proporsional. Saat akun tidak lagi diperlukan, akun tersebut dapat ditutup dan sewanya dikembalikan kepada pemilik akun. 

Sebagai contoh, jika pengguna memiliki stablecoin berdenominasi dolar, state ini disimpan dalam akun token. Saat ini, jumlah bebas sewa untuk akun token adalah 0,002 SOL. Jika pengguna mentransfer seluruh saldo stablecoin kepada temannya, akun token dapat ditutup dan pengguna akan menerima kembali 0,002 SOL miliknya. Program sering kali menangani penutupan akun secara otomatis untuk pengguna. Tersedia beberapa aplikasi yang membantu pengguna membersihkan akun lama yang tidak digunakan dan mengambil kembali sejumlah kecil SOL yang tersimpan di dalamnya.

Kepemilikan

Meski data akun dapat dibaca oleh siapa pun, model kepemilikan Solana meningkatkan keamanan dengan membatasi secara tepat siapa yang dapat mengubah atau menulis data akun. Konsep ini sangat penting untuk menegakkan aturan dan izin pada blockchain Solana. Setiap akun memiliki program "pemilik". Pemilik akun bertanggung jawab mengaturnya dan memastikan hanya program yang berwenang yang dapat mengubah data akun. Pengecualian penting untuk aturan ini adalah transfer lamport, yaitu unit terkecil SOL—siapa pun dapat meningkatkan saldo lamport suatu akun, terlepas dari kepemilikannya.

Penyimpanan State

Karena merupakan file executable hanya-baca, program Solana harus menyimpan state menggunakan “Program Derived Addresses” (PDA). PDA adalah jenis akun khusus yang terkait dengan dan dimiliki oleh program, bukan pengguna tertentu. Alamat pengguna Solana biasa berasal dari kunci publik pasangan kunci Ed25519, sedangkan PDA tidak memiliki kunci privat. Sebaliknya, kunci publiknya berasal dari kombinasi parameter—sering kali kata kunci atau alamat akun lain—beserta ID program (alamat) dari program pemiliknya.

Alamat PDA berada "di luar kurva", artinya alamat tersebut tidak berada pada kurva Ed25519 seperti alamat biasa. Hanya program pemilik PDA yang dapat menghasilkan tanda tangan untuknya secara terprogram, sehingga memastikan hanya program tersebut yang dapat mengubah state PDA.

Turbine

Selama tahap banking, transaksi disusun menjadi entri dan dikirim ke stream Proof of History untuk diberi stempel waktu. Bank blok diperbarui, dan entri kini siap untuk fase berikutnya—Turbine.

Turbine adalah proses yang digunakan pemimpin untuk menyebarkan bloknya ke seluruh jaringan. Terinspirasi oleh BitTorrent, Turbine dirancang agar cepat dan efisien, mengurangi overhead komunikasi, serta meminimalkan jumlah data yang perlu dikirim pemimpin.

‍Turbine melakukannya dengan memecah data transaksi menjadi "shred" melalui proses yang disebut "shredding." Shred adalah paket data kecil berukuran hingga 1.280 byte, mirip dengan masing-masing frame dalam stream video. Setelah disusun kembali, shred ini memungkinkan validator memutar ulang seluruh blok. Shred dikirim melalui internet antar-validator menggunakan UDP dan memanfaatkan erasure coding untuk menangani kehilangan paket atau penghapusan paket secara berbahaya. Erasure coding, skema deteksi dan koreksi kesalahan berbasis polinomial, memastikan integritas data. Meskipun beberapa shred hilang, blok tetap dapat direkonstruksi.

Shred dikelompokkan ke dalam batch yang dikenal sebagai batch forward error correction (FEC). Secara default, batch ini terdiri dari 64 shred (32 shred data + 32 shred pemulihan). Pemulihan data dilakukan per batch FEC. Artinya, hingga setengah paket dalam suatu batch dapat hilang atau rusak dan seluruh data masih dapat dipulihkan. Setiap batch berisi 64 shred dibuat menjadi pohon Merkle, dengan root yang ditandatangani pemimpin dan ditautkan ke batch sebelumnya. Proses ini memastikan shred dapat diperoleh dengan aman dari node mana pun di jaringan yang memilikinya karena rantai root Merkle menyediakan jalur keaslian dan integritas yang dapat diverifikasi.

Pemimpin awalnya menyiarkan ke satu node root, yang kemudian menyebarkan shred ke semua node validator lainnya. Node root ini berubah untuk setiap shred. Validator disusun ke dalam beberapa lapisan yang membentuk "Pohon Turbine." Validator dengan stake lebih besar biasanya ditempatkan di bagian atas pohon, sedangkan validator dengan stake lebih rendah ditempatkan di bagian bawah.

‍Pohon ini biasanya mencakup dua atau tiga lompatan, tergantung jumlah validator aktif. Demi kesederhanaan visual, ilustrasi di atas menampilkan fanout sebesar 3, tetapi nilai fanout aktual Solana saat ini ditetapkan sebesar 200. Demi keamanan, urutan pohon dirotasi untuk setiap batch shred baru.

Tujuan utama sistem seperti ini adalah mengurangi tekanan egress data keluar pada pemimpin dan node root. Dengan menggunakan sistem transmisi dan transmisi ulang, beban didistribusikan antara pemimpin dan para retransmitter sehingga mengurangi tekanan pada setiap node individual.

Konsensus

Setelah validator menerima blok baru dari pemimpin melalui Turbine, validator tersebut harus memvalidasi semua transaksi dalam setiap entri. Proses ini mencakup pemutaran ulang seluruh blok, validasi hash PoH secara paralel, pembuatan ulang transaksi sesuai urutan yang ditentukan PoH, dan pembaruan bank lokalnya. 

‍Proses ini ditangani oleh Transaction Validation Unit (TVU), yang serupa dengan Transaction Processing Unit (TPU) milik pemimpin dan berfungsi sebagai logika inti yang bertanggung jawab memproses shred serta memvalidasi blok. Seperti TPU, alur TVU dibagi menjadi beberapa tahap, dimulai dengan Shred Fetch Stage, tempat shred diterima melalui Turbine. Pada Shred Verify Leader Signature Stage berikutnya, shred menjalani beberapa pemeriksaan kewajaran, terutama verifikasi tanda tangan pemimpin yang memastikan shred yang diterima berasal dari pemimpin. ‍

Pada Retransmit Stage, validator meneruskan shred ke validator hilir yang sesuai berdasarkan posisinya di pohon Turbine. Pada Replay Stage, validator membuat ulang setiap transaksi secara persis dan dalam urutan yang benar sambil memperbarui versi lokal banknya.

Replay Stage serupa dengan tahap banking dalam TPU. Ini adalah tahap terpenting dan dapat dijelaskan secara lebih langsung sebagai tahap validasi blok. Replay adalah loop proses single-threaded yang mengorkestrasi banyak operasi utama, termasuk voting, mengatur ulang jam PoH, dan beralih bank. 

Konsensus

Untuk mencapai konsensus, Solana menggunakan Tower BFT (TBFT), implementasi khusus dari algoritma Practical Byzantine Fault Tolerance (PBFT) yang terkenal dan umum digunakan oleh sebagian besar blockchain untuk menyepakati state chain. Seperti semua blockchain, Solana mengasumsikan adanya node berbahaya dalam jaringan. Karena itu, sistem harus mampu bertahan bukan hanya dari kegagalan node, tetapi juga dari serangan pada tingkat tertentu.

Tower BFT membedakan dirinya dari chain lain dengan memanfaatkan jam tersinkronisasi yang disediakan oleh Proof of History. PBFT tradisional memerlukan beberapa putaran komunikasi untuk menyepakati urutan transaksi, sedangkan node Solana memanfaatkan urutan peristiwa yang telah ditetapkan sebelumnya sehingga secara signifikan mengurangi overhead pesan.

Voting

‍Untuk berpartisipasi dalam konsensus dan memperoleh reward, validator mengirimkan suara bagi blok yang mereka yakini valid, yaitu bebas dari masalah seperti double spend atau tanda tangan yang salah, dan layak dianggap kanonis. Validator membayar biaya transaksi untuk suara ini, yang diproses oleh pemimpin dan disertakan dalam blok bersama transaksi pengguna biasa. Inilah alasan transaksi Solana sering dikategorikan sebagai transaksi voting dan non-voting. Saat validator mengirimkan suara yang benar dan berhasil, mereka memperoleh kredit. Mekanisme ini mendorong validator untuk memilih fork yang mereka yakini memiliki peluang terbaik untuk disertakan, yaitu fork “terberat”.

Fork

Salah satu bagian dari desain Solana yang membuatnya sangat cepat adalah jaringan tidak menunggu semua validator menyepakati blok yang baru diproduksi sebelum memproduksi blok berikutnya. Akibatnya, dua blok berbeda cukup sering ditautkan ke blok induk yang sama sehingga menciptakan fork.

Validator Solana harus memberikan suara pada fork ini dan menggunakan algoritma konsensus untuk menentukan fork yang akan diadopsi. Saat terdapat fork yang bersaing, pada akhirnya hanya satu fork yang akan difinalisasi oleh jaringan, sedangkan blok dalam fork yang dibuang akan ditinggalkan.

Setiap slot memiliki pemimpin yang telah ditentukan, dan hanya blok dari pemimpin tersebut yang akan diterima. Tidak boleh ada dua blok yang diusulkan untuk satu slot. Karena itu, jumlah fork potensial terbatas pada daftar lompatan "ada/tidak ada" yang dapat muncul di batas slot rotasi pemimpin. Setelah validator memilih sebuah fork, validator tersebut terikat pada fork ini hingga periode lockout berakhir. Artinya, validator harus mempertahankan pilihannya selama periode minimum tertentu.

‍"Tingkat lompatan" Solana—persentase slot yang tidak menghasilkan blok—bervariasi dari 2% hingga 10%, dengan fork sebagai penyebab utama slot yang dilewati ini. Kemungkinan penyebab lain mencakup dimulainya epoch baru, pemimpin sedang offline, atau produksi blok yang tidak valid.

Ingat:

Status transaksi di Solana bervariasi, tergantung tahapnya saat ini dalam proses konsensus:

• Diproses: Transaksi telah disertakan dalam sebuah blok.
• Dikonfirmasi: Blok transaksi telah memperoleh suara dari supermayoritas dua pertiga.
• Difinalisasi: Lebih dari 31 blok telah dibangun di atas blok transaksi tersebut.

Hingga saat ini, belum pernah ada kejadian dalam sejarah Solana ketika blok yang dikonfirmasi secara optimistis tidak menjadi final.‍

Untuk setiap blok, Solana menggunakan bank guna mengakses state pada blok tersebut. Saat bank difinalisasi, pembaruan akun dari bank tersebut dan para leluhurnya ditulis ke disk. Selain itu, semua pembaruan akun dari bank sebelumnya yang bukan leluhur bank final akan dipangkas. Proses ini memungkinkan Solana mempertahankan beberapa state potensial secara efisien.

Gossip + Arsip

Gossip

Jaringan gossip dapat dianggap sebagai bidang kontrol untuk jaringan Solana. Berbeda dari bidang data yang menangani alur transaksi, bidang kontrol menyebarkan metadata penting mengenai state blockchain, seperti informasi kontak, ketinggian ledger, dan informasi voting. Tanpa gossip, validator dan RPC tidak akan mengetahui alamat serta port yang terbuka untuk komunikasi di berbagai layanan. Node baru juga mengandalkan gossip untuk bergabung dengan jaringan.

Protokol gossip Solana menggunakan komunikasi peer-to-peer informal dengan pendekatan siaran berbentuk pohon yang terinspirasi oleh algoritma PlumTree yang telah dimodifikasi. Metode ini menyebarkan informasi secara efisien tanpa bergantung pada sumber pusat apa pun.

Gossip beroperasi seperti sistem terisolasi yang independen dari sebagian besar komponen validator lainnya. Validator dan RPC membagikan objek data bertanda tangan setiap 0,1 detik melalui UDP menggunakan gossip, sehingga memastikan informasi tersedia di seluruh jaringan. Semua pesan gossip harus berukuran kurang dari atau sama dengan maximum transmission unit (MTU) sebesar 1.280 byte, yang disebut sebagai "packet struct" dalam codebase.

Catatan gossip adalah objek data aktual yang dibagikan antar-node. Terdapat sekitar 10 jenis catatan berbeda yang masing-masing memiliki tujuan berbeda. Catatan gossip ditandatangani, diberi versi, dan diberi stempel waktu untuk memastikan integritas serta keterbaruannya.

Terdapat empat jenis pesan gossip:‍

1. Push: Pesan yang paling umum, membagikan informasi dengan subset "push peer."
2. Pull & Pull Response: Secara berkala memeriksa pesan yang terlewat, dengan respons pull mengirimkan kembali informasi yang belum dimiliki node.
3. Prune: Memungkinkan node mengurangi jumlah koneksi yang dipertahankan secara selektif.
4. Ping & Pong: Pemeriksaan kondisi node—jika ping dikirim, pong diharapkan kembali untuk menunjukkan bahwa node peer masih aktif.

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

Arsip

Solana berbeda dari blockchain lain karena tidak mewajibkan seluruh riwayat untuk menentukan state akun saat ini. Model akun Solana memastikan state pada slot tertentu diketahui sehingga validator dapat menyimpan state setiap akun saat ini tanpa memproses semua blok historis. Sesuai desainnya, RPC dan validator tidak menyimpan seluruh ledger historis. Sebaliknya, keduanya biasanya hanya menyimpan data transaksi untuk 1 atau 2 epoch (2–4 hari), yang cukup untuk memvalidasi ujung chain.

Saat ini, arsip dikelola oleh "node warehouse" yang dioperasikan oleh penyedia layanan RPC profesional, Solana Foundation, dan peserta ekosistem lain yang berkepentingan memastikan riwayat transaksi tersedia. Node warehouse biasanya mempertahankan 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, yang diformat untuk melayani permintaan RPC.

Ekonomi + Jito

Solana menggunakan inflasi untuk mendistribusikan reward staking dengan menghasilkan token SOL baru pada setiap epoch. Proses ini menyebabkan bagian jaringan milik pihak yang tidak melakukan staking menurun dibandingkan pihak yang melakukan staking, sehingga terjadi transfer kekayaan dari non-staker kepada staker. Inflasi dimulai pada awal 2021 dengan tingkat awal 8%, yang menurun 15% setiap tahun hingga stabil pada tingkat jangka panjang sebesar 1,5%.

‍Setiap pemegang token SOL dapat memperoleh reward dan membantu mengamankan jaringan dengan melakukan staking token ke satu atau beberapa validator. Menetapkan token ke validator dikenal sebagai delegasi. Mendelegasikan token kepada validator menunjukkan kepercayaan kepada validator tersebut. Namun, tindakan ini tidak memberikan kepemilikan atau kendali atas token kepada validator. Semua tindakan staking, unstaking, dan delegasi dijalankan pada awal epoch baru berikutnya.

Reward Voting

‍Saat validator mengirimkan suara, mereka memperoleh kredit jika suara tersebut akurat dan berhasil. Transaksi voting berbiaya 0,000005 SOL dan dibebaskan dari biaya prioritas. Biaya voting mencapai sekitar 1 SOL per hari per validator sehingga menjadi biaya operasional utama untuk menjalankan validator. Sepanjang epoch, validator mengumpulkan kredit dari voting yang dapat ditukar dengan bagian inflasi pada akhir epoch.

Validator dengan performa terbaik berhasil memberikan suara pada sekitar 90% slot. Perhatikan bahwa persentase slot tanpa blok (tingkat slot yang dilewati) berkisar antara 2% hingga lebih dari 10%, dan slot tersebut tidak dapat diberi suara. Rata-rata validator berhasil memberikan suara pada sekitar 80% slot dan memperoleh 345.600 kredit dalam satu epoch yang berisi 432.000 slot.

Total kumpulan inflasi pertama-tama dibagi berdasarkan kredit yang diperoleh selama epoch. Bagian validator dari total kredit, yaitu kredit mereka dibagi jumlah kredit semua validator, menentukan reward proporsionalnya. Nilai ini kemudian diberi bobot berdasarkan stake.

Karena itu, validator dengan 1% dari total stake seharusnya memperoleh sekitar 1% dari total inflasi jika memiliki jumlah kredit rata-rata. Jika jumlah kreditnya berada di atas atau di bawah rata-rata, reward akan berfluktuasi sesuai kondisi tersebut.‍

Perbedaan performa voting adalah salah satu alasan imbal hasil yang ditawarkan validator kepada staker, yang diukur dalam APY, bervariasi. Faktor lainnya adalah tingkat komisi yang dikenakan validator, yaitu persentase dari total reward inflasi yang diarahkan kepada validator mereka. Selain itu, kondisi validator yang offline atau tidak sinkron dengan blockchain, yang dikenal sebagai delinquency, berdampak signifikan terhadap imbal hasil.

Reward blok

Validator yang ditetapkan sebagai pemimpin untuk blok tertentu menerima reward blok tambahan. Reward ini mencakup 50% biaya dasar dan 50% biaya prioritas dari semua transaksi dalam blok, sedangkan biaya sisanya dibakar. Hanya validator yang memproduksi blok tersebut yang menerima reward ini. Berbeda dari reward staking yang didistribusikan per epoch, reward blok langsung dikreditkan ke akun identitas validator saat blok diproduksi.

Liquid staking

Liquid staking telah menjadi alternatif populer untuk staking native. Peserta menerima token yang dikenal sebagai Liquid Staking Token (LST) atau Liquid Staking Derivative (LSD) sebagai imbalan atas staking SOL mereka, biasanya dalam stake pool yang mendelegasikan token ke beberapa validator. Token LST yang baru diterima mewakili bagian pengguna dari SOL yang di-staking. Token ini dapat diperdagangkan, digunakan di berbagai aplikasi, atau ditransfer kepada orang lain sambil tetap menghasilkan reward staking. Keunggulan utama sistem ini adalah peningkatan efisiensi modal secara signifikan.

Price of LST = (total staked SOL in pool * price of SOL) / total LST minted

Dengan staking native tradisional, staker akan langsung mengakumulasi lebih banyak SOL seiring waktu. Sementara itu, pada liquid staking, reward diinvestasikan kembali ke dalam pool sehingga meningkatkan nilai wajar LST. Selama tersedia mekanisme untuk menukarkan LST dengan SOL yang mendasarinya dan telah di-staking, trader arbitrase akan memastikan harga token tetap rasional.

Jito

Pada saat artikel ini ditulis, lebih dari 80% (sumber) stake di Solana menggunakan perangkat lunak validator klien Jito. Klien ini, yang merupakan fork dari klien Agave asli, memperkenalkan lelang blockspace di luar protokol yang memberikan insentif ekonomi tambahan kepada validator melalui tip. Insentif tambahan ini menjadi faktor utama dalam meluasnya adopsi klien Jito di kalangan validator.

Saat pemimpin menggunakan klien validator Jito, transaksi mereka awalnya diarahkan ke Jito-Relayer. Perangkat lunak sumber terbuka ini berfungsi sebagai router proxy transaksi. Node jaringan lain tidak mengetahui keberadaan Jito-Relayer karena mereka hanya mengirim transaksi ke konfigurasi alamat dan port yang diiklankan pemimpin melalui jaringan gossip sebagai ingress_socket, dengan asumsi bahwa konfigurasi tersebut adalah milik pemimpin.

‍Relayer menahan semua transaksi selama 200 milidetik sebelum meneruskannya kepada pemimpin. Mekanisme "penghambat kecepatan" ini menunda pesan transaksi masuk dan menyediakan jangka waktu singkat untuk mengadakan lelang. Setelah 200 milidetik, relayer secara optimistis melepaskan transaksi tanpa mempertimbangkan hasil lelang.

Lelang blockspace berlangsung secara off-chain melalui Jito Block Engine, sehingga searcher dan aplikasi dapat mengirimkan kelompok transaksi yang dieksekusi secara atomik dan dikenal sebagai bundle. Bundle ini biasanya berisi transaksi sensitif waktu, seperti arbitrase atau likuidasi. Jito mengenakan biaya 5% atas semua tip, dengan tip minimum sebesar 10.000 lamport. Tip beroperasi sepenuhnya di luar protokol, terpisah dari biaya prioritas dan biaya dasar dalam protokol. Sebelumnya, Jito mengoperasikan layanan mempool kanonis di luar protokol yang kini telah dihentikan.