Il y a plus d’un an, en parallèle des déploiements successifs de The Merge et du hard fork Shanghai, Ethereum a fait le choix de confier la problématique de scalabilité aux solutions de seconde couche. Ainsi, ce changement de paradigme tend à déporter l’activité réelle sur des layers 2 et à utiliser Ethereum comme une couche de règlement (settlement) et de disponibilité des données.
Layer 2 (L2) : le nerf de la guerre sur Ethereum
Depuis le début d’année, ces solutions ont le vent en poupe. Ainsi, tour à tour Optimism, Arbitrum ou encore Base ont été au cœur de l’attention. Si bien, qu’en l’espace d’un an, la TVL des layers 2 d’Ethereum est passée de 5 à 12 milliards de dollars.
Cependant, toutes ces solutions n’adoptent pas la même approche. En effet, il existe une variété d’architectures différentes pour les L2, chacune adaptant le compromis entre sécurité, scalabilité et coût à sa manière.
De plus, toutes les applications hébergées sur ces couches 2 n’ont pas les mêmes besoins en ce qui concerne le trilemme précédemment évoqué. Par exemple, une application de finance décentralisée accordera une importance particulière à la sécurité, même si cela se fait au détriment de la scalabilité et du coût. En revanche, une application de réseau social mettra davantage l’accent sur la scalabilité et le coût pour ses utilisateurs.
Autant de spécificités que Vitalik Buterin a récemment abordées et analysées dans un article publié sur son blog personnel.
Sécurité vs scalabilité
Dans un premier temps, Vitalik Buterin explore la relation entre la sécurité et la scalabilité pour définir une couche 2. Il pose la question :
« Si vous disposez d’un actif émis sur L1, puis déposé sur L2, et transféré à vous, quel niveau de garantie avez-vous que vous serez en mesure de ramener l’actif sur L1 ? »
Vitalik Buterin
En d’autres termes, la sécurité de votre actif lors de son passage de la couche 1 à la couche 2, et à vous, dépend entièrement du type de seconde couche utilisée. Examinons les différentes solutions, à savoir les rollups, les validiums et les L2 “déconnectées” d’Ethereum.
Avant toute chose, explicitons les différences entre ces concepts :
- Un rollup exécute des transactions et stocke les données de transaction sur la chaîne principale, garantissant une forte sécurité ;
- un validium exécute également des transactions de manière vérifiable, mais externalise le stockage des données, réduisant les coûts, mais aussi la sécurité ;
- un L2 déconnecté fonctionne indépendamment de la chaîne principale, offrant une scalabilité maximale, mais avec la sécurité la plus faible, dépendant de ses propres mécanismes de consensus.
Les différentes garanties
Si c’est un rollup, la garantie est forte : vous aurez toujours la possibilité de récupérer votre actif sur la couche 1 grâce aux preuves de fraude ou aux ZK-SNARKs qui valident les transactions et stockent les données sur L1.
Pour un validium, cette garantie peut être réduite, car elle dépend de la fiabilité du stockage des données et des mécanismes de consensus spécifiques à ces systèmes.
Enfin, les systèmes déconnectés quant à eux nécessitent de faire confiance à un petit groupe de personnes pour ne pas dérober les fonds ou perdre les clés. En effet, ces solutions nécessitent des ponts qui sont la plupart du temps opérés de manière centralisée.
| System type | Technology properties | Security guarantees | Costs |
|---|---|---|---|
| Rollup | Computation proven via fraud proofs or ZK-SNARKs, data stored on L1 | You can always bring the asset back to L1 | L1 data availability + SNARK-proving or redundant execution to catch errors |
| Validium | Computation proven via ZK-SNARKs (can’t use fraud proofs), data stored on a server or other separate system | Data availability failure can cause assets to be lost, but not stolen | SNARK-proving |
| Disconnected | A separate chain (or server) | Trust one or a small group of people not to steal your funds or lose the keys | Very cheap |
Malheureusement, il semblerait que la sécurité soit fonction inverse de la scalabilité dans le cas des L2. En effet, plus le niveau de garantie est élevé, moins le système est scalable dans le contexte des solutions de Layer 2.
Ainsi, les rollups, qui offrent une forte garantie de retrait des actifs vers L1, requièrent que toutes les données de transaction soient stockées sur L1, ce qui les rend moins scalables en raison de la limitation de l’espace de données sur L1.
En revanche, les validiums et les systèmes déconnectés, qui stockent les données en dehors de L1, peuvent traiter plus de transactions à moindre coût, mais au prix d’une garantie moindre lorsqu’il s’agit de récupérer les actifs sur L1.
Les options de sécurité intermédiaires
Toutefois, comme le précise Vitalik Buterin, il s’agit là d’une simplification de l’état réel du monde des rollups. En effet, il existe une multitude de solutions intermédiaires ou hybrides, dont :
- Les Volitions, un hybride entre rollup et validium, qui permettent aux utilisateurs de choisir où les données de transaction sont stockées (on-chain ou off-chain) ;
- Les systèmes avec pré-confirmations, qui permettent les retraits rapides avant la finalisation complète, idéale dans le cas des rollups Optimistic.
À noter qu’à l’avenir, le coût de publication des données sur Ethereum devrait drastiquement diminuer. Dans un premier temps via le déploiement de proto-danksharding lors du hard fork Cancun-Deneb, qui devrait amener à ~32 kB/sec de données disponibles sur la chaîne. Puis dans un second temps avec le déploiement de full-danksharding, pour atteindre finalement une disponibilité de données d’environ 1,3 Mo/sec.
Cela permettra notamment une nette amélioration des performances des rollups, qui utilisent Ethereum comme couche d’accessibilité des données.
Intégration avec Ethereum : la synchronisation essentielle
La cohésion entre Ethereum et les couches secondaires est centrale à la sécurité des L2. Ainsi, ces dernières doivent lire avec précision la blockchain Ethereum, et ce, à tout moment.
C’est particulièrement vrai dans le cas où Ethereum viendrait à revert, à savoir revenir en arrière. Vitalik Buterin expose cette situation dans un exemple. Imaginons que la blockchain Ethereum “se retourne”. Si la L2 n’est pas en mesure de gérer cette situation, celle-ci ne sera pas au fait des modifications d’état on-chain. Par conséquent, il pourrait être possible d’imprimer de l’argent sur le L2 en profitant de cette faille.
C’est pour cela que Vitalik Buterin souligne l’importance pour les systèmes de Layer 2 de pouvoir lire la blockchain Ethereum de manière fiable et de revenir en arrière si nécessaire. Il met en avant deux solutions principales :
- Les chaînes de Layer 2 ne lisent que les blocs d’Ethereum qui ont été finalisés, évitant ainsi le besoin de revenir en arrière.
- Les chaînes de Layer 2 peuvent revenir en arrière si Ethereum revert, ce qui maintient la fonctionnalité, mais est plus complexe à implémenter.
Il s’agit là d’une nouvelle distinction dans le fonctionnement des solutions de seconde couche. Ainsi, chacune de ces solutions est viable, leur implémentation dépendra des besoins de la layer 2.
Conclusion
Les liens avec Ethereum sont essentiels pour les couches secondaires. Vitalik Buterin identifie deux composantes majeures.
D’un côté, nous avons la sécurité des retraits vers Ethereum : est-ce fiable et tout le monde bénéficie-t-il de cette fiabilité ? De l’autre, la capacité de lire la blockchain d’Ethereum : est-ce rapide et comment réagir face à des événements exceptionnels comme des attaques ou des retours en arrière de la blockchain ?
Les réponses varient selon les applications, certaines nécessitant une connexion étroite et sécurisée, d’autres pouvant se permettre plus de flexibilité.
Alors que les layers 2 sont au cœur de l’attention, les layers 3 commencent à pointer le bout de leur nez. Par exemple, Arbitrum a récemment déployé Orbit, son programme dédié à la création de L3 au-dessus d’Arbitrum.
