Hi all,
We have completed a working implementation of the Lido zkOracle, which could serve as a trust-minimized second opinion source for negative rebases of stETH, as outlined in LIP-23. Though delayed from our initial timeline, this allowed us to leverage the latest zkVM advancements, strengthening the implementation.
Initial Plonky2x Implementation
The initial prototype described in the first post was built using Plonky2x—a circuit framework. At the time this design was state of art and performant. However, there were key limitations:
-
The circuit design has a computational constraint that limits the maximum validator set size to 2^21 (approximately 2 million validators). This limit could be reached through two mechanisms:
-
Natural growth in the number of active validators from increased staking.
-
The continuous increase in validator indices is due to each validator (including those that have exited) being permanently assigned a unique index. With validator indices currently approaching 1.7 million, this computational ceiling of 2 million becomes a practical concern that needs to be addressed.
-
Circuit programs are difficult to maintain due to a lack of readability.
Final SP1 Base Implementation
Following the release of SP1, Succinct’s general purpose zkVM, we decided in April-May to rewrite the entire oracle implementation in Rust for SP1. Not only was this much faster to implement than the circuit-based design, but the codebase is much more readable and auditable. It also does not suffer from the 2^21 validator limit, enabling a future proof-design.
Demo
The implementation provides end-to-end functionality: from requesting slot-specific metrics to generating proofs and updating the Lido AccountingOracle contract onchain.
- Here is a report for slot 10339199, the clBalanceGwei value is 9744648818963059, which corresponds exactly to the Lido Oracle committee report.
- This proof is verified in this mainnet contract, where onchain proof verification is 366k gas.
- Proof generation took takes around 30 minutes and consumes around ~4B RISC-V cycles (note this is on the v3 version of SP1 and computational times vary as a public shared cluster is used). Proof generation times will likely be greatly improved with SP1 V4, our latest release.
SP1 ZK Lido Oracle Audit
The greatly improved solution based on SP1 took significantly more time and resources than it was expected. While the code was preliminary reviewed by two independent 3rd-parties (a16z research and Pashov audit group) with a helping hand of the Lido audits committee, we propose to put the full-fledge audit expenses out of scope for the grant and make them against the latest Pectra-hardfork enabled specifications.
Audit scope
- Commit: 5ed589331f
- Codebase size:
- Solidity: 171 nSLOC
- Rust: ~2039 nSLOC
- Modified dependency ([email protected]): ~100 nSLOC
Timeline and Next Steps
- We suggest considering this grant as completed and open for community feedback.
- The suggested timeframe for the final audits and escalating a governance vote to plug a second opinion provider is the post-Pectra hardfork period to accommodate any potential Beacon chain last-minute updates and the V4 release of SP1 being battle-tested.
- Further audit expenses will be handled separately from the original grant due to the extended scope of work and development timeline.
SP1 Based Implementation: GitHub - color-typea/sp1-lido-accounting-zk
Original Forum Post: ZK Lido Oracle powered by Succinct