Get a Blockchain App into Production Fast with Hyperledger Fabric and Kaleido

By Jim Zhang, Co-Founder and Head of Protocol – Kaleido

Kaleido

Ever since its launch in 2015, Hyperledger Fabric has been a top blockchain protocol choice for enterprise use cases that require a permissioned blockchain network.

Fabric is well designed based on a modular architecture that supports the full spectrum of levels of decentralization, so it’s no surprise that multiple blockchain-as-a-service (BaaS) platforms exist that support Fabric.

However, most of these platforms target the fully decentralized governance model, with all members being equal. This makes critical procedures such as onboarding a new organization, creating a channel, or deploying chaincodes a complex process of collecting signatures and votes from multiple stakeholders.

As a result, enterprises often struggle to actually get into production with Fabric on these platforms.

Kaleido, on the other hand, makes provisioning a Hyperledger Fabric blockchain network dramatically simpler.

Kaleido, which is available on AWS Marketplace, is built on the philosophy that a Network Operator role is critical to the success of today’s enterprise consortiums. Rather than trying to force consortiums to fit into an ideal model that does not reflect the practical challenges existing today, this approach helps consortiums succeed in the real world, and get their apps into production faster.

The Case for Network Operators-Centered Design

Before diving into the Fabric support on Kaleido, we first need to understand the Kaleido platform’s design philosophy that is centered around the Network Operator role.

While blockchain protocols solved the technical challenges with governance, making decentralization the foundation of transaction finality and data immutability, in real-world consortiums an organizational governance model is still a separate piece of the puzzle independent of the blockchain protocol.

Using an example, ERC20 is a popular standard for non-fungible tokens (NFTs) with hundreds of deployments on Ethereum mainnet alone.

While Ethereum mainnet itself is fully decentralized, with tens of thousands of block mining nodes, most ERC20 tokens deployed on Ethereum mainnet employ a centralized governance model. The prevalent practice is that the deployer of the token contract is given special privileges to become one of the select few, sometimes the only, identities who can mint new tokens.

This is not a scam scheme but a reflection of the need for a governance model that makes things work in the real world.

Now, let’s zoom in on the world of enterprise consortiums. From working with hundreds of companies both large and small—including many leading consortiums for industries like healthcare, insurance, banking, retail, global trade finance, manufacturing, and others—Kaleido has observed the dynamics of multiple companies and organizations that are often competitors trying to collaborate in a consortium setting.

A key observation is that for such consortiums to function and realize the promise of the peer-to-peer blockchain network, a central entity that defines and implements the governance policies is critical.

It’s important to note that a centralized governance model does not negate decentralization on other layers. For a detailed discussion on different layers of decentralization, check out this blog post on What is Blockchain Decentralization?

This design philosophy has led to some unique platform features on Kaleido compared to other BaaS providers. Any user on an appropriate subscription plan, either Business or Enterprise, can initiate a consortium and invite other organizations to join, which makes the initiator’s organization the designated Network Operator of the consortium.

This organization has the authority to delegate key privileges to the invited organizations, or choose to keep the privileges to themselves.

These privileges include the ability to:

• Provision blockchain nodes that are permitted to propose blocks. Without this privilege, a member organization can only provision blockchain nodes that can replicate blocks proposed and regulated by other nodes.
• Create and upgrade blockchain environments.
• Invite other organizations.
• Create multiple memberships in the consortium under their organization.
• Deploy smart contracts.

Fabric support on Kaleido can leverage this governance model and streamline the complex processes involved in the key procedures, such as creating channels and deploying chaincodes.

Details on Kaleido’s Fabric Support

Node Deployment

To start off, as with the existing blockchain protocols, Kaleido supports a full range of node deployment options, including:

• Fully managed cloud-based deployment with AWS across six regions (US east, US west, Europe central, Europe south, Asia north, Asia south) and three continents.
• Self-managed cloud-based deployment with any cloud vendor.
• Self-managed private data center-based deployment.

Raft is the only consensus algorithm available to choose from at the moment. Given the complexity of managing an Apache Kafka cluster and its centralized nature, the Kafka-based consensus implementation is no longer recommended.

As a practical limitation, given Raft consensus algorithm’s sensitivity to networking latency, all orderer nodes must be provisioned in the same region. Orderer nodes can only be provisioned inside a Kaleido region as fully managed nodes, but for peer nodes all deployment options are applicable.

Channel Management and Policies

All Fabric blockchain environments on Kaleido have a built-in channel that includes all of the member organizations and the orderer and peer nodes.

This is useful for application developers to quickly get started, as well as acting as a public utility channel holding global information and common utility chaincode services that are available to all the members of the environment. The name of the built-in channel is default-channel.

Figure 1 – Member organizations, orderer nodes, and peer nodes in the Fabric environment.

The design philosophy of the Network Operator-centered design is best reflected in the policies that Fabric channels in Kaleido are configured with by default. These policies are displayed in the details panel of the channel.

Figure 2 – Detail panel showing the Fabric channel’s default policies.

For the “Channel Membership Administration” policy, which governs approval of channel memberships, the formula is “OR('u0vgwu9s00.admin')”. The string ID “u0vgwu9s00” represents the membership of the channel initiator organization.

This policy gives the channel initiator organization the sole responsibility of adding or deleting channel memberships.

For the “Channel Consensus Administration” policy, the same formula is applied. This default policy is chosen to allow the member organization of the Network Operator role to effectively perform its duty vested in them by the general member organizations.

Of course, if the consortium takes a different shape and does not include a Network Operator role, then different policies can be applied. Support for specifying non-default policies including custom formulas is coming soon.

Chaincode Management

Chaincode management, including deployment and upgrading, is streamlined as well. This takes advantage of the platform-level smart contract management support in Kaleido.

A chaincode lifecycle starts with the chaincode developers, who develop and test the chaincode program. At some point, the program is deemed ready for review and approval by the technical committee of the consortium. Once approved, the contract code must be uploaded to the consortium for version management and deployment to individual environments and channels.

The Kaleido smart contract management allows the Network Operator, or any other member organizations that have been delegated with the “Manage Smart Contract” privileges, to upload Fabric chaincodes to the consortium’s shared storage. This makes it visible to all member organizations.

For this step, an app project must first be created. Two types of chaincode implementations are supported:

• Golang binary: This must be the binary executable compiled from the golang chaincode.
• Node.js project: This must be the project that contains a node.js application with a package.json describing the module details. The module can be written in JavaScript or typescript.

Figure 3 – Select the chaincode type planned for deployment in the app project.

Inside the chaincode project, deployments are uploaded and versioned. According to the Fabric chaincode specification, each deployment must be given a version string.

The cleansed app name appended with the version string plus the membership ID (which is also the managed service provider {MSP} ID) forms the label of the chaincode deployment.

For instance, in the above example, the app project is named “Asset-Transfer”, the uploaded chaincode deployment is given the version string “v1”, with the membership ID of the operator being “u0lmaqk8dn”, the label is calculated as “asset_transfer-v1.u0lmaqk8dn”.

Figure 4 – Specify details of the chaincode to deploy.

The chaincode is now ready to deploy into a blockchain environment. Click the Promote to Environment button and select the target environment to deploy to.

Upon promotion, the chaincode is available in the environment but still needs to be installed on the peer nodes, approved, and committed to the desired channels that will use it.

This again can be accomplished by a process triggered from the channel’s initiator organization, and completed without manual intervention from the other member organizations. This is possible thanks to the underlying governance model.

Figure 5 – Deploy the chaincode to the channel after just a few streamlined steps.

In summary, for a channel of any number of member organizations, creation of the channel or deployment of chaincodes can be accomplished in a few streamlined steps. This can be done without having to resort to coordination among the member organizations for digital signatures collection, which tend to get bogged down by the complexity of the communications and procedures in practice.

The Network Operator is able to perform its duty, and the member organizations are able to quickly proceed to the actual business of building the solutions and applications.

REST API for Interacting with Fabric Nodes

Fabric API is based on gRPC, which is an efficient binary wire format. The Fabric transaction model, like almost all blockchain protocols, requires the client to adopt an asynchronous, event-driven programming paradigm.

Powerful client software development kits (SDKs) are available for multiple languages, including golang, node.js, and Java. As with most blockchain protocols, programming with the SDK is a steep learning curve.

Most application developers would rather deal with RESTful APIs using wire formats that are more universally supported than gRPC, such as JSON.

This is where the Fabric Connector comes in. As part of the Hyperledger FireFly project, the firefly-fabconnect component provides a RESTful interface for submitting transactions using JSON payloads. Subscribing to block events or chaincode events that can be delivered in multiple streaming interfaces including websocket connections and webhooks.

With the Fabric Connector, the application developers’ job is made extremely simple. They can accomplish everything involving the Fabric blockchain by using familiar technologies without having to be trained on the Fabric transaction model and learning to use the complex SDKs.

Conclusion

Kaleido supports Hyperledger Fabric by making practical decisions where real-world actors’ experiences are improved without sacrificing the value of the blockchain (data immutability and distributed transaction processing).

Kaleido provides fast time from consortium formation to ready-to-submit-transaction with a fully configured Fabric blockchain. Finally, Kaleido’s full stack approach to the solution development support beyond simple blockchain-as-a-service (BaaS) makes it an ideal platform for building the next generation of collaborative multi-party IT solutions.

To try out Kaleido for yourself, open an account for free. In a couple of minutes, with the free starter plan, you’ll have a fully functional Fabric blockchain network to test with.

Let us know if you have any questions by submitting tickets from inside the console, or send an email to support@kaleido.io.

The content and opinions in this blog are those of the third-party author and AWS is not responsible for the content or accuracy of this post.

.

.

Kaleido – AWS Partner Spotlight

Kaleido in an AWS Partner that provides organizations with a simple and cost-effective platform for launching digital asset solutions and building private blockchain networks.

Contact Kaleido | Partner Overview | AWS Marketplace

*Already worked with Kaleido? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.