有关智能合约的三种常见误解

关于智能合约有很多误导性的评论，使得人们产生了不少对智能合约是什么以及能做什么的困惑。本文便给出三个我所注意到的最常见的误解。本文也建立在之前一篇文章《智能合约简介》的基础上。

误区：智能合约就是会自己执行的代码

不是这样的。正如你将钱投入自动售货机让它出货那样，你要在公链上支付费用来运行这一合约。在一个公链上，比如以太坊，你就能通过支付ETH（以太币，以太坊的原生加密货币）来启动一个智能合约 —— 这就是将钱投入自动售货机的数字领域里的等价形式。

因此，除非有人启动了一个智能合约，否则智能合约是不会执行的。而且当智能合约运行的时候，它们也是不会在 “云端的某个位置” 自己执行的。它们只是会在所有参与对区块链的认证的机器里面同时运行。在公链上，有着大量的计算机（根据 Bitnodes 目前有约 6000 个节点参与比特币的验证工作，而根据 Ethernodes，参与以太坊验证工作的节点有约 8000 个）。在它们运行着同样的代码，处理着同样的输入的前提下，整个网络会对代码的运行结果最终达成一致。

误区：智能合约可以用普通货币进行支付

我常常读到一些用法定货币计价的区块链或智能合约的实例，比如 “智能合约能支付 20 美元”。这也不对。

在目前的智能合约里能拿来进行支付的货币只限于加密货币（比特币、以太币、等等），以及一些存储在区块链上的余额，后者有时被叫做硬币或者代币。比特币的合约能进行比特币支付，以太坊的智能合约能进行以太币的支付，或者转移记录在以太坊上的硬币 / 代币余额。

智能合约不能进行以法定货币（英镑、新加坡币、美元、等等）计价的支付，因为数字法定货币一般来说其实都驻留在银行账号上，而银行账号目前都记录在私有账本上 —— 不是分布式账本上。

所以，目前你所能达成 “自动支付” 的最简单的方法就是去拿个智能合约在分布式账本上弄点东西，然后让一个与分布式账本分离的系统（可能是集中的）检测到，让后者创建一个银行支付消息或者环球银行金融电信协会（SWIFT）消息，将消息递给相关的系统或者门户，让系统或者门户来验证这个支付的合法性，并接着在相应的银行账本上创建一条借记 / 贷记。这个过程没什么重大的意义，也没什么颠覆性。

智能合约只能在一个区块链或者分布式账本里面有一些法定货币的象征物，且这些东西是由一个具有能够合法地放入象征物的能力的个体（商业银行、中央银行或支付机构）放入的这一前提下处理法定货币的支付。这就是为何取得一种法定货币在分布式账本中的象征物对实现智能合约还有分布式账本的目标如此重要的原因。

误区：你需要智能合约来实现流程的自动化

我常常读到这样的评论：区块链上的智能合约可以实现业务决策的自动化（保险赔付、投注结果、等等）—— 就好像在说那些基本的业务逻辑不用智能合同就实现不了一样。 实际上，自从我们拥有计算机之后，我们就已经能够实现流程的自动化了。如果你读了点东西然后得出你需要智能合约来实现一些琐碎的逻辑，比如在特定时间按相应的股价来进行支付的流程，的自动化改造的结论，那你已经被误导了。在投资银行里，不少金融市场交易业务早在好几年前便已经可以根据股价或者其他数据来进行自动支付了。

那这有什么意义呢？智能合约又有什么好处呢？

智能合约是一段在参与者之间互相共享并各自独立并同时运行的，并且会自动核对结果的计算机程序。一个分布式账本能确保所有相关的参与者都会拥有同一份代码，并同时确保所有程序在运行时的输入都是相同的。每个参与者在运行这一程序时应该达成同一个结果 —— 也就是记录在分布式账本上的结果。

在一个公链，比如比特币或者以太坊上，所有认证节点会运行相同代码并建立起一个对运行结果的在节点网络上的共识。在一个有着更多选择性的分布式账本，比如 R3 的 Corda 里，则只有与智能合约有关的一方运行代码，然后与会受智能合约影响的一方对代码的运行结果达成共识。

这给参与者提供了一定程度上的安慰 —— 自己系统上的运行结果正是其他有关的参与者在它们的系统里看到的结果。这本身就是一件很重要的事，因为数据的不一致性会带来不少可能造成损失的风险。

那么如果发生了不一致的情况呢？智能合约能够取代可信第三方的地位吗？应该是的... 对一些功能，比如基本的在线托管交易，就能设置一个透明的程序，然后按照特定的标准来进行交易的支付。这样参与者就能审查然后信任有关的程序代码，而不是去信任（并且支付费用）一个第三方。而且随着技术的成熟，智能合约还会有越来越多的用处。但还有一些群体需要考虑：代码是由谁来运行的，这一重要的业务标准又是由谁来维护的？

结论：目前，企业都采用书面（人类语言）形式来表示认同特定的交易，有时它们会将其记录在一个合法的合约上，然后独立地编写自己的代码来实现合约里面的逻辑。一个分布式账本上的智能合约可以支持这些公司的多方协定。智能合约会在参与者间重现自动化的业务逻辑，确保在理解上的更高度的一致性，更小程度的差异性，以及更稳定的运行结果。