误区一：一个客户端负责所有工作
Ethereum.org 的节点文档说明，以太坊节点由执行客户端与共识客户端协作运行：前者执行交易、维护状态，后者负责权益证明共识；验证者软件则承担额外的验证者职责。全节点与归档节点的区别涉及历史状态保存，多种客户端实现共同遵循协议规范。
因此，理解架构时应分别追问：交易如何改变状态，网络如何就链达成一致，谁承担验证者职责。把这些问题混在一起，容易误以为运行节点就自动成为验证者，或执行交易的软件可以独自完成共识工作。
误区二：全节点必须保存全部历史状态
“验证数据是否有效”和“随时查询任意历史状态”是两类需求。普通应用读取较新的状态，与分析服务频繁查询过去某个区块的账户状态，对存储能力的要求不同。
归档能力主要影响历史查询的便利性。评估节点是否适用，应明确需要查询哪些时期的数据，并核对客户端的保存与同步配置，不能仅凭“全节点”名称推断全部历史状态都能直接读取。
误区三：不同客户端意味着不同协议
客户端可以由不同团队、使用不同语言实现，同时遵守相同协议规则。软件实现的多样性与规则的一致性可以共存。讨论兼容性时，应区分实现方式不同与验证规则不一致；讨论可靠性时，则需考虑对单一代码实现的依赖。
误区四：去中心化网络上的合约没有管理员
OpenZeppelin 的访问控制文档区分了单一所有者管理与基于角色的授权。角色的使用权限和授予、撤销权限分别受规则约束；默认管理员权限范围较广。放弃所有权会使 onlyOwner 保护的操作无法继续调用。
网络验证交易遵守规则，并不意味着合约内不存在管理权。例如，某个操作即使严格按合约执行，也可能只有指定账户能够调用。判断应用的权限结构，需要查看受限功能及其授权关系，不能只看它是否部署在以太坊上。
常见问题：角色越多就越安全吗
角色拆分适用于职责不同的场景，但角色数量不能直接代表安全程度。如果同一账户同时掌握多个角色及其管理权，权限仍可能集中。分析时应同时考虑谁能执行操作、谁能改变授权，以及权限移交后功能是否仍然可用。
这些区别适用于理解节点部署、数据查询和合约权限设计；它们不能直接证明某个具体应用已经实现去中心化或具备充分安全性，具体判断仍需对应的实现与配置证据。