Add ERC: AI Inference Proof Verification Interfaces

[JimmyShi22]

ERC-8274 v0.2 — Two-layer inference verification interfaces

This PR introduces ERC-8274, defining three minimal abstract interfaces organized into two composable layers for on-chain AI inference proof verification.

What this ERC defines

IProofVerifier — inner algorithm layer, implemented by proof system providers (ZK teams, TEE vendors, oracle networks, attestation gateways). Stateless. Answers: "is this proof cryptographically valid for this input and output?"

function verify(bytes32 inputHash, bytes32 outputHash, bytes calldata metadata, bytes calldata proof) external returns (bool);
function proofSystem() external view returns (string memory);  // e.g. "zk/sp1", "attestation/judgment"
function proofProfile() external view returns (bytes32);       // deployment-specific fingerprint

IAgentVerifier — outer application layer, implemented by agent developers. Stateful. Wraps one or more IProofVerifier(s). Answers: "for this task, was this agent authorized and does the proof confirm it?"

function verify(bytes32 taskId, bytes32 agentId, bytes32 inputHash, bytes32 outputHash, bytes calldata proof)
    external returns (bool valid, bytes32 verificationDigest);

event VerificationCompleted(bytes32 indexed taskId, bytes32 indexed agentId, bytes32 indexed verificationDigest,
    bool valid, bytes32 inputHash, bytes32 outputHash, bytes32 agentProofProfile);

IAgentVerifiable — declaration layer for settlement contracts; declares which IAgentVerifier is in use and emits AgentVerifierUpdated on any change.

Key design decisions

Two-layer separation. Proof system providers implement IProofVerifier without knowing the application context. Agent developers implement IAgentVerifier without being coupled to a specific proof system. Settlement contracts call IAgentVerifier without knowing the backend. Each layer is independently deployable and auditable.

verificationDigest commitment. IAgentVerifier.verify() returns a bytes32 digest computed from keccak256(abi.encode(taskId, agentId, inputHash, outputHash, valid, agentProofProfile)). VerificationCompleted carries all preimage fields alongside the digest, making every record independently verifiable by any observer without querying live contract state — following OCP's recompute → compare → confirm model.

proofSystem() paradigm taxonomy. Four paradigms are named: zk, op, tee, attestation. Within attestation, three variants are named: multisig, wyriwe, judgment. This allows consumers to inspect and reason about trust assumptions without reading implementation internals.

metadata ownership. Invariant deployment configuration (circuit key, enclave hash, signer registry address) is stored in IAgentVerifier and passed to IProofVerifier on each call. Settlement contracts never encode or see it.

OCP alignment. VerificationCompleted is designed so any observer can apply OCP's three-step procedure (recompute → compare → confirm inclusion) independently, covering both on-chain and off-chain verification contexts.

Input provenance. IProofVerifier.verify()'s inputHash maps directly to WYRIWE's triple-commitment input_hash field. WyriweProofVerifier is already deployed on mainnet and implements IProofVerifier directly.

Proof anchoring. verify() confirms cryptographic validity but not when the proof was generated. The proof anchoring rationale section describes how an on-chain anchor registry closes this gap at the IAgentVerifier layer.

Note on cross-references: OCP, WYRIWE, and the proof anchoring work are referenced by name in the current spec rather than by ERC number. The corresponding PRs have not yet been formally merged, so direct ERC links would fail CI checks. References will be updated once those PRs land.

Reference implementation (3-layer stack)

1. SP1ProofVerifier (Layer 1 — IProofVerifier) — ZK backend; decodes programVKey from metadata; proofProfile() includes VERIFIER_HASH to fingerprint the specific verifier deployment.
2. AgentVerifier (Layer 2 — IAgentVerifier) — wraps SP1ProofVerifier; stores metadata and authorized agent set; enforces single-use taskId; computes and emits verificationDigest.
3. ProofEvaluator (Layer 3 — ERC-8183 settlement) — implements IAgentVerifiable; calls IAgentVerifier.verify() at settlement time; forwards verificationDigest as job.reason.

Pre-submission alignment

• Damon Zwicker (OCP author) — the OCP primitive and recompute → compare → confirm framing shaped the VerificationCompleted event design; discussed in the Ethereum Magicians thread.
• Tiago Merlini (WYRIWE, ERC-8004) — the WYRIWE input provenance work clarified the inputHash contract; WyriweProofVerifier provides a ready-made IProofVerifier backend; attestation/wyriwe is a named proofSystem() variant.
• Vincent Wu (ERC-8263) — the proof anchoring layer closes the temporal gap that pure cryptographic verification leaves open; discussed and confirmed in the Ethereum Magicians thread.

Changes from v0.1

• Replaced single-interface design (IProofVerifier + IVerificationMethod) with two-layer architecture (IProofVerifier + IAgentVerifier + IAgentVerifiable)
• verify() is no longer view; returns (bool valid, bytes32 verificationDigest) instead of bool
• Replaced name() + version() with proofSystem() (paradigm/variant string) and proofProfile() (deployment fingerprint)
• Added VerificationCompleted event with agentProofProfile and full preimage fields
• Added verificationDigest commitment following OCP
• metadata ownership clarified: stored in IAgentVerifier, never exposed to settlement contracts
• Reference implementation updated to 3-layer composable stack
• Added Composability in Practice section (ERC-8183 and WYRIWE integration examples)

Discussion

Ethereum Magicians thread: https://ethereum-magicians.org/t/erc-8274-ai-inference-proof-verification/28083

[eip-review-bot]

File ERCS/erc-8274.md

Requires 1 more review from Editors: @g11tech, @jochem-brouwer, @samwilsn, @xinbenlv

[JimmyShi22]

@damonzwicker all check passed

[JimmyShi22]

@abcoathup Hi editor, the ERC draft is fully prepared and ready for the official review and merging process. Thank you for your assistance with the next steps—your support is much appreciated!

[github-actions]

The commit 10ed575 (as a parent of 6c9f1d2) contains errors.
Please inspect the Run Summary for details.