📎Architecture
Explaining the architecture of continuum - verifiable sequencing
Core Architecture
1. Continuous-Time Ledger
Continuum replaces discrete blocks with a continuous-time transaction log. Each transaction is anchored to a specific timestamp, determined by a VDF-based clock that produces a "tick" every 100 µs. This fine-grained resolution ensures that transactions are processed in the order they are received, eliminating the ability of a sequencer to arbitrarily reorder transactions within a block. The ledger is a hash-linked chain of state commitments, where each commitment incorporates the transaction, the previous ledger state, and the VDF output for the corresponding tick.
Key Feature: Transactions are timestamped and committed in real-time, ensuring FIFO ordering with sub-millisecond precision.
Benefit: Removes opportunities for MEV by enforcing strict time-based ordering, preventing frontrunning or transaction exclusion based on content.
2. Verifiable Delay Functions (VDFs)
VDFs serve as the cryptographic backbone of Continuum’s decentralized clock. A VDF is a computationally intensive function that takes a fixed amount of time to compute but can be verified quickly. In Continuum, the VDF generates a new output every 100 µs, creating a verifiable sequence of ticks. Each tick is linked to the previous one through a hash chain, ensuring that no party can manipulate the timeline without performing an infeasible amount of sequential computation.
Mechanism: For each tick ( t ), the sequencer computes the VDF output ( y_t ) from the previous output ( y_{t-1} ), using a fixed number of sequential steps (e.g., modular squarings). The output is accompanied by a proof ( \pi_t ) that allows nodes to verify its correctness efficiently.
Security: The sequential nature of VDFs ensures that even a malicious sequencer cannot "speed up" the clock or forge earlier timestamps without detection.
Hardware Adaptation: Continuum adjusts the VDF difficulty dynamically to maintain a 100 µs tick rate as hardware improves, ensuring long-term scalability.
3. Transaction Commitment and Hash-Linked Chain
Each transaction ( T_i ) is anchored to a VDF tick ( t_i ). The sequencer creates a state commitment ( C_i ) by hashing the previous commitment ( C_{i-1} ), the transaction ( T_i ), and the VDF output ( y_i ):
[ C_i = H(C_{i-1} | T_i | y_i) ]
where ( H ) is a cryptographic hash function (e.g., SHA-256). This forms a hash-linked chain that ensures the integrity of the transaction order and ledger state. Any attempt to reorder or exclude a transaction would break the hash chain, making it detectable by verifying nodes.
Monotonic Timestamps: Transactions must have strictly increasing timestamps (( t_i < t_{i+1} )), ensuring no transaction can be backdated.
No Postdating: The sequencer cannot assign a future timestamp to a transaction, as timestamps must align with real-world time (within network propagation bounds).
4. Separation of Sequencing and Execution
Continuum is designed as a modular sequencing layer, decoupling transaction ordering from execution logic. It takes transactions as opaque inputs, assigns timestamps, and produces an ordered log with state commitments. The execution of these transactions (e.g., updating an EVM state or matching DEX orders) is handled by external layers, making Continuum compatible with various blockchain systems.
Example Use Cases:
Ethereum-Compatible Systems: An Ethereum client can process Continuum’s ordered log to update account balances or execute smart contracts.
Decentralized Exchanges (DEXes): A matching engine can execute trades in the timestamped order, ensuring fairness.
Advantage: This modularity allows Continuum to serve as a universal sequencing layer for Layer-1 blockchains, Layer-2 rollups, or decentralized applications (DApps).
5. Commit-Reveal Scheme for Enhanced Fairness
To prevent intra-tick manipulation (e.g., content-based reordering within the same 100 µs tick), Continuum supports an optional commit-reveal scheme. Users can encrypt transactions with a time-locked key derived from the VDF, ensuring the sequencer cannot view the transaction content until it is committed to the log.
Process:
A user (e.g., Alice) generates a random secret ( s ) and computes a VDF output ( p = \text{VDF}(s) ) after ( \delta ) ticks.
She derives a symmetric key ( K = H(p) ), encrypts the transaction ( T ) as ( C = \text{Encrypt}(T, K) ), and submits ( C ) with a commitment to ( s ).
The sequencer includes ( C ) in the log at tick ( t ), without knowing ( T ).
At tick ( t + \delta ), the VDF output ( p ) becomes computable, revealing ( K ) and thus ( T ), which is then executed.
Benefit: Prevents content-based censorship or frontrunning, as the sequencer cannot manipulate transactions it cannot decrypt.
Last updated