Oggi continuiamo a parlare di un progetto dal sapore nuovo, Sonic, che negli ultimi giorni ha suscitato molto interesse, poiché domani si svolgerà il TGE (Token Generation Event) e ci sarà anche un airdrop. Sonic è l'L2 di SOL, ed è sorprendente che un SOL così veloce abbia bisogno di L2? Non è proprio ciò di cui ha bisogno il settore delle criptovalute?
Quindi perché SOL ha bisogno di L2?
Con l'aumento più rapido delle attività dAPP e DeFi su Solana, a gennaio 2024 il numero di transazioni giornaliere sulla catena ha già superato le 200 milioni, con gli analisti che stimano conservativamente che nel 2026 il volume delle transazioni supererà i 4 miliardi.
Sotto questa pressione prevedibile, il TPS di Solana è di circa 2500-4000, con tempi di ping medi del cluster di Solana che oscillano tra 6 e 80 secondi; quando il TPS è sempre più saturo o supera i 4000, il tasso di successo delle transazioni di Solana scende solo al 70%-85%.
Oltre ai ritardi fisici e alle fluttuazioni della rete causate dalle condizioni di rete, è evidente che la causa principale è legata all'aumento costante della saturazione del TPS. Secondo la traiettoria di crescita di Solana, si prevede che nei prossimi anni il valore TPS raggiunga da 10.000 a decine di migliaia, il che porterà a problemi di prestazioni più evidenti.
Quello sopra è la risposta fornita dal white paper di Sonic, e qui aggiungo un punto:
1. Nei rapporti di Messari sui L2 di Ethereum nei giorni scorsi, si è affermato che attualmente L1 è più adatta per la liquidazione sicura, mentre è meglio posizionare le applicazioni su L2.
2. Sonic si concentra attualmente sulla blockchain per giochi, puntando a giochi completamente on-chain, se ci sono davvero 100.000 o milioni di giocatori online, se i dati sono tutti on-chain, allora migliaia o decine di migliaia di TPS non reggeranno, quindi c'è realmente bisogno di un L2 più veloce e conveniente.
Uno. Introduzione
Sonic è la prima catena SVM atomica (cosa significa interoperabilità atomica, ovvero conti e programmi comunicano con sol), ed è anche il L2 più veloce di Solana. Sonic è costruito sopra il primo framework di scalabilità concorrente di Solana, HyperGrid. Grazie all'interprete di HyperGrid, è facile distribuire dApp da una catena EVM a Solana, quindi è compatibile sia con EVM che con SOL.
Sonic pubblica primitive di gioco native combinabili e tipi di dati scalabili sulla catena basati sul framework ECS. Il sandbox del motore di gioco fornisce strumenti pratici agli sviluppatori, aiutandoli a costruire la logica aziendale sulla catena.
Due. Rush framework ECS
Rush è un framework Entity-Component-System (ECS) completamente costruito in Rust, il cui unico obiettivo è: minimizzare la complessità di integrazione della tecnologia blockchain con strumenti familiari agli sviluppatori (come SDK e API dei motori di gioco) attraverso l'adozione di tecnologie di esperienza di sviluppo verificate.
Rush guarda a un futuro: qualsiasi gioco già costruito o in via di costruzione, può facilmente essere trasformato in un gioco completamente on-chain (Fully-Onchain Game) o in un mondo autonomo (Autonomous World) tramite Rush e il loro stack tecnologico preferito per lo sviluppo di giochi.
Come funziona Rush
Di solito, gli sviluppatori di giochi utilizzano motori di gioco per creare giochi.
Grazie ai motori di gioco, la complessità della logica di base è notevolmente ridotta, consentendo agli sviluppatori di concentrarsi sul design e meccaniche di gioco, mentre la complessità è gestita dal motore di gioco.
D'altra parte, l'implementazione di giochi full chain (FOCG) e mondi autonomi (AW) deve fare affidamento su archiviazione dati decentralizzata, come la blockchain.
Questa caratteristica decentralizzata rende la persistenza dei dati molto superiore a quella di un singolo repository di dati, ma comporta anche costi aggiuntivi.
Problemi affrontati dagli sviluppatori
Per implementare FOCG o AW, gli sviluppatori di giochi devono padroneggiare la tecnologia blockchain full stack o assumere esperti di blockchain.
Sia che si tratti di apprendimento o assunzione, richiede molte risorse ed è spesso un grande ostacolo per gli sviluppatori di giochi nel passare a giochi full chain o mondi autonomi.
Rush è nato proprio per risolvere questo problema.
Si basa su esperienze di sviluppo verificate e ad alta efficienza, come:
- Configurazione dichiarativa (Declarative Configuration)
- Entità-Componente-Sistema (Entity-Component-System, ECS)
- Generazione di codice (Code Generation)
Riducendo così notevolmente la complessità.
Tre. Framework HyperGrid
Il protocollo HyperGrid è un framework di espansione e orchestrazione Rollup, progettato per supportare gli operatori Rollup dell'ecosistema SVM. Realizza un potenziale throughput di transazione illimitato attraverso la compressione dello stato (State Compression) e la tolleranza agli errori bizantini (Byzantine Fault Tolerance, BFT). Questo è realizzato attraverso l'implementazione della scalabilità orizzontale tra diverse reti (Grids), come dimostrato da Sonic (una rete focalizzata sui giochi), le cui transazioni vengono infine liquidate su Solana.
3.1 Panoramica dell'architettura
Panoramica dell'architettura multi-rete di HyperGrid: reti semi-autonome che realizzano consenso e finalità tramite Solana.
L'architettura di HyperGrid è basata su un modello multi-rete (multi-grid), in cui ogni rete opera in modo semi-autonomo mentre realizza consenso e finalità attraverso la rete principale di Solana.
3.2 Architettura del sistema HyperGrid
Componenti chiave
1. Base di Solana:
- La base del sistema HyperGrid, fornendo consenso finale e finalità dei dati.
2. Rete di condivisione dello stato HyperGrid (HSSN):
- Il nucleo del sistema, che opera su tutte le reti.
- Comprende più validatori (Validator 1 a Validator N).
- Condivisione dello stato tra la rete e la base di Solana.
- Gestisce le prove zero-knowledge (ZK Proofs) per la liquidazione.
3. Struttura della rete (prendendo Grid 1 e Grid 2 come esempio):
- Ogni rete rappresenta un ecosistema semi-autonomo, specializzato in applicazioni specifiche (come diversi giochi).
- Le componenti di ogni rete includono:
- ZK co-processore: gestisce operazioni specifiche della rete e prove Merkle.
- Runtime SVM: esegue operazioni di rete sulla Solana Virtual Machine.
- Motore Sonic Gas: gestisce le risorse di calcolo.
- Generatore di alberi Merkle concorrenti: gestisce efficientemente le transizioni di stato.
4. Interazione degli utenti:
- Gli utenti possono interagire in modo indipendente con ciascuna rete.
- Le transazioni (incluse le transazioni SVM ed EVM) circolano tra l'utente e il runtime della rete corrispondente.
- Le risposte alle transazioni vengono restituite agli utenti.
3.2 Flusso di dati
Interoperabilità e condivisione dello stato:
- Condivisione bidirezionale dello stato tra la base di Solana e HSSN.
- HSSN condivide lo stato con ogni rete.
- La condivisione dello stato può avvenire anche tra diverse reti.
3.4 Prove ZK:
1. Le transazioni vengono compresse e aggregate in un albero Merkle.
2. Per ogni blocco, inviare il corrispondente valore hash di stato radice.
3. Prova di validità (Validity Proof) calcolata sulla rete.
4. HSSN utilizza prove ZK per la liquidazione e l'invio alla base di Solana.
Quattro. Comunicazione tra reti e grid
L'architettura della rete HyperGrid: la rete di condivisione dello stato, le istanze della rete e la relazione con la base di Solana forniscono supporto per il deployment scalabile delle dApp.
Flusso di dati della rete di condivisione dello stato HyperGrid
Il framework HyperGrid è progettato per supportare una vasta gamma di reti specifiche per applicazioni o applicazioni decentralizzate (dApp), con particolare attenzione alle applicazioni ad alta domanda all'interno del suo ecosistema, come giochi, DeFi, agenti AI, ecc.
Gli obiettivi di questa architettura includono:
1. Ridurre la pressione sulle prestazioni della base di Solana.
2. Minimizzare i conflitti e la competizione per le prestazioni causati dalla contesa per lo spazio nel blocco tra la base e vari dApp specifici.
Caratteristiche chiave
1. Flessibilità, fornendo opzioni ai creatori di reti grid:
- Gli sviluppatori possono scegliere:
- Utilizzando la rete pubblica di HyperGrid.
- Scalabilità orizzontale per creare reti dedicate a esigenze specifiche.
2. Ottimizzazione delle prestazioni e dei costi:
- La scelta tra rete pubblica e rete dedicata dipende dalla valutazione da parte degli sviluppatori delle esigenze di prestazioni e dei costi associati.
3. Indipendenza della rete:
- Gli sviluppatori possono disattivare la propria rete dedicata in qualsiasi momento senza influenzare altre reti all'interno dell'ecosistema.
Framework operativo
1. Verifica:
- Ogni rete gestisce autonomamente la verifica delle proprie transazioni e modifiche di stato.
2. Registrazione:
- Ogni rete mantiene in modo indipendente il proprio registro di transazioni e modifiche di stato.
3. Recupero dei dati:
- Il processo di recupero dei dati viene eseguito in modo indipendente in ciascuna rete.
Cinque. Interoperabilità con Solana
5.1 Leggere i dati da Solana a HyperGrid
L'immagine sopra illustra il seguente processo quando si esegue la sincronizzazione dello stato da Solana a una rete su HyperGrid (come Sonic).
Caricamento iniziale: caricare i programmi preesistenti dalla memoria nella cache di HyperGrid.
Gli utenti inviano richieste di lettura per programmi specifici al Sonic RPC di HyperGrid.
I programmi di sincronizzazione controllano se il programma richiesto è presente nella cache, ma non è stato trovato.
I programmi di sincronizzazione inviano richieste di programma al RPC di base di Solana.
La base di Solana utilizza i dati del programma per rispondere.
I programmi di sincronizzazione ricevono una risposta e utilizzano i nuovi dati del programma per aggiornare la cache di HyperGrid.
I programmi di sincronizzazione inviano le risposte di lettura al Sonic RPC.
Il Sonic RPC inoltra la risposta di lettura all'utente.
5.2 Sincronizzazione degli aggiornamenti sulla base di Solana
L'immagine sopra illustra il seguente processo quando si esegue la sincronizzazione dello stato da una rete su HyperGrid (come Sonic) di ritorno a Solana.
Caricamento iniziale: caricare i programmi preesistenti dalla memoria nella cache di HyperGrid.
Gli utenti inviano richieste di scrittura per programmi specifici al Sonic RPC di HyperGrid.
I programmi di sincronizzazione controllano se il programma richiesto è presente nella cache, ma non è stato trovato.
I programmi di sincronizzazione inviano richieste, bloccando i programmi sulla base di Solana.
Il RPC della base di Solana blocca le richieste del programma.
La base di Solana utilizza i dati del programma per rispondere.
I programmi di sincronizzazione ricevono una risposta e utilizzano i nuovi dati del programma per aggiornare la cache di HyperGrid.
I programmi di sincronizzazione inviano richieste per rilasciare i blocchi e scrivere i dati aggiornati del programma nella base di Solana.
La base di Solana RPC rilascia i blocchi e scrive i dati aggiornati.
I programmi di sincronizzazione inviano le risposte di scrittura al Sonic RPC.
Il Sonic RPC inoltra le risposte di scrittura all'utente.
Sei. Rete di condivisione dello stato HyperGrid (HSSN)
La rete di condivisione dello stato HyperGrid (HSSN) è una componente chiave nell'ecosistema Grid. Funziona come livello di consenso, centro di comunicazione e cluster di gestione dello stato, facilitando l'interazione tra Grid e la base di Solana. Questa rete gestisce lo stato di tutta la comunicazione, inclusa la sincronizzazione periodica dei dati di blocco dai Rollup di Grid alla base di Solana.
Componenti e funzionalità principali
Architettura HSSN: costruita sulla base del framework Cosmos, garantisce l'affidabilità e la sicurezza della comunicazione cross-chain.
Struttura dei dati: gestisce lo stato tra la rete e la base di Solana, includendo:
- Registrazione della rete
- Sorgente dati di comunicazione
- Controllo delle versioni
- Lettura/Scrittura dello stato
- Espansione dei campi dati degli account: potenziare i campi dati degli account della base di Solana per adattarsi ai nuovi campi di gestione HSSN, garantendo la sincronizzazione con lo stato degli account della rete.
- RPC della rete ristrutturata: consente comunicazioni dirette tra la rete e HSSN, facilitando l'interoperabilità all'interno dell'ecosistema.
Meccanismo di caricamento e distribuzione del GAS: gli utenti pagano le spese di gas per alcune richieste di rete, una rete dedicata (Sonic Grid) esegue programmi di calcolo del gas, gestendo centralmente il gas dell'intero ecosistema di rete.
Situazione di finanziamento del progetto
Sonic ha completato un round di finanziamento di Serie A da 12 milioni di dollari, guidato da Bitkraft Ventures, con partecipazioni di Galaxy Interactive, BigBrain Holdings e altre, attualmente valutato 120 milioni di dollari.
TGE:
La fornitura totale di SONIC è di 2,4 miliardi di token, di cui il 57% è assegnato alla comunità, comprendente sviluppo della comunità ed ecologia (30%), reclamo iniziale (7%) e premi HyperGrid (20%). Il TGE è previsto per il 7 gennaio 2025, con un volume circolante iniziale che rappresenta il 15% del totale. SONIC sarà distribuito entro 6 anni, momento in cui tutti i SONIC saranno completamente circolanti, con la maggior parte assegnata alla comunità. Nei primi 12-18 mesi dopo il lancio, non verrà sbloccato alcun token per team e investitori, i token bloccati non possono essere messi in staking.
Alla fine, riassumiamo questo progetto, SOL ha iniziato a lanciare L2, quindi attualmente tutte le blockchain veloci dovrebbero avere una domanda di L2. Seguendo questa logica, l'architettura multi-chain di avax è effettivamente utile, e L2 di SOL potrebbe emergere.
