What is a blockchain node? For Ethereum, a node is a running instance of Ethereum client software connected to other computers running Ethereum software. The client is the implementation that checks data against Ethereum’s protocol rules. These terms describe different aspects of the same arrangement: the software doing the work and its connected instance in the network.
Understanding that relationship makes several other distinctions easier to follow. Execution and consensus describe client responsibilities. Full and archive describe verification and data-retention roles. Validator participation is a separate question. Remote RPC introduces another distinction: whose node or service supplies the information you receive?
How a node relates to its clients
The Ethereum node architecture described here pairs two clients: an execution client and a consensus client. Calling both of them clients does not make their responsibilities interchangeable. Each has a different part in the paired architecture.
A useful way to read the terminology is to ask two questions. Which software component is being discussed? And is the discussion about its running, connected instance? The first question identifies the client; the second identifies the node relationship. This avoids treating a software implementation and its operation in the network as identical concepts.
This explanation follows Ethereum’s nodes and clients documentation. Its terminology is used here specifically for Ethereum. The paired architecture should not be assumed to describe every blockchain, and the light-client discussion below is a conceptual explanation rather than a claim about available software.
Execution, consensus, and validator participation
The execution client executes transactions in the Ethereum Virtual Machine, or EVM. Execution describes processing the transaction; it does not imply that every transaction executes successfully. The execution client also holds the latest Ethereum state and a database of current Ethereum data. Keeping current state should not be confused with keeping every historical state.
The consensus client’s proof-of-stake consensus role enables the network to reach agreement based on data validated by the execution client. The relationship matters: execution supplies validated data, while the consensus component handles the agreement role described by the source. Describing a node only through one of these responsibilities leaves out the other component of the paired architecture.
Validator software is an optional addition to the consensus client. Running a node therefore does not itself mean running a validator. When a description says someone operates an Ethereum node, do not infer validator participation from that statement alone. This article stops at that architectural distinction; it does not describe how to participate as a validator.
Full nodes and archive nodes answer different questions
A full node validates the blockchain block by block, including block bodies and state data. However, the verification starting point depends on the synchronization approach. Some full nodes begin from a more recent block they trust to be valid. The phrase full node therefore should not be read as a universal claim that verification began at Ethereum’s first block.
Retention is another question. A full node can prune data instead of retaining every historical state back to genesis. No fixed retention window is assumed here. The essential distinction is that validating data and keeping all historical state are separate responsibilities.
An archive node retains an archive of historical states in addition to full-node data. That explains why archive appears in discussions about historical state: retention of those states is its distinguishing role. This description does not promise a particular query interface, response speed, or storage requirement.
When comparing descriptions, keep the questions separate: What does this node verify? Where does that verification begin? Which historical states does it retain? A single label can be too broad to answer all three without additional context.
Light clients: obtaining data and checking data
In the light-client concept described by the source, a light node downloads block headers instead of every complete block. It requests other required information from a full node. The source then describes checking received data against state roots in the block headers.
This introduces a useful distinction between obtaining information and verifying it. A full node supplies additional information in this model, while the light client has the stated mechanism for checking received data. Dependence on another node to supply information does not erase that checking step. Equally, describing the checking step does not guarantee that another node will serve every request.
The limits matter. This is a conceptual verification tradeoff, not a list of working light-client products. The explanation does not establish that light clients have identical overall guarantees to full verification. It also does not explain how the block headers themselves are authenticated. Those limits prevent a narrow description of one verification mechanism from becoming a broader security promise.
Own-node verification versus remote RPC
Running your own node enables local verification of transactions and blocks against consensus rules. That is a specific verification benefit, rather than an absolute trustlessness guarantee. The earlier starting-point caveat still applies: some synchronization approaches begin at a recent block trusted to be valid.
A third-party API provider offers an alternative to running your own node instance. To make the distinction concrete, Ethereum’s JSON-RPC documentation defines eth_getTransactionCount as returning the number of transactions sent from an address. Its request includes an address and a block number or tag, so the requested state context matters when describing the answer.
The following is a deduction from those facts: when a remote RPC provider supplies a response, you rely on an external node or service for that response. Making the request does not itself establish that you performed local verification. The premises are the source’s distinction between own-node verification and external API access, together with the documented RPC response. This deduction does not mean remote answers are necessarily wrong, and it does not rule out separate verification.
A hypothetical comparison
Imagine that Nora is writing a classroom explanation of an address’s transaction count. In one version, she asks a remote provider using eth_getTransactionCount with the address and a chosen block number. She should describe the result as the provider’s response for that requested context.
In a second version, Nora uses her own node, with local verification subject to its synchronization starting point. The question being asked can remain the same while the source of the answer changes. This hypothetical illustrates the reliance distinction; it makes no claim that either particular answer has been independently reviewed.
For a separate explanation focused on transaction records, see how to read an Ethereum transaction in a block explorer.
A checklist for reading node descriptions
- Identify the component: Is the description about execution, consensus, or optional validator software?
- Check the verification starting point: Does the explanation establish where verification begins?
- Separate verification from retention: Does full mean validation, or is historical-state archiving also specified?
- Keep light-client claims narrow: Distinguish requested data, the stated checking mechanism, and any unexplained assumptions.
- Identify the response source: Is information coming from your own node or an external RPC service?
- Preserve request context: For the transaction-count example, identify the address and requested block number or tag.
Use these questions to assess what a description actually establishes. A node label or a documentation link alone should not be treated as a safety guarantee.
This educational article was prepared with AI assistance. It explains concepts rather than providing installation, staking, or financial advice.