Store state tries longer than default

[calebcall]

I'm running a full node (--gcmode full). I'm querying a block that's 15 hours old, and while the block exists on my node, I get "missing trie node" for various other methods (eth_getBalance, eth_call, etc). How can I retain states for longer than the default (which seems to only be a few hours).

I've found --db.num-statetrie-shards as well as a few other various parameters that seem like they may be related.

[hyeonLewis]

In full node, it flushes states to DB every 128 interval (default config), and it means you can't access to arbitrary random historic states in full mode. (But you can still access to states of N % 128 == 0)

I think using archive mode with live pruning can be a solution for your situation. As you already know, in archive node, all state changes will be flushed into DB every block. But live pruning will delete state changes after LivePruningRetention. It will allow you to maintain states of only last LivePruningRetnetion blocks and you can configure the retention time. You can check the live pruning here.

[calebcall]

Thanks @hyeonLewis . Couple follow-up/clarification questions. I'm running several full nodes, all return the missing trie node response. However, if I run the same query against the public rpc node (https://public-en-cypress.klaytn.net) which according to https://docs.klaytn.foundation/docs/references/service-providers/public-en/ is a full node, it returns as expected. So can you share if this public node is not running the gcmode full and is actually running as an archive with pruning?

Just trying to understand the differences.

example query:

curl -X POST 'https://public-en-cypress.klaytn.net' \
-H 'Content-Type: application/json' \
-d '{
  "id": "0x19aac5f612f524b754ca7e7c41cbfa2e981a4432-0x06fdde03000000000000000000000000000000000000000000000000000000-161577795",
  "jsonrpc": "2.0",
  "method": "eth_call",
  "params": [
    {
      "data": "0x06fdde03000000000000000000000000000000000000000000000000000000",
      "to": "0x19aac5f612f524b754ca7e7c41cbfa2e981a4432"
    },
    "0x9A0A855"
  ]
}'

[hyeonLewis]

@calebcall Good question. Long story short, it's full node with upstream EN. The upstream feature allows full EN to be connected with upstream archive EN. If full EN can't handle the rpc request (specifically when missing trie node occurs), the full EN can send a request to connected upstream archive EN to handle the request. You can also utilize this with: Only running one archive node with live pruning and connect it to several full ENs as upstream node. Of course, you might need to use LB for it. You can check code here: https://github.com/kaiachain/kaia/blob/dev/networks/rpc/handler.go#L451

[calebcall]

Very cool! I'm actually maybe two weeks out from having a fully sync'd archive node. I'm going to put together a pruned archive as well and use the upstream approach. Thanks for the help!

[hyeonLewis]

Please make another issue if you have any troubles. Thanks.