Shulou(Shulou.com)06/01 Report--

Editor to share with you the Fabric block chain network operation and maintenance tool configtxgen configuration file example analysis, I believe that most people do not know much about it, so share this article for your reference, I hope you will learn a lot after reading this article, let's go to know it!

Configtx.yaml is a configuration file used by configtxgen, a Hyperledger Fabric block chain network operation and maintenance tool, to generate channel creation blocks or channel transactions. The content of configtx.yaml directly determines the content of the generated creation blocks.

Capabilities / Channel capability configuration

The Capabilities segment is used to define the capabilities of the fabric network. This is a new configuration segment introduced in version v1.0.0 and cannot be used when networking with peer nodes and sort nodes of version v1.0.x.

The Capabilities section defines the features that fabric programs must support in order to join the network. For example, if a new MSP type is added, the updated program may identify and verify the signature against that type, but the older version of the program has no way to validate these transactions. This may result in inconsistent world states maintained in different versions of fabric programs.

Therefore, by defining the capability of the channel, it is clear that fabric programs that do not meet the capability requirements will not be able to process transactions unless upgraded to a new version. For a v1.0.x program, if any capabilities are defined in the Capabilities section, even if it declares that they do not need to be supported, it will cause them to crash intentionally.

Capabilities: # Global configuration applies to both sort and peer nodes and must be supported by both nodes. # setting this configuration item to ture indicates that the node is required to have this capability: Global: & ChannelCapabilities V1: 3: true # Orderer configuration is only applied to sorting nodes, regardless of peer node upgrade. Setting the configuration item # to true indicates that the sorting node is required to have this capability: Orderer: & OrdererCapabilities V1: true # Application configuration is only applied to peer-to-peer networks, regardless of the upgrade of sorting nodes. Setting the configuration item # to true indicates that the peer node is required to have this capability Application: & ApplicationCapabilities V1 configuration 3: trueOrganizations / organizational configuration

The Organizations configuration segment is used to define organizational entities for reference in subsequent configurations. For example, in the following configuration file, three institutions are defined and can be referenced using ExampleCom, Org1ExampleCom, and Org2ExampleCom, respectively:

Organizations:-& ExampleCom Name: ExampleCom ID: example.com AdminPrincipal: Role.ADMIN MSPDir:. / ordererOrganizations/example.com/msp Policies: Readers: Type: Signature Rule: OR ('example.com.member') Writers: Type: Signature Rule: OR (' example .com.member') Admins: Type: Signature Rule: OR ('example.com.admin') Endorsement: Type: Signature Rule: OR (' example.com.member')-& Org1ExampleCom Name: Org1ExampleCom ID: org1.example.com MSPDir:. / peerOrganizations/org1.example.com/ Msp AdminPrincipal: Role.ADMIN AnchorPeers:-Host: peer0.org1.example.com Port: 7051 Policies: Readers: Type: Signature Rule: OR ('org1.example.com.member') Writers: Type: Signature Rule: OR (' org1.example.com .member') Admins: Type: Signature Rule: OR ('org1.example.com.admin') Endorsement: Type: Signature Rule: OR (' org1.example.com.member')-& Org2ExampleCom Name: Org2ExampleCom ID: org2.example.com MSPDir:. / peerOrganizations/org2.example. Com/msp AdminPrincipal: Role.ADMIN AnchorPeers:-Host: peer0.org2.example.com Port: 7051 Policies: Readers: Type: Signature Rule: OR ('org2.example.com.member') Writers: Type: Signature Rule: OR (' org2.example .com.member') Admins: Type: Signature Rule: OR ('org2.example.com.admin') Endorsement: Type: Signature Rule: OR (' org2.example.com.member') Orderer / sort node configuration

The Orderer configuration section is used to define the sort node parameters to be encoded to write to the creation block or channel transaction.

The Orderer: & OrdererDefaults # sort node type is used to specify the sort node implementation to be enabled, and different implementations correspond to different consensus algorithms. # currently available types are: solo and kafka OrdererType: solo Addresses:-orderer0.example.com:7050 BatchTimeout: 2s BatchSize: MaxMessageCount: 10 AbsoluteMaxBytes: 98 MB PreferredMaxBytes: 512 KB MaxChannels: 0 Kafka: Brokers:-kafka0:9092-kafka1:9092-kafka2:9092-kafka3:9092 Organizations: # Define the sort node strategy at this level Its authoritative path is / Channel/Orderer/ Policies: Readers: Type: ImplicitMeta Rule: ANY Readers Writers: Type: ImplicitMeta Rule: ANY Writers Admins: Type: ImplicitMeta Rule: MAJORITY Admins # BlockValidation configuration item specifies which signatures must be included in the block So that the peer node can verify BlockValidation: Type: ImplicitMeta Rule: ANY Writers # Capabilities configuration to describe the capability requirements at the sorting node level. Here we directly refer to the OrdererCapabilities configuration item Capabilities in the previous Capabilities configuration section:

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.