BEP-221: CometBFT Light Block Validation

[KeefeL]

   BEP: 221
   Title: CometBFT Light Block Validation
   Status: Draft
   Type: Standards
   Created: 2022-04-11

BEP-221: CometBFT Light Block Validation.

• BEP-221: CometBFT Light Block Validation.
  • 1. Summary
  • 2. Motivation
  • 3. Specification
  • 4. License

1. Summary

This BEP introduces a new precompiled contract to validate the CometBFT light blocks.

2. Motivation

There are some cross-chain requirements between BSC and CometBFT-compatible blockchains, like the BNB Greenfield which is an important part of the BNB ecosystem, thus we need a gas-friendly solution to validate the light blocks from the
CometBFT-compatible blockchains.

3. Specification

3.1 Consensus State

To validate the light blocks from the CometBFT-compatible blockchains, there should be a light client of the blockchain
on the BSC side, it could be implemented as a smart contract, and this light client should record the necessary
current state which we call it Consensus State to validate the future light blocks. The consensus state is defined as:

type ConsensusState struct {
  ChainID              string
  Height               uint64
  NextValidatorSetHash []byte
  ValidatorSet         *types.ValidatorSet
}

The consensus state should be encoded as a part of the precompiled contract's input, and after applying the light block,
the updated consensus state should be encoded as a part of the precompiled contract's output. The encoding format should be:

|--ChainID---|--Height---|--NextValidatorSetHash--|--[{validator pubkey, voting power, relayer address, relayer bls pubkey}]--|
|--32 bytes--|--8 bytes--|--32 bytes--------------|--[{32 bytes, 8 bytes, 20 bytes, 48 bytes}]--------------------------------|

The validator pubkey and voting power are necessary for recovering the validator in the current validator set. The
relayer address and relayer bls pubkey are extended to support some cross-chain infrastructure base on BLS,
we can just pad zero bytes if we don't use relayer address or relayer bls pubkey.

3.2 Light Block

A light block of CometBFT-compatible blockchain contains a SignedHeader and a ValidatorSet, which can be imported into
the CometBFT Light Client and update the light client's consensus state accordingly. The light block is defined as:

type LightBlock struct {
   *SignedHeader `json:"signed_header"`
   ValidatorSet  *ValidatorSet `json:"validator_set"`
}

The light block itself has a Marshal method to convert it into a byte array, and it should be a part of the precompiled
contract's input. Within the precompiled contract, use the Unmarshal method to recover it.

3.3 Validate Light Block

The input of the precompiled contract should include the current consensus state and the future light block. The encoding
format should be:

|--consensus state length--|--consensus state--|--light block--|
|--32 bytes----------------|-------------------|---------------|

Here are the steps to validate the light block within the precompiled contract:

1. Decode the input to get the current consensus state and the light block.
2. Apply the light block into the current consensus state according to CometBFT Light Client Verification.
3. Encode the updated consensus state and return it to the caller.

The output of the precompiled contract should be encoded as follows:

|--validatorSetChanged--|--empty-----|--consensus state length--|--new consensus state--|
|--1 byte---------------|--23 bytes--|--8 bytes-----------------|-----------------------|

4. License

The content is licensed under CC0.

[unclezoro]

Like the BNB Greenfield which is an important part of the BNB ecosystem.

[KeefeL]

Fixed in the part2, please check.