PV11 cost-model governance bootstrap fails with "Plutus cost models update failed: null" (yaci-cli 0.12.0-beta5, -b1)

[nau]

Summary

On bloxbean/yaci-cli:0.12.0-beta5 (and 0.12.0-beta5-b1) the devnet node runs protocol version 11, but the automatic Plutus cost-model governance update fails on first run, so the chain keeps the pre-PV11 (251-entry) PlutusV3 cost model. The node then costs the missing PV11 entries (batch6 builtins, case on non-constructor values) as maxBound, so any PV11-compiled PlutusV3 script fails on-chain with a huge budget overspend, while off-chain evaluators that use proper PV11 costs consider the same transaction valid.

Reproduction

Equivalent to what yaci-cardano-test's YaciCardanoContainer runs:

docker run -d --name yaci-pv11 \
  -e yaci_cli_mode=native -e yaci_store_mode=native \
  -e conwayHardForkAtEpoch=1 -e shiftStartTimeBehind=true \
  -e yaci_store_enabled=true -e ogmios_enabled=true \
  --entrypoint /app/yaci-cli -p 8080:8080 \
  bloxbean/yaci-cli:0.12.0-beta5 \
  create-node -o --slot-length 1 --block-time 1 --start

Container log:

Submitting Plutus cost models governance proposal...
Using Plutus cost models file: plutus-costmodels-v11.json
Plutus cost models update failed: null
Plutus cost models governance proposal failed. Extended builtins may not be available.

(The message text suggests a NullPointerException inside LocalNodeService.updateCostModels.)

Afterwards GET /api/v1/epochs/parameters reports protocol_major_ver: 11 but the PlutusV3 cost model still has only 251 entries (the correct 350-entry model is present in the image at /app/config/plutus-costmodels-v11.json).

Effect

Submitting a transaction with a PV11-compiled PlutusV3 script (e.g. one using case on built-in values) fails with:

ConwayUtxowFailure (UtxoFailure (UtxosFailure (ValidationTagMismatch (IsValid True)
  (FailedUnexpectedly (PlutusFailure ...
The machine terminated part way through evaluation due to overspending the budget.
The budget when the machine terminated was:
({cpu: -9223372036842497312 | mem: -9223372036854734533})
The protocol version is: Version 11

So the devnet cannot execute scripts that target the van Rossem protocol version even though the node itself is PV11.

Environment

• bloxbean/yaci-cli:0.12.0-beta5 and 0.12.0-beta5-b1, arm64, Docker Desktop on macOS
• Observed both via yaci-cardano-test 0.1.0 (Testcontainers) and plain docker run as above

[nau]

Follow-up after more experiments, narrowing this down:

• The NPE is specific to the haskell-only node mode fallback (LocalNodeService.updateCostModels). It reproduces with plain docker run both with and without conwayHardForkAtEpoch=1 / shiftStartTimeBehind=true, on 0.12.0-beta5 and 0.12.0-beta5-b1.
• With nodeMode=companion the Yano bootstrap applies the cost models successfully: /api/v1/epochs/parameters reaches the full 350-entry PlutusV3 cost model (and PlutusV2 reappears, see yaci-store omits PlutusV2 cost model from /api/v1/epochs/parameters (yaci-cli 0.12.0-beta5) #185), and PV11-compiled PlutusV3 scripts execute on the devnet. We validated this with a full integration suite (payments, minting, delegation, Plutus V3 spend scripts with validity intervals).

Two practical notes for anyone hitting this via yaci-cardano-test (Testcontainers):

1. YaciCardanoContainer hardcodes conwayHardForkAtEpoch=1 and shiftStartTimeBehind=true. Combined with nodeMode=companion the devnet never becomes ready (the store API never serves /epochs/parameters), so those env vars must be stripped from the container command in addition to setting nodeMode=companion.
2. Right after companion-mode startup the store can be over a thousand blocks behind the node (the bootstrap mints blocks faster than the store indexes them), so queries briefly return stale UTxOs ("All inputs are spent" on submit). Clients should wait until the store tip catches up with the node tip before using the API. Also, the admin API's startTime is the cluster creation time, which no longer matches the chain's actual slot-zero time after the bootstrap shift - deriving zero time from /blocks/latest (time - slot * slotLength) works in both modes.

We've implemented exactly that in Scalus's testkit (companion mode + env stripping + store-sync wait + slot-zero re-anchoring) and the full integration suite is green against 0.12.0-beta5, so this issue is only about fixing the haskell-only fallback path (or defaulting yaci-cardano-test to companion mode).