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

-cache.triesinmemory flag ignored or doesn't work #676

Closed
nikitakoshikov opened this issue Jan 16, 2023 · 2 comments · Fixed by #677
Closed

-cache.triesinmemory flag ignored or doesn't work #676

nikitakoshikov opened this issue Jan 16, 2023 · 2 comments · Fixed by #677

Comments

@nikitakoshikov
Copy link

System information

Bor client version: [0.3.3-stable]
Heimdall client version: [0.3.0]

OS & Version: Windows / Linux / OSX: Linux ip-10-0-0-189.us-west-2.compute.internal 5.12.19-1.hsx.el8.x86_64 #1 SMP Tue Oct 26 03:14:08 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Environment: Polygon Mainnet

Type of node: Validator / Sentry / Archive - Sentry

Additional Information:

Overview of the problem

Eth_call suppose to work on historical block number up to configured value (-cache.triesinmemory) but it fails.

Reproduction Steps

git checkout 56d3058 (tag v0.3.3)
make bor
Exec binary with:
bor server -datadir "/data/bor/data" -port 30303 -http -http.addr '0.0.0.0' -http.vhosts '*' -http.corsdomain '*' -http.port 8545 -ipcpath "/data/bor/data/bor.ipc" -http.api 'eth,net,web3,txpool,bor' -chain mainnet -txpool.nolocals -txpool.accountslots 16 -txpool.globalslots 131072 -txpool.accountqueue 64 -txpool.globalqueue 131072 -txpool.lifetime '1h30m0s' -maxpeers 200 -metrics -bootnodes "enode://0cb82b395094ee4a2915e9714894627de9ed8498fb881cec6db7c65e8b9a5bd7f2f25cc84e71e89d0947e51c76e85d0847de848c7782b13c0255247a6758178c@44.232.55.71:30303,enode://88116f4295f5a31538ae409e4d44ad40d22e44ee9342869e7d68bdec55b0f83c1530355ce8b41fbec0928a7d75a5745d528450d30aec92066ab6ba1ee351d710@159.203.9.164:30303,enode://3178257cd1e1ab8f95eeb7cc45e28b6047a0432b2f9412cff1db9bb31426eac30edeb81fedc30b7cd3059f0902b5350f75d1b376d2c632e1b375af0553813e6f@35.221.13.28:30303,enode://16d9a28eadbd247a09ff53b7b1f22231f6deaf10b86d4b23924023aea49bfdd51465b36d79d29be46a5497a96151a1a1ea448f8a8666266284e004306b2afb6e@35.199.4.13:30303" -txlookuplimit '0' -ws -ws.port 8546 -ws.addr 0.0.0.0 -ws.origins '*' -rpc.txfeecap 10 -syncmode "snap" -gcmode "full" -cache.triesinmemory 1024
2) Check recent block number:
curl -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","method":"eth_blockNumber","id":1}' http://localhost:8545 {"jsonrpc":"2.0","id":1,"result":"0x2464640"}
3) Wait for at least 10 minutes, in this case - sleep 900;
4) Get up to date block number after sleep:
curl -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","method":"eth_blockNumber","id":1}' http://localhost:8545 {"jsonrpc":"2.0","id":1,"result":"0x24648e7"}
5) There were 679 blocks received (0x24648e7-0x2464640):
6) Run eth_call on most recent block number (less 128 default triesinmemory value):
curl -H 'Content-Type: application/json' http://localhost:8545 -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"from":"0x0000000000000000000000000000000000000000","data":"0x70a0823100000000000000000000000049a1b17480eccc4ef628e24efd62b48bfef87ac1","to":"0xdbc186e4b6e0cdec851387e6a0dfb6255c4d8132"},"0x24648e7"]}' {"jsonrpc":"2.0","id":1,"result":"0x0000000000000000000000000000000000000000000000000000000000002dfc"}
7) Step 6 works(block within trieinmemory), now execute the same call on a block number in the past hex(0x24648e7-128) ->0x2464867
curl -H 'Content-Type: application/json' http://localhost:8545 -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"from":"0x0000000000000000000000000000000000000000","data":"0x70a0823100000000000000000000000049a1b17480eccc4ef628e24efd62b48bfef87ac1","to":"0xdbc186e4b6e0cdec851387e6a0dfb6255c4d8132"},"0x2464867"]}' {"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"missing trie node 882323b1ea460977a10f83835e6dc3a86fd6d4836e098d277514a0f15b56edd5 (path )"}}
8) Even though block under 1024 -cache.triesinmemory key - step 7 failed.
Expected result - step 7 succeed with output from step 6.

Logs / Traces / Output / Error Messages

Please see in repro section

Additional Information

Please note - with below patch, everything is working accordingly to the changed amount:
`# git diff
diff --git a/core/blockchain.go b/core/blockchain.go
index 74fd4bfed..a33e0ac4c 100644
--- a/core/blockchain.go
+++ b/core/blockchain.go
@@ -145,7 +145,7 @@ var DefaultCacheConfig = &CacheConfig{
TrieTimeLimit: 5 * time.Minute,
SnapshotLimit: 256,
SnapshotWait: true,

  •   TriesInMemory:  128,
    
  •   TriesInMemory:  1024,
    

}
`
If you run binary with applied patch - Step 7 succeed:

@0xsharma
Copy link
Contributor

@nikitakoshikov thank you for raising this issue, the PR to resolve this has been merged to develop and should be added to the next release.

Thank you once again 💜

@nikitakoshikov
Copy link
Author

Thanks for the swift fix

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 a pull request may close this issue.

2 participants