permit2

[mrq1911]

The current implementation of permits has several drawbacks:

1. Only one permit per account can exist in the mempool at any given time.
2. There's no RPC function to retrieve the latest nonce from the mempool, as there is for regular transactions.
3. Indexing permits is difficult because there’s no nonce included in the arguments, making it hard to track the sequence.
4. Dispatched permits are sometimes deleted from the mempool due to nonce validation issues, especially when the node hasn’t synced to the latest nonce.
5. Permits cannot be replaced with newer ones.

Proposed Solution

We should introduce a nonce as an additional parameter when submitting a permit. This nonce will be validated against the specified value, rather than the one stored in the state, allowing:

• Permits to be dispatched with the same nonce as a priority.
• Multiple permits per account to exist in the pool simultaneously.

To ensure nonce continuity, we will create a runtime API to retrieve the latest permit nonce for an account from the mempool, similar to how it's done for regular transactions.This will resolve points 1-4.

For point 5, we will allow a permit to be replaced by a newer one by specifying a higher tip, granting it more priority, similar to how regular transactions behave.

Backward Compatibility:

These changes will be backward compatible with the original Moonbeam-derived interface, allowing us to process old permits with the same limitations as before.

[mrq1911]

related to #846 #845 #814