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