Source originale : Gravity

Introduction

Depuis le lancement du Gravity Alpha Mainnet en août 2024, le réseau a traité plus de 275 millions de transactions, avec un volume de transactions quotidien atteignant jusqu'à 2,6 millions, et a réussi à atteindre des frais de transaction de 30 millions de G. Avec la publication du Litepaper, nous sommes impatients de découvrir la feuille de route future de cette chaîne EVM haute performance. Cet article analysera en profondeur le Litepaper, révélant comment Gravity construit une architecture de blockchain Layer-1 haute performance exceptionnelle pour des applications du monde réel.

Gravity est une blockchain Layer-1 haute performance et compatible EVM créée par Galxe. Le développement de Gravity est né des besoins de croissance de Galxe. La plateforme Galxe est le plus grand réseau de distribution sur chaîne au monde, reliant un vaste écosystème multi-chaînes et attirant plus de 25 millions d'utilisateurs. Au cours de son développement, Galxe est devenu une super application décentralisée, intégrant des outils innovants tels que Quest, Passport, Score, Compass et Alva, tout en offrant des services variés comme des points de fidélité, des NFT d'événements, des récompenses en tokens, une authentification zk et une épargne intelligente inter-chaînes. Dans ce processus de développement continu, le volume élevé de transactions de Galxe est devenu un facteur clé pour la construction de Gravity : son système de points de fidélité prend en charge 51,2 transactions par seconde, et ses activités de récompenses en tokens prennent en charge 32,1 transactions par seconde. Cela nous a poussés, lors de la décentralisation de l'arrière-plan de Galxe, à nous tourner vers les blockchains EVM tout en maintenant la meilleure expérience utilisateur.

Avec le développement complet de Galxe sur la chaîne, une augmentation supplémentaire du volume des transactions est à prévoir. La demande de débit devrait atteindre 50 millions de gas par seconde, tandis que la satisfaction des besoins écologiques plus larges (tels que le règlement inter-chaînes, les transactions de points de fidélité et les marchés NFT) pourrait nécessiter une capacité de traitement de 500 millions de gas par seconde. Pour cela, l'objectif de Gravity est de soutenir un débit de 1 gigagas par seconde afin de répondre aux besoins d'évolutivité des applications gourmandes en ressources.

Parmi les solutions existantes, de nombreuses plateformes réalisent leur évolutivité via Ethereum, mais les périodes de contestation des Rollup L2 entraînent inévitablement des retards de transactions, ce qui n'est pas convivial pour des applications nécessitant des confirmations de transactions immédiates, comme Galxe. Bien que certaines DApp tentent d'atténuer ce retard par des modes de confiance ou une surveillance externe, ces méthodes introduisent des complexités et des risques supplémentaires, ce qui est clairement peu idéal pour des scénarios d'application clés.

Dans ce contexte, Gravity a vu le jour. Gravity se concentre sur un EVM parallèle et, en développant Grevm, le système d'exécution EVM parallèle open source le plus rapide actuellement, réduit l'écart de performance entre L2 et L1. De plus, Gravity module l'architecture d'Aptos, intégrant des composants éprouvés tels que Quorum Store et le moteur de consensus AptosBFT. En tirant parti de l'architecture mature d'Aptos, Gravity évite la complexité et les risques potentiels associés au développement à partir de zéro. En fin de compte, Gravity construit non seulement une blockchain Layer 1 haute performance offrant une expérience complète de chaîne, mais lance également le premier SDK de blockchain en pipeline, simplifiant considérablement les interactions pour les développeurs et les utilisateurs.

Gravity offre une évolutivité sans précédent, une capacité de décentralisation et une vitesse de transaction quasi instantanée. Sa technologie combine les avantages de L1 et L2, réalisant 10 000 transactions par seconde et une finalité sous seconde. En outre, grâce à l'intégration de protocoles de restaking tels qu'EigenLayer et Babylon, Gravity assure une sécurité robuste dès le départ, tout en réduisant le risque systémique à long terme associé à la dépendance à un actif unique.

À l'avenir, Gravity progressera selon la feuille de route suivante :

· Lancement de la phase 1 de Devnet, test de performances en temps réel ;

· Lancement du Longevity Testnet, vérifiant la stabilité à long terme du réseau ;

· Transition du Gravity Alpha Mainnet à un Gravity Mainnet pleinement opérationnel, établissant les bases de l'application à grande échelle des technologies décentralisées.

Voici la compilation complète du Gravity Litepaper.

Résumé

Gravity est une blockchain Layer-1 hautes performances et compatible EVM, développée par Galxe, conçue pour des applications à grande échelle et un écosystème multi-chaînes. Ses caractéristiques incluent un débit de 1 gigagas par seconde, une confirmation finale des transactions sous seconde et un mécanisme de consensus PoS reposant sur des protocoles de restaking. La conception de Gravity repose sur deux composants open source clés : (1) Gravity SDK, qui est un moteur de consensus PoS basé sur AptosBFT en pipeline ; (2) Gravity reth, une couche d'exécution propulsée par un EVM Grevm (Gravity EVM) parallèle. Ces outils offrent aux applications Web3 la capacité de construire des Layer-1 alternatifs et des Layer-2 efficaces, en particulier sur les chaînes EVM. Cet article explore en profondeur la conception d'ingénierie et l'innovation technique de Gravity, montrant comment répondre aux besoins de haute performance grâce à une architecture de pipeline, des algorithmes de consensus avancés, des technologies d'exécution parallèle et des mécanismes de stockage optimisés (en améliorant reth et en affinant le moteur de consensus Aptos).

Introduction

Le développement de Gravity est né des défis rencontrés par Galxe dans ses opérations. Galxe est une application Web3 de premier plan qui offre à ses utilisateurs des points de fidélité, des NFTs d'événements, des récompenses en tokens, une authentification zk et des économies intelligentes inter-chaînes. Avec la croissance rapide de Galxe, son système de points de fidélité traite en moyenne 51,2 transactions par seconde, tandis que les activités de récompenses en tokens traitent en moyenne 32,1 transactions par seconde. Au fur et à mesure de la décentralisation progressive de Galxe, il est devenu difficile de migrer ces cas d'utilisation vers une blockchain EVM tout en assurant une expérience utilisateur fluide. Il est donc devenu crucial de développer une blockchain EVM haute performance capable de répondre à (1) un débit transactionnel élevé et (2) une confirmation quasi instantanée des transactions.

Dans ce contexte, le choix d'une solution Layer-2 existante ou le développement d'une nouvelle Layer-1 est un point de décision clé. La Layer-1 réalise la finalité grâce à un algorithme de consensus, tandis que la Layer-2 résout ce problème grâce à des protocoles Rollup. Les deux présentent des compromis : la Layer-1 sacrifie généralement une partie du débit en raison des limitations de l'algorithme de consensus, mais permet une confirmation finale des transactions plus rapide. Par exemple, l'algorithme de consensus basé sur AptosBFT peut confirmer des transactions sous seconde, tandis que les Rollups optimistes peuvent avoir une période de contestation allant jusqu'à sept jours. Bien que les preuves à connaissance nulle puissent accélérer ce processus, la confirmation finale nécessite encore des heures. Compte tenu des besoins de Gravity en matière de confirmation finale sous seconde (en particulier pour son protocole d'intention de chaîne complète), nous avons choisi de construire une Layer-1.

Bien que les Layer-2 aient un avantage natif dans la communication avec Ethereum, une Layer-1 comme Gravity peut réaliser une interopérabilité profonde avec Ethereum et d'autres blockchains via le protocole d'intention Gravity et les ponts inter-chaînes. Cette conception permet non seulement une collaboration sans faille avec Ethereum, mais renforce également la connectivité de tout l'écosystème Web3.

De plus, les protocoles de restaking (restaking) réduisent considérablement la difficulté de construire une blockchain PoS Layer-1. Grâce aux protocoles tels qu'EigenLayer et Babylon, Gravity intègre les actifs de jalonnement d'Ethereum et de Bitcoin ainsi que leurs vastes réseaux de validateurs. Cela fournit une garantie économique pour le consensus PoS, permettant à la décentralisation et à la sécurité de Gravity d'atteindre un niveau comparable à celui d'Ethereum.

En résumé, Gravity a été construit en tant que blockchain Layer-1 haute performance et compatible EVM pour satisfaire les besoins de scalabilité et de performance des applications Web3 modernes. Bien que son développement initial ait été destiné à servir Galxe, le cadre flexible offert par Gravity SDK et Grevm (Gravity EVM) est approprié pour construire toute Layer-1 et un Layer-2 efficace, fonctionnant de façon similaire aux SDK Tendermint/Cosmos.

Nous avons besoin d'un débit de 1 gigagas/s

Pour une blockchain, le débit est l'indicateur de performance le plus critique, généralement mesuré en termes de transactions par seconde (TPS) ou d'utilisation de gaz par seconde (gas/s). Prenons le système de points de fidélité de Galxe comme exemple, qui nécessite d'atteindre au moins 4 millions de gas/s pour fonctionner de manière stable. Ce chiffre provient de la consommation moyenne de 80 000 gas par transaction de points de fidélité, tandis qu'environ 51,2 transactions peuvent être traitées par seconde.

Cette prévision a été soutenue par les données pratiques du Gravity Alpha Mainnet. En tant que réseau Layer 2 dans nos tests, les transactions de points de fidélité du Gravity Alpha Mainnet ont montré que son débit peut atteindre de manière stable 4 millions de gas/s, validant ainsi l'exactitude des estimations précédentes.

Bien que les coûts élevés des opérations sur chaîne puissent entraîner une légère baisse de la demande, la tendance à l'expansion de Galxe montre qu'en période de pointe, la demande pourrait augmenter jusqu'à deux à trois fois son niveau actuel. De plus, avec l'ajout d'autres cas d'utilisation, tels que les NFT, les récompenses en tokens, ainsi que le soutien futur des preuves à connaissance nulle, si Galxe devient entièrement sur chaîne, on s'attend à ce que la demande de débit atteigne 50 millions de gas/s. En supposant que l'utilisation de gas des applications sur Gravity suit une distribution de Pareto (similaire à Uniswap consommant 10 % du gas d'Ethereum), pour répondre à des besoins écologiques plus larges, tels que le règlement inter-chaînes, les transactions de points de fidélité et le marché NFT, idéalement, un débit de 500 millions de gas/s devrait être soutenu. Par conséquent, pour répondre à ces besoins potentiels, la blockchain doit avoir une capacité de traitement de 1 gigagas par seconde, garantissant qu'elle peut s'adapter à l'évolutivité des applications gourmandes en ressources.

Pour atteindre un débit aussi élevé, il est essentiel d'introduire un EVM parallèle. Nous avons développé Grevm, qui est actuellement le système d'exécution EVM parallèle open source le plus rapide, dont les performances peuvent être consultées dans les chapitres suivants.

Temps de confirmation sous seconde

Au-delà du débit, la vitesse de confirmation des transactions est également cruciale pour l'expérience utilisateur. Les utilisateurs modernes sont habitués à des réponses quasi instantanées similaires à celles du Web2, ce qui reste un défi pour les blockchains. Prenons Galxe comme exemple, qui est similaire à un jeu entièrement sur chaîne et exige une faible latence. Actuellement, le temps de confirmation des transactions sur la plupart des blockchains EVM varie de quelques secondes à plusieurs jours, ce qui est loin de répondre à cette exigence. Nous avons choisi l'algorithme de consensus AptosBFT pour réaliser des temps de confirmation sous seconde.

Bien que les Rollup Layer-2 puissent théoriquement augmenter le débit, leurs périodes de contestation entraînent des retards sur les transactions, ce qui est très défavorable pour les applications nécessitant une confirmation de transaction immédiate (comme Galxe). Bien que certaines DApp tentent d'optimiser cela par des modes de confiance ou une surveillance externe, cela introduit une complexité et des risques supplémentaires, ce qui n'est pas idéal pour les applications critiques. Le Gravity SDK, grâce à la conception d'un pipeline à cinq étapes, parallélise les processus de consensus et d'exécution, réduisant ainsi l'écart de performance entre L2 et L1 (les détails de la conception seront abordés plus loin).

Sécurité PoS basée sur le restaking

Le Gravity SDK offre une méthode sécurisée pour étendre Ethereum, ne se limitant pas à L2 Rollup, mais choisissant une architecture L1 protégée par un restaking, équilibrant performance, interopérabilité et sécurité. Les modules centraux intègrent des protocoles de restaking tels qu'EigenLayer et Babylon, fournissant un soutien économique de confiance pour garantir un consensus robuste à preuve d'enjeu.

Avec les 45 milliards de dollars d'actifs de jalonnement d'Ethereum et 850 000 validateurs, ainsi que l'accès aux 600 milliards de dollars d'actifs de Bitcoin via Babylon, Gravity peut établir dès le départ une base de sécurité solide, évitant les problèmes de démarrage et les risques de sécurité courants auxquels font face les nouvelles blockchains, tout en réduisant à long terme le risque systémique d'une dépendance à un actif unique.

Architecture de Gravity Chain

Gravity Chain comprend deux composants principaux : Gravity SDK et Gravity reth. Gravity SDK est un cadre de blockchain amélioré dérivé de la chaîne Aptos, qui est actuellement la blockchain PoS la plus avancée basée sur la famille des algorithmes de consensus HotStuff, dont l'architecture en pipeline améliore considérablement le débit et l'efficacité des ressources. Gravity reth est la couche d'exécution basée sur reth, fonctionnant sous la forme d'un réacteur de flux de blocs (BSR) pour recevoir les blocs proposés de la couche de consensus. En optimisant reth, Gravity reth réalise une exécution parallèle, un calcul de soumission d'état par lots asynchrones et une amélioration de l'efficacité du stockage. Ces deux composants sont étroitement liés par l'interface de moteur de consensus Gravity (GCEI) et l'adaptateur reth, gérés dynamiquement par le contrôleur de pipeline à chaque étape.

Cette conception sépare l'exécution des blocs du consensus des blocs, permettant à la couche d'exécution d'agir en tant que consommateur de propositions de blocs. Nous avons optimisé reth pour qu'il s'adapte parfaitement au processus de proposition de blocs géré par le réacteur de flux de blocs (BSR).

Le flux de transactions de Gravity Chain est le suivant :

1. Les transactions sont soumises via l'interface JSON RPC de Gravity reth, qui est entièrement compatible avec Ethereum.

2. Ensuite, les transactions entrent dans le pool de mémoire du Gravity SDK et se propagent à travers le réseau, les validateurs traitant les transactions par lots et générant des certificats Quorum Store (QS).

3. À chaque tour, un leader propose une proposition de bloc contenant des métadonnées de bloc et des transactions ordonnées sélectionnées depuis le pool de mémoire et QS.

4. Une fois que la proposition est marquée comme ordonnée, elle entre dans la couche d'exécution.

5. La couche d'exécution Grevm traite les transactions en parallèle, génère les résultats d'exécution et transmet le nouvel état au module de gestion d'état.

6. Le module d'état calcule la racine d'état et la transmet au moteur de consensus pour parvenir à un consensus sur la racine d'état.

7. Une fois la racine d'état confirmée, le module de stockage persiste la racine d'état et les données du bloc.

Les chapitres suivants détailleront chaque composant.

Gravity SDK : Pratique innovante de blockchain open source en pipeline

Gravity SDK est un cadre de blockchain open source modulaire, développé sur la blockchain Aptos prête pour la production. Son objectif est de modulariser l'architecture d'Aptos, en s'inspirant de composants éprouvés tels que Quorum Store et le moteur de consensus AptosBFT, pour créer le premier SDK de blockchain en pipeline.

Les raisons pour lesquelles Gravity SDK a choisi Aptos comme base incluent :

· Architecture technique de premier plan : Aptos est une blockchain PoS avancée basée sur le consensus de la famille HotStuff.

· Performance optimale : Aptos offre un débit de 160 000 transactions par seconde, avec un temps de confirmation finale inférieur à 1 seconde.

· Fiabilité en conditions réelles : Aptos a été validé dans des environnements de production, montrant une stabilité et une efficacité exceptionnelles.

· Éviter de réinventer la roue : tirer parti de l'architecture mature d'Aptos permet d'éviter la complexité et les risques potentiels du développement à partir de zéro, tandis que d'autres tentatives de surpasser Aptos sont souvent théoriques et pratiquement insuffisantes.

· Gains de synergie : avec le développement continu d'Aptos, le Gravity SDK pourra s'intégrer sans faille à ses nouvelles fonctionnalités, telles que l'API de nombres aléatoires, tout en réinjectant des innovations de sécurité via une architecture modulaire.

La blockchain basée sur le Gravity SDK se connecte au moteur de consensus Gravity (GCEI) via le moteur de consensus en pipeline. Bien que le GCEI soit compatible avec plusieurs couches d'exécution, le Gravity SDK prend principalement en charge Gravity reth pour le moment. Les détails concernant le GCEI seront discutés dans les chapitres suivants.

Interface de moteur de consensus Gravity (GCEI)

Le protocole GCEI (Gravity Consensus Execution Interface) est un pont de communication entre la couche de consensus et la couche d'exécution. Il réglemente les interactions entre les deux couches, garantissant que les processus de consensus et d'exécution restent synchronisés via le contrôleur de pipeline.

La principale différence entre le SDK de blockchain traditionnel et le Gravity SDK réside dans son moteur de consensus en pipeline. La couche d'exécution doit être mise en œuvre en tant que réacteur de flux de blocs (Block Stream Reactor), ce qui signifie qu'elle doit être capable de consommer en continu le flux de blocs proposés, et l'engagement d'état doit être calculé de manière asynchrone par rapport à l'exécution des transactions. En outre, la couche d'exécution doit être en mesure de fournir des signaux de rétroaction à la couche de consensus pour ajuster dynamiquement le rythme de proposition des blocs.

En outre, en raison des caractéristiques de pipeline du Gravity SDK, la couche d'exécution doit être capable de traiter les transactions non exécutables dans les blocs proposés, car le pool de mémoire ne peut pas vérifier strictement la validité des transactions en raison de l'absence d'accès à l'état mondial le plus récent : l'exécution peut ne pas être terminée. De plus, les résultats d'exécution ne doivent pas bloquer la génération des blocs suivants, car après la parallélisation du consensus des blocs et du consensus d'état dans le Gravity SDK, la couche d'exécution devient un réacteur pour le flux de blocs proposés, capable de renvoyer librement les résultats d'exécution aux étapes suivantes.

Le protocole GCEI définit deux ensembles d'API :

· API de la couche de consensus : ces API sont mises en œuvre par le Gravity SDK pour que la couche d'exécution réponde aux propositions de blocs du moteur de consensus et soumette les engagements d'état.

· API de couche d'exécution : ces API doivent être mises en œuvre par la couche d'exécution. Le moteur de consensus utilisera ces API pour valider les propositions de transactions avant de les soumettre à un bloc, pour fluidifier les blocs proposés, et pour notifier la couche d'exécution de l'engagement d'état final.

Du point de vue du cycle de vie des transactions, le protocole GCEI définit ce qui suit :

1. check_txn (API de la couche d'exécution)

· Entrée : recevoir une transaction (GTxn) en entrée.

· Sortie : retourne l'adresse de l'expéditeur de la transaction, le nonce et la limite de gas.

Utilité : cette méthode est utilisée par le moteur de consensus pour exécuter une validation de bonne foi avant de proposer une transaction à un bloc. Cette méthode peut être appelée plusieurs fois pour la même transaction, par exemple lorsque la transaction entre dans le pool de mémoire, avant d'être proposée dans un bloc et lors de la finalisation de l'engagement d'état.

2. submit_txn (API de la couche de consensus)

Entrée : recevoir une transaction (GTxn) de la couche d'exécution.

Sortie : retourne Result<()> indiquant si la transaction a été ajoutée avec succès au pool de mémoire.

Utilité : la couche d'exécution peut utiliser cette méthode pour soumettre des transactions au pool de mémoire. Le moteur de consensus propagera ensuite cette transaction à travers le réseau et formera un Quorum Store après avoir reçu un lot de transactions.

3. recv_ordered_block (API de la couche d'exécution)

Entrée : recevoir un ordered_block (type BlockBatch), contenant des transactions triées et des métadonnées de bloc.

Sortie : retourne Result<()>, indiquant si la couche d'exécution a réussi à recevoir et à accepter ce bloc.

Utilité : une fois qu'un bloc a été proposé par le moteur de consensus, il sera envoyé à la couche d'exécution pour l'exécution des transactions. Cette méthode permet à la couche d'exécution de recevoir et de traiter le bloc proposé.

4. update_state_commitment (API de la couche de consensus)

Entrée : engagement d'état (StateCommitment) d'un numéro de bloc donné.

Sortie : retourne Result<()>, indiquant si l'engagement d'état a été accepté avec succès par le moteur de consensus local.

Utilité : après que la couche d'exécution ait calculé l'engagement d'état, elle l'envoie à la couche de consensus pour finalisation, c'est-à-dire pour parvenir à un consensus léger de 2f+1 avec d'autres validateurs. Si le consensus sur l'engagement d'état diverge trop de l'avancement du bloc proposé, le contrôleur de pipeline ajustera le rythme de proposition des blocs.

5. commit_block_hash (API de la couche d'exécution)

Entrée : recevoir un vecteur de block_ids, représentant les blocs à soumettre.

Sortie : retourne Result<()> indiquant le succès ou l'échec de l'opération.

Utilité : lorsque l'engagement d'état est finalisé, la couche de consensus avisera la couche d'exécution de soumettre le hachage du bloc au stockage de la blockchain.

Pipeline de blockchain

Le Gravity SDK maximise l'utilisation des ressources matérielles grâce à une architecture de pipeline à cinq étapes, permettant ainsi d'obtenir un débit plus élevé et une latence plus faible. Le pipeline exécute des tâches entre différents blocs de manière entrelacée, le gestionnaire de pipeline utilisant un mécanisme de rétroaction pour garantir que la blockchain avance de manière régulière. Les trois premières étapes appartiennent à la couche de consensus, tandis que les deux dernières appartiennent à la couche d'exécution.

Les différentes phases sont expliquées comme suit :

· Phase 1 : Propagation des transactions : cette phase propage efficacement les transactions entre les validateurs, garantissant que les transactions sont incluses de manière opportune et fiable pendant la construction des blocs. La conception découple la propagation des transactions du mécanisme de consensus, suivant les idées de Narwhal & Tusk et d'Aptos, où les validateurs partagent en continu des lots de transactions, exploitant toutes les ressources du réseau pour fonctionner simultanément. Lorsqu'un lot de transactions obtient une signature de poids de 2f+1 (formant un PoAv, c'est-à-dire une preuve de disponibilité), il est garanti que ce lot de transactions est stocké par au moins f+1 validateurs honnêtes, permettant à tous les validateurs honnêtes de récupérer ces transactions pour exécution.

· Phase 2 : Tri des métadonnées des blocs : cette phase établit un ordre cohérent et reconnu des transactions et des métadonnées de blocs au sein du réseau. Le mécanisme de consensus (AptosBFT) suit la règle des doubles chaînes (2-chain rule) pour fournir des blocs tolérants aux fautes Byzantines. Les blocs passeront ensuite à la phase d'exécution, prêts pour un traitement parallèle.

· Phase 3 (BSR) : Exécution parallèle des transactions : cette phase fait partie de la couche d'exécution, où les transactions sont exécutées en parallèle. Les résultats d'exécution seront transmis à la phase d'engagement d'état.

· Phase 4 : Engagement d'état : cette phase complète les changements d'état causés par l'exécution des transactions et prépare la finalisation des blocs. L'engagement d'état et l'exécution des transactions sont calculés de manière asynchrone, garantissant que l'exécution du prochain bloc n'est pas entravée par l'engagement d'état du bloc actuel.

· Phase 5 : Persistance de l'état : cette phase persiste les changements d'état engagés dans le stockage de la blockchain. La racine d'état finale et les données associées sont stockées dans Gravity Store, qui utilise un moteur de stockage hautement optimisé, conçu pour un accès rapide et fiable. Elle informe également le pool de mémoire et le Quorum Store de supprimer les transactions futures qui ne pourront plus être incluses.

Modules de jalonnement et de restaking

Construire une blockchain Layer 1 à preuve d'enjeu (PoS) sécurisée est une tâche complexe, notamment dans le cas où le jalonnement dépend uniquement de tokens spécifiques sur la chaîne. Cette approche peut faire face à des problèmes de sécurité économique insuffisante à un stade précoce, tels que la volatilité de la valeur des tokens ou une participation limitée des validateurs. Pour résoudre ce problème, le Gravity SDK propose un module de jalonnement et de restaking flexible, conçu pour améliorer la sécurité du réseau grâce à des mécanismes de jalonnement locaux et externes.

L'une des stratégies clés du Gravity SDK est l'introduction de protocoles de Restaking tels qu'EigenLayer et Babylon. Ces protocoles permettent aux validateurs de restaker les actifs d'autres réseaux matures (comme Ethereum et Bitcoin), tirant ainsi parti de leur sécurité existante. En permettant aux validateurs de mettre en gage les actifs de ces chaînes, le Gravity SDK peut améliorer la sécurité économique du réseau sans dépendre complètement des tokens locaux. Cette approche renforce non seulement la robustesse de la chaîne, mais favorise également la diversité de l'écosystème des validateurs. La conception du module de jalonnement est axée sur la modularité, son composant de restaking étant hautement flexible et capable de s'adapter facilement aux nouveaux protocoles de restaking à mesure que l'écosystème blockchain évolue.

Ce module prend en charge non seulement les actifs de restaking, mais aussi le jalonnement de tokens ERC20 personnalisés pris en charge sur la chaîne, tels que le token G sur Ethereum. Les validateurs peuvent participer au consensus en jalonnant ces tokens autorisés, contribuant ainsi à la sécurité du réseau. Le poids de vote des validateurs est calculé en fonction de leur valeur totale de jalonnement, y compris les tokens personnalisés et les actifs du protocole de restaking. Ce calcul est effectué en fonction de la configuration spécifique de la chaîne, garantissant que chaque chaîne peut définir ses propres règles de jalonnement et de restaking de manière flexible selon ses besoins.

Le gestionnaire d'Epoch dans le moteur de consensus collabore directement avec le module de jalonnement pour calculer le poids du prochain ensemble de validateurs. Il assure que le processus de consensus reflète avec précision la dynamique de jalonnement la plus récente en obtenant la valeur de jalonnement de la couche d'exécution. Dans cette architecture, les actifs inter-chaînes (comme les actifs de jalonnement provenant d'Ethereum) doivent d'abord être pontés vers la couche d'exécution avant de pouvoir être utilisés pour calculer la valeur totale de jalonnement des validateurs. La mise en œuvre du mécanisme de pontage est de la responsabilité de la couche d'exécution, permettant ainsi une gestion plus flexible de la communication inter-chaînes. Les solutions possibles comprennent des ponts PoS, des preuves à connaissance nulle sur l'état de la chaîne, et des messages inter-chaînes auto-démarrants intégrés.

Plus de détails techniques, des conceptions API et des explications complètes des mécanismes de jalonnement et de restaking seront présentés dans des documents ultérieurs.

Gravity Reth : couche d'exécution EVM réacteur de flux de blocs

L'intégration de la couche d'exécution EVM d'Ethereum dans l'architecture du Gravity SDK pose des défis uniques, notamment lorsqu'il s'agit de tirer pleinement parti des capacités de son moteur de consensus en pipeline. Pour réaliser cette intégration sans faille et exploiter pleinement le potentiel de cette architecture, nous avons dû effectuer plusieurs optimisations clés sur le client open source Ethereum reth. Ces optimisations transforment fondamentalement reth en Gravity reth, une couche d'exécution EVM optimisée pour le moteur de consensus en pipeline.

Les architectures de blockchain traditionnelles traitent les blocs séquentiellement, garantissant que chaque bloc est complètement validé et exécuté avant de proposer le suivant. Cependant, le Gravity SDK adopte un mécanisme de consensus en pipeline, séparant les différentes étapes du traitement des blocs pour améliorer les performances. Ce changement de paradigme introduit une complexité :

Transactions inattendues : dans une chaîne en pipeline, le pool de mémoire ne peut pas accéder à l'état mondial le plus récent en raison de l'exécution potentiellement inachevée du bloc précédent. Par conséquent, les transactions contenues dans le bloc proposé peuvent ne pas être exécutables au moment de la proposition, car leur validité ne peut pas être strictement vérifiée sans l'état le plus récent.

Exécution non bloquante des résultats : pour éviter que le pipeline ne se bloque, les résultats d'exécution ne doivent pas entraver la génération des blocs suivants. La couche d'exécution doit pouvoir traiter de manière asynchrone les blocs proposés et renvoyer les résultats d'exécution à une étape ultérieure sans bloquer le processus de consensus. Pour l'EVM, cela signifie qu'il est nécessaire de redéfinir le blockhash, en éliminant la dépendance au champ stateRoot dans l'en-tête du bloc.

Pour résoudre ces problèmes, nous avons introduit quatre optimisations clés :

· Réacteur de flux de blocs (Block Stream Reactor, BSR) : le BSR vise à ajuster reth au processus de proposition de blocs en pipeline du Gravity SDK. Il permet à la couche d'exécution de consommer en continu le flux de blocs proposés, agissant comme un réacteur de traitement asynchrone des blocs. Le BSR établit un cycle de rétroaction dynamique avec le moteur de consensus, combinant des signaux de rétroaction appropriés. Ces signaux ajustent en temps réel la vitesse de proposition de blocs et de soumission d'état en fonction du débit et de la latence de la couche d'exécution. Si la couche d'exécution est retardée en raison de transactions complexes ou de limitations de ressources, le mécanisme de rétroaction réduira le taux de proposition de blocs pour maintenir la stabilité du système.

· Découplage de la soumission d'état et de l'exécution des transactions : la deuxième optimisation implique de séparer le calcul de la soumission d'état de l'exécution des transactions. En découplant ces processus, nous avons réalisé l'asynchronisation du calcul de la soumission d'état, permettant à l'exécution des blocs suivants de ne pas attendre la finalisation de la soumission d'état du bloc actuel. Nous avons redéfini le blockhash, éliminant la dépendance au champ stateRoot dans l'en-tête du bloc, garantissant que le calcul de la racine d'état ne bloque pas la génération de blocs suivants.

· Optimisation de la couche de stockage : dans l'architecture en pipeline, le cache efficace et la persistance des valeurs d'état multi-version et des soumissions d'état sont cruciaux. La troisième optimisation se concentre sur le renforcement de la couche de stockage pour répondre à ces besoins sans introduire de goulets d'étranglement. Grâce à l'optimisation du mécanisme de stockage, nous garantissons que les données d'état peuvent être rapidement écrites et récupérées avec une haute concurrence. Cela inclut la construction d'un moteur de stockage multi-version et le support d'E/S asynchrones de l'API de stockage à la base de données.

· EVM parallèle : la dernière optimisation concerne l'exécution des transactions à l'intérieur de l'EVM de manière parallèle. Nous avons développé Grevm, un environnement d'exécution EVM parallèle qui accélère considérablement le traitement des transactions par l'exécution concurrente des transactions. Grevm optimise l'exécution parallèle en utilisant les indications de dépendance des données obtenues à partir de la simulation des transactions, réduisant ainsi la réexécution des transactions et augmentant le débit.

Grevm (Gravity EVM) - Exécution EVM parallèle

Grevm est un projet open source, hébergé sur GitHub (s'il n'est pas encore open source, il le sera prochainement). Veuillez vous référer à son README pour plus d'informations.

Grevm (Gravity EVM) est un environnement d'exécution EVM parallèle basé sur revm. L'algorithme de Grevm s'inspire de BlockSTM et est renforcé par l'introduction de graphiques de dépendance de données issus de la simulation des transactions. Ce mécanisme rend l'ordonnancement de l'exécution parallèle plus efficace, minimisant ainsi les besoins de réexécution des transactions.

Dans nos tests de référence, Grevm est actuellement la mise en œuvre open source parallèle EVM la plus rapide. Pour les transactions sans conflit, Grevm est 4,13 fois plus rapide que l'exécution séquentielle, atteignant une vitesse de 26,50 gigagas/s. Si l'on simule un délai d'E/S de 100 μs du monde réel, sa vitesse est 50,84 fois celle de l'exécution séquentielle, avec un débit de 6,80 gigagas/s. Ce bond en performance est dû à l'intégration de l'exécution parallèle et des opérations d'E/S asynchrones, permettant une superposition efficace des opérations d'E/S pour une accélération supplémentaire.

L'idée centrale de Grevm est d'utiliser la dépendance des données entre les transactions pour optimiser l'exécution parallèle à l'aide d'ensembles de lecture/écriture de transactions spéculatives. Bien que toutes les indications ne soient pas entièrement précises, ces indications basées sur la simulation sont généralement suffisamment pratiques. Par exemple, sur la chaîne principale Ethereum, environ 30 % des transactions sont de simples transferts d'Ethereum, et 25 % à 30 % concernent des transferts de tokens ERC20, ces transactions impliquant généralement la lecture et l'écriture d'un nombre limité de comptes et de slots de stockage. Pour ces transactions, les résultats de simulation montrent une précision cohérente.

Sur la base de ces idées, nous avons développé un cadre d'exécution parallèle en trois phases pour Grevm, en tant que suite du modèle Block-STM, intégrant des indications de dépendance des données issues de la simulation des transactions :

· Phase 1 : Génération d'indices et préchargement d'état - simuler des transactions pour recueillir des indices de dépendance et préchauffer le cache mémoire. Cette phase peut être exécutée à différents moments, selon la conception de la blockchain. Par exemple, lorsque de nouvelles transactions arrivent dans le pool de mémoire, une simulation peut être exécutée immédiatement pour préparer à l'avance des indices de dépendance.

· Phase 2 : Analyse de dépendance - transformer les indications de dépendance recueillies lors de la phase de simulation en un graphique acyclique dirigé (DAG) représentant les dépendances entre transactions. Ce DAG sera utilisé pour planifier l'ordonnancement des transactions dans les exécutions parallèles suivantes.

· Phase 3 : Exécution parallèle sous résolution de conflits - exécuter les transactions en parallèle en utilisant une version modifiée de l'algorithme BlockSTM basé sur les dépendances DAG. Le programmeur d'ordonnancement ne sélectionne plus strictement les transactions en fonction du numéro de séquence dans le bloc (comme 1, 2, 3, ..., n), mais priorise plutôt les transactions en fonction du DAG pour minimiser les conflits et réduire les besoins de réexécution.

Soumission d'état par lots asynchrone

La génération de la soumission d'état reste un goulot d'étranglement clé dans le pipeline de blockchain, découlant de la nature séquentielle de la transformation de Merkle. Chaque calcul de sous-arbre doit être terminé avant de générer la soumission finale de l'état, ce qui entraîne des délais significatifs. Bien que les solutions existantes (comme la parallélisation au niveau des comptes de reth) introduisent un certain degré de parallélisme, il reste encore beaucoup de place pour l'optimisation. Dans le contexte du réacteur de flux de blocs (BSR) de Gravity reth, le consensus sur la soumission d'état et l'exécution des transactions sont découplés, ce qui permet des calculs de soumission d'état différés et en lot sans bloquer l'exécution.

Pour résoudre ces problèmes, le cadre proposé introduit les innovations clés suivantes :

Calcul de hachage par lots asynchrones : en séparant le consensus sur la soumission d'état et l'exécution des transactions, ce cadre réalise le calcul asynchrone de la soumission d'état. La mise à jour de la racine d'état se fait par lots (par exemple, en la calculant tous les 10 blocs) pour réduire la fréquence des calculs de racine d'état. Cette méthode de traitement par lots garantit un calcul de hachage efficace des nœuds sales partagés, minimisant ainsi les coûts d'actualisation fréquente et réduisant les coûts de calcul globaux. Pour les petits blocs, le traitement par lots peut considérablement augmenter la parallélisation ; pour les grands blocs, cela peut réduire les coûts de calcul globaux.

Parallélisation complète : ce cadre étend la parallélisation à l'ensemble de l'arbre d'état, et non pas seulement à un arbre de compte unique. Pour les nœuds marqués comme 'sales', le cadre utilise un algorithme de calcul d'état parallèle qui divise l'arbre en sous-arbres indépendants et les traite en parallèle. Les résultats sont agrégés au niveau supérieur pour calculer efficacement la racine finale. Cette méthode garantit que les grands blocs contenant de nombreuses transactions et modifications d'état peuvent pleinement tirer parti du multithreading, maximisant ainsi le débit.

Racine d'état rapide en alternative : pour s'adapter à l'en-tête de bloc Ethereum et à l'opcode BLOCKHASH (nécessitant l'accès aux racines d'état des 256 blocs les plus récents), nous avons redéfini la racine d'état. Contrairement à la dépendance à la soumission finale d'état (qui n'est pas disponible pendant l'exécution des transactions), nous calculons la racine d'état comme une combinaison du lot de changements de blocs et de l'ancien hachage de la racine d'état. Cette méthode permet un calcul de racine d'état plus rapide, sans attendre l'achèvement de la soumission complète de l'état.

Gravity Store

Pour répondre aux exigences de gestion de données à grande échelle des blockchains haute performance, Gravity Store est né en tant que couche de stockage multi-version optimisée. Il est basé sur la conception de reth, qui a déjà réduit le problème de l'expansion de l'état en séparant le stockage de l'engagement d'état et le stockage des données d'état, tout en réduisant les coûts d'E/S pour la lecture et l'écriture de données. Cependant, la couche d'exécution Gravity reth doit soutenir davantage le traitement parallèle et la soumission d'état asynchrone, ce qui pose des exigences techniques supplémentaires.

Pour relever ces défis, Gravity Store propose une structure d'arbre multi-version efficace, spécialement conçue pour notre architecture BSR (Block Stream Reactor). Cette structure d'arbre prend en charge la gestion des mises à jour d'état multi-version. Contrairement à l'approche traditionnelle qui met à jour immédiatement la valeur de hachage après modification, Gravity Store marque les nœuds modifiés comme 'nœuds sales', permettant ainsi un traitement différé du calcul de hachage et une exécution par lots. Cette conception permet de créer rapidement de nouvelles versions, d'interroger efficacement les données d'une version spécifique, et de nettoyer les anciennes versions en dessous d'une certaine hauteur, améliorant considérablement les performances de gestion de l'état de la blockchain.

Nous explorons également le développement indépendant d'un moteur de stockage Gravity DB, dont l'objectif de conception est de fournir une couche de stockage optimisée pour les applications blockchain, tout en supportant des opérations d'E/S entièrement asynchrones. La conception de ce moteur s'inspire de LETUS, un moteur de base de données log structure high performance destiné aux blockchains. Notre développeur principal Richard, l'un des principaux auteurs de LETUS, présentera les détails de sa conception dans un article de blog à venir.

Conclusion

Gravity Chain est une blockchain de première couche hautes performances compatible EVM, conçue pour répondre aux besoins de scalabilité et de performance des applications web3 modernes. Combinant le Gravity SDK, un moteur de consensus PoS en pipeline basé sur AptosBFT, et la couche d'exécution Gravity reth propulsée par Grevm, Gravity atteint un débit de 1 gigagas par seconde, un temps de confirmation des transactions sous seconde, et une sécurité PoS basée sur des mécanismes de restaking. La conception de ces composants techniques offre une base solide pour créer des blockchains L1 personnalisées ou des solutions L2 plus efficaces pour les applications Web3, particulièrement adaptées à l'optimisation des scénarios d'utilisation des chaînes EVM.

Cet article provient d'une soumission et ne représente pas l'opinion de BlockBeats.