Fabric organization dynamic management

The blockchain is essentially a decentralized, peer-to-peer, and self-built trustworthy distributed network that meets ultimate consistency. In the centralized system, after years of theoretical exploration and practical development, it has become relatively mature. In a decentralized system, each node brings uncertainty in their respective states due to network congestion, performance limitations, and even network corruption, malicious nodes, and it is no easy task to solve the consistency problem. To this end, the blockchain solves the consistency problem through a consensus mechanism. The so-called consensus mechanism is a multi-party cooperative operation mechanism, which coordinates the multi-participants in the network to achieve an acceptable only result, and ensures that the process is correct, effective and sustainable. Common consensus mechanisms include PoW, PoS, PBFT, Raft, etc. The consensus in the follow-up article is based on the most common Raft of the fabric alliance chain.

In the network of the fabric alliance chain, the network topology and various configurations are stored in the creation block in the form of blocks. Any operation is a transaction, whether it is calling a smart contract to perform a business operation or a configuration change, a consensus is required to be generated later. If a new business entity is added to an already running consortium chain network, the existing configuration needs to be modified to form a new configuration and get on the chain through consensus. This process is called the dynamic management of the organization. The dynamic management of the organization is divided into dynamic addition and dynamic deletion. .

Organization dynamically added

Timing diagram dynamically added by the organization

Prepare an already running fabric consortium chain network, which consists of the following containers.

Next, prepare the organization org3 that needs to be dynamically added, and use the command line tool cryptogen generate --config=./org3-crypto.yaml to generate the organization org3 certificate;

Use the command line tool configtxgen -printOrg Org3MSP> ../channel-artifacts/org3.json to generate the organization org3 configuration.

Get the latest configuration block

First, enter the CLI container:

docker exec -it cli bash

Set the ORDERER_CA and CHANNEL_NAME variables:

export ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem && export CHANNEL_NAME=mychannel

Pull the latest version of the configuration block and save it in config_block.pb in the form of binary protobuf:

peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA

The new organization configuration is added to the channel configuration

Use the configtxlator binary tool to parse and cut the PB format configuration and output it as config.json:

configtxlator proto_decode –input config_block.pb –type common.Block | jq .data.data[0].payload.data.config > config.json

Use the jq tool to add the org3 organization configuration generated by the preparatory work to the application group field of the channel, and the output file: modified_config.json:

jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"Org3MSP":.[1]}}}}}' config.json ./channel-artifacts/org3.json > modified_config.json

Now we have two very important json configuration files, config.json and modified_config.json. The former contains the channel configuration of org1 and org2, and the latter contains the configuration of three organizations org1, org2 and org3.

Re-encode the two json files and calculate the difference

First, rewind the config.json file back to the protobuf format and name it config.pb:

configtxlator proto_encode --input config.json --type common.Config --output config.pb

Next, encode modified_config.json into modified_config.pb:

configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb

Now use configtxlator to calculate the difference between the two protobuf configurations and output a new PB binary file org3_update.pb:

configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_config.pb --output org3_update.pb

Packaging difference cover

First, we decode this difference PB file into editable json format and name it org3_update.json:

configtxlator proto_decode --input org3_update.pb --type common.ConfigUpdate | jq . > org3_update.json

Get the decoded update file org3_update.json, then we need to restore the header information cropped in the second step and name it org3_update_in_envelope.json:

echo ‘{“payload”:{“header”:{“channel_header”:{“channel_id”:”mychannel”, “type”:2}},”data”:{“config_update”:’$(cat org3_update.json)’}}}’ | jq . > org3_update_in_envelope.json

Use the configtxlator tool to convert json into a complete and independent protobuf required by Fabric for the last time:

configtxlator proto_encode --input org3_update_in_envelope.json --type common.Envelope --output org3_update_in_envelope.pb

Sign with the identity of the existing organization in the channel

Now we have an org3_update_in_envelope.pb file that can be used to update the channel configuration. Before submitting the configuration file to the Orderer node, we need the signatures of the two existing organizations Org1 and Org2 in the channel to meet the consensus mechanism, otherwise the Orderer node will The transaction was rejected because it did not meet the strategy.

Use the signature of the Org1 administrator:

peer channel signconfigtx -f org3_update_in_envelope.pb

Next, we will switch the MSP identity to the Org2 administrator and use the signature of the Org2 administrator.

Export the environment variables of Org2:

export CORE_PEER_LOCALMSPID="Org2MSP"export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crtexport CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/[email protected]/mspexport CORE_PEER_ADDRESS=peer0.org2.example.com:9051

Use the signature of the Org2 administrator:

peer channel signconfigtx -f org3_update_in_envelope.pb

Initiate a channel configuration update call

peer channel update -f org3_update_in_envelope.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA

Add the new organization Org3 to the channel

First start the node container and cli container of Org3:

docker-compose -f docker-compose-org3.yaml up -d

The docker-compose file has been bridged to the initial network, and the two peer node containers of the cli container and Org3 can be connected to existing nodes and ordering nodes.

Enter the cli container of Org3:

docker exec -it Org3cli bash

As before, set the environment variables:

export ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem && export CHANNEL_NAME=mychannel

At this time, we go to get the genesis block of the channel. Because each ledger in the blockchain must be consistent, it is necessary to obtain the block with an index of 0:

peer channel fetch 0 mychannel.block -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA

In the previous steps, we have added Org3 to the channel configuration, so the Order node can successfully verify the signature of Org3 in this request, otherwise, the Order node will reject the request.

Add the first node peer0 of Org3 to the channel (the default env in the cli container is peer0):

peer channel join -b mychannel.block

Switch environment variables and add the second node peer1 to the channel:

export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org3.example.com/peers/peer1.org3.example.com/tls/ca.crt && export CORE_PEER_ADDRESS=peer1.org3.example.com:12051peer channel join -b mychannel.block

So far, we have successfully added the new organization Org3 dynamically to the already running fabric alliance chain network. During the tailoring of the new organization configuration, many protobuf and json format conversions were performed. The reason is that the fabric network only accepts complete binary protobuf format files, and profobuf can only achieve readable tailoring through json conversion. At the same time, due to the complex and large definition of blocks in fabric, the UML class diagram is as follows:

(The picture comes from the Internet)

Organization dynamic exit

Dynamic exit sequence diagram

Dynamic exit is to delete a business entity organization in the already running alliance chain network. The implementation steps are exactly the opposite of the dynamic addition. The prepared network environment is as follows:

Get the latest channel configuration block

Enter the cli container:

docker exec -it cli bash

Set the $ORDERER_CA and $CHANNEL_NAME environment variables:

export ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/msp/tlscacerts/tlsca.example.com-cert.pemexport CHANNEL_NAME=mychannel

Get the channel configuration:

peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA

Delete the existing organization Org3 on the channel and generate a new configuration

Convert the configuration config_block.pb obtained in the previous step to json:

configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config > config.json

Delete the organization configuration in the json file and generate a new json file modify_config.json:

jq 'del(.channel_group.groups.Application.groups.Org3MSP)' config.json > modify_config.json

Convert two important json files into PB:

configtxlator proto_encode --input config.json --type common.Config --output config.pbconfigtxlator proto_encode --input modify_config.json --type common.Config --output modified_config.pb

Calculate the difference between two configurations

Use the binary tool configtxlator to calculate the difference and generate the file org3_delete.pb:

configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_config.pb --output org3_delete.pb

Restore the cropped header information and pack it into an envelope

Convert the PB file to json:

configtxlator proto_decode --input org3_delete.pb --type common.ConfigUpdate | jq . > org3_delete.json

Restore the header information and generate json org3_delete_in_envelope.json:

echo '{"payload":{"header":{"channel_header":{"channel_id":"'$CHANNEL_NAME'", "type":2}},"data":{"config_update":'$(cat org3_delete.json)'}}}' | jq . > org3_delete_in_envelope.json

Convert the json envelope to PB format:

configtxlator proto_encode --input org3_delete_in_envelope.json --type common.Envelope --output org3_delete_in_envelope.pb

Use channel to organize identity signature

org1 organization signature:

peer channel signconfigtx -f org3_delete_in_envelope.pb

Export the environment variables of the org2 organization identity:

export CORE_PEER_LOCALMSPID="Org2MSP"export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crtexport CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/[email protected]/mspexport CORE_PEER_ADDRESS=peer0.org2.example.com:9051

org2 organization signature:

peer channel signconfigtx -f org3_delete_in_envelope.pb

Initiate a channel configuration update call

The update call is initiated by the identity of the organization org2:

peer channel update -f org3_delete_in_envelope.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA

So far, the organization org3 has been deleted from the channel mychannel. If org3 is used as the endorsement organization of a certain chain code in the channel, it participates in the endorsement of the chain code calling process. Then the original chain code will not be able to perform any invoke operations. At this time, you can update the chain code endorsement strategy through the upgrade chain code, and re-designate the endorsement organization to realize the normal operation of the chain code.

Through the dynamic operation of the fabric alliance chain, business participants can be flexibly increased or decreased, and the members in the alliance can be controlled in a fine-grained manner. Better support for business circulation, meet different business models, and complete the efficient and reliable operation of the blockchain network.

Fabric organization dynamic management

Guess you like