性能指标需要对应实际业务
区块链技术的真正应用需要注意哪些问题，可以从两条主线理解：系统能否承受业务负载，以及关键操作由谁控制。前者影响处理效率与费用，后者决定管理权限的边界。两方面需要一起设计。
以太坊扩容文档说明，网络需求增加会带来容量与费用压力，扩容需要兼顾速度、吞吐量、安全和去中心化。应用评估因此应区分提交成功、处理完成和最终确认，不能用单一的每秒交易数量概括全部体验。
扩容方案具有不同的适用条件
该文档区分了依托主网安全的二层方案和采用独立共识的侧链，也说明了Rollup与Validium在数据存放位置上的差异。这意味着，能够与主网通信的方案，其安全条件并不相同。
选择方案时，需要分别梳理交易由谁处理、结果如何验证、验证所需数据存放在哪里。如果业务依赖快速反馈，还应明确界面显示的处理结果与最终结算之间的关系。链下执行可以缓解主网负担，但应用仍需理解其验证与结算流程。
关键操作应按职责划分权限
OpenZeppelin访问控制文档介绍了单一所有者与基于角色的授权机制。前者适合管理职责简单的场景，后者可以分别设置不同操作权限，并遵循最小权限原则。
对于有多类管理人员的应用，应把业务操作权与分配权限的管理权分开考虑。例如，能执行某项操作，不必同时拥有授权他人执行该操作的能力。评估权限是否合理，需要检查每项关键功能及其管理员，而不只是查看账户数量。
权限交接和退出同样属于系统设计
OpenZeppelin文档还指出，两步所有权转移要求接收方确认；放弃所有权则会使受所有者限制的管理功能无法继续调用。默认管理员可以管理其他角色，其权限需要特别审慎地配置。
因此，权限交接不能只理解为更换地址。应用需要明确谁接收管理权、接收方能否操作，以及权限撤销后哪些功能仍应可用。停止某个账户的业务权限，也不等于取消其所有管理能力，具体结果取决于角色关系。
常见问题：扩容和公开代码是否足够
扩容不能替代访问控制，两者解决的问题不同。即使交易处理更快，错误的授权仍可能允许不合适的账户执行关键操作。公开代码也不能代替对实际权限配置的检查。
实际验收应把性能与治理放在同一张需求表中：业务接受怎样的确认时间，系统依赖哪些验证条件，谁能更改权限，以及交接后功能是否符合预期。这样才能把技术能力转化为可核查的应用要求。