Consensus does not check transaction chain ID or expiry #4308
Labels
C-bug
Category: a bug
consensus-breaking
breaking change to execution of on-chain data
E-easy
Effort: Easy
_P-critical
Priority: critical
_P-V1
Priority: slated for V1 release
Describe the bug
A transaction which contains a mismatched chain ID or an expired expiry height is currently accepted by the chain.
To Reproduce
I have not reproduced this on a testnet, but there is currently, to my ability to determine, no code which checks these properties. It should be in the historical check method right next to the FMD parameters check, per @erwanor.
Expected behavior
If a transaction is submitted with exactly the current chain ID, it should be accepted. Otherwise, it should be rejected. Note that the empty chain ID string
""
should not be treated specially here. The empty chain ID should always cause a transaction to fail, because there will never be a chain with an empty chain ID. This is distinct from the current RPC behavior of "failing open" and accepting requests with an empty chain ID, so that you can request information without first acquiring the chain ID.If a transaction is submitted with a zero expiry height or an expiry height greater than the current height, it should be accepted. Otherwise, it should be rejected.
Additional context
Expiry height was at one point going to be converted to time-based, but this was closed out because of proto stabilization. It's my opinion that we should enforce the field, rather than leaving it in a state that is documented as being enforced, but not enforced. The alternative would be to change the documentation to deprecate it.
This is technically a consensus-breaking change because it makes previously-valid transactions invalid, although no client tooling currently produces such transactions.
The text was updated successfully, but these errors were encountered: