Category

Blog

Announcing Hyperledger Aries, infrastructure supporting interoperable identity solutions!

By | Blog, Hyperledger Aries

Identity is commonly cited as one of the most promising use-cases for distributed ledger technology. Initiatives and solutions focused on creating, transmitting and storing verifiable digital credentials will benefit from a shared, reusable, interoperable tool kit. Hyperledger Aries, the newest Hyperledger project (the13th!), is a shared infrastructure of tools that enables the exchange of blockchain-based data, supports peer-to-peer messaging in various scenarios, and facilitates interoperable interaction between different blockchains and other distributed ledger technologies (DLTs).

Hyperledger Aries intends to:

  • Provide code for peer-to-peer interaction, secrets management, verifiable information exchange, and secure messaging for different decentralized systems.
  • Foster practical interoperability in support of ongoing standards work and extend the applicability of technologies developed within Indy beyond its current community components from the Hyperledger stack into a single, effective business solution.

What is Aries?
Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions. It’s not a blockchain and it’s not an application.

It includes:

  • A blockchain interface layer (known as a resolver) for creating and signing blockchain transactions.
  • A cryptographic wallet for secure storage (the secure storage tech, not a UI) of cryptographic secrets and other information used to build blockchain clients.
  • An encrypted messaging system for off-ledger interactions between clients using multiple transport protocols.
  • An implementation of ZKP-capable W3C verifiable credentials using the ZKP primitives found in Ursa.
  • An implementation of the Decentralized Key Management System (DKMS) specification currently being incubated in Hyperledger Indy.
  • A mechanism to build higher-level protocols and API-like use cases based on the secure messaging functionality described earlier.

The generic interface of Aries will initially support the Hyperledger Indy resolver but is flexible enough so that someone could build a pluggable method using other DID method resolvers such as Hyperledger Fabric, Ethereum, or another DID method resolver they wish. These types of resolvers would support the resolving of transactions and other data on other ledgers.

Additionally, Hyperledger Aries will provide features and functionality outside of the scope of the Indy ledger to be planned and fully supported. We have reached out to other groups, including Ethereum-based decentralized identity efforts and others participating at the W3C to contribute to this code base.

With all of these capabilities, the open source community will now be able to build core message families that are necessary to facilitate interoperable interactions a wide variety of use cases involving blockchain-based identity.

Where did Aries come from?
Hyperledger Aries is related to both Hyperledger Indy, which provides a resolver implementation, and Hyperledger Ursa, which it uses for cryptographic functionality. Aries will consume the cryptographic support provided by Ursa to provide both secure secret management and hardware security modules support.

One of the main purposes of this project is to change the client layers in Hyperledger Indy to be interoperable with other identity projects. Hyperledger Indy has been incubating protocol work for peer interactions between identity owners for some time but as the development community has grown, it has become clear that the scope of that work extends beyond the functionality provided by Indy for support of other systems and networks.

With the main wallet and cryptographic code moving to its own project, it makes sense to move the pieces necessary to support that process with them in order to support a standards-driven approach and avoid cross dependencies between Indy and Aries.

What’s next for Aries?
The ultimate goal of Hyperledger Aries is to provide a dynamic set of capabilities to store and exchange data related to blockchain-based identity. These capabilities will range from the secured, secret storage of data such as private keys, up to the capability of globally accessible data that can be viewed and accessed by anyone. An example of such support is the creation of a secure storage solution similar to the wallet available in Hyperledger Indy today.

Other Aries functionality that would be in scope for a 1.0 project release would be a Decentralized Key Management Solution (DKMS) which would add key recovery, social recovery, and wallet backup and restore functionality. Using DKMS, clients will need a way to interact with one another peer to peer that is currently in development within Hyperledger Indy. Much of this work would be based on the DKMS documents outlined in the Indy-HIPE dkms design folder. This would be capable of storing verifiable credential data, private keys, relationship state data, and functionality that could perform operations with this data without having to extract this data.

We also hope to eventually have a scalable, searchable storage layer which is capable of storing other associated data necessary for identity maintenance. Examples of such data would be pictures, health records, or other personal information.

Who’s Involved?
The Sovrin Foundation has been the primary contributor to this initial initiative along with the team from the Government of British Columbia, but endorsements and possible contributions are in flight from several other organizations. Hyperledger has proven to be a collaborative and open environment for growing the community and has helped attract a variety of contributors. We are excited by the enthusiastic response from like-minded members of the community and look forward to collaborating further.

Want to Learn More?
If you’re interested in learning more about Aries, Indy, or Ursa, consider visiting https://wiki.hyperledger.org/display/HYP/Hyperledger+Aries+Proposal or #Aries on Hyperledger chat at https://chat.hyperledger.org/channel/aries

We welcome interest from all groups and organizations, including enterprises and standards organizations.  We are looking forward to hearing from you!

When Hyperledger Sawtooth Met Kubernetes – Simplifying Enterprise Blockchain Adoption

By | Blog, Hyperledger Sawtooth

Blockchain Technology Partners has teamed up with Digital Asset to deliver DAML Smart Contracts for Hyperledger Sawtooth deployed and managed on Kubernetes using its blockchain management platform Sextant.

One of the great things about being a member of the Linux Foundation is that you are part of a vibrant global community that is home to open source projects in a wide range of ecosystems and host to an impressive array of events worldwide.

  • A global community where you are actively encouraged to participate in meetups and events specific to your ecosystem as well as contribute to broader open source summits
  • A global community where there is the opportunity to collaborate not just within your own ecosystem but with ecosystems that complement yours – this is at the heart of the open source ethos

A case in point is Blockchain Technology Partners (BTP) which, like a number of our Hyperledger members, is also an active participant in the CNCF, aka Cloud Native Computing Foundation. Its founding team recognized early on that the only way to make blockchain technology more accessible and easier to adopt was to address the operational challenges that they could see lying in wait for enterprises. With their team’s  background in open source, operations and cloud, BTP quickly realised that CNCF’s Kubernetes was the perfect match for Hyperledger Sawtooth. This led to the creation of Sextant, their blockchain management platform that radically simplifies the development, deployment and ongoing management of blockchain-based enterprise applications.

The power of open source collaboration doesn’t end there as BTP have now teamed up with Digital Asset to bring DAML Smart Contracts to Hyperledger Sawtooth – integrating their open source DAML runtime with Sawtooth, similar to the way the Sawtooth Ethereum (SETH) project integrates the Burrow EVM with Sawtooth, and handling its deployment and management with Sextant.

For the full story behind the creation of Sextant to deploy and manage Hyperledger Sawtooth on Kubernetes and BTP’s collaboration with Digital Asset to bring DAML to Sawtooth, read our case study.

Welcome Hyperledger Iroha 1.0: Flattening the DLT learning curve

By | Blog, Hyperledger Iroha

My first experience running a blockchain was when I first launched a Bitcoin node about six years ago. I got into Bitcoin out of curiosity and because the idea of sending value as digital data across the Internet was a very compelling idea.

Since those early days of experimentation, blockchain and DLT have emerged and found its place in enterprise — companies, individuals, consortiums want to get rid of non-transparent resource allocation, corruption, and fraud. Today, diamonds are registered on a blockchain, insurance companies know if you registered your MacBook at several places, and cross-border payments can operate more efficiently.

While blockchain technology has passed its longevity test, the software in general is still far from being integrator-friendly, developer-oriented, and straightforward; specifically when it comes to using distributed ledger technology instead of a database. This is where Hyperledger Iroha is different. With Hyperledger Iroha, it took me about 10 minutes to start building a blockchain. And now the Hyperledger Iroha team is releasing its first production-ready version, offering a faster, less complex path to DLT deployment. Welcome Hyperledger Iroha v1.0!

When it comes to solutions for business, it is critical that the technology is fit for the task and easy to integrate. Moreover, it must be reliable and safe so a business can trust it. Hyperledger Iroha provides safety with its decentralized consensus algorithm and reliability with a tested set of commands and queries. With them you can be sure that the code will do exactly what it is supposed to do — whether you want to add information to, or get information from, the ledger.

For this release the team prepared a special set of improvements:

  • New native client libraries deliver cross-application support for desktop/server (on Java, Python, C++) or mobile (iOS, Android (Java)) applications. You only need to get an idea of the client application and you are ready to go! Take a look at desktop and mobile application examples: on Java or JS: https://github.com/soramitsu/iroha-wallet-js
  • Novel, asynchronous consensus algorithm supporting one step agreement on votes with vote collection optimizations included (Yet Another Consensus; YAC). This means that even if a node is faulty, your decentralised ledger will still be up and running correctly. You can now focus on implementing your business application, leaving the question of whether you can trust partners’ nodes to Hyperledger Iroha.
  • Multi-signature transactions, or as we call them, MST, are now ready for production use. What does it mean for your business? It means that you can set a quorum, such that transactions from your company’s wallet will need several signatories instead of just one — just like in traditional banking, but quicker and more secure. This can also be used to model complex business processes in a secure and automatic way.
  • New backwards-compatibility allows you to integrate Hyperledger Iroha into your business and be sure that no breaking changes will affect it.

Hyperledger Iroha is already gaining strong traction with the community and enterprises:

Alexander Yakovlev from Moscow Exchange Group’s National Settlement Depository is using Hyperledger Iroha in D3 Ledger, and he said: “Global business is always terrific, and we looked for a solution that fits our requirements and is 100% open-sourced and oriented for the specific needs of our task. Features such as Iroha’s account management and supportive community, in addition to Soramitsu’s KYC application, were key factors in our decision to use Iroha for D3 Ledger. Iroha’s existing adoption in several countries and the practical use case with the Cambodian central bank were additional benefits.”

Hyperledger Iroha is already used in asset management, identity management, and payment systems. From simple asset transfers to secure information exchange about customers, Hyperledger Iroha can be used to empower a multitude of use cases, all without the need to program custom smart contracts.

Last year, I wrote a paper about Sora Identity, an implementation of a self-sovereign identity protocol using Hyperledger Iroha. Since then, we have worked on expanding this app and now we have a working product for KYC, targeted towards financial institutions. We are now expanding this to be at the core of the Sora decentralized autonomous economy, an exciting new type of economic system, geared towards empowering the creation of new goods and services.

Try it – simplicity and friendly support from the community will surely help you find your own way of improving your project with Hyperledger Iroha blockchain. You can find the Hyperledger Iroha 1.0 documentation here: https://iroha.readthedocs.io/en/latest/. Follow the “Getting Started” guide to create your first Iroha network in 10 minutes.

An overview of Self-Sovereign Identity: the use case at the core of Hyperledger Indy

By | Blog, Hyperledger Indy

In the real world, most identity interactions are self-sovereign. We collect and hold various credentials that we keep in our possession and present at our discretion to prove things about ourselves. These could be collections of cards, certificates, or paperwork that prove various things about someone or something. Some credentials are obvious, like birth certificates, licenses to drive, employee ID cards, passports, university diplomas…the list goes on. We hold and present these to any anyone we want, without the permission of the organization who issued them. These credentials are kept and controlled by the holder, and only taken from her wallets and revealed with her expressed consent.

This is not what happens on the internet. Like the famous cartoon says – “On the Internet, nobody knows you’re a dog,” illustrating the very real issue with the lack of an easy, secure, standardized system for a person to collect, hold, and ultimately present trustworthy, verifiable credentials online.

Unfortunately, online identity is very clearly broken. This is due to the fact that the internet was created without any way to identify the people who used it. Initially, it was a fairly small network of machines. Internet protocols are designed to identify machines and services, not people. People used the Internet through some institution (usually their company or university) and were part of that institution’s administrative identity system. This can still be seen in the format of email addresses that identify both recipient and sender as someone@someplace.

As the internet grew to include people who weren’t formally associated with an institution, every website and service created its own administrative identity domain. The result is the fractured profusion of identifiers, policies, and user experiences that constitute digital identity in 2019. Where early internet users had a handful of credentials and logged in occasionally, modern internet users typically have dozens, even hundreds, of usernames and passwords. Security has made these harder to use by encouraging or even forcing users to use more cryptic passwords and not share them between sites. And now multi-factor authentication adds to the cognitive burden. And then there’s the inconvenience of supplying the same information to application after application, all the while suffering the dangers that they might lose it or expose it to hackers.

One attempt to solve this problem is single-source or ‘federated logins.’ Social login systems from Google, Facebook, and others expedite logging into various websites, but these systems are limited in the kinds of attributes they use and the trustworthiness of those attributes. As a result, they aren’t as widely used as one might hope. Many companies don’t or can’t use social login and so the system of fractured administrative identity systems remains.

Traditional, identity systems have a single identity provider (IdP) administering an identity system for their own purposes. The rights of the so-called “identity subject” are subordinate to those of the identity provider. These systems are siloed, meaning the attributes you’ve shared with one organization are difficult to use with another. Each company asks for the same information, like your name, credit card, address, and so on. Users are required to provide that information to use the service – whether they like it or not. This single entity determines what information will be collected, decides who can participate, and how their data is stored – and that data is only as secure as the company or organization that keeps it.

Consequently, until now, the internet has lacked a universally available digital identity system that lets individuals collect and hold trustworthy verifiable credentials and present them to whoever they want, whenever they want – without the reliance on a third-party managing access.

What is SSI

Self-sovereign identity (SSI) gives individuals or organizations agency to control their identity information. SSI acknowledges that identity is about much more than logging in. Identity can be expanded to other uses by using verifiable attestations, called credentials, to prove things about yourself. SSI uses verifiable, trustworthy credentials. Identity owners autonomously use those credentials wherever they want. Privacy is a critical feature of SSI because, without privacy, there is no control. In SSI, the identity owner must be in control of who sees what. This represents a monumental shift in how identity functions on the internet.

Credential issuers, holders, and verifiers are peers on an SSI network. Any person or organization can play any or all of the roles, creating a decentralized system for the exchange of trustworthy, digital credentials.

  • Credential issuers determine what credentials to issue, what the credential means, and how they’ll validate the information they put in the credential.
  • Credential holders determine what credentials they need and which they’ll employ in workflows to prove things about themselves.
  • Credential verifiers determine what credentials to accept, and which issuers to trust.


In SSI, players independently determine the role they’ll play, who they trust, and what they will believe. While credentials can be revoked individually, the identity owner still controls her own identity wallet and all the other credentials she has collected. The result is an internet identity system that is more flexible, more secure, more private, less burdensome, and less costly.

About the author: Dr. Windley, an expert in decentralized digital identity and IoT and event-driven systems, is Chair of the Board of Trustees, Sovrin Foundation. The Sovrin Foundation open sourced the codebase used to create the Sovrin Network and contributed the initial code for Hyperledger Indy to Hyperledger, a project dedicated to blockchain hosted by the Linux Foundation.

Research Paper: Validating Confidential Blockchain Transactions with Zero-Knowledge Proof

By | Blog, Hyperledger Indy

By: Carlo Gutierrez and Alex Khizhniak, Altoros

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.

Developer showcase series: Juan Navarro, Biztribution

By | Blog, Hyperledger Fabric

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!

Hyperledger Sawtooth: Improving the Devops CI Workflow with Kubernetes

By | Blog, Hyperledger Sawtooth

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.

Building Sawtooth

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.

$ docker build -f Dockerfile -t registry.url/repo/image_name:${tag} .
$ docker push registry.url/repo/image_name:${tag}

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.

containers:
  - name: sawtooth-intkey-workload
    image: registry.url/repo/sawtooth-intkey-workload:latest
    resources:
      limits:
        memory: "1Gi"
    command:
      - bash
    args:
      - -c
      - |
         intkey-workload \
           --rate 10 \
           --urls ...

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.

Try It Out!

The Sawtooth documentation can help you get started: See Using Kubernetes for Your Development Environment and Kubernetes: Start a Multiple-node Sawtooth Network.

To configure Grafana, see Using Grafana to Display Sawtooth Metrics.

See these links for more information about each tool in our CI workflow:

About the Authors

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.

 

 

Forbes Blockchain 50: Half of the biggest companies deploying blockchain use Hyperledger

By | Blog

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.

DAML smart contracts coming to Hyperledger Sawtooth

By | Blog, Hyperledger Sawtooth

It has been a busy two weeks at Digital Asset… first, we announced that we have open-sourced DAML under the Apache 2.0 license and that the DAML SDK is available to all. Five days later, ISDA (the standards body for the derivatives market) announced DAML as an available smart contract language for their Common Domain Model, and we open-sourced a reference library and application. Next up, we announced that we’ve been working with the team at VMware to integrate DAML with their enterprise blockchain platform, VMware Blockchain.

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.

And so each platform has its own patterns for writing distributed ledger applications, typically in a general-purpose language such as Java, JavaScript, Kotlin, Go, Python, and C++. The result of this is that developers must pick which framework they want to use and then develop their application specifically for that platform. Their application is now tightly coupled to the underlying architecture of that ledger and if a better alternative arises for their needs, that likely results in a wholesale rewrite.

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 permissions

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!

Hyperledger Indy Graduates To Active Status; Joins Fabric And Sawtooth As “Production Ready” Hyperledger Projects

By | Blog, Hyperledger Fabric, Hyperledger Indy, Hyperledger Sawtooth

By Steven Gubler, Hyperledger Indy contributor and Sovrin infrastructure and pipeline engineer

The Hyperledger Technical Steering Committee (TSC) just approved Indy to be the third of Hyperledger’s twelve projects to graduate from incubation to active status.

This is a major milestone as it shows that Hyperledger’s technical leadership recognizes the maturity of the Indy project. The TSC applies rigorous standards to active projects including code quality, security best practices, open source governance, and a diverse pool of contributors. Becoming an active Hyperledger project is a sign that Indy is ready for prime time and is a big step forward for the project and the digital identity community.

Hyperledger Indy is a distributed ledger purpose-built for decentralized identity. This ledger leverages blockchain technology to enable privacy-preserving digital identity. It provides a decentralized platform for issuing, storing, and verifying credentials that are transferable, private, and secure.

Hyperledger Indy grew out of the need for an identity solution that could face the issues that plague our digital lives like identity theft, lack of privacy, and the centralization of user data. Pioneers in self-sovereign identity realized we could fix many of these issues by creating verifiable credentials that are anchored to a blockchain with strong cryptography and privacy preserving protocols. To this end, the private company Evernym and the non profit Sovrin Foundation teamed up with Hyperledger to contribute the source code that became Hyperledger Indy. The project has advanced significantly due to the efforts of these two organizations and many teams and individuals from around the world.

A diverse ecosystem of people and organizations are already building real-world solutions using Indy. The Sovrin Foundation has organized the largest production network powered by Indy. The Province of British Columbia was the first to deploy a production use case to the Sovrin Network with its pioneering work on Verifiable Organizations Network, a promising platform for managing trust at an institutional level. Evernym, IBM, and others are bringing to market robust commercial solutions for managing credentials. Many other institutions, researchers, and enthusiasts are also actively engaged in improving the protocols, building tools, contributing applications, and bringing solutions to production.

The team behind the project is excited about current efforts that will lead to increased scalability, better performance, easier development tools, and greater security. User agents for managing Indy credentials are under active development, making it easy to adopt Indy as an identity solution for diverse use cases.

If you’d like to support Indy, join our community and contribute! Your contributions will help to fix digital identity for everyone. You can participate in the discussions or help write the code powering Indy. Together, we will build a better platform for digital identity.A