Fabric官方文档--Key Concepts--Smart Contracts and Chaincode

从应用程序开发人员的角度来看，智能合约与分类帐一起构成了Hyperledger Fabric区块链系统的核心。

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

管理员通常使用链码对相关的智能合约进行分组以进行部署，但也可以将其用于Fabric的低级系统编程。 在本主题中，我们将重点介绍为什么存在智能合约和链码以及如何以及何时使用它们。

1.1 智能合约

在业务彼此之间进行交易之前，他们必须定义一组通用合同，涵盖通用条款，数据，规则，概念定义和流程。 总而言之，这些合同奠定了管理交易双方之间所有交互的业务模型。

智能合约在可执行代码中定义了不同组织之间的规则。 应用程序调用智能合约以生成记录在分类账上的交易。

使用区块链网络，我们可以将这些合同转换为可执行程序（在业界称为智能合同），以开辟各种新的可能性。 这是因为智能合约可以为任何类型的业务对象实施治理规则，因此在执行智能合约时可以自动执行这些规则。 例如，智能合约可以确保在指定的时间范围内完成新车交付，或者确保按照预先安排的条款释放资金，从而分别改善了货物或资金的流动。 但是，最重要的是，智能合约的执行比人工人工业务流程的执行效率要高得多。

在上图中，我们可以看到ORG1和ORG2这两个组织如何定义了汽车智能合约来查询，转让和更新汽车。 这些组织的应用程序调用此智能合约在业务流程中执行约定的步骤，例如将特定汽车的所有权从ORG1转移到ORG2。

1.2 术语

Hyperledger Fabric用户经常互换使用术语智能合约和链码。 通常，智能合约定义了控制世界状态中包含的业务对象生命周期的交易逻辑。 然后将其打包成链码，然后将其部署到区块链网络。 将智能合约视为支配交易，而链码则控制如何将智能合约打包以进行部署

智能合约在链码中定义。 可以在同一链码中定义多个智能合约。 部署了链码后，其中的所有智能合约均可供应用程序使用。

在该图中，我们可以看到一个包含三个智能合约的车辆链码：汽车，船只和卡车。 我们还可以看到包含四个智能合约的保险链代码：保单，责任，银团和证券化。 在这两种情况下，这些合同均涉及与车辆和保险有关的业务流程的关键方面。 在本主题中，我们将以汽车合同为例。 我们可以看到，智能合约是与特定业务流程相关的领域特定程序，而链码是一组相关智能合约的技术容器。

1.3 账本

在最简单的级别上，区块链一成不变地记录更新账本中状态的交易。 智能合约以编程方式访问总账的两个不同部分：一个区块链，该区块不可变地记录所有交易的历史记录；一个世界状态，保存这些状态的当前值缓存，因为它通常是对象需要的当前值。

智能合约主要在世界状态下put、get、delete，还可以查询不可变的区块链交易记录。

• get 通常代表查询以检索有关业务对象当前状态的信息。
• put 通常会创建新的业务对象或修改分类帐世界状态中的现有业务对象。
• delete 通常表示从分类帐的当前状态中删除业务对象，但不表示其历史记录

智能合约有许多可用的API。 至关重要的是，在所有情况下，无论交易是在世界状态下创建，读取，更新还是删除业务对象，区块链都包含这些更改的不可变记录。

1.4 Development

智能合约是应用程序开发的重点，正如我们已经看到的，可以在单个链码中定义一个或多个智能合约。 将Chaincode部署到网络后，该网络中的所有组织均可使用其所有智能合约。 这意味着只有管理员才需要担心链码。 其他人都可以根据智能合约进行思考。

智能合约的核心是一组交易定义。 例如，在此处查看assetTransfer.js，您可以在其中看到创建新资产的智能合约交易：

async CreateAsset(ctx, id, color, size, owner, appraisedValue) {
        const asset = {
            ID: id,
            Color: color,
            Size: size,
            Owner: owner,
            AppraisedValue: appraisedValue,
        };
        return ctx.stub.putState(id, Buffer.from(JSON.stringify(asset)));
    }

您可以在“运行Fabric应用程序”教程中了解有关Basic智能合约的更多信息。

智能合约可以描述与多组织决策中的数据不变性相关的几乎无限的业务用例。 智能合约开发人员的工作是采用可能控制金融价格或交付条件的现有业务流程，并以诸如JavaScript，Go或Java之类的编程语言将其表示为智能合约。 精明的合同审核员越来越多地练习将数百年的法律语言转换为编程语言所需的法律和技术技能。 您可以在“开发应用程序”主题中了解如何设计和开发智能合约。

1.5 Endorsement

与每个链码相关联的是一种背书策略，该策略适用于其中定义的所有智能合约。 背书政策非常重要，它指示区块链网络中的哪些组织必须签署由给定智能合约生成的交易才能将该交易宣布为有效。

每个智能合约都有与之相关的背书策略。 该背书策略可确定哪些组织必须批准由智能合约生成的交易，然后才能将其识别为有效交易。

背书策略示例可以定义参与区块链网络的四个组织中的三个必须在一笔交易被视为有效之前对其进行签名。 所有有效或无效交易都将添加到分布式分类帐中，但只有有效交易会更新世界状态。

如果背书策略指定必须由多个组织签署交易，则智能合约必须由足够多的组织执行才能生成有效交易。 在上面的示例中，转移汽车的智能合约交易需要由ORG1和ORG2执行并签名，以使其生效。

代言政策使Hyperledger Fabric与以太坊或比特币等其他区块链有所不同。 在这些系统中，网络中的任何节点都可以生成有效的交易。 Hyperledger Fabric更现实地模拟了现实世界； 交易必须由网络中受信任的组织进行验证。 例如，政府组织必须签署有效的签发身份交易，或者汽车的买卖双方都必须签署汽车转让交易。 背书策略旨在使Hyperledger Fabric能够更好地对这些类型的实际交互进行建模。

最后，背书策略只是Hyperledger Fabric中策略的一个示例。 可以定义其他策略以标识谁可以查询或更新分类帐，或从网络中添加或删除参与者。 一般而言，尽管不是一成不变的，但是政策应该由区块链网络中的组织财团事先达成协议。 实际上，策略本身可以定义可以更改策略的规则。 尽管是高级主题，但也可以在Fabric提供的规则之外定义自定义认可策略规则。

1.6 Valid transactions

1.7 Channels

1.8 Intercommunication

1.9 System chaincode