This ERC standardizes an interface for contract-layer consensus-agnostic verifiable cross-chain bridging, through which we can define a new global token inherited from ERC-20/ERC-721 over multi-chains.

With this ERC, we can create a global token protocol, that leverages smart contracts or similar mechanisms on existing blockchains to record the token states synchronously. The synchronization could be made by trustless off-chain synchronizers.
The core of this ERC is synchronization instead of transferring, even if all the other chains break down, as long as Ethereum is still running, user’s assets will not be lost.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
There SHOULD be a global user identifier of this ERC, which is RECOMMENDED to be referred to as Omniverse Account (o-account for short) in this article.
The o-account is RECOMMENDED to be expressed as a public key created by the elliptic curve secp256k1. A mapping mechanism is RECOMMENDED for different environments.
An Omniverse Transaction (o-transaction for short) MUST be described with the following data structure:
The data structure ERC6358TransactionData MUST be defined as above.
The member nonce MUST be defined as uint128 due to better compatibility for more tech stacks of blockchains.
The member chainId MUST be defined as uint32.
The member initiateSC MUST be defined as bytes.
The member from MUST be defined as bytes.
The member payload MUST be defined as bytes. It is encoded from a user-defined data related to the o-transaction. For example:
For fungible tokens it is RECOMMENDED as follows:
signature in o-transaction is RECOMMENDED to be the concatenation of the raw bytes of op, exData, and amount.For non-fungible tokens it is RECOMMENDED as follows:
signature in o-transaction is RECOMMENDED to be the concatenation of the raw bytes of op, exData, and tokenId.The member signature MUST be defined as bytes. It is RECOMMENDED to be created as follows.
It is OPTIONAL that concating the sectors in ERC6358TransactionData as below (take Fungible token for example) and calculate the hash with keccak256:
It is OPTIONAL that encapsulating the sectors in ERC6358TransactionData according to EIP-712.
Sign the hash value.
Every ERC-6358 compliant contract MUST implement the IERC6358
sendOmniverseTransaction function MAY be implemented as public or externalgetTransactionCount function MAY be implemented as public or externalgetTransactionData function MAY be implemented as public or externalgetChainId function MAY be implemented as pure or viewTransactionSent event MUST be emitted when sendOmniverseTransaction function is calledOptional Extension: Fungible Token
omniverseBalanceOf function MAY be implemented as public or externalOptional Extension: NonFungible Token
omniverseBalanceOf function MAY be implemented as public or externalomniverseOwnerOf function MAY be implemented as public or externalAs shown in Figure.1, smart contracts deployed on multi-chains execute o-transactions of ERC-6358 tokens synchronously through the trustless off-chain synchronizers.
o-transactions from the ERC-6358 smart contracts on one blockchain to the others. The synchronizers work trustless as they just deliver o-transactions with others' signatures, and details could be found in the workflow.The o-account has been mentioned above.
The synchronization of the o-transactions guarantees the ultimate consistency of token states across all chains. The related data structure is here.
nonce mechanism is brought in to make the states consistent globally.nonce appears in two places, the one is nonce in o-transaction data structure, and the other is account nonce maintained by on-chain ERC-6358 smart contracts.nonce in o-transaction data will be checked by comparing it to the account nonce.A and her related operation account nonce is $k$.A initiates an o-transaction on Ethereum by calling IERC6358::sendOmniverseTransaction. The current account nonce of A in the ERC-6358 smart contracts deployed on Ethereum is $k$ so the valid value of nonce in o-transaction needs to be $k+1$.o-transaction data. If the verification succeeds, the o-transaction data will be published by the smart contracts on the Ethereum side. The verification includes:
nonce in o-transaction is $k+1$o-transaction SHOULD NOT be executed on Ethereum immediately, but wait for a time.A's latest submitted nonce in o-transaction on Ethereum is $k+1$, but still $k$ on other chains.o-transaction on Ethereum but not on other chains.o-transaction data, verify the signature and execute it when the waiting time is up.account nonce on all chains will add 1. Now all the account nonce of account A will be $k+1$, and the state of the balances of the related account will be the same too.3092860212ceb90a13e4a288e444b685ae86c63232bcb50a064cb3d25aa2c88a24cd710ea2d553a20b4f2f18d2706b8cc5a9d4ae4a50d475980c2ba83414a796
secp256k1cdfa0e50d672eb73bc5de00cc0799c70f15c5be6b6fca4a1c82c35c7471125b6In the simplest implementation, we can just build two mappings to get it. One is like pk based on sece256k1 => account address in the special environment, and the other is the reverse mapping.
The Account System on Flow is a typical example.
Flow has a built-in mechanism for account address => pk. The public key can be bound to an account (a special built-in data structure) and the public key can be got from the account address directly.pk to the account address on Flow can be built by creating a mapping {String: Address}, in which String denotes the data type to express the public key and the Address is the data type of the account address on Flow.The ERC-6358 Token could be implemented with the interfaces mentioned above. It can also be used with the combination of ERC-20/ERC-721.
The implementation examples of the interfaces can be found at:
IERC6358, the basic ERC-6358 interface mentioned aboveIERC6358Fungible, the interface for ERC-6358 fungible tokenIERC6358NonFungible, the interface for ERC-6358 non-fungible tokenThe implementation example of some common tools to operate ERC-6358 can be found at:
The implementation examples of ERC-6358 Fungible Token and ERC-6358 Non-Fungible Token can be found at:
According to the above, there are two roles:
o-transactiono-transaction data if they find differences between different chains.The two roles might be where the attack happens:
Simply speaking, it's none of the synchronizer's business as they cannot create other users' signatures unless some common users tell him, but at this point, we think it's a problem with the role common user.
The synchronizer has no will and cannot do evil because the o-transaction data that they deliver is verified by the related signature of other common users.
The synchronizers would be rewarded as long as they submit valid o-transaction data, and valid only means that the signature and the amount are both valid. This will be detailed and explained later when analyzing the role of common user.
The synchronizers will do the delivery once they find differences between different chains:
account nonce on one chain is smaller than a published nonce in o-transaction on another chainnonce in o-transaction on one chain is different from another published o-transaction data with the same nonce in o-transaction on another chainConclusion: The synchronizers won't cheat because there are no benefits and no way for them to do so.
Simply speaking, maybe they will, but fortunately, they can't succeed.
Suppose the current account nonce of a common user A is $k$ on all chains. A has 100 token X, which is an instance of the ERC-6358 token.
Common user A initiates an o-transaction on a Parachain of Polkadot first, in which A transfers 10 Xs to an o-account of a common user B. The nonce in o-transaction needs to be $k+1$. After signature and data verification, the o-transaction data(ot-P-ab for short) will be published on Polkadot.
At the same time, A initiates an o-transaction with the same nonce $k+1$ but different data(transfer 10 Xs to another o-account C for example) on Ethereum. This o-transaction (named ot-E-ac for short) will pass the verification on Ethereum first, and be published.
At this point, it seems A finished a double spend attack and the states on Polkadot and Ethereum are different.
Response strategy:
ot-P-ab to Ethereum and deliver ot-E-ac to Polkadot because they are different although with the same nonce. The synchronizer who submits the o-transaction first will be rewarded as the signature is valid.A did cheating after they received both ot-E-ac and ot-P-ab respectively as the signature of A is non-deniable.o-transaction will not be done immediately and instead there needs to be a fixed waiting time. So the double spend attack caused by A won't succeed.o-transactions to two chains, but none of the synchronizers deliver the o-transactions successfully because of a network problem or something else, we still provide a solution:
o-transactions will be synchronized when the network recovered. If the waiting time is up and the cheating o-transaction has been executed, we are still able to revert it from where the cheating happens according to the nonce in o-transaction and account nonce.A couldn't escape punishment in the end (For example, lock his account or something else, and this is about the certain tokenomics determined by developers according to their own situation).
Conclusion: The common user maybe cheat but won't succeed.
Copyright and related rights waived via CC0.