Hyperledger Fabric 智能合约

智能合约和链码

账本包含了与一组业务对象的当前和历史状态有关的事实，而智能合约定义了生成这些被添加到账本中的新事实的可执行逻辑。

管理员通常使用链码将相关的智能合约组织起来进行部署，并且链码也可以用于 Fabric 的底层系统编程。

智能合约

在各业务彼此进行交互之前，必须先定义一套通用的合约，其中包括通用术语、数据、规则、概念定义和流程。

智能合约用可执行的代码定义了不同组织之间的规则。

应用程序调用智能合约来生成被记录到账本上的交易。

组织 ORG1 和 ORG2 是如何通过定义一个 car 智能合约来实现 查询、转移 和 更新 汽车的。

可以将智能合约看成交易的管理者，而链码则管理着如何将智能合约打包以便用于部署。

一个智能合约定义在一个链码中。而多个智能合约也可以定义在同一个链码中。当一个链码部署完毕，该链码中的所有智能合约都可供应用程序使用。

vehicle 链码包含了以下三个智能合约：cars、boats 和 trucks；而 insurance 链码包含了以下四个智能合约：policy、liability、syndication 和 securitization。

账本

智能合约以编程方式访问账本两个不同的部分：

一个是区块链（记录所有交易的历史，且记录不可篡改）
一个是世界状态（保存这些状态当前值的缓存，是经常需要用到的对象的当前值）。

智能合约主要在世界状态中将状态写入（put）、读取（get）和删除（delete），还可以查询不可篡改的区块链交易记录。

读取（get） 操作一般代表的是查询，目的是获取关于交易对象当前状态的信息。
写入（put） 操作通常生成一个新的业务对象或者对账本世界状态中现有的业务对象进行修改。
删除（delete） 操作代表的是将一个业务对象从账本的当前状态中移除，但不从账本的历史中移除。

开发

智能合约是应用程序开发的重点。

智能合约的核心是一组 交易 定义。

例如，在 fabcar.js 中，创建了一辆新车的智能合约交易：

async createCar(ctx, carNumber, make, model, color, owner) {

    const car = {
        color,
        docType: 'car',
        make,
        model,
        owner,
    };

    await ctx.stub.putState(carNumber, Buffer.from(JSON.stringify(car)));
}

背书

每个链码都有一个背书策略与之相关联，该背书策略适用于此链码中定义的所有智能合约。

背书策略非常重要，它指明了区块链网络中哪些组织必须对一个给定的智能合约所生成的交易进行签名，以此来宣布该交易有效。

一个示例背书策略可能这样定义：参与区块链网络的四个组织中有三个必须在交易被认为有效之前签署该交易。所有的交易，无论是有效的还是无效的，都会被添加到分布式账本中，但只有有效交易会更新世界状态。

交易必须由 Fabric 网络中受信任的组织验证。

例如，一个政府组织必须签署一个有效的 issueIdentity 交易，或者一辆车的 买家 和 卖家 都必须签署一个 车辆 转移交易。

有效交易

智能合约提取一组名为交易提案的输入参数，并将其与程序逻辑结合起来使用以读写账本。对世界状态的更改被捕获为交易提案响应（或简称交易响应），该响应包含一个读写集，其中既含有已读取的状态，也含有还未书写的新状态（如果交易有效的话）。

在执行智能合约时世界状态没有更新！

所有交易，无论是否有效，都会被记录在区块链上，但仅有效交易会更新世界状态。

各节点通过两个阶段对其进行验证。

根据背书策略检查交易，确保该交易已被足够的组织签署。
该交易在受到背书节点签名时它的交易读集与世界状态的当前值匹配，并且中间过程中没有被更新。

交易通过了这两个测试，它就被标记为有效。

通道

通道在一群组织之间提供了一种完全独立的通信机制。当链码定义被提交到通道上时，该通道上所有的应用程序都可以使用此链码中的智能合约。

链码定义是一种包含了许多参数的结构，这些参数管理着链码的运行方式，包含着链码名、版本以及背书策略。各通道成员批准各自组织的一个链码定义，以表示其对该链码的参数表示同意。

链码的定义为通道成员提供了一种他们在通道上使用智能合约来交易之前，同意对于一个链码的管理的方式。