通过Fauxton的Hyperledger Fabric CouchDB更新被视为有效更新，但在区块链中没有记录 [英] Hyperledger Fabric CouchDB updates through Fauxton treated as valid updates, but no record in blockchain

问题描述

我有一个Hyperledger Fabric网络设置，其中包含3个对等点，每个对等点都有一个CouchDB持久性容器。

I have a Hyperledger Fabric network setup with 3 peers, each with a CouchDB persistence container.

如果我通过Fauxton接口并更改JSON记录，则会传播此状态更改

If I go through the Fauxton interface and alter a JSON record, this state change is propagated to all three peers, which are in the same org.

但是，在区块链中没有状态变化的记录。没有为其创建任何交易。

However, there is no record of the state change in the blockchain. No transaction is created for it.

• 如果不是区块链交易，导致状态更改传播到所有对等节点，则是什么机制导致的？

• If it's not a blockchain transaction causing the state change to be propagated to all peers, what mechanism is causing it?

通过Fauxton进行的状态更改在没有任何交易的基础上被视为有效吗？

How in the heck is the state change through Fauxton considered valid with no transaction underlying it?

在生产环境中对Fauxton的期望是什么？

What is the expectation for Fauxton in a prod environment?

编辑：
对此进行回顾：原来我是个白痴，并且我的docker端口映射有问题。

To circle back on this: Turns out I was an idiot and had issues with my docker port mappings.

推荐答案

如果直接在对等方CouchDB中更改数据，则不会将其传播到其他对等方。您不应将CouchDB端口暴露在对等方网络之外，以免数据被篡改。只有对等方的管理员才能访问CouchDB，并且管理员没有动机去篡改自己的数据。让我进一步解释...

If you change data directly in the peers CouchDB, it will not be propagated to other peers. You should not expose the CouchDB port beyond the peer's network to avoid the data getting tampered. Only the peer's administrator should be able to access CouchDB, and the administrator has no incentive to tamper their own data. Let me explain further...

Hyperledger Fabric状态数据库类似于未使用的比特币交易数据库，因为如果对等管理员篡改了自己的对等数据库，对等方将无法使其他对等方相信来自它的交易是有效的。在这两种情况下，数据库都可以视为当前区块链状态的缓存。在这两种情况下，如果数据库损坏或被篡改，都可以在区块链的对等点上重建数据库。对于比特币，这是通过-reindex标志完成的。对于Fabric，这是通过删除状态数据库并重新启动对等方来完成的。

The Hyperledger Fabric state database is similar to the bitcoin unspent transaction database, in that if a peer administrator tampers with their own peer’s database, the peer will not be able to convince other peers that transactions coming from it are valid. In both cases, the database can be viewed as a cache of current blockchain state. And in both cases, if the database becomes corrupt or tampered, it can be rebuilt on the peer from the blockchain. In the case of bitcoin, this is done with the -reindex flag. In the case of Fabric, this is done by dropping the state database and restarting the peer.

在Fabric中，背书策略中指定的来自不同组织的对等方必须返回待验证交易的链码执行结果相同。如果对等节点上的账本状态数据已被更改或损坏（在CouchDB或LevelDB文件系统中），则在认可的对等节点之间链码执行结果将不一致，将找出不良对等点/组织，应用程序客户端应在提交交易以进行订购/提交之前，先从不良的同行/组织中剔除结果。如果客户应用程序尝试提交的签注结果不一致，则在验证时所有同行都将检测到该签注，并且该交易将无效。

In Fabric, peers from different orgs as specified in the endorsement policy must return the same chaincode execution results for transactions to be validated. If ledger state data had been altered or corrupted (in CouchDB or LevelDB file system) on a peer, then the chaincode execution results would be inconsistent across endorsing peers, the 'bad’ peer/org will be found out, and the application client should throw out the results from the bad peer/org before submitting the transaction for ordering/commit. If a client application tries to submit a transaction with inconsistent endorsement results regardless, this will be detected on all the peers at validation time and the transaction will be invalidated.

这篇关于通过Fauxton的Hyperledger Fabric CouchDB更新被视为有效更新，但在区块链中没有记录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！