Vitalik : Comment rendre les NFT compatibles entre les rollups lors de leur migration vers la couche 2 ?
TechFlow SélectionTechFlow Sélection
Vitalik : Comment rendre les NFT compatibles entre les rollups lors de leur migration vers la couche 2 ?
Nous devons transférer les NFT vers l'écosystème de la couche 2 (L2) afin de réduire les frais. Toutefois, pour y parvenir correctement, il est nécessaire d’établir des normes solides de portabilité inter-Rollup, permettant ainsi à l’écosystème d’éviter d’être verrouillé sur une L2 spécifique.
Dédié à des analyses Web3 approfondiesAuteur : Vitalik Buterin
Traduction : Kai'er,巴比特
L'écosystème des NFT évolue rapidement et représente désormais une part importante de la consommation de gaz sur Ethereum. La jeunesse de cet écosystème et son manque relatif de stabilité, combinés au fait que beaucoup de NFT ont une nature non financière et nécessitent donc d’éviter des frais élevés, font des NFT un candidat idéal pour migrer vers la couche 2 (Layer 2). Toutefois, cela soulève la question de la manière de transférer les NFT vers la Layer 2.
Une proposition simple serait de coordonner collectivement le transfert des NFT vers une seule plateforme Rollup (par exemple Arbitrum, qui permet actuellement le déploiement général de contrats), mais cette approche présente plusieurs inconvénients majeurs :
- Toutes les principales plateformes Rollup compatibles EVM comportent actuellement des portes dérobées, un ordonnancement centralisé ou d'autres fonctionnalités expérimentales. Confier l'ensemble de l'écosystème à un seul Rollup comporte des risques, et l'évolution future du Rollup au-delà de ces fonctionnalités reste incertaine.
- L'écosystème NFT pourrait devenir trop vaste pour qu'un seul Rollup puisse traiter toutes les transactions en toute sécurité.
- Aucune partie de l'écosystème NFT, pas même l'ensemble de celui-ci, ne forme un monde fermé ; il devra interagir avec d'autres composants de l'écosystème Ethereum.
Cet article propose une solution permettant aux NFT d'être inter-opérables entre différents Rollups, ce qui autorise leur migration dans tout l'écosystème de la Layer 2.
Proposition de solution 1
Les NFT seraient d’abord enregistrés sur un Rollup (ou sur la chaîne principale). Un NFT peut alors être transféré entre différents Rollups (ou la chaîne principale) via un processus d’emballage ("wrapping").
Le processus d'emballage est le suivant :
1. Sur le Rollup A, on envoie le NFT (appelons-le X) au contrat gestionnaire d'emballage, en précisant (i) le Rollup de destination et (ii) le propriétaire initial. Le contrat gestionnaire enregistre dans son stockage une entrée attribuant au NFT X un nouveau numéro de série R, ainsi que le Rollup de destination (appelons-le B) et le propriétaire initial sur ce Rollup (appelons ce compte O1).
2. Sur le Rollup B, n'importe qui peut créer un NFT emballé via le contrat gestionnaire d'emballage local. Pour créer un NFT emballé, il faut spécifier le Rollup source et le numéro de série. Seul le propriétaire désigné peut créer un NFT emballé « valide » correspondant à X, en déclarant (R, A) comme numéro de série et Rollup source. Notez qu'il est possible de créer un NFT emballé invalide sans lien vers un contenu réel ; le Rollup B ne peut pas distinguer ce qui est valide ou non. Le contrat gestionnaire enregistre les tuples (numéro de série, Rollup source, propriétaire initial) et empêche la création de plusieurs NFT à partir du même tuple.
3. Pour retirer le NFT de l'emballage, le propriétaire actuel du NFT emballé-X sur le Rollup B doit le renvoyer au contrat gestionnaire, qui génère alors un reçu indiquant : « Le NFT de numéro de série R, dont le Rollup source est A et le propriétaire initial O1, vient d'être retiré de l'emballage, avec comme nouveau propriétaire souhaité O2 ».
4. Le contrat gestionnaire peut alors remettre X à O2 dès lors qu’il reçoit une preuve de ce reçu émis sur le Rollup B, vérifie via ses propres données stockées le numéro de série, le Rollup source et le propriétaire initial, et confirme la validité.
Notez qu’un délai intervient lors du retrait, car les racines d’état des Rollups optimistes nécessitent environ une semaine pour finaliser la validation du reçu. À ce jour, la seule façon d’accélérer les sauts multiples est d’utiliser un emballage multi-niveaux.
Pour que les utilisateurs puissent vérifier qu’un wrapped-X est légitime, ils doivent eux-mêmes vérifier l’état du Rollup B et le reçu sur le Rollup A.
Extension : ajout du transfert inter-Rollup
Sur le Rollup B, le propriétaire du wrapped-X peut l’envoyer au gestionnaire d’emballage accompagné d’une instruction générant un reçu différent : « Le NFT de numéro de série R, dont le Rollup source est A et le propriétaire initial O1, vient d’être transféré au Rollup C, avec comme nouveau propriétaire souhaité O2 ».
Sur le Rollup C, n’importe qui peut créer un objet wrapped-X en spécifiant le Rollup source initial (dans cet exemple, le Rollup A), le numéro de série et le propriétaire initial, et ce wrapped-X peut ensuite être librement échangé sur le Rollup C. Toutefois, pour pouvoir retirer le wrapped-X, il faudra transmettre le reçu du Rollup B au Rollup A.
Ce qui se produit en réalité est que chaque fois qu’un NFT passe d’un Rollup à un autre, une chaîne de reçus est créée. Chaque reçu est reflété (« mirroré ») sur le Rollup A et traité séquentiellement à un moment donné. À l’avenir, lorsque l’état des autres Rollups sera finalisé (ce qui peut être optimisé spatialement à court terme via des engagements de Kate, et à long terme via des preuves ZK-SNARK de toute la chaîne de reçus).
Pour que les utilisateurs puissent vérifier qu’un wrapped-X est légitime, ils doivent valider toute la chaîne de reçus sur tous les Rollups concernés par les transferts inter-Rollup (ou du moins, la chaîne de reçus depuis le dernier reçu déjà reflété sur un Rollup).
En outre, notons que ce protocole peut être simplifié : un « retrait » n’est qu’un transfert inter-Rollup vers le Rollup A. Si le contrat d’emballage sur le Rollup A détecte qu’un numéro de série spécifique est maintenant disponible sur le Rollup A, il peut directement délivrer le NFT natif.
Extension 2 : Émission optimisée en gaz sur la chaîne principale
Tous les NFT peuvent être émis de telle sorte qu’ils soient « possédés » initialement par le contrat gestionnaire d’emballage sur la chaîne principale Ethereum. Pour rendre ce processus efficace en termes de gaz, le contrat gestionnaire disposera de la capacité de générer un ensemble complet de numéros de série et de les transférer vers un Rollup. En pratique, tous les NFT sont pré-créés, mais aucun n’a encore reçu de « signification » (imaginez : 2**256 NFT « cellules souches » non différenciés), et ils sont transférés en masse vers un Rollup.
Le processus d’« émission » devient alors un processus d’attribution de sens. Cela peut se faire en passant un « hachage de signification » dans le reçu, de la même manière que l’on transmet le propriétaire : si un NFT n’a pas de signification (il est une « cellule souche »), son propriétaire peut lui attribuer une signification, le transformant ainsi en un NFT « différencié ». La chaîne principale ne connaît la signification du NFT qu’après avoir validé la chaîne de reçus, jusqu’à l’attribution de signification (en pratique, la validation des reçus doit utiliser des ZK-SNARK pour être viable).
Cela permet à tous les NFT d’être « ancrés » dans la chaîne principale plutôt que dans un Rollup. Cela s’avère utile en cas de panne d’un Rollup ou s’il devient autrement inutilisable, ainsi que pour les applications nécessitant un transfert permanent vers un autre domaine.
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
@VitalikButerin
