区块链、节点与客户端
区块链组织交易记录，节点运行软件并按照协议检查这些记录。客户端是协议的软件实现，节点则是客户端运行并连接网络的实例。理解三者，可以分别关注数据如何组织、规则如何实现，以及由谁执行验证。
比特币开发文档介绍了哈希链接、交易验证及工作量证明；以太坊节点文档说明了执行客户端、共识客户端和节点类型。两种网络可用于解释基础概念，但具体机制不能直接互换。
哈希与默克尔树解决什么问题
在比特币中，区块通过前一区块头的哈希相连，交易的哈希则汇总成默克尔根并写入区块头。修改交易会改变相关哈希，使原有链接无法保持一致。
默克尔证明可以用一组中间哈希检查交易是否被某个区块收录。这里需要区分“收录证明”和“完整有效性验证”：证明数据属于一个区块，并不自动证明交易满足所有规则，也不自动证明该区块属于被网络接受的链。
交易状态与共识规则
比特币用未花费交易输出，即UTXO，描述可以被后续交易花费的输出。节点检查输入是否可用，以识别重复花费。以太坊执行客户端则执行交易，并维护账户和合约等状态；EVM是其执行交易所用的虚拟机环境。
共识还要处理有效区块之间的选择。比特币依据累计工作量选择有效链；以太坊共识客户端实现权益证明机制，并与执行客户端协作。验证是否合规与确定链的进展，是相互配合的不同任务。
节点类型的适用条件
全节点适合需要自行验证区块和状态的场景，但全节点不等于永久保存全部历史状态。归档节点侧重保留历史状态，适用于历史余额查询、区块浏览器和链上分析等需求，存储负担通常更大。
轻节点通过区块头和相关证明减少数据处理需求，适合资源受限的环境。其验证范围和安全条件取决于具体协议与实现，不能笼统认为与全节点完全相同。同步方式也会影响初始验证起点和本地保存的数据。
常见问题：节点是否都参与出块
运行节点不自动意味着成为矿工或验证者。以太坊节点的执行客户端与共识客户端负责协同验证、跟踪链；参与验证者职责还需要相应组件及协议条件。普通全节点也能通过验证和提供数据支持网络。
客户端多样性可以减少对单一代码库的依赖，但节点数量本身不足以证明去中心化程度。理解网络韧性，还需要区分软件实现是否多样，以及节点是否由独立参与者运行。