区块广播:

区块链研究实验室-最全的以太坊智能合约编码安全技巧

fulipan船员发布在 技术文档
 1234  0

智能合约代码测试编写

编写测试需要做很多工作,但可以避免回归问题。 当先前正确的组件根据最近的更改而中断时,会出现回归错误。

容错和自动bug赏金

感谢Peter Borah对这两个想法的启发。 代码审查和安全审核不足以确保安全。 我们的代码需要为最坏的情况做好准备。 如果我们的智能合约存在漏洞,应该有一种方法可以安全恢复。 不仅如此,我们应该尽早找到这些漏洞。 这就是我们的合同中内置的自动错误奖励可以提供帮助的地方。

让我们来看看这个假设令牌合约的自动错误赏金的简单实现:
4823.png
和以前一样,我们使用PullPayment来确保我们的付款安全。 该Bounty合同允许研究人员创建我们想要审计的令牌合同的副本。 任何人都可以通过向Bounty合同的地址发送交易来为bug赏金做出贡献。 如果任何研究人员设法破坏他的令牌合同副本,做一些不变的中断(例如,在这种情况下,使令牌的总供应量与令牌的余额不同),他将获得赏金奖励。 一旦申请赏金,合同将不再接受任何资金(无名职能被称为合同的后备功能,并且每次合同直接汇款时执行)。

至于容错,我们需要修改我们的原始合同以增加额外的安全机制。 一个简单的想法是允许合同的策展人冻结合同作为紧急机制。 让我们看看通过继承实现此行为的方法:

5152.png
Stoppable允许指定可以停止合同的策展人地址。 “停止合同”是什么意思? 这是由继承自Stoppable的子契约定义的,使用函数修饰符stopInEmergency和onlyInEmergency。 我们来看一个例子:
5402.png
现在可以由策展人停止出价,该策展人在创建合同时定义。 当StoppableBid处于正常模式时,只能调用bid函数。 如果发生奇怪的事情并且合同处于不一致状态,策展人可以介入并激活紧急状态。 这使得出价函数不可调,并允许函数撤销工作。

在这种情况下,紧急模式只允许策展人销毁合同并收回资金,但在实际情况下,恢复逻辑可能更复杂(例如将资金返还给其所有者);

限制存入的资金数额

保护我们的智能合约免受攻击的另一种方法是限制其范围。 攻击者最有可能瞄准管理着数百万美元的高调合同。 并非所有智能合约都需要拥有如此高的股份。 特别是如果我们进行实验。 在这种情况下,限制我们的合同接受的资金数额可能是有用的。 这就像对合同地址余额的硬性限制一样简单。

这是一个如何执行此操作的简化示例:
5657.png
短期后备功能将拒绝任何直接支付合同。 存款功能将首先检查合约的余额是否超出期望的限额,或抛出例外。 更有趣的事情,如动态或托管限制也很容易实现。

编写简单和模块化代码

安全性来自我们的意图与我们的代码实际允许的内容之间的匹配。 这很难验证,特别是如果代码庞大而且混乱。 这就是编写简单和模块化代码的重要性。

这意味着,函数应该尽可能短,代码依赖性应该减少到最小,文件应该尽可能小,将独立逻辑分成模块,每个模块都有一个单一的责任。

命名也是在编码时表达我们意图的最佳方式之一。 仔细考虑您选择的名称,使代码尽可能清晰。

最大的问题是它太长而且复杂。尽量保持您的功能更短,比如最多30或40行代码。理想情况下,您应该能够在不到一分钟的时间内阅读功能并了解他们的工作。另一个问题是第685行中事件转移的命名错误。该名称与只有1个字符的名为transfer的函数不同!这给每个人带来了混乱。通常,建议的事件命名是它们应该以“Log”开头。在这种情况下,更好的名称是LogTransfer。

请记住,尽可能简化,模块化和命名合同。这将极大地方便其他人和您自己审核您的代码。

不要从头开始编写所有代码

最后,正如古老的谚语所写:“不要滚动你自己的加密”。我认为它也适用于智能合约代码。您正在处理资金,您的代码和数据是公开的,并且您正在一个新的实验平台上运行。赌注很高,到处乱搞的可能性很大。

这些做法有助于保护我们的智能合约但最终,我们应该创建更好的开发人员工具来构建智能合约。

回顾一下,本文中描述的安全模式是:

尽可能早地暴露bug;
赞成拉动推付款;
制定您的功能代码:条件,操作,交互;
注意平台限制;
编写智能合约测试;
容错和自动bug赏金;
限制存入的资金数额;
编写简单和模块化代码;
不要从头开始编写所有代码;
本文转载公众号:区块链研究实验室

本主题由 等一轮残月 于 2019-02-14 13:24:41 删除回复
  • 正序
  • 最新
帖子暂无回复,回帖抢沙发
登录 账号发表你的看法,还没有账号?立即免费 注册