节点与客户端：运行实例和协议实现
节点是参与区块链网络的软件运行实例，客户端则是实现协议规则的软件。理解二者时，可以分别关注“谁在网络中运行”和“它依据什么规则工作”。不同客户端可以采用不同编程语言，但要遵循共同的协议规范。
以太坊的完整节点架构包含执行客户端与共识客户端：前者负责交易执行和状态维护，后者处理权益证明共识。验证者软件承担额外的共识参与职责，因此运行节点并不自动意味着成为验证者。
点对点网络：发现、连接与传播
点对点网络让节点交换交易和区块。比特币开发文档介绍了通过DNS种子、已知节点记录和节点间地址交换来发现连接对象的机制。发现节点解决的是“向谁获取数据”，协议验证解决的是“收到的数据是否有效”，两者承担不同任务。
网络连通也不等于账本已经同步。新加入或长期离线的节点，还需要取得缺失数据并按规则检查，才能跟上链的进展。
执行、状态与共识分别处理什么
交易执行决定一次操作如何改变账本状态。以太坊执行客户端使用以太坊虚拟机处理交易，维护账户和合约等状态。共识则让网络在有效数据的基础上确定链的进展。执行规则与共识规则相互配合，不能仅凭收到一个区块就认定它已经被网络接受。
全节点、归档节点与轻客户端
全节点强调独立验证能力；归档存储强调历史数据的保留；轻客户端则减少本地下载和存储，通过区块头及相关证明检查所需数据。轻客户端的安全条件取决于具体协议和实现，不能一概视为与全节点完全相同。
术语还需结合链的语境理解：比特币文档中的归档节点保存完整区块历史，裁剪节点验证后可以删除部分旧区块；以太坊归档节点的重要用途是查询历史状态。历史区块与历史状态不是同一种数据。
适用条件与常见问题
需要独立检查链上数据时，重点在验证能力；需要频繁查询过去某个时点的账户状态时，重点在历史状态保存；资源受限的访问场景，则需要评估轻客户端的验证方式和数据可用性。
全节点必须永久保存全部数据吗？不一定，验证范围与保存范围需要分开理解。节点数量能否直接代表去中心化程度？数量只是一个维度，客户端实现是否多样、连接和服务是否过度集中也会影响网络韧性；网络探测工具看到的节点还可能只是局部样本。