Welcome to the Supply Chain application which allows nodes to track products or goods along their chain of custody, providing everyone along the way with relevant data to their product. The implementation has been done for Hyperledger Fabric and R3 Corda. The two will slightly differ in behavior but follow the same principles. There are two types of items that can be tracked, products and containers. Products are defined as such:

The creator of the product will be marked as its initial custodian. As a custodian, a node is able to package and unpackage goods. Packaging a good stores an item in an existing ContainerState structured as such:

Products being packaged will have their trackingID added to the contents list of the container. The Product will be updated when its container is updated. If a product is contained it can no longer be handled directly (ie transfer ownership of a single product while still in a container with others).

• this prevents allocation or sale of individual products which is sometimes needed

Any of the participants can scan the QR code to claim custodianship. History can be extracted via transactions stored on the ledger/ within the vault.

As mentioned before, items are identified by their QR code. These codes are meant to be generated about a product and used to interact with a product. The QR will store a parsable JSON body with the following format:

Also containers are identified by their QR code. These codes are meant to be generated about a container and use to interact with a container. The QR will store a parsable JSON body with the following format:

Prerequisites

• The supplychain application requires that nodes have subject names that include a location field in the x.509 name formatted as such: L=<lat>/<long>/<city>
• Fabric or Corda network of 1 or more organizations

Setup Guide

The setup process has been automated using Ansible scripts, GitOps, and Helm charts. The files have all been provided to use and require the user to populate the network.yaml file accordingly.

The playbooks are as listed:

• platforms\r3-corda\configuration\deploy_cordapps.yaml
• platforms\hyperledger-fabric\configuration\chaincode-install-instantiate.yaml
• examples\supplychain-app\configuration\deploy-supplychain-app.yaml

These playbooks make use of several roles defined within

• create/corda/api_components
• create/corda/api_values
• create/fabric/api_components
• create/fabric/api_values
• create/frontend

They are responsible for creating the helm release files for the platform specfic rest service, the nodejs api abstraction layer, and the front end.

Jenkinsfiles have also been provided to automate the execution of these playbooks and other additional steps:

• buildFrontendImages.jenkinsfile - Build images for frontend and pushes to the desired container repository
• buildImages.Jenkinsfile - Build images for rest server and nodejs application
• deployChaincode.Jenkinsfile or deployCorDapps.Jenkinsfile - Follows the necessary steps to deploy the platforms smartcontracts to the existing network
• deployApp.Jenkinsfile - Uses ansible playbooks to create helm releases which GitOps uses to deploy the rest server, nodejs app, and frontend images.

The jenkins pipelines can automate the execution of the ansible playbooks as well as pass in any values that are not to be hardcoded in the network.yaml file

smaple-home/generate/qr

Multi-Cloud service providers support

The Blockchain Automation Framework’s scripts do not stick to any one of the Cloud service provider. On the contrary, they can be used on any Cloud platform as long as all the prerequisites are met.

Multi-DLT platforms support

The Blockchain Automation Framework supports an environment of multi-clusters for the spin-up of a DLT network (e.g. Hyperledger Fabric or R3 Corda). Regardless of unique components (e.g. channels and orderers in Fabric, and Doorman, Notary in Corda) designed in each platform which makes the DLT ecosystems be heterogeneous, the Blockchain Automation Framework does remove this complexity and challenge by leveraing a uniquely-designed network.yaml file, which enables set-up of a DLT network on either platform to be consistent.

No dependency on managed K8s services

Setting up a DLT network does not depend on a managed K8s services, which means non-managed K8s clusters can be used to make a DLT network set-up happen.

One touch/command deployment

A single Ansible playbook called site.yaml can spin up an entire DLT network and a substantial amount of time can be reduced which is involved in configuring and managing the network components of a Corda or Fabric DLT network.

Security through Vault

HashiCorp Vault is used to provide identity-based security. When it comes to managing secrets with machines in a multi-cloud environment, the dynamic nature of HashiCorp Vault becomes very useful. Vault enables the Blockchain Automation Framework to securely store and tightly control access to tokens, passwords, certificates, and encryption keys for protecting machines, applications, and sensitive data.

Sharing a Network.yaml file without disclosing any confidentiality

The Blockchain Automation Framework allows an organization to use a configured network.yaml file to set up an initial DLT network and a first node in the network, and allows this file to be shared by new organizations that will have to join this DLT network to reuse this network.yaml file, but without revealing any confidential data of the first

Installation

There are two approaches to installing Vault:

• Using a precompiled binary
• Installing from source

Downloading a precompiled binary is easiest and provides downloads over TLS along with SHA256 sums to verify the binary. Hashicorp also distributes a PGP signature with the SHA256 sums that should be verified.

Securing RPC Communication with TLS Encryption

Securing your cluster with TLS encryption is an important step for production deployments. The recomended tool for vault certificate management is Consul. Hashicorp Consul is a networking tool that provides a fully featured service-mesh control plane, service discovery, configuration, and segmentation.

Consul supports using TLS to verify the authenticity of servers and clients. To enable TLS, Consul requires that all servers have certificates that are signed by a single Certificate Authority (CA). Clients should also have certificates that are authenticated with the same CA.

After generating the necessary client and server certificates, the values.yaml file tls field can be populated with the ca.cert certificates. Populating this field will enable or disable TLS for vault communication if a value present.

The latest documentation on generating tls material with consul can be found at: https://learn.hashicorp.com/consul/security-networking/certificates