36

通过链下逻辑扩展区块链智能合约

 5 years ago
source link: http://www.ibm.com/developerworks/cn/cloud/library/cl-extend-blockchain-smart-contracts-trusted-oracle/index.html?ca=drs-&%3Butm_source=tuicool&%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

本文将介绍两种方法,利用在区块链典型边界外获得的逻辑来增强智能合约,同时仍然保留界定区块链网络的信任和透明性。

在利用区块链技术的业务网络中,事务是依据 智能合约 中包含的规则来执行的。智能合约采用一种编程语言进行编码并部署到区块链运行时平台。例如, Hyperledger Fabric 运行时的智能合约可以采用 Go 编程语言或 JavaScript(Fabric v1.1 中使用了它)进行编码。

温习一下智能合约知识

了解如何 结合使用业务流程管理和区块链

然后,了解如何通过业务规则 让区块链智能合约变得更智能

在部署和实例化智能合约之前,它们要经历审查和背书流程,该流程与常规事务提交到共享账本之前所要经历的相同。 在智能合约成为区块链网络的一部分之前,网络中拥有和管理对等节点的参与者需要通过代码评审,验证并确认智能合约中的业务规则和逻辑确实有效。

当智能合约不如他们需要的那么智能时

验证和确认智能合约可以建立透明性,并增加对控制网络中执行的事务的流程和规则的可视性。因此,在理想情况下,所有事务逻辑都应封装在智能合约中,以确保参与事务背书流程的所有对等节点都将执行相同的代码。

然而,在某些情况下,智能合约可能 不具备 完成事务处理所需的全部知识。例如,智能合约可能需要在运行时从外部系统获取易变的信息(比如股票价格)。或者,管理事务的业务规则可能错综复杂,以至于将它们外部化更为合适。类似这样的情况使我们想到以下问题:

用链下逻辑扩展智能合约有多大可行性?

使用链下逻辑的两种方式

在本文中,我们将介绍两种实现链下逻辑的机制,以保持信任、可视性和透明度,这些代表了区块链网络的服务质量:

  • 将智能合约的操作边界扩展到 第三方系统 (比如 IBM Operational Decision Manager (ODM))。在此模型中,区块链网络中的对等节点会调用与它们位于同一位置的第三方服务。基本假设是调用的结果是确定的。

    图 1. 将智能合约的操作边界扩展到第三方系统,比如 ODM。

    yE7ZB3n.png!web
    yE7ZB3n.png!web
  • 引入一个智能合约可以调用的 预言机 (oracle) 。在这个模型中,预言机是一个受信任的第三方,可以在不知道事务完整上下文的情况下以明确方式回答问题。换言之,隐私和机密性得到了保留。

    图 2. 可信预言机简介

    UbENBva.jpg!web
    UbENBva.jpg!web

下面几节将介绍两种模型的考虑因素。

1

扩展智能合约的操作边界

通过 ODM 让智能合约更智能

如何实现上述操作?使用一个受决策管理平台支持的规则引擎来实现它们。

借助 IBM Operational Decision Manager (ODM),可以在智能合约定义级别上增强信任。这种方法使业务干系人能为智能合约决策逻辑做出贡献。

进一步了解如何使用 ODM 实现智能合约

我们假设一个组织利用 IBM Operational Decision Manager (ODM) 来实现并托管许多复杂的业务规则。另外我们还假设此组织计划创建一个新的区块链网络,该网络将包括来自其他企业的参与者。

该组织的一种选择是,将目前在 IBM ODM 中存在且执行的业务规则作为多个智能合约重新实现,并将它们部署到区块链运行时平台。

从纯技术角度讲,这似乎是理想的解决方案。但是,对于已经过测试和验证的、已知能按预期正常工作的数百乃至数千条规则而言,重新实现它们是否可行?这么做对组织而言可能代价高昂,而且在将这些规则重新实现为智能合约时很容易引入错误。重新实现这些规则并将它们部署为智能合约的另一个可能的缺陷是,如果业务人员习惯于通过 IBM ODM 用户界面来更新和验证规则,那么他们将失去这种灵活性。

避免重复工作

这个组织的一个更可行的选择是,从智能合约的上下文利用 IBM ODM 中实现的现有规则:

  1. 业务网络中的每个组织(以及每个对等节点)都有自己的私有 IBM ODM 实例。
  2. 智能合约调用 IBM ODM 中存在的业务规则。然后,将从 IBM ODM 返回的输出用于智能合约,以执行额外的计算和/或更新共享账本。
  3. 网络中的每个组织将相同版本的业务规则代码部署到他们的 IBM ODM 实例,以确保在智能合约运行时,网络可以达成共识。
  4. 安装和更新 IBM ODM 实例上运行的代码的流程 遵循 IBM ODM 使用的典型部署流程。(如果使用典型的部署流程,网络中的组织之间可能出现信任问题。例如,他们如何确知区块链网络中的智能合约调用的每个 IBM ODM 实例都在运行相同的代码?)正如智能合约代码在区块链中是防篡改的,任何人都无法篡改 IBM ODM 内运行的业务规则逻辑。
  5. 在 IBM ODM 上运行的代码的安装和更新发生在区块链网络上一个事务的上下文中。这可以确保网络中的所有 IBM ODM 实例都有相同的逻辑/业务规则版本。规则集归档文件的二进制文件(包含业务规则/逻辑的 IBM ODM 工件)及其版本号通过事务提交给区块链网络,然后由一个智能合约处理:
    • 在世界状态数据库中存储规则集归档文件
    • 存储规则集的版本
    • 将规则集部署到在本地对等节点上运行的 IBM ODM 实例

上述架构方法允许组织利用来自区块链网络解决方案中的现有工件,同时确保这些工件是防篡改的,而且可以在安装或更新时进行验证和检查。

尽管我们关注的是 IBM ODM,但这种架构方法也适用于其他拥有链下业务逻辑的组件。例如,可以从区块链运行时采用类似的方法,以利用在 IBM Business Process Manager 上下文中运行的业务流程内定义和执行的逻辑。

请注意,尽管这种架构方法维护了您期望在区块链网络中获得的信任,但它带来了额外的成本和操作问题。这主要是由于需要对与智能合约共存于网络对等节点上的第三方系统进行配置和持续维护。

2

引入可信预言机

上一节中介绍的架构方法提供了一种外部化复杂决策规则的可靠途径。但是,如果信息易变(例如利率),我们如何使用这些信息可靠地充实智能合约?

一种可能的方法是将此责任委托给客户端应用程序:客户端应用程序检索当前利率,并将其包含在智能合约的有效负载中。但是网络为什么会信任客户端应用程序能始终准确可靠地提供这类信息?因此,除了将此责任委托给客户端应用程序之外,更好的选择是:

  1. 将获取易变信息的过程委托给一个称为 预言机 的第三方
  2. 在易变信息使用的值上达成明确一致

了解区块链预言机的内幕

在区块链上下文中,预言机找到、验证并提供真实数据,以便在智能合约中使用。进一步了解预言机在区块链网络中的作用:

要在区块链网络中发挥作用,预言机必须满足以下几个必要条件:

  • 多个背书者必须能够从预言机中获得相同的答案,以保持智能合约的确定性。
  • 必须在智能合约的执行与来自预言机的响应之间建立一个耐久的链接。
  • 必须在需要时保持数据的机密性。

此场景的架构

下图展示了在多方区块链网络中利用预言机组件的架构和事件顺序:

图 3. 预言机组件如何与区块链网络配合使用

EFVjUfF.png!web

EFVjUfF.png!web

在上图中:

  1. 客户端应用程序将事务提交给需要对该事务进行背书的每个组织(已在背书策略中指定)。客户端应用程序完全不知道智能合约将一部分执行工作委托给了外部系统。
  2. 每个组织中的每个背书对等节点都可以并行向预言机发出请求,并提供足够的信息,这样预言机就能将来自不同背书对等节点的不同请求联系起来。下面这个事务结构给出了实现此操作的潜在方法:

    理解事务流和绑定

    进一步了解在标准资产交换期间的典型 事务机制 ,以及如何在 Hyperledger Fabric 中使用 绑定字符串

    FvAZzmu.png!web
    FvAZzmu.png!web

    上面的事务数据结构使用了一个 Merkle 树,该树包含发送到智能合约的所有输入,但它仅公开必须与预言机共享的字段。通过使用 Merkle 树,可以追踪输入参数与预言机的响应之间的关系。请注意, 绑定字段 被用作识别事务和请求者的唯一方式。现在,建立此链接是可选的,因为 Hyperledger Fabric 中的验证和执行阶段会处理对等节点受到损害的情况。

  3. 预言机使用绑定字段(如下图所示)来关联常见请求,并确保响应中的一致性。预言机还应该对响应进行签署,以避免任何潜在的篡改。此外,还可以使用 Apache Kafka 主题来确保这些请求的顺序。 3Yn2qam.png!web

    3Yn2qam.png!web

    预言机的响应结构可能类似于上面的结构,其中包括请求哈希值与响应之间的链接以及来自预言机的签名。

  4. 背书对等节点会验证预言机的签名。签名和响应数据都应保留在账本上,以提供可审计性。

在本节中,我们假设采用了一种与预言机交互的独特机制,但业务网络可能选择与商业预言机集成。如果是这样,预言机提供者可能会指定该方法。不过,本节开头列出的条件仍然适用。

总结与建议

您现在已经了解了实现链下逻辑,同时保持区块链网络所需的信任和透明性的两种方法。

第一种方法需要在网络的对等节点中安装第三方组件。这些第三方组件包含错综复杂的业务逻辑,如果将该业务逻辑外部化,维护会变得更容易。安装和更新这些组件上执行的工件将作为网络事务执行。

第二种方法展示了使用预言机组件扩展智能合约的一种方法,而且需要智能合约的输入与来自预言机的响应之间的耐久链接。正如一些人可能注意到的,这种实现不同于其他所使用的技术。在本系列的下一篇文章中,我们将深入探讨将预言机集成到业务网络中的其他考虑因素,还会查看各种替代方案。

与任何解决方案一样,在引入额外的组件时,必须考虑到它们可能带来的非功能性影响。例如,由于仅当服务的所有组件可用时服务才可用,所以向事务链添加更多组件会直接影响服务的正常运行时间。类似问题也适用于整个事务延迟。鉴于此,必须认真考虑智能合约的外部化。

智能合约以及存在于链下的任何扩展点的安装和更新过程都应经过网络成员的审核,以确保每个人都能正确理解了它的条款和条件。此操作必须在网络治理过程中执行。这需要超越单一组织的传统边界的协作水平、信息技术技能,以及业务和法律技能。决定将业务规则外部化到智能合约之外可能带来许多积极的好处,但它必须与联盟流程的成熟度保持一致。

敬请期待本系列的第二篇文章,我们会在其中介绍将预言机集成到业务网络中的其他考虑因素和备选方案。

后续步骤

  • 通过 IBM Blockchain Starter Plan (目前免费提供测试版)尝试这些扩展智能合约的选项。Starter Plan 为开始在 IBM Cloud 上部署和开发区块链应用程序提供了一个简单、经济的起点。 开始使用 Starter Plan。 
  • 要调整您的自定义区块链解决方案来满足您的业务需求,请访问 IBM Blockchain Workshop ,您可以在其中将初始概念转变为生产就绪的原型。 
  • 要更深入地研究,这个 IBM Code Pattern 介绍了如何使用 Hyperledger Composer 创建和执行智能合约 。查阅其他许多 Code Pattern ,它们提供了用区块链技术解决复杂问题的路线图,还提供了架构图、代码存储库和其他阅读材料。 
  • 访问 区块链开发人员中心 。可以在这里获得开发和部署商业区块链解决方案的免费工具和教程,以及代码和社区支持。 
  • 在这个幻灯片资料中进一步了解 区块链解决方案架构 ;具体来讲,第 55 - 58 页介绍了如何使用诸如 IBM Operational Decision Manager 之类的外部规则引擎来设计智能合约。

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK