提前防范：外盘分析比特币丨Defi审计防漏洞

Defi项目进行审计可避免漏洞。近几个月，DeFi行业经历了一些动荡，不少攻击和未披露漏洞被曝光。虽说Bug不可避免，但如果采取一些有效措施仍可减少问题发生的频率，并降低由此带来的负面影响。

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

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

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

管理员权限 大多数知名DeFi协议都是以某种形式被中心化控制的，支持特定「管理员」以强有力的方式进行干预。虽然这种方式在安全性上有些好处，但也意味着你必须信任管理员不会滥用自己的特权。另一方面，如果攻击者窃取了管理员私钥及其附带的所有特权，那么也会增加项目风险。

管理员账户通常会采用几种可能的形式，包括：对单个地址、多重签名钱包、以及由投票流程控制的去中心化自治组织（DAO）。这里要询问的安全性问题包括：管理员可以采取哪些特殊措施？能否暂停系统？能否修改余额？能否将代币/用户列入白名单/黑名单？能否升级系统子集？能否升级所有系统（等同于无所不能）？是否具有实施其他特殊措施的能力？上述行为中，哪些会有时延、哪些没有？如果有时延，具体会延长多久时间？有多少人具有管理员权限？在执行某些操作之前，必须获得多少个管理员批准？是否有任何行政行为被链上治理控制，比如DAO？对于拟议的协议更改，可以在哪里查询到最新状态？

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

因此在涉及有关外部依赖关系风险时，下面这些问题可能会有一定帮助：你的系统依赖哪些预言机？你的系统依赖哪些交易所？你的系统使用了哪些第三方智能合约来构建（比如OpenZeppelin）？你的系统支持哪些代币？你对这些代币的功能做了哪些假设？

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

出于对客户资金保护的目的，任何一家运行DeFi协议的公司都应该考虑黑客赏金计划，对此我们可以针对相关计划和披露流程提出以下一些问题：你的合约源代码是否能公开获得？能否在你的网站和GitHub代码库上快速找到安全联系信息？你的合约上有赏金计划吗？赏金计划包含了哪些合约？赏金额度范围有多少？你此前是否支付过赏金？你此前是否拒绝为报告Bug的人支付赏金？能否在你的网站和GitHub代码库上快速找到赏金计划的细节内容？理想情况下，这些信息都可以在项目官方网站的安全网页/栏目中找到，或是利用GitHub的SECURITY.md功能也能找到相关信息。

事件响应规划 在遭遇安全事件时，随着各种新信息不断涌入，开发人员通常很难理清思路，因为会有大量用户在Twitter、Telegram、Discard上提出各种各样的棘手问题。所以，你需要制定计划来确保安全事件朝着健康的方向发展。虽然对于DeFi项目团队而言公开完整计划可能没有太大意义，但他们最好能够回答以下几个问题：你是否有书面计划概述如何处理安全事件？你的计划考虑了哪些方案？如果你的系统是可升级的，那么所有执行操作步骤是否被记录在案？如果发现了导致资金面临

热点：分析比特币 比特币 特币 项目