智能合约对区块链初创公司构成安全威胁

根据官方网站 ,以太坊智能合约“完全按照程序执行,没有停机,审查,欺诈或第三方干扰的可能性”。 今天,在研究了智能合约用户在实践中面临的一些问题之后,我将尝试找出所有事实是否真的如此乐观。


在文章的最后,我总结了我的想法,并提供了编写安全智能合约的简要指南。


图片


备注


  1. 本文仅关注以太坊智能合约。 社区已默认将智能合约与以太坊智能合约进行标识。 同时,第一个更多的是概念,第二个是实现,可以讨论该实现如何满足该概念的问题(以及原则上智能合约的概念以及其他可能的实现)。 这个主题很复杂,被低估并且很有趣,但这不是本文的主题,因此我将推荐对Nick Szabo作品感兴趣的人。 因此,在更远的地方,我所说的“智能合约”实际上是指“以太坊智能合约”。
  2. 本文将仅关注最流行的智能合约Solidity的语言,而对于以太坊用户而言,实际上是目前唯一的语言。

智能合约安全性问题


这将与智能合约的开发者最终面临的问题有关,而不是与平台本身的安全性有关(尽管有一些有关)。 我们通常将这些问题分为以下几种类型:


  1. 智能合约代码中的问题;
  2. 开发过程中的问题;
  3. 语言问题;
  4. 概念上的问题。

1.智能合约代码中的问题


这里的智能合约代码中的问题,是指通过编辑.sol文件可以解决的问题。 特别是:


  • 已知的易受攻击的构造(例如重新进入 )。
    生命示例 :重新进入,或更广泛地说,是违反了Checks-Effects-Interactions模式-甚至在新合同中仍然发现了广为人知(并且以前被利用过的 )的漏洞。
  • 作者的易受攻击的构造(尤其是代码逻辑中的错误)。
    生活示例 :实际上不是MultiSig的MultiSig钱包。 为了签署交易并转移资金,您需要钱包所有者的签名数量等于required 。 同时,为了更改required (例如,一个人,以便进一步自己签署交易),仅所有者之一的签名就足够了:

图片
图片


  • 糟糕的架构。
    生活示例 :尝试在单个合同中实现令牌,钱包和密钥库。 合同变得过于复杂,代码难以维护,审核,修改。 结果,安全性也受到损害。
  • 低质量代码。
    寿命示例 :具有不同缩进,任意换行符和空格的合同。 该代码很难阅读,这意味着安全性再次受到损害。 尽管事实上已经有短绒SoliumSolhit )。

图片
图片


代码中的问题直接导致攻击和资金损失。 好消息是,可以在审核过程中识别并解决代码问题。 重要的是要了解它们的来源,以便将来避免它们。 因此,我们继续下一段。


2.开发过程中的问题


代码中的问题主要是由错误构建的开发过程引起的。 看起来,软件开发是一项经过长期研究并拥有公认最佳实践的业务。 然而,智能合约领域的年轻人,不成比例的巨额资金和炒作导致人们事实上出于某种原因而忽视了标准程序,这通常会导致严重的问题。 最典型的是,值得一提:


  • TK:大多数以太坊智能合约都是在没有技术任务的情况下编写的。 为此会导致不必要的解释。
  • 时间:平均来说,用于开发的时间很少,大约一个月。 我的实践中有一个极端的例子:客户要求开发人员在ICO前三天写一份智能合约。
  • 开发人员级别:很多人进入该领域,包括完全没有编程背景的人。
  • 了解生态系统:即使有背景,开发人员通常也不会完全沉浸在该主题中,也不了解智能合约的细节。
  • 开发成本:但是,编写智能合约的人很少。 写得好的人更少了。 因此,开发成本过高。

3.语言上的问题


将tar添加到Solidity本身的语言中。 最初,它的创建更多是为了使其可以被大量人员快速掌握,而不是为了方便在其上编写安全的智能合约。 以下是一些会干扰安全性的功能:


  • using forcall / delegate call多重继承-所有这些都不从当前源启动代码,这意味着它降低了可读性,并因此降低了代码安全性。
  • Checks-Effects-Interactions模式-如果违反CEI的构造不安全,那么为什么不仅仅在语言级别上禁止它们(以及许多其他构造)?
  • 通过调用另一个合约,您可能突然陷入其后备功能,从而产生意想不到的后果。

显然,以太坊项目正在开发中,不可能事先考虑所有因素。 但是最后,开发人员被迫记住许多功能,并使用拐杖使他们的智能合约变得安全。


4.概念中的问题


但是,最严重的问题甚至更深层次-许多人还不够了解为什么需要智能合约,它们可以做什么,不能做什么以及如何工作。 在最坏的情况下,这导致以下事实:智能合约:


  1. 不聪明:


    • 写得不好-做的是写的,但不是写的。
    • 它与后端和/或前端紧密相连-此代码不再是智能合约,它以通常的方式执行,并且其实现完全由服务器管理员控制。

  2. 不是合约:


    • 它没有记录当事方的义务-例如,ICO出售其代币以太坊,但代币实质上是糖果包装,因为 不要对发布它们的人施加任何限制或义务。
    • 允许单方面更改-事实证明,当事方之一可以在合同签订后更改合同。

      生命示例 :合同的所有者可以任意更改代币销售的资本化,比率和持续时间:

      图片

  3. 不需要:


    • 添加智能合约并不是因为它在技术上是必要的,而是在于试图弄清楚如何使用智能合约并大肆宣传。
    • 我们试图弄清楚如何将智能合约与现有产品联系在一起。

      图片


智能合约对区块链初创公司构成安全威胁


结果如何? 他们希望它成为一种时尚,安全的区块链,但是我们得到了昂贵的不受支持的代码,这些代码威胁了安全性,根本不需要。 我们希望智能合约“完全按程序执行,不会出现停机,审查,欺诈或第三方干预的可能性”,最后,它们实际上是按编写的方式执行的-仅在存在漏洞的情况下编写。 对我们而言,剩下的就是挥舞笔头。 好吧,或者如果以太坊的创建者由于该漏洞而蒙受了损失,或者做出艰难的决定 (从而实际上抹黑了最初的想法本身)。


图片


如何编写安全的智能合约


实际上,当然,一切还不错。 我只是夸大其词,以引起我对某些重要观点的注意。 总的来说,该领​​域正在发展,人们正在学习,包括安全。


如果读者决定写一份智能合约,我建议:


  • 了解为什么需要智能合约(以及是否需要);
  • 从客户那里接收或写TK;
  • 计算时间;
  • 使用开发和测试工具( 松露RemixSmartCheckSolhintSolium linter );
  • 编写测试;
  • 进行几次独立的审核和赏金;
  • 监视项目其余部分(网站,Twitter等)的安全性。

遵循这些简单的建议,您可以避免上面描述的大多数问题(但是,通过硬分叉,还是不能解决)。


该文章是与Eugene Marchenko( eMarchenko )共同创建的。

Source: https://habr.com/ru/post/zh-CN412559/


All Articles