Update EIP-3074: add nonce to auth msg to provide revocation

[lightclient]

This is one of the longest request features of 3074. Thanks to @yoavw and @shemnon for more recent discussions on the topic and inspiration for this adaptation.

--

This PR modifies the AUTH message to now include nonce. The full message, over which the signature is constructed, is now as follows:

keccak256(MAGIC || chainId || nonce || invokerAddress || commit)

This places nonce within the protocol-definition of the AUTH message, so no matter the security of the invoker it is possible for the user to revoke any and all outstanding AUTH signatures they've created.

Using the message does not increment the EOA's nonce. This allows the user to reuse the same AUTH signature as much as they like (until their EOA originates a tx), which provides a similar experience to the original 3074 proposal while still providing global revocation.

The anticipated usage of nonce is to be set the EOA's current nonce. This way, a single tx origination will revoke all outstanding signatures. The rationale for this is once a user has signed to an invoker, it should be possible for them to do almost all of their normal tasks via their invoker, so long as there is some entity relaying their ops on-chain.

Although this is the anticipated and recommended usage of nonce, it does prohibit other nonce values to be used. 2**64 would be equivalent to the previous version of 3074 where there was no in-protocol revocation. We strongly advise wallets do not allow signing AUTH messages this high, but do concede there may be occasional use cases for this, such as an extremely locked-down social recovery invoker that you do not want to be revocable via the nonce.

Hopefully this will provide enough protection and flexibility to please all sides of the 3074 debate!

[eth-bot]

✅ All reviewers have approved.

[shemnon]

Is there an in-protocol limit to how far in the future a nonce can be signed and valid? There is still a window to make an "effectively infinite" authorization without such checking. Putting it on invokers still keeps space open for malicious invokers. Requiring the nonce to be within some limit of the signing nonce would reduce that window and ensure an achievable path to revocation. The next nonce seems too limiting, what about 64? And if needed and without notable incidents the limit could be raised at future hard forks.

[lightclient]

@shemnon it's up to wallets to decide what future nonce to sign. There is no protocol requirement of what the nonce should be other than at least equal to EOA's current nonce. Next nonce is only a recommendation.

[shemnon]

If there is the possibility to sign a nonce at MAX_NONCE then the blast radius of mistaken signatures still grows in new novel ways with significant scope. This does not provide for the possibility of an effective revocation in all cases.

[lightclient]

A some point the user needs to take responsibility for their actions. The protocol's duty is to provide tools to developers and users. Signing MAX_NONCE should be probably be frowned upon by the community, just like any other poor security practice. If a chain desires to reduce the "blast radius" they are welcome to add an in-protocol validity limit to the nonce to something like you propose, maybe 64. But that is not my recommended limit for L1.

[eth-bot]

All Reviewers Have Approved; Performing Automatic Merge...