Série Layer2 Proof (Partie 1) – OP Stack Fraud Proof : enjeux, solutions et innovations

Aperçu

Les solutions Layer 2 (L2) constituent une réponse prometteuse aux problématiques de scalabilité du Layer 1. Cette série se concentre sur les dispositifs de proof en L2, avec un accent particulier sur les mécanismes de fraud proof. Ces systèmes sont des dispositifs cryptographiques servant à valider et vérifier les transactions ou calculs sur la blockchain, garantissant l’intégrité et la sécurité des opérations sur le registre distribué.

Synthèse du fonctionnement d’Optimistic Rollup

Le workflow Optimistic Rollup s’articule autour de sept étapes clés qui constituent une chaîne complète de vérification des transactions. Initialement, les utilisateurs initient des transactions sur le réseau Layer 2 en les adressant directement au séquenceur L2. Ce dernier exécute ces transactions à partir de sa copie de la chaîne L2 et génère une nouvelle racine d’état reflétant la mise à jour du registre.

Après exécution, le séquenceur transmet à la blockchain Layer 1 l’ensemble des transactions d’origine ainsi que les nouvelles racines d’état calculées. À la réception, le smart contract L1 ouvre une fenêtre temporelle de contestation, durant laquelle tout participant du réseau peut s’opposer à la validité des transactions ou résultats d’exécution soumis par le séquenceur L2. Cette phase de contestation est décisive pour la sécurité du système et la prévention des activités malveillantes.

À l’issue de la période de contestation, la blockchain L1 finalise l’enregistrement de l’exécution L2. Si un séquenceur est reconnu malveillant lors de cette phase, des sanctions sont appliquées et les racines d’état sont recalculées pour garantir l’exactitude et rétablir l’intégrité du système.

Pourquoi le mécanisme de preuve est-il crucial pour la sécurité L2 ?

Le mécanisme de fraud proof et le système de contestation sont essentiels pour limiter les risques liés à un comportement malveillant du séquenceur. L’utilisation de preuves cryptographiques permet à tout participant sur la blockchain L1 de vérifier indépendamment la validité des transactions rollup et des racines d’état, sans devoir réexécuter l’intégralité de l’historique des transactions.

Optimism met en œuvre une fenêtre de contestation élargie, permettant à différents acteurs — utilisateurs et validateurs indépendants — de vérifier la conformité des résultats d’exécution et des racines d’état. Cette période de vérification donne le temps à la communauté d’identifier et de contester les soumissions potentiellement frauduleuses, établissant ainsi un modèle de sécurité robuste fondé sur des mécanismes incitatifs et la vérification cryptographique, non sur la confiance envers un acteur centralisé.

Fraud Proof vs Validity Proof

Deux grandes familles de solutions de proof existent dans l’écosystème blockchain, chacune avec ses principes opérationnels et arbitrages. Les systèmes de validity proof imposent au séquenceur d’inclure des preuves cryptographiques de validité lors de la soumission des résultats au Layer 1. Ces preuves permettent à tout membre du réseau L1 de vérifier instantanément la conformité des résultats sans devoir réexécuter les transactions sur la L2, mais nécessitent des systèmes mathématiques complexes et de la zero-knowledge proof.

Les systèmes de fraud proof, aussi appelés fault proof, fonctionnent sur un autre postulat. Ils partent d’une présomption d’honnêteté du séquenceur par défaut et s’appuient sur un mécanisme de contestation pour garantir la conformité. Dans ce schéma, les participants disposent d’un délai pour contester les soumissions suspectes, transférant la charge de la preuve du séquenceur vers le contestataire, ce qui peut être plus efficace lorsque la majorité des soumissions sont valides.

Solutions de fraud proof

Les dispositifs de fraud proof s’organisent autour de deux approches majeures : non-interactive et interactive, chacune avec ses choix d’architecture et ses conséquences sur la performance.

Présentation du fraud proof non interactif

Les fraud proofs non interactifs reposent sur la réexécution directe de toutes les transactions L2 sur L1. Cette approche requiert une infrastructure capable d’exécuter les transactions L2 dans l’environnement L1 et de vérifier les évolutions d’état de la L2 via la couche de vérification L1. Les principaux défis concernent la réexécution des transactions L2 sur L1 et la résolution des incohérences d’état entre les environnements L2 et L1 pour garantir une vérification fiable.

The Optimism Virtual Machine (OVM v1)

Pour résoudre les problèmes de cohérence d’état avec les fraud proofs non interactifs, le protocole Optimism a mis en place plusieurs techniques avancées. Les engagements d’état sont générés régulièrement par la L2, produisant des preuves cryptographiques de l’état complet. La disponibilité des données est assurée par la validation sur L1 de la présence et de l’accessibilité des données requises. La vérification de l’exécution intervient lorsque les validateurs L1 réexécutent les transactions à partir des données L2 dans le contexte L2. Des mécanismes de communication inter-chaînes facilitent l’interaction L1/L2. Enfin, des incitations bien conçues favorisent un comportement honnête.

L’innovation principale de l’OVM a été la création d’un « contenant » donnant à la réexécution sur L1 la même fonctionnalité qu’une exécution sur L2. Cela passe par le préchargement de l’état des comptes (préparation des états L2 pour L1), la modification de la gestion des bytecodes EVM liés au stockage et à l’accès à l’état, le déploiement de smart contracts sur L1 qui modifient le bytecode utilisateur pour accéder à des données externes, et la modification du compilateur Solidity pour générer du bytecode OVM à la place du bytecode EVM classique.

Limites de l’OVM

Malgré son caractère innovant, l’OVM présente plusieurs limitations. Il introduit une complexité importante via la modification du compilateur de bytecode, obligeant les développeurs à manipuler un bytecode non standard. L’augmentation de la taille du code résulte du remplacement d’opcodes par des appels de fonction, ce qui alourdit les instructions et augmente le coût de déploiement. La consommation de gas croît sensiblement, les appels de fonction étant plus coûteux que des opcodes, rendant ainsi les transactions OVM plus onéreuses. Enfin, la performance demeure limitée, l’OVM n’étant pas totalement optimisé, ce qui peut provoquer des ralentissements dans le traitement des transactions.

Présentation du fraud proof interactif d’Optimism

Les fraud proofs interactifs marquent un changement de paradigme, s’appuyant sur un protocole d’échanges entre un défenseur et un contestataire pour valider la transition d’état. Cette approche vise une plus grande efficacité que les mécanismes classiques, car elle permet de concentrer les ressources de calcul sur les parties en litige, sans nécessiter la réexécution de toutes les transactions.

L’implémentation actuelle d’Optimism, le projet Cannon, cible une vérification reposant sur une seule instruction MIPS exécutée sur L1, réduisant drastiquement la charge de calcul on-chain.

Présentation de Cannon

Cannon vise plusieurs objectifs : éliminer les modifications de smart contract au niveau opcode, évitant la complexité des scénarios EVM-on-EVM ; proposer un mécanisme simplifié d’accès à l’état L2 ; et réduire fortement les coûts de vérification on-chain des fraud proofs.

Ces objectifs sont atteints grâce à plusieurs innovations. L’accès unifié à l’état passe par un oracle de préimage, mécanisme permettant d’accéder à l’état L2 via des valeurs de hachage. Plutôt que de réexécuter les transactions au niveau contrat, Cannon utilise un replay au niveau Geth, plus proche de l’implémentation client. La vérification on-chain est optimisée pour ne nécessiter qu’une instruction MIPS, réduisant la charge de calcul. Le op-program sert de passerelle d’accès et de génération des données de préimage, tandis que le dispute game permet à défenseur et contestataire d’identifier les instructions problématiques.

Processus de Cannon

L’architecture de Cannon repose sur plusieurs composants clés fonctionnant ensemble. Le op-program est une implémentation client-serveur pour l’accès aux données de préimage : le client est compilé en instructions MIPS, le serveur gère les requêtes et la récupération de préimage. Cannon agit comme un émulateur MIPS exécutant les instructions MIPS, et inclut le composant mipsevm et des smart contracts on-chain. MIPS.sol est l’interpréteur des instructions MIPS on-chain, PreimageOracle.sol gère les requêtes de préimage venant de MIPS.sol.

Le workflow suit une séquence précise. Le client op-program MIPS est chargé dans l’émulateur Cannon MIPS, générant l’état initial pour la preuve de fraude. L’exécution démarre, effectue les étapes dans mipsevm, enregistre les accès et sauvegarde si besoin les données de préimage. Le dispute game démarre si des contestataires identifient des divergences entre l’état du rollup L2 et celui enregistré sur L1. Défenseur et contestataire utilisent une recherche binaire pour localiser l’instruction générant des états différents. Les preuves sont ensuite préparées et soumises à MIPS.sol pour la vérification on-chain.

Défis du fraud proof interactif d’Optimism

Malgré ses innovations, Cannon rencontre plusieurs défis majeurs. Le choix de l’instruction set MIPS s’explique par le support natif de Golang, la facilité d’implémentation et la simplicité d’architecture, mais crée une barrière d’apprentissage. Le risque d’exploits du runtime Golang pose des enjeux de sécurité, Cannon ayant dû corriger plusieurs fonctions dont la désactivation du garbage collection, pouvant générer des erreurs mémoire sur des scénarios intensifs.

La fenêtre de contestation constitue la principale contrainte pour l’utilisateur. Ce délai impose une attente avant le retrait des tokens, générant des frictions pour les applications sensibles au facteur temps. Par ailleurs, la sécurité des smart contracts L1 et des composants off-chain exige une vigilance continue.

Solutions alternatives

La communauté blockchain explore activement d’autres pistes, avec plusieurs propositions fondées sur les fraud proofs utilisant le zero-knowledge. De telles solutions visent à réduire, voire supprimer, la phase interactive des fraud proofs classiques, offrant potentiellement une finalité plus rapide et une complexité moindre, pour des compromis différents en termes d’exigence de calcul et de temps de génération de la preuve.

Initiatives d’avancement des L2 Proof

Avec le développement des principales implémentations blockchain L2 basées sur OP Stack, les projets accélèrent la progression des dispositifs de fraud proof par diverses initiatives : amélioration de l’efficacité de l’infrastructure off-chain, optimisation de la fenêtre de contestation pour une finalité plus rapide, consolidation des smart contracts on-chain via des tests et audits approfondis, et exploration de solutions alternatives adaptées aux besoins des applications et communautés d’utilisateurs.

Conclusion

Cet article retrace l’évolution des dispositifs de fraud proof Layer 2, des approches historiques aux innovations interactives portées par le projet Cannon. L’analyse couvre les principes de conception de l’OVM, son ambition de créer un environnement d’exécution EVM-compatible sur L1, ainsi que les choix d’architecture et d’implémentation de Cannon, qui marque une avancée en réduisant la vérification on-chain à une seule instruction MIPS. Ces développements illustrent l’évolution continue de la technologie Layer 2 vers plus d’efficacité, une réduction des coûts et une expérience utilisateur optimisée, tout en maintenant les garanties de sécurité indispensables aux applications blockchain.

FAQ

Qu’est-ce qu’un fraud proof ?

Les fraud proofs sont des preuves cryptographiques permettant de contester la validité de transactions sur les réseaux blockchain. Ils garantissent l’intégrité des transactions et sont essentiels pour les solutions de scalabilité blockchain.

Comment fonctionnent les fraud proofs dans Optimistic Rollups ?

Les fraud proofs permettent aux utilisateurs de contester les états L2 incorrects proposés par les séquenceurs. Les optimistic rollups publient les données de transaction et reposent sur des tiers pour reconstruire l’état L2. En cas de divergence, les contestataires peuvent challenger l’état sur L1 via un mécanisme de jeu de bissection, identifiant l’étape de calcul incorrecte et exécutant des proofs one-step pour prouver la fraude.

Quelle différence entre fraud proofs et validity proofs ?

Les fraud proofs valident les transactions a posteriori en contestant les transactions frauduleuses, tandis que les validity proofs les confirment instantanément grâce à la cryptographie zero-knowledge. Les validity proofs sont plus efficaces et offrent une finalité immédiate, là où les fraud proofs imposent un délai d’attente pour d’éventuelles contestations.