State Relaying Mechanism

[bhavesh197]

I have one query regarding the information relay in the ethereum to ethereum integration. In your design wiki, it is mentioned that Alice will get the encoded block from the CLI of chain B and submit it to chain A. I want to know how it is submitted to chain A? What is the relaying mechanism being used? I did not find anything more transparent about the state relaying mechanism between two chains at your Github wiki or your Medium page. Please try to clarify it. @Shirikatsu

[Shirikatsu]

Apologies for the lack of clarity on this.

ION is agnostic to how this happens.

State relaying is an action that can be carried out by any party; but that party incurs the cost of state submission. In this way it is normally in the interest of the actor that wishes to perform some cross chain transaction to submit this state and then verify against it. In the example it is explicitly Alice that gets the block and submits it.

It is also foreseeable to creative incentive mechanisms (depending on the use case) to encourage state transmission between chains where third parties are compensated for submitting blocks. Since state submission is simply data fetching and submitting via a transaction, there is no complex 'mechanism' that relays the blocks. Automated systems can be designed to do this by listening to both chains but again the operator of the relaying system incurs the cost of submission.

[bhavesh197]

Say for a simple use-case I want to transfer some tokens from chain A to chain B. How can I set up end to end connection from chain A to chain B? Can you provide the steps that I need to follow in order to establish that end to end connection? @Shirikatsu

[Shirikatsu]

The specific application logic will depend on how a developer implements the semantic logic for how tokens can be ported. ION provides a base layer that developers can use for interconnection.

Token transfer between chains is typically seen as:

1. Lock up tokens on chain A
2. Submit proof of lock to Chain B
3. Mint tokens on Chain B
4. Trade tokens on Chain B
5. Burn tokens on Chain B
6. Submit proof of burn to Chain A
7. Unlock tokens on chain A

You need two sets of contracts below for each chain:

• Validation.sol - This needs to contain logic that can verify the validity of a block from another chain based on their specific consensus algorithm. This is important as this dictates the security properties of the block derived from the other chain. Currently we have IBFT, Clique PoA validation mechanisms.
• BlockStore.sol - This needs to contain logic that can persist the blocks (or other types of data structures for non-blockchains) from the peer chain. Currently we have Ethereum and Hyperledger Fabric block storage contracts implemented.

To implement the above, you will require a deep fundamental understanding of the peer chains involved in order to replicate the security assumptions afforded by the chains' consensus mechanism (as the security of a PoW chain is vastly different from that of a dPoS chain). This must be used such that there are no additional security assumptions that affect the correctness and/or validity or finality of the incoming blocks (many other solutions require trusted relayers or other subsystems with their own incentive structures).

To use the stack, you will need to deploy a set of the above contracts for both chains A and B. If the two chains are completely different systems i.e. ETH and EOS, the contracts must be implemented in their respective available languages to include logic that processes data from the opposite. For example, a set of solidity contracts that a) can hold EOS blocks; and b) verify the dPoS algorithm over every block; must be deployed to the Ethereum chain, and a set of CPP contracts that a) can hold Ethereum blocks; and b) verify the PoW/PoA or other (depending on chain) consensus algorithm over every block; must be deployed to the EOS chain.

Once you have a set of those contracts deployed on each chain you will need use-case application contracts that can make use of state from opposing chains. Thus use-case contracts must be designed such that they can read other-chain state from their native chain as the blocks from foreign chains are held within the block storage contracts. These can be used as dependencies or conditions (to check for transaction inclusion or specific data) to be used in transactions on your native chain. For example, you want to only send ERC20 tokens to somebody if they have sent some other token to you on the EOS chain. You can develop an atomic swap contract that utilises the state from the opposite chain to check if some particular transaction has happened (in this case, if counterparty has sent token) before sending your own.

In this case you need one contract on each chain that facilitates the above lock, prove, mint, burn, prove, unlock flow between the two chains. Using the block storage you can prove that there was a transaction on chain A that locked X tokens in order to mint X tokens on chain B.

Thus the eventual stack for token transfer between Chain A (ETH PoW) to Chain B (EOS) looks like:

Chain A:

• dPoSValidation.sol
• EOSBlockStore.sol
• Ion.sol (as the mediator)
• TokenTransfer.sol

Chain B:

• ETHPoWValidation.cpp
• ETHBlockStore.cpp
• Ion.cpp
• TokenTransfer.cpp

1. Alice locks ETH at TokenTransfer contract on Chain A.
2. Block containing the lock tx is packed and submitted to the ETHPoWValidation contract on Chain B (can be done by anyone, but here Alice will do it)
3. Validation contract verifies the block and passes it to ETHBlockStore contract for storage.
4. Alice calls Mint function on TokenTransfer contract on Chain B pointing to the block in the ETHBlockStore contract containing the lock tx as a proof of lock and Mints EOSETH on Chain B.
5. Alice trades EOSETH with Bob on Chain B.
6. Bob wants to use his funds on Chain A so calls Burn function on TokenTransfer contract on Chain B and burns his EOSETH.
7. Block containing the burn tx is packed and submitted to the dPoSValidation contract on Chain A (can be done by anyone, but here Bob will do it)
8. Validation contract verifies the block and passes it to EOSBlockStore contract for storage.
9. Bob calls Unlock functions on TokenTransfer contract on Chain A pointing to the block in the EOSBlockStore contract containing the burn tx as a proof of burn and Unlocks ETH on Chain A.

Any contracts that do not yet exist will need to be implemented. As you can imagine, there exists a combinatorial number of possibilities of bilateral chain which makes it prohibitively difficult to enumerate all possibilities.

[Shirikatsu]

ION provides security over transactions (to the extent of that offered by each chain) at the expense of high data transmission costs (blocks must be passed in their entirety including any data that is required for validation).

This problem may be mitigated in some scenarios where the base layers are very efficient and scalable.

We are currently looking into downsizing the amount of data that needs to be passed without compromising on security.

[Shirikatsu]

FYI The ion-cli provides tooling that allows you to deployed contracts and interact with them including generating transaction proofs and blocks for submission to Ethereum chains. This is not strictly necessary to integrate with ION but provides an interface to simplify some of the processes.

[bhavesh197]

@Shirikatsu Thanks for the detailed answer. I will try it out and let you know if any issue arises.

[Shirikatsu]

No problem. Please let me know if you need any more clarification of the concepts.

ION is agnostic so it may prove that runtime of a stack will not be very user friendly as you will have to manage a lot of processes to enable one thing.

You can run the demo in the README to get something to work naively. It simply checks that a tx on the Rinkeby testnet has occurred with the correct parameters in the event, and performs another transaction only if the check passes.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days