核心概念 - 智能合约和链码
从应用程序开发人员的角度来看，智能合约与帐本一起构成了 Hyperledger Fabric 区块链系统的核心。账本保存有关一组业务对象的当前和历史状态的事实，而智能合约定义可执行逻辑，生成添加到账本的新事实。管理员通常使用链码对相关的智能合约进行分组以进行部署，但也可以将其用于 Fabric 的低级系统编程。在本主题中，我们将重点介绍为什么存在智能合约和链码以及如何以及何时使用它们。
在本主题中，我们将介绍：
- 什么是智能合约
- 术语说明
- 智能合约和帐三个
- 如何开发智能合约
- 背书策略的重要性
- 有效交易
- 智能合约和通道
- 智能合约之间的通信
- 什么是系统链码？
1. 智能合约
在业务彼此之间进行交易之前，他们必须定义一组通用合约，涵盖通用条款，数据，规则，概念定义和流程。这些合约放在一起，构成了控制交易双方之间所有交互的业务模型。
智能合约以可执行代码定义了不同组织之间的规则。应用程序调用智能合约以生成记录在账本上的交易。
使用区块链网络，我们可以将这些合约转换为可执行程序 (在业界称为智能合约)，以开辟各种新的可能性。这是因为智能合约可以为任何类型的业务对象实施治理规则，以便在执行智能合约时可以自动执行这些规则。例如，智能合约可以确保在指定的时间范围内完成新车交付，或者确保按照预先安排的条款释放资金，从而分别改善了货物或资金的流动。但是，最重要的是，智能合约的执行比人工业务流程要高效得多。
在上图中，我们可以看到 ORG1 和 ORG2 这两个组织如何定义了汽车智能合约来查询，转让和更新汽车。这些组织的应用程序调用此智能合约在业务流程中执行约定的步骤，例如将特定汽车的所有权从 ORG1 转移到 ORG2。
2. 术语
Hyperledger Fabric 用户经常互换使用术语智能合约和链码。通常，智能合约定义了控制世界状态中包含的业务对象生命周期的交易逻辑。然后将其打包成链码，然后将其部署到区块链网络。可以将智能合约视为管理交易，而链码则可以控制如何打包智能合约以进行部署。
智能合约在链码中定义。可以在同一链码中定义多个智能合约。部署链码后，其中的所有智能合约都可用于应用程序。
在上图中，我们可以看到一个包含三个智能合约的车辆 (vehicle) 链码：汽车 (cars)，船只 (boats) 和卡车 (trucks)。我们还可以看到包含四个智能合约的保险 (insurance) 链码：保单 (policy)，责任 (liablility)，银团 (syndication) 和证券化 (securitization)。在这两种情况下，这些合同均涉及与车辆和保险有关的业务流程的关键方面。在本主题中，我们将以汽车 (car) 合约为例。我们可以看到，智能合约是与特定业务流程相关的特定于域的程序，而链码是一组用于安装和实例化的相关智能合约的技术容器。
3. 账本
在最简单的层次上，区块链一成不变地记录更新账本中状态的交易。智能合约以编程方式访问账本的两个不同部分：一个区块链，它不变地记录所有交易的历史记录；一个世界状态，保存着这些状态的当前值缓存，因为它是对象通常需要的当前值。
智能合约主要在世界状态下放置 (put)，获取 (get) 和删除 (delete) 状态，并且还可以查询不可变的区块链交易记录。
- 获取 (get) 通常代表查询以检索有关业务对象当前状态的信息。
- 放置 (put) 通常会创建新的业务对象或修改帐本世界状态中的现有业务对象。
- 删除 (delete) 通常表示从帐本的当前状态中删除业务对象，但不删除其历史记录。
智能合约有许多可用的 API。至关重要的是，在所有情况下，无论交易是在世界状态下创建，读取，更新还是删除业务对象，区块链都包含这些更改的 不可变记录。
4. 开发
智能合约是应用程序开发的重点，正如我们已经看到的，可以在单个链码中定义一个或多个智能合约。将链码部署到网络后，该网络中的所有组织均可使用其所有智能合约。这意味着只有管理员才需要担心链码。其他人都可以根据智能合约进行思考。
智能合约的核心是一组交易定义。例如，查看 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)));
}
你可以在 编写第一个应用程序教程 中了解有关 Fabcar 智能合约的更多信息。
智能合约可以描述与多组织决策中的数据不变性相关的几乎无限的业务用例。智能合约开发人员的工作是采用可能控制金融价格或交付条件的现有业务流程，并以诸如 JavaScript，GOLANG 或 Java 的编程语言将其表示为智能合约。智能合约审核员越来越多地练习将数百年的法律语言转换为编程语言所需的法律和技术技能。你可以在 开发应用程序主题 中了解如何设计和开发智能合约。
5. 背书
与每个链码相关联的是一种背书策略，该策略适用于其中定义的所有智能合约。背书非常重要；它指示区块链网络中的哪些组织必须签署由给定智能合约生成的交易，才能将该交易宣布为有效。
每个智能合约都有与其相关的背书策略。该背书策略可确定哪些组织必须批准智能合约生成的交易，然后才能将其确认为有效交易。
示例性背书策略可能定义了参与区块链网络的四个组织中的三个必须在一笔交易被视为有效之前对其进行签名。所有有效或无效交易都将添加到分布式帐本中，但只有有效交易会更新世界状态。
如果背书策略指定必须由多个组织签署交易，则必须由足够多的组织来执行智能合约，以便生成有效的交易。在上面的示例中，转让汽车的智能合约交易需要由 ORG1 和 ORG2 执行并签名，以使其有效。
背书策略使 Hyperledger Fabric 与以太坊或比特币等其他区块链有所不同。在这些系统中，网络中的任何节点都可以生成有效的交易。Hyperledger Fabric 更现实地模拟了现实世界；交易必须由网络中的受信任组织验证。例如，管理组织必须签署有效的 issueIdentity 交易，或者汽车的买 (buyer) 卖 (seller) 双方都必须签署汽车 (car) 转让交易。背书策略旨在使 Hyperledger Fabric 能够更好地对这些类型的实际交互进行建模。
最后，背书策略只是 Hyperledger Fabric 中策略的一个示例。可以定义其他策略以标识谁可以查询或更新帐本，或从网络中添加或删除参与者。一般而言，尽管不是一成不变的，但策略应由区块链网络中的联盟组织事先达成协议。实际上，策略本身可以定义可以更改策略的规则。尽管是高级主题，但也可以在 Fabric 提供的规则之外定义 自定义背书策略 规则。
6. 有效交易
当智能合约执行时，它在区块链网络中的一个组织拥有的对端节点上运行。合约采用一组称为交易提案的输入参数，并将其与程序逻辑结合使用以读取和写入帐本。对世界状态的更改被捕获为交易提案响应 (或仅仅是交易响应)，其中包含一个读写集 (read-write set)，其中包含已读取的状态以及如果交易有效将要写入的新状态。请注意，执行智能合约时世界状态不会更新！
[图片上传失败...(image-4ff111-1575546689004)]
所有交易都具有由一组组织签名的标识符，提案和响应。所有交易均记录在区块链上，无论其有效与否，但只有有效交易才能更新世界状态。
检查 car transfer 交易。你可以看到在 ORG1 和 ORG2 之间进行汽车转移的交易 t3。查看交易如何输入 {CAR1，ORG1，ORG2} 并输出 {CAR1.owner = ORG1，CAR1.owner = ORG2}，表示所有者从 ORG1 变为 ORG2。请注意，输入是由应用程序的组织 ORG1 签名的，输出是由背书策略 ORG1 和 ORG2 标识的两个组织签名的。这些签名是通过使用每个参与者的私钥生成的，意味着网络中的任何人都可以验证网络中的所有参与者是否都同意交易细节。
分两个阶段验证分发给网络中所有对端节点的交易。首先，检查交易，以确保有足够的组织根据背书策略签署了该交易。其次，检查以确保世界状态的当前值与由对端节点签名的交易的读取集相匹配；没有中间更新。如果交易通过了这两个测试，则将其标记为有效。所有交易都会添加到区块链历史记录中，无论有效与否，但只有有效交易才会导致世界状态的更新。
在我们的示例中，t3 是有效交易，因此 CAR1 的所有者已更新为 ORG2。但是，t4 (未显示) 是无效交易，因此，尽管将其记录在帐本中，但世界状态并未更新，CAR2 仍归 ORG2 所有。
最后，要了解如何在世界状态下使用智能合约或链码，请阅读 链码命名空间主题。
7. 通道
Hyperledger Fabric 允许组织通过通道同时参与多个独立的区块链网络。通过加入多个通道，组织可以参与所谓网络的网络。通道可有效共享基础架构，同时保持数据和通信的隐私。它们足够独立，可以帮助组织与不同的交易对手分离其工作量，但又足够集成，可以在必要时协调独立的活动。
通道在一组组织之间提供了完全独立的通信机制。在通道上实例化链码时，将为其定义背书策略。链码中的所有智能合约均可供该通道上的应用程序使用。
管理员在通道上实例化链码时为其定义了背书策略，并且可以在链码升级时对其进行更改。背书策略同样适用于在部署到通道的同一链码中定义的所有智能合约。这也意味着可以将单个智能合约部署到具有不同背书策略的不同通道。
在上面的示例中，汽车合约已部署到 VEHICLE 通道，保险合约已部署到 INSURANCE 通道。汽车合约的背书策略要求 ORG1 和 ORG2 在被视为有效之前签署交易，而保险合约的背书策略仅要求 ORG3 签署有效交易。 ORG1 参与两个网络，即 VEHICLE 通道和 INSURANCE 网络，并且可以分别通过 ORG2 和 ORG3 协调这两个网络之间的活动。
8. 互通
智能合约可以在同一通道内和不同通道之间调用其他智能合约。这样，他们可以读取和写入由于智能合约命名空间而无法访问的世界状态数据。
合约间通信存在局限性，在 链码命名空间 主题中已对此进行了全面介绍。
9. 系统链码
链码中定义的智能合约对一组区块链组织之间达成共识的业务流程的域相关规则进行编码。但是，链码还可以定义与领域无关的系统交互相对应的低级程序代码，而这些交互与业务流程的智能合约无关。
以下是不同类型的系统链码及其相关的缩写：
- 生命周期系统链码 (Lifecycle system chaincode, LSCC) 在所有对端节点中运行，以处理程序包签名，安装，实例化和升级链码请求。你可以阅读有关 LSCC 实现此 过程 的更多信息。
- 配置系统链码 (Configuration system chaincode, CSCC) 在所有对端节点中运行，以处理对通道配置的更改，例如策略更新。你可以在以下链码 主题 中阅读有关此过程的更多信息。
- 查询系统链码 (Query system chaincode, QSCC) 在所有对端节点运行提供账本的 API，其中包括区块查询，交易查询等，你可以在交易方面的 话题 了解更多有关这些帐本 API。
- 背书系统链码 (Endorsement system chaincode, ESCC) 在背书对端节点以加密方式签署交易响应时运行。你可以阅读有关 ESCC 如何实施此 过程 的更多信息。
- 验证系统链码 (Validation system chaincode, VSCC) 验证交易，包括检查背书策略和读写集版本控制。你可以阅读有关 LSCC 实现此 过程 的更多信息。
底层 Fabric 开发人员和管理员可以修改这些系统链码以供自己使用。但是，系统链码的开发和管理是一项专门的活动，与智能合约的开发完全分开，通常不需要。对系统链码的更改必须格外小心，因为它们对于 Hyperledger Fabric 网络的正常运行至关重要。例如，如果未正确开发系统链码，则一个对端节点可能会与另一对端节点不同地更新其世界状态或区块链的副本。缺乏共识是账本分叉的一种形式，这是非常不理想的情况。
Reference
- Docs » Key Concepts » Smart Contracts and Chaincode, https://hyperledger-fabric.readthedocs.io/en/release-1.4/smartcontract/smartcontract.html
- Docs » Developing Applications » Application design elements » Transaction context, https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/transactioncontext.html#structure
- Docs » Key Concepts » Ledger, https://hyperledger-fabric.readthedocs.io/en/release-1.4/ledger/ledger.html
- Docs » Tutorials » Writing Your First Application, https://hyperledger-fabric.readthedocs.io/en/release-1.4/write_first_app.html
- Docs » Developing Applications, https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/developing_applications.html
- Docs » Operations Guides » Pluggable transaction endorsement and validation, https://hyperledger-fabric.readthedocs.io/en/release-1.4/pluggable_endorsement_and_validation.html
- Docs » Developing Applications » Application design elements » Chaincode namespace, https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/chaincodenamespace.html
- Docs » Developing Applications » Application design elements » Chaincode namespace, https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/chaincodenamespace.html#cross-chaincode-access
项目源代码
项目源代码会逐步上传到 Github，地址为 https://github.com/windstamp。
Contributor
- Windstamp, https://github.com/windstamp
