智能合约的性能是否被高估了？

金融科技记者有竞争力的薪水！

要求：

1、经济学、法学专业毕业，熟悉证券、银行等资本市场，对大数据、人工智能等计算机技术有浓厚兴趣

2. CET-6水平，良好的写作能力

雷锋网出版社：本文翻译自Fintechranking，原文来自LTP，作者Milos Dunjic：金融科技技术顾问，拥有25年支付和电子交易软件系统开发经验，曾从事加密算法RSA实验室。

智能合约是安装在区块链网络节点中的离散计算机程序组件。 从本质上讲，这些自动合约的工作方式类似于其他计算机程序中的 if-then 语句。 当智能合约准备好部署时，将计算代码的哈希值并进行数字签名。 单向哈希、数字签名和代码本身在参与区块链的节点网络中同时复制。 作为部署过程的一部分，每个节点做的第一件事就是验证哈希。 如果验证通过，节点将在本地部署代码。 接下来，该节点将等待智能合约的调用。

由于智能合约代码的完整性受到其单向哈希和作者数字签名的保护，部署后任何人都无法更改。 在某种程度上，这很像智能芯片卡中配置的密码防篡改保护功能。 事实上，在安装之后，智能合约的代码连同所有交易记录和内部数据一起成为不可变区块链的一部分。

当条件触发时，智能合约代码将在每个安装了代码并具有挖矿和验证功能的节点上执行。 这些节点将尝试就各自智能合约代码执行的结果达成共识。 作为共识发现过程的一部分，区块链网络协议确保最新更新的智能合约内部数据可靠地复制到每个节点。 内部数据结构是不可变的，这意味着只有智能合约代码本身可以更改其内容。

在所有区块链节点并行且完全独立地执行同一段代码的状态下，为保证执行的健壮性和可靠性，智能合约的代码本身必须具有非常高的确定性。 这就要求智能合约的代码必须在每个执行节点上产生完全相同的结果。 这些要求极大地限制了智能合约可以做什么和不能做什么。

智能合约最大的问题是人们并不完全理解它们是如何工作的； 对智能合约基本特性的误解也导致了一些无法实施的想法。

虽然这听起来很简单并且被许多人认为是可行的，但智能合约不应该调用外部网络服务或数据库。 这样的设计大大增加了同一段智能合约代码在重复独立执行时产生不同结果的概率。 因为这会导致区块链节点无法达成可靠的共识，这样的设计会导致系统混乱。

智能合约设计的另一个不好的例子是试图从智能合约调用另一个简单的 API，比如银行资金转账。 由于区块链中的每个节点都会独立执行相同的智能合约代码，让每个节点上的每个代码执行都调用“资金转账”API 真的是个好主意吗？ 这显然感觉像是对一个糟糕的 API 的自我造成的 DDos 攻击。 这样的设计要求 API 本身的设计足够复杂，能够检测并正确处理数百次重复调用。 同时这也势必造成不必要的计算机资源浪费。

其次，由于智能合约需要可靠地知道 API 调用的状态并据此做出内部决策比特币有智能合约功能吗，我们能否保证智能合约对 API 的每次调用都会收到完全相同的 API 反馈？ 无论如何，这一切看起来都很混乱。

许多人热情地相信智能合约将是解决区块链固有的数据隐私问题的优雅答案。 由于智能合约可以轻松封装其内部数据库并控制对其的访问（本质上它的行为类似于分布式对象），这不是保证了数据保护吗？ 不幸的是，相同的智能合约数据总是被复制并存储在每个安装了智能合约代码的区块链参与者的计算机中。 因此，没有什么可以阻止某些参与者机器上的一些聪明的本地代码获得对存储在本地系统上的所有内容的访问权。

虽然对于上述智能合约设计的局限性有一些（不是很优雅的）解决方法，但智能合约应该只用于管理对其内部数据状态的更新。 也就是说，智能合约在去中心化数字资产转移的技术实现上比普通的比特币区块链技术提供了更多的灵活性比特币有智能合约功能吗，但除此之外，智能合约并没有太多其他优势。

综上所述，目前的智能合约很难有超出内部数据状态管理作用的其他应用。 更复杂的应用程序将需要智能合约与外部环境和服务进行交互，这将导致难以想象的测试复杂性，这种复杂性固有地存在于分布式和去中心化的系统结构中。 它很容易变成噩梦般的测试和支持场景。 只需询问 DAO 程序员即可。