DeFi 用户应该向开发者提出的质询【澳门金威尼斯游戏】

过去几个月来，DeFi 生态经历了极大的动荡不安，数次反击之下，许多并未被利用过的缺失也被报导出来。虽然代码中无可避免不会有 bug，但还是有很多方法能减少缺失再次发生的频率，以及减少缺失带给的负面影响。

作为一个审计员，我们想协助 DeFi 用户问一些较为锐利的问题；问这些问题的目的，一方面是让开发人员严肃去考虑到系统安全性的优先级，另一方面，让用户能辨别出有问得好的协议，然后把钱投放这些协议。以下问题能协助用户理解 DeFi 研发团队对于安全性的立场，答案不一定有是非之分，而且也不是每个团队（or 独立国家开发者）都有资源全盘考虑到所有方面。但不论如何，用户有权利告诉这些信息，来要求自己不愿忍受的风险。

我们期望通过以下发问，促成先前积极开展更加多正面的辩论。1. 管理员权限大部分的主流 DeFi 协议都不存在一些中心化的机制——容许特定的 “管理员” 地址以强硬态度的手段介入协议的运营。这样做到虽然在安全性上有益处，但这意味著你必需坚信这些 “管理员” 会欺诈他们的特权；而且但凡这些管理员遭黑客攻击，他们的私钥泄漏所带给的后果不会更为相当严重。

管理员账户可以是以下几种形式：单一地址、多重亲笔签名钱包，或是由 DAO 管理的投票过程。那么，网卓新闻网，· 管理员能采行哪些措施？停止整个系统？改动账户余额？设置 代币/用户 的 白名单/黑名单 ？升级某个子系统？升级整个系统？（等同于万能...）其他权限？· 如果采行上述不道德，否有延后继续执行机制？· 如果有延迟时间，那是多长？· 多少人有管理员权限？· 采行上述不道德前，必须经过多少管理员表示同意？· 有哪些权限是由链上管理程序（即 DAO）来掌控的吗？· 我该去哪里理解建议改版协议的议案？以上某些问题的问早已可以通过 DefiWatch 追踪理解。2. 外部倚赖因为是公开发表的网络，以太坊上弥漫着不怀好意的攻击者，因此开发者无法假设本系统外的合约一定会采行什么样的不道德。但在许多 DeFi 应用于中又被迫做出这样的假设，因为服务本身就是在有数的一些合约上建构出来的。

这些问题能协助用户理解该项目在外部倚赖上不存在的风险。· 你的系统倚赖什么应验机（Oracle）？· 你的系统倚赖什么交易所？· 你用什么第三方智能合约（如，OpenZeppelin）来创建系统？· 你的系统反对哪些代币，你对这些代币（合约）的不道德模式有怎样的预期？3. 可信的的透露系统和奖励计划对于才华横溢的黑客来说，反击 DeFi 协议对他们具有强劲的金钱欲望。制订奖励计划能鼓舞大家找到并揭发漏洞，而非铁环漏洞。

对于白帽黑客来说，通过鼓舞系统揭发代码漏洞也是提升自身声誉的好方法 —— 既有益处又不违法。任何公司要运营 DeFi 协议，或是牵涉到在线托管地金钱的业务，都应当另设奖励系统。

你可以就他们的奖励计划及透露流程明确提出以下问题：· 你们的合约代码需要被所有人看见吗？· 从你们的网站和 git 代码库，需要很更容易寻找安全性的联系方式吗？· 你们的合约是不是设置奖励计划？· 哪些合约在奖励计划内？· 奖励计划明确金额是？· 你们否缴纳过奖励计划的奖金？· 对于 bug 报告，你们否曾拒绝接受缴纳过？· 从你们的网站和 git 代码库，需要很更容易地寻找奖励计划的详细信息吗？理想情况下，这些信息应当放到 “website.com/security” 页面下，而且能配上 Github 的 SECURITY.md 功能用于。4. 应急预案当面临某些安全性突发状况的时候，新的消息如潮水般黄泥来，用户持续在 Twitter、Telegram、Discord 上明确提出棘手的问题......，这时候开发者很难头脑清楚地应付突发状况。所以如果有应急预案的话，就能证明项目于是以朝着安全性方向发展。拒绝项目公开发表他们原始的计划有可能不过于现实，但我们还是能明确提出以下基础的问题去侧面理解：· 你们否有处置脑溢血安全事件的计划庐山会议？· 你们的应急预案限于于哪些紧急情况？· 如果你们的系统是可升级的，这些升级步骤否记录在案？· 如果你们找到某个系统漏洞有可能让资金面对风险，你们否能通过应急预案先发制人，维护资金安全性？5. 审核与安全性发展审核并非万灵丹，而且审核的内容总多多少少有点区别，但对于部署任何的 DeFi 合约之前，展开审核是至关重要的一步。

下面的问题不一定有 “准确答案”，但学识渊博的社区群众们，应当能从项目的问中显现出研发团队对于安全性的立场。· 你们最近一次审核是什么时候？· 这次审核投放了多少精力（以标准开发者的一小时来做到单位）？· 哪个机构做到的审核？· 审计报告公开发表吗？· 你们系统中有任何部分是没被涵括在审核的范围内吗？· 最近一次审核之后，你们有对合约展开改版吗？如果有，改版了什么？· 你们有和哪个安全性团队展开长年合作吗？· 在拆分代码之前，开发者不会彼此做到 code review 吗（最少检查 Solidity 文件）？· 你们的合约代码中，做到过单元测试的比重是多少？· 审核过程中，你们用过其他的安全性分析工具吗？。

本文来源：98858vip威尼斯下载-www.shisu.org