Skip to content

Optimizations for Soroban LTX commit path. - #5418

Draft
dmkozh wants to merge 3 commits into
stellar:masterfrom
dmkozh:commit_to_ltx2
Draft

Optimizations for Soroban LTX commit path.#5418
dmkozh wants to merge 3 commits into
stellar:masterfrom
dmkozh:commit_to_ltx2

Conversation

@dmkozh

@dmkozh dmkozh commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

Description

Optimizations for Soroban LTX commit path.

This includes several micro-optimizations that have a significant impact on the Soroban LTX commit stage performance (~-40ms on large TPL benchmarks; surprisingly much more impact than parallelization change this is based on):

  • Replace several hot path copies with moves
  • Avoid unnecessary LTX loads that were only needed to distinguish between INIT and LIVE entries; propagate a flag that distinguishes these instead
  • Get rid of an unnecessary inner LTX in commitChangesToLedgerTxn

Checklist

  • Reviewed the contributing document
  • Rebased on top of master (no merge commits)
  • Ran clang-format v8.0.0 (via make format or the Visual Studio extension)
  • Compiles
  • Ran all tests
  • If change impacts performance, include supporting evidence per the performance document

dmkozh added 3 commits August 4, 2026 14:18
While the current logic intertwines reads and writes, in fact it can be cleanly separated into a read-only validation step, and a sequential commit step that simply bumps the sequence numbers and removes pre-authorized tx signers. This is possible because that while the writes change the entries that take part in validation, none of these changes are relevant during the validation. Specifically, sequence number bump is only observable by a single transaction (the one that has the respective account as a source), and the pre-authorized tx signer by definition belongs to a single transaction. There is also a subtle caveat to the latter operation: it increases the available balance of the signer owner (or its sponsor), but since at the pre-apply time the fees have already been charged, we're only checking that the account available balance is non-negative, which is an invariant that must always hold in the current protocol.

The change is not protocol-gated because it's not a protocol change for the *current* protocol. It was technically a protocol change prior to p26 where we had a bug that actually did allow overcharging the fee bump source accounts and thus making their available balance to go negative. However, the bug has been fixed without the behavior ever triggering on-chain, and thus this replay-only behavior change should be non-observable.

This change significantly speeds up the pre-apply step. On the local high TPL benchmarks I'm getting 30-60ms improvement locally compared to the main branch version.
When we commit the changes from Soroban apply threads to the global state map, we can shard the output such that every worker only writes into a single shard (thus avoiding any synchronization). Besides the parallelization, this includes a few micro-optimizations that help us avoid extra hash re-computations and copies.
This includes several micro-optimizations that have a significant impact on the Soroban LTX commit stage performance (~-40ms on large TPL benchmarks; surprisingly much more impact than parallelization change this is based on):

- Replace several hot path copies with moves
- Avoid unnecessary LTX loads that were only needed to distinguish between INIT and LIVE entries; propagate a flag that distinguishes these instead
- Get rid of an unnecessary inner LTX in commitChangesToLedgerTxn
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant