实践指南：如何在审计后安全地启动 DeFi 协议

• 原文链接：mixbytes.io/blog...
• 译者：AI翻译官，校对：翻译小组
• 本文链接：learnblockchain.cn/article…

介绍

大多数新团队在构建 Web3 协议时，常常忽视审计并不是 100% 安全保障这一事实。这些团队在进行审计后，并未采取额外措施来降低其协议用户的风险，这往往会导致不愉快的后果——尤其是当所选择的审计提供商质量较低时。本文旨在强调当前行业中可用的选项，这些选项可以帮助在审计的基础上增加额外的保护层，从而降低协议用户的风险。\ \ 我们将从一个典型的协议状态开始，该协议已经进行了 一到两次 安全审计，修复了在这些审计中发现的所有关键 漏洞，并通过各种思维方式增加了测试覆盖率。（有关如何使用黑客、不可变性和系统架构师思维创建深思熟虑的测试的更多详细信息，请查看这篇文章： 掌握 Web3 协议审计的有效测试编写 ）\ \ 想象一下：距离你部署协议只有几天（或更好是几周）的时间。舞台已经搭建好——你准备在 Discord 和 Twitter 上宣布用户可以开始存入资金并赚取 XX% 的年利率。一切似乎都已就绪。你走过了一条漫长的道路：从构思初始想法、开发 MVP、向投资者推介、组建团队、创建产品的第一个版本，到获得公开审计报告并将社区发展到超过 100,000 名 Discord 成员。\ \ 然而，一个紧迫的想法突然浮现：“如果在启动后立即有 50 亿美元的存款流入协议怎么办？协议是否足够稳健，以确保用户资金的安全，让我能够安心？”\ \ 这种担忧挥之不去，促使你考虑推迟启动以解决潜在的 漏洞。如果这个场景即使部分与你产生共鸣，本文将指导你采取可行的步骤来增强协议的安全性，并自信地准备应对任何威胁。

指南

第一步：评估审计数量

首先要考虑的是你为协议进行了多少次审计。如果你的协议引入了一种尚未在 DeFi 中实现的新金融原语，建议的审计数量不少于 三次。如果你的协议与另一个协议集成，但没有引入新的金融原语，那么进行 两次审计 可能就足够了。一个额外的优势是与审计基础协议的公司合作，因为这可能会导致更高质量的审计——前提是审计基础协议的同一团队被分配到你的审计中。\ \ 确定协议所需审计数量的一般规则应取决于协议面临的风险水平和 严重性 （例如，你的协议将与多少种不同类型的协议集成、协议的跨链性质、具有复杂计算的函数数量等）。风险越大，你应进行的审计就越多。每种情况都需要适当数量的审计。不幸的是，这些情况并不容易分类，建立普遍规则来确定审计数量是具有挑战性的。因此，你应咨询你的审计提供商，以了解他们认为需要多少次审计才能覆盖大多数风险，尤其是关键风险。\ \ 这里的经验法则是，不要发布任何一行代码，至少要有 两位开发者进行审核。即使目前没有预算进行适当数量的安全审计，也要确保你的内部团队至少对协议进行一次交叉检查。绝不要部署未经审计的代码，即使是小部分，尤其是在项目的关键领域。验证部署以防止参数或版本的错误。

第二步：考虑限制性启动

除了进行的审计数量外，你还应考虑实施限制性启动，在初始阶段限制协议中的总存款量。这种方法允许你在“实际”中测试协议的所有用例，同时限制用户的风险。\ \ 在安全方面，过于谨慎总是更好的。我们建议从一个等于未来白帽黑客最大悬赏的限制开始，有效地将你的限制性启动转变为一个实时的夺旗（CTF）活动。这种类型的启动也可以有效地进行市场推广，以吸引安全专家。例如，Euler v2 协议进行了类似的启动，并在此处详细描述了该过程：Euler v2 夺旗比赛 。

第三步：在测试网部署和测试

在将协议部署到主网之前，你必须先在 测试网 上启动它，并在此处测试所有用户流程。测试网部署允许你在不冒用户资金风险的情况下实验“实时”协议，并提前测试合约（或网络）更新，从而降低潜在的未来风险。\ 你协议的测试网版本应始终是主网合约的 100% 复制，合约版本方面（实现完整状态复制可能是不可能的）。如果你需要对其中一个合约进行小更新，请始终先在测试网中进行这些更改。这将保护你免受不必要和可避免的错误。\ \ 在此阶段，你还可以测试前端的安全性，为渗透测试人员提供一个方便的测试环境。即使是 XSS 漏洞，在 Web2 项目中并不关键，但在 Web3 环境中可能极其危险。为项目前端在 HackerOne 或类似的 Web2 悬赏平台上启动悬赏计划可能是个好主意。

第四步：监控和警报

协议的正常运行——无论它是由多个模块组成、实现跨链逻辑，还是基于单个合约的简单协议——都需要强大的监控。要监控你的协议，你需要一个收集所有必要 指标 以确定协议当前状态的服务。此外，你还需要一个服务来实时显示协议的 指标，并在发生意外事件时向你的值班团队发送警报。\ \

• 使用像 Prometheus 这样的工具进行实时 指标 可视化。
• 对于警报通知，像 PagerDuty 或类似的服务是合适的。

\ 拥有一支专门的团队，随时准备应对协议状态的意外变化，并采取措施降低用户风险至关重要。准备一份定义协议正常操作的不可变性和 指标 列表。如果这些 指标 超出可接受范围，则应发送警报。\ \ 有效警报的示例包括：\ \

• 负责关键协议角色的多签署人发生变化。
• 发送到协议的有效交易被回滚。
• 关键不可变性（例如，合约余额与跟踪所有可用资金的变量之间的差异）出现偏差。
• 你的协议与之交互的协议的状态变化（例如，价格 预言机）。

\ 编写不可变性是一个值得单独撰写的主题，我们可能会在未来的博客中涵盖。\ \ 为了确保你的值班团队为紧急情况做好准备，请进行压力测试以在测试环境中触发警报，并评估团队对每种类型威胁的反应。Seal 911 为市场领导者进行压力测试，但他们的方法可以根据你的具体情况进行调整。随机间隔模拟紧急情况，以评估团队的反应并完善内部程序。

第五步：漏洞赏金和安全联系方式

在解决上述问题后，你的协议即将准备好上线。确保其安全性的下一个重要里程碑是将其注册到漏洞赏金平台。Immunefi 是最知名的平台，尽管还有其他具有独特功能的平台。\ \ 此外，确保你的专门安全团队的联系方式在文档和 GitHub 仓库中显著位置。战略性地将这些联系方式放置在潜在的白帽黑客可能遇到你代码的地方，使他们能够快速报告问题，降低用户风险。\ \ 通过为赏金猎人提供方便的测试环境，使他们能够轻松探索你的代码。对代码进行充分注释，以防止误解。确保你的协议始终有一个活跃的赏金计划，即使是针对协议本身以外的问题——例如编译器或区块链节点中的漏洞。在这种情况下，赏金猎人通常能比你的开发团队更快做出响应。\ 及时且尊重地与赏金猎人沟通，确保他们继续认为你的项目值得他们的努力。

安全协议上线的最终检查清单

• 根据协议的风险进行必要数量的审计。
• 为协议设置监控和警报系统。
• 部署协议的完整测试网副本并测试所有用户流程。
• 在启动阶段实施初始存款限制。
• 在一个或多个漏洞赏金平台上注册协议，并将安全联系信息添加到所有相关位置。

恭喜你！你已准备好安全协议上线，显著降低了用户的风险。干得好！

我是 AI 翻译官，为大家转译优秀英文文章，如有翻译不通的地方，在这里修改，还请包涵～