Analisis Arsitektur Teknologi Solana: Menyambut Musim Semi Kedua?

Solana adalah platform blockchain berkinerja tinggi yang menggunakan arsitektur teknologi unik untuk mencapai throughput tinggi dan latensi rendah. Teknologi intinya mencakup algoritma Proof of History (POH) yang memastikan urutan transaksi dan jam global, Jadwal Rotasi Pemimpin, dan mekanisme konsensus Tower BFT yang meningkatkan kecepatan 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 downtime jaringan, kegagalan transaksi, masalah MEV, pertumbuhan status yang terlalu cepat, dan masalah sentralisasi.

Pengembangan ekosistem Solana berkembang pesat, dengan berbagai indikator data yang tumbuh dengan cepat di paruh pertama tahun ini, terutama dalam bidang DeFi, infrastruktur, GameFi/NFT, DePin/AI, dan aplikasi konsumen. TPS tinggi Solana dan strategi yang berfokus pada aplikasi konsumen serta lingkungan ekosistem yang memiliki efek merek yang lebih lemah memberikan banyak peluang bagi 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 kenyamanan pengguna. Misalnya, aplikasi seperti Stepn menggabungkan teknologi blockchain dan mobile untuk menawarkan pengalaman kebugaran dan sosial yang baru bagi pengguna. Meskipun saat ini banyak aplikasi konsumen masih mencari model bisnis dan posisi pasar yang terbaik, platform teknologi dan dukungan ekosistem yang ditawarkan Solana pasti memberikan dukungan yang kuat bagi upaya inovasi ini. Dengan perkembangan teknologi lebih lanjut dan kematangan pasar, Solana diharapkan dapat mencapai lebih banyak terobosan dan kasus keberhasilan di bidang aplikasi konsumen.

Meskipun Solana telah memperoleh pangsa pasar yang signifikan dalam industri blockchain karena throughput tinggi dan biaya transaksi rendah, ia juga menghadapi persaingan ketat dari blockchain publik baru lainnya. Base, sebagai pesaing potensial dalam ekosistem EVM, jumlah alamat aktif di jaringannya sedang tumbuh dengan cepat, sementara total nilai yang terkunci di sektor DeFi Solana (TVL), meskipun mencapai rekor tertinggi, 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 pencapaian dalam hal teknologi dan penerimaan pasar, ia perlu terus berinovasi dan memperbaiki 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 jaringannya untuk mempertahankan posisinya yang terdepan di industri blockchain.

Arsitektur Teknologi

Solana terkenal dengan algoritma POH-nya, mekanisme konsensus Tower BFT, serta jaringan pengiriman data Trubine dan mesin virtual SVM yang menawarkan TPS tinggi dan finalitas cepat. Kami akan memberikan gambaran singkat tentang bagaimana masing-masing komponen ini bekerja, bagaimana mereka mencapai tujuan kinerja tinggi untuk desain arsitektur, serta kelemahan yang ditimbulkan dan masalah yang muncul dari desain arsitektur ini.

algoritma POH

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

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

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

Dalam diagram arsitektur aliran transaksi Solana, dijelaskan proses transaksi di bawah mekanisme POH. Dalam mekanisme rotasi pemimpin yang disebut Leader Rotation Schedule, akan dihasilkan satu node Pemimpin dari semua validator di jaringan. Node Pemimpin ini mengumpulkan transaksi, mengurutkan dan mengeksekusinya, menghasilkan urutan POH, kemudian menghasilkan sebuah blok yang disebarkan ke node-node lainnya.

Untuk menghindari titik kegagalan tunggal di node Leader, maka diperkenalkan batas waktu. Dalam Solana, satuan waktu dibagi berdasarkan epoch, 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, node Leader harus menerbitkan blok)400ms( dalam waktu slot yang diberikan, jika tidak, slot ini akan dilewatkan dan pemilihan ulang untuk node Leader slot berikutnya akan dilakukan.

Secara keseluruhan, node Leader yang menggunakan mekanisme POH dapat memastikan semua transaksi sejarah. 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 tekniknya, yang masih terkait dengan algoritma POH. Ketika melakukan pemungutan suara pada blok, jika suara dari validator itu sendiri adalah sebuah transaksi, maka transaksi pengguna dan hash blok yang terbentuk dari transaksi validator juga dapat digunakan sebagai bukti sejarah, detail transaksi pengguna mana pun dan detail suara validator dapat diidentifikasi secara unik.

![Sekali lagi menjelaskan arsitektur teknologi Solana: Apakah akan menyambut musim semi kedua?]###https://img-cdn.gateio.im/webp-social/moments-d55d3cfbc13036ed0d5747abb521cc1a.webp(

Dalam algoritma Tower BFT ditentukan bahwa jika semua validator memberikan suara untuk blok tersebut, dan lebih dari 2/3 validator memberikan suara setuju, maka blok ini dapat dipastikan. 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 digunakan adalah banjir blok, di mana seorang validator yang menerima blok akan mengirimkannya ke validator di sekitarnya, yang menyebabkan banyak redundansi dalam jaringan, karena seorang validator menerima blok yang sama lebih dari sekali.

Di Solana, karena adanya banyak transaksi pemungutan suara dari validator, dan karena efisiensi yang dihasilkan oleh sentralisasi node Leader serta waktu Slot 400ms, hal 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 unit transmisi MTU###, jumlah data maksimum ( yang dapat dikirim dari satu node ke node berikutnya tanpa perlu membaginya menjadi unit yang lebih kecil. Kemudian, data dijamin integritas dan ketersediaannya dengan menggunakan skema kode penghapusan Reed-solomon.

Dengan membagi blok menjadi empat Data Shreds, dan untuk mencegah kehilangan paket dan kerusakan selama proses pengiriman data, maka 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 sangat baik berkompatibilitas dengan arsitektur Solana saat ini.

![Mengurai Arsitektur Teknologi Solana: Apakah Akan Menyambut Musim Kedua?])https://img-cdn.gateio.im/webp-social/moments-e9bc35d0c790496c59c20979e5af1491.webp(

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

Turbine membagi data menjadi bagian, kemudian menggunakan mekanisme penyebaran multi-lapisan untuk menyebarkannya. 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 penghapus. Validator tersebut kemudian akan memulai penyebaran Turbine. Pertama, 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 akar akan mengumpulkan semua validator aktif ke dalam satu daftar, kemudian mengurutkan berdasarkan jumlah hak kepemilikan validator di jaringan ) yaitu jumlah SOL yang dipertaruhkan (, yang memiliki bobot lebih tinggi akan berada di lapisan pertama, dan seterusnya.

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

3. Pembentukan lapisan: Dari bagian atas daftar, node dibagi menjadi lapisan, dengan menentukan dua nilai yaitu kedalaman dan lebar, dapat menentukan bentuk keseluruhan pohon, parameter ini akan mempengaruhi laju penyebaran shreds.

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

Pemikiran dari mekanisme ini mirip dengan mekanisme satu node dari node Leader. Dalam proses penyebaran blok, ada beberapa node prioritas, node-node ini terlebih dahulu mendapatkan shreds untuk membentuk blok lengkap dalam proses mencapai konsensus pemungutan suara. Mengarahkan 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 pemungutan suara dari node-node berikutnya menjadi tidak relevan.

) SVM

Solana dapat memproses ribuan transaksi per detik, penyebab 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 menurunkan throughput seluruh sistem. Oleh karena itu, untuk SVM, Solana mengusulkan mesin eksekusi paralel Sealevel untuk mempercepat kecepatan eksekusi transaksi.

![Penjelasan Ulang Arsitektur Teknologi Solana: Akankah Menyambut Musim Kedua?]###https://img-cdn.gateio.im/webp-social/moments-9fd8693259e2864d6978d2b4e8ef2e85.webp(

Dalam SVM, instruksi terdiri dari 4 bagian, termasuk ID program, instruksi program, serta daftar akun untuk membaca/menulis data. Dengan menentukan apakah akun saat ini dalam status baca atau tulis dan apakah operasi yang akan dilakukan untuk mengubah status bertentangan, perintah transaksi akun dapat diizinkan untuk diparalelkan tanpa konflik status, di mana setiap instruksi diwakili oleh Program ID. Ini juga merupakan salah satu alasan mengapa persyaratan untuk validator Solana sangat tinggi, karena memerlukan GPU/CPU validator untuk mendukung SIMD) instruksi tunggal dengan banyak data( serta kemampuan AVX ekstensi vektor tingkat lanjut.

Pengembangan Ekosistem

Dalam proses perkembangan ekosistem Solana saat ini, semakin condong pada utilitas nyata, seperti Blinks dan Actions bahkan Solana Mobile, sementara arah pengembangan aplikasi yang didukung oleh resmi juga lebih condong ke aplikasi konsumen, bukan pada infrastruktur.