Analisis Arsitektur Teknologi Solana dan Perkembangan Ekosistem
Solana adalah platform blockchain berkinerja tinggi yang menggunakan arsitektur teknologi unik untuk mencapai throughput tinggi dan latensi rendah. Teknologi inti 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.
Ekosistem Solana berkembang pesat, berbagai indikator data 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 yang kurang kuat 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.
Meskipun Solana telah mendapatkan pangsa pasar yang signifikan di industri blockchain dengan throughput yang tinggi dan biaya transaksi yang rendah, ia juga menghadapi persaingan ketat dari blockchain publik baru lainnya. Base sebagai pesaing potensial dalam ekosistem EVM, jumlah alamat aktif di jaringannya sedang meningkat dengan cepat, sementara total nilai terkunci (TVL) di bidang DeFi Solana ( telah mencapai rekor tertinggi, tetapi pesaing seperti Base juga dengan cepat mengambil alih pangsa pasar, dan jumlah pendanaan ekosistem Base juga untuk pertama kalinya melampaui Solana di kuartal kedua (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 laju pertumbuhan status, Solana perlu terus mengoptimalkan arsitektur teknologinya dan protokol jaringan untuk mempertahankan posisinya yang terdepan 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. Bagaimana masing-masing komponen bekerja, bagaimana mereka mencapai tujuan kinerja tinggi dalam desain arsitektur, serta kelemahan dan masalah yang muncul dari desain arsitektur tersebut.
) algoritma POH
POH###Proof of History( adalah sebuah 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 diberikan input X, maka hanya ada satu output Y yang unik, oleh karena itu setiap perubahan pada X akan mengakibatkan Y yang sepenuhnya berbeda.
Dalam urutan POH Solana, dengan menerapkan algoritma sha256, kita dapat memastikan integritas seluruh urutan, yang juga memastikan integritas transaksi di dalamnya. Sebagai contoh, jika kita mengemas transaksi menjadi satu blok, menghasilkan nilai hash sha256 yang sesuai, maka transaksi dalam blok tersebut telah ditentukan, setiap perubahan akan menyebabkan perubahan pada nilai hash tersebut, kemudian hash blok ini akan menjadi bagian dari X fungsi sha256 berikutnya, ditambahkan dengan hash blok berikutnya, maka blok sebelumnya dan blok berikutnya akan ditentukan, setiap perubahan akan menghasilkan Y yang berbeda.
Ini adalah makna inti dari teknologi Proof of History, hash blok sebelumnya akan menjadi bagian dari fungsi sha256 berikutnya, mirip dengan rantai, Y terbaru selalu mencakup bukti sejarah.
![Mengurai Arsitektur Teknologi Solana: Apakah Akan Menyambut Musim Kedua?])https://img-cdn.gateio.im/webp-social/moments-83781275d369bad28954d579213dd93e.webp(
Dalam diagram arsitektur aliran transaksi Solana, dijelaskan tentang alur transaksi di bawah mekanisme POH. Dalam mekanisme rotasi yang disebut Leader Rotation Schedule, akan dihasilkan sebuah node Leader dari semua validator di rantai. Node Leader ini mengumpulkan transaksi dan melakukan penyortiran eksekusi, menghasilkan urutan POH, kemudian sebuah blok akan dihasilkan dan disebarkan ke node lainnya.
Untuk menghindari titik kegagalan tunggal di node Leader, maka diperkenalkan batas waktu. Di Solana, unit waktu dibagi berdasarkan epoch, setiap epoch terdiri dari 432.000 slot), setiap slot berlangsung selama 400ms, di setiap slot, sistem rotasi akan mengalokasikan satu node Leader di 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. Satuan waktu dasar Solana adalah Slot, node Leader perlu menyebarkan blok dalam satu slot. Pengguna mengirimkan transaksi melalui node RPC ke Leader, node Leader mengemas transaksi, menyusunnya, kemudian mengeksekusi untuk menghasilkan blok, blok tersebut disebarkan ke validator lain, validator perlu mencapai konsensus melalui suatu mekanisme, mengenai 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 konkret dari algoritma tersebut, dan algoritma ini tetap terkait dengan algoritma POH. Saat memberikan suara pada blok, jika suara validator itu sendiri adalah suatu transaksi, maka transaksi pengguna dan hash blok yang terbentuk dari transaksi validator juga dapat berfungsi sebagai bukti historis, detail transaksi pengguna serta detail suara validator dapat dikonfirmasi secara unik.
![Mengurai Arsitektur Teknologi Solana: Akankah Menghadapi Musim Semi Kedua?])https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp###
Dalam algoritma Tower BFT, ditetapkan 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 mengkonfirmasi blok. Namun, dalam mekanisme konsensus tradisional, biasanya menggunakan banjir blok, yaitu seorang validator menerima blok dan kemudian mengirimkannya ke validator di sekitarnya, yang dapat menyebabkan banyak redundansi di jaringan, karena seorang validator menerima blok yang sama lebih dari sekali.
Di Solana, adanya banyak transaksi suara validator dan efisiensi yang dibawa oleh sentralisasi node Leader serta waktu Slot 400ms menyebabkan ukuran blok secara keseluruhan dan frekuensi pembuatan blok menjadi sangat tinggi. Blok besar saat disebarkan juga dapat 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 dikenal sebagai Sharding, dengan ukuran spesifikasi maksimum MTU), yang merupakan jumlah data maksimum yang dapat dikirim dari satu node ke node berikutnya tanpa perlu membaginya menjadi unit yang lebih kecil, yaitu ###. 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 transmisi data, 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 berkompatibilitas dengan baik dengan arsitektur Solana saat ini.
Dalam transmisi data di lapisan dasar, biasanya akan mempertimbangkan penggunaan protokol UDP/TCP. Karena toleransi Solana terhadap tingkat kehilangan paket relatif tinggi, maka digunakan protokol UDP untuk transmisi. Kekurangan dari metode ini adalah tidak akan mengirim ulang saat terjadi kehilangan paket, tetapi keuntungannya adalah kecepatan transmisi yang lebih cepat. Sebaliknya, protokol TCP akan mengirim ulang beberapa 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, di lingkungan nyata, throughput dapat meningkat hingga 9 kali lipat.
Setelah Turbine membagi data, mekanisme penyebaran multi-lapis digunakan 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 penghapusan. Setelah itu, validator tersebut akan memulai penyebaran Turbine. Pertama, harus disebarkan ke node akar, kemudian node akar akan menentukan validator mana yang berada di lapisan berapa. Prosesnya adalah sebagai berikut:
Buat daftar node: Node akar akan mengumpulkan semua validator aktif ke dalam satu daftar, kemudian mengurutkannya berdasarkan hak kepemilikan setiap validator di jaringan, yaitu jumlah SOL yang dipertaruhkan (, di mana yang memiliki bobot lebih tinggi akan berada di tingkat pertama, dan seterusnya.
Kelompok Node: Kemudian setiap validator yang berada di lapisan pertama juga akan membuat daftar node mereka sendiri, untuk membangun lapisan pertama mereka sendiri.
Pembentukan lapisan: Dari bagian atas daftar, node dibagi menjadi lapisan, dengan menentukan dua nilai yaitu kedalaman dan lebar, kita dapat menentukan bentuk keseluruhan pohon, parameter ini akan mempengaruhi kecepatan penyebaran shreds.
Node dengan proporsi hak yang tinggi, saat pembagian tingkat, berada di tingkat yang lebih tinggi, maka dapat memperoleh shreds lengkap lebih awal, pada saat ini dapat memulihkan blok lengkap, sedangkan node di tingkat yang lebih rendah, karena kehilangan saat transmisi, kemungkinan mereka untuk mendapatkan shreds lengkap akan berkurang, jika shreds ini tidak cukup untuk membangun potongan lengkap, akan meminta Leader untuk mentransmisikan ulang secara langsung. Maka saat ini transmisi data akan berlangsung ke dalam pohon, dan node di tingkat pertama sudah membangun konfirmasi blok lengkap, semakin lama waktu yang dibutuhkan untuk validator di tingkat yang lebih rendah untuk menyelesaikan pembangunan blok dan melakukan pemungutan suara.
Gagasan dari mekanisme ini mirip dengan mekanisme node tunggal pada node Leader. Dalam proses penyebaran blok, ada beberapa node prioritas yang terlebih dahulu mendapatkan shreds untuk membentuk blok lengkap guna mencapai proses konsensus suara. Mengarahkan redundansi ke tingkat yang lebih dalam dapat secara signifikan mempercepat proses Finality dan memaksimalkan throughput serta efisiensi. Karena pada kenyataannya, beberapa lapisan awal mungkin sudah mewakili 2/3 dari node, maka suara dari node berikutnya menjadi tidak relevan.
) SVM
Solana dapat memproses ribuan transaksi per detik, terutama karena 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 seluruh sistem. Oleh karena itu, untuk SVM, Solana telah mengusulkan mesin eksekusi paralel Sealevel untuk mempercepat kecepatan eksekusi transaksi.
Dalam SVM, instruksi terdiri dari 4 bagian, yang mencakup ID program, instruksi program, serta daftar akun yang membaca/menulis data. Dengan menentukan apakah akun saat ini dalam status membaca atau menulis 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. Dan ini juga merupakan salah satu alasan mengapa persyaratan untuk validator Solana sangat tinggi, karena memerlukan GPU/CPU validator untuk mendukung SIMD### instruksi tunggal banyak data( serta kemampuan ekstensi vektor tingkat lanjut AVX.
Pengembangan Ekosistem
Dalam proses pengembangan ekosistem Solana saat ini, semakin mengarah pada utilitas praktis, seperti Blinks dan Actions bahkan Solana Mobile, dan arah pengembangan aplikasi yang didukung resmi juga lebih condong ke aplikasi konsumen, bukan pengulangan tak terbatas pada infrastruktur. Dengan kinerja Solana yang cukup saat ini, jenis aplikasi menjadi lebih beragam. Sedangkan untuk Ethereum, karena TPS-nya yang lebih rendah, ekosistem Ethereum tetap didominasi oleh infrastruktur dan teknologi skalabilitas. Ketika infrastruktur tidak dapat menopang aplikasi, maka tidak mungkin untuk membangun aplikasi konsumen, yang juga menyebabkan ketidakseimbangan dengan investasi yang terlalu banyak pada infrastruktur tetapi terlalu sedikit pada investasi aplikasi.
) DeFi
Di protokol DeFi di Solana, ada banyak proyek yang belum mengeluarkan token, termasuk Kamino( Lending), Marginfi### Lending + Restaking(, SoLayer) Restaking(, Meteora, dan lain-lain. Karena suasana ekosistem Solana yang bersatu, biasanya ketika sebuah proyek merilis token, proyek lainnya akan berusaha untuk menghindari waktu peluncuran tersebut, untuk menarik perhatian pasar yang cukup.
Saat ini, persaingan di seluruh DEX sangat ketat, dan pemimpin pasar juga telah mengalami beberapa perpindahan, dari Raydium, Orca hingga sekarang di DEX tertentu yang mendominasi.
Perlu dicatat bahwa sekitar 50% dari perdagangan DEX dilakukan oleh bot MEV
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
19 Suka
Hadiah
19
6
Bagikan
Komentar
0/400
staking_gramps
· 07-16 11:08
Kinerja sol sangat memuaskan
Lihat AsliBalas0
0xSunnyDay
· 07-15 15:18
Apakah Downtime King masih membanggakan kinerjanya?
Lihat AsliBalas0
CoconutWaterBoy
· 07-14 03:35
Apakah kamu juga berbicara tentang sol?
Lihat AsliBalas0
SandwichTrader
· 07-14 03:21
Mencegah lebih baik daripada mengobati, pikirkan tentang kegagalan sistem.
Analisis Struktur Teknologi Solana dan Status Perkembangan Ekosistem
Analisis Arsitektur Teknologi Solana dan Perkembangan Ekosistem
Solana adalah platform blockchain berkinerja tinggi yang menggunakan arsitektur teknologi unik untuk mencapai throughput tinggi dan latensi rendah. Teknologi inti 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.
Ekosistem Solana berkembang pesat, berbagai indikator data 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 yang kurang kuat 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.
Meskipun Solana telah mendapatkan pangsa pasar yang signifikan di industri blockchain dengan throughput yang tinggi dan biaya transaksi yang rendah, ia juga menghadapi persaingan ketat dari blockchain publik baru lainnya. Base sebagai pesaing potensial dalam ekosistem EVM, jumlah alamat aktif di jaringannya sedang meningkat dengan cepat, sementara total nilai terkunci (TVL) di bidang DeFi Solana ( telah mencapai rekor tertinggi, tetapi pesaing seperti Base juga dengan cepat mengambil alih pangsa pasar, dan jumlah pendanaan ekosistem Base juga untuk pertama kalinya melampaui Solana di kuartal kedua (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 laju pertumbuhan status, Solana perlu terus mengoptimalkan arsitektur teknologinya dan protokol jaringan untuk mempertahankan posisinya yang terdepan 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. Bagaimana masing-masing komponen bekerja, bagaimana mereka mencapai tujuan kinerja tinggi dalam desain arsitektur, serta kelemahan dan masalah yang muncul dari desain arsitektur tersebut.
) algoritma POH
POH###Proof of History( adalah sebuah 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 diberikan input X, maka hanya ada satu output Y yang unik, oleh karena itu setiap perubahan pada X akan mengakibatkan Y yang sepenuhnya berbeda.
Dalam urutan POH Solana, dengan menerapkan algoritma sha256, kita dapat memastikan integritas seluruh urutan, yang juga memastikan integritas transaksi di dalamnya. Sebagai contoh, jika kita mengemas transaksi menjadi satu blok, menghasilkan nilai hash sha256 yang sesuai, maka transaksi dalam blok tersebut telah ditentukan, setiap perubahan akan menyebabkan perubahan pada nilai hash tersebut, kemudian hash blok ini akan menjadi bagian dari X fungsi sha256 berikutnya, ditambahkan dengan hash blok berikutnya, maka blok sebelumnya dan blok berikutnya akan ditentukan, setiap perubahan akan menghasilkan Y yang berbeda.
Ini adalah makna inti dari teknologi Proof of History, hash blok sebelumnya akan menjadi bagian dari fungsi sha256 berikutnya, mirip dengan rantai, Y terbaru selalu mencakup bukti sejarah.
![Mengurai Arsitektur Teknologi Solana: Apakah Akan Menyambut Musim Kedua?])https://img-cdn.gateio.im/webp-social/moments-83781275d369bad28954d579213dd93e.webp(
Dalam diagram arsitektur aliran transaksi Solana, dijelaskan tentang alur transaksi di bawah mekanisme POH. Dalam mekanisme rotasi yang disebut Leader Rotation Schedule, akan dihasilkan sebuah node Leader dari semua validator di rantai. Node Leader ini mengumpulkan transaksi dan melakukan penyortiran eksekusi, menghasilkan urutan POH, kemudian sebuah blok akan dihasilkan dan disebarkan ke node lainnya.
Untuk menghindari titik kegagalan tunggal di node Leader, maka diperkenalkan batas waktu. Di Solana, unit waktu dibagi berdasarkan epoch, setiap epoch terdiri dari 432.000 slot), setiap slot berlangsung selama 400ms, di setiap slot, sistem rotasi akan mengalokasikan satu node Leader di 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. Satuan waktu dasar Solana adalah Slot, node Leader perlu menyebarkan blok dalam satu slot. Pengguna mengirimkan transaksi melalui node RPC ke Leader, node Leader mengemas transaksi, menyusunnya, kemudian mengeksekusi untuk menghasilkan blok, blok tersebut disebarkan ke validator lain, validator perlu mencapai konsensus melalui suatu mekanisme, mengenai 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 konkret dari algoritma tersebut, dan algoritma ini tetap terkait dengan algoritma POH. Saat memberikan suara pada blok, jika suara validator itu sendiri adalah suatu transaksi, maka transaksi pengguna dan hash blok yang terbentuk dari transaksi validator juga dapat berfungsi sebagai bukti historis, detail transaksi pengguna serta detail suara validator dapat dikonfirmasi secara unik.
![Mengurai Arsitektur Teknologi Solana: Akankah Menghadapi Musim Semi Kedua?])https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp###
Dalam algoritma Tower BFT, ditetapkan 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 mengkonfirmasi blok. Namun, dalam mekanisme konsensus tradisional, biasanya menggunakan banjir blok, yaitu seorang validator menerima blok dan kemudian mengirimkannya ke validator di sekitarnya, yang dapat menyebabkan banyak redundansi di jaringan, karena seorang validator menerima blok yang sama lebih dari sekali.
Di Solana, adanya banyak transaksi suara validator dan efisiensi yang dibawa oleh sentralisasi node Leader serta waktu Slot 400ms menyebabkan ukuran blok secara keseluruhan dan frekuensi pembuatan blok menjadi sangat tinggi. Blok besar saat disebarkan juga dapat 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 dikenal sebagai Sharding, dengan ukuran spesifikasi maksimum MTU), yang merupakan jumlah data maksimum yang dapat dikirim dari satu node ke node berikutnya tanpa perlu membaginya menjadi unit yang lebih kecil, yaitu ###. 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 transmisi data, 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 berkompatibilitas dengan baik dengan arsitektur Solana saat ini.
Dalam transmisi data di lapisan dasar, biasanya akan mempertimbangkan penggunaan protokol UDP/TCP. Karena toleransi Solana terhadap tingkat kehilangan paket relatif tinggi, maka digunakan protokol UDP untuk transmisi. Kekurangan dari metode ini adalah tidak akan mengirim ulang saat terjadi kehilangan paket, tetapi keuntungannya adalah kecepatan transmisi yang lebih cepat. Sebaliknya, protokol TCP akan mengirim ulang beberapa 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, di lingkungan nyata, throughput dapat meningkat hingga 9 kali lipat.
Setelah Turbine membagi data, mekanisme penyebaran multi-lapis digunakan 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 penghapusan. Setelah itu, validator tersebut akan memulai penyebaran Turbine. Pertama, harus disebarkan ke node akar, kemudian node akar akan menentukan validator mana yang berada di lapisan berapa. Prosesnya adalah sebagai berikut:
Buat daftar node: Node akar akan mengumpulkan semua validator aktif ke dalam satu daftar, kemudian mengurutkannya berdasarkan hak kepemilikan setiap validator di jaringan, yaitu jumlah SOL yang dipertaruhkan (, di mana yang memiliki bobot lebih tinggi akan berada di tingkat pertama, dan seterusnya.
Kelompok Node: Kemudian setiap validator yang berada di lapisan pertama juga akan membuat daftar node mereka sendiri, untuk membangun lapisan pertama mereka sendiri.
Pembentukan lapisan: Dari bagian atas daftar, node dibagi menjadi lapisan, dengan menentukan dua nilai yaitu kedalaman dan lebar, kita dapat menentukan bentuk keseluruhan pohon, parameter ini akan mempengaruhi kecepatan penyebaran shreds.
Node dengan proporsi hak yang tinggi, saat pembagian tingkat, berada di tingkat yang lebih tinggi, maka dapat memperoleh shreds lengkap lebih awal, pada saat ini dapat memulihkan blok lengkap, sedangkan node di tingkat yang lebih rendah, karena kehilangan saat transmisi, kemungkinan mereka untuk mendapatkan shreds lengkap akan berkurang, jika shreds ini tidak cukup untuk membangun potongan lengkap, akan meminta Leader untuk mentransmisikan ulang secara langsung. Maka saat ini transmisi data akan berlangsung ke dalam pohon, dan node di tingkat pertama sudah membangun konfirmasi blok lengkap, semakin lama waktu yang dibutuhkan untuk validator di tingkat yang lebih rendah untuk menyelesaikan pembangunan blok dan melakukan pemungutan suara.
Gagasan dari mekanisme ini mirip dengan mekanisme node tunggal pada node Leader. Dalam proses penyebaran blok, ada beberapa node prioritas yang terlebih dahulu mendapatkan shreds untuk membentuk blok lengkap guna mencapai proses konsensus suara. Mengarahkan redundansi ke tingkat yang lebih dalam dapat secara signifikan mempercepat proses Finality dan memaksimalkan throughput serta efisiensi. Karena pada kenyataannya, beberapa lapisan awal mungkin sudah mewakili 2/3 dari node, maka suara dari node berikutnya menjadi tidak relevan.
) SVM
Solana dapat memproses ribuan transaksi per detik, terutama karena 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 seluruh sistem. Oleh karena itu, untuk SVM, Solana telah mengusulkan mesin eksekusi paralel Sealevel untuk mempercepat kecepatan eksekusi transaksi.
Dalam SVM, instruksi terdiri dari 4 bagian, yang mencakup ID program, instruksi program, serta daftar akun yang membaca/menulis data. Dengan menentukan apakah akun saat ini dalam status membaca atau menulis 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. Dan ini juga merupakan salah satu alasan mengapa persyaratan untuk validator Solana sangat tinggi, karena memerlukan GPU/CPU validator untuk mendukung SIMD### instruksi tunggal banyak data( serta kemampuan ekstensi vektor tingkat lanjut AVX.
Pengembangan Ekosistem
Dalam proses pengembangan ekosistem Solana saat ini, semakin mengarah pada utilitas praktis, seperti Blinks dan Actions bahkan Solana Mobile, dan arah pengembangan aplikasi yang didukung resmi juga lebih condong ke aplikasi konsumen, bukan pengulangan tak terbatas pada infrastruktur. Dengan kinerja Solana yang cukup saat ini, jenis aplikasi menjadi lebih beragam. Sedangkan untuk Ethereum, karena TPS-nya yang lebih rendah, ekosistem Ethereum tetap didominasi oleh infrastruktur dan teknologi skalabilitas. Ketika infrastruktur tidak dapat menopang aplikasi, maka tidak mungkin untuk membangun aplikasi konsumen, yang juga menyebabkan ketidakseimbangan dengan investasi yang terlalu banyak pada infrastruktur tetapi terlalu sedikit pada investasi aplikasi.
) DeFi
Di protokol DeFi di Solana, ada banyak proyek yang belum mengeluarkan token, termasuk Kamino( Lending), Marginfi### Lending + Restaking(, SoLayer) Restaking(, Meteora, dan lain-lain. Karena suasana ekosistem Solana yang bersatu, biasanya ketika sebuah proyek merilis token, proyek lainnya akan berusaha untuk menghindari waktu peluncuran tersebut, untuk menarik perhatian pasar yang cukup.
Saat ini, persaingan di seluruh DEX sangat ketat, dan pemimpin pasar juga telah mengalami beberapa perpindahan, dari Raydium, Orca hingga sekarang di DEX tertentu yang mendominasi.
Perlu dicatat bahwa sekitar 50% dari perdagangan DEX dilakukan oleh bot MEV