## Bedrock State Attestations Overview
Bedrock State Attestations is an EigenLayer AVS that provides **cryptographically verifiable state proofs** across heterogeneous blockchains (EVM and Bitcoin). It enables smart contracts to access and trustlessly verify data like storage slots, transactions, or account balances.
---
### Problem Statement
Cross-chain applications require cryptographic state verification but face limitations such as:
- Restricted queries and limited to certain EVM Chains.
- Requires contract pre-registrations and often indexing.
- High on-chain gas costs occur when handling large proofs.
Bedrock solves these by offering a unified verification layer for arbitrary chains and data types without pre-configuration.
#### **Key Goals**
1. **Multi-chain support**: Verify states on EVM chains and Bitcoin (via SPV).
2. **Ad-hoc queries**: Allow any public data request without pre-registration.
3. **Gas efficiency**: Optimize costs via Zero-Knowledge based attestations.
4. **Operator security**: Leverage EigenLayer re-staking for slashing-based fraud deterrence.
#### Non Goals
1. Replacing cross-chain messaging (e.g., LayerZero, Wormhole).
2. Serving as a general-purpose data availability layer.
3. Supporting private data or permissioned chains.
---
### AVS Consumer User Stories
This section describes core functionalities of Bedrock State Attestations from the perspective of end users (AVS Consumers). These stories illustrate how different consumers interact with the AVS to solve real problems.
#### **User Story 1: Cross-Chain Lending Protocol**
As a cross-chain lending protocol operating on Ethereum, I need to verify Bitcoin UTXO ownership and balance directly on Ethereum, So I can accept native BTC as collateral for loans while eliminating reliance on wrapped assets or centralized custodians.
#### **User Story 2: Multi-Chain DAO Governance**
As a DAO governance contract spanning different EVM Chains, I require verified token balances of members at specific block heights on multiple chains, So voting power allocations accurately reflect cross-chain holdings without manual snapshot coordination.
#### **User Story 3: Derivatives Settlement Engine**
As an options settlement contract on Arbitrum, I must prove historical Uniswap v3 price ticks from Optimism storage slots, So I can autonomously resolve contracts using verifiable on-chain data instead of price oracles.
---
### Entities
#### End User (AVS Consumer)
The End User is a smart contract or external account that submits state verification requests to the Bedrock AVS. This entity initiates tasks by calling the `createTask` function in the Bedrock contract, specifying the target chain (EVM or Bitcoin), query type (e.g., storage slot, transaction inclusion), and required parameters.
#### Bedrock AVS Contract
The Bedrock AVS Contract is the primary on-chain component deployed on Ethereum. It handles:
- Task creation via `createTask()`
- Proof submission and verification via `submitProof()`
- Fee management and slashing coordination
- Integration with EigenLayer contracts for operator management
This contract stores no state proofs only processes journals and emits results.
#### EigenLayer Core Contracts
These are existing EigenLayer protocols that Bedrock integrates with:
- **DelegationManager**: Assigns operators to tasks based on restaked ETH.
- **AllocationManager**: Forms operator sets and tracks stake allocations.
- **SlashEscrowFactory**: Enforces slashing penalties for invalid proofs.
- **RewardsCoordinator**: Distributes fees to operators and restakers.
Bedrock interacts with these for security, rewards, and operator governance.
#### Operator
Operators are node runners with restaked ETH delegated through EigenLayer. They:
1. Monitor `TaskCreated` events from the Bedrock contract.
2. Generate proofs using RISC Zero Steel (locally or via Bonsai).
3. Submit proofs and journals to `submitProof()`.
4. Require minimum hardware (GPU for local proving) or Bonsai API access.
#### RISC Zero Bonsai Service (3rd Party Service)
Bonsai is an optional external proving service provided by RISC Zero. Operators can choose to offload proof generation to Bonsai via an API instead of running the RISC Zero zkVM locally. Bonsai receives query data, executes the RISC Zero Steel guest program, and returns a Groth16 proof and journal. This service is used when operators lack sufficient hardware or for faster proof generation.
#### RISC Zero Verifier (Precompile)
This is an on-chain precompiled contract (part of the RISC Zero suite) that verifies Groth16 proofs. The Bedrock AVS Contract calls this verifier during the `submitProof` function to check the validity of the proof and journal. It is a trustless component with constant gas costs.
---
## AVS Security Model
### Operator Sets
Bedrock State Attestations defines two operator sets based on proof-generation methodology. Each set has distinct hardware requirements, SLAs, and economic incentives aligned with their risk/reward profile.
#### **Operator Set #1: Local Proving Operators**
**Scope of Work**
- Generate RISC Zero proofs locally using dedicated hardware.
- Tasks:
1. Execute Steel guest programs for EVM/Bitcoin state verification.
2. Monitor AVS for `TaskCreated` events.
3. Submit proofs to AVS within 45 seconds.
**SLAs**
| **Metric** | **Requirement** | **Penalty** |
| ---------- | --------------- | --------------------------- |
| Proof Time | ≤45 sec | Rewards withheld |
| Uptime | 99% monthly | Ejection after 3 violations |
**Rewards**
- **Base Reward**: 80% of task fees.
- **Performance Bonus**:
- 10% bonus for proofs submitted in top 25% speed.
- 5% bonus for 100% monthly uptime.
**Malicious Behaviors**
| **Behavior** | **Action** | **Severity** |
| ------------------------ | --------------------------- | ------------ |
| Invalid proof submission | Slash 100% stake | Critical |
| Late submissions (>3x) | Withhold rewards + ejection | High |
| Downtime (>1% monthly) | Withhold rewards | Medium |
**Entry Criteria**
1. **Stake**: ≥32 ETH restaked via EigenLayer.
2. **Technical**:
- Pass RISC Zero benchmark test (prove EVM storage in <15 sec).
#### **Operator Set #2: Remote Proving Operators (Bonsai)**
**Scope of Work**
- Delegate proof generation to RISC Zero Bonsai service.
- Tasks:
1. Forward queries to Bonsai API.
2. Relay proofs/journals to AVS within 30 seconds.
**Rewards**
- **Base Reward**: 60% of task fees.
- **Performance Bonus**:
- 15% bonus for Bonsai cost optimization (e.g., batch proofs).
**Malicious Behaviors**
| **Behavior** | **Action** | **Severity** |
| ----------------------- | --------------------------- | ------------ |
| Journal tampering | Slash 100% stake | Critical |
| Bonsai downtime (>0.5%) | Withhold rewards + ejection | High |
| Delayed relaying (>3x) | Withhold rewards | Medium |
**Entry Criteria**
1. **Stake**: ≥16 ETH restaked.
2. **Technical**:
- Valid Bonsai API key.
---
## System Design
Bedrock State Attestations uses RISC Zero Steel to generate cryptographic proofs for EVM and Bitcoin state queries. Operators generate proofs locally or via Bonsai, submitting them directly to the Bedrock contract for on-chain verification.
#### **Phase 1: Task Submission (On-Chain)**
End users submit state queries to the Bedrock AVS contract through the `createTask` function. This function accepts `BedrockRequest` Structure which contains all necessary information about the request such as `chainType`, `chainId`, `queryType`, etc.
```solidity
function createTask(
// Struct containing data such as chainType, chainId, queryType, blockNumber, etc.
BedrockRequest memory req
) external payable;
```
The contract emits a `TaskCreated` event containing the `taskId` and requester address.
```solidity
taskId = last8Bytes(keccak256(request));
```
#### Phase 2: Proof Generation (Off-Chain)
Operators monitor `TaskCreated` events and generate proofs using RISC Zero Steel's guest programs. Steel handles all state verification internally no external node calls are needed.
Two operator paths exist:
**1. Local Proving Operator**
Operators with GPU resources (e.g., NVIDIA RTX 4090) run RISC Zero's zkVM locally. They execute Steel guest programs (EVM or Bitcoin variants), which fetch and verify state trustlessly. The zkVM outputs a Groth16 proof and minimal journal data (e.g., storage slot value).
```mermaid
sequenceDiagram
participant EndUser as End User
participant AVS
participant Operator
participant Local as Local RISC Zero
EndUser->>AVS: Create a new task
AVS->>Operator: Monitors TaskCreated Event
Operator->>Local: Execute Steel guest program
Local->>Operator: Return Groth16 Receipt
Operator->>AVS: submitProof(journalData, seal)
AVS->>AVS: Verify Groth16 Proof
AVS->>EndUser: Decode Journal Data
```
**2. Remote Proving Operator**
Operators without GPUs forward queries to Bonsai via SDK. Bonsai executes the same Steel programs in its cloud infrastructure, returning Groth16 proofs. Operators maintain Bonsai API keys for authentication.
```mermaid
sequenceDiagram
participant EndUser as End User
participant AVS
participant Operator
participant Remote as Bonsai
EndUser->>AVS: Create a new task
AVS->>Operator: Monitors TaskCreated Event
Operator->>Remote: Execute Steel guest program
Remote->>Operator: Return Groth16 Receipt
Operator->>AVS: submitProof(journalData, seal)
AVS->>AVS: Verify Groth16 Proof
AVS->>EndUser: Decode Journal Data
```
#### Phase 3: On-Chain Verification
Operators call `submitProof(taskId, journalData, seal)` on the Bedrock contract. The contract:
1. Verifies the Groth16 proof using RISC Zero's precompiled verifier (constant 500k gas).
2. Decodes the journal (e.g., extracts `(contract, slot, value)`.
3. Executes a callback to the user with the verified data.
## Architecture Design
```mermaid
graph TD
A[End User] -->|createTask| B[Bedrock AVS Contract]
B -->|TaskCreated Event| C[Operator]
C -->|Local Proof| D[RISC Zero zkVM]
C -->|Remote Proof| E[Bonsai Service]
D & E -->|Groth16 Proof + Journal| B
B -->|Verify & Process| F[User Callback]
```
## Appendix
#### Glossary
- **zkVM**: Zero-knowledge virtual machine (RISC Zero's execution environment).
- **SPV**: Simplified Payment Verification (lightweight Bitcoin verification).
- **Groth16**: zk-SNARK proof system used by RISC Zero.
- **Journal**: Minimal output data committed by RISC Zero guest programs.
- **Bonsai**: A remote proving service for zkVM applications.
#### **References**
1. **RISC Zero Steel**:
- [Documentation](https://github.com/risc0/risc0-ethereum/tree/main/crates/steel)
- [Guest Program Examples](https://github.com/risc0/risc0-ethereum/tree/main/examples/erc20-counter)
2. **Bonsai Proving Service**:
- [API Docs](https://dev.risczero.com/api/generating-proofs/remote-proving)
---
Sign in with Wallet
Connect another wallet