区块链与节点分别承担什么作用
区块链组织交易记录，节点运行协议软件并核验、传播相关数据，客户端则是这些协议规则的软件实现。理解三者时，可以依次关注记录的结构、执行核验的网络参与者，以及核验所依据的程序。点对点网络使节点能够彼此交换信息，但收到数据并不意味着认可数据，节点还需要检查其是否符合规则。
比特币：哈希、默克尔树与工作量证明
比特币区块通过前一区块头的哈希相连，交易哈希汇总成默克尔根。节点检查交易是否使用尚未花费的输出，并核验区块规则与工作量证明；出现有效分支时，依据累计工作量选择链。
这里涉及三个不同问题：哈希关联帮助发现记录变化，默克尔证明用于核对交易是否被某个区块包含，共识规则决定哪些记录可以接受。证明一笔交易被包含，并不等于完成该区块全部交易的有效性检查。区块高度表示位置，分叉时同一高度可能出现不同区块，因此不能作为全局唯一标识。
以太坊：执行、共识与状态
以太坊节点由执行客户端和共识客户端协同工作：前者在以太坊虚拟机中执行交易并维护状态，后者处理权益证明共识。参与验证者职责还需要相应的验证者软件。全节点、归档节点与轻节点在数据保留和核验方式上有所区别。
交易记录描述发生了哪些操作，状态描述执行这些操作后的结果。查询某个历史时点的账户情况，与核验新交易对当前状态的影响，属于不同的数据需求。执行和共识分工，也意味着交易计算结果与网络认可哪条链需要配合处理。
不同节点类型适用于哪些需求
需要独立核验区块时，应理解全节点的验证职责；需要频繁查询历史状态时，应关注归档能力。全节点并不必然永久保留每个历史时点的完整状态，具体保留范围与客户端配置有关。
轻节点通过区块头及相关证明减少数据负担，适合资源受限的访问场景。其安全条件取决于具体协议、可信起点和证明验证方式，不能笼统认定与全节点完全相同。同步方式则关系到节点如何建立可用的本地数据，应与历史数据保留策略分别理解。
常见问题：运行节点是否等于参与出块
运行节点不自动等于挖矿或承担验证者职责。验证收到的区块，与提出新区块，是不同角色承担的工作。节点数量也不能单独代表去中心化程度，还需关注运营主体及客户端实现是否多样。上述例子分别适用于比特币和以太坊，不能把某一网络的客户端结构或共识方式直接套用到所有区块链。