Cross-Chains: How Blockchains Communicate With Each Other
Recognized as an integral technology, we examine cross-chains to better understand how blockchains can communicate with each other.
When blockchains were first being built, they were envisioned as being able to provide a ‘one size fits all’ solution, meaning that all transactions, smart contracts, or anything else is performed on a single chain. However, it’s clear now that such a system isn’t so practical, especially when there are scalability limits and innovation constraints.
A cross-chain is the interoperability between two relatively independent blockchains. In other words, it allows blockchains to speak to one another because they’re built in a standardized way. Cross-chain implementation is mainly represented by asset swap and asset transfer, which is both an important part of the blockchain world and a key research direction of PPIO. With cross-chains, the limitations of a single chain can be avoided. Today we will explore the logical structure of the Cosmos cross-chain protocol, one of the most promising cross-chain platforms.
Cross-chain interaction can be divided into isomorphic cross-chains and heterogeneous cross-chains according to the different underlying technology. For isomorphic chains, the security mechanism, consensus algorithm, network topology, and block generation verification logic are consistent and the cross-chain interaction between them is relatively simple.
On the other hand, the cross-chain interaction of heterogeneous chains is relatively complex and includes technology such as the PoW algorithm for Bitcoin and PBFT consensus algorithm for Tendermint. The block composition and the deterministic guarantee mechanism are quite different, therefore a direct cross-chain interaction mechanism is not easy to design. Cross-chain interaction between heterogeneous chains generally requires third-party ancillary services.
How to Realize Isomorphism Across Chains?
Chains developed based on Tendermint can adopt isomorphic cross-chains. The principle of asset transfer between isomorphic chains in Cosmos is as follows.
Since Tendermint uses the PBFT+POS consensus algorithm, a block is only submitted to the network when 2⁄3 certifiers agree. The Validator information can be verified by checking the block header to verify whether the block header is legal in a certain chain. As an example, Tendermint is developing two chains: Chain A and Chain B. Now assume that assets need to be transferred across the chain. Firstly, the two chains, A and B, will register with each other. In the process of registration, A and B recognize their separateness. The chain will then send the respective genesis blocks and ChainID (used to represent different chains) to each other. Since the genesis block contains the Validator information, after registration, A and B chains will have the Validator information of the other chain, as well as block header information.
Now the assets in A need to be transferred to B. First, the user can send a cross-chain transaction packageTx to A. A executes the packageTx, destroys or locks the related assets, and then writes packageTx to the egress. The egress can be regarded as a mailbox where all externally notified cross-chain transactions are placed.
In order to notify chain B of events occurring in chain A, a relayer is needed. The relayer is responsible for forwarding cross-chain messages from the egress in chain A to chain B’s egress. In this situation, the relayer queries the packageTx in chain A’s egress and obtains the Merkle Proof of packageTx. The information is packaged into IBC Package PostTx transaction and sent to chain B, which queries block header information as to where packageTx is located. It also packs the block header information into IBCUpdate Chain Tx and sends it to chain B. Note that the relayer pays the transaction cost of both IBC Package PostTx and IBCUpdate Chain Tx.
After chain B receives the IBCPacketPostTx transaction, it first checks whether the block header in the IBCUpdateChainTx is part of chain A through the Validator in that chain, and then verifies whether the Merkle proof of the cross-chain transaction in IBCPacketPostTx is equal to the block header hash in IBCUpdateChainTx. When all the checks pass, the B chain starts to perform related operations (for chain B, this means generating related assets, etc).
Isomorphic Cross-Chain Implementation Method
The cross-chain in Cosmos is implemented by the IBC protocol. The following IBC protocol packages defined in the Cosmos ecosystem: IBCRegisterChainTx, IBCUpdateChainTx, IBCPacketCreateTx, IBCPacketPostTx.
IBCRegisterChainTx
The following code is used at the beginning of the cross-chain to register and send the Genesis Block. The Validator will give it to the other party. This code can only be executed once, and multiple executions will report an error.
type IBCRegisterChainTx struct {
BlockchainGenesis
}
type BlockchainGenesis struct {
ChainID string
Genesis string
}IBCUpdateChainTx
Used to transfer the latest block information, block height, and block-head information on the current chain to another chain.
type IBCUpdateChainTx struct {
Header tm.Header
Commit tm.Commit
// TODO: NextValidators
}IBCPacketCreateTx
When the chain receives the transaction package, it will perform cross-chain transactions and will put relevant information in the egress.
type IBCPacketCreateTx struct {
Packet
}
type Packet struct {
SrcChainID string
DstChainID string
Sequence uint64
Type string // redundant now that Type() is a method on Payload ?
Payload Payload
}IBCPacketPostTx
This package contains the Merkle proof after the cross-chain transaction is executed, which is then sent by the relayer to another chain.
type IBCPacketPostTx struct {
FromChainID string // The immediate source of the packet, not always Packet.SrcChainID
FromChainHeight uint64 // The block height in which Packet was committed, to check Proof
Packet
Proof *merkle.IAVLProof // Merkle证明
}# plugin
We can see from the above protocol that these protocol packages are actually a transaction. Tendermint has a plug-in module in order to facilitate our extension. We can implement the interface in the plugin and perform cross-chain transactions with the IBC plug-ins.
type Plugin interface {
// Name of this plugin, should be short.
Name() string
// Run a transaction from ABCI DeliverTx
RunTx(store KVStore, ctx CallContext, txBytes []byte) (res abci.Result)
// Other ABCI message handlers
SetOption(store KVStore, key, value string) (log string)
InitChain(store KVStore, vals []*abci.Validator)
BeginBlock(store KVStore, hash []byte, header *abci.Header)
EndBlock(store KVStore, height uint64) abci.ResponseEndBlock
}The above code is the definition of the plugin interface. It can be seen that the plugin is very similar to the ABCI interface, so the IBC transaction is handed to the plugin at deliverTx.
// ABCI::DeliverTx
func (app *BaseApp) DeliverTx(txBytes []byte) (res abci.Result) {
// Exec tx
switch tx := tx.(type) {
case *types.SendTx:
// 执行正常交交易
case *types.AppTx:
// 执行plugin中的交易
plugin := pgz.GetByName(tx.Name)
res = plugin.RunTx(cache, ctx, tx.Data)
return res
default:
return abci.ErrBaseEncodingError.SetLog("Unknown tx type")
}
return res
}Heterogeneous Cross-Chain PegZone
For chains that use POW consensus algorithms, such as Bitcoin and Ethereum, how can they operate across chains using Tendermint’s IBC protocol? Because of the POW algorithm used in these chains, we can’t verify the blocks of these chains through the Validator. We also can’t use Merkle proof to prove the legitimacy of cross-chain transactions on these chains. Furthermore, the blocks generated by the POW consensus algorithm are probabilistically final and have the possibility of being rolled back. We need to ensure that cross-chain transactions are truly final and will not be rolled back.
Based on the above considerations, we use the PegZone scheme to perform heterogeneous cross-chaining. PegZone itself is actually a proxy chain developed by Tendermint, which tracks the state of the original chain in real-time, and sets a security threshold to wait for the original chain block to grow. When the number reaches the safety threshold, the original chain state is considered to have a pseudo-real-time finality (small rollback probability), which is the same principle as the light client wallet verification. For example, the Bitcoin Safety Threshold is usually set to 6, while the ETF Safety Threshold can be set to 20 or 100. PegZone itself has real-time finality and can be connected to the Cosmos Hub through IBC to achieve the cross-chain.
The following image uses PegZone, or Peggy, alongside Ethereum as an example of cross-chaining.
As can be seen from the picture above, PegZone can be divided into five parts:
- Smart Contract: The role of asset trusteeship in the custody of tokens in Ethereum and in Cosmos. It mainly provides four methods: lock, unlock, mint and burn.
- Witness: It is a full-scale Ethereum node that monitors the event of the Ethereum contract and waits for 100 blocks to be generated. The encapsulated Witness Tx is submitted to PegZone to prove the status change on the Ethereum blockchain.
- PegZone: PegZone is a Tendermint-based blockchain that maintains user account information, allows the transfer of assets between users, and provides transaction queries.
- Signer: Secp256k1 is used to sign transactions so that signatures can be efficiently validated by smart contracts; this corresponds to the set of verifier public keys of smart contracts.
- Relayer: The relayer is responsible for all transaction forwarding. This role forwards the signed SignTx to the smart contract.
Cosmos Hub Role
In the basecoin cross-chain demo in Cosmos, two chains, Chain A and Chain B, are cross-linked, and send IBC Register Chain Tx to each other for registration. When crossing the chain, IBC protocol packages are sent directly to carry out the cross-chain operation of assets. However, this direct connection has a problem. As the number of Zones (which are equivalent to an independent blockchain) accessed to the network increases, the number of links will increase in a square order if communication is implemented directly. Take 100 Zones connected to the network as an example. If each Zone directly needs to establish an IBC connection, the network needs n(n-1)/2=4950 communication links. Such rapid growth will obviously overwhelm the network.
The concept of the Hub can solve the problem regarding this problem. In the Cosmos ecosystem, all Zones will register with and send IBC packages to the Hub.
Hub Operation Mode
Hubs manage many Zones. All Zones need to register with a Hub. The Hub tracks the status of each Zone. Each Zone reports all new block information it produces to the Hub. At the same time, each Zone also needs to synchronize the status of the Hub. Instead of communicating directly between Zones, each Zone communicates indirectly by sending IBC to the Hub.
When a Zone establishes an IBC connection to the Hub, it can automatically access other Zones connected to the Hub, which means that a Zone does not need to connect to other Zones.
When one Zone receives tokens from another Zone connected to the Hub, it only needs to trust the Hub and that Zone, not all other Zones in the network.
Check the join the PPIO community on Discord or follow us on Twitter for more
