Hyperledger Fabric 权限策略和访问控制

这篇具有很好参考价值的文章主要介绍了Hyperledger Fabric 权限策略和访问控制。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

Hyperledger Fabric 权限策略和访问控制

访问控制是区块链网络十分重要的功能,负责控制某个身份在某个场景下是否允许采取某个操作(如读写某个资源)。

常见的访问控制模型包括强制访问控制(Mandatory Access Control)、自主访问控制(Discretionary Access Control)、基于角色的访问控制(Role BasedAccess Control)和基于属性的访问控制(Attribute Based Access Control)。功能越强大的模型,实现起来往往越复杂。

Fabric通过权限策略和访问控制列表(ACL)机制实现了基于角色的访问控制模型,可以满足通道内资源访问、背书控制或链码调用控制等多个场景下的需求。

应用场景

访问场景包括采用不同策略(如通道策略、节点策略、背书策略等),按照访问控制列表(如要求身份为Admins、Writers等)对某资源的特定操作进行限制。


身份证书

实现权限策略的基础是身份,身份的实现依赖证书机制。通过基于PKI的成员身份管理,Fabric网络可以对网络内的资源和接入用户的各种能力进行限制。

Fabric最初设计中考虑了三种类型的证书:登记证书(Enrollment Certificate)、交易证书(Transaction Certif icate),以及保障通信链路安全的TLS证书。证书的默认签名算法为ECDSA,Hash算法为SHA-256。

●登记证书(ECert):颁发给提供了注册凭证的用户或节点等实体,代表网络中身份。可以长期有效。

●交易证书(TCert):颁发给用户,控制每个交易的权限,不同交易可以不同,实现匿名性,短期有效。暂未实现。

●通信证书(TLSCert):控制对网络层的接入访问,可以对远端实体身份进行校验,防止窃听。可以长期有效。

目前,在实现上,主要通过ECert来对实体身份进行检验,通过检查签名来实现权限管理。TCert功能暂未实现,用户可以使用idemix机制来实现部分匿名性。


身份集合

基于证书机制,Fabric设计了身份集合(MSPPrincipal)来灵活标记一组拥有特定身份的个体.

对应的MSPPrincipal的数据结构:

身份集合支持从以下不同维度对身份进行分类。

●Role:根据证书角色来区分,如Member、Admin、Client、Peer、Orderer等。

●OrganizationUnit:根据身份证书中指定的OU信息来区分。

●Identity:具体指定某个个体的证书,只有完全匹配才认为合法。

●Anonymity:证书是否是匿名的,用于idemix类型的MSP。

●Combined:由其他多个子身份集合组成,需要符合所有的子集合才认为合法。

基于不同维度可以灵活指定符合某个身份的个体,例如,某个MSP的特定角色(如成员或管理员),或某个MSP的特定单位(OrganizationUnit),当然也可以指定为某个特定个体。

注意,目前对不同角色的认可采取不同方法。对于管理员角色,会认可本地msp/admincerts路径下的证书列表或证书带有代表管理员角色的OU信息;Client、Peer、Orderer等角色则需要查看证书是否带有对应的OU域;对于成员角色,则需要证书是由对应组织根证书签发。


权限策略的实现

权限策略指定了可以执行某项操作的身份集合。以通道相关的策略为例,一般包括对读操作(例如获取通道的交易、区块等数据)、写操作(例如向通道发起交易)、管理操作(例如加入通道、修改通道的配置信息)等进行权限限制。对策略配置自身的修改是通过额外指定的修改策略(mod_policy)来实现的。

操作者在发起操作时,其请求中签名组合只有满足策略指定的身份规则,才允许执行。实现上,每种策略结构都要实现Policy接口。对于给定的一组签名数据或身份,按照给定规则进行检验,看是否符合约定的条件。符合则说明满足了该策略;反之则拒绝。

数据结构

策略相关的数据结构定义在fabric-protos-go项目的common/policies.pb.go文件中,其中主要包括Policy、SignaturePolicyEnvelope(内嵌SignaturePolicy结构)和ImplicitMetaPolicy三种数据结构,如图14-20所示。

其中,Type的数值代表策略的类型,具体含义为:

●UNKNOWN,保留值,用于初始化。

●SIGNATURE,通过匹配基于签名的组合,如某个MSP中至少有三个签名。

●MSP,代表策略必须匹配某MSP下的指定身份,如MSP的管理员身份。

●IMPLICIT_META,隐式类型,包括若干子策略,并通过Rule来指定具体的规则,包括ANY、ALL、MAJORITY三种,仅用于通道配置内标记通道规则。

目前已经实现支持的策略类型主要包括SIGNATURE策略和IMPLICIT_META策略两种。

SIGNATURE策略

SIGNATURE策略指定通过签名来对数据进行认证,例如,必须满足给定身份的签名组合

其中,SignaturePolicy结构体代表了一个策略规则(rule)。支持指定某个特定签名,或者满足给定策略集合中的若干个(NOutOf)即可。NOutOf用法十分灵活,基于它可以递归地构建任意复杂的策略语义,指定多个签名规则的与、或组合关系。

SignaturePolicyEnvelope结构体代表了一个完整的策略,包括版本号(version)、策略规则(rule)和策略关联的身份集合(identities)。

例如,某个策略要求满足MP1身份集合签名,或者MP2集合和MP3集合同时签名,则可以表达为MP1||(MP2&&MP3)。对应的策略结构如下:

SignaturePolicyEnvelope{
    version: 0,
    rule: SignaturePolicy{
        n_out_of: NOutOf{
            N: 1,
            rules: [
                SignaturePolicy{ signed_by: 0 },
                SignaturePolicy{
                    n_out_of: NOutOf{
                        N: 2,
                        rules: [
                            SignaturePolicy{ signed_by: 1 },
                            SignaturePolicy{ signed_by: 2 },
                        ],
                    },
                },
            ],
        },
    },
    identities: [MP1, MP2, MP3] // 身份集合列表
}
// github.com/hyperledger/fabric-protos-go/common/policies.pb.go
type ImplicitMetaPolicy struct {
    SubPolicy string // 子策略类型名称,如 Readers、Writers、Admins
    Rule ImplicitMetaPolicy_Rule // 子策略的匹配条件,可以为 ANY、ALL、MAJORITY
}
ImplicitMetaPolicy{
    sub_policy: "Readers",
    rule: ANY,
}

需要注意,对签名策略的匹配过程是顺序敏感的(参考FAB-4749)。进行策略检查时,给定的多个签名会按照策略顺序依次与身份集合进行匹配,签名一旦匹配则会被消耗掉,再检查下一个签名。例如上述例子中,假如MP1代表组织A的管理员,MP2代表组织B的成员,MP3代表组织B的管理员,那么对于签名组合[S1={组织B的管理员},S2={组织B的成员}],并不会匹配成功。因为,S1在匹配MP2后会被消耗掉,剩下的S2在匹配MP3时会失败。为了避免这种情况,进行签名时要将优先级较低的签名放到前面,比如代表成员身份的签名应当放到管理员身份前。同时,对于策略的身份集合列表,则应该将高优先级的放到前面。


IMPLICIT_META策略

IMPLICIT_META策略用于通道配置,它并不直接进行签名检查,而是通过引用其他子策略(最终还是通过SIGNATURE策略)来实现。检查结果通过策略规则进行约束。


通道策略

权限策略的主要应用场景之一便是通道策略。通道策略采用了层级化树形结构,最上层为/Channel组,下面是各级子组。在每一级别都可以指定策略,作为本层级的默认策略。

通道配置可以包括联盟组(仅当系统通道,包括联盟组织信息)、应用组(一般仅当应用通道,包含使用通道的组织信息)和排序组(包括排序组织信息)等不同的元素。

一个典型的应用通道的例子如图14-23所示,包括一个排序组和一个应用组。

默认情况下,通道内的策略使用的角色定义如下:

# 通道全局策略
/Channel/Readers: ImplicitMetaPolicy-ANY Readers
/Channel/Writers: ImplicitMetaPolicy-ANY Writers
/Channel/Admins : ImplicitMetaPolicy-MAJORITY Admins
# 通道内应用组默认策略(仅当应用通道),需要从应用组织中推断
/Channel/Application/Readers: ImplicitMetaPolicy-ANY Readers
/Channel/Application/Writers: ImplicitMetaPolicy-ANY Writers
/Channel/Application/Admins : ImplicitMetaPolicy-MAJORITY Admins
/Channel/Application/Endorsement: ImplicitMetaPolicy-MAJORITY Endorsement
/Channel/Application/LifecycleEndorsement: ImplicitMetaPolicy-MAJORITY 
LifecycleEndorsement
# 通道内应用组各组织的默认策略(仅当应用通道)
/Channel/Application/Org/Readers: SignaturePolicy for 1 of Org Member
/Channel/Application/Org/Writers: SignaturePolicy for 1 of Org Member
/Channel/Application/Org/Admins : SignaturePolicy for 1 of Org Admin
/Channel/Application/Org/Endorsement: SignaturePolicy for 1 of Org Member
# 通道内排序组的默认策略,需要从排序组织中推断
/Channel/Orderer/Readers: ImplicitMetaPolicy-ANY Readers
/Channel/Orderer/Writers: ImplicitMetaPolicy-ANY Writers
/Channel/Orderer/Admins : ImplicitMetaPolicy-MAJORITY Admins
/Channel/Orderer/BlockValidation: ImplicitMetaPolicy-ANY Writers
# 通道内排序组中各组织的默认策略
/Channel/Orderer/Org/Readers: SignaturePolicy for 1 of Org Member
/Channel/Orderer/Org/Writers: SignaturePolicy for 1 of Org Member
/Channel/Orderer/Org/Admins : SignaturePolicy for 1 of Org Admin
# 通道内联盟组的默认策略(仅当系统通道)
/Channel/Consortiums/Admins: SignaturePolicy for ANY
# 通道内联盟组中某联盟的默认通道创建策略(仅当系统通道)
/Channel/Consortiums/Consortium/ChannelCreationPolicy: ImplicitMetaPolicy-ANY 
for Admin
# 通道内联盟组中某联盟组织的默认策略(仅当系统通道)
/Channel/Consortiums/Consortium/Org/Readers: SignaturePolicy for 1 of Org Member: 
 ImplicitMetaPolicy-ANY for Admin
/Channel/Consortiums/Consortium/Org/Writers: SignaturePolicy for 1 of Org Member
/Channel/Consortiums/Consortium/Org/Admins : SignaturePolicy for 1 of Org Admin

其中,通道内的元素,默认对其进行修改的策略(mod_policy)为Admins;与排序相关的配置的修改策略则指定为/Channel/Orderer/Admins,主要包括系统通道内相关配置,如Orderer-Addresses、Consortiums和具体的联盟配置。

另外,应用通道的策略会考虑最新配置中的Orderer组和Application组;系统通道的策略会考虑最新配置中的Orderer组和Consortiums组。新建应用通道时,用户需要指定Application组配置,如果不指定Orderer组配置,会自动从系统通道中继承过来。


通道访问控制

目前,Fabric中大多数的访问权限通过通道访问控制列表来指定。访问控制列表位于通道配置中,被通道内所有成员认可。可以在新建通道时利用conf igtx.yaml指定,也可以后期通过配置更新进行变更。访问控制列表配置示例如下,包括访问控制列表和其引用的策略:

Application: &ApplicationDefaults
    ACLs: &ACLsDefault
        # Lifecycle 方法调用权限:CheckCommitReadiness()、CommitChaincodeDefinition()、 
QueryChaincodeDefinition()、QueryChaincodeDefinitions()
        _lifecycle/CheckCommitReadiness: /Channel/Application/Writers
        _lifecycle/CommitChaincodeDefinition: /Channel/Application/Writers
        _lifecycle/QueryChaincodeDefinition: /Channel/Application/Readers
        _lifecycle/QueryChaincodeDefinitions: /Channel/Application/Readers
        # LSCC 方法调用权限:getid()、getdepspec()、getccdata()、getchaincodes()
        lscc/ChaincodeExists: /Channel/Application/Readers
lscc/GetDeploymentSpec: /Channel/Application/Readers
        lscc/GetChaincodeData: /Channel/Application/Readers
        lscc/GetInstantiatedChaincodes: /Channel/Application/Readers
        # QSCC 方法调用权限:GetChainInfo()、GetBlockByNumber()、GetBlockByHash()、
GetTransactionByID()、GetBlockByTxID()
        qscc/GetChainInfo: /Channel/Application/Readers
        qscc/GetBlockByNumber: /Channel/Application/Readers
        qscc/GetBlockByHash: /Channel/Application/Readers
        qscc/GetTransactionByID: /Channel/Application/Readers
        qscc/GetBlockByTxID: /Channel/Application/Readers
        # CSCC 方法调用权限:GetConfigBlock()
        cscc/GetConfigBlock: /Channel/Application/Readers
        # 通道内链码调用权限(向 Peer 发送背书请求)
        peer/Propose: /Channel/Application/Writers
        # 通道内跨链码调用权限
        peer/ChaincodeToChaincode: /Channel/Application/Readers
        # 接收区块事件权限
        event/Block: /Channel/Application/Readers
        # 接收过滤区块事件权限
        event/FilteredBlock: /Channel/Application/Readers
    # 默认应用通道内组织成员为空
    Organizations:
    # 通道内相关的策略,可被 ACL 中引用,用户也可以自定义全局策略
    Policies: &ApplicationDefaultPolicies
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"
    # 引用应用通道默认的能力集合
    Capabilities:
        <<: *ApplicationCapabilities

目前通道配置支持的资源访问权限总结如表:

资源访问 权限 功能
Lifecycle/InstallChaincode 本 MSP Admins 安装链码
Lifecycle/QueryInstalledChaincode 本 MSP Admins 查询已安装的链码信息
Lifecycle/GetInstalledChaincodePackage 本 MSP Admins 获取链码安装包
Lifecycle/QueryInstalledChaincodes 本 MSP Admins 查询所有已安装链码列表
Lifecycle/ApproveChaincodeDefinitionForMyOrg 本 MSP Admins 本 MSP Admins
Lifecycle/CommitChaincodeDefinition 通道 Writers 提交链码定义
Lifecycle/QueryChaincodeDefinition 通道 Writers 查询指定的已提交链码定义
Lifecycle/CheckCommitReadiness 通道 Writers 检查链码定义提交状态
Lscc/Install 本 MSP Admins 传统安装链码
Lscc/GetInstalledChaincodes 本 MSP Admins 传统获取安装链码列表
Lscc/Deploy 通道 Writers 传统实例化链码
Lscc/Upgrade 通道 Writers 传统升级链码
Lscc/ChaincodeExists 通道 Readers 检查链码是否安装
Lscc/GetDeploymentSpec 通道 Readers 获取安装包
Lscc/GetChaincodeData 通道 Readers 获取链码完整数据包
Lscc/GetInstantiatedChaincodes 通道 Readers 获取已实例化链码列表
Lscc/GetCollectionsConfig 通道 Readers 获取私有数据集合配置
Qscc/GetChainInfo 通道 Readers 查询通道信息
Qscc/GetBlockByNumber 通道 Readers 获取指定序号区块
Qscc/GetBlockByHash 通道 Readers 获取指定 hash 区块
Qscc/GetTransactionByID 通道 Readers 获取指定 ID 交易
Qscc/GetBlockByTxID 通道 Readers 获取包括指定交易的区块
Qscc/JoinChain 通道 Readers 加入通道
Qscc/GetChannels 通道 Readers 获取已加入的通道列表
Qscc/GetConfigBlock 通道 Readers 获取配置区块
Peer/Propose 通道 Writers 调用链码
Peer/ChaincodeToChaincode 通道 Writers 跨链码调用
Event/Block 通道 Readers 监听完整区块事件
Event/FilteredBlock 通道 Readers 监听过滤区块事件

背书策略

链码背书策略

用户在批准执行链码(2.0版本之前为实例化链码)时,可以指定调用该链码需要满足的背书策略(Endorsement Policy)并存放到链码定义中。当对链码的调用交易被提交时,Peer会检查是否交易携带了符合指定背书策略的签名信息。

背书策略可以采用SignaturePolicy或ChannelConf igPolicy两种方式进行指定,构建十分灵活的策略组合。SignaturePolicy方式指定使用特定身份签名组合来进行背书。例如,指定某几个组织内的任意成员身份进行背书,或者至少有一个管理员身份进行背书等。

语法上,背书策略通过-P指定需要哪些SignaturePolicy;通过-T指定所需要的Signature-Policy个数。目前,客户端已经实现了对背书策略的初步支持,通过-P来指定通过AND、OR、OutOf组合的身份角色(包括admin、member、peer、client)集合。

下面的策略指定要么Org1的管理员进行背书,要么Org2和Org3的peer节点同时进行背书:

OR('Org1.admin', AND('Org2.peer', 'Org3.peer'))

下面的策略指定三个组织中至少两个组织的成员进行背书:

OutOf(2, 'Org1.member', 'Org2.member', 'Org3.member')

ChannelConf igPolicy方式则引用通道配置内的已有策略名,使用对应的身份进行背书。

例如,如果不显式指定背书策略,则会使用通道配置中的Channel/Application/Endorsement策略,其默认为通道内的大多数成员。


键值背书策略

除了面向链码(该链码的所有状态)的背书策略外,自1.3.0版本开始,Fabric支持基于特定状态(键值)的更细粒度的背书策略。用户可以指定要修改某个指定状态时所需的背书策略。

包括如下的shim层API,可以在链码内使用。

●GetStateValidationParameter(collection,key string)([]byte,error):获取指定集合对指定键值的背书策略。

●SetStateValidationParameter(collection,key string,ep[]byte)error:指定某个键值所绑定的背书策略。

●GetPrivateDataValidationParameter(collection,key string)([]byte,error):获取指定集合对指定私密键值的背书策略。

●SetPrivateDataValidationParameter(collection,key string,ep[]byte)error:指定某个私密键值对应的背书策略。

Peer在提交区块阶段会对背书策略进行检查.


私有数据集合背书策略

自2.0版本起,用户也可以为每个私密数据集合指定对应的背书策略。当用户对私密数据集合内的键值进行写或修改操作时,需要满足指定的背书策略。此时,链码的整体背书策略会被忽略。发起写请求的用户不必为私密数据集合的成员。使用私密数据集合背书策略,可以限制对私密数据的写操作,实现更为安全的链码访问保护。

类似于链码背书策略,私密数据集合背书策略支持SignaturePolicy或ChannelConf igPolicy两种方式。例如,可以在集合配置文件collection.json中指定signaturePolicy或channelConf ig-Policy背书策略,示例代码如下:

[
 {
     "name": "collection1",       // 集合名称
     "policy": "OR('Org1MSP.member', 'Org2MSP.member')", // 集合成员
     "requiredPeerCount": 1, // 背书之前至少扩散私密数据到的节点数
     "maxPeerCount": 3,      // 背书之前尝试扩散最多节点个数,不能小于 requiredPeerCount
     "blockToLive":99999,    // 私密数据保存时长。0 意味着永不过期
     "memberOnlyRead": true, // 是否只允许集合成员(如客户端)来读取私密数据,v1.4 开始支持
     "memberOnlyWrite": true,// 是否只允许集合成员(如客户端)来发起对私密数据的写交易,v2.0  
         // 开始支持
     "endorsementPolicy": {  // 指定对私密数据进行写操作时的背书策略,会取代链码的背书策略
      "signaturePolicy": "OR('Org1MSP.member')" // 指定使用签名策略
    }
},
{
     "name": "collection2",
     "policy": "OR('Org1MSP.member')",
     "requiredPeerCount": 1,
     "maxPeerCount": 3,
     "blockToLive":3,
     "memberOnlyRead": true,
     "memberOnlyWrite": true,
     "endorsementPolicy": {
      "channelConfigPolicy": "Channel/Application/Writers" // 指定使用通道配置内已 
              // 有策略
    }
}
]

基于证书属性的链码访问控制

另外,用户也可以在自己的链码内通过基于证书属性的链码访问控制,实现自定义的控制逻辑。例如,可在方法入口处先检测调用者身份证书,过滤某些特定身份调用者,以实现基于键值或其他条件的细粒度的控制。

// github.com/hyperledger/fabric-chaincode-go/pkg/cid/cid.go
// 获取根据证书主题生成的唯一标识
func GetID() (string, error) 
// 获取 MSP ID
func GetMSPID() (string, error) 
// 获取证书某个属性的值
func GetAttributeValue(attrName string) (value string, found bool, err error)
// 检查证书中某个属性是给定值
func AssertAttributeValue(attrName, attrValue string) error 
// 获取调用者的 X509 证书
func GetX509Certificate() (*x509.Certificate, error)
// 判断调用者是否属于给定 OU
func HasOUValue(stub ChaincodeStubInterface, OUValue string) (bool, error)

用户可以使用这些方法在链码方法中对调用者身份进行访问控制。

例如,在证书的extension域中设置自定义的属性"abac."+role,并在链码方法中判断只有证书带有该属性的用户才可以调用该方法,示例代码如下:

import "github.com/hyperledger/fabric-chaincode-go/pkg/cid"
 func (t *TestChaincode) Access(stub shim.ChaincodeStubInterface, role string)  
    pb.Response {
    // 根据属性值来判断是否允许访问方法
    err := cid.AssertAttributeValue(stub, "abac."+role, "true")
    if err != nil {
        return shim.Error("Not allowed with missed attribution"+err.Error())
    }
    ...
}

实例化策略

实例化策略(Instantiation Policy)仅在2.0版本之前生效,负责对链码的实例化情况进行控制。Committer在确认阶段利用VSCC对网络中进行链码部署的操作进行权限检查。

目前,实例化策略同样采用了SignaturePolicy结构进行指定,可以基于身份集合结构构建复杂的签名校验组合。

默认情况下,会以当前MSP的管理员身份作为默认策略,即只有当前MSP管理员可以进行链码实例化操作。这可以避免链码被通道中其他组织成员私自在其他通道内进行实例化。

实例化策略的检查发生在Peer的背书阶段。 文章来源地址https://www.toymoban.com/news/detail-783190.html

到了这里,关于Hyperledger Fabric 权限策略和访问控制的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【Hyperledger Fabric 学习】运行一个Fabric应用

    中文网址:https://hyperledger-fabric.readthedocs.io/zh_CN/latest 英文网址:https://hyperledger-fabric.readthedocs.io/en/latest 一般情况英文网址的内容更全面,版本也比中文新。 本教程介绍了 Fabric 应用程序如何与已部署的区块链网络进行交互。本教程使用使用 Fabric Gateway 客户端 API 构建的示例

    2023年04月08日
    浏览(70)
  • Hyperledger Fabric问题汇总

    Ubuntu 20.04 Hyperledger Fabric 2.3.3 SDK对应的Go 1.17.5 链码对应的Go 1.18 Fabric-sdk-go 1.0.0 Docker 20.10.12 Docker-Compose 2.11.2 调用命令: peer chaincode invoke -o localhost:7050 – ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts

    2024年02月04日
    浏览(47)
  • Hyperledger Fabric架构设计

    目录 1、逻辑架构 答疑:什么叫做背书策略? 2、运行时架构         答疑:什么是锚节点? Hyperledger Fabric从1.X开始,在扩展性及安全性方面有了很大的提升,且新增了诸多特性。 多通道:支持多通道,提高隔离安全性。 可插拔的组件:支持共识组件、权限管理组件等可

    2024年02月11日
    浏览(37)
  • Hyperledger Fabric 架构概览

    fabric 版本 v2.4.1 超级账本 Fabric 自诞生以来已经发布了两个主要版本:1.0 系列版本(2017 年 7 月)和 2.0 系列版本(2020 年 1 月)。2016 年 9 月,Fabric 发布了 v0.6.0 预览版本,通过这一版本社区收集了大量来自实践的反馈和建议,主要集中在性能、安全、可扩展性等方面。2017

    2024年02月01日
    浏览(40)
  • Hyperledger Fabric 环境搭建

    以 fabric:2.2.0 ; ca:1.4.7 为例 官网下载go Downloads - The Go Programming Language (google.cn) 没有问题就完成啦 官方安装脚本(修改过了): 两个简单脚本直接开启/关闭测试区块链: 开启: 关闭:

    2024年02月11日
    浏览(42)
  • Hyperledger Fabric 链码

    懂哪写哪,随时补充 链码在开发过程中需要实现链码接口,交易的类型决定了哪个接口函数将会被调用,链码的接口定义如下: 链码的必要结构如下: shim.ChaincodeStubInterface接口 1、Init方法 Init方法中,首先通过stub的GetFunctionAndParameters()方法提取本次调用的交易中所指定的

    2023年04月08日
    浏览(47)
  • Hyperledger Fabric网络快速启动

    目录 1、网络服务配置 2、关联的docker-compose-base.yaml 各Peer节点容器设置如下信息。 3、被关联的Peer-base.yaml 4、启动网络 2、完成通道的创建 2.1将节点加入应用通道  更新锚节点  2.为什么要创建节点并将其加入应用通道中?         由于要启动多个网络节点,Hyperledger Fa

    2024年02月12日
    浏览(39)
  • 1.Hyperledger Fabric架构介绍

    Hyperledger是一个开放源代码的区块链项目合作组织,旨在推动跨行业的企业级区块链解决方案的发展。该项目由Linux基金会于2015年发起,致力于建立一个可靠、安全和可扩展的区块链框架和工具集。Hyperledger提供了一个集合,其中包含了多个不同的区块链框架、工具和库,用于

    2024年02月07日
    浏览(39)
  • 区块链hyperledger fabric部署

      新建目录、下载、解压 配置环境   将指定版本的 Hyperledger Fabric 平台特定二进制文件和配置文件安装到 fabric-samples 下的  /bin 和  /config  目录中,下载指定版本的 Hyperledger Fabric docker 镜像 2.2.1 配置镜像源 注:以上curl主要是为了获得一个 bootstrap.sh 的脚本文件并执行,可能

    2024年02月11日
    浏览(42)
  • Fabric 超级账本学习【5】Fabric2.4网络环境下——搭建Hyperledger Fabric区块链浏览器

    博主最近在搭建Hyperledger Fabric区块链浏览器过程中也学习了很多博主的搭建流程,踩了很多雷,踩了很多 坑,现将成功搭建好的Hyperledger Fabric区块链浏览器详细流程分享如下,帮助大家避雷闭坑 Hyperledger Explorer 是一个简单,强大,易于使用,维护良好的开源实用程序,可浏

    2023年04月23日
    浏览(46)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包