Nana-EC
commented
2 weeks ago @david-bakin-sl is the notion here that the CN would dedupe after coming to consensus so that only 1 record file existed or that a dupe would fail during a precheck so that no record would even need to be created.
Also for clients that see a duped transaction should they not also see one succeeded and the other failed in the RPC response?
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.)