Investigate pros/cons of deduping EthereumTransactions (before consensus) based on the contained Ethereum transaction itself

[david-bakin-sl]

If you submit the same Ethereum transaction twice, wrapped in different EthereumTransactions (with different transaction id) then they will both go through consensus. The second one through consensus will fail due to an invalid nonce. So the behavior is correct: only one of the two identical Ethereum transactions executes. But you can notice in the record stream (e.g., looking at it through the mirror node via the explorer) that the same Ethereum transaction was executed twice. This (apparently) doesn't happen in Ethereum networks which filter duplicates before consensus. This thing - seeing the same ethereum transaction twice in the record stream - whether two different blocks or the same block - can be noticed by applications, and may not be expected. (At least, in this case, a 3rd party reported it to us asking what was going on).

Proposal: Investigate having services dedup EthereumTransactions not just on its own (Hedera) transaction id, but also on the contained Ethereum transaction bytes. What impact would it have, and would it be net positive or negative for Ethereum users (i.e., developers).

(All this deduping happens, of course, only within the usual time range, which I think is 3 minutes for mainnet.)