先明确业务需要达成什么共识
区块链不同的技术方案需要注意哪些问题，首先取决于系统需要让哪些参与者，对哪些记录达成一致。比较方案前，应明确谁能提交交易、谁能验证记录，以及参与者之间是否存在信任基础。
如果业务涉及多个独立参与方共同维护记录，就需要进一步说明：出现互相冲突的交易、节点离线或消息延迟时，系统如何确定可接受的状态。这些问题比单独比较共识名称更能界定技术需求。
共识机制要看完整规则
以太坊开发者文档将共识机制解释为协议、激励与相关规则构成的整体。工作量证明和权益证明涉及参与资源约束与出块者选择，完整方案还需要交易验证、分叉选择等配套规则。
因此，评估时应把规则衔接起来：谁有资格提出区块，其他节点依据什么接受区块，同时出现多个候选区块时又如何选择。只知道采用哪一种证明机制，仍不足以判断系统行为。
安全比较需要写明成立条件
工作量证明通过计算投入形成参与约束，权益证明通过质押及奖惩形成经济约束。比较时需要分别考察相关资源是否集中、违规行为能否被识别，以及约束规则如何执行。
攻击比例也必须结合具体协议和攻击目标理解。重排交易、阻碍确认与伪造有效交易涉及不同条件，不能用一个比例概括全部安全边界，更不能把攻击成本较高理解为绝对不会发生攻击。
区分区块有效与链的选择
比特币开发者指南说明，全节点独立验证区块；在有效的竞争分支之间，累计工作量用于确定跟随哪条链。由此可见，区块符合规则与区块最终留在主链上，是需要分别处理的问题。
业务系统应明确交易被收录后如何更新状态，以及发生链重组时怎样处理已有记录。适用的确认条件取决于协议和业务容错要求，不能仅凭出块速度判断记录是否已经稳定。
明确客户端实际验证了什么
全节点验证与轻量验证具有不同边界。默克尔证明可用于核验交易是否被包含在某个区块中，但包含关系本身不能证明客户端已经独立执行了全部交易规则。
选择客户端方案时，应说明它自行检查哪些内容、依赖外部节点提供哪些信息。资源受限场景可以评估轻量验证，但需要把节省资源所对应的验证范围交代清楚。
常见问题：有哈希连接就无法修改吗
哈希连接使历史内容的变化能够被发现，也使修改记录牵涉后续区块。历史记录能否被替换，还受到共识规则、资源投入和节点验证的共同约束。
因此，方案说明应给出可检查的条件：正常情况下如何确认，冲突时如何选择，异常后如何恢复。明确这些边界，才能判断技术方案是否符合实际业务要求。