Statemanager: Direct Storage Trie Usage Experiment

[holgerd77]

Can someone spot why this approach does not work (yet)? 🤔

I am trying to swap out the copied-storage-trie read (our SLOAD performance still drives me crazy) by using the original trie and temporarily setting a new root.

Running the client with:

cd ../trie && npm run build && cd ../client && DEBUG=ethjs,trie:* npm run client:start -- --vmProfileBlocks --executeBlocks=1999950-2000005

This gives me a receiptTrie error though.

[codecov[bot]]

Codecov Report

Attention: 11 lines in your changes are missing coverage. Please review.

Comparison is base (c0d5fc8) 87.93% compared to head (cfb943e) 87.20%.

Additional details and impacted files

Flag	Coverage Δ
block	88.34% <ø> (ø)
blockchain	91.61% <ø> (ø)
client	84.69% <ø> (?)
common	98.25% <ø> (ø)
devp2p	82.12% <ø> (ø)
ethash	∅ <ø> (∅)
evm	74.33% <ø> (ø)
genesis	99.98% <ø> (ø)
rlp	∅ <ø> (∅)
statemanager	?
trie	88.96% <62.06%> (-0.34%)	:arrow_down:
tx	?
util	89.13% <ø> (ø)
vm	80.20% <ø> (ø)
wallet	88.35% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[am1r021]

Can someone spot why this approach does not work (yet)? 🤔

I am trying to swap out the copied-storage-trie read (our SLOAD performance still drives me crazy) by using the original trie and temporarily setting a new root.

Running the client with:

cd ../trie && npm run build && cd ../client && DEBUG=ethjs,trie:* npm run client:start -- --vmProfileBlocks --executeBlocks=1999950-2000005

This gives me a receiptTrie error though.

I ran into a similar invalid receiptTrie error when I was doing the LMDB spike. The fix was awaiting two saveReceipts calls in vmexecution.ts as seen here. I was able to trace the issue to the point where I could see the saveReceipts put call finishing after the expected get call was made. Can look into adding the 2-line fix and see if it resolves the issue.

[holgerd77]

Updated this via UI