如何解决智能合约区块链的围墙花园问题

“围墙花园”并不是一个区块链的专属概念。Facebook、Twitter、微信、支付宝、甚至苹果的iOS，当今几乎每一个互联网科技巨头都在建立自己的围墙花园。通过外部分享限制、生态搜索限制与小程序限制，大量用户被绑定在某一个生态里。AppStore内的开发者被苹果强迫抽成、百度里无法搜到微信10w+文章、在微信里分享一个淘宝链接也要使用非主流语言写成的“淘口令”。除了为自己生态锁住流量、保证用户信息的安全与内容的质量，这些花园的建立也让目前的互联网环境高度中心化。

而在以去中心化为己任的区块链世界，“围墙花园”问题也是所有基于智能合约的区块链都持续面临的一个难题。简单而言，由于智能合约的作用范围仅限于所在的区块链，这使得智能合约无法与区块链之外的其他实体进行交互。

虽然这一问题在NEO3中可以通过引入运行在共识节点上的Oracle预言机得到缓解，这允许NEO区块链获取外部数据，但要想完全实现与外部数据交互仍然是不可能的。事实证明智能合约无法操作任何私有信息、保存私钥或主动触发链外的操作。

由于智能合约的运行会受到这些严重的限制，那么需要这些功能的区块链解决方案又该如何避开这个问题呢？

一种解决方案是使用预言机，这是一种可信的服务器，可保存私有数据、密钥或凭据，并监听来自智能合约的事件，在触发这些事件时执行相应的操作，从而可承担智能合约的部分功能。当然，这个解决方案需要信任这样的服务器，这会失去在公链上构建项目所具备的去信任的属性。

康奈尔大学的研究所创新性地提出了一个更好的解决方案，即在可信执行环境（TEEs）中运行预言机，TEEs是嵌入到CPU中的硬件系统，在其中运行的程序是完全相互隔离的，使得其他部分的CPU或计算机不可能改变其状态或篡改内部运行的代码，因为一切都受到硬件级别的隔离保护。

然而，对于预言机而言，TEEs最重要的特性是，在TEE中创建代码实例时，可以创建一个证明：用TEE的私钥签名的TEE状态的哈希（包括TEE中的所有内存和代码）。然后，可以使用此证明向其他节点证明服务器正在运行特定的代码并处于特定的状态，因此它将始终遵循该代码（如果您提供了一个密码，并且代码中没有任何发送该密码的指令，则可以确保密码不会被泄露）。

此外，由于所有与Intel SGX兼容的CPUs（实现了TEE）都有一个来自Intel的唯一私钥，因此可以使用该私钥来对所创建的证明进行签名，以便向任意实体证明代码实际上是在TEE内运行的，确保服务器处于已知的状态并且不会被篡改，从而可以随时了解服务器的运行过程。

此外，如果不能直接信任Intel的私钥（Intel可能被黑客攻击），可以不考虑这个假设，我们仍可以发现自己的系统比标准服务器需要更少的信任，因为一旦一个程序开始在TEE中运行，它就不能被篡改，因此我们只需要信任在创建预言机时运行着预言机的实体，而不必持续信任它。有人也许会说，这不能完全消除对Intel的信任，因为当我们假设Intel没有在这些系统中留有任何硬件后门时，就是一种隐式的对Intel的信任，但这种信任可以通过使用多个TEE提供商（如AM）来消除， 例如AMD，ARM…

最后，需要注意的是，这些系统都不能完全和绝对地消除对运作服务器的人员或组织的信任，因为这些实体仍然可以关闭TEE，或者，如果有足够的资源的话，发起一次TEMPES攻击*来泄露私有数据。通过在由不同实体托管的一组服务器之间进行责任分配并使用阈值加密算法来保证密码也同样被分发，某种程度上可以减轻，但不能完全消除这些风险。