Business Process Modeling: The Missing Link Between Legal Know-how and Blockchain-based Legal Products

By | Blog, Hyperledger Burrow

Guest post: Jan Hendrik Scheufen Chief Product Officer & Nina Gunther Kilbride, Chief Commercial Officer, Monax

For the past two decades, tools for Business Process Management (BPM) have found their way into many domains to model and reliably execute business logic. However, benefits are still largely confined to single organizations while end-to-end value chains that stretch across organizations are a patchwork of individual participants storing and processing data in their own silos. Inter-organizational processes today require expensive intermediaries (lawyers, financial services, etc.) to deliver intended results and manage obligations in contractual, legal agreements and deliver intended results. Opportunities for efficiency gains and lower transaction costs remain largely untapped.

Blockchain technology, by creating a reliable source of provable data, is a tool to tackle these inefficiencies. Blockchain enables the expansion of BPM and automated decision-making to operations between companies. Monax and others have propounded the concept of blockchains integrating BPM methodologies and standards as a means for capturing and operating  cross-organizational business processes while providing data certainty between parties. The combination of blockchain technology, smart contracts, and BPM provide us with the ability to create new, more effective commercial vehicles for getting jobs done in networked commerce: legal products.

Legal products will deliver end-to-end legal solutions in order to support efficient, reliable processes across value chains, systems and borders, transforming commerce and scaling global networks. Legal products incorporate the coordination of legally significant actions (signing a contract, paying a bill, recording a document, transferring possession) into software, thus providing better visibility on contract status as well as the ability to automate execution of some of those actions. Before the rise of distributed ledger technology, legal products were not broadly feasible for commercial application, resulting in a lack of access to simple legal functions for most businesses and individuals.

Currently, legal know-how is mostly encoded in the heads of lawyers who lack the means to transform their knowledge into instructions that can run on a distributed computer system. Industry-proven standards such as BPMN (Business Process Model & Notation) provide a usable toolset that can be learned easily by a broad portion of the legal community.

The BPMN standard defines generic symbols to describe the interaction of participants and data in a flow diagram that can be persisted into an XML representation (fig. 1). The XML schema is extensible with custom vocabulary to support features for specific execution engines available in the market. Therefore, it can also be enhanced with instructions for an execution engine that consists of a number of smart contracts and runs on a blockchain.

Fig.1. Example created using an open-source BPMN 2.0 modeler

From a modeling perspective, any legal contract can be expressed as two sequential processes, one governing the Formation, the other the Execution phase of the agreement. Contract formation includes the negotiation of terms until the point when the agreement is signed by all parties. Execution of an agreement is the performance of its contractual promises.

Figure 1 shows on the left a BPMN diagram for a very simple Formation process with swimlanes representing the parties (Buyer and Seller) and “tasks” for signing. The right side shows the resulting XML file containing standard BPMN elements as well as extension properties linking the swimlanes to the appropriate agreement fields. The above example left out a few more blockchain-relevant BPMN elements, (e.g., service tasks {to call other smart contracts}, receive tasks {to block the process for outside input from sources like Oracle}, gateways for routing decisions, etc.) for simplicity reasons. However, even such a simple example contains enough information to be executed by a smart contract-based process engine, particularly:

  • The order of activities as defined in the flow diagram
  • The signatures required to complete a task, assuming that the specified fields on the agreement contain the public addresses of the parties

Hyperledger member Monax has produced such a process engine written in Solidity that can be fed with instructions from external files, such as BPMN. This process engine runs on Hyperledger Burrow, one of the Hyperledger projects hosted by the Linux Foundation. Burrow provides a modular blockchain client with a permissioned smart contract interpreter partially developed to the specification of the Ethereum Virtual Machine (EVM).

Leveraging a standardized approach like BPMN captures the data requirements and procedural intent of legal agreements. Packaging it into deployable units for a shared blockchain infrastructure holds the promise of expanding access to legal tools for everyone.

Legal products built this way can transform the delivery of legal services and promote productization of law. As the networked economy grows, the proliferation of devices and digital commerce means a need for legal functions to be embedded within the software driving transactions. The open-source nature of blockchains and standards like BPMN naturally support the development of a framework for building broad access to legal tools, products and services to achieve business goals.

Most lawyers will not have the training to construct a process model containing all the necessary technical information all by themselves. In fact, the BPM discipline is inherently a collaborative effort between domain experts and IT professionals. Input from both sides is required to capture and implement a business process that connects human resources as well as computer systems. This makes one thing clear: building blockchain-based legal products with and for lawyers presents a giant opportunity for developers to enter a domain of a market that has been thus far not very accessible. Software-based legal products are distinct from and complementary to legal advice and will enable lawyers to serve more clients, more efficiently, all while generating new revenue streams and broader access to justice.

Developer Showcase Series: Markus Sabadello, Danube Tech

By | 网志, Hyperledger Indy

We have another Developer Showcase blog ready! This series serves to highlight the work and motivations of developers, users and researchers collaborating on Hyperledger’s projects. Next up is Markus Sabadello from Danube Tech. Let’s see what he has to say!

What advice would you offer other technologists or developers interested in getting started working on blockchain?

You probably already have a good technical understanding of how blockchain works. You already know that blockchain is more than Bitcoin. You know that there are many different types of blockchains with different features and properties. You also know that blockchain is not a panacea, that it is sometimes over-used, and that blockchain is often just a small piece of a bigger solution.

Since you know all that already, my advice would be, let’s now try to understand why there is such high interest in blockchain, and why so many individuals and companies are working with this technology. Is it because blockchain is a novel solution for technical challenges such as security and stability? Or is the rise of blockchain mostly about profit and new business models? Or is it about a desire for a utopian new world with more democracy, transparency and without authorities?

Today, it is becoming clearer that technology is not always neutral. It tends to have built-in assumptions and objectives. The design of technical architectures and algorithms can imply and support certain world views and values. Some of the currently existing digital infrastructure is perhaps based on paradigms and assumptions that has resulted in adverse effects for our political and social structures.

As engineers and developers, we have a special responsibility here. Therefore, when you start working with blockchain, try to not only find the best technical solution for your use case, but also consider what deeper human effects your algorithms and data structures will have once they get deployed and used in the real world.

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?

I have worked on digital identity technologies for a long time, the question of who we are, how we present ourselves, and what do others know about us in the digital world. There’s this concept of user-centric identity, and more recently self-sovereign identity, which places individuals at the center of their online relationships and transactions, and gives us all the ability to create, manage, use, and destroy our online identities according to our own rules.

In classic identity technologies such as OpenID, SAML, WebID, etc., the act which establishes a digital identity for an individual always introduces a dependency on an external entity that has to be trusted in some way. In these systems, digital identity is always represented as an account in some service provider’s database, or as an identifier managed by some registration authority.

With blockchain or distributed ledger technology, we realize that now for the first time we have a way to establish digital identity without such dependencies on identity service providers.

In a joint effort of several communities such as the W3C Credentials Community Group, the OASIS XDI Technical Committee, the series of Rebooting-the-Web-of-Trust workshops, and the Internet Identity Workshop, we then began developing the concept of a Decentralized Identifier (DID), which will become a base building block for higher-level identity data formats and protocols. This is currently my focus at Danube Tech.

What project in Hyperledger are you working on? Any new developments to share? Can you sum up your experience with Hyperledger?

The only Hyperledger project I work on is Hyperledger Indy, and I am not among the most active direct contributors, but everything I work on is connected to it. It is a codebase for a distributed ledger, which unlike most others is specifically being built for digital identity that is decentralized, independent, and follows privacy-by-design principles. Indy offers functionality and components for registering DIDs on a ledger, for privacy-preserving cryptography, and for so-called agents, which are off-chain components that exchange verifiable identity data on an identity owner’s behalf.

I can share that there are currently dozens of proof-of-concepts happening around the world using the Indy software, involving well-known major corporations, but also non-profits, academic institutions, and governments. Here in Austria, we have a consortium of several large companies jointly experimenting with Indy, and I think we will soon see plans for concrete products, applications, and services, that will transform the way how identity works online.

I was already part of this project and its community before it was accepted into Hyperledger incubation, but I can definitely say that Hyperledger has really accelerated Indy both in terms of the provided infrastructure, but also credibility and community support.

What is the best piece of developer advice you’ve ever received?

One good advice for developers I have received a few times is “sleep is more important” – but then again, it’s not always true, is it? 🙂

What technology could you not live without?

My pen that I use for writing down thoughts and taking notes during conferences.

Keynote Sneak Peek for Hyperledger Global Forum – See Who’s Speaking

By | 网志, Events

Check Out the Initial Lineup of Blockchain Leaders Speaking at Hyperledger Global Forum.

Attend Hyperledger Global Forum to see real uses of distributed ledger technologies for business and to learn how these innovative technologies run live in production networks across the globe today. Hyperledger Global Forum will cut through the hype and focus on adoption. Attendees will see first-hand how the largest organizations in the world go beyond experimentation to lead blockchain production applications with measurable impact. Make your plans now to attend the premier blockchain event of 2018.

Keynote Speakers Include:

  • Alexis Gauba, Co-Founder, Mechanism Labs and She(256); R&D, Blockchain at Berkeley; R&D, ThunderCore
  • Leanne Kemp, Founder & CEO, Everledger
  • Bruce Schneier, Fellow and Lecturer at the Harvard Kennedy School

Stay tuned. We will announce additional keynote speakers as well as the full agenda later this month!

What makes attending Hyperledger Global Forum so valuable?

  • Live Demos & Roadmaps: Get an inside look at live demos and roadmaps showing how the biggest names in financial services, healthcare, supply chain and more are integrating Hyperledger technologies for commercial, production deployments.
  • Collaboration & Leading Experts: Collaborate face-to-face, network, and learn directly from leading experts and project maintainers on how to better your skills with blockchain, DLTs and smart contracts.
  • Gain Knowledge: Learn how to leverage and adopt DLT and smart contracts technologies when the market demands, contribute code and documentation, increase your blockchain development skills, and keep up-to-date with these leading technologies. Get an understanding of the Hyperledger greenhouse of multiple blockchain projects, how they differ from alternative ledger platforms, and how products and services built with Hyperledger technologies can scale in highly regulated, enterprise-level environments.
  • Hands-on Workshops: Learn how to install, contribute to, and build products and services on top of Hyperledger open source business blockchain frameworks.

Register now to save before ticket prices increase on September 30.



Sign up to receive updates on Hyperledger Global Forum:


Developer Showcase Series: Jean-Louis (JL) Marechaux, JDA Labs

By | 网志, Hyperledger Composer, Hyperledger Fabric, Hyperledger Indy

Image: Jean-Louis (JL) Marechaux, JDA Labs

We return back to our Developer Showcase blog series, which serves to highlight the work and motivations of developers, users and researchers collaborating on Hyperledger’s projects. Next up is JL Marechaux from JDA Labs. Let’s see what he has to say!

What advice would you offer other technologists or developers interested in getting started working on blockchain? 

The first advice I would offer is what I give on every single new technology adoption: Clearly identify the business need, and make sure that blockchain is appropriate to meet business needs. Blockchain is not a silver bullet. There are a couple of use-cases where blockchain is absolutely not the right answer. Be sure you assess blockchain applicability in your context.

I would also recommend to take an incremental and iterative approach for new Blockchain initiatives. Decompose your business problem to identity a simple use-case, something that can be described as an agile story. Implement this first story in a small prototype, to get familiar with core blockchain concepts. Then incrementally add new capabilities to your blockchain solution.

There are plenty of resources to help when you start a blockchain project. I personally recommend the Hyperledger online documentation, as it cover the key concepts and provide practical tutorials. Moreover, a tool like Hyperledger Composer is an easy way to define and test a business network with minimal investment. To me, Composer is a pretty good platform for an early blockchain prototype.

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?

I work at JDA Labs, which is the R&D entity of JDA Software. The company has a focus on the supply chain and the retail industry, and we provide software solution to support the digital transformation of our customers. Because we are interested in digital transactions between multiple parties, blockchain seems to be a natural fit to address some automation and traceability problems. When products transit all over the world, through multiple countries and multiple companies, I believe that blockchain can help provide a better end-to-end visibility of the supply chain.

I started to be interested in blockchain when I was working at IBM. Around 2015 or 2016, I was part of an internal initiative to identify blockchain use cases for different industries. I had the opportunity to discuss with people far more knowledgeable than me in this area, and to learn basic concepts. When I started at JDA, I was exposed to a new business domain, and it quickly became obvious that blockchain could improve supply chain transparency and traceability. So I decided do more research and experimentation in this area.

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?

I see a lot of value in all the Hyperledger projects, so it is difficult to mention just a few.

But given my current job and my focus at this time, I would select Hyperledger Fabric and Indy.

Because it supports permissioned networks, Hyperledger Fabric seems appropriate in a supply chain environment where participants are usually known and vetted. The channel capability in Fabric provides a data partitioning mechanism to restrict visibility to some participants, which is required for some some business transactions. Hyperledger Fabric is based on a modular and scalable architecture to support most business needs.

I have not explored Hyperledger Indy capabilities yet, but given the nature of a blockchain business network, it seems important to have a strong mechanism to manage decentralized identities.

In addition to the blockchain frameworks, I am quite interested in the different tools (e.g. Composer , Explorer) that are developed under the Hyperledger umbrella to facilitate and accelerate blockchain adoption.

What’s the one issue or problem you hope blockchain can solve?

As a consumer, I always wonder where the products I buy are coming from. I can sometime get that information reading the product label, but can I really believe what is written? Why should I trust the organic certification body? Organic food fraud is massive. Traceability on fair trade products is weak. Provenance of consumer goods is nearly impossible to obtain.

Blockchain technologies can solve this problem by enabling full transparency and traceability on products. As a consumer, I would love to be able to scan a product in a store with my smartphone and get the proof of origin through a blockchain.

What is the best piece of developer advice you’ve ever received?

“If you want to eat an elephant, do it one bite at a time.” This comes from an old saying, but I remember receiving that advice for software development, long before Agile practices were popular. To be able to deliver complex software solution, it is important to have the big picture first, to understand the end goal. But then the best approach to deliver the solution is to adopt a step by step approach to incrementally develop the software.

And of course, I was told many times to read the manual. The “RTFM” acronym cannot be repeated often enough.

I think those two tips are relevant for any blockchain project.

Developer Showcase Series: Enrico Zanardo, OneZero Binary Ltd

By | 网志, Hyperledger Fabric

Image: Enrico Zanardo, OneZero Binary Ltd.

This Developer Showcase blog series serves to highlight the work and motivations of developers, users and researchers collaborating on Hyperledger’s projects. Next up is Enrico Zanardo from OneZero Binary. Let’s see what he has to say!

What advice would you offer other technologists or developers interested in getting started working on blockchain? 

I recommend that not only developers but also anybody passionate about the technology study thoroughly, and also to adopt a typical distributed ledger technology (DLT) “forma mentis”. Blockchain is starting to become a new mainstream technology just like the Internet in the 2000s and social networks in the successive decade.

What project in Hyperledger are you working on? Any new developments to share? Can you sum up your experience with Hyperledger?

Between Malta and Italy, my team and I have been working on PulseRescue, a mobile app with a backend application that connects to all the emergency centres in each country. PulseRescue alerts first responders that are nearest to the emergency. We needed to connect and share information between multiple entities like hospitals, emergency services, first responder organisations such as the Red Cross, White Cross, etc… so Hyperledger Fabric was the best choice. We are also able to customise the app based on each organisation’s specific needs, like the layout, without changing our communication protocol. We really hope that this use case can gain wide enough adoption to help save lives.

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?

I’m a Golang fanatic, and Hyperledger Fabric is the most interesting choice if I have to connect multiple organisations together. I’m also looking at Hyperledger Iroha because I think that it will become a common framework when the development of mobile applications is required. The development of a new, chain-based Byzantine Fault Tolerant consensus algorithm called Sumeragi is also interesting.

Where do you hope to see Hyperledger and/or blockchain in 5 years?

The most obvious answer is “everywhere.” However, if I had to think about the sectors with the most important and immediate need, I would say education, IoT, and everything concerning product traceability in supply and production chains, e.g. large-scale organised distribution.

What is the best piece of developer advice you’ve ever received?

While taking the first certified cohort of the Hyperledger Fabric for Developers course provided by B9lab, I learned how to setup Kafka and Zookeeper on the Hyperledger Fabric network. Thanks to this course, I was able to test this “consensus” mechanism to make multiple order processes crash fault tolerant.

I personally suggest that everybody interested in blockchain technology try at least one course provided by B9lab simply because they are able to teach sophisticated tools like Hyperledger Fabric in a simple way, and they are always ready to help their students during (and after) the course.

From XOs to Crypto Assets

By | 网志, Hyperledger Sawtooth

Guest post: Jonatan Alava

Hyperledger Sawtooth 1.0 has been widely available since January 2018. This is the second Hyperledger product to get to 1.0 and become widely available. The project in its current iteration employs a more familiar DLT implementation when contrasted with Hyperledger Fabric for developers that have worked on some of the other popular blockchain projects. Its simple architecture not only enables a very small learning curve, but makes it real easy to setup a network and implement custom applications. It’s also great that the product comes with a rich SDK and documentation as well as boasts an active community that will help you answer questions on Hyperledger chat or live calls setup to support all developers working with Sawtooth. Let’s dig a bit deeper into the modularity and flexibility of the product while at the same time provide a simple introduction to Sawtooth development.

Separation of concerns redux — Application vs. Core System

Before digging into code, let’s cover what we have found to be the cornerstone behind Sawtooth’s design, a clear separation of concerns. This makes Sawtooth an easy to use framework. Any use case can be implemented without having to touch core network elements. Transaction families can be developed to process any logic needed within the network and multiple families can be deployed on the same network. Here we cover two extremes in a sample spectrum of transaction families to display the flexible range of implementations while at the same time show the practicality of the framework for solutions with real uses.

To read more about its architecture & design details please see the docs here.

Games Hyperledger Plays

As part of robust documentation, Sawtooth comes packed with a set of pre-defined transaction families. The one that caught my attention right away was the XO family.

The XO transaction family enables your DLT network to support games of Tic Tac Toe between two registered users. All those users need are valid credentials and access to the network.

Tic Tac Toe

The “thrill” of playing Tic Tac Toe on a robust DLT powered network alone is worth some level of analysis. The XO transaction family includes a very specific set of functions, which are great for demystifying the capabilities of Hyperledger Sawtooth. All the business logic is implemented within the TransactionHandler and its apply method. Below I’ll go over some highlights of the transaction family implementation using the Javascript SDK.

Let’s start by how simple the file structure is:

Each one of those .js files implements one of the key components of a transaction family; A transaction handler (xo_handler.js), the family’s state (xo_state.js) and the payload (xo_payload.js) to be obfuscated simply to avoid shallow inspection.

Creating a game simply checks for uniqueness by name and then defines a new Game containing, Name, Players, State and Board. The code in JS is as simple as its description:

if (game !== undefined) {
throw new InvalidTransaction(‘Invalid Action: Game already exists.’)
let createdGame = {
board: ‘ — — — — -’,
state: ‘P1-NEXT’,
player1: ‘’,
player2: ‘’

And once that object is created, it just gets saved to State.

return xoState.setGame(, createdGame)

Similar to Create, there is a Delete game action. This simply looks up a game by name and if found deletes it from state. As a side note, if you are wondering what it truly means to fetch a game from State, it is also implemented within the transaction family specification. An XOState includes all games serialized, and in order to fetch a particular game by name, the list gets deserialized and a simple search is applied on the list.

return this._loadGames(name).then((games) => games.get(name))

Finally, the most interesting action is Take. Take is called by game participants taking their turn. It starts by fetching a game by name, then validating a valid position on the board being taken and ensuring the right user is taking this turn. Once the turn is taken, the action checks for a winner.

if (_isWin(game.board, ‘X’)) {
game.state = ‘P1-WIN’
} else if (_isWin(game.board, ‘O’)) {
game.state = ‘P2-WIN’
else if (‘-’) === -1) {
game.state = ‘TIE’

The _isWin function is very simple to read, since it hard codes all permutations a player can win on Tic Tac Toe and iterates through them. In case you are wondering, this is what those winning positions look like:

let wins = [
[1, 2, 3],
[4, 5, 6],
[7, 8, 9],
[1, 4, 7],
[2, 5, 8],
[3, 6, 9],
[1, 5, 9],
[3, 5, 7] ]

Setting up an XO DLT

As described earlier; documentation is also very robust and easy to follow in order to set up your own test or development network. Using the docker compose file provided you can stand up your development network right away. Validators and transaction processors are part of the default configuration and transaction processors will have all sample families pre-loaded. If the right transaction family is not loaded you can run the following:


sawset proposal create — url http://rest-api:8008
— key /root/.sawtooth/keys/my_key.priv
sawtooth.validator.transaction_families=’[{“family”: “xo”, “version”: “1.0”},
{“family”:”sawtooth_settings”, “version”:”1.0"}]’


Once you start up your network and ensure your transaction processors have the XO family included all you have to do is register users and start playing. As explained on the transaction family overview, the game can be played through the CLI without having to write any extra lines of code and simply using the pre-defined operations.

Is this the future?

Running this example does not feel like an accomplishment at all, but it is one of the best ways to clearly explain DLT to a friend that has never heard about Blockchain. (Similar article here) The immediate question after this is; how powerful and transformative can DLT be right now? After all, we just ran through a command line controlled example of Tic Tac Toe. It’s hard to see this as a game changer.

So, let’s go back to the basics of software development. The game changer is the ability to so easily implement Tic Tac Toe as a DLT application without needing to architect the underlying network. The built in separation of concerns allows a single file Tic Tac Toe implementation to run on such a powerful infrastructure and to leverage all the core features of DLT. This is what makes this Hyperledger project so powerful.

Hyperledger Sawtooth solves asset transfers

We started with Tic Tac Toe; other solutions can only get better and the community aspects of Hyperledger inspire collaboration. A company called Pokitdok defined a more interesting transaction family and shared its overall design with the world. You can read about it here. To quickly summarize, they have defined a new transaction family which supports their in-ledger asset and created it as an integral component of their operation by batching transactions from their application specific families with coin transactions. You can read more specifics about cross family transaction batching here.

What is interesting is the fact that this solution allows an existing network, to add accounting and asset transfers on a DLT without changing any of its core structure. Just like with our initial example, the power of Sawtooth lies in its clear separation of concerns.

Setting up a DLT to move assets around

We keep mentioning how great this separation of concerns is, but how different do two DLT applications need to really be and how much should the underlying network change to support these two extremes in a complexity spectrum? Setup is exactly the same for these two implementations. You could even use the development ready docker composer files provided by the Sawtooth team. The only change that will need to be applied is to run a new transaction family create command to add the newly defined asset management transaction family. It would look something like this:


sawset proposal create — url http://rest-api:8008 
— key /root/.sawtooth/keys/my_key.priv
sawtooth.validator.transaction_families=’[{“family”: “assets”, “version”: “1.0”},
{“family”:”sawtooth_settings”, “version”:”1.0"}]’


Now this is more like it; with all the talk of DLT and how it’s going to change the face of software forever, it’s refreshing to see how simple it can be to run a full fledged crypto asset management network.

Putting it all together

These examples were not meant to prove the validity of DLT, rather to illustrate the simplicity and practicality of Hyperledger Sawtooth. To demystify the utility and complexity of DLT powered solutions and create a simple path towards more meaningful implementations and uses of the technology. The Hyperledger Sawtooth framework allows you to easily implement your application’s logic as a transaction family and have it running on a scalable DLT network within minutes.

Sawtooth is built for performance and decent scalability and as mentioned earlier has a simple network structure that allows for very large deployments without a lot of specialized software components. At its core, its focus on separation of concerns empowers developers to create any transaction family you can think of. The asset management example also allows us to see how incredibly powerful composition through reuse could become.

The project also shows great promise for extensibility for larger & open, not just permissioned solutions. Finally, the addition of yet another really powerful transaction family called SETH extends Sawtooth to process Ethereum smart contracts. With some minor changes, any Sawtooth network that includes SETH would be able to run any solidity contract. Our team is currently working on migrating one of our Ethereum powered solutions into our own Sawtooth network and hopefully soon we will share it on another blog post.


[VIDEO] Hyperledger Interviews Ram Jagadeesan, Distinguished Engineer & CTO of Blockchain Incubation at CISCO

By | 网志

We are excited to feature Ram Jagadeesan and Hyperledger founding and Premier Member CISCO in this month’s Hyperledger community spotlight. Ram is a Distinguished Engineer and CTO of Blockchain Incubation at CISCO’s Chief Strategy office, and he serves on the Hyperledger Governing Board. A highly-regarded contributor to open standards and open source implementation, Ram was a founder and board member of Open Interconnect Consortium, where he drove IoT interoperability.

CISCO joined Hyperledger because they are firm believers in open source, open standards and interoperability. In this video, filmed at Hyperledger Member Summit in Singapore, Ram shares his thoughts on the impact of blockchain across industry verticals, how the technology is being used today compared with its future potential, and how to fast-track blockchain technology adoption.

According to Ram, “[CISCO is] very excited by the potential for blockchain technology and the opportunity it represents, but we do believe that a strong open ecosystem is needed for the technology to gain widespread adoption. This is true especially for a collaborative network technology like blockchain.”

Since it’s inception, Ram has chaired the Hyperledger Architecture Working Group (AWG), where he is a proponent of modern architecture framework for enterprise-class blockchain. The AWG serves as a cross project forum for architects and technologists from the Hyperledger community to exchange ideas and explore alternate architectural options, discuss the tradeoffs, and capture the reasoning behind the choices. The AWG provides recommendations and architectural guidance to the projects in the Hyperledger greenhouse and encourage them towards convergence on a modular architecture.

All are welcome to join the biweekly AWG calls on Wednesdays at 9 a.m. PST. Check out previous meeting minutes, dial-in details and publications collaboratively written by the AWG on the Wiki here.

3 Things Ethereum Users Should Know about Hyperledger Burrow

By | 网志, Hyperledger Burrow

Guest post: Casey Kuhlman, CEO, Monax

An Introduction to Hyperledger Burrow for Ether-heads

Over the years, there has been a lot of confusion within the Ethereum community about the various codebases which claim to be “Ethereum.” To us at Monax, the word Ethereum has meant a variety of things. It has meant a singular blockchain network and its attendant testnets. It has meant a series of software codebases. And it has also meant an “idea” about how smart contracting platforms operate; namely, that there should be a strongly-deterministic, smart contract native virtual machine that operates blockchain-based smart contracts.

Enter Hyperledger Burrow, one of the Hyperledger projects hosted by the Linux Foundation. Hyperledger Burrow provides a modular blockchain client with a permissioned smart contract interpreter partially developed to the specification of the Ethereum Virtual Machine (EVM). While it is certainly true that Hyperledger Burrow as a piece of software was not designed to be an active participant in the public Ethereum network and its testnets, in the other senses of “Ethereum”, Hyperledger Burrow has always been a member of the community.

This blog post is written to provide an overview of Hyperledger Burrow. It walks through three important things to note about the project and how those familiar with Ethereum could seek to implement proofs of concept, private or consortia blockchains.

1. Hyperledger Burrow is more like the Redis of Smart Contract Blockchains

Hyperledger Burrow maintainer, Silas Davis, often describes Burrow as the Redis of blockchains because Burrow was built to be a lightweight, efficient, and fast permissioned smart contract machine. By leveraging the hardened and speedy Tendermint protocol for consensus alongside Burrow’s Apache licensed Ethereum Virtual Machine, users have access to one of the fastest codebases available.

Speed in blockchains comes in a number of dimensions. The first dimension is the amount of transactional throughput of the codebase. We have observed in preliminary testing that Hyperledger Burrow can steadily process upwards of 200 transactions per second. This speed dimension for smart contract focused blockchains is largely a misnomer, however, because the speed of processing is strongly linked to the complexity of smart contracts operating on any one blockchains. The second dimension is the speed at which blocks are propagated within the network. Hyperledger Burrow’s blocktime is tunable, but by default produces blocks every two seconds.

The final dimension is less quantifiable but asks the question “when can my other systems rely upon the information within a given block as being final?’ Finality of blocks is a crucial issue — particularly when other business systems rely on information propagated by a blockchain network. Hyperledger Burrow was the first Ethereum style blockchain to offer its users strong finality. Relying upon the Tendermint protocol, Burrow produces a non-forking blockchain. This means that the instant that a block is added to the end of a chain that other business systems will be able to rely upon that information. Finality greatly increases the overall system speed by ensuring that upstream systems can rely on the information within a blockchain instantly.

Not only is Hyperledger Burrow, speedy, but it is also extremely lightweight. We routinely run Burrow nodes on very small cloud instances and even on Raspberry Pi’s. Burrow’s proof of stake consensus protocol is fully byzantine fault tolerant without relying on specialized hardware.

2. Hyperledger Burrow permissions without a VPN

Many users when they are first exploring blockchain technology are taking blockchain clients built for a public chain and deploying them behind a VPN. With Hyperledger Burrow, it is not necessary to operate a permissioned chain behind a VPN in order to gain fast and secure validation. Burrow’s in built capabilities based permissioning system offers users easy access to a structured permissioning system.

This means that operators of any network can establish which keys can do what things within the context of the blockchain network. Of course over time these permissions can be changed by sending a transaction signed by a key with permission to change other’s permissions within the network.

In effect, this allows users to start small and grow their ecosystems and networks over time. Many users begin their blockchain exploration with only a single company operating a blockchain network and over time seek to expand the set of operators of that network. Hyperledger Burrow’s capabilities based permissioning system is built for this ever-evolving world. Burrow is even capable of growing into a permissioned, public chain should users so desire.

3. Ethereum Virtual Machine all the Things with Hyperledger Burrow

Burrow has kick started a wave of use of the Ethereum Virtual Machine (EVM) within the context of other Hyperledger blockchain designs. From the perspective of the Burrow team, this is an amazing use of open source modalities. By working with the Hyperledger Sawtooth team, we have identified areas of how to reimplement our EVM such that it can be more easily consumed by other codebases. The effects of the collaboration between Sawtooth and Burrow teams have been the SETH system which allows Sawtooth users to operate EVM contracts within a transaction processor.

The Hyperledger Burrow team has also began working with the Hyperledger Fabric team, and the effect of that collaboration will hopefully be the ability for Fabric users to also deploy EVM contracts onto their networks to be operated by an EVM chaincode container. Such a deployment style will be a boon for Hyperledger Fabric users as it would greatly reduce any distribution challenges for smart contracts within the network. We are also collaborating actively with the Fabric team on a Web3 RPC framework that can be implemented easily and simply by multiple codebases.

These collaboration across Hyperledger teams are one of the greatest benefits for us on the Burrow team being a part of the larger Hyperledger community. Not only do we receive great feedback from upstream teams that are using our EVM in their codebases, but we also receive contributions from there projects as well.

Getting started

For those seeking to get started with the exciting possibilities that Ethereum Virtual Machine capable blockchains offer, Hyperledger Burrow is a great choice for getting started. As noted above, it is a speedy and lightweight blockchain design.

Burrow’s high-level architecture is described (in diagrammatic form) below:

Given the increased uptake in EVM usage across the Hyperledger blockchain frameworks, should the capabilities of Burrow not be suitable for production level deployments, there is an easy migration path to another of the more feature-filled blockchain platforms such as Hyperledger Fabric and Sawtooth. Since contracts written for an EVM run the same no matter the blockchain they are running on, users can easily start with Hyperledger Burrow and over time migrate their smart contract suites to the more feature-filled platforms.

You can get started with Hyperledger Burrow today very simply. Read the documentation and/or download the code to kick the tires. You can also join the discussion on Rocket.Chat!


Hyperledger Sawtooth, Seth and Truffle 101

By | 网志, Hyperledger Burrow, Hyperledger Sawtooth

Guest post: Nathan Aw

I develop on both Hyperledger Fabric/Sawtooth and Ethereum (to be specified, Quorum) so I am familiar with the languages available on both platform — chaincode (Go) and smart contract (Solidity). Often I am asked this question: “Which platform is better?” To which I will answer, this question is a false choice as with Hyperledger Sawtooth Seth, you can build your smart contracts in Solidity and deploy the same smart contract in Hyperledger Sawtooth — Pretty cool isn’t it? 😉

Before we get to the technical section, we need to get a handle on the basic terminology first.

What is Hyperledger Sawtooth?

Hyperledger Sawtooth is an enterprise blockchain platform for building distributed ledger applications and networks. The design philosophy targets keeping ledgers distributed and making smart contracts safe, particularly for enterprise use.

Sawtooth simplifies blockchain application development by separating the core system from the application domain. Application developers can specify the business rules appropriate for their application, using the language of their choice, without needing to know the underlying design of the core system.

Sawtooth is also highly modular. This modularity enables enterprises and consortia to make policy decisions that they are best equipped to make. Sawtooth’s core design allows applications to choose the transaction rules, permissioning, and consensus algorithms that support their unique business needs.

What is Hyperledger Sawtooth Seth?

The primary goal of the Sawtooth-Ethereum integration project, which is also known as “Seth” is to add support for running Ethereum Virtual Machine Smart Contracts to the Hyperledger Sawtooth Platform.

Ethereum Virtual Machine (EVM) Smart Contracts can be deployed to Sawtooth using the Seth Transaction family. The Seth Transaction Family enables the creation and execution of smart contracts. It integrates the Hyperledger Burrow implementation of the EVM into the Hyperledger Sawtooth Framework using the Sawtooth Transaction Processor SDK.

For those familiar with Ethereum Geth (Go-Ethereum) client, you will find out that Sawtooth Seth client replicates the Ethereum JSON RPC API.

Seth is composed of three components

  1. Seth Client
  2. Seth-TP Transaction Processor
  3. Seth-RPC Server

For more details on JSON RPC API, check out

Do note that Seth is not a complete Ethereum implementation. The Sawtooth platform has made fundamental design decisions that differ from those made by the Ethereum platform. The specified differences can be found under Sources/References

What is Truffle?

Truffle is often considered the most popular Ethereum development framework. Truffle does a lot of things for the developer. It is a development environment, testing framework and asset pipeline for Ethereum, aiming to make life as an Ethereum developer easier. We won’t be going through Truffle. Point of introducing Truffle is to share with you that one can build smart contracts with Solidity and enjoy Truffle and its related capabilities and yet deploy the end product (i.e., your Smart Contract) onto Hyperledger Sawtooth — this to me is pretty awesome! For more information on truffle, please check out

Step by Step Setup Guide

I am using Ubuntu 16.04. You will need git and Docker installed.  

  1. Do a git clone of sawtooth-seth

2. Build the Sawtooth Seth

This process will take 10 – 15 minutes.

  1. Run Sawtooth Seth

docker run -v $(pwd)/docs:/project/sawtooth-seth/docs seth-build-docs

  1. Verify if the components are running correctly  


curl -d ‘{“jsonrpc”: “2.0”, “id”: 1, “method”: “eth_blockNumber”}’ -H “Content-Type: application/json”

  1. Creating an Account. Generating a Key Pair

In order to interact with Seth, we need to create an external account on the network. Creating an account is equivalent to generating a new private key that Seth can understand. Seth accepts secp256k1 private keys

docker exec -it seth bash

openssl ecparam -genkey -name secp256k1 | openssl ec -out mykey.pem -aes128

Now we are ready to set up the account on the network. To do this, we need to use the seth command. From the prompt where you generated the key, run:

seth account import mykey.pem myalias

seth account create myalias –wait

seth show account {address}

  1. Write the Smart Contract

Once you have an account created, you can use it to deploy EVM smart contracts. To demonstrate how to deploy and call contracts, we will be using the following Solidity contract, which is based loosely on the IntegerKey Transaction Family. Solidity is a high-level language for defining contracts that compiles to EVM byte code for deployment. To follow along with this guide, you should create a new file with this contract:

pragma solidity ^0.4.0;

contract intkey {

 mapping (uint => uint) intmap;

 event Set(uint key, uint value);

function set(uint key, uint value) {

   intmap[key] = value;

   Set(key, value);


 function inc(uint key){

   intmap[key] = intmap[key] + 1;


 function dec(uint key){

   intmap[key] = intmap[key] – 1;


 function get(uint key) constant returns (uint retVal) {

   return intmap[key];



Save this contract in a file called “contract.sol” in your working directory. If you are working with the development environment described in :doc`./getting_started` you should save this file in the sawtooth-core/ directory on your host so that it is available within the seth container.

Before we can deploy this contract, we have to compile it. The seth client expects that the contract will be passed as a hex-encoded byte array. We can use the Solidity compiler solc to create it. If you followed the Getting Started instructions, this tool is already installed in the seth container we created earlier. Connect to the seth container as explained there. If not, we assume you have it installed locally.

$ solc –bin contract.sol

======= contract.sol:intkey =======


…byte array here…

In place of {contract} you should insert the blob of hex that you saved from earlier. This will create a new contract creation transaction and submit it to the validator.

If everything works, a new contract account will be created and the client will print the address of the newly created contract account along with some additional execution information. To confirm the contract was deployed, you can run:

seth show account {address}

  1. Calling Contracts

To call the deployed contract we need the address where the contract is deployed and the input data for the contract call. The address was printed when the contract was deployed. Constructing the input for the contract is a little harder.

Solidity uses an Application Binary Interface or ABI to determine which function in your contract to run and what the function call’s arguments are. There are many tools available for abstracting the creation of the input data for a contract call. One option for generating the input data that is compatible with the seth client is the ethereumjs-abi library. If you are using the development environment described earlier, this is already installed in the seth docker container.

To use this library to call a function in contract, you can use the simpleEncode. The following shows how to call the set() function in the contract we deployed earlier with arguments 19 and 42:

$ node

> var abi = require(‘ethereumjs-abi’)

> abi.simpleEncode(“set(uint,uint)”, “0x13”, “0x2a”).toString(“hex”)

…byte array here…

To call our contract and run set(19,42), run:

seth contract call –wait {address} {input}

In place of {input} you should insert the blob of hex formatted according to the contract’s ABI that we created above. If everything works, the client will state that transaction was succesful and print the transaction id. To verify that the message call was successful, you can do:

seth show receipt {transaction-id}

seth contract create –wait myalias {contract}


Imagine having the best of both worlds — building smart contracts with Solidity, originally intended for EVM — and deploying it onto Hyperledger Sawtooth. Portability is the key differentiator here which explains why I love building smart contracts with Solidity and deploying it onto Sawtooth via Seth.  

I am happy to answer any questions you might have on Hyperledger Sawtooth and Solidity or any blockchain related questions. Drop me a line at and/or connect with me on Linkedin at


Blockchain and the Enterprise. But What about Security? Webinar Q&A

By | 网志

Our Security Maven Dave and Director of Ecosystem, Marta recently presented the “Blockchain is the New Black, but What About Security?” webinar. It was a recap of a talk they gave at RSA. As Dave and Marta covered a lot of different aspects of blockchain from the history of distributed ledgers to the shifts in security models and use cases, it was no wonder that 45 minutes was not enough. Along with the general questions about the business and community side of things, we received a lot of questions on technical topics like identity systems, permissioned vs. permissionless systems, distributed ledger technology, performance and security. It is our pleasure to go into more detail on topics discussed during the webinar. We’ve organized them into the themes below. Let’s give it a shot!

Business & Community

For those that don’t know Hyperledger follows a greenhouse approach, and we believe collaboration enables innovation. This means that we do not plan to merge the frameworks together into a single Hyperledger framework, or take over any other ones to eliminate it. We welcome new projects and new ideas into our greenhouse and hope that they grow.

We got comments on the fact that its mostly enterprises that develop blockchain based solutions, and that it is hard to evaluate the return on investment. The latter is very true. This is driven by the fact that there is no one blockchain solution and even when using a certain framework, depending on the setting used the cost will be different. It is worth remembering that, as we discussed in the webinar, blockchain can only be part of a larger solution. It’s not a magic fix or something that is going to answer to all your problems. Some important metrics are being evaluated by our Performance and Scalability Working Group. As everything technical in Hyperledger, the group is open to public, so please see what’s buzzing during the next meeting or browse through the wiki and mailing list. Blockchain offers cost-effective and time-efficient features impacting the total cost of ownership positively. The blockchain technology stack is robust and verifiable alternative to traditional proprietary stacks at a fraction of the cost. Blockchain technology makes it possible to give various parties (e.g., clients, custodians and regulators) access to their own live copies of a shared system of record.[1] To answer the first part: we see more startups and freshly created companies in this space than before. Blockchain enables creativity and expansion with very limited resources. Some of the stars in the field include BigchainDB, Medicalchain, or ChainNova.

We have a lot of Working Groups that meet regularly and try to evaluate some of the questions and issues around Hyperledger and permissioned blockchain. There is a healthcare working group that looks at how blockchain can be used to tackle problems around patient data sharing or prescriptions. There is a public sector working group that looks at the government use cases. We have an identity working group that is working on a whitepaper discussing the identity management in Hyperledger frameworks as well as we have worked together with a group of researchers on a GDPR and Blockchain paper. Everyone is welcome to come to the meetings and submit their questions and proposals. We also welcome discussions on our chat. If you think we are missing a topic, you can propose a new working group according to the process Technical Steering Committee defined. If you have code you’d like to contribute, we have also launched Hyperledger Labs.

In terms of where things are going, timelines, projects and such, we have some great news for you: all the code is available, and downloadable from our github. You can check out every project’s wiki page for roadmaps and plans and participate in their weekly meetings to have a peek at what is planned. Many of the frameworks are being used for live deployments. We are very happy to say, that we know of more than 40 live deployments on Hyperledger frameworks already. Depending on the industry, various technologies are being used. The use cases spread from supply chain, trade finance, music industry, all the way to fashion, healthcare and many more. And remember that due to the open source nature of the project we are unable to track all of them!

Permissioned vs Public Blockchains

If we want to get a bit more technical, let’s start with the differences between permissioned blockchains like the platforms developed by the Hyperledger community and public blockchains such as Bitcoin and Ethereum. As we discussed in the webinar, Hyperledger was created to host enterprise grade blockchain frameworks. While we do not limit ourselves to only one type (like permissioned-private or permissionless-private) today all of our frameworks are permissioned and in theory only Hyperledger Sawtooth could be implemented as a permissionless system. The main difference is that public blockchains are open to anybody and rely on much slower consensus protocols based on proof-of-work. Hyperledger blockchain platforms are designed to work in environments where all participants need to fulfill a certain set of rules to participate. This allows the distributed ledger to use faster consensus protocols and to dynamically configurable over the lifetime of the blockchain. The consensus protocols are designed to be resilient as long as some fraction of nodes—typically 2/3rds—are honest nodes. But this is less of a concern in a permissioned network because participants usually have legal and/or business incentives to not be malicious. Moreover, participants of a permissioned blockchain are already incentivized to execute the consensus so we have no need to build in tokens to such solutions. If you’d like to learn more about permissioned blockchains and Hyperledger, we strongly recommend going through the open source, free course we created.

Distributed Ledger Architecture

Now, that you have the basics, we can talk about how Hyperledger permissioned blockchains encode their configuration in configuration transactions stored in the blockchain. The configuration typically specifies which cryptographic algorithms are used for public/private encryption and signing as well as which consensus protocol is being used. This design allows the blockchain to evolve with business requirements and/or changes in cryptography (e.g. quantum computers or breaks in certain algorithms). Instead of having to throw away a blockchain—something that could cause considerable harm—Hyperledger blockchains can change which algorithms they are using (e.g. increasing key lengths) and/or which consensus protocol is being used if there is a different one that better fits the environment of the network.

Membership in a permissioned network is typically controlled by a central authority that enrolls users. The enrollment process involves the membership authority storing the public key of the user and signing it with the master key. This will allow the user to use their private key to sign their messages to other participants in the network and the other participants can trust that the user is valid member of the network. When a user is removed from the network, their key isn’t deleted, but the central authority issues a revocation certificate telling the participants that they can no longer trust the key associated with the user. This does not invalidate any of the signatures made by the removed user, it just prevents them from signing anything else. It is a bit complicated, but thankfully our Architecture Working Group has published two great white papers: on consensus mechanisms used in Hyperledger, and on smart contracts. As we grow, and if community decides to adopt other ideas, we hope to keep the papers updated.

Performance Metrics

A critique often stated is that blockchain technology doesn’t scale or is too slow. This is in reference to public permissionless implementations. With private or permissioned ledgers the speed of the update mechanisms are easily addressed. Hyperledger blockchain platforms don’t have fixed consensus windows like Bitcoins’ 10 minute block time. Also, because Hyperledger platforms have configurable consensus mechanisms, each deployment can choose and configure a consensus mechanism that best meets the need of the application.

However, we don’t have any official numbers but we do have a Performance and Scalability working group that focuses on how to measure the performance of distributed ledgers. Distributed systems are difficult to quantify in terms of performance, especially that with such a new technology there is no agreed upon standard for what we should measure so that we can compare one blockchain to another. Thankfully we also have Hyperledger Caliper, which is a tool that is aiming to stress test your implementations.

Identity Systems

It is great to see a lot of excitement around Identity Systems. And hopefully with the last webinar given by our Ambassador, Daniel Hardman, many of the questions have been already answered. The excitement of blockchain based identity systems comes from the fact that the security and authentication of blockchains is distributed and at the edges as opposed to being centralized. Distributed blockchains creates the possibility of realizing the dream of truly self-sovereign identity where the data about any given person is directly under the control of the person and endorsed and annotated sources of trust—a.k.a. trust anchors—that we already recognize in society (e.g. governments, professional certification organizations, civil rights organizations, universities, etc). For instance, I could store my identity, encrypted on a server, and then track that data and make it discoverable by adding it to an identity blockchain system.

Trust anchors like my alma mater and my local government could issue verifiable claims that are linked to my identity. The claims can cryptographically prove that I earned a university degree or that I am old enough to drive a car or consume alcohol. The important detail is that everything is under my direct control. I present the claims when needed and I can reveal only pieces of my identity as needed.

It is important to note that none of my personal data is stored directly in the blockchain. What is stored is the metadata about my personal data. Things like when my data was created, when it was updated and when it has been accessed. Blockchains are most useful for tracking the provenance of data and in this case it is tracking the set of personal identity data. Exiting, the EU Commission’s Blockchain Observatory Data Policy & Compliance Working Group met for a workshop in Brussels, Belgium, and discussed blockchain compatibility with the GDPR.The framework build in Hyperledger, Indy, has been announced as one of the two GDPR compliant!


We were happy to see very few security questions. It gave us hope we actually did a decent job explaining the topic thoroughly. Since distributed ledgers is still an evolving technology, specifically the permissioned variety, it may be hard to argue that it is ‘proven’ and time tested. However, the usage of vetted cryptographic primitives, sound consensus mechanisms based on decades of research and improved security and privacy—especially compared to permissionless systems—creates a substantial foundation upon which distributed ledgers are built. Blockchain and distributed ledger technology ensure immutability of the data in a network. In terms of reliability, blockchains are designed to provide a distributed and shared ledger abstraction, where ledger immutability, cryptographic authenticity and the tolerance against attacks and faults is a core property. While currently efforts to canonize blockchain-based distributed ledgers in a generalized way tend to somewhat focus on the functional side (as the “chain of blocks“ data model or the distributed ledger abstraction), a blockchain-based DLT is also positively required to be highly tolerant against faults and attacks. However, generally when a system actively allocates resources to engage dependability or security mechanisms (e.g. for fault tolerance: spatial, time or data redundancy), its peak performance potentially diminishes.[2]



We hope this outline of topics we dove into helps clear up some things up for some people. If interested, you can watch a replay of the “Blockchain and the Enterprise. But What about Security” webinar here:

As always, you can keep up with what’s new with Hyperledger on Twitter or email us with any other questions: