Hi everyone!
I’d like to share some research on how EIP-2935 could help reduce trust assumptions in Lido’s AccountingOracle, particularly for EL data verification.
Special thanks to @VictorP and @TheDZhon for reviewing and providing constructive feedback (:
Introduction and Background
EIP-2935, slated for inclusion in the upcoming Pectra fork, aims to extend Ethereum’s historical block hash storage from 256 to 8192 blocks. This change is particularly relevant for Lido’s AccountingOracle as it can significantly reduce trust dependencies and improve the reliability of reporting Execution Layer (EL) data. This post explores the impact of EIP-2935 on Lido’s oracle system and how it can leverage Merkle-Patricia Trie (MPT) proofs for on-chain verification of EL data.
EIP-2935 Key Features
- Increases accessible block hashes from ~50 minutes (256 blocks) to ~27 hours (8192 blocks)
- Enhances on-chain verification of historical state using MPT proofs
The AccountingOracle Report
Lido’s AccountingOracle is an important component that relies on a trusted committee to report on various aspects of the protocol’s state, including but not limited to:
- Consensus Layer (CL) data
- Number of Lido-participating validators
- Cumulative balance of all Lido validators on the consensus layer
- Number of exited validators
- Execution Layer (EL) data
- Withdrawal Vault balance (withdrawalVaultBalance)
- Execution Layer Rewards Vault balance (elRewardsVaultBalance)
- Shares Requested to Burn (coverSharesToBurn and nonCoverSharesToBurn)
- Withdrawals-related data
- Withdrawal finalization batches
- Simulated share rate
- Bunker mode status
The oracle committee submits this data approximately every 24 hours, referencing a specific slot. This comprehensive reporting is crucial for accurate staking rewards calculation, maintaining protocol security, and ensuring overall system integrity.
How EIP-2935 can support AccountingOracle
Extended Verification Window
This extension enables the AccountingOracle to utilize EL historical data for the first time by increasing the accessible block hash window from ~50 minutes to ~27 hours. Previously, the short 50-minute window limited the use of historical EL data in the oracle’s reporting process. With EIP-2935, it becomes feasible to generate and verify MPT proofs over the extended timeframe, allowing for verifiable on-chain state data over the entire 24-hour reporting cycle.
Trustless Verification via MPT Proofs
EIP-2935 enhances the ability to generate and verify MPT proofs over a longer time frame, particularly for EL data such as balances and vault states. While MPT proofs have always been possible, this expanded block history makes it more feasible to construct and verify these proofs over the entire reporting period, making the oracle less dependent on trust-based mechanisms.
To illustrate how MPT proofs can be verified on-chain, we can look at how this MerkePatriciaProofVerifier.sol contract was previously used for the backup trustless price oracle for ETH/stETH curve pool (now deprecated, though). This implementation could be referenced for verifying MPT proofs of the required EL data in the AccountingOracle report.
Additionally, it is also possible to leverage ZK technology for storage proofs. For example, the sp1-storage-proof repository demonstrates how ZK proofs can be integrated with MPT proofs. The script uses the RPC method get_ethProof to retrieve the MPT proof, generates the ZK proof using the SP1 package, and verifies the ZK proof. To verify such a proof on-chain, one can use the verifier contract found in this repository.
Reduced Reliance on Oracle Committee
For EL data, EIP-2935 can contribute to reducing the reliance on Lido’s oracle committee, as the increased block history enables trustless, on-chain verification through MPT proofs.
For CL data, while it is more challenging to verify on-chain, there has been notable progress toward reducing reliance on a trusted committee. EIP-4788, which was passed in the Dencun upgrade, exposes the Beacon block root directly in the Execution Layer via the BEACON_ROOTS_ADDRESS. This enables CL data to be accessed from the Execution Layer, providing an on-chain reference point that can be utilized by ZK proof systems.
For example, in their proposal and demo, Succinct shows how EIP-4788 can be combined with ZK proofs to verify CL data. While there are some computational challenges due to a large validator set, this work represents a significant step toward reducing reliance on the oracle committee for both CL and EL data, bringing Lido closer to a fully trustless reporting model.
Conclusion
In conclusion, EIP-2935 can provide opportunities for reducing trust requirements in Lido’s AccountingOracle. By extending historical block hash access, it could enhance on-chain verification of EL data through MPT proofs, reducing reliance on the oracle committee for reported EL data. This increased ability to independently verify data could strengthen the overall security and resilience of the oracle system, contributing to the broader goal of minimizing trust assumptions in the Oracle-reported data.