Réflexions sur l’avenir d’Ethereum

À savoir :

– Ethereum, la deuxième plus grande blockchain au monde en matière de capitalisation, a récemment réalisé une importante mise à niveau, « The Merge » (La Fusion). Elle est alors passée d’un consensus par preuve de travail à un consensus par preuve d’enjeu. – La transition s’est bien déroulée, mais des questions subsistent : la blockchain Ethereum pourra-t-elle continuer à évoluer ? Est-elle véritablement prête pour la prochaine étape du Web3 ? – Cet article se penche sur les challenges qu’Ethereum devra résoudre pour continuer à évoluer et analyse les enjeux liés à son adoption par le grand public. Il n’existe pas encore de solution parfaite de scalabilité. Pourtant, les solutions de seconde couche, y compris les rollups optimistes et de validité, offrent le plus grand potentiel d’évolutivité, ainsi qu’un bon compromis pour résoudre le trilemme des blockchains. – Plus précisément, les rollups optimistes (Optimistic Rollups) et les rollups de validité (Validity Rollups), grâce à la technologie ZKP, joueront un rôle essentiel dans l’avenir d’Ethereum. Ils permettront de réaliser à grande échelle des transactions sans confiance, complexes et libres.

Faire évoluer Ethereum : en quête d’une solution

Ethereum, comme de nombreuses blockchains, est actuellement limitée dans sa capacité à traiter ses transactions. Cette blockchain est capable de prendre en charge les transferts d’ETH et des milliers de dApps s’appuient sur elle. Seulement, cette utilisation accrue s’est traduite par des transactions plus lentes et plus coûteuses.

Cette situation a conduit à la conception de services peu sécurisés, tels que des services centralisés hors chaîne pour les marchés de NFT, dans le but de réduire le montant élevé des frais. La mise à niveau EIP-1559 a amélioré le processus d’estimation des frais ainsi que le mécanisme des récompenses, mais n’a pas beaucoup amélioré la scalabilité. Ce défi de scalabilité se comprend bien dans le cadre du célèbre trilemme des blockchains, à savoir : scalabilité, décentralisation et sécurité.

En effet, selon le trilemme des blockchains, il est impossible d’obtenir en même temps ces trois propriétés que sont la décentralisation, la sécurité et la scalabilité. Si l’on sacrifie la décentralisation, il devient beaucoup plus facile de construire un système évolutif et sécurisé, comme l’a déjà prouvé le Web2. En revanche, si l’on privilégie la scalabilité en sacrifiant le mécanisme de consensus, on obtient une blockchain décentralisée, mais non sécurisée, et sans vrai intérêt. Il est extrêmement complexe de trouver une solution au trilemme de la blockchain, et c’est un véritable défi qui perdure depuis toute une décennie.

Traiter plus de transactions, plus rapidement : les multiples solutions

Au fil des ans, de nombreuses solutions ont été envisagées pour résoudre le trilemme de la blockchain Ethereum. L’une des idées les plus répandues est de construire des blocs plus gros ou de produire des blocs plus rapidement. Cette idée puisse sembler intéressante. Mais afin d’assurer le consensus, elle met les nœuds de la blockchain et les validateurs/mineurs sous pression, ce qui conduit à une centralisation accrue. De plus, cette solution freine les réorganisations de chaîne (« reorg »), ce qui amplifie les risques pour la sécurité.

Une autre solution consiste à créer une sidechain (chaîne latérale) pour réduire la charge de la chaîne principale, comme c’est le cas avec le réseau Polygon. Ce système implique des compromis en matière de sécurité, car il repose sur un consensus plus faible qu’Ethereum (plus petite capitalisation). Un tel système peut convenir à certains cas d’utilisation, mais il conduit souvent à la centralisation et ne résout pas entièrement les problèmes de scalabilité d’Ethereum. Et de toute façon, nous sommes encore loin des dizaines de milliers de requêtes nécessaires pour faire fonctionner un système comme celui de Visa.

Couches 2 et fragmentation (sharding) : des solutions aux problèmes de scalabilité d’Ethereum ?

Les solutions de fragmentation et de couche 2 sont largement considérées comme les meilleures options pour améliorer la scalabilité d’Ethereum tout en préservant l’équilibre entre la décentralisation et la sécurité.

Tout d’abord, la fragmentation de la blockchain a longtemps été considérée comme le secret de la scalabilité dans le secteur de la blockchain. C’était la principale caractéristique d’Eth2.0 en 2019 avec le passage au schéma de signature BLS, au mécanisme de consensus par preuve d’enjeu (PoS) et à la mise en œuvre d’eWASM (Ethereum WebAssembly). Les solutions de couche 2 ont quant à elles connu une avancée rapide grâce à la recherche soutenue sur les mécanismes de rollup. Voyons ce qu’il en est de ces deux approches concurrentes et ce qu’elles peuvent nous réserver à l’avenir.

Comment la fragmentation de la blockchain fonctionne-t-elle ?

Le terme fragmentation (« sharding » en anglais) provient de la science des bases de données, où l’on partitionne horizontalement une base de données en morceaux plus petits et plus faciles à gérer, appelés fragments (« shards »). Chaque fragment constitue une base de données distincte qui contient un sous-ensemble de données. La fragmentation est utilisée pour faire évoluer les bases de données en répartissant les données et les requêtes sur plusieurs serveurs. Elle permet à la base de données de traiter un volume plus important de données, sans avoir besoin d’un serveur unique et puissant.

Cette idée d’utiliser la fragmentation sur les blockchains est rapidement devenue populaire parmi les développeurs. La fragmentation de la blockchain consiste à diviser le réseau en sous-réseaux plus petits, appelés fragments. Ces derniers permettent de traiter les transactions de façon parallèle. Dans une blockchain fragmentée, chaque fragment est une chaîne distincte qui fonctionne de manière indépendante. Cela signifie que chaque nœud, mineur ou validateur peut se concentrer sur un fragment donné afin de créer un consensus local. Cela permet tout d’abord de traiter les transactions en parallèle. D’autre part, chaque fragment a moins de transactions à gérer. Cela semble parfait, mais est-ce vraiment le cas ?

Les problèmes liés à la fragmentation : consensus, communication entre les différents fragments, et sécurité

Il n’est pas évident de définir le consensus global dans une blockchain fragmentée. De quoi est-il constitué ? S’agit-il de l’union de tous les consensus locaux ? Comment et où ancrer ces consensus locaux pour créer un consensus global auquel tout le monde puisse se fier ? Il n’est pas facile de répondre à de telles questions.

Un autre défi de taille dans la mise en œuvre de la fragmentation est celui de la communication entre les différents fragments. Lorsqu’il s’agit de bases de données, ce problème ne se pose pas puisque les données sont réparties sur différents fragments, ce qui vous permet de les lire ou de les écrire indépendamment sans véritable problème. En revanche, cela est beaucoup plus compliqué quand il s’agit d’une blockchain fragmentée qui exécute du code. Chaque fragment doit être en mesure d’exécuter son propre code, de consulter l’état d’un autre fragment et d’exécuter du code sur un autre. Ce n’est pas une mince affaire.

Cela pose également un problème de sécurité. Les experts ont étudié cette question et les différents schémas de fragmentation se sont révélés vulnérables à de nombreuses nouvelles formes d’attaques. Tout d’abord, elle remet tout simplement en question le mécanisme de consensus. Si par exemple vous disposez de 10 fragments et que les mineurs sont répartis par fragments, il est 10 fois moins coûteux de prendre le contrôle d’un fragment que de l’ensemble de la blockchain. De manière simplifiée, l’attaque des 51 % devient l’attaque des 5,1 %. L’une des solutions consiste à modifier le mécanisme de consensus en passant de la preuve de travail à la preuve d’enjeu. C’est la principale raison pour laquelle Ethereum est passé à la preuve d’enjeu.

Sur le plan de la sécurité, l’effet de la Fusion a suscité de nombreux débats. Sur le plan de la décentralisation, la mise à jour du consensus d’Ethereum a favorisé la centralisation, étant donné que la propriété des tokens détermine le contrôle du réseau.

En ce qui concerne le nouveau consensus d’Ethereum, plusieurs paramètres incitent à la centralisation :

• Faire fonctionner votre nœud Ethereum n’est pas simple, cela demande des ressources et un bon uptime. Impossible donc d’utiliser votre wallet et de le faire fonctionner sur votre ordinateur portable ou même sur votre mobile.

• Le seuil de 32 ETH et le fait qu’il n’est pas possible de déstaker avant une date inconnue ont donné lieu aux réserves de liquidités et au staking liquide. Lido et les plateformes d’échange ont alors pris la plus grande part du marché. Aujourd’hui, quatre acteurs contrôlent plus de 55 % des cryptos mises en staking sur la blockchain Ethereum (Lido 29,2 %, Coinbase 13,1 %, Kraken 7,6 % et Binance 6,2 %).

Dans l’ensemble, la fragmentation de la blockchain est une idée intéressante pour accroître sa scalabilité. Seulement, elle nécessite une architecture complexe, en particulier lorsqu’il s’agit de définir le consensus global et de mettre en œuvre un protocole fragmenté efficace. Beaucoup de travail a été accompli pour atteindre ces objectifs, mais nous sommes encore loin de les mettre en œuvre et de mesurer l’impact sur le trilemme de la blockchain.

Les rollups à la rescousse

Les rollups compressent plusieurs transactions en une seule qu’Ethereum exécute, ce qui permet l’exécution hors chaîne de nombreuses transactions en bénéficiant de la sécurité d’Ethereum pour les règlements. Il existe principalement deux types de mise en œuvre de cette solution :

• Les rollups optimistes, qui permettent aux utilisateurs d’émettre des preuves de fraude en cas de litige.
• Les rollups ZK où le réseau de couche 2 (L2) émet des preuves de validité.

Les rollups optimistes et le problème de finalité :

Les rollups optimistes ont été conçus pour ressembler le plus possible aux EVM. Ils sont dits optimistes parce qu’ils partent du principe que les utilisateurs ne soumettent pas de transactions frauduleuses, ce qui permet de les inscrire directement sur la blockchain.

Il existe un mécanisme utilisant des preuves de fraude que les validateurs de couche 2 peuvent configurer pour vérifier les transactions hors chaîne effectuées dans un délai de quelques jours (7 jours sur Optimism). Une preuve de fraude valide identifie les étapes frauduleuses du processus de transaction, ce qui entraîne l’annulation de la transaction et une pénalité pour le validateur qui l’a approuvée. Cela permet d’améliorer le débit des transactions tout en assurant la sécurité de la chaîne principale d’Ethereum.

Toutefois, les rollups optimistes posent un nouveau problème : celui de la finalité. Avec les blockchains, les transactions confirmées sont considérées comme permanentes et irréversibles, mais cela dépend du mécanisme de consensus. Par exemple, les chaînes utilisant la preuve de travail (PoW) considèrent les transactions comme définitives lorsque la probabilité d’une réorganisation est faible, et les transactions Bitcoin sont définitives après six confirmations. Avec les rollups optimistes, les transactions peuvent être annulées après plusieurs jours, ce qui pose un problème de finalité, et un tout autre débat.

Un autre type de rollup : les rollup ZK

Un autre type de rollup porte le nom de rollup ZK, en raison de son utilisation de la technologie ZKP (« Zero-Knowledge Proof », ou preuve à divulgation nulle de connaissance), comme les SNARK ou les STARK. Il serait plus juste de les appeler « rollups de validité », étant donné que la propriété Zero Knowledge (nulle de connaissance) n’est pas réellement utile.

Le rollup exécute un lot de transactions et produit une preuve de validité, vérifiée par un contrat intelligent sur la blockchain Ethereum, qui confirme le résultat final des transactions. La preuve cryptographique est générée à l’aide des primitives cryptographiques Zero Knowledge.

Plus généralement, les preuves à divulgation nulle de connaissance permettent à une partie (le prouveur) de démontrer à une autre partie (le vérificateur) qu’elle possède certaines informations sans révéler les informations en question. Le vérificateur peut être sûr de la véracité de la déclaration du prouveur sans en connaître le contenu.

Conçus à l’origine pour protéger la vie privée, les rollups ZK utilisent les preuves à divulgation nulle de connaissance dans un but très différent : la compression et l’informatique de confiance. Les deux principales technologies Zero Knowledge sont les ZK-STARK (acronyme de Zero-Knowledge Scalable Transparent Argument of Knowledge) et les ZK-SNARK (acronyme de Zero-Knowledge Succinct Non-interactive Argument of Knowledge).

Problème de disponibilité des données pour la couche 2 (L2) :

Comme nous l’avons vu, les technologies ZKP assurent la validité de l’état de la couche 2 (L2), mais la preuve seule ne permet pas d’accéder à l’état. Pour augmenter le débit, l’exécution est déplacée hors de la chaîne. Cependant, les données doivent toujours être facilement accessibles pour la reconstruction. Pour ce faire, les données transactionnelles sont soumises sous forme de données d’appel (« calldata » en anglais) sur Ethereum, afin de s’assurer que les données sont disponibles pour une reconstruction future. Ces données pourraient également être stockées dans un système de stockage décentralisé fiable, tel que IPFS ou Arweave, ce qui permettrait à quiconque de reconstituer la couche 2 et de bénéficier des incitations offertes par le stockage décentralisé.

Il serait encore mieux de pouvoir stocker ces données sur la chaîne, mais elles ne servent qu’à reconstruire l’état/la vérité de la couche 2 et ne sont pas exécutées. Ce serait donc une utilisation inefficace et coûteuse de la capacité de la blockchain.

Pour résoudre ce type de problème, les développeurs d’Ethereum ont proposé deux EIP : EIP-4488 et EIP-4844 (bonne chance pour ne pas les confondre…). La première permet de réduire le coût du gaz pour les calldata, tandis que la seconde crée un nouveau type de transaction pour le stockage des données sur la couche 2. Ces données sont immuables et en lecture seule ; elles ne sont pas accessibles par l’EVM et ne peuvent donc pas être exécutées.

Ces EIP constituent exactement la croisée entre la feuille de route des rollups ZK et celle de l’Execution Sharding. Les deux proposent le même concept, mais à des fins différentes. L’EIP-4488 vise à stocker les données essentielles de la couche 2, tandis que l’EIP-4844, également connu sous le nom de Proto-Danksharding, est une étape vers la mise en œuvre du Danksharding et l’Execution Sharding.

Le Danksharding :

Le Danksharding consiste à diviser de grands ensembles de données en parties plus petites, pour les séparer et les traiter, souvent en parallèle. Cette méthode est utilisée dans les domaines du big data et de l’IA, où les ensembles de formation peuvent être très volumineux.

Le Proto-Danksharding (EIP-4844) ne met pas en œuvre la fragmentation, mais réduit les coûts de stockage des données calldata, qui pourraient être fragmentées. Ce stockage moins coûteux des données calldata améliorera considérablement la scalabilité d’Ethereum sur la couche 2. Il pourrait même rendre la fragmentation superflue.

Le Proto-Danksharding :

Avec le Proto-Danksharding, la blockchain Ethereum aura des calculs non évolutifs, mais des données évolutives. De plus, les rollups ZK convertissent essentiellement ces données évolutives et ces calculs non évolutifs mais fiables, en calculs évolutifs.

Les rollups ZK et le trilemme de la blockchain :

Les rollups ZK présentent d’importants avantages en matière de scalabilité, sans modifier les propriétés de la blockchain sous-jacente. La vérification par preuve à divulgation nulle de connaissance en chaîne est la principale exigence, tandis que la disponibilité des données peut être mise en œuvre hors chaîne. À long terme, on peut s’attendre à ce que les couches 1 deviennent simples, sûres et, espérons-le, décentralisées, tandis que les couches 2 assureront l’évolutivité.

Quel est donc le problème ?

Les solutions de seconde couche peuvent améliorer considérablement la scalabilité. Cependant, pour être réglé en chaîne (sur la couche 1), il faut produire une preuve de validité de l’état général de la couche 2, ce qui pose des difficultés en termes de centralisation. À l’heure actuelle, les modèles de couche 2 n’ont qu’un seul prouveur, ce qui signifie qu’il peut censurer vos transactions. Il ne pourrait pas vraiment geler vos actifs de la couche 1, puisqu’il existe des ponts natifs. Les recherches se poursuivent pour relever ce défi, en permettant à d’autres parties d’émettre des preuves. Toutefois, des questions difficiles restent sans réponse, notamment en ce qui concerne l’arbitrage entre ces preuves. Dans tous les cas, il s’agit d’un problème important à résoudre pour l’avenir.

StarkNet a fait de cette question un point important de sa feuille de route, tandis qu’Arbitrum répartit les responsabilités entre une Sequencer Inbox et une Delayed Inbox, pour faire en sorte que les fonds puissent être récupérés en cas de censure.

Réflexions finales

Comme nous l’avons vu, il est possible d’améliorer la scalabilité en sacrifiant la sécurité et la décentralisation. Les solutions de seconde couche sont considérées comme les moyens les plus prometteurs d’améliorer la scalabilité sans compromettre les autres aspects du trilemme de la blockchain.

Les rollups optimistes et les rollups de validité, utilisant la technologie ZKP, joueront un rôle essentiel dans l’avenir d’Ethereum. En effet, ils permettront de réaliser à grande échelle des transactions sans confiance, complexes et libres. Les rollups de validité présentent un avantage important sur les rollups optimistes : une finalité plus courte. Ethereum a récemment modifié sa feuille de route pour prendre en charge ces rollups au niveau de la blockchain.

Voilà donc l’avenir de la scalabilité de la blockchain : des dApps complexes fonctionnant sur des couches 2 (ou rollups récursifs), permettant une scalabilité virtuellement infinie, tout en reposant sur une couche 1 décentralisée et sécurisée. À long terme, la couche 1 pourrait devenir une pure couche de règlement, la complexité des dApps étant transférée sur la couche 2.