知道创宇周启鹏：未来智能合约涉及行业会更广、逻辑复杂度更高、非开发者也能轻松编写

在分享中，周启鹏较为系统的介绍了智能合约的产生及应用，安全事件以及安全风险分析，并提出随着智能合约在社会化大规模应用中应对智能合约安全的策略。

周启鹏表示，未来智能合约社会化应用的难点主要有三个：一是随着“区块链+”浪潮的到来，涉及的行业将越来越广；二是行业应用所需的合约复杂度越来越高；三是未来的智能合约，除开发者外非开发者也可以编写，这将给智能合约的安全带来很大挑战。 

对此，知道创宇“404”安全实验室研发了一套智能合约验证系统“昊天塔”。该系统和公链、联盟链等团队深入合作，以提供应用层的安全防护能力，支撑智能合约数量和逻辑复杂度不断增加的应用场景。

以下为演讲全文，enjoy：

我今天的演讲分为四个部分，第一个是探讨一下智能合约发生了哪些引发我们思考的安全事件，为什么我们要开始讨论智能合约的安全。第二部分会对智能合约的安全风险做一个简单总结，把这个问题向大家做一个描述。第三部分是区块链+应用的情况下智能合约安全又是怎样的。最后一个是未来的智能合约要如何做，我们也提出了自己的想法和建议。

首先是看智能合约安全的现状。

在此之前我想先解释一个名词——智能合约。智能合约是区块链的核心技术之一。之所以称作智能合约，是因为智能合约在区块链当中是一段能够自动化执行的程序代码，嵌在区块链的顶层架构上。所以我们可以简单的理解为，如果把区块链技术比作现在大家都用智能手机操作系统，或者说区块链底层的技术可以认为是一个网络分布式的操作系统，智能合约就可以理解为是这个网络分布式操作系统中所运行的程序。所以智能合约是一个以信息化的方式传播，验证和执行合同的协议。

智能合约基于区块链去中心化的特性，允许在没有第三方的情况下进行可信的交易，同时这些交易是可以追溯、不可逆的，这些因素促进了智能合约技术的发展。智能合约的最终目的是提供比原来纸质合同，或者说合同文本更优的安全方案，同时减少双方毁约和因此产生的纠纷，可大大提高交易的效率。

要追溯历史的话，这个概念是 1994 年的时候由科学家尼克·萨博提出来的。当时互联网还是一个雏形，只是提出智能合约这样一个设想。2008 年区块链 1.0 版本诞生，提供一个天然可信环境，但是这个环境缺失一些东西，没有能够对外提供更多可以被第三方执行和调用的接口，所以可以说区块链1.0只支持一些简单的指令，到 2014 年区块链 2.0 版本发布，这个时候就在具备 区块链1.0 可信环境属性同时，开始支持图灵完备，设计了可供开发者调用和执行的接口，提供了与应用场景解决的可能性。

接下来我们可以回顾下智能合约真正被运行起来后，产生的对整个历史进程影响比较大的安全事件，这就是发生在 2016 年，以太坊中的 DAO 事件。

2016年6月15日，攻击合约被创立。6月17日，攻击开始，Vitalik Buterin 得知攻击消息后立刻通知了中国社区。theDAO 监护人提议社区发送垃圾交易阻塞以太坊网络，以减缓 DAO 资产被转移的速度。随后 V 神在官方博客发布[紧急状态更新：关于 DAO 的漏洞]公告。解释了被攻击的一些细节以及提出软分叉解决方案，不会有回滚。不会有交易和区块被撤销。软分叉将从块高度 1760000 开始把任何与 the DAO 和 child DAO 相关的交易认做无效交易，以此阻止攻击者在 27天之后提走被盗的资产。这之后会有一次硬分叉将资产找回。

我们看一下合约的本身是怎么被攻击的。首先左边是 DAO智能合约 的代码片断，这里边写了一个withdraw函数，右边是黑客攻击合约的代码片段，这个攻击合约在执行的时候，可以通过外部直接调用的方式调用DAO智能合约的withdraw函数，一层一层不断执行不断递归调用，使得黑客可以通过合约外部调用方式用攻击合约把原合约很多数字资产做了转移，由此引发 DAO 事件。最大的影响莫过于对以太坊这条公链，因为产生了一个硬分叉。

接下来分析一些智能合约的安全风险。

先跟大家交流一下智能合约代码方面的特性，我总结了四类：

• 第一个是账户的设计，智能合约一共设计了两种账户，一种是外部账户，由公私钥体系做控制，另一种叫做合约账户，是由代码本身控制。

• 第二个是在区块链 2.0 上还有个叫 gas 的东西。合约代码越复杂的时候，我在执行这个合约过程中所需要花费的 gas 越多。这就产生一个问题，如果调用者提供的 gas 不足，这个合约里面已经执行的代码是会被回滚的，这个合约调用者也可以设计自己本身的 gasPrice，矿工优先处置 gasPrice 较高的交易，所以 gasPrice 如果设计的比较低，或者设计的太高了等等这样一些方式，都是不合理的。

• 接下来是函数，一共涉及几种函数，第一个是 fallback 函数（编者注：当我们调用某个智能合约时，如果指定的函数找不到，或者根本就没指定调用哪个函数时，fallback 函数就会被调用），同时设计 transfer、send、call.value 等等这样接收资金的函数，同时还有一个 selfdestruct 这样一个函数去做合约。

• 最后是函数调用方面，类似于传统的调用方式。

接着我们来看智能合约语言的特性。

这个语言当中本身涉及的函数默认可见性是 public，只要写出一个合约，函数如果没有设计权限，对于用户来说都是公开的 public 。

第二个里面涉及大量数值运算内容。

第三个是设计三种异常处理方式，require、assert 或者 revert 这三种。它们各有区别，require 一般是写在函数前面，用来检查输入的变量和合作状态变量是否满足条件，如果满足条件的话才会去执行。assert 这个函数，从开发者角度会写在函数的尾部，用来检查函数的内部错误，如果出现错误就会强制停止。revert 函数更特殊一些，遇到一些无效代码，会回滚之前所有的状态。这三个函数还有一个区别，revert 可以返回，合约如果没有执行的话，这个 gas 是不需要付的。

刚才讲到了，合约本身是有一个外部账户和合约账户的区分，所以智能合约风险第一个也是我们认为比较常见的问题，叫做访问控制的问题。

访问控制函数应该设定成只有特定的用户才能够调用这样一个情况。我是合约的用户者才能够调用一些挖矿函数，但是我们在代码过程当中能够看到，黑客这边可以通过写恶意合约或者写攻击合约来提升自己权限，使人人都可以成为一个合约拥有者，这样无形当中把整个合约内容函数，或者叫做合约账户函数暴露在外面，就产生后面一系列问题。

下面举一个 Owner 构造函数的错误例子。

构造函数在部署合约的时候才调用，并且本身不上链。普通函数则是能够被任意调用，同时代码也写在区块链当中。大家应该理解一个情况，数据也好，合约也好，一旦上链，都是被允许查看的，所以普通函数写在链上之后可以被任意的团队，可以被恶意黑客或者被白帽子参考和研究。

下面做一个简单的代码梳理，这边写了一个构造函数Owner，下面这个函数定义的function中，大家能够看到这个 Owner函数的大小写变了，由于大小写原因书写错误，导致了这样一个构造函数变成了一个普通的公有函数。

接下来我们整理了一下智能合约中我们认为目前出现安全风险比较大的四个原因。

首先第一个是智能合约在整个区块链的架构当中，属于中间协议层的最上层，在上面是我们所谓的分布式应用，所以出现的位置是位于上层应用，上层应用本身出现安全问题的概率，按照以往基于 windows 操作系统的应用出现问题概率相对会高一些。

第二个是语言的发展时间很短，语言本身不够完善。到目前为止，这个语言版本大概在 0.4.24，一般能够公开发布的开发语言版本可都是在 V1.0 或者 V1.1 等等，所以说从版本本身发展来说还需要一个很长阶段。

第三个问题属于国内项目方这边，目前经验不是很充足，语言本身发展时间又很短，基于solidity这个语言产生的示例或范示标准文件比较少，包括官方发布的也存在问题，所以导致开发人员经验更少，又不熟悉语言特性，会拿传统开发互联网的软件开发区块链，缺乏安全经验导致问题出现。

最后就是目前并没有一个智能合约代码审核的完善标准，这个标准没有的话，实际上其实还有很多事情大家都是不清楚的，就会产生更多的奇奇怪怪的问题。

接下来一个是展示一下开源项目 DAPS 统计以及公布的分布式应用的安全问题。有递归调用漏洞，访问控制，整数溢出，未检查底层调用，错误随机等等这样十个类。

最后一个原因是智能合约本身也是顶层应用，包括本身的安全问题都还有很多未知未觉的领域存在，需要更多项目方，更多的白帽子，更多安全厂商一起努力，不断使技术，还有上层应用更加健壮，为更多社会化应用服务。

接下来想把我们智能合约未来应用的场景做一个大的猜想，或者做一个预期。首先现在结合我们社会化的应用来说，区块链也好，智能合约也好，其实已经和我们生活当中一部分事情结合在一起了。

首先第一个金融属性，像之前蚂蚁金服在香港的新闻，利用区块链技术做跨境汇款，包括现在保险、证券、股权登记这样一些原有金融领域的应用，现在已经慢慢出现雏形了。第二个物联网应用，现在基于区块链的物联网、汽车租赁应用也逐渐出现。第三个供应链，上午百度介绍的时候，针对百度百科的文件编辑溯源也在落地建设过程当中。能源领域点对点的便利共享的领域，包括公共服务领域，针对我们文化、教育、产权、医疗等等这样一些领域逐渐出现了。

下面做几张图的展示，首先介绍一下传统汇款和区块链汇款的差别。在传统汇款当中，境内都还好，速度很快，但是一旦涉及到境外的跨境汇款效率非常低，这里面涉及到一个问题，叫做中间银行和清算网络，作为一个中心化机构解决信任问题，导致效率会有所降低。

如果把这个场景放到区块链上，用智能合约实现的话，通过链本身的去中心化信任的机制，资产转移的就可以用智能合约实现，从资产结算任何时间结算，包括资产转移，上次蚂蚁金服那边在做的时候，从菲律宾汇款到香港大概用了几十秒时间。

第二个应用在传统供应链金融，我们已经看到国内有一些机构大胆用区块链技术尝试物品溯源，比如之前曝光的疫苗事件。虽然疫苗生产厂商作为源头无法通过区块链技术进行控制，但是疫苗整个在冷链运输，在各个监督站各个医院的数据都可以上传，防止中间有一些个人的恶意行为，导致在传播当中数据的丢失和篡改。

第三个针对传统物流，原来传统物流有很多痛点，互相不信任，之前用淘宝的时候最大的问题到底是买方先付钱还是卖方先发货，后来出现了支付宝为来解决第三方信任问题，买房把钱给中间平台。如果有区块链能够和网购支付场景结合的话，互不信任这个问题可以解决，买方可以在收到货的这一刻，订单信息就会在链上做数据提交，这个时候买方账户里面的钱就可以通过智能合约方式直接打到卖方账户上面去，包括订单被篡改风险，还有隐私信息，包括现在大家遇到快递信息泄露个人隐私，将来都可以上链的话，大家面对的都是在链上隐藏数据的信息身份。

还有针对疫苗，针对医院，针对医疗体系，从每一个药厂药品信息上链，药房售卖药片都是可以在链上确认的，患者也可以和医生做关联，甚至可以用一个 APP 知道这个人的健康信息，包括历史服药信息，在哪些医院检查，都是能够被查到的。

前面做了一些大胆的幻想，下面看一下未来智能合约会是一个什么状态。

第一个是区块链+应用，在未来可能涉及的行业特别广泛，刚才上午百度区块链的平台介绍了几个特点，第一个和版权结合，我们现在很多商用图片都会上链，包括未来可能会有数字音乐版权，数字电影版权都会上链，包括像邮政、游戏等等，和我们生活的结合越来越深，涉及的行业也越来越广。

第二个是随着行业越来越多，每个行业都有每个行业的特点，所以行业应用复杂度越来越高，现在智能合约的代码是 300 行到 500 行，将来智能合约应用，一个合约可能有几千或者上万行代码，代码逻辑越复杂，产生的逻辑漏洞，安全威胁肯定会越多。

最后一个场景是开发者现在还比较少，未来的开发者越来越多，越来越成熟，将来提供很多智能合约的应用，不仅仅是对开发者，也可能对更多普通的民众开放。我们的民众就可以像现在用 APP 一样，简单输入一些数据，输入一些数量或者输入一些价格，就可以自发产生智能合约，后面其实是公链方针对智能合约、对自己项目所起的标准，这样的人越来越多。所以他们所产生的问题越来越多，通过目前的使用方式就不现实了。

我们知道创宇404实验室也是结合之前介绍的，未来预计会有更广泛更复杂的应用，还有更多的智能合约的场景，我们设计研发了一套智能合约智能验证的系统，能够在结合人工审计情况下，更多通过自动化智能化，通过 AI 方式和很多的公链项目方一起深入的结合，通过深度结合方式，对整个链产生的智能合约标准，和未来所产生智能合约使用的应用，让他们更健康更健壮一些，减少所出现的安全漏洞，让这些智能合约能够给我们生活带来便利性的同时，减少经济上的损失。

后面这两个是我们现在目前内部版本的截图，把名字定义为叫做昊天塔，通过这样一个产品，或者这样一个系统，来为更多智能合约开发者和使用者提供安全的服务和保障。

今天介绍暂时到这里，希望后续有关心的技术方面的同学或者是项目方，如果有兴趣大家在一起多多交流，谢谢大家。