-
Notifications
You must be signed in to change notification settings - Fork 35
Ion Stage 1
Ion Stage 1 is the implementation of simplest mechanism for cross chain payments. That means that this stage is not expected to avoid attacks or to work beyond the happy path described as a simple walkthrough.
The main goal of this implementation is to explore one possible way of executing cross chain payments, there are other methods that can achieve this goal.
There are 3 main components to the Ion Stage 1 stack:
- IonLock
- IonLink
- Lithium
An ERC-223 Token contract is also necessary for swaps as we currently only support swaps of ERC-223
The description of the smart contracts used on the Ion Stage 1 walkthrough can be found here.
Lithium is used as the event relay illustrated below. Lithium acts as a one-way listener of events on one chain, creates a merkle tree of them and submits merkle roots to the secondary chain.
Lithium is a standalone service that connects to two blockchains. Each Lithium instance will listen to the IonLock IonTransfer event on one chain, pack each event into a piece of data (leaf) and create a merkle tree out of all the leaves captured. This maintains a tree of transactions and each leaf can be verified via merkle proofs. The root of the merkle tree is then submitted to the opposite chain's IonLink where this root will be used to validate withdrawals.
To validate withdrawals we make a query to our Lithium service with the leaf we are verifying and it returns us a relevant path to prove it's existence in the merkle root. This is then submitted with other metadata pertaining to the withdrawal to IonLock during the withdrawal to verify whether the sender can withdraw.
For full functionality, two Lithium instances must be used to connect chain A to chain B and vice versa.
The final goal of these operations is:
A pays to B in Token X. B pays to A in Token Y.
Smart Contract on-chain Token and IonLock
- Token X is minted
- Token X is transferred to A
- Token Y is minted
- Token Y is transferred to B
- Token X is transferred from A to IonLockA
- Token Y is transferred from B to IonLockB
Executed by a middleware off-chain that submits to IonLink on-chain smart contract
- Merkle Tree is created with a leaf Merkle_A
H( to_B, token_address, ionlock_address,value)note: hashes address of B - Merkle Tree is created with a leaf Merkle_B
H( to_A, token_address, ionlock_address,value)note: hashes address of A - A submits Merkle_A to IonLinkA
- B submits Merkle_B to IonLinkB
Smart Contract on-chain IonLock that uses IonLink to verify proof
- B withdraws Token X from IonLockA
- A withdraws Token Y from IonLockB
- Step 1 to 6 both parties transfer Tokens to the IonLock smart contract. The payments are considered locked at this point, it is not possible to withdraw the payment unless the respective IonLink is updated.
- Step 7 to 10 update on-chain maintained merkle root. After IonLock emitting events that are caught by a middleware service, the service is responsible for updating the on-chain IonLink contract with the latest merkle root. The middleware maintains a merkle tree with a set of transactions that can be withdrawn.
- Step 11 to 12 withdraw funds from the opposite party IonLock contract. The IonLock contract only allows for withdraw if the opposite party has transferred funds, and if funds have been transferred to the original IonLock, the latter is verified through the state of the IonLink smart contract.
- The trusted nature of our event relay intermediary means that any roots that IonLink receives are trusted. This means malicious roots could be created and issued to IonLink compromising the verification layer.
- The lack of reversion means that a single party could escrow their funds in anticipation of their counterparty doing the same. In the case where the counterparty decides not to engage in the transaction after the initiator has escrowed, there is no method via which funds can be returned. The solution for this lies in providing a timeout for a deposit but state-syncing of chains and finality becomes an issue i.e. if both parties escrow and withdrawing becomes possible, one malicious party could both refund on one chain and withdraw on the other before the refund state change updates the other chain leaving one party out of funds.
Clearmatics :D