Full Node vs Validator Node: What Actually Differs

By Nika, NodeTimes newsroom.

A full node verifies blocks and transactions itself and keeps the state of the chain; a validator does everything a full node does and additionally proposes its own blocks and attests to blocks proposed by others. The second duty is what puts the validator's own money at stake, because a validator's weight in consensus is its deposit. The roles are confused so often because one machine can carry both: a validator almost always runs a full node underneath, and the difference sits in the responsibility taken on rather than in the software installed.

Two jobs people confuse: serving and validating

Serving a chain and validating a chain are two different obligations: a node answers questions about a chain it has verified, while a validator produces blocks and votes on the ones it did not produce.

Node: a process that keeps a copy of the chain, checks every block and transaction against the protocol rules, and can answer questions about the result. State: the current set of balances, code and storage that the protocol needs to process the next block, as distinct from the history of blocks that produced it. Client: the software that implements the protocol, which in modern proof-of-stake networks is split in two. The consensus client (also called the beacon node): follows the chain of attestations and decides what is final. The execution client: executes transactions and maintains the state; the two talk to each other over a local channel rather than over the network.

A node that only serves is a reader. It matters because someone has to hold and check the chain without permission and without being paid for it, which is the whole argument for why a blockchain needs nodes at all.

• Serving: verify, keep state, answer queries, relay transactions. No deposit, no voting duty, no reward.
• Validating: propose blocks, attest to the blocks of others, stay online when called. Deposit required: 32 ETH to enter, and up to 2,048 ETH of effective balance since EIP-7251, where the effective balance is the portion of the stake that counts toward consensus weight. Duties enforced, penalties possible.
• Both: run the same consensus and execution software, which is exactly why the distinction is easy to lose.

Full node, archive node, light client

The three differ in what they verify and what they keep: a full node verifies everything itself, an archive node adds historical state to that, and a light client verifies block headers while asking a provider for everything else, and what each of them ends up storing is set out in the explainer on RPC.

Pruning is where most of the confusion lives. A full node keeps every block and every transaction, but it does not have to keep every past state: state is pruned behind a retention window, while the block history stays. An archive node keeps the historical states as well, which is what makes it large and what makes it the only node class that can answer a query about a balance at an arbitrary past block.

Sync mode is a separate choice from node class: a node can rebuild state by executing every block from genesis, or start from a snapshot that a peer provides and verify forward from there. The first is slower and fully self-checked; the second is faster and trusts the snapshot it began from, which is a different trade from the one a light client makes.

What a validator actually does

A validator has two duties in every epoch: propose a block when it is selected, and attest to the block it believes is canonical; its influence on the outcome is proportional to its deposit.

The validator client is a third process. It holds the signing keys and performs the duties, while the beacon node it connects to keeps the chain and the execution client keeps the state. That split exists so keys live in the smallest possible process, and it is also why a validator cannot be run as a client on someone else's infrastructure without giving that someone the ability to sign: in a plain setup the key lives where the duty is performed, and a separate signer that the validator can only ask moves that trust problem instead of removing it. How the votes of many validators turn into a finalised block is the subject of its own explainer on consensus.

• Proposal: one validator per slot is selected to build and sign the block, with the selection weighted by deposit.
• Attestation: every validator votes on the head of the chain and on the checkpoints it considers justified.
• Sync committee: a rotating subset signs the headers that light clients follow, so those clients do not have to trust a provider for the chain itself.

Slashing and staking: where the risk comes from

The risk of running a validator comes from its own behaviour rather than from an attacker: misbehaviour that could be part of an attack on the chain is slashable, and an isolated incident is punished much more lightly than a mass one.

The initial penalty is a fraction of the effective balance rather than a fixed amount: since EIP-7251 it is one part in 4096, which is about 0.008 ETH for a validator staked at the 32 ETH minimum and about 0.5 ETH at the 2,048 ETH maximum. The validator is then queued for exit over roughly a 36-day period, and at the midpoint of that period a correlation penalty is applied whose size scales with the total stake slashed around the same time; if a large share of validators is slashed together, that penalty can reach the entire stake.

Three offences are slashable, and none of them happens by accident:

1. Proposing two different blocks for the same slot.
2. Attesting to two different blocks for the same slot.
3. Contradicting an earlier checkpoint vote.

Being offline is a different category. A validator that simply stops answering loses the rewards it would have earned and bleeds slowly, and the severe version of that penalty arrives only when the chain itself cannot finalise and the inactivity leak is active. That asymmetry is deliberate: an absence is a cost, a conflicting signature is an attack. The difference between the two families of consensus is set out in proof of work versus proof of stake.

What running one costs

A validator's cost is not only the machine: bandwidth, synchronisation time, downtime tolerance and the discipline of upgrades are the parts that decide whether the role is sustainable.

Storage is the first bill, and its size depends on the network, the client and how much history you choose to keep: an archive configuration costs multiples of a pruned one, and a snapshot sync needs less time but more free space at the peak. Bandwidth is the second, because a node talks to peers continuously and a validator has to be reachable to do its duty. Time is the third and the one that is usually underestimated: a full sync from genesis is a multi-day operation on a fast link, and every missed duty during it is a missed reward.

• Disk: state plus history, prunable for a full node and by definition not prunable for an archive node.
• Network: sustained peer traffic and, in a validator, the latency at which a duty can still be performed.
• Time: initial sync, client upgrades, and the operator's own attention to a key that must not be copied to a second machine.

Two operational rules follow from the cost structure. The first is never to run the same validator key in two places, because duplicated signing is precisely the double-vote case that slashing exists to punish. The second is to treat an upgrade as a scheduled risk, not as background maintenance, since the client pair has to stay in step with the network.

Why validators rarely expose a public API

An operator usually keeps the query interface away from the validator, because a public endpoint puts unknown traffic on the same process that holds the signing keys and answers for the deposit.

The two functions have opposite load profiles. A validator serves a handful of duties per epoch and needs predictable latency; a query interface absorbs whatever the internet sends, including expensive requests and scans for exposed keys or debug methods. Running them on one machine is what turns a traffic spike into a missed attestation, and in the worst case into an incident around the key.

The cleaner arrangement is to separate the roles and let the validator be the only process with duties: a separate node, or a provider's endpoint, serves the queries. Where the boundary between node, endpoint and provider actually sits is covered in the explainer on RPC, including why an endpoint is not a node. The separation also makes the failure modes separate: a query node can be restarted at will, while the validator's process should only be restarted when nobody else could be signing with the same key.

Frequently asked questions

Can a validator run without a full node?

No. To propose and attest to blocks a validator has to verify the chain state itself, which means a consensus client and an execution client underneath it.

A provider's endpoint can relay queries, but it cannot perform the validator's duties on its own.

Does a full node earn anything?

No. A full node is not paid by the protocol for verifying blocks and keeping state, so its return is independence rather than income.

Operators run one for their own guarantees: no third party decides what they can see or which chain they follow.

Is a light client unsafe?

It is stronger in one respect and weaker in another: it verifies the headers it receives locally, but it depends on a provider for the state those headers point at.

For a wallet reading a balance that trade is usually acceptable; for anything that moves value on its own it is not.

What causes slashing?

Behaviour that could be part of an attack on the chain: proposing two blocks for one slot, attesting to two, or contradicting an earlier checkpoint vote.

Long absence is penalised differently and usually far more gently, through lost rewards rather than a destroyed stake.

Why not expose the validator's API publicly?

Because public traffic would reach the process that signs blocks and answers for the deposit, where the cost of a failure is not measured in convenience.

Keeping queries on a separate node keeps the signing process reachable only by its operator.