Light client protocol

[txhsl]

Rationale

A light client protocol will be helpful if we are going to have a ZK-based cross-chain message protocol. I think this issue is now for discussion, since we haven't put it on the roadmap.

We always refer to this article when talking about ZK messaging. It lists several projects about this topic, Succinct, Electron and zkBridge. They aim to build a trustless message protocol based on ZK, and the LC protocol is exactly the core of it.

When most of the other cross-chain protocols are using multi-sigs or centralized trust to guarantee the safety and correctness. These projects choose to rely on the trust of LC protocols. By proving a correct LC block verification from the sender chain, a continuos state change can be synchronized to the receiver chain.

IMO, we need at least a document specification of LC protocol, or an LC verifier like https://github.com/cometbft/tendermint-rs/blob/main/light-client-verifier/src/verifier.rs.

Implementation

Geth has deleted its internal light client implement, ref ethereum/go-ethereum#28586, because it was broken after Merge, the consensus was moved to CL. So we don't have such an implementation either.

Now for the Ethereum PoS, a light client protocol should be implemented in consensus layer clients, e.g. OffchainLabs/prysm#12991, status-im/nimbus-eth2#2337.

Although there are different LC client implementations, they stick to the same protocol definition, ref https://github.com/ethereum/annotated-spec/blob/master/altair/sync-protocol.md.

This protocol is important for ZK messaging, because it determines what should an LC client verify when listening to an Ethereum full node. Then we can use ZK to prove this procedure and synchronize the state root to a smart contract on the receiver chain.

There is a simple practice about this synchronization, ref https://github.com/succinctlabs/sp1-helios or https://github.com/succinctlabs/sp1-tendermint-example.

Neo X now has a similar rule about block verification, and it's even much easier when we use the BLS.

1. Ethereum CL needs 512 public keys to compute the global public key for verification, and needs a Merkel hash to identify the block miner;
2. Neo X has an on-chain DKG to maintain the global public key for verification, CNs share the same secret, so there is no need for public key aggregation, and no need to verify the block miner;
3. Ethereum CL doesn't verify the election of sync committee;
4. Neo X doesn't have to prove the election of the 7 CNs as well.

So to me, an LC protocol is quite practical. Our block headers now allow two different schemes at the same time.

1. In ExtraV1ECDSAScheme, a block header contains an address list of the elected CNs. We verify the following things;
   • If the hash of this list is the same as parentNextConsensus declared in the parent block;
   • If at least 5 signatures in the block header, each is signed by a distinct CN in the list;
2. In ExtraV1ThresholdScheme, a block header contains a global public key. We verify the following things;
   • If the hash of this global public key is the same as parentNextConsensus declared in the parent block;
   • If the signature of this block header is signed by the decentralized secret corresponding to the global public key.

So we need two different kinds of circuit to prove the verification.

1. A recursive circuit to prove there are 5 signatures can be verified by the parentNextConsensus (5 Secp256k1 ECDSA + 1 Keccak256 Hash);
2. A quite simple circuit to prove that the signature can be verified by the parentNextConsensus (1 BLS12381 BLS + 1 Keccak256 Hash).

TBD

1. How about the N3 side, do we have an LC protocol? Because I can't find a signature field inside a N3 block. The neo-go code is using a VM calling to verify header, can I do it state-independently?
2. To make things easier, maybe we someday remove the ECDSA scheme? E.g. in V2, because our BLS has the simplest verification. If we launch ZK then it should be safe. (I've tried, seems not that valuable)

[txhsl]

I've implemented a demo about Neo X dBFT LC verification, https://github.com/txhsl/dbft-verifier/tree/main/neox.

And also another demo for N3, https://github.com/txhsl/dbft-verifier/tree/main/n3.

[txhsl]

A PoC of Neo X ZK LC is uploaded to https://github.com/bane-labs/sp1-neox-dbft.

Update: We've evaluated the performance of different solutions, further development is moved to https://github.com/bane-labs/dbft-verifier.