SIMD-0191

TL;DR

This proposal aims to relax certain transaction errors related to loading transaction accounts, from protocol violations to runtime errors. Specifically, if a transaction fails to load a valid program account or exceeds the requested maximum loaded account data size, the transaction may be included in a block, and the transaction fee will be charged.

Summary

This proposal aims to relax certain transaction errors related to loading transaction accounts, from protocol violations to runtime errors. Specifically, if a transaction fails to load a valid program account or exceeds the requested maximum loaded account data size, the transaction may be included in a block, and the transaction fee will be charged.

Motivation

The current transaction constraints are overly restrictive and adds complexity in determining whether a block is valid or not. This proposal aims to relax these loading constraints to simplify the protocol, and give block-producers more flexibility in determining which transactions may be included in a block. The goal is to remove this reliance on account-state in order to validate a block.

Key Changes

• 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.
• The total loaded data size of the transaction must not exceed requested_loaded_accounts_data_size_limit, or the default limit (64MiB).
• Any account used as a program in a top-level instruction must:
• be the native loader: NativeLoader1111111111111111111111111111111
• be executable
• be owned by the native loader: NativeLoader1111111111111111111111111111111
• the owner account be owned by the native loader: NativeLoader1111111111111111111111111111111
• the owner account must be executable
• Check if the account exists. If not, assume default account state (empty).
• Accumulate account's data field len. If the total exceeds the requested_loaded_accounts_data_size_limit (or default if unspecified), return MaxLoadedAccountDataSizeExceeded.
• If the program account is native_loader, continue to next instruction.
• If the program account does not exist, return ProgramAccountNotFound
• If the program account is not executable, return `InvalidProgramForExecution
• This only applies until SIMD-0162 is activated
• If the program account's owner is the native_loader, continue to next instruction.
• If the program account's owner does not exist, return ProgramAccountNotFound
• If the program account's owner is not the native_loader, return `InvalidProgramForExecution
• If the program account's owner is not executable, return `InvalidProgramForExecution
• Accumulate the owner account's data field len and check if the total exceeds the requested_loaded_accounts_data_size_limit (or default if unspecified), return MaxLoadedAccountDataSizeExceeded.

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 they are executable if they do not want to waste fees. - Block-production is simplified as it can be done without needing to load large program accounts for the initial decision to include a transaction.

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.

Security Considerations

None