Les défis de mise à l'échelle d'Ethereum

Limitations of Ethereum’s Mainnet

Selon le trilemme de la blockchain de Vitalik Buterin, aucune blockchain ne peut simultanément atteindre la décentralisation, la sécurité et la scalabilité. Des compromis doivent être faits entre ces trois facteurs. Ethereum a choisi de se concentrer sur la décentralisation et la sécurité. Il a réussi à passer du consensus Proof of Work (PoW) au consensus Proof of Stake (PoS), en menant l'innovation et le développement au sein de l'industrie. En conséquence, il est devenu le plus grand écosystème de blockchain public, juste après Bitcoin en termes de décentralisation et de sécurité économique.

Cependant, malgré plusieurs mises à niveau, la scalabilité d'Ethereum reste limitée. Le temps moyen de bloc est de 12 secondes et ses transactions par seconde (TPS) ne sont que d'environ 13. Lorsque l'activité du réseau augmente, des congestions se produisent, accompagnées de frais de transaction élevés, ce qui impacte considérablement l'expérience utilisateur. Les problèmes de scalabilité d'Ethereum deviennent plus prononcés à mesure que l'écosystème se développe avec plus d'applications et d'utilisateurs. En réponse, en 2020, Vitalik Buterin a annoncé officiellement que la feuille de route future d'Ethereum se concentrerait sur les Rollups (c'est-à-dire les solutions de couche 2) pour résoudre les problèmes de scalabilité du mainnet.

Les préoccupations cachées de la couche 2

En termes simples, Layer 2 fait référence à la couche de calcul d'Ethereum. Le principe est de déplacer l'exécution des transactions hors chaîne pour le calcul, puis de compresser les résultats de plusieurs transactions en une seule transaction qui est renvoyée au réseau principal d'Ethereum pour validation et règlement final. Grâce au calcul hors chaîne, le TPS de Layer 2 peut être plusieurs fois supérieur à celui du réseau principal. De plus, parce qu'une seule transaction renvoyée au réseau principal consolide plusieurs détails de transaction, les coûts de validation sont partagés entre de nombreux utilisateurs, ce qui réduit les coûts de transaction et offre une expérience utilisateur plus fluide. Cela a permis à Layer 2 de gérer le trafic substantiel et la charge de l'écosystème provenant du réseau principal.

Selon les statistiques de L2BEAT et de Dune, selon les dernières données (18 novembre), la valeur totale bloquée (TVL) en couche 2 a atteint 4,4 milliards de dollars, avec un total de TPS d'environ 360. Plus de 90% des transactions de l'écosystème Ethereum sont désormais effectuées en couche 2.

Figure 1: TVL et TPS de la couche 2, Source: L2BEAT

Figure 2: Part de transactions Ethereum Mainnet vs. Layer 2, Source: Dune

Cependant, actuellement, il existe 52 solutions de couche 2, dont certaines n'ont pas encore été lancées officiellement. Le nombre important de projets de couche 2 a entraîné la fragmentation des utilisateurs et la liquidité étant dispersée sur différentes plateformes. Pour rivaliser pour les utilisateurs et les fonds, ces plateformes consomment des ressources substantielles. Les utilisateurs doivent également transférer fréquemment des actifs entre différentes solutions de couche 2, ce qui entraîne des coûts de transaction supplémentaires, tout en exposant leurs actifs à des risques accrus lors du processus de transfert.

De plus, sur les 52 solutions de couche 2, seules 6 répondent aux normes de sécurité de la première phase fixées par L2BEAT. Cela indique que la plupart des solutions de couche 2 n'héritent pas adéquatement de la sécurité du mainnet d'Ethereum, et que les fonds des utilisateurs pourraient être gelés en cas de défaillance de la couche 2.

(Les normes de sécurité à trois phases de L2BEAT pour la couche 2:
Phase 0: La solution de couche 2 fonctionne normalement.
Phase 1: L'équipe du projet abandonne une partie de son contrôle, permettant à une certaine proportion d'entités externes de participer, ce qui entraîne un niveau plus élevé de décentralisation. Les utilisateurs peuvent décider s'ils veulent retirer leurs actifs.
Phase 2: Décentralisation totale, où n'importe qui peut participer et sortir sans autorisation.)

Face à ces défis, Gear Protocol a lancé Gear.exe, une solution non-Layer 2 qui améliore considérablement la capacité de calcul d'Ethereum - plus de 1000 fois - sans sacrifier la sécurité du réseau principal d'Ethereum, atteignant ainsi un niveau de scalabilité plus élevé.

Introduction à Gear.exe

Gear.exe, développé par Gear Protocol, est un réseau informatique décentralisé construit sur Vara Network (une couche 1 publiée par Gear Protocol, qui sera présentée plus tard). Entièrement compatible avec la Machine Virtuelle Ethereum (EVM), Gear.exe peut être considéré comme une suite d'expansion pour le réseau Ethereum. Il prend en charge une exécution parallèle infiniment évolutive, compensant les limites de scalabilité propres à Ethereum et offrant une expérience de transaction à faible latence et à faible coût. Il est important de noter que Gear.exe n'est pas une blockchain et ne génère pas ses propres blocs. Au lieu de cela, il sert d'infrastructure fournissant de puissantes ressources de calcul, ce qui signifie qu'il ne rivalise pas avec les solutions de couche 2 existantes pour les utilisateurs et les fonds, évitant ainsi une fragmentation accrue des actifs.

Les avantages apportés par l'intégration de Gear.exe comprennent:

• Jusqu'à 1000 fois d'amélioration des performances de calcul
• Réduction des frais de gaz de 90 à 99%
• Latence sub-seconde et règlement rapide des transactions (limité uniquement par le temps de bloc du réseau principal Ethereum)
• Expérience utilisateur similaire à Web2
• Environnement de développement Rust optimisé

Grâce aux puissantes ressources de calcul de Gear.exe, les développeurs peuvent externaliser des tâches complexes et intensives en calcul vers Gear.exe, en construisant des DApps avec des fonctionnalités complexes et des exigences de calcul élevées. Les cas d'utilisation incluent DeFi, GameFi, l'IA, l'apprentissage automatique, les preuves à divulgation nulle et les oracles. Cela augmente l'efficacité des transactions, réduit les coûts et optimise davantage l'expérience utilisateur.

En ce qui concerne la sécurité, étant donné que Gear.exe n'est pas une blockchain et ne dispose pas de sa propre protection de consensus, il introduit un protocole de re-staking appelé Symbiotic. Grâce à l'ETH re-staké, Symbiotic offre une sécurité économique suffisante pour Gear.exe, empêchant les actions malveillantes des nœuds de validation. Cela permet à Gear.exe de fournir une solution de scalabilité alternative, différente de la couche 2, qui améliore la scalabilité d'Ethereum sans compromettre la décentralisation ni la sécurité tout en permettant des cas d'utilisation plus gourmands en calcul.

Histoire du développement

Gear Protocol a été lancé en septembre 2021 en tant que plateforme de contrat intelligent basée sur Substrate, spécialement conçue pour le développement de programmes parallèles avec plusieurs fonctionnalités dédiées, notamment le modèle d'acteur, la mémoire permanente et WASM. Il prend en charge les contrats intelligents écrits dans différents langages de programmation tels que Rust, Solidity, C et C++, ce qui le rend compatible avec plusieurs blockchains et permet le déploiement inter-réseaux sans avoir besoin de modifier les contrats.

(Substrate: Un cadre de développement modulaire qui facilite l'intégration de plusieurs blockchains spécialisées, améliorant ainsi la scalabilité.)

Initialement, Gear Protocol a servi l'écosystème Polkadot. À l'époque, la chaîne relais de Polkadot ne prenait pas en charge le déploiement de contrats intelligents, de sorte que les développeurs souhaitant se connecter au réseau devaient déployer des contrats sur des parachains ou créer une nouvelle blockchain et la connecter à Polkadot. En raison du coût élevé de cette dernière, la plupart des développeurs ont choisi de déployer des DApps sur des parachains. Gear Protocol, compatible avec différents langages de programmation et offrant diverses infrastructures, est devenu la plateforme de choix des développeurs. Par conséquent, il est devenu un hub pour DeFi, DAO, NFT et autres types de DApp, jouant un rôle clé dans l'écosystème Polkadot.

En septembre 2023, Gear Protocol a officiellement lancé son réseau indépendant de couche 1, Vara Network, développé sur la base du framework Substrate. Vara Network intègre toutes les technologies et fonctionnalités de Gear Protocol, utilisant des processus parallélisés pour améliorer significativement les performances du réseau. Il peut également être mis à niveau sans forks ni temps d'arrêt, et il se concentre sur la réduction des barrières de développement pour les DApps, dans le but de créer un réseau blockchain avec une durabilité à long terme grâce à son infrastructure robuste.

En octobre 2024, Gear Protocol a lancé Gear.exe, dans le but de tirer parti des avantages de haute performance de Vara Network pour gérer des tâches de calcul complexes pour les DApps et relever les défis de scalabilité d'Ethereum.

Contexte de l'équipe

Gear Protocol a été lancé en septembre 2021. L'équipe est composée de développeurs principaux de Polkadot et du framework de développement de blockchain Substrate. Avec une expérience approfondie dans Web3, l'équipe apporte une expertise approfondie en technologie, finance, développement et vente.

Nikolay Volf, Co-fondateur et PDG, est impliqué dans Polkadot et Substrate depuis 2015. Alors qu'il travaillait chez Parity Technologies, une entreprise spécialisée dans l'infrastructure blockchain, il a introduit le premier contrat intelligent WebAssembly (WASM).

Ilya Veller, co-fondateur et directeur financier, possède plus de 20 ans d'expérience dans l'industrie financière. Il a occupé des postes de vente seniors dans des institutions telles que la Bank of America, Morgan Stanley, Renaissance Capital, UniCredit et ITI Capital, levant plus de 1 milliard de dollars pour divers projets.

Aleksandr Bugorkov, co-fondateur et CTO, apporte une vaste expérience technique acquise chez des entreprises telles que Lyft, New Relic et Spotify, où il a travaillé sur des solutions technologiques innovantes.

Statut du financement

En décembre 2021, Gear Protocol a bouclé une levée de fonds de 12 millions de dollars, menée par Blockchange Ventures. D'autres investisseurs comprenaient HashKey Capital, Lemniscap et Three Arrows Capital.

Comment fonctionne Gear.exe

Gear.exe prend en charge les programmes parallélisés, et ses technologies de base sont basées sur plusieurs composants clés :

• Modèle d'acteur

En programmation informatique, un "Acteur" est une unité de calcul fondamentale qui peut envoyer et recevoir des messages. Les acteurs peuvent représenter des contrats intelligents ou des utilisateurs finaux. Dans le Modèle d'Acteur, l'état entre les acteurs est conservé privé et ne peut être modifié ou communiqué que par passage de messages. Cela garantit la confidentialité et la sécurité pour chaque acteur. Tous les processus sont asynchrones, ce qui signifie qu'ils sont exécutés en parallèle, permettant à plusieurs tâches d'être traitées simultanément sans attendre le résultat d'une tâche précédente.

Pour illustrer, imaginez que vous préparez à la fois un steak et une salade. Normalement, vous chaufferiez d'abord la poêle et l'huile, puis pendant l'attente de la chauffe de la poêle, vous pourriez commencer à laver les légumes. Une fois la poêle prête, vous retournez pour cuire le steak, le laissez reposer, puis retournez pour préparer la salade. Ce processus est similaire à une exécution parallèle, où pendant qu'une tâche attend un résultat, une autre peut être traitée, améliorant ainsi considérablement l'efficacité computationnelle.

De plus, pour éviter toute confusion due à l'arrivée de plusieurs messages en même temps, un acteur est limité à traiter une demande à la fois. Par exemple, si A souhaite déposer 10 $ sur un compte tandis que B souhaite retirer 5 $ du même compte en même temps, le traitement simultané des deux demandes pourrait conduire à un solde de compte incorrect. Dans le modèle d'acteur, même si les demandes arrivent simultanément, le système les exécutera séquentiellement (par exemple, en traitant d'abord la demande de A, puis celle de B) pour garantir que le solde du compte reste cohérent.

• Mémoire persistante

L'état de chaque acteur et les données requises sont stockés dans leur propre mémoire, plutôt que dans un stockage partagé externe tel que des disques durs ou des bases de données. Cela réduit considérablement le besoin d'appels d'API pour interagir avec la blockchain, permettant d'accéder directement aux données depuis la mémoire locale, ce qui réduit la latence. De plus, l'état de chaque acteur est persistant, ce qui signifie que même si un contrat intelligent est mis en pause ou si le système est redémarré, l'état de l'acteur peut être immédiatement restauré.

Gear Protocol utilise également la technologie de virtualisation de mémoire, qui suit le comportement d'accès à la mémoire par les programmes pour s'assurer que seules les données nécessaires sont lues et sauvegardées. Cela réduit au minimum le gaspillage de ressources de calcul, rendant le système plus efficace.

• WebAssembly (WASM)

WebAssembly (WASM) est un environnement d'exécution isolé qui permet l'exécution efficace de contrats intelligents. Il prend en charge une grande variété de langages de programmation, de sorte que les développeurs peuvent utiliser des outils de développement familiers pour déployer des contrats intelligents sur Gear.exe. Cela réduit considérablement les barrières de déploiement, ce qui facilite l'utilisation de la puissance de calcul de Gear.exe par les développeurs sans avoir à apprendre de nouveaux langages ou frameworks.

Processus d'exploitation de Gear.exe

Figure 3, Processus d'exploitation de Gear.exe, Source: Protocole Gear

Gear.exe fournit aux développeurs deux méthodes principales d'intégration pour interagir avec sa plateforme :

1. Intégration native
   Dans cette méthode, les dApps invoquent directement les procédures opérationnelles de Gear.exe, sans avoir besoin d'envoyer des demandes à Ethereum. Cela permet une interaction en temps réel avec le système.

2. Intégration basée sur les événements
   Dans ce modèle, les contrats intelligents Ethereum émettent des événements qui déclenchent les opérations de Gear.exe. Lorsque les validateurs de Gear.exe détectent l'événement, ils exécutent immédiatement le processus correspondant. Cela permet une intégration entièrement décentralisée où Ethereum et Gear.exe peuvent fonctionner de manière transparente.

Quel que soit la méthode d'intégration choisie, le processus opérationnel suit ces étapes :

Processus étape par étape

1. Acceptation de la demande
   À réception d'une demande, les nœuds validateurs de Gear.exe exécutent le programme déployé de l'application dans l'environnement Gear. Les nœuds signent ensuite le résultat final du calcul pour en garantir la validité.

2. Sécurité économique via le ré-engagement
   Pour empêcher les comportements malveillants des nœuds, la sécurité économique de Gear.exe est protégée par le protocole de re-staking symbiotique. De plus, les participants à la mise en jeu du jeton natif de Vara Network (VARA) contribuent à la sécurité. Il y a également des mécanismes de pénalité en place pour dissuader les comportements malhonnêtes.

3. Pre-confirmation
   Après que Gear.exe commence à traiter la demande, il envoie une pré-confirmation à l'utilisateur. Cette pré-confirmation agit comme un reçu, contenant des détails sur la transaction tels que l'expéditeur, le destinataire, la valeur de hash, les frais de transaction, etc. Elle assure à l'utilisateur que la transaction sera traitée et finalement finalisée sur Ethereum. La pré-confirmation est essentielle car les données de la transaction sont encore en cours de traitement, et le règlement final sur Ethereum prendra un certain temps. En fournissant une pré-confirmation, Gear.exe permet aux dApps d'éviter d'attendre la finalisation de la transaction, offrant ainsi une expérience utilisateur plus rapide.

4. Agrégation et téléchargement des résultats
   Environ toutes les 8 secondes, le séquenceur collecte tous les résultats de calcul (qui peuvent impliquer des transactions de plusieurs dApps) et la dernière racine d'état. Ces résultats sont ensuite emballés et téléchargés sur le contrat intelligent de Gear.exe sur Ethereum.

5. Mise à jour des contrats intelligents des dApps
   Les résultats finaux de la transaction sont envoyés aux contrats intelligents respectifs des dApps, mettant à jour leurs racines d'état avec les dernières données.

Caractéristiques clés de l'architecture de Gear.exe

• Flexibilité pour les développeurs Web3:
  L'architecture et les méthodes d'intégration de Gear.exe offrent aux développeurs Web3 une plus grande flexibilité, leur permettant de choisir entre des intégrations natives et basées sur les événements en fonction de leur cas d'utilisation.

• Performance and Speed:
  En fournissant des pré-confirmations et en traitant les transactions hors chaîne, Gear.exe permet aux dApps d'offrir une expérience utilisateur beaucoup plus rapide et plus fluide, car les utilisateurs peuvent interagir immédiatement avec la plateforme sans attendre que la transaction complète soit finalisée sur Ethereum.

• Sécurité et Validation:
  La combinaison de la restake, des nœuds validateurs et des mécanismes de pénalité garantit que le système est sécurisé et que les actions malveillantes sont découragées. Le recours au mainnet d'Ethereum pour le règlement final ajoute une couche supplémentaire de sécurité, car le consensus d'Ethereum est l'arbitre final de la légitimité de la transaction.

Cette approche, combinant des performances élevées, des transactions rapides et des fonctionnalités de sécurité robustes, positionne Gear.exe comme un outil précieux pour les développeurs Web3 cherchant à intégrer le calcul hors chaîne avec Ethereum de manière évolutive et efficace.

Comparaison entre Gear.exe et Layer 2

Gear.exe et diverses solutions de couche 2 visent à améliorer la scalabilité d'Ethereum, ce qui lui permettrait d'accueillir plus d'utilisateurs et d'applications. Cependant, il existe des différences significatives dans la façon dont ces deux approches sont mises en œuvre. Cette comparaison se concentrera sur deux aspects critiques: la sécurité et les performances.

Sécurité

Gear.exe et les solutions de couche 2 délocalisent les tâches de calcul d'Ethereum hors chaîne, puis regroupent les transactions sur le mainnet. Cela signifie qu'une partie importante du traitement des transactions se produit hors chaîne et qu'il devient crucial de garantir la sécurité et la cohérence des données de transaction lors du calcul hors chaîne pour éviter les altérations malveillantes par les nœuds.

• Couche 2 (par exemple, Arbitrum) : Dans les solutions de couche 2 comme Arbitrum, le processus de calcul est protégé par son propre consensus réseau. Les transactions sont classées par un séquenceur centralisé puis téléchargées sur le mainnet pour le règlement. Arbitrum utilise un mécanisme de preuve optimiste avec une période de contestation de 7 jours. Le système suppose que toutes les données de transaction téléchargées sont correctes mais offre une fenêtre à toute personne pour contester la transaction. En cas de contestation, les validateurs Ethereum sont responsables de confirmer la validité de la transaction. Cette conception garantit que, même si les nœuds du réseau Arbitrum sont malveillants, Ethereum peut servir de dernière ligne de défense.
• Gear.exe : Gear.exe ne dispose pas de son propre consensus réseau et s'appuie plutôt sur Symbiotic, qui utilise des ETH re-engagés pour assurer la sécurité économique. Les transactions sont d'abord ordonnées par un séquenceur centralisé, puis transmises à l'Ethereum mainnet. Cependant, la documentation actuelle de Gear.exe ne précise pas s'il utilise des mécanismes tels que les Preuves Optimistes ou les Preuves de Connaissance Nulle (ZKPs) pour vérifier que les données téléchargées sur Ethereum sont correctes. Par conséquent, la sécurité de Gear.exe repose fortement sur le protocole de re-engagement de Symbiotic. Il n'est pas clair si la sécurité fournie par ce modèle de re-engagement peut correspondre pleinement au consensus natif d'Ethereum, car le mécanisme de re-engagement exploite la sécurité d'Ethereum via des contrats intelligents, ce qui introduit des risques systémiques potentiels.

De plus, Gear.exe et Layer 2 utilisent tous deux un séquenceur centralisé pour ordonner les transactions au lieu de s'appuyer sur le consensus du réseau. Bien que cela accélère le réseau, cela accorde également au séquenceur et à l'équipe du projet un pouvoir considérable. Dans des cas extrêmes, une équipe de projet pourrait manipuler l'ordre des transactions pour se favoriser et rejeter des transactions qui sont préjudiciables à leurs intérêts. Les solutions de couche 2 telles que Arbitrum et Optimism fournissent un mécanisme d'évasion, permettant aux utilisateurs de contourner le séquenceur et de soumettre directement des transactions au mainnet. Cependant, Gear.exe n'a pas une telle conception.

Conclusion sur la sécurité:
Par rapport aux solutions de couche 2, la sécurité de Gear.exe repose fortement sur le symbiotique et manque de certaines contre-mesures pour les cas extrêmes trouvés dans les solutions de couche 2. Il n'est pas aussi mature et bien structuré en termes de sécurité. Cependant, Gear.exe pourrait fournir plus de détails dans les futurs livres blancs pour clarifier son modèle de sécurité.

Performance

En termes de performance, Gear.exe et Layer 2 renvoient tous deux des informations pré-confirmées aux utilisateurs lors du traitement des transactions, indiquant que le système a accepté la transaction et la traitera. Cela permet aux utilisateurs de recevoir rapidement les résultats initiaux de la transaction et de continuer d'autres opérations sans attendre qu'Ethereum finalise le bloc, ce qui améliore considérablement la vitesse et l'efficacité des transactions. De plus, Gear.exe et Layer 2 utilisent des séquenceurs centralisés pour ordonner les transactions, ce qui permet d'économiser du temps sur la formation du consensus et de regrouper plusieurs transactions en une seule. Cela réduit les frais de gaz et permet aux blocs d'Ethereum d'accueillir plus de transactions.

• Couche 2:
  Les solutions de couche 2, telles que Arbitrum, offrent des performances améliorées par rapport à la couche de base d'Ethereum en déchargeant le calcul. Cependant, la couche 2 rencontre encore certaines limitations en termes de scalabilité, car elle prend généralement en charge des améliorations linéaires du débit de transaction plutôt que des gains exponentiels.

• Gear.exe:
  Gear.exe intègre plusieurs technologies avancées, telles que le modèle d'acteur, la mémoire persistante et WebAssembly (WASM), pour prendre en charge l'exécution parallèle des tâches. Cela optimise encore plus l'efficacité de calcul et l'utilisation des ressources. La parallélisation des processus permet à Gear.exe de potentiellement offrir une performance réseau significativement supérieure à celle des solutions de couche 2. Gear.exe prétend qu'il peut atteindre 1000 fois la puissance de calcul de la couche de base d'Ethereum, mais la vérification de cette affirmation dépend des données de performance et des tests futurs.

Conclusion sur les performances :
Alors que les solutions de couche 2 offrent déjà des améliorations de performance significatives par rapport à Ethereum, Gear.exe pourrait offrir une performance réseau encore plus grande grâce à son support de l'exécution parallèle. Cependant, il reste à vérifier s'il peut fournir l'amélioration revendiquée de 1000 fois à travers des données et des tests réels.

Perspectives et défis

En termes simples, Gear.exe améliore les performances grâce à une exécution parallèle, en s'appuyant sur l'infrastructure Layer 2 existante et se positionnant comme un module d'extension pour Ethereum plutôt que comme une nouvelle blockchain. Il se concentre uniquement sur la fourniture de services de calcul pour les DApps sur d'autres chaînes, évitant le problème de fragmentation des actifs qui accompagne les multiples solutions de Layer 2. À l'avenir, Gear.exe pourrait potentiellement remplacer certaines solutions de Layer 2, réunissant l'écosystème d'Ethereum. De plus, avec ses capacités de haute performance, Gear.exe rend Ethereum plus compétitif par rapport à d'autres chaînes publiques axées sur la performance telles que Solana, Sei, Sui et Aptos.

Cependant, il reste à voir si les performances opérationnelles et la stabilité de Gear.exe peuvent réellement répondre aux revendications faites. De plus, en termes de sécurité, Gear.exe est protégé uniquement par Symbiotics et ne dispose pas de nombreuses mesures associées que fournissent les solutions Layer 2 existantes. Il existe des risques de conception à prendre en compte, notamment par rapport aux fonctionnalités de sécurité plus matures des solutions Layer 2. La sécurité tend à être une priorité plus élevée pour les développeurs et les utilisateurs, notamment compte tenu des nombreux incidents où des pirates ont volé des actifs, y compris auprès de grandes bourses centralisées. Étant donné que Gear.exe est un protocole entièrement basé sur le code on-chain, sa sécurité doit être prouvée comme étant robuste et fiable, en particulier pour gérer des situations telles que les temps d'arrêt. C'est un domaine dans lequel Gear.exe devra s'améliorer et se renforcer pour gagner davantage la confiance du marché.

Conclusion

Avec la montée de la technologie blockchain et des blockchains modulaires, la barrière à la création d'une couche 2 est devenue de plus en plus basse, de nombreuses plateformes offrant des fonctionnalités de "création de chaîne en un clic". En conséquence, le nombre de solutions de couche 2 s'est considérablement étendu, laissant les développeurs et utilisateurs d'Ethereum incertains quant au choix à faire. Chaque couche 2 nécessite la création de son écosystème, ce qui ne fait que reproduire ce que d'autres chaînes publiques ont déjà traversé, ce qui entrave en quelque sorte l'innovation de nouvelles technologies.

Gear.exe offre une solution de performance supérieure pour les DApps par rapport à la couche 2 et élimine la nécessité de migrer les utilisateurs et les fonds existants. En utilisant la re-staking pour la sécurité, il offre une alternative unique aux défis de scalabilité d'Ethereum. Bien que cette solution n'ait pas encore été largement adoptée et doive subir une validation de marché, elle introduit sans aucun doute de nouvelles possibilités pour Ethereum. Gear.exe pourrait offrir une solution plus adaptée pour la mise à l'échelle d'Ethereum, et son développement futur mérite une attention continue.