From 21659ecaa5641121c49a635845dbf44dabe565ad Mon Sep 17 00:00:00 2001 From: Andrew Fitzgerald Date: Wed, 6 Nov 2024 13:39:47 -0600 Subject: [PATCH 1/5] Initial draft --- .../0192-transaction_account_resolution.md | 101 ++++++++++++++++++ 1 file changed, 101 insertions(+) create mode 100644 proposals/0192-transaction_account_resolution.md diff --git a/proposals/0192-transaction_account_resolution.md b/proposals/0192-transaction_account_resolution.md new file mode 100644 index 000000000..7b446fe93 --- /dev/null +++ b/proposals/0192-transaction_account_resolution.md @@ -0,0 +1,101 @@ +--- +simd: '0192' +title: Relax Transaction Account Resolution +authors: + - Andrew Fitzgerald (Anza) +category: Standard +type: Core +status: Review +created: 2024-11-06 +feature: +supersedes: +superseded-by: +extends: +--- + +## Summary + +This proposal aims to relax certain transaction errors related to the account +keys used in a transaction, from protocol violations to runtime errors. + +## Motivation + +The current transaction constraints are overly restrictive and add complexity +to the protocol. Specifically the constraints that require account-state +in order to validate a block due to lookup tables. This account-state +dependence makes both block-production and block-validation more complex than +necessary. + +## New Terminology + +These terms are used elsewhere, but are defined here for clarity: + +- Protocol Violating Transaction Error: A transaction error that violates the + protocol. This class of errors must result in the entire block being rejected + by the network. +- Runtime Transaction Error: A transaction error that results in a failed + transaction, and may be included in the block. These transactions still + incur transaction fees, and nonce advancements. + +## Detailed Design + +The current protocol requires that the the account keys used in a transaction: + +1. Contain no duplicate account keys, +2. Have no more than 64 account keys, + - The limit is subject to change to 128 with the activation of + `9LZdXeKGeBV6hRLdxS1rHbHoEUsKqesCC2ZAPTPKJAbK`. +3. All address lookup tables must be resolvable: + - The address lookup table account must exist. + - The address lookup table account must be owned by the address lookup + table program: `AddressLookupTab1e1111111111111111111111111` + - The address lookup table account data must be deserializable into + `AddressLookupTable` as defined in `solana-sdk`. + - All account table indices specified in the transaction must be less than + the number of active addresses in the address lookup table. + +This proposal seeks to relax these constraints from protocol violation errors +to runtime errors. +This means that transactions that break any of these constraints may be +included in a block, if they are otherwise valid. +Such transactions do not need to attempt any further loading or execution; they +need only to pay fees and advance the nonce. +Such transactions should have transaction costs for block-limits applied only +to the fee-payer and nonce accounts, since exucution will not even be +attempted. + +## Alternatives Considered + +- Do nothing + - This is the simplest option, as we could leave the protocol as is. + However, this leaves the protocol more complex than it needs to be. +- Relax additional constraints: + - SIMD-0082 sought to relax additional constraints, but has not been + accepted. This proposal is a subset of SIMD-0082, intended to make the + review process simpler and faster. Therefore, we have decided to keep + this proposal focused specifically on certain loading failures. + +## Impact + +- Transactions that would previously have been dropped with a protocol + violation error can now be included and will be charged fees. + - Users must be more careful when constructing transactions to ensure the + account keys requested are valid. + +## Security Considerations + +None + +## Drawbacks + +- Users must be more careful about what they sign, as they will be charged fees + for transactions that are included in a block, even if they are not executed. +- This will likely break a lot of tooling, such as explorers, which may expect + all transactions to attempt execution. + +## Backwards Compatibility + +This proposal is backwards compatible with the current protocol, since it only +relaxes constraints, and does not add any new constraints. All previously valid +blocks would still be valid. However, new blocks may not be valid under the old +protocol. From d4d0e90f8f8169aef234dbc36a16d56f9ad9b61b Mon Sep 17 00:00:00 2001 From: Andrew Fitzgerald Date: Wed, 24 Sep 2025 14:15:17 -0500 Subject: [PATCH 2/5] clarify language of violating transactions --- proposals/0192-transaction_account_resolution.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/0192-transaction_account_resolution.md b/proposals/0192-transaction_account_resolution.md index 7b446fe93..1026d3efc 100644 --- a/proposals/0192-transaction_account_resolution.md +++ b/proposals/0192-transaction_account_resolution.md @@ -60,8 +60,8 @@ This means that transactions that break any of these constraints may be included in a block, if they are otherwise valid. Such transactions do not need to attempt any further loading or execution; they need only to pay fees and advance the nonce. -Such transactions should have transaction costs for block-limits applied only -to the fee-payer and nonce accounts, since exucution will not even be +Such transactions must have transaction costs for block-limits applied only +to the fee-payer and nonce accounts, since execution will not even be attempted. ## Alternatives Considered From cdce3157a8431591bf6878342db5e0b7c50ca81b Mon Sep 17 00:00:00 2001 From: Andrew Fitzgerald Date: Wed, 24 Sep 2025 14:16:25 -0500 Subject: [PATCH 3/5] remove unnecessary acct limit relaxation --- proposals/0192-transaction_account_resolution.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/proposals/0192-transaction_account_resolution.md b/proposals/0192-transaction_account_resolution.md index 1026d3efc..21661192b 100644 --- a/proposals/0192-transaction_account_resolution.md +++ b/proposals/0192-transaction_account_resolution.md @@ -42,10 +42,7 @@ These terms are used elsewhere, but are defined here for clarity: The current protocol requires that the the account keys used in a transaction: 1. Contain no duplicate account keys, -2. Have no more than 64 account keys, - - The limit is subject to change to 128 with the activation of - `9LZdXeKGeBV6hRLdxS1rHbHoEUsKqesCC2ZAPTPKJAbK`. -3. All address lookup tables must be resolvable: +2. All address lookup tables must be resolvable: - The address lookup table account must exist. - The address lookup table account must be owned by the address lookup table program: `AddressLookupTab1e1111111111111111111111111` From 9066f7619559431bc915c73cf7b2a253d331fbe3 Mon Sep 17 00:00:00 2001 From: Andrew Fitzgerald Date: Wed, 24 Sep 2025 14:20:05 -0500 Subject: [PATCH 4/5] fee-only transaction similarity for cost-model --- proposals/0192-transaction_account_resolution.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/0192-transaction_account_resolution.md b/proposals/0192-transaction_account_resolution.md index 21661192b..6f4d66783 100644 --- a/proposals/0192-transaction_account_resolution.md +++ b/proposals/0192-transaction_account_resolution.md @@ -60,6 +60,8 @@ need only to pay fees and advance the nonce. Such transactions must have transaction costs for block-limits applied only to the fee-payer and nonce accounts, since execution will not even be attempted. +Transaction-cost calculation is unchanged, and calculated as if the transaction +were a "fee-only" transaction. ## Alternatives Considered From 3fb21b1dcf27c89dff78ca9444487e47a6f8d344 Mon Sep 17 00:00:00 2001 From: Andrew Fitzgerald Date: Mon, 12 Jan 2026 12:55:26 -0600 Subject: [PATCH 5/5] clarify nonce and fee-payer case --- proposals/0192-transaction_account_resolution.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/0192-transaction_account_resolution.md b/proposals/0192-transaction_account_resolution.md index 6f4d66783..9e3c6be60 100644 --- a/proposals/0192-transaction_account_resolution.md +++ b/proposals/0192-transaction_account_resolution.md @@ -60,6 +60,8 @@ need only to pay fees and advance the nonce. Such transactions must have transaction costs for block-limits applied only to the fee-payer and nonce accounts, since execution will not even be attempted. +In the case the fee-payer and nonce are the same account, costs are applied +only once, as is currently done for valid and successful transactions. Transaction-cost calculation is unchanged, and calculated as if the transaction were a "fee-only" transaction.