Vitalik: Migrating NFTs to Layer 2 – How Can We Enable Friendly Cross-Rollup Interoperability?
TechFlow Selected TechFlow Selected
Vitalik: Migrating NFTs to Layer 2 – How Can We Enable Friendly Cross-Rollup Interoperability?
We need to transfer NFTs to Layer 2 (L2) ecosystems to reduce fees. However, doing this properly requires robust cross-Rollup portability standards, enabling ecosystems to avoid being locked into a specific L2.
Navigating Web3 tides with focused insightsAuthor: Vitalik Buterin
Translation: Kyle,巴比特
The NFT ecosystem is rapidly evolving and has become a significant contributor to gas consumption on the Ethereum chain. The youthfulness and relative lack of established foundations in the NFT ecosystem, combined with the fact that much of NFT usage is non-financial and thus more sensitive to high fees, make NFTs a prime candidate for migration to Layer 2 (L2) networks. However, this raises the question of how to migrate NFTs to L2.
A simple proposal would be to coordinate within the community to move NFTs to a single Rollup platform (e.g., Arbitrum, as it's currently available for general contract deployment), but this approach has several important drawbacks:
- All major existing EVM-compatible rollup platforms have backdoors, centralized sequencing, or other experimental features. Entrusting the entire ecosystem to a single rollup carries risk, and there is uncertainty about how these rollups will evolve beyond such features.
- The NFT ecosystem could grow so large that a single rollup may not securely handle all transactions.
- No part of the NFT ecosystem—or even the entire ecosystem—is a closed world; it will need interoperability with other parts of the Ethereum ecosystem.
This article proposes an approach to make NFTs cross-rollup compatible, enabling NFTs to move across the broader Layer 2 ecosystem.
Proposed Solution 1
NFTs are first registered on one rollup (or the base chain). They can then "hop" between other rollups (or the base chain) via a wrapping mechanism.
The wrapping process works as follows:
1. On Rollup A, send the NFT (call it X) to a wrapper manager contract, specifying (i) the destination rollup and (ii) the initial owner. The wrapper contract stores a record, assigning a new serial number R to X, and records the destination rollup (call it B) and the initial owner on that rollup (call this account O1).
2. On Rollup B, anyone can use the wrapper manager contract to create a wrapped NFT. Creating a wrapped NFT requires specifying the source rollup and serial number. Only the designated owner can create a "valid" wrapped version of X by claiming (R, A) as the serial number and source rollup. Note that invalid wrapped NFTs with no backing can be created; Rollup B does not know what is valid or invalid. The wrapper manager contract stores tuples of (serial number, source rollup, initial owner) and prevents multiple NFTs from being created using the same tuple.
3. To withdraw the NFT from wrapping, the current owner of wrapped-X on Rollup B must send it back to the wrapper manager, which then issues a receipt stating: "The NFT with serial number R, source rollup A, and initial owner O1 has just exited wrapping, with desired new owner O2."
4. The wrapper contract can then release X to O2 upon receiving proof of the receipt from Rollup B, checking the serial number, source rollup, and initial owner against its stored data and validating it accordingly.
Note that withdrawals will involve a time delay, as Optimistic Rollup state roots require approximately one week to finalize before receipts can be verified. Currently, the only way to enable faster multi-hop transfers is through multiple layers of wrapping.
For users to verify that wrapped-X is legitimate, they must personally verify the state on Rollup B and the receipt on Rollup A.
Extension: Adding Cross-Rollup Transfers
On Rollup B, the owner of wrapped-X can send it to the wrapper manager with instructions to issue a different kind of receipt: "The NFT with serial number R, source rollup A, and initial owner O1 has just moved to Rollup C, with desired new owner O2."
On Rollup C, anyone can create a wrapped-X object by specifying the original source rollup (Rollup A in this example), serial number, and initial owner, and this wrapped-X on Rollup C can be freely traded. However, to enable withdrawal of wrapped-X, the receipt from Rollup B must eventually be sent to Rollup A.
What actually happens is that when an NFT moves from one rollup to another, a chain of receipts is left behind, each mirrored onto Rollup A and processed sequentially at some point. In the future, once states on other rollups are finalized (this could be space-optimized in the short term using Kate commitments, and long-term via ZK-SNARK proofs of the entire receipt chain).
For users to verify that a wrapped X is legitimate, they need to validate the full chain of receipts across all relevant rollups (or at least, the portion of the receipt chain since the last one was mirrored to Rollup A).
Additionally, note that the protocol can be simplified: a "withdrawal" is just a cross-rollup transfer to Rollup A, and if the wrapper contract on Rollup A recognizes that a particular serial number issued by Rollup A is now back on Rollup A, it can directly redeem the wrapped token.
Extension 2: Gas-Efficient Issuance on the Base Chain
All NFTs can be issued in such a way that they are initially "owned" by the wrapper contract on the Ethereum base chain. To make this gas-efficient, the wrapper contract gains the ability to generate entire batches of serial numbers and transfer them to rollups. Effectively, all NFTs are pre-created but none yet assigned any "meaning" (think: 2**256 undifferentiated "stem cell" NFTs), and they are batch-transferred to rollups.
The "issuance" process now becomes one of assigning meaning. This can be done by passing a "meaning hash" in the receipt, just like passing ownership: if an NFT has no meaning (it's a "stem cell"), the owner can assign it a meaning, turning it into a "differentiated" NFT. The base chain only learns of the NFT’s meaning after verifying the receipt chain—until meaning is assigned (in practice, receipt validation must use ZK-SNARKs to be feasible).
This allows all NFTs to be "rooted" in the base chain rather than in a rollup. This is useful for handling rollup failures or cases where rollups otherwise become infeasible, and for applications requiring permanent migration to other domains.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@VitalikButerin
