Hyperledger Fabric 权限策略和访问控制

news2024/11/17 11:22:06

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

常见的访问控制模型包括强制访问控制（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 的背书阶段。

fabricgogithubhyperledger

© 著作权归作者所有

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1368397.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

学生用台灯多少瓦比较合适？适合学生用的护眼台灯推荐

学生用台灯多少瓦比较合适？适合学生用的护眼台灯推荐

近年来&#xff0c;随着电子产品的普及和使用时间的增长&#xff0c;人们对眼部健康的关注度也越来越高为了解决这一问题&#xff0c;护眼台灯便是在这样的背景下诞生的。护眼台灯是一种集成了先进技术的台灯&#xff0c;旨在减轻眼部疲劳和保护视力。学生是使用台灯的一大群体…
阅读更多...
抖店新手如何申请开店？

抖店新手如何申请开店？

我是电商珠珠 抖店大家都知道&#xff0c;热度高门槛低&#xff0c;所以有很多人都想去入驻。但是对于开店流程&#xff0c;还不太了解。 今天&#xff0c;我就来给大家详细的讲一下。 一、入驻前准备 在入驻之前&#xff0c;需要准备好一张营业执照&#xff0c;新手的话个…
阅读更多...
JavaWeb——后端AOP面向特定方法编程

JavaWeb——后端AOP面向特定方法编程

七、AOP 1. 概述 AOP&#xff08;Aspect Oriented Programming&#xff09;&#xff1a;面向切面编程、面向方法编程&#xff0c;其实就是面向特定方法编程 场景&#xff1a; 案例部分功能运行较慢&#xff0c;定位执行耗时较长的业务方法&#xff0c;此时需要统计每个业务…
阅读更多...
linux安装node.js

linux安装node.js

先去官网下载对应的版本 官网&#xff1a;https://nodejs.org/en/download 选择对应的版本&#xff0c;点这个&#xff0c;直接去虚拟机上面安装 # apt的系统 apt install -y wget # yum的系统 yum install -y wget下载包 wget https://nodejs.org/dist/v20.10.0/node-v20.…
阅读更多...
后端程序员开发win小工具(未完待续)

后端程序员开发win小工具(未完待续)

github&#xff1a;https://gitee.com/forgot940629/win-tool-demo 本地启动&#xff0c;查看http://127.0.0.1:8080/form 场景 在日常工作中可能需要后端开发者开发一些辅助工具。这些辅助工具通常希望能想其他软件一样在桌面系统运行&#xff0c;并且有一些桌面应用的基本…
阅读更多...
股票开户须知！北京股票开户佣金最低是多少？找那家证券公司开户手续费低？

股票开户须知！北京股票开户佣金最低是多少？找那家证券公司开户手续费低？

股票交易是一种投资活动&#xff0c;需要一些基本的须知来帮助投资者进行决策和进行交易。以下是一些股票交易的基本须知&#xff1a; 了解股票市场&#xff1a;了解股票市场的基本原理、运作机制和相关法规是非常重要的。投资者应学习股票交易的基本概念和术语&#xff0c;了解…
阅读更多...
BERT 模型是什么

BERT 模型是什么

科学突破很少发生在真空中。相反&#xff0c;它们往往是建立在积累的人类知识之上的阶梯的倒数第二步。要了解 ChatGPT 和 Google Bart 等大型语言模型 &#xff08;LLM&#xff09; 的成功&#xff0c;我们需要回到过去并谈论 BERT。 BERT 由 Google 研究人员于 2018 年开发&…
阅读更多...
【算法练习】leetcode算法题合集之二叉树篇

【算法练习】leetcode算法题合集之二叉树篇

递归遍历基础篇 前序遍历&#xff0c;中序遍历&#xff0c;后序遍历是根据处理根节点的位置来命名的。 树的处理大多用到了递归&#xff0c;递归需要知道终止条件。 前序遍历&#xff08;中左右&#xff09; 144.二叉树的前序遍历 中左右&#xff0c;先处理根节点&#xff0c;…
阅读更多...
简单易懂的PyTorch激活函数大全详解

简单易懂的PyTorch激活函数大全详解

目录 torch.nn子模块Non-linear Activations nn.ELU 主要特点与注意事项 使用方法与技巧 示例代码 图示 nn.Hardshrink Hardshrink函数定义 参数 形状 示例代码 图示 nn.Hardsigmoid Hardsigmoid函数定义 参数 形状 示例代码 图示 nn.Hardtanh HardTanh函数…
阅读更多...
湖南大学-数据库系统-2018期末考试解析

湖南大学-数据库系统-2018期末考试解析

【写在前面】 这是2018年的卷子&#xff0c;复习备考的时候做了并与同学校对了答案。答案仅供参考。这张难度不大&#xff0c;同样的&#xff0c;跟前几张差不了太多。但是从这一年开始&#xff0c;选择题变成了15道&#xff0c;越来越贴切近几年的考试了。 一、单选题&#xf…
阅读更多...
基于SpringBoot摄影跟拍预定管理系统(系统+数据库+文档)

基于SpringBoot摄影跟拍预定管理系统(系统+数据库+文档)

&#x1f345;点赞收藏关注 → 私信领取本源代码、数据库&#x1f345; 本人在Java毕业设计领域有多年的经验&#xff0c;陆续会更新更多优质的Java实战项目 希望你能有所收获&#xff0c;少走一些弯路。&#x1f345;关注我不迷路&#x1f345;摘 要 首先,一开始便是清楚的论…
阅读更多...
虚拟机安装KALI

虚拟机安装KALI

阅读更多...
揭秘证券公司网站部署的SSL证书品牌

揭秘证券公司网站部署的SSL证书品牌

近日&#xff0c;有多家证券公司因网络安全问题被点名&#xff0c;由此&#xff0c;建立完善的网络安全管理制度、采用适当的安全策略和工具&#xff0c;以营造安全的网络环境&#xff0c;更好的保护用户隐私和业务安全就显得尤为重要。SSL证书作为保护传输数据安全的重要工具&…
阅读更多...
pve多台物理机虚拟化 pve虚拟机优势

pve多台物理机虚拟化 pve虚拟机优势

Proxmox VE是一个运行虚拟机和容器的平台。基于Debian Linux&#xff0c;完全开源。为了获得最大的灵活性&#xff0c;实现了两种虚拟化技术——基于内核的虚拟机(KVM)和基于容器的虚拟化(LXC)。一个主要的设计目标是使管理尽可能容易。运行在单个节点上使用Proxmox VE&#xf…
阅读更多...
acwing 并查集

acwing 并查集

目录 并查集的路径压缩两种方法法一法二 AcWing 240. 食物链AcWing 837. 连通块中点的数量示例并查集自写并查集 并查集的路径压缩两种方法 法一 沿着路径查询过程中&#xff0c;将非根节点的值都更新为最后查到的根节点 int find(int x) {if (p[x] ! x) p[x] find(p[x]);r…
阅读更多...
LitJson-Json字符串转对像时:整型与字符串或字符串转:整型进的类型不一致的处理

LitJson-Json字符串转对像时:整型与字符串或字符串转:整型进的类型不一致的处理

目录 问题描述上代码测试代码各位看官&#xff0c;打赏个1元吧 Json数据格式是大家在游戏开中常量用的一种数据格式&#xff0c;某种程度上可以说是必备的。对unity开发来说&#xff0c;LitJson这个json库应该是被使用最多的json库了。 问题描述 今天说要的其中的这个api: Jso…
阅读更多...
【docker】centos7安装harbor

【docker】centos7安装harbor

目录 零、前提一、下载离线包二、安装三、访问四、开机自启 零、前提 1.前提是已经安装了docker和docker-compose 一、下载离线包 1. csdn资源&#xff1a;harbor-offline-installer-v2.10.0.tgz 2. 百度云盘&#xff08;提取码&#xff1a;ap3t&#xff09;&#xff1a;harbo…
阅读更多...
YOLOv8 Ultralytics：使用Ultralytics框架进行姿势估计

YOLOv8 Ultralytics：使用Ultralytics框架进行姿势估计

YOLOv8 Ultralytics&#xff1a;使用Ultralytics框架进行姿势估计 前言相关介绍前提条件实验环境安装环境项目地址LinuxWindows 使用Ultralytics框架进行姿势估计参考文献 前言 由于本人水平有限&#xff0c;难免出现错漏&#xff0c;敬请批评改正。更多精彩内容&#xff0c;可…
阅读更多...
*5.1 Global Memory Bandwidth

*5.1 Global Memory Bandwidth

并行程序的执行速度可能因计算硬件的资源限制而有很大差异。虽然管理并行代码和硬件资源约束之间的交互对于在几乎所有并行编程模型中实现高性能很重要&#xff0c;但这是一种实用技能&#xff0c;最好通过为高性能设计的并行编程模型中的实践练习来学习。在本章中&#xff0c;…
阅读更多...
探索大模型时代下的文档识别与分析【GPT4-V带来的挑战与机遇】

探索大模型时代下的文档识别与分析【GPT4-V带来的挑战与机遇】

中国图象图形学学会青年科学家会议是由中国图象图形学学会青年工作委员会发起的学术会议。本会议面向国际学术前沿与国家战略需求&#xff0c;致力于支持图象图形领域的优秀青年学者&#xff0c;为青年学者们提供学术交流与研讨的平台&#xff0c;促进学者之间的交流与合作。会…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023