I am not 100% sure this counts as a bug, perhaps it's something we need to improve, but I think currently the result would be undesirable behavior.
I believe that right now if we change LATEST_MAX_TRANSACTION_SIZE, we will run into an issue where if this value changes, then nodes running an old version could refuse transactions from newer upgraded nodes, or vice versa, depending on whether the value increased or decreased.
This was surfaced in #4344 (review)
As mentioned in the comment linked above, we likely need to make the size check more robust - perpahos something along these lines: not pick the latest max transaction size, but:
- in the fn propose_batch flow use the one at ConsensusVersion(current_height)
- in the fn process_batch_propose flow allow the max size from max(max_transaction_sizes[(ConsensusVersion(current_height-100))..]
More careful thought is needed to fully flush this out.
I am not 100% sure this counts as a bug, perhaps it's something we need to improve, but I think currently the result would be undesirable behavior.
I believe that right now if we change
LATEST_MAX_TRANSACTION_SIZE, we will run into an issue where if this value changes, then nodes running an old version could refuse transactions from newer upgraded nodes, or vice versa, depending on whether the value increased or decreased.This was surfaced in #4344 (review)
As mentioned in the comment linked above, we likely need to make the size check more robust - perpahos something along these lines: not pick the latest max transaction size, but:
More careful thought is needed to fully flush this out.