Comment exécuter un message inter-chaînes avec un contrat LayerZero ?

Comprendre l'architecture LayerZero

1. LayerZero fonctionne comme un protocole d'interopérabilité léger et sans autorisation qui permet la communication entre les blockchains sans recourir à des intermédiaires de confiance ou à des actifs enveloppés.

2. Il exploite les nœuds ultra légers (ULN) déployés sur chaque chaîne pour vérifier l'intégrité et la cohérence des messages sans stocker l'état complet de la blockchain.

3. Les composants principaux incluent le contrat Endpoint, qui gère le routage des messages, ainsi que les services Oracle et Relayer qui récupèrent et fournissent indépendamment les en-têtes de bloc et les preuves de transaction.

4. Chaque chaîne conserve sa propre adresse de point de terminaison et les développeurs doivent déployer ou interagir avec des adaptateurs ULN compatibles pour lancer des appels entre chaînes.

5. La livraison du message est asynchrone et déterministe : une fois envoyée, elle reste en attente jusqu'à ce qu'Oracle et Relayer confirment le même hachage de bloc et la même preuve.

Déploiement et configuration du point de terminaison

1. Les développeurs doivent d'abord identifier l'adresse correcte du point de terminaison pour leurs chaînes source et de destination à l'aide de la documentation officielle de LayerZero ou des outils d'exploration.

2. Un contrat personnalisé héritant de LayerZeroReceiver ou LayerZeroUserApplicationConfig doit être déployé sur la chaîne source pour définir la logique d'envoi.

3. Le point de terminaison nécessite le paiement du gaz en jetons natifs des deux chaînes : l'expéditeur paie la transmission sortante, tandis que le destinataire couvre les frais d'exécution entrants.

4. Les paramètres de configuration tels que dstChainId , dstEndpoint et adapterParams doivent être codés avec précision avant la soumission.

5. Des paramètres d'adaptateur mal configurés (en particulier une estimation incorrecte des frais ZRO ou des paramètres de compression de charge utile incorrects) peuvent entraîner des pannes silencieuses lors du relais.

Encodage et envoi de la charge utile

1. Les données de l'application doivent être codées en octets en ABI à l'aide de abi.encode de Solidity ou d'un outil équivalent, garantissant ainsi l'absence d'ambiguïtés de tableau dynamique ou de divergences d'alignement.

2. La fonction d'envoi sur le point de terminaison accepte trois arguments : l'ID de la chaîne de destination, l'adresse de destination et la charge utile codée, ainsi que les paramètres spécifiques à l'adaptateur.

3. La taille de la charge utile est limitée par la limite de gaz de bloc de la chaîne de destination et par le plafond par message de LayerZero : un dépassement de 10 Ko déclenche souvent le rejet à moins qu'il ne soit compressé via LZ4 ou un prétraitement similaire.

4. Les développeurs doivent inclure une allocation de gaz suffisante pour l'envoi initial et l'appel exécuté OnReceive ultérieur : une sous-estimation interrompt le traitement des messages à la destination.

5. Toutes les charges utiles sont immuables une fois soumises ; aucune modification ou annulation n'est possible après la confirmation de la transaction sur la chaîne source.

Réception et validation des messages

1. Le contrat de destination doit implémenter lzReceive , qui est automatiquement invoqué par le point de terminaison en cas de vérification réussie du relais.

2. Dans lzReceive , les développeurs doivent valider srcAddress et srcChainId pour empêcher l'usurpation d'identité ou l'injection d'origine non autorisée.

3. Les gardes de réentrée sont obligatoires : le fait de ne pas verrouiller l'état pendant l'exécution peut permettre des exploits en double dépense ou en invocation récursive.

4. Le décodage doit refléter exactement le codage source ; les types ou les ordres incompatibles provoquent un retour sans visibilité du message d'erreur sur la chaîne.

5. Le msg.sender dans lzReceive est toujours le contrat du point de terminaison local (et non l'utilisateur d'origine), le contrôle d'accès doit donc s'appuyer sur des identifiants sources vérifiés.

Foire aux questions

Q : Puis-je envoyer un message d'Ethereum à Arbitrum sans déployer de contrat sur Arbitrum ? R : Non. Un contrat de réception implémentant lzReceive doit exister sur Arbitrum et être enregistré auprès du point de terminaison local.

Q : Que se passe-t-il si Oracle signale un hachage de bloc différent de celui du Relayer ? R : Le message s'arrête indéfiniment jusqu'à ce que les deux services convergent vers des valeurs identiques. Aucune tentative automatique ou repli ne se produit.

Q : Est-il sûr de coder en dur l'adresse du point de terminaison dans les contrats de production ? R : Oui, mais seulement après avoir vérifié son immuabilité sur la chaîne cible : certains points de terminaison du réseau de test sont mis à niveau, tandis que ceux du réseau principal sont corrigés.

Q : Pourquoi ma transaction est-elle annulée avec « Charge utile invalide » même si l'encodage semble correct ? R : Cela provient généralement de non-concordances de version de l'encodeur ABI, de sélecteurs de champ de structure manquants ou d'une utilisation incorrecte de abi.encodePacked au lieu de abi.encode .