如何在Hyper-Ledger Fabric 2.0中创建新的加密货币

区块链技术具有变革性和进化性，但在某些情况下，甚至未能留下一定的影响。许多专家普遍认为，区块链将扰乱许多行业，并将彻底改变当今许多企业的经营方式。

所有业务都是采用原始概念形式拥抱区块链技术的更具挑战性的领域之一。特别是当必须依靠区块链技术来签订合约时。在去中心化网络上，双方共同签署合同可以公开敏感信息。这些小错误足以使您的业务重回原始时代。在这一点上，需要一个智能的解决方案，在一个混合的环境中，又可以独立工作。

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的任何组织的成员。

这就是背书政策在分散的环境中是如何工作的。现在回到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