Hari ini kita lanjutkan membahas Sonic, proyek memasukkan wine lama ke dalam botol baru. Sudah cukup populer dalam dua hari terakhir, karena besok akan ada TGE (Token Generation Event) dan akan diberikan airdrop. Sonic adalah L2 dari Sol. Semua orang terkejut bahwa SOL secepat itu masih membutuhkan L2? Bukankah ini hot spot yang dibutuhkan oleh kalangan mata uang?
Jadi mengapa SOL membutuhkan L2?
Ketika aktivitas dAPP dan DeFi di Solana tumbuh lebih cepat, transaksi on-chain harian melebihi 200 juta pada bulan Januari 2024, dan beberapa analis secara konservatif memperkirakan bahwa volume transaksi akan melebihi 4 miliar pada tahun 2026.
Di bawah tekanan yang dapat diperkirakan ini, TPS Solana berada di kisaran 2500-4000, dan waktu ping rata-rata cluster Solana berfluktuasi antara 6 detik dan 80 detik; ketika TPS menjadi semakin jenuh atau bahkan melebihi 4000, tingkat keberhasilan transaksi Solana hanya mencapai 70% hingga 85. %.
Selain keterlambatan fisik dan fluktuasi jaringan yang disebabkan oleh kondisi jaringan, jelas bahwa penyebab utama terkait dengan peningkatan saturasi TPS. Berdasarkan tren pertumbuhan Solana, diprediksi nilai TPS dalam beberapa tahun ke depan akan mencapai 10.000 hingga puluhan ribu, yang akan menyebabkan masalah kinerja yang lebih jelas.
Di atas adalah jawaban yang diberikan oleh whitepaper Sonic, sementara saya di sini menambahkan sedikit:
1. Dalam laporan Messari tentang Ethereum L2 yang diterbitkan dua hari lalu, disebutkan bahwa saat ini L1 yang paling cocok masih menekankan penyelesaian yang aman, dan aplikasi lebih baik ditempatkan di L2.
2. Saat ini Sonic lebih fokus pada blockchain game, menekankan game full-chain, jika benar ada 100.000 orang, atau jutaan orang online dalam game blockchain, jika data sepenuhnya on-chain, maka ribuan atau puluhan ribu TPS tidak dapat menampung, sehingga memang diperlukan L2 yang lebih cepat dan lebih murah.
Satu. Pendahuluan
Sonic adalah rantai SVM atom pertama (apa yang dimaksud dengan interoperabilitas atom adalah bahwa akun dan program dapat saling berkomunikasi dengan SOL), dan juga L2 tercepat di Solana, Sonic dibangun di atas kerangka perluasan konkuren HyperGrid pertama di Solana. Dengan interpreter HyperGrid, dApp dapat dengan mudah dikerahkan dari rantai EVM ke Solana, jadi ia kompatibel dengan EVM dan juga SOL.
Sonic di blockchain berdasarkan kerangka ECS yang secara publik menyediakan primitif game asli yang dapat digabungkan dan tipe data yang dapat diperluas. Sandbox mesin game menyediakan alat praktis bagi pengembang untuk membantu mereka membangun logika bisnis di blockchain.
Dua. Kerangka Rush ECS
Rush adalah kerangka kerja deklaratif cepat yang sepenuhnya dibangun dengan Rust untuk sistem entitas-komponen (Entity-Component-System, ECS) yang bertujuan tunggal: meminimalkan kompleksitas integrasi teknologi blockchain dengan alat yang akrab bagi pengembang (seperti SDK dan API mesin game) melalui teknik abstraksi pengalaman pengembangan yang terverifikasi.
Rush memproyeksikan masa depan: setiap game yang telah dibangun atau akan dibangun, dapat dengan mudah diubah menjadi game full-chain (Fully-Onchain Game) atau dunia otonom (Autonomous World) melalui Rush dan tumpukan teknologi pengembangan game yang mereka suka.
Cara kerja Rush
Umumnya, pengembang game menggunakan mesin game untuk membuat game.
Dengan bantuan mesin game, kompleksitas logika dasar sangat berkurang, pengembang dapat fokus pada desain dan mekanisme permainan, sementara kompleksitas ditangani oleh mesin game.
Di sisi lain, implementasi game full-chain (FOCG) dan dunia otonom (AW) harus bergantung pada penyimpanan data terdesentralisasi, seperti blockchain.
Karakteristik desentralisasi ini membuat ketahanan data jauh lebih baik daripada satu repositori data, tetapi ini juga disertai dengan biaya tambahan.
Masalah yang dihadapi pengembang
Untuk mewujudkan FOCG atau AW, pengembang game perlu menguasai teknologi blockchain full stack atau mempekerjakan ahli blockchain.
Baik itu belajar atau mempekerjakan, ini memerlukan banyak sumber daya, dan sering kali merupakan hambatan besar bagi pengembang game menuju game full-chain atau dunia otonom.
Rush diciptakan untuk menyelesaikan masalah ini.
Ini dilakukan melalui teknik abstraksi pengalaman pengembangan yang efisien dan terverifikasi, seperti:
- Konfigurasi deklaratif (Declarative Configuration)
- Entitas-Komponen-Sistem (Entity-Component-System, ECS)
- Generasi kode (Code Generation)
Dengan demikian sangat menyederhanakan kompleksitas.
Tiga. Kerangka HyperGrid
Protokol HyperGrid adalah kerangka kerja Rollup yang diperluas dan diorkestrasi, dirancang untuk mendukung operator Rollup dari ekosistem SVM. Ini mencapai potensi throughput transaksi yang tidak terbatas melalui kompresi status (State Compression) dan teknologi toleransi kesalahan Byzantine (Byzantine Fault Tolerance, BFT). Ini dilakukan dengan mengimplementasikan skala horizontal antar beberapa grid (Grids), seperti yang ditunjukkan oleh Sonic (grid yang berfokus pada game), yang transaksi akhirnya diselesaikan di Solana.
3.1 Gambaran arsitektur
Gambaran arsitektur multi-grid HyperGrid: grid semi-otonom mencapai konsensus dan finalitas melalui Solana.
Arsitektur HyperGrid didasarkan pada mode multi-grid, di mana setiap grid beroperasi secara semi-otonom, sambil mencapai konsensus dan finalitas melalui jaringan utama Solana.
3.2 Arsitektur sistem HyperGrid
Komponen kunci
1. Lapisan dasar Solana:
- Dasar sistem HyperGrid, menyediakan konsensus akhir dan finalitas data.
2. Jaringan berbagi status HyperGrid (HSSN):
- Inti sistem, berjalan di seluruh grid.
- Termasuk beberapa validator (Validator 1 hingga Validator N).
- Berbagi status antara grid dan lapisan dasar Solana.
- Mengelola bukti nol-pengetahuan (ZK Proofs) batch yang digunakan untuk penyelesaian.
3. Struktur grid (dengan contoh Grid 1 dan Grid 2):
- Setiap grid mewakili ekosistem semi-otonom yang dapat dikhususkan untuk aplikasi tertentu (seperti berbagai game).
- Komponen dari setiap grid mencakup:
- Prosesor ZK: Mengelola operasi khusus grid dan bukti Merkle.
- Runtime SVM: Menjalankan operasi grid di mesin virtual Solana.
- Mesin Gas Sonic: Mengelola sumber daya komputasi.
- Generator pohon Merkle bersamaan: Mengelola transisi status secara efisien.
4. Interaksi pengguna:
- Pengguna dapat berinteraksi secara mandiri dengan setiap grid.
- Transaksi (termasuk transaksi SVM dan EVM) berputar antara pengguna dan waktu operasi grid yang sesuai.
- Respons transaksi dikembalikan kepada pengguna.
3.2 Aliran data
Interoperabilitas dan berbagi status:
- Berbagi status dua arah antara lapisan dasar Solana dan HSSN.
- HSSN akan berbagi status dengan setiap grid.
- Berbagi status juga dapat terjadi antar grid.
3.4 Bukti ZK:
1. Transaksi dikompresi dan digabungkan ke dalam pohon Merkle.
2. Untuk setiap blok, kirim nilai hash status root yang sesuai.
3. Bukti validitas (Validity Proof) dihitung di grid.
4. HSSN menggunakan bukti ZK untuk penyelesaian dan diserahkan ke lapisan dasar Solana.
Empat. Komunikasi jaringan dan grid
Arsitektur jaringan HyperGrid: hubungan antara jaringan berbagi status, instance grid, dan lapisan dasar Solana, mendukung penerapan dApp yang dapat diskalakan.
Aliran data dari jaringan berbagi status HyperGrid
Kerangka HyperGrid dirancang untuk mendukung berbagai jaringan aplikasi spesifik atau aplikasi terdesentralisasi (dApp), dengan fokus khusus pada aplikasi yang banyak diminati dalam ekosistemnya, seperti game, DeFi, agen AI, dll.
Tujuan dari arsitektur ini termasuk:
1. Mengurangi tekanan kinerja pada lapisan dasar Solana.
2. Meminimalkan konflik dan persaingan kinerja yang disebabkan oleh perebutan ruang blok antara lapisan dasar dan berbagai dApp spesifik.
Fitur kunci
1. Fleksibilitas, memberikan pilihan kepada pembuat jaringan grid:
- Pengembang dapat memilih:
- Menggunakan jaringan publik HyperGrid.
- Skala horizontal untuk membuat jaringan eksklusif yang dikhususkan untuk kebutuhan tertentu.
2. Optimalisasi kinerja dan biaya:
- Pilihan antara jaringan publik dan jaringan eksklusif tergantung pada evaluasi pengembang terhadap kebutuhan kinerja dan biaya terkait.
3. Kemandirian jaringan:
- Pengembang dapat menonaktifkan jaringan eksklusif mereka kapan saja tanpa mempengaruhi jaringan lain dalam ekosistem.
Kerangka operasi
1. Verifikasi:
- Setiap jaringan secara mandiri menangani verifikasi transaksi dan perubahan statusnya.
2. Pencatatan:
- Setiap jaringan secara mandiri memelihara log transaksi dan perubahan statusnya.
3. Pengambilan data:
- Proses pengambilan data dilakukan secara mandiri di setiap jaringan.
Lima. Interoperabilitas dengan Solana
5.1 Membaca data dari Solana ke HyperGrid
Gambar di atas menunjukkan proses berikut saat melakukan sinkronisasi status dari Solana ke grid di HyperGrid (seperti Sonic).
Pemuatan awal: Memuat program yang sudah ada dari penyimpanan ke dalam cache HyperGrid.
Pengguna mengirimkan permintaan bacaan untuk program tertentu ke Sonic RPC HyperGrid.
Program sinkronisasi memeriksa apakah program yang diminta ada dalam cache, tetapi tidak ditemukan.
Program sinkronisasi mengirimkan permintaan program ke RPC lapisan dasar Solana.
Lapisan dasar Solana menggunakan data program untuk memberi respons.
Program sinkronisasi menerima respons dan menggunakan data program baru untuk memperbarui cache HyperGrid.
Program sinkronisasi mengirimkan respons bacaan kembali ke Sonic RPC.
Sonic RPC akan meneruskan respons bacaan kepada pengguna.
5.2 Memperbarui sinkronisasi kembali ke lapisan dasar Solana
Gambar di atas menunjukkan proses berikut saat melakukan sinkronisasi status dari grid di HyperGrid (seperti Sonic) kembali ke Solana.
Pemuatan awal: Memuat program yang sudah ada dari penyimpanan ke dalam cache HyperGrid.
Pengguna mengirimkan permintaan penulisan untuk program tertentu ke Sonic RPC HyperGrid.
Program sinkronisasi memeriksa apakah program yang diminta ada dalam cache, tetapi tidak ditemukan.
Program sinkronisasi mengirimkan permintaan untuk mengunci program di lapisan dasar Solana.
RPC Lapisan Dasar Solana mengunci permintaan program.
Lapisan dasar Solana menggunakan data program untuk memberi respons.
Program sinkronisasi menerima respons dan menggunakan data program baru untuk memperbarui cache HyperGrid.
Program sinkronisasi mengirimkan permintaan untuk melepaskan kunci dan menulis data pembaruan program ke lapisan dasar Solana.
Lapisan dasar Solana melepaskan kunci dan menulis data yang diperbarui.
Program sinkronisasi mengirimkan respons penulisan kembali ke Sonic RPC.
Sonic RPC akan meneruskan respons penulisan kepada pengguna.
Enam. Jaringan berbagi status HyperGrid (HSSN)
Jaringan berbagi status HyperGrid (HSSN) adalah komponen kunci dalam ekosistem Grid. Ini berfungsi sebagai lapisan konsensus, pusat komunikasi, dan kluster manajemen status, memfasilitasi interaksi antara Grid dan lapisan dasar Solana. Jaringan ini mengelola semua status komunikasi, termasuk secara berkala menyinkronkan data blok dari Rollup Grid ke lapisan dasar Solana.
Komponen utama dan fungsinya
Arsitektur HSSN: Dibangun di atas kerangka Cosmos, menjamin keandalan dan keamanan komunikasi lintas rantai.
Struktur data: Mengelola status antara grid dan lapisan dasar Solana, termasuk:
- Pendaftaran jaringan
- Sumber data komunikasi
- Kontrol versi
- Membaca/Menulis status
- Memperluas kolom data akun: Meningkatkan kolom data akun dasar Solana untuk menampung kolom baru manajemen HSSN, memastikan sinkronisasi dengan status akun grid.
- RPC grid yang direkonstruksi: Mewujudkan komunikasi langsung antara grid dan HSSN, memfasilitasi interoperabilitas dalam ekosistem.
Mekanisme pengisian dan distribusi GAS: Pengguna membayar biaya gas untuk permintaan tertentu dari jaringan, grid khusus (Sonic Grid) menjalankan program perhitungan gas, mengelola semua gas dalam ekosistem jaringan secara terpusat.
Situasi pendanaan proyek
Sonic menyelesaikan pendanaan putaran A sebesar 12 juta dolar AS, dengan Bitkraft Ventures sebagai pemimpin putaran ini, diikuti oleh Galaxy Interactive, BigBrain Holdings, dan perusahaan lainnya, saat ini valuasinya 120 juta dolar AS.
TGE:
Total pasokan SONIC adalah 2,4 miliar, di mana 57% dialokasikan untuk komunitas, termasuk pengembangan komunitas dan ekosistem (30%), klaim awal (7%) dan hadiah HyperGrid (20%). TGE dijadwalkan pada 7 Januari 2025, dengan sirkulasi awal mencapai 15% dari total. SONIC akan didistribusikan dalam 6 tahun, pada saat itu semua SONIC akan sepenuhnya beredar, di mana sebagian besar dialokasikan untuk komunitas. Dalam 12-18 bulan setelah peluncuran, tidak akan ada token tim dan investor yang dibuka, dan token yang terkunci tidak dapat dipertaruhkan.
Sebagai ringkasan akhir proyek ini, SOL mulai meluncurkan L2, jadi saat ini sepertinya semua blockchain dengan kecepatan tinggi memiliki kebutuhan L2. Berdasarkan logika ini, arsitektur multi-chain dari avax sebenarnya menunjukkan bahwa itu berguna, dan L2 SOL mungkin akan bangkit.