Light Client

On-chain Light Client

At the heart of the Wisp protocol is an on-chain light client for the Ethereum network. These on-chain light clients are smart contracts deployed inside the rollups anchored to Ethereum and allow for reasoning about the state of the L1. As all rollups are posting their state, one way or another, inside L1, this allows any rollup to reason about the state of any other rollup by proxy of the Ethereum state.

The on-chain light clients are based on ZK proofs implementing the Ethereum Sync Protocol.

In a nutshell, the Ethereum Sync protocol introduces an Ethereum Sync Committee of 512 validators. The purpose of the sync committee is to allow light clients to keep track of the chain of beacon block headers. The committee is selected through an algorithm every sync committee period (~27 hours), and while a validator is part of the currently active sync committee they are expected to continually sign the block header that is the new head of the chain at each slot. Importantly, the validators of the next sync committee period are known in the current sync committee period. This means that following the consensus from the beginning, any light client can compute the current active sync committee that should be signing the block headers.

Having this in mind, any light client needs to perform two verifications in order to trust a block header.

1. Firstly the light client would need to find out what is the current sync committee validator set. This is done by knowing at least one slot from the previous sync committee period and getting the sync committee from there.

2. Secondly, the Ethereum beacon block headers are signed via aggregated BLS key of the validators. Light clients perform Aggregated BLS Signature verification of the signed root hash representing the beacon block header.

Information on the BLS signature scheme can be found here.

Combining the two verifications allows the light client to trust any beacon block header supplied by a third-party provider.

It is exactly this process that is being executed on-chain in order to create an on-chain light client for Ethereum inside the supported rollups. However, this process is quite complex and resource-consuming.

This has led to the implementation of the on-chain light client via succinct Computational Integrity (ZK) proofs - SNARKS. The current version of the on-chain light client is based on the work of Succinct Labs called Proof of Consensus.

Circuits

There are two circuits as part of the Light Client flow - Sync Committee Mapping circuit and the Aggregate BLS Verification circuit. Both can be found here:

https://github.com/LimeChain/wisp-protocol/tree/main/circuits

Sync Committee Mapping

The Ethereum Sync Protocol saves the Sync Committee public keys in an SSZ-based Merkle Tree. While this is super convenient for non-ZK light clients, the keccak hashing used for constructing the tree root is unfriendly to be performed inside ZK proof. In order to fight this inefficiency at the beginning of each sync committee period a ZKP is created for mapping the ZK unfriendly format to a ZK friendly one.

This SNARK proves the equivalence of the keccak-based sync committee Merkle tree to a Poseidon-based (zk-friendly hashing algorithm) Merkle tree. This allows the next SNARK to be somewhat fast and inexpensive to produce.

Aggregated BLS verification

The second SNARK is the actual BLS verification of the signature for the block header. This SNARK proves that the majority of the validators of the appropriate sync committee have signed the block header.

Under the hood, this involves both aggregated BLS signature verification and proving that the set of validators that have cast their signature is one that is contained in the tree proven in the previous snark and is the one applicable for this block.

Contracts

https://github.com/LimeChain/wisp-protocol/tree/main/contracts/src/lightclient

Alongside the circuits, the on-chain light client has smart contracts. The obvious job of smart contracts is to perform the verification of the ZK proofs.

While the ZK circuits prove the validity of the block header, what is important for the Wisp protocol is the actual execution state root of the block. The BeaconLightClient contract also does the verification of the execution state root through a Merkle Inclusion Proof based on the already proven using ZKP beacon state root.

Delivery Time

The delivery time of a message has several components.

The first component is the time that it takes for the source rollup to anchor their state into the Ethereum L1. For the demo, where the supported rollups are Optimism and Base, this normally takes about 5 minutes.

After that, the block containing the rollup anchoring transaction needs to be finalized. This will take around 12 minutes but can take up to 18.

After the finalization of the block, the Aggregated BLS verification SNARK for the L1 Head needs to be produced. This takes about 4 minutes. So in total, in the alpha version, it takes between 21 and 28 minutes.

Optimizations

Several optimizations can be implemented in the future. Firstly, instead of verifying the merkle inclusion proof of the execution state root, this can become part of the Aggregated BLS verification SNARK.

Secondly, further exploration can be made in using STARK + SNARK combination for both proofs. This has the potential to get down the proving time without significantly increasing the proof size.