Blockchain Hyperledger v0.6解剖学

据我所知，所有对等点都存储在VM的结构中。每个对等方存储所有区块链历史

当我想要构建一个应用程序时，我应该提供一个界面，用户可以在其中进行更改，该更改将保存在他的对等网络中，共识网络将把该更改添加到所有对等网络中

应该是这样的？ 那么，每个应用程序的用户向应用程序发送请求（后端API）和应用程序向结构发送请求（用户的对等方）

这是我的理解，如果我错了，请纠正我或确认。

1）据我所知，所有对等点都存储在VM的结构中

我不明白这种说法。让我给你一个总结

Hyperledger结构是一个连接的对等网络。在v0.6中，对等方可以是验证（VP）或非验证（NVP）。VP拥有区块链形式的世界状态和交易历史的完整副本。NVP仅仅是VP进行交易和查询的管道。事务可以看到未提交的状态，因此可以自己分层来构建一系列块。查询只能看到提交状态（事务肯定位于块中的世界状态）。这在事务和世界状态变化之间引入了滞后现象。请注意，可见性已改变iun v1结构

2） 每个对等方存储所有区块链历史

每个验证对等方存储所有区块链历史和所有世界状态

3） 当我想要构建一个应用程序时，我应该提供一个界面，用户可以在其中进行更改，该更改将保存在他的对等网络中，共识网络将把该更改添加到所有对等网络中

应用程序必须在一个或多个智能合约的上下文中构建。智能合约（也称为链码）具有架构师/开发人员为事务和查询处理创建的API。API的选择是灵活的，任何适合您的应用程序的API都可以。链码可以访问世界状态，因此其行为非常类似于servelet

当您从应用程序发送事务时，对等方将对其进行打包并将其发送给所有VP，他们将执行协商一致。如果通过，则事务将在所有服务器上执行。如果其中一个对等方出现错误，则事务失败

v0.6中有一个特点，即失败的事务不会写入块的事务数组。如果事务不发出事件，它也不会写入块的事件数组。这导致它或多或少地消失。我不确定是否发出了拒绝事件，但我怀疑没有。因此，我总是从我的物联网合同平台（）发出成功或失败事件，以便我的交易始终在链中留下痕迹

请注意，fabric v1将解决此问题

4） 应该是这样的？那么，每个应用程序的用户向应用程序发送请求（后端API）和应用程序向结构发送请求（用户的对等方）？ 这是我的理解，如果我错了请纠正或确认

这个图表是相当自由的概括，但本质上是正确的。每个对等方在v0.6中部署其自己的每个链码副本。这是自动发生的，因为部署也要经过协商一致，并且与其他事务一样是一个事务。因此，部署基本上在所有对等方上同时进行

链码在docker容器中运行（或在对等方中运行，但忽略您自己的链码），并通过称为shim的代理/存根安排通过gRPC与对等方的docker容器通信

---注---

Fabric v1正在完全更改此协议，因为链码必须显式安装在要访问它的任何对等机上。V1有特定参与者可以看到的私有渠道（想想子链）（通过他们的专属同行，通常是背书人或订购人，如果我到目前为止理解的话），因此链码将部署到参与者之间打开的渠道中，但是，只有当链码已经安装在要使用的对等机上时，部署才能成功

---

从中可以明显看出，将有许多可能的拓扑。每个参与者可能有一个对等体，每个对等体上有多个通道，但不是所有的对等体都有相同的参与者。一些参与者可能选择不使用对等点，而是在云中使用对等点，或者在另一个（可能是受信任的）参与者的前提下使用对等点。依此类推。

我所理解的“所有对等点都存储在虚拟机的结构中”是指所有对等点都存储在一台机器上，现在我理解对等点可以存储在同一台机器上，也可以存储在单独的机器上。对等点在docker容器中运行，但根据定义，它们通常属于参与者，因此在不同的机器上运行——虚拟机或物理机。