中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC043
An Ethereum node’s execution client checks execution-related rules and state changes. Its consensus client follows consensus rules, including chain selection and finality. Optional validator software performs assigned signing duties. These responsibilities cooperate, but a successful result from one component does not automatically establish a result belonging to another.
That distinction explains several otherwise confusing observations. An execution payload can be valid without being finalised. A consensus component can display a head while execution validation remains incomplete. A node can validate the chain without performing validator signing duties.
This guide turns the architecture into a diagnostic worksheet. Rather than calculating gas again or repeating proof-of-stake voting mathematics, we ask which component produced a claim, which object it concerns, and what evidence is still missing.
Choose your reading route
In this guide
- 1. Start with responsibilities, not product names
- 2. Keep the two kinds of block identifier separate
- 3. The main evidence packet
- 4. What VALID contributes
- 5. What the consensus side contributes
- 6. SYNCING is an incomplete answer
- 7. ACCEPTED does not mean fully validated
- 8. INVALID is not repaired by an attractive head label
- 9. A stopped component creates a local evidence gap
- 10. No validator component does not mean no validation
- 11. Payload construction is another handoff
- 12. Build an incident note that can be checked
- 13. Worked exercise: classify six incident cards
- 14. Frequently asked questions
- Sources and next reading
Read the three-role map first. Then follow the named objects F, X, BF and BX through the main case. Compare the missing-data and unavailable-component cases before attempting the incident worksheet and answer key.
All node names, identifiers and observations below are fictional. They are deliberately short labels, not valid hashes or live API requests. This is a reading exercise, with no staking, key creation, signing, configuration changes or transactions.
The architecture sources were checked on 12 October 2026. The Engine API example is explicitly drawn from its Paris-specific V1 specification; it is not a claim that every present or future Ethereum payload uses that version.
Back to contents · Next section
1. Start with responsibilities, not product names
The execution client handles execution-side transaction processing and state. The consensus client handles consensus-side tracking and decisions. Validator software adds protocol signing duties, such as proposals and attestations, when appropriately enabled and assigned.
The Ethereum node architecture guide describes these cooperating roles and the Engine API connection between the execution and consensus clients. It also distinguishes execution-payload construction from the consensus and validator work involved in proposing a complete block.
For our worksheet, call the execution client EL, the consensus client CL and the optional validator component V. These are functional labels. They do not identify brands, programming languages, separate companies or independent physical machines.
A single operator could control all three. Conversely, an application might consume information from several services without operating any of them. Count responsibilities before counting boxes in a diagram; otherwise a software diagram can be mistaken for evidence of organisational decentralisation.
Back to contents · Next section
2. Keep the two kinds of block identifier separate
Our node N sees a beacon block labelled BX that contains an execution payload labelled X. The label BX refers to the beacon-block identity; X refers to the execution-block hash associated with that payload. They are related through the containing object, not interchangeable names for one hash.
An earlier beacon block BF contains execution payload F. The supplied ancestry is that BX descends from BF, and execution block X descends from F. Both relationships are part of the exercise evidence, not conclusions drawn merely because one displayed number is larger.
A report about BX therefore needs an explicit mapping before it can answer a question about X. Copying the characters of a beacon root into a field expecting an execution-block hash would change the type of object being named.
This is a common diagnostic pattern beyond Ethereum: first identify the namespace. A transaction identifier, a block identifier, a state root and a process identifier can all look like opaque strings, yet they answer different questions.
Back to contents · Next section
3. The main evidence packet
At observation time t1, N has the following supplied information. The clients use compatible rules for the same network and relevant protocol version; the observations are current and refer to the same local node.
- EL has completed its execution checks for X and reports VALID for that payload.
- CL’s selected head is BX, whose execution payload is X.
- CL’s latest finalised beacon block in this packet is BF, whose execution payload is F.
- BX is a proper descendant of BF. No later finalised checkpoint covering BX is supplied.
- The worksheet supplies that the relevant consensus checks and ancestry mapping have been verified, rather than merely copied from an untrusted screen.
We may describe X as execution-validated and associated with the selected head in this packet. We may not describe X as finalised on the strength of BF alone. BF is an ancestor, so its finality covers the earlier history through that point, not every later descendant.
Notice how little arithmetic is involved. The difficulty is joining the right statements without silently upgrading one into another. A green execution status and a current head label still leave a separate finality question.
Back to contents · Next section
4. What VALID contributes
In the Paris Engine API specification, payload validation checks the applicable execution-related rules. A successful completed validation returns VALID. The same document distinguishes missing-data and incomplete-validation responses from that result.
Applied to our fictional packet, VALID(X) supplies one necessary part of N’s assessment: execution validation for this object and context. It does not itself say that BX is the chosen beacon head, that X is covered by finality, or that an application event described a true physical observation.
The scope matters even when the software is working correctly. Suppose an application asks, “Can I say the catalogue entry is final?” EL’s response concerns execution validity. The application still needs the consensus relationship and the relevant finality evidence, followed by its own interpretation of the catalogue’s meaning.
A report also has provenance. Receiving a string saying VALID from a remote service is a report from that service. Our exercise explicitly supplies trustworthy local observations; a real reader would need to establish which service answered and what validation it actually performed.
Back to contents · Next section
5. What the consensus side contributes
CL tracks consensus information and applies the relevant chain-selection and finality rules. For this lesson, those rules are already part of the node’s verified operating context. We do not replace them with a slogan such as “the branch with the most votes always wins”.
The important output is a relationship among identified objects: the selected beacon head, the finalised checkpoint or block represented by the observation, and the execution payloads associated with that history. Head selection and finality need separate labels even when both are shown on one dashboard.
At a later time t2, suppose the packet changes: a genuinely verified finalised beacon block BG is BX itself or a descendant of BX. Keep the same network, compatible rules and verified ancestry. Then the finality evidence covers BX and its associated execution history through X.
That is a new evidential event, not a reinterpretation of EL’s earlier VALID result. Record the new consensus observation and its time. Keeping this distinction makes a later audit understandable instead of leaving one undated “confirmed” label.
Back to contents · Next section
6. SYNCING is an incomplete answer
Consider a separate case Y. CL has received a beacon block BY containing execution payload Y, but EL lacks data needed to validate Y. In the Paris-specific example, a SYNCING response can represent that missing prerequisite.
The correct note is “execution validation is not yet established by this response”. It is not “Y is valid because the client has not reported INVALID”. Absence of a completed rejection is not completion of the required checks.
If the missing data later arrives, EL may complete validation. The later result must be recorded separately. Do not invent the eventual outcome from the earlier response: Y could pass, or the completed checks could find a problem.
For application reporting, this suggests a useful vocabulary: distinguish received, execution-validation pending, execution-validated, selected and finalised. A compact interface can still preserve these distinctions internally, rather than forcing every observation into success or failure too early.
Back to contents · Next section
7. ACCEPTED does not mean fully validated
The same Paris specification includes ACCEPTED for specified circumstances involving a payload that has not been fully validated. The word sounds reassuring in ordinary English, but its technical meaning is defined by that method and version.
In a separate fictional case Z, the supplied response is ACCEPTED under those specified conditions. The analyst must not relabel it VALID. Nor should the analyst assume it means transaction-pool admission, recipient acceptance, block finality or business approval.
The lesson is to preserve the original status alongside a plain-language interpretation. Write “ACCEPTED, execution validation incomplete in this API example”, rather than replacing the status with a broad green tick.
This is also why an API dictionary belongs beside an incident record. Status names are not universal across methods, clients or protocols. Read the matching specification instead of transferring a familiar meaning from another endpoint.
Back to contents · Next section
8. INVALID is not repaired by an attractive head label
Now suppose EL completes validation of payload Q and reports INVALID. Another display claims that the associated beacon block BQ has many supporting messages. That display does not convert an invalid execution result into a valid state transition.
Our diagnostic task is to investigate the inconsistent evidence: wrong network, mismatched object mapping, stale observations, incompatible rules, faulty software or an unreliable report are possible categories to examine. The worksheet does not identify which cause actually occurred.
It would be a mistake to settle the inconsistency by saying that consensus weight grants permission to ignore execution rules. The node architecture combines the responsibilities; it does not let one component’s appealing summary abolish the other’s validity requirements.
Likewise, do not claim that a single error report proves the entire network has failed. First establish what this node checked, which branch it concerned and whether the purported conflicting claim was verified at all.
Back to contents · Next section
9. A stopped component creates a local evidence gap
Suppose N’s EL becomes unavailable at t3 while CL continues receiving network information. The analyst can no longer assume that N is completing fresh execution validation merely because CL’s interface still responds.
Some observations may describe optimistic tracking or other incomplete validation states. The Beacon API syncing-status schema separately exposes syncing, optimistic-tracking and execution-client-offline indicators. These are useful distinctions, not interchangeable measurements of one general health score.
Now reverse the situation: CL becomes unavailable while EL can still answer some queries about stored execution data. A successful historical query does not establish that N has current consensus or finality information. The returned data may be perfectly useful for a narrower historical question.
In either case, describe N’s missing capability precisely. One unavailable local component does not, by itself, demonstrate that Ethereum as a whole has stopped. A local application dependency and a network-wide protocol failure are different scales of claim.
Back to contents · Next section
10. No validator component does not mean no validation
Suppose N operates its execution and consensus clients correctly but has no active validator component. Under our supplied conditions, N can still follow and validate the chain without creating validator signatures for assigned proposals or attestations.
The word “validator” causes confusion because it names a protocol participation role, while “validate” also describes the broader act of checking rules. A node can perform checking without that additional signing role.
The Ethereum nodes and clients guide describes the execution/consensus combination and the optional validator software. This lesson concerns those responsibilities, not eligibility amounts, rewards, deposits or operational setup.
When diagnosing a missing signature, ask whether the relevant signing role and duty were present. When diagnosing unchecked execution, ask about EL’s completed checks. Looking for a validator process is not a substitute for asking either question precisely.
Back to contents · Next section
11. Payload construction is another handoff
Validation of a received payload and construction of a candidate payload are different jobs. In a simplified local construction path, the consensus side requests execution-payload work, EL assembles execution content, and the wider proposal path incorporates that content into a beacon-block proposal.
A constructed candidate is not evidence that it was published, selected or finalised. Keep the identifiers from the construction process distinct from the final identity of the resulting block and from any later acceptance evidence.
Our map deliberately omits external builder and relay arrangements. Their existence means a real deployment needs a more detailed responsibility map, not that the simple local map should be stretched to cover every production arrangement without checking.
For this exercise, the useful question is modest: “Which handoff has actually completed?” A request sent, a payload produced, a proposal signed and a proposal observed on the selected chain are different observations with different responsible components.
Back to contents · Next section
12. Build an incident note that can be checked
A good note preserves enough context for another reader to reproduce the classification. It need not contain secrets, private keys or complete operational configuration.
- Name the network, relevant protocol/API version and observation time.
- Identify the reporting node or service and the component that supplied each fact.
- Keep beacon-block identities separate from execution-block hashes, with the verified mapping.
- Record the exact validation status and whether its prerequisites were complete.
- Record head selection and finality separately, including the ancestry that makes any coverage claim true.
- State which component or observation is unavailable, stale or unverified.
- Write the narrow conclusion and the next missing evidence, rather than a generic success label.
For the t1 packet, the conclusion is: “N reports X execution-validated and BX selected; the supplied finality reaches BF/F and does not yet cover BX/X.” This sentence is longer than “confirmed”, but its meaning survives a change of interface.
Back to contents · Next section
13. Worked exercise: classify six incident cards
Use only the supplied facts. All cards concern the same fictional network with compatible rules unless a card says that a fact is unknown. The named observations are authentic; whether they are sufficient is the question.
- Card A: EL reports VALID(X), CL selects BX containing X, and finality reaches proper ancestor BF containing F.
- Card B: EL reports SYNCING(Y) because required parent data is missing. A dashboard displays BY.
- Card C: The Paris-specific response for Z is ACCEPTED, with full execution validation not completed.
- Card D: EL reports INVALID(Q). An unverified screen says BQ is popular.
- Card E: EL is unavailable; CL responds and reports optimistic tracking. No fresh completed execution result is supplied.
- Card F: EL and CL complete their ordinary checking, but there is no active validator component.
For each card, answer two questions: what can be stated now, and which tempting conclusion must be withheld? Then apply the extension: Card A gains verified finality for BG, a descendant of BX. Which part of the answer changes?
Answers and reasoning
A supports execution validation and selected-head association for X, but not finality for X. BF is earlier; a finalised ancestor does not finalise every later descendant. The missing evidence is finality coverage reaching BX through verified ancestry.
B supports a missing-data diagnosis, not completed execution validity. A displayed BY does not fill that gap. C likewise lacks completed validation, though its named API status and conditions differ from B. Do not merge the two original status records.
D supports an invalid execution result from the supplied EL observation. The unverified popularity claim cannot override it; investigate the conflicting reports without declaring a network-wide incident from this card alone.
E identifies a local execution-validation gap. Optimistic tracking is not a substitute for the missing completed result. F permits ordinary node checking under the supplied conditions, while no validator signing duties are performed by an absent component.
In the extension, verified finality for descendant BG covers BX and its execution history through X. EL’s original validation result did not change; the consensus evidence did. Record the new observation rather than rewriting what was known at t1.
Back to contents · Next section
14. Frequently asked questions
Does a valid execution payload have to become the selected head?
No. Execution validity and selection answer different questions. A payload may satisfy execution checks without being on the selected branch. Our main packet supplies selection separately, rather than deriving it from VALID.
Can a successful HTTP response prove the node is fully synced?
No. Transport success says the request received a response. Read the response’s actual fields, object context and freshness. The Beacon API block-response schema, for example, distinguishes execution-optimistic and finalised information instead of treating a returned block as one universal assurance.
Are two clients automatically two independent trust domains?
No. One operator, host or administrative account may control both. Logical separation helps explain responsibilities; independence requires separate evidence about control and shared dependencies.
Is this a current node installation guide?
No. It is an architecture and evidence-reading lesson. Software versions, activated upgrades and deployment arrangements must be checked for a real system. No commands, credentials or setup instructions are needed to complete the worksheet.
Back to contents · Next section
Sources and next reading
Primary sources checked on 12 October 2026, Singapore time:
- Ethereum node architecture, page last updated 25 March 2026: the execution, consensus and validator role map. Used for that division of responsibility, not current staking terms.
- Ethereum nodes and clients: cooperating client roles and the distinction between implementations and a node’s responsibilities.
- Engine API, Paris specification: version-labelled examples of payload statuses and execution-hash fork-choice fields. The main branch can change; this is not a complete specification of every activated upgrade.
- Beacon API syncing-status schema: separate syncing, optimistic-tracking and EL-offline observations.
- Beacon API block-response schema: separate execution-optimistic and finalised fields. The repository’s moving schema includes version entries; their presence is not evidence that an upgrade is deployed on a particular network.
For revision, return to the earlier lessons on deterministic execution, fork choice and recipient finality if those individual checks are unfamiliar. This lesson joins their responsibilities at the client boundary. The next architecture exercise examines when declared account access allows transactions to run without conflicting over shared state.