Cross-chain NFT transfer

[librelois]

@mrshiposha

I propose using this repository for this purpose.

We can start with this repository to move forward quickly, but it would be nice to be able to move it in the future under an organization managed by the community, it can be the open-web3-stack organization or another one

@mrshiposha

using the pre-image pallet could be a recommendation (because it is a Substrate-way for storing data blobs and the free loading of the metadata requested by the target chain).

Yes, it’s perfectly fine to quote/recommend the pre-image pallet in any documentation/examples/tutorials around the NFTs transfer, I’m just saying that it shouldn’t be integrated in the formal specifications.

@mrshiposha

When we transferred the NFT from the Reserve Chain to another chain A, the Reserve Chain could safely remove all the metadata on its side (a user still can acquire the metadata for transferring via the Runtime API from the Reserve Chain’s previous blocks) because now chain A is the owner of the NFT and, as a sovereign entity, can do whatever it wants. The Reserve Chain doesn’t need to store or update the metadata on its side since chain A is now fully responsible for the NFT future story until the NFT is transferred to another chain.

This is not how the reserve based model works. Your description corresponds more to a teleportation between two networks that totally trust each other.
In the reserve-based model, the reserve chain is the only source of truth, and the only one on which the “real” asset is located. The other chains only mint/burn derivatives representations.

This is why in all cases the reserve chain must keep the NFT metadata and check that any modifications to it comply with the business rules of the NFT concerned (defined by the smart contract that handle this NFT or by the runtime itself through a pallet).
The fact that a remote chain becomes the owner of the asset (via its sovereign account), does not mean that it can modify the design or operation rules of this asset.
All these considerations are not specific to moonbeam, they are inherent to the “reserve based transfer” model.

@mrshiposha

why would the Reserve Chain impose rules on how the NFTs are modified on the derivative chains?

It does not impose any, the derived chain can modify what it wants on its own network, but if it wants its changes to be taken into account by the reserve chain (and therefore by any other chain that derive this NFT), it needs the agreement of the reserve chain.

@mrshiposha

The NFT could have a different standard (or the old one + some extension) on the target chain.

Yes, the NFT can have the old one + some extension, I agree. But a chain that has its own extension for NFTs metadata cannot force other chains to recognize this extension.
When the destination chain receives a message from the reserve chain, it trusts the reserve chain and considers as true everything the reserve chain sends. So the reserve chain can only send data that it has been able to verify itself.
If the destination chain wants to recognize an extension of the sending chain but this extension is not recognized by the reserve chain, then the 2 chains which are not reserve must define their own protocol to pass the data related to this extension.

Concerning Moonbeam in particular, it is possible to define some contract interfaces allowing to know if a smart contract supports such or such extension provided by such or such parachain/pallet or other, everything is possible, provided that it remains optional.

In the general case, a contract that only complies to ERC721 and nothing else does not allow to modify the metadata, so we must be able to handle this case.

I understand that this is frustrating, but it is necessary to preserve security and ensure that the rules defined by the designer of an NFT are respected.

We will do our best to support the NFT extensions you wish to provide, but we cannot force our users to accept these extensions in their smart contracts, especially since some ERC721 smart contracts are already deployed and not upgradeable.

The specifications for xc-NFTs must assume as little as possible if they are to be widely adopted, so they cannot assume support for this or that way of modifying metadata.

I think it is better for the user if the transfer fails as soon as possible in case of incompatibility, to avoid wasting time and money for nothing.

What the reserve chain can optionally do (but it doesn’t have to be mandatory) is to store a request for metadata modification while waiting for someone (basically any signed origin) to inject the whole new metadata, the reserve chain then checks if the state transition respects its rules, there are then 3 possible results:

1. The metadata change is accepted: the reserve chain then performs 3 distinct operations (the reserve chain must first check that enough fees have been paid for all these operations):

• forward the XCM message in the request to the destination chain (with a topic that contains the new metadata hash)
• send back an XCM message to the initial sender chain (to unlock and burn the derivative on the sender chain)
• Move the NFT ownership from the sovereign account of the sender chain to the sovereign account of the destination chain

2. The metadata change is not accepted: the reserve chain then perform one operation (the reserve chain must first check that enough fees have been paid for this operation):

• Send back an XCM message to the initial sender chain with the error, the initial sender chain can either unlock the NFT and cancel the transfer or still the NFT locked and rely on its governance or any other process to find a solution.

3. Not enough costs have been provisioned by the user who initially requested the transfer or/and the user who injected the new metadata on the reserve chain: the metadata injection action/extrinsic must fail with an error like “TooExpensive”.

With such a system, what we could do on the Moonbeam side when we receive an “xc-NFT XCM message”, is to ask to the contract that handle this NFT if it support an interface (to be defined) to mutate the metadata in the “xc-NFT way” (we can do that thanks to EIP165).
If this is the case, we store the request and follow the process I described above, but if it’s not the case, we must throw an error and interrupt the NFT transfer.

Obviously, the reserve chain should first verify that the new hash is not the same as the old one, if it’s the same, the reserve chain should forward the transfer directly.

This imply 3 user actions for transfer from a non-reserve chain to a non-reserve chain, but I think we can’t do better.

[librelois]

Just an first draft about what the XCM messages could look like (pseudo-code):

From reserve to non-reserve

Message send by the reserve chain to the non-reserve chain:

Xcm([
  ReserveAssetDeposited(feeAssetAndNft)
  ClearOrigin
  BuyExecution { fees: feeAsset, weight_limit }
  SetTopic(metadataHash)
  DepositAsset(assets: all, beneficiary)
])

From non-reserve to reserve (without metadata mutation)

Message send by the non-reserve chain to the reserve chain:

Xcm([
  WithdrawAsset(feeAssetAndNft)
  ClearOrigin
  BuyExecution { fees: feeAsset, weight_limit }
  SetAppendix([ReportError({ destination: sender, query_id, max_weight})])
  DepositAsset(assets: all, beneficiary)
])

From non-reserve to reserve (with metadata mutation)

Message send by the non-reserve chain to the reserve chain:

Xcm([
  WithdrawAsset(feeAssetAndNft)
  DescendOrigin(userAccountOnSenderChain)
  BuyExecution { fees: feeAsset, weight_limit }
  SetErrorHandler([ReportError({ destination: sender, query_id, max_weight})])
  DepositAsset(assets: all, beneficiary: origin)
  Transact(xnft.mutateThenDeposit(nftAsset, newMetadataHash, destAccount, response: { sender, query_id }))
])

The call xnft.mutateThenDeposit can either:

1. Accept the new metadata hash direcly and deposit the NFT on the destAccount, in that case the call should send to the sender chain the XCM message Xcm([QueryResponse { queryi_id, response: DispatchResult(Success), .. }]).
2. Create a pending request and lock the NFT, waiting for whole metatada injection.
3. Reject the new metadata hash direcly and throw an XCM error

In case of 2, a response will be send back to the sender chain only at metadata injection on the reserve or call to xnft.mutateRequestExpire (by any signed origin) after the expiration delay.

This allow to send back a response to the sender chain only when the mutate request is finally accepted or rejected.

From non-reserve to non-reserve

Message send by the non-reserve sender chain to the reserve chain:

Xcm([
  WithdrawAsset(feeAssetAndNft)
  DescendOrigin(userAccountOnSenderChain)
  BuyExecution { fees: feeAsset, weight_limit }
  SetErrorHandler([ReportError({ destination: sender, query_id, max_weight})])
  DepositAsset(assets: all, beneficiary: origin)
  Transact(xnft.mutateThenSend(
    nftAsset,
    newMetadataHash,
    dest,
    fees: Some((feeAsset, weight_limit)),
    response: { sender, query_id }
    xcm: Xcm([
      DepositAsset(assets: all, beneficiary)]))
    ]),
  )), 
])

The call xnft.mutateThenSend can either:

1. Accept the new metadata hash direcly and forward the inner xcm message to the destination, in that case the call should:

• prepend the inner message with 3 instructions ([WidrawAsset(feeAssetAndNft),ClearOrigin,SetTopic(newMetadataHash)]) and send it to the destination chain.
• send to the sender chain the XCM message Xcm([QueryResponse { queryi_id, response: DispatchResult(Success), .. }]).
• move the NFT ownership to the sovereign account of the dest chain.

2. Create a pending request and lock the NFT, waiting for whole metatada injection.
3. Reject the new metadata hash direcly and throw an XCM error

In case of 2, a response will be send back to the sender chain only at metadata injection on the reserve or call to xnft.mutateRequestExpire (by any signed origin) after the expiration delay.

This allow to send back a response to the sender chain only when the mutate request is finally accepted or rejected.

All the call names can obviously be changed, the relevant part is not about the names but the structure of the process.

It seem’s that we need at least 3 calls in the common pallet (and probably a 4th to just mutate metadata without any cross-chain transfer), that can be the existing “xtokens” pallet but I’m afraid that the xtokens pallet will become too heavy.
It seem’s better to me to create a new dedicated pallet because transferring NTFs need a lot of specific stuff to handle metadata that will pollute the xtokens pallet for project that don’t need to handle NFTs transfers through XCM.

[gavofyork]

@librelois

This is not how the reserve based model works. Your description corresponds more to a teleportation between two networks that totally trust each other.
In the reserve-based model, the reserve chain is the only source of truth, and the only one on which the “real” asset is located. The other chains only mint/burn derivatives representations.

This is why in all cases the reserve chain must keep the NFT metadata and check that any modifications to it comply with the business rules of the NFT concerned (defined by the smart contract that handle this NFT or by the runtime itself through a pallet).
The fact that a remote chain becomes the owner of the asset (via its sovereign account), does not mean that it can modify the design or operation rules of this asset.

Cannot agree enough with this reply. The whole premise of this conversation seems to be an exercise in broken understanding of the cross-chain trust model.

If A and B trust each other enough to allow each other to arbitrarily modify the meaning of common assets, then they don’t need a reserve - they should just pre-synchronise the metadata and teleport the asset. But would this trust model really extend to any other chain which would hold the asset too? Seems dangerous and unlikely. The fact that a reserve chain S is already specified suggests A and B don’t trust each other to respect ownership semantics. So why would they possibly trust each other to modify the meaning of the assets?! In this case, S should be the one to determine if a metadata-mutation is valid, and if so, store the ground-truth for metadata and provide a synchronisation service to allow these changes to be synced to A, B and any other chain which might want to know.

[librelois]

@gavofyork

In this case, S should be the one to determine if a metadata-mutation is valid, and if so, store the ground-truth for metadata and provide a synchronisation service to allow these changes to be synced to A, B and any other chain which might want to know.

Yes I totally agree with that, and it seems to me that this is what I have already explained with my own words