From a technical perspective, there are three main types of strategies for interoperability between chains:
Centralized or multi-signature notary mechanism:
one or more parties agree to take an action on chain B if an event occurs on chain A.
The witness mechanism is the easiest way to implement inter-chain operations. In the witness mechanism, a trusted entity, or a team of multiple entities, is used to declare to the original ChainX that an event occurred on chain Y, or to declare that an assertion on chain Y is true. These entities can be active, constantly monitoring events on the chain Y, and automatically respond accordingly when an event occurs; they can also be responsive, and only sign certain messages when a request is received.
Sidechain / Relay:
The internal system of a chain can verify and read events or states on other chains, which is a light-node inter-chain solution.
Relaying is a more direct way to achieve interoperability. It no longer relies on trusted intermediaries to provide information about other chains, but allows the chain itself to take over this task. The general method is this: suppose the smart contract on chain B wants to know whether a specific event occurs on chain A, or in a state of chain A, an object has a specific value; assume that chain A is designed It must have the concept of “block” and “block header” like Bitcoin or Ethereum, and the block header is a compressed representation of a block (and the current state) (this compressed representation is based on some cryptographic structures, such as Merkle tree).
At this time, we can create a smart contract on chain B, which takes the block header of chain A as input, and uses the standard verification process determined by the consensus algorithm on chain A to verify this block header.
This is the light node inter-chain solution.
A smart contract on chain B wants to verify a specific transaction, event, or state on chain A. It will use a Merkle Proof in a way very similar to client verification . Because the blockchain is a self-contained environment and there is no natural access interface to perceive the external world, the data on chain A is actually submitted to chain B by a user, but because these data can be cryptographically Verified, so there is no need to trust the user who submitted the data.
Hash lock:
Set up an operation in chain A and chain B, these two operations have the same trigger condition, usually this condition is to reveal the original image of a hash value (ie, how the original data can be hashed to get this Hash value)
In the scenario of inter-chain atomic exchange, the mechanism of hash lock can be simply described as follows:
1. A generates a secret random number S, then calculates its hash value hash (s) = h, then A sends h to B.
2. Both A and B lock their assets in a smart contract. A locks first, and B sees that A’s lock operation is successful before locking. The logic of the smart contract is: on the A side, if the secret random number s is provided within 2X seconds, the asset is transferred to B, and the asset is passed back to A when it times out; on the B side, if Within X seconds, s is provided, then the asset is transferred to A, and the asset is passed back to B when it times out.
3. In order to obtain the asset locked in B’s contract, A will reveal s within X seconds; at the same time, this also ensures that B can observe s on the chain, thereby obtaining the asset locked in A’s contract.
About ChainX
- Official website: https://chainx.org
- Wiki: https://github.com/chainx-org/ChainX/wiki
- Twitter: https://twitter.com/chainx_org
- Medium: https://medium.com/@chainx_org
- Telegram: https://t.me/chainx_org
- White paper: https://chainx-static.oss-cn-hangzhou.aliyuncs.com/chainx_en.pdf
- Desktop wallet: https://github.com/chainx-org/chainx-wallet/releases/tag/v1.0.3
- Official Wechat: interchain
