从四个问题理解技术结构
区块链开发新技术涉及哪些技术概念，可以先拆成四个问题：计算在哪里执行，结果如何验证，状态如何还原，关键操作由谁授权。以以太坊扩容和智能合约访问控制为例，这些问题分别对应二层执行、密码学证明、数据可用性和权限管理。它们构成不同的技术层次，也有各自的适用边界。
二层扩容与有效性证明
以太坊开发文档介绍的ZK-rollup，将交易放在链下批量执行，再向主链提交状态更新及有效性证明，由链上合约验证。其状态可用Merkle根进行承诺，重建状态所需的数据则通过calldata或blob发布。
这种结构适用于希望减少主链重复执行负担、同时在主链验证结果的扩容场景。理解时应区分三个概念：执行产生结果，证明说明结果符合规则，状态承诺用紧凑的哈希表示状态。仅有一个状态根，并不能说明状态变化正确。
数据可用性与隐私的边界
有效性证明回答计算是否正确，数据可用性回答参与者能否取得还原状态所需的信息。两者解决的问题不同，设计系统时需要分别考虑。
ZK-rollup这一名称不意味着交易默认保密：公开发布的状态重建数据仍然可见。blob也不能直接视为永久档案，其长期访问需要考虑归档安排。因此，隐私需求、状态同步需求与历史数据保存需求，应分别定义。
所有权与基于角色的权限
OpenZeppelin访问控制文档区分了Ownable所有权模型与AccessControl角色模型：前者适合单一管理主体，后者适合将不同操作分配给不同角色。角色的使用权限与授予、撤销角色的管理权限也有区别。
例如，一个账户能够执行某项业务操作，不代表它应当能够授权其他账户执行。按职责拆分权限，有助于落实最小权限原则。管理员交接还涉及接收确认；Ownable2Step通过新所有者主动接受来完成交接。
适用条件与常见问题
扩容证明能否代替权限检查？不能。证明用于验证系统规定的计算规则，而权限检查决定哪些调用被规则允许。规则本身如果给予某账户过大的权力，正确执行规则也无法消除这种设计问题。
是否所有应用都需要复杂角色体系？应根据管理职责选择。单一管理主体可采用简单所有权，多职责协作则适合角色划分。无论采用哪种模型，都需要明确谁能操作、谁能授权，以及管理权限如何交接；这些问题与扩容能力同样影响系统行为。