节点与客户端：先明确软件职责
节点是运行区块链客户端并连接网络的实例，客户端则按照协议规则处理和验证数据。理解节点方案，可以先拆成三个问题：如何取得数据、如何判断数据有效、需要保留哪些数据。不同区块链对这些职责的组织方式并不相同。
以太坊节点采用执行客户端与共识客户端协作的结构：前者执行交易、维护状态，后者处理权益证明共识；验证者软件承担额外的共识参与职责。全节点、归档节点和轻节点在数据保留及验证方式上存在差异，多种客户端实现则有助于降低对单一代码库的依赖。
P2P网络：发现节点与交换数据
比特币开发文档介绍了通过DNS种子、已保存的节点地址及节点间地址交换来发现连接对象的机制。节点建立连接后交换区块和交易；初始同步涉及下载与验证区块。其归档节点保留完整区块链，裁剪节点则可在验证后删除部分历史区块。
节点发现解决的是连接对象从哪里来，协议验证解决的是接收到的数据能否接受，两者承担不同职责。连接成功并不代表数据可信，网络连通性也不能替代本地验证。
同步与存储：区分追赶进度和保留范围
同步关注节点如何追上链的进度，存储策略关注追上之后保留什么。讨论方案时，应分别明确验证起点、数据下载方式与历史数据保留范围，不能只用同步快慢衡量能力。
历史区块和历史状态也需要区分：前者记录区块内容，后者描述某一时点的账户等状态。同样称为归档节点，在不同链上的含义可能不同，因此不能直接套用术语判断查询能力。
适用条件：围绕数据需求界定能力
需要本地验证数据时，应关注全节点的验证能力；需要频繁查询过去的账户状态时，应关注历史状态保存能力；资源受限时，可考虑轻客户端的验证方式及数据依赖。具体支持范围取决于链协议和客户端实现。
钱包、浏览器等应用还需要访问节点数据。以太坊资料中的RPC和IPC属于应用接入方式，与节点之间传播区块的P2P通信承担不同职责。方案说明应把这两类连接分开描述。
常见问题：运行节点是否等于参与出块
运行节点不自动等于成为验证者，也不自动获得出块职责。验证收到的数据与参与区块生产，应按具体协议分别理解。
全节点是否必须永久保存所有历史数据？不一定。完整验证能力与历史数据保留范围是两个维度。评估方案时，需要同时确认它能验证什么、能查询什么，以及查询所需数据是否仍在本地。