适用范围：技术机制能够说明什么
判断区块链项目有哪些常见问题，可以先从技术说明是否完整入手。以下讨论适用于理解采用类似共识和交易验证机制的区块链，不能据此认定某个项目已经安全运行，也不能单凭底层机制判断其业务是否可靠。
只看共识名称，忽略完整规则
以太坊开发者文档将共识机制解释为协议、激励及相关规则的整体，其中包括出块安排、分叉选择和奖惩机制。工作量证明或权益证明这个名称，只能提供部分信息。
因此，项目即使写明采用某种证明机制，仍需要解释参与者如何获得出块资格、其他节点如何验证，以及出现竞争区块时如何形成一致记录。缺少这些内容，就难以理解其安全主张的依据。
把节点数量等同于独立控制权
节点多并不直接说明共识权力分散。理解这类系统，需要区分节点数量、独立参与者数量，以及实际影响共识的资源分布。
例如，以权益作为投票权重的机制不能简单按节点个数理解表决结果。同一主体运行多个节点，也不能据此视为多个独立控制方。判断时应先弄清权重如何计算，再解释数量指标的意义。
把上链理解为绝对不可更改
比特币开发者指南说明，全节点独立验证区块；有效链之间发生竞争时，累计工作量影响链的选择。区块相互引用，使修改历史记录需要重新处理后续关联区块。
这意味着历史记录的保护依赖验证规则及重建链的成本。看到交易进入某个区块，还需要理解该区块是否可能因链的重新选择而被替代。其他机制的确认与最终性条件，需要按其自身协议解释，不能直接套用比特币的规则。
把攻击门槛当作统一安全线
攻击者需要控制多少资源，取决于机制和攻击目标。干扰出块、改变交易排序与重写部分历史，涉及的条件并不完全相同。
因此，单独引用一个比例，无法完整表达项目的安全性。更有意义的问题是：该比例衡量算力、质押权重还是其他资源；讨论的是哪种攻击；协议又通过哪些规则约束攻击行为。
把底层共识推广为全部可靠性
共识主要解决网络如何就符合规则的账本状态达成一致。交易被协议接受，只能说明其满足相应验证条件，不能由此证明项目的全部宣传成立。
阅读技术说明时，应将已解释的机制、尚未说明的条件和具体项目的实际实现分开。通用文档能够帮助理解原理；某个项目是否按这些原理实现并运行，仍需要针对该项目的证据。