据我所知，所有对等体都存储在VM中的结构中。每个对等方都存储所有区块链历史记录。
当我想构建一个应用程序时，我应该提供一个用户可以进行更改的界面，该更改将保存在他的同行中，共识网络会将更改添加到所有对等方。
应该是https://www.altoros.com/blog/wp-content/uploads/2017/02/Hyperledger-Webinar-Thomas-Marckx-architecture.jpg之类的东西？ 那么，每个应用程序的用户向应用程序发送请求（后端API）和应用程序发送请求到结构（用户的对等方）？
根据我的理解，如果我错了或确认，请纠正我。
答案 0 :(得分：3)
1）据我所知，所有对等体都存储在VM中的结构中。
我不理解这句话。让我给你一个总结。
Hyperledger结构是连接对等体的网络。在v0.6中，对等体可以是验证（VP）或非验证（NVP）。 VP以区块链的形式拥有世界状态的完整副本和交易历史记录。 NVP仅仅是用于交易和查询的VP的管道。事务可以看到未提交的状态，因此可以自行构建一系列块。查询只能看到提交状态（事务肯定在块中的世界状态）。这引入了可见的事务和世界状态变化之间的滞后。请注意，可见性已更改iun v1 fabric。
2）每个对等体都存储所有区块链历史记录。
每个验证对等体存储所有区块链历史记录和所有世界状态。
3）当我想构建一个应用程序时，我应该提供一个用户可以进行更改的界面，该更改将保存在他的同行中，共识网络会将更改添加到所有对等方。
必须在一个或多个智能合约的上下文中构建应用程序。智能合约（也称为链代码）具有架构师/开发人员为事务和查询处理创建的API。 API的选择非常灵活，适用于您的应用程序。链码可以访问世界状态，因此很像一个服务器。
当您从应用程序发送交易时，对等方将打包并将其发送给所有VP，他们将达成共识。如果通过，则将对所有进行交易。如果其中一个对等体出错，则事务失败。
v0.6中存在一个特点，即失败的事务不会写入块的事务数组中。如果事务没有发出事件，它也不会被写入块的事件数组中。这导致它或多或少地消失。我不确定是否发出拒绝事件，但我怀疑不是。出于这个原因，我总是从我的物联网合同平台（https://github.com/ibm-watson-iot/blockchain-samples/tree/master/contracts/platform）中发出成功或失败事件，以便我的交易总是在链中留下痕迹。
请注意，fabric v1将解决此问题。
4）应该是https://www.altoros.com/blog/wp-content/uploads/2017/02/Hyperledger-Webinar-Thomas-Marckx-architecture.jpg之类的东西？那么，每个应用程序的用户向应用程序（后端API）发送请求并向结构（用户的对等方）发送应用程序请求？ 这是我的理解，如果我错了或确认，请纠正我。
图表对于概括是完全免费的，但是基本上是正确的。每个对等体在v0.6中部署自己的每个链代码的副本。这种情况会自动发生，因为部署也会达成共识，并且与其他任何事务一样。因此，部署基本上同时发生在所有对等体上。
Chaincode在docker容器中运行（或在对等进程中运行，但忽略对于您自己的链代码）并通过称为shim的代理/存根安排通过gRPC与对等的docker容器通信。
---注意---
Fabric v1正在完全改变这个协议，因为必须在任何从中访问它的对等体上显式安装链代码。 V1具有私人渠道（想想子链），这些渠道对于特定参与者是可见的（通过他们的专属同行，如果我到目前为止理解它通常是代言人或订货人），因此链代码将被部署到参与者之间打开的渠道中，但只有在要使用的对等端上已安装链代码时才能成功部署。
由此可以明显看出，有许多可能的拓扑结构。每个参与者可以在每个对等体上具有具有多个通道的对等体，但不是所有对象具有相同的参与者一些参与者可能选择不拥有对等体，而是在云中使用一个，或者在另一个（可能是可信的）参与者的场所使用对等体。等等。
