Bridge contracts to support non-fungible tokens (ERC721)

[akolotov]

The next phase of bridging assets between two blockchain network is to transfer non-fungible tokens (NFT). ERC721 could be used as the actual standard of NFTs.

There are few possible approaches to transfer NFTs between networks:

1. Mirroring: complete transfer of a token from one chain to another. In this case the token on one side of the bridge is locked for all operations (token data and token ownership cannot be changed) and a mirrored token is created on another side.
2. Splitting: different operations are split between two blockchains. For example, changing ownership could be possible in one chain (e.g. to trade the token) whereas changing of token data (e.g. assets properties) could be done in another chain.

Depending on the approach bridge contracts could be different. So, under this issue is being suggested to choose and discuss particular approach (or suggest a new one) and implement bridge and token contracts as per chosen way.

As soon as the contracts are developed another issue for off-chain part of bridge (https://github.com/poanetwork/poa-bridge or https://github.com/poanetwork/bridge-nodejs/) to introduce corresponding logic should be created.

[6proof]

   Stateful Binary Bridge Mirroring - a Protocol Definition for Practical ERC721 Bridging

The mirroring method described by @akolotov at #46 to bridge an ERC721 non-fungible token (NFT) allows owners to maximize utility and safely harbor assets on one of two blockchain networks. With additional definition, this can extend to harboring assets on one of two or more blockchain networks, and become the standard vehicle for NFT liquidity. This document discusses and documents the protocol for its deployment. Following is a modified version of Alexander's definition of Mirroring, defined as Stateful Binary Bridge Mirroring:

Stateful Binary Bridge Mirroring is the complete transition of a token from one chain to another through State Transformation. The token on one side of a Binary Bridge ( a bridge with exactly two end-points) is locked for all operations (token data and token ownership cannot be changed) and a mirrored or identical token is created (minted) on the chain at the opposite side of that binary bridge. The situation is repeated if the token is bridged to any new blockchain other than the blockchain of origin, meaning the token is always locked for all operation on the egress blockchain and a new, identical or mirrored token is created (minted) on the ingress blockchain, allowing the Token to travel freely between blockchains as its owner may desire. Visually:

     Blockchain of Origination:
    Left side (Egress) of Binary Bridge <--------->  (Ingress) Right side of Binary Bridge
                 ^                                                                    |
                 |  (Line below Represents 1 to infinite progression of blockchains)  |
Right side (Ingress) of Binary Bridge <-..........-> (Egress) Left side of Binary Bridge

When a token is sent from any blockchain to a blockchain of origin (a blockchain with a locked or "frozen" instance of the token in play) the token shall be burned (destroyed) on the Egress blockchain and "revived" (unlocked) on the Ingress blockchain, where it will inherit any state differences from the token in play.

In this manner, An ERC721 token (or any token using the Stateful Binary Bridge protocol) must exist on exactly one blockchain, can exist in a frozen state on all ERC721 compliant blockchains other than the blockchain carrying the Stateful (active) token, and has potential to exist on all chains not currently home to the Stateful token or a frozen instance of the token. Any Ingress blockchain carrying a frozen instance of a token is indistinguishable from and therefore considered to be the blockchain of origin.

The Stateful Binary Bridge protocol requires the Ingress blockchain to signal the Egress blockchain as to the state of the Token in play on its blockchain. There are exactly two potentially valid responses: Origin - a frozen instance of the token in play exists on the Egress blockchain, represented as "0" - or Ready - the potential exists to carry the token in play, represented as "1." The response signals the Egress blockchain upon successful crossing to either burn the on-chain token in play or else freeze the token until such time where it is activated as an Ingress blockchain with the identical token in play. Once burned, an instance of that token no longer exists on the Egress blockchain and it again has potential to carry that token, like all compatible blockchains.

Stateful Binary Mirroring is a Protocol Definition for Practical ERC721 Bridging, may be implemented as an ERC721 specific or broad-protocol bridge, and can fill a significant demand in the Ethereum ecosystem.

Jim O'Regan, posted to #46 June 25, 2018

[akolotov]

Here is draft of NFT POA Bridge proposals:

Thesis:

1. There is a contract in an EVM-based blockchain (e.g. POA Network) which provide ability to create a non-fungible token (NFT) and change its attributes.
2. There is a neccesity to transfer NFTs from one blockchain (Home) to another (Foreign).
3. "Transfer" means that the token is locked (not available for further operations) in one chain (Home, left side of the bridge) and created in another chain (Foreign, right side of the bridge).
4. When the token is being transfered, the particular token ownership and all its metadata (changable attributes linked with the token) are being completely copied to new token in Foreign network.
5. The token can be withdrawn from the chain on right side of the bridge to the chain on left side of the bridge.
6. "Withdrawal" means that the token is demolished in Foreign network and unlocked in Home network.
7. When the token is being withdrawn, the token ownership and all its metadata are being completely copied to existing token in Home network as so previous ownership and metadata are being replaced.

Scenario #1: transfer NFT from Home to Foreign

1. A user calls safeTransferFrom from the token contract. Reciever of the token is the bridge contract on Home side.
2. safeTransferFrom invokes onERC721Received of the bridge contract on Home side.
3. The bridge contract asks the token contract to serialize the metadata of the token and uses these serialized data in UserRequestForSignature event.
4. The bridge catches UserRequestForSignature event and initiates procedure to sign the user request to transfer data.
5. As soon as enough signatures are collected in the bridge contract, it emits CollectedSignatures event which contains serialized data related to transfered token.
6. The bridge catches CollectedSignatures event and call executeSignatures of the bridge contract on Foreign side.
7. The bridge contract invokes a method of the token contract to create token and passes serialized data to this method.
8. The token contract creates token with the same metadata.
9. The bridge contract transfers new token to the account with the same address which originates the transaction on the step refactoring of the bridge logic to work with authorities #1.

Scenario #2: withdraw NFT from Foreign to Home

1. A user calls safeTransferFrom from the token contract on Foreign side. Reciever of the token is the bridge contract on Foreign side.
2. safeTransferFrom invokes onERC721Received of the bridge contract on Home side.
3. The bridge contract requests the token contract to serialize the metadata of the token and uses these serialized data in UserRequestForAffirmation event.
4. The bridge contract requests the token contract to burn the token.
5. The bridge catches UserRequestForAffirmation event and invokes executeAffirmation of the bridge contract on Home side.
6. As soon as enough requests to execute the affirmation are collected in the bridge contract, it requests the token contract to replace metadata of corresponding token by the serialized data received in executeAffirmation call.
7. The bridge contract transfers the token to the account with the same address which originates the transaction on the step refactoring of the bridge logic to work with authorities #1.

[marekkirejczyk]

Is there any progress on this? We would love to use it.

[akolotov]

Hi @marekkirejczyk! Thanks for interesting in the feature. The main idea was to implement Arbitrary Message Bridging (#73) first as so the NFT bridging feature could be implemented with usage of this technology. The AMB was started implementing (#77) but was postponed a bit due to other HP activities.

[patitonar]

ERC721-to-ERC721 on top of AMB

We will have an ERC721 on the Foreign network that will be bridged to the Home network using AMB. The approach to interact with AMB bridge will be similar to how ERC677-to-ERC677 works #267

Every ERC721 will have its unique way to define their metadata attached to the tokens id, so the implementation of the contracts should be generic leaving only some methods related to getting/setting the serialization of the metadata to be defined for the desired ERC721 that wants to be bridged.

For our implementation, we can define an ERC721 that extends this OpenZeppelin implementation. We can use the method tokenURI to get the metadata of the token and define a method that allows only the owner of the token to internally call _setTokenURI to update the metadata of the token. Also we will need a method to Mint the token with the specified id and metadata similar to:

function mintWithTokenURI(address to, uint256 tokenId, string memory tokenURI) public onlyOwner returns (bool) {
        _mint(to, tokenId);
        _setTokenURI(tokenId, tokenURI);
        return true;
    }

Transfer from Foreign to Home

1. A user calls safeTransferFrom from the token contract. Receiver of the token is the token management contract.
2. The token is transferred and the token contract calls onERC721Received method of the token management contract.
3. In onERC721Received method, the token management contract calls the token contract method tokenURI to get the metadata of the token. Then the token management contract calls requireToPassMessage method of Foreign AMB bridge contract with parameters indicating that method handleBridgedToken of the Home token management contract should be called with the recipient, token id and metadata parameters.
4. Then on Home side, Home AMB bridge will call handleBridgedToken method of the Home Token Management contract which will mint the token to the user with the same id and metadata.

Transfer from Home to Foreign

The opposite direction works similar but the Token Manager on the Home side burns the token and the Foreign Token Manager will call setTokenURI to update the metadata of the existing token with the one provided from the Home side and then safeTransferFrom to transfer the token to the user.

[akolotov]

We are preparing the reference implementation of NFT bridge as part of the demo to transfer CryptoKitties tokens. The issue will be closed as soon as the demo is performed.

[akolotov]

The functionality to transfer NFTs between chains was successfully tested and documented. The issue is being closed.