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

Add "archival check" for chains that must be served by archival nodes #74

Open
nymd opened this issue Jun 24, 2021 · 1 comment
Open
Assignees
Labels
enhancement New feature or request

Comments

@nymd
Copy link
Contributor

nymd commented Jun 24, 2021

Currently any node can join an "archival" chain ID and serve bad data due to their database being pruned.

Some calls, such as eth_getStorageAt, will return properly formatted results that do not register as errors when the node has pruning turned on. This results in bad data getting out to the end-user if a node-runner is not serving an archival chain ID with an archival node.

In addition to the sync check, the portal API should perform an "archival check" for chain IDs that are marked as such.

For EVM-based chains, the method of calling eth_getBalance at block height 0x0 will show the pruning state of the node.

Querying OpenEthereum with pruning turned on for archival data:

curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0", "method": "eth_getBalance", "params": ["0x0000000000000000000000000000000000000000", "0x2710"], "id": 1}' http://localhost:8555
{"jsonrpc":"2.0","error":{"code":-32000,"message":"This request is not supported because your node is running with state pruning. Run with --pruning=archive."},"id":1}

Querying BSC with pruning turned on:

curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0", "method": "eth_getBalance", "params": ["0x0000000000000000000000000000000000000000", "0x2710"], "id": 1}' localhost:8545
{"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"missing trie node dafa7081c603c29487e3a64a0da0a569485cdef17fe13867d53be92f26ef192e (path )"}}

Implementation should follow the same method as services/sync-check but the record that a node is improperly configured should last 24 hours. After 24 hours that record should expire and a node can be re-checked.

@nymd nymd added the enhancement New feature or request label Jun 24, 2021
@crisog crisog assigned crisog and unassigned crisog Aug 23, 2021
@rem1niscence rem1niscence self-assigned this Oct 18, 2021
@DragonDmoney
Copy link

Any progress? This issue is greatly affecting the quality of service.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants