Category

Hyperledger Burrow

Burrow – The Boring Blockchain

By Blog, Hyperledger Burrow

Blockchains are too exciting. Burrow wants to be boring. Then we want to be simple. Then we want to be fast. Even more boring than Git is stupid. The kind of boring that lets you sleep well at night. Burrow gives you just enough blockchain to build a strongly decentralised public permissioned network. Enough but no more.

Burrow philosophy

Burrow aims to be simple, complete, opinionated, and lightweight. We want to be ‘the Redis of blockchain.’ Our guiding principles are:

  1. Provide single pure Go binary running as a single process with (almost) everything included
  2. Support public permissioned networks as first-class citizens
  3. Prefer introspection and tight coupling of components over configurability
  4. Provide a single Byzantine Fault Tolerant (BFT) consensus algorithm
  5. Provide a clean and simple developer experience that gets you closer to the metal

Boring deeper

Burrow is a fully fledged blockchain and smart contract framework. That is, you ought to be able to service the same use cases as with Hyperledger Sawtooth, Fabric, and Besu (whereas Iroha takes a slightly different approach to smart contracts).

The core of Burrow is a custom, fully compliant, Ethereum Virtual Machine (EVM) implementation with an authenticated state (Merkle tree) based on Tendermint consensus (A PBFT consensus variant which we embed as a library). Burrow has a coarse-grain Unix-style model of permissioning baked directly into its EVM implementation. Permissions are for things like SEND, CREATE (a contract), and BOND (become a validator).

There are many other features wrought from our use of Burrow in the wild, both to run the Agreements Network and from years of working on use cases when it was still called eris-db.

It is an explicit focus of Burrow to support running permissioned networks that are, in some sense ‘open to the public.’ There are many shades of grey in terms of network participation with Burrow’s permissions model; validators may be established on an invite-only basis, contract creation may be limited to autonomous contracts rather than human participants, or Burrow could be configured much like permissionless public Ethereum. We are particularly interested in modes of operation that bridge the gap between private chains and public permissionless ones. This bridge is why we value BFT consensus so highly, and why we include quorum-based governance primitives.

Burrow avoids relying on container orchestration and virtual machines as part of its basic setup. These technologies are powerful and can also hide a multitude of sins. Burrow provides an ergonomic developer experience on bare metal — on your laptop or server without needing docker or container orchestration in the first instance. We still have high-quality Kubernetes support for use in production, but you can also spin up a multiple node network directly on your laptop. We aim to give a streamlined developer UX and to help build developer intuition with our tools such as burrow examine, our JSON debug output or our curl-able HTTP info endpoint.

You can use our composable command line tools to spin up a simple chain:

 burrow spec -v1 | burrow configure -s- | burrow start -c-

We provide statically linked cross-compiled binaries for Linux, macOS, and Windows.

We run over a Tendermint BFT consensus that prioritises correctness and finality and provides good throughput for networks with several validators in the low 100s. We only expose additional configuration where it is necessary and try to provide higher level configuration and sane default to reduce the numbers of levers you need to pull on.

We provide a smart contract model exclusively in the Ethereum world view (state lives in buckets called ‘accounts’) and assume the structure provided by the EVM ABI.

Our entire state is modelled in Google’s Protocol Buffers, which is used in our GRPC layer down to our underlying state storage.

Three faces of Burrow

Within the Hyperledger family Burrow can be seen to occupy three different niches:

1) The Hyperledger bridge to the Tendermint/Cosmos ecosystem

Burrow is tightly integrated with Tendermint via its ABCI interface for consensus. This integration means Burrow serves as an excellent way into the emerging Cosmos Network as that network and protocol emerge, Burrow will be amongst the first frameworks to join it. If you are interested in running smart contracts on Cosmos and their inter-blockchain proposals then the Burrow project has built most of what you need. We intend to continue to push the envelope on what can run on top of Tendermint/Cosmos.2. An Ethereum side-chain and compatibility project with support for advanced smart contract languages via WASM and experimental economic systems

2) An Ethereum side-chain and compatibility project with support for advanced smart contract languages via WASM and experimental economic systems

Since Burrow shares a smart contract language and ABI with Ethereum we have an impedance match with public Ethereum. We have plans to provide a two-way peg and support for staking on public Ethereum, which makes us a viable option for acting as an Ethereum side-chain. Since we are not pinned down by consensus, p2p, or low-level state compatibility with Ethereum mainnet, we have an excellent opportunity to innovate side-chain architectures and to help influence emerging standards in this direction.

3) A lightweight hackable EVM/Solidity execution library

Having entered Hyperledger as an independently developed Apache 2.0 licensed EVM implementation, we are most well-known for our EVM library. We successfully integrated into Fabric and Sawtooth, which helped us refine our internal interfaces and modularity. Our implementation is straightforward to read and understand and is not complicated by legacy support required for mainnet. In this respect we provide an excellent base for experimenting with the EVM – by extending it or making it run in other contexts (for example there has been recent discussion about running Burrow’s EVM within processor enclaves (e.g. Intel SGX) as part of the newly established Hyperledger Trusted Compute Framework.

For a more detailed look at Hyperledger Burrow features, read an extended version of this article here.

Plea for help


Join us for Hacktoberfest – see Burrow Issues here

If you are looking to get involved in Hyperledger, then you will find in Burrow a small and uncrowded community with much to do. We have interesting features for newcomers to work on, and we are in search of contributors and maintainers. Come and help us build! I or another Burrow maintainer will be happy to help you to get going with any of Burrow’s features if you swing by Burrow chat. If you are willing to spend a little time sequestering that knowledge by contributing to our documentation, I am willing to devote special attention to your learning and the needs of your use case, including by making changes to the Burrow roadmap or fixing bugs on the spot.

References

To learn more about the project and community, check out these resources:

About the Author

Silas Davis is the Burrow maintainer and CTO at Monax.io. An outdoor adventurer, dad, math fan, and local political advocate, Silas looks forward to collaborating on Hyperledger  Burrow.

2019 Summer Mentee Project Update: Integration of EVM from Hyperledger Burrow into Hyperledger Iroha

By Blog, Hyperledger Burrow, Hyperledger Iroha, Hyperledger Summer Mentorship Program

Hello, my name is Ivan Tyulyandin. I am a student at Saint Petersburg State University. I took part in the Hyperledger Internship Program, working with Andrei Lebedev (my mentor), Iurii Vinogradov and Eugene Kovalev from the Hyperledger Iroha team.

Hyperledger Iroha is a straightforward distributed ledger technology, inspired by the Japanese Kaizen principle — eliminate excessiveness. Users can create and manage their assets via Iroha commands. Iroha is written using C++, Protobuf, Boost and GTest. There are no smart contracts in Iroha.

Introduction

Hyperledger Burrow provides a modular blockchain client with the possibility to change different parts of the system. One modular piece is a permissioned smart contract engine, partially developed to the specification of the Ethereum Virtual Machine (EVM). Burrow is developed using language Go.

The main purpose of this internship was to integrate EVM from Hyperledger Burrow into Hyperledger Iroha. Since Ethereum is de facto the most known platform for smart contract development, the integration will let Ethereum developers use Iroha as a new blockchain in distributed applications.

Project Components

The starting point was identifying the main components the project needed to address: 

  • First of all, there should be a way to pass data (such as Ethereum bytecode, caller and callee) from Hyperledger Iroha to Hyperledger Burrow EVM. For this purpose, a new command to Iroha has to be added.
  • Another issue is to connect Golang and C++ code to bind Iroha and EVM. 
  • The next step is to implement a special Burrow API to store EVM accounts data in Iroha.
  • The final requirement is new functionality testing.

Challenges

One of the challenges was to get deeper into the codebases of Hyperledger Burrow and Hyperledger Iroha. Existing integration examples of Burrow EVM to Fabric and Sawtooth gave me a nice understanding of what to do. From the Iroha side, Andrei Lebedev led me through the Iroha source code.

Results

With this information, I was able to develop a new command EngineCall. I made a wrapper using CGO (special go compiler mode that generates C library from Go source code) that Iroha uses to call Burrow EVM. Now an implementation of Burrow EVM API can send requests to Iroha for modification of its state via Protobuf messages. Every EVM account is stored in a technical account in Iroha. EVM account storage is emulated in the technical account details (which is key-value storage). All of this work was QA’d by writing and completing module and integration testing.

What comes next

More features can be added to this  integration. The first one is web3 interface implementation, which  will call remote EVM instance or use a local one. The next possible improvement is to add permissions to an Iroha account that represents an EVM account. Also, the current support of Burrow EVM in Iroha is not full, since there is no catching of EVM logs.

For more on this project, please read my full report.

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 https://allarewelcomehere.us/ for Hyperledger

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

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.

Successes:

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

Successes:

  • 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.

Successes:

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.

Successes:

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.

Successes:

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: info@hyperledger.org.

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!