Blockchains and blockchain applications are everywhere. There is absolutely no way around it. We are all quite familiar with one of the applications of blockchain - cryptocurrencies. But apart from it, there are many other interesting applications of this wonderful technology that has lead to the development of many exciting software ecosystems. By the exciting software ecosystems, we are pinpointing towards the Hyperledger project, which is a remarkably modular blockchain framework.
In this blog, we shall see how do we implement a blockchain application with Hyperledger Fabric and Composer.
In Hyperledger, the developer does not build a single blockchain framework or platform. Rather, the primary focus is on pursuing several approaches in parallel, creating synergies, reusable components and flexibility. Going by the Hyperledger concepts, it is not possible to compare blockchain network with the crypto currencies such as Bitcoin or Ethereum. Instead of this, we distribute the nodes of the Hyperledger networks across the participating organizations. This makes it particularly interesting for private, permissioned or consortium blockchain networks.
Initially we can neglect the prominence Proof of Work, Proof of Stake and other consensus mechanisms from the territory of public blockchain. The organizations involved in the network validate each other’s transactions and benefit wholly as a consortium from the applications business value and the trust involved. We can solve the scalability problems to a great extent and make a high valued transaction possible through the network.
There are different blockchain approaches to the project Hyperledger. They are Fabric, Burrow, Iroha, Indy and Sawtooth. We can develop Private, permissioned and consortium blockchains with each of them, but the implementation follows a different approach.
In this blog, we shall focus our attention on Fabric as it has the most active online community and is of the most flexible of the variants of the project. Hyperledger Fabric is universally usable because of its strong modularization.
According to the words of Brian Behlendorf , Executive Director of Hyperledger at the Linux Foundation“You could think of Hyperledger Fabric as kind of like an Apache Web Server.”
The other approaches are incline more for the purpose of the implementation of special cases in limited contexts.
We can develop a completely individual distributed ledger solutions with Fabric as a platform. Fabric contains a lot of concepts that can be implemented in a free manner.
Modeling of the desired organizational structure is the basis for a blockchain network. Each participant will have a fixed identity and this identify is verified itself through issued certificates. In addition to this authentication, authorization is also covered. Using this role-based system, we can give the flexible aspects of privacy and confidentiality in permissioned blockchains.
We can use the Fabric Certificate Authority for the for the administration of certificates and participants.
The definition of assets and the items that are to be managed on the blockchain is entirely up to the blockchain application. These assets that includes engine blocks from the automotive industry can be defined by a model of key-value pairs in JSON and/or binary format.
The intention of the concept of the chain code is for the implementation of the business logic based on the assets and their owners. We can use this to implement rules in languages such as Go, Java or Node.js that define read rights or modifications to assets. We can execute a chain code function that can read and return assets and/or create and modify assets and store them in the local ledger database. After the local persistence of the changes on a node, the developer can propose changes to the network. By network, we mean the endorsement. After it has been accepted by other organisations, it is later on inserted into the blockchain. Wecan compare the Chain code to Smart Contracts in the context of Ethereum or other public blockchain platforms.
Areas of privacy are implemented by the channels. In the very simplest scenario, the entire chain code can be deployed on a single channel to which all the participants join. However, in order to create encapsulated areas and allow only selected participants to communicate in them, we can configure the channels with restricted participant groups. We can deploy different chain codes per channel, so that we can achieve functional isolation. In addition to this, communication in the channel can be partially or completely encrypted with AES.
As a result of this, a distributed ledger is maintained in each channel. We can imagine this as a cash book of linked transactions. For every channel that he/she is a member of,each participant keeps a copy of the ledger. This will create a blockchain data structure for each existing channel in the network.
Along with the assets, we can define the scheme of network participants, transactions and events in the Composer Modeling Language. We can implement the flows for each transaction type on a simple API through JavaScript code. We can use the access control files to limit the access rights for participants to certain resources. We can define the frequently used queries on the data in the ledger in the Composer Query Language, a SQL-like language.
We need to pack all required files to a BND (Business Network Definition) in a .bna file. This archive is later on installed on an existing Fabric network. The source code for BNDs is then developed and tested locally in our preferred editor and can be versioned via Git.
There is an entity called Composer Playground for prototyping and demo purposes. This will give is a modern, clear and intuitively usable web interface that will access all the local configurations of the Composer CLI. Using the Playground the developer can easily create, install, test, edit, import and export BNDs.
In the Composer Playground, we can install, modify and test a new business network in a user-friendly manner and without much previous knowledge from sample blockchain applications. We can do the same locally after setting up the tools, post which we can leave the hosted playground after playing around with it for a short while.
We find this playground ideal for validating ideas using prototypes and getting an actual feel for the underlying Composer & Fabric model.
The next step in the series is the installation of the required tools and setting up the project.
The composer-playground web-UI can be started via composer-playground while the network is running. All managed configurations of the composer-cli is used by it and it accesses the running Fabric network. Now, we see Fabric more as a configurable platform/infrastructure whose state can be changed with suitable tools. It is not necessary to develop chain code, permissions or any models directly with Fabric concepts since the Composer provides more advantages.
Now, we shall open the folder in the editor that we like. Visual Studio Code is very appropriate for Composer because it comes with an installable extension for syntax highlighting. After a short observation, we will notice that it is an NPM project, so we will have to install all dependencies beginning with npm install. With npm test, it is possible to run the unit tests. We can test the code style with npm run lint . We can create the.bna file with npm run createArchive. Now, we have our finished business network definition in a packaged format.
Now, we shall try it to find if everything works perfectly.
Then we familiarize ourselves with the project structure. The JS files are in the lib/ folder and these implement the transaction processor functions. We will have to test this business logic and then store our unit tests in the test/ folder. models/ will have the Model definitions (participants, assets, transactions etc.) The desired blockchain network will have to be designed first. For doing this, we will delete the content of the model file and then give it a new namespace in the first line:
namespace org.acme.enginesupplychain
The participants manufacturers and dealers are modelled as such and we use the inheritance of the Composer modeling language. We also need each participant to have an optional address along with their name. Now, we shall put these attributes into a concept:
participant Member identified by memberId {
o String memberId
o String name
o Address address optional
}
participant Manufacturer extends Member {
}
participant Merchant extends Member {
}
concept Address {
o String country
o String city
o String street
o String streetNo
}
Now, we introduce the assets of our network. We shall later on install the the engine blocks and cars in which the engines are installed. From this, we know that the assets and participants can refer to each other. A reference always points towards an existing resource of any type. Properties that we begin with a small “o” always live within the resource itself.
asset Engine identified by engineId {
o String engineId
o EngineProperties data
--> Manufacturer manufacturer
--> Car currentCar optional
--> Merchant merchant optional
}
asset Car identified by carId {
o String carId
o String legalDocumentId
}
concept EngineProperties {
o String brand
o String model
o Double horsePower
o Double cubicCapacity
o Integer cylindersAmount
}
Once this system is modelled, we shall now define all the available operations that can be executed on top of the existing assets and participants we imply the transaction resources. The underlying transaction logic are tested and implemented for each of the following transaction models afterwards.
transaction EngineMerchantTransfer {
--> Engine engine
--> Merchant merchant
}
transaction EngineCarInstallation {
--> Engine engine
--> Car car
}
transaction EngineCreation {
--> Manufacturer manufacturer
o EngineProperties data
}
transaction CarCreation {
o String legalIdDocument
}
Now, we have portrayed what can happen, it is time we start implementing how it’s affecting the ledger state at the time of the submission of the transaction. First we need to create an engine asset. An engine will get a randomly generated ID in UUID format. It will always belong to a manufacturer right from the start.
So we will empty the logic.js file and then start from the beginning. We shall define the constant “modelsNamespace” and the function “uuid” because they are needed more often.
We will follow this by the “createEngineAsset” function. The documentation block above the function is an important element here. It is because of this that the Composer recognizes which transaction type is implemented when packaging the code.
The process of unit testing of the functions is relatively a very simple task. An experienced developer can do this without much of a learning process. The objects need to be bootstrapped for this and it is kin of overloaded with boilerplate code. We first start the tests in an in-memory Fabric network, and then install the business network on it and authenticate themselves further against it as default admin. To fo this,Composer provides the libraries with a “composer-admin”, “composer-client”, “composer-common” and “composer-connector-embedded”.
After the test setup, it is now possible to write test cases against the embedded network. We have not included the setup code in the listing because of its length, but if you want, you can view and test it on the master branch in test/example.js.
The unit test cases for testing a transaction type has a similar scheme of things A transaction with its properties and relationships is recreated, and then it is executed against the network. Later on, the data status of the assets and participants involved is checked.
It is clear about the way to implementing Business Network Definitions in Hyperledger Composer with these examples. Along with this, we can define a few things with a BND. In permissions.acl, a Access Control Language can be used to define access restrictions for participants to resources given a simple condition. The features of the event and query are also very useful and exciting for many applications.
In the end, you should take a look at the solution on the master branch. All of these requirements have been implemented and tested in it. Now, the finished “.bna” file with npm run createArchive can be generated, which is then in the dist/ folder. It can then be imported into the Composer Playground. We had started this in the console, to try it out on our local Fabric network. Though the way through the web UI sis officially documented, it is quite self explanatory in nature.
From the case of the implemented blockchain application about the production and tracking of engine blocks, we now know of a very simple and at the same time powerful scenario of the usage for private/consortium blockchains.
The blockchain network that resulted from this was initially executed at a local scale. It has not expanded the configuration of the peer organizations and the ordering service. eBut it is absolutely easy to add more organizations and distribute the peer nodes via multiple hosts.
However, for a blockchain network to be adopted and spread by a real organization consortium, there are still a few more problems that needs to be addressed quickly.
The first and foremost among this is the management of the organizations and peer nodes. It should be first figured out how can organizations automatically add new peer nodes to the network. We need tp get a fair and homogeneous network that can withstand failures. There should be a mechanism through which clients can communicate with the network.
Despite of being a young platform, it already offers a lot of functions and comfort. However, , there are a lot of additional tasks to be completed. From the point of view of a developer , the test code of the unit seems a little bloated. Libraries will follow this soon and the usual test patterns can be implemented more easily with this.
Get the customized Hyperledger Application