一、只选共识名称，没有明确一致性规则
讨论区块链私有链技术架构有哪些常见问题，首先要区分共识与权限两个层面：前者解决节点如何认可共同状态，后者解决账户可以执行哪些操作。两者需要配合设计。
以太坊共识机制文档将共识解释为协议、规则与激励等组成的整体。仅用工作量证明、权益证明或权威证明命名架构，仍不足以说明完整流程。对于私有链，需要进一步明确谁能提出区块、如何验证，以及发生不同状态视图时如何达成一致。
二、直接套用公链的确认条件
共识规则具有适用条件。以太坊文档中的权益权重、分叉选择与奖惩机制属于其具体协议背景，不能直接转换成所有私有链通用的节点投票比例。
架构说明应结合采用的协议，交代参与者资格、投票权如何计算，以及什么条件下可以确认状态。否则，“多数同意”这样的描述难以回答节点意见不一致时系统如何处理。
三、混淆网络准入与业务授权
允许某个参与者接入网络，并不能完整表达其业务权限。对于使用智能合约的私有链，还需要明确哪些账户可以调用管理功能，以及权限检查位于哪里。
OpenZeppelin访问控制文档区分了单一所有者与基于角色的授权方式。单一管理主体可采用较简单的所有权模型；存在多种职责时，角色划分更适合表达不同操作范围。架构评审应检查业务职责是否落实到相应的授权检查。
四、忽略管理权限自身的风险
业务操作权与角色管理权需要分别理解。能够执行某项业务，不一定意味着能够把这项权限授予别人；反过来，能够管理角色的账户可能间接影响多项业务。
上述访问控制文档还指出，默认管理员具有较大的权限影响范围，所有权交接也可能因目标账户错误而失效。适用于支持相应机制的合约系统的做法，包括细分管理员职责、采用分步交接，并核查接收账户是否具备实际管理能力。
五、缺少权限变更后的核查方式
权限会随组织分工变化，架构不能只记录部署时的授权关系。还应明确授予、撤销和交接之后，如何确认当前有效权限，避免管理界面与实际授权状态脱节。
对于合约权限系统，变更事件与成员查询能力可以承担不同的核查用途，具体取决于所用组件。以上讨论适用于共识与合约授权层面的架构分析，不能单凭这些设计判断一条私有链的性能、隐私保护或整体安全性。