Sursa originală: Gravity

Introducere

De la lansarea Gravity Alpha mainnet în august 2024, rețeaua a procesat peste 275 de milioane de tranzacții, cu un volum mediu zilnic de 2,6 milioane de tranzacții și a realizat cu succes taxe de tranzacție de 30 de milioane G. Odată cu publicarea Litepaper-ului, așteptăm cu nerăbdare planul de viitor pentru această blockchain EVM de înaltă performanță. Acest articol va analiza în profunzime Litepaper-ul, dezvăluind cum Gravity construiește o arhitectură de blockchain Layer-1 de înaltă performanță pentru aplicații din lumea reală.

Gravity este un blockchain de înaltă performanță, compatibil EVM, creat de Galxe. Dezvoltarea Gravity provine din nevoile de evoluție ale Galxe. Platforma Galxe, ca cea mai mare platformă de distribuție on-chain din lume, conectează un ecosistem vast multi-chain, atrăgând peste 25 de milioane de utilizatori. Pe parcursul procesului său de dezvoltare continuă, Galxe a evoluat într-o super-aplicație descentralizată, integrând instrumente inovatoare precum Quest, Passport, Score, Compass și Alva, oferind în același timp servicii variate, inclusiv puncte de fidelitate, NFT-uri de activitate, recompense în token-uri, verificare zk-identitate și economii inteligente între blockchain-uri. Pe măsură ce Galxe continuă să se dezvolte, volumul său ridicat de tranzacții a devenit un factor important în construirea Gravity - sistemul său de puncte de fidelitate susținând 51,2 tranzacții pe secundă, iar activitățile de recompensă în token-uri susținând 32,1 tranzacții pe secundă. Acest lucru ne-a determinat să căutăm o blockchain EVM pentru a permite descentralizarea backend-ului Galxe, menținând în același timp cea mai bună experiență pentru utilizatori.

Odată cu dezvoltarea Galxe pe blockchain complet, o creștere suplimentară a volumului de tranzacții este de așteptat. Se preconizează că cerințele de capacitate vor ajunge la 50 de milioane de gas pe secundă, iar satisfacerea cerințelor unui ecosistem mai larg (cum ar fi decontarea între blockchain-uri, tranzacții de puncte de fidelitate și piețe NFT) ar putea necesita o capacitate de procesare de 500 de milioane de gas pe secundă. În acest scop, Gravity își propune să susțină o capacitate de 1 gigagas pe secundă pentru a satisface cerințele de extindere ale aplicațiilor intensive în resurse.

Dintre soluțiile existente, multe platforme obțin scalabilitate prin Ethereum, dar perioadele de provocare ale L2 Rollup duc inevitabil la întârzieri ale tranzacțiilor, ceea ce nu este prietenos pentru aplicațiile care necesită confirmări imediate ale tranzacțiilor, cum ar fi Galxe. Deși unele DApp-uri încearcă să compenseze întârzierile prin metode bazate pe încredere sau monitorizare externă, aceste metode introduc complexitate și riscuri suplimentare, care sunt clar inadecvate pentru aplicațiile de bază.

În acest context, Gravity a apărut. Gravity se concentrează pe EVM paralel, dezvoltând Grevm, cel mai rapid sistem de execuție EVM open-source de până acum, reducând distanța de performanță între L2 și L1. În plus, Gravity modularizează arhitectura Aptos, integrând componente validate precum Quorum Store și motorul de consens AptosBFT. Prin utilizarea arhitecturii mature a Aptos, Gravity evită complexitatea și riscurile potențiale ale dezvoltării de la zero. În final, Gravity nu doar că a construit un blockchain Layer-1 de înaltă performanță care oferă o experiență completă pe blockchain, ci a lansat și primul SDK pentru blockchain-uri pipeline, simplificând semnificativ interacțiunile dezvoltatorilor și utilizatorilor.

Gravity oferă o scalabilitate, capacitate de descentralizare și viteză de tranzacție aproape instantanee fără precedent. Tehnologia sa combină avantajele L1 și L2, realizând 10.000 de tranzacții pe secundă și finalitate sub o secundă. În plus, prin integrarea protocoalelor de restaking precum EigenLayer și Babylon, Gravity nu doar că asigură o securitate puternică în faza de lansare, dar și reduce riscurile sistemice pe termen lung asociate cu dependența de un singur activ.

În viitor, Gravity va avansa conform următoarei foi de parcurs:

· Lansarea etapei 1 a Devnet, testând performanța în timp real;

· Lansarea Longevity Testnet, validând stabilitatea rețelei pe termen lung;

· Trecerea de la Gravity Alpha mainnet la Gravity mainnet complet operațional, punând bazele pentru aplicarea pe scară largă a tehnologiilor descentralizate.

Iată compilarea completă a Litepaper-ului Gravity.

Rezumat

Gravity este un blockchain Layer-1 de înaltă performanță, compatibil EVM, creat de Galxe, destinat aplicațiilor de scară largă și ecosistemelor multi-chain. Caracteristicile sale includ o capacitate de 1 gigagas pe secundă, confirmarea finală a tranzacțiilor sub o secundă și un mecanism de consens PoS bazat pe protocoale de restaking. Designul Gravity se bazează pe două componente open-source esențiale: (1) Gravity SDK, un motor de consens AptosBFT bazat pe pipeline și restaking; (2) Gravity reth, un strat de execuție condus de EVM Grevm (Gravity EVM) în paralel. Aceste instrumente oferă aplicațiilor Web3 capacitatea de a construi alternative Layer-1 și Layer-2 eficiente, mai ales în contextul blockchain-urilor EVM. Acest articol explorează în profunzime designul ingineresc și inovațiile tehnologice ale Gravity, demonstrând cum prin arhitectura pipeline, algoritmi avansați de consens, tehnici de execuție paralele și mecanisme de stocare optimizate (prin îmbunătățirea reth și perfecționarea motorului de consens Aptos) se pot satisface cerințele de înaltă performanță.

Introducere

Dezvoltarea Gravity provine din provocările întâmpinate de Galxe în operațiunile sale. Galxe este o aplicație Web3 de vârf care oferă utilizatorilor puncte de fidelitate, NFT-uri de activitate, recompense în token-uri, verificare zero-knowledge a identității și economii inteligente între blockchain-uri. Pe măsură ce Galxe a crescut rapid, sistemul său de puncte de fidelitate procesează în medie 51,2 tranzacții pe secundă, în timp ce activitățile de recompensă în token-uri procesează în medie 32,1 tranzacții pe secundă. Pe măsură ce ne mutăm către descentralizarea Galxe, migrarea acestor cazuri de utilizare pe blockchain EVM, menținând în același timp o experiență utilizator plăcută, a devenit o provocare. Prin urmare, dezvoltarea unei blockchain EVM de înaltă performanță care să satisfacă (1) o capacitate mare de tranzacții și (2) o confirmare aproape instantanee a tranzacțiilor a devenit crucială.

În acest context, alegerea unei soluții Layer-2 existente sau dezvoltarea unei noi Layer-1 este un punct cheie de decizie. Layer-1 realizează finalitatea prin algoritmul de consens, în timp ce Layer-2 abordează această problemă prin protocoale Rollup. Cele două au compromisuri: Layer-1 sacrifică adesea o parte din capacitate din cauza limitărilor algoritmului de consens, dar poate realiza o confirmare a tranzacțiilor mai rapidă. De exemplu, algoritmul de consens bazat pe AptosBFT poate confirma tranzacțiile sub o secundă, în timp ce Rollup-urile optimiste pot avea perioade de provocare de până la șapte zile. Deși dovezile zero-knowledge pot accelera acest proces, confirmarea finală necesită totuși câteva ore. Având în vedere cerințele Gravity pentru confirmări finale sub o secundă (în special pentru protocolul său de intenție complet on-chain), am decis să construim Layer-1.

Deși Layer-2 are avantaje native în comunicarea cu Ethereum, Layer-1 cum ar fi Gravity poate realiza interoperabilitate profundă cu Ethereum și alte blockchain-uri prin protocolul de intenție Gravity și poduri între blockchain-uri. Acest design nu doar că colaborează fără probleme cu Ethereum, ci și îmbunătățește conectivitatea întregului ecosistem Web3.

În plus, protocoalele de restaking reduc semnificativ dificultatea construcției unui blockchain PoS Layer-1. Gravity, prin intermediul protocoalelor EigenLayer și Babylon, integrează activele de staking din Ethereum și Bitcoin și rețeaua sa extinsă de validatori. Acest lucru oferă garanții economice pentru consensul PoS, asigurându-se că descentralizarea și securitatea Gravity ating niveluri comparabile cu cele ale Ethereum.

În concluzie, Gravity a fost construit ca un blockchain performant, compatibil EVM, pentru a satisface cerințele de scalabilitate și performanță ale aplicațiilor Web3 moderne. Deși scopul său inițial a fost să servească Galxe, cadrul flexibil oferit de Gravity SDK și Grevm (Gravity EVM) este potrivit pentru a construi orice Layer-1 și Layer-2 eficiente, având funcționalități similare cu Tendermint/Cosmos SDK.

Avem nevoie de o capacitate de 1 gigagas/s

Pentru blockchain, capacitatea este cel mai critic indicator de performanță, de obicei măsurat în tranzacții pe secundă (TPS) sau utilizarea gazului pe secundă (gas/s). De exemplu, sistemul de puncte de fidelitate al Galxe necesită o capacitate de cel puțin 4 milioane gas/s pentru a funcționa stabil. Această cifră provine din consumul mediu de 80.000 de gaz pe fiecare tranzacție de puncte de fidelitate, în timp ce poate gestiona aproximativ 51,2 tranzacții pe secundă.

Această predicție a fost susținută de datele practice din Gravity Alpha Mainnet. Ca rețea Layer 2 în testele noastre, tranzacțiile de puncte de fidelitate din Gravity Alpha Mainnet au arătat că capacitatea sa poate atinge stabil 4 milioane gas/s, validând exactitatea estimărilor anterioare.

Deși costurile ridicate ale operațiunilor on-chain pot duce la o scădere ușoară a cererii, tendința de expansiune a Galxe arată că, în perioadele de vârf, cererea poate crește de două sau trei ori față de nivelul actual. În plus, odată cu integrarea altor scenarii de utilizare, precum NFT-uri, recompense în token-uri și viitoare suporturi ale dovezilor zero-knowledge pentru sarcini on-chain complete, se estimează că cererea de capacitate va ajunge la 50 de milioane gas/s. Presupunând că utilizarea gazului aplicațiilor de pe Gravity Chain urmează o distribuție Pareto (similar cu Uniswap, care a consumat constant 10% din gazul Ethereum), pentru a satisface cerințele unui ecosistem mai larg, cum ar fi decontarea între blockchain-uri, tranzacții de puncte de fidelitate și piețe NFT, ideal ar trebui să suporte o capacitate de 500 de milioane gas/s. Prin urmare, pentru a satisface aceste cerințe potențiale, blockchain-ul trebuie să aibă o capacitate de 1 gigagas pe secundă, asigurându-se că poate să se adapteze la extinderea aplicațiilor intensive în resurse.

Pentru a atinge o astfel de capacitate ridicată, cheia este introducerea EVM-ului paralel. Am dezvoltat Grevm, care este cel mai rapid sistem de execuție EVM open-source de până acum, performanțele exacte pot fi consultate în capitolele următoare.

Timp de confirmare sub o secundă

Pe lângă capacitate, viteza de confirmare a tranzacțiilor este esențială pentru experiența utilizatorului. Utilizatorii moderni sunt obișnuiți cu răspunsuri aproape imediate, asemănătoare cu Web2, iar aceasta rămâne o provocare pentru blockchain-uri. De exemplu, Galxe, care este similar cu jocurile complet on-chain, are cerințe specifice de latență scăzută. În prezent, timpul de confirmare a tranzacțiilor pe majoritatea blockchain-urilor EVM variază de la câteva secunde la câteva zile, ceea ce este departe de a satisface această cerință. Am ales algoritmul de consens AptosBFT pentru a realiza timpi de confirmare sub o secundă.

Deși L2 Rollup teoretic poate îmbunătăți capacitatea, perioadele lor de provocare pot duce la întârzieri ale tranzacțiilor, ceea ce este extrem de dăunător pentru aplicațiile care necesită confirmări imediate ale tranzacțiilor (cum ar fi Galxe). Deși unele DApp-uri încearcă să optimizeze acest lucru prin metode bazate pe încredere sau monitorizare externă, acestea introduc complexitate și riscuri suplimentare, ceea ce nu este ideal pentru aplicațiile critice. Gravity SDK reduce distanța de performanță dintre L2 și L1 prin proiectarea unei pipeline în cinci etape, paralelizând fluxurile de consens și execuție (designul specific este detaliat mai departe).

Securitate PoS bazată pe restaking

Gravity SDK oferă o modalitate sigură de a extinde Ethereum, fără a se limita la L2 Rollup, ci alegând să protejeze L1 prin restaking, echilibrând performanța, interoperabilitatea și securitatea. Modulul de bază integrează protocoale de restaking precum EigenLayer și Babylon, oferind suport de încredere economic, asigurându-se că se construiește un consens robust bazat pe dovezi de participare.

Cu activele de staking de 45 de miliarde de dolari și cei 850.000 de validatori din Ethereum, precum și prin conectarea la activele de 600 de miliarde de dolari din Bitcoin prin Babylon, Gravity poate construi de la început o bază de securitate solidă, evitând problemele comune de lansare și riscurile de securitate ale noilor blockchain-uri, în timp ce reduce pe termen lung riscurile sistemice asociate cu un singur activ.

Arhitectura Gravity Chain

Gravity Chain conține două componente principale: Gravity SDK și Gravity reth. Gravity SDK este un cadru de blockchain îmbunătățit bazat pe blockchain-ul Aptos, care este în prezent blockchain-ul PoS cel mai avansat bazat pe familia de algoritmi de consens HotStuff, iar arhitectura sa de tip pipeline îmbunătățește semnificativ capacitatea și eficiența resurselor. Gravity reth este stratul de execuție bazat pe reth, funcționând sub formă de reactor de flux de blocuri (BSR) pentru a primi propunerile de blocuri din stratul de consens. Prin optimizarea reth, Gravity reth realizează execuție paralelă, calculul asincron al angajamentului de stare în loturi și îmbunătățirea eficienței stocării. Cele două componente sunt strâns legate prin interfața motorului de consens Gravity (GCEI) și adaptorul reth, gestionate dinamic de controller-ul pipeline-ului pe parcursul fiecărei etape.

Acest design separă execuția blocului de consensul blocului, permițând stratului de execuție să acționeze ca un consumator al propunerilor de blocuri. Optimizarea noastră pentru reth îl face să se potrivească perfect cu fluxul de propuneri de blocuri gestionat de reactorul de flux de blocuri (BSR).

Fluxul tranzacțiilor din Gravity Chain este următorul:

1. Tranzacțiile sunt submitte prin interfața JSON RPC Gravity reth, care este complet compatibilă cu Ethereum.

2. Apoi, tranzacțiile intră în pool-ul de memorie al Gravity SDK și se propagă în rețea, validatorii procesând tranzacțiile în loturi și generând certificate Quorum Store (QS).

3. Fiecare lider dintr-un ciclu propune o propunere de bloc, conținând metadatele blocului și tranzacțiile ordonate selectate din pool-ul de memorie și QS.

4. Propunerile marcate ca ordonate vor intra în stratul de execuție.

5. Stratului de execuție Grevm procesează tranzacțiile în paralel, generând rezultatele execuției și transmitând noua stare către modulul de gestionare a stării.

6. Modulul de stare calculează rădăcina stării și o transmite motorului de consens pentru a ajunge la consensul asupra rădăcinii stării.

7. După confirmarea finală a rădăcinii stării, modulul de stocare persistă rădăcina stării și datele blocului.

Capitolele următoare vor detalia fiecare componentă.

Gravity SDK: Practica inovatoare a blockchain-urilor open-source pipeline

Gravity SDK este un cadru de blockchain open-source modular, dezvoltat pe baza blockchain-ului Aptos pregătit pentru producție. Scopul său este de a modulariza arhitectura Aptos, împrumutând componente validate precum Quorum Store și motorul de consens AptosBFT pentru a crea primul SDK pentru blockchain-uri pipeline.

Motivul pentru care Gravity SDK a ales Aptos ca bază include:

· Arhitectura tehnică de vârf: Aptos este un blockchain PoS avansat bazat pe consensul familiei HotStuff.

· Performanță extremă: Aptos oferă o capacitate de 160.000 de tranzacții pe secundă, iar timpul de confirmare finală este sub 1 secundă.

· Fiabilitate în practică: Aptos a fost validat în medii de producție, demonstrând o stabilitate și eficiență remarcabile.

· Evitați să inventați roata din nou: utilizarea arhitecturii mature a Aptos poate evita complexitatea și riscurile potențiale ale dezvoltării de la zero, în timp ce alte încercări de a depăși Aptos sunt în mare parte teoretice și insuficiente în practică.

· Sinergie: pe măsură ce Aptos continuă să evolueze, Gravity SDK poate integra fără probleme noile sale caracteristici, cum ar fi API-ul de numere aleatorii, în timp ce și contribuie la Aptos prin arhitectura modulară și mecanismele inovatoare de securitate.

Blockchain-ul bazat pe Gravity SDK se conectează la motorul de consens Gravity prin interfața Gravity Consensus Engine Interface (GCEI). Deși GCEI este compatibil cu diverse straturi de execuție, Gravity SDK sprijină în prezent în principal Gravity reth. Detaliile despre GCEI vor fi discutate în capitolele următoare.

Gravity Consensus Engine Interface (GCEI)

Protocolul GCEI (Gravity Consensus Execution Interface) este puntea de comunicare între stratul de consens și stratul de execuție. Acesta normează interacțiunea dintre cele două niveluri, asigurându-se că fluxurile de consens și execuție rămân sincronizate prin intermediul controller-ului pipeline.

Principala diferență între SDK-urile blockchain tradiționale și Gravity SDK este motorul său de consens pipeline. Stratului de execuție trebuie să fie implementat ca un reactor de flux de blocuri (Block Stream Reactor), ceea ce înseamnă că trebuie să fie capabil să consume continuu fluxul de blocuri propuse, iar angajamentul de stare trebuie să fie calculat asincron față de execuția tranzacțiilor. În plus, stratul de execuție trebuie să fie capabil să ofere semnale de presiune către stratul de consens pentru a ajusta dinamic ritmul propunerii de blocuri.

În plus, datorită caracteristicilor pipeline-ului Gravity SDK, stratul de execuție trebuie să fie capabil să gestioneze tranzacțiile neexecutabile din blocurile propuse, deoarece pool-ul de memorie nu poate verifica strict validitatea oricărei tranzacții din cauza imposibilității de a accesa cea mai recentă stare a lumii: execuția poate să nu fi fost finalizată. În același timp, rezultatul execuției nu ar trebui să blocheze generarea blocurilor ulterioare, deoarece, după ce Gravity SDK a paralelizat consensul blocurilor cu consensul stării, stratul de execuție devine un reactor pentru fluxul de blocuri propuse, putând returna liber rezultatele execuției în etapele ulterioare.

Protocolul GCEI definește două seturi de API-uri:

· API-ul stratului de consens: aceste API-uri sunt implementate de Gravity SDK, pentru a răspunde propunerilor de blocuri din partea motorului de consens și pentru a trimite angajamentele de stare.

· API-ul de execuție: Aceste API-uri trebuie implementate de stratul de execuție. Motorul de consens va folosi aceste API-uri pentru a verifica cu bună credință și a fluxa propunerile de blocuri înainte de a le propune pentru bloc.

Din perspectiva ciclului de viață al tranzacției, protocolul GCEI definește următoarele:

1. check_txn (API-ul stratului de execuție)

· Intrare: primește o tranzacție (GTxn) ca input.

· Ieșire: returnați adresa expeditorului tranzacției, nonce-ul și limita gazului.

Utilizare: această metodă este folosită de motorul de consens pentru a efectua verificarea bună a tranzacțiilor înainte de a le propune pentru bloc. Această metodă poate fi apelată de mai multe ori pentru aceeași tranzacție, de exemplu când tranzacția intră în pool-ul de memorie, înainte de a fi propusă pentru bloc și când angajamentul de stare este finalizat.

2. submit_txn (API-ul stratului de consens)

Intrare: primește o tranzacție (GTxn) din stratul de execuție.

Ieșire: returnați Result<(), indicând dacă tranzacția a fost adăugată cu succes la pool-ul de memorie.

Utilizare: stratul de execuție poate folosi această metodă pentru a trimite tranzacții la pool-ul de memorie. Motorul de consens va răspândi ulterior această tranzacție prin rețea și, după ce primește un lot de tranzacții, va forma Quorum Store.

3. recv_ordered_block (API-ul stratului de execuție)

Intrare: primește un ordered_block (de tip BlockBatch), care conține tranzacții sortate și metadatele blocului.

Ieșire: returnați Result<(), indicând dacă stratul de execuție a reușit să primească și să accepte acest bloc.

Utilizare: odată ce motorul de consens propune un bloc, acesta este trimis la stratul de execuție pentru execuția tranzacțiilor. Această metodă permite stratului de execuție să primească și să proceseze blocurile propuse.

4. update_state_commitment (API-ul stratului de consens)

Intrare: angajamentul de stare pentru un anumit bloc (StateCommitment).

Ieșire: returnați Result<(), indicând dacă angajamentul de stare a fost acceptat cu succes de motorul de consens local.

Utilizare: după ce stratul de execuție calculează angajamentul de stare, acesta îl trimite stratului de consens pentru a-l finaliza, adică pentru a ajunge la un consens ușor de 2f+1 cu alți validatori. Dacă consensul angajamentului de stare și progresul blocului propus sunt prea departe unul de celălalt, controller-ul pipeline-ului va ajusta ritmul propunerii de blocuri.

5. commit_block_hash (API-ul stratului de execuție)

Intrare: primește un vector de block_ids, reprezentând blocurile care trebuie submit.

Ieșire: returnați Result<(), indicând dacă operația a avut succes.

Utilizare: când angajamentul de stare este finalizat, stratul de consens va notifica stratul de execuție să trimită hash-ul blocului la stocarea blockchain-ului.

Pipeline blockchain

Gravity SDK maximizează utilizarea resurselor hardware printr-o arhitectură de tip pipeline în cinci etape, realizând astfel o capacitate mai mare și o latență mai mică. Pipeline-ul execută sarcini în straturi intercalate între diferite blocuri, iar managerul de pipeline folosește un mecanism de feedback pentru a asigura progresele constante ale blockchain-ului. Primele trei etape aparțin stratului de consens, iar ultimele două etape aparțin stratului de execuție.

Fiecare etapă este explicată mai jos:

· Etapa 1: Propagarea tranzacțiilor: această etapă propagă eficient tranzacțiile între validatori, asigurându-se că tranzacțiile sunt incluse în mod timely și fiabil în timpul construcției blocului. Designul decuplează propagarea tranzacțiilor de mecanismul de consens, urmând ideile Narwhal & Tusk și Aptos, adică validatori care împărtășesc continuu loturi de tranzacții, utilizând toate resursele rețelei pentru a rula concurent. Când un lot de tranzacții primește o semnătură ponderată de 2f+1 (formând PoAv, adică dovada disponibilității), se asigură că acest lot de tranzacții este stocat de cel puțin f+1 validatori cinstiți, astfel încât toți validatorii cinstiți să poată recupera aceste tranzacții pentru execuție.

· Etapa 2: Sortarea metadatelor blocului: această etapă stabilește un ordin consistent și recunoscut al tranzacțiilor și metadatelor blocului în rețea. Mecanismul de consens (AptosBFT) respectă regula celor două lanțuri (2-chain rule) pentru a oferi blocuri tolerate la faulturi byzantine. Blocurile vor curge apoi în etapa de execuție, pregătindu-se pentru procesare paralelă.

· Etapa 3 (BSR): Execuția tranzacțiilor în paralel: această etapă este parte a stratului de execuție, în care tranzacțiile sunt executate în paralel. Rezultatul execuției va fi transmis în etapa angajamentului de stare.

· Etapa 4: Angajamentul de stare: această etapă finalizează modificările de stare cauzate de execuția tranzacțiilor și pregătește blocul pentru finalizare. Angajarea stării și execuția tranzacțiilor sunt calculate asincron, asigurându-se că execuția blocului următor nu este afectată de angajamentul de stare al blocului curent.

· Etapa 5: Persistența stării: această etapă persistă modificările de stare angajate în stocarea blockchain-ului. Rădăcina de stare finală și datele relevante sunt stocate în Gravity Store, care utilizează un motor de stocare extrem de optimizat, proiectat pentru acces rapid și fiabil. În același timp, notifică pool-ul de memorie și Quorum Store să elimine tranzacțiile care nu vor mai putea fi incluse în viitor.

Modulele de Staking și Restaking

Construirea unei blockchain Layer 1 bazate pe dovezi de participare (PoS) sigură este o sarcină complexă, mai ales în cazul în care se bazează exclusiv pe staking-ul unui token specific. Această abordare poate întâmpina probleme de securitate economică insuficientă în etapele inițiale, cum ar fi fluctuațiile valorii token-ului sau participarea limitată a validatorilor. Pentru a aborda această problemă, Gravity SDK oferă un modul flexibil de Staking și Restaking, destinat să îmbunătățească securitatea rețelei prin mecanisme de staking locale și externe.

Una dintre strategiile cheie ale Gravity SDK este introducerea unor protocoale de Restaking, cum ar fi EigenLayer și Babylon. Aceste protocoale permit validatorilor să restakeze activele altor rețele mature (cum ar fi Ethereum și Bitcoin), profitând de securitatea acestora existente. Prin permiterea validatorilor să stakeze activele acestor blockchain-uri, Gravity SDK poate îmbunătăți securitatea economică a rețelei fără a se baza complet pe token-uri locale. Această abordare nu doar că întărește robustetea blockchain-ului, ci și promovează diversitatea ecosistemului validatorilor. Modulul de Staking este proiectat cu modularitate în centrul său, iar componenta sa de Restaking are o flexibilitate ridicată, capabilă să se adapteze cu ușurință la noi protocoale de Restaking pe măsură ce ecosistemul blockchain-ului evoluează.

Modulul nu numai că susține activele de Restaking, ci și permite staking-ul personalizat al token-urilor ERC20 pe blockchain-uri care le susțin, cum ar fi G Token pe Ethereum. Validatorii pot participa la consens prin staking-ul acestor token-uri permise, contribuind la securitatea rețelei. Drepturile de vot ale validatorilor sunt calculate în funcție de valoarea totală a staking-ului, inclusiv token-uri personalizate și active din protocoalele de restaking. Această calculare se face în funcție de configurațiile specifice ale lanțului, asigurându-se că fiecare lanț poate stabili reguli de staking și restaking în mod flexibil, în funcție de nevoile sale.

Managerul Epoch din motorul de consens colaborează direct cu modulul de Staking pentru a calcula greutatea setului de validatori pentru următorul ciclu. Acesta asigură că procesul de consens reflectă cu exactitate cele mai recente dinamici de stakare, obținând valorile de staking din stratul de execuție. În această arhitectură, activele între blockchain-uri (de exemplu, activele de staking din Ethereum) trebuie mai întâi să fie transferate la stratul de execuție înainte de a putea fi utilizate pentru calcularea valorii totale de staking a validatorilor. Implementarea mecanismului de transfer este responsabilitatea stratului de execuție, permițând o gestionare mai flexibilă a comunicării între blockchain-uri. Posibilele soluții includ poduri PoS, dovezi zero-knowledge ale stării lanțului și mesaje între blockchain-uri auto-startate încorporate.

Mai multe detalii tehnice, designul API-ului și descrierea completă a mecanismelor de Staking și Restaking vor fi detaliate în documentele viitoare.

Gravity Reth: reactor de flux de blocuri strat de execuție EVM

Integrarea stratului de execuție EVM Ethereum în arhitectura Gravity SDK a adus provocări unice, în special în maximizarea capacităților motorului său de consens pipeline. Pentru a realiza integrarea fără probleme și a valorifica pe deplin potențialul acestei arhitecturi, a fost necesar să se efectueze mai multe optimizări cheie asupra clientului open-source Ethereum reth. Aceste optimizări transformă fundamental reth în Gravity reth, un strat de execuție EVM optimizat pentru motorul de consens pipeline.

Arhitectura blockchain-ului tradițional procesează blocurile în ordine, asigurându-se că fiecare bloc este complet verificat și executat înainte de a propune următorul bloc. Cu toate acestea, Gravity SDK adoptă un mecanism de consens pipeline, separând etapele procesării blocurilor pentru a îmbunătăți performanța. Această schimbare de paradigmă introduce complexitate:

Tranzacții neașteptate: în pipeline-ul blockchain-ului, din cauza execuției anterioare a blocurilor care poate să nu fi fost finalizată, pool-ul de memorie nu poate accesa cea mai recentă stare a lumii. Prin urmare, tranzacțiile incluse în blocul propus pot să nu poată fi executate în momentul propunerii, deoarece validitatea acestora nu poate fi verificată strict fără a avea cea mai recentă stare.

Execuția rezultatelor non-blocante: pentru a preveni stagnarea pipeline-ului, rezultatele execuției nu ar trebui să blocheze generarea blocurilor ulterioare. Stratului de execuție trebuie să fie capabil să proceseze propunerile de blocuri în mod asincron și să returneze rezultatele execuției în etapele ulterioare fără a împiedica procesul de consens. Pentru EVM, aceasta înseamnă redefinirea blockhash-ului, eliminând dependența de câmpul stateRoot din antetul blocului.

Pentru a aborda aceste probleme, am introdus patru optimizări cheie:

· Reactorul de flux de blocuri (Block Stream Reactor, BSR): BSR este destinat ajustării reth la fluxul de propuneri de blocuri al Gravity SDK. Acesta permite stratului de execuție să consume continuu fluxul de blocuri propuse, acționând ca un reactor pentru procesarea asincronă a blocurilor. BSR stabilește un ciclu dinamic de feedback cu motorul de consens, combinând semnale de presiune adecvate. Aceste semnale ajustează în timp real viteza propunerii de blocuri și a angajamentului de stare în funcție de capacitatea și latența stratului de execuție. Dacă, din cauza unor tranzacții complexe sau a limitărilor de resurse, stratul de execuție întâmpină întârzieri, mecanismul de presiune va reduce rata propunerii de blocuri pentru a asigura stabilitatea sistemului.

· Decuplarea angajamentului de stare de execuția tranzacțiilor: a doua optimizare implică separarea calculului angajamentului de stare de execuția tranzacțiilor. Prin decuplarea acestor procese, am realizat asincronizarea calculului angajamentului de stare, astfel încât execuția blocurilor ulterioare să nu fie necesar să aștepte finalizarea angajamentului de stare al blocului curent. Am redefinit blockhash-ul, eliminând dependența de câmpul stateRoot din antetul blocului, asigurându-ne că calcularea rădăcinii stării nu va împiedica generarea blocurilor ulterioare.

· Optimizarea stratului de stocare: în arhitectura pipeline-ului, caching-ul eficient și persistența valorilor de stare cu multiple versiuni și angajamentele de stare sunt esențiale. A treia optimizare se concentrează pe îmbunătățirea stratului de stocare pentru a satisface aceste cerințe fără a introduce blocaje. Prin optimizarea mecanismului de stocare, ne asigurăm că datele de stare pot fi scrise rapid și recuperate cu o mare concurență. Aceasta include construirea unui motor de stocare cu multiple versiuni și suport pentru I/O asincron de la baza de date la API-ul de stocare.

· EVM paralel: ultima optimizare implică execuția tranzacțiilor în paralel în cadrul EVM. Am dezvoltat Grevm, un runtime EVM paralel, care accelerează semnificativ procesarea tranzacțiilor prin execuția concurentă. Grevm utilizează indicii de dependență a datelor obținute din simularea tranzacțiilor pentru a optimiza execuția paralelă, reducând re-execuția tranzacțiilor și îmbunătățind capacitatea.

Grevm (Gravity EVM) - Execuție EVM paralel

Grevm este un proiect open-source, găzduit pe GitHub (dacă nu a fost încă open-source, va fi open-source în viitor). Consultați README-ul său pentru mai multe informații.

Grevm (Gravity EVM) este un runtime open-source paralel EVM bazat pe revm. Algoritmul Grevm este inspirat de BlockSTM și este îmbunătățit prin introducerea unui grafic de dependență a datelor din simulări de tranzacții. Acest mecanism face ca programarea execuției paralele să fie mai eficientă, minimizând re-execuția tranzacțiilor.

În testele noastre de referință, Grevm este în prezent cea mai rapidă implementare open-source a EVM-ului paralel. Pentru tranzacții fără conflicte, Grevm este de 4,13 ori mai rapid decât execuția secvențială, cu o viteză de 26,50 gigagas/s. Dacă simulăm o întârziere I/O de 100 μs în lumea reală, viteza sa este de 50,84 ori mai rapidă decât execuția secvențială, cu o capacitate de 6,80 gigagas/s. Această saltare de performanță se datorează integrării execuției paralele cu operațiunile I/O asincrone - paralelismul permite ca operațiunile I/O să se suprapună eficient, accelerând astfel și mai mult.

Ideea centrală a Grevm este de a utiliza dependențele de date între tranzacții pentru a optimiza execuția paralelă prin seturi de citire/scriere speculate. Deși toate indiciile nu sunt complet precise, aceste indicii bazate pe simulare sunt de obicei suficient de utile. De exemplu, pe blockchain-ul Ethereum, pe baza utilizării istorice a gazului, aproximativ 30% din tranzacții sunt simple transferuri de Ether, iar alte 25%-30% sunt transferuri de token-uri ERC20, aceste tranzacții implicând de obicei citirea și scrierea unui număr limitat de conturi și sloturi de stocare. Pentru aceste tranzacții, rezultatele simulării au o acuratețe consistentă.

Pe baza acestor perspective, am dezvoltat un cadru de execuție paralelă în trei etape pentru Grevm, ca o continuare a modelului Block-STM, integrând indicii de dependență obținuți din simularea tranzacțiilor:

· Etapa 1: Generarea indiciilor și preîncălzirea stării - simularea tranzacțiilor pentru a colecta indiciile de dependență și a preîncălzi cache-ul de memorie. Această etapă poate fi executată în diferite momente, în funcție de designul blockchain-ului. De exemplu, atunci când o nouă tranzacție ajunge în pool-ul de memorie, poate fi executată imediat simularea pentru a pregăti indiciile de dependență.

· Etapa 2: Analiza dependențelor - transformarea indiciilor de dependență colectate în etapa de simulare într-un grafic orientat aciclic (DAG) care reprezintă relațiile de dependență între tranzacții. Acest DAG este folosit pentru a planifica programarea tranzacțiilor în execuția paralelă ulterioară.

· Etapa 3: Execuția paralelă sub rezolvarea conflictelor - folosind un algoritm BlockSTM modificat bazat pe dependențe DAG pentru a executa tranzacțiile în paralel. Programarea nu mai selectează tranzacțiile strict în funcție de numărul de secvență al tranzacțiilor din bloc (de exemplu, 1, 2, 3, ..., n), ci prioritizează selectarea tranzacțiilor în funcție de ordinea DAG pentru a minimiza conflictele și a reduce necesitatea de re-execuție.

Angajament de stare în loturi asincrone

Generarea angajamentului de stare rămâne un blocaj cheie în pipeline-ul blockchain-ului, din cauza naturii secvențiale a merkelizării. Fiecare calcul al subarborilor trebuie să fie finalizat înainte de a putea genera angajamentul final al stării, ceea ce va duce la întârzieri semnificative. Deși soluțiile existente (precum paralelismul la nivel de cont din reth) au introdus un anumit grad de paralelism, mai există o mulțime de oportunități de optimizare. În contextul reactorului de flux de blocuri (BSR) din Gravity reth, consensul angajamentului stării și execuția tranzacțiilor sunt decuplate, permițând calculul angajamentului stării să fie întârziat și procesat în loturi fără a bloca execuția.

Pentru a aborda aceste probleme, cadrul propus introduce următoarele inovații cheie:

Calculul hash-ului în loturi asincron: prin decuplarea consensului angajamentului de stare și execuția tranzacțiilor, acest cadru realizează calculul asincron al angajamentului de stare. Actualizările rădăcinii stării se fac pe loturi (de exemplu, o dată la 10 blocuri) pentru a reduce frecvența calculului rădăcinii stării. Această abordare de procesare în loturi realizează calcule hash eficiente prin agregarea nodurilor murdare partajate, minimizând astfel cheltuielile de actualizare frecventă și reducând costurile totale de calcul. Pentru blocuri mici, procesarea în loturi poate îmbunătăți semnificativ paralelismul; pentru blocuri mari, aceasta poate reduce costurile totale de calcul.

Complet paralel: acest cadru extinde paralelizarea întregii structuri de stare, nu doar a unui singur arbore de conturi. Pentru nodurile marcate ca „murdare”, cadrul adoptă un algoritm de calcul al stării paralele, împărțind arborele în subarbori independenți și procesându-i concurent. Rezultatul este agregat la nivelul superior pentru a calcula eficient rădăcina finală. Această metodă asigură că blocuri mari cu multe tranzacții și schimbări de stare pot folosi eficient multithreading, maximizând astfel capacitatea.

Rădăcină rapidă alternativă a stării: pentru a se adapta la antetul blocului Ethereum și la opcode-ul BLOCKHASH (care necesită acces la rădăcina stării celor mai recente 256 de blocuri), am redefinit rădăcina stării. Spre deosebire de dependența de angajamentele finale ale stării (care nu sunt disponibile pe parcursul execuției tranzacțiilor), am calculat rădăcina stării ca o combinație a setului de modificări ale blocului și a hash-ului anterior al rădăcinii stării. Această metodă face ca calcularea rădăcinii stării să fie mai rapidă, fără a aștepta finalizarea angajamentului complet al stării.

Gravity Store

Pentru a satisface cerințele blockchain-ului de înaltă performanță pentru gestionarea datelor la scară largă, Gravity Store a apărut ca un strat de stocare optimizat cu multiple versiuni. Se bazează pe designul reth, care a redus deja problema expansiunii stării prin separarea stocării angajamentului de stare de stocarea datelor de stare, în timp ce a redus cheltuielile de citire și scriere a datelor. Cu toate acestea, stratul de execuție Gravity reth necesită în continuare suport pentru procesarea paralelă și angajamentele de stare asincrone, generând cerințe tehnice suplimentare.

Pentru a aborda aceste provocări, Gravity Store a propus o structură eficientă de arbore cu multiple versiuni, special concepută pentru arhitectura noastră BSR (Block Stream Reactor). Această structură de arbore suportă gestionarea actualizărilor de stare cu multiple versiuni. Spre deosebire de abordarea tradițională de a actualiza imediat hash-urile după modificare, Gravity Store va marca nodurile modificate ca „noduri murdare”, permițând astfel procesarea întârziată a calculului hash și executarea în loturi. Acest design permite crearea rapidă a noilor versiuni, interogarea eficientă a datelor pentru versiuni specifice și curățarea versiunilor vechi sub o anumită înălțime, îmbunătățind semnificativ performanța gestionării stării blockchain-ului.

De asemenea, cercetăm dezvoltarea independentă a motorului de stocare Gravity DB, care are ca obiectiv furnizarea unei stocări optimizate pentru aplicațiile blockchain și suport pentru operațiuni I/O complet asincrone. Designul acestui motor este inspirat de LETUS, un motor de bază de date generală structurat pe jurnale, destinat blockchain-urilor. Principalul nostru dezvoltator, Richard, fiind unul dintre autorii principali ai LETUS, va detalia designul său într-un articol de blog care va fi publicat în curând.

Concluzie

Gravity Chain este un blockchain Layer 1 de înaltă performanță, compatibil EVM, proiectat pentru a satisface cerințele de scalabilitate și performanță ale aplicațiilor web3 moderne. Combinând Gravity SDK, motorul de consens AptosBFT pipeline, și stratul de execuție Gravity reth condus de Grevm, Gravity realizează o capacitate de 1 gigagas pe secundă, timp de confirmare a tranzacțiilor sub o secundă și securitate PoS bazată pe mecanisme de restaking. Designul acestor componente tehnice oferă o bază solidă pentru crearea de blockchain-uri L1 personalizate sau soluții L2 mai eficiente pentru aplicațiile web3, în special în utilizarea optimizată a blockchain-urilor EVM.

Acest articol provine dintr-o contribuție, nu reflectă opinia BlockBeats.