1.hyperledger fabric1.1.0 主要包含以下几个结构模型,Assets(资产),Chaincode(链码),Ledger Features(分类帐功能),Privacy through Channels(渠道隐私),Security & Membership Services (安全和会员服务),Consensus(共识)
2.Assets(资产):
资产可以从有形（不动产和硬件）到无形（合同和知识产权）。 Hyperledger Fabric提供了使用链式代码事务修改资产的功能。
资产在Hyperledger Fabric中被表示为键值对的集合，状态更改记录为Channel(渠道)分类帐中的事务。 资产可以用二进制和/或JSON格式表示。
您可以使用Hyperledger Composer工具轻松定义和使用Hyperledger Fabric应用程序中的资产。
3.Chaincode(链码):
资产。 换句话说，这是业务逻辑。 Chaincode强制执行读取或修改键值对或其他状态数据库信息的规则。 Chaincode函数针对分类帐的当前状态数据库执行，并通过交易提议启动。 Chaincode执行产生一组键值写入（写集），可以将其提交到网络并应用于所有peers的分类帐。
4.Ledger Features(分类帐功能):
分类帐是fabric中所有状态转换的顺序防篡改记录。状态转换是由参与方提交的链式代码(chaincode)调用（'交易'）的结果。每笔交易都会生成一组资产键值对，并将其作为创建，更新或删除提交给分类帐。
分类帐由区块链（'链'）组成，用于存储不可变的顺序记录，以及用于维护当前结构状态的状态数据库。每个渠道(channel)有一个分类帐(Ledger)。每个peer为其所属的每个渠道维护分类帐的副本。
使用基于密钥的查找，范围查询和组合键查询来查询和更新分类帐,使用丰富查询语言的只读查询（如果使用CouchDB作为状态数据库）,只读历史记录查询 - 为一个密钥查询记录历史记录，实现数据来源方案,事务由链码（读取集合）中读取的键/值的版本和链码（写集合）中写入的键/值构成，交易包含每个认可对等方的签名并提交给ordering服务,交易按顺序排列，并从ordering服务“交付”给渠道的peers,peers根据背书政策验证交易并执行相关政策,在附加块之前，执行版本检查以确保自链式代码执行时间以来读取的资产的状态未发生变化,一旦交易得到确认和承诺，交易具有不变性,渠道分类帐包含定义政策，访问控制列表和其他相关信息的配置块.
5.Privacy through Channels(渠道隐私):
Hyperledger Fabric在每个通道的基础上使用不可变的分类账，以及可以操纵和修改资产当前状态（即更新键值对）的chaincodes。分类账存在于一个渠道范围内 - 它可以在整个网络中共享（假设每个参与者都在一个共同渠道上运营） - 或者可以将其私有化，只包含一组特定的参与者。
在后一种情况下，这些参与者将创建一个单独的渠道，从而隔离/隔离其交易和分类账。为了解决想要缩小总体透明度和隐私之间差距的方案，链码只能安装在需要访问资产状态以执行读取和写入的peers（换句话说，如果链码未安装在peers上，它将无法正确地与分类账连接）。
为了进一步混淆数据，可以在将事务发送到订购服务并将块附加到分类账之前，使用常用的加密算法（如AES）对链码中的值进行加密（部分或全部）,一旦将加密数据写入分类帐，只能由拥有用于生成密文的相应密钥的用户解密。
6.Security & Membership Services (安全和会员服务):
Hyperledger Fabric支持所有参与者已知身份的交易网络。 公钥基础结构用于生成与组织，网络组件，最终用户或客户端应用程序绑定的加密证书。 因此，数据访问控制可以在更广泛的网络和通道级别上进行操纵和管理。 Hyperledger Fabric的这种“许可”概念，再加上渠道的存在和功能，有助于解决隐私和机密性成为首要问题的场景,请参阅成员资格服务提供程序（MSP）主题以更好地理解加密实现以及Hyperledger Fabric中使用的签名，验证和身份验证方法
7.Consensus(共识):
在分布式账本技术中，在单一功能中，共识最近已成为特定算法的同义词。然而，共识不仅仅是简单地就交易顺序达成一致，而且Hyperledger Fabric通过其在整个交易流程中的基本角色（从提案和认可，到订购，确认和承诺）突出了这种差异。简而言之，共识被定义为包含区块的一组交易的正确性的全面验证。
当区块交易的顺序和结果符合明确的政策标准检查时，最终达成共识。这些检查和平衡发生在交易的生命周期中，并且包括使用背书政策来规定哪些特定成员必须认可某个交易类别，以及系统链码以确保这些策略得到执行和维护。在承诺之前，peers将使用这些系统链码来确保有足够的认可，并且它们来源于适当的实体。此外，在包含交易的任何块被附加到分类账之前，将进行版本检查，在该期间，分类账的当前状态被同意或同意。此最终检查可防止双重支出操作以及可能危及数据完整性的其他威胁，并允许针对非静态变量执行功能。
除了发生大量的背书，有效性和版本检查之外，还有在交易流程的各个方向上进行的身份验证正在进行中。访问控制列表在网络的层次结构层次上实施（订购服务直至通道），并且在交易建议通过不同的架构组件时，有效载荷会重复签名，验证和验证。总而言之，协商一致并不仅仅局限于一批交易的商定顺序，而是作为交易从提案到承诺之间的持续核查的副产品而实现的一个总体特征。