Relax invariants in recordStorageChanges for optimization.#5290
Merged
Conversation
Instead of checking that created TTL keys belong to the specific entries, we just ensure that the expected entry counts match. This should be a pretty reasonable tradeoff - it seems like it would be pretty hard to create a mismatched TTL entry (vs missing it entirely). The benefit is that we avoid building a whole separate set and making lookups based on TTL keys (a SHA-256 per key).
Contributor
There was a problem hiding this comment.
Pull request overview
This PR optimizes InvokeHostFunctionOpFrame::recordStorageChanges by replacing a per-key TTL pairing invariant check (that computes TTL keys via hashing) with a cheaper count-based invariant, aiming to reduce CPU overhead in Soroban apply.
Changes:
- Replaces the “created Soroban entry must have created TTL entry” check from per-key validation to a count equality check.
- Removes the temporary
createdKeysset and replaces it with creation counters plus a cachedallowClassicCreationsprotocol-version check. - Avoids computing
keySizefor TTL entries when metering write bytes (consistent with TTL fees being handled separately).
Comments suppressed due to low confidence (1)
src/transactions/InvokeHostFunctionOpFrame.cpp:684
- This comment says we "Verify that each newly created Soroban entry has a corresponding newly created TTL entry", but the code now only checks count equality, not 1:1 pairing by key. Please update the comment to match the actual invariant being enforced (count-only), or restore a key-based pairing check if that's still intended.
// Verify that each newly created Soroban entry has a corresponding
// newly created TTL entry (1:1 pairing guaranteed by the host).
releaseAssertOrThrow(numCreatedSorobanEntries == numCreatedTTLEntries);
anupsdf
approved these changes
May 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Relax invariants in recordStorageChanges for optimization.
Instead of checking that created TTL keys belong to the specific entries, we just ensure that the expected entry counts match. This should be a pretty reasonable tradeoff - it seems like it would be pretty hard to create a mismatched TTL entry (vs missing it entirely). The benefit is that we avoid building a whole separate set and making lookups based on TTL keys (a SHA-256 per key).
Checklist
clang-formatv8.0.0 (viamake formator the Visual Studio extension)