首页区块链技术智能合约Hyperledger Fabric可插拔式认证和验证逻辑
  • 评论(0)

分享到

微博

微信

QQ

Hyperledger Fabric可插拔式认证和验证逻辑

在提交时验证交易事务时,在应用交易事务本身的状态更改之前执行各种检查工作:

  1. 验证签署事务的身份。

  2. 在交易中验证代言人的签名。

  3. 确保事务满足相应chaincode的命名空间的认可策略。

有些用例要求自定义事务验证规则与默认的Fabric验证规则不同,例如:

  1. UTXO(未使用的事务输出):当验证考虑事务是否不会花费其输入时。

  2. 匿名交易事务:当认可不包含对等体的身份时,但共享的签名和公钥不能链接到对等体的身份。

可插拔式认证和验证逻辑

Fabric允许将定制认证和验证逻辑实现和部署到对等体中,以可插拔的方式与chaincode处理相关联。这个逻辑可以编译到对等体中,内置于可选逻辑中,也可以作为Golang插件与对等体一起编译和部署。

回想一下,在chaincode实例化时,每个链代码chaincode都与其自己的认可和验证逻辑相关联。如果用户未选择一个,则隐式选择默认的内置逻辑。对等管理员可以通过在对等启动时加载和应用的认可/验证逻辑的定制来改变通过扩展对等体的本地配置而选择的认证/验证逻辑。

本地配置

每个对等体都有一个本地配置(core.yaml),它声明了认证/验证逻辑名称和要运行的实现之间的映射。

默认逻辑称为ESCC(“E”代表认可)和VSCC(验证),它们可以在handlers程序部分的对等本地配置中找到:

handlers:
    endorsers:
      escc:
        name: DefaultEndorsement
    validators:
      vscc:
        name: DefaultValidation

当认证或验证实现被编译到对等体中时,name属性表示要运行的初始化函数,以便获得创建认证/验证逻辑实例的工厂。

该函数是core / handlers / library / library.go下的HandlerLibrary构造的实例方法,为了添加自定义认可或验证逻辑,需要使用任何其他方法扩展此构造。

由于这很麻烦并且构成了部署挑战,因此可以通过在名为library的名称下添加另一个属性来将自定义认证和验证部署为Golang插件。

例如,如果我们有作为插件实现的自定义认证和验证逻辑,我们将在core.yaml的配置中包含以下条目:

handlers:
    endorsers:
      escc:
        name: DefaultEndorsement
      custom:
        name: customEndorsement
        library: /etc/hyperledger/fabric/plugins/customEndorsement.so
    validators:
      vscc:
        name: DefaultValidation
      custom:
        name: customValidation
        library: /etc/hyperledger/fabric/plugins/customValidation.so

我们必须将.so插件文件放在对等的本地文件系统中。

©免责声明和风险提示:本文系用户自行发布或转载,不代表比特万象任何观点,如有任何形式的转载请联系原作者。文章中的所有内容均不构成比特万象任何的投资建议及意见、立场,请您根据自身评估做出理性决策。比特万象仅提供网络存储空间服务,如文章侵犯到您的合法权利,请您通知比特万象予以删除。
粤ICP备17084271号-2 Copyright © 比特万象 版权所有