Analisis Arsitektur Teknologi Solana: Apakah Musim Semi Baru Segera Tiba?

Solana adalah platform blockchain berkinerja tinggi yang menggunakan arsitektur teknologi unik untuk mencapai throughput tinggi dan latensi rendah. Teknologi inti termasuk algoritma Proof of History (POH) yang memastikan urutan transaksi dan jam global, Jadwal Rotasi Pemimpin dan mekanisme konsensus Tower BFT yang meningkatkan laju pembuatan blok. Mekanisme Turbine mengoptimalkan penyebaran blok besar melalui pengkodean Reed-solomon. Solana Virtual Machine (SVM) dan mesin eksekusi paralel Sealevel mempercepat kecepatan eksekusi transaksi. Semua ini adalah desain arsitektur Solana untuk mencapai kinerja tinggi, tetapi juga membawa beberapa masalah, seperti pemadaman jaringan, kegagalan transaksi, masalah MEV, pertumbuhan status yang terlalu cepat, dan masalah sentralisasi.

Ekosistem Solana berkembang pesat, dengan berbagai indikator data tumbuh dengan cepat pada paruh pertama tahun ini, terutama dalam bidang DeFi, infrastruktur, GameFi/NFT, DePin/AI, dan aplikasi konsumen. TPS tinggi Solana dan strategi yang berorientasi pada aplikasi konsumen serta lingkungan ekosistem yang kurang kuat secara merek memberikan banyak peluang bagi para pengusaha dan pengembang. Dalam hal aplikasi konsumen, Solana menunjukkan visinya untuk mendorong penerapan teknologi blockchain di bidang yang lebih luas. Dengan mendukung seperti Solana Mobile dan SDK yang dibangun khusus untuk aplikasi konsumen, Solana berkomitmen untuk mengintegrasikan teknologi blockchain ke dalam aplikasi sehari-hari, sehingga meningkatkan penerimaan dan kemudahan bagi pengguna. Misalnya, aplikasi seperti Stepn menggabungkan teknologi blockchain dan mobile untuk memberikan pengalaman kebugaran dan sosial yang baru bagi pengguna. Meskipun saat ini banyak aplikasi konsumen masih menjelajahi model bisnis dan posisi pasar yang terbaik, platform teknologi dan dukungan ekosistem yang ditawarkan oleh Solana tidak diragukan lagi memberikan dukungan kuat bagi upaya inovasi ini. Dengan perkembangan teknologi yang lebih lanjut dan kematangan pasar, Solana diharapkan dapat mencapai lebih banyak terobosan dan contoh sukses di bidang aplikasi konsumen.

Meskipun Solana telah mendapatkan pangsa pasar yang signifikan di industri blockchain dengan throughput tinggi dan biaya transaksi rendah, ia juga menghadapi persaingan ketat dari blockchain baru yang muncul. Base sebagai pesaing potensial di ekosistem EVM, jumlah alamat aktif di jaringannya sedang meningkat dengan cepat, sementara total nilai terkunci Solana di bidang DeFi mencapai (TVL) meskipun mencetak rekor tertinggi dalam sejarah, tetapi pesaing seperti Base juga dengan cepat mengambil alih pangsa pasar, dan pendanaan ekosistem Base untuk pertama kalinya melampaui Solana di kuartal Q2.

Meskipun Solana telah mencapai beberapa prestasi dalam hal teknologi dan penerimaan pasar, ia perlu terus berinovasi dan meningkatkan diri untuk menghadapi tantangan dari pesaing seperti Base. Khususnya dalam meningkatkan stabilitas jaringan, mengurangi tingkat kegagalan transaksi, menyelesaikan masalah MEV, dan memperlambat laju pertumbuhan status, Solana perlu terus mengoptimalkan arsitektur teknologinya dan protokol jaringan untuk mempertahankan posisinya sebagai pemimpin di industri blockchain.

Arsitektur Teknologi

Solana terkenal dengan algoritma POH, mekanisme konsensus Tower BFT, serta jaringan transmisi data Trubine dan mesin virtual SVM yang memberikan TPS tinggi dan Finality cepat. Kami akan secara singkat memperkenalkan bagaimana masing-masing komponen bekerja, bagaimana mereka mencapai tujuan kinerja tinggi dalam desain arsitektur, serta kelemahan yang dihadirkan dan masalah yang muncul dari desain arsitektur tersebut.

algoritma POH

POH(Proof of History) adalah teknologi yang menentukan waktu global, yang bukan merupakan mekanisme konsensus, melainkan algoritma untuk menentukan urutan transaksi. Teknologi POH berasal dari teknologi kriptografi dasar SHA256. SHA256 biasanya digunakan untuk menghitung integritas data, dengan memberikan input X, maka hanya ada satu output Y yang unik, sehingga setiap perubahan pada X akan menyebabkan Y menjadi sepenuhnya berbeda.

Dalam urutan POH Solana, integritas seluruh urutan dapat dipastikan dengan menerapkan algoritma sha256, yang juga menentukan integritas transaksi di dalamnya. Sebagai contoh, jika kita mengemas transaksi menjadi satu blok, menghasilkan nilai hash sha256 yang sesuai, maka transaksi dalam blok ini akan ditentukan, setiap perubahan akan menyebabkan perubahan nilai hash, setelah itu hash blok ini akan menjadi bagian dari X fungsi sha256 berikutnya, kemudian menambahkan hash blok berikutnya, maka blok sebelumnya serta blok berikutnya akan ditentukan, setiap perubahan akan menyebabkan Y baru yang berbeda.

Ini adalah inti dari teknologi Proof of History, hash dari blok sebelumnya akan menjadi bagian dari fungsi sha256 berikutnya, mirip dengan sebuah rantai, Y terbaru selalu mencakup bukti sejarah.

Dalam diagram arsitektur aliran transaksi Solana, dijelaskan tentang proses transaksi di bawah mekanisme POH, di mana dalam mekanisme rotasi pemimpin yang disebut Leader Rotation Schedule, akan muncul satu node Leader dari semua Validator di rantai, node Leader ini mengumpulkan transaksi dan melakukan pengurutan eksekusi, menghasilkan urutan POH, dan setelah itu akan menghasilkan blok yang disebarkan ke node lainnya.

Untuk menghindari titik tunggal kegagalan di node Leader, maka batas waktu diperkenalkan. Di Solana, satuan waktu dibagi berdasarkan epoch, di mana setiap epoch terdiri dari 432,000 slot(, setiap slot berlangsung selama 400ms. Dalam setiap slot, sistem rotasi akan menetapkan satu node Leader dalam setiap slot, yang harus menerbitkan blok)400ms( dalam waktu yang ditentukan. Jika tidak, slot ini akan dilewati dan pemilihan kembali node Leader untuk slot berikutnya akan dilakukan.

Secara keseluruhan, node Leader yang menggunakan mekanisme POH dapat memastikan semua transaksi yang telah terjadi. Unit waktu dasar Solana adalah Slot, node Leader perlu menyiarkan blok dalam satu slot. Pengguna mengirimkan transaksi melalui node RPC kepada Leader, node Leader mengemas transaksi, mengurutkannya, kemudian mengeksekusi untuk menghasilkan blok, blok tersebut disebarkan ke validator lain, validator perlu mencapai konsensus melalui suatu mekanisme, untuk mencapai konsensus tentang transaksi dalam blok dan urutannya, konsensus yang digunakan adalah mekanisme konsensus Tower BFT.

) Mekanisme konsensus Tower BFT

Protokol konsensus Tower BFT berasal dari algoritma konsensus BFT, merupakan salah satu implementasi teknik spesifik dari algoritma tersebut, dan algoritma ini tetap berkaitan dengan algoritma POH. Ketika melakukan pemungutan suara terhadap blok, jika suara dari validator itu sendiri adalah suatu transaksi, maka hash blok yang dibentuk oleh transaksi pengguna dan transaksi validator juga dapat digunakan sebagai bukti sejarah, detail transaksi pengguna serta detail suara validator dapat dikonfirmasi secara unik.

Dalam algoritma Tower BFT ditentukan bahwa jika semua validator memberikan suara untuk blok tersebut dan lebih dari 2/3 validator memberikan suara approve, maka blok tersebut dapat dikonfirmasi. Manfaat dari mekanisme ini adalah menghemat banyak memori, karena hanya perlu memberikan suara pada urutan hash untuk mengonfirmasi blok. Namun, dalam mekanisme konsensus tradisional, umumnya menggunakan banjir blok, yaitu ketika seorang validator menerima blok, dia akan mengirimkannya kepada validator di sekitarnya, sehingga akan menyebabkan redundansi jaringan yang besar, karena seorang validator menerima blok yang sama lebih dari sekali.

![Apakah Solana akan mengalami kebangkitan kedua?]###https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(

Dalam Solana, karena adanya banyak transaksi suara validator, dan karena efisiensi yang dihasilkan oleh sentralisasi node Leader serta waktu Slot 400ms, ini menyebabkan ukuran blok keseluruhan dan frekuensi pembuatan blok menjadi sangat tinggi. Blok besar saat disebarkan juga akan memberikan tekanan besar pada jaringan, Solana menggunakan mekanisme Turbine untuk mengatasi masalah penyebaran blok besar.

) Turbine

Node Leader membagi blok menjadi sub-blok yang disebut shred melalui proses yang disebut Sharding, dengan ukuran spesifikasi maksimum MTU###, yang merupakan jumlah maksimum data yang dapat dikirim dari satu node ke node berikutnya tanpa perlu membaginya menjadi unit yang lebih kecil, yaitu (. Kemudian, data dilindungi dari kerusakan dan tersedia dengan menggunakan skema kode penghapusan Reed-Solomon.

Dengan membagi blok menjadi empat Data Shred, kemudian untuk mencegah kehilangan dan kerusakan data selama proses pengiriman, digunakan pengkodean Reed-Solomon untuk mengkodekan empat paket menjadi delapan paket, skema ini dapat mentolerir hingga 50% tingkat kehilangan paket. Dalam pengujian nyata, tingkat kehilangan paket Solana sekitar 15%, sehingga skema ini dapat dengan baik mengakomodasi arsitektur Solana saat ini.

Dalam transmisi data di lapisan dasar, umumnya akan dipertimbangkan penggunaan protokol UDP/TCP. Karena toleransi Solana terhadap tingkat kehilangan paket cukup tinggi, maka protokol UDP digunakan untuk transmisi. Kekurangan dari ini adalah tidak ada retransmisi saat terjadi kehilangan paket, tetapi keuntungannya adalah kecepatan transmisi yang lebih cepat. Sebaliknya, protokol TCP akan melakukan retransmisi berkali-kali ketika terjadi kehilangan paket, yang dapat secara drastis mengurangi kecepatan transmisi dan throughput. Dengan adanya Reed-Solomon, solusi ini dapat secara signifikan meningkatkan throughput Solana, di lingkungan nyata, throughput dapat meningkat hingga 9 kali.

Setelah Turbine membagi data, ia menggunakan mekanisme penyebaran multi-lapis untuk menyebarkan data. Node Leader akan menyerahkan blok kepada salah satu validator blok sebelum akhir setiap Slot, kemudian validator tersebut akan membagi blok menjadi Shreds dan menghasilkan kode penghapusan. Setelah itu, validator tersebut akan memulai penyebaran Turbine. Pertama, data harus disebarkan ke node akar, kemudian node akar akan menentukan validator mana yang berada di lapisan mana. Prosesnya adalah sebagai berikut:

1. Buat daftar node: Node utama akan mengumpulkan semua validator aktif ke dalam satu daftar, kemudian mengurutkannya berdasarkan hak kepemilikan setiap validator di jaringan, yaitu jumlah SOL yang dipertaruhkan ), dengan bobot yang lebih tinggi berada di lapisan pertama, dan seterusnya.

2. Pengelompokan node: Kemudian setiap validator yang berada di lapisan pertama juga akan membuat daftar node mereka sendiri untuk membangun lapisan pertama mereka.

3. Pembentukan lapisan: Dengan membagi node menjadi lapisan dari bagian atas daftar, dan dengan menentukan dua nilai yaitu kedalaman dan lebar, kita dapat menentukan bentuk kasar dari seluruh pohon, parameter ini akan mempengaruhi kecepatan penyebaran shreds.

Node dengan proporsi hak yang lebih tinggi, dalam pembagian tingkat, akan berada di tingkat yang lebih tinggi, sehingga dapat memperoleh shreds lengkap lebih awal. Pada saat ini, mereka dapat memulihkan blok lengkap, sementara node di lapisan berikutnya, karena kerugian transmisi, kemungkinan mereka untuk memperoleh shreds lengkap akan menurun. Jika shreds ini tidak cukup untuk membangun fragmen lengkap, akan meminta Leader untuk mentransmisikan ulang secara langsung. Maka saat ini, transmisi data akan dilakukan ke dalam pohon, sementara node di lapisan pertama sudah membangun konfirmasi blok lengkap, semakin lama waktu yang dibutuhkan untuk validator di lapisan berikutnya untuk menyelesaikan pembangunan blok dan melakukan voting.

Pemikiran dari mekanisme ini mirip dengan mekanisme satu node dari node Leader. Dalam proses penyebaran blok, ada beberapa node prioritas, yang terlebih dahulu memperoleh shreds untuk membentuk blok lengkap guna mencapai proses konsensus suara. Mendorong redundansi ke tingkat yang lebih dalam dapat secara signifikan mempercepat proses Finality, serta memaksimalkan throughput dan efisiensi. Karena pada kenyataannya, beberapa lapisan pertama mungkin sudah mewakili 2/3 dari node, maka suara dari node berikutnya menjadi tidak relevan.

( SVM

Solana dapat memproses ribuan transaksi per detik, alasan utamanya adalah mekanisme POH, konsensus Tower BFT, dan mekanisme penyebaran data Turbine. Namun, SVM sebagai mesin virtual untuk transisi status, jika node Leader lambat dalam mengeksekusi transaksi, maka kecepatan pemrosesan SVM akan mengurangi throughput seluruh sistem. Oleh karena itu, untuk SVM, Solana mengusulkan mesin eksekusi paralel Sealevel untuk mempercepat kecepatan eksekusi transaksi.

Dalam SVM, instruksi terdiri dari 4 bagian, termasuk ID program, instruksi program, dan daftar akun yang membaca/menulis data. Dengan menentukan apakah akun saat ini berada dalam status baca atau tulis dan apakah operasi yang akan dilakukan untuk mengubah status memiliki konflik, instruksi transaksi akun dapat diparalelkan jika tidak ada konflik pada status, setiap instruksi diwakili oleh Program ID. Itulah sebabnya mengapa persyaratan untuk validator Solana sangat tinggi, karena validator harus memiliki GPU/CPU yang mampu mendukung SIMD) single instruction multiple data### dan kemampuan AVX advanced vector extensions.

Pengembangan Ekosistem

Dalam proses pengembangan ekosistem Solana saat ini, semakin condong pada utilitas yang nyata, seperti Blinks dan Actions bahkan Solana Mobile, sementara arah pengembangan aplikasi yang didukung resmi juga lebih condong ke aplikasi konsumen, bukan pada pengulangan tanpa batas dari infrastruktur. Dengan kinerja Solana yang cukup saat ini, jenis aplikasi menjadi lebih beragam. Berbicara tentang Ethereum, karena TPS-nya yang lebih rendah, maka