header-langage
简体中文
繁體中文
English
Tiếng Việt
Scan to Download the APP
Partnered With:

Vitalik Buterin: How do I migrate NFT to Layer 2 and have them friendly across Rollup?

Read this article in 10 Minutes
God V proposes a cross-rollup friendly proposal that allows NFT to migrate to the entire Layer 2 ecosystem.
Cross-rollup NFT Wrapper and Migration Ideas
Vitalik Buterin
Kyle, the Way of DeFi


We need to move NFT to layer 2 (L2) ecosystems to reduce costs. However, doing this correctly requires good cross-rollup portability standards so that ecosystems can avoid being locked into a particular L2.

- Vitalik Buterin



The NFT ecosystem is growing rapidly and has become an important part of gas consumption in the Ethereum chain. The youth and relative lack of roots of the NFT ecosystem, as well as the greater need to avoid high fees due to the non-financial nature of a large part of NFT, also make NFT a prime target for moving to Layer2 networks. However, this raises the question of how to migrate NFT to Layer2.


A simple proposal would be to coordinate the migration of NFT to a single Rollup platform within the community (e.g., Arbitrum, since it is currently available for general contract deployment), but this has some important drawbacks:


All existing major Rollup platforms that support EVM have backdoors, centralized sorting, or other experimental features, leaving the entire ecosystem to a single Rollup is risky, and there is uncertainty about how Rollup will outperform these features.

The NFT ecosystem can become too large for a single Rollup to handle safely

No part of the NFT ecosystem, or even the entire NFT ecosystem, is a closed world; They will need to interoperate with the rest of the Ethereum ecosystem.


This article presents a proposal on how to make NFT Rollup friendly across the Rollup, allowing NFT to move across the entire Layer2 ecosystem.



Proposed solution 1


The NFT will first be registered in a Rollup (or base chain). By creating a encapsulated NFT, the NFT can jump between other rollups (or base chains).


The process for encapsulating NFT is as follows:


1. On Rollup A, send the NFT (which we call X) to the Wrapper manager contract, specifying (I) the destination Rollup and (ii) the initial owner. The password box contract keeps a record in the store, assigns X a new serial number R, and saves the target Rollup (we call it B) and the original owner of the target Rollup (we call this account O1)


2. On Rollup B, anyone can create a wrapper NFT using the wrapper manager contract on Rollup B. Creating a encapsulated NFT requires specifying the source Rollup and sequence number. Creating A "valid" wrapper NFT of X can only be done by the specified owner and by declaration (R, A) as serial number and source Rollup. Note that it is possible to create an invalid wrapper NFT with no pointing content; Rollup B does not know what is valid and invalid. The wrapper manager contract stores tuples (serial numbers, source Rollup, initial owner) and prevents multiple NFTS from being created using the same tuple.


3. To extract the NFT from the cipher box, the current owner of wrapper -x on Rollup B must send it back to the wrapper manager, which issues A receipt stating that "NFT with serial number R, source summary A, and original owner O1 just touched the wrapper with desired new owner O2".


4. The password box contract can hand X to O2 upon receipt of proof of the receipt on summary B, and check the serial number, source Rollup, and original owner against its own stored information, and verify that it passes.




Please note that there is a time delay for withdrawals, as Optimistic Rollup status roots require a delay of approximately 1 week to be finalized in order to validate receipts. Until now, the only way to do multiple hops faster was to do multiple layers of encapsulation.


In order for users to verify that wrap-x is valid, they need to validate the state on Rollup B and the receipt on Rollup A themselves.



Extension: Add transports across Rollup


On summary B, the owner of Wrapped -X can send it to the wrapper manager with instructions to issue A different receipt: "NFT with serial number R, source Rollup A and original owner O1 has just moved to Rollup C, with desired new owner O2".


On Rollup C, anyone can make A wrap-X object by specifying the original source Rollup (in this case Rollup A), serial number, and initial owner, and this wrap-x on Rollup C can be freely traded. However, in order to be able to undo the wrapper -x, the receipt for Rollup B needs to be sent to Rollup A.


What actually happens is that as the NFT moves from one Rollup to another, the transfer chain leaves behind A chain of receipts, each receipt in which is mirrored to Rollup A and processed sequentially at some point in time. In the future, when the status of other rollups is finalized (this can be spatially optimized in the short term by Kate's promise, and in the long term by zK-SNark proof of the entire receipt chain).


In order for the user to verify that the encapsulated X is valid, they need to validate the entire receipt chain on all rollups that reflect transfers across Rollup (or at least, one that has mirrored to Rollup since the last receipt).


Also note that the protocol can be simplified: the "withdrawal" is just A cross-rollup transfer Rollup A, and the encapsulated contract can be directly exchanged if it is recognized that the particular serial number published by Rollup A is now on Rollup A.



Extension 2: Optimized gas distribution on the base chain


All NFTS can be distributed in such a way that they are "owned" by a cryptobox contract on the underlying Ethereum chain. To make this gas efficient, the cipher box contract will get the ability to generate a set of serial numbers and transfer them to Rollup. Virtually all NFTS are pre-created, but have not yet been assigned to any of them "meaningfully" (think: there are 2**256 undifferentiated "stem cell" NFTS), and they are transferred in bulk to Rollup.


The process of "publishing" is now the process of making meaning. This can be done by passing a "meaning hash" in the receipt in the same way as passing ownership: if the NFT has no meaning (it's a "stem cell"), the owner can assign a meaning to it, turning it into a "differentiated" NFT. The base chain does not know the meaning of NFT until it validates the receipt chain, until the meaning is assigned (in fact, receipt validation must be ZK-SNARK for it to work).


This allows all NFTS to "root" in the base chain rather than Rollup. This is useful for dealing with situations where Rollup breaks or otherwise becomes infeasible and applications need to be permanently migrated to other domains.


The original link


Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia

举报 Correction/Report
Choose Library
Add Library
Cancel
Finish
Add Library
Visible to myself only
Public
Save
Correction/Report
Submit