08 Custom-token: At least add nonce to prevent exploiting admin signature

[HyunggyuJang]

It is not bullet-proof solution, but at least, we can alert with the following change, we should consider double spending for the mint method in production.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docs2	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 16, 2023 0:27am

[barriebyron]

thank you for your suggestion @HyunggyuJang
Let me ask our tutorial expert @ymekuria to lend his technical expertise and evaluate this change.

[mitschabaude]

Thanks @HyunggyuJang for watching out!
As I read this, this prevents replaying a mint transaction by adding a special "mint nonce" which the mint is tied to. The nonce is incremented so that this transaction can't succeed a second time.

I think this is a good idea, but I'd do it differently. There's already a dedicated nonce field on the account which would be better to use.

We could even refactor the admin signature input, to instead create an account update for the admin (assuming they have an associated Mina account) and call update.requireSignature(). This achieves everything here (access control + replay protection) with very little code and a cheap proof (signature is checked on the Mina node, not in the SNARK), and would be a nice pattern to demonstrate.

But importantly, we should only make any change to the example code if we also update the tutorial along with it.