SIMD-0186

Loaded Transaction Data Size Specification

Author: Hanako Mumei · Category: Core Protocol GitHub →

TL;DR

Before a transaction can be executed, every account it may read from or write to must be loaded, including any programs it may call. The amount of data a transaction is allowed to load is capped, and if it exceeds that limit, loading is aborted. This functionality is already implemented in the validator. This SIMD defines a new algorithm for calculating the consensus-enforced total size of loaded transaction data during transaction processing.

Summary

Motivation

Transaction data size accounting is currently unspecified, and the implementation-defined algorithm used in the Agave client exhibits some surprising behaviors: * BPF loaders required by instructions' program IDs are counted against transaction data size. BPF loaders required by CPI programs are not. If a required BPF loader is also included in the accounts list, it is counted twice. * The size of a program owned by LoaderV3 may or may not include the size of its programdata depending on how the program account is used on the transaction. Programdata is also itself counted if included in the transaction accounts list. This means programdata may be counted zero, one, or two times per transaction. * Due to certain quirks of implementation, loader-owned accounts which do not contain valid programs for execution may or may not be counted against the transaction data size total depending on how they are used on the transaction. This includes, but is not limited to, LoaderV3 buffer accounts, and accounts which fail ELF validation. All validator clients must arrive at precisely the same transaction data size for all transactions because a difference of one byte can determine whether a transaction is executed or failed, and thus affects consensus. Also, we want the calculated transaction data size to correspond well with the actual amount of data the transaction requests. Therefore, this SIMD seeks to specify an algorithm that is straightforward to implement in a client-agnostic way, while also accurately accounting for all account data required by the transaction.

Key Changes

Instruction account: an account passed to an instruction in its accounts
Transaction accounts list: all accounts for the transaction, which includes
LoaderV3 program account: an account owned by
The set of accounts that determine loaded transaction data size is defined as
The set of account keys explicitly specified on the transaction,
The set of programdata accounts referenced by the LoaderV3 program
Each loaded account's size is defined as the byte length of its data prior to
There is a flat 8248 byte cost for each address lookup table used by a
The total transaction loaded account data size is the sum of these sizes.
Verify the account exists. Otherwise, return ProgramAccountNotFound.
Verify the program account's owner is one of:
NativeLoader1111111111111111111111111111111
BPFLoader1111111111111111111111111111111111
BPFLoader2111111111111111111111111111111111
BPFLoaderUpgradeab1e11111111111111111111111
LoaderV411111111111111111111111111111111111

Impact

The primary impact is this SIMD makes correctly implementing transaction data size accounting much easier for other validator clients. It makes the calculated size of transactions which include program accounts for CPI somewhat larger, but given the generous 64MiB limit, it is unlikely that any existing users will be affected. Based on an investigation of a 30-day window, transactions larger than 30MiB are virtually never seen.

Backwards Compatibility

Transactions that currently have a total transaction data size close to the 64MiB limit, which call LoaderV3 programs via CPI, may now exceed it and fail.

Security Considerations

Security impact is minimal because this SIMD merely simplifies an existing feature. Care must be taken to implement the rules exactly. This SIMD requires a feature gate.

← View all SIMDs on simd.watch