且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

通过Fauxton的Hyperledger Fabric CouchDB更新被视为有效更新,但在区块链中没有记录

更新时间:2023-10-18 16:58:40

如果直接在对等方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.