-
Notifications
You must be signed in to change notification settings - Fork 296
SIMD-406: Restrict the number of accounts in an instruction #406
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
6fe01cb
96dec4e
8e7a4ae
9ce30cb
959ecc3
9ac1694
5bc845a
f600fbc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,69 @@ | ||
| --- | ||
| simd: "0406" | ||
| title: Maximum instruction accounts | ||
| authors: | ||
| - Alexander Meißner (Anza) | ||
| - Lucas Steuernagel (Anza) | ||
| category: Standard | ||
| type: Core | ||
| status: Review | ||
| created: 2025-11-19 | ||
| feature: (fill in with feature tracking issues once accepted) | ||
| --- | ||
|
|
||
| ## Summary | ||
|
|
||
| This SIMD imposes a hard restriction on the maximum number of account | ||
| references that an instruction may declare. There is already a limit of 255 | ||
| account references imposed during serialization in ABI v0 and v1, but it does | ||
| not currently apply to builtin invocations or precompiles. | ||
|
|
||
| ## Motivation | ||
|
|
||
| Although there can only be a maximum of 35 account keys in the legacy message | ||
| format and 256 in the v0 format, instructions can have up to 65535 (`u16::MAX`) | ||
| accounts, each being a `u8` index referencing a transaction account. | ||
|
|
||
| Allowing instructions to reference more accounts than what the message format | ||
| allows is not necessary. On one hand there is a limit of 255 accounts for CPI | ||
| and user deployed programs, on the other, builtins and precompiles do not need | ||
| as many accounts as the message format allows. | ||
|
|
||
| Furthermore, since there can only be 256 unique pubkeys in a transaction, any | ||
| instruction referencing more than 256 will have aliased references, requiring | ||
| the validator to deduplicate them, even though they are unused. | ||
|
|
||
| ## New Terminology | ||
|
|
||
| None. | ||
|
|
||
| ## Detailed Design | ||
|
|
||
| A new verification step must be included in message sanitization for message | ||
| formats legacy and v0. The verification step must examine every instruction in | ||
| a transaction, check if the former references more than 255 accounts, and | ||
| throw `SanitizationError::ValueOutOfBounds` otherwise. Transactions violating | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We don't need to specify the error here, it's an implementation detail. It's enough to say that the transaction and any block including this transaction will be rejected.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. While the specific error code is not part of consensus it is still good to specify it for fuzzing between validator implementations. At least that is how we handled it in other SIMDs. |
||
| such a restriction must be considered invalid and not included in a block. | ||
| Likewise, blocks containing transactions that violate such condition should be | ||
| declared dead. | ||
|
|
||
| Transactions in the v1 format | ||
| ([SIMD-0385](https://github.com/solana-foundation/solana-improvement-documents/pull/385)) | ||
| already have a limit of 255 accounts per instruction, so this change and the | ||
| accompanying feature gate do not affect such newer format. | ||
|
|
||
| ## Alternatives Considered | ||
|
|
||
| None. | ||
|
|
||
| ## Impact | ||
|
|
||
| Calls to user deployed programs from top level instructions and CPIs will not | ||
| be impacted, since there is already a limit in place. | ||
|
|
||
| Instructions that invoke builtin programs or precompiles will error out if | ||
| they have more than 255 accounts. | ||
|
|
||
| ## Security Considerations | ||
|
|
||
| None. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about the new Transaction v1 format?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new transaction v1 format also specifies this limit, so this applies to all transaction formats. Definitely worth specifying 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The limit for v1 transactions won't be behind the feature gate implied by this SIMD. Is it worth specifying if that is the case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe just mention it for clarity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mentioned v1 transactions and dead blocks (from the following thread) in f600fbc