Motivation: Blockchain interoperability, which allows transferring assets and sharing data across different blockchain networks, is an emerging but crucial field of blockchain technology. Existing blockchain interoperability solutions have shown interest in assets exchange across permissionless blockchains. A few of them involve the interoperability between permissionless and permissionless blockchains. We propose BXHub, which targets the interoperability between the two types of blockchains.

Architecture: BXHub consists of three main components: Router, Driver, and CrossApp.

(1) Router is a peer-to-peer network layer, where the nodes run in a trusted execution environment, e.g. Intel SGX. The layer is responsible for processing the cross-chain transactions requests from users’ applications and coordinating the execution of transactions above multiple blockchains. Router also stores the verification information for each connecting blockchain, such as block headers data, in order to validate the transactions occurring on each blockchain. Routers connect the drivers to forward each single-chain transaction to the destination blockchain.

(2) The driver layer is responsible for all the communications between routers and blockchain networks. A type of blockchain network (e.g. Fabric, Ethereum etc) has its own type of driver. Drivers transmit the request from routers through different blockchain SDK and forward the responses of transaction status, e.g. transaction hash.

(3) CrossApp is a smart contract deployed on each connecting blockchain, which is responsible for coordinating the cross-chain transaction execution and managing locking or unlocking of assets.

To manage the user’s identity and access control in permissioned blockchain networks, we also introduce an external DID component.

BXHub utilizes a ChainRelay component running in routers to validate the transaction inclusion on connecting blockchains. The ChainRelay provides two functionalities: Block header migration and Transaction inclusion verification.

• Block header migration. The ChainRelay continuously receives the propagation requests of block headers from the nodes or clients of the blockchain. For each given block header, ChainRelay needs to verify it is part of the souring blockchain. The block headers verification depends on the consensus mechanism used by the connecting blockchains. For Nakamoto consensus, the ChainRelay must get the difficulty adjustment policy, and verify each received header that is on the main chain, with the most accumulated Proof-of-Work. For Proof-of-Stake blockchains, the ChainRelay needs to know the epochs of the staking, and verify the threshold/multi-signatures of each received block header is from the elected leaders. For permissioned blockchain (Proof-of-Authority), the ChainRelay needs to verify the signature of the block header is from consensus participants.
• Transaction inclusion verification. The ChainRelay stores block headers information for all connecting blockchains, which is responsible for verifying a transaction is included in one connecting blockchain. The verification mechanism is based SPV technique, where the ChainRelay receives the Merkle tree proof and transaction data for verifying.