在fabric中，共識過程意味着多個節點對於某一批交易的發生順序、合法性以及它們對賬本狀態的更新結構達成一致的觀點。滿足共識則意味着多個節點可以始終保證相同的狀態，對於以同樣順序到達的交易可以進行一致的處理。
具體來看，fabric中的共識包括背書、排序和驗證三個環節的保障。
我們先來研究下背書策略。
一.什么是背書策略
chaincode在實例化的時候，需要指定背書策略。這里的背書策略就是需要什么節點背書交易才能生效。
發起交易的時候，發起端（一般是SDK），需要指定交易發給哪些節點進行背書驗證（fabric不會自動發送），而是由sdk發送。發送后等待背書節點的返回，收集到足夠的背書后將交易發送給orderer（排序節點或稱共識節點）進行排序打包分發。最后，當每個Peer接受到block數據后，會對其中的交易進行驗證，如果交易不符合背書策略，就不會在本地生效，所以真正驗證背書是在這一步。
二.Endorsement policy 設計
背書策略有兩個主要組成部分：
主體（principal）：P定義了期望的簽名來源實體
門檻（thshold gate）：T有兩個參數：整數t（閾值）和n個主體，表示從這n個主體中獲取t個簽名
例如：
T(2, 'A', 'B', 'C')表示需要A、B、C中任意2個主體的簽名背書
T(1, 'A', T(2, 'B', 'C'))表示需要來自主體A的簽名或者來自B和C兩者的簽名背書
三.在CLI中實行背書策略
3.1CLI endorsement policy語法
在CLI中，使用一種簡單的語言來表示相對於Principal的布爾表達式的策略。
principal通過MSP進行描述，MSP的任務是驗證簽名者的身份和簽名者在該MSP內的角色。目前，支持兩個角色：成員和管理員。
principal被描述為 MSP.ROLE 其中 MSP 是所需的MSP ID，
和 ROLE 是 member 或者 admin 。
有效principle的示例是 ‘Org0.admin’（ MSP Org0的任何管理員）或
‘Org1.member’ （Org1 MSP的任何成員）。
語言的語法是：
EXPR(E[, E…])
其中 EXPR 是 AND 或
OR 表示兩個布爾表達式，並且 E 是principle（
具有上述語法）或另一個嵌套調用 EXPR 。
例如：
- AND(‘Org1.member’, ‘Org2.member’, ‘Org3.member’) ，請求3個principle的簽名。
- OR(‘Org1.member’, ‘Org2.member’) 請求兩個中的一個的簽名。
- OR(‘Org1.member’, AND(‘Org2.member’, ‘Org3.member’)) ，請求一個來自MSP=red >
Org1 的簽名，或者來自MSP=red > org2 的成員和來自=red > Org3 的成員的簽名。
3.2為chaincode指定Endorsement policy
通過使用這種語言，chaincode的開發者可以為一個chaincode指定特定的endorsement策略。
注意 - 默認策略需要 DEFAULTMSP 成員的一個簽名 ）。如果在CLI中未指定策略，則使用此選項。
該策略可以在部署時通過鍵 -P 來指定。
例如： peer chaincode deploy -C testchainid -n mycc
-p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02
-c ‘{“Args”:[“init”,”a”,”100”,”b”,”200”]}’ -P “AND(‘Org1.member’, ‘Org2.member’)”
該命令使用 AND(‘Org1.member’, ‘Org2.member’) 策略，將chaincode
mycc 部署到鏈testchain上。
四.Node SDK中實行背書
官方實例balance-transfer使用fabric node sdk構建了一個完整的客戶端，實現了CLI的完整功能（包括注冊用戶、創建channel、加入channel、安裝鏈碼、實例化鏈碼），並且提供了REST API。但是在balance-transfer在實例化時並未指定背書策略。但是我們可以在實例化請求的Request對象中加入背書策略。
我們可以構建一個endorsement對象。先看兩個例子：
4.1 example
背書策略: "由其中一個組織的任何成員簽名"
{
identities: [
{ role: { name: "member", mspId: "org1" }},
{ role: { name: "member", mspId: "org2" }}
],
policy: {
"1-of": [{ "signed-by": 0 }, { "signed-by": 1 }]
}
}
背書策略: "ordererOrg的管理員和一個peer組織的成員簽名"
{
identities: [
{ role: { name: "member", mspId: "peerOrg1" }},
{ role: { name: "member", mspId: "peerOrg2" }},
{ role: { name: "admin", mspId: "ordererOrg" }}
],
policy: {
"2-of": [
{ "signed-by": 2},
{ "1-of": [{ "signed-by": 0 }, { "signed-by": 1 }]}
]
}
}
4.2 endorsement對象分析
它有兩個高級屬性：indentities和policy。
Indentities：在policy中引用的身份列表。
Policy：使用“signed-by”和“n-f”結構組合的策略規范。policy可以是對於單個indentities簽名的“signed-by”或是“n-of”。如果類型屬性是“sign-by”，則該值是策略中指定的indentities數組的數字索引。如果類型屬性是“n-of”，則該值是policy對象的數組。正如所看到的，這個結構允許復雜策略的遞歸定義。
policy是可選的。如果不指定，那么就將采用默認的背書策略：被來自MSPs內任何組織的任何成員簽名。不推薦使用默認策略投入實際生產，因為這允許應用繞過請求背書將一個手動構建的具有任意輸出的交易直接發送給orderer。應用程序自己的簽名將會允許交易成功驗證並提交到賬本。