EIP-0045: Native STARK Proof Verification Opcode

[a-shannon]

Summary

EIP-0045 specifies VerifyStark (0xB9), a consensus-native ErgoScript
operation that verifies one bounded STARK receipt in one ordinary transaction.
The rewrite replaces the original parameterized research design with a stable
four-child ABI and immutable, content-addressed verifier profiles activated by
authenticated network generations.

This PR fixes the architecture and closes the first profile's B1-B3 identity.
It does not propose network activation; B4-B8 remain open.

Stable ABI

verifyStark(
  proofChunks:         Coll[Coll[Byte]],
  applicationPayload: Coll[Byte],
  programId:           Coll[Byte],
  profileId:           Coll[Byte]
): Boolean

There is no vmType, costParams, query count, Merkle depth, script-selected
cryptographic parameter, or proof-declared work estimate.

Main design decisions

• Exact statement binding. Ergo constructs a domain-separated statement
  binding chain, profile, guest program, executing contract, and application
  payload. When an application relies on state, replay, amount, destination,
  nullifier, or aggregate-root fields, the contract must bind those fields to
  the actual Ergo transaction and the guest must bind its proof to the exact
  payload fields it relies on. Neither check substitutes for the other.
• Immutable compiled profiles. Each profile commits to one proof grammar,
  verifier algorithm, binary-data artifact, and transport/payload shape.
  profileId selects a vetted verifier already compiled into a node release;
  a profile cannot install runtime data, native code, or a dynamic plugin.
  A new profile still requires an authenticated network activation. A later
  zkVM or verifier revision may use a new profile ID without changing the
  opcode only if it preserves every global invariant: the four-child ABI,
  ErgoStatementV1, bounded direct transport, precharge order, lifecycle and
  quarantine, v0-v4+ fallback, exception taxonomy, and monotone costing.
  Incompatible global semantics require a separate EIP or opcode.
• Fixed precharge. Lifecycle and the complete fixed profile charge are
  resolved before heavy children, parsing, or cryptography. Cost is not derived
  from untrusted proof or script declarations. A profile must prove equal
  bounded cost across every accepted proof shape or price the worst accepted
  shape; shape-dependent charging requires a different schedule and evaluation
  design.
• Fail-closed lifecycle. Profiles are absent, active, or irreversibly
  quarantined in an authenticated generation snapshot. Missing host support is
  an unavailable capability, never a permissive fallback.
• Whole-input future fallback. v0-v3 preserve historical behavior while
  structurally rejecting the new opcode. v4+ completes deterministic recursive
  materialization over the entire tree, including dead branches, before
  evaluation can begin.
• Separate admission defence. Consensus metering protects block
  validation; bounded mempool/API concurrency, memory, queueing, and replay
  controls protect validators from unpaid invalid-proof work.

First profile candidate

The initial profile targets stock RISC Zero v3.0.5 succinct receipts using
BabyBear/Ext4/Poseidon2. It accepts only the reviewed outermost shipping
controls: lifts for segment exponents 15 through 22, join, and resolve. The
allowlist is outermost-only; exact final claim equality and empty assumptions
remain mandatory.

Its current security estimate is about 95 conjectured classical bits under the
stated toy model, below 128. This is model-dependent, is not a proven lower
bound, may be materially lower under more conservative analysis, and is not an
end-to-end post-quantum-security claim.

Closed B1-B3 values:

• algorithm artifact: 29,773 bytes;
• binary-data artifact: 65,119 bytes;
• manifest: 458 bytes, SHA-256
  deffb2cb231f98a348cbd166d5f1c43315661ccd8bd212099f16f238d0fe8946;
• profile-ID preimage: 485 bytes;
• profileId:
  23c4a123ffb33a1c8db89436fe0e7972bd8e4e289459ee5fd71be5440607d383.

The exact package is embedded under eip-0045/profile-v1/, so review of B1-B3
does not depend on an unpublished external repository. Its Apache-2.0 license
and notice accompany the adapted RISC Zero material and are excluded from the
identity inputs.

The generic V1 statement format has an arithmetic payload ceiling of
2_147_483_488 = 2^31 - 1 - 159 bytes. Every compiled profile must choose and
enforce a separately reviewed, resource-safe limit at or below that ceiling;
the first profile remains fixed at 16,384 bytes.

Remaining activation gates

• B4: one immutable identity-bound archive containing exactly eleven
  ordered positives: lifts 15-22, terminal join, explicit-root terminal
  resolve, and zero-root resolve followed by terminal join, plus isolated
  negatives. The unpublished foundation fixes 62 groups and 254 executions;
  exact schema publication, digest binding, 254 materialization identities,
  and 508 agreeing Rust/JVM results remain open;
• B5: measured JVM consensus charge and resource envelope;
• B6: authenticated activation generation, transition manifest, and
  validation update;
• B7: hermetic host/guest/OCI locking; two clean reproductions of
  deterministic artifacts and archived verification results; fresh
  challenge-bound shipping-prover receipts for all eleven B4 shapes without
  requiring proof-byte equality; Rust/JVM differential agreement; and
  independent consensus and cryptographic reviews;
• B8: a shared 262,144-byte standalone relay/API/mempool policy deployed
  before activation (without constraining received/historical block decoding),
  admission controller, block/mempool/candidate/reorg integration, stress
  tests, and testnet evidence.

Review focus

1. Global/profile/transition authority split.
2. Four-child ABI and exact contract/guest statement binding.
3. Lifecycle, quarantine, compiled-profile activation, and fixed-precharge
   rules.
4. v0-v3 compatibility and v4+ whole-input preflight.
5. Initial profile's exact shipping-prover boundary and explicit nonclaims.

Implementation: ergoplatform/sigmastate-interpreter#1116

[a-shannon]

Superseded: the 159-test Poseidon1/Ext16 prototype summary no longer describes this PR. Current scope and status are in the PR body and implementation PR #1116.