Case Study: Synchronous Composability and the Need for a Commitment Layer
Reference Problem
Recent research proposes enabling synchronous composability between rollups via realtime proving:
The design introduces a powerful capability:
- atomic execution across L1 and multiple L2s within a single slot
- execution tables capturing all cross-domain state transitions
- validity proofs ensuring correctness of the entire execution bundle
- shared sequencing to guarantee all-or-nothing state transitions
This represents a major step toward unified multi-chain execution.
System Model
At a high level, the system operates as follows:
-
A shared builder/sequencer constructs:
- an L1 block
- multiple L2 blocks
-
It simulates all cross-domain calls and produces:
- an execution table representing ordered state transitions
-
A validity proof is generated for the entire bundle
-
The execution table (or its effects) is submitted to L1 proxies
- allowing nodes to replay the state transition
- without direct access to all underlying L2 states
This yields atomic composability:
all transitions succeed together or none do
Observed Constraints
While the design is robust, it introduces several tightly coupled constraints:
1. Slot-Bound Validity
- Proofs are valid only for a specific L1 slot and pre-state
- Execution correctness is tied to a narrow temporal window
2. Cross-Domain Synchronization
- Nodes may require access to multiple rollups
- or must trust the correctness of bundled execution
3. Atomicity via Infrastructure
- Guarantees depend on:
- shared sequencer behavior
- correctness of the proving system
4. Ephemeral Execution Artifacts
- The execution table exists primarily as:
- an intermediate structure
- consumed by the proving system
- It is not treated as a persistent, referenceable object
Underlying Gap
These constraints point to a deeper architectural question:
What is the canonical, independently verifiable reference for the resulting state?
In the current model:
- truth is defined by the validity proof
However, the system lacks:
a persistent, system-independent commitment to the resulting state itself
OCP Perspective: Commitment to Observed State
The execution table already represents:
a complete, ordered record of observed state transitions across domains
The Observation Commitment Protocol (OCP) suggests elevating this artifact:
- compute a digest of the execution table (or its root)
- anchor that digest on-chain at the relevant slot
- treat it as a first-class, referenceable object
This introduces a minimal invariant:
a specific state artifact existed at time t and can be independently verified
Separation of Concerns
This enables a clean architectural split:
| Function | Mechanism |
|---|---|
| Prove correctness | zk validity proof |
| Anchor result | observation commitment |
| Reference state | committed digest |
| Verify integrity | hash + inclusion + event |
Implications for the Case
Slot Dependence → Slot-Anchored State
- Proofs remain slot-specific
- Commitments provide a persistent reference tied to that slot
Cross-Rollup Sync
- Nodes can verify against:
- a shared committed state root
- without reconstructing all execution dependencies
Atomicity
- Not only enforced by execution
- but reflected in:
- a single committed state artifact
Execution Table Lifecycle
- Transitions from:
- ephemeral proof input
- to:
- portable, verifiable object
Key Insight
Synchronous composability solves:
how to execute atomically across domains
But it leaves open:
what is the canonical object representing the result of that execution?
OCP as a Complementary Layer
OCP does not replace:
- shared sequencing
- realtime proving
- zk validity systems
Instead, it introduces:
a neutral commitment layer for observed state
This allows execution artifacts (like execution tables) to be:
- anchored
- referenced
- verified independently
Takeaway
Execution and proof establish correctness.
But large-scale composability systems also require:
a stable, portable reference to the resulting state
Treating execution artifacts as commitment objects provides that reference.
This suggests a broader architectural pattern:
execution → proof → commitment
Where commitment acts as the bridge between:
- computation
- verification
- and independent observation