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

Update BonsaiLayeredWorldState implementation #1999

Merged
merged 11 commits into from
Mar 16, 2021

Conversation

matkt
Copy link
Contributor

@matkt matkt commented Mar 10, 2021

Signed-off-by: Karim TAAM [email protected]

PR description

Update BonsaiLayeredWorldState implementation to find valid code, storage and account corresponding to a block

Test performed

  • Fast sync bonsai trie goerli

Fixed Issue(s)

Changelog

|| persistedState.blockHash().equals(blockHash)
|| worldStateStorage.isWorldStateAvailable(rootHash, blockHash);
}

@Override
public Optional<MutableWorldState> getWorldState(final Hash rootHash, final Hash blockHash) {
if (layeredWorldStates.containsKey(blockHash)) {
return Optional.of(layeredWorldStates.get(blockHash));
} else {
Copy link
Contributor

Choose a reason for hiding this comment

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

If we don't load TrieLog layered world states from disk how do we then do traces beyond near chain head? We won't be able to do eth_call 1MM blocks back but we should be able to do trace_* from 1MM blocks back if we have the TrieLogs.

Copy link
Contributor Author

@matkt matkt Mar 11, 2021

Choose a reason for hiding this comment

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

Indeed I just put back the loading of the layer from the disk but in this case I put the nextLayer (=parent) to empty and I load it on demand (call getNextWorldView : https://github.com/hyperledger/besu/pull/1999/files#diff-b24e30196f7e0d254b3a27e89926831bb450c356a094f435e6a6daa80b10b09dR64)

so as not to load all layers for maybe nothing when we call getMutable

I tried it's work

@@ -146,7 +146,7 @@ public BlockReplay(
return Optional.empty();
}
final MutableWorldState mutableWorldState =
worldStateArchive.getMutable(previous.getStateRoot(), previous.getHash()).orElse(null);
worldStateArchive.getWorldState(previous.getStateRoot(), previous.getHash()).orElse(null);
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like there is a lingering type/name issue. If the return type is a MutableWorldState then the method name should be getMutable or getMutableWorldState. This should either go to just a WorldState or the method name should be getMutable

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done renamed to getMutable

@@ -129,15 +124,21 @@ public UInt256 getStorageValue(final Address address, final UInt256 key) {
while (currentLayer != null) {
final Optional<UInt256> maybeValue =
currentLayer.trieLog.getStorageBySlotHash(address, slotHash);
if (maybeValue.isPresent()) {
final Optional<UInt256> maybeOriginalValue =
currentLayer.trieLog.getOriginalStorageBySlotHash(address, slotHash);
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this is a good place for getOriginalStorageBySlotHash. Original in the sense of EIP-2200 gas costing. I think we need to go to renaming BonsaiValue getOriginal as getPrior to remove that confusion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

indeed I wanted to rename it in another PR but why not do it now

@@ -37,30 +37,31 @@
/** A World State backed first by trie log layer and then by another world state. */
public class BonsaiLayeredWorldState implements MutableWorldState, BonsaiWorldView, WorldState {

private final BonsaiWorldStateArchive worldStateArchive;
private final BonsaiWorldView parent;
private Optional<BonsaiWorldView> parent;
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this being re-worked so as only used for blocks that were before the persisted state? (eg persisted #100, this is a trie log for #99) In that case parent may not be the best name. perhaps nextTrieLog

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So we can have a layer or a persistate Worldstate so I renamed it to nextWorldView because those are both BonsaiWorldView.

Layer9 (parent = = Layer10), Layer10 (parent= = Layer11), Layer11 (parent==PersistedWorldState)

matkt added 5 commits March 11, 2021 15:21
Signed-off-by: Karim TAAM <[email protected]>
Signed-off-by: Karim TAAM <[email protected]>
Signed-off-by: Karim TAAM <[email protected]>
Signed-off-by: Karim TAAM <[email protected]>
Signed-off-by: Karim TAAM <[email protected]>
@matkt matkt marked this pull request as ready for review March 13, 2021 19:55
@matkt
Copy link
Contributor Author

matkt commented Mar 15, 2021

@shemnon Do you have any other remarks before its merge into master ?

@matkt matkt merged commit 8a0d002 into hyperledger:master Mar 16, 2021
RichardH92 pushed a commit to RichardH92/besu that referenced this pull request Mar 29, 2021
Update BonsaiLayeredWorldState implementation to find valid code, storage and account corresponding to a block with Bonsai trie storage mode

Signed-off-by: Karim TAAM <[email protected]>
Signed-off-by: Richard Hart <[email protected]>
@matkt matkt deleted the feature/tracing-fix branch April 13, 2021 11:21
eum602 pushed a commit to lacchain/besu that referenced this pull request Nov 3, 2023
Update BonsaiLayeredWorldState implementation to find valid code, storage and account corresponding to a block with Bonsai trie storage mode

Signed-off-by: Karim TAAM <[email protected]>
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.

2 participants