That behavior is actually safe because it should have no observable difference to the validation rules of the blockchain and therefore to consensus. Note that if an expired entry in the de-duplication exists in the database of one correct node and not in another correct node (both at the same head block), they should both behave the same in terms of accepting or rejecting transaction. If during validation at the first node of a transaction in the head block there is a conflict in transaction IDs detected with an entry in the de-duplication index in which that entry is not present on the second node, then: it is virtually impossible (due to the nature of the cryptographic hash) for the transaction to have an expiration different than the one in that entry; the expiration must necessarily be one that is strictly less than the head block's timestamp (meaning it has expired); and, therefore the transaction would be rejected even before getting to the duplicate check due to it being an expired transaction.
https://github.com/AntelopeIO/leap/blob/a8d48d406082cc6ec5ef18dddd30b5589b3e870a/libraries/chain/transaction_context.cpp#L269-L276https://github.com/AntelopeIO/leap/blob/a8d48d406082cc6ec5ef18dddd30b5589b3e870a/libraries/chain/controller.cpp#L3337-L3341
However, if one is probing the state as of a particular block of the de-duplication index in a manner that should be viewed as the consensus state, we would need to ignore any entries that would be considered expired as of the timestamp of the block from which we are probing the state. In particular, this means that snapshot generation and integrity hash computation must avoid exporting or incorporating any expired entries in the de-duplication index. This is required to meet the goals of a bitwise identical representation of the portable snapshot and the consistency requirements of the integrity hash.
The simplest solution to address the portable snapshot and integrity hash issues is to just call clear_expired_input_transactions without any deadline bound to ensure that all expired entries have actually been removed prior to iterating through the indices to calculate the integrity hash or generate the portable snapshot.
heifner
commented
1 year ago
clear_expired_input_transactionsis non-deterministic despite modifying chainbase state which is used to drive the blockchain protocol rules. https://github.com/AntelopeIO/leap/blob/a8d48d406082cc6ec5ef18dddd30b5589b3e870a/libraries/chain/controller.cpp#L2400-L2406That behavior is actually safe because it should have no observable difference to the validation rules of the blockchain and therefore to consensus. Note that if an expired entry in the de-duplication exists in the database of one correct node and not in another correct node (both at the same head block), they should both behave the same in terms of accepting or rejecting transaction. If during validation at the first node of a transaction in the head block there is a conflict in transaction IDs detected with an entry in the de-duplication index in which that entry is not present on the second node, then: it is virtually impossible (due to the nature of the cryptographic hash) for the transaction to have an expiration different than the one in that entry; the expiration must necessarily be one that is strictly less than the head block's timestamp (meaning it has expired); and, therefore the transaction would be rejected even before getting to the duplicate check due to it being an expired transaction. https://github.com/AntelopeIO/leap/blob/a8d48d406082cc6ec5ef18dddd30b5589b3e870a/libraries/chain/transaction_context.cpp#L269-L276 https://github.com/AntelopeIO/leap/blob/a8d48d406082cc6ec5ef18dddd30b5589b3e870a/libraries/chain/controller.cpp#L3337-L3341
However, if one is probing the state as of a particular block of the de-duplication index in a manner that should be viewed as the consensus state, we would need to ignore any entries that would be considered expired as of the timestamp of the block from which we are probing the state. In particular, this means that snapshot generation and integrity hash computation must avoid exporting or incorporating any expired entries in the de-duplication index. This is required to meet the goals of a bitwise identical representation of the portable snapshot and the consistency requirements of the integrity hash.
The simplest solution to address the portable snapshot and integrity hash issues is to just call
clear_expired_input_transactionswithout any deadline bound to ensure that all expired entries have actually been removed prior to iterating through the indices to calculate the integrity hash or generate the portable snapshot.