Hyperledger Fabric 相关概念

Ledger（账本）

账本是所有状态转换的顺序，防篡改记录。状态转换是参与方提交的chaincode调用（“transaction”）的结果。每个transaction都会产生一组资产键值对，这些对象将作为创建，更新或删除而提交给账本。

账本由blockchain（’chain’）组成，用于存储块不可变的、有序的记录，以及状态数据库来保持当前状态。每个channel有一个账本。每个peer为他们所属的每个通道保留账本的副本。

Chain（链）

链是transaction日志，其结构为哈希链接块，其中每个块包含N个transaction的序列。块头包括块的transaction的散列，以及先前块的头的散列。以这种方式，账本上的所有交易都被排序并加密地链接在一起。换句话说，不可能在不破坏散列链接的情况下篡改账本数据。最新块的散列表示之前的每个transaction，使得可以确保所有peer处于一致和可信状态。 该链存储在对等文件系统（本地或附加存储）上，有效地支持blockchain工作负载的只追加（append-only）属性。

State Database（状态数据库 ）

账本的当前状态数据表示在链式transaction日志中的所有键的最新值。由于当前状态表示channel已知的所有最新键值对，因此有时称为“world state”（世界状态）。

chaincode调用根据当前状态数据执行transaction。为了使这些chaincode交互非常有效，所有键的最新值都存储在状态数据库中。状态数据库只是transaction日志的索引视图，因此可以随时从链中重新生成。在transaction接受之前，状态数据库将在peer启动时自动恢复（或需要时生成）。

Transaction Flow（交易流程）

在high level上，交易流程由应用客户端发送给特定背书节点的transaction proposal组成。背书节点验证客户端签名，并执行chaincode功能来模拟transaction。输出是链码结果，在链码（读集）中读取的一组键/值版本以及以链码（写集）编写的一组键/值。带有背书签名的proposal响应将被发送回客户端。 客户端将签名装配到transaction有效负载中并将其广播到ordering服务。ordering服务将有序交易作为块传送到这个通道上的所有peers。

在交付之前，peers将验证交易。首先，他们将检查背书策略，以确保指定peer已经对结果进行了签名，并且将根据交易有效负载来验证签名。

其次，peers将针对交易读集执行版本检查，以确保数据的完整性，并防止双花等威胁。Hyperledger Fabric具有并发控制，其中transaction并行执行（通过背书节点）以增加吞吐量，并且在提交（由所有peers）每个transaction时，每个transaction都被验证，以确保没有其他transaction已经修改了已读取的数据。换句话说，它确保在chaincode执行（背书）期间需要读取的数据没有改变，因此执行结果有效，并且可以提交到账本状态数据库。如果读取的数据已被其他transaction更改，则块中的transaction被标记为无效，并且不会写入账本状态数据库。客户端应用程序被提醒，然后可以控制错误或重新尝试。

请参阅Transaction Flow和Read-Write set semantics，以便更深入地了解transaction结构，并发控制和状态数据库。

State Database options（状态数据库选项）

状态数据库选项包括LevelDB和CouchDB（beta）。LevelDB是内置的默认密钥/值状态数据库。CouchDB是可选的外部状态数据库。像LevelDB键/值存储一样，CouchDB可以存储以chaincode建模的任何二进制数据（CouchDB附件功能在内部用于非JSON二进制数据）。但作为一个JSON文档型数据库，当chaincode值（例如资产）被建模为JSON数据时，CouchDB还可以对chaincode数据进行rich query。

LevelDB和CouchDB都支持核心chaincode操作，例如获取和设置key（资产），以及基于key的查询。可以对key进行range query，并且可以构建复合键来实现对多个参数的等价查询。例如，（owner，asset_id）的组合键可用于查询某个实体拥有的所有资产。这些基于key的查询可以用于对账本的只读查询，也可用于更新账本的transaction。 如果您将资产建模为JSON并使用CouchDB，则还可以使用chaincode中的CouchDB JSON查询语言对chaincode数据执行复杂的rich queries。这些类型的查询非常适合了解账本上的内容。对于这些类型的查询的proposal响应通常对客户端应用程序有用，但通常不会作为交易提交给ordering service。实际上，不能保证结果集在chaincode执行和rich query的提交时间之间是稳定的，因此rich queries不适合用于更新transaction，除非你的应用程序可以保证结果集在chaincode执行和提交之间是稳定的，或者可以在后续交易中处理潜在的变化。例如， 你执行了一个rich query来搜索Alice的所有资产，并要把他们转给Bob，在chaincode执行和提交的时间之间，一个新的资产可能被另一个transaction分配给了Alice，有可能会丢失这个资产。

CouchDB作为独立的数据库进程与peer一起运行，因此在设置，管理和操作方面还有其他注意事项。你可以考虑从默认的LevelDB开始，如果需要额外的复杂的rich query，请转到CouchDB。将chaincode资产数据模型化为JSON是一个很好的做法，因此您可以选择在将来需要时执行复杂的rich query。 要启用CouchDB作为状态数据库，请配置/fabric/sampleconfig/core.yaml stateDatabase 部分。

如果有转载请注明出处！

[英文原版]

Ledger