误区一：所有区块链都需要挖矿
比特币开发者指南中的挖矿属于工作量证明：通过寻找符合目标阈值的区块头哈希参与出块。以太坊官方共识文档则介绍权益证明，由验证者承担区块提议与验证职责。两者不能套用同一套“矿机竞争算力”的解释。
讨论开发需求时，应先明确目标网络及其共识机制。“区块链开发”是更宽泛的概念，不能直接等同于挖矿软件开发。
误区二：算出合格哈希就能绕过其他规则
工作量证明并不替代区块有效性检查。哈希达到目标要求，只解决出块条件中的一部分；区块和交易仍须满足网络规则。开发中应分别理解计算工作、区块构造与节点验证，不能把它们视为同一个步骤。
误区三：矿池接受份额就是网络确认区块
矿池份额用于衡量矿工提交的工作，其目标通常比网络出块目标宽松。被矿池接受的份额不一定构成有效新区块，只有同时达到网络要求的结果才可能用于出块。
因此，份额提交量、矿池接受量与网络出块数量属于不同指标。展示运行状态时，应清楚标注统计对象，避免把工作量凭据写成链上确认。
误区四：加入矿池就消除了不确定性
比特币开发者指南区分独立挖矿和矿池挖矿：前者回报间隔的波动通常更大，后者通过共享工作和分配回报降低个体波动。不同矿池的分配制度也可能不同。降低波动不等于保证结果，更不能据此作收益承诺。
误区五：历史接口说明可以直接当成现行规范
比特币参考正文涉及已经弃用的 getwork，以及 getblocktemplate 和 Stratum 等机制。它们提供的信息和交互方式存在差异，不能仅凭“都服务于挖矿”就认为可以直接替换。
理解历史设计有助于认识系统分工，但工程兼容性仍需对应具体客户端与协议版本；历史文档中的普及程度描述，也不宜写成实时行业结论。
常见问题：权益证明是否意味着无需运维
不是。以太坊的权益证明仍要求验证者运行相关客户端、保持连接并履行验证职责，缺席或违反协议可能带来不同类型的处罚。它改变的是共识参与方式，而不是取消软件运行和维护要求。
上述区分适用于理解工作量证明挖矿与权益证明验证的基本边界，不应直接推广为所有区块链项目的实现细节。