Why store account nonce on chain instead of using timestamp to prevent replay attacks, or any other random bit of information that will change thr hash and differentiate the transaction?

As far as I was able to understand, the account nonce is a bit of information added to a transaction to counteract replay attacks by making the transaction hash used to identify the account unique.

My question is, why is there a need for a permanent record that occupies space on the chain of the amount of transaction each account has made? Couldn't the same effect be achieved with the addition of any other kind of random or unique data to the transaction, such as a timestamp at the moment the transaction is generated by the wallet client? Is there any other advantage to recording account nonces that I am failing to see?

  • Please elaborate a bit - like add a documentation link explaining the use of nonce, and maybe explain some more what you think is usable instead and what are the benefits of your proposed alternative compared to what Ethereum has now. Also, check this question - does it contain what you want to know? ethereum.stackexchange.com/questions/27432/… – Utgarda Sep 29 '18 at 18:17
  • 1
    Thanks, I've edited the question to try to be clearer. The link provided doesn't exactly address this particular question I have – F L Sep 29 '18 at 20:43

First of all, transactions don't have a timestamp. Only the blocks have timestamps.

Now you may ask why didn't we simply use timestamps instead of nonce; technically speaking, it would have worked equally fine. I guess it had more to do with design choice. Consider the billions of transactions and then each transaction holding multiple bytes for the timestamp, a nonce is comparatively smaller in size. And actually if you look at it programmatically, a nonce is more sort of a notion of ordering (much like a timestamp.) Additionally, you get transaction count as well.

Effectively, you're getting three benefits when using nonce- less space, simplicity, ordering, and tracking number of transactions. The most important being the fact by the virtue of the decentralized nature of the Ethereum network, you need to make sure that a transaction A was not lost, and hence the EVM won't process transaction B, assuming transaction A was supposed to happen before B. You can think of it as transactions will be executed in order despite the network latency each transaction experiences (very much like TCP packets, if the analogy helps.) This can't be achieved with mere timestamps.

Additionally, you should be aware that timestamps in the network can be artificially modified by the miner nodes.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.