Skip to content
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

[VERKLE] Preload stems #7206

Closed
wants to merge 4 commits into from
Closed

Conversation

matkt
Copy link
Contributor

@matkt matkt commented Jun 11, 2024

PR description

Currently, trie keys generation will gather all transactions data and generate a single large batch of trie keys at once.
However, there are already mechanisms implemented in Besu to preload those trie keys in a background thread during block processing.

This PR generates the different triekeys in the background in order to have a maximum of triekeys already calculated at the end of the block

Fixed Issue(s)

Thanks for sending a pull request! Have you done the following?

  • Checked out our contribution guidelines?
  • Considered documentation and added the doc-change-required label to this PR if updates are required.
  • Considered the changelog and included an update if required.
  • For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

  • unit tests: ./gradlew build
  • acceptance tests: ./gradlew acceptanceTest
  • integration tests: ./gradlew integrationTest
  • reference tests: ./gradlew ethereum:referenceTests:referenceTests

matkt added 2 commits June 11, 2024 14:53
Signed-off-by: Karim Taam <[email protected]>

private Map<Bytes32, Bytes32> getCachedTrieKeysForAccount(final Address address) {
return Optional.ofNullable(trieKeysCache.getIfPresent(address))
.orElseGet(ConcurrentHashMap::new);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it doesn't look like trieKeysCache can ever be null in this case

CompletableFuture.runAsync(() -> cacheCodeTrieKeys(account, code));
}

public Map<Bytes32, Bytes32> generateManyTrieKeyHashes(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we really need to cache trieKeys? seems like the only expensive thing to cache would be the 31 byte stem address, and we can just suffix it at-will. It should reduce the cache size and might make for a better performing key generation on execution (since the stem would be cached and not regenerated if the slot key or code keys were not pre-calculated)

Copy link
Contributor

@garyschulte garyschulte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, a couple non-blocking suggestions

matkt added 2 commits June 20, 2024 11:11
Signed-off-by: Karim Taam <[email protected]>
@matkt
Copy link
Contributor Author

matkt commented Jun 20, 2024

I updated the code in order to save stem , this one depends on this besu-verkle-trie PR hyperledger/besu-verkle-trie#64

@matkt matkt changed the title [VERKLE] Preload triekeys [VERKLE] Preload stems Jun 21, 2024
@matkt matkt requested a review from garyschulte June 24, 2024 08:49
@jflo
Copy link
Contributor

jflo commented Oct 31, 2024

already implemented via another branch

@jflo jflo closed this Oct 31, 2024
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.

3 participants