Arsitektur Solana: 8 Inovasi di Balik Kecepatan SOL

Catatan akurasi: Performa jaringan, jumlah validator, biaya, fitur protokol, dukungan wallet, dan integrasi pihak ketiga berubah seiring waktu. Perlakukan angka bertanggal sebagai cuplikan historis dan verifikasi dokumentasi sumber utama saat ini.

Arsitektur Solana umumnya dijelaskan melalui delapan ide desain dari materi teknis awalnya. Beberapa tetap menjadi pusat, sementara yang lain adalah proposal historis atau telah berkembang, sehingga artikel ini membedakan model asli dari klaim implementasi saat ini.

Materi awal Solana mengelompokkan arsitektur menjadi delapan ide yang dimaksudkan untuk mendukung eksekusi throughput tinggi. Performa saat ini, kepemilikan implementasi, komponen perangkat lunak, dan peran organisasi berkembang, sehingga artikel ini memperlakukan pembingkaian “delapan inovasi” sebagai model penjelasan historis alih-alih spesifikasi saat ini yang lengkap.

Poin Penting

Arsitektur Solana dibangun di atas delapan pilar, yang masing-masing memecahkan hambatan performa tertentu:

1. Proof of History (PoH): jam kriptografis yang membubuhkan stempel waktu pada peristiwa sebelum konsensus berjalan
2. Tower BFT: mekanisme konsensus yang menggunakan stempel waktu PoH dalam voting
3. Turbine: propagasi blok yang memecah blok menjadi paket yang lebih kecil
4. Gulf Stream: penerusan transaksi berdasarkan pemimpin yang dijadwalkan
5. Sealevel: runtime eksekusi kontrak pintar paralel
6. Pipelining: pemrosesan transaksi bertahap
7. Cloudbreak: basis data akun yang dirancang untuk akses konkuren
8. Archivers: proposal penyimpanan terdistribusi historis

Catatan performa: TPS teoritis historis, target waktu slot, konfirmasi, finalitas, biaya dasar, dan biaya prioritas adalah pengukuran yang berbeda. Verifikasi metrik terkini yang bertanggal dan metodologi di baliknya.

Pengorbanan jujur: Solana telah mengalami pemadaman jaringan yang terdokumentasi sejak peluncuran mainnet Maret 2020, dan persyaratan perangkat keras validatornya (disarankan RAM 128+ GB) menciptakan tekanan sentralisasi. Ini adalah pengorbanan arsitektural yang diketahui, bukan masalah insidental.

Masalah yang Dibangun untuk Diselesaikan oleh Solana

Blockchain secara tradisional menghadapi kendala mendasar: trilema blockchain, sebuah konsep yang dipopulerkan oleh Vitalik Buterin, yang menyatakan bahwa sebuah jaringan secara bersamaan hanya dapat mencapai maksimal dua dari tiga properti. Properti tersebut adalah skalabilitas (throughput tinggi), keamanan (ketahanan terhadap serangan), dan desentralisasi (kontrol terdistribusi). Anggap saja sebagai segitiga di mana mendorong satu sudut lebih jauh akan selalu menarik dua sudut lainnya ke dalam. Bitcoin memproses ~7 TPS dengan waktu blok 10 menit, memprioritaskan keamanan dan desentralisasi dengan mengorbankan throughput. Ethereum memproses ~15–30 TPS pada lapisan dasarnya sebelum solusi penskalaan ditambahkan, yang juga memprioritaskan keamanan dan desentralisasi.

Anatoly Yakovenko, mantan insinyur sistem terdistribusi di Qualcomm, mendekati kendala ini secara berbeda. Pada November 2017, ia menerbitkan whitepaper berjudul Proof of History: A Clock for Blockchain, yang menjelaskan mekanisme pencatatan waktu kriptografis yang dapat mengurangi beban komunikasi secara drastis dalam algoritma konsensus. Greg Fitzgerald bergabung sebagai salah satu pendiri dan CTO, dan bersama-sama mereka membangun protokol yang menjadi Solana. Solana Labs, perusahaan nirlaba yang mereka dirikan bersama, memimpin pengembangan protokol inti. Solana Foundation, entitas nirlaba terpisah yang berbasis di Jenewa, mendanai hibah ekosistem, program desentralisasi validator, dan inisiatif pendidikan.

Arsitektur delapan pilar Solana dirancang untuk mendorong batas skalabilitas sejauh mungkin dalam batasan trilema tersebut. Desain tersebut secara sengaja menerima persyaratan perangkat keras validator yang lebih tinggi sebagai biaya dari throughput tersebut. Solana tidak menyelesaikan trilema; ia menempati posisi yang sangat agresif pada poros skalabilitas. Pengorbanan tersebut memiliki biaya nyata, yang diperiksa di bagian pengorbanan arsitektural di bawah ini.

Delapan Pilar Arsitektur Solana: Sebuah Gambaran Umum

Pembingkaian delapan bagian historis ini mencakup Proof of History, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak, dan Archivers. Tidak setiap item harus dianggap tetap sebagai subsistem saat ini yang diterapkan secara terpisah, terutama proposal Archivers.

1. Proof of History: rantai hash SHA-256 berurutan yang membuat catatan stempel waktu yang dapat diverifikasi sebelum konsensus berjalan
2. Tower BFT: mekanisme konsensus Byzantine Fault Tolerant yang ditingkatkan PoH yang menggunakan stempel waktu PoH untuk melakukan voting secara efisien
3. Turbine: protokol propagasi blok yang terinspirasi dari BitTorrent yang memecah blok menjadi paket-paket kecil dengan kode penghapusan yang disebut shred
4. Gulf Stream: protokol penerusan transaksi tanpa mempool yang merutekan transaksi langsung ke pemimpin validator mendatang
5. Sealevel: runtime eksekusi kontrak pintar paralel yang menjalankan ribuan program yang tidak bertentangan secara bersamaan
6. Pipelining: sistem Optimasi Validasi Transaksi (TVO) yang memproses transaksi melalui empat tahap perangkat keras konkuren
7. Cloudbreak: basis data akun berskala horizontal menggunakan file yang dipetakan memori untuk mendukung pembacaan dan penulisan konkuren
8. Archivers: proposal historis untuk penyimpanan buku besar terdistribusi menggunakan konsep bukti replikasi

Setiap pilar dibahas secara mendalam pada bagian di bawah ini.

Proof of History (PoH): Mesin Pencatat Waktu Solana

Proof of History (PoH) adalah rantai hash SHA-256 berurutan yang membuat catatan peristiwa yang dapat diverifikasi dan terurut waktu sebelum konsensus berjalan, bertindak sebagai jam kriptografis bersama untuk seluruh jaringan. PoH bukanlah mekanisme konsensus Solana; peran itu milik Tower BFT. PoH adalah lapisan pencatat waktu yang membuat Tower BFT cepat.

Bayangkan PoH sebagai stopwatch kriptografis yang membuktikan berapa banyak waktu yang telah berlalu di antara peristiwa, tanpa mengharuskan setiap validator di jaringan untuk memeriksa jam satu sama lain terlebih dahulu. Dalam jaringan blockchain tradisional, validator harus bertukar pesan stempel waktu satu sama lain selama setiap putaran konsensus, menambahkan beban komunikasi yang tumbuh seiring dengan ukuran set validator. PoH menghilangkan pertukaran itu sepenuhnya.

Secara teknis, PoH adalah rantai hash SHA-256 berurutan di mana setiap output menjadi input untuk komputasi berikutnya. Karena SHA-256 tidak dapat diparalelkan dalam bentuk rantai ini, panjang rantai tersebut adalah catatan waktu yang telah berlalu yang tahan gangguan. Seorang validator yang menghasilkan rantai N hash telah terbukti menghabiskan waktu yang diperlukan untuk menghitung N operasi hash berurutan. Tidak ada jalan pintas. Anatoly Yakovenko pertama kali menjelaskan mekanisme ini dalam whitepaper November 2017-nya, Proof of History: A Clock for Blockchain.

PoH berfungsi sebagai Fungsi Penundaan yang Dapat Diverifikasi (VDF): komputasi yang membutuhkan waktu komputasi sekuensial yang dapat diprediksi tetapi dapat diverifikasi hampir seketika. Asimetri antara waktu komputasi dan waktu verifikasi inilah yang membuat PoH praktis. Validator dapat menyiarkan output PoH dan pengamat mana pun dapat memverifikasi autentisitasnya dalam hitungan mikrodetik, meskipun untuk menghasilkannya membutuhkan waktu berlalu yang nyata. Ini adalah properti yang akan dikenali oleh peneliti akademik dan analis protokol sebagai landasan teoretis untuk properti keamanan PoH.

Dengan menetapkan referensi pengurutan yang dapat diverifikasi, PoH dapat mengurangi beberapa koordinasi waktu. Ini tidak menghilangkan pesan konsensus atau secara langsung menjamin slot, konfirmasi, atau waktu finalitas tertentu.

Klarifikasi penting: Solana terkadang digambarkan sebagai "blockchain Proof of History", menyiratkan PoH menggantikan Proof of Stake (PoS). Ini salah. Solana adalah blockchain Proof of Stake pada lapisan keamanan ekonominya. Validator mempertaruhkan SOL sebagai jaminan dan menghadapi slashing untuk perilaku tidak jujur. PoH adalah jam kriptografis yang membuat mekanisme konsensus PoS Solana, yang diimplementasikan melalui Tower BFT, lebih cepat dan efisien. Kedua lapisan diperlukan; tidak ada yang menggantikan yang lain.

Tower BFT: Mekanisme Konsensus Solana

Tower BFT adalah mekanisme konsensus Solana: varian yang ditingkatkan PoH dari Practical Byzantine Fault Tolerance (pBFT) yang menggunakan catatan stempel waktu PoH sebagai jam bersama, memungkinkan validator untuk memberikan suara pada status ledger tanpa bertukar pesan sinkronisasi jam.

Byzantine Fault Tolerance (BFT) menjelaskan properti sistem terdistribusi yang memungkinkannya mencapai konsensus dengan benar bahkan ketika beberapa peserta berperilaku jahat atau tidak terduga, dinamai dari masalah Byzantine Generals dalam komputasi terdistribusi. Algoritma pBFT tradisional membutuhkan pertukaran pesan yang ekstensif antar node untuk menetapkan pandangan waktu yang sama, yang membuatnya tidak praktis dalam skala besar. Tower BFT menggantikan catatan PoH untuk pertukaran pesan tersebut. Validator sudah berbagi jam PoH; mereka tidak perlu menegosiasikan stempel waktu.

Validator adalah peserta jaringan yang mempertaruhkan SOL, memvalidasi transaksi, menghasilkan blok ketika dipilih sebagai pemimpin, dan memberikan suara pada status ledger. Mereka memberikan suara yang terkunci waktu dan tumbuh secara eksponensial pada fork. Semakin lama validator memberikan suara pada fork tertentu, semakin banyak SOL yang berisiko hilang melalui slashing (mekanisme penalti yang menghapus token yang dipertaruhkan untuk perilaku tidak jujur atau tidak konsisten) jika fork tersebut ditinggalkan. Mekanisme penguncian suara ini menciptakan insentif ekonomi yang kuat untuk partisipasi yang jujur tanpa memerlukan putaran komunikasi tambahan.

Tower BFT mentolerir hingga sepertiga dari kumpulan validator yang berperilaku Byzantine. Jika kurang dari sepertiga validator bertindak jahat, jaringan mencapai konsensus yang benar. Ambang batas ini berasal dari persyaratan matematis dari masalah Byzantine Generals, yang awalnya diformalkan oleh Lamport, Shostak, dan Pease pada tahun 1982. Garis keturunan konsensus untuk peneliti: pBFT (Castro dan Liskov, 1999) menetapkan algoritma dasar; varian selanjutnya termasuk HotStuff dan Tendermint meningkatkannya; Tower BFT (2017) mengambil langkah lebih lanjut untuk menghilangkan overhead sinkronisasi jam melalui PoH.

Waktu slot target tidak boleh disajikan sebagai jaminan finalitas. Aplikasi harus membedakan tingkat komitmen yang diproses, dikonfirmasi, dan final, serta memilih aturan konfirmasi berdasarkan model risiko mereka.

Turbine: Propagasi Blok dalam Skala Besar

Menyiarkan blok penuh ke setiap validator pada 65.000 TPS teoretis akan menciptakan hambatan bandwidth yang tumbuh secara linier dengan ukuran jaringan. Turbine memecahkan ini dengan cara yang sama seperti BitTorrent memecahkan distribusi file besar: dengan memecah data menjadi bagian-bagian kecil dan menyebarkan beban propagasi ke seluruh jaringan.

Turbine adalah protokol propagasi blok Solana, terinspirasi oleh model distribusi berbasis bagian BitTorrent. Alih-alih satu pemimpin menyiarkan blok lengkap ke setiap validator secara bersamaan, Turbine memecah blok menjadi paket-paket kecil yang dikodekan penghapusan yang disebut shred dan mendistribusikannya melalui jaringan validator yang terstruktur seperti pohon.

Shred dikodekan penghapusan untuk redundansi. Setiap node dalam pohon propagasi menerima subset shred, mentransmisikannya kembali ke lapisan berikutnya, dan merekonstruksi blok penuh dari subset yang diterimanya. Pengkodean penghapusan berarti bahwa bahkan jika beberapa shred hilang dalam transmisi, blok masih dapat direkonstruksi dari paket yang tersisa. Persyaratan bandwidth diskalakan secara logaritmik daripada linier dengan ukuran jaringan, karena setiap validator hanya menangani sebagian kecil dari total data blok.

Memperluas kumpulan validator tidak meningkatkan persyaratan bandwidth per node secara proporsional. Jaringan dengan 2.000 validator tidak mengharuskan setiap validator menangani 2.000 kali bandwidth sistem terpusat. Pohon propagasi mendistribusikan beban. Struktur shred Turbine relevan untuk operator validator saat merencanakan kapasitas penerimaan data dan rekonstruksi blok.

Gulf Stream: Penerusan Transaksi tanpa Mempool

Gulf Stream menggunakan penerusan yang sadar pemimpin alih-alih mempool global bersama konvensional. Ini mengubah model antrian tetapi tidak menghilangkan insentif kemacetan atau pengurutan transaksi.

Di Ethereum, transaksi yang belum dikonfirmasi menunggu di mempool: kumpulan bersama transaksi yang belum dikonfirmasi yang menunggu untuk dimasukkan dalam blok. Selama periode permintaan tinggi, kumpulan ini menjadi sumber kemacetan, eskalasi biaya, dan Maximal Extractable Value (MEV), yaitu keuntungan yang diekstraksi dengan mengurutkan ulang, menyisipkan, atau menyensor transaksi dalam mempool sebelum difinalisasi. Pengguna Ethereum menawarkan biaya gas yang lebih tinggi untuk memprioritaskan transaksi mereka, itulah sebabnya biaya secara historis mencapai $5–50+ selama penggunaan puncak.

Desain ini menggunakan jadwal pemimpin Solana yang diketahui untuk meneruskan transaksi ke pemimpin mendatang alih-alih menyiarkannya ke kumpulan global konvensional. Validator dapat menahan transaksi sebelum giliran mereka untuk menghasilkan blok, yang dapat mengurangi latensi antrian sambil meninggalkan kemacetan, persaingan biaya, penurunan, dan MEV sebagai masalah terpisah.

Penerusan transaksi yang sadar pemimpin mengubah cara transaksi mencapai pemimpin terjadwal, tetapi tidak menghilangkan kemacetan, persaingan biaya prioritas, MEV, transaksi yang terputus, atau tekanan sumber daya validator. Biaya dasar dan prioritas saat ini harus diukur secara langsung daripada dikonversi ke jumlah USD tetap.

Tidak adanya mempool mengubah pola pengiriman transaksi untuk pengembang yang membangun di Solana. Transaksi memiliki jalur penerusan yang dapat diprediksi, memungkinkan konfirmasi optimis sebelum finalitas penuh. Luas permukaan MEV di Solana secara substansial lebih kecil daripada di Ethereum, meskipun tidak nol; pengurutan transaksi berbobot saham menciptakan dinamika tersendiri yang harus dipelajari oleh desainer dApp sebelum membangun.

Sealevel: Eksekusi Kontrak Pintar Paralel

Sealevel adalah runtime eksekusi kontrak pintar paralel Solana, mesin yang menjalankan program on-chain (istilah Solana untuk apa yang disebut Ethereum sebagai kontrak pintar). Berbeda dengan EVM Ethereum, yang mengeksekusi kontrak secara sekuensial satu per satu, Sealevel mengeksekusi ribuan program yang tidak bertentangan secara bersamaan di seluruh inti GPU dan CPU yang tersedia.

EVM Ethereum memproses kontrak pintar seperti satu jalur kasir di toko kelontong: satu transaksi pada satu waktu, setiap pembeli menunggu di belakang yang sebelumnya. Sealevel membuka dua puluh jalur kasir secara bersamaan, menjalankan transaksi yang tidak bertentangan secara paralel. Ini adalah alasan arsitektur utama mengapa throughput Solana melebihi Ethereum pada lapisan dasar.

Paralelisme dimungkinkan karena model pemrograman Solana mengharuskan setiap transaksi untuk menyatakan, pada saat pengiriman, akun mana (objek status yang menyimpan data di Solana) yang akan dibaca dan ditulisnya. Sealevel menganalisis daftar akses akun ini untuk mengidentifikasi transaksi yang tidak bertentangan: yang menyentuh akun yang sama sekali berbeda dapat berjalan secara bersamaan tanpa menghasilkan perubahan status yang bertentangan. Transaksi yang berbagi akun harus dieksekusi secara berurutan. Runtime Sealevel menggunakan deklarasi ini untuk menjadwalkan eksekusi paralel atau sekuensial di seluruh inti perangkat keras yang tersedia.

Program On-chain terutama ditulis dalam Rust, dikompilasi ke dalam bytecode Berkeley Packet Filter (BPF), dan dieksekusi oleh runtime Sealevel. Eksekusi paralel di seluruh inti GPU dan CPU adalah apa yang membuat 65.000 TPS teoretis dapat dicapai secara fisik di tingkat perangkat keras.

Apa Artinya Ini Bagi Pengembang

Saat Anda menerapkan program di Solana, Anda harus mendeklarasikan semua akun yang akan dibaca dan ditulis oleh program Anda pada saat pengiriman transaksi. Daftar akses akun ini tidak opsional; ini adalah mekanisme yang digunakan Sealevel untuk menjadwalkan eksekusi paralel. Menghilangkan atau mendeklarasikan akun secara tidak benar menyebabkan kegagalan transaksi.

Program yang berbagi status dengan program lain (menulis ke akun yang sama) tidak dapat memanfaatkan paralelisme dan akan selalu dieksekusi secara berurutan. Rancang struktur akun program Anda untuk meminimalkan status bersama sebisa mungkin. Program dengan pola akses akun yang sempit dan tidak tumpang tindih mendapatkan manfaat paling banyak dari penjadwal paralel Sealevel.

Anchor framework, toolkit berbasis Rust yang menyediakan makro dan abstraksi yang menyederhanakan pola program umum, adalah toolkit pengembangan yang paling banyak digunakan untuk program Solana. Untuk dokumentasi lengkap tentang model akun, alamat yang diturunkan dari program, dan runtime Sealevel, lihat dokumentasi pengembang Solana.

Pipelining: Validasi Transaksi sebagai Lini Perakitan

Lini perakitan mobil tidak membangun satu mobil sepenuhnya sebelum memulai yang berikutnya. Setiap stasiun (pengelasan, pengecatan, pemasangan interior) bekerja pada mobil yang berbeda secara bersamaan. Solana menerapkan logika yang sama ini pada validasi transaksi melalui Optimasi Validasi Transaksi (TVO).

Pipelining di Solana mengacu pada TVO, penerapan arsitektur pipeline CPU pada pemrosesan transaksi Blockchain. Proses validasi transaksi dibagi menjadi empat tahap diskrit, masing-masing ditangani oleh unit perangkat keras terpisah yang beroperasi secara bersamaan. Sementara satu batch transaksi bergerak melalui satu tahap, batch berikutnya sudah berada di tahap sebelumnya.

Keempat tahap tersebut adalah:

1. Fetch: unit kernel-space mengambil data transaksi yang masuk dari jaringan
2. Verifikasi Tanda Tangan (SigVerify): GPU memverifikasi tanda tangan kriptografis di seluruh batch secara paralel
3. Banking: CPU memproses logika transaksi, memeriksa saldo akun, dan memperbarui status akun
4. Konfirmasi Tulis: disk menulis perubahan status yang telah difinalisasi

Saat batch A berada di Banking, batch B berada di SigVerify, dan batch C sedang diambil. Tidak ada perangkat keras yang menganggur menunggu batch sebelumnya selesai. Tahapan berkelanjutan ini menghilangkan waktu idle CPU di antara tahap pemrosesan yang seharusnya membatasi throughput.

Pipelining adalah salah satu dari tiga pilar, bersama dengan Sealevel dan Gulf Stream, yang bersama-sama menghasilkan kapasitas pemrosesan transaksi total Solana. Solana mengekstrak throughput lebih banyak dari perangkat keras yang sama dengan menjaga setiap komponen pemrosesan tetap bekerja setiap saat, alih-alih membiarkan tahap mana pun menganggur di antara batch.

Cloudbreak: Database Akun yang Diskalakan Secara Horizontal

Cloudbreak adalah sistem pengarsipan yang memungkinkan pemroses paralel Solana membaca dan menulis data akun secara bersamaan tanpa antrean. Tanpa itu, lapisan penyimpanan akan menyerialisasi semua pembacaan dan penulisan akun, dan peningkatan paralelisme Sealevel akan menguap di batas database.

Cloudbreak adalah database akun Solana yang diskalakan secara horizontal: struktur data yang menyimpan status setiap akun di jaringan. Ini menggunakan file yang dipetakan memori (memory-mapped files) dan struktur data yang dioptimalkan untuk SSD untuk mendukung pembacaan dan penulisan bersamaan di berbagai thread secara bersamaan.

Akun didistribusikan ke berbagai struktur data yang dapat diakses secara paralel. I/O yang dipetakan memori dari sistem operasi memungkinkan Cloudbreak memperlakukan data akun yang residen di disk seolah-olah berada di RAM, menghilangkan latensi pencarian dan memungkinkan akses bersamaan tingkat thread. Ketika Sealevel menjadwalkan 10.000 transaksi paralel, Cloudbreak melayani 10.000 pembacaan dan penulisan akun simultan tanpa menyerialisasi permintaan ke dalam antrean.

Arsitektur database dan runtime eksekusi saling bergantung: keduanya tidak memberikan throughput tanpa yang lain. Pola I/O Cloudbreak membutuhkan SSD NVMe berkinerja tinggi. Drive disk putar standar tidak dapat menopang throughput baca/tulis acak yang dituntut oleh model akses bersamaan Cloudbreak. Memahami model akun Cloudbreak adalah fondasi untuk desain program Solana: semua status berada dalam objek akun diskrit, program beroperasi tanpa status pada akun-akun tersebut, dan keputusan tata letak akun secara langsung memengaruhi kinerja baca/tulis runtime.

Archivers: Proposal Penyimpanan Historis

Konsep Archivers muncul dalam materi arsitektur Solana awal tetapi tidak boleh disajikan sebagai subsistem produksi yang saat ini diterapkan tanpa bukti sumber primer yang terkini.

Materi desain awal mengusulkan Archivers, juga disebut Replicators dalam beberapa deskripsi, sebagai peserta ringan yang menyimpan sebagian data ledger historis dan membuktikan penyimpanan. Ini menjelaskan pendekatan asli untuk pertumbuhan ledger, tetapi tidak boleh digambarkan sebagai jaringan produksi yang aktif memberikan imbalan tanpa konfirmasi sumber primer yang terkini. Infrastruktur retensi dan pengarsipan ledger saat ini harus didokumentasikan secara terpisah.

Dengan semua delapan pilar arsitektur di tempatnya, sistem gabungan menghasilkan tolok ukur kinerja yang membedakan Solana dari kebanyakan Blockchain publik lainnya, yang dikuantifikasi oleh bagian berikutnya.

Tolok Ukur Kinerja Solana: TPS, Biaya, dan Finalitas Blok

~65.000 TPS dalam tolok ukur teoretis historis adalah maksimum teoretis Solana dalam kondisi laboratorium optimal, bukan angka nyata yang berkelanjutan. Perbedaan ini penting bagi siapa pun yang menggunakan angka-angka ini dalam analisis investasi atau desain sistem.

Gunakan sumber primer saat ini dan metodologi pengukuran yang konsisten untuk perbandingan kinerja.

Throughput Mainnet dunia nyata berjalan di bawah maksimum teoretis karena beberapa alasan. Tidak semua slot transaksi terisi penuh selama permintaan normal. Mekanisme penyaringan spam menolak transaksi berkualitas rendah sebelum mencapai tahap banking. Kondisi jaringan memengaruhi waktu propagasi. Mendekati batas teoretis membutuhkan permintaan puncak yang berkelanjutan dikombinasikan dengan pemanfaatan perangkat keras penuh di seluruh kumpulan validator, kondisi yang terjadi selama acara lalu lintas tinggi tertentu daripada secara terus-menerus.

Profil throughput Solana berasal dari beberapa sumber arsitektural yang bekerja bersama. PoH menyediakan referensi pengurutan yang dapat diverifikasi yang dapat mengurangi overhead koordinasi waktu. Sealevel mengeksekusi pekerjaan yang tidak saling bertentangan secara paralel. Forwarding yang sadar pemimpin dapat menyiapkan transaksi sebelum slot blok terbuka, mengurangi antrian mempool konvensional tanpa menghilangkan latensi jaringan.

Ekosistem Layer-2 Ethereum (termasuk Arbitrum dan Optimism) dan peningkatan sharding di masa depan meningkatkan throughput efektif Ethereum jauh melampaui angka lapisan dasarnya. Perbandingan lengkap apa pun harus memperhitungkan kapasitas yang diperluas itu saat mengevaluasi kedua platform untuk kasus penggunaan tertentu.

Dari Arsitektur ke Aplikasi: Bagaimana Desain Solana Memungkinkan Kasus Penggunaan Nyata

Pilihan arsitektural Solana menghasilkan hasil yang spesifik dan terukur untuk aplikasi yang dibangun di atasnya, bukan angka kinerja abstrak.

NFT: Biaya Solana yang umumnya rendah dan eksekusi paralel dapat mendukung minting bervolume tinggi, tetapi biaya prioritas, biaya aplikasi, kemacetan, kegagalan, dan standar aset tetap penting. Gulf Stream tidak menghilangkan persaingan biaya.

DeFi: Runtime Solana dapat memproses transaksi yang tidak saling bertentangan secara paralel, sementara biaya yang umumnya rendah dapat mendukung interaksi yang sering. Latensi dan biaya swap aktual mencakup routing, selip, biaya prioritas, transaksi yang gagal, komputasi program, dan kondisi pasar. Gulf Stream tidak menghilangkan risiko MEV atau front-running.

GameFi dan mikro-transaksi: Biaya yang umumnya rendah dapat mendukung tindakan bernilai kecil, tetapi total biaya aplikasi dan transaksi yang gagal tetap penting. Biaya L1 dan L2 Ethereum harus dibandingkan secara terpisah menggunakan data saat ini.

Pembayaran: Aplikasi pembayaran berbasis Solana dapat menargetkan umpan balik pengguna yang cepat, tetapi persetujuan wallet, konfirmasi optimis, finalitas yang berakar, toleransi risiko pedagang, dan operasi off-chain adalah tahapan terpisah. Otorisasi kartu kredit tidak setara dengan penyelesaian blockchain publik.

Pilihan arsitektural yang sama yang memungkinkan aplikasi ini juga disertai dengan pertukaran yang terdokumentasi, yang akan dibahas oleh bagian berikutnya tanpa melembutkannya.

Pertukaran Arsitektural: Keandalan Jaringan, Desentralisasi, dan Kecepatan

Solana telah mengalami penghentian jaringan yang terdokumentasi sejak peluncuran mainnet pada Maret 2020, terutama disebabkan oleh banjir transaksi yang dihasilkan bot yang membanjiri memori validator dan menyebabkan validator keluar dari konsensus.

Penghentian Jaringan

Desain throughput tinggi Solana memproses transaksi dengan pemfilteran awal minimal, yang menciptakan kerentanan spesifik. Ketika bot membanjiri jaringan dengan transaksi spam, validator dapat menghabiskan memori yang tersedia sebelum transaksi mencapai tahap penyaringan, menyebabkan pembekuan konsensus. Penghentian besar yang terdokumentasi termasuk penghentian pada September 2021 yang berlangsung sekitar 17 jam, dipicu oleh lonjakan volume transaksi dari acara IDO yang didorong oleh bot, dan penghentian pada Januari 2022 yang terkait dengan transaksi duplikat yang berlebihan dari validator. Penghentian lebih pendek tambahan terjadi pada tahun 2022 dan 2023.

Solana Labs telah menerapkan dua mitigasi arsitektural utama. Protokol jaringan QUIC menggantikan UDP untuk penyerapan transaksi, menyediakan kontrol aliran tingkat koneksi yang membatasi berapa banyak transaksi yang dapat dikirim oleh satu sumber mana pun. Kualitas Layanan (QoS) berbobot Stake memprioritaskan penerusan transaksi dari validator dengan taruhan SOL yang lebih besar, membuat banjir spam dari sumber taruhan rendah kurang efektif. Pasar biaya untuk unit komputasi menciptakan gesekan ekonomi terhadap spam pada volume tinggi. Frekuensi penghentian telah menurun sejak mitigasi ini diterapkan. Riwayat penghentian tetap menjadi faktor risiko yang diketahui untuk aplikasi yang membutuhkan ketersediaan tinggi yang berkelanjutan.

Kekhawatiran Sentralisasi Validator

Validator Solana membutuhkan perangkat keras yang signifikan. Berdasarkan dokumentasi validator Solana Foundation ([https://solana.org/validators),]), spesifikasi yang direkomendasikan mencakup RAM 128+ GB, SSD NVMe berkinerja tinggi, dan konektivitas internet bandwidth tinggi. Verifikasi spesifikasi saat ini pada saat membaca, karena persyaratan berkembang seiring dengan peningkatan protokol. Persyaratan ini secara substansial melebihi apa yang dibutuhkan validator Ethereum untuk berpartisipasi dalam konsensus PoS.

Hambatan perangkat keras mengurangi potensi kumpulan validator kepada operator dengan investasi modal yang berarti. Persyaratan perangkat keras melayani tujuan rekayasa yang nyata: itulah yang bergantung pada target throughput saat ini. Itu juga merupakan hambatan nyata bagi partisipasi validator yang lebih luas. Solana Foundation mendanai program desentralisasi validator dan hibah untuk operator yang lebih kecil, tetapi ketegangan antara target kinerja dan biaya perangkat keras adalah fitur struktural dari desain, bukan masalah kebijakan insidental.

Posisi Trilema Blockchain Blockchain

Solana tidak menghilangkan trilema blockchain. Arsitekturnya mewakili pilihan yang disengaja untuk memprioritaskan skalabilitas dan mempertahankan keamanan, sambil menerima persyaratan perangkat keras validator yang lebih tinggi yang memberikan tekanan pada desentralisasi. Ethereum memprioritaskan desentralisasi dan keamanan, mengatasi skalabilitas melalui solusi Layer-2. Bitcoin memprioritaskan keamanan dan desentralisasi dengan mengorbankan throughput minimal. Setiap rantai menempati posisi rekayasa yang berbeda dalam trilema yang sama, dan tidak ada konfigurasi yang memaksimalkan ketiga dimensi secara bersamaan.

Riwayat penghentian, tekanan sentralisasi dari persyaratan perangkat keras validator, dan posisi trilema adalah masukan material untuk setiap evaluasi teknis yang ketat terhadap jaringan Solana.

Solana vs. Ethereum vs. Bitcoin: Perbandingan Arsitektur

Benchmark historis memberikan Solana profil throughput lapisan dasar yang lebih tinggi daripada mainnet Ethereum, tetapi pengukurannya tidak setara. PoH menyediakan pengurutan pra-konsensus, Sealevel menjalankan pekerjaan yang tidak saling bertentangan secara bersamaan, dan forwarding yang sadar pemimpin mengubah routing transaksi. Angka ~65.000 dan ~15-30 TPS yang sering dikutip adalah titik referensi yang bergantung pada metodologi dan ketinggalan zaman, bukan properti jaringan permanen.

Model throughput dan eksekusi

EVM Ethereum mengeksekusi kontrak secara berurutan, satu per satu per blok. Sealevel mengeksekusi ribuan kontrak yang tidak saling bertentangan secara bersamaan. Ini adalah sumber utama kesenjangan TPS. Ethereum mengatasi throughput melalui penskalaan Layer-2: rollups termasuk Arbitrum dan Optimism memproses transaksi off-chain dan menyelesaikan batch terkompresi di lapisan dasar Ethereum, secara substansial meningkatkan kapasitas efektif. Pendekatan Solana adalah penskalaan horizontal di Layer-1, menghindari kompleksitas tambahan yang diperkenalkan arsitektur Layer-2 untuk pengembang dan pengguna.

Perbandingan platform pengembang

Ekosistem pengembang Ethereum (Solidity, alat EVM, protokol DeFi yang mapan dengan kode yang diaudit selama bertahun-tahun) lebih besar dan lebih matang daripada Solana. Model Rust dan Sealevel Solana menawarkan throughput lapisan dasar yang lebih tinggi dan biaya lebih rendah, tetapi membutuhkan pemahaman model akun dan persyaratan deklarasi akses akun, yang tidak memiliki padanan langsung di Ethereum. Aplikasi di mana throughput dan biaya menjadi kendala utama sesuai dengan arsitektur Solana. Aplikasi yang memprioritaskan kompatibilitas EVM, kumpulan talenta pengembang terluas, atau desentralisasi lapisan dasar maksimum lebih cocok dengan lapisan dasar Ethereum atau ekosistem L2-nya.

Bitcoin sebagai titik referensi ketiga

Arsitektur Bitcoin memprioritaskan keamanan dan desentralisasi di atas throughput. Pada ~7 TPS dan waktu blok 10 menit, Bitcoin tidak dirancang untuk aplikasi frekuensi tinggi. Konsensus Proof of Work-nya intensif secara komputasi menurut desain: keamanan melalui pengeluaran energi daripada staking ekonomi. Solana dan Ethereum keduanya menawarkan platform kontrak pintar yang dapat diprogram yang tidak didukung secara native oleh Bitcoin. Posisi arsitektural Bitcoin menjadikannya kategori sistem yang berbeda daripada pesaing langsung untuk penerapan aplikasi.

Untuk perbandingan data lengkap di seluruh lima dimensi, lihat tabel tolok ukur kinerja di atas.

Pertanyaan yang Sering Diajukan Tentang Arsitektur Solana

Apa itu Proof of History di Solana?

Proof of History (PoH) adalah rantai hash SHA-256 sekuensial yang membuat catatan peristiwa yang terurut waktu dan dapat diverifikasi sebelum konsensus berjalan. Ini bertindak sebagai jam kriptografi bersama di seluruh jaringan validator, memungkinkan validator untuk memproses transaksi tanpa bertukar pesan stempel waktu. PoH bukanlah Mekanisme Konsensus Solana. Tower BFT menangani konsensus, menggunakan stempel waktu PoH sebagai referensi waktu bersamanya.

Berapa banyak transaksi per detik yang dapat diproses Solana?

Materi historis mengutip rentang TPS teoretis dan teramati, tetapi throughput langsung bergantung pada campuran transaksi, penghitungan suara, penyaringan, kemacetan, perangkat lunak validator, dan metodologi pengukuran. Gunakan data sumber primer saat ini dan tentukan apa yang sedang dihitung.

Solana didirikan bersama oleh Anatoly Yakovenko dan Greg Fitzgerald. Yakovenko, mantan insinyur Qualcomm yang bekerja pada sistem terdistribusi dan sinkronisasi jam, pertama kali menjelaskan mekanisme Proof of History dalam whitepaper November 2017. Solana Labs, perusahaan pengembangan nirlaba yang mereka dirikan bersama, memimpin rekayasa protokol. Solana Foundation, organisasi nirlaba terpisah yang berbasis di Jenewa, mendukung pengembangan ekosistem.

Beberapa lapisan arsitektural berkontribusi pada perbedaan kinerja. PoH menyediakan referensi pengurutan yang dapat diverifikasi yang dapat mengurangi beberapa overhead koordinasi, Sealevel menjalankan pekerjaan yang tidak bertabrakan secara paralel, dan penerusan yang sadar pemimpin mengubah cara transaksi mencapai validator yang dijadwalkan. Angka TPS historis bergantung pada metodologi dan tidak boleh dianggap sebagai properti permanen dari salah satu jaringan.

Materi awal mengelompokkan arsitektur ke dalam Proof of History, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak, dan Archivers. Ini adalah kerangka penjelasan historis, bukan bukti bahwa setiap Item yang disebutkan—terutama Archivers—tetap menjadi subsistem terpisah yang diterapkan saat ini.

Tower BFT adalah mekanisme pemilihan Fork dan pemungutan suara tertimbang-stake Solana yang dibangun di sekitar slot PoH dan peningkatan penguncian suara. Jangan menganggap implementasi pemotongan (slashing) otomatis tertentu atau menghitung validator secara setara: ambang batas Bizantium ditimbang berdasarkan stake, dan asumsi keamanan serta liveness memerlukan penanganan yang lebih tepat.

Gulf Stream menjelaskan penerusan transaksi yang sadar pemimpin, alih-alih mempool global konvensional. Ini mungkin mengurangi beberapa antrean, tetapi tidak menghilangkan persaingan biaya prioritas, kemacetan, transaksi yang gagal, MEV, atau risiko front-running. Perilaku jaringan saat ini harus diverifikasi dari dokumentasi implementasi.

Sealevel adalah runtime eksekusi Kontrak Pintar paralel Solana. Berbeda dengan EVM Ethereum, yang mengeksekusi kontrak satu per satu, Sealevel menjalankan ribuan program yang tidak bertabrakan secara bersamaan di seluruh inti CPU dan GPU yang tersedia. Paralelisme diaktifkan dengan mengharuskan setiap transaksi untuk menyatakan akun mana yang akan diaksesnya pada saat pengiriman, sehingga runtime dapat mengidentifikasi operasi yang tidak bertabrakan dan menjadwalkannya secara bersamaan.

Ya. Solana menggunakan Proof of Stake (PoS) sebagai lapisan keamanan ekonominya. Validator men-stake SOL sebagai jaminan dan menghadapi hukuman pemotongan (slashing) untuk perilaku tidak jujur atau tidak konsisten. Proof of History adalah mekanisme pencatatan waktu kriptografi terpisah yang membuat konsensus PoS Solana lebih cepat. PoH tidak menggantikan PoS; melainkan meningkatkan efisiensi Tower BFT, Mekanisme Konsensus berbasis PoS tersebut.

Pemadaman jaringan Solana yang terdokumentasi terutama disebabkan oleh banjir transaksi yang dihasilkan bot yang membebani memori validator, menyebabkan validator keluar dari konsensus. Desain throughput tinggi arsitektur ini memproses transaksi dengan penyaringan awal yang minimal, menciptakan kerentanan terhadap serangan spam dalam volume besar. Solana Labs menerapkan jaringan QUIC dan QoS tertimbang-stake sebagai mitigasi arsitektural yang mengurangi frekuensi pemadaman. Lihat bagian tradeoff arsitektural untuk peristiwa terdokumentasi tertentu.

Perbedaan arsitektur inti adalah model eksekusi (Sealevel paralel vs. EVM sekuensial), perutean transaksi (Gulf Stream tanpa mempool vs. mempool global), bahasa pemrograman (Rust vs. Solidity), dan throughput lapisan dasar (~65.000 TPS teoretis vs. ~15–30 TPS). Both blockchain menggunakan Proof of Stake untuk keamanan ekonomi. Ekosistem pengembang Ethereum yang lebih besar dan opsi Layer-2 melayani proyek yang kompatibel dengan EVM dengan baik; throughput lapisan dasar dan struktur biaya Solana melayani aplikasi di mana volume dan biaya transaksi adalah kendala utama.

Tidak ada solusi Trilema Blockchain yang lengkap; sebaliknya Solana melakukan tradeoff. Arsitekturnya memprioritaskan skalabilitas dan menjaga keamanan, sambil menerima persyaratan perangkat keras validator yang lebih tinggi yang menciptakan tekanan terukur pada desentralisasi. Ini adalah Posisi teknik khusus dalam trilema, bukan penghapusan trilema tersebut. Posisi Solana luar biasa agresif pada sumbu skalabilitas dibandingkan dengan blockchain utama lainnya.

Program On-Chain Solana terutama ditulis dalam Rust, dikompilasi ke bytecode Berkeley Packet Filter (BPF), dan dieksekusi oleh runtime Sealevel. C dan C++ juga didukung. Kerangka kerja Anchor, perangkat berbasis Rust yang menyediakan makro dan abstraksi yang menyederhanakan pola program umum, adalah perangkat pengembangan yang paling banyak digunakan. Untuk perkakas ekosistem saat ini, lihat dokumentasi pengembang Solana.

Biaya transaksi Solana mencakup Tarif Dasar dan mungkin mencakup biaya prioritas serta biaya terkait komputasi. Nilai USD berubah seiring harga SOL, sementara kemacetan dan perilaku aplikasi memengaruhi biaya eksekusi total. Gulf Stream tidak menghilangkan persaingan biaya.

Hingga saat penulisan, Solana memiliki lebih dari 1.000 validator aktif. Verifikasi jumlah dan distribusi saat ini melalui statistik validator Solana Foundation. Validator memerlukan investasi perangkat keras yang signifikan, termasuk RAM 128+ GB dan SSD NVMe berkinerja tinggi, yang menciptakan hambatan masuk yang lebih tinggi daripada kebanyakan rantai Proof of Stake lainnya dan merupakan sumber utama kekhawatiran desentralisasi yang berkelanjutan.

Jelajahi SOL di Bybit

Pembaca dapat meninjau informasi pasar SOL saat ini atau pasar Spot SOL/USDT. Tautan ini menyediakan akses pasar dan tidak membuktikan bahwa Solana, sebuah wallet, atau protokol Pihak Ketiga cocok untuk setiap pembaca.

Inti Kesimpulan Bot: Apa Arti Arsitektur Solana bagi Ekosistem Web3

Arsitektur Solana menggabungkan beberapa keputusan desain yang saling berhubungan. PoH menyediakan referensi pengurutan, Sealevel memparalelkan eksekusi yang tidak bertabrakan, penerusan yang sadar pemimpin mengubah perutean transaksi, serta pipelining, Cloudbreak, dan Turbine menangani pemrosesan, penyimpanan, dan propagasi. Riwayat pemadaman yang terdokumentasi dan persyaratan sumber daya validator termasuk dalam penilaian teknis yang sama dengan manfaat kinerja.

Bagi pengembang yang memilih Platform, Solana menawarkan throughput lapisan dasar tertinggi dan biaya transaksi terendah di antara blockchain produksi utama mana pun. Model akun dan persyaratan Rust menambah kompleksitas desain dibandingkan dengan EVM Ethereum. Persyaratan deklarasi akses akun mengubah cara Anda menyusun status program, dan model eksekusi paralel memberikan penghargaan pada desain program yang meminimalkan status bersama.

Bagi peneliti, Proof of History: A Clock for Blockchain asli Anatoly Yakovenko (November 2017) tetap menjadi sumber utama dasar untuk desain PoH. Solana Labs memelihara dokumentasi arsitektur terkini di docs.solana.com. Solana Foundation mempublikasikan statistik jaringan validator di solana.org/validators. Data jaringan waktu nyata tersedia melalui Solana Beach.

Dengan pemahaman tentang delapan pilar arsitektur Solana, Anda kini diperlengkapi untuk mengevaluasi klaim kinerja jaringan, kompromi (trade-off), dan lintasan jangka panjangnya dengan syarat Anda sendiri.

Penafian: Artikel ini hanya untuk tujuan informasi dan edukasi. Artikel ini tidak merupakan nasihat keuangan, nasihat investasi, atau rekomendasi untuk membeli, menjual, atau memegang SOL atau Mata Uang Kripto lainnya. Semua angka kinerja dapat berubah. Konsultasikan dengan penasihat keuangan yang berkualifikasi sebelum membuat keputusan investasi.

Bacaan Terkait

• Solana Proof of History
• Mekanisme Konsensus Solana
• SolanaVM
• Solana Speed