The NFT ecosystem is growing rapidly and constitutes an important part of the gas consumption on the Ethereum chain. The NFT ecosystem is still young and relatively lacking in foundation, and since a large part of the NFT field is non-financial, it is more necessary to avoid high fees, which makes moving to layer 2 the main goal. However, this raises the question of how to transfer to layer 2.
A simple proposal is to transfer to a specific rollup platform through social coordination (for example, Arbitrum, because it already supports general smart contract deployment), but this has several disadvantages:
- All major rollup platforms that currently support EVM have backdoors, centralized sequencing or other auxiliary measures. It is risky to transfer the entire ecosystem to a single rollup, and there is still uncertainty about how rollup will upgrade these functions;
- The NFT ecosystem may eventually grow to a volume that a single rollup cannot safely carry;
- No part of the NFT ecosystem, or even the entire NFT ecosystem, is closed; they will need to interoperate with other parts of the Ethereum ecosystem
This article proposes a proposal to make NFT-friendly cross-rollup and make it migrate to the entire layer 2 ecosystem.
Proposed solution one
NFT can be initially registered in a single rollup, and then transferred between different rollups (or underlying chains) by creating a wrapper NFT (encapsulated NFT).
The NFT wrapping process is as follows:
- On Rollup A, send the NFT (set to X) to the wrapper manager contract, specifying (i) the target Rollup and (ii) the initial owner. The lockbox contract stores a record, assigns a new serial number R to X, and saves the target Rollup (set to B) and the initial owner of the target Rollup (set to 01).
- On Rollup B, anyone can use the package manager contract on Rollup B to create a wrapper NFT. To create a wrapper NFT, you need to specify the source Rollup and serial number. To create a “valid” wrapper NFT of X, it can only be done by the designated owner and by declaring (R, A) as the serial number and source rollup. Note that it is possible to create an invalid wrapper NFT pointing to no content, and Rollup B cannot distinguish between valid and invalid. The package manager contract stores (serial number, source Rollup, initial owner) value groups and prevents the use of the same value group to create multiple wrapper NFTs.
- To propose an NFT from the lockbox, the current owner of the wrapped-X on Rollup B must send it back to the packaging manager, who issues a receipt stating that “The NFT with serial number R, source rollup A, and initial owner 01 has been Decapsulation, and potential new owner 02”.
- The lockbox contract can pass the NFT X to 02 after receiving the proof of the receipt on rollup B, and check the serial number, source Rollup and initial owner based on the stored information, and verify the transfer of NFT.
Please note that there is a time delay in extracting the NFT because the state root of the Optimistic Rollup solution needs about a week of delay to be finalized in order to verify the receipt. So far, the only way to do multi-hop faster is to do multi-layer packaging.
To verify whether the wrapped X is legal, the user needs to verify the status on Rollup B and the receipt on Rollup A.
Expansion: Increase cross-rollup transfer
On rollup B, the owner of the wrapped-X can send it to the package manager and attach an instruction to issue a different receipt “The NFT with serial number R, source Rollup A, and initial owner 01 has just been transferred to Rollup C, and potential new owner 02”.
On Rollup C, anyone can make a wrapped-X object by specifying the original source Rollup (Rollup A in the current example), serial number, and initial owner, and this wrapped-X on Rollup C can be freely traded . But once so, it is proposed that wrapped-X needs to publish all the receipts (2 in the current example) generated by the cross-rollup transfer.
Please note that for the sake of simplicity, the “withdrawal” itself is no longer a cross-rollup operation, but is done through a cross-rollup. Create a wrapped-X (the same rollup of X) on rollup A, and then perform a separate unwrapping ( Unpack) operation.
In fact, when NFT is transferred from one rollup to another rollup, the chain on the transfer path will generate a series of receipts. Each receipt in the chain of receipts is mirrored to rollup A, and in the future, when the status of other rollups When the root is finalized, these receipts will be processed in order at a certain point in time (in the short term, Kate promises to optimize the space, and in the long term, the entire receipt chain can be proven through ZK-SNARK).
To verify the authenticity of wrapped X, users need to verify that all path rollups reflect the entire receipt chain transferred across rollups (or at least the receipt chain that has been mirrored to rollup A after the previous receipt).
Extension 2: Optimize the issuance of gas on the underlying chain
All NFTs can be issued in this way: “owned” by the encryption box on the underlying Ethereum chain. In order to optimize the efficiency of gas, the lockbox contract will have the function of generating a set of serial numbers and transmitting them to rollup. In fact, all NFTs are pre-created, but no “meaning” has been assigned to any of them (it can be imagined as having 2*256 undifferentiated “stem cell” NFTs), and they are transferred to rollup in batches.
The “distribution” process has now become a process of distributing meaning. This can be done by passing a “meaning hash” in the receipt, in the same form as the owner passed: if the NFT has no meaning (it is a “stem cell”), the owner can assign a meaning to it, making it a ” Differential” NFT. The underlying chain only knows the meaning of NFT after verifying the receipt chain, until the meaning is assigned (in fact, receipt verification must be ZK-SNARK to be feasible).
This allows all NFTs to be “rooted” in the underlying chain instead of rollup. This is helpful for handling rollup failures, unavailability for other reasons, or applications that need to be permanently migrated to other domains.