Morpho Blue 安全框架：构建最安全的借贷…

Morpho Blue 安全框架：构建最安全的借贷协议

Morpho

在整个 2023 年，我们都专注于构建世界上最安全的借贷协议。任何协议的安全性都始于最初的想法，并贯穿项目的整个生命周期；换句话说，它永无止境。本文分享 Morpho Blue 的安全框架，以便其他项目可以从我们的经验中受益。

该框架分为四个阶段：预构建、构建 & 测试、预部署和后部署。每个阶段都有不同的目标和可交付成果。本文将逐步介绍每个阶段，从预构建阶段开始。

Morpho Blue 安全框架阶段

在我们开始之前的一些免责声明：

• 项目的限制是时间和金钱。任何流程都可以用无限的金钱和时间来改进：更多的测试、安全审查等等。

• 本文仅关注智能合约安全。项目团队良好的 OpSec 和 dapp 级别的安全是必要的。

• 这不能保证安全，而只是为了尽量减少代码库中的任何漏洞而采取的步骤的回顾。

预构建阶段

在编写任何一行代码之前，我们定义了我们想要构建的内容。Morpho Blue 的开发大约花费了六个月的时间。虽然对于仅仅 ~600 行代码来说，这似乎很久，但重要的是要考虑更大的背景。Morpho Blue 是长时间辩论、数十次迭代以及被扔进垃圾桶的概念验证的成果。进入预构建阶段。

概念化安全协议需求

Morpho Blue 的需求是从我们在 去中心化经纪商 (如 Aave 和 Compound) 上构建 Optimizers 的经验中发展而来的。

我们意识到这些平台比它们看起来更危险：

• 它们有非常大的代码库，有几千行代码。

• 用户会接触到平台上列出的所有资产。

• 必须实时监控和调整数百个风险参数。

• 它们不是无需信任的，因为它们是可以由治理或运营商更新的可升级代码。

在 Morpho Labs，我们坚信，为了使去中心化金融成为整个金融系统的轨道，基础层协议必须没有任何缺陷。

这引导我们塑造了我们对 DeFi 借贷领域的愿景，并概念化 Morpho Blue 如何成为最安全的借贷协议。

包含必要的；将其余的外部化

至关重要的是要理解，每个附加的需求都会增加协议的攻击面。任何时候，如果想要添加额外的功能，都应该问以下问题：“如果我们不包含此功能，用户是否不会集成/使用该协议？”。一般来说，答案是“否”，应该删除该需求。

这个简单的过程，系统地应用，使得设计只关注协议的核心功能。这些功能对于使其有用和工作至关重要。

通过这样做，以下功能被放弃：

• 协议级别的风险管理增加了代码的复杂性。

• 协议中嵌入的预言机创建了对一个预言机提供商的依赖。

• 协议中嵌入的 IRM 降低了灵活性并增加了代码的复杂性。

• 无预言机模式：必须构建一个完整的抗性拍卖系统。

在 Morpho Labs，我们经常将 极简主义 作为设计和编写智能合约的指导方针。我们鼓励其他项目也采用这种方法。

威胁建模和公开辩论

可以（并且应该）将威胁建模应用于他们的项目。目标是提出对项目几乎每个组件或利益相关者的任何担忧。即使我们不使用 这个特定的框架，也值得一读。

Morpho Labs 识别威胁的方式不那么程序化，但仍然非常有效；我们已经建立了一种文化，在这种文化中，任何人都可以（并且被鼓励）挑战事物并将决策置于质疑之中。这促进了公司内部的公开辩论和讨论。

虽然这在构思过程中似乎很耗时，但它最终通过找到最佳（通常也是最简单）的解决方案来节省时间。我们建议创始人及管理者为团队成员创造表达他们的声音和担忧的空间。

构建 & 测试阶段

在预构建阶段，我们构建了几个不同的 POC 和迭代，这使得规范更加清晰和简洁。此时，方向已经明确，是时候开始构建协议了。

以下是我们用来及早发现错误的一些方法。

单元和集成测试

当然，我们使用了 单元测试 和 集成测试。单元测试非常容易设置，并且可以捕获大多数可能遇到的错误。发布未经彻底测试的代码是不可能的。

我们的目标是覆盖代码的所有分支。为此，我们使用了 Foundry 的 forge coverage 功能。但仅凭这一点并不能确保代码经过了充分的测试，因为该工具存在局限性；有些分支被标记为已覆盖，但并非所有场景都已覆盖。为了帮助确保覆盖所有场景，可以使用 分支树技术 (BTT) 方法来列出它们。还可以使用诸如来自 Certora 的 vertigo-rs 或 gambit 之类的突变工具来搜索丢失的测试。

突变工具 是一些工具，它们更改现有代码的某些部分以创建“突变体”并将测试套件应用于它。如果测试成功，则意味着缺少一些测试。

编写集成测试至关重要，尤其是在代码库依赖于外部第三方时。这些测试确保合约在生产中的行为符合预期。

可以模拟第三方依赖项以使测试运行得更快，但我们改用 fork，因为可以及早发现一些意外的极端情况。例如，不合规的 token（如 USDT）不会在 transfer 上返回布尔值，其他 token 则会在 transfer 时收取费用等等。是否应该覆盖极端情况？如果应该，是否已应用正确的适配？否则，必须意识到这一点并在文档中提及假设。例如，这里 是 Morpho Blue 对市场的假设的一个例子。

Fuzzing

我们用 fuzzing 来补充测试，以覆盖大的输入范围并捕获极端情况。使用 Foundry 非常容易设置。在发布协议之前不使用 fuzzing 将是一个可怕的错误。

只管 fuzzing。

内部审查

我们在 Morpho Labs 有 2 个团队：协议团队和 集成团队。协议团队同时处理与协议相关的研究和编码部分。另一方面，集成团队审查和增强协议，并致力于改进测试套件。

无论一个团队多么强大，代码中总是存在一些缺陷、错误或低效之处。由一个独立的团队尽早审查团队的代码，带着全新的视角，这是非常被低估的。

在任何情况下，我们始终让所有 solidity 开发者审查将要部署的所有智能合约。这确保了每个人都完全了解实时的代码库，并且我们不会创建一个单点故障（一个人拥有所有知识）。

同样，记录每个设计选择和研究是避免创建单点故障的好方法。为了有效地共享知识、让新员工上手或提醒我们之前的决策（对辩论很有用），这也是必要的。

顾问/VC 研究员同行评审

一旦代码库相当稳定，我们就会邀请外部顾问和来自 VC 公司的安全研究人员或一些顾问来进行外部安全审查。请注意，顾问和研究人员已经在协议设计期间为我们提供帮助。

同样，这增加了另一层外部视角来查看代码，批评事物，并使代码库更加安全。

使用 Certora 进行不变量和形式化验证

除了单元/集成测试和模糊测试之外，我们还使用 Foundry 完成了 不变量测试，并使用 Certora 的 Prover 进行了形式化验证。关于后者，我们强烈建议阅读我们关于 使用 Certora 形式化验证 Morpho Blue 的文章，其中深入探讨了该主题。

作为一个 TL;DR

形式化验证 是指使用数学方法来证明智能合约的正确性的过程，通过验证它是否满足某些属性。这些属性使用验证工具支持的正式语言来表达，用于证明它们

可以查看 Quentin 在 Morpho Blue 的存储库中专门的 文件夹 中编写的规则。

不变量测试可以被看作是形式化验证的较弱版本。然而，它设置起来更快，并且不需要对形式化验证有很强的了解。所需要的是协议的不变量。例如，在 Morpho Blue 中，一个不变量是对于特定的贷款资产，借入的金额加上协议的余额必须大于或等于供应的金额（参见 此处）。

我们两者都做，因为不变量测试可以更早地捕获错误。

由于对协议执行形式化验证是一个永无止境的过程，因此该工作坊通常会持续到协议部署之后。

训练营来打破代码

对于每个新协议，我们都会做一个训练营（Morpho Labs 一年中最好的时刻 👀）。我们将整个团队聚集在法国一个非常好的地方几个星期。这是一个尝试和非常紧张的时刻，团队能量达到了局部最大值。目标很明确：

• 确保每个人都认同协议的愿景。

• 确保每个团队都为发布做好准备。

• 打破代码。

因此，我们花费了几个星期的时间来改进代码，试图打破它，改进测试套件，删除无用的功能，并辩论非常小的细节。

训练营结束后，代码就可以进行外部安全审查了。

预部署阶段

Tier 1 安全审查

在进行安全竞赛之前，我们与两家 tier 1 安全公司（通过 Cantina 与 Open Zeppelin 和 Spearbit）合作开发 Morpho Blue。目标是：

• 找到项目中主要的漏洞。

• 接收关于设计选择的反馈。

与竞赛相比，安全审查通常需要更多时间，因此安全团队可以深入了解协议的细节，尤其是在涉及一些数学运算时。它使我们能够清理和改进代码库，并加倍我们对协议特定方面的研究。

根据时间安排，最好是按顺序进行安全审查。不幸的是，这并不总是可能的，因为它可能会将协议的部署推迟几个月。

可以在 此处 找到对 Morpho Blue 进行的所有安全审查。

需要记住的一些事项：

• 必须提前计划安全审查，尤其是在大多数安全公司都被预订一空的牛市中。

• 安全审查的定时很难。但是，对于项目团队来说，确保他们在审计开始时已准备就绪至关重要。这包括编写测试并提供最少数量的文档来帮助安全研究人员。团队绝不能等到最后一分钟，那就太晚了。

• 作为一般规则，项目团队不应低估进行修复的时间。最好彻底了解问题，而不是仓促修复。

• 安全审查对团队来说可能是压力大且令人筋疲力尽的。

• 在安全审查期间，团队必须随时回答安全研究人员的问题。这加快了他们对代码库的理解，因此他们可以专注于捕获错误。

• 再多的安全审查也不够。

$20 万美元 Cantina 竞赛

在应用安全审查后的修复程序后，就该进行竞赛了。可以将安全竞赛视为一个巨大的真人 fuzzer 来发现错误。

同样，我们与 Cantina 合作有几个原因：我们很了解团队，并且相信他们会为安全研究人员创建一个很棒的平台；此外，我们是第一个提供公共 Cantina 竞赛的项目。

为了最大限度地提高竞赛效率，请提供以下建议：

• 奖金必须足够高，以确保最好的安全研究人员会查看代码。

• 尝试找到一个没有其他大型项目进行重大竞赛的时刻。

我们很幸运能够满足这两个要求，并让技术娴熟的安全研究人员查看 Morpho Blue 的代码及其外围合约。

准备事件响应计划

我们一直在与竞赛并行地制定事件响应计划。事件响应计划是易于遵循的剧本，可以在紧急情况下快速响应。由于我们已经考虑过了，因此我们将通过遵循剧本来节省时间和脑力。

威胁建模可以在这里发挥作用；可以将 IRP 适配到已经确定的特定场景。Nascent 的 危机手册 是创建 IRP 的一个很好的资源。

我们还 与 Chainalysis 建立了合作伙伴关系；当发生盗窃、违规或漏洞利用（包括未经授权的资金转移）时，将立即聘请 Chainalysis 加密事件响应服务来监控和追踪支持资产追回的交易。

通过 Hats Finance 提供的 10 万美元预部署赏金

在竞赛后应用修复程序后，我们要求之前进行安全审查的安全研究人员最后一次查看更改。

现在，有一段时间协议尚未部署，但代码已冻结并公开。为什么不激励没有时间查看代码的安全研究人员在代码库中找到高/严重错误？这就是为什么我们与 Hats Finance 合作创建一个 10 万美元的预部署赏金。

后部署阶段

Morpho Blue 已经启动。现在，我们无法回到过去。对于不可变的合约来说，最好的办法是提供赏金并密切监控合约。

监控

监控合约非常重要。在内部，我们构建了自己的机器人，该机器人可在每次交易后对每个市场执行持续的不变量检查。如果出现问题，则会发出警报，以便我们可以快速做出反应并遵循我们已经设计的相关 IRP。

我们本可以在协议中添加熔断器。但是，我们认为协议应该保持不变，并且治理应该最小化。否则，我们只是在 web3 基础设施上重建 web2 平台，这与 DeFi 的承诺相矛盾。

50 万美元的漏洞赏金

对于安全研究人员来说，一旦协议已部署，提供赏金可能是最重要的事情。这是激励有才华的人不要破解协议的唯一方法。否则，人们只是在赌每个人都是善良和友好的（这是不合理的）。

Morpho Blue 及其外围合约的漏洞赏金将很快发布。

结语

现在你已经了解了我们用于 Morpho Blue 的安全流程的所有信息。我们为一个单一协议投入了大量的时间和金钱，但这对于一个旨在处理数万亿美元的协议来说是有意义的。

虽然有很多改进的可能性，但我们希望这将有助于其他项目加强其安全实践。

对于未来，我们有一些想要探索的想法，其中包括：

• 在流程的早期阶段使用安全研究人员作为顾问。

• 按以下顺序进行：在代码准备好接收早期反馈之前进行一次小型审计，然后在代码完成后进行外部安全审查，然后再进行竞赛，然后再进行一次外部安全审查。

• 像 Yearn 那样，在生产中进行 CTF。

也请不要犹豫与我们分享你的想法和最佳实践！

• 原文链接： morpho.mirror.xyz/7mfZLV...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～