Hyperledger Besu

This release includes new versioning and mainnet-focused advancements

The Hyperledger Besu team is excited to announce today’s Hyperledger Besu 20.10.0 release. 

You might have noticed that the versioning for this quarterly release is a little different than prior Hyperledger Besu releases. The Hyperledger Besu community recently decided to switch its versioning to calendar versioning, known as CalVer. Instead of the historic semantic versioning used by Besu and other Hyperledger projects, the Besu team decided to use CalVer moving forward. In all future releases, you will notice the project versions will start with the year and month (YY.M) of the last major release candidate, followed by a patch number for incremental releases, which results in a YY.M.patch, or 20.10.0 for this release. The Besu team believes this will better track the project’s changes and it follows many other successful open source projects that use Calver, including Splunk and Ubuntu.

Check out the old vs. new versioning in the table below.

Now to share what is included in the latest release. The Besu community is excited about the continued advancements of the Hyperledger Besu project featured in this release. 

A few highlights for this release include:

• Flexible Privacy Group Performance tests
• Mainnet Support Work, including preparing for the Berlin Network Upgrade and EIP-1559 support

Flexible Privacy Group Performance Tests

The ‘add and remove members for privacy groups’ feature was released earlier this year as an early access feature. With privacy groups in Hyperledger Besu, you can add and remove members from a privacy group, creating an improved user experience for private transactions. Privacy groups are built using a private transaction manager, called Orion, to help send private transactions in a permissioned network.

In the 20.10.0 version, privacy groups have been further improved to ensure robust performance. The team performed various tests to ensure the flexible privacy group feature is not a performance bottleneck. 

Flexible privacy groups are now supported when using multi-tenancy. In addition, the team created more library examples and documentation of use cases. 

Mainnet Support Work

Since Hyperledger Besu runs on the public Ethereum mainnet, the Besu community also sought to improve its public chain settings. As a reminder, Hyperledger Besu is the only Hyperledger project that runs on a public chain and in permissioned network settings. This optionality makes it unique and a popular project for trying out both public chain or permissioned network options for a use case.

Berlin Network Upgrade

In this release, the community prioritized work ensuring Hyperledger Besu is ready for the next Ethereum hard fork, Berlin, scheduled to happen in the next few months. You can learn more about Ethereum’s hard forks here. For the Berlin hard fork, the Besu and Ethereum communities are broadly focused on implementing EIPs, or Ethereum Improvement Proposals, that will help with the UX of the Ethereum 2.0 deposit contract, add new functionality to the EVM and change gas costs to reflect their execution time more accurately. 

EIP-1559

In addition to its work on the Berlin network upgrade, the Besu team has also been leading efforts to implement EIP-1559. EIP-1559 is a highly anticipated upgrade to Ethereum’s transaction fee market. This EIP’s goal is to make the Ethereum fee market more efficient. You can read more about the current status of EIP-1559 here in a post written by Tim Beiko, one of our Besu team members.

What’s Next?

The Hyperledger Besu community remains committed to improving its project and making it fit for production blockchain use cases. Watch for new features addressing node hibernation and Bonsai Tries database improvements in our next quarterly release.

Get Involved

Download the latest version of Hyperledger Besu here.

Interested in learning more or curious on how to get started with Hyperledger Besu? Check out the Besu docs, view the tutorials, visit the wiki, or take a look at some open issues in GitHub. 

Stay tuned to hear more about our work in Ethereum and Hyperledger and about how Hyperledger Besu is continuing to lead the enterprise blockchain space.

As we pointed out in part I of this series, the days when hardware and software were separate entities are long gone. Along with the ongoing worldwide digitization and digitalization, the integration between the virtual and physical worlds is getting stronger – making the Internet of Things (IoT) a real thing. Going further, we can leverage blockchain features like data immutability, distributed character, and exploit the smart contracts it offers to connect it with IoT applications to build a trusted and all-inclusive solution. We’ve created a two-part tutorial to showcase how to deploy and connect all the pieces. In part I of our tutorial, we set up a private Hyperledger Besu network and configured a Raspberry Pi to sign transactions with its own keys. We used this to write a Python program, hosted on Raspberry, sending Ether to other participants of the network. The final solution used quite a broad technological stack: Terraform, Amazon Web Services, MetaMask, and, finally, Raspberry Pi. In part II, we don’t want to lower the bar, so here we add some extra technological stack on the top of what we had.  

Scenario 

Let us consider a contract between a supplier and a buyer. They both agree on some delivery time, conditions, pick up and drop off locations, and, of course, the price the buyer is willing to pay. Among the conditions, they can agree on some penalty for delayed delivery or that the parcel couldn’t be exposed to a temperature higher than some threshold longer than X minutes. While the delivery time can be verified, the monitoring of the second condition is not that easy to verify. Even if we suspect that the temperature threshold has been exceeded (because, for example, the delivered food is spoiled), how can we prove that transport conditions were inappropriate?

In part II, Ratified Smart Contract for Constrained Delivery with Oraclized Data, we created an automated solution covering the entire supply process, including:

• publishing the delivery offer with specified conditions, 
• acceptance of the conditions by contractor, 
• starting the delivery by an authorized person (using personalized hardware signature), 
• monitoring the delivery temperature and contract voiding conditions, confirming the delivery, and 
• calculating the final payment for the supplier. 

To achieve this, we take advantage of the Hyperledger Besu network that was deployed in part I and now write a smart contract on the top of it that handles the delivery operations.

Overview

In the full tutorial, we detail all the steps to designing a smart contract for the presented delivery use case. To do this, we use web-based Remix IDE as an environment for contract development while the contract itself is written in the Vyper language. We opted for this pythonic language for the simplicity and readability of its code. Once the contract is developed, we show how to test the deployment to verify that all the functionalities are working correctly.

Further, we go through the steps required to use the hardware signature (contained in the smart card) to sign the transaction, to configure the temperature sensor and measure the current value of the temperature, and, finally, to integrate all the parts into one program that will serve as “delivery starter” and “temperature measurement provider.”

Our tutorial covers a very concrete use case, and it is only the tip of the iceberg. There’s much more, and the possibilities are endless. We hope that this tutorial will give you the thrill to build your own blockchain application. If you have any questions, feel free to contact us!

The days when hardware and software were separate entities are long gone. Along with the ongoing worldwide digitization and digitalization, the integration between the virtual and physical worlds is getting stronger – making the Internet of Things (IoT) a real thing. Going further, we can leverage blockchain features like data immutability, distributed character, and exploit the smart contracts it offers to connect it with IoT applications to build a trusted and all-inclusive solution.

Of course, step one is to build out a network to support such solutions. We’ve created a two-part tutorial to showcase how to deploy and connect all the pieces. In part I, we discuss the deployment of a private Hyperledger Besu network on Amazon Web Services (AWS) and the minimum configuration of a Raspberry Pi to interact with the deployed network. In part II, we will do a more complex configuration of a Raspberry Pi, making it a physical instance of an externally owned account with an ability to send hardware signed transactions and interact with smart contracts as both signature and measurements provider.

Our goal with part I, Deployment of Private Hyperledger Besu on AWS with Hardware Layer for Externally Owned Account, is to provide an introduction to the topic as well as guidance for getting started.  The tutorial details how to connect a hardware node to the network and configure it to interact with the blockchain. In this regard, it can be treated as a blockchain enabler for IoT solutions.

For a quick overview of the setup, see below. The entire methodology and codebase can be found here.

Setting up the blockchain, accounts and hardware node

First of all, a Hyperledger Besu network should be hosted. For our scenario, we show how to provision a network of four Hyperledger Besu nodes, running an IBFT2.0 consensus, and deployed on AWS. If, like us, you’re not a fan of dull and repetitive tasks, you can use terraform to set the scene instead of manually creating all four nodes.

For general-purpose account management, we use MetaMask – a browser extension that helps to create and manage Ethereum blockchain identities. In the tutorial, we present how to connect to our private, test network, and create a new account – used as an identifier and signature of Raspberry Pi.

Next, we show how to configure Raspberry Pi to:

• hold its own identity given as a private-public key pair
• become a part of our private blockchain network
• sign transactions using its own keys and send ether to other nodes

These steps show how to build a hardware-inclusive blockchain network

Next steps

Getting a handle on the basic ideas and configurations that have to be done in order to have a private Hyperledger Besu blockchain with a hardware node attached is only the beginning. In Part II of our tutorial, we will go beyond merely sending some virtual (and, in fact, worthless) tokens between virtual accounts. We’ll take advantage of the functionalities offered by smart contracts and dive into a business case where the hardware node serves as a trusted source of measurements used to invalidate or finalize a contract. Stay tuned!

The latest release of Hyperledger Besu is now available for download. The 1.5 version offers better performance and improved enterprise functionality.

In February, Hyperledger Besu 1.4 was released. Since then, we’ve been concentrating on continuing to bring Hyperledger Besu users the best experience among enterprise blockchain clients. Today, we’re announcing the release of Hyperledger Besu 1.5, which brings with it significant improvements to performance, usability, and privacy.

Hyperledger Besu 1.5 comes with primary upgrades that focus on enterprise requirements.

PRIMARY UPGRADES: HYPERLEDGER BESU 1.5

Privacy

The most recent set of privacy enhancements include:

• Ability to add and remove members from privacy groups.
• Filters and subscriptions for private contracts.
• Web3j and web3js support for private transactions and filters.

Read more about privacy enhancements in Besu 1.5.

Performance

• Added native encryption libraries to provide optimization optionality
• EVM execution improvements
• Improved logs querying performance 
• Improved transactions per second (TPS) performance by 33%

Look for more details on the improvements in an upcoming blog post.

Parity Tracing APIs

In the Hyperledger Besu 1.4 upgrade, we introduced new tracing APIs as early access features. Since then, we’ve ensured they worked smoothly across every edge case we could find and are now ready to suggest using them by default.

“Hands-on with Hyperledger Besu” is a guided introduction to Besu, hosted by some of the people who build, maintain, train, and work with the Ethereum client. The program is a four-week, detailed introduction to building with the client. Sign up and start learning about Besu today.

EARLY ACCESS FEATURES

The following features are still under active development, may not be documented and have unstable APIs. Nevertheless, because community feedback is valuable to their development, we want to share them as “early access” features. All feedback and questions are welcomed in our contributor chat. 

EIP-1559 Support
Hyperledger Besu has been one of the clients leading the implementation of EIP-1559, a major upgrade to Ethereum’s transaction fee market. The upgrade will allow better transaction fee estimation and faster transaction inclusion in periods of high demand on the network.  

Ephemeral Testnet YOLO
In preparation for the next network upgrade, Berlin, an ephemeral testnet called YOLO was launched with two new EIPs enabled: EIP-2315, which adds subroutines to the EVM, and EIP-2537, which introduces a new precompile for the BLS12-381 curve.

While the network is currently down (its status can be seen at https://yolonet.xyz/) Hyperledger Besu is YOLO-compatible. 

Download the latest version of Hyperledger Besu here.

Interested in learning more or curious on how to get started with Hyperledger Besu? Check out the Besu docs, view the tutorials, visit the wiki, or take a look at some open issues in GitHub. 

Those looking to interact one on one with Besu developers and contributors can join the conversation on Rocketchat at #besu, or join our regular contributor calls.

Introduction

The Hyperledger Besu project underwent a security audit in Q1 of this year. This is the second security audit for the codebase. The codebase had a security audit performed in 2018 prior to the initial launch of the codebase (and when it was named Pantheon). The Besu team conducted another security audit because there have been many new features and functionality added to the codebase since its original security audit. Ensuring security best practices are used in the codebase is a priority for the Besu team.

The Hyperledger Besu team was pleased to partner with Tevora on this security audit and work with them closely on their findings. Tevora’s approach to auditing the codebase included: 

1. Reconnaissance
2. Threat Mapping
3. Known Vulnerability Identification
4. Exploitation
5. Post-Exploitation
6. Reporting

Key Findings and How the Hyperledger Besu Team Addressed Them

When conducting a code audit, it is important to address each finding to help improve the codebase and ensure it meets security expectations. While there were no critical or high issues found in the codebase, there were a couple of medium risk issues that were identified. 

Below is an outline of the issues and the team’s steps to address them:

1) GraphQL Configuration: 

• Summary of Finding: The Hyperledger Besu client includes a configurable GraphQL endpoint for data queries. Tevora discovered the GraphQL implementation did not adequately protect against malicious queries. If the GraphQL endpoint is served on a routable network interface (a non-default configuration), an attacker could craft a query that exhausts the node’s system resources. This attack would cause over utilization of system resources and the affected node would be disconnected from its peers. A network configured to expose GraphQL endpoints on Besu clients would be at risk of DoS based blockchain attacks.
• How Team Addressed it: The Besu team immediately began query complexity metering, preventing query loops from forming. Also, as members of the Ethereum community, the team noticed this was a flaw in other Ethereum clients with a GraphQL endpoint so it informed the community so other clients could also implement the appropriate fix. You can find this item resolved in Hyperledger Besu’s 1.4.3 Release.

2) Key Storage

• Summary of Finding: Besu nodes store the node private key on the host filesystem. Compromise of this key would not lead to a direct loss of funds; however, it would cause a loss of trust in the affected node’s communications. 
• How Team Addressed It: By design, the Hyperledger Besu team does not store account keys like other Ethereum nodes can be configured to do. This mitigates account takeover attacks. The team is continuing to evaluate how to encourage adoption of best practices for storing node private keys in Besu, including the use of HSMs to store node keys. 

Hyperledger’s Commitment to Security of its Projects

Part of Hyperledger’s role with all of its projects is to ensure security best practices are followed. Activities Hyperledger enforces with its projects to ensure secure codebases include performing security audits, running license checks regularly, and facilitating a security task force with representatives from all project teams. Hyperledger is committed to the security of its projects, and it continues to be diligent about implementing security best practices in all of its projects. 

The Hyperledger Besu team is equally diligent about ensuring security in its codebase, and we believe this security audit was an important step in ensuring its a safe and secure codebase for the community to build on.

“The Hyperledger staff and Besu team were outstanding to work with! Hyperledger takes the security of its projects very seriously and it shows. The response to our primary finding was impressive, with a fix implemented by the Besu team within hours. They are definitely leading by example in the security maturity of open-source software projects.” – Brian Sullivan Information Security Consultant at Tevora.

If you would like to access the full report, you can go here.

The Hyperledger Besu team is excited to announce Hyperledger’s Technical Steering Committee (TSC) members voted to graduate the project from incubation to active status. The Hyperledger Besu team believes this decision demonstrates the strength of the Besu project and the active community supporting it. With this announcement, Hyperledger Besu joins Fabric, Indy, Sawtooth, and Iroha as projects with active status in the Hyperledger greenhouse and the only Ethereum project to be granted active status.

Since Hyperledger Besu joined Hyperledger in August 2019 under incubation, the Besu team has remained focused on growing Besu’s developer base and making it an inclusive community. The Besu team has had active participation from a number of organizations, including several that have become maintainers of the project. Some of these organizations include ConsenSys, Chainsafe, Web3Labs, Machine Consultancy, Everis, ETC Labs, and MyEtherWallet. Each of these organizations provides critical code to improve and grow the featuresets of the codebase. For example, Chainsafe and ETC Labs focus on maintaining Besu syncing with Ethereum Classic networks, whileWeb3Labs builds the privacy feature. These critical contributions help make Besu the high quality project it is.

Hyperledger Besu’s team has been focused on developing the project to be a leading client for the public Ethereum mainnet as well as in permissioned consortium settings. The Besu team has built enterprise-grade features, including privacy, permissioning, and consensus mechanisms. The optionality of running Besu in a public chain or permissioned chain setting is part of its radical appeal with community members. Now that Besu is an active project, we plan on continuing to encourage enterprises, individual contributors, and application developers alike to explore and support Besu to ensure it continues to evolve to fit each of their purposes. 

What Does Active Status Mean?

By voting for Hyperledger Besu to be granted active status, the Technical Steering Committee acknowledges that Besu meets all of the Incubation Exit Criteria, including legal requirements, high-quality documentation, consistent tooling usage, and diversity of community requirements. Each of these requirements helps demonstrate a project is a safe, welcoming, and vibrant space for community members to join and contribute. By being designated as an active project, Besu is demonstrating that it is meeting Hyperledger’s highest standards for a project.

What is next for Hyperledger Besu?

The next quarterly release, v1.5, is scheduled for mid 2020 and will include our most ambitious features to date. Some features include: 

• Performance improvements, including block propagation, block product and validation, transaction pool management, and JSON RPC query response time. 
• Privacy Improvements
• Beam Sync Early Access
• Mining Support

Additionally, the Besu team is focused on building out performance metrics using another Hyperledger project, Hyperledger Caliper. The team is looking forward to publishing those results soon.

Hyperledger Besu continues to sit at the intersection of Hyperledger and Ethereum and hopes to continue to grow both communities. We think graduating to Active status is a giant step forward in the project’s maturity.

Do you want to get involved in Hyperledger Besu?

Those looking to interact one on one with Besu developers and contributors can join the conversation on RocketChat at #besu, or join our bi-weekly contributor calls.

Interested in learning more, or curious on how to get started with Besu? 

• Check out the Besu documentation,
• Visit the wiki, or 
• Take a look at some open issues in GitHub.