注：本人翻译。原作者为格林斯潘。
作为一个比较出名的区块链平台的开发者，经常有人问我，以太坊类型的智能合约是否会出现在MultiChain的发展路线上。对于这个问题，我总是回答“不会，至少现在不会”。
但是在区块链的风口，智能合约确也是一热点，那么为什么multichain不考虑呢？好吧，问题是，我们现在已经知道比特币类型的区块链有三种非常强的应用场景：起源追溯、公司记录保存、轻量级金融，但是在以太坊智能合约上我们还没有找到类似的强应用场景。
这并不是说人们不明白他们该怎么使用智能合约，而是说很多这种关于智能合约的想法是不可能实现的。当聪明的人听到“智能合约”的时候，他们的想法跑偏了。他们臆想出具有自主意识的智能软件，只要给出数据，这个软件就能智能化给出结果。但是现实是，智能合约要只是普通的软件。
智能合约只是一个时髦的名字，在这个名字背后，仅仅是一段能在区块链上运行的代码，这段代码跟区块链的状态做交互。这是什么代码呢？可以是Pascal，Python,PHP, Java, Fortran, C 。在数据库领域，那么这就是用扩展的SQL写的一段存储过程。
所有这些编程语言本质上是一样的，用相同的方法解决相同的问题。当然了，它们各有优劣，如果让你用c编写网站或者用Ruby处理高清视频，你可能会疯掉。但是从理论上来说，你是能做到的，只是说如果你非要这么做，需要付出很高的代价，比如易用性，性能，或者你的头发。
智能合约的问题不仅仅是人们对其的期望过高，而是这些过高的期望使很多人把很多时间和金钱用在了那些非常不可能实现的想法上。
似乎那些大公司们有足够的资源做一个长跑，从高管发现一个新技术开始，到完全了解这个新技术的优点和局限。也许我们的经历能帮忙缩短这个时间。
过去九个月里面，我们研究了很多智能合约的使用案例，一次又一次的发现他们根本实现不了。
所以，我们总结出了最常见的三种关于智能合约的错误概念。这些想法本身并不是错的，只是目前技术不成熟，或者某些工具还不可用。
尤其是，他们误解了这么一个基本概念：智能合约就是在数据库里面以去中心的方式运行的一段代码。
- 与外部服务通信
通常来说，能想到的关于智能合约的第一个使用案例就是它能根据某些外部的事件改变自己的行为。比方说，一个关于农业的保险条例，能根据某个月下雨的天数来有条件的支付保费。
很容易想到的方式就是，这个智能合约等到特定的时间，比如说月末，然后从一个外部的服务获取气象报告然后根据气象报告的结果做相应的处理（付钱或者不付钱）。
这个听起来很简单的实现方法，放到区块链里面是不能实现的，为什么呢？因为区块链是一个基于共识的系统，也就是说只有当每个节点对于每条交易（transaction）和区块的处理结果相同的时候，这种共识逻辑才成立。
在区块链上发生的所有事情都必须是完全确定的、不能有一点不确定性。一旦有两个信任节点对于链的状态理解产生了分歧，这整个系统就没有价值了。
现在，想想看智能合约需要在链上的每个节点互相独立的运行。那么，如果智能合约从一个外部的源获得信息，这个动作需要在每个节点重复分离的执行。但是由于这个源是区块链之外的资源，所以在链内没法保证每个智能合约都取到相同的结果。
也许是这个外部源对于不同节点的请求返回了不同的结果，或者只是暂时的服务不可用，任何一个原因，只要共识被打破，这整个区块链就死了。
有没有变通的方案呢？有而且也很简单。不需要由智能合约发起向外部源的请求，而改为某些信任方（“先知”）在链中创建交易把它取到的信息加到链中来。这样的话每个节点就是拿到这份数据的拷贝，从而可以执行职能合约的结算了。
换言之就是由一个信任的第三方（也可以是链中节点）主动把信息推给区块链而不是智能合约去把数据拉进来。
当谈到智能合约也能对区块链的外部世界输出事件的时候，也有一个类似的问题。比如很多人想到用智能合约来调用银行的外部接口用来转账。但是如果每个节点都要独立的执行这个职能合约，那么究竟哪个节点来负责调用银行接口呢？
如果说我们只找一个节点去联系银行，那么如果这个特殊的节点运行有问题，这是故意的还不是？如果说我们所有节点都去联系银行，那么我们需要把密码都给所有节点，这些节点都是可信的吗？另一方面，节点那么多，银行的接口需要调用那么多次吗？更糟糕的是，如果智能合约需要知道银行的接口调用是否成功，我们又回到了依赖外部信息的那个问题。
和之前一样，我们也有一个变通方案，我们不需要智能合约调用银行接口，而是用一个可信任的服务监控区块链的状态然后根据链的状态做相应的动作。比如一家银行可以主动监控区块链然后做转账操作，这跟区块链调用银行接口相反。这种方案对于区块链的共识没有损害，因为区块链在这里完全是被动模式。
从上面这两个变通方案我们可以得出一些结论。
首先，这两个方案都需要一个可信任的实体去管理区块链跟外部世界的交互。技术上是可实现的，但是违背了区块链的去中心化目的。
其次，用在这两个变通方案里面的机制都只是简单的读写操作。一个提供外部信息的先知只是简单的把数据写到区块链。一个对区块链做监控的服务只是从区块链读取数据出来。所以说区块链跟外部世界的任何交互限制在基本的数据库的读写操作层面。
后来我们会更多的讨论这个事实。
2. 强化的链式支付
我们还听到另外一种关于智能合约的想法：用智能合约来自动做债券的兑付，也叫作“智能债券”。这个想法是说用智能合约在合适的时间自动的发起支付，避免了人工操作并且保证券的发行方不会拖欠。
当然了，为了让这个想法能运行，用来做支付的这笔资金必须在区块链存着，否则的话智能合约没法保证支付。
提醒一下，区块链只是数据库，所以在这个例子里，区块链只是一个金融账簿，包含了发行的债券和资金的数据。所以，我们在讨论债券汇兑的时候，我们只是讨论在协议时间自动执行的一些数据库操作。
尽管这种自动化是技术上可实现的，但是这里有个金融问题。如果说这些给债券做支付用的资金是被债券的智能合约控制的，那么支付肯定是能保证的，不过这些钱不能被发行方做其他用途了。如果这些钱不受智能合约控制呢，又没法保证支付。
换言之，一个“智能债券”对于发行方和投资者来说都没有用。仔细想想，这就是支出。
从一个投资者的角度来说，债券的好处就是高的投资回报率和发行方不兑付的风险。从发行方的角度来说，债券的目的就是募集资金做一些高产出但是可能有点风险的事情，比如建一个新工厂。
如果用上面的方案的话，没有办法同时保证债券的发行方使用这笔募集到的资金，并且投资者能随时兑付。对于区块链没法同时解决风险跟回报的问题应该正常看待。（别的技术也解决不了）
3. 隐藏机密信息
部署区块链的最大挑战就是它提供的彻底的透明性。
比如，如果十家银行一起设立了一个区块链，其中两家做了一次双边交易，这个信息会马上被其他八家看到。尽管对于这个问题，有很多的方法去避免，但是最简单和有效的方法还是做一个中心化的数据库，用一个可信任的管理系统去控制谁能看到什么信息。
有些人认为智能合约能解决这个问题。他们设计每个智能合约包含自己的微型数据库，智能合约有全权控制。所有的读写操作都通过合约来做，通过这种方法来保证数据的排他性，其他合约没法读取。（这种数据和逻辑的紧耦合叫做封装，也是面向对象编程的基础）
所以，如果一个智能合约不能访问其他合约的数据，我们是不是就解决了区块链的保密性问题？在智能合约里面谈论隐藏信息是不是有意义？不巧的是，no。
因为虽然一个合约不能读取其他合约的数据，但是这些数据还是存在链的每个节点中。对于每一个链的参与者，这些数据就存在了他的内存或者硬盘上，这些东西，他是有完全的控制权。他们如果愿意，完全可以从他们自己的系统读取出这些信息。
在智能合约里面隐藏数据就跟在网页的HTML里面隐藏数据一样。当然了，普通的上网用户不会看见这些信息，因为这些信息不会在他们的浏览器窗口显示。但是浏览器只要加一个“查看源代码”的功能（浏览器已经都有了），这个信息就没法隐藏。
类似的，对于隐藏在智能合约中的信息，只要有人修改一下他的区块链代码显示合约的全部状态，这种保密的表象被完全破解。
稍微一个过得去的程序员能在一小时内搞定这事。
智能合约到底有什么用？
上面说了那么多事情智能合约都干不了，就有人会问了，到底能干什么？为了能回答这个问题，我们看看区块链的本质。区块链本质是使得数据库能在互相不信任的实体之间的一个去中心的共享。
区块链使得数据的传输不需要中介，这样很大程度上减少了事务交互的复杂度和成本。
任何数据库都是通过“事务”（transactions）来修改的，事务里面包含了一组对数据库的操作，这些操作被作为一个整体来看待失败或者成功。比如，一个金融账簿，张三向李四付钱，作为一个事务来看包含了（a）检查张三是否有足够的资金（b）从张三的账户扣除相应的钱（c）同等的钱增加到李四的账户。只有三步都成功了，这个事务才成功。
在一个普通的中心化数据库，单一的可信任的授权对象负责发起这些事务。相反，在区块链驱动的共享数据库里面，事务可由区块链的任何一个用户发起。但是因为这些用户彼此不完全信任，数据库不得不包含一些规则去约束这些事务的发起。
比如，在一个点对点的金融存折里，每一个交易必须预查资金总额，否则的话，参与者可以无限的给自己取钱。
能想到很多方法去表达这些规则，目前受到比特币和以太坊的启发，有两个优势方案。
比特币的方法：可以说是“事务限制”，对每条交易做评估（a）交易删掉数据库的数据（b）交易创建的数据库数据。
金融账簿中，这个规则表示删除的那些记录的资金总数需要跟创建的记录的资金总数一致。（对于更新操作我们认为是先删一条，再加一条。）
另一个模式，从以太坊来的，是智能合约。这个要求所有对合约数据的更改必须由合约的源码来做。（如果放在传统的数据库的话，我们可以想象这是增强版的存储过程）。需要更改合约管理的数据的时候，区块链用户向合约代码发送请求，由这些代码决定是否或者怎样去满足这些请求。
这种模式在金融账簿中，跟中心化数据库一样，需要执行三个任务，验证资金足够，从一个账户扣钱，加到另一账户。
这两种模式都很有效，并且各有优劣。总结来说，比特币模式的交易限制提供了优越的并发性和性能，以太坊的模式提供了更多的灵活性。
所以针对这个智能合约能做什么的问题：智能合约是能被用在区块链的一些不能使用比特币类型事务限制（transactionconstraints）的使用场景中。
基于这个标准使用智能合约，我还目前没有看到区块链能使用的强场景。
目前我知道所有的强区块链应用都能用比特别模式的事务，它能处理许可，通用数据存储，资产创建、转移、第三方托管、兑换和销毁。尽管如此，新的应用场景还在出现，如果有人说要用智能合约我也不会惊讶。或者说，至少，扩展的比特币模式。
不管最后答案是什么，关键要记住的是，智能合约只是约束数据库事务的一个简单方法。
无可厚非，这是个有用的东西，对于数据库共享安全也是一个必要的保证，除此之外智能合约不能做更多的事情，也不能逃离它们生存的这个分享的数据库的边界。
