Toward a Portable Verification Boundary for Ethereum

Execution Layer Research
1

Toward a Portable Verification Boundary for Ethereum

Ethereum has made major progress on two fronts:

  • Correctness (e.g., ZK proofs): proving computation was executed correctly
  • Data Availability (e.g., DAS, blobs): proving data can be retrieved

But a gap remains:

Verification is still system-dependent.

Most real-world verification workflows still rely on:

  • specific execution environments
  • rollup-specific provers
  • indexers or APIs
  • application-layer semantics

Which means verification does not survive outside the system that produced the result.

The Missing Layer

As AI systems begin generating:

  • legal documents
  • financial records
  • audit logs
  • execution traces

…the requirement changes.

The question is no longer:

“Was this computed correctly?”

It becomes:

“Can any third party independently verify what actually existed—without trusting the originating system?”

Minimal Model

observation ∈ {0,1}*
H = hash(observation)
commitment = inclusion of H in a public ledger

Verification reduces to:

  1. recompute H′ = hash(observation′)
  2. check H′ == H
  3. confirm inclusion of H in a transaction

This yields a portable verification invariant:

If one byte changes, verification fails.

Observation Commitment Protocol (OCP)

The Observation Commitment Protocol defines only this boundary.

It does not define:

  • storage
  • identity
  • authorship
  • canonical encoding
  • execution semantics
  • data availability

It defines:

A system-independent verification boundary
A portable verification artifact: (digest + transaction reference)

Why This Matters

Today:

  • ZK proves correct execution
  • DA proves data is available

But neither alone provides:

a portable artifact that allows independent third-party verification of what actually existed

Without this, verification remains:

  • tied to specific systems
  • dependent on infrastructure assumptions
  • non-portable across contexts

Proposed Framing

Ethereum may be missing a third primitive:

  1. Correctness → “Was it computed correctly?”
  2. Availability → “Can the data be retrieved?”
  3. Verification Boundary → “Can this exact artifact be independently verified later?”

Open Questions

  • Should this boundary be standardized at the protocol level?
  • Is a canonical commitment/extraction interface needed?
  • How should this compose with rollups, ZK systems, and DA layers?
  • Can this reduce reliance on indexers and application-specific verification logic?

Reference Implementation

npx ocp-commit file.txt
npx ocp-verify file.txt

If one byte changes, verification fails.

Repository:

Closing

Ethereum has evolved from a settlement layer into a coordination layer.

The next step may be:

a verification layer—where truth is not inferred from systems,
but independently recomputed and confirmed.