先确定参与者与信任边界
区块链的架构需要注意哪些问题，首先取决于谁能参与、谁负责验证，以及节点发生分歧时如何恢复一致。开放网络允许不相识的参与者加入，需要考虑恶意节点和伪造大量身份的攻击；成员受控的网络则需要明确准入与权限边界，不能直接照搬开放网络的安全假设。
共识需要覆盖完整的决策过程
以太坊共识机制文档区分了抗女巫攻击、区块提议与链选择等环节。工作量证明或权益证明只是整体机制中的组成部分，完整设计还涉及协议规则和激励约束。
因此，架构不能停留在选择某一种证明机制。还需回答：谁有资格提议区块，节点如何验证提议，同时出现多个候选区块时采用什么规则，以及作恶受到什么约束。安全性应结合具体机制评估，不能只凭算法名称判断。
独立验证与历史保护需要配合
比特币开发指南说明，全节点独立验证区块；区块通过前一区块头的哈希相连，交易通过默克尔树汇总。其未花费交易输出规则用于约束重复花费，分叉时则在有效链中比较累计工作量。
这些原理对应不同的架构职责：数据结构帮助发现内容变化，交易规则判断状态变化是否合法，共识决定采用哪段有效历史。哈希关联本身不能保证所有节点接受同一版本，也不能替代交易有效性检查。
为分叉和重组保留处理空间
网络传播存在先后，节点可能暂时看到不同的链头。业务系统应区分已接收、已入块和达到所需确认条件等状态，并根据所用协议定义后续处理。依赖链上事件的应用还需要考虑：记录所在区块退出主链后，先前触发的业务如何核对和修正。
区块高度也不适合作为全局唯一标识，因为竞争区块可能处于同一高度。需要精确定位区块时，应使用区块哈希等能区分具体区块的标识。
常见问题：证明包含是否等于验证全部
默克尔证明可以帮助检查某笔交易是否被指定区块收录，但这一结论有边界。架构仍需明确区块头是否可信、区块属于哪条链，以及交易规则由谁验证。轻量客户端和独立验证节点承担的验证范围不同。
这些原则适用于理解基于区块组织记录的分布式账本。具体确认条件、资源要求与故障处理方式，应由采用的协议决定，不宜把某一条链的规则直接推广为所有区块链的共同要求。