Astăzi continuăm să vorbim despre Sonic, un proiect care pune vinul vechi în sticle noi A fost destul de popular în ultimele două zile pentru că mâine va avea loc un TGE (Token Generation Event) și se vor da airdrops. Sonic este L2 al Solului. Toată lumea este surprinsă că un SOL atât de rapid mai are nevoie de L2? Nu este acesta punctul fierbinte de care are nevoie cercul valutar?
Deci, de ce SOL are nevoie de L2?
Pe măsură ce activitățile dAPP și DeFi pe Solana cresc mai repede, tranzacțiile zilnice în lanț au depășit 200 de milioane în ianuarie 2024, iar unii analiști estimează în mod conservator că volumul tranzacțiilor va depăși 4 miliarde în 2026.
Sub această presiune previzibilă, TPS-ul Solana este în jur de 2500-4000, iar timpul mediu de ping al cluster-ului Solana fluctuează între 6 secunde și 80 de secunde când TPS devine din ce în ce mai saturat sau chiar depășește 4000, rata de succes a tranzacției Solana ajunge doar la 70% până la 85; %.
În afară de întârzierile fizice cauzate de starea rețelei și de fluctuațiile rețelei, motivul principal este evident legat de creșterea constantă a saturării TPS. Conform tendințelor de creștere ale Solana, se preconizează că valorile TPS vor atinge 10.000 până la zeci de mii în următorii câțiva ani, ceea ce va duce la probleme de performanță mai evidente.
Deasupra este răspunsul oferit de white paper Sonic, iar eu adaug un pic:
1. În raportul Messari despre Ethereum L2 din ultimele două zile, s-a menționat că actuala L1 este cea mai potrivită pentru soluționarea securizată, iar aplicațiile ar trebui să fie plasate pe L2.
2. Sonic se concentrează în prezent pe lanțul de jocuri publice, axându-se pe jocuri complete pe lanț; dacă într-adevăr sunt 100.000 de utilizatori sau milioane online în jocuri pe lanț, dacă datele sunt complet pe lanț, atunci câteva mii sau zeci de mii de TPS nu vor face față, deci este necesar un L2 mai rapid și mai ieftin.
O. Introducere
Sonic este primul lanț SVM atomic (ce înseamnă interoperabilitate atomică este că conturile, programele și SOL sunt interconectate), fiind și cel mai rapid L2 de pe Solana, Sonic este construit pe primul cadru de extindere concurent HyperGrid de pe Solana. Prin intermediul interpretului HyperGrid, este ușor să desfășori dApp-uri de pe lanțurile EVM pe Solana, astfel că este compatibil atât cu EVM cât și cu SOL.
Sonic publică primitivii de jocuri native și tipurile de date scalabile pe baza cadrului ECS. Sandbox-ul motorului de joc oferă instrumente utile dezvoltatorilor, ajutându-i să construiască logica de afaceri pe blockchain.
Două. Cadrele Rush ECS
Rush este un cadru rapid de entitate-componență-sistem (Entity-Component-System, ECS) complet construit în Rust, având ca singur obiectiv: reducerea la minimum a complexității integrării tehnologiei blockchain cu instrumentele familiare dezvoltatorilor (cum ar fi SDK-ul și API-ul motorului de joc) prin adoptarea unei experiențe de dezvoltare verificate.
Rush privește spre un viitor: orice joc deja construit sau în curs de construire poate fi ușor transformat în jocuri pe întreaga rețea (Fully-Onchain Game) sau lumi autonome (Autonomous World) prin Rush și tehnologiile sale preferate de dezvoltare a jocurilor.
Cum funcționează Rush
În mod obișnuit, dezvoltatorii de jocuri folosesc motoare de joc pentru a crea jocuri.
Cu ajutorul motorului de joc, complexitatea logicii de bază este considerabil redusă, dezvoltatorii se pot concentra pe designul și mecanica jocului, în timp ce complexitatea este gestionată de motorul de joc.
Pe de altă parte, realizarea jocurilor pe întreaga rețea (FOCG) și a lumilor autonome (AW) trebuie să se bazeze pe stocarea descentralizată a datelor, cum ar fi blockchain-ul.
Această caracteristică de descentralizare face ca persistența datelor să depășească cu mult un singur depozit de date, dar vine și cu costuri suplimentare.
Problemele cu care se confruntă dezvoltatorii
Pentru a realiza FOCG sau AW, dezvoltatorii de jocuri trebuie să stăpânească tehnologia blockchain full-stack sau să angajeze experți în blockchain.
Indiferent dacă este vorba despre învățare sau angajare, aceasta necesită resurse considerabile și adesea reprezintă un obstacol uriaș pentru dezvoltatorii de jocuri în drumul lor spre jocuri pe întreaga rețea sau lumi autonome.
Rush a fost creat exact pentru a rezolva această problemă.
Aceasta face prin tehnici de abstractizare a experienței de dezvoltare eficiente verificate, cum ar fi:
- Configurare declarativă
- Entitate-Componență-Sistem (Entity-Component-System, ECS)
- Generarea codului
Reducând astfel complexitatea considerabil.
Trei. Cadru HyperGrid
Protocolul HyperGrid este un cadru de extindere Rollup și orchestrare, destinat să susțină operatorii Rollup ai ecosistemului SVM. Acesta realizează o capacitate potențială de tranzacții infinite prin tehnici de compresie a stării și toleranță la defecte bizantine (Byzantine Fault Tolerance, BFT). Acest lucru se realizează prin scalarea orizontală între mai multe rețele (Grids), așa cum este demonstrat de Sonic (o rețea axată pe jocuri), a cărei tranzacții se finalizează în cele din urmă pe Solana.
3.1 Prezentare generală a arhitecturii
Prezentarea arhitecturii multi-grid a HyperGrid: rețele semi-autonome implementând consens și finalitate prin Solana.
Arhitectura HyperGrid se bazează pe un model multi-grid, fiecare rețea funcționând într-un mod semi-autonom, în timp ce atinge consensul și finalitatea prin rețeaua principală Solana.
3.2 Arhitectura sistemului HyperGrid
Componente cheie
1. Baza Solana:
- Baza sistemului HyperGrid, oferind consens final și finalitate a datelor.
2. Rețeaua de partajare a stării HyperGrid (HSSN):
- Nucleul sistemului, care rulează în toate rețelele.
- Include mai mulți validatori (Validator 1 până la Validator N).
- Partajarea stării între rețea și baza Solana.
- Gestionează dovezile zero-știință de volum (ZK Proofs) pentru soluționare.
3. Structura rețelei (exemplu Grid 1 și Grid 2):
- Fiecare rețea reprezintă un ecosistem semi-autonom, dedicat aplicațiilor specifice (cum ar fi diferite jocuri).
- Componentele fiecărei rețele includ:
- Co-procesor ZK: gestionează operațiunile specifice rețelei și dovezile Merkle.
- SVM Runtime: execută operațiuni de rețea pe Solana Virtual Machine.
- Motorul Sonic Gas: gestionează resursele de calcul.
- Generator de arbori Merkle concurent: gestionează eficient tranzițiile de stare.
4. Interacțiunea utilizatorului:
- Utilizatorii pot interacționa independent cu fiecare rețea.
- Tranzacțiile (inclusiv tranzacțiile SVM și EVM) circulă între utilizatori și rețelele corespunzătoare în timpul funcționării.
- Răspunsurile tranzacțiilor se întorc utilizatorului.
3.2 Fluxul de date
Interoperabilitatea și partajarea stării:
- Partajarea stării bidirecțională între baza Solana și HSSN.
- HSSN împarte starea între diverse rețele.
- Partajarea stării poate avea loc și între rețele diferite.
3.4 Dovezi ZK:
1. Tranzacțiile sunt comprimate și agregate în arbori Merkle.
2. Pentru fiecare bloc, se va trimite valoarea hash a stării de rădăcină corespunzătoare.
3. Dovezile de validitate (Validity Proof) sunt calculate pe rețea.
4. HSSN folosește dovezi ZK pentru a se regla și a le trimite la baza Solana.
Patru. Comunicarea între rețele și rețele
Arhitectura rețelei HyperGrid: partajarea stării, instanțele rețelei și relația cu baza Solana, susținând desfășurarea dApp-urilor scalabile.
Fluxul de date al rețelei HyperGrid de partajare a stării
Cadrele HyperGrid sunt concepute pentru a susține o gamă largă de rețele specifice aplicațiilor sau aplicații descentralizate (dApp), cu un accent special pe aplicațiile cu cerere mare din ecosistemul său, cum ar fi jocurile, DeFi, agenți AI etc.
Obiectivele acestei arhitecturi includ:
1. Reducerea presiunii de performanță pe baza Solana.
2. Minimizați conflictele și competiția de performanță generate de disputele pentru spațiul de blocuri între baza de bază și diverse aplicații dApp specifice.
Caracteristici cheie
1. Flexibilitate, oferind alegerea creatorilor rețelei de rețea:
- Dezvoltatorii pot alege:
- Folosind rețeaua publică HyperGrid.
- Scalare orizontală pentru a crea rețele dedicate cerințelor specifice.
2. Optimizarea performanței și costurilor:
- Alegerea între rețele publice și rețele dedicate depinde de evaluarea de către dezvoltatori a cerințelor de performanță și a costurilor asociate.
3. Independența rețelei:
- Dezvoltatorii pot dezactiva oricând rețeaua lor dedicată fără a afecta alte rețele din ecosistem.
Cadru operațional
1. Validare:
- Fiecare rețea gestionează independent validarea tranzacțiilor și a modificărilor de stare.
2. Înregistrarea:
- Fiecare rețea își întreține independent jurnalul de tranzacții și modificări de stare.
3. Recuperarea datelor:
- Procesul de recuperare a datelor se desfășoară independent în fiecare rețea.
Cinci. Interoperabilitatea cu Solana
5.1 va citi date de la Solana la HyperGrid
Imaginea de mai sus ilustrează următorul proces atunci când sincronizarea stării de la baza Solana la rețeaua HyperGrid (cum ar fi Sonic) este executată.
Încărcare inițială: încărcarea programelor existente din stocare în cache-ul HyperGrid.
Utilizatorii trimit cereri de citire pentru programe specifice la Sonic RPC al HyperGrid.
Programul de sincronizare verifică dacă programul solicitat există în cache, dar nu a fost găsit.
Programul de sincronizare trimite cereri de program către RPC-ul de bază Solana.
Baza Solana folosește datele programului pentru a răspunde.
Programul de sincronizare primește răspunsul și folosește noile date ale programului pentru a actualiza cache-ul HyperGrid.
Programul de sincronizare trimite răspunsurile citite înapoi la Sonic RPC.
Sonic RPC va redirecționa răspunsurile citite către utilizatori.
5.2 va sincroniza actualizările înapoi la baza Solana
Imaginea de mai sus ilustrează următorul proces atunci când sincronizarea stării de la rețeaua HyperGrid (cum ar fi Sonic) se întoarce la Solana.
Încărcare inițială: încărcarea programelor existente din stocare în cache-ul HyperGrid.
Utilizatorii trimit cereri de scriere pentru programe specifice către Sonic RPC al HyperGrid.
Programul de sincronizare verifică dacă programul solicitat există în cache, dar nu a fost găsit.
Programul de sincronizare trimite cereri, blocând programul de pe baza Solana.
RPC-ul de bază Solana blochează cererile programului.
Baza Solana folosește datele programului pentru a răspunde.
Programul de sincronizare primește răspunsul și folosește noile date ale programului pentru a actualiza cache-ul HyperGrid.
Programul de sincronizare trimite cereri pentru a elibera blocarea și pentru a scrie datele actualizate ale programului în baza Solana.
Baza Solana eliberează blocarea și scrie datele actualizate.
Programul de sincronizare trimite răspunsurile de scriere înapoi la Sonic RPC.
Sonic RPC va redirecționa răspunsurile de scriere către utilizatori.
Șase. Rețeaua de partajare a stării HyperGrid (HSSN)
Rețeaua de partajare a stării HyperGrid (HSSN) este o componentă cheie a ecosistemului Grid. Acesta servește ca strat de consens, centru de comunicare și cluster pentru gestionarea stării, facilitând interacțiunea între Grid și baza Solana. Această rețea administrează toate stările comunicării, inclusiv sincronizarea periodică a datelor blocurilor de la Grid Rollups către baza Solana.
Componente și funcționalități principale
Arhitectura HSSN: construită pe baza cadrului Cosmos, asigurând fiabilitatea și securitatea comunicării între lanțuri.
Structura de date: gestionează starea între rețea și baza Solana, inclusiv:
- Înregistrarea rețelei
- Surse de date de comunicare
- Controlul versiunii
- Citirea/Scrierea stării
- Extinderea câmpului de date al contului: îmbunătățirea câmpului de date al contului de bază Solana pentru a se adapta la noile câmpuri de gestionare HSSN, asigurând sincronizarea cu starea contului rețelei.
- RPC-ul rețelei reconstruite: permite comunicarea directă între rețea și HSSN, facilitând interoperabilitatea în cadrul ecosistemului.
Mecanismul de încărcare și distribuție a gazului: utilizatorii plătesc taxe de gaz pentru anumite cereri de rețea, o rețea dedicată (Sonic Grid) rulează un program de calcul al gazului, gestionând în mod central întregul ecosistem al rețelei de gaz.
Starea finanțării proiectului
Sonic a finalizat o rundă de finanțare de 12 milioane de dolari în prima rundă, condusă de Bitkraft Ventures, cu participarea companiilor Galaxy Interactive, BigBrain Holdings și altele, având în prezent o evaluare de 120 de milioane de dolari.
TGE:
SONIC are o ofertă totală de 2,4 miliarde de unități, dintre care 57% sunt alocate comunității, incluzând dezvoltarea comunității și ecologiei (30%), revendicarea inițială (7%) și recompensele HyperGrid (20%). TGE este programat pentru 7 ianuarie 2025, iar circulația inițială reprezintă 15% din total. SONIC va fi distribuit complet în termen de 6 ani, când toate SONIC vor fi complet circulante, majoritatea fiind alocate comunității. În primele 12-18 luni după lansare, nu se vor debloca niciun token de echipă sau investitor, iar tokenurile blocate nu pot fi staked.
În concluzie, acest proiect, SOL a început să lanseze L2, astfel că în prezent, pe lanțurile publice rapide ar trebui să existe cerere pentru L2. Conform acestei raționări logice, arhitectura multi-chain a AVAX demonstrează că este utilă, iar L2 al SOL ar putea să înflorească.
