區(qū)塊鏈技術具有變革性和進化性，但在某些情況下，甚至未能留下一定的影響。許多專家普遍認為，區(qū)塊鏈將擾亂許多行業(yè)，并將徹底改變當今許多企業(yè)的經營方式。

所有業(yè)務都是采用原始概念形式擁抱區(qū)塊鏈技術的更具挑戰(zhàn)性的領域之一。特別是當必須依靠區(qū)塊鏈技術來簽訂合約時。在去中心化網絡上，雙方共同簽署合同可以公開敏感信息。這些小錯誤足以使您的業(yè)務重回原始時代。在這一點上，需要一個智能的解決方案，在一個混合的環(huán)境中，又可以獨立工作。

Hyper-Ledger Fabric為企業(yè)提供了這樣的機會，即使在許可的網絡中，也可以編寫可訪問性限制的腳本。隨著在分布式賬本技術上引入非許可區(qū)塊鏈而演變的概念使Hyper-Ledger Fabric如此受歡迎。兄弟們可以輕松簽署合約并交換敏感信息，而不必擔心將信息公開。但是盡管具有所有優(yōu)點，但Hyper-Ledger Fabric早期版本中仍然存在灰色區(qū)域，并且隨著更新版本的發(fā)布，這些缺點已得到了解決。在此博客中，我們將討論Hyper-Ledger Fabric 2.0版中的新增功能以及它如何解決以前版本的弊端。

Hyper-Ledger Fabric 2.0版中有哪些新功能？

發(fā)布新的Fabric Chaincode生命周期

在Fabric 2.0 Alpha的新模型中，將引入新的分散式治理，這將釋放一個在對等網絡上安裝Chaincode的新過程。通過此功能，現在多個組織將通過在Chaincode上設置不同的參數來在同一頁面上達成一致。Chaincode背書政策是一個如此聰明的功能，將被引進。在背書策略中，命令流將按以下方式發(fā)生：

示例Policy 1

{

“identiTIes”： ［

{ “role”： { “name”： “member”， “mspId”： “Org1MSP” }}，

{ “role”： { “name”： “member”， “mspId”： “Org2MSP” }}

］，

“policy”： {

“1-of”： ［{ “signed-by”： 0 }， { “signed-by”： 1 }］

}

}

示例Policy 2

{

“idenTITIes”： ［

{ “role”： { “name”： “member”， “mspId”： “Org1MSP” }}，

{ “role”： { “name”： “member”， “mspId”： “Org2MSP” }}，

{ “role”： { “name”： “admin”， “mspId”： “Org1MSP” }}

］，

“policy”： {

“2-of”： ［

{ “signed-by”： 2}，

{ “1-of”： ［{ “signed-by”： 0 }， { “signed-by”： 1 }］}

］

}

}

在這兩個示例策略中，身份定義了區(qū)塊鏈網絡的角色和MSP。

同樣，這些政策是由包含nOf格式政策的對象定義的，該政策也是用于簽注的特定“Signature Set Policy”，其中“ n”是為簽注指定簽名所需的最少簽名數。

在示例策略1中，有兩個來自Org1MSP和Org2MSP的身份。

“policy”： {

“1-of”： ［{ “signed-by”： 0 }， { “signed-by”： 1 }］

}

在定義背書策略時，它應該由將在身份數組（IdenTIty Org1MSP）中標識1的0（具有Role成員）進行簽名，或由1（具有Role成員）進行標識的2將身份標識給I數組（Identity Org2MSP）。在功能上，只有當交易由Org1MSP或Org2MSP的成員簽名時，區(qū)塊鏈的策略才會成功。以同樣的方式，示例策略2將指示與此策略相關的任何交易。 并且只有（i）簽名時，任何更改才會在區(qū)塊鏈中接受。OrdererMSP的管理員（ii）。Org1MSP或Org2MSP的任何組織的成員。

這就是背書政策在分散的環(huán)境中是如何工作的?，F在回到Fabric Chaincode從現在開始轉換示例的方式；

1.協(xié)助多個組織一致同意Chaincode的任何特定參數

在以前的版本中，明確提到了Fabric的1.x版本，其中規(guī)定只為一個組織提供設置Chaincode所需的參數能力，以使網絡正常運行。在這種設置中，只有一個組織能夠定義Chaincode的參數。

但是新的Hyper-Ledger Fabric版本2.0完全不同，為所有方提供了更大的靈活性。這樣它將支持區(qū)塊鏈的混合模型和本地模型。因此集中式和分散式兩種環(huán)境都可以得到支持。無論Chaincode需要一個成員或多個成員來認可網絡上的任何策略，然后才能夠轉移合約和操作，通過引入這一新功能，一切都將成為可能。

2.Chaincode的升級過程比以前的版本更安全

在以前的Hyper-Ledger Fabric版本中，只有一個組織或網絡中的第一個組織有權升級Chaincode上的事務。 結果，網絡中的任何新進的組織別無選擇，只能下載帶有損壞的Chaincode。

這樣新成員總是要承受交易風險的影響。但是更高版本的Hyper-Ledger Fabric帶來了新的修訂，這將允許在Chaincode上建立共識。只有在團隊達成共識后，新的Chaincode才會被實施，以幫助區(qū)塊鏈平臺根據業(yè)務需求運行。

3.通過更新簡化背書策略

網絡中的鏈無需時常重新打包或重新安裝Chaincode，以更改背書策略。有新的默認策略可供用戶從大多數成員中尋求共識。

4.更好地檢查Chaincode軟件包

讀取可讀tar文件中的Chaincode非常簡單。因此，網絡中的節(jié)點可以方便地檢查Chaincode包，并在安裝過程中與網絡中的其他節(jié)點進行協(xié)調。

在Hyper-Ledger Fabric 2.0版中引入FabToken

在最新版本的Hyper-Ledger Fabric 2.0中，用戶有機會使用其資產作為令牌。確切地說，FabToken將是此新版本上可用的用于啟動交易的令牌。它使用未花費的交易輸出或UTXO模型，以便使用Hyper-Ledger Fabric Network提供的身份和成員資格基礎結構來發(fā)行，轉移和贖回令牌。使用FabToken，用戶可以輕松創(chuàng)建新的加密貨幣。同時將完全簡化將令牌從一個用戶轉移到另一個用戶的過程。用戶可以執(zhí)行整個交易列表，并使用FabToken發(fā)起令牌的完全贖回。

安裝Hyper-Ledger Fabric SDK后，請使用docker映像進行快速驗證。您需要訪問FabToken目錄以選擇所需的令牌。 為此目的使用此命令：cd$HOME/fabric-samples/fabtoken。

當您計劃使用FabToken制作任何令牌時，要求Fabric網絡啟動并運行。使用示例節(jié)點應用程序來測試FabToken，是使用命令fabtoken.js和名為“startFabric.sh”的shell腳本。它將位于您當前所在的目錄中。輸入這些代碼后，它將啟動Fabric網絡和JavaScript目錄。您需要安裝“ npm install”。使用命令。/startFabric.sh立即啟動FabToken。

要使用FabToken創(chuàng)建令牌，安裝SDK后應出現以下屏幕，

1. —fabtoken.js—開始設置客戶端網絡對象已創(chuàng)建客戶端對象以表示通道

2. 創(chuàng)建了代表peer的客戶端對象

3. 創(chuàng)建了代表orderer的客戶端對象

成功安裝客戶端sideToken arg:goldcoinToken arg:1000

開始操作發(fā)行令牌

使用args goldcoin開始發(fā)行令牌，1000End令牌發(fā)行操作，返回{status： ‘SUCCESS’， info： ‘’} — — fabtoken.js —結束

當您給出此命令時，它將啟動令牌創(chuàng)建并根據您的期望幫助您創(chuàng)建令牌。

結論

創(chuàng)建Hyper-Ledger Fabric的目的是為企業(yè)提供更好的功能。 引入的高級功能將有助于在不同企業(yè)中使用Hyper-Ledger Fabric，以簡化并增強他們在不久的將來的潛力。