Title: 「Understanding Darwinia Bridge 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.
.png)
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.
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.
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.