Vitalik : Avec l'émergence de différents types de L2, comment les applications et les utilisateurs doivent-ils choisir ?
TechFlow SélectionTechFlow Sélection
Vitalik : Avec l'émergence de différents types de L2, comment les applications et les utilisateurs doivent-ils choisir ?
Parmi ces compromis complexes entre Rollup, Validium et d'autres systèmes, lequel est le plus pertinent pour une application donnée ?
Dédié à des analyses Web3 approfondiesRédaction : Vitalik
Traduction : TechFlow
L'écosystème des couches 2 d'Ethereum s'est considérablement étendu au cours de la dernière année. Le paysage traditionnel des ZK-EVM Rollup, avec StarkNet, Arbitrum, Optimism et Scroll, a progressé rapidement, réalisant d'importants progrès en matière de sécurité ; L2beat offre un excellent résumé de l'état actuel de chaque projet. En outre, nous assistons à des équipes développant initialement des sidechains qui se tournent vers les rollups (Polygon), à des projets de première couche cherchant à adopter Validium (Celo), ainsi qu'à de nouveaux efforts émergents comme Linea ou Zeth...
Une conséquence inévitable de ces développements est une diversification croissante des projets L2. J'anticipe que cette tendance va se poursuivre, pour plusieurs raisons clés :
-
Certains projets actuellement indépendants de la couche 1 souhaitent désormais se rapprocher de l'écosystème Ethereum et devenir potentiellement des couches 2. Ces projets peuvent vouloir opérer une transition progressive. Un passage immédiat et total serait aujourd'hui préjudiciable à cause d'une disponibilité limitée, car la technologie n'est pas encore prête à tout placer sur des rollups. Trop tarder à effectuer la bascule risquerait quant à lui de perdre l'élan et de devenir obsolète.
-
Certains projets centralisés souhaitent renforcer la sécurité offerte à leurs utilisateurs et envisagent des solutions blockchain. Dans bien des cas, ils ont déjà exploré auparavant des « blockchains consortium permissionnées ». En réalité, ils n'ont souvent besoin que d'un niveau de « semi-centralisation ». De plus, ils présentent généralement un débit très élevé, incompatible à court terme avec les rollups.
-
Les applications non financières, telles que les jeux ou les réseaux sociaux, veulent s'appuyer sur la décentralisation mais n'ont besoin que d'un niveau de sécurité modéré. Dans le cas des réseaux sociaux, cela implique de traiter différemment les différentes composantes de l'application : les actions rares et à haute valeur, comme l'enregistrement d’un nom d'utilisateur ou la récupération de compte, devraient être effectuées sur un rollup, tandis que les activités fréquentes et peu valorisées, comme publier ou voter, nécessitent moins de sécurité. Si la chaîne échoue et que vos publications disparaissent, c’est un coût acceptable. Si vous perdez votre compte, cela pose un problème beaucoup plus grave.
Un point important est que, bien que les applications et utilisateurs actuels d’Ethereum soient prêts à payer, à court terme, des frais de rollup faibles mais visibles, les utilisateurs venant du monde non blockchain ne le seront pas : passer de 1 dollar à 0,10 dollar est acceptable, mais demander de payer 0,10 dollar alors qu'on ne payait rien auparavant l'est nettement moins. Cela vaut non seulement pour les applications centralisées actuelles, mais aussi pour les petites blockchains de niveau 1, dont les frais sont souvent très bas tant que leur base d'utilisateurs reste restreinte.
Une question naturelle se pose alors : parmi ces compromis complexes entre rollups, validiums et autres systèmes, lequel convient le mieux à une application donnée ?
Rollup vs Validium vs systèmes déconnectés
La première dimension du compromis entre sécurité et évolutivité peut être décrite comme suit : si vous détenez un actif émis sur L1, que vous le déposez sur L2, puis qu'il vous est transféré, quel est le niveau de garantie que vous pourrez ramener cet actif sur L1 ?
Une question similaire concerne les choix techniques permettant ce niveau de garantie, ainsi que leurs compromis respectifs.
Nous pouvons représenter simplement cela par un schéma :
Il convient de noter que ce modèle est simplifié, et qu’il existe de nombreuses options intermédiaires. Par exemple :
-
Entre rollup et validium : un validium peut autoriser toute personne à payer des frais de transaction directement sur la chaîne, forçant ainsi l’opérateur à publier certaines données, sous peine de perdre son dépôt.
-
Entre Plasma et Validium : un système Plasma offre des garanties de sécurité similaires à celles d’un rollup, avec une disponibilité des données hors chaîne, mais ne prend en charge qu’un nombre limité d’applications. Un système pourrait fournir un EVM complet, offrant aux utilisateurs qui n’utilisent pas les applications complexes des garanties de type Plasma, et aux autres des garanties de type Validium.
Ces options intermédiaires peuvent être considérées comme situées entre rollup et validation. Mais quels facteurs poussent une application à choisir un point précis aux extrémités plutôt qu’un autre plus à gauche ou à droite ? Deux éléments principaux entrent en jeu :
-
Le coût de la disponibilité des données natives d’Ethereum, qui diminue progressivement grâce aux améliorations technologiques. La prochaine mise à jour d’Ethereum, Dencun, introduira l’EIP-4844 (aussi appelée « proto-danksharding »), offrant environ 32 Ko/s de disponibilité des données sur chaîne. Cette capacité devrait augmenter progressivement dans les années à venir, atteignant environ 1,3 Mo/s avec le déploiement complet du danksharding. Parallèlement, les améliorations en compression de données nous permettront de faire davantage avec la même quantité d’espace.
-
Les besoins propres à l’application : les utilisateurs sont-ils plus affectés par des frais élevés ou par des dysfonctionnements applicatifs ? Les applications financières pâtissent davantage des pannes ; les jeux et réseaux sociaux impliquent de nombreuses interactions à faible valeur, rendant donc pertinents des compromis différents en matière de sécurité.
Grossièrement, ce compromis peut être représenté ainsi :
Une autre forme partielle de garantie mérite d'être mentionnée : les pré-confirmations. Une pré-confirmation est un message signé par certains participants d’un rollup ou d’un validium affirmant : « Nous confirmons que ces transactions sont incluses dans cet ordre, et que la racine d’état ultérieure est cette valeur ». Ces participants pourraient signer une pré-confirmation inexacte, mais s'ils le font, leur dépôt serait brûlé. Ce mécanisme est très utile pour les applications à faible valeur, comme les paiements quotidiens, tandis que pour des transferts financiers importants (ex. : millions de dollars), on attendra une confirmation « classique », soutenue par la sécurité complète du système.
Les pré-confirmations peuvent être vues comme un autre exemple de système hybride, similaire au « mélange plasma/validium » mentionné ci-dessus, mais cette fois entre un rollup (ou validium) doté d’une sécurité totale mais d’un délai élevé, et un système à sécurité moindre mais à latence réduite. Les applications exigeant une latence plus faible obtiennent une sécurité réduite, tout en coexistant dans le même écosystème que celles acceptant une latence plus élevée pour une sécurité maximale.
Lecture sans confiance d’Ethereum
Une autre forme de connexion, moins discutée mais tout aussi importante, concerne la capacité d’un système à lire la blockchain Ethereum. En particulier, cela inclut la possibilité d’effectuer un rollback lorsque la chaîne Ethereum subit elle-même un rollback. Pour comprendre pourquoi c’est précieux, examinons le scénario suivant :
Supposons, comme illustré, qu’une chaîne Ethereum subisse un rollback. Cela peut correspondre à une panne temporaire intra-époque, avant finalisation, ou à une période prolongée de stagnation due à un grand nombre de validateurs hors ligne.
La situation la plus critique serait la suivante : supposons que depuis le premier bloc de la chaîne supérieure, des données aient été lues depuis le tout premier bloc d’Ethereum. Par exemple, quelqu’un a déposé 100 ETH d’Ethereum vers la chaîne supérieure. Puis, Ethereum subit un rollback. Or, la chaîne supérieure ne fait pas de rollback. Résultat : les blocs futurs de la chaîne supérieure suivent correctement la nouvelle chaîne Ethereum, mais les conséquences de l’ancien lien erroné (le dépôt de 100 ETH) persistent. Cette vulnérabilité permettrait d’imprimer de la monnaie, transformant les ETH pontés sur la chaîne supérieure en réserve partielle.
Deux solutions existent :
-
La chaîne supérieure ne lit que les blocs définitivement finalisés d’Ethereum, évitant ainsi tout rollback.
-
Si Ethereum subit un rollback, la chaîne supérieure doit également revenir en arrière. Les deux méthodes empêchent le problème. La première est plus facile à mettre en œuvre, mais entraînerait une indisponibilité prolongée en cas de stagnation d’Ethereum. La seconde est plus complexe, mais assure une fonctionnalité optimale en toutes circonstances.
Notez que la première méthode (1) comporte un cas particulier : si une attaque 51 % sur Ethereum crée deux nouveaux blocs incompatibles simultanément finalisés, la chaîne supérieure pourrait se verrouiller sur le mauvais bloc (celui non soutenu par le consensus social d’Ethereum) et devrait effectuer un rollback pour basculer sur le bon. On pourrait argumenter qu’il n’est pas nécessaire d’anticiper ce cas par du code ; il pourrait être géré via un hard fork de la chaîne supérieure.
La capacité d’une chaîne à lire Ethereum sans confiance repose sur deux raisons principales :
-
Elle réduit les problèmes de sécurité liés au pontage de jetons émis sur Ethereum (ou une autre L2).
-
Elle permet aux portefeuilles d’abstraction de compte utilisant un trousseau de clés partagé de détenir des actifs en toute sécurité sur cette chaîne.
Ces deux aspects sont cruciaux, bien que le premier soit largement reconnu. Le second l’est tout autant, car il permet d’avoir un portefeuille facilitant le changement de clés et la détention d’actifs sur de multiples chaînes.
Posséder un pont cross-chain fait-il de vous un Validium ?
Supposons qu’une chaîne supérieure soit initialement autonome, puis qu’on déploie un contrat de pont sur Ethereum. Ce contrat accepte les en-têtes de blocs de la chaîne supérieure, vérifie qu’ils sont accompagnés d’un certificat valide attestant de leur approbation par le consensus de la chaîne supérieure, puis les ajoute à une liste. Des applications peuvent s’appuyer dessus pour permettre le dépôt/retrait de jetons. Une fois ce pont en place, fournit-il les garanties de sécurité précédemment mentionnées ?
Pour l’instant, non, pour deux raisons :
-
Nous vérifions que les blocs sont signés, mais pas que les transitions d’état sont correctes. Ainsi, si vous déposez un actif émis sur Ethereum vers la chaîne supérieure, et que les validateurs de celle-ci deviennent malveillants, ils peuvent signer une transition d’état invalide leur permettant de voler ces actifs.
-
La chaîne supérieure ne peut toujours pas lire Ethereum. Il est donc impossible d’y déposer des actifs natifs d’Ethereum sans recourir à un autre pont tiers (potentiellement non sécurisé).
Transformons maintenant ce pont en pont vérificateur : il vérifie non seulement le consensus, mais aussi via un ZK-SNARK que le nouvel état résultant de chaque bloc est correctement calculé.
Dès lors, les validateurs de la chaîne supérieure ne peuvent plus voler vos fonds. Ils peuvent publier un bloc contenant des données indisponibles, bloquant tous les retraits, mais ils ne peuvent pas voler (sauf à offrir aux utilisateurs les données leur permettant de retirer, contre rançon). Ce modèle de sécurité est identique à celui d’un Validium.
Toutefois, le second problème persiste : la chaîne supérieure ne peut toujours pas lire Ethereum.
Pour y remédier, deux solutions sont possibles :
-
Intégrer dans la chaîne supérieure un contrat de pont vérifiant les blocs d’Ethereum finalisés.
-
Faire en sorte que chaque bloc de la chaîne supérieure contienne le hachage du dernier bloc d’Ethereum, et définir une règle de sélection de fourche obligeant à suivre ce lien. Autrement dit, un bloc de la chaîne supérieure lié à un bloc Ethereum non conforme à la chaîne canonique n’est pas canonique lui-même, et si un bloc Ethereum passe de canonique à non canonique, le bloc associé de la chaîne supérieure doit aussi devenir non canonique.
Est-ce suffisant ? En réalité, non, à cause de quelques cas marginaux :
-
Que se passe-t-il en cas d’attaque 51 % sur Ethereum ?
-
Comment gérer les mises à niveau par hard fork d’Ethereum ?
-
Comment gérer les mises à niveau par hard fork de votre propre chaîne ?
Une attaque 51 % sur Ethereum aurait des conséquences comparables à une attaque similaire sur la chaîne supérieure, mais inversées. Un hard fork d’Ethereum pourrait rendre obsolète le pont interne à la chaîne supérieure. La solution la plus claire consiste à établir un engagement social : si Ethereum rollback un bloc finalisé, ou subit un hard fork, la chaîne supérieure fera de même. Cet engagement n’aurait probablement jamais besoin d’être activé : si un gadget de gouvernance sur la chaîne supérieure détecte une attaque ou un hard fork, il pourrait déclencher automatiquement le rollback, et seul un échec de ce gadget justifierait un hard fork.
Concernant la question (3), la seule réponse viable, malheureusement, est d’avoir sur Ethereum un gadget de gouvernance permettant au contrat de pont de reconnaître les hard forks de la chaîne supérieure.
Conclusion : un pont bidirectionnel vérificateur est presque suffisant pour qu’une chaîne devienne un Validium. Il ne manque essentiellement qu’un engagement social stipulant que, si Ethereum subit un événement exceptionnel rendant le pont invalide, l’autre chaîne répondra par un hard fork.
Conclusion
La « connexion à Ethereum » comporte deux dimensions clés :
-
La sécurité des retraits vers Ethereum ;
-
La sécurité de la lecture d’Ethereum.
Ces deux aspects sont importants et relèvent de considérations différentes :
Notez que chaque dimension comporte deux mesures distinctes (donc quatre dimensions au total) : la sécurité des retraits peut être évaluée selon (i) le niveau de sécurité lui-même et (ii) le nombre d’utilisateurs ou d’usages bénéficiant du niveau maximal de sécurité. Quant à la sécurité de lecture, elle dépend de (i) la rapidité avec laquelle la chaîne peut lire les blocs d’Ethereum, notamment les blocs finalisés versus tous les blocs, et (ii) la force de l’engagement social de la chaîne face aux cas marginaux comme les attaques 51 % ou les hard forks.
De nombreux points de cet espace de conception sont valables. Pour certaines applications, une sécurité élevée et une connexion étroite sont cruciales. Pour d’autres, des solutions plus flexibles sont acceptables afin d’obtenir une meilleure évolutivité. Dans de nombreux cas, commencer par une solution flexible aujourd’hui et progresser vers un couplage plus étroit au fil des améliorations technologiques au cours des dix prochaines années sera probablement le meilleur choix.
Lecture recommandée : Comptes rendus en direct d'ETH HK : que dit Vitalik sur les défis et l'avenir d'Ethereum ? - TechFlow
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@VitalikButerin
