solana-labs
[backburner] ESLint rule for detecting possible integer overflows
This rule is not as necessary as I initially thought, because any token amount shifted by 6 digits (or more) will just be a safe integer. It's still worthy of consideration but I'm putting it on pause for now.
The final transaction signature (aka txid) itself should be sufficient for this -- the signature incorporates the recent blockhash: https://docs.solana.com/developing/programming-model/transactions#recent-blockhash
Any transaction that is completely identical to a previous one is rejected
Assuming we use a mutex (#2) to store signatures we've seen, I think we can use this to uniquely represent a transaction. I don't think we need a state for it, as it's either in flight, or it's on chain (confirmed or rejected).
I expect that simulation of a duplicate signature should fail, but this should be tested.
904343dbe0668dccde001b2a8359f254ecf70e32 from #3 has a possible implementation of this (with the same caveats as #2) but at least here it's not necessary (any such transaction will already be locked out by its source token account).
Any transaction that is completely identical to a previous one is rejected
Oh, that's awesome. That gives us idempotence at the chain-level.
If the presence of a recent blockhash (or nonce info) in the transaction implies that a hash of the transaction itself is an idempotence token for the transaction, how about we use that hash of the transaction itself as a lock for Octane?
We could detect the presence of any such lock in middleware which would save Octane from doing any work at all. No validating the transaction, no validating the transfer; nothing.
To prevent that list from growing indefinitely, we could set a TTL roughly as long as it takes for the recent blockhash to age out (ie. become old enough to fail the getFeeCalculatorForBlockhash check).
Yeah, true. We can check it up front without signing just by hashing it. We could also just sign it and use the signature if it passes verification, and then do the real validation afterward.
how about we use that hash of the transaction itself as a lock for Octane?
Implemented in #3: https://github.com/solana-labs/octane/blob/8479af3e78a4a613006405c535ba052aaac5b2f7/src/api/transfer.ts#L17-L19
Let me know what you think!