SIMD-0339: Increase CPI Account Info Limit by jstarry · Pull Request #339 · solana-foundation/solana-improvement-documents

jstarry · 2025-08-15T05:17:14Z

[the CPI max account info limit] is actually quite the pain because [at the] top level the compression allow for repeating accounts a lot, but then [..] for cpi purposes we can't

Ideally cpi is never more restrictive than the top level to prevent this kind of limitation

Lichtso · 2025-08-15T07:54:41Z

+
+Since the list of account info's passed to a CPI can now be ~4 times longer,
+there will be more overhead in the SVM to map each instruction account address
+to one of the account info.


We should also charge a few CUs for duplicate instruction accounts. Currently we only charge after de-duplication I think.

We should also charge a few CUs for duplicate instruction accounts

Do you mean charge CUs for duplicate account info's or duplicate instruction accounts or both?

Currently we only charge after de-duplication I think.

Yeah I think we are just charging for the account data length after de-duplication.

How about we just charge a fee based on the account info length? That way we don't necessarily need to check which account info's are duplicates or even used by the CPI instruction. Could charge total_serialized_account_info_len / cpi_bytes_per_unit CU's where

sol_invoke_signed_c: total_serialized_account_info_len = 56 * account_infos_len pre-simd-max-cus = 56 * 64 / 250 = 14 post-simd-max-cus = 48 * 255 / 250 = 57 sol_invoke_signed_rust: total_serialized_account_info_len = 48 * account_infos_len pre-simd-max-cus = 48 * 64 / 250 = 12 post-simd-max-cus = 48 * 255 / 250 = 48

Do you mean charge CUs for duplicate account info's or duplicate instruction accounts or both?

Isn't that the same? Every AccountInfo corresponds to one InstructionAccount. The only translation is from Pubkey to index.

How about we just charge a fee based on the account info length?

Yes, that is what I had in mind.

Isn't that the same?

Not the same. The CPI syscall receives both account_infos as well as the account_metas from the instruction accounts slice. Both of which are keyed with an account address for some reason and therefore they can both contain duplicates.

Every AccountInfo corresponds to one InstructionAccount.

Nope. Every account meta corresponds to instruction account. There's an additional translation step from account metas to account info's before the translation from Pubkey to index.

So, sounds like we should charge for both the account metas length as well as the account infos length?

Ah yes, sorry confused AccountInfo and AccountMeta again...

So, sounds like we should charge for both the account metas length as well as the account infos length?

Yup

Added in 281a466

Lichtso · 2025-08-15T15:47:28Z

+
+## Motivation
+
+CPI's are restricted to a limit of 64 account info's passed to the syscall.


Didn't you already raise the limit in solana-labs/solana#27242?

The feature gate is still there: https://github.com/anza-xyz/agave/blob/d54feac498c6ce29fce9b4b262ea3ba1d3bb5a5e/syscalls/src/cpi.rs#L932

Yes, thanks for pointing it out. The increase_tx_account_lock_limit feature gate is currently only activated on devnet and it does two things:

Increase tx account lock limit from 64 to 128

Increase CPI account info limit from 64 to 128

SIMD-0339 should change the CPI account info limit to 255 no matter whether the increase_tx_account_lock_limit feature gate is active or not. This SIMD has nothing to do with the tx account lock limit. It's more of an acknowledgement that account info length can contain duplicates and should be allowed to be as long as the ix account length and not necessarily the same as the tx account lock limit.

Lichtso · 2025-08-25T19:56:10Z

We would have to either only charge CUs for things going over the current limit or offset CUs in the CPI base cost, not to break existing dApps.

Also, this SIMD should probably depend on #219 for direct mapping as this will reduce some overhead of instruction accounts.

febo · 2025-08-25T23:19:41Z

+  - 8 bytes for data length
+
+The total cost of account info's can be computed with
+`(account_info_size * account_infos_len) / cpi_bytes_per_unit` rounded down to


Just to confirm whether the cost is for each unique account info or not. This is not very clear from the equation here. For example, if I use a slice of 255 account infos, but all of them are copies from the same one, then the runtime has only to serialize a single account payload.

My intention was to charge a cost for each account info in the account_infos slice passed to the CPI syscall including duplicates. The runtime needs to search for the first instance of each instruction account address in the account_infos slice. So when account_infos is longer, the runtime typically needs to do more work to do the account translation step even if some of those account info's are duplicates and skipped.

febo · 2025-08-25T23:23:27Z

@@ -0,0 +1,108 @@
+---
+simd: '0339'
+title: Increase CPI Account Info Limit


cosmetic: I find it a bit confusing the wording "Account Info Limit" referring to the maximum number of account infos in a CPI. My first impression is that it is a limit on the length of an account info, not on the number of account infos.

I updated to Increase CPI Account Infos Limit. Is that better or do you prefer something different?

Yeah, that reads better.

febo · 2025-08-25T23:29:46Z

+The max account info length increase for CPI's and new costs will be feature
+gated. Since the limit is being increased, existing behavior will not be
+restricted. However, new imposed costs for CPI instruction accounts and account
+info's may cause onchain programs to consume additional CU's.


Is it possible to include a numeric example of an existing bahaviour (< 64 account) to illustrate the difference, like a before and after calculation? The cost of CPI is already perceived as high, and given that this change potentially will increase the cost, it would be nice to see by how much.

After discussion with @Lichtso we decided it was better to offset the base cost of CPI's by the maximum account cost of existing allowed behavior. So consumed CU's for existing behavior will only be decreased, if at all.

Sounds good!

jstarry · 2025-08-26T00:35:39Z

We would have to either only charge CUs for things going over the current limit or offset CUs in the CPI base cost, not to break existing dApps.

Yeah, agreed. Just updated the SIMD to reflect an offset to the CPI base cost.

Also, this SIMD should probably depend on #219 for direct mapping as this will reduce some overhead of instruction accounts.

Do you mean the overhead of instruction account info's? Can you explain what overhead you mean? I don't think the overhead actually changes in this SIMD because the number of translated account's is still capped at 64 because we only translate unique instances of each account, we don't translate duplicates.

Lichtso · 2025-08-26T08:24:47Z

Sorry, I meant the overhead of instruction accounts. How is that still limited after this SIMD? If you can pass in 255 AccountInfos and 255 AccountMetas, wouldn't they translate into 255 instruction accounts (which are possibly all unique)?

jstarry · 2025-08-26T09:31:50Z

Sorry, I meant the overhead of instruction accounts. How is that still limited after this SIMD? If you can pass in 255 AccountInfos and 255 AccountMetas, wouldn't they translate into 255 instruction accounts (which are possibly all unique)?

Transactions can only have 64 unique accounts right now and it's not possible to reference other accounts besides those 64 in a CPI. Also, you can already pass 255 instruction account metas. Allowing 255 account info's in this SIMD just makes it easier for an onchain program invoked with 255 instruction account metas to pass many or all of those accounts to another onchain program CPI

Lichtso · 2025-09-08T16:33:10Z

+compute units to 946 compute units to offset the new costs.
+
+Before this SIMD, up to 255 instruction account metadata's could be passed to a
+CPI syscall. The base cost offset is therefore `255 * 34 / 250 = 34` CU's.


It currently does not make sense to pass in that many, so it probably does not happen. Realistically this should maybe assume 64 as well?

It is already over 64 in the wild (see here: https://explorer.solana.com/tx/69BYATGo3SrSPBKbF5PBs36DvJUssxrFBJtXhfRkmDBrLvLapGevr3NzpKPcBTPr52tYHCkdRNbCyXpuWjMrb4n). I think it's safer to assume 255 since it's only 34 CU's

jstarry force-pushed the normalize-ix-accounts-limit branch from 1b2911f to 8c17df6 Compare August 15, 2025 05:17

jstarry changed the title ~~SIMD-XXXX: Normalize Instruction Accounts Limit~~ SIMD-0339: Normalize Instruction Accounts Limit Aug 15, 2025

jstarry requested a review from Lichtso August 15, 2025 05:18

jstarry marked this pull request as draft August 15, 2025 05:24

jstarry force-pushed the normalize-ix-accounts-limit branch from 8c17df6 to 1a5da24 Compare August 15, 2025 05:34

jstarry changed the title ~~SIMD-0339: Normalize Instruction Accounts Limit~~ SIMD-0339: Increase CPI Account Info Limit Aug 15, 2025

SIMD-0339: Increase CPI Account Infos Limit

1a5da24

jstarry marked this pull request as ready for review August 15, 2025 05:35

Lichtso reviewed Aug 15, 2025

View reviewed changes

github-actions Bot mentioned this pull request Aug 18, 2025

Upstream Updates - Mon Aug 18 00:18:26 UTC 2025 smartcontractkit/chainlink-solana#1325

Open

jstarry added 2 commits August 20, 2025 03:46

charge cu's

281a466

fix formatting

685abb9

febo reviewed Aug 25, 2025

View reviewed changes

feedback

4561799

topointon-jump approved these changes Sep 5, 2025

View reviewed changes

Lichtso reviewed Sep 8, 2025

View reviewed changes

Lichtso approved these changes Sep 9, 2025

View reviewed changes

Benhawkins18 approved these changes Sep 24, 2025

View reviewed changes

Benhawkins18 merged commit f3a87c6 into solana-foundation:main Sep 24, 2025
2 checks passed

github-actions Bot mentioned this pull request Sep 29, 2025

Upstream Updates - Mon Sep 29 00:16:35 UTC 2025 smartcontractkit/chainlink-solana#1351

Open

jstarry deleted the normalize-ix-accounts-limit branch October 9, 2025 08:26

nbelenkov mentioned this pull request Oct 20, 2025

SIMD-0339: Increase CPI Account Infos Limit anza-xyz/agave#8513

Merged

topointon-jump mentioned this pull request Nov 25, 2025

flamenco, vm: implement increase_cpi_account_info_limit firedancer-io/firedancer#7430

Merged

4 tasks

github-actions Bot locked as resolved and limited conversation to collaborators Jan 12, 2026


		## Motivation

		CPI's are restricted to a limit of 64 account info's passed to the syscall.

Conversation

jstarry commented Aug 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Lichtso commented Aug 25, 2025

Uh oh!

febo Aug 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jstarry commented Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Lichtso commented Aug 26, 2025

Uh oh!

jstarry commented Aug 26, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jstarry Sep 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

febo Aug 25, 2025 •

edited

Loading

jstarry commented Aug 26, 2025 •

edited

Loading

jstarry Sep 9, 2025 •

edited

Loading