Sécurité L2 et rollups : nouvelles surfaces d'attaque pour la DeFi en 2026

En 2026, la plupart des nouveaux protocoles DeFi lancent d'abord sur un L2, puis bridgent vers le mainnet plus tard, voire jamais. L'économie du coût du block space rend ce choix rationnel. Les compromis de sécurité restent sous-discutés. Cet article détaille les surfaces d'attaque nouvelles sur L2 (celles qui ne s'appliquent pas à un déploiement mainnet du même code) et ce qu'il faut chercher dans un audit de smart contract qui cible un rollup.

Le delta de sécurité L2

Un smart contract déployé sur mainnet hérite de la sécurité complète d'Ethereum : environ 1 million de validateurs, finalité après ~12 minutes, et environ 18 GW de capital inélastique sécurisant la chaîne. Le même contrat sur un L2 hérite d'un set de confiance bien plus petit et plus étroit. Concrètement :

1. Le sequencer. Quasi tous les rollups en production en 2026 ont un seul sequencer, opéré par la société mère du rollup. Ce sequencer peut réordonner, censurer ou retarder des transactions aussi longtemps que la fenêtre de « force inclusion » du rollup le permet.
2. Le système de preuve. Les optimistic rollups dépendent d'au moins un watcher honnête qui soumet des fraud proofs dans la fenêtre de challenge. Les ZK rollups dépendent de la soundness de leur verifier et du trusted setup (quand applicable).
3. Le bridge. Chaque L2 a un bridge canonique vers le mainnet. Le contrat bridge sur L1 détient la totalité du TVL du L2. S'il est compromis, chaque protocole sur le L2 perd tout ce qui est custodié au L1, indépendamment de la sécurité propre du L2.
4. La couche de data availability. Si les données de transaction ne sont pas disponibles, les utilisateurs ne peuvent pas reconstruire l'état pour challenger une fraude ou sortir. La couche DA (que ce soit le L1, une chaîne DA séparée, ou des comités off-chain) est une dépendance forte.

Ces points ne sont pas théoriques. Plusieurs incidents de 2024-2025 sont issus d'une de ces quatre surfaces. L'audit qui les ignore traite le déploiement L2 comme s'il était L1.

Ce qui change dans le périmètre d'audit

Pour un contrat DeFi déployant sur un optimistic rollup :

• MEV au niveau sequencer. Le sequencer peut extraire de la valeur comme les miners pré-Flashbots. Si le pricing de votre protocole est sensible à l'ordre, modélisez ce qu'un sequencer malicieux peut faire.
• Chemin de force-inclusion L1. Les utilisateurs peuvent forcer l'inclusion de transactions sur L1 si le sequencer L2 censure. Vérifiez que votre contrat se comporte correctement quand appelé via ce chemin, y compris validation de signature et accounting du gas.
• Replay des messages cross-domain. Les messages L1↔L2 passent par les messengers canoniques. Assurez-vous que les messages ont des nonces, ne peuvent pas être rejoués, et dégradent gracieusement si le messenger est en pause.
• Sensibilité aux reorgs. Les optimistic rollups ont une longue fenêtre de challenge. L'état qui paraît final au RPC L2 peut encore être contesté. Les consommateurs de messages cross-chain doivent traiter la finalité L2 avec un délai approprié.

Pour un déploiement ZK rollup, remplacez l'analyse fraud-proof par la soundness du verifier : faites confiance aux maths, mais vérifiez que le verifier est celui qui a été audité et qu'aucun upgrade ne peut le swap sans timelock.

Risque bridge : le silent killer

Les bridges détiennent plus de valeur que les protocoles déployés dessus. Les incidents Ronin et Nomad de 2022 ont drainé plus de 800 M$ combinés. Les audits de bridges reçoivent une fraction de l'attention que reçoivent les audits de protocoles DeFi, malgré un risque disproportionné.

Implications pratiques pour une équipe DeFi qui déploie sur L2 :

• N'agrégez pas le risque bridge canonique. Si votre protocole détient de l'USDC sur Arbitrum, vous êtes exposé au risque du bridge USDC et au risque du bridge canonique Arbitrum. Les deux sont des événements systémiques.
• Assets natifs vs bridgés. L'USDC natif (chemin CCTP de Circle) réduit le risque bridge vs l'USDC.e bridgé. Utilisez le natif quand c'est possible.
• Exposition multi-bridges. Si le TVL de votre protocole transite par plusieurs bridges (LayerZero, Wormhole, Across), chacun ajoute de la surface d'attaque. Documentez et bornez-la.
• Comportement en pause de bridge. Auditez comment votre protocole se comporte quand un bridge est en pause. Des withdrawals bloqués peuvent devenir des événements de solvabilité.

Centralisation des sequencers : réalisme contre idéologie

La roadmap « decentralised sequencer » est réelle mais lente. En 2026, la réalité production des sequencers est :

• La plupart des rollups ont encore un seul sequencer.
• Certains ont du sequencing par comité (avec un N encore petit).
• Une poignée fait tourner des shared sequencers (Espresso, Astria) en production.
• Le sequencing vraiment permissionless reste rare.

Votre audit doit modéliser ce qu'un sequencer malicieux ou compromis peut faire, même si la roadmap du rollup promet la décentralisation plus tard. La fenêtre d'audit, c'est le présent.

ZK rollups : soundness contre liveness

Les ZK rollups répartissent le risque différemment. La validity proof élimine le besoin de fraud proofs et de fenêtres de challenge ; la finalité au L1 est rapide. Mais :

• Soundness du verifier. Le contrat verifier au L1 est l'ancre de confiance. Des bugs dans le verifier compromettent tout le rollup. Des vulnérabilités récentes de verifiers ont été trouvées dans du code de production : auditez-le aussi soigneusement que la logique du protocole.
• Trusted setup. Les rollups basés zkSNARK dépendent d'une cérémonie de trusted setup. Un setup compromis veut dire des preuves forgées.
• Liveness du prover. Si aucun prover ne soumet une preuve valide, les withdrawals stallent. L'escape hatch (withdraw sans le prover via interaction L1 directe) doit fonctionner sinon le rollup devient partiellement custodial.
• Complexité du circuit. Le circuit arithmétique qui prouve l'exécution L2 est lui-même un morceau de logiciel. Les bugs à ce niveau sont plus durs à trouver que les bugs Solidity et ont des implications full-state.

Data availability : le nouveau vecteur d'attaque

Le DA-as-a-service (Celestia, EigenDA, Avail) reshape la structure de coût des L2s. Il reshape aussi le modèle de sécurité :

• Un rollup qui poste les données sur sa propre couche DA est seulement aussi sûr que la sécurité économique de cette couche DA.
• L'indisponibilité des données bloque les fraud proofs et les sorties, même si l'exécution est correcte.
• Le mécanisme de consensus de la couche DA elle-même fait partie du threat model de votre protocole.

Pour un protocole DeFi sur un L2 « modulaire » (exécution + DA sur des couches différentes), l'audit doit modéliser explicitement les modes de défaillance DA.

Checklist d'audit pratique pour un déploiement L2

En plus du checklist standard d'audit de smart contract, un audit de protocole déployé en L2 doit répondre à :

1. Par quel bridge la liquidité transite, et quel est son mode de défaillance ?
2. Que fait le protocole pendant une panne de sequencer de >24 h ?
3. Que fait le protocole pendant une attaque de censure pilotée par le sequencer ?
4. Le chemin de force-inclusion L1 est-il testé dans le handling des signatures / nonces du contrat ?
5. Le protocole assume-t-il la finalité du RPC L2, ou la traite-t-il comme conditionnelle ?
6. Les messages cross-chain sont-ils idempotents et replay-protected ?
7. Quel est le comportement du protocole pendant une pause bridge multi-jours ?
8. (Pour les ZK rollups) l'adresse du verifier est-elle upgradeable ? Via quel process ?

Si votre audit n'a pas posé ces questions, vous n'avez pas eu un audit L2-aware. Vous avez eu un audit mainnet qui se trouve déployer ailleurs.