-
Notifications
You must be signed in to change notification settings - Fork 861
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
[VERKLE] Preload stems #7206
Conversation
Signed-off-by: Karim Taam <[email protected]>
Signed-off-by: Karim Taam <[email protected]>
|
||
private Map<Bytes32, Bytes32> getCachedTrieKeysForAccount(final Address address) { | ||
return Optional.ofNullable(trieKeysCache.getIfPresent(address)) | ||
.orElseGet(ConcurrentHashMap::new); |
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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)
There was a problem hiding this 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
Signed-off-by: Karim Taam <[email protected]>
Signed-off-by: Karim Taam <[email protected]>
I updated the code in order to save stem , this one depends on this besu-verkle-trie PR hyperledger/besu-verkle-trie#64 |
already implemented via another branch |
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?
doc-change-required
label to this PR if updates are required.Locally, you can run these tests to catch failures early:
./gradlew build
./gradlew acceptanceTest
./gradlew integrationTest
./gradlew ethereum:referenceTests:referenceTests