Increase TxV1 Account Lock Limit to 96 - #596
Conversation
|
Hello apfitzge! Welcome to the SIMD process. By opening this PR you are affirming that your SIMD has been thoroughly discussed and vetted in the SIMD discussion section. The SIMD PR section should only be used to submit a final technical specification for review. If your design / idea still needs discussion, please close this PR and create a new discussion here. This PR requires the following approvals before it can be merged:
Once all requirements are met, you can merge this PR by commenting |
|
An increase like this has been considered and discussed for years. We are finally at a point where we think we can activate it soon. @jacobcreech is it reasonable to skip discussion phase given this context? edit: I don't mean merge immediately or quickly, just skipping the github discussion and going straight to this proposal document. |
Greptile SummaryThe PR proposes increasing the account-lock limit for v1 transactions from 64 to 96 while retaining the 64-account limit for legacy and v0 transactions.
Confidence Score: 4/5The proposal content appears sound, but the commit must be replaced with a verified signed commit before merging. The only accepted issue is that the PR's sole commit is not verified, which violates the repository's mandatory commit-signature policy. Files Needing Attention: proposals/0596-increase-txv1-account-lock-limit-to-96.md Important Files Changed
Reviews (1): Last reviewed commit: "Increase TxV1 Account Lock Limit to 96" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| @@ -0,0 +1,53 @@ | |||
| --- | |||
There was a problem hiding this comment.
The PR's sole commit is not verified as signed, so it does not satisfy the repository's mandatory commit-signature policy and must be replaced with a verified signed commit before merging.
Context Used: Request changes if the commits are not signed (ver... (source)
There was a problem hiding this comment.
except that it is signed.
There was a problem hiding this comment.
You're right, I apologize. My original comment was incorrect — I don't have reliable visibility into commit signature verification status, and I should not have flagged it. Sorry for the noise.
Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.
| ## New Terminology | ||
|
|
||
| None. |
There was a problem hiding this comment.
Do we want to place a dependency on Direct Mapping?
There was a problem hiding this comment.
I think we don't need to be explicit in the proposal about that. The dependency on direct mapping is just our concern about potential performance impact, not correctness.
Given the amount of discussion we've had outside and the general stamps/acks we've had, I think it's ok to skip discussion this time. |
|
ship it |
|
Thanks, ptaffet-jump! |
bw-solana
left a comment
bw-solana
left a comment
There was a problem hiding this comment.
we should specify how this interacts with increase_tx_account_lock_limit feature. Like does this supersede? override? noop if increase_tx_account_lock_limit is active?
Also would be good to add a note on conformance/testing
|
|
||
| ## Summary | ||
|
|
||
| Increase the account lock limit for v1 transactions from 64 to 96. Legacy and |
There was a problem hiding this comment.
instead of "account lock limit", maybe we should say "number of addresses" and make it explicit this includes everything such as signers, program IDs, write/read only accounts, etc.
|
|
||
| The runtime limits v1 transactions to 64 account locks. Raising the limit allows | ||
| v1 transactions to use more accounts while leaving room for signatures, | ||
| instructions, and instruction data within the transaction size limit. |
There was a problem hiding this comment.
probably worthwhile to mention some of the practical use cases for where this increased limit is useful. E.g. more competitive onchain routing
|
|
||
| Once the associated feature gate is activated, v1 transactions MUST be allowed | ||
| to lock up to 96 accounts, inclusive. A v1 transaction with more than 96 | ||
| accounts MUST fail sanitization. |
There was a problem hiding this comment.
might be good to spell out what fail sanitization means here. On the leader side, discard. On the replay side, mark slot dead
|
|
||
| ## Alternatives Considered | ||
|
|
||
| None. |
There was a problem hiding this comment.
this is probably a good section to discuss why 96 (the relation to TxV1 size limits)
|
I'm assuming this will be a new feature gate and we will rip out |
7 participants
No description provided.