Feat: Check and increment nonce

[birchmd]

To prevent replaying transactions, we need to check the nonce matches the nonce of the account, and increment it if it matches.

In the case of directly calling call or deploy_code replaying the transaction is not a concern because it originates from Near, and so is protected by the base system, but I still increment the nonce in those cases to be consistent.

One issue with this is the case where the transaction runs out of Near gas. In that case the state changes are rolled back, including the incremented nonce, which is different behaviour from if the transaction ran on Ethereum directly. I think the best way to handle this would be to make running out of Near gas impossible by setting appropriate limits on the Eth gas. But this probably is not feasible in the short term. We might need to leave this as a known bug for now. I'm interested in what others think about this issue @artob @djsatok @joshuajbouw @mrLSD

[joshuajbouw]

If in a usual NEAR contract execution, the nonce being rolled back on failure, I think that should be fine to continue with, as long as it doesn't hinder any data between ETH. But if otherwise, a sort of mandatory cost is a good idea, if thats the only way to solve that.

[birchmd]

If in a usual NEAR contract execution, the nonce being rolled back on failure

It's not that on the Near base runtime nonces are always rolled back, that is not the case. The problem here is that we track the nonce explicitly as part of the EVM contract state, and contract state changes are rolled back on OOG (this is true on Eth as well of course). So when we run out of Near gas, the EVM contract state changes are rolled back (it is just a normal contract on Near after all), including the nonce change.

A more "near native" solution than what I suggested above (limiting the Eth gas so that we can never run out of Near gas), would be to take advantage of the Near asyc runtime. We could save the nonce change as a transaction first, then execute the EVM call as an async call (receipt) afterwards. So if the receipt runs out of gas, then only those state changes will be rolled back, not the nonce change since it was already committed. One drawback of this solution is that EVM transactions would then always be split over two Near blocks, which could be awkward for tooling.

[joshuajbouw]

The first solution in the description seems the most favourable for me, and likely will be the solution we will require when we go to main net. The two transaction with the first being the nonce does seem quite awkward for the reasons you posted.

I say, lets leave it open ended for now, be aware of it, and ensure we track it before main net.

[artob]

LGTM 👍 Nice job!