讨论范围：从账户到权限结构
讨论“区块链2.0结构有哪些常见问题”，需要先限定具体技术范围。“区块链2.0”通常用于描述支持智能合约的区块链应用，并非一套统一的结构规范。这里以以太坊账户和 OpenZeppelin 合约权限机制为例，解释账户、执行、状态与管理之间的关系，不将这些设计推广为所有区块链的共同实现。
账户、钱包和合约是否属于同一概念
以太坊账户文档区分由私钥控制的外部账户与由代码控制的合约账户，并说明钱包是与账户交互的应用。账户状态包含 nonce、余额、代码哈希和存储根等字段；合约执行需要调用触发。
这些概念对应不同职责：钱包提供操作界面，账户承载链上身份与状态，合约定义执行逻辑。因此，分析应用结构时，应分别识别操作入口、签名主体与实际执行规则，避免把界面展示的功能直接等同于链上能力。
为什么合约不会自行完成所有操作
合约代码描述满足条件后如何处理调用。业务中所谓“自动执行”，仍需要明确调用从哪里发起、输入如何传入，以及调用者是否具备权限。仅有一段合约逻辑，不能据此认定整个业务流程已经具备完整的触发机制。
账户字段也有各自边界：余额用于记录 ETH 数量，代码哈希用于关联代码，存储根用于概括存储状态。理解结构时，应将状态内容、状态摘要和执行规则分开，不能只凭余额判断合约的完整业务状态。
有管理员是否意味着拥有全部业务权限
OpenZeppelin 访问控制文档提供单一所有者与按角色授权两种方式。角色的执行权限和角色管理权限可以分开；默认管理员角色具有较大管理权。所有权可采用两步移交，放弃所有权则会使仅限所有者的功能无法调用。
单一管理主体适合职责简单的场景；需要不同主体分别负责不同功能时，角色划分更便于表达权限边界。评估结构不能只数有多少角色，还要检查谁能授予或撤销角色，否则表面分散的业务权限仍可能集中于同一管理主体。
权限移交与退出为什么容易出问题
权限设计需要覆盖初始授权、日常使用、移交和退出。移交时，关键在于接收账户能否实际行使权限；退出时，则需要判断相关管理功能以后是否仍有必要使用。两步接收机制可以减少错误移交风险，但不能代替对接收主体能力的确认。
这些问题适用于采用相应账户模型和权限组件的智能合约应用。具体系统是否存在缺陷，还需结合实际代码、角色配置与调用关系核验，不能仅凭组件名称或“去中心化”描述作出判断。