为什么很多智能合约应用案例根本不可能实现

  暴走时评：Dr Gideon Greenspan是Coin Sciences的创始人兼CEO，在文章中探讨了智能合约现状、本质和分类。通过对该技术的深层剖析，拨开周围的炒作迷雾，作者最后给出结论，认为智能 合约在很多应用案例上的无效性并不是因为人们的期望过高，而是因为它的本质就是一串代码而已。系统运行也必须符合对应的系统程序和规则。  

  翻译：Annie_Xu  

  Dr Gideon Greenspan是Coin Sciences的创始人兼CEO，该公司是区块链私链平台MultiChain的支持者。

  Dr Gideon Greenspan  

  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的账户中。

  常规数据库中的这些交易是由单一受信任机构创建的；相反在区块链驱动的共享数据库中，任何区块链用户都可以创建交易。并且因为用户不是完全互信，所以其数据库必须包含限制交易的规范。

  比如说在点对点金融账本中，每笔交易必须保存全额资金；否则参与者就可以随心所欲的分配资金。

  表达这些规则的方式很多，但是目前主要有两个范本，分别是比特币和以太坊。比特币的方法可以称为“交易限制”，其评估交易的依据有：交易删除的数据库条目以及被创建的条目。

  金融账本规则规定被删除条目的总资金额必须等于被创建的条目的资金额（假设现有条目的修改与条目的删除和新建条目对等）。

  第二个范本是来自以太坊的智能合约，规定对合约数据的所有修改必须由代码执行（传统数据库情况下，可以将其称为存储执行过程）。要修改合约数据，区块链用户必须向代码提交请求，然后由代码决定是否以及怎样执行这些要求。

  比如说，金融账本的智能合约与中心化数据库的管理者执行相同的三个任务：确定资金是否充足、从一个账户中减去一定金额、将这个金额加入另一账户。

  以上两个范本都是有效的，并且各自有优缺点。总结起来就是，比特币类型的交易限制提供卓越的性能和并发性；而以太坊类型的智能合约有很好的弹性。

  然后回到开头智能合约用途的问题：智能合约是用于区块链中受交易限制而无法执行的应用案例的。

  按照智能合约应用的标准，可以预测许可型区块链将有很多应用案例。

  我所知的所有重要的区块链应用都可以用比特币类型的交易完成，执行许可程序和一般数据存储；以及资产创建、转移、托管、交易和取消。然而新的案例仍不断出现，即使有人寻求智能合约的参与我也不会感到惊讶。或者说至少会出现比特币范本的延伸。

  无论答案是什么，最重要的是记住智能合约只是限制数据库中交易的一种方式而已。

  显然这是很有用的，也是安全的数据库共享必须的；但是智能合约做不了其他任何事，也肯定脱离不了它们所在的数据库范围。

声明：此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。本网站所提供的信息，只供参考之用。