電子發燒友App
區塊鏈技術具有變革性和進化性，但在某些情況下，甚至未能留下一定的影響。許多專家普遍認為，區塊鏈將擾亂許多行業，并將徹底改變當今許多企業的經營方式。
所有業務都是采用原始概念形式擁抱區塊鏈技術的更具挑戰性的領域之一。特別是當必須依靠區塊鏈技術來簽訂合約時。在去中心化網絡上，雙方共同簽署合同可以公開敏感信息。這些小錯誤足以使您的業務重回原始時代。在這一點上，需要一個智能的解決方案，在一個混合的環境中，又可以獨立工作。
Hyper-Ledger Fabric為企業提供了這樣的機會，即使在許可的網絡中，也可以編寫可訪問性限制的腳本。隨著在分布式賬本技術上引入非許可區塊鏈而演變的概念使Hyper-Ledger Fabric如此受歡迎。兄弟們可以輕松簽署合約并交換敏感信息，而不必擔心將信息公開。但是盡管具有所有優點，但Hyper-Ledger Fabric早期版本中仍然存在灰色區域，并且隨著更新版本的發布，這些缺點已得到了解決。在此博客中，我們將討論Hyper-Ledger Fabric 2.0版中的新增功能以及它如何解決以前版本的弊端。
Hyper-Ledger Fabric 2.0版中有哪些新功能？
發布新的Fabric Chaincode生命周期
在Fabric 2.0 Alpha的新模型中，將引入新的分散式治理，這將釋放一個在對等網絡上安裝Chaincode的新過程。通過此功能，現在多個組織將通過在Chaincode上設置不同的參數來在同一頁面上達成一致。Chaincode背書政策是一個如此聰明的功能，將被引進。在背書策略中，命令流將按以下方式發生：
示例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 }］}
］
}
}
在這兩個示例策略中，身份定義了區塊鏈網絡的角色和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的成員簽名時，區塊鏈的策略才會成功。以同樣的方式，示例策略2將指示與此策略相關的任何交易。 并且只有（i）簽名時，任何更改才會在區塊鏈中接受。OrdererMSP的管理員（ii）。Org1MSP或Org2MSP的任何組織的成員。
這就是背書政策在分散的環境中是如何工作的?，F在回到Fabric Chaincode從現在開始轉換示例的方式；
1.協助多個組織一致同意Chaincode的任何特定參數
在以前的版本中，明確提到了Fabric的1.x版本，其中規定只為一個組織提供設置Chaincode所需的參數能力，以使網絡正常運行。在這種設置中，只有一個組織能夠定義Chaincode的參數。
但是新的Hyper-Ledger Fabric版本2.0完全不同，為所有方提供了更大的靈活性。這樣它將支持區塊鏈的混合模型和本地模型。因此集中式和分散式兩種環境都可以得到支持。無論Chaincode需要一個成員或多個成員來認可網絡上的任何策略，然后才能夠轉移合約和操作，通過引入這一新功能，一切都將成為可能。
2.Chaincode的升級過程比以前的版本更安全
在以前的Hyper-Ledger Fabric版本中，只有一個組織或網絡中的第一個組織有權升級Chaincode上的事務。 結果，網絡中的任何新進的組織別無選擇，只能下載帶有損壞的Chaincode。
這樣新成員總是要承受交易風險的影響。但是更高版本的Hyper-Ledger Fabric帶來了新的修訂，這將允許在Chaincode上建立共識。只有在團隊達成共識后，新的Chaincode才會被實施，以幫助區塊鏈平臺根據業務需求運行。
3.通過更新簡化背書策略
網絡中的鏈無需時常重新打包或重新安裝Chaincode，以更改背書策略。有新的默認策略可供用戶從大多數成員中尋求共識。
4.更好地檢查Chaincode軟件包
讀取可讀tar文件中的Chaincode非常簡單。因此，網絡中的節點可以方便地檢查Chaincode包，并在安裝過程中與網絡中的其他節點進行協調。
在Hyper-Ledger Fabric 2.0版中引入FabToken
在最新版本的Hyper-Ledger Fabric 2.0中，用戶有機會使用其資產作為令牌。確切地說，FabToken將是此新版本上可用的用于啟動交易的令牌。它使用未花費的交易輸出或UTXO模型，以便使用Hyper-Ledger Fabric Network提供的身份和成員資格基礎結構來發行，轉移和贖回令牌。使用FabToken，用戶可以輕松創建新的加密貨幣。同時將完全簡化將令牌從一個用戶轉移到另一個用戶的過程。用戶可以執行整個交易列表，并使用FabToken發起令牌的完全贖回。
安裝Hyper-Ledger Fabric SDK后，請使用docker映像進行快速驗證。您需要訪問FabToken目錄以選擇所需的令牌。 為此目的使用此命令：cd$HOME/fabric-samples/fabtoken。
當您計劃使用FabToken制作任何令牌時，要求Fabric網絡啟動并運行。使用示例節點應用程序來測試FabToken，是使用命令fabtoken.js和名為“startFabric.sh”的shell腳本。它將位于您當前所在的目錄中。輸入這些代碼后，它將啟動Fabric網絡和JavaScript目錄。您需要安裝“ npm install”。使用命令。/startFabric.sh立即啟動FabToken。
要使用FabToken創建令牌，安裝SDK后應出現以下屏幕，
1. —fabtoken.js—開始設置客戶端網絡對象已創建客戶端對象以表示通道
2. 創建了代表peer的客戶端對象
3. 創建了代表orderer的客戶端對象
成功安裝客戶端sideToken arg:goldcoinToken arg:1000
開始操作發行令牌
使用args goldcoin開始發行令牌，1000End令牌發行操作，返回{status： ‘SUCCESS’， info： ‘’} — — fabtoken.js —結束
當您給出此命令時，它將啟動令牌創建并根據您的期望幫助您創建令牌。
結論
創建Hyper-Ledger Fabric的目的是為企業提供更好的功能。 引入的高級功能將有助于在不同企業中使用Hyper-Ledger Fabric，以簡化并增強他們在不久的將來的潛力。
責任編輯；zl
工商網監
評論