Fabric背書策略相關概念與背書驗證過程

背書策略

cli中背書策略語法

為chaincode指定背書策略

背書策略的驗證過程

節點通過背書策略來確定乙個交易是否被正確背書。當乙個peer接收乙個交易後，就會呼叫與該交易chaincode相關的vscc（validator system chaincode例項化時指定的）作為交易驗證流程的一部分來確定交易的有效性。為此，乙個交易包含乙個或多個來自背書節點的背書。

vscc的任務是驗證：

1. 所有的背書是有效的（即有效證書進行的有效簽名）

2. 恰當的（滿足要求的）背書數量

3. 背書來自預期的背書節點

背書策略即是用於定義2和3的驗證規則。

在cli中，用一種簡單的布林表示式來表示背書策略。

fabric使用msp來描述主體，msp用於驗證簽名者的身份和簽名者在msp中的角色、許可權。目前支援：member, admin, client和peer。主體的描述形式是msp.role，其中msp是msp id，role是member，admin，client或peer。

比如乙個有效的主體可表示為 'org0.admin'（msp org0的管理員）或 'org1.member'（msp org1的成員）或 'org0.client（msp org0的客戶端）或 'org1.peer（msp org1的節點）。

cli語法是：expr(e[, e...])

其中expr是and或or，表示布林表示式；e是上面語法所描述的主體或者是另乙個巢狀進去的expr。

例如：

and('org1.member', 'org2.member', 'org3.member')表示需要三個主體共同簽名背書

or('org1.member', 'org2.member')表示需要兩個主體之一的簽名背書

or('org1.member',and('org2.member', 'org3.member'))表示需要org1的簽名背書或者org2和org3共同的簽名背書

如果在例項化chaincode時未指定背書策略，則背書策略默為「由通道中的組織的任何乙個成員進行背書」。例如，乙個帶有「org1」和「org2」的通道將有乙個預設的背書策略：or（「org1.成員」，「org.成員」）。

命令：peerchaincode instantiate -c -n mycc -p "and('org1.peer','org2.peer')"

例項化chaincode後新增到通道中的新組織，可以查詢chaincode，但將無法提交由其背書的事務。必須修改背書策略，來讓由新加入的組織背書的交易得到認可。

1. 客戶端（sdk）把交易提議（tx proposal）發給指定的乙個或多個背書節點(endorsing peer)。接收提議的背書節點在sdk的交易提議請求中指定，最終進行背書的節點由交易所屬的chaincode和該chaincode所定義的背書策略（endorsement policy）共同決定。

例如node.js sdk的交易提議請求介面：

channel. sendtransactionproposal(request, timeout)

request是乙個chaincodeinvokerequest物件，可以在該物件中指定目標節點，如果未指定，則會將交易提議請求傳送給加入該通道的所有節點。

2. 背書節點收到交易提議後，首先用客戶端（sdk）的公鑰驗證它的簽名、客戶端是否可以在該channel進行操作、交易是否已被提交、交易提議組織是否正確。驗證通過後模擬執行chaincode（不會將結果寫入到賬本裡），將執行的結果反饋給客戶端。

3. 客戶端（sdk）收到足夠多的背書節點的結果後（背書策略），表示這個交易已經正確背書，然後將交易提議、模擬結果和背書資訊打包發給orderer節點；如果客戶端沒有蒐集到足夠多的背書節點反饋的背書資訊，這個交易就會被捨棄。

4. orderer節點對來自客戶端（sdk）的資訊進行排序，並建立區塊，然後在channel上進行廣播。

channel上的peer節點接收到交易區塊後，驗證背書策略是否滿足，然後更新賬本，至此，背書策略的驗證過程完成。

Fabric背書策略相關概念與背書驗證過程

Fabric背書策略

Nginx相關概念及負載均衡策略

與OGRE相關的概念

Fabric背書策略相關概念與背書驗證過程

Fabric背書策略

Nginx相關概念及負載均衡策略

與OGRE相關的概念

相關推薦