先明确应用讨论的范围
“华尔街区块链应用场景”涉及金融业务与链上程序的结合。入门时，可以先理解三个问题：合约管理什么、谁能改变它、出现异常如何处理。以下讨论通用技术机制，不据此判断某家金融机构的实际部署情况。
智能合约能够按预设代码管理链上数据与价值。将业务规则写进合约，需要把参与者、操作条件和权限边界表达清楚；自动执行本身不能证明规则设计正确。
代币管理：理解创建与销毁权限
代币管理是理解合约权限的直观入口。例如，一个业务模型可以分别设置创建代币与销毁代币的角色，让不同账户承担不同职责。这种设计适用于需要明确操作分工的系统。
OpenZeppelin访问控制文档介绍了单一所有者与按角色授权两种机制，并强调最小权限原则。理解这类模型时，除了看谁能执行操作，还要看谁能授予或撤销权限；角色分开后，管理权限仍可能集中。
参与资格：链上授权的适用边界
角色机制也可以用于限制特定功能的参与资格。名单需要变化时，系统可以通过授予和撤销角色调整授权，适合参与者并非一次确定的业务流程。
这里需要区分地址授权与身份核验。合约检查某个地址是否具备角色，并不能单独证明现实身份核验已经完成。用于客户身份相关流程时，仍需明确资格由谁确认、何时更新，以及失效后如何撤权。
管理审批：减少单一账户依赖
对于涉及重要管理操作的合约，多签机制可以要求多个签署方共同批准。它适合需要多人审批的权限安排，但实际效果取决于签名门槛、密钥保管和签署方是否独立。
ethereum.org的智能合约安全说明强调访问控制、测试与独立审查的重要性。对金融业务而言，这意味着权限设计需要和验证流程一起考虑，不能只检查业务功能是否能够正常运行。
常见问题：审计和验证能保证安全吗
审计不能保证发现所有漏洞。正常输入下的测试通过，也不意味着异常输入或边界条件已经覆盖。理解安全评估时，应关注检查对象、覆盖范围和未解决的问题。
形式化验证同样有范围：它针对明确写出的性质及相应模型提供证明，不能直接推导出整个业务系统没有风险。合约管理逻辑能否调整、调整由谁批准，也应在设计阶段明确；采用可升级结构时，升级权限本身就是需要保护的关键能力。