银行在链上建设前必须做对的架构决策

OpenZeppelin 发布于 2026-06-19 阅读 123

银行在构建链上金融基础设施时,架构决策(如升级治理、密钥管理、访问控制、暂停机制、依赖集成和链选择)至关重要,因为这些决策在代码编写前就已确定,且上线后难以更改。文章强调了架构审查的价值,指出设计阶段的决策决定了安全态势,而预上线安全审查只能记录现有模型。建议银行在设计阶段进行架构审查,以确保合规与风险管理。

对于构建链上金融基础设施的银行来说,最能决定一个程序是否具有防御能力的决策大多在编写一行代码之前就已做出。升级治理、密钥管理和访问控制架构在设计阶段就已确定,当安全审查开始时,它们基本上已经定型。 安全团队可以识别这些决策中的风险,但并非总能修复它们,除非进行大量返工,或者在某些情况下,完全重新部署现有系统。对于从创新团队过渡到核心运营的链上程序来说,这一区别至关重要。

为什么链上架构更难更改

在传统软件中,大多数架构决策可以通过足够的工程努力重新考虑。访问控制模型可以更新,基础设施可以重新配置,大多数更改可以在用户不知情的情况下进行。

链上程序的工作方式不同。智能合约一旦部署,默认是不可变的。 任何可升级性都必须经过精心设计,而可升级性的结构本身会引入自身的安全面。在传统系统中属于常规的更改,在链上可能需要治理流程、新的合约部署以及资产和状态的迁移,所有这些在实时金融环境中都带有操作和安全风险。

这意味着链上程序的安全态势在很大程度上是架构阶段决策的函数。启动前的安全审查记录了已构建的安全模型,而架构审查则塑造了它。

最重要的决策

升级治理

合约是否以及如何升级是一个团队做出的最重要的架构决策之一,也是最常被规定不足的决策之一。

不可升级合约提供了简单性和可预测性,但如果在部署后发现漏洞,则没有补救路径。可升级合约引入了灵活性,但也引入了一个需要明确回答的问题:谁可以授权升级,在什么条件下,以及有什么控制措施?

如果没有时间锁,持有相关密钥的任何人可以立即单方面执行升级。对于银行来说,升级治理应遵循机构风险标准:防止立即单方面更改的时间锁、分散权限的多签要求,以及满足内部和外部风险与合规审查的文档化授权流程。这些要素应在部署前精心设计并准备就绪。

密钥管理和访问控制架构

链上金融系统中的每一个特权操作都由私钥控制。密钥管理的架构对于整个程序的安全至关重要:谁持有密钥,它们如何构建和分发,使用它们需要什么授权,以及如何轮换或撤销。

这些方面的错误会迅速产生连锁反应。考虑一个典型的法币支持代币的特权结构:

  • 代理管理员:可以更改合约逻辑
  • 所有者:控制角色分配
  • 铸造者:控制发行能力
  • 暂停者:可以暂停转账
  • 封锁列表者:可以冻结账户

每个角色都代表一个独特的攻击面。如果其中任何一个被攻破,爆炸半径完全取决于访问控制架构的设计方式,以及系统其余部分能多快做出反应。

设计良好的访问控制架构限制了任何单个被攻破密钥所能做的事情,确保高影响操作需要多个批准,并提供清晰的遏制路径。设计不良则意味着,在监控警报来得及采取行动之前,攻破一个角色就可能级联到完全控制整个系统。

暂停机制及其未覆盖的范围

许多链上金融程序包含一个暂停机制作为紧急制动:在出现问题时能够快速暂停转账和铸造。这是一个合理的设计选择,对于银行来说,这通常是其链上运营风险论证的关键部分。

暂停机制限制了面向用户的功能,如转账、铸造和销毁。在大多数标准实现中,它并不能阻止特权管理操作。所有权转移、角色更新、代理管理员更改和合约升级都可以在合约暂停时执行。

依赖与集成设计

银行的链上程序集成了外部协议,依赖预言机获取定价和数据输入,并且在许多情况下,通过桥与其他链交互。这些集成中的每一个都是一个架构选择,并带有其连接的外部系统的风险特征。

在架构阶段的两个相关问题:给定的预言机或协议当前是否可靠,以及如果不可靠,集成设计是否限制了风险敞口。断路器、回退逻辑和风险敞口限制是需要开发前指定的架构控制。

链上依赖关系带有自身的风险特征,并代表了主智能合约之外的攻击面。这也是一个供应商风险和合规问题:协议、预言机和桥在集成前需要结构化的技术尽职调查,调查结果应以满足内部风险审查和监管审查的形式记录。

链的选择

程序运行在哪条链上是一个早期的架构决策,具有长期的安全影响,但通常主要被当作技术或生态系统问题来处理。

不同的链带有显著不同的风险特征:验证者集中度、升级治理、事故历史,以及围绕它们的安全工具和安全评估生态系统的成熟度。对于构建生产金融基础设施的银行来说,链的选择既是风险管理决策,也是技术决策。它应该在开发开始前进行结构化分析。

评估这些决策的恰当时机

在部署前对智能合约代码进行彻底的安全评估仍然是任何机构链上程序的基础要求。启动后的持续监控对于随着系统、其依赖关系以及更广泛环境的演变而保持对风险敞口的实时了解是必要的。

早期阶段杠杆最高,并不仅仅因为修复发现成本更低。在超过900次安全项目中,我们看到了相同的模式:架构决策为后续的每一次审查设定了基调。OpenZeppelin 的架构审查是一种不同于启动前审查的参与方式:协作性和指导性,它帮助团队设计访问控制结构、评估升级模式,并在这些选择被实际实施之前做出密钥管理决策。启动前审查则记录已构建的内容,并针对已知的风险模式进行评估。两者都是必要的。

对于链上面临风险委员会批准、合规审查和监管审查的银行来说,这种区别是实质性的。在架构阶段进行审查的程序会产生更清晰的安全评估记录、更少的延迟发现项,以及一份更明确的文档,可以提交给风险委员会或监管机构。

寻找安全合作伙伴?

与专家交流 →

常见问题

为什么架构决策在链上程序中比在传统软件中更难更改?

智能合约一旦部署,默认是不可变的。部署后更改治理结构、访问控制或升级逻辑需要一个预先设计的升级机制或完全重新部署,这两者对于实时金融系统来说都是复杂且高风险的操作。

什么是升级治理,为什么它对机构链上程序很重要?

升级治理定义了谁可以授权对已部署智能合约的更改以及在什么条件下进行。如果没有时间锁和多签要求等控制措施,单个被攻破的密钥就可以在任何响应之前更改实时合约逻辑。对于银行来说,这需要在部署前按照机构风险标准进行设计。

暂停机制会停止链上金融系统中的所有活动吗?

不一定。标准的暂停机制会停止面向用户的功能,如转账和铸造,但不会阻止特权管理操作,如所有权转移、角色更新或合约升级。了解暂停的确切范围是一个架构问题,应在启动前解决并记录。

银行应如何从安全角度处理链上依赖关系,如预言机和桥?

链上依赖关系带有自身的风险特征,并代表了主智能合约之外的攻击面。集成设计应包括在依赖关系失败或被攻破时限制风险敞口的控制。这也是一个供应商风险和合规问题:协议、预言机和桥在集成前需要结构化的技术尽职调查,调查结果应以满足内部风险审查和监管审查的形式记录。

什么时候是为链上程序引入安全合作伙伴的恰当时机?

在架构阶段、开发开始之前进行安全审查会产生最高的杠杆,因为发现的问题可以完全修复而不是推迟。启动前的安全评估和启动后的持续监控也是必要的,但最能决定程序安全态势的决策是在设计阶段做出的。

  • 原文链接: openzeppelin.com/news/th...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

相关文章

0 条评论