节点、客户端与验证者
以太坊开发者文档将节点理解为连接网络的客户端软件实例。执行客户端负责执行交易、维护状态；共识客户端负责共识协作。验证者软件承担额外的共识职责，运行节点不等于运行验证者。
管理中应分别记录节点实例、客户端类型和承担的职责。排查问题时，需要明确异常发生在交易执行、共识协作还是验证者职责环节。这套双客户端分工适用于以太坊，不能直接套用于所有区块链。
全节点、归档节点与轻节点
以太坊文档区分了全节点、归档节点和轻节点：全节点验证数据，归档节点侧重保存历史状态，轻节点借助区块头及相关证明校验所需数据。不同类型的数据保存量与资源需求不同。
理解这些名称时，应把验证能力与历史查询能力分开。需要查询过去某个区块对应的账户状态时，要确认历史状态是否保留、能否恢复，以及查询接口是否支持。全节点的“全”不代表所有历史状态都永久可直接查询。
区块高度、哈希与共识规则
比特币开发者指南说明，区块通过前一区块头的哈希相连；共识规则决定节点接受哪些区块。高度表示区块所处的位置，但分叉时同一高度可能出现多个区块，因此高度不能作为全局唯一标识。
运营记录中，高度适合描述处理进度，区块哈希适合定位具体对象。两个节点高度相同，并不足以证明它们记录的是同一个区块；核对一致性还需要比较相应哈希。
UTXO与默克尔证明
在比特币中，UTXO指未花费交易输出，普通交易以此前未花费的输出作为输入。默克尔树把交易摘要汇总到区块头中的默克尔根，使交易包含关系可以通过证明进行核验。
两者回答的问题不同：UTXO涉及输出能否被使用，默克尔证明涉及某笔交易是否被某个区块收录。包含证明本身不能替代完整的交易有效性检查，也不能单独说明该区块所在分支是否被网络接受。
常见问题：如何读懂运营指标
节点在线是否代表数据已更新？在线仅说明连接或服务可达，还应核对同步状态与链头。能够查询交易是否代表具备归档能力？交易记录与历史状态属于不同查询需求，应分别确认。
网络节点统计是否就是实际总量？去中心化网络的探测存在可见性限制，不同统计工具可能得到不同结果。理解运营指标时，应同时明确测量对象、统计范围和适用网络，避免用单一数字概括整体运行情况。