适用范围：技术问题不等于本地项目结论
眉山区块链项目有哪些常见问题，可以先从共识机制和智能合约权限两个层面理解。以下内容适用于相关区块链系统的技术分析，不代表眉山某个项目已经发生故障，也不能据此确认当地项目采用了哪种架构。具体判断需要对应的技术说明、合约配置和运行记录。
共识机制是否只是选择工作量证明或权益证明
以太坊共识机制文档说明，共识涉及节点就区块链状态达成一致的整套协议与激励安排，工作量证明、权益证明只是其中的组成部分。出现竞争区块时，还需要分叉选择规则。
因此，介绍一个项目时，仅标注共识名称不足以说明系统如何运行。还应解释哪些参与者可以提出或验证区块、节点意见不一致时如何选择，以及系统依据什么条件确认状态。这些问题适用于需要多节点协同维护记录的系统。
采用某种共识是否就能证明项目安全
共识机制描述的是特定规则和假设下的协作方式。评估具体实现时，需要核对参与者资格、资源约束和异常处理规则是否与所宣称的机制一致。
以太坊的机制说明不能直接证明其他项目具备相同保障，尤其不能把某种公开网络的安全解释直接套用到参与方式不同的系统。项目名称、所在地区和技术术语本身，都不足以支持安全结论。
管理员能否操作所有业务功能
OpenZeppelin访问控制文档区分单一所有者与按角色授权，并强调最小权限、管理员交接和授权记录的重要性。单一所有者适合管理关系简单的合约，多角色结构适合需要细分职责的场景。
常见疑问是业务操作权限与分配权限是否相同。二者需要分别核对：能够执行某项业务，不一定能够把该权限授予别人；设置了多个角色，也需要继续检查是否由同一账户控制。
权限交接、放弃与查询有哪些容易误解的地方
管理权交接需要确认接收账户能够实际接管。采用双方确认的交接方式，可以减少错误转交的风险。放弃所有权则可能使受所有者限制的功能无法再调用，不能简单理解为完成了正常交接。
权限还可能随人员和业务变化而调整，因此部署时的名单未必代表当前授权状态。查询权限时，需要区分合约是否支持直接列出角色成员，以及是否需要通过授权、撤销事件追踪变化。对具体项目作判断，应以其实际采用的合约能力和当前状态为依据。