Blockchain node infrastructure
Every application that reads a blockchain reads it through a node, and whoever runs that node decides what the application can see. For a regulated firm that makes node infrastructure a supervisory question and not only a technical one: the answer to "where does this balance come from" has to name a party.
What follows is what the different node types store, where a node operator ends and a validator begins, what it takes to run one, and the concentration risks a bank inherits when it buys the service instead.
Full node, archive node, light client
A full node holds the current state of the chain and enough recent history to verify it, validates every incoming block and transaction against the consensus rules, and rejects what does not comply, which is the property that separates a full node from a client trusting someone else's copy. On Ethereum that is roughly 500 gigabytes of storage and growing, because the node prunes older state it no longer needs for verification.
An archive node does everything a full node does and keeps the complete historical state from the genesis block, so any balance or contract state at any past block can be queried. That is the expensive one: an Ethereum archive node runs from about two terabytes with a storage-efficient client such as Erigon up to twelve terabytes and more with Geth. A light client downloads block headers only and asks fuller nodes for anything else, which is what a mobile wallet runs, and it trusts the node it asks. An RPC node is a full or archive node that exposes a JSON-RPC interface for applications to query, which is the shape most firms actually consume, covered on the RPC providers page.
Consensus client and execution client on Ethereum
Since the Merge, an Ethereum node is two programs that talk to each other. The execution client holds the state, executes transactions and serves the JSON-RPC interface, with Geth, Nethermind, Besu and Erigon as the implementations in use. The consensus client follows the proof-of-stake chain, handles attestations and block proposals, with Prysm, Lighthouse, Teku, Nimbus and Lodestar on that side.
Running a node therefore means running, updating and monitoring two pieces of software with separate release cycles, and a mismatch between them takes the node offline. This split is the single most common reason a self-hosted node falls behind the chain, and falling behind is worse than being down: a node that serves stale data without saying so gives an application an answer that looks valid and is not.
A node operator against a validator
The two words get used interchangeably and they are not the same thing. A node operator runs node infrastructure: the machines, the clients, the monitoring, the upgrades. A validator participates in consensus, which on a proof-of-stake network means staking the network's token as collateral, proposing blocks and attesting to the blocks of others, and being penalized for failing to do so.
Running an Ethereum node does not make the operator a validator. Becoming one needs validator software, a stake and a set of keys, and it brings an economic exposure the plain node operator does not have. The same firm often does both, which is where the confusion comes from, and the distinction matters because the risks are unrelated: an operator's risk is availability, a validator's risk includes losing capital. The validator economics page covers the revenue and the penalties; crypto staking covers how proof of stake works.
Why a bank or an asset manager runs or buys a node
Because a public endpoint is someone else's infrastructure answering a question the firm is accountable for. The reasons split into four and each one stands on its own. Correctness: a firm that verifies blocks itself does not have to believe a third party's answer about a holding it reports. Privacy: every query to a hosted endpoint tells the operator which addresses the firm cares about, which for an asset manager is position information. Availability: a public endpoint can rate-limit, change or disappear, and it owes the firm nothing. And supervision: a dependency on an external provider for a function that matters is an ICT third-party arrangement, with the documentation that follows, which the DORA regulation in Germany page covers.
Against that sits operational reality. A node needs the initial sync, which takes days, storage that grows every month, client upgrades on the network's schedule and monitoring that notices a node drifting behind. Most firms run their own node for the queries that matter and buy a provider for breadth, which is a defensible answer as long as both paths are documented.
Client diversity as a concentration risk
If one execution or consensus client implementation runs most of a network and that client has a bug, the bug becomes the network's behavior, and nodes running the minority client are the ones that correctly reject what the majority accepts. On a proof-of-stake network a supermajority client bug can also lead to the wrong chain being finalized, which is a settlement risk and not a theoretical one.
For a firm this reads as a diversification instruction with a cost. Running a minority client is better for the network and means running software with a smaller user base, fewer worked examples and a different failure profile. A firm that runs more than one node should at least not run the same client pair on all of them, which is the cheap version of the same insight, and the same logic a bank already applies to its vendors elsewhere.
Who supplies node infrastructure in Europe
Firms that will not operate nodes themselves buy them, and the suppliers divide by what they actually sell. Blockdaemon runs node and staking infrastructure for institutional clients across many networks. Tangany is a German custody provider whose service includes the chain access behind the custody, which is a different purchase: the node comes with the regulated custody and not on its own.
The question to ask a supplier is narrow and the marketing rarely answers it: whether the node is dedicated or shared, whether it is an archive node, which client implementations it runs, where it is hosted, and what happens when it falls behind. A supplier that cannot answer the last one in writing is selling an endpoint and not infrastructure.
Do you need to run your own node to use a blockchain?
No, and most applications do not have one. A wallet, an application or a reporting process can read the chain through a hosted provider, and the great majority do. The reason to run one is not functionality but who answers for the answer: a firm that has to state a holding, a valuation or a transaction to a supervisor or an auditor is in a different position from an application that displays a balance to a user.
What does a node actually cost to run?
The hardware is the small part. A full node needs a fast NVMe disk of a terabyte or more, enough memory, a connection with real upstream bandwidth, and an archive node needs multiples of that storage with a monthly growth rate. The larger cost is a person: someone who tracks the client releases, applies them on the network's schedule, watches the node's distance from the chain head and is reachable when it stops. That is the figure a firm underestimates, and it is the reason the hosted market exists.
Node infrastructure and Finance Loop
Finance Loop is the meeting place for the people who run and buy this infrastructure in Europe: the node operators, the custody providers that depend on them and the banks that have to document the dependency. Finance Loop keeps node infrastructure in its Digital Infrastructure & Sovereignty track, next to the cloud and resilience questions it shares.
Finance Loop is a professional network and has the goal of driving the adoption of emerging technologies in finance, such as AI, tokenization, stablecoins, and DeFi. Finance Loop helps its members build skills and personal networks in these fields: Investment & Digital Assets, Payments & Digital Money, Digital Infrastructure & Sovereignty, and Risk & Compliance.