一、先区分交易验证与记账共识
交易验证回答“这笔交易是否符合规则”，记账共识回答“网络接受哪一段交易历史”。两者相互配合，但不能替代：交易满足授权条件，不意味着已经写入区块；区块被提出，也不意味着其他节点会直接接受其中的交易。
二、交易结构与UTXO
Bitcoin Developer Guides 的交易说明以比特币普通交易为例：输入引用已有输出，输出规定金额与后续花费条件；尚未被花费的输出称为UTXO。交易标识txid与输出索引共同定位被引用的输出。
这一结构让验证对象更明确：节点不只是查看一个显示余额，还要检查被引用的输出是否可用、花费条件是否满足。这里的UTXO解释适用于比特币这类模型，不能直接视为所有区块链共同采用的账户结构。
三、哈希、数字签名与脚本
哈希用于生成数据摘要，数字签名用于验证授权，两者作用不同。在比特币传统P2PKH示例中，节点核对公钥哈希，并用公钥验证ECDSA签名；脚本把这些校验组织成花费条件。
签名不是把交易内容加密，也不证明现实世界中的身份。它使节点能够检查相应密钥是否对指定交易数据作出授权。对签名覆盖的数据进行修改，会影响验证结果，因此不能把“有签名”简单理解为任何字段都受到同等保护。
四、共识、抗女巫攻击与分叉选择
以太坊开发者文档将共识机制解释为协议、激励和规则的组合。工作量证明与权益证明涉及抗女巫攻击及区块作者选择，但单靠它们不足以描述完整共识，还需要分叉选择等规则。
抗女巫攻击针对的是通过大量虚假身份影响网络的问题；分叉选择处理的是节点看到竞争区块时如何选择链头的问题。二者分别约束参与影响力与历史选择，不能混为一谈。
五、常见问题与适用边界
为什么不能只检查签名？因为授权正确不代表引用的资产仍然可花费。防止同一资产重复花费，还需要结合账本状态检查，并通过共识协调交易历史。
为什么广播不等于完成记账？广播只是传播交易，验证、区块收录与链的选择是不同环节。理解这些概念时，应把交易层的合法性检查与网络层的历史一致性分开，再依据具体区块链的规则判断。