Be a crypto hero in the market by logging in
Don't you have an account? Sign in
Market trends report
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.
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.
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.
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.
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.
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:
Video Tutorials Link:
Ontology set up the research institute in order to focus more on the research and development of core blockchain technology and strengthen the ability to explore, reflect on, and apply emerging technologies, as well as make contributions to the entire industry. At present, there is more than 10 R&D personnel in the Ontology Research Institute.
How does Ontology’s Multichain Design Prevent Side-Chain Malicious Act was originally published in OntologyNetwork on Medium, where people are continuing the conversation by highlighting and responding to this story.
서비스 이용에 불편을 드려 죄송합니다. 현재 전화상담은 진행하고 있지 않아서 가입하신 메일 주소로 답변을 보내드렸으니 메일을 확인해 주시기 바랍니다.
Community | 3단계 휴대폰 인증버튼 안 눌림
제가 알기론 신청 후 4일간 락업되고 그 이후엔 본인이 원하실때 해지하시면 될 겁니다. 그럼 신청 시 렉스 비율과 해지시 렉스 비율에 따라 이오스 수익금이 계산되어 들어올 겁니다.
Community | [중요] 이오스 렉스 참여방법 (EOS 입금부터 수익금 확인방법까지)
12/12일 신청한것 대여기간이 언제 까지 인지 궁금합니다
Community | [중요] 이오스 렉스 참여방법 (EOS 입금부터 수익금 확인방법까지)
Community | 고객센터 연락처 문의
하려는 친구들이 많아야 미래가 밝다고 할 수 있겠죠.
Community | 인하대에서 인천 중·고생에게 블록체인 교육 실시한다네요
Write a post
Are you sure you want to delete this post?
Are you sure you want to delete this comment?
Purchase has been completed.
닉네임을 설정 후 작성해주세요.