SIMD-0242

Static Nonce Account Only

Author: Andrew Fitzgerald (Anza) · Category: Core Protocol GitHub →

Feature Gate Status

Mainnet Active E890
Testnet Active E859
Devnet Active E980

7VVhpg5oAjAmnmz1zCcSHb2Z9ecZB2FQqpnEwReka9Zm

TL;DR

The advance nonce instruction in a transaction can currently specify any account in the transaction as the account to advance. This proposal would restrict the advance nonce instruction to only be able to advance a statically included account.

Summary

The advance nonce instruction in a transaction can currently specify any account in the transaction as the account to advance. This proposal would restrict the advance nonce instruction to only be able to advance a statically included account.

Motivation

- There is a separate proposal to relax the constraints on transaction account resolution. That proposal would allow transactions with invalid lookups or duplicate accounts to be included in a block, pay fees, but not processed. - However, that relaxation cannot happen without specifying the interaction with nonce accounts. Rather than complicating the protocol and specifying the interactions between lookups and nonces, this proposal aims to simplify by restricting nonce accounts to statically declared accounts.

Key Changes

  • nonce transaction
  • A transaction that includes SystemInstruction::AdvanceNonceAccount as its first instruction.
  • nonce account
  • The account specified in the first account of the SystemInstruction::AdvanceNonceAccount instruction in a nonce transaction.
  • statically included account
  • An account that has its' Pubkey directly included in the transaction message.
  • Nonce transactions MUST have a nonce account index that is less the number of statically included accounts in the transaction.
  • Leader nodes MUST drop nonce transactions that do not meet this requirement without including them in a block.
  • Nonce transactions that do not meet this requirement are invalid and MUST result in the entire block being rejected by the validators.

Impact

- Clients who currently send nonce-transactions with looked up nonce accounts will need to change their behavior.

Backwards Compatibility

- Some previously valid transactions may not be valid under the new restrictions.

Security Considerations

- Requires a feature-gate to be enabled to avoid forking the network.