Memahami kembali arsitektur teknologi Solana: Apakah akan menyambut hari kedua?

Solana adalah platform blockchain berkinerja tinggi yang menggunakan arsitektur teknologi unik untuk mencapai throughput tinggi dan latensi rendah. Teknologi inti meliputi 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. Mesin Virtual Solana (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, yang juga kita bahas secara mendalam dalam artikel ini.

Ekosistem Solana berkembang pesat, dengan berbagai indikator data yang tumbuh dengan cepat pada paruh pertama tahun ini, terutama di bidang DeFi, infrastruktur, GameFi/NFT, DePin/AI, dan aplikasi konsumen. TPS tinggi Solana dan strategi yang berfokus pada aplikasi konsumen serta lingkungan ekosistem dengan efek merek yang lebih lemah memberikan peluang kewirausahaan yang kaya 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 membangun SDK khusus untuk aplikasi konsumen, Solana berkomitmen untuk mengintegrasikan teknologi blockchain ke dalam aplikasi sehari-hari, sehingga meningkatkan penerimaan dan kenyamanan pengguna. Misalnya, suatu aplikasi kebugaran olahraga menyediakan pengalaman kebugaran dan sosial yang baru bagi pengguna dengan menggabungkan teknologi blockchain dan seluler. Meskipun saat ini banyak aplikasi konsumen masih menjelajahi model bisnis dan penempatan pasar terbaik, platform teknologi dan dukungan ekosistem yang disediakan oleh Solana tidak diragukan lagi memberikan dukungan yang kuat untuk upaya inovasi ini. Dengan perkembangan teknologi yang lebih lanjut dan pematangan pasar, Solana diharapkan dapat mencapai lebih banyak terobosan dan kasus sukses di bidang aplikasi konsumen.

Meskipun Solana telah memperoleh pangsa pasar yang signifikan dalam industri blockchain dengan throughput tinggi dan biaya transaksi yang rendah, ia juga menghadapi persaingan ketat dari blockchain baru lainnya. Base, sebagai pesaing potensial dalam ekosistem EVM, jumlah alamat aktif di on-chain-nya sedang tumbuh dengan cepat, sementara total nilai terkunci di sektor DeFi Solana (TVL) meskipun mencapai rekor tertinggi, pesaing seperti Base juga dengan cepat merebut pangsa pasar, dan pendanaan ekosistem Base juga untuk pertama kalinya melampaui Solana pada kuartal Q2.

Meskipun Solana telah mencapai beberapa prestasi 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 kecepatan pertumbuhan status, Solana perlu terus mengoptimalkan arsitektur teknologinya dan protokol jaringannya untuk mempertahankan posisinya yang unggul di industri blockchain.

Arsitektur Teknologi

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

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, dengan memberikan input X, maka hanya ada satu output Y yang unik, sehingga setiap perubahan pada X akan mengakibatkan Y yang sama sekali berbeda.

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

Ini adalah inti dari teknologi Proof of History, 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, menggambarkan alur transaksi di bawah mekanisme POH, di mana dalam mekanisme rotasi yang disebut Leader Rotation Schedule, akan dihasilkan satu node Leader di antara semua validator di rantai, yang mengumpulkan transaksi dan melakukan pengurutan eksekusi, menghasilkan urutan POH, setelah itu akan dihasilkan sebuah blok yang disebarkan ke node lainnya.

Untuk menghindari titik kegagalan tunggal di node Leader, maka diterapkan batas waktu. 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 di dalam setiap slot, node Leader harus menerbitkan blok dalam waktu slot yang ditentukan)400ms(, jika tidak, slot ini akan dilewati dan pemilihan ulang node Leader untuk slot berikutnya akan dilakukan.

Secara keseluruhan, node Leader yang menggunakan mekanisme POH dapat memastikan semua transaksi historis. Unit waktu dasar Solana adalah Slot, node Leader perlu menyiarkan blok dalam satu slot. Pengguna mengirim transaksi melalui node RPC ke Leader, node Leader mengemas dan mengurutkan transaksi, kemudian mengeksekusi untuk menghasilkan blok, blok disebarkan ke validator lain, validator perlu mencapai konsensus melalui suatu mekanisme, mencapai konsensus pada transaksi dan urutan dalam blok, konsensus yang digunakan adalah mekanisme konsensus Tower BFT.

) Mekanisme konsensus Tower BFT

Protokol konsensus Tower BFT berasal dari algoritma konsensus BFT, yang merupakan salah satu implementasi rekayasa konkret dari algoritma tersebut, dan algoritma ini masih terkait dengan algoritma POH. Ketika melakukan pemungutan suara untuk blok, jika suara validator itu sendiri adalah sebuah transaksi, maka transaksi pengguna dan hash blok yang dihasilkan oleh transaksi validator juga dapat berfungsi sebagai bukti sejarah, di mana detail transaksi pengguna dan 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 setuju, maka blok ini 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, biasanya digunakan banjir blok, yaitu ketika seorang validator menerima blok, ia akan mengirimkannya kepada validator di sekitarnya, sehingga menyebabkan banyak redundansi di jaringan, karena satu validator menerima blok yang sama lebih dari sekali.

Di Solana, karena adanya banyak transaksi voting oleh validator, serta efisiensi yang ditawarkan oleh sentralisasi node Leader dan waktu Slot 400ms, hal ini menyebabkan ukuran blok keseluruhan dan frekuensi pemblokiran 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###, yaitu jumlah data maksimum yang dapat dikirim dari satu node ke node berikutnya tanpa perlu membaginya menjadi unit yang lebih kecil, yang diukur dalam satuan (. Kemudian, integritas dan ketersediaan data dijamin dengan menggunakan skema kode penghapusan Reed-Solomon.

Dengan membagi blok menjadi empat Data Shreds, kemudian untuk mencegah kehilangan paket dan kerusakan selama proses transfer 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 adalah sekitar 15%, sehingga skema ini dapat dengan baik kompatibel dengan arsitektur Solana saat ini.

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

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

Setelah Turbine membagi data, mekanisme penyebaran multilapis digunakan untuk menyebarkan data tersebut. 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. Validator tersebut kemudian akan memulai penyebaran Turbine. Pertama-tama, 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 akar akan mengumpulkan semua validator aktif ke dalam satu daftar, kemudian mengurutkan berdasarkan hak kepemilikan setiap validator di jaringan, yaitu jumlah SOL yang dipertaruhkan ), semakin tinggi bobotnya maka akan 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: Membagi node menjadi lapisan dari bagian atas daftar, dengan menentukan dua nilai yaitu kedalaman dan lebar, maka dapat menentukan bentuk keseluruhan pohon, parameter ini akan mempengaruhi laju penyebaran shreds.

Node dengan proporsi hak yang tinggi, pada saat pengelompokan tingkat, berada di tingkat yang lebih tinggi, maka dapat memperoleh shreds yang lengkap lebih awal, pada saat itu dapat memulihkan blok yang lengkap, sedangkan node di lapisan berikutnya, karena kehilangan dalam transmisi, probabilitas mereka untuk mendapatkan shreds yang lengkap akan menurun. Jika shreds ini tidak cukup untuk membangun fragmen yang lengkap, akan meminta Leader untuk mengirim ulang secara langsung. Jadi pada saat ini, transmisi data akan dilakukan ke dalam pohon, dan node di lapisan pertama telah membangun konfirmasi blok yang lengkap, semakin lama waktu untuk validator di lapisan berikutnya untuk menyelesaikan pembangunan blok sebelum melakukan pemungutan suara.

Pemikiran dari mekanisme ini mirip dengan mekanisme node tunggal pada node Leader. Dalam proses penyebaran blok, terdapat beberapa node prioritas, yang pertama kali menerima shreds untuk membangun blok lengkap guna mencapai proses 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, sehingga pemungutan suara dari node berikutnya menjadi tidak relevan.

( SVM

Solana dapat memproses ribuan transaksi per detik, alasan utamanya terletak pada 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 memperlambat throughput sistem secara keseluruhan. Oleh karena itu, untuk SVM, Solana mengusulkan mesin eksekusi paralel Sealevel untuk mempercepat kecepatan eksekusi transaksi.

Di SVM, instruksi terdiri dari 4 bagian, termasuk ID program, instruksi program, dan daftar akun untuk membaca/menulis data. Dengan menentukan apakah akun saat ini berada dalam status membaca atau menulis serta apakah operasi yang akan dilakukan memiliki konflik dengan perubahan status, instruksi transaksi akun dapat diparalelkan jika tidak ada konflik pada status, setiap instruksi diwakili oleh Program ID. Dan inilah salah satu alasan mengapa permintaan untuk validator Solana sangat tinggi, karena memerlukan GPU/CPU validator untuk mendukung SIMD) single instruction multiple data### serta kemampuan AVX advanced vector extension.

Pengembangan Ekosistem

Dalam proses pengembangan ekosistem Solana saat ini, semakin condong ke utilitas praktis, seperti proyek smartphone tertentu dan toko aplikasi tertentu bahkan perangkat bergerak tertentu, dan arah pengembangan aplikasi yang didukung oleh resmi juga lebih condong ke aplikasi konsumen, bukan pengulangan tanpa batas infrastruktur. Saat ini, kinerja Solana cukup.