Unify compute-budget system for heavy opcodes

[msinkec]

The Arkade VM enforces script size (MaxScriptSize = 10000), stack size (MaxStackSize = 1000), and BIP-342's per-input sigops budget — but it does not enforce a per-script op-count limit. BIP-342 dropped that limit on purpose.

That trade-off is sound for plain Bitcoin tapscript, where the per-call cost of every opcode is small or already charged against the sigops budget.

Several heavy opcodes added to Arkade do not yet fit that model. They have per-call costs orders of magnitude above other opcodes, and the engine charges nothing against the sigops budget for them. They are only constrained by 10 KB script-size cap.

We should pick a design for a compute-budget brake.

What the Engine Charges Today

Only the BIP-342 sigops budget exists, defined at pkg/arkade/engine.go:48-77:

const sigOpsDelta = 50

func newTaprootExecutionCtx(inputWitnessSize int32) *taprootExecutionCtx {
    return &taprootExecutionCtx{
        sigOpsBudget: sigOpsDelta + inputWitnessSize,
    }
}

Starting budget per input is 50 + witness_size_bytes; each charged signature opcode deducts 50.

Charged opcodes today, via callers of tallysigOp():

• OP_CHECKSIG / OP_CHECKSIGVERIFY — pkg/arkade/opcode.go:1782
• OP_CHECKSIGADD — pkg/arkade/opcode.go:1869

Notably not charged, despite being non-trivial:

• OP_CHECKSIGFROMSTACK (~84 µs / call)
• OP_ECMULSCALARVERIFY
• OP_TWEAKVERIFY
• OP_ECADD
• OP_ECMUL
• OP_ECPAIRING
• OP_MODEXP

#79
#80

Measured Per-Call Costs

Apple Silicon, single-threaded:

Operation	Per-call	vs Schnorr verify
OP_ECADD (any curve)	1.5 – 3.7 µs	~0.03×
OP_ECMUL (256-bit scalar, any curve)	25 – 45 µs	0.3 – 0.5×
Schnorr verify (~OP_CHECKSIGFROMSTACK)	84 µs	1×
OP_ECPAIRING (1 pair)	314 µs	3.7×
OP_ECPAIRING (16 pairs, current max)	2.04 ms	24×
OP_MODEXP (capped at 64-byte operands today)	~60 µs (extrap.)	~0.7×
OP_MODEXP if cap were lifted (520-byte operands)	13.5 ms	167×

OP_ECPAIRING already has a hard cap:

• maxECPairingCount = 16
• pkg/arkade/ec_ops.go:30

OP_MODEXP has a 64-byte operand cap added purely as a DoS brake:

• pkg/arkade/opcode.go

Both are ad-hoc per-opcode caps rather than a system the next heavy opcode can plug into.

Worst-Case Script CPU Today

Given MaxScriptSize = 10000, no op-count cap, and the per-call costs above, a maximally adversarial script can drive:

• ~5,000 OP_ECADDs → ~15 ms CPU per input
• ~5,000 OP_ECMULs at 256-bit → ~200 ms CPU per input
• ~5,000 max-pair OP_ECPAIRINGs → ~10 s CPU per input ❗
• ~5,000 OP_MODEXPs with the current 64-byte cap → ~300 ms CPU per input
• ~5,000 OP_MODEXPs if uncapped → ~67 s CPU per input ❗

[arkanaai]

Codebase context

Good write-up — all code references check out. A few additions:

PRs #79 and #80 are the immediate trigger

Both are currently OPEN and add exactly the opcodes listed as uncharged:

• PR Implement OP_ECADD, OP_ECMUL, OP_ECPAIRING #79 — OP_ECADD, OP_ECMUL, OP_ECPAIRING
• PR Implement OP_MODEXP #80 — OP_MODEXP

Neither PR adds budget charges. Until a compute-budget system lands, merging either PR in their current form would add the DoS vectors described below to production. This issue should be treated as a merge prerequisite for both.

Worst-case DoS exposure today (pre-#79/#80)

Even without the new opcodes, OP_ECPAIRING has a hard cap but no budget charge. With maxECPairingCount = 16 (ec_ops.go:30) and no sigops deduction, a 10 KB script can embed ~5,000 16-pair calls. At 2.04 ms each that is ~10 s CPU per input. The ad-hoc cap on OP_MODEXP (opcode.go, 64-byte operand ceiling) is the only thing keeping that path under ~300 ms; lifting the cap to 520 bytes (Bitcoin's max) would push it to ~67 s per input.

Design options

Three common approaches for VMs in this space:

1. Extend the existing sigops budget — charge each heavy opcode a fixed number of "virtual sigops" calibrated so worst-case CPU ≈ 1 Schnorr verify (84 µs). Fits the existing tallysigOp() path at engine.go:48 with no interface change.

2. Separate opcode weight budget — new opWeightBudget field in taprootExecutionCtx (alongside sigOpsBudget), charged independently. Cleaner separation; allows per-opcode weights to be tuned without touching sigops semantics.

3. Per-script wall-clock timeout — a context deadline on execute(). Simple but non-deterministic across hardware; not suitable for consensus-critical validation.

Option 1 is the least invasive. Option 2 is cleaner and easier to extend as new opcodes are added (just register a weightTable entry). Option 3 is unsuitable for consensus.

Acceptance criteria (suggested)

• All opcodes in the "notably not charged" list above have a budget entry
• Worst-case single-input CPU bounded ≤ ~2× Schnorr verify (≤ ~170 µs) or explicit rationale for a higher bound
• Budget constants documented with the benchmark numbers that produced them
• A unit test that constructs a maximally adversarial script and asserts ErrScriptTooBig (or equivalent budget exhaustion) before it reaches the per-pair/per-byte caps
• PRs Implement OP_ECADD, OP_ECMUL, OP_ECPAIRING #79 and Implement OP_MODEXP #80 are updated to register charges before merge