中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC054
A block explorer page combines information with different origins. A transaction identifier, a receipt field, a decoded event name, a contract-verification badge and an address label do not all prove the same kind of claim. Read each field by asking where it came from, what transformation produced it and what conclusion it supports.
The page can be extremely useful without being a universal certificate. It may organise chain data, interpret bytes through an ABI, index selected history and add off-chain context. A careful reader preserves those distinctions instead of letting one reassuring badge validate everything on the screen.
This guide audits a fictional explorer page for a museum record. All identifiers are symbolic teaching labels. There is no real address to investigate, no allegation about a person and no instruction to connect a wallet or transact.
Choose your reading route
In this guide
- 1. Start with a page, not a conclusion
- 2. The supplied evidence packet
- 3. Give each field a provenance category
- 4. What the receipt supports
- 5. Decode the event without turning its name into authority
- 6. Source verification answers a matching question
- 7. A public name tag has its own source
- 8. Read index coverage and historical context together
- 9. Rewrite the overconfident report
- 10. A field-by-field audit method
- 11. Exercises and answers
- 12. Frequently asked questions
- Sources and next reading
Read sections 1–3 to identify the evidence layers. Sections 4–8 examine the event, verification badge, name tag and freshness fields. Sections 9–11 provide an audit exercise with answers.
Ethereum’s explorer documentation describes interfaces for blocks, transactions, accounts and other chain activity. That breadth makes an explorer convenient, but it also makes field-by-field reading important. A page can contain both execution and consensus information as well as presentation added by the service. Ethereum block explorers
Back to contents · Next section
1. Start with a page, not a conclusion
The fictional page concerns chain S, transaction TXa and contract C. It displays a green status, an event called RevisionRecorded, a “Source verified” badge and the public name tag “MuseumArchive”. A reader says, “This proves the museum approved revision 3, the contract is safe, and the record is final.”
That sentence contains several claims, none of which should be accepted as one package. Did the transaction execute successfully under the relevant rules? What does the event actually encode? Who supplied the name tag? What kind of verification does the badge describe? Which evidence establishes finality?
The purpose of the audit is not to distrust every field. It is to attach the right confidence to each field for the right reason. Accurate transaction data can coexist with an outdated annotation. Correctly matched source code can contain dangerous behaviour. A useful decoded event can describe a technical action without proving a real-world approval.
Write the reader’s claims separately before checking them. Otherwise a discussion about one field can quietly become an argument about a different claim.
Back to contents · Next section
2. The supplied evidence packet
For this exercise, the following records are supplied as correct observations in their stated contexts:
- Chain S and transaction TXa are identified.
- TXa is included in block H500 at height 500.
- Its matching receipt has success status under the toy’s Ethereum-style receipt interpretation.
- A retained receipt log was emitted by C and is decoded with the correct ABI V1 as RevisionRecorded(object42,3).
- A source-verification record establishes the specified source-to-bytecode match for C at H500.
- The explorer adds the public name tag MuseumArchive from its off-chain annotation process.
- The explorer’s event index is complete only through H500 at the observation time.
- A separately established head H503 is a descendant of H500; a correctly contextualised state read there returns revision 4 for object42.
The source-verification record concerns the simple non-proxy C in this exercise. Its code is unchanged between H500 and H503. A later valid state update accounts for revision 4. No supplied record establishes a legal identity, a safety audit, a real-world museum approval or finality coverage for H500.
These assumptions let us isolate interpretation. We are not asking the reader to reproduce an inclusion proof, discover a hidden proxy or diagnose a failed transaction. We are asking what each correct piece of evidence actually means.
Back to contents · Next section
3. Give each field a provenance category
Use four categories. Chain-derived fields come from the identified chain records. Decoded fields interpret those bytes using a schema or other rule. Service metadata describes the explorer’s own processing or verification work. Off-chain annotations add human or external context.
TXa’s identifier, H500’s identity and the matched receipt status belong to the chain-derived group in this packet. The readable event name and argument labels belong to the decoded group. The index coverage marker and verification report describe service work. MuseumArchive is an off-chain annotation.
These categories are not a ranking from good to bad. An annotation can be helpful, and decoding is often essential. The categories identify what evidence would support or correct the field. A wrong ABI is repaired differently from an outdated public label or a stale index.
Some fields span layers. A verification report compares chain bytecode with a compilation result, but the badge is still a service’s summary of that comparison. Preserve the underlying objects and matching criterion rather than treating the word “verified” as self-explanatory.
Back to contents · Next section
4. What the receipt supports
The supplied receipt supports the statement that TXa has the specified successful execution status in H500. Its transaction and block references matter: a status copied without those references is harder to associate with the intended event.
Ethereum’s RPC receipt representation includes transaction and block context, status and logs. An explorer can present those fields in a more readable form, but the presentation does not expand their meaning. Ethereum JSON-RPC receipt reference
Success under execution rules does not prove that the human purpose was appropriate. A correctly executed record update can still contain inaccurate information. Likewise, the existence of a receipt in a particular block does not by itself establish whatever finality standard a later decision requires.
For the audit, write: “TXa has a successful receipt in H500 under the supplied observations.” Do not append “therefore the museum legally approved it” or “therefore irreversible” unless separate evidence supports those additions.
This is a provenance limit, not a failure diagnosis. The receipt is not defective merely because it does not answer every question a reader wants to ask.
Back to contents · Next section
5. Decode the event without turning its name into authority
The correct ABI V1 interprets the retained log as RevisionRecorded(object42,3). The supported statement is that the log has that interpretation under the supplied ABI and emission context. The event’s readable name is part of the schema used to understand the bytes.
Solidity’s ABI specification describes how events use topics and data and how the ABI supplies their interpretation. Its indexed-field rules also mean that not every displayed event field should be assumed to contain a directly recoverable original value in every event design. Solidity 0.8.30 ABI specification
Our toy directly supplies the correct decoded object identifier and integer revision. It does not ask readers to reverse a hash or infer missing dynamic data. That keeps the audit focused on provenance rather than a new decoding exercise.
Now consider an interface that rewrites the event as “Museum approved revision 3”. That is a stronger interpretation. The event name alone does not establish who was permitted to emit it, what the application checked, or whether a real museum reviewed the underlying document.
Even an event literally named Approved would not settle those questions. A human-readable word in a schema is not an independent institutional certificate. To support an approval claim, inspect the application rule and the external authority relationship relevant to that claim.
Back to contents · Next section
6. Source verification answers a matching question
The supplied verification record establishes a particular source-to-bytecode match for C at H500. This makes the corresponding source useful for examining behaviour. It does not establish that the behaviour is safe, desirable or consistent with every claim in the comments.
Ethereum’s verification documentation distinguishes source-code verification from formal verification. Source verification concerns the relationship between source, compilation and deployed bytecode; different matching procedures can have different scope. Verifying smart contracts
For the toy, the matching scope is explicitly supplied, so there is no need to guess what the badge means. On a real page, a reviewer should identify the network, address, relevant code context, compiler information and the verification service’s result rather than relying on badge colour alone.
A source file can clearly reveal a rule that nobody should want. That would not invalidate the source match. It would show why readable code and a safety assessment are different deliverables.
Similarly, source matching does not authenticate the legal identity of the deployer or prove that an organisation endorses the application. Those claims need their own evidence. The advantage of verification is narrower and still valuable: it helps a reader connect human-readable material to the code being examined.
Back to contents · Next section
7. A public name tag has its own source
MuseumArchive is supplied as an explorer annotation. It is not a field that the chain’s receipt independently certifies. The audit should therefore preserve its source and any supporting reference.
Etherscan explains that its public name tags, labels and notes add context from public chain and internet information. It describes curator involvement and provides a process for reporting falsely attributed tags. Its information page was published on 7 February 2021. Etherscan public name tags, labels and notes
The lesson is not that a name tag is always wrong. It is that a name tag and a chain-derived address answer different questions. An address can be precisely identified while the relationship to a named organisation remains uncertain, outdated or narrower than the reader assumes.
For this packet, no external identity evidence is supplied. The correct statement is “the explorer labels C as MuseumArchive”. The stronger statement “the legally authorised museum controls C” is not established.
This distinction protects both the reader and the named party. A technical report should not turn a convenient label into an unsupported ownership assertion, endorsement or accusation.
Back to contents · Next section
8. Read index coverage and historical context together
The event index is complete through H500, while a separately established head is H503. This is a coverage statement about the explorer’s index, not evidence that the chain stopped at H500.
If a search shows no later event, the packet does not support the conclusion that no later event exists. The service has not established coverage for the later range. A blank result outside the supported range is weaker evidence than a complete search of a defined range.
The state read at H503 returns revision 4. That does not contradict the log recording revision 3 in H500. The packet supplies an intervening valid update, and H503 is explicitly a descendant of H500. A historical record and a later state can differ without either being wrong.
Do not silently combine the latest state field with the old receipt as though they were one snapshot. Put each block identity beside the claim it supports. A reader should be able to see which fields describe the transaction at H500 and which describe a later query at H503.
This section is about reading a page’s coverage promise. Building a complete historical index requires additional ingestion and retention guarantees; the presence of an explorer search box does not establish those guarantees by itself.
Back to contents · Next section
9. Rewrite the overconfident report
Return to the original statement: “This proves the museum approved revision 3, the contract is safe, and the record is final.” A defensible rewrite is more specific:
“On chain S, the supplied receipt associates TXa with successful execution in H500. Its log from C decodes under ABI V1 as RevisionRecorded(object42,3). A supplied verification record matches the specified source to C’s bytecode at that block. MuseumArchive is an explorer annotation. The packet does not establish institutional approval, a safety audit or finality coverage.”
That paragraph is longer because it preserves several separate claims. In a short report, the same discipline can be expressed with a few labelled lines. The key is that no field borrows authority from an unrelated badge.
Now add the later-state observation: “A separately contextualised read at descendant H503 gives revision 4; the packet supplies a later update. The explorer event index covers only through H500.” This makes the apparent discrepancy understandable without accusing the chain or explorer of inventing data.
The rewrite does not dismiss the page. It turns the page into a useful evidence record whose limits are visible.
Back to contents · Next section
10. A field-by-field audit method
For each important field, answer three questions: origin, supported claim, and limit. Then record the identifier or context needed to revisit the evidence.
For the decoded event, origin is the retained log plus ABI V1; supported claim is the given event interpretation; limit is that this alone does not prove institutional approval. For the name tag, origin is the explorer annotation process; supported claim is that the service assigns the label; limit is that independent legal identity is not supplied.
For index coverage, origin is service processing metadata; supported claim is coverage through H500; limit is that later absence is not established. For source verification, origin is the matching report; supported claim is its specified source-to-bytecode relationship; limit is that safety and authorisation remain separate questions.
An audit can also mark missing evidence explicitly. “No finality proof supplied” is a clear limitation. “Probably final because the page is green” is not a substitute.
When two explorers disagree, first determine which field differs and which category it belongs to. Different labels may reflect different curation. Different decoded event text may reflect different schemas. Different chain-derived fields require aligned network and block context before the disagreement can be assessed.
Do not settle every disagreement by majority vote among websites. The websites may share data sources, and the correct question may require a specific chain record or verification process rather than more copies of the same presentation.
Back to contents · Next section
11. Exercises and answers
Question 1. Which supplied field identifies the block containing TXa: the name tag, the verification badge or H500’s block identity?
Answer. H500’s block identity in the matched transaction and receipt context. The other fields serve different purposes.
Question 2. Does RevisionRecorded(object42,3) prove that a real museum approved the document?
Answer. No. It establishes the supplied log interpretation. Institutional authority and the real-world approval process need separate evidence.
Question 3. Can source verification and unsafe behaviour coexist?
Answer. Yes. A correct source match can expose unsafe behaviour; matching is not a safety audit.
Question 4. The event index ends at H500 and the established head is H503. Does a search with no later results prove there were no later events?
Answer. No. The packet does not supply index coverage for that range.
Question 5. The old log says revision 3; a read at descendant H503 says revision 4. Must one be false?
Answer. No. They describe different contexts, and the packet explicitly supplies a later valid update.
Question 6. What wording accurately reports the name tag without claiming unproven ownership?
Answer. “The explorer labels C as MuseumArchive.” Add the annotation’s source if available; do not invent a legal identity conclusion.
Back to contents · Next section
12. Frequently asked questions
Is an explorer page itself a cryptographic proof?
Not automatically. It is an interface presenting information. Some tools may expose proofs or verification features, but their scope must be checked separately.
Does a green success status mean the code was audited?
No. Execution status and a safety assessment are different claims with different evidence.
Should I ignore labels and decoded names?
No. They make records understandable. Keep their provenance and avoid treating their human-readable wording as stronger authority than it provides.
Can a current page explain a historical transaction without block context?
Not reliably when relevant state or interpretation changes over time. Preserve the historical block and the context of any later query.
Back to contents · Next section
Sources and next reading
Primary sources checked on 12 October 2026:
- Ethereum block explorers, for the range of presented information.
- Ethereum JSON-RPC API, for receipt context.
- Solidity 0.8.30 ABI specification, for event encoding and interpretation.
- Ethereum source-code verification, page updated 22 October 2025, used only for the source-matching distinction.
- Etherscan public name tags, labels and notes, published 7 February 2021.
The page, labels, records and audit answers are fictional teaching material. They are not a report about a real contract, museum or explorer incident.