中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC053
Two RPC endpoints can return different numbers without answering the same question. Before deciding that one answer is wrong, align the network, method, parameters, block identity and interpretation of the result. A successful connection is only the beginning of that comparison.
For blockchain reads, “latest” is especially easy to misread. It is a moving selection made by the responding node, not a shared snapshot that every endpoint must resolve identically at every instant. A block number also needs context: two branches can contain different blocks at the same height.
This guide uses an invented catalogue getter and prepared response records. No live service is queried, no API key is required, and no transaction is submitted. The lesson is how to classify evidence before choosing a conclusion.
Choose your reading route
In this guide
- 1. Write down the complete question
- 2. The first pair of answers is not a contradiction
- 3. Align to one identified block
- 4. Equal height does not mean equal block
- 5. Read the response layer that actually failed
- 6. Missing historical state is not a zero value
- 7. Null, zero and empty bytes need method semantics
- 8. An execution call is not a submitted transaction
- 9. Network identity comes before numerical comparison
- 10. A compact reconciliation worksheet
- 11. Exercises and worked answers
- 12. Frequently asked questions
- Sources and next reading
Sections 1–4 explain why apparently conflicting answers may refer to different states. Sections 5–8 distinguish errors, absent data, method results and simulations. The final sections provide a comparison worksheet and worked answers.
For general request contracts, authentication, versioning and retry semantics, see How APIs Work. This article concentrates on blockchain-specific query context and the evidence needed to compare two RPC results.
Back to contents · Next section
1. Write down the complete question
The informal question is “How many records are in the catalogue?” The technical question must identify the network, the application, the getter, its arguments and the state in which the getter is evaluated. If relevant, it must also preserve caller context and execution options.
Ethereum’s JSON-RPC documentation distinguishes methods for reading state, obtaining chain data and interacting with transactions. Several state methods accept a block parameter. Method and context therefore belong to the meaning of the answer, not merely to the mechanics of obtaining it. Ethereum JSON-RPC API
For our toy, a read-only getter returns an unsigned integer catalogue count. Its code and decoding rule are fixed. Both endpoints receive the same application reference, getter arguments and caller context, with no state overrides. The exercise supplies the correctly decoded values, so it is not an ABI-decoding tutorial.
Only the block selection changes in the first comparison. This restriction is deliberate: it allows one source of disagreement to be examined at a time. In a real review, failing to preserve the other parameters would leave several possible explanations open.
Back to contents · Next section
2. The first pair of answers is not a contradiction
On fictional chain S, block A100 at height 100 has catalogue count 7. Its child A101 at height 101 has count 9. The labels A100 and A101 stand for distinct block identities, not literal hashes or usable RPC parameters.
At the observation time, endpoint P resolves its latest state to A101 and returns 9. Endpoint Q resolves its latest state to A100 and returns 7. The exercise provides these actual resolved block identities as additional evidence; a bare scalar RPC result need not include them automatically.
Both values agree with the supplied states. P answers about A101; Q answers about A100. The mismatch does not demonstrate that either getter execution is incorrect.
It also does not prove why Q is behind P. Possible causes would require further evidence. The bounded conclusion is that their selected states differ in the supplied observation. Do not turn that into an accusation that Q is malicious or a declaration that the entire network has stopped.
If the required task was specifically “read at A101”, Q’s response about A100 does not satisfy it, even though seven is correct for A100. Correctness at one context and fitness for another request are different assessments.
Back to contents · Next section
3. Align to one identified block
Now the worksheet supplies that both endpoints support the required block-hash selection and possess the state needed for A100. Query the same getter at A100 with the same remaining context. Both correctly return 7.
The comparison has changed because the question is now aligned. It is no longer “what does your node currently select as latest?” but “what does this getter return in the state of this identified block?”
EIP-1898 specifies block-hash selection for several state-query methods, including eth_call, and an optional requireCanonical condition. The proposal is Final and was created on 1 April 2019. Actual endpoint support still needs to be established rather than inferred from the existence of the standard. EIP-1898
An explicit block identity can stabilise the state context, but it does not independently prove that the endpoint evaluated the request honestly. Our exercise supplies correct execution. A real user who needs independent verification must identify how that responsibility is discharged.
Agreement between two hosted responses is evidence of agreement, not automatically evidence of independent validation. The endpoints could share infrastructure or data. Comparing their answers is useful, but it does not replace examining their dependencies and the required assurance level.
Back to contents · Next section
4. Equal height does not mean equal block
For a separate branch card, reset the situation. A100 and B100 are competing blocks at the same height 100 on the same fictional chain S. The catalogue count is 7 at A100 and 11 at B100. Do not combine this card with the earlier parent-child history as though it were one simultaneous canonical sequence.
P supplies a result tied to A100; Q supplies a result tied to B100. Both records say height 100. The values differ because the identified states differ. Matching only the height would conceal that fact.
The EIP-1898 requireCanonical flag adds another question: must the selected block be canonical according to the responding node? It defaults to false. When true, a noncanonical block is a distinct error case from a block the node cannot find. The specification recommends distinguishing those errors. EIP-1898 canonicality condition
For our card, suppose P retains A100’s state but currently considers B100 canonical. A request for A100 without the canonicality requirement may be answered under the supplied support assumptions. Requiring canonicality causes the request to fail that check. Neither outcome says that A100’s old state bytes have changed.
Canonical according to the callee is also not a certificate of finality. The selected head can change under the protocol’s rules. If a task requires finality, it needs the appropriate finality evidence as well as an identified block.
Back to contents · Next section
5. Read the response layer that actually failed
Consider a prepared HTTP response with status200 whose JSON-RPC body contains an error object and no result. It is not a successful catalogue answer. The transport response arrived, but the RPC operation reported an error.
JSON-RPC 2.0 defines result and error responses, with a matching request identifier used to correlate replies. A successful response uses result; an error response uses error. The two are not both present in a compliant response. JSON-RPC 2.0 specification
For this worksheet, the error record is correctly matched to the intended request. That assumption prevents a different problem, such as accidentally comparing a reply from another request in a batch. In an actual review, correlation must be checked rather than presumed.
Preserve the error category and relevant context. “Unsupported method”, “selected block not found” and “execution failed” do not mean the same thing. This article does not assign universal numeric codes to every provider-specific failure; implementation details and the applicable specification matter.
A report should therefore say which layer supplied which evidence. “The HTTP request returned a body, and the matched RPC response reported a missing resource” is more informative than “the blockchain returned zero”.
Back to contents · Next section
6. Missing historical state is not a zero value
In the next card, an endpoint can identify an older block but cannot serve the historical state needed to execute our getter there. Its prepared response explicitly reports that limitation. The worksheet supplies no successful getter result.
The correct classification is “historical state unavailable from this endpoint for this request”. Do not convert the error into zero, an empty catalogue or proof that the application did not exist. Those are claims about state contents, not about whether a service can provide the state.
Ethereum’s archive-node documentation discusses access to historical state and distinguishes that storage capability from ordinary node operation. Historical query support is therefore a capability to establish for the chosen endpoint. Ethereum archive nodes
A second endpoint that can answer the exact historical query may be useful. But compare the same network, block, method and parameters before treating its answer as the missing result. Replacing the query with a latest-state read changes the task rather than repairing historical coverage.
The distinction also helps interpret an apparently healthy service. A node can respond to recent queries while lacking data needed for an old one. A single unsupported historical read does not prove a complete outage; it does prove that the requested function was not supplied.
Back to contents · Next section
7. Null, zero and empty bytes need method semantics
Our catalogue getter returns an integer. A correctly decoded zero would be a legitimate count if the getter successfully evaluated to zero in the requested state. That is very different from an error record that contains no result.
Other RPC methods have other result contracts. Ethereum’s transaction-receipt method can return null when no receipt is found. Such a response must be interpreted in the responding node’s context; it should not be silently promoted to proof that the transaction never existed anywhere. Ethereum JSON-RPC method reference
Similarly, empty return bytes from an execution call are not automatically the integer zero. Their interpretation depends on the called code and decoding contract. A decoder expecting an encoded integer cannot invent one merely because the transport succeeded.
In the worksheet, keep the raw result category beside the interpreted value: successful integer result, null under a specified method, empty bytes, or error. Otherwise a user interface can erase the distinction by turning every missing or unexpected result into the same displayed zero.
Do not generalise one method’s null meaning to all methods. The useful habit is to consult the exact contract for the operation that was requested, rather than treating JSON values as universal blockchain facts.
Back to contents · Next section
8. An execution call is not a submitted transaction
A prepared eth_call record shows the result of evaluating a call under the selected state and context. It does not itself submit a transaction that changes canonical chain state. The Ethereum method documentation explicitly distinguishes this execution from creating a blockchain transaction. Ethereum eth_call reference
For example, a hypothetical method could evaluate successfully against A100 but fail against A101 because a relevant application condition changed. That difference is meaningful if the contexts are preserved. It is not proof that a later signed transaction will succeed under every future ordering.
A simulation result is also sensitive to its inputs. If two calls use different senders, arguments or state overrides, aligning the block alone does not align the entire question. The earlier toy fixed those fields precisely to avoid that ambiguity.
This guide supplies no transaction-sending exercise. Its conclusion is about the evidence of the read or simulation, not permission to act on a live service. A later state-changing operation would need its own authority, parameters and outcome evidence.
Back to contents · Next section
9. Network identity comes before numerical comparison
Suppose endpoint P answers from chain S and endpoint Q answers from another network T. Both use a catalogue-looking application reference, and both return 7. The matching number does not make them answers to the same request.
The worksheet’s network identity is established separately. In a real review, record the intended network and the evidence used to recognise it. A familiar endpoint name or a single reported identifier should not be treated as an independent proof of an endpoint’s honesty.
Application identifiers also need their network context. Identical-looking address strings on different networks need not designate the same code or state. Comparing numbers before identifying the network can produce a false agreement as easily as a false disagreement.
Now reverse the situation: both endpoints are genuinely on S and both query A100, but one evaluates a different getter. That comparison is also misaligned. The chain and block are necessary context, not a replacement for the method and argument fields.
The complete question is a bundle. Removing one field because the result happens to look plausible weakens the conclusion that the comparison supports.
Back to contents · Next section
10. A compact reconciliation worksheet
For each prepared response, record:
- Intended network and observed network context.
- Endpoint and observation time, without assuming provider independence.
- Method, application reference, arguments and relevant execution context.
- Requested block selector and actual resolved block identity when established.
- Any canonicality requirement and separate finality requirement.
- Transport outcome and matched JSON-RPC result or error.
- Data-availability or method-support limitations.
- Decoding rule and the narrowly justified interpretation.
Then compare rows only after aligning their questions. If the contexts differ, classify the difference before discussing values. If the contexts match and successful values still conflict under deterministic assumptions, the conflict deserves investigation; the table alone does not identify which endpoint is wrong.
Useful next evidence might include the exact requests, raw responses, documented support, block references and independently verified state. The worksheet does not prescribe blindly repeating state-changing calls or treating a majority of endpoint answers as consensus.
A strong final sentence names the limit: “These values differ because the supplied blocks differ,” or “These aligned results conflict, and the available evidence does not resolve the cause.” Both are better than an unjustified claim that a chain is corrupt.
Back to contents · Next section
11. Exercises and worked answers
Question 1. P returns 9 at A101; Q returns 7 at A100. Both values match the supplied states. Is this proof of incorrect execution?
Answer. No. They evaluated different states. If the requested job required A101, Q’s A100 answer does not satisfy that job.
Question 2. A100 and B100 are both at height 100 but have counts 7 and 11. What field is missing from a height-only comparison?
Answer. Exact block identity. Equal heights do not establish equal states.
Question 3. An HTTP 200 response contains a matched JSON-RPC error for unavailable historical state. What is the catalogue count?
Answer. Unknown from this response. The error is not a count of zero.
Question 4. P retains A100 but regards B100 as canonical. What changes when the A100 request requires canonicality?
Answer. Under the supplied EIP-1898 support, the canonicality check rejects A100. Without that requirement, retained state may be served. Neither answer establishes finality.
Question 5. Two endpoints return 7, but one is on S and the other on T. Is the intended S query corroborated twice?
Answer. No. The second row concerns another network.
Question 6. A successful eth_call predicts a return value. Does that demonstrate a successfully included transaction?
Answer. No. It is execution evidence for the supplied call context, not evidence of a submitted or included state-changing transaction.
Back to contents · Next section
12. Frequently asked questions
Should I always prefer the larger returned number?
No. Larger is not a correctness criterion. Identify the query and state first.
Does requireCanonical mean finalised?
No. It asks about canonicality according to the responding node. Finality requires its own protocol-specific evidence.
Can an endpoint answer recent reads but fail older ones?
Yes. Historical data support is a separate capability. The result must be interpreted for the requested method and block.
Do several matching endpoints remove all trust assumptions?
No. They may share dependencies, and response agreement is not the same as independently checking the underlying state.
Back to contents · Next section
Sources and next reading
Sources checked on 12 October 2026:
- EIP-1898, Final, created 1 April 2019.
- JSON-RPC 2.0 specification, origin date 26 March 2010, updated 4 January 2013.
- Ethereum JSON-RPC API, for method-specific state selection and results.
- Ethereum archive nodes, for historical-state capability.
The catalogue counts and endpoint records are original teaching examples. Symbolic block labels are not real hashes, and the article makes no claim about the behaviour of a live provider.