【 学习专栏】a16z：如何保护智能合约安全？

　　【 学习专栏】a16z：如何保护智能合约安全？

　　本文属于老雅痞原创文章，转载规矩不变，给我们打声招呼～

　　转载请微信联系：huangdiezi，更多DAO、Web3、NFT、元宇宙资讯请关注FastDaily

　　作者：Andy Beal、Nassim Eddequiouaq、

　　Riyaz Faizullabhoy 和 Christian Seifert

　　

　　通过更加重视智能合约的安全性，许多发生在 web3 项目上的黑客攻击都是可以避免的。

　　通常，攻击者会发现并利用整个软件开发供应链中的多个缺陷——向世界发布新代码的一系列从设计到部署和维护的步骤。如果更容易获得适当的协议和最佳实践，我们相信会发生更少的安全事件。

　　这篇文章的目的是概述 web3 构建者、开发人员和安全团队在设计、开发和维护安全的智能合约系统时必须考虑的核心安全基础。下面介绍的框架讨论了应在整个软件开发生命周期中实施的八种核心安全考虑类别——从威胁建模到应急响应准备。

　　在进入智能合约安全考虑之前，了解安全软件供应链的开发阶段很重要，可以分为以下五个阶段：

　　A) 设计：开发人员描述系统所需的功能和操作，包括重要的基准和不变的属性。

　　B) 开发：开发人员编写系统的代码。

　　C) 测试和审查：开发人员将所有模块放在一个测试环境中，并评估它们的正确性、规模和其他因素。

　　D) 部署：开发人员将系统投入生产。

　　E) 维护：开发人员评估和修改系统以确保它正在执行其预期功能。

　　有了这个基本的生命周期基础，现在让我们深入了解影响每个步骤的智能合约安全注意事项。下图将考虑因素映射到其相关的开发阶段。请注意，供应链中的某些步骤有多种安全考虑：

　　但软件开发周期（如上所示）不一定总是遵循线性路径：在实践中，可能重叠或延伸到其他阶段。可以重复步骤。一些任务，例如测试和安全审查，可能需要自始至终执行。

　　上面描述的软件开发周期步骤和相应的安全注意事项为促进智能合约的安全性提供了有用的基础，接下来会更详细地解释它们，帮助各位理解、应用和分享这些最佳实践，尽可能简单和具体的表述关键问题是什么、为什么和怎么办。

　　设计阶段的智能合约安全注意事项（A）

　　#1：考虑威胁建模和安全设计

　　内容：从开发周期的一开始就实施明确的做法来识别系统的潜在威胁并确定其优先级是很重要的。智能合约开发人员应确定要在开发中实施的任何安全控制以及应在开发中检查的任何威胁测试、审计和监控。所有安全假设，包括攻击者的预期复杂程度和经济手段，都应在设计阶段明确定义和阐明。

　　原因：虽然开发人员倾向于只关注智能合约或协议的预期用途，但这种唯一关注可能会给他们留下攻击者可以并且将会利用的盲点。

　　怎么做：遵循已知的威胁建模实践。如果开发团队没有内部安全的专业知识，那么应该在设计阶段的早期就与安全顾问合作。在设计系统时采用“攻击者”的心态，并假设任何个人、机器或服务都可以合理地受到损害。

　　开发阶段的安全考虑 (B)

　　#2：考虑管理和访问控制

　　内容：实施访问控制，限制对特权账户和智能合约调用执行管理任务（例如升级合约和设置特殊参数）的特殊功能的能力。遵循“最小特权原则”：每个参与者应该只拥有所需的最小访问权限。

　　原因：通过升级和治理流程维护协议允许开发人员通过添加新功能、修补安全问题和解决不断变化的条件来改进协议。如果升级的能力没有得到适当的控制，这可能构成一个严重的安全漏洞。

　　怎么做：建立一个多重签名钱包(multisig) 或 DAO 合约，以透明的方式代表社区管理变更。变更应经过彻底的审查过程，以及时间锁定（故意延迟制定并具有取消能力），以确保可以验证它们的正确性并在发生治理攻击时回滚。确保特权密钥在自托管钱包或安全托管服务中安全地存储和访问。

　　#3：考虑可重用、久经考验的模板和集成

　　内容：尽可能利用现有的智能合约标准（例如 OpenZeppelin Contracts）并评估您可能需要与现有协议进行的协议集成的安全假设。

　　原因：使用现有的经过实战检验、社区审核的标准和实施在降低安全风险方面大有帮助。评估协议集成的风险有助于您开发安全检查，以防止对外部组件的攻击，例如预言机操作。

　　怎么做：导入经过安全审计的可信合约库和接口；毕竟，crypto 和 web3 的重点是开源使用、重用和可组合性！请务必在代码库中记录合约依赖项及其版本，并尽可能减少代码占用空间；例如，导入大型项目的特定子模块而不是所有内容。了解风险敞口，以便监控供应链攻击。使用官方接口调用外部协议，并确保考虑到潜在的集成风险。监控重复使用的合同的更新和安全披露。

　　测试和审查阶段的安全注意事项 (C)

　　#4：考虑测试和文档

　　内容：创建清晰、全面的代码文档，并设置快速、全面、易于运行的测试套件。在可能的情况下，在测试网上或通过主网模拟设置测试环境以进行更深入的实验。

　　原因：为代码库的预期行为编写假设，有助于确保威胁模型中的风险得到解决，并且帮助用户和外部审计人员了解开发团队的意图。为代码创建测试套件，有助于证明或反驳开发假设，并鼓励对威胁模型进行更深入的思考。该测试套件应包括在极端市场情景下检查项目代币经济学的机制设计测试，以及单元测试和集成测试。

　　怎么做：实施已知的测试框架和安全检查器——例如Hardhat、 Mythril、 Slither、 Truffle等。提供不同的测试技术，例如模糊测试、属性检查，甚至形式验证。广泛记录代码，使用NatSpec注释来指定预期的副作用、参数和返回值。使用文档生成工具和高级设计说明生成实时文档。

　　#5：考虑内部审查和安全审计

　　内容：花时间通过内部和外部代码审查来发现错误。

　　原因：从功能开发转移到安全问题上，让开发人员有时间发现潜在的晦涩问题。外部审计在这方面可能特别有用，因为它们可以带来开发团队没有的外部观点和专业知识。

　　怎么做：在项目开发的适当时刻，安排功能冻结，以便有时间进行内部审查，然后进行外部审计。这应该在任何实时部署和升级之前进行。查看来自ConsenSys、Nascent、OpenZeppelin和Trail of Bits 的指南，这些指南为开发人员提供了考虑事项清单，包括供任何准备审计的人使用的时间安排。还要确保查看部署事务以确保它们使用经过审核的代码版本并具有适当的参数，尤其是在升级软件时。

　　部署 (D) 和维护 (E) 阶段的安全注意事项

　　#6：考虑激励白帽社区参与

　　内容：创建鼓励社区参与开源代码库安全改进的计划。一种方法是创建错误赏金。另一种方法是鼓励社区开发协议监控检测机器人。

　　原因：开发团队可以从更广泛的知识和经验中受益匪浅。（同样，开源也有助于加密。）值得注意的是，此类程序可以帮助激发对项目的热情，从本质上将社区和白帽黑客变成福音传道者。它们还可以通过为黑客提供成为防御者的途径来帮助将潜在的攻击者转变为安全资产。

　　怎么做：使用漏洞赏金平台（例如Code4rena、HackenProof、 Immunefi或Secureum）为赏金系统提供基于严重程度的奖励，以激励熟练的黑客安全地披露漏洞。[完全披露，这篇文章的一些合著者为Forta工作，该网络有一个为高质量安全监控机器人的分散创建提供标记化激励结构的网络。]开发团队可以鼓励他们的协议社区利用传统和 web3-native 方法来激励漏洞赏金，并让参与者通过增强安全性来潜在地获利，从而为所有人带来双赢。

　　#7：考虑实时监控

　　内容：实施监控智能合约和关键运营组件（如预言机和网桥）的系统，并根据已知威胁模型向开发团队和社区报告可疑活动。

　　原因：早期发现问题使团队能够快速响应漏洞利用和错误，从而可能阻止或减轻任何损害。这似乎很明显，但在规划中可能会被忽略。

　　怎么做：使用监控平台或分布式节点运行实时监控智能合约事件的机器人。根据需要为开发团队和更广泛的社区实施仪表板和警报通知。

　　#8：考虑事件和应急响应操作

　　内容：利用能够在出现任何安全问题时立即做出响应的工具和流程。

　　原因：即使有最好的部署前保护措施，智能合约和关键组件（例如预言机和网桥）仍然可能存在实时问题。拥有专门的人员、清晰的流程和适当的自动化确保可以快速调查并尽快解决事件。

　　怎么做：通过计划如何响应事件或紧急情况以及最大程度地自动化响应能力，为最坏的情况做准备。这包括为有能力的人员分配调查和响应责任，这些人员可以通过分布式安全邮件列表、代码存储库中的说明或智能合约注册表公开联系有关安全问题的人员。根据协议的威胁模型，开发一套流程，其中可能包括情景演练和采取紧急行动的预期响应时间。考虑将自动化集成到事件响应中：例如，工具可以接收来自 Forta 机器人的事件并对其采取行动。

　　***

　　安全考虑应该是成功开发的一个组成部分——不要做事后诸葛亮。

　　尽管该框架为那些构建 web3 协议和应用程序的人群在整个开发过程中提高安全性提供了一些快速指南，但没有简短的概述可以提供对智能合约安全性各个方面的详尽讨论。缺乏内部安全专业知识的团队应该联系合格的 web3 安全专家，他们可以帮助开发人员将上述一般指导应用于他们的具体开发情况。但最重要的是，请记住，安全绝不仅仅是在简单的清单中打勾；它始终是一套永无止境、持续不断的通过实践获得真知灼见的过程。我们仍处于建立这些最佳实践的开始阶段，因此，现在是为所有级别的开发人员共享它们的时候了。

　　作者背景

　　a16z