Hyperledger Burrow

All Are Welcome Here

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

A Minneapolis coffee shop that has fueled or at least caffeinated a lot of Hyperledger commits.

One of the first things people learn when coming to Hyperledger is that Hyperledger isn’t, like it’s name may imply, a ledger. It is a collection of blockchain technology projects. When we started out it was clear almost immediately that a single project could not satisfy the broad range of uses nor explore enough creative and useful approaches to fit those needs. Having a portfolio of projects, though, enables us to have the variety of ideas and contributors to become a strong open source community. Back in January of 2016 Sawtooth and Fabric were both on the horizon followed shortly by Iroha, but we wouldn’t have predicted that we would have Hyperledger Burrow and Hyperledger Indy – two projects that bear no resemblance to each other. Burrow is a permissioned Ethereum-based platform and Indy is a distributed identity ledger. Burrow is written in Go, and Indy was created in Python and is porting to Rust.

Both of these platforms are interesting in their own rights, but Hyperledger is even more interesting for the combination of these projects with the others. Both Sawtooth and Fabric have already integrated with Burrow’s EVM. Now Hyperledger has a set of offerings that can simultaneously satisfy diverse requirements for smart contract language, permissioning, and consensus. Likewise Sawtooth and Indy have been working together at our last several hackfests. The results of that may unlock new use cases and deployment architectures for distributed identity. So it’s not that our multiplicity of projects has given us strength through numbers, but rather strength through diversity.

Hyperledger Hackfest – December 2017 at The Underground Lisboa

The hackfests that we mentioned are one of the rare times that we get together face to face. Most of our collaboration is over mail list, chat, and pull-requests. When we do get together though it’s always in a new city with new faces. One of our most recent projects was hatched inside one of those buses. It wasn’t the most ergonomic meeting I’ve ever had but there was room for everyone on that bus.

Hyperledger Hackfest in Chicago

Our hackfest in Chicago was in a lot more conventional surroundings (still a very cool shared creative space .. lots of lab equipment and benches out of view on the other side of the wall to the right). Looking back at this photo is fun for me. I can see a lot of separate conversations happening at each table… people sharing different ideas, helping ramp new contributors, working on advancing new concepts with existing contributors. I can see a lot of similarity but also a little variety. It’s a busy room but there’s still open chairs and room for more variety.

Our next hackfest won’t be until March 2019 (Hyperledger is hosting Hyperledger Global Forum in December in Basel though). The March hackfest will be somewhere in Asia – location to be settled soon. The dates and locations of the other 2019 hackfests aren’t set yet. I don’t know where they will be specifically, but I do know that there will be a seat available and you will be welcome there.

These face to face meetings really are more the exception than the rule at Hyperledger. There are now more than 780 contributors spread all across the globe. 165 of those were just in the last few months. That means that every day we have a new person contributing to Hyperledger. Most of our engagement is through the development process. People contribute bug fixes, write new documentation, develop new features, file bugs, etc. If you’ve never contributed open source code before getting started might be intimidating. We don’t want it to be, though. There are a number of resources to help you get started. You can watch this quick video from Community Architect, Tracy Kuhrt. There’s documentation for each project, mail lists, a chat server, working groups, and some of the projects even host weekly phone calls to help new developers get engaged. Everyone in Hyperledger abides by a Code of Conduct so you can feel comfortable knowing that when you join any of those forums you will be treated respectfully. Anyone who wants to get involved can regardless of “physical appearance, race, ethnic origin, genetic differences, national or social origin, name, religion, gender, sexual orientation, family or health situation, pregnancy, disability, age, education, wealth, domicile, political view, morals, employment, or union activity.” We know that to get the best ideas, best code, best user experience we need your involvement. Please come join our community.

Image created by for Hyperledger

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

The journey to becoming a Hyperledger contributor

By | Blog, Hyperledger Burrow, Hyperledger Fabric

Guest Post: Av Lakshmy

I am an undergraduate student in the Department of Computer Science and Engineering at the Indian Institute of Technology Madras (IIT Madras), India. This summer, I had a wonderful opportunity to intern at Hyperledger. I worked on a module related to the integration of Burrow EVM into Hyperledger Fabric, specifically integrating Ethereum events into Fabric, under my mentors, Swetha Mam and Jay Sir.

Before this internship, I had very little knowledge of blockchains. Moreover, this was my first experience with open-source development. But, over the course of the internship, I have learnt a lot! Let me share with you my journey over the past few months: how I learnt about blockchain frameworks, became familiar with the Hyperledger development process, and submitted my first patch using Git. I would also like to share some of the key lessons I learnt along the way.

Most people who are new to open source development may find it a bit difficult to get started, since there are no clearly-defined instructions or hard deadlines. Indeed, open source development is more self-driven but is a joy once we get used to it! Let me outline the steps involved in contributing to open source code, especially for Hyperledger projects.

The first and most important step in open source development is identifying the area where we want to contribute. Fortunately for me, this was taken care of by my mentors. This is the first lesson I learnt. Like many other endeavours in life, once we have a mentor, things become much easier. Of course, as we understand the project more and more, we can ourselves develop a better idea of where we can contribute.

Prior knowledge of the programming language involved in the project is desirable but not essential. We can always learn the language while writing the code. This brings us to another important lesson I learnt. Lack of proficiency in the language being used should not be a mental block while volunteering for an open source project. Most of the Fabric code is in Golang, which I had never worked with so I had some apprehensions. But, within a few days, my confidence increased, and by the time I finished the internship, I had become reasonably proficient in Golang.

Another lesson I learnt is that, besides the specific module on which we are working, we must also have a broad awareness of related modules, so that we have a holistic understanding of the project. For this, we must go through the documentation on the project, and do some background reading. I spent the first three weeks of the 12-week internship just studying about blockchains, and the three main platforms involved in my project, namely Hyperledger Fabric, Hyperledger Burrow and Ethereum.

The next lesson I learnt is that, we have to carefully set up our development environment to ensure that all the versions of the different softwares and tools downloaded are compatible. Otherwise, we may face problems later on. This is the phase where we may have a lot of questions and doubts, since the environment on each developer’s machine will be different. The documentation usually does not have the answers to all these questions. Online discussion forums can come in handy here; we can learn from others who have also faced similar issues. Posting doubts on the Hyperledger mailing lists, or in the Rocket Chat channels also helps. In my case, my mentors were very patient and helpful, and they clarified almost all my doubts.

The next step is to delve deep into the specific module we will be working on. We can’t rely on the documentation to guide us here. This is where my mentors gave me an important insight. The best place to understand more about the project is by going through the source code itself. I learnt the importance of going through the source code of vast projects like Fabric and Burrow in a systematic way. I learnt how to track the code flow, starting from an entry point, and tracing the flow of data through several function calls, until the exit point. This gave me a better picture of what is already in place, and where exactly I would have to add my code.

The internship also taught me the importance of test-driven development. The conventional way of software development is to write the code and then test it. But, while implementing large complex software projects, which should work in various scenarios, this method is not recommended. A better method is test-driven development (TDD), where we start with test cases and incrementally build the actual code. As we keep building the code, we can keep adding more complicated test cases to check how well the code works. The rationale behind TDD is that, if a particular test case doesn’t pass, we will know exactly where our code went wrong. This is a much more reliable and convenient way of improving the code. TDD is ideal for open source development where many people are involved. TDD makes it easy for the next contributor to pick up from where we have left because the test cases already being used will indicate the scenarios that have already been dealt with. In my case, we made use of Go testing frameworks like Ginkgo and Gomega to write our test-suites.

The essence of an open source project is the coordination and synchronization of many contributors,working on the code simultaneously. This is where a powerful version control tool like Git comes into the picture.  Once I had written some code for my project, it was time for me to push up a patch. For this, I became familiar with the process of pushing up a Git commit, thereby submitting the code for review. The process of review is iterative and continues till the reviewers find the code good enough to be merged into the repository.

Looking back, my internship project of integrating Ethereum events into Fabric was a rewarding and enriching experience! In the first few weeks, I wrote some simple test cases (using TDD) for the main piece of the project, the chaincode evmcc.go. When my patch passed through the review process and finally got merged into the repository, I was elated! I also wrote code for an event manager module to be integrated with the evmcc.go chaincode. These pieces are still under review and will hopefully be merged soon. I am thrilled that my work will eventually be included in the source code of a prestigious project like Fabric!

I hope this article will motivate people to start contributing to open source projects in general, and Hyperledger in particular.

(9.21.18) InfoQ: Hyperledger Releases New Version of Burrow Featuring Improved Integration and Developer Experience

By | Hyperledger Burrow, News

In a recent blog post, the Hyperledger open source project announced the next version of Hyperledger Burrow v.0.21.0. Within this release, organizations can expect improved integration, key-signing, helm charts for Kubernetes and developer experience.

Hyperledger Burrow is a permissioned Ethereum smart-contract blockchain node that is capable of running Ethereum EVM smart contracts on a permissioned virtual machine. Some of the core capabilities of Burrow include transaction finality and high transaction throughput, in part, due to a Tendermint proof-of-stake consensus engine.

More here.

Hyperledger 2018 Summer Interns Recap

By | Blog, Hyperledger Burrow, Hyperledger Cello, Hyperledger Fabric, Hyperledger Iroha

It’s suddenly September and so it’s time to check in on our Hyperledger summer interns and mentors. Read on for more about five of the projects our interns tackled. We asked the interns about their summer with Hyperledger.

Here, their own words, are the goals, successes and lessons learned from each intern:

Ahmad Zafar (Project: Running Solidity Smart Contracts on Hyperledger Fabric or Vice Versa)

Project goals:

I was working on Running Solidity Smart Contracts on Hyperledger Fabric Project. The Solidity smart contracts are easy to write and are widely used by developers. The aim of this project was to help the developers to translate the publicly available Solidity smart contracts into readable and, hopefully, functionally equivalent Hyperledger Fabric contracts without writing the contracts from scratch. For Hyperledger Fabric, we chose Javascript language. Our goal was to translate 70-80% of the Solidity grammar/programs correctly into fabric smart contracts that are also human readable to make them easy to understand and change.


I have successfully translated approximately 65-70% of solidity code to javascript code for Fabric smart contracts. Examples of language features include types, expressions, functions, events, function modifiers, structs, and single inheritance. Since Ethereum is a public blockchain with notions of Ether (Cryptocurrency) and Ether transfer, I had to provide functional equivalence in terms of Ether transfer on Fabric – (we ignore gas for now).

I have also translated 15 Solidity smart contracts examples to javascript code. These contract have been taken from different places. Some are from solidity documentation, and some are from github repositories, including the ERC20 token format which is used to create ICOs. These contracts were chosen with my mentor to cover a large number of Solidity features.

My translator will work on other contracts as well if the contract has 65-70% of the common components. My translated code and all examples that I have tested are placed on my github repository along with all the other content related to my project, including which components we have covered, how you can run this tool and results of my translated code.

Lessons learned:

For developing a translator from Solidity to Fabric, one has to have knowledge of compilers and has to learn both Solidity and chain code and both frameworks for testing code. Before starting this internship, I worked on compiler construction in my university project. The scope of that project was not big but making a translator for complete language was a massive task for me. Successfully completing that project boosted my skills in writing translator tools for different things. However, before starting this project, I had little knowledge about Ethereum and Hyperledger Fabric smart contracts. After this project, I have become skillful enough in writing both Ethereum and Fabric smart contracts. Other than languages, I have learned how to run contracts on both frameworks and their architecture. In short, I learned many things related to Ethereum and Hyperledger Fabric. This project will help me a lot to start development in blockchain, especially in Fabric and hopefully other Hyperledger frameworks.

A V Lakshmy (Project: Extended Support for EVM and and Tooling in Hyperledger Fabric)

Project goals:

My project involved the integration of Ethereum events into Hyperledger Fabric. The two key goals of the project were:

  • Implementation of event-related interfaces from Hyperledger Burrow to work with the event framework in Hyperledger Fabric
  • Modification of the JSON-RPC API functions in the fabproxy module to deal with events


  • In the initial few weeks of my internship, I wrote some simple test cases for the chaincode evmscc.go. When my patch passed through the review process and finally got merged into the repository, I was elated
  • I also wrote code for an event manager module and modified the API functions in the fabproxy module. These pieces are still under review and will hopefully be merged before the September release.
  • This was my first experience with open-source development and in the exciting field of blockchain. I am thrilled that my work will eventually be included in the source code of a vast project like Fabric!

Lessons learned:

  • I got to study a new programming language, Golang.
  • I learned about Ethereum and Fabric and how to interact with these blockchain frameworks.
  • I got an exposure to version control systems like Git.
  • I grasped good software engineering principles, such as test-driven development.

I am very grateful to my mentors, Swetha Mam and Jay Sir , for patiently guiding me through this project. All in all, this project was an incredible learning experience for me!

Daniel McSheehy (Project: Hyperledger Fabric Chrome Extension)

Project goals:

The goals of my project was to build a Chrome extension that can connect to a Hyperledger Fabric network and provide an easy to use api for websites to send transactions.


The Chrome Extension is operational. Through a simple api, a website can easily prompt the chrome extension to send transactions and query the ledger. The extension also requires confirmations from the user, preventing a website maliciously sending transactions.

Lessons learned:

Sometimes the “right” way to do something doesn’t work, so I had to come up with alternative solutions to get things working. Because my project is intended to make things easy for users, I also learned the importance of reaching out to others and receiving feedback.

Martin Martinez (Project: Simulating Hyperledger Networks with Shadow)

Project goals:

We had two key goals for the project:

  • Analyzing the current Shadow tool characteristics to find compatibility with Hyperledger networks.
  • Testing the Shadow tool with platforms such a Hyperledger Sawtooth, Hyperledger Fabric and Hyperledger Iroha.


We successfully identified that Hyperledger Iroha is the most suited candidate to use the Shadow network simulation tool.

Lessons learned:

I learn more about the complexity and benefits of working in an open source community. Also, I feel grateful for the support of my mentor as well as the Hyperledger community members that I contacted through different channels such a Hyperledger chat.

Shuo Wang (Project: Design Effective Operational Platform for Blockchain Management)

Project goals:

My internship project focused on supporting dynamic blockchain configuration and integrating Fabric-CA module into Hyperledger Cello to make it more suitable for production environment. For beginners or in the testing environment, we often use an offline tool to generate all the cryptographic configuration artifacts statically. However, it is a centralized and unsafe way for a single user to generate all users’ identities in a real application scenario.


I adopted Fabric-CA module and made the generation of cryptographic artifacts dynamic, automatic and decentralized. After users login into an operator dashboard, they could easily connect to a worker node and create the blockchain on it with quite simple configuration of the network type, size and roles in the blockchain. All the orderer nodes and peer nodes will register and enroll their identities from the CA server. Then users could login into a User-Dashboard to install and run chaincode in the blockchain with a newly generated user identity from the CA server.

I will continue to work in Hyperledger Cello Project after internship, and I plan to make the process of Cello workflow more dynamic so that each organization in the blockchain network could change their own settings more freely.

Currently, I am doing my master thesis at the Southern University of California and Tsinghua University. My research is focused on the blockchain consensus. Therefore, I am quite interested in seeing the Byzantine-fault-tolerant consensus used in the future version of Hyperledger Fabric.

Lessons learned:

During the internship, I enjoyed the culture of open source and learned some great tools for open source project development. The most important lesson I learned is to be timely in following up and keep in close touch with mentors and colleagues because people work collaboratively from all over the world. I really appreciate my mentor, Dr. Baohua Yang, and his kind help and guidance. He gave me many practical suggestions and shared deep insight of blockchain industry with me.

As a bonus, we asked for the intern’s take on what they’d like to see Hyperledger do in the future. Here are a couple of our favorite answers:

“I hope Hyperledger offers or organizes hackathons at universities. I think that it could be a great way to get students involved in blockchain and expose them to open source communities. I’m always amazed at the ideas people come up with at hackathons, and think that there could be projects and use cases that have never been thought of.” – Daniel McSheehy

“I hope that Hyperledger continues to give such amazing internship opportunities to students!” – A V Lakshmy

We would like to thank these interns for all their hard work and success. We would also like to recognize the mentors for all the time, effort and input they provided. Many of them went the extra mile and provided some their take on lessons learned, what they gained by being a mentor and advice for future interns as well. We will be posting their reactions and experiences with the program in another blog tomorrow – stay tuned! As always, you can keep up with what’s new with Hyperledger on Twitter or email us with any questions:

Hyperledger Burrow – Even faster and Easier to Use!

By | Blog, Hyperledger Burrow

We’ve just released a new Burrow, and it’s a good one!

Hyperledger Burrow is built to be a unitary binary, and a fast, lightweight and easy to get to grips blockchain framework. Over the past year Hyperledger Burrow has been refactoring itself into an even lighter and more agile network platform – and with the new v.0.21.0 it’s starting to really fire on all four cylinders. The latest version can be downloaded from here.  

We have integrated a number of abstractions with the goal of making it even easier for developers looking to leverage the Ethereum Virtual Machine in a permissioned context to get started with the actually important aspect of building any business-for blockchain use case: namely the business logic encoded in the smart contract layer.

This release and the others preceding it make some landmark improvements to the Burrow architecture, both in its tool and the node itself. Most notable amongst these refinements are:

  • Rewiring with protobuf types and GRPC interfaces across the board to facilitate robust integration points and RPC layers (replacing previous multiple RPCs)
  • Addition of a powerful ETL / execution event service to drive downstream services from smart contract events and to populate queriable datasets from smart contract objects
  • An integrated and harmonized key-signing daemon that can perform as a key-holding delegate for other services
  • Massively improved burrow helm charts for Kubernetes which increase the flexibility and ease of booting complex networks within the popular container orchestration system.
  • Bos (Monax’s deployment tool) has now been integrated as part of Burrow Deploy. Significantly, this includes an Apache2 licenced ABI which we architected from scratch to the Ethereum community’s specification. This enables various Hyperledger projects to build Ethereum smart contract aware systems.
  • Monax’s burrow.js library has been refactored to utilize Burrow’s new GRPC interface, bringing noticeable improvements to the overall developer experience (not to mention better documentation).

One of the most important changes for Burrow is a completely reworked governance transactions framework (or, as we call it, govTx). govTx allows network operators to modify validator sets, native tokens, permissions and more all within the context of a live network. While the work provides the foundation for further on-chain governance policies including committee votes and DPOS-style decision-making (which could be elegantly operated in combination with Tendermint’s upcoming multi-signature validation optionality), what is more important for developers to understand is that govTx allows them to evolve their networks over time from POC to Pilot to Alpha to Beta to Production without needing to change their chain (unless they want to). In upcoming releases we will be continuing to work towards more flexible on-chain governance primitives, namely smart contract upgrades by popular vote, validator set control of permissions and token distribution

The Burrow maintainers have also worked hard on how Burrow signs transactions in the context of advanced applications. Part of this work included the ability to implement address-based signing via Burrow Deploy and transaction server either server- or client-side. Another part of this work involved improving safety in the circumstances where Burrow had multiple authorized tenants seeking to sign transactions on its behalf.

These developments set the bar high and give the Burrow community a strong base on which to build future releases. What we have in store next for Burrow is just as significant and will be in the following areas:

  • A continued focus on chain stability and operability; including hardening, testing, quality assurance, and security of the codebase as the systems that are built on it continue to iterate toward production status.
  • We will also be focusing on how Hyperledger Burrow’s permissioned EVM runtime can continue to be leveraged by and complement a variety of other complex networks from both the public blockchain sector as well as the enterprise blockchain world.

As multiple systems, including the Agreements Network whose development is initially being led by Monax, built on Hyperledger Burrow continue to iterate towards production capacity the maintainers look forward to continuing to work with the community to ensure that Burrow remains the easiest and quickest way to run Ethereum smart contracts in a permissioned context.

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.

3 Things Ethereum Users Should Know about Hyperledger Burrow

By | Blog, 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 | Blog, 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


One Year Later: Interoperability & Standardization Shine at Consensus

By | Blog, Events, Hyperledger Burrow, Hyperledger Fabric, Hyperledger Quilt, Hyperledger Sawtooth

Image: The Hyperledger booth at Consensus 2018

Interoperability and standardization took center stage (literally) last week in New York at Consensus, when organizations like FedEx explained that both Ethereum and Hyperledger technology power their logistics solution and that it was a goal of theirs to be agnostic when choosing ledger technologies. Then there was the Enterprise Ethereum Alliance, which announced their 1.0 specification that many blockchain developer communities, including Hyperledger Sawtooth, plan to be compatible with in the near future.

It seems as though our hard work at Hyperledger has been paying off and Executive Director, Brian Behlendorf believes we’re now seeing evolution beyond the basic technology questions to more involved discussions about scale, interoperability and governance. In fact, he met with Steven Norton of The Wall Street Journal during Consensus to discuss just that. Brian told Steven:

“Now that we have running systems and there is real value on these different networks, figuring out how to wire them together is a greater priority now than it was a few years ago. But even outside the blockchain space, interoperability is always a process, never a destination. People are starting to finally ask how do we get out of a simplistic mode of saying everyone should all be on the same public ledger, and instead get to a more sophisticated set of questions, like what does interoperability actually mean. It might mean wiring these things together with common software underneath. It might also mean common software on top.”

The discussions around interoperability were a significant contrast to what we saw one year ago at Consensus, when many were just trying to wrap their minds around the technology capabilities and experimentation was in full swing. The idea of different blockchains interacting with one another still seemed like several years away. At that time, we only saw a glimpse of potential possibilities for interoperability when the HACERA team created a fun chess game called Dutchess at the Building Blocks Hackathon that used a combination of technologies like Ethereum, Solidity, Quorum, and Hyperledger Sawtooth.

Jonathan Levi from HACERA explaining different technologies powering Dutchess

At Hyperledger, we envision a world of many chains, some public like the crypto-currencies and some permissioned like you will see in healthcare settings. That’s why we focus on developing the common frameworks for building all kinds of chains. Our diverse developer communities remain diligent in helping the industry advance interoperability above the layer of the DLT, and are on constant look out for simple and open cross-blockchain approaches. An early example of this was the integration between the Hyperledger Sawtooth and Hyperledger Burrow projects last year. As a result of that integration, simple EVM smart contracts can be deployed to Hyperledger Sawtooth using the “Seth” (Sawtooth Ethereum) Transaction Family.

“This integration validates that positioning and establishes a strong upstream-downstream relationship between the Sawtooth and Burrow projects. Successful open source endeavours are community driven, collaborative efforts and this linkage between the Hyperledger Sawtooth and Hyperledger Burrow teams reinforces that ethos.” – Adam Ludvik, Bitwise IO & Casey Kuhlman, Monax  

Building on that development, the Hyperledger Sawtooth community released a feature called Dynamic Consensus, which goes beyond pluggable consensus to allow networks to change consensus on the fly. Hyperledger Sawtooth supports three consensus protocols right now and two more are in development. Also in development, is a change to the Sawtooth consensus API that will allow consensus providers written in a variety of languages. This follows a similar pattern to Sawtooth’s support for smart contracts in a variety of languages. This expands the breadth of possible consensus algorithm andprotocols that can be easily coupled to Sawtooth. A more recent example is the Hyperledger Fabric community, which has been working hard to create a bridge to the Ethereum community, so that developers can write EVM smart contracts on Fabric. The hope is that our community will continue to tighten integration and interoperability across Hyperledger projects and beyond, allowing a greater number of available options for developers. We hope that even more developers can start to think out of the box, connecting blockchains, and doing it securely. The problem of working with more than one technology stack is no longer a technical one.  

Community Architect, Tracy Kuhrt presenting at the Hyperledger NYC Meetup after Consensus

Hyperledger was established to bring together related, and even competing, technologies with the expectation that the common governance will lead to interoperability and gradual consolidation. Interoperability will be essential to the widespread adoption of blockchain technology because that is what will help the blockchain business ecosystem standardize and thrive. As Brian mentioned to The Wall Street Journal, standards are hard, but getting everyone to agree will end up being the bigger challenge:

“I think the tech is ready for the volume of transactions people want to throw at it and the flexibility of programming models that they want. It’s really the governance. It’s hard enough for one organization to launch any new product. Getting multiple parties to agree on anything — like a time of day for a meeting, let alone a common application — will end up being a bigger challenge. Standards are hard. These things are alive and humming like a benzene ring. They depend upon everybody running the right thing at all times. That I think operationally will be the big challenge.” – Brian Behlendorf

We look forward to the rest of 2018 and all the progress to be made with interoperability. We hope you join us in the effort by contributing to Hyperledger projects.

You can plug into the Hyperledger community at github, Rocket.Chat the wiki or our mailing list. As always, you can keep up with what’s new with Hyperledger on Twitter or email us with any questions: