最近几个月，DeFi 行业经历了一些动荡，不少攻击和未披露漏洞被曝光。

虽说 Bug 不可避免，但如果采取一些有效措施仍可减少问题发生的频率、并降低由此带来的负面影响。

作为审核员，我们希望在这方面提供一些帮助。为了让开发人员可以优先考虑安全性问题，用户做好能早点提出一些棘手问题，只有当这些问题得到满意答复之后，才能放心把钱投入到相应的协议项目里。

要想搞清楚 DeFi 项目开发团队的安全立场，本文会列出的一些有用的问题，这些问题的答案并不能简单地用「对 / 错」来衡量，因为某些团队（或独立开发人员）可能并没有足够资源来解决所有问题。事实上，用户只能根据自己所能获得到的信息来判断是否愿意承受相应的风险级别。

当然，我们希望下面这些问题能够推动 DeFi 项目朝正确的方向发展。

管理员权限

大多数知名 DeFi 协议都是以某种形式被中心化控制的，支持特定「管理员」以强有力的方式进行干预。

虽然这种方式在安全性上有些好处，但也意味着你必须信任管理员不会滥用自己的特权。另一方面，如果攻击者窃取了管理员私钥及其附带的所有特权，那么也会增加项目风险。

管理员账户通常会采用几种可能的形式，包括：对单个地址、多重签名钱包、以及由投票流程控制的去中心化自治组织（DAO）。这里要询问的安全性问题包括：

• 管理员可以采取哪些特殊措施？

• 能否暂停系统？

• 能否修改余额？

• 能否将代币 / 用户列入白名单 / 黑名单？

• 能否升级系统子集？

• 能否升级所有系统（等同于无所不能）？

• 是否具有实施其他特殊措施的能力？

• 上述行为中，哪些会有时延、哪些没有？

• 如果有时延，具体会延长多久时间？

• 有多少人具有管理员权限？

• 在执行某些操作之前，必须获得多少个管理员批准？

• 是否有任何行政行为被链上治理控制，比如 DAO？

• 对于拟议的协议更改，可以在哪里查询到最新状态？

上述某些信息已能在 DefiWatch 中进行跟踪。

外部依赖

以太坊区块链中充满对抗性参与者，一般而言，开发人员应该尽量避免对其他系统的合约行为作出任何假设。然而在许多 DeFi 应用中，这几乎是不可能的，因为服务本身就是建立在现有合约之上。

因此在涉及有关外部依赖关系风险时，下面这些问题可能会有一定帮助：

• 你的系统依赖哪些预言机？

• 你的系统依赖哪些交易所？

• 你的系统使用了哪些第三方智能合约来构建（比如 OpenZeppelin）？

• 你的系统支持哪些代币？你对这些代币的功能做了哪些假设？

负责的披露和赏金计划

对于那些高智商黑客而言，攻击 DeFi 协议能让他们获得巨大的经济收益。因此你其实可以尝试制定一个赏金计划，为提供系统漏洞的人提供一些资金奖励，这样就能减少漏洞被黑客利用。实际上，通过赏金计划举报漏洞对黑客声誉也有好处，因为这样他们就不必通过非法手段来获利了。

出于对客户资金保护的目的，任何一家运行 DeFi 协议的公司都应该考虑黑客赏金计划，对此我们可以针对相关计划和披露流程提出以下一些问题：

• 你的合约源代码是否能公开获得？

• 能否在你的网站和 GitHub 代码库上快速找到安全联系信息？

• 你的合约上有赏金计划吗？

• 赏金计划包含了哪些合约？

• 赏金额度范围有多少？

• 你此前是否支付过赏金？

• 你此前是否拒绝为报告 Bug 的人支付赏金？

• 能否在你的网站和 GitHub 代码库上快速找到赏金计划的细节内容？

理想情况下，这些信息都可以在项目官方网站的安全网页 / 栏目中找到，或是利用 GitHub 的 SECURITY.md 功能也能找到相关信息。

事件响应规划

在遭遇安全事件时，随着各种新信息不断涌入，开发人员通常很难理清思路，因为会有大量用户在 Twitter、Telegram、Discard 上提出各种各样的棘手问题……

所以，你需要制定计划来确保安全事件朝着健康的方向发展。虽然对于 DeFi 项目团队而言公开完整计划可能没有太大意义，但他们最好能够回答以下几个问题：

• 你是否有书面计划概述如何处理安全事件？

• 你的计划考虑了哪些方案？

• 如果你的系统是可升级的，那么所有执行操作步骤是否被记录在案？

• 如果发现了导致资金面临风险的漏洞，你是否会先发制人处理问题以保护资金安全？

审计与安全发展

审计不是万灵药，也不是所有审计都能做到公平对待。但是对于 DeFi 合约而言，正式部署之前进行安全审计仍是至关重要的一步。

虽然不是每个问题都能有「正确答案」，但项目开发团队给予的反馈和回复至少能让社区成员可以了解他们的安全立场，下面这几个问题值得关注：

• 你的项目上一次审计是在什么时候？

• 审计工作需要多少工作量（以人 / 小时为单位）？

• 哪家公司对你进行的审计？

• 审计报告是公开的吗？

• 你的系统有哪些部分被排除在审计之外了？

• 自从上次审计以来，你的合约是否升级？如果升级了，发生了哪些变化？

• 你是否与安全公司保持长期关系？

• 在代码合并之前，开发人员是否会在 GitHub 里检查彼此的 Pull Request （至少在 Solidity 文件里）？

• 单元测试会涵盖合约代码的哪些部分？

• 流程中是否使用过任何其他安全分析工具？

对于有兴趣跟进这些问题的 DeFi 用户，另一个值得关注的项目是 ConsenSys 的 DeFi Score，该项目正在执行一项艰巨的任务，即评估各个主要 DeFi 项目上的审计质量和其他安全流程质量。

最后，谢谢 Emilio 和 Ernesto （Telegram 上的 @eboado），他们都是 Aave 开发人员，以及 DeFi Score 的 Jack 为本文早期草稿提供的反馈。

来源链接：diligence.consensys.net