In this post, we compare different ZK light clients to prove the state of Ethereum EL and CL. We summarize trust assumptions and benchmarks for different light client implementations, focusing on the time it takes to generate the ZK consensus proofs.
The external light clients in question are:
- Spectre (Chainsafe)
- Telepathy (Succinct)
- Brevis
- DendrEth
This post is intended to guide the Celestia Community and Developers in selecting the best Light Client implementation for integrating IBC + ZK accounts, enabling a canonical bridge for Ethereum assets.
TL;DR
| Category | Spectre Halo2 (ChainSafe) | Spectre SP1 (ChainSafe) | Telepathy (Succinct) | Brevis (Celer) | DendrETH |
|---|---|---|---|---|---|
| Trust Assumptions | Beacon node queries, Initial sync committee verification | Beacon node queries, Initial sync committee verification | Beacon node queries, Upgradable contracts, Freeze mechanism | Beacon node queries, Initial sync committee verification | Beacon node queries, Initial sync committee verification |
| Proof Type | Halo2-KZG SNARKs | Raw STARK, Groth16, Plonk | Groth16 SNARKs | Groth16 SNARKs | Groth16, Plonky2 SNARKs |
| Step Proof Time | 114.2s | 43.2s (STARK) 91.6s (Groth16) | 242s | Not Available | Not Available |
| Rotation Proof Time | 271.2s | 22s (STARK) 56s (Groth16) | 240s | 72s | Not Available |
| Additional Notes | Optimized for cost efficiency | WIP project. Benchmarked with GPU acceleration, performance expected to improve | Upgradable contracts may introduce additional trust assumptions | Benchmarked on high-end hardware (384GB RAM) | Exposes both finalized and optimistic headers |
Background: Ethereum Light Client Sync Protocol
Ethereum’s Light Client Sync Protocol is designed to reduce the cost of verifying the internal state of the L1. Every set interval, rather than every single block, a network of committee nodes attests to the current state and serves both attestations and headers for external verification.
Without the Light Client Sync Protocol, in order to verify even a single storage slot against the most recent Ethereum state root, one would be required to verify the entire chain against a trusted Genesis block, which requires a lot of storage space and time.
1. Spectre
Spectre is a ZK light client developed by Chainsafe Systems as part of a blockchain interoperability solution named Sprinter. Spectre is currently in production and was integrated into the Hashi stack.
The primary implementation of Spectre, which is currently deployed, is written in Halo2. However Chainsafe R&D are currently working on a future-proof ZKVM version of Spectre.
Spectre consists of two different ZK circuits:
- step circuit
- committee update circuit
The step circuit is used to prove that a beacon block header is valid and was signed by a corresponding committee.
The committee update circuit proves that a sync committee root is included in a finalized header.
When the committee is updated, an aggregate proof of both the step and committee update circuits is submitted. During the sync period, step proofs are submitted to trustlessly maintain the latest finalized header root. The update of the sync committee public keys is referred to as a rotation.
The proof committee rotates every 256 epochs, which is equivalent to approximately 27 hours. Proofs for individual Steps can be submitted every epoch. An epoch contains 32 slots and spans ~ 6.5 minutes.
For a rotation, the committee update and step proofs are linked via a commitment to the public key vector. The public key commitment for the currently active committee is updated on-chain at each rotation. This separation aims to optimize step proof aggregation by avoiding repeating expensive computations
1.1. Trust Assumptions
At Smart Contract initialization, an initial sync committee root is manually set for an initial sync period.
Before trusting Spectre, one should verify said sync committee against the root of the specified sync period.
function setUp() public {
spectre = new Spectre(
stepVerifierAddress,
committeeUpdateVerifierAddress,
initialSyncPerios,
initialSyncCommiteePoseidon,
slotsPerPeriod,
finalityThreshold
);
When obtaining the necessary data to verify the initial sync committee for the initial sync period, one must query one or more trusted beacon node(s). Therefore the actual trust assumption lies in the beacon node query.
1.2. Benchmarks - Spectre Halo2
1.2.1 Step Circuit
| Hardware | m7g.4xlarge (16 core ARM, 64 GB) |
|---|---|
| Gas Cost | 324114 |
| Proof Size | 1376b |
| Elapsed Time | 114.2s |
1.2.2 Sync Committee Rotation
| Hardware | m7g.4xlarge (16 core ARM, 64 GB) |
|---|---|
| Gas Cost | 349775 |
| Proof Size | 23493b |
| Elapsed Time | 271.2s |
1.3. Benchmarks - Spectre SP1
Note: currently on SP1 v3.4.0, in the process of migrating to v4.x which will boost performance by up to 2-3x.
1.3.1 Step Circuit
| Hardware | 1x H100 lambdalabs 80 GB sxm5 |
|---|---|
| wrapped (groth16) | 91.6s |
| wrapped (plonk) | 170.8s |
| generic (SP1) | 43.2s |
1.3.1 Commitee Circuit
| Hardware | 1x H100 lambdalabs 80 GB sxm5 |
|---|---|
| wrapped (groth16) | 56.9s |
| wrapped (plonk) | 137.6s |
| generic (SP1) | 22.1 |
1.3.3 Sync Committee Rotation
| Hardware | 1x GH200 lambdalabs 96 GB pcie |
|---|---|
| wrapped (groth16) | 239.1s |
| wrapped (plonk) | 289.5s |
Note: this benchmark was performed on less powerful hardware, using SP1 v4.0.1.
2. Succinct - Telepathy
Learn more about Telepathy here.
2.1. Trust Assumptions
Similar trust assumptions to Spectre, however a key difference is that Freezing is enabled.
Telepathy state that they will pause the functionality in the event that a vulnerability is found: Guardrails | Telepathy.
Additionally, the Telepathy Smart Contracts are upgradable, meaning they have the ability to override the verification logic at any time.
This positions Telepathy as a trust assumption alongside the beacon node queries.
2.2. Benchmarks
| Hardware | r6a.8xlarge |
|---|---|
| Step (groth16) | 118s |
| Witness generation | 124s |
| Rotate (groth16) | 60s |
| Witness generation | 180s |
| Aggregate | unknown |
Note that Witness generation is part of the proving process and therefore the total proving time is actually the sum of witness generation and “proving time”:
| Hardware | r6a.8xlarge |
|---|---|
| Total Step | 242s |
| Total Rotate | 240s |
| Est. Aggregate | 482s |
3. Brevis
Learn more about Brevis here.
3.1. Trust Assumptions
Celer’s Brevis has the exact same trust assumptions as Spectre .
The Smart Contracts are nearly identical.
While Spectre circuits are written in Halo2 and SP1 , Brevis circuits are written in gnarks (go).
constructor(
uint256 genesisTime,
bytes32 genesisValidatorsRoot,
uint64[] memory _forkEpochs,
bytes4[] memory _forkVersions,
uint64 _finalizedSlot,
bytes32 syncCommitteeRoot,
bytes32 syncCommitteePoseidonRoot,
address _zkVerifier
)
Note: the source of this contract was labeled as deprecated.
3.2. Benchmarks
While there are no benchmarks available for the step and committee update components of the circuit individually, the Brevis Whitepaper contains information regarding the performance of gnark for signature verification and a full rotation proof.
The Sync Committee Update is essentially identical to the Rotation proof in Spectre.
Bear in mind that most of the workload in a Step circuit is not just the verification of the BLS signature, but also the interpretation of curve points.
| Hardware | Unspecified Linux Server with 384GB RAM and 20 cores @2.3GHz |
|---|---|
| Committee Update | 72s |
| Signature Verification Bls12-381 (single) | 25s |
Note: 384GB of memory exceeds the available resources of devices used for other benchmarks in this post by a significant amount.
4. DendrETH
Learn more about the DendrETH project here.
4.1. Trust Assumptions
DendrETH exposes both finalized and optimistic headers in their Smart Contracts. When working with optimistic headers it is important to understand that they might be subject to change.
Other than that the architecture and trust assumptions are again similar to Spectre and Brevis, see here:
where prevHeaderHash is a commitment over the active committee and nextHeaderHash is a commitment over the next committee.
4.2. Benchmarks
There are no meaningful benchmarks available for DendrETH that could be used for a comparison with the clients above, however they did publish experimental results for their circom slot proofs:
“We tested our prototype circuits on a desktop computer with Intel i9-12900K CPU and on various cloud instances. The proving time is dominated by steps 3 and 4 which are embarrassingly parallel problems. On the i9 CPU, the Validator Status and Balance Verification proof requires 700 ms for 8 validators, while each Range Aggregation takes 1200 ms (the depth of the tree of recursive calls is 38 levels)”
Note that these benchmarks are not meaningful compared to the numbers mentioned for the clients above, as the Balance Verification occurs after the finalized header is validated by the light client, which serves as the primary benchmark in this post.
Summary
From the data provided in this summary, it can be concluded that Telepathy is the only light client that introduces additional trust assumptions, aside from the trusted beacon node queries. Spectre, Brevis and DendrETH ship with immutable Smart Contracts, which implement no upgradability. Aside from that, their trust assumptions are equivalent and rooted in the necessity for trusted beacon node queries and in the one-time verification of the initial contract state.
With respect to performance, Brevis scores impressive results on powerful hardware with 384 GB of memory. Spectre Halo2 yields balanced results on less powerful hardware and is therefore a cost-efficient option. Spectre SP1 requires GPU acceleration in order to generate proofs within a reasonable timeframe and while GPU acceleration is currently relatively expensive, has the greatest potential for future performance improvements and long-term cost reduction.
Note on upgradability
In general, smart contract upgradability is undesirable as it can alter core verification logic, such as the critical 2/3 supermajority check. However, Ethereum’s inevitable hard forks may require updates to the SNARK verifier logic. To avoid making the main lightclient contract upgradable, we propose a proxy design allowing verifier upgrades to be added to the immutable contracts.
In this design, the lightclient contract delegates verification to one or more SNARK verifier contracts, selected based on the current block height. As block height increases beyond a fork height, a permissioned mechanism (e.g., admin key or governance) allows adding new verifier contracts without modifying the core lightclient logic.
Acknowledgements
This post is co-authored by Jonas Pauli. Jonas also developed the Spectre-Sp1 implementation during his time at ChainSafe. We also thank @nashqueue for the review and feedback.