Hyperledger Fabric架构提供以下优点：
1.链码信任的灵活性。该架构将链码（块链应用）的信任假设与信任假设进行排序。换句话说，订购服务可以由一组节点（订单者）提供，并且容许他们中的一些节点出现故障或不正当行为，并且支持者对于每个链码可能是不同的。
2.可扩展性。由于负责特定链码的支持者节点与订户正交，所以系统可能比这些功能由相同节点完成的更好。特别地，当不同的链码指定不相交的支持者时，会产生这种结果，该代码引入了支持者之间的链式代码的划分，并允许并行的链码执行（背书）。此外，从代码订购服务的关键路径中删除可能成本高昂的链码执行。
3.保密。该架构便于部署具有关于其事务的内容和状态更新的机密性要求的链码。
4.共识模块化。该架构是模块化的，并允许可插拔的一致性（即订购服务）实现。
第一部分：与Hyperledger Fabric v1相关的架构元素：系统架构、交易背书的基本工作流程、认可政策
第二部分：架构的Post-v1元素：分类帐检查点（修剪）
一、系统架构
块链是由许多节点组成的分布式系统，它们彼此通信。块链运行称为chaincode的程序，保存状态和分类帐数据，并执行事务。链码是中间元素，因为事务是在链码上调用的操作。交易必须“认可”，只有认可的交易可能会对状态产生影响。可能存在用于管理功能和参数的一个或多个特殊链码，统称为系统链码。
1.1、交易
交易有两种类型：
交易有两种类型：
a、部署事务创建新的链码，并以程序为参数。当部署事务成功执行时，链码已被安装在块上。
b、调用事务在先前部署的链码的上下文中执行操作。调用事务是指链码及其提供的一个功能。当成功时，链码执行指定的功能 - 这可能涉及修改相应的状态，并返回一个输出。
如后所述，部署事务是调用事务的特殊情况，其中创建新链码的部署事务对应于系统链码上的调用事务。
备注：本文档目前假设事务创建新的链码，或者调用*已经部署的链码提供的操作。本文档还没有描述：a）查询（只读）交易的优化（包含在v1中），b）支持交链代码交易（post-v1功能）*
1.2、区块链数据结构
块（或简单的状态）的最新状态被建模为版本化键/值存储（KVS），其中键是名称，值是任意的blob。这些条目由通过放置运行在块链上的链码（应用程序）进行操作，并获得KVS操作。状态被持久存储，并且状态的更新被记录。注意，版本化KVS被采用为状态模型，实现可能使用实际的KVS，也可以使用RDBMS或任何其他解决方案。
正式地，状态S 被建模为映射K - >（V X N）的元素，其中：
K是一组键
V是一组值
N是版本号的无限有序集合。注入函数next：N - > N取N的元素并返回下一个版本号。
V和N都包含一个特殊元素 bot，这在N是最低元素的情况下。最初所有的键映射到（ bot， bot）。对于s（k）=（v，ver），我们用s（k），vue表示v，由s（k）表示v。
KVS操作模型如下：
put（k，v），对于k中的k和v中的V，获取块状态，并将其改变为s'，使得s'(k)=(v,next(s(k).version))对于所有k'!=k返回s'(k')=s(k')
get(k) 返回 s(k) 状态通过peers维护，但不是orderers and clients。
状态分区。KVS中的密钥可以从其名称识别为属于特定的链码，因为只有特定链码的事务可以修改属于该链码的密钥。原则上，任何链码都可以读取属于其他链码的密钥。支持交链代码交易，修改属于两个或更多链码的状态是一个post-v1功能。
1.2.2、账本
分类帐提供了所有成功的状态变化（有效的交易）和在系统运行过程中出现的不成功的改变状态的尝试（无效的事务）。。
分类帐由ordering服务构建（见第1.3.3节）作为（有效或无效）交易的块的完全有序的散列。散列链将块的总顺序施加在分类帐中，每个块包含完全有序事务的数组。这对所有交易都施加了整个订单。
分类帐被保留在所有peer，并且可选地在一些order的子集。在订阅者的上下文中，我们将分类帐称为OrdererLedger，而在对等体的上下文中，我们将分类帐称为PeerLedger。PeerLedger与OrdererLedger不同之处在于，对等体本地保留了一个位掩码，它将有效的事务从无效的事务中分离出来（详见第XX部分）。
Peer可以修整PeerLedger，如第XX部分（post-v1功能）中所述。Orderers维护OrdererLedger的容错和可用性（PeerLedger），并可以随时修改它，只要订购服务的属性（见第1.3.3节）得到维护。
分类帐允许对等体重播所有交易的历史记录并重建状态。因此，第1.2.1节所述的状态是可选的数据结构。
1.3、节点
节点是块链的通信实体。在不同类型的多个节点可以在同一物理服务器上运行的意义上，“节点”只是逻辑功能。重要的是如何将节点分组在“信任域”中并与控制它们的逻辑实体相关联。
有三种类型的节点：
1.Client or submitting-client：提交一个实际交易调用的背书，并且广播交易提议到ordering service。
2.Peer：提交交易并维护分类帐的状态和副本的节点（见1.2）。除此之外，peer是一个特殊的背书角色。
3.Ordering-service-node or orderer：运行通信服务的节点，其实现递送保证，例如原子或总订单广播。
1.3.1、client
客户端代表代表最终用户的实体。他必须连接到一个用于块链通讯peer节点。客户端可以连接到所选择的任何peer节点。客户创建并调用交易。
1.3.2、Peer
Peer节点通过ordering service以block的形式接收有序的状态更新，并且维持状态和分类帐。
另外Peer也能是一个背书角色，背书Peer节点的特殊功能是能触发特定的链码，包括在提交前背书一个交易。每个链码都可以指定背书政策，并且指定背书peer节点。该协议定义了一个背书的充要条件（背书签名），稍后2,3展示。部署交易的特殊案例，安装一个新的链码，背书协议是一个特殊的系统背书协议。
1.3.3、Ordering service nodes (Orderers)
即提供交付保证的通信结构。Ordering Service可以以不同的方式实现：范围从集中式服务（例如，在开发和测试中）到针对不同网络和节点故障模型的分布式协议。
ordering service为client和peer提供了一个共享的通讯channel，为包含交易的消息提供广播服务。客户端连接到通道，并可以在通道上广播消息，然后传送给所有Peer节点[对等体]。该通道支持所有消息的原子传递，即具有全面订单传送和（具体实现）可靠性的消息通信。换句话说，信道向所有连接的peer[对等体]输出相同的消息，并以相同的逻辑顺序将其输出到所有Peer[对等体]。这种原子通信保证在分布式系统的上下文中也称为总命令广播，原子广播或共识。被传递的消息是blockchain列入候选交易状态。
分区（ordering service channels）。Ordering Service 可以支持与发布/订阅（pub / sub）消息系统的主题相似的多个频道。客户端可以连接到给定的通道，然后可以发送消息并获取到达的消息。通道可以被认为是分区 - 连接到一个通道的客户端不知道其他通道的存在，但客户端可能连接到多个通道。即使Hyperledger Fabric中包含的某些订购服务实现支持多个通道，为了简单的呈现，在本文的其余部分中，我们假设订购服务由单个通道/主题组成。
Ordering service API，peers节点通过Ordering Service提供的接口连接到订购服务提供的通道。Ordering Service API由两个基本操作（通常异步事件）组成：
TODO：添加了用于在客户端/Peer指定的序列号下获取特定块的API的一部分。
broadcast(blob):一个客户端调用任意一个消息在通道上广播。当向服务发送请求时，这也称为BFT上下文中的请求（blob）。
deliver(seqno, prevhash, blob)：Ordering service 在Peer上调用此命令以指定的非负整数序列号（seqno）和最近传送的blob（prevhash）的散列来传递消息blob。换句话说，他是来自Ordering service的输出事件。delivery（）有时在pub-sub系统中称为notify（），或者在BFT系统中称为commit（）。
分类账和快构造。分类帐（参见第1.2.2节）包含Ordering Service 输出的所有数据。简单的说，他是deliver(seqno, prevhash, blob)事件的序列，它根据前面描述的prevhash的计算形成一个哈希链。
大多数情况下，出于效率原因，ordering service将不会输出单个交易（blob），而是在单个交付事件中分组（批处理）blob和输出块。这种情况下，ordering service必须为每个block，强制传递一个确定排序的blob。可以通过排序服务实现动态地选择块中的块的数量。
在下文中，为了方便介绍，我们定义了ordering service属性（本小节的其余部分），并解释了交易背书的工作流程（第2节），假设每个交付事件有一个blob。这些容易地扩展到块，假设块的递送事件对应于块内每个块的单个递送事件的序列，根据上述块内的团块的确定性排序。