我想知道当管理员可以使用Couchdb直接提供的Fauxton或cURL更改Couchdb中的最新状态时，您的数据是如何安全的。
根据我的理解，Hyperledger Fabric提供不可变数据功能，最适合防欺诈（Blockchain功能）。
问题是： - 我可以轻松更改couchdb中的数据，当我从chaincode查询时，它显示更改的数据。但是当我通过使用ledger查询GetHistoryForKey()时，它并没有显示我对couchdb做出的改变。有什么办法可以防止这种欺诈吗？因为用户将看到最新的状态，即来自couchdb的数据而不是来自ledger
任何答案将不胜感激。
谢谢
在Hyperledger Fabric v1.2中，每个对等体都有自己的CouchDB。即使您直接从一个对等体的CouchDB更改数据也是如此。认可将失败。如果认可失败，您的数据既不会被写入世界状态也不会被写入当前状态。
您必须保护您的couchdb不被对等方以外的进程修改，就像您通常必须保护您的文件系统或内存一样。
如果您使文件系统可写，则其他用户可以覆盖分类帐内容。同样，如果您没有在couchdb写入上放置访问控制，那么您将失去不变性属性。
这是分布式分布式系统的美妙之处。即使您或其他人更改了数据库/分类帐的状态，它也不会与网络中其他人的状态相匹配，也不会与事务块哈希匹配，导致任何交易无效的代理人，除非您可以恢复实际约定的来自网络参与者或订货人的分类帐的状态。要利用分类帐的不变性，您必须查询分类帐。查询数据库不利用区块链的功能，因此必须以类似于保护对任何其他数据库的访问的方式进行保护。
您不应将CouchDB端口暴露在对等网络之外，以避免数据被篡改。只有对等方的管理员才能访问CouchDB，管理员无需篡改自己的数据。让我进一步解释......
Hyperledger Fabric状态数据库类似于比特币未使用的事务数据库，因为如果对等管理员篡改他们自己的对等数据库，则对等方将无法说服其他对等方来自它的事务是有效的。在这两种情况下，数据库都可以被视为当前区块链状态的缓存。在这两种情况下，如果数据库损坏或被篡改，它可以在区块链的对等体上重建。在比特币的情况下，这是通过-reindex标志完成的。在Fabric的情况下，这是通过删除状态数据库并重新启动对等体来完成的。
在Fabric中，来自认可策略中指定的不同组织的对等方必须为要验证的事务返回相同的链代码执行结果。如果对等体上的分类账状态数据被更改或损坏（在CouchDB或LevelDB文件系统中），那么链代码执行结果将在支持对等体之间不一致，将找到“坏”对等体/组织，并且应用程序客户端应该在提交订单/提交事务之前，从坏的peer / org中抛出结果。如果客户端应用程序尝试提交具有不一致的认可结果的事务，则在验证时将在所有对等方上检测到该事务，并且该事务将被无效。
你需要在这里理解两件事
正如其他人所解释的那样 - 认可/共识是关键。尽管可以在外部修改支持对等方的分类帐状态 - 在这种情况下，该对等方认可的所有交易都将被丢弃，因为其他支持对等方将发送正确的交易（假设其他世界状态也未被篡改）并达成共识将在这里发挥关键作用，以帮助选择正确的交易。
最糟糕的情况是所有交易都会失败。
Hyperledger fabric的世界状态（Ledger state）可以随时从区块链（Transactions Log）重新生成。并且，在对等失败的情况下，这种再生自动发生。通过一些仔细的配置，可以构建一个自我修复的网络，其中一个故障的对等体将自动从灰烬（双关语意图）上升。
这里要考虑的关键点是Gossip数据传播协议，它可以被视为神秘的治疗者。网络中的所有对等体持续连接，并与网络内的其他对等体交换数据。
引用文档 -
受延迟，网络分区或导致错过块的其他原因影响的对等方最终将通过联系拥有这些丢失块的对等方同步到当前分类帐状态。
和......
具有与通道其余部分不同步的数据的任何对等体识别丢失的块并通过复制正确的数据来同步自身。
这就是为什么总是建议在网络和组织中越来越多地支持同行。网络越大 - 就越难以被恶意打败。
我希望，我可以提供一些帮助。参考链接：https://hyperledger-fabric.readthedocs.io/en/release-1.4/gossip.html
即使这是合理的，但认可政策是保护自己（系统）免受此类行为影响的一般手段。