A blockchain node runs software that communicates with other participants and maintains a view of the network according to that software's role. A client is an implementation of this software; a node is a running instance. Nodes may receive transactions, exchange blocks, validate rules, and expose an API to applications. These responsibilities should not be confused with block production: running a node does not automatically make its operator a miner or validator, or entitle it to protocol rewards.

When a wallet asks for an account balance, the answer often comes through a remote procedure call endpoint. That endpoint may be backed by the user's own node or by a third-party service operating many nodes. In a current Ethereum node architecture, execution and consensus clients perform different parts of the work and communicate through a defined interface. An application can therefore depend on several components even when its settings show only a single RPC URL.

A node's capabilities depend on its configuration, synchronization mode, retained data, and peer connectivity. An endpoint that answers quickly is not proof that it independently verified the requested state. A node isolated from honest peers may also have an incomplete view of current activity. For research or development, specify whether evidence came from a validating local node, a light client, or an external API. That distinction explains which checks were performed locally and which claims were accepted from another operator.