How to Stage Managed Blockchain Networks on AWS

For an example of how to create a managed blockchain network on AWS, we’ve decided to build a basic instance for an NGO-type company and use Hyperledger Fabric (HLF).

For building the blockchain network, a blend of AWS CloudFormation, AWS CLI, and AWS Console will be used. We will be provisioning a cloud9 instance with the Linux terminal over it. Following that, we will set up the AWS CloudFormation template for developing an HLF network.

After that we’ll set up one peer node on the Ambrosus (AMB) chain. From the Cloud9 Itself, an AWS CloudFormation template will be run as a Virtual Private Cloud, which will be an HLF client node. It will then be used for administering the HLF network.

Starting with the Fabric client node, we will form a Fabric channel, followed by installing and instantiating the chaincode which is the smart contract, and then querying and invoking the transactions over the HLF network that will be created.

Prerequisites

AWS Cloud9 will be utilized for making use of the Linux terminal with pre-installed AWS CLI. Follow these steps to prepare for creating the HLF instance:
✅ Select a Cloud9 IDE in the Console
✅ Click ‘create environment’ to start setting it up
✅ Choose the region based on where you're located
✅ Name the Environment as ‘NGO-Fabric’
✅ Choose other instance type and pick t2.medium
✅ Click on ‘create environment’.

Within 30 to 60 seconds, Cloud9 IDE will be ready and you can clone the repo from the home directory:

cd ~
git clone “git url of ngo fabric”

Also, don’t forget to update your AWS CLI by using the sudo command and pip install.

Stage 1. Creating an HLF Network

Cloud9 is used for creating the HLF network from the CloudFormation template. Here’s what you need to do in the Cloud9 terminal:

export REGION=us-west-2-lax-1a
export STACKNAME=NGO-amb
cd ~" URL for amb.sh"

Now, the cloudFormation template takes in quite a few parameters. Each of these bear a value by default, however, for this article, they are being overridden in amb.sh script. By default, the template creates an HLF Fabric network that has one peer node. However, this is not good for the production network as that necessitates a standard HLF network with a lot of peer nodes that are being spread over the AZs.

Stage 2. Establishing Network Availability

After the HLF network has been shaped, we need to check its availability status. It may take quite a while to create the network, so in the meantime, let’s prepare for the upcoming steps.

The network status can be checked in two locations:

• AWS CloudFormation Console. Search for the possessions for the stack. You also need to wait for the peer node to show the state of ‘CREATE_COMPLETE’
• AMB Console. You need to wait for the member and network, and the peer node of the member to show availability status. Once you find that the AMB network is up and running you are set for creating the HLF node.

Stage 3. Creating an HLF Client Node

The HLF client node needs to be formed to host the HLF CLI. This CLI will administer the HLF network. The HLF client node will be formed in the VPC within AWS Account, and the endpoint of the VPC will point to the HLF Network that was made during Stage1.

The AWS CloudFormation will create the HLF client node through our codes and the VPC as well as its endpoints. The template of CloudFormation asks AWS for quite a bit of parameters. The script triggered below will ensure that all these export variables are ready before you call the CloudFormation:

export REGION=us-west-2-lax-1a
cd "URL OF clientnode.sh file of vpc”

Following the above steps, the progress of AWS CloudFormation console needs to be monitored. After the Stack status shows a green signal, the required information can be found in the CloudFormation stack’s outputs tab. Keep a hold of this, as we’ll be using this information later on.

Stage 4. Registering Identity for the HLF Client Node

Before executing any command in the HLF client node, you have to carry across ENV variables to provide the HLF context. These define the HLF network client node identity, which peer nodes it will be able to communicate with, as well as the TLS certificates that will be used.

Using the Cloud9 terminal, connect to your HLF network instance with the keypair (.PEM file) located in the root directory. Take the EC2 instance DNS from the CloudFormation stack output we generated in stage3.

cd ~
ssh “user of ec2”@<EC2 instance dns> -i ~/<HLF network name>-keypair.pem

Next step is to clone the repository:

git clone "your ngo blockchain git URL" 

From now onwards you need to refer to diverse configuration standards for the HLF network. Source the folder having the ENV export standards with the context of the HLF network and apply them to the current setting.

export REGION=us-west-2-lax-1a
cd ~”url of ngo fabric directory”
cp “we need to copy the template here, paste original template directory and then available template directory”
source “Paste available template file here”
source ~”Paste peer export template file here”

By sourcing the files, two things are ensured. Completing the export of required ENV variables, and creating an additional file that has all the export standards required while working with an HLF peer node. You can find this in the ~/peer-exports.sh file, which is being sourced as well here

Next check whether the source worked. The values for each of the ENV variables mentioned below must be visible.

$ echo $PEERSRVICEENDPOINT
“the variable”
$ echo $M_S_P
“the variable”

Check if the peer export folder exists and whether it has the values for the export keys as shown below:

cat ~”peer export file”

Further the latest version of AMB PEM file needs to be overwritten and replaced with the file that is in the root directory.

AWS s3 cp “pem file url”

Next an administrator identity will be registered through the HLF CA for administering the HLF network as well as for performing the tasks like producing channels and initializing the chaincode.

export PATH=$path of bin of fabric-ca
cd ~
fabric-ca-client enroll -u “CA service endpoint URL” –“AMB pem URL” -M “Administrator MSP file path”

You also need to make some concluding replication of the certs.

mkdir -p “Admin certs of Admin MSP file path”
cp ~ “ sign certs file path of admin msp” “admin certs file path of admin msp”
cd ~”file path of ngo fabric”

Stage 5. Updating the Configuration of Configtx Channel

Over the HLF client node, the configuration of the configtx channel needs to be updated along with the Name and the ID fields and changed to the Managed Blockchain member ID.

”file path of configtx.yaml file” ~
sed -i "s|__MMBERID__|$MMBERID|g" ~/configtx.yaml

The succeeding script will now be executed to create the configtx channel arrangement. After the channel is created, the genesis chunk or the chunk 0 will be the channel arrangement for this channel.

docker exec cli configtxgen -outputCreateChannelTx /opt/home/$CHANNEL.pb -profile OneOrgChannel -channelID $CHANNEL --configPath /opt/home/

The details will be found in the output. You need to check whether the channel configuration is generated or not. This can be checked via:

ls -lt ~/$CHANNEL.pb

Stage 6. Creating the HLF Channel

Over the HLF client node an HLF Channel will be created through execution of the following code:

docker exec -e "Set TLS enabled for Core Peer to true” -e "Provide TLS Root certificate file path of Core Peer =”AMB file path " \
    -e "CORE_PEER_ADDRESS=$PEERAD" -e "CORE_PEER_LOCALMSPID=$M_S_P" -e "CORE_PEER_MSPCONFIGPATH=$M_S_P_PATH" \
    cli peer channel join -b $CHANNEL.block  -o $ORDERR --cafile $CAFLE --tls

The above step will lead to creating the mychannel.block in the CLI container directory. This directory mounts the beginning for the host HLF client node. So now we will be able to view the chunk file:

ls -lt “file path of Peer under fabric”

Executing the following command will enable the user to read the channel configuration and to prevent genesis chunks in the very directory as was discussed before.

docker exec -e "Set TLS enabled for Core Peer to true -e "Provide TLS Root certificate file path of Core Peer”=”pem file path "  \
    -e "CORE_PEER_ADDRESS=$PEERAD"  -e "CORE_PEER_LOCALMSPID=$M_S_P" -e "CORE_PEER_MSPCONFIGPATH=$M_S_P_PATH" \
    cli peer channel fetch oldest “fabric file path”-“peer file path”/$CHANNEL.block \
    -c $CHANNEL -o $ORDERR --cafile “AMB pem file path”--tls

You can check for file chunks as follows:

ls -lt “file path of peer under fabric”

Stage 7. Adding the Peer Node to the Channel

From the HLF Client Node,the PEER will now be joined to the HLF Channel by executing the following code:

docker exec -e "Set TLS enabled for Core Peer to true” -e "Provide TLS Root certificate file path of Core Peer =”AMB file path " \
    -e "CORE_PEER_ADDRESS=$PEERAD" -e "CORE_PEER_LOCALMSPID=$M_S_P" -e "CORE_PEER_MSPCONFIGPATH=$M_S_P_PATH" \
    cli peer channel join -b $CHANNEL.block  -o $ORDERR --cafile $CAFLE --tls

The displayed output will need to be noted down as it is used later on.

Stage 8. Installing Chaincode on the Peer Node

While remaining on the HLF client node, the chaincode will now be installed on the HLF peer by executing the following code:

docker exec -e "Set TLS enabled for Core Peer to true” -e "Provide TLS Root certificate file path of Core Peer =”AMB PEM file path " \
    -e "CORE_PEER_ADDRESS=$PEERAD" -e "CORE_PEER_LOCALMSPID=$M_S_P" -e "CORE_PEER_MSPCONFIGPATH=$M_S_P_PATH" \
    cli peer chaincode install -n $CHAINCODENME -v $CHAINCODEVRSION -p $CHAINCODED_I_R

The displayed output will need to be noted down as it is used later on.

Stage 9. Installing Chaincode Over the Channel

From the HLF client node, the chaincode will now be instantiated on the HLF Channel by executing the code below. The process takes up to 30 seconds.

docker exec -e "Set TLS enabled for Core Peer to true -e "Provide TLS Root certificate file path of Core Peer =”AMB PEM File path " \
    -e "CORE_PEER_ADDRESS=$PEERAD" -e "CORE_PEER_LOCALMSPID=$M_S_P" -e "CORE_PEER_MSPCONFIGPATH=$M_S_P_PATH" \
    cli peer chaincode instantiate -o $ORDERR -C $CHANNEL -n $CHAINCODENME -v $CHAINCODEVERSION \
    -c '{"Args":["init","a","200","b","300"]}' --cafile $CAFILE --tls 

The displayed output will need to be noted down as it is used later on.

Stage 10. Calling the Chaincode

Now from the HLF client node, the chaincode will be enquired in the HLF peer by executing the following code:

docker exec -e "Set TLS enabled for Core Peer to true -e "Provide TLS Root certificate file path of Core Peer =”AMB file path " \
    -e "CORE_PEER_ADDRESS=$PEERAD" -e "CORE_PEER_LOCALMSPID=$M_S_P" -e "CORE_PEER_MSPCONFIGPATH=$M_S_P_PATH" \
    cli peer chaincode query -C $CHANNEL -n $CHAINCODENME -c '{"Args":["query","a"]}

The output here should be 200.

Stage 11. Invoking A Transaction

While on the HLF fabric node, the fabric transaction will now be invoked by executing the following code.

docker exec -e "Set TLS enabled for Core Peer to true -e "Provide TLS Root certificate file path of Core Peer =”AMB PEM File” \
    -e "CORE_PEER_ADDRESS=$PEERAD" -e "CORE_PEER_LOCALMSPID=$M_S_P" -e "CORE_PEER_MSPCONFIGPATH=$M_S_P_PATH" \
    cli peer chaincode invoke -o $ORDERR -C $CHANNEL -n $CHAINCODENME \
    -c '{"Args":["invoke","a","b","100"]}' --cafile $CAFILE --tls

The displayed output will need to be noted down as it is used later on.

Stage 12. Enquire the Chaincode Once More and Crisscross the Modification in Value

At the HLF client node, the altered values need to be checked by querying the HLF Peer. This will ensure execution of the transaction that was invoked. You need to wait at least two seconds between after invoking the transaction before making queries. Execute the code for the query below:

docker exec -e "Set TLS enabled for Core Peer to true -e "Provide TLS Root certificate file path of Core Peer =”AMB PEM file path " \
    -e "CORE_PEER_ADDRESS=$PEERAD" -e "CORE_PEER_LOCALMSPID=$M_S_P" -e "CORE_PEER_MSPCONFIGPATH=$M_S_P_PATH" \
    cli peer chaincode query -C $CHANNEL -n $CHAINCODENME -c '{"Args":["query","a"]}' 

The output here should be 100.

Since ‘A’ sent 100 to ‘B’, therefore 100 remains with A (previously holding 200). This proves that the Hyperledger network was successfully created and that it can serve any organization. It is now an AWS managed blockchain network.

To finalize implementation and enable the network to be applied for NGOs, take the additional steps below:

1. Create an NGO chaincode
2. Execute the server (RESTful API)
3. Execute the Application
4. Further add new members to the web
5. Do the reading and writing into the blockchain by the help of Amazon API gateway as well as AWS Lambda
6. Finally, make use of the blockchain events for notifying the users about the donations received by the NGO.

Conclusion

Our created HLF instance is a managed Blockchain network to be used for an NGO for decentralized data storage and executing transactions. Following the example, an AWS-based managed blockchain network can be created for any type organization with Hyperledger. Feel free to drop us a line if you have any questions or need assistance in porting your blockchain network to AWS.