Skip to content

feat: gate 256-bit A/B arithmetic behind AT creation version 3#12

Merged
QuickMythril merged 1 commit into
mainfrom
feat/at-v3-creation-gating
Jul 22, 2026
Merged

feat: gate 256-bit A/B arithmetic behind AT creation version 3#12
QuickMythril merged 1 commit into
mainfrom
feat/at-v3-creation-gating

Conversation

@QuickMythril

Copy link
Copy Markdown
Member

Summary

Gates the eight 256-bit A/B arithmetic function codes 0x0140-0x0147 (added in #11) behind AT creation version 3, so a consumer chain can control their availability by AT version rather than having them execute unconditionally the moment the jar is repinned.

  • New minVersion field on FunctionCode; the eight arithmetic codes declare minVersion = 3. The gate is the first statement of FunctionCode.execute() — before any signature/value checks or state mutation — throwing IllegalFunctionCodeException for version-1/2 ATs.
  • MachineState gains creation version 3, byte-identical to version 2 except opcode availability; creation-bytes parse/round-trip accept it.

Why this matters (consensus)

Without version gating, repinning a consumer chain to this jar is a silent flag-day: bytecode containing 0x0140-0x0147 faults on the old jar but executes on the new one. Gating by creation version lets the consumer chain reject version-3 deploys until a coordinated activation height, then allow them — no ambiguous window.

Backward compatibility (proven)

Version-1/2 execution is bit-identical to the current pinned 33df17d jar: for those versions the arithmetic codes fault at the version check exactly as unknown codes did before, charging the same steps, writing no registers, entering the same fatal-error path (only log text differs). Verified by a byte-for-byte machine-state comparison harness against pre-batch 070e22c.

Verification

  • mvn -B clean verify: 211 tests, 0 failures.
  • Mutation-checked the version gate.

⚠️ Merge/consume sequencing — DO NOT repin Core to this jar alone

The dual-model review's finding: gating execution by version is necessary but not sufficient — the consuming chain (qortium-core) must also reject deployment of version-3 creation bytes before the activation height (DeployAtTransaction), or a v3 DEPLOY_AT broadcast pre-activation forks upgraded vs un-upgraded nodes. That Core-side deploy-gate + repin is the companion "phase-2" change. This jar PR is correct in isolation and can be reviewed/merged, but Core must not be repinned to it until the phase-2 deploy-gate lands.

🤖 Generated with Claude Code

…ersion 3

Introduce AT creation version 3, which keeps version 2's page-size
semantics and differs only in function code availability. The eight
256-bit A/B arithmetic function codes (ADD_A_TO_B..DIV_B_BY_A,
0x0140-0x0147) now declare minVersion 3 and FunctionCode.execute()
throws IllegalFunctionCodeException for ATs created with an earlier
version, exactly as an unknown function code would - verified
bit-identical (final packed machine state, steps, PC, balance) against
pre-batch commit 070e22c for raw codes 0x0140-0x0148 under version 2.

Version 3 is accepted by creation-bytes parsing and toCreationBytes,
with a round-trip test. ABArithmeticFunctionCodeTests now run under a
version 3 header, plus explicit version-2 fault tests (mutation-checked:
removing the gate makes them fail).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@QuickMythril
QuickMythril merged commit 0525eec into main Jul 22, 2026
4 checks passed
@QuickMythril
QuickMythril deleted the feat/at-v3-creation-gating branch July 22, 2026 18:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant