Topic: 作为区块链数据隐私的最优选，智能合约的性能是否被高估 (Read 232 times)
智能合约有无限可能
智能合约是安装在区块链网络节点中离散的计算机程序组件，从本质上讲，这些自动合约的工作原理类似于其它计算机程序的if-then语句。当智能合约准备好被部署的时候，代码的哈希值会被计算出来并打上数字签名。单向哈希值，数字签名和代码本身会被同时复制到由参加区块链的节点所组成的网络之中。作为部署流程的一部分，每一个节点第一件要做的事情是要验证哈希值。如果验证通过，节点会在本地部署代码。接下来，这个节点会等待智能合约的调用。
因为智能合约代码的完整性是被它的单向哈希值和作者的数字签名所保护起来的，没有人能在部署之后改变它。从某种方面来讲，它非常像配置在智能芯片卡中的密码的防篡改保护特性。事实上，在安装之后，智能合约的代码与全部交易记录和内部数据一起，成为了不可篡改的区块链的一部分。
当条件被触发时，在每一个代码有被安装、并且有挖矿和验证功能的节点上，智能合约代码都会被执行。这些节点会尝试就他们各自的智能合约代码执行的结果达成共识。作为寻找共识过程的一部分，区块链网络协议会保证将最新更新过的智能合约内部数据可靠地复制到每一个节点。内部数据结构是不可改变的，这意味除了智能合约代码自己之外，没有东西可以改变它的内容。
在区块链节点全都平行地、完全独立地执行同一段代码的状态下，要保证执行的稳健和可靠，就要求智能合约的代码本身必须有非常高的确定性。这要求智能合约的代码在每一个执行的节点上，必须产出完全相同的结果。这样的要求就极大的限制了智能合约什么可以做、什么不可以做。
关于智能合约的最大问题在于，人们并不完全理解它们是如何运作的；对于智能合约基础特性的错误理解，也引致了一些无法被实现的想法。
虽然听起来十分简单，同时又被许多人相信是可行的，但是智能合约不应该调用外部的web服务或者数据库。这样的设计极大地提高了同一段智能合约代码在被重复独立地执行时产生不同结果的概率。因为这样会导致区块链节点无法得出可靠地共识，这样的设计会导致系统的混乱。
另外一个智能合约设计的反面例子是试图从智能合约调用另一个简单的API，比如说银行资金转账。因为每一个区块链中的节点都会独立地执行相同的智能合约代码，让每一个节点上的每一次代码执行都调用“资金转账”的API真的是一个好的想法吗？这明显感觉像是一个自己造成的对可怜API的一次DDos攻击。这样的设计要求API本身的设计足够复杂，能够侦测并正确地处理数以百计的重复调用。同时这也一定会造成计算机资源的无谓浪费。
接下来，因为智能合约需要可靠地知道API调用的状态并以此为依据来做出内部决定，我们能够保证每一次智能合约对API的调用都会收到API一模一样的反馈吗？总之这一切看起来十分混乱。
许多人满腔热情地相信智能合约会是对区块链天生的数据隐私问题的优雅解答。既然智能合约可以很容易地封装它的内部数据库并控制对它的访问（基本上它表现得像是分布式对象），这不就能够保证将数据保护起来了吗？不幸的是，相同的智能合约数据总是被复制和储存在每一个区块链参与者有安装智能合约代码的电脑中。因此，没有东西可以阻止一些参与者机器上的聪明的本地代码得到访问一切存储在本地系统上信息的权限。
虽然存在着一些（不是很优雅的）针对以上提到的智能合约设计局限的变通措施，智能合约仍应该只被用来管理它内部数据状态的更新。换一种说法就是，智能合约提供了比普通比特币区块链技术在去中心化数字资产转移的技术实现上多那么一点点的灵活性，但是除此之外，智能合约并没有更多其他的优点了。
总结起来，目前的智能合约很难在内部数据状态管理作用之外有别的应用。更加复杂的应用就会要求智能合约与外部环境和服务产生互动，这会导致不可想象的测试复杂性，这样的复杂性天生就存在于分布式及去中心化的系统结构中。它很容易就变成一个噩梦般的测试和支援情景。
http://www.btc38.com/news/2017/2/13244.html
因为智能合约代码的完整性是被它的单向哈希值和作者的数字签名所保护起来的，没有人能在部署之后改变它。从某种方面来讲，它非常像配置在智能芯片卡中的密码的防篡改保护特性。事实上，在安装之后，智能合约的代码与全部交易记录和内部数据一起，成为了不可篡改的区块链的一部分。
当条件被触发时，在每一个代码有被安装、并且有挖矿和验证功能的节点上，智能合约代码都会被执行。这些节点会尝试就他们各自的智能合约代码执行的结果达成共识。作为寻找共识过程的一部分，区块链网络协议会保证将最新更新过的智能合约内部数据可靠地复制到每一个节点。内部数据结构是不可改变的，这意味除了智能合约代码自己之外，没有东西可以改变它的内容。
在区块链节点全都平行地、完全独立地执行同一段代码的状态下，要保证执行的稳健和可靠，就要求智能合约的代码本身必须有非常高的确定性。这要求智能合约的代码在每一个执行的节点上，必须产出完全相同的结果。这样的要求就极大的限制了智能合约什么可以做、什么不可以做。
关于智能合约的最大问题在于，人们并不完全理解它们是如何运作的；对于智能合约基础特性的错误理解，也引致了一些无法被实现的想法。
虽然听起来十分简单，同时又被许多人相信是可行的，但是智能合约不应该调用外部的web服务或者数据库。这样的设计极大地提高了同一段智能合约代码在被重复独立地执行时产生不同结果的概率。因为这样会导致区块链节点无法得出可靠地共识，这样的设计会导致系统的混乱。
另外一个智能合约设计的反面例子是试图从智能合约调用另一个简单的API，比如说银行资金转账。因为每一个区块链中的节点都会独立地执行相同的智能合约代码，让每一个节点上的每一次代码执行都调用“资金转账”的API真的是一个好的想法吗？这明显感觉像是一个自己造成的对可怜API的一次DDos攻击。这样的设计要求API本身的设计足够复杂，能够侦测并正确地处理数以百计的重复调用。同时这也一定会造成计算机资源的无谓浪费。
接下来，因为智能合约需要可靠地知道API调用的状态并以此为依据来做出内部决定，我们能够保证每一次智能合约对API的调用都会收到API一模一样的反馈吗？总之这一切看起来十分混乱。
许多人满腔热情地相信智能合约会是对区块链天生的数据隐私问题的优雅解答。既然智能合约可以很容易地封装它的内部数据库并控制对它的访问（基本上它表现得像是分布式对象），这不就能够保证将数据保护起来了吗？不幸的是，相同的智能合约数据总是被复制和储存在每一个区块链参与者有安装智能合约代码的电脑中。因此，没有东西可以阻止一些参与者机器上的聪明的本地代码得到访问一切存储在本地系统上信息的权限。
虽然存在着一些（不是很优雅的）针对以上提到的智能合约设计局限的变通措施，智能合约仍应该只被用来管理它内部数据状态的更新。换一种说法就是，智能合约提供了比普通比特币区块链技术在去中心化数字资产转移的技术实现上多那么一点点的灵活性，但是除此之外，智能合约并没有更多其他的优点了。
总结起来，目前的智能合约很难在内部数据状态管理作用之外有别的应用。更加复杂的应用就会要求智能合约与外部环境和服务产生互动，这会导致不可想象的测试复杂性，这样的复杂性天生就存在于分布式及去中心化的系统结构中。它很容易就变成一个噩梦般的测试和支援情景。
http://www.btc38.com/news/2017/2/13244.html
Jump to: