「Understanding Darwinia 1–6」The BSC Light Client for New Message Protocols
To accommodate the new design of the cross-chain message protocol, we need to update the light client accordingly. This article introduces the new design of the BSC light client on Darwinia.
In a previous article, we introduced the new design of cross-chain message protocol for the Ethereum-Darwinia bridge. Since BSC(Binance Smart Chain) is derived from Ethereum, the majority part of the design for the Ethereum-Darwinia bridge also applies to the BSC-Darwinia bridge. In addition, BSC has much lower gas fee, which makes the new design even more favourable.
To build a cross-chain bridge between BSC and Darwinia, we need to deploy a BSC light client on the Darwinia side, which is responsible for the verification of relayed messages. It lies in the Truth Layer in the following hierarchy. In this article, we will introduce the design of our new BSC light client and discuss its implications for the Ethereum light client.
How the BSC Light Client Works
What does a BSC Light Client Do?
In a light-client-based bridge, relayers transfer information between two blockchains, including block headers, messages, and proofs of messages. The light client’s job is to verify the validity of messages using block headers and proofs of messages. Because cross-chain messages are stored onchain, the light client does not necessarily need the header of the block where the message is generated to do the verification. In other words, only headers of epoch blocks will suffice. The reason will be stated in the section of Message Proof. Therefore, we explain the job of the BSC light client in two parts: verification of headers(of epoch blocks) and verification of messages.
Verification of Headers
Update BSC Validator set
According to the BSC consensus, the consensus engine is named Parlia, which is similar to Clique, where members of a validator set take turns to produce blocks. We need to ensure that the validator set in the light client can accurately follow the BSC.
BSC light client security
For every epoch block, the new validator set will be filled in the extra_data field of the block header. But, for the security reason, the new validator set only takes effect after N/2 blocks. (N is the size of the validator set in the last epoch block)
Since the light client can not verify it against the contract(there is no contract data in the light client), it has to believe the signer of the epoch block. If the signer of the epoch block write a wrong extra_data, the light client may just go to a wrong chain.
If we delay N/2 blocks to let the validator set change take place, the wrong epoch block won’t get another N/2 subsequent blocks signed by other validators, and therefore the light clients are free from such attacks.
Validator set update process
From the above conclusions, once the light client receives an epoch block, it only needs to keep receiving its N/2 following child blocks, which is enough to update the validator set.
When a fork happens, you do not need to decide on which branch to use instantly. According to the criteria specified in the BSC documentation, once the number of child blocks on a branch reaches N/2 , this branch will become the canonical one, as the following diagram shows.
- When a validator node receives a new epoch block (height%epoch==0), it fetches the new validator set from it after verifying its signature;
- It continues to receive the following blocks and verify the signatures with the current validator set. Once the length of the longest branch reaches N/2 , the epoch block can be finalized;
- The validator set is updated;
- Go back to Step 1.
Finalize the BSC block header
According to Darwinia’s cross-chain bridge specification, cross-chain verification is the verification of messages or events on the source chain using the accepted block headers. If the information in the light client is insufficient for the verification of messages or events, the light client needs extra information, which normally is the block header when the message or event happens.
Verification of Messages
In our the design of the cross-chain message protocol, a message is nothing more than a key-value pair stored onchain. The process to verify a message is exactly the same as the verification of any storage. The light client needs the message, the message proof and the State Root hash in the block header to accomplish the verification task. The finality of block headers was discussed in the previous section. Here we will explain the the messages and the message proof.
A cross-chain message is stored as a key-value pair under the account of the smart contract of Message Protocol. The key part contains the indexing information(chain_id, lane_id etc.) of the message and the value part is the payload which contains the encoded information for the application on the target chain to interpret.
The message proof consists of two parts, the storage trie-related storageProof and the state-trie-related accountProof. The BSC light client first verifies the message with the first part of the proof(storageProof) against the storageHash(SHA3 of the StorageRoot), and then the second part(accountProof) against the stateRoot, which is included in the finalized block header.
Since a cross-chain message is stored on the source chain unless it is pruned after being successfully delivered, the message is included in the digests of several blocks. Therefore, the BSC light client does not necessarily need to have every block header from the BSC network to verify the messages. Even better, a header can often be used in the verification of multiple messages(with the respective multiple proof).
In our previous design, the light client on the Darwinia side utilized an MMR(Merkle Moutain Range)-proof-based verification mechanism. MMR is a variant of the Merkle tree, which is easy to add a new node to the existing tree. However, neither Ethereum nor BSC has inherent support for MMR, so we had to run an off-chain service to maintain an MMR of Ethereum or BSC.
The revision of the BSC light client is a step toward the unified model of different types of bridges. This new design has already been implemented in our Substrate-to-Substrate bridges. For BSC, it has separated the Truth Layer from the Message Layer by eliminating the MMR service. The side effect of the new design is the gas fee brought about the use of on-chain storage. It pays off for low-gas-fee blockchains, like BSC. For Ethereum, optimization to save transaction cost is an open question.
About Darwinia Network
Darwinia Network is a decentralized cross-chain bridge network building on Substrate, which is the “cross-chain bridge hub” of the Web 3.0 Metaverse. It provides a safe and general bridging solution, connects to Polkadot, Ethereum, TRON, and other heterogeneous chains by cross-chain transfer of assets and remote chain calls.
Darwinia Network has gained high reputation and recognition along the way to build the decentralized cross-chain bridge protocol. In 2020, Darwinia was written in Polkadot light-paper as one of the friends of Polkadot and Substrate. And Darwinia was selected to join Substrate Builder Program and Web3.0 Bootcamp, and for the outstanding work in Substrate Builder Program, Darwinia Network was officially awarded the Level 2 badge by Parity. The products and tools developed by Darwinia have been rewarded three W3F Grants.
Darwinia has been contributing to the compatibility and interoperability of the Metaverse.
The application areas of Darwinia Network include DeFi, cross-chain NFT trading, games, etc. Darwinia also develops the Metaverse game Evolution Land.