这个章节描述了Hyperledger Fabric的关键设计功能，实现了其全面但可定制的企业级区块链解决方案的承诺:
- 资产----资产定义是能过通过网络交换获得的任何具有货币价值的东西，从食品到古董车到货币期货。
- 链码---链码的执行是从交易排序中分离的，限制跨节点类型所需的信任和验证级别，并优化网络扩展性和性能。
- 账本---不变的共享账本对每个通道的整个交易历史记录进行编码，并且包括类似SQL的查询功能，用于高效的审计和争议解决。
- 专用通道---通道可以提供竞争企业和在普通网络上交换资产的受监管行业所需的高度隐私和保密性进行多边交易。
- 共识---Fabric独特的共识方法可以提供实现企业所需的灵活性和可扩展性。
资产范围从有形（房地产和硬件）到无形（合同和知识产权）。 您可以轻松地在客户端JavaScript中定义资产，并使用包含的Fabric Composer工具在Fabric应用程序中使用它们。
Fabric支持使用未使用的交易输出作为后续交易的输入来交换资产的能力。 资产（和资产注册表）存放在Fabric中，作为键值对的集合，状态更改记录为通道账本上的交易。 Fabric允许以二进制或JSON格式表示任何资产。
链码是定义一个资产或资产们的软件，以及用于修改资产的交易指令。 换句话说，它是业务逻辑。 链码是强制执行的读取或更改键值对或者其他状态数据库信息的一套规则。 链码功能是对总账的当前状态数据库执行，并通过交易提案被启动。 链码执行结果是一组可以提交到网络并且被所有对等节点写入账本的键值写入（写入集）。
账本是Fabric中所有状态转换的顺序的、防篡改的记录。状态转换是参与方提交的链码调用("交易")的结果。每个交易都会产生一组资产键值对，这些对象将作为创建、更新或删除操作提交给账本。
账本是由一条区块链组成，就像状态数据库一样维护这当前Fabric的状态。区块链是由存储着不可更改的、序列化的记录的区块组成。每个通道都有一个账本。每个对等节点都维护着它们所属的每个通道的账本拷贝。
- 查询和更新账本可以使用基于键的查询、范围查询和符合关键字查询。
- 只读查询可以使用富查询语言（如果使用CouchDB作为状态数据库）。
- 只读历史查询---通过关键字查询账本历史记录，获取数据来源的情况。
- 交易包括从链码中读取的键值(读操作)和写进链码的键值(写操作)。
- 交易包含每个背书节点的签名并提交给排序服务。
- 交易在区块中被排序，并且被排序服务“传送”到通道上的对等节点。
- 对等节点根据背书策略验证交易并且执行策略。
- 在加入区块之前，将先执行版本检查，以确保从链码执行时间到现在读取的资产状态没有改变。
- 一旦交易被验证并提交，就具有不变性。
- 通道的账本包含一个配置区块定义策略、访问控制列表和其他相关信息。
- 通道包含会员服务提供者实例，允许从不同的证书颁发机构派生加密资料。
请参阅账本章节，深入了解数据库，存储结构和“查询能力”。
Fabric采用基于每个通道的不可变的账本，以及可以操作和修改当前资产状态（即更新键值对）的链码。 账本存在于通道的范围内 - 可以在整个网络中共享（假设每个参与者都在一个公共通道上运行） - 或者可以将其私有化，只包括一组特定的参与者。
在后一种情况下，这些参与者将创建一个单独的通道，从而隔离/分离其交易和账本。 Fabric甚至解决了希望弥合透明度和隐私之间差距的场景。 链码仅在需要访问资产状态以及执行读和写操作的对等体上安装（换句话说，如果链码未安装在对等体上，则无法与账本正确连接）。 为了进一步模糊数据，链码中的值可以使用常用的加密算法（如SHA-256）进行加密（部分或全部），然后记录到账本中。
Hyperledger Fabric支撑起一个所有参与者都具有已知身份的交易网络。 公共密钥用于生成与组织，网络组件以及最终用户或客户端应用程序相关联的加密证书。 因此，可以在更广泛的网络和通道级别上操作和管理对数据的访问控制。 Fabric的“许可”概念，加上通道的存在和功能，有助于解决隐私和机密性至关重要的情况。
请参阅Fabric CA部分，以更好地了解加密实现，以及Fabric中使用的签名，验证，验证方法。
在分布式分类帐技术中，共识最近已成为单一功能中特定算法的代名词。 然而，共识不仅仅是简单地同意交易顺序，而是通过其在整个交易流程中的基本角色，从提案和认可到排序，验证和提交，在Hyperledger Fabric中强调了这种差异化。 简而言之，共识被定义为对包含块的一组交易的正确性的全方位验证。
当区块的交易排序和结果符合明确的政策标准检查时，最终达成共识。 这些检查和平衡是在交易的生命周期内进行的，并且包括命令某些交易类型必须得到特定成员认可的认可策略的用法，以及确保这些策略得到执行和维护的系统链码。 在交易提交之前，对等节点将部署这些系统链码来确保它有足够的认可，并且它们是从适当的实体派生出来的。 此外，在包含交易的任何区块写入到账本之前，在账本的当前状态同意或者同意之前要进行版本检查。 这个最终检查提供了针对双重支付操作和可能危及数据完整性的其他威胁的保护，并允许对非静态变量执行函数。
除了发生的众多认可，有效性和版本检查之外，还有在交易流程的所有方向上发生的持续身份验证。 访问控制列表在网络的层次层次上实现（从订单服务到通道），并且随着交易提议通过不同架构组件，有效负载被重复签名，确认和验证。 总而言之，共识不仅仅是对一批交易进行排序，而是作为在交易从提议到确认提交的过程中进行的正在进行的验证的副产品而实现的总体表征。
查阅交易流程图，可以直观的感受共识