From c93e7c389ae93fd6ea999c1b960c8d932f07466a Mon Sep 17 00:00:00 2001
From: KeefeL <90749943+KeefeL@users.noreply.github.com>
Date: Fri, 14 Apr 2023 10:19:41 +0800
Subject: [PATCH] BEP-221: CometBFT Light Block Validation (#221)

---
 BEP221.md | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 BEP221.md

diff --git a/BEP221.md b/BEP221.md
new file mode 100644
index 00000000..2d3a4990
--- /dev/null
+++ b/BEP221.md
@@ -0,0 +1,92 @@
+<pre>
+   BEP: 221
+   Title: CometBFT Light Block Validation
+   Status: Draft
+   Type: Standards
+   Created: 2022-04-11
+</pre>
+
+# BEP-221:  CometBFT Light Block Validation.
+
+- [BEP-221: CometBFT Light Block Validation.](#bep-221--cometbft-light-block-validation)
+  - [1. Summary](#1-summary)
+  - [2. Motivation](#2-motivation)
+  - [3. Specification](#3-specification)
+  - [4. License](#4-license)
+
+## 1. Summary
+
+This BEP introduces a new precompiled contract to validate the [CometBFT](https://docs.cometbft.com/v0.37/introduction/) 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:
+
+```go
+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](https://en.wikipedia.org/wiki/BLS_digital_signature),
+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](https://docs.cometbft.com/v0.37/spec/light-client/) and update the light client's consensus state accordingly. The light block is defined as:
+
+```go
+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](https://docs.cometbft.com/v0.37/spec/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](https://creativecommons.org/publicdomain/zero/1.0/).