We’re excited to share the work-in-progress whitepaper for [Project Untitled], a novel approach to decentralized state management that we’ve been developing at o1Labs. In our whitepaper, we present a protocol that aims to solve some fundamental challenges in decentralized state management while maintaining the guarantees of a layer 1 blockchain system. By sharing this work at this stage, we hope to gather feedback from the community on both our established designs and areas still under research and refinement. Your feedback will be invaluable in strengthening the protocol and ensuring we've considered all critical aspects before finalizing the design. We welcome detailed technical discussions, alternative perspectives, and suggestions across all aspects of the whitepaper.
The core technical foundation of [Project Untitled] is largely complete, centred around our novel cryptographic protocols, and is fully formalized. Specifically, we have:
1. A comprehensive protocol for proving reads and updates ensuring that:
- Read operations provably return correct data
- Updates maintain commitment consistency
- State retention proofs guarantee actual data availability
2. Proof of retrievability that allows state replicators to prove data possession without revealing the data itself.
3. Efficient implementation strategies for all core operations, with concrete complexity bounds and optimized constructions.
Network Transactions
Our transaction system defines several specialized types for the following network participants:
- State replicator: A node responsible for managing the data and ensuring all the requested reads and writes are performed on it
- Validator: Node that produces a block or attests blocks produced by other nodes in a BFT consensus mechanism
- Requestor: Application/user whose data state replicators manage. A Requestor makes read and write requests on the state.
Contract Handling Transactions
- Write Request: Initiates contract creation with proposed terms
- Contract Renewal: Extends existing contract terms
- Contract Termination: Ends contract and releases collateral
- Termination Agreement: Confirms contract termination
- Contract Acknowledgement: Confirms data receipt and polynomial commitment of the data
Data Operations
- Read Request: Queries the state with proof requirements
- Update Request: Modifies existing data and commitment
- State retention Proof: Verifies continued data availability
- Read Proof: Proves correct data retrieval
- Data Acknowledgement: Confirms successful data receipt
System Operations
- State Retention Slashing: Penalizes missed state retention proofs
- Read Slashing: Penalizes missed read proofs
- Update Account Info: Modifies account parameters
Security & Incentive Structures for On- & Off-Chain Operations
Each transaction type has specific security considerations and incentive structures:
On-Chain Operations
State retention proofs represent a critical component of our protocol’s security model. Each proof requires state replicators to provide cryptographically valid evidence of data possession, ensuring that data remains available and intact. To maintain network reliability, we’ve implemented a strict deadline system enforced directly by the protocol. State replicators who fail to provide timely proofs face collateral slashing, creating a strong economic incentive for consistent performance.
Read proofs follow a similar security paradigm but focus on verifying correct data retrieval. When a read request is made, the protocol escrows payment for serving the read request until the state replicator provides cryptographic verification of correct data delivery. This creates a trustless environment where neither party needs to rely on the other’s good faith. Missed deadlines result in slashing penalties, ensuring timely responses to read requests.
Off-Chain Operations
Data transfer operations combine off-chain efficiency with on-chain security guarantees. We’ve designed the contract creation process to require successful data transfer, ensuring that state replicators can’t claim responsibility of state management without actually possessing the data. Our system allows multiple state replicators to provide soft acknowledgements, creating a competitive environment that increases reliability.
Side channel communication offers significant efficiency benefits while ensuring data integrity via the read proofs. While this approach substantially reduces on-chain costs, we maintain an on-chain fallback mechanism to guarantee compliance with latency impacts. This hybrid approach provides the efficiency of off-chain operations with the security guarantees of on-chain verification when needed.
Account Structure and State Management Lifecycle
In our account-based model, we detail two primary account types - regular accounts and state management contracts - and explain how they interact through various transaction types. This includes our approach to side channel operations for large data transfers and our mechanism for contract creation and management.
The state management lifecycle is another area where we’ve made significant progress. We’ve described a comprehensive system for proving data availability and implementing slashing mechanisms for non-compliance. This connects directly to our ledger construction, which builds on Mina’s architecture while introducing our novel read ledger for tracking asynchronous requests.
Partially Developed Sections
Several sections contain important foundational work but need further refinement. Our consensus mechanism outlines the use of Algorand’s BFT system and presents two potential approaches for preventing long fork attacks in a succinct chain setting. While the basic framework is established, details are still being worked out.
The connection with Mina and usage from other chains outline our cross-chain vision, but technical specifications for bridges and integration mechanisms are still being worked on.
Areas Under Development
We’re actively working on several components:
Consensus Implementation
- Finalizing our adaptation of Algorand’s BFT mechanism
- Developing concrete solutions for long fork attack prevention
- Defining specific block validation rules and chain quality measures
Economic Model
Designing token economics for sustainable operation:
- Fees based on data size and duration
- Proof verification rewards for validators
- Snark work compensation system
Creating incentive structures for network participants:
- Collateral requirements for state replicators
- Slashing penalties for missed proofs
- Read request payment mechanisms
Developing payment channel mechanisms:
- Escrow systems for read operations
- Contract renewal incentives
Defining specific slashing conditions:
- Missed state retention proof penalties
- Read request timeout penalties
- Invalid proof submission consequences
Cross-Chain Integration
- Building bridge mechanisms for Mina and EVM chains
- Developing a generic chain compatibility layer
- Creating standardized interfaces for cross-chain operations
We Want Your Input
We’re sharing this work-in-progress to engage with the community and gather feedback. We’re particularly interested in your thoughts on:
- Our cryptographic primitives, their properties and guarantees
- Our approach to consensus and proposed solutions for long fork attack prevention in a succinct chain
- The economic model and incentive structures
- Any potential attack vectors or security considerations we should address
- Any uses cases or edge cases for which the design doesn’t work well
We welcome detailed technical discussions and questions. Feel free to reach out through our GitHub discussions.