在 Hyperledger Fabric 中設計更好的私有數據集合

Question

我有一個與私人數據收集的實施相關的針對特定案例的查詢，我正在尋求專家的建議/建議。 我們有一個在 Hyperledger Fabric 2.3.3 上運行的產品，該平台可以擁有任意數量的組織。 例如，最初將有 4 個組織，下周將有 10 個組織可以加入網絡。 當這些組織開始相互交易時，問題就出現了。 這些事務可以有許多只需要在這些組織之間保密的對象。 為此，我們可以使用名稱創建私有數據集合：

collection_org1
collection_org2
collection_org3
collection_org1_org2
collection_org1_org3
collection_org1_org2_org3
collection_org2_org3

假設如果網絡有 20 個組織作為參與者，將有多少私有數據收集組合。

這是因為，在給定時間，任何組織都可以與網絡中的另一個組織或一系列組織開始交易。 這里的問題是我們必須使用該模式創建大量私有數據集合並對其進行維護。

由於這個問題，我們刪除了這個實現，並為每個組織使用了隱式私有數據集合。 現在，如果有一個對象應該只與 org1、org2 和 org3 共享，則該對象將被推送到collection_org1 、 collection_org2 、 collection_org3 。 我們使用設置memberOnlyRead: false和memberOnlyWrite: false來做到這一點，並在鏈碼級別添加了驗證。 這個實現解決了上述問題，但又產生了一個新問題。 現在，我們想要實現密鑰級別的背書策略，這樣如果 org1 更改了在 org2 和 org3 之間共享的私有對象，則 org1 必須從 org2 和 org3 對等方獲得背書。 這意味着對等方將從他們自己的私有數據集合中讀取對象，從而導致背書提案響應中的讀取集不同，這進一步導致錯誤說read/write sets do not match 。

例如， org1 在背書提案期間將從其自己的私有數據集合collection_org1讀取對象 key: key1 。 以類似的方式，org2 將在背書期間從其自己的集合collection_org2讀取相同的密鑰，對於 org3 也是如此。 這導致背書提案中的讀取集不同。

我正在尋求以更好的方式實現整個功能的建議。 請讓我知道您的建議/建議。

Answer 1

GetPrivateDataHash() 就是您的答案。 您可以使用此功能來驗證每個背書人是否具有相同的值，並確保您的讀取集是一致的。

有關將其用於此目的的示例，請參閱安全傳輸教程和示例。