1004人阅读
以太坊（3）
本文主要总结以太坊智能合约的安全漏洞。新加坡国立大学的Loi Luu提出了现在的智能合约存在的几种安全漏洞。然而，由于智能合约目前还只是初级阶段，相信各种安全问题会不断的发现。
智能合约中的安全漏洞
交易顺序依赖合约
交易顺序依赖就是智能合约的执行随着当前交易处理的顺序不同而产生差异。例如，有两个交易T[i]和T[j]，两个区块链状态S[1]和S[2]，并且S[1]状态处理完交易T[j]后才能转化为状态S[2]。那么，如果矿工先处理交易T[i]，交易T[i]调用的就是S[1]状态下的智能合约；如果矿工先处理交易T[j]再处理交易T[i]，那么由于先执行的是T[j]，合约状态就转化为S[2]，最终交易T[i]执行的就是状态S[2]时的智能合约。
攻击方法举例：
攻击者提交一个有奖竞猜合约，让用户找出这个问题的解，并允诺给予丰厚的奖励。攻击者提交完合约后就持续监听网络，如果有人提交了答案的解，此时提交答案的交易还未确认，那么攻击者就马上发起一个交易降低奖金的数额使之无限接近0。当矿工处理这两个交易时，当前交易池就有两个待确认交易：一个交易是提交答案，一个交易是更改奖金数额。如果矿工先处理的是敌手更改奖金的交易，而敌手可以通过增加交易费用让矿工先处理自己的交易，那么等到矿工处理提交答案的交易时，答案提交者所获得的奖励将变得极低，敌手就能几乎免费的获得正确答案。
时间戳依赖合约
矿工处理一个新的区块时，如果新的区块的时间戳大于上一个区块，并且时间戳之差小于900秒，那么这个新区块的时间戳就是合法的。这是以太坊协议所规定的。时间戳依赖顾名思义就是指智能合约的执行依赖当前区块的时间戳，随着时间戳的不同，合约的执行结果也有差别。
攻击方法举例：
如果有一个抽奖合约，要求由当前的时间戳和其它可提前获知的变量计算出一个“幸运数”，与“幸运数”相同的编码的参与者将获得奖品。那么矿工在挖矿过程中可以提前尝试不同的时间戳来计算好这个“幸运数”，从而将奖品送给自己想给的获奖者。
误操作异常
在以太坊中，一个合约调用另一个合约可以通过send指令或直接调用另一个合约的函数。然而在调用过程中可能会出现错误，调用的合约就会回退到之前的状态。那么这个异常就可能无法很好地被调用者获知，这取决于调用方式。例如，通过send指令调用的合约应该通过检查返回值来验证合约是否被正确执行。
攻击方法举例：
有个名叫的智能合约：用户可以通过一定数量的以太币成为“以太币国王”，支付的数额由现任国王决定。很显然，当前国王可以通过买卖国王获得利润。当一个用户声称为国王后，合约就发送赔偿金给现任国王，并指定这个用户为新的国王。然而，这个合约并没有检查支付赔偿金的交易的结果。 这样一旦合约在执行过程中产生了异常，现任国王就有可能同时失去王座和赔偿金。
可能的攻击方式就是敌手故意超出调用栈的大小限制。以太坊虚拟机规定调用栈的深度为1024。敌手在攻击之前，首先调用自身1023次，然后发送交易给KoET合约，这样就造成了合约的调用栈超出了限制，从而出现了错误。合约出错后，因为这个合约没有检查合约的返回值，那么如果合约在发送赔偿金给现任国王的过程中出现了异常，那么现任国王极有可能失去王座和赔偿金。
可重入攻击
在以太坊中，当一个合约调用另一个合约的时候，当前的操作就要等到调用结束之后才会继续。这时，如果被调用者需要使用调用者当前所处的状态，那么这就产生了问题。
著名的DAO攻击事件就是因为这个漏洞而发生的。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：19986次
排名：千里之外
原创：19篇
(3)(1)(2)(2)(10)(7)(1)直播单页：
当前位置： > > 为什么很多智能合约应用案例根本不可能实现
为什么很多智能合约应用案例根本不可能实现
&nbsp&nbsp
时间： 23:58
来源：汇讯通
Greenspan是Coin
iences的创始人兼CEO，该公司是区块链私链平台MultiChain的支持者。
Greenspan在本文章讨论了区块链的智能合约，以及人们过高的期望对该技术应用的负面影响。
作为知名区块链平台的开发者，常常有人问我MultiChain计划中是否也有以太坊那样的智能合约。我的回答一直都是“没有，或者至少目前还没有”。
但是在这个充满炒作的区块链领域，智能合约成为中心地带，所以我为什么总说不呢？其实问题在于，尽管我们现在知道许可型比特币区块链的三个重要应用案例(出处、企业记录保存、小额融资)，我们还没能找到以太坊智能合约的替代品。
这并不是说人们还不知道他们希望智能合约帮他们实现什么，而是因为很多的想法根本没办法实现。聪慧的人听到“智能合约”的概念，他们的想象会信马由缰。他们想象出自主智能软件，可以带着数据环游世界。但是不幸的是，智能合约的现实其实很无趣。
智能合约就是区块链上的一个代码，被区块链上的交易激活，在其数据库中读写数据。真实的区块链也就这么点东西。
智能合约就只是在区块链上运行代码花哨的名字，与该区块链状态产生互动。那么代码是什么？它可以是Pascal、Python、PHP、Java、Fortran、C++。如果涉及数据库的话，它的存储过程是用SQL扩展语言编写的。
所有以上编程语言根本上是一样的，都是用同样的方法解决同样的问题。当然它们各自有不同的优缺点，只有疯子才会用C语言编写网站或用Ruby语言编写高清视频。但是原则上，你可以随心所欲。只是这样就要为系统的便利性、性能、甚至你的头发付出高昂的代价。
当然智能合约的问题不只是人们过高的期望，而是这些期望错误地引导人们把时间和资金浪费在根本不可能实现的想法上。
似乎大公司有足够的资源，可以拉长战线；从高管偶然遇到新技术到认识其优势和缺陷。也许我们自己的经验有助于缩短这个过程。
在过去九个月中，出现了很多新的智能合约应用案例；于是我们不断地发现这些应用根本不可能实现。
结果是，我们甚至可以总结出三个普遍存在的智能合约思维误区。当然这些误解并不是因为技术不成熟或者工具还没开发出来。
而是因为他们误解了数据库中去中心化运行的代码的基本属性。
1.联合外部服务
智能合约的第一个应用案例通常是，根据一些外部事件，改变自己的行为。例如，按照某个月降雨量向投保人支付一定金额的农业保单。
这个想象的过程是这样的：智能合约会一直等到预定的时间，从外部服务获取天气报告，然后按照获取的数据采取恰当的行动。
听起来很简单，但却不可能实现。为什么呢？因为区块链是基于共识的系统；就是说只有在每个交易和区块处理过后，每个节点达到相同状态，智能合约才会开始运行。
区块链上发生的所有事情必须是确定的，这样才不会出现分歧。两个有信誉的节点对区块链状态有歧义的时候，整个系统就变得完全没有价值了。
然后就是智能合约由链上的每个节点独立执行，因此如果智能合约从外部服务获取数据的话，这个数据获取过程是由各节点重复和独立完成的。但是因为这个数据来源于区块链外部，不能保证每个节点都收到同样的答案。
也许这些数据源收到不同节点要求时，会给出不同的应答；或者干脆暂时不可用。不管怎样，共识都被打破了，整个区块链也就崩溃了。
那么解决方法是什么呢？事实上很简单。不需要智能合约发出外部数据获取指令，而是由一个或多个受信任方（预报者）进行交易，而这些交易会将需要的数据嵌入区块链。每个节点都有该数据的相同备份，因此可以用于智能合约的计算中。
也就是说，由预报者将数据推送进区块链，而不是由智能合约将数据拉取进去。
并且如果是智能合约引起外部世界事件的情况，同样会出现类似的问题。例如，很多人都喜欢利用银行API进行资金转移的想法，但是如果每个节点都独立执行区块链代码，那么由谁去获取这个银行API呢？
也许你会说，可以选择一个节点去做这个；但是如果该节点发生故障了，无论是不是故意的，我们又该怎么办呢？那么选择全部节点去完成API获取的话，是否每个节点都可信，怎么保证API密码的安全呢？况且我们又是否愿意一个API被多次频繁使用呢？更糟糕的是，如果智能合约想要知道API获取是否成功，就会发现我们又回到过分依赖外部数据的尴尬境地中。
同样的，可以用一个简单的解决办法。智能合约不需要获取外部API，我们用受信任的服务监控区块链状态，然后做出相应的反馈。例如，一个银行可以积极地监控区块链，然后进行链上交易对应的资金转移。这样就不会对区块链共识产生威胁，因为它完全处于被动状态。
这两个解决方法可以总结出以下结论。
第一，区块链和外部世界之间的互动都需要受信任的服务。但是尽管技术上说是可行的，却可能歪曲去中心化系统的目标。
第二，这些解决方案用到的机制都是数据库读写的简单直接的例子；提供外部信息的预报者只是简单地把相关信息写进区块链中。而现实世界中反映区块链状态的服务也只是读取区块链的数据。也就是说，区块链和外部世界的互动被限制于常规的数据库操作。
后面会继续探讨这个问题。
2.执行链上支付
这个提议是我们常常听到的：用智能合约自动执行所谓“智能”的优惠券支付。就是在恰当的时候，用智能合约代码自动发起支付，避开手动程序的复杂性，保证发行者的执行。
当然，为了实现以上功能，支付必须用区块链上的资金；否则智能合约就不能保证完成支付。
要注意，这个包含债券和现金的金融账本用例中，区块链只是数据库。所以在优惠券的支付中，我们谈论的是在规定时间内自动执行的数据库运行。
尽管自动化运行在技术上是可行的，却有金融难度。如果债券的智能合约控制了用于债券支付的资金，这些支付就有了保障。同时意味着发行者或其他任何人都不能使用这些债券。但是如果这些资金不受智能合约控制，就不能保障系统进行支付。
也就是说，智能债券要么对发行者无用，要么对投资者无效。只要随意想想就知道这是很明显的结果。
从投资者角度看，债券的全部意义在于其吸引人的回报率，当然有一定的故障风险。对于发行者来说，债券目的是为有回报、同样有风险的活动进行融资，例如建造厂房。发行者没办法保证实现融资，同时投资者还会收到回报。区块链没办法解决风险和回报之间的关联，这并没什么值得惊讶的。
3.隐藏机密数据
之前我也写过了，部署区块链的最大挑战是其高透明度。
例如假如10家公司共同建立一个区块链，其中两家公司进行了双边贸易，另外八家公司马上就可以看到相关信息。尽管有很多解决问题的方法，中心化数据库的简单性和高效性是独一无二的。其中受信任的管理者完全控制信息查看渠道。
有些人认为智能合约可以解决这个问题，因为首先每个智能合约都包含一个完全自己可以控制的小型数据库。这个数据库的所有读写都由合约代码决定，使合约之间数据的直接互相读取变得不可能（这个数据和代码之间紧密的联系被称为封装，是流行的面向对象编程范式的基础）。
所以，如果一个智能合约不能获取另一个的数据，还能说解决了区块链保密性问题吗？讨论智能合约的信息隐藏还有任何意义吗？不幸的是，答案是否定的。
因为即使一个智能合约不能读取另一个的数据，相关数据还是存储在区块链的每个节点上。对每个区块链参与者来说，他们完全控制的是信息是存储在系统磁盘或存储器里的。没有任何东西可以阻挡其读取自己系统里的数据，除非他们自己选择不读取。
在智能合约中隐藏数据与在网页的HTML代码中隐藏一样安全。当然一般用户是无法看到数据的，因为它不是显示在他们浏览器窗口的。他们需要做的就是网页浏览器添加“浏览源代码”选项（浏览器都有该功能），然后相关信息就普遍可见了。
同样的，想要查看智能合约中隐藏的数据的用户需要修改其区块链软件，显示合约的完整状态，然后所有秘密性特征都会消失。
随便一个稍微像样点的程序员都可以在一个小时内完成以上操作。
智能合约的用途
智能合约既然能做这么多事，也许就会有人问它真正的目的是什么。为了回答这个问题，就需要回到区块链本身的基本原理了。总结来说，区块链使数据库可以直接安全地被无需互信的团体共享，也无需中心管理者。
区块链支持数据的脱媒，能显著减少复杂性和成本。
交易可以修改任何数据库，其中包括必须整体性成功或失败的数据库的变化。比如说金融账本中，验证A是否资金充足的交易代表A给B的付款，然后从A账户中拿出的资金会添加到B的账户中。
常规数据库中的这些交易是由单一受信任机构创建的；相反在区块链驱动的共享数据库中，任何区块链用户都可以创建交易。并且因为用户不是完全互信，所以其数据库必须包含限制交易的规范。
比如说在点对点金融账本中，每笔交易必须保存全额资金；否则参与者就可以随心所欲的分配资金。
表达这些规则的方式很多，但是目前主要有两个范本，分别是比特币和以太坊。比特币的方法可以称为“交易限制”，其评估交易的依据有：交易删除的数据库条目以及被创建的条目。
金融账本规则规定被删除条目的总资金额必须等于被创建的条目的资金额（假设现有条目的修改与条目的删除和新建条目对等）。
第二个范本是来自以太坊的智能合约，规定对合约数据的所有修改必须由代码执行（传统数据库情况下，可以将其称为存储执行过程）。要修改合约数据，区块链用户必须向代码提交请求，然后由代码决定是否以及怎样执行这些要求。
比如说，金融账本的智能合约与中心化数据库的管理者执行相同的三个任务：确定资金是否充足、从一个账户中减去一定金额、将这个金额加入另一账户。
以上两个范本都是有效的，并且各自有优缺点。总结起来就是，比特币类型的交易限制