feat(api/c-chain): change of behavior for eth_getProof #1996
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
qdm12
commented
Jan 13, 2025
| Note the `eth_getProof` is acting differently from release v0.14.1: | ||
|
|
||
| - On archive nodes (`"pruning-enabled": false`): queries for historical proofs for state older than approximately 24 hours preceding the last accepted block will be rejected by default. This can be adjusted with the new option `historical-proof-query-window` which defines the number of blocks before the last accepted block which should be accepted for state proof queries, or set to `0` to accept any block number state query. | ||
| - On `pruning` nodes: queries for proofs past the tip buffer (32 blocks) will be rejected |
There was a problem hiding this comment.
this is the same (except the error message I suppose) as the previous behavior isn't it? 🤔
If it is, should we remove it from here?
There was a problem hiding this comment.
It's not the exact same behavior as they would have responded to proofs for blocks matching the commit height 4096, so we can leave this here.
Also perhaps this should be under the Ethereum APIs section, we can add a new section for eth_getProof if there's not one already and just include this notice, mentioning the API otherwise behaves as upstream.
There was a problem hiding this comment.
It's already in the ## Ethereum APIs section / ### Standard Ethereum APIs sub-section.
I've moved this to an #### Exceptions subsection as a bullet point, let me know if that works.
qdm12
force-pushed
the
qdm12/api/c-chain/eth_getProof
branch
from
cd874a5 to
2101c6e
Compare
Comment on lines
+86
to
+91
| - `eth_getProof` behaves differently than geth, from release v0.14.1, with the following differences: | ||
| - On archive nodes (`"pruning-enabled": false`), queries for proofs for state older than approximately 24 hours preceeding the last accepted block will be rejected by default. | ||
| This can be adjusted with the option `historical-proof-query-window` which defines the number of blocks before the last accepted block which should be accepted for state proof queries, or set it to `0` to accept any block number state query. | ||
| - On pruning nodes (`"pruning-enabled": true`), queries for proofs past the tip buffer of 32 blocks are always rejected | ||
|
|
||
|
|
There was a problem hiding this comment.
Suggested change
| - `eth_getProof` behaves differently than geth, from release v0.14.1, with the following differences: | |
| - On archive nodes (`"pruning-enabled": false`), queries for proofs for state older than approximately 24 hours preceeding the last accepted block will be rejected by default. | |
| This can be adjusted with the option `historical-proof-query-window` which defines the number of blocks before the last accepted block which should be accepted for state proof queries, or set it to `0` to accept any block number state query. | |
| - On pruning nodes (`"pruning-enabled": true`), queries for proofs past the tip buffer of 32 blocks are always rejected | |
| `eth_getProof` behaves differently than geth, from release `v0.14.1`, with the following differences: | |
| - On archival nodes (nodes with`pruning-enabled` set to `false`), queries for state proofs older than 24 hours preceding the last accepted block will be rejected by default. This can be adjusted with `historical-proof-query-window`, which defines the number of blocks before the last accepted block that can be queried for state proofs. Set this option to `0` to accept a state query for any block number. | |
| - On pruned nodes (nodes with `pruning-enabled` set to `true`), queries for state proofs past a 32 block buffer are always rejected. | |
There was a problem hiding this comment.
- TIL I've been using
preceedingwrong forever, thanks! Only 1e! - Sorry for the extra line, I hate those extra lines as much as the md linter!
- Isn't it
pruning nodesinstead ofpruned nodes? We're talking about avalanche nodes, not i.e. trie nodes 🤔 queries for state proofs past a 32 block buffer are always rejected.➡️queries for state proofs outside the 32 blocks window trailing the last accepted block are always rejected.- since the32 block buffermight leave some room for interpretation and is a bit of an implementation details I'd think?
Thanks!
qdm12
commented
Jan 15, 2025
| @@ -81,6 +81,14 @@ For batched requests on the [public API node](/tooling/rpc-providers) , the maxi | |||
| number of items is 40. We are working on to support a larger batch size. | |||
| </Callout> | |||
|
|
|||
| #### Exceptions | |||
|
|
|||
| - `eth_getProof` behaves differently than geth, from release v0.14.1, with the following differences: | |||
There was a problem hiding this comment.
the release version should the avalanchego version, not the coreth version. I suppose we should wait for the next avalanchego release using coreth v0.14.1 (unreleased) to merge this PR.
qdm12
added
the
DO NOT MERGE
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.