CrossChain — My Summary
Lately I have checked out some cross-chain projects. Thought it would be nice to summarize technologies related to cross-chain. “Cross-chain” means that semantics on one chain can be correctly executed on other chains. Currently, cross-chain projects are mainly impelemtned for asset on one chain to be projected to another chain. From a technical standpoint, I would categorize current cross-chain technologies into three types: HTLC，cross-chain bridge based on consensus, and cross-chain bridge based on light client. Relevant technologies and projects are summarized in below chart:
HTLC（Hash Time Lock Contract）
HTLC principle is rather simple:
Say Alice and Tom want to exchange assets. Alice first creates HTLC. Then Tom creates HTLC with the same hash. In short, Tom and Alice create “locks” with the same key to protect their own property. When Alice opens Tom’s assets with the key, Tom can Alice’s assets with the same key. At the same time, it goes without saying that both of them need to check assets lock timestamps.
Implementing cross-chain through HTLC is a simple and safe solution, which garantees both parties’ atomic manipulation. However, both of the chains are required to support smart contract, and therefore limits both transaction parties not to divide the transaction assets. As a matter of fact, for the porpose of effective transaction, it is required for both parties to communicate offline beforehand through another channel and to reach the same page.
Cross-Chain Bridge Based on Consensus
It is relatively easy to implement the cross-chain bridge logic based on other consensus. Verify one chain event based on consensus, then execute on the other chain. Security of the entire bridge depends on the strength of consensus. Besides the traditional consensus mechanism (such as BFT, PoS), it also includes MPC and multi-signature.
Cross-Chain Bridge Based on Light Client
In order to verify information on one chain from another chain, we execute the light client of another chain on this one. Usually light clients are based on SPV (Simple Payment Verification) agreement. SPV originates from BTC, mainly used in PoW consensus chain. Celo and Harmony have also implemented light clients for their own consensus algorithm of the chain. The pure PoS consensus chain is challenging for implementing light client, since the consensus depends on Staking, and Staking is made up from transactions. It is unrealistic to exhaust all Staking transactions just to implement the light client.
The two chains of Cross-Chain Bridge verify the states of the other party through the light client. This bridge is dependent on Relay, and the block header information of synchronized chain. To syncing the block header information is necessary, we require the following elements:
1/ sync frequency and fee: there is a fee for saving block header information on another chain. Especially the chain with higher tps — more blocks exist over there.
2/ verify main chian and blocks: based on the chain consensus, we verify the main chain through blcok header information. Take the PoW as an example, block verification is usually done by the amount of following blocks.
Here are a few methods to optimize the sync fee: 1/ random challenge (NiPoPOW，FlyClient) 2/ zk-SNARK (include recursive zk-SNARK). We introduce a few typical cases:
- BTCRelay
Utilize traditional SPV light client implementation to cross from BTC to ETH chain. Obvisouly, syncing up BTC block header information is consuming Gas on ETH. When it comes to the high Gas price of Etherum, the fee of synchronization is relatively high.
- FlyClient
FlyClient takes the random challenge and MMR (Merkle Mountain Range) technologies to lower the amount of light client synchronized blocks. The goal of random challenge is to not synchronize all the blocks in a certain range to the chain, but to randomly select some blcoks to sync. In order to verify the unselected blcoks on the chain, all block information are organized together through MMR. MMR is a variation of Merkle tree, and is applicable to scenarios of additive nodes. MMR, compared to normal binary Merkle tree, it owns the feature of low cost of updating new leaf node.
- zkRelay
zkRelay also attempts on lowering the fee of light client for synchronized block on the chain. Different from FlyClient, zkRelay utilizes zk-SNARK proof. The off-chain proofs are submitted to the chain within a certain range of block effectiveness. On the chain we only need to check whether proofs are valid.
- Celo
Celo is a very interesting project. Celo project itself does not relate much to cross-chain, but generates inspiration for the light clients. In order to impelment lighter client, Celo utlizes the recursive zero-knowledge proof technology to recursively prove block header connection information. One proof can show the legality from the genesis block to current block. One light node only requires synchronizing the latest proof to confirm validity of all blocks.
- Summa (Stateless SPV)
The projects mentioned above focus on optimization of lowering sync cost on client chain. Here we introduce a brand new angle by Summa:
The summary is extracted from the introduction slides deck from Summa. Summa has observed an interesting fact: one chain may have synced with another, but many blocks are wasted. The root reason is the nonexistence of transactions needed to be proved. Summa has assumed an “Ecnomic“ safety measure: proving one transaction exists in a certain block, and there exist blocks behind such block. Summa thinks it is against the “economic” way to keep blocking out following a fake block. The calculation power would be better utilized on the real blocks. With this method, there is no need to save node information on the chain, but only providing the corresponding block and its proof when one transaction needs the proof only. This method is also referred to as Stateless SPV. Of course, the assumption of “economic safety” requires deduction, especially on the low complextiy cases, which is rather easy to fake the block and to verify it.
- Xclaim
As of the traditional chain with no calculation power, it is impossible to implement the light client of other chains. That is to say, if only through the light client method, only one-way cross-chain can be implemented on these chains. In order for these chains to implement double-way cross-chain, Xclaim introduces the mortgage role and implements the two-way projection. Xclaim has mentioned 3 operations in the paper: issue, swap, and redeem. Take issue and redeem as examples, let us take a look at the effect of mortgage role:
Most of the chains support transaction feature. The mortgager acts as the middleman, and accepts transactions from other people when mortgages exist on another chain (which supports smart contract). The initiater of the transaction can prove the legality of the proof from another chain through client verification. The transaction could happen after the cross-chain transaction is proved legal on the other chain.
After submitting burn operation on one chain, the mortgager actively starts the transaction while has observed the operation. At the same time, the mortgager provides the transaction proof to “redeem” assets from the smart contract on another chain. In short, as long as the two chains has one smart contract, the double-way cross-chain operations could happen through the mortgager role. Root reason would be the transactions on the chain can be verified and validated.
Summary:
Cross-chain is a complex topic. It is rather simple and realistic to implement cross-chain through other consensus. HTLC can implement the itomic transaction for both transaction parties. However, the transaction is limited to two parties, and the communication has to be conducted beforehand before the transaction to ensure the effectiveness of the transaction. The research has been ongoing on the impelmentation of client validation of states of other chains. As for PoW chain, we need to take into consideration the block header synchronization cost and the verification logic during implementation of the light client.
