This article is an excerpt taken from the book Hands-On IoT Solutions with Blockchain written by Maximiliano Santos and Enio Moura. In this book, you’ll learn how to work with problem statements and learn how to design your solution architecture so that you can create your own integrated Blockchain and IoT solution.
In this article, you will learn how to install your own blockchain network using Hyperledger Fabric and Composer.
Hyperledger is growing its society one member and one company, or in this case nine companies at a time as reported on the community’s official website. The open source project is a community collaborative effort to bring the wonders of blockchain to businesses and help advance the technology across various industries in the world today.
The announcement stated that Hyperledger will be adding the Special Interest Groups (SIGs) to the community. There are currently four SIGs in operation which include Hyperledger Trade Finance Special Interest Group, Hyperledger Social Impact SIG, Smart Contract Working Group and the latest addition, Telecom SIG.
A new document explains how blockchain transactions can be verified without having to reveal the details. Some of the model’s implementations include Idemix and Hyperledger Indy.
Transparency is considered by many to be one of blockchain’s most important traits. However, there are businesses, such as those in finance, which deal with sensitive information. In these situations, transparency takes a step behind privacy. For organizations operating with confidential information, implementing blockchain transactions with zero-knowledge proof (ZKP) is a solution to consider.
Altoros, a General Member of Hyperledger and an expert in blockchain development and training, has released a research paper exploring how to ensure privacy while still providing transparency on a blockchain.
Who can benefit from ZKP?
In a nutshell, ZKP is a method in cryptography where a prover can convince a verifier that it knows a secret value, without actually disclosing any information apart from the fact that it knows the secret value. While this requires some input from the verifier (e.g., challenging a response), there is also a form of this model called noninteractive ZKP, which does not require such an interaction between the two parties.
Avoiding linkability between certificates using ZKP protocols such as Idemix (Image credit)
Applications that benefit from ZKP are those that require a measure of data privacy. Some of these example applications include:
Authentication systems. The development of ZKP was inspired by authentication systems, where one party needed to prove its identity to a second party through some secret information, but without revealing the secret altogether.
Anonymous systems. ZKP can enable blockchain transactions to be validated without the need to reveal the identity of the users making a transaction.
Confidential systems. Similar to anonymous systems, ZKP can instead be used to validate blockchain transactions without revealing pertinent information, such as financial details.
ZKP implementations: Idemix and Hyperledger
In Hyperledger Fabric, privacy-preserving authentication and transfer or certified attributes can be done using Identity Mixer (Idemix), a ZKP-based cryptographic protocol. Its implementation consists of the three components:
A core Idemix cryptopackage (in Golang), which implements basic cryptographic algorithms (key generation, signing, verification, and zero-knowledge proofs)
MSP implementation for signing and verifying transactions using the Identity Mixer cryptopackage
A CA service for issuing ECert credentials using the Identity Mixer cryptopackage
The Idemix architecture within Hyperledger Fabric
This combination provides:
anonymity (sending transactions without having to reveal your identity)
unlinkability (sending multiple transactions without revealing that all the transactions come from the same source)
Based on Idemix, the Hyperledger Indy project was built for managing decentralized, independent digital identity. It utilizes the so-called Indy-anoncreds to cryptographically secure credentials. Just a couple of days ago, it was announced that The Hyperledger Technical Steering Committee (TSC) had approved Indy to graduate from incubation to the active status.
For more details on ZKP, the zkSNARK protocol, and noninteractive ZKP implementations (such as Idemix and Indy), check out the full research paper.
Back to our Developer Showcase Series to learn what developers in the real world are doing with Hyperledger technologies. Next up is Juan Navarro of Biztribution.
What advice would you offer other technologists or developers interested in getting started working on blockchain?
First, I recommend having a look at Anders Brownworth’s website “how blockchain works”. It’s a very easy way to understand how and why blockchain works. Next, add some PKI infrastructure reading to know who did what and… congratulations! Now, you know the foundations of blockchain.
When it comes to Hyperledger Fabric, don’t let the seeming complexity make you reluctant to dive in. At first sight, Hyperledger Fabric may look a bit overwhelming with a lot of different technologies and configuration files.. However, to quote Albert Einstein: “Learning is experience. Everything else is just information.” Don’t be afraid of the vast amount of documentation you can find about Hyperledger. Instead, I recommend, start with the Fabric demo. Then, watch Chaincode for developers and some of the other online examples. Suddenly, everything will begin to make sense and you will start to understand the architecture and its beauty.
Give a bit of background on what you’re working on, and let us know what was it that made you want to get into blockchain?
Our project is related to giving governance of content distribution back to airlines. Airlines are competitors and partners at the same time. For that reason, they have to share some information continuously and keep other information private. In order to achieve that today, they rely on third parties that centralize all their data to retail their contents, specifically over indirect channels. We have identified blockchain as the answer to solve this puzzle, and Hyperledger Fabric as the technology the industry needs.
What project in Hyperledger are you working on? Any new developments to share? Can you sum up your experience with Hyperledger?
We are mainly working with Hyperledger Fabric. At the moment, we have successfully done several lab proofs-of-concept with millions of routes, availabilities, fares, geographic data, etc. It is amazing to see how the information flows among peers.
What do you think is most important for Hyperledger to focus on in the next year?
Pluggable interfaces and documentation.
Performance metrics as a function of transactions/sec, peers, consensus, channels, participants, orderers, etc. It would be great to get an answer to the white paper published by the Performance and Scalability Working Group.
Guidelines about how many orderers we need to deploy as a function of organizations, transactions, peers, performance, etc.
As Hyperledger’s incubated projects start maturing and hit 1.0s and beyond, what are the most interesting technologies, apps, or use cases coming out as a result from your perspective?
Sovereign ID initiatives. I am very careful about sharing my personal data. I have always asked myself “why do I have to give my ID when I subscribe to a service, in hotels, shops, etc.?” Are there other alternatives that fulfill regulatory requirements and preserve my privacy at the same time?
What’s the one issue or problem you hope blockchain can solve?
Well, our goal is to reinvent an industry by creating a new revolutionary, automated and simple distribution model for the travel and tourism ecosystem. Based on Distributed Ledger Technology, we enable airlines to regain control over their contents. This creates a shift towards a fully decentralized scenario in which flexibility and de-commoditization are achieved, translating into more efficient operations and a significant reduction in distribution costs.
Where do you hope to see Hyperledger and/or blockchain in 5 years?
I hope to see Hyperledger in a lot of interactions on a daily basis where end users are not even able to perceive that Hyperledger is working behind the scenes. That’s the magic of technology!
What is the best piece of developer advice you’ve ever received?
Don’t write a single line of code until you have a clear understanding of what you want to get done.
What technology could you not live without?
Short answer: Linux and… Linux!
At home, I’m a big fan of Raspberry Pi because you have a great computer with a very low energy consumption and no noise. With it, I have IPTV, home automation, VPN and content filtering for kids.
At work, micro services architecture! Once you try it, you can’t live without it!
Every devops engineer knows the importance of continuous integration (CI) testing. It’s vital to prevent regressions, as well as maintain performance, security, and supportability. At Bitwise IO, we are experimenting with Kubernetes as an automated CI deployment tool. We like the simplicity of extending tests with deployments on Kubernetes. We think Kubernetes has compelling potential for use in the CI workflow.
Figure 1: The main tools in our CI workflow
This blog post explains how Kubernetes fits into our CI workflow for Hyperledger Sawtooth. We don’t go into detail, but we provide links so you can learn more about Kubernetes and the other tools we use.
Hyperledger Sawtooth uses Jenkins to automate builds of around 20 GitHub repositories. Each new or merged pull request in the master branch initiates a build that contains project-specific tests. The next logical step is to deploy into a test environment.
We have two deployment methods: Debian packages and Docker images. We install the Debian packages inside the Docker deployment image to ensure both that the binaries are tested and that the packages are installable.
Using Docker’s multi-stage build capability, an intermediate build container makes the deployment image smaller and narrows its exposed attack surface (possible vulnerabilities).
Handing off Docker Images with Docker Registry
Jenkins is a great place for build artifacts, but Docker has its own way to easily retrieve images. Docker Registry allows you to push your newly created images and easily retrieve them with Docker, Kubernetes, or anything else that uses the Docker Registry model.
This example shows how to tag an image with the URL of an internal registry, then upload the image to that registry.
We also use Portus, because Docker Registry does not provide user and access management on its own. The Portus project makes it simple to place an authentication layer over Docker Registry. Now, any authenticated user can pull and deploy the same images that are being deployed into the test environment.
Kubernetes: Simulating Scaled Deployments
Kubernetes excels at creating deployments within and across abstracted infrastructures. We have done our experiments on local (“on-prem”) hardware with a cluster of small Kubernetes nodes dedicated to Sawtooth deployments. Each deployment consists of several pods partitioned in a namespace, which allows us to run multiple networks based on the same deployment file. (Without namespaces, Kubernetes would think we are updating the deployment.) A pod represents a Sawtooth node and contains several containers, each running a specific Sawtooth component: validator, transaction processor, REST API, and so on. Each namespace can have independent quotas for resources such as CPU time, memory, and storage, which prevents a misbehaving network from impacting another network.
Figure 2: Containerized services grouped together in pods.
Because we use Kubernetes, these deployments are portable. We can use them on any cloud infrastructure that supports Kubernetes.
Kubernetes also allows us to scale the number of CI test deployments. With an elastic cloud infrastructure, Kubernetes provides effortless testing on a large number of virtual systems (limited only by the cost of cloud hosting). This solves the issue of limited hardware resources, where each additional deployment will stress existing deployments when they share a node’s resources.
Workload Generation: Deploying Changes Under Load
Deploying Sawtooth is the first step, but you need to give it something to do—better yet, lots to do. Sawtooth includes several workload generators and corresponding transaction processors. In our Kubernetes environment, we deploy intkey_workload and smallbank_workload at rates slightly above what we think the hardware can handle for shorter runs.
Modifying workload rates is as simple as editing the deployment file, changing the rate settings, and reapplying with kubectl. When Kubernetes detects that the pod’s configuration has changed, it terminates the existing workload pod and creates a new one with the changed settings.
This example shows a container definition for an intkey workload pod.
Retaining Data with Kubernetes: Logging and Graphing
All this testing isn’t much use if you can’t troubleshoot issues when they arise. Kubernetes can streamline deployments, but it can also frustrate your attempts to gather logs and data embedded inside Docker containers after a pod has failed or stopped. Luckily, Sawtooth provides real-time metrics (which we view with Grafana) and remote logging through syslog. We actively collect logs and metrics from the Sawtooth networks, even down to syslog running on the hardware, then carefully match the logging and metrics artifacts to the testing instance. In the end, we can provide a comprehensive set of log data and system metrics for each code change.
Richard Berg is a Senior Systems Engineer at Bitwise IO. He has several years’ experience in sysadmin and devops roles. When not behind a terminal, Richard can be found in the woods with his snow-loving adventure cat.
Ben Betts is a Senior Systems Engineer at Bitwise IO. Ben has lots of experience with deploying, monitoring, coordinating, and supporting large systems and with writing long lists of experiences. He only uses Oxford commas because he has to.
Hyperledger, “the gold standard for corporate blockchain projects,” powers half of the “Forbes Blockchain 50,” according to a new set of articles deep diving into the state of enterprise blockchain.
This week, Forbes took on the challenge of chronicling “the rise of so called ‘enterprise’ blockchain” with the creation of its inaugural Blockchain 50, a list of 50 of the biggest companies deploying DLT technology within their operations. Forbes also captured the blockchain platforms at work in each of the 50 companies on its list. Half of the companies on the list, including Amazon, Cargill, CVS, IBM, Seagate, Visa and more, are using Hyperledger technologies.
The list was accompanied by the in-depth, case study-filled feature “Blockchain Goes to Work,” which welcomes readers to “the brave new world of enterprise blockchain, where corporations are embracing the technology underlying cryptocurrencies like bitcoin and using it to speed up business processes, increase transparency and potentially save billions of dollars.”
Hyperleger has focused exclusively on enterprise blockchain and DLT solutions, applying rigorous standards to how open source blockchain is developed. The recognition that some of the world’s largest organizations are building on Hyperledger is validation for the course set three years ago by Executive Director, Brian Behlendorf, to be the premiere community advancing the commercial adoption of blockchain tech.
The Forbes articles solidified Hyperledger technologies’ position as the de facto infrastructure for enterprise blockchain. Or, as Forbes says, “the gold standard for corporate blockchain projects.”
The transition from possibility to reality is well underway, which makes it more important than ever that we push ahead with a transparent, rigorous community-driven development across all our current and future projects. Our community is conceiving, building and deploying foundational technologies that are forever changing the way global companies, customers and communities interact.
Today, we’re delighted to share that we have been working with fellow Hyperledger members, Blockchain Technology Partners (BTP), to integrate the DAML runtime with Hyperledger Sawtooth! In this blog post, I’ll describe why we believe it’s important to architect a DLT application independently of the platform, why a new language is needed for smart contracts, and why we are working with BTP to integrate it with Hyperledger Sawtooth.
“Following the recent announcement that DAML has been open-sourced, we are delighted that work is already underway to integrate the DAML runtime with Hyperledger Sawtooth. This demonstrates the power of the open source community to enable collaboration and give developers the freedom required to truly move the industry forward.”
Brian Behlendorf, Executive Director of Hyperledger
One language for multiple platforms
As you all know, the enterprise blockchain space is fairly nascent and highly competitive. There are multiple platforms and protocols battling it out to be the “one true blockchain,” each with their own version of maximalists. Hyperledger alone has six distinct frameworks, each tailored to different needs, making necessary trade-offs to solve different problems. The field is rapidly evolving and we are all learning from the contributions of others to better the industry as a whole. One thing all these platforms have in common: Their purpose is to execute multi-party business processes. The differences arise in how a given platform deals with data representation and privacy, transaction authorization, progressing the state of an agreement, and so on.
One of the primary goals of DAML was to decouple smart contracts, the business logic itself, from the ledger by defining an abstraction over implementation details such as data distribution, cryptography, notifications, and the underlying shared store. This provides a clean ledger model accessible via a well specified API. With a mapping between this abstraction layer and the specifics of a given platform, as BTP is developing for Hyperledger Sawtooth, DAML applications can be ported from platform to platform without complex rewrites.
Why do smart contracts need a new language?
DAML’s deep abstraction doesn’t just enable the portability of applications—it greatly improves the productivity of the developer by delivering language-level constructs that deal with boilerplate concerns like signatures, data schemas, and privacy. Blockchain applications are notoriously difficult to get right. Libraries and packages can help improve productivity in some cases, but the application will remain bound to a given platform. Even Solidity, the language of choice for writing to an Ethereum Virtual Machine (EVM), exposes elements of the Ethereum platform directly to the developer. And we’ve seen several examples of how damaging a bug in a smart contract, or even the language itself, can be.
Abstracting away the underlying complexities of blockchains allows you to focus only on the business logic of your project and leave lower-level issues to the platform.
For example, when a contract involves many parties and data types it can be extremely difficult to define fine-grained data permissions in a general-purpose language. DAML allows you to define explicitly in code who is able to see which parts of your model, and who is allowed to perform which updates to it.
As a very simple illustration, consider the model for a cash transfer. DAML’s powerful type system makes it easy to model data schemas—even far more complex schemas than this—directly in the application.
DAML data model
Built-in language elements simplify the specification of which party or parties need to sign a given contract, who can see it, and who is allowed to perform actions on it. These permissions can be specified on a very fine-grained, sub-transaction basis. For example, the issuer of cash does not need to know who owns that currency or what they do with it.
DAML provides a very clean syntax for describing the actions available on a contract, together with their parameters, assertions, and precise consequences.
DAML business logic
What you won’t find in DAML are low-level, platform-specific concerns like hashing, cryptography, and consensus protocols. You define the rules in DAML, and the runtime enforces the rules that you set out.
If you refer to the examples in the DAML SDK documentation, or the open source code for the set of complete sample applications we’ve provided, you’ll really come to appreciate the full richness of DAML and the simplifying effect it can have on complicated workflows.
Why Hyperledger Sawtooth?
Digital Asset has a long history with Hyperledger, being founding premier members and serving as both the Chairs of the Governing Board and Marketing Committees. In fact, we donated code to the initial implementation of Hyperledger Fabric and the trademark “Hyperledger” itself! I personally worked with Jim Zemlin and team at the Linux Foundation to establish the project and co-founded the company Hyperledger with my colleague Daniel Feichtinger back in early 2014.
We have clearly always believed in the need for an organization such as Hyperledger to exist, to create an open source foundation of common components that can serve as the underlying plumbing for the future of global commerce.
Hyperledger Sawtooth has quickly been emerging as an enterprise-grade platform that exemplifies the umbrella strategy that Brian laid out in his first blog post after joining as executive director. It has an extremely modular architecture that lends itself well to the plug-and-play composability that Hyperledger set out to achieve.
An example of this is that Hyperledger Sawtooth originally only offered support for the Proof of Elapsed Time, or PoET, consensus algorithm; consensus is now a pluggable feature. This modularity is accompanied by a very clean separation of business logic from platform logic, offering developers a degree of ‘future-proofing’ by limiting the amount of code that needs to be changed should a core component such as consensus be replaced.
Modularity also makes Hyperledger Sawtooth very amenable to plugging in new language runtimes. We’ve already seen this in action with Hyperledger Burrow, which integrates an Ethereum Virtual Machine into Hyperledger Sawtooth to support contracts written in Solidity. Incorporating the DAML runtime into Hyperledger Sawtooth similarly enables support for contracts written in DAML as an enterprise-grade alternative to Solidity.
Finally, from a ledger model point of view, many of the Hyperledger Sawtooth characteristics already map well to what DAML expects. Hyperledger Sawtooth’s Transaction Processor has a very flexible approach towards roles and permissions, for example, and is based on a very natural DLT network topology of fully distributed peers. DAML is based on a permissioned architecture and Hyperledger Sawtooth can be configured to be permissioned without requiring special nodes.
What comes next?
Digital Asset and BTP will soon be submitting the DAML Integration to the upstream Hyperledger Sawtooth framework, fully open sourcing our work.
The integration will also be commercially supported by BTP’s blockchain management platform, Sextant, which provides application developers with a cloud-ready instance of Hyperledger Sawtooth. Sextant is already available on the AWS Marketplace for Containers, and DAML support for Sextant will be added in July. BTP expects to support Sextant on other cloud provider support soon thereafter.
BTP is one of Digital Asset’s first partners to use the DAML Integration Toolkit, a new tool designed to enable developers and partners to easily integrate our open source DAML runtime with their own products, immediately offering the benefits of the best in class smart contract language to their end customers. We look forward to any collaboration that brings DAML to even more platforms, including the other frameworks in the Hyperledger family!
To learn more, download the DAML SDK today and start building your applications for Hyperledger Sawtooth!
Today the French National Council of Clerks of Commercial Courts (NCC or Conseil national des greffiers des tribunaux de commerce) announced that IBM has developed a blockchain corporate registry solution. France doesn’t have a central corporate registrar. Instead any changes to commercial and corporate records have to be submitted via the local commercial courts. The blockchain is expected to launch in the first half of 2019.
The initiative involves sharing information about two sets of data. The first is general registry data such as a change of company name, moving from one court jurisdiction to another, adding new branches and corporate dissolutions. And the second set of data relates to corporate recoveries and insolvencies.
CU Ledger, a consortium of U.S. credit unions that’s been experimenting with a range of private blockchains, has added one more to the list: IBM’s Hyperledger Fabric solution.
The consortium will use IBM’s tech to create “an immutable audit trail that can be used to create new business models and transform existing business processes for credit unions,” Big Blue said Monday.
In particular, the new solutions will be built for such services as identity authentication, compliance with know-your-customer (KYC) regulations, lending and payments, the tech giant said. The first blockchain-based services will be available to CULedger members “later in 2019,” IBM said.