应用程序开发 - 流程和数据设计

本主题向你展示如何在 PaperNet 中设计商业票据流程及其相关的数据结构。我们的分析强调，使用状态和交易对 PaperNet 进行建模可以提供一种精确的方式来了解正在发生的事情。现在，我们将详细说明这两个紧密相关的概念，以帮助我们随后设计 PaperNet 的智能合约和应用程序。

1. 生命周期

如我们所见，在处理商业票据时，有两个重要的概念与我们有关。状态和交易。确实，对于所有区块链用例都是如此。有一些以状态为模型的值概念对象，其生命周期转换由交易描述。对状态和交易进行有效分析是成功实现的重要起点。

我们可以使用状态转换图来表示商业票据的生命周期：

image

商业票据的状态转换图。商业票据通过发行，购买和赎回交易在发行，交易和赎回状态之间转换。

查看状态图如何描述商业票据如何随时间变化，以及特定交易如何控制生命周期转换。在 Hyperledger Fabric 中，智能合约实现了交易逻辑，可以在不同状态之间转换商业票据。商业票据状态实际上是在帐本世界状态中保存的；因此，让我们仔细看看它们。

2. 账本状态

回忆一下商业票据的结构：

image

商业票据可以表示为一组属性，每个属性都有一个值。通常，这些属性的某种组合将为每张票据提供唯一的键。

查看商业票据 Paper 属性的值是 00001，Face value 属性的值是 5M USD。最重要的是，当前状态属性指示商业票据是已发行，交易还是已赎回。结合起来，全套属性构成了商业票据的状态。而且，这些单独的商业票据状态的整个集合构成了帐本 世界状态。

所有帐本都共享此形式；每个都有一组属性，每个属性都有不同的值。状态的这种多属性方面是一个强大的功能 – 它使我们可以将 Fabric 状态视为向量而不是简单的标量。然后，我们将有关整个对象的事实表示为单独的状态，随后这些状态会受到交易逻辑控制的转换。Fabric 状态被实现为键/值对，其中值以捕获对象的多个属性 (通常为 JSON) 的格式对对象属性进行编码。帐本数据库 可以支持针对这些属性的高级查询操作，这对于复杂的对象检索非常有帮助。

查看 MagnetoCorp 的票据 00001 如何表示为状态向量，该状态向量会根据不同的交易驱动而转变：

image

商业票据状态由于不同的交易而存在并转变。Hyperledger Fabric 状态具有多个属性，使其成为向量而不是标量。

请注意，每张票据都是从空状态开始的，从技术上讲，它是零状态，因为它不存在！了解发行交易如何使票据 00001 产生，以及随后由于购买和赎回交易而对其进行更新。

注意每个状态如何自我描述；每个属性都有一个名称和一个值。尽管目前我们所有的商业票据都具有相同的属性，但并非总是如此，因为 Hyperledger Fabric 支持具有不同属性的不同状态。这允许同一帐本世界状态包含同一资产的不同形式以及不同类型的资产。它还可以更新状态的结构；想象一个需要附加数据字段的新规则。灵活的状态属性支持随时间推移数据演变的基本要求。

3. 状态键

在大多数实际应用中，状态将具有属性的组合，这些属性可以在给定的上下文中唯一地标识它 - 这是关键。 PaperNet 商业票据的键是由 Issuer 和 paper 属性的串联形成的。因此对于 MagnetoCorp 的第一份票据，是 MagnetoCorp00001。

状态键使我们能够唯一地识别票据。它是通过发行交易创建的，随后通过购买和赎回进行更新。 Hyperledger Fabric 要求账本中的每个状态都有唯一的键。

如果在可用属性集中没有唯一键，则将应用程序确定的唯一键指定为创建状态的交易的输入。此唯一键通常带有某种形式的 UUID，尽管可读性较差，但它是标准做法。重要的是，帐本中的每个状态对象都必须具有唯一的键。

注意：应避免在键中使用 U+0000 (无字节)。

4. 多状态

如我们所见，PaperNet 中的商业票据作为状态向量存储在帐本中。能够从账本查询不同的商业票据是一项合理的要求；例如：查找由 MagnetoCorp 发布的所有票据，或：查找处于赎回状态的 MagnetoCorp 发布的所有票据。

为了使这些搜索任务成为可能，将所有相关票据归为一个逻辑列表会很有帮助。PaperNet 的设计结合了商业票据清单的概念 – 一个逻辑容器，每当发行商业票据或进行其他更改时，逻辑容器都会更新。

4.1 逻辑表示

将所有 PaperNet 商业票据都放在一个商业票据列表中会很有帮助：

image

MagnetoCorp 新创建的商业票据 00004 已添加到现有商业票据列表中。

发行交易可以将新票据添加到列表中，并且可以使用购买或赎回交易来更新列表中已有的票据。查看列表如何使用描述性名称：org.papernet.papers；使用这种 DNS 名称是一个非常好的主意，因为精心选择的名称将使你的区块链设计对其他人来说很直观。这个想法同样适用于 智能合约名称。

4.2 物理表示

虽然在 PaperNet 中只考虑一个文件列表是 org.papernet.papers 是正确的，但最好将列表实现为一组单独的 Fabric 状态，其组合键将状态与其列表相关联。这样，每个状态的组合键都是唯一的，并支持有效的列表查询。

将 PaperNet 商业票据的列表表示为一组不同的 Hyperledger Fabric 状态。

请注意，列表中的每篇票据如何用向量状态表示，并具有由 org.papernet.paper，Issuer 和 Paper 属性串联而成的唯一复合键。此结构很有用，其原因有两个：

• 它使我们能够检查帐本中的任何状态向量，从而确定其在哪个列表中，而无需参考单独的列表。这类似于看一组体育迷，然后根据所穿衬衫的颜色来确定他们支持的球队。体育迷们自称忠诚。我们不需要粉丝列表。
• Hyperlegder Fabric 在内部使用 并发控制机制 来更新帐本，这样将票据保持在单独的状态向量中就大大减少了共享状态冲突的机会。这样的冲突需要重新提交交易，使应用程序设计复杂化，并降低性能。

第二点实际上是 Hyperledger Fabric 的关键要素。状态向量的物理设计对于优化性能和行为非常重要。让你的状态分开！

5. 信任关系

我们已经讨论了网络中的不同角色 (例如发行人，交易者或评估机构) 以及不同的商业利益如何决定谁需要签署交易。在 Fabric 中，这些规则由所谓的 背书策略 捕获。可以在链码粒度以及各个状态键上设置规则。

这意味着在 PaperNet 中，我们可以为整个命名空间设置一个规则，该规则确定哪些组织可以发布新票据。之后，可以为各个票据设置和更新规则，以捕获购买和赎回交易的信任关系。

在下一个主题中，我们将向你展示如何结合这些设计概念来实现 PaperNet 商业票据智能合约，然后在其中进行应用！

Reference

• Docs » Developing Applications » Process and Data Design, https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/architecture.html
• Docs » Key Concepts » Ledger, https://hyperledger-fabric.readthedocs.io/en/release-1.4/ledger/ledger.html#world-state
• Docs » Developing Applications » Application design elements » Contract names, https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/contractname.html
• Docs » Architecture Reference » Architecture Origins, https://hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#the-endorsing-peer-simulates-a-transaction-and-produces-an-endorsement-signature
• Docs » Developing Applications » Application design elements » Endorsement policies, https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/endorsementpolicies.html

项目源代码

项目源代码会逐步上传到 Github，地址为 https://github.com/windstamp。

Contributor

1. Windstamp, https://github.com/windstamp