許多事務因Fabric中的讀寫集當前設計而失敗

Question

這是用於讀寫集語義的文檔http://hyperledger-fabric.readthedocs.io/en/latest/readwrite.html，這意味着如果多個事務在同一個塊中爲某個鍵寫入值，則只有第一個將通過驗證並生效。

我已經做了通過使用Java SDK的一些測試中，我使用的鏈碼是github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02，我初始化chaincode爲： instantiateProposalRequest.setArgs（新的String [ ] {「a」，「300」，「b」，「200」）}）; 然後我使用for循環連續發送3個事務（每個事務將從a移動到10），並將它們放在同一個塊中。在塊被對等體持久化後，我查詢b的值是210而不是230，並且我檢查了這三個事務的ValidationCode，只有第一個是0，這意味着成功，其他都是11.這個結果與文檔完全匹配。

但是在同一個塊中多次更改相同密鑰的值是非常正常的情況。例如，有一個慈善申請，所有的人都會把錢轉到慈善組織的單一賬戶，而且TPS很高，這將是一個問題。

在文檔的末尾，它提到了關於具有多個讀寫集的事務尚不受支持。誰可以更詳細地解釋它？它能解決這個問題嗎？

Answer 1

我只有未驗證的關於多個讀寫集應該是什麼的假設，以便我保持開放。

另一方面，我認爲問題是example02沒有足夠強調Hyperledger不是分佈式數據庫 - 它是一個分佈式的分類帳。如果你想用Hyperledger實現一個加密貨幣，爲什麼不按照例如比特幣建立的UTXO模型？在這種情況下，您直接追蹤「帳戶擁有的未使用交易」，而不是當前帳戶餘額。經常賬戶餘額仍然可以計算，例如在查詢操作中作爲「分類賬狀態視圖」，如果你願意的話。

順便說一下，我的印象是，Hyperledger能夠閃耀的絕大多數用例不會像「cryptocurrency-like」一樣。 （而不是資產管理，「真實」的合同，政府，...）

如果我可以提出一個建議：這樣的概念性問題可能有更好的地方在RocketChat上的結構郵件列表和各種渠道。