iotaledger / iota / 34550027955

70%

Build Type

push

github

Committed by web-flow

Commit Message

fix(iota-core,iota-protocol-config): use protocol config verifier limits in post-consensus validation (#12842)

# Description of change

### Why

Post-consensus validation (P-COOL, Check #5) ran the metered bytecode
verifier with each validator's own `verifier-signing-config` from its
node YAML. A validator with a non-default setting drops a package
publish that the other validators keep, so it builds a different
checkpoint and halts on fork detection.

### Changes

This PR adds and enables the feature flag
`pcool_verifier_limits_from_protocol_config` in protocol version 35 on
all chains: when the flag is set (_and the P-COOL flow is on_),
post-consensus validation meters published packages with the protocol
config's verifier limits instead of the node's own config. The flag is
read only by post-consensus validation, which runs only under the P-COOL
flow, so it needs no chain condition: it is inert on `mainnet` and
`testnet`, where the flow is off, and takes effect on any chain that
enables the flow later.

The protocol constants `max_verifier_meter_ticks_per_function`,
`max_meter_ticks_per_module` and `max_meter_ticks_per_package` have been
16M since version 1, but nothing read them: signing meters packages with
the node config, whose defaults are 2.2M. This PR makes these constants
the post-consensus limits and sets them to 2.2M, so post-consensus
validation enforces the same limits signing enforces on a validator with
the default `verifier-signing-config`. It also adds
`max_meter_ticks_regex_reference_safety` (2.2M) for the one node config
limit that had no protocol constant. **Nothing changes below version
35.**

> [!NOTE]
> Signing, admission, dry-run, and the simulators keep using the node
config; only post-consensus validation passes the protocol config.

## Links to any relevant issues

Closes https://github.com/iotaledger/iota-private/issues/504. Part of
https://github.com/iotaledger/iota-private/issues/502.

## How the change has been tested... (continued)

Coverage Stats

87 of 90 new or added lines in 9 files covered. (96.67%)

457 existing lines in 26 files now uncovered.

180422 of 258100 relevant lines covered (69.9%)

455115.55 hits per line