Foreword

As a distributed ledger technology, blockchain can be used in various sectors, such as finance, health care, supply chain, and asset management. However, limited throughput and scalability and network isolation prevent blockchain projects from better serving business applications. Among these limitations, network isolation hinders the collaboration between different blockchains and significantly limits what blockchain can do.

Introduction

In the previous Tech Point articles, we gave a detailed introduction to the 6 components of the Ontology multichain design and how do they work. We believe these articles will help you gain a basic understanding of the Ontology multichain design.

In today’s article, we will introduce the problems and challenges today’s cross-chain solutions are facing and what Ontology has done to overcome them.

Side-Chain Malicious Act

An important security issue involved in cross-chain interaction is how to prevent side-chain validators from acting maliciously——side-chain malicious act.

In Cosmos, side-chains are an autonomous system, and side-chain validators are elected by the side-chain itself; whereas in Polkadot, the side-chain validators are managed by the Polkadot main chain. Whether the election is autonomous or decided by the main chain, a fundamental problem is that these side-chain validators are not necessarily reliable. If the asset value of the interacting chains is greater than the value of the validators’stake on the main chain, the validators will have enough motivation to act maliciously.

For example, a dApp developer deploys smart contracts on both the main chain and the sidechain, hoping to achieve cross-chain asset interaction. When dApp users transfer a part of their assets to the side-chain, the side-chain validators can directly transfer the assets to themselves if they find out that the asset value is greater than the value of their stake on the main chain. Then they can transfer the assets onto the main chain and sell them on the exchange.

Of course, the side-chain validators’stake on the main chain will be used to compensate the users. Nonetheless, if the value of users’assets is greater than the value of the validators’stake on the main chain, then there is a high possibility the validators will make a colluded attempt to steal the assets.

How Malicious Act is Performed

Existing cross-chain solutions mostly adopt Merkle Tree Proof, that is, side-chains will generate in each block a State Root containing the state of all the transactions in the current block, and side-chain validators will sign that State Root. When a cross-chain transaction is taking place, the cross-chain state can be validated by validating the State Root.

If the asset value of the interacting chains is greater than the value of the validators’stake on the main chain, then the side-chain validators can forge a State Root based on the current block, which means they ignore the executed results of the current block and create a State Root in their favor, so as to steal users’ assets locked on the main chain.

How to Prevent Side-Chain Malicious Act

In response to the inconsistency of State Root of the current block, we can set a challenge period during which anyone can do the following:

(1) Submit the block where the malicious act takes place;

(2) Submit the previous state proof right before the malicious transaction;

(3) Submit the malicious smart contract;

(4) Check whether the State Root generated in the corresponding virtual machine is consistent with the State Root of the current block.

We can see that validators act maliciously by making a colluded attempt to forge a State Root in the current block and the transactions in the block cannot be altered as user signatures cannot be forged. Based on this, we have come up with an idea to solve this problem. During the challenge period, if a malicious transaction is spotted, we can run the malicious block, transaction in the block, the previous state of the transaction in the block, and the malicious smart contract on the corresponding virtual machine, and then compare the State Root generated to the State Root of the malicious block to see if that State Root is valid or not.

In the meantime, whether there are cross-chain transactions taking place or not, the Relayer will monitor the side-chains in real time. If the Relayer discovers that there are two block headers at the same block height or the State Root of the current block header is inconsistent with the State Root that is actually in operation, it can immediately submit the proof to the main chain, prove the malicious behavior on the side-chain, and receive the incentives the side-chain validators staked on the main chain.

We can see that the method of validating the State Root in the block is quite complex, especially for heterogeneous chains. In addition, the challenge period is not user-friendly enough. We will continue to improve on this solution and come up with more feasible and efficient ones.

Afterword

We have shared the details about the Ontology multichain design in several articles and we hope you now have a clear idea of what is the Ontology cross-chain solution and how does it work. Please let us know if you have any questions or suggestions.

Also, the Ontology cross-chain TestNet was launched in May and we have prepared detailed Developer Manual and video tutorials for fellow developers. Try developing on the TestNet and give us your feedback.

Ontology Multichain Documentation Link:

Ontology Multichain Developer Manual

Cross-Chain Tutorial

Video Tutorials Link:

Ontology Multichain TestNet

Ontology Cross-chain Contract Development