Fonte originale: Gravity

Introduzione

Dal lancio della Gravity Alpha Mainnet nell'agosto 2024, la rete ha elaborato oltre 275 milioni di transazioni, con un volume medio giornaliero di 2,6 milioni di transazioni e ha raggiunto con successo 30 milioni di G in costi di transazione. Con il rilascio del Litepaper, abbiamo grandi aspettative per il futuro di questa blockchain EVM ad alte prestazioni. Questo documento analizzerà approfonditamente il Litepaper, rivelando come Gravity stia costruendo un'architettura blockchain Layer-1 eccezionale per applicazioni nel mondo reale.

Gravity è una blockchain Layer-1 ad alte prestazioni, compatibile con EVM, costruita da Galxe. Lo sviluppo di Gravity nasce dalle esigenze di sviluppo di Galxe. La piattaforma Galxe, il più grande hub di distribuzione on-chain al mondo, connette un vasto ecosistema multi-chain, attirando oltre 25 milioni di utenti. Nel suo processo di continua evoluzione, Galxe si è trasformata in un'applicazione super decentralizzata, integrando strumenti innovativi come Quest, Passport, Score, Compass e Alva, offrendo allo stesso tempo servizi ricchi come punti fedeltà, NFT per eventi, premi in token, zk-verifica dell'identità e risparmi intelligenti cross-chain. Durante questo percorso di crescita, l'alto volume di transazioni di Galxe è diventato un fattore determinante per la costruzione di Gravity: il suo sistema di punti fedeltà supporta 51,2 transazioni al secondo, mentre le attività di premi in token supportano 32,1 transazioni al secondo. Questo ci ha portato, nella decentralizzazione del backend di Galxe, a volgere la nostra attenzione verso le blockchain EVM, mantenendo al contempo la migliore esperienza per l'utente.

Con lo sviluppo della completa on-chain di Galxe, è prevedibile un ulteriore aumento del volume delle transazioni. Si prevede che la domanda di capacità raggiunga 50 milioni di gas al secondo, mentre il soddisfacimento di esigenze ecologiche più ampie (come la regolazione interchain, le transazioni di punti fedeltà e i mercati NFT) potrebbe richiedere una capacità di elaborazione di 500 milioni di gas al secondo. Pertanto, l'obiettivo di Gravity è supportare una capacità di 1 gigagas al secondo, per soddisfare le esigenze di scalabilità delle applicazioni ad alta intensità di risorse.

Tra le soluzioni esistenti, molte piattaforme realizzano la scalabilità tramite Ethereum, ma i periodi di sfida dei Rollup L2 portano inevitabilmente a ritardi nelle transazioni, il che non è amichevole per applicazioni come Galxe che richiedono conferme immediate. Sebbene alcune DApp tentino di compensare i ritardi tramite modalità di fiducia o monitoraggi esterni, questi approcci introducono complessità e rischi aggiuntivi, evidenziando che non sono ideali per scenari applicativi critici.

In questo contesto, Gravity è emersa. Gravity si basa su un EVM parallelo, sviluppando Grevm, il sistema di esecuzione EVM parallelo open-source più veloce attualmente disponibile, riducendo il divario di prestazioni tra L2 e L1. Inoltre, Gravity ha modularizzato l'architettura di Aptos, integrando componenti verificati come Quorum Store e il motore di consenso AptosBFT. Sfruttando l'architettura consolidata di Aptos, Gravity evita la complessità e il rischio potenziale dello sviluppo da zero. In definitiva, Gravity non solo ha costruito una blockchain L1 ad alte prestazioni che offre un'esperienza on-chain completa, ma ha anche lanciato il primo SDK di blockchain a pipeline, semplificando notevolmente il processo di interazione per sviluppatori e utenti.

Gravity offre una scalabilità, capacità di decentralizzazione e velocità di transazione quasi istantanee senza precedenti. La sua tecnologia combina i vantaggi di L1 e L2, realizzando 10.000 transazioni al secondo e finalità sub-secondo. Inoltre, integrando protocolli di Restaking come EigenLayer e Babylon, Gravity non solo garantisce una forte sicurezza nelle fasi iniziali, ma riduce anche il rischio sistemico a lungo termine derivante dall'affidamento su un singolo asset.

In futuro, Gravity procederà secondo il seguente piano:

· Lancio della fase 1 di Devnet, test delle prestazioni in tempo reale;

· Lancio del Longevity Testnet, per verificare la stabilità a lungo termine della rete;

· Transizione dalla mainnet Alpha di Gravity a una mainnet Gravity completamente operativa, ponendo le basi per l'applicazione su larga scala delle tecnologie decentralizzate.

Di seguito è riportata la traduzione completa del Gravity Litepaper.

Riepilogo

Gravity è una blockchain Layer-1 ad alte prestazioni, compatibile con EVM, costruita da Galxe, progettata per applicazioni su larga scala e un ecosistema multi-chain. Le sue caratteristiche includono una capacità di 1 gigagas al secondo, conferme finali delle transazioni in sub-secondo e un meccanismo di consenso PoS basato su protocolli di Restaking. La progettazione di Gravity si basa su due componenti open-source chiave: (1) Gravity SDK, un motore di consenso PoS a pipeline basato su Restaking; (2) Gravity reth, un layer di esecuzione alimentato da Grevm (Gravity EVM) in parallelo. Questi strumenti offrono la capacità di costruire alternative di Layer-1 e Layer-2 efficienti per le applicazioni Web3, eccellendo in particolare sulle catene EVM. Questo documento esplora in profondità la progettazione ingegneristica e l'innovazione tecnologica di Gravity, dimostrando come soddisfare la domanda di prestazioni elevate attraverso architetture a pipeline, algoritmi di consenso avanzati, tecnologie di esecuzione parallela e meccanismi di archiviazione ottimizzati (migliorando reth e raffinando il motore di consenso Aptos).

Introduzione

Lo sviluppo di Gravity è nato dalle sfide affrontate da Galxe durante le sue operazioni. Galxe è un'applicazione Web3 leader che offre servizi come punti fedeltà, NFT per eventi, premi in token, verifica dell'identità a zero conoscenze e risparmi intelligenti cross-chain. Con la rapida crescita di Galxe, il suo sistema di punti fedeltà gestisce in media 51,2 transazioni al secondo, mentre le attività di premi in token gestiscono in media 32,1 transazioni al secondo. Durante il processo di decentralizzazione di Galxe, è diventato una sfida trasferire questi casi d'uso su una blockchain EVM, garantendo al contempo un'esperienza utente fluida. Pertanto, sviluppare una blockchain EVM ad alte prestazioni in grado di soddisfare (1) un'elevata capacità di transazione e (2) conferme di transazione quasi istantanee è diventato cruciale.

In questo contesto, la scelta di soluzioni Layer-2 esistenti o lo sviluppo di un nuovo Layer-1 è un punto di decisione chiave. Layer-1 raggiunge la finalità tramite algoritmi di consenso, mentre Layer-2 affronta questo problema tramite protocolli Rollup. Ci sono compromessi tra i due: Layer-1 sacrifica normalmente parte della capacità a causa delle limitazioni degli algoritmi di consenso, ma può raggiungere conferme di transazione più veloci. Ad esempio, l'algoritmo di consenso basato su AptosBFT può confermare le transazioni in sub-secondo, mentre un Rollup ottimista può avere un periodo di sfida che dura fino a sette giorni. Anche se le prove a conoscenza zero possono accelerare questo processo, la conferma finale richiede ancora ore. Considerando la necessità di Gravity per conferme finali sub-secondo (soprattutto nel suo protocollo di intenzione on-chain), abbiamo scelto di costruire un Layer-1.

Anche se il Layer-2 ha vantaggi nativi nella comunicazione con Ethereum, un Layer-1 come Gravity può realizzare una profonda interoperabilità con Ethereum e altre blockchain tramite il protocollo di intenzione Gravity e ponti interchain. Questo design non solo collabora senza soluzione di continuità con Ethereum, ma migliora anche la connettività dell'intero ecosistema Web3.

Inoltre, i protocolli di Restaking (restaking) riducono significativamente la difficoltà di costruire una blockchain PoS Layer-1. Gravity, grazie a protocolli come EigenLayer e Babylon, integra gli asset staked di Ethereum e Bitcoin e la loro ampia rete di validatori. Ciò fornisce garanzie economiche per il consenso PoS, portando la decentralizzazione e la sicurezza di Gravity a un livello paragonabile a quello di Ethereum.

In sintesi, Gravity è stata costruita come una blockchain Layer-1 ad alte prestazioni, compatibile con EVM, per soddisfare le esigenze di scalabilità e prestazioni delle moderne applicazioni Web3. Sebbene il suo scopo iniziale fosse servire Galxe, il Gravity SDK e Grevm (Gravity EVM) offrono un framework flessibile, adatto per costruire qualsiasi Layer-1 e Layer-2 efficienti, con funzionalità simili a Tendermint/Cosmos SDK.

Abbiamo bisogno di una capacità di 1 gigagas/s

Per una blockchain, la capacità è il principale indicatore di prestazioni, di solito misurato in transazioni al secondo (TPS) o gas al secondo (gas/s). Prendendo ad esempio il sistema di punti fedeltà di Galxe, richiede almeno 4 milioni di gas/s per funzionare in modo stabile. Questo dato è derivato dal fatto che ogni transazione di punti fedeltà consuma in media 80.000 gas, mentre può elaborare circa 51,2 transazioni al secondo.

Questa previsione è supportata dai dati pratici della Gravity Alpha Mainnet. In quanto rete Layer 2 nei nostri test, le transazioni di punti fedeltà della Gravity Alpha Mainnet mostrano che la sua capacità può stabilmente raggiungere 4 milioni di gas/s, confermando l'accuratezza delle stime precedenti.

Sebbene l'alto costo delle operazioni on-chain possa portare a una leggera diminuzione della domanda, la tendenza all'espansione di Galxe indica che nei periodi di picco la domanda potrebbe aumentare fino a due o tre volte il livello attuale. Inoltre, con l'ingresso di altri scenari applicativi, come NFT, premi in token e la futura integrazione di prove a conoscenza zero per compiti on-chain completi, se Galxe dovesse diventare completamente on-chain, si prevede che la domanda di capacità raggiunga 50 milioni di gas/s. Assumendo che l'utilizzo di gas delle applicazioni sulla Gravity chain segua una distribuzione di Pareto (simile a come Uniswap consuma il 10% del gas di Ethereum), per soddisfare le esigenze ecologiche più ampie, come le regolazioni interchain, le transazioni di punti fedeltà e i mercati NFT, idealmente si dovrebbe supportare una capacità di 500 milioni di gas/s. Pertanto, per soddisfare queste potenziali esigenze, la blockchain deve avere una capacità di elaborazione di 1 gigagas al secondo, garantendo che possa adattarsi alla scalabilità delle applicazioni ad alta intensità di risorse.

Per raggiungere una capacità così alta, è fondamentale introdurre un EVM parallelo. Abbiamo sviluppato Grevm, il sistema di esecuzione EVM parallelo open-source più veloce attualmente disponibile, i cui dettagli sulle prestazioni possono essere consultati nei capitoli successivi.

Tempi di conferma sub-secondo

Oltre alla capacità, la velocità di conferma delle transazioni è cruciale per l'esperienza utente. Gli utenti moderni sono abituati a risposte quasi istantanee simili a Web2, il che rappresenta ancora una sfida per le blockchain. Prendendo Galxe come esempio, che è simile a un gioco completamente on-chain, ha requisiti specifici per la bassa latenza. Attualmente, i tempi di conferma delle transazioni nella maggior parte delle blockchain EVM variano da pochi secondi a giorni, ben al di sotto di queste aspettative. Abbiamo scelto l'algoritmo di consenso AptosBFT per raggiungere tempi di conferma sub-secondo.

Sebbene i Rollup L2 possano teoricamente migliorare la capacità, i loro periodi di sfida portano inevitabilmente a ritardi nelle transazioni, il che è estremamente svantaggioso per le applicazioni che richiedono conferme immediatamente (come Galxe). Sebbene alcune DApp tentino di ottimizzare questo tramite modalità di fiducia o monitoraggi esterni, ciò introduce ulteriori complessità e rischi, che non sono ideali per applicazioni critiche. Il Gravity SDK ha ridotto il divario di prestazioni tra L2 e L1 progettando una pipeline a cinque fasi che parallelizza i flussi di consenso e di esecuzione (il design specifico sarà discusso più avanti).

Sicurezza PoS basata su Restaking

Il Gravity SDK fornisce un metodo sicuro per scalare Ethereum, non limitandosi a L2 Rollup, ma scegliendo un'architettura L1 protetta da Restaking, bilanciando prestazioni, interoperabilità e sicurezza. Il core dei moduli integra protocolli di Restaking come EigenLayer e Babylon, offrendo un supporto economico di fiducia per costruire un consenso PoS robusto.

Grazie ai 45 miliardi di dollari di asset staked di Ethereum e 850.000 validatori, e all'accesso a 600 miliardi di dollari di asset tramite Bitcoin con Babylon, Gravity ha potuto costruire fin dall'inizio una solida base di sicurezza, evitando i problemi comuni di avvio e i rischi di sicurezza delle nuove blockchain, riducendo nel lungo termine il rischio sistemico derivante dalla dipendenza da un singolo asset.

Architettura della Gravity Chain

Gravity Chain è composta da due componenti principali: Gravity SDK e Gravity reth. Gravity SDK è un framework blockchain migliorato dalla chain Aptos, che è la blockchain PoS più avanzata attualmente basata sulla famiglia di algoritmi di consenso HotStuff, la cui architettura a pipeline aumenta notevolmente la capacità e l'efficienza delle risorse. Gravity reth è un layer di esecuzione basato su reth, che opera come reattore di flusso di blocchi (BSR) per ricevere le proposte di blocco dal layer di consenso. Ottimizzando reth, Gravity reth ha realizzato l'esecuzione parallela, il calcolo asincrono degli impegni di stato in batch e un aumento dell'efficienza di archiviazione. Questi due componenti sono strettamente collegati tramite l'interfaccia del motore di consenso di Gravity (GCEI) e l'adattatore reth, gestiti dinamicamente dal controllore della pipeline per monitorare i progressi di ogni fase.

Questo design separa l'esecuzione dei blocchi dal consenso dei blocchi, rendendo il layer di esecuzione un consumatore delle proposte di blocco. Abbiamo ottimizzato reth affinché si adatti perfettamente al processo di proposta di blocco gestito dal reattore di flusso di blocchi (BSR).

Il flusso delle transazioni nella Gravity Chain è il seguente:

1. Le transazioni vengono inviate attraverso l'interfaccia JSON RPC di Gravity reth, che è completamente compatibile con Ethereum.

2. Successivamente, le transazioni entrano nel pool di memoria del Gravity SDK e si diffondono nella rete, i validatori elaborano le transazioni in batch e generano un certificato Quorum Store (QS).

3. Ogni round un leader propone un blocco contenente metadati del blocco e transazioni ordinate selezionate dal pool di memoria e dal QS.

4. Una volta contrassegnata come ordinata, la proposta entrerà nel layer di esecuzione.

5. Il layer di esecuzione di Grevm gestisce le transazioni in parallelo, genera i risultati dell'esecuzione e trasferisce il nuovo stato al modulo di gestione dello stato.

6. Il modulo di stato calcola la radice di stato e la trasferisce al motore di consenso per raggiungere un consenso sulla radice di stato.

7. Una volta che la radice di stato è stata definitivamente confermata, il modulo di archiviazione persiste la radice di stato e i dati del blocco.

I capitoli successivi forniranno ulteriori dettagli su ciascun componente.

Gravity SDK: pratica innovativa della blockchain a pipeline

Gravity SDK è un framework blockchain open-source modulare, sviluppato sulla blockchain Aptos pronto per la produzione. Il suo obiettivo è modularizzare l'architettura di Aptos, attingendo a componenti verificati come Quorum Store e il motore di consenso AptosBFT, creando il primo SDK blockchain a pipeline.

Le ragioni per cui Gravity SDK ha scelto Aptos come base includono:

· Architettura tecnologica di alto livello: Aptos è una blockchain PoS avanzata basata sul consenso della famiglia HotStuff.

· Prestazioni estreme: Aptos offre una capacità di 160.000 transazioni al secondo e un tempo di conferma finale inferiore a 1 secondo.

· Affidabilità in situazioni reali: Aptos ha dimostrato un'eccellente stabilità ed efficienza attraverso la validazione in ambienti di produzione.

· Evitare di reinventare la ruota: sfruttare l'architettura consolidata di Aptos può evitare la complessità e il rischio potenziale dello sviluppo da zero, mentre altri tentativi di superare Aptos sono per lo più teorici e privi di pratica.

· Sinergia: con il continuo sviluppo di Aptos, il Gravity SDK può integrarsi senza soluzione di continuità con le sue nuove funzionalità, come l'API dei numeri casuali, mentre restituisce a Aptos attraverso architetture modulari e meccanismi di sicurezza innovativi.

Le blockchain basate su Gravity SDK si interfacciano con il motore di consenso Gravity attraverso l'interfaccia GCEI. Sebbene la GCEI sia compatibile con vari livelli di esecuzione, il Gravity SDK attualmente supporta principalmente Gravity reth. I dettagli sulla GCEI verranno discussi nei capitoli successivi.

Interfaccia del motore di consenso Gravity (GCEI)

Il protocollo GCEI (Interfaccia di Esecuzione del Consenso di Gravity) è un ponte di comunicazione tra il layer di consenso e il layer di esecuzione. Regola le interazioni tra i due livelli, assicurando che il flusso di consenso e di esecuzione rimanga sincronizzato tramite il controllore della pipeline.

La principale differenza tra i tradizionali SDK blockchain e il Gravity SDK risiede nel suo motore di consenso a pipeline. Il layer di esecuzione deve essere implementato come un reattore di flusso di blocchi (Block Stream Reactor), il che significa che deve essere in grado di consumare continuamente il flusso di blocchi proposti, e l'impegno allo stato deve essere calcolato in modo asincrono rispetto all'esecuzione delle transazioni. Inoltre, il layer di esecuzione deve essere in grado di fornire segnali di retroazione al layer di consenso per regolare dinamicamente il ritmo delle proposte di blocco.

Inoltre, a causa della natura a pipeline del Gravity SDK, il layer di esecuzione deve essere in grado di gestire transazioni non eseguibili nel blocco proposto, poiché il pool di memoria non può rigorosamente verificare la validità delle transazioni senza accesso all'ultimo stato del mondo: l'esecuzione potrebbe non essere ancora completata. Allo stesso tempo, i risultati dell'esecuzione non dovrebbero bloccare la generazione di blocchi successivi, poiché, dopo aver parallelizzato il consenso dei blocchi con il consenso di stato, il layer di esecuzione diventa un reattore al flusso di blocchi proposti, capace di restituire liberamente i risultati dell'esecuzione nelle fasi successive.

Il protocollo GCEI definisce due set di API:

· API del layer di consenso: queste API sono implementate dal Gravity SDK per consentire al layer di esecuzione di rispondere alle proposte di blocco del motore di consenso e di inviare l'impegno allo stato.

· API del layer di esecuzione: queste API devono essere implementate dal layer di esecuzione. Il motore di consenso utilizzerà queste API per effettuare una verifica diligente prima di proporre le transazioni a un blocco, fluidificare il blocco proposto e informare il layer di esecuzione dell'impegno finale dello stato.

Dal punto di vista del ciclo di vita delle transazioni, il protocollo GCEI definisce quanto segue:

1. check_txn (API del layer di esecuzione)

· Input: riceve una transazione (GTxn) come input.

· Output: restituisce l'indirizzo del mittente della transazione, il nonce e il limite di gas.

Uso: questo metodo viene utilizzato dal motore di consenso per effettuare una verifica diligente prima di proporre transazioni a un blocco. Questo metodo può essere chiamato più volte per la stessa transazione, ad esempio quando la transazione entra nel pool di memoria, prima di essere proposta a un blocco e quando l'impegno allo stato viene finalizzato.

2. submit_txn (API del layer di consenso)

Input: ricevi una transazione (GTxn) dal layer di esecuzione.

Output: restituisce Result<(), indicando se la transazione è stata aggiunta con successo al pool di memoria.

Uso: il layer di esecuzione può utilizzare questo metodo per inviare transazioni al pool di memoria. Il motore di consenso diffonderà quindi la transazione attraverso la rete e formerà un Quorum Store una volta ricevuto un lotto di transazioni.

3. recv_ordered_block (API del layer di esecuzione)

Input: riceve un ordered_block (di tipo BlockBatch), contenente transazioni ordinate e metadati del blocco.

Output: restituisce Result<(), indicando se il layer di esecuzione ha ricevuto e accettato con successo il blocco.

Uso: una volta che il motore di consenso propone un blocco, esso viene inviato al layer di esecuzione per l'esecuzione delle transazioni. Questo metodo consente al layer di esecuzione di ricevere e gestire le proposte di blocco.

4. update_state_commitment (API del layer di consenso)

Input: impegno allo stato di un determinato blocco (StateCommitment).

Output: restituisce Result<(), indicando se l'impegno allo stato è stato accettato con successo dal motore di consenso locale.

Uso: una volta calcolato l'impegno allo stato, il layer di esecuzione lo invia al layer di consenso per la finalizzazione, ovvero per raggiungere un consenso leggero di 2f+1 con altri validatori. Se il consenso sull'impegno allo stato si discosta troppo dallo stato del blocco proposto, il controllore della pipeline regolerà il ritmo delle proposte di blocco.

5. commit_block_hash (API del layer di esecuzione)

Input: riceve un vettore di block_ids, che rappresenta i blocchi da sottoporre.

Output: restituisce Result<(), indicando il successo o meno dell'operazione.

Uso: quando l'impegno allo stato viene finalizzato, il layer di consenso notificherà il layer di esecuzione di inviare l'hash del blocco allo storage della blockchain.

Pipeline di blockchain

Il Gravity SDK massimizza l'utilizzo delle risorse hardware attraverso un'architettura a pipeline a cinque fasi, ottenendo così una maggiore capacità e una minore latenza. La pipeline esegue compiti in modo intercalato tra i vari blocchi, e il gestore della pipeline utilizza meccanismi di feedback per garantire che la blockchain proceda in modo costante. Le prime tre fasi appartengono al layer di consenso, mentre le ultime due appartengono al layer di esecuzione.

Le varie fasi sono spiegate come segue:

· Fase 1: diffusione delle transazioni: questa fase diffonde le transazioni in modo efficiente tra i validatori, assicurando che le transazioni siano incluse in modo tempestivo e affidabile durante la costruzione del blocco. Il design disaccoppia la diffusione delle transazioni dal meccanismo di consenso, seguendo le idee di Narwhal & Tusk e Aptos, in cui i validatori condividono continuamente lotti di transazioni, utilizzando tutte le risorse della rete per eseguire in parallelo. Quando un lotto di transazioni ottiene 2f+1 firme pesate (formando PoAv, prova di disponibilità), si assicura che quel lotto di transazioni sia memorizzato da almeno f+1 validatori onesti, in modo che tutti i validatori onesti possano recuperare queste transazioni per l'esecuzione.

· Fase 2: ordinamento dei metadati del blocco: questa fase stabilisce un ordine coerente e riconosciuto di transazioni e metadati del blocco all'interno della rete. Il meccanismo di consenso (AptosBFT) segue la regola delle due catene (2-chain rule) per fornire blocchi a tolleranza agli attacchi bizantini. I blocchi successivamente fluiranno nella fase di esecuzione, pronti per l'elaborazione parallela.

· Fase 3 (BSR): esecuzione parallela delle transazioni: questa fase fa parte del layer di esecuzione, in cui vengono eseguite in modo parallelo le transazioni. I risultati dell'esecuzione verranno trasferiti alla fase di impegno allo stato.

· Fase 4: impegno allo stato: questa fase completa le modifiche di stato causate dall'esecuzione delle transazioni e prepara la finalizzazione del blocco. L'impegno allo stato e l'esecuzione delle transazioni vengono calcolati in modo asincrono, garantendo che l'esecuzione del successivo blocco non sia ostacolata dall'impegno dello stato del blocco attuale.

· Fase 5: persistenza dello stato: questa fase persiste le modifiche allo stato impegnate nello storage della blockchain. La radice di stato finale e i dati relativi vengono memorizzati in Gravity Store, che utilizza un motore di archiviazione altamente ottimizzato, progettato per un accesso rapido e affidabile. Notifica nel contempo al pool di memoria e al Quorum Store di eliminare le transazioni che non possono più essere incluse.

Moduli di Staking e Restaking

Costruire una blockchain Layer 1 a prova di sicurezza basata su Proof of Stake (PoS) è un compito complesso, soprattutto quando ci si basa esclusivamente su token specifici per lo staking. Questo approccio potrebbe affrontare problemi di sicurezza economica in fase iniziale, come la volatilità del valore dei token o la bassa partecipazione dei validatori. Per affrontare questo problema, il Gravity SDK offre un modulo di Staking e Restaking flessibile, progettato per migliorare la sicurezza della rete attraverso meccanismi di staking locali ed esterni.

Una delle strategie chiave del Gravity SDK è l'introduzione di protocolli di Restaking come EigenLayer e Babylon. Questi protocolli consentono ai validatori di ri-stakeare gli asset di altre reti consolidate (come Ethereum e Bitcoin), sfruttando le loro garanzie di sicurezza esistenti. Consentendo ai validatori di mettere in staking questi asset di catene, il Gravity SDK riesce ad aumentare la sicurezza economica della rete senza fare completamente affidamento sui token locali. Questo approccio non solo migliora la robustezza della catena, ma promuove anche la diversità nell'ecosistema dei validatori. Il design del modulo di staking è centrato sulla modularità, con il suo componente di Restaking altamente flessibile, capace di adattarsi facilmente a nuovi protocolli di Restaking man mano che l'ecosistema blockchain evolve.

Questo modulo non solo supporta gli asset di Restaking, ma consente anche lo staking di token ERC20 personalizzati che possono essere messi in staking sulla catena, come il G Token su Ethereum. I validatori possono partecipare al consenso mettendo in staking questi token consentiti, contribuendo alla sicurezza della rete. Il diritto di voto dei validatori viene calcolato in base al valore totale di staking, che include token personalizzati e asset nel protocollo di Restaking. Questo calcolo è basato sulla configurazione specifica della catena, garantendo che ogni catena possa impostare regole di staking e restaking flessibili in base alle proprie esigenze.

Il gestore dell'Epoch nel motore di consenso collabora direttamente con il modulo di Staking per calcolare il peso del prossimo insieme di validatori. Si assicura che il processo di consenso rifletta accuratamente le dinamiche di staking più recenti, estraendo valori di staking dal layer di esecuzione. In questa architettura, gli asset cross-chain (ad esempio, gli asset staked provenienti da Ethereum) devono prima essere trasferiti al layer di esecuzione prima di poter essere utilizzati per calcolare il valore totale di staking dei validatori. L'implementazione del meccanismo di bridge è responsabilità del layer di esecuzione, per gestire in modo più flessibile la comunicazione cross-chain. Le possibili soluzioni includono ponti PoS, prove a conoscenza zero dello stato della catena e messaggistica cross-chain auto-avviata incorporata.

Ulteriori dettagli tecnici, design API e spiegazioni complete sui meccanismi di Staking e Restaking saranno forniti in documenti successivi.

Gravity Reth: layer di esecuzione reattore di flusso di blocchi EVM

L'integrazione del layer di esecuzione EVM di Ethereum nell'architettura del Gravity SDK ha presentato sfide uniche, in particolare nella massimizzazione delle capacità del suo motore di consenso a pipeline. Per realizzare un'integrazione senza soluzione di continuità e sfruttare appieno il potenziale di questa architettura, è stato necessario apportare diverse ottimizzazioni chiave al client open-source di Ethereum, reth. Queste ottimizzazioni trasformano radicalmente reth in Gravity reth, un layer di esecuzione EVM ottimizzato per il motore di consenso a pipeline.

Le architetture blockchain tradizionali elaborano i blocchi in sequenza, garantendo che ogni blocco venga completamente verificato ed eseguito prima di proporre il blocco successivo. Tuttavia, il Gravity SDK adotta un meccanismo di consenso a pipeline, separando le varie fasi dell'elaborazione dei blocchi per migliorare le prestazioni. Questo cambiamento di paradigma introduce complessità:

Transazioni inaspettate: nella catena a pipeline, poiché l'esecuzione del blocco precedente potrebbe non essere ancora completata, il pool di memoria non può accedere all'ultimo stato del mondo. Pertanto, le transazioni contenute nel blocco proposto potrebbero non essere eseguibili al momento della proposta, poiché la loro validità non può essere rigorosamente verificata senza l'ultimo stato.

Risultati di esecuzione non bloccanti: per evitare di bloccare la pipeline, i risultati dell'esecuzione non dovrebbero ostacolare la generazione di blocchi successivi. Il layer di esecuzione deve essere in grado di gestire in modo asincrono i blocchi proposti e restituire i risultati dell'esecuzione in una fase successiva senza ostacolare il processo di consenso. Per l'EVM, ciò significa che è necessario ridefinire il blockhash, eliminando la dipendenza dal campo stateRoot nell'intestazione del blocco.

Per affrontare questi problemi, abbiamo introdotto quattro ottimizzazioni chiave:

· Reattore di flusso di blocchi (Block Stream Reactor, BSR): il BSR è progettato per adattare reth al processo di proposta di blocchi a pipeline del Gravity SDK. Consente al layer di esecuzione di consumare in modo continuo il flusso di blocchi proposti, fungendo da reattore per il trattamento asincrono dei blocchi. Il BSR stabilisce un ciclo di feedback dinamico con il motore di consenso, combinando segnali di retroazione appropriati. Questi segnali regolano in tempo reale la velocità delle proposte di blocchi e degli impegni allo stato in base alla capacità e alla latenza del layer di esecuzione. Se l'esecuzione del layer è in ritardo a causa di transazioni complesse o limitazioni delle risorse, il meccanismo di retroazione ridurrà la velocità di proposta dei blocchi per garantire la stabilità del sistema.

· Disaccoppiamento tra impegno di stato e esecuzione delle transazioni: la seconda ottimizzazione riguarda la separazione del calcolo dell'impegno allo stato dall'esecuzione delle transazioni. Disaccoppiando questi processi, abbiamo realizzato l'asincronizzazione del calcolo degli impegni allo stato, consentendo così che l'esecuzione dei blocchi successivi non debba attendere il completamento dell'impegno dello stato del blocco attuale. Abbiamo ridefinito il blockhash, rimuovendo la dipendenza dal campo stateRoot nell'intestazione del blocco, garantendo che il calcolo della radice di stato non ostacoli la generazione dei blocchi successivi.

· Ottimizzazione del layer di archiviazione: nell'architettura a pipeline, il caching e la persistenza efficienti dei valori di stato multipli e degli impegni di stato sono fondamentali. La terza ottimizzazione si concentra sul miglioramento del layer di archiviazione per soddisfare queste esigenze senza introdurre colli di bottiglia. Ottimizzando il meccanismo di archiviazione, assicuriamo che i dati di stato possano essere scritti rapidamente e recuperati ad alta concorrenza. Questo include la costruzione di un motore di archiviazione multi-versione e il supporto per le operazioni asincrone I/O dall'API di archiviazione al database.

· EVM parallelo: l'ultima ottimizzazione riguarda l'esecuzione delle transazioni all'interno dell'EVM in parallelo. Abbiamo sviluppato Grevm, un runtime EVM parallelo che accelera significativamente l'elaborazione delle transazioni grazie all'esecuzione concorrente. Grevm sfrutta i suggerimenti delle dipendenze dei dati ottenuti dalla simulazione delle transazioni per ottimizzare l'esecuzione parallela, riducendo la riesecuzione delle transazioni e aumentando la capacità.

Grevm (Gravity EVM) - Esecuzione EVM parallela

Grevm è un progetto open-source, ospitato su GitHub (se non è ancora open-source, lo sarà in futuro). Si prega di fare riferimento al suo README per ulteriori informazioni.

Grevm (Gravity EVM) è un runtime EVM parallelo basato su revm. L'algoritmo di Grevm è ispirato a BlockSTM e viene potenziato dall'introduzione di grafi di dipendenza dei dati delle transazioni ottenuti dalla simulazione. Questo meccanismo rende la programmazione dell'esecuzione parallela più efficiente, riducendo al minimo la riesecuzione delle transazioni.

Nei nostri test di benchmark, Grevm è attualmente l'implementazione EVM parallela open-source più veloce. Per le transazioni senza conflitti, Grevm è 4,13 volte più veloce rispetto all'esecuzione sequenziale, raggiungendo una velocità di 26,50 gigagas/s. Se si simula un ritardo I/O di 100 μs nel mondo reale, la sua velocità è 50,84 volte quella dell'esecuzione sequenziale, con una capacità di 6,80 gigagas/s. Questo balzo nelle prestazioni è dovuto all'integrazione dell'esecuzione parallela con le operazioni I/O asincrone, che consente un'efficace sovrapposizione delle operazioni I/O, accelerando ulteriormente il processo.

L'idea centrale di Grevm è sfruttare la dipendenza dei dati tra le transazioni, ottimizzando l'esecuzione parallela tramite insiemi di lettura/scrittura delle transazioni stimati. Sebbene non tutti i suggerimenti siano completamente accurati, questi suggerimenti basati sulla simulazione sono spesso sufficientemente pratici. Ad esempio, sulla mainnet di Ethereum, in base all'utilizzo storico del gas, circa il 30% delle transazioni è semplice trasferimento di Ether, un ulteriore 25%-30% è trasferimento di token ERC20, e queste transazioni coinvolgono generalmente solo la lettura e la scrittura di un numero limitato di account e slot di archiviazione. Per queste transazioni, i risultati della simulazione hanno una coerenza nell'accuratezza.

Sulla base di queste intuizioni, abbiamo sviluppato un framework di esecuzione parallela a tre fasi per Grevm, come prosecuzione del modello Block-STM, combinando i suggerimenti delle dipendenze ottenuti dalla simulazione delle transazioni:

· Fase 1: generazione di suggerimenti e pre-caricamento dello stato - simulare transazioni per raccogliere suggerimenti di dipendenza e pre-riscaldare la cache della memoria. Questa fase può essere eseguita in diversi momenti, a seconda del design della blockchain. Ad esempio, quando nuove transazioni arrivano nel pool di memoria, si può immediatamente eseguire la simulazione per preparare in anticipo i suggerimenti di dipendenza.

· Fase 2: analisi delle dipendenze - trasformare i suggerimenti di dipendenza raccolti nella fase di simulazione in un grafo aciclico diretto (DAG) che rappresenta le dipendenze tra le transazioni. Questo DAG verrà utilizzato per pianificare la programmazione delle transazioni nell'esecuzione parallela successiva.

· Fase 3: esecuzione parallela sotto risoluzione dei conflitti - utilizzare una versione modificata dell'algoritmo BlockSTM basata su DAG di dipendenze per eseguire le transazioni in parallelo. La programmazione non seleziona più rigidamente le transazioni in base al numero di sequenza nel blocco (come 1, 2, 3, ..., n), ma prioritizza le transazioni in base all'ordinamento DAG, minimizzando i conflitti e riducendo la necessità di riesecuzione.

Invio asincrono in batch degli stati

La generazione dell'impegno allo stato rimane un collo di bottiglia chiave nella pipeline blockchain, derivante dalla natura sequenziale della merkleizzazione. Ogni calcolo del sotto-albero deve completarsi prima di generare l'impegno finale allo stato, il che comporta ritardi significativi. Anche se soluzioni esistenti (come la parallelizzazione a livello di account di reth) introducono un certo grado di parallelizzazione, c'è ancora ampio margine di ottimizzazione. Nel contesto del reattore di flusso di blocchi (BSR) di Gravity reth, il consenso dell'impegno allo stato e l'esecuzione delle transazioni vengono disaccoppiati, permettendo il calcolo degli impegni di stato in modo asincrono e in batch senza bloccare l'esecuzione.

Per affrontare questi problemi, il framework proposto introduce le seguenti innovazioni chiave:

Calcolo asincrono dell'hash in batch: sfruttando il disaccoppiamento tra il consenso sull'impegno e l'esecuzione delle transazioni, questo framework realizza il calcolo asincrono degli impegni di stato. Gli aggiornamenti delle radici di stato vengono eseguiti in batch (ad esempio, ogni 10 blocchi) per ridurre la frequenza di calcolo delle radici di stato. Questo approccio di elaborazione batch consente un calcolo hash efficiente per i nodi sporchi condivisi, riducendo al minimo i costi di aggiornamento frequenti e abbassando i costi di calcolo complessivi. Per blocchi piccoli, l'elaborazione in batch può migliorare significativamente la parallelizzazione; per blocchi grandi, può ridurre i costi complessivi di calcolo.

Completamente parallelizzata: questo framework estende la parallelizzazione all'intero albero di stato, non solo a un singolo albero di account. Per i nodi contrassegnati come 'sporchi', il framework utilizza un algoritmo di calcolo dello stato parallelo, suddividendo l'albero in sotto-alberi indipendenti e gestendo in parallelo questi sotto-alberi. I risultati vengono aggregati in cima per calcolare in modo efficiente la radice finale. Questo metodo garantisce che i grandi blocchi contenenti un gran numero di transazioni e cambiamenti di stato possano sfruttare pienamente il multithreading, massimizzando così la capacità.

Radice dello stato alternativa rapida: per adattarsi all'intestazione del blocco di Ethereum e all'operazione op_BLOCKHASH (che richiede l'accesso alla radice di stato degli ultimi 256 blocchi), abbiamo ridefinito la radice di stato. A differenza della dipendenza dall'impegno finale dello stato (non disponibile durante l'esecuzione delle transazioni), calcoliamo la radice di stato come una combinazione dell'insieme di modifiche del blocco e dell'hash della radice di stato precedente. Questo metodo rende il calcolo della radice di stato più rapido, senza dover attendere il completamento dell'impegno dello stato.

Gravity Store

Per soddisfare le esigenze di gestione di grandi dati delle blockchain ad alte prestazioni, Gravity Store è emerso come un layer di archiviazione multi-versione ottimizzato. Si basa sul design di reth, che ha ridotto il problema dell'espansione dello stato separando l'archiviazione dell'impegno di stato e dei dati di stato, riducendo nel contempo i costi di lettura e scrittura dei dati. Tuttavia, il layer di esecuzione Gravity reth deve supportare ulteriormente l'elaborazione parallela e l'invio asincrono degli impegni di stato, presentando ulteriori requisiti tecnici.

Per affrontare queste sfide, Gravity Store ha proposto una struttura ad albero multi-versione altamente efficiente, progettata su misura per la nostra architettura BSR (Block Stream Reactor). Questa struttura ad albero supporta la gestione degli aggiornamenti di stato multi-versione. Diversamente dal metodo tradizionale di aggiornamento immediato dell'hash dopo la modifica, Gravity Store contrassegna i nodi modificati come 'nodi sporchi', consentendo così un'elaborazione ritardata e batch del calcolo dell'hash. Questo design consente una rapida creazione di nuove versioni, query efficienti dei dati di versioni specifiche e la pulizia delle vecchie versioni al di sotto di un'altezza specificata, migliorando notevolmente le prestazioni nella gestione dello stato della blockchain.

Stiamo anche esplorando lo sviluppo indipendente di un motore di archiviazione Gravity DB, il cui obiettivo di design è fornire un layer di archiviazione ottimizzato per le applicazioni blockchain e supportare operazioni di I/O completamente asincrone. Il design di questo motore è ispirato a LETUS, un motore di database generico strutturato per log ad alte prestazioni orientato alla blockchain. Il nostro principale sviluppatore, Richard, uno dei principali autori di LETUS, fornirà dettagli sul suo design in un prossimo articolo sul blog.

Conclusione

Gravity Chain è una blockchain di primo livello compatibile con EVM ad alte prestazioni, progettata per soddisfare le esigenze di scalabilità e prestazioni delle moderne applicazioni web3. Combinando Gravity SDK, il motore di consenso PoS a pipeline AptosBFT e il layer di esecuzione Gravity reth alimentato da Grevm, Gravity raggiunge una capacità di 1 gigagas al secondo, tempi di conferma delle transazioni in sub-secondo e sicurezza PoS basata su meccanismi di Restaking. Questi componenti tecnologici sono progettati per fornire una base solida per la creazione di blockchain L1 personalizzate o soluzioni L2 più efficienti per le applicazioni web3, particolarmente adatte per ottimizzare gli scenari d'uso delle catene EVM.

Questo articolo proviene da una sottomissione, non rappresenta il punto di vista di BlockBeats.