Technology Perspectives | How to solve the problems and challenges of all current cross-chain solutions?

Inscription: As a distributed ledger technology, blockchain can be applied in many fields such as finance, health care, supply chain, asset management, etc., but it is restricted by factors such as throughput, network isolation, scalability, etc. Blockchain projects do not serve commercial applications well. Among the many problems faced by blockchains, network isolation hinders the cooperative operation between different blockchains, which greatly limits the space for blockchains.

I. Introduction

In the previous technical point of view article, we introduced in detail the specific design and implementation of the six modules of the ontology chain. I believe that everyone has a basic understanding of the ontology chain technology.

Figure | Network

This time we mainly introduce the problems and challenges faced by all current cross-chain solutions , as well as further improvements and optimizations to address these issues and challenges.

Second, the side chain makes evil
An important security issue involved in cross-chain interactions is how to prevent sidechain certifiers from collectively doing evil, that is, sidechains doing evil .

In Cosmos, the side chain is an autonomous system, and the side chain certifier's election is determined by the side chain itself; in Polkadot, the side chain certifier's management is determined by the Polkadot main chain. Whether it is an autonomous verifier election or a unified verifier election, there is a fundamental problem – these sidechain verifiers are not necessarily reliable . If the actual value of any one or more of the assets in the cross-chain interaction is greater than the actual value of the verifier's mortgage, the verifier will have sufficient motivation to do evil.

E.g:
Developers of a dApp deploy smart contracts on both the main chain and the sidechain, hoping to cross-chain asset interactions. When the user of the dApp transfers a part of the assets to the side chain, if the actual value of the part of the assets is greater than the actual value of the side chain (the verifier collective) in the main chain, then the malicious side chain (verifier collective) can Directly transfer this part of the assets to their own name, and finally transfer to the main chain and sell the assets in the exchange.

Of course, the side chain certifier's margin in the main chain mortgage will pay for part of the user's loss. However, if the actual value of the side chain certifier's mortgage asset on the main chain is less than the actual value of this part of the user's assets, the malicious side chain certifier will have the incentive to take the collective evil to benefit.
Evil way
Most of the existing cross-chain schemes use the Merkle Tree proof method, that is, the side chain will generate a state root in all the blocks in the current block in each block, and the side chain certifier will sign the state root. When a cross-chain transaction occurs, the validity of the cross-chain state can be verified by verifying the State Root.

If the side chain verifier finds that the actual value of the assets of the user cross-chain interaction is greater than the actual value of the mortgage assets of the verifier, the side chain verifier can forge a State Root based on the current block, ie, ignoring the execution result of the current block, forcibly constructing A state root that is good for itself, stealing the assets that the user has locked in the main chain.

Third, how to solve the side chain evil

We can set a challenge period , which can be divided into the following steps to prove the evil during the challenge period:

(1) Whether it is possible to submit a block of evil;

(2) Whether it can provide the previous state of the transaction that is doing evil;

(3) Whether it can provide a smart contract for doing evil;

(4) Whether the generated States Root running in the corresponding virtual machine is consistent with the state root of the current block.

The verifier is to construct a false State Root in the current block by the collective, but the transaction in the block cannot be changed because it cannot forge the user's signature. Therefore, in the case of the certifier's evil, we propose a solution to the problem.
During the challenge period, if a transaction is found to be evil, you can run the results in the virtual machine by doing the evil block, trading in the bad block, trading the previous state in the bad block, and making the evil contract. Whether the state root generated by the operation is consistent with the State Root submitted in the evil block, thereby verifying whether the state root is legal.

Figure | Network

At the same time, regardless of whether there is a cross-chain transaction, Relayer will monitor the side chain in real time. If the State Root of the current block header is not consistent with the actual running State Root, the certificate can be submitted to the main chain immediately, and the proof side chain is provided. The malicious behavior and the side chain certifiers are motivated by the corresponding incentives in the main chain.

It can be seen that there is currently room for further optimization of the program. The verification process is somewhat complicated, especially for heterogeneous chains; in addition, the existence of the challenge period is not sufficiently friendly to the user. Therefore, the ontology will continue to study other more feasible and efficient solutions based on this solution.

Fourth, postscript

In this series of technical viewpoints on cross-chain, we bring you specific details about cross-chain design. At present, the ontology provides detailed cross-chain use tutorials and multi-chain development manuals, and hopes that the majority of technology enthusiasts will experience the ontology cross-chain test network.

Multi-chain development manual
https://github.com/siovanus/documentation/blob/master/multichain/Testnet_Dev_Manual.md
Cross-chain tutorial:
https://github.com/siovanus/documentation/blob/master/multichain/Tutorial_Case.md

Source: Ontology