Hyperledger fabric Hyperledger结构在单个节点上使用CouchDb时是脆弱的？

我正在使用Hyperledger Fabric开发一个应用程序，并构建了Node.js客户端，该客户端公开API以调用区块链，这是startFabric.sh脚本

我正在使用CouchDB和我们需要的所有Docker。我只有一个对等节点，所以我的网络中有一个节点。这是一个非常简单的问题

我认为拥有一个带有Hyperledger的区块链可以使我的数据持久化。但是我在CouchDB中修改了数据，如果我查询分类账，就会得到修改后的数据。 怎么可能呢？ 这不是区块链

有人能解释一下吗

以下是我为让你更好地理解这个问题所做的。 我已经创建了调用API的实体，区块链的结果是交易已经提交：

事实上，如果我使用查询API获取该实体，我会收到：

但我们也可以在区块链上检查，因为我让docker处于日志模式： 所以，在这里之前，一切似乎都很好

现在我打开CouchDb，我看到我的数据存储在这里：

我打开实体Try2，修改所有者和位置参数，然后保存：

这在区块链内部是不可能的。我正在修改数据，但还没有完成新的事务，那么这怎么可能呢

如果我现在查询区块链，我会得到修改后的数据：

---

我是否遗漏了某一点，或者这在区块链内部不可能实现？

当您进行

查询

交易时，对等方将获得参数的最新状态，该状态位于

世界状态

。这一部分使网络的可用性更好

默认情况下，系统将LevelDB用于

世界状态

，CouchDB是一个选项（）

因此，当您在单个对等机上修改CouchDB的值时，只修改

世界状态

，而不修改

分类账

。这不会打破链条

您可以阅读有关Hyperledger结构的

分类帐
概念的更多信息

希望这能有所帮助
 您只有一个对等方，因此，如果该对等方认可一个事务，则该事务将有效

然而，在实时用例中，不同组织拥有多个对等点。背书政策规定，大多数或所有背书对等方必须背书交易，交易才被视为有效

例如，考虑一个由3个组织组成的联盟，Org1，Org2和Org3。他们中的每个人都有一个背书对等者，即Org1Peer1、Org2Peer1和Org3Peer1。并且背书策略的设置使得只有当所有这些对等方都背书该交易时，该交易才有效。这里，假设您是Org1的管理员
现在，要将任何有效交易提交到分类账，它必须经过4个阶段：

赞同
检查背书回复并提出交易建议
订购
验证和提交
对于你的问题，我们需要看一下第1和第2阶段。在背书阶段，所有背书对等方Org1Peer1、Org2Peer1和Org3Peer1都必须模拟事务并创建一个新的签名。这里，背书对等方使用状态数据库（例如，CouchDB）中存储的值来创建此集合。一般来说，读集包含模拟前资产的状态值，写集包含模拟后资产的状态值

此外，所有这些背书对等方将其读写集发送到启动事务的客户端。这里，检查并比较所有背书对等方发送的读写集。现在，由于背书策略要求所有对等方都必须背书事务，因此所有对等方的读写集必须完全相同。这意味着，在模拟之前，所有认可的对等方在状态数据库中应该具有相同的值，并且在模拟之后应该得到相同的状态值。如果读写集不同，则不生成提案，并且拒绝交易

因此，如果您是Org1的管理员，更新了状态数据库中的值，那么在背书阶段，您的对等Org1Peer1将生成与Org2Peer1和Org3Peer1不同的读写集。交易建议书不会提交给订购服务（第3阶段）

注意，客户端可以选择不检查响应（读写集），但转发事务建议。但是，将在确认和提交阶段对该提案进行检查。此处，由于读写集不同，事务将被标记为无效，并将提交到分类账

您可以通过阅读获得更清晰的信息。
谢谢，我会阅读的！但你的意思是不使用CouchDB，所以只使用LevelDB，我可以避免这个问题？还有，让我问另一个问题：我阅读了你发送的所有分类账文档，但我不清楚：如果我只修改世界状态而不修改分类账，应用程序在什么时候意识到世界状态的哈希与分类账上的哈希不匹配，因为我修改了一些数据？-CouchDB和LevelDB只是保存世界状态的选项，所以是相同的。-这些数据库是NoSQL。数据将存储为（键值）对，并且这里没有
散列您必须向其他同行查询，以确保数据未被修改
query
交易无需由背书同行背书！是的，你说得对，查询交易不需要背书。然而，它是关于流氓数据，是躺在国家数据库。在这里，它只有一个对等点，所以它可能不会产生更大的影响。但是，如果存在多个对等点，则查询事务将导致不同对等点的不同数据，这将在下一个事务中再次导致不同的读写集。您提供的信息不适用