Aujourd'hui, continuons à parler d'un projet ancien sous un nouveau flacon, Sonic, qui a récemment suscité pas mal d'attention, car demain aura lieu le TGE (Token Generation Event) et il y aura également un airdrop. Sonic est le L2 de Sol, et il est surprenant que le SOL si rapide ait besoin d'un L2 ? N'est-ce pas exactement le type de sujet dont le monde des cryptos a besoin ?
Alors pourquoi SOL a-t-il besoin de L2 ?
Avec l'accélération des dAPP et des activités DeFi sur Solana, les transactions quotidiennes sur la chaîne ont déjà dépassé les 200 millions en janvier 2024, et certains analystes estiment de manière conservatrice que le volume des transactions dépassera 4 milliards d'ici 2026.
Dans cette pression prévisible, le TPS de Solana tourne autour de 2500-4000, le temps de ping moyen du cluster Solana fluctuant entre 6 et 80 secondes ; lorsque le TPS atteint une saturation croissante ou même dépasse 4000, le taux de succès des transactions Solana n'atteint que 70 % à 85 %.
À part le retard physique et les fluctuations du réseau causées par les conditions du réseau, la principale raison est clairement liée à l'augmentation continue de la saturation du TPS. Selon les tendances de croissance de Solana, il est prévu que la valeur TPS atteigne entre 10 000 et plusieurs dizaines de milliers dans les prochaines années, ce qui entraînera des problèmes de performance plus évidents.
Ce qui précède est la réponse fournie par le livre blanc de Sonic, et je vais y ajouter un point :
1. Dans le rapport de Messari sur les L2 d'Ethereum des deux derniers jours, il a été mentionné que le L1 actuel est encore mieux adapté à un règlement sécurisé, et qu'il est préférable de placer les applications sur L2.
2. Sonic se concentre actuellement sur la blockchain de jeux, visant à être la chaîne pour les jeux entièrement sur chaîne. Si nous avons vraiment 100 000 ou un million d'utilisateurs en ligne, si les données sont entièrement sur chaîne, alors quelques milliers ou dizaines de milliers de TPS ne suffiront pas, c'est pourquoi nous avons vraiment besoin d'un L2 plus rapide et moins cher.
Un. Introduction
Sonic est la première chaîne SVM atomique (ce qu'on appelle l'interopérabilité atomique, c'est-à-dire que les comptes et les programmes communiquent avec sol), et c'est également le L2 le plus rapide de Solana. Sonic est construit sur le premier cadre d'expansion concurrente de Solana, HyperGrid. Grâce à l'interpréteur de HyperGrid, il est facile de déployer des dApps depuis des chaînes EVM vers Solana, donc il est compatible à la fois avec EVM et avec SOL.
Sonic expose des primitives de jeu natif et des types de données extensibles basés sur le cadre ECS sur la chaîne. Le bac à sable du moteur de jeu fournit aux développeurs des outils pratiques pour les aider à construire la logique métier sur la chaîne.
Deux. Rush ECS framework
Rush est un cadre déclaratif rapide de système entité-composant (Entity-Component-System, ECS) entièrement construit en Rust, dont le seul objectif est de réduire au minimum la complexité d'intégration de la technologie blockchain avec des outils familiers aux développeurs (comme les SDK et API de moteurs de jeux) en adoptant des techniques d'expérience de développement validées.
Rush envisage un avenir où tout jeu déjà construit ou en cours de construction peut facilement être transformé en jeu entièrement sur chaîne (Fully-Onchain Game) ou monde autonome (Autonomous World) grâce à Rush et à leur technologie de développement de jeux préférée.
Fonctionnement de Rush
En général, les développeurs de jeux utilisent des moteurs de jeux pour créer des jeux.
Grâce aux moteurs de jeux, la complexité de la logique sous-jacente est considérablement réduite, permettant aux développeurs de se concentrer sur la conception et les mécanismes de jeu, tandis que la complexité est gérée par le moteur de jeu.
D'un autre côté, la réalisation de jeux entièrement sur chaîne (FOCG) et de mondes autonomes (AW) doit s'appuyer sur un stockage de données décentralisé, tel que la blockchain.
Cette caractéristique décentralisée confère une durabilité des données bien supérieure à celle d'un unique dépôt de données, mais cela s'accompagne de coûts supplémentaires.
Problèmes rencontrés par les développeurs
Pour réaliser FOCG ou AW, les développeurs de jeux doivent maîtriser les technologies blockchain full stack ou embaucher des experts en blockchain.
Que ce soit pour l'apprentissage ou l'embauche, cela nécessite d'importantes ressources et constitue souvent un obstacle majeur pour les développeurs de jeux en vue d'un jeu entièrement chaînes ou d'un monde autonome.
Rush a été créé pour résoudre ce problème.
Il utilise des techniques d'expérience de développement abstraites et efficaces vérifiées, telles que :
- Configuration déclarative
- Entité-Composant-Système (Entity-Component-System, ECS)
- Génération de code
Simplifiant ainsi considérablement la complexité.
Trois. Cadre HyperGrid
Le protocole HyperGrid est un cadre d'extension et d'orchestration Rollup, conçu pour soutenir les opérateurs Rollup de l'écosystème SVM. Il réalise un potentiel illimité de débit de transactions grâce à la compression d'état (State Compression) et à la tolérance aux fautes byzantines (Byzantine Fault Tolerance, BFT), en réalisant une mise à l'échelle horizontale entre plusieurs grilles (Grids), comme le montre Sonic (une grille axée sur les jeux), dont les transactions sont finalement réglées sur Solana.
3.1 Aperçu de l'architecture
Aperçu de l'architecture multi-grille de HyperGrid : des grilles semi-autonomes réalisent un consensus et une finalité via Solana.
L'architecture de HyperGrid est basée sur un modèle multi-grille (multi-grid), chaque grille fonctionnant de manière semi-autonome tout en réalisant un consensus et une finalité via le réseau principal de Solana.
3.2 Architecture du système HyperGrid
Composants clés
1. Couche de base de Solana :
- La base du système HyperGrid, fournissant le consensus final et la finalité des données.
2. Réseau de partage d'état HyperGrid (HSSN) :
- Le cœur du système, fonctionnant à travers toutes les grilles.
- Comprend plusieurs validateurs (Validator 1 à Validator N).
- Partage d'état entre la grille et la couche de base de Solana.
- Gérer les preuves à connaissance nulle (ZK Proofs) par lots pour le règlement.
3. Structure de la grille (avec Grid 1 et Grid 2 comme exemple) :
- Chaque grille représente un écosystème semi-autonome, pouvant être dédié à des applications spécifiques (comme différents jeux).
- Les composants de chaque grille comprennent :
- Co-processeur ZK : gère les opérations spécifiques à la grille et les preuves Merkle.
- Runtime SVM : exécute des opérations de grille sur la machine virtuelle Solana.
- Moteur de gaz Sonic : gère les ressources de calcul.
- Générateur de Merkle Tree concurrent : traite efficacement les transitions d'état.
4. Interaction utilisateur :
- L'utilisateur peut interagir de manière indépendante avec chaque grille.
- Transactions (y compris les transactions SVM et EVM) circulent entre l'utilisateur et les temps d'exécution de la grille correspondante.
- Les réponses de transaction sont renvoyées à l'utilisateur.
3.2 Flux de données
Interopérabilité et partage d'état :
- Partage d'état bidirectionnel entre la couche de base de Solana et HSSN.
- HSSN partage l'état avec chaque grille.
- Le partage d'état peut également se produire entre différentes grilles.
3.4 Preuve ZK :
1. Les transactions sont compressées et agrégées dans un arbre Merkle.
2. Pour chaque bloc, soumettre la valeur de hachage de l'état racine correspondant.
3. Preuve de validité (Validity Proof) calculée sur la grille.
4. HSSN utilise la preuve ZK pour le règlement et l'envoie à la couche de base de Solana.
Quatre. Communication entre grilles et réseaux
L'architecture du réseau HyperGrid : le réseau de partage d'état, les instances de grille et la relation avec la couche de base de Solana, soutient le déploiement scalable de dApp.
Flux de données du réseau HyperGrid partagé
Le cadre HyperGrid est conçu pour soutenir un large éventail de réseaux d'applications spécifiques ou d'applications décentralisées (dApp), en mettant particulièrement l'accent sur les applications à forte demande au sein de son écosystème, telles que les jeux, DeFi, agents AI, etc.
Les objectifs de cette architecture incluent :
1. Réduire la pression de performance sur la couche de base de Solana.
2. Minimiser les conflits de performance et la concurrence causés par la concurrence pour l'espace de bloc entre la couche de base et divers dApp spécifiques.
Caractéristiques clés
1. Flexibilité, offrant aux créateurs de réseaux de grille le choix :
- Les développeurs peuvent choisir :
- Utilisation du réseau public HyperGrid.
- Mise à l'échelle horizontale pour créer des réseaux exclusifs spécifiquement dédiés aux besoins particuliers.
2. Optimisation des performances et des coûts :
- Le choix entre un réseau public et un réseau exclusif dépend de l'évaluation par le développeur des besoins en performance et des coûts associés.
3. Indépendance du réseau :
- Les développeurs peuvent désactiver à tout moment leur réseau exclusif sans affecter les autres réseaux de l'écosystème.
Cadre opérationnel
1. Validation :
- Chaque réseau gère de manière autonome la validation de ses transactions et de ses changements d'état.
2. Journalisation :
- Chaque réseau maintient de manière autonome son propre journal de transactions et de changements d'état.
3. Récupération des données :
- Le processus de récupération des données est exécuté de manière indépendante dans chaque réseau.
Cinq. Interopérabilité avec Solana
5.1 Lecture des données de Solana vers HyperGrid
Le schéma ci-dessus illustre le processus de synchronisation d'état de Solana vers la grille sur HyperGrid (comme Sonic).
Chargement initial : charger les programmes Solana préexistants à partir du stockage dans le cache de HyperGrid.
L'utilisateur envoie une demande de lecture à Sonic RPC de HyperGrid pour un programme spécifique.
Le programme de synchronisation vérifie si le programme demandé existe dans le cache, mais ne le trouve pas.
Le programme de synchronisation envoie des demandes de programme au RPC de la couche de base Solana.
La couche de base de Solana répond en utilisant des données de programme.
Le programme de synchronisation reçoit une réponse et utilise les nouvelles données du programme pour mettre à jour le cache de HyperGrid.
Le programme de synchronisation envoie les réponses de lecture à Sonic RPC.
Sonic RPC transmet les réponses de lecture à l'utilisateur.
5.2 Synchronisation des mises à jour vers la couche de base de Solana
Le schéma ci-dessus illustre le processus de synchronisation d'état depuis la grille sur HyperGrid (comme Sonic) vers Solana.
Chargement initial : charger les programmes préexistants depuis le stockage dans le cache de HyperGrid.
L'utilisateur envoie une demande d'écriture d'un programme spécifique à Sonic RPC de HyperGrid.
Le programme de synchronisation vérifie si le programme demandé existe dans le cache, mais ne le trouve pas.
Le programme de synchronisation envoie une demande pour verrouiller le programme sur la couche de base de Solana.
Le RPC de la couche de base de Solana verrouille les programmes demandés.
La couche de base de Solana répond en utilisant des données de programme.
Le programme de synchronisation reçoit une réponse et utilise les nouvelles données du programme pour mettre à jour le cache de HyperGrid.
Le programme de synchronisation envoie une demande pour libérer le verrou et écrite les données mises à jour du programme dans la couche de base de Solana.
La couche de base de Solana libère le verrou et écrit les données mises à jour.
Le programme de synchronisation renvoie les réponses d'écriture à Sonic RPC.
Sonic RPC transmet les réponses d'écriture à l'utilisateur.
Six. Réseau de partage d'état HyperGrid (HSSN)
Le réseau HyperGrid de partage d'état (HSSN) est un élément clé de l'écosystème Grid. Il sert de couche de consensus, de centre de communication et de cluster de gestion d'état, facilitant l'interaction entre Grid et la couche de base de Solana. Ce réseau gère l'état de toutes les communications, y compris la synchronisation régulière des données de blocs depuis les Rollups de Grid vers la couche de base de Solana.
Composants et fonctionnalités principaux
Architecture HSSN : construite sur le cadre Cosmos, garantissant la fiabilité et la sécurité de la communication entre chaînes.
Structures de données : gestion de l'état entre la grille et la couche de base de Solana, y compris :
- Enregistrement de la grille
- Source de données de communication
- Contrôle de version
- Lire/Écrire l'état
- Champ de données de compte extensible : amélioration des champs de données de compte natifs de la couche de base Solana pour s'adapter aux nouveaux champs de gestion HSSN, garantissant la synchronisation avec l'état des comptes de la grille.
- Grille RPC reconstruite : permet la communication directe entre les grilles et HSSN, facilitant l'interopérabilité au sein de l'écosystème.
Mécanisme de chargement et de distribution de GAS : les utilisateurs paient des frais de gaz pour certaines requêtes du réseau, une grille spécialisée (Sonic Grid) exécute des programmes de calcul de gaz, gérant de manière centralisée le gaz de l'écosystème de l'ensemble du réseau.
Situation du financement du projet
Sonic a terminé un tour de financement de 12 millions de dollars, ce tour a été dirigé par Bitkraft Ventures, avec la participation de Galaxy Interactive, BigBrain Holdings et d'autres, et est actuellement évalué à 120 millions de dollars.
TGE :
L'offre totale de SONIC est de 2,4 milliards de jetons, dont 57 % sont alloués à la communauté, comprenant le développement communautaire et écologique (30 %), la réclamation initiale (7 %) et les récompenses HyperGrid (20 %). Le TGE est prévu pour le 7 janvier 2025, avec un volume initial en circulation représentant 15 % du total. SONIC sera distribué sur 6 ans, à ce moment-là, tous les SONIC seront entièrement en circulation, la majeure partie étant allouée à la communauté. Aucun jeton d'équipe ou d'investisseur ne sera débloqué au cours des 12 à 18 premiers mois suivant le lancement, et les jetons verrouillés ne peuvent pas être mis en jeu.
Enfin, faisons un résumé de ce projet, SOL a commencé à lancer L2, donc en réalité, il devrait y avoir une demande L2 sur les blockchains rapides. Selon cette logique, l'architecture multichaîne d'avax est en fait utile, et L2 de SOL pourrait connaître un essor.
