ERC721-O : Protocole standard et mise en œuvre des NFT entièrement sur chaîne
TechFlow SélectionTechFlow Sélection
ERC721-O : Protocole standard et mise en œuvre des NFT entièrement sur chaîne
Le NFT Catddle sera le premier NFT tout-chaîne développé à l'aide d'ERC721-O.
Dédié à des analyses Web3 approfondiesERC721-O est conçu par l'équipe de développement Catddle Lab, derrière Catddle NFT. Catddle NFT sera le premier NFT entièrement multi-chaînes développé avec ERC721-O.
*ERC721-O est un projet entièrement open source ; contribuez dès maintenant sur GitHub !
Aperçu
ERC721-O est un protocole standard et son implémentation pour les NFT (jetons non fongibles) entièrement multi-chaînes, basé sur ERC721.
Le protocole ERC721-O vise à permettre aux applications tierces (par exemple portefeuilles, bourses) d'interagir et de valider uniformément tout NFT implémentant ce protocole.
ERC721-O ajoute plusieurs fonctionnalités inter-chaînes et propose une série de solutions aux problèmes de sécurité liés au passage d'une chaîne à une autre.
Contexte
LayerZero est une nouvelle infrastructure blockchain qui fournit un service de transmission de messages entre blockchains différentes. Selon le document officiel de LayerZero, ce service garantit une transmission valide. Lorsqu’un destinataire reçoit un message m provenant d’un tel service valide, ce dernier assure que la transaction associée t a bien été validée et enregistrée sur la blockchain émettrice.
Grâce à ce protocole universel de messagerie, la mise en œuvre de NFTs véritablement multi-chaînes devient possible.
Différences entre ERC721-O et les autres NFTs multi-chaînes existants*
Améliorations apportées par ERC721-O
Plus sécurisé
· Mécanisme de protection contre l’épuisement du gaz inter-chaînes
Bien que nous ayons mis en place diverses protections comme le mode non-bloquant, un NFT peut toujours être bloqué lors d’un transfert inter-chaînes si la limite de gaz (destination gas limit) est trop faible.
Pour éviter cela, nous avons introduit un mécanisme de protection. Le propriétaire du contrat peut définir une limite minimale raisonnable de gaz inter-chaînes afin de garantir que tous les NFT puissent achever leur transfert sans problème de gaz insuffisant, tout en préservant les autres fonctionnalités inter-chaînes.
· Configuration sécurisée des adresses distantes
La mise à jour d’un contrat NFT multi-chaînes en cours d’utilisation peut entraîner une perte irréversible de fonds. De plus, lors du déploiement du contrat NFT sur une nouvelle chaîne, si les appels de fonctions ne suivent pas un ordre spécifique, les NFT peuvent être bloqués ou même perdus définitivement pendant le transfert inter-chaînes.
Pour résoudre ces problèmes, ERC721-O intègre un mécanisme sécurisé de configuration des adresses distantes. Ce mécanisme permet au propriétaire du contrat d’éviter toute perte de fonds lors de mises à jour, sans avoir à se soucier de l’ordre des appels entre chaînes.
· Verrouillage de la version de la bibliothèque tierce
L’envoi et la réception de messages dépendent de la bibliothèque LayerZero. En cas de mise à jour de LayerZero, il est essentiel de pouvoir figer la version de cette bibliothèque tierce pour éviter tout bug potentiel. C’est d’ailleurs la meilleure pratique recommandée officiellement par LayerZero.
· Dernier recours conservé
Même avec plusieurs mesures de sécurité (comme le mode non-bloquant et la protection du gaz), il peut arriver qu’un chemin de message soit bloqué sans possibilité de réessai réussi.
forceResumeReceive est notre ultime recours, sans quoi les erreurs de chaîne resteraient bloquées indéfiniment. Nous le conservons donc dans l’implémentation comme mesure de dernier recours.
Fonctionnalités supplémentaires
· Prise en charge du modèle d’approbation tiers pour les transferts
L’autorisation (approve) d’un tiers à transférer vos jetons est une fonction clé offerte par ERC20 et ERC721. Nous ajoutons cette fonctionnalité pour permettre aux applications tierces d’interagir plus efficacement avec les NFTs multi-chaînes.
· Choix libre de l’adresse cible pour les transferts inter-chaînes
Les utilisateurs peuvent désormais transférer leurs NFT vers n’importe quelle adresse sur une autre chaîne, plutôt que seulement vers la même adresse.
· Airdrop automatique de gaz lors de l’envoi d’un NFT
Après avoir envoyé un NFT sur une autre chaîne, l'utilisateur doit généralement envoyer manuellement du gaz natif (Ether, BNB, AVAX, etc.) vers son adresse sur la chaîne cible pour pouvoir l'utiliser — une étape fastidieuse.
Désormais, l’airdrop de gaz peut être effectué simultanément avec l’envoi du NFT, éliminant toute action supplémentaire sur la chaîne cible.
· Paiement des frais inter-chaînes via un jeton
Lorsque LayerZero lancera son propre jeton, les utilisateurs pourront régler les frais inter-chaînes en configurant un propriétaire spécifique du jeton. Des réductions pourraient alors être proposées :)
Plus transparent
· Divulgation obligatoire des informations critiques de déploiement
Dans la conception du protocole ERC721-O, l’adresse du point de terminaison (endpoint) émetteur et l’adresse du contrat distant (remote) doivent être publiques. Tout utilisateur ou tiers peut ainsi vérifier que l’endpoint provient bien de LayerZero et que l’adresse du contrat distant est correctement configurée.
Les plateformes tierces comme les bourses ou portefeuilles peuvent donc facilement intégrer des mécanismes de vérification pour protéger les utilisateurs contre toute perte potentielle.
· Divulgation des activités importantes sur la chaîne
L’émission d’événements lors d’activités critiques permet aux utilisateurs et aux tiers de connaître immédiatement ce qui se passe sur la chaîne.
Dans la conception de l’interface ERC721-O, l’envoi et la réception d’un NFT vers une autre chaîne déclenchent obligatoirement un événement. Cela permet de suivre clairement toutes les actions sur la chaîne.
Dans l’implémentation ERC721-O, d’autres activités clés (comme la pause ou la modification de l’adresse distante) génèrent également des événements pour informer des changements importants.
· Suivi possible du Nonce
Le nonce identifie le nombre de transactions envoyées depuis une adresse donnée. LayerZero offre la capacité de suivre le nonce, que ERC721-O intègre dans les événements inter-chaînes. Grâce aux données fournies par ces événements, utilisateurs et tiers peuvent facilement associer les transactions entre la chaîne source et la chaîne cible.
Réduction de la consommation de gaz
Puisque LayerZero effectue déjà une estimation du gaz pour l’utilisateur, la vérification préalable du gaz avant l’envoi du message est redondante. ERC721-O la supprime donc pour réduire la consommation de gaz lors des transferts inter-chaînes.
Code facilement personnalisable et réutilisable
Toutes les fonctions et variables sont conçues pour être facilement surchargées et réutilisées.
En tant que classe de base, les mots-clés virtual, override et internal sont largement utilisés, accompagnés de commentaires explicites, afin de guider clairement les développeurs qui héritent du code du contrat.
Principes sous-jacents aux choix de sécurité
LayerZero fournit une excellente implémentation de base, comme illustré dans cet exemple officiel. De plus, des projets comme Gh0stly Gh0sts ont démontré tout le potentiel des NFTs inter-chaînes.
Cependant, pour que les jetons multi-chaînes progressent davantage, certaines graves vulnérabilités doivent être anticipées et corrigées. C’est pourquoi ERC721-O introduit une série de mécanismes de sécurité spécifiques.
Avant d’entrer dans les détails, précisons un concept important : le blocage des messages inter-chaînes. Le blocage des messages inter-chaînes désigne un état où les messages ne peuvent plus être transmis de la chaîne source à la chaîne cible. Dans cet état, le contrat source continue d’envoyer des messages, mais ceux-ci restent suspendus, ni sur la chaîne source ni sur la chaîne cible, et ne peuvent être exécutés.
Cet état est non seulement frustrant pour les utilisateurs, mais aussi dangereux car :
Tous les messages bloqués disparaissent de la chaîne et attendent dans une file gérée par LayerZero, ce qui comporte des risques.
Si les messages en échec ne peuvent pas être analysés, la file de messages bloqués reste figée indéfiniment.
Si le propriétaire du contrat utilise forceResumeReceive pour traiter un message en échec au lieu de retryPayload, le message peut être perdu à jamais. Or, dans un NFT multi-chaînes, perdre un message équivaut à perdre le NFT lui-même.
L’objectif principal des mesures de sécurité est donc de minimiser autant que possible les risques de blocage des messages.
· Mécanisme de protection contre l’épuisement du gaz inter-chaînes
Il convient de noter que même avec un mécanisme non-bloquant, un jeton peut être bloqué si la limite de gaz inter-chaînes (destination gas limit) est trop faible.
Dans la conception d’ERC721-O, les paramètres de l’adaptateur sont entièrement accessibles aux utilisateurs, offrant davantage de flexibilité, par exemple pour airdropper des jetons de gaz (Ether, BNB, AVAX, etc.) en même temps que le NFT. Les utilisateurs peuvent aussi régler manuellement la limite de gaz inter-chaînes. Si un utilisateur fixe cette limite à 100 et lance un transfert, la requête est valide côté LayerZero, mais entraînera un blocage de la transaction — même en mode non-bloquant.
En effet, si la limite de gaz est trop basse, la transaction sur la chaîne destinataire échoue avant même l’exécution du bloc try-catch. Autrement dit, le mode non-bloquant est inefficace dans ce cas.
Pour résoudre cela, ERC721-O introduit un mécanisme de protection du gaz. Ce mécanisme vérifie la validité des paramètres d’adaptateur saisis par l’utilisateur. Si les paramètres sont invalides ou si le gaz alloué est inférieur au minimum défini par le propriétaire du contrat, la transaction est annulée. Ce mécanisme ne limite pas l’utilisation de paramètres avancés, notamment pour l’airdrop de gaz.
Ainsi, le propriétaire du contrat peut définir une limite minimale raisonnable selon la consommation de gaz de sa fonction de réception, évitant ainsi tout blocage.
· Configuration sécurisée des adresses distantes
N’importe qui peut utiliser LayerZero pour envoyer des messages à n’importe qui. Il faut donc configurer l’adresse distante pour éviter l’exécution de messages illégitimes. Dans les implémentations existantes, la fonction setTrustedRemote permet de limiter l’expéditeur autorisé. Le propriétaire du contrat appelle setTrustedRemote pour définir l’adresse distante, après quoi seul ce contrat pourra envoyer des messages.
Cela semble logique, mais on néglige souvent que les opérations sur différentes chaînes ne sont jamais instantanées — un délai existe toujours.
Imaginons deux contrats : le contrat a sur la chaîne A et le contrat b sur la chaîne B, chacun ayant configuré l’autre comme adresse distante, et tous deux actifs (avec des NFT déjà frappés). Supposons maintenant que nous souhaitions remplacer le contrat a sur la chaîne A par un nouveau contrat c.
On pourrait simplement appeler setTrustedRemote sur la chaîne B pour pointer vers c. Mais cela poserait problème : les utilisateurs sur la chaîne A pourraient continuer à envoyer des NFT vers B, or puisque l’adresse distante sur B a changé, ces NFT seraient perdus à jamais. Le mode non-bloquant ne peut rien faire ici, car il ne s’active qu’une fois l’adresse distante correctement configurée.
Inversement, si on change d’abord l’adresse distante sur a, le résultat est similaire : les utilisateurs sur B pourraient envoyer des NFT à a avant que b ne soit configuré, ce qui entraînerait aussi une perte définitive, car a n’accepterait plus les messages de b.
Il faut comprendre que rien ne garantit que deux opérations sur des chaînes différentes se produisent simultanément. Peut-on alors jamais mettre à jour un contrat en cours d’utilisation ?
Il existe une solution : le mécanisme de configuration sécurisée des adresses distantes dans ERC721-O. Nous introduisons une fonction pauseMove prenant un paramètre chainId. Elle verrouille temporairement la fonction move vers cette chaîne. Le propriétaire peut ainsi attendre que les deux appels setRemote soient confirmés, puis déverrouiller via unpauseMove(chainId) pour restaurer les transferts.
Reprenons l’exemple : le propriétaire appelle pauseMove(A) sur B, empêchant les utilisateurs de B d’envoyer vers A, tandis que les utilisateurs de A peuvent encore envoyer vers B. Comme b accepte toujours les messages de a, aucun NFT n’est perdu. Ensuite, il appelle pauseMove(B) sur a et sur c. Il peut alors appeler setRemote dans n’importe quel ordre entre b et c. Enfin, il débloque tout avec unpauseMove, achevant ainsi le remplacement de a par c sur la chaîne A.
Ce design s’applique aussi à d’autres cas. Par exemple, quand un NFT actif sur A veut être déployé sur B, le propriétaire doit d’abord configurer l’adresse distante sur B, sinon les NFT risquent d’être bloqués. Avec pauseMove, il peut d’abord verrouiller les transferts, puis configurer les adresses sans craindre l’ordre des appels.
Ce modèle peut s’étendre à d’autres types de jetons comme ERC20, mais nous n’entrerons pas dans les détails ici.
Discussion
· Faut-il supprimer l’estimation du gaz sur la chaîne ?
La documentation officielle de LayerZero recommande une estimation du gaz sur la chaîne pour éviter les échecs de transaction sur la chaîne cible.
Mais en réalité, LayerZero effectue déjà cette vérification dans ses propres contrats déployés. De plus, dans le cas de multiples types de messages, même une estimation sur la chaîne ne garantit pas la justesse du calcul. En outre, même en cas d’erreur d’estimation, le contrat ERC721-O, grâce à son design non-bloquant, gère parfaitement la situation sans perte notable.
Par conséquent, imposer une estimation du gaz sur la chaîne semble inutile, et nous l’avons retirée de la version actuelle du protocole.
· Faut-il supprimer la fonction forceResumeReceive ?
La fonction forceResumeReceive peut entraîner des pertes de fonds. Toutefois, si un message erroné bloque le chemin et qu’aucune nouvelle tentative n’est possible, forceResumeReceive est le seul moyen de débloquer la situation. Notons que le design non-bloquant ne garantit pas à lui seul un chemin toujours ouvert. Pour éviter des blocages imprévus, nous la conservons dans l’implémentation actuelle. Vous pouvez uniquement la désactiver si votre contrat possède la propriété IFG (Instant Finality Guarantee) — c’est-à-dire que si une transaction est acceptée sur la chaîne source, elle le sera aussi sur la chaîne cible.
Le blocage nuit à l’expérience utilisateur et peut entraîner des pertes. Nous cherchons donc à le minimiser. Étant donné que l’ordre des transactions n’a pas d’importance dans les opérations NFT inter-chaînes, nous pouvons utiliser le mécanisme non-bloquant pour maintenir le chemin ouvert même après une erreur. Si votre contrat garantit une exécution correcte après vérification de l’adresse distante, vous pouvez supprimer cette partie.
ERC721-O reste un standard ouvert, nécessitant la contribution de la communauté. Nous croyons qu’avec l’apport collectif, ERC721-O deviendra le protocole standard des NFTs multi-chaînes.
Toutes les conclusions ci-dessus proviennent des documents et codes open source du laboratoire LayerZero, ainsi que d’expérimentations menées sur les nœuds officiels de LayerZero. Si vous repérez une erreur, merci de commenter ou d’ouvrir une issue sur GitHub. Merci d’avoir lu !
* Note : dans cet article, nous comparons ERC721-O à l’implémentation de Gh0stly Gh0sts et à l’exemple officiel de LayerZero.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
