HyperLedger Fabric v2.3 背书政策未生效
HyperLedger Fabric v2.3 Endorsement Policy did not come into action
我试图用 Running a Fabric Application tutorial 测试 Fabric 的背书策略功能，我遇到了一些 questions/issues。
我没有使用 LevelDB，而是通过将命令更改为 ./network.sh up createChannel -c mychannel -ca -s couchdb 使用 CouchDB 来建立网络。
在调用 InitLedger 之后，我通过 fauxton 手动将 asset2 的 "Size" 字段值编辑为另一个随机值，从 http://127.0.0.1:5984/_utils/ (couchdb0,属于组织 1)。所以此时，asset2 在 couchdb0 和 couchdb1 中有 2 个不同的值。
然后我调用链代码中的 UpdateAsset 函数来更新 asset2 的值。我期待一个关于背书政策不符合的错误或一些东西被抛出，因为 couchdb0 和 couchdb1 中 asset2 的不同值应该导致不同的 RW 集。
peer0.org1.example.com|2021-03-23 09:03:09.568 UTC [statecouchdb] commitUpdates -> WARN 0b4 CouchDB batch document update encountered an problem. Reason:Document update conflict., Retrying update for document ID:asset2
我确实在 logspout 中注意到了这个警告，但是在我的 try catch 块中没有发现任何错误，并且似乎提交了一个有效的块并且世界状态正在照常更新而没有任何错误。
不同的 RW Set 不应该将交易视为无效并且不会更新世界状态吗？
这是按预期工作的。您更新了大小字段但没有更新版本字段。读取集检查只检查版本字段。由链代码检查其他字段，例如资产所有权（和大小，如果有围绕它的业务规则，例如不允许在更新中更改大小）。资产转移链代码是一个简单的样本，仅通过密钥检查状态数据库中的资产是否存在。因此，在您的情况下，链码执行成功，因为它通过了资产存在性检查，背书成功，并且验证成功，因为两个背书都在相同的读取集（版本）和写入集上。
您收到 CouchDB 警告是因为内部 CouchDB 修订号因外部更新而不同，但这不是致命问题，可以通过重试解决（不保证 CouchDB 内部修订号在不同版本之间相同）状态数据库，因为对等方可能会多次更新相同的状态，例如在崩溃恢复场景中）。
我试图用 Running a Fabric Application tutorial 测试 Fabric 的背书策略功能，我遇到了一些 questions/issues。
我没有使用 LevelDB，而是通过将命令更改为 ./network.sh up createChannel -c mychannel -ca -s couchdb 使用 CouchDB 来建立网络。
在调用 InitLedger 之后，我通过 fauxton 手动将 asset2 的 "Size" 字段值编辑为另一个随机值，从 http://127.0.0.1:5984/_utils/ (couchdb0,属于组织 1)。所以此时，asset2 在 couchdb0 和 couchdb1 中有 2 个不同的值。
然后我调用链代码中的 UpdateAsset 函数来更新 asset2 的值。我期待一个关于背书政策不符合的错误或一些东西被抛出，因为 couchdb0 和 couchdb1 中 asset2 的不同值应该导致不同的 RW 集。
peer0.org1.example.com|2021-03-23 09:03:09.568 UTC [statecouchdb] commitUpdates -> WARN 0b4 CouchDB batch document update encountered an problem. Reason:Document update conflict., Retrying update for document ID:asset2
我确实在 logspout 中注意到了这个警告，但是在我的 try catch 块中没有发现任何错误，并且似乎提交了一个有效的块并且世界状态正在照常更新而没有任何错误。
不同的 RW Set 不应该将交易视为无效并且不会更新世界状态吗？
这是按预期工作的。您更新了大小字段但没有更新版本字段。读取集检查只检查版本字段。由链代码检查其他字段，例如资产所有权（和大小，如果有围绕它的业务规则，例如不允许在更新中更改大小）。资产转移链代码是一个简单的样本，仅通过密钥检查状态数据库中的资产是否存在。因此，在您的情况下，链码执行成功，因为它通过了资产存在性检查，背书成功，并且验证成功，因为两个背书都在相同的读取集（版本）和写入集上。
您收到 CouchDB 警告是因为内部 CouchDB 修订号因外部更新而不同，但这不是致命问题，可以通过重试解决（不保证 CouchDB 内部修订号在不同版本之间相同）状态数据库，因为对等方可能会多次更新相同的状态，例如在崩溃恢复场景中）。