Comment éviter les attaques par relecture dans les transferts inter-chaînes

Validation de transaction non basée

1. Chaque transaction sur les chaînes compatibles Ethereum comprend un champ occasionnel représentant le nombre de transactions envoyées depuis cette adresse.

2. Les nœuds vérifient si le nom occasionnel soumis correspond à l'état du compte actuel avant l'exécution.

3. Une fois traité, le compte nonce s'incrémente de un, rendant toute soumission en double invalide.

4. Ce mécanisme empêche la relecture intra-chaîne mais ne protège pas intrinsèquement entre les forks ou les chaînes hétérogènes.

5. Une mauvaise gestion des valeurs occasionnelles, comme la réutilisation ou l'omission de valeurs, peut exposer les utilisateurs à des dépenses doubles ou à des échecs d'exécution.

Intégration de l'ID de chaîne dans les signatures

1. EIP-155 a introduit l'intégration d'ID de chaîne dans les signatures de transaction pour distinguer les réseaux.

2. Lors de la signature, les portefeuilles incluent l'identifiant numérique de la chaîne actuelle ainsi que les composants r, s et v.

3. Les nœuds rejettent les signatures dont l'ID de chaîne intégré ne correspond pas à la valeur configurée du réseau cible.

4. Cela bloque les rediffusions cross-fork, telles que la diffusion d'une transaction sur le réseau principal ETH sur ETC ou vice versa.

5. Les chaînes comme BSC et Polygon adoptent des identifiants de chaîne distincts, rendant leurs transactions signées incompatibles avec le réseau principal Ethereum.

Signature de demande limitée dans le temps

1. Un horodatage est ajouté à chaque charge utile de message inter-chaîne avant la signature cryptographique.

2. Les validateurs du destinataire vérifient si l'horodatage se situe dans une fenêtre de temps acceptable, généralement ± 300 secondes.

3. Les messages hors fenêtre sont supprimés quelle que soit la validité de la signature.

4. Cette approche atténue les attaques à relais retardé où des observateurs malveillants détiennent et soumettent à nouveau des preuves valides.

5. La synchronisation entre les horloges de la chaîne source et destination doit être maintenue pour éviter les faux rejets.

Identificateurs de messages inter-chaînes uniques

1. Chaque message inter-chaînes porte un identifiant unique au monde dérivé de l'ID de la chaîne source, de la hauteur du bloc et de l'index des événements.

2. Les contrats de destination maintiennent un registre des identifiants de messages traités pour détecter les doublons.

3. Les nœuds relais soumettent des preuves contenant ces identifiants, permettant une déduplication déterministe.

4. Cette méthode fonctionne indépendamment du timing de consensus et prend en charge les protocoles de pontage asynchrones.

5. La résistance aux collisions repose sur des sources d'entropie appropriées lors de la génération de l'ID et sur une application stricte au niveau de la couche de vérification.

Vérification de preuve sans connaissance

1. Les zk-SNARK ou zk-STARK codent les contraintes de validité et d'unicité des transactions dans des preuves succinctes.

2. Les contrats des vérificateurs n'acceptent que les preuves démontrant à la fois la bonne exécution et l'absence de traitement préalable.

3. Le prouveur s'engage sur une racine Merkle contenant tous les événements inter-chaînes précédemment traités.

4. Chaque nouvelle preuve inclut un chemin prouvant l'inclusion de son propre hachage dans une racine mise à jour, empêchant ainsi sa réutilisation.

5. Cette technique élimine le recours à des observateurs centralisés ou à des relais de confiance tout en maintenant la résistance à la censure.

Foire aux questions

Q1 : Des attaques par relecture peuvent-elles se produire même lors de l'utilisation de portefeuilles matériels ? Oui. Les portefeuilles matériels sécurisent l'utilisation de la clé privée mais n'empêchent pas la relecture si les paramètres de transaction tels que le nonce ou l'ID de chaîne sont mal configurés lors de la diffusion.

Q2 : L’augmentation du prix du gaz empêche-t-elle les attaques par rejeu ? Le prix du gaz affecte la priorité des transactions et la vitesse d'inclusion, mais n'a aucune incidence sur l'unicité de la signature ou la validation spécifique à la chaîne.

Q3 : Les jetons enveloppés sont-ils intrinsèquement vulnérables à la relecture ? Les jetons encapsulés eux-mêmes ne sont pas vulnérables, mais le protocole de pont sous-jacent gérant les opérations de verrouillage/mint peut l'être s'il manque de déduplication de message ou d'attestations de portée en chaîne.

Q4 : En quoi LayerZero et Wormhole diffèrent-ils dans la conception de la protection contre la relecture ? LayerZero utilise la séparation Oracle + Relayer avec des paramètres ULN configurables pour renforcer l'unicité des messages par point de terminaison, tandis que Wormhole intègre des en-têtes VAA signés par le tuteur contenant un contexte spécifique à la chaîne et des numéros de séquence vérifiés en chaîne.