iotaledger / iota / 34916874737

70%

Build Type

push

github

Committed by web-flow

Commit Message

fix(iota-types,iota-protocol-config): reject input object versions in or right below the canceled range (#12879)

# Description of change

### Why

When the consensus handler assigns versions for a transaction, it
computes the version of the outputs as one more than the largest input
version, unwraps that increment, and asserts the result is valid.
Versions at or above `Version::MAX_VALID_EXCL` are markers for the
objects of canceled transactions, not regular versions, so an input
named at or above that value, or one below it, makes that computation
fail. That failure halts the node instead of dropping the transaction.

Such a transaction does not reach version assignment today. At
admission, it would be _dropped by the input load_ on honest validators.
At post-consensus validation, it would also be _dropped by the input
load_. Under the P-COOL
[redesign](https://github.com/iotaledger/iota-private/issues/502), the
bookkeeping records would answer the same question and drop it, _but
only after the lookups_. **So this change alters no keep or drop
decision.**

What it adds is an _earlier and cheaper_ route to the same drop. The
transaction bytes are enough to decide it, so the check needs no object
load and no bookkeeping lookup, and it runs at the structural check
before any signature verification, lock lookup, or object read. It is
also independent of the bookkeeping and of where the other checks sit,
which matters because the redesign moves several of them out of the
handler.

### Changes

This PR adds the feature flag `validate_input_object_versions` and sets
it in protocol version 36 on all chains. With the flag set, the validity
check refuses a transaction that names a version at, one below, or above
`MAX_VALID_EXCL` for:

- owned, receiving, and shared call arguments (for a shared argument,
the declared start version);
- gas payment references;
- the object a Move authenticator authenticates.

The existing `InvalidSequenceNumber` error is reused.... (continued)

Coverage Stats

26 of 29 new or added lines in 3 files covered. (89.66%)

2856 existing lines in 83 files now uncovered.

181121 of 258840 relevant lines covered (69.97%)

451427.02 hits per line