Synchronous Composability Between Rollups via Realtime Proving

Layer 2
27

This is a great set of questions — and the follow-up concern about builder centralization is especially important in this model.

Reading both threads together, there are really two layers of issues emerging:

  1. Technical constraints

    • ephemeral, slot-bound proofs
    • non-canonical intermediate “state” representations
    • coordination requirements between operators

  2. Structural risks

    • concentration of power in high-performance builders
    • reliance on real-time proving infrastructure
    • coupling between execution, proving, and inclusion

A common thread

Both sets of concerns seem to converge on a deeper question:

what is the canonical, independently verifiable reference for what actually happened?

Right now, that role is effectively played by:

  • the validity proof
  • the execution table
  • and the sequencing context

But all three are:

  • tightly coupled
  • time-sensitive
  • and dependent on specialized infrastructure

A possible separation

One way to reduce this coupling is to separate:

  • proof of correctness (zk / execution layer)
    from
  • commitment to resulting state (reference layer)

The execution table already represents:

a complete, ordered record of cross-domain state transitions

Instead of existing only inside the proving pipeline, it could also be treated as a commitment artifact:

  • hash the execution table (or its root)
  • anchor that digest on-chain at the relevant slot
  • make it independently referenceable

Why this matters for the concerns raised

For the technical questions

  • Ephemeral proofs
    → paired with persistent, slot-anchored commitments

  • Non-standard intermediate state
    → commitment does not require canonical STF compatibility
    → only a stable digest of observed transitions

  • Operator coordination
    → coordination produces a single committed artifact
    → not just a proof tied to a specific builder

For the structural risks (builder centralization)

If:

  • only a small set of builders can produce valid proofs in time

then:

they effectively control what becomes “truth” in the system

A commitment layer introduces a subtle but important shift:

  • builders may still compete to produce proofs
  • but the resulting state becomes a publicly anchored artifact
  • independently referenceable and verifiable

This reduces reliance on:

  • who produced the proof

and strengthens:

  • what was actually committed

Framing

This does not replace realtime proving or shared sequencing.

It introduces a complementary layer:

commitment to observed state as a first-class primitive

I have been exploring this more formally here:

:backhand_index_pointing_right: Observation Commitment Protocol (OCP) v1.0.0 - #3 by DamonZwicker

At a high level:

  • execution → produces state
  • proof → establishes correctness
  • commitment → anchors the result

Open question

If execution tables already represent the full cross-domain state transition:

should they also be treated as canonical commitment objects, not just inputs to a proving system?

It seems this separation could help reduce both:

  • technical fragility (slot dependence, replay complexity)
  • structural risk (builder concentration as a gatekeeper of truth)

Curious how others thinking about realtime proving view this distinction.