Tx expiration

[grarco]

Closes #1009

Based on #1106

Adds an optional expiration field to struct Tx to prevent transactions from being applied indefinitely.

• Adds expiration field to struct Tx
• Adds mempool_validate check against last committed block time
• Adds process_proposal check against the proposed block time or, if missing, the last committed block time
• Adds prepare_proposal check against the proposed block time (if missing accept txs as assumed to have been checked by mempool_validate)
• Unit tests
• Updates client to allow for a new expiration optional arg

[grarco]

pls update wasm

[batconjurer]

This is unfortunately not documented in main, but the idea of these numbers is that past a certain threshold, we reject the block. In this branch, those are error codes >=4. However, we can't reject an entire block if we get the InvalidDecryptedChainId error since we have to include all decrypted txs in order. So its number should be lowered below the critical threshold

[batconjurer]

I think the same is also true of ExpiredDecryptedTx

[batconjurer]

Ah here. If the ordering of the errors is fixed, we just need to change the 3 to a 5 in the old code

[grarco]

I think I'm missing something, what do you mean when you say "in the old code"?

[batconjurer]

status: if tx_results.iter().any(|res| res.code > 3) {
                ProposalStatus::Reject as i32
 } else {
            ```

[grarco]

Ah, I think I see what you mean. I've changed that code to use the enum variants because I was struggling to keep track of the error codes and thought that using the variants was more readable. Would you prefer to revert to using the codes instead?

[batconjurer]

We rely on it heaving in eth-bridge-integration, so I thinks it's easier for you to make this change than us.

[batconjurer]

We also document it a lot better and add helper functions, so it's not such a secret design choice anymore.

[grarco]

Actually, in this PR I've also changed process_proposal to reject the block in more cases: in particular to reject a block even in case of an InvalidTx or InvalidSig which we were not doing before. Does this look ok to you? In theory, the block proposer should be able to verify these at block construction time. So in essence the threshold could stay at 3 like before if I reorder the variants correctly in the enum

[batconjurer]

Yep, sounds good

[batconjurer]

Oh god. What did fmt do here??

[batconjurer]

Also, Dercrypted. 😆