Que sont les contrats intelligents de couche 2 et comment fonctionnent-ils ?

Définition et concept de base

1. Les contrats intelligents de couche 2 sont des accords auto-exécutables déployés sur des protocoles secondaires construits sur une blockchain de base, le plus souvent Ethereum.

2. Ces contrats héritent des hypothèses de sécurité de la couche 1 sous-jacente, mais exécutent des calculs et des mises à jour d'état hors chaîne ou dans des environnements hautement optimisés.

3. Ils s'appuient sur des preuves cryptographiques ou des défis de fraude pour garantir l'exactitude sans exiger que chaque nœud de la chaîne principale valide chaque opération.

4. Le déploiement s'effectue via des mécanismes de pont spécifiques qui ancrent la logique contractuelle et les soldes des utilisateurs à la couche 1, permettant une interaction minimisée en termes de confiance entre les couches.

5. Contrairement aux contrats natifs de couche 1, leur exécution de bytecode s'effectue en dehors de la couche de consensus, ce qui réduit considérablement la surcharge de gaz et la latence.

Architecture opérationnelle

1. Un système de contrat intelligent de couche 2 typique comprend un séquenceur, un prouveur (dans des cumuls basés sur ZK) et un contrat de vérificateur sur la couche 1.

2. Les utilisateurs soumettent les transactions au séquenceur, qui les regroupe et calcule une nouvelle racine d'état ou une nouvelle preuve de validité.

3. La racine d'état ou la preuve mise à jour est soumise au contrat du vérificateur de couche 1, déclenchant une validation automatique ou activant des fenêtres de défi.

4. Les modifications du stockage sous contrat sont reflétées sous forme compressée (souvent sous forme de racines Merkle) plutôt que sous forme d'écritures sur des emplacements de stockage individuels.

5. Les interactions avec les contrats de couche 1 se produisent via des interfaces de pont standardisées, appliquant une sémantique stricte de transmission des messages et une vérification des signatures.

Dépendances du modèle de sécurité

1. La sécurité dépend de l'intégrité de la couche de disponibilité des données : pour les cumuls optimistes, les données d'appel doivent être publiées en chaîne ; pour les cumuls ZK, les preuves de validité doivent être vérifiables par la couche 1.

2. Un séquenceur compromis peut retarder les retraits ou réorganiser les transactions, mais ne peut pas forger de transitions d'état valides sans violer les garanties cryptographiques.

3. Les preuves de fraude dans les systèmes optimistes supposent qu'au moins un participant honnête détectera et contestera les affirmations invalides dans le délai de contestation.

4. Les systèmes basés sur ZK éliminent le besoin de faire confiance aux séquenceurs en exigeant des preuves succinctes qui confirment mathématiquement l'exactitude des calculs avant que les mises à jour d'état ne soient acceptées.

5. L'évolutivité des contrats repose souvent sur des contrats de gouvernance multi-signatures ou contrôlés par DAO sur la couche 1, introduisant des surfaces d'attaque supplémentaires si elles ne sont pas rigoureusement auditées.

Efficacité du gaz et flux d'exécution

1. Les frais de transaction sont calculés en fonction de la taille des données d'appel compressées et de la complexité de calcul au sein de l'environnement de couche 2, et non des opcodes EVM exécutés sur la couche 1.

2. Une seule transaction de couche 2 peut coûter moins de 1 % de son équivalent sur le réseau principal Ethereum en raison des coûts de vérification partagés entre des milliers d'opérations.

3. L'exécution suit des règles déterministes codées dans la machine virtuelle du rollup, telles que l'AVM d'Arbitrum ou l'OVM d'Optimism, qui émulent mais s'écartent du comportement EVM standard.

4. La gestion des restaurations diffère : les erreurs déclenchent une restauration locale dans le contexte d'exécution de la couche 2, tandis que la finalité nécessite la confirmation de la couche 1 de l'inclusion du lot.

5. L'émission d'événements se produit à la fois localement et via des contrats de pont canoniques, permettant aux dApp d'écouter les activités entre couches à l'aide de schémas d'événements standardisés.

Foire aux questions

Q : Les contrats intelligents de couche 2 peuvent-ils accéder directement au solde ETH d'une adresse sur la couche 1 ? R : Non. Ils observent uniquement les soldes reflétés via les dépôts relais. L'ETH natif sur la couche 1 reste inaccessible jusqu'à ce qu'il soit explicitement ponté.

Q : Les contrats intelligents Solidity sont-ils automatiquement compatibles avec tous les réseaux de couche 2 ? R : Pas universellement. Bien que beaucoup prennent en charge une exécution équivalente à EVM, des différences subtiles dans les précompilations, la mesure du gaz et le comportement des opcodes nécessitent une compilation et des tests ciblés.

Q : Que se passe-t-il si un réseau de couche 2 arrête indéfiniment son séquenceur ? R : Les utilisateurs conservent la possibilité de forcer le retrait à l'aide de mécanismes en chaîne, bien que des retards et une intervention manuelle puissent être nécessaires en fonction de la conception.

Q : Les contrats intelligents de couche 2 prennent-ils en charge les appels de délégués entre les couches ? R : Non. Delegatecall fonctionne dans un contexte d’exécution unique. Les appels intercouches nécessitent le passage de messages explicites via des contrats de pont et ne peuvent pas préserver le contexte de stockage entre les chaînes.