Category

Hyperledger Besu

Aug 06
Love0

Hyperledger Besu 1.5 Performance Enhancements

By Blog, Hyperledger Besu

Overview

Over the past quarter, the Hyperledger Besu team has been hard at work improving performance across many fronts, from adding support for native encryption libraries to tuning our EVM execution code, experimenting with different different JVMs and building more robust benchmarking infrastructure. This has resulted in performance improvements across sync times, transactions per second and requests per second.

We are excited to share these results as well as the details of future work we have planned around stability and performance. 

Native Encryption Libraries

When writing Hyperledger Besu (back when it was called Pantheon), we had a principle that the code had to be correct first. If the execution of a block was wrong, it didn’t matter how fast it was because we would fall out of consensus. Combine this with the complexity and specificity of encryption software, and any attempts to optimize performance could have a destructive effect on the whole project if we got even one corner case wrong.  To avoid this, we used mostly pre-existing Java-based cryptography implementations.

Starting in Besu 1.4.2, we shifted our model to use external non-Java or “native” encryption (specifically, external libraries called through native OS calling conventions). This opened us up to a large swath of optimized implementations. The first library we added was secp256k1(AKA the Bitcoin Elliptic Curve). This library is heavily used throughout Ethereum, often invoked multiple times in each transaction. The implementation we use is Bitcoin Core’s optimized library (https://github.com/bitcoin-core/secp256k1). It is mostly written in C but also features a handwritten assembly loop in the “hottest” parts of the calculation. The second library we use is for the altbn128 curve, a precompiled contract that has seen a significant uptick in use as Eth2 testnets have started popping up.  

For now, Hyperledger Besu supports both the native versions and pure Java versions, so they are still usable if a native library isn’t compiled for your target device. We split these specific libraries out into a standalone package to simplify the process of building and packaging them for the various platforms on which they must run. They can be accessed on GitHub (https://github.com/hyperledger/besu-native).

This change has led to a noticeable speedup in fast syncing times (and transactions per second, but more on that below!), especially for networks where secp256k1 verification takes a significant part of the sync time, such as testnets or networks with lots of empty blocks. For example, this change reduced our fast sync time on Goerli by 13%, from 92 minutes (Besu 1.4.0) to 80 minutes (Besu 1.5 RC2). The full sync speedup (processing every transaction and storing every block state) was even larger: a 1,571% improvement, from just over six days (Besu 1.4.0) to just over nine hours (Besu 1.5.0)!

EVM Implementation Optimizations

Another place we improved performance is in our pure Java implementation of the Ethereum Virtual Machine (EVM).  There are three significant improvements of note:

  1. We simplified our exceptional halt detection with simpler language constructs, 
  2. We flattened out a series of three calls into one call and removed a lot of duplicate calculations along the way, and 
  3. We adopted some low-level optimizations that we upstreamed to Apache Tuweni 1.1.

To determine where we needed to perform these optimizations, we used a combination of a handwritten tool and off-the-shelf profilers. The Besu community uses a mix of the VisualVM, Java Flight Recorder/Mission Control, and YourKit profilers (provided to Besu under their Open Source Licencing program – https://github.com/hyperledger/besu/blob/master/README.md#special-thanks).

We then pointed those profilers at a tool we built called “EVMTool” https://github.com/hyperledger/besu/tree/master/ethereum/evmtool) that was initially written to support cross-client fuzz testing of EVM smart contracts. With very slight modifications, we were able to turn it into a repeated EVM executor. Setting the repetitions up to an absurdly high number, we could point our profiler of choice at the EVM and get some longer term performance numbers. This revealed a large amount of unneeded copying of byte arrays, duplicate calculations, and inefficient call structures.

When compared to 1.4.2, our EVM evaluations (i.e., “gas per second”) have now improved from 78-220% depending on the specific contract structure and state size, with all but one benchmark showing over 100% improvement. While we don’t have raw measurements, we suspect this change is also partially responsible for the sync times improvements mentioned earlier.

GraalVM

Since Besu runs on top of Java, we have access to the full range of Java Virtual Machines.  Previously, we have recommended OpenJDK 11 as it is a known and stable version of the JVM with many downstream distributions (Corretto, AdoptOpenJDK, Zulu).

Recently we’ve started testing with GraalVM (https://www.graalvm.org/), a JVM implementation that is Oracle’s successor to the HotSpot JVM that’s been at the core of Java for over two decades. It is also at the core of several new projects such as Micronaut and Quarkus. While it has lots of fancy features (such as Ruby support, experimental WASM support, native image generation, AOT compilation), it offers several significant performance advantages while remaining a drop in replacement for the JDK. 

Just dropping in GraalVM Community Edition 20.1 without any additional JVM tuning resulted in a 14% increase in our TPS numbers, from roughly 350 to 400 smart contract calls per second.  All the other fancy features it will bring along in the future is just icing on the cake.

Transactions Per Second (TPS)

As mentioned in the prior section, we have seen great improvement to Hyperledger Besu’s TPS numbers in a private chain setting. All in all, our efforts have moved us from 300 TPS on Besu 1.4.0 to 350 for Besu 1.5 and 400 TPS when  using GraalVM. In order to get repeatable measurements for our TPS improvements, we worked with Hyperledger Caliper, another project under the Hyperledger umbrella to benchmark our numbers across various Besu versions. 

The network we used was composed of five nodes. Four of these were validators, and the only non-validator node was used as an RPC node. One of the validator nodes was designated for use as a bootnode.

The network used IBFT 2.0 as its consensus algorithm with a two second block time, an epoch length of 30,000, and a 10 second request timeout value. A very high block gas limit of 672,000,000 was set, and blocks were monitored to be sure that this gas limit was not saturated. The function called to benchmark TPS numbers was a “register” transaction from one of LACChain’s registry contracts. 

All of this was set up using Ansible playbooks we had developed to launch Besu instances. 

Requests Per Second (RPS) 

Another area where we saw notable improvements was in Hyperledger Besu’s handling of JSON RPC requests. Using ethspam (https://github.com/shazow/ethspam), a library that generates realistic read-only JSON RPC queries to bombard a node with, we saw an 64% improvement in Besu’s request-per-second performance. On version 1.4.0, when sent 100,000 requests, Besu could answer on average 5242.39 per second. Using the 1.5.0 release, that number was up to 8632.75. Even better results were obtained using GraalVM on Besu 1.5.0, with RPS reaching 8988.59, an increase of 71% over the 1.4.0 release!

For our RPS benchmarks, we used Versus (https://github.com/INFURA/versus), a tool developed by Infura, which can compare the RPS performance across various Ethereum node implementations and, of course, Infura itself. 

Stay Tuned

While the Hyperledger Besu team is pleased with the progress made, we are continuing to focus on performance and, over the coming months, will make it one of our main priorities for the codebase. Specifically, along with continuing to fine tune various parts of the codebase, we will begin major refactors of two areas of the codebase: the peer-to-peer (P2P) layer and the database.

Besu’s P2P layer has grown and been extended significantly over the past few releases with the addition of privacy, permissioning and various other improvements. It is now time to take a step back to redesign it so that it is maximally stable and performs well. We’ll also be looking to add even more new functionality, such as enabling the new eth/65 version of the eth networking protocol.

On the database side, the Ethereum mainnet’s growing state size has made database access reading and writing state  a major performance bottleneck. Over the next few months, the Besu team will be experimenting with a new database format that is designed to be more performant for networks with large state sizes. The first “feature” coming out of this work should enable users to more easily backup and restore their network’s state, providing an offline disaster recovery backup.

Stay tuned!

Download Hyperledger Besu
Join the Conversation about Hyperledger Besu

Aug 03
Love0

IoT Deployment Tutorial Part II: Deploying Hyperledger Besu to Support Hardware Layer

By Blog, Hyperledger Besu

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!

Jul 31
Love0

IoT Deployment Tutorial Part I: Deploying Hyperledger Besu to Support Hardware Layer

By Blog, Hyperledger Besu

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!

Jul 27
Love0

Hyperledger-powered Internet of Things applications

By Blog, Hyperledger Besu, Hyperledger Fabric

The Internet of Things (IoT) is driving an array of new distributed technology models and applications. The potential for pairing IoT and blockchain is increasingly a hot topic. This month, as part of #HypereldgerIoT, we take a look at some productions examples where the technologies are already working together. 

Read on for more about Hyperledger-powered IoT applications at work across a mix of use cases:

Norwegian Seafood Traceability Network

A recently launched Norwegian seafood traceability network leverages IBM Blockchain, which is built on Hyperledger Fabric, to share supply chain data throughout Norway’s seafood industry. The goal is to provide safer, better seafood to consumers worldwide. The network uses IoT sensors to report key environmental parameters. Starting with aquaculture, the sensors will monitor and report on the conditions required to produce high quality fish, such as water temperature, oxygen levels, and water quality, and when the fish are transported, IoT sensors will track and report factors such as the length of journey, temperature, and movement in transit. Several Norwegian seafood companies are now in the process of putting data onto the network.

My Sensor

My Sensor is an IoT device developed by Movistar that detects minute concentrations of Radon gas in the surroundings. Radon is a naturally occurring gas which may build up in your property in enclosed spaces, particularly in the basement and on lower floors. If Radon levels exceed certain thresholds, it can affect people’s health.

Leveraging Telefonica’s TrustOS MQTT module, My Sensor tracks and certifies the historical series of Radon gas concentration. The user can get a certification with full proof that guarantees the concentration did not exceed the thresholds in a period or did it during n measurements in a raw. The sensor sent the measurements through TrustOS to a Hyperledger Fabric network where some chaincodes are monitoring and certifying that the measures are in the expected range (or eventually are out of the range). The network itself certifies the series of measurements and anyone can verify it without any doubt avoiding the participation of a trusted expert third party.

VideoCoin Network

The VideoCoin Network is a decentralised video infrastructure that provides developers with video processing services that are simple to use and inexpensive compared to centralised providers. Developed by the VideoCoin Development Association Ltd. and implemented by services provider Live Planet, Inc., the VideoCoin Network runs on the Public Mint platform and is enabled by a native protocol token, the VideoCoin (VID). 

Powered by a large-scale, distributed video infrastructure, the VideoCoin Network marshals under-utilised computing resources from around the world, including IoT devices, to revolutionise enterprise-grade video services with blockchain technology. 

“Public Mint provides a revolutionary and first of its kind money system that lets us use real USD as programmable currency  allowing us to pay tens of thousands of participants on our network. This satisfies our needs to pay anyone whether they’re running a datacenter or a Raspberry Pi IoT device.” – Devadutta Ghat, CTO at LivePlanet Inc.

Backed by Hyperledger Besu distributed ledger technology, Public Mint fosters a marketplace of Smart Services that can run on top of Public Mint’s programmable fiat platform. Anyone can use the current Smart Services or build new ones, using Public Mint’s Open APIs and open-source wallet.

IoT devices integrity service

This service is an extra feature of the Hyperledger Fabric-based TrustOS product. A part of Telefonica’s TrustOS software, this library is provided to be executed by IoT devices in the secure boot. It adds as an additional HTTP header including a checksum of the secure boot for each request sent by the devices.

The first time a device sends this header, TrustOS creates an asset to track any variation in the device behaviour (including besides detecting new checksum, an IA assessing pace and frequency of the requests). Any request is registered and, if something unexpected is detected, a warning is triggered to quickly act over the affected device.

This service can’t avoid unauthorized tampering or unexpected updates but helps in identifying problems earlier and without any doubt. The result: it adds extra trustworthiness-proof beyond KPII.

Join the conversation about blockchain-based IoT applications with #HyperledgerIoT this month on social channels. 

Cover image by Tumisu from Pixabay

Jul 16
Love0

Announcing Hyperledger Besu 1.5: Available Now

By Blog, Hyperledger Besu

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.

May 28
Love0

Interoperability and Integration Developments in the Hyperledger Community

By Blog, Hyperledger Aries, Hyperledger Besu, Hyperledger Cactus, Hyperledger Fabric, Hyperledger Grid, Hyperledger Indy, Hyperledger Sawtooth

Interoperability and integration are top of mind issues across the blockchain space right now. From new projects to new solutions, the Hyperledger community is taking on the challenges of cross-chain and cross application communication and data flow. 

Here are some of the most recent #HyperledgerInterop developments from across the community.

New Project – Hyperledger Cactus

The newly announced Hyperledger Cactus is a blockchain integration tool designed to allow users to securely integrate different blockchains. This pluggable architecture helps enable the execution of ledger operations across multiple blockchain ledgers, including Hyperledger Besu, Hyperledger Fabric, Corda, and Quorum available today, with the aim of developers continually adding support for new blockchains in the future. 

 Cactus started as a Hyperledger Labs project six months ago and has attracted significant attention and become a locus of collaboration between developers from teams at Accenture and Fujitsu, and dozens of others working on DLT platforms both inside and outside Hyperledger.

Member applications

  • Smart Block Laboratory built the Hyperledger Fabric-powered distributed register Cryptoenter, blockchain infrastructure for digital banking that unites banks into a single digital space for transmitting financial messages and brings a new level of interaction to the financial market. The platform is designed for p2p interaction between consumers of financial services, safe execution of payment transactions with cryptocurrencies, fiat currencies and cryptocurrencies, user interaction within a social network for investors / distributed crowdfunding platform.

    The basis of the platform is the Rubicon Blockchain, a cloud platform for the blockchain economy, built on Hyperledger Fabric. Cryptoenter has a dual security system: at the Hyperledger blockchain network level and at the Rubicon Blockchain (also based on Hyperledger Fabric) network level. The solution uses an SRP authentication system. TLS (transport layer security) protocol based on SSL (Secure Sockets Layer) protocol is also included. This dual security system allows Cryptoenter to authenticate the person who signed the message, control message integrity, protect the message from fakes and prove the authorship of the person who signed the message.

Technical talks from Hyperledger Global Forum

Nathan George from the Sovrin Foundation offers his take on “Standards and Interoperability for Identity”

 Identity platforms have made significant advances leveraging blockchain technology and standards developed at Hyperledger. In his talk, Nathan covers the latest in trusted information flows and the standards being incubated to promote interoperability and create network effects across multiple blockchains and identity platforms.

Key topics include the advancements incubated in Hyperledger Indy, Hyperledger Aries, the W3C Credentials Community Group and at the Decentralized Identity Foundation for Verifiable Credentials, Decentralized Identifiers (DIDs), DID Communications, Identity Hubs, Authentication, and the data models that power them.

Panelists Rich Meszaros and Sarah Banks from Accenture, Melanie Nuce from GS1 US, David Cecchi for Cargill and Patrick Erichsen from Target discuss “Business Interoperability – The Key to Supply Chain Traceability”

Technology such as blockchain has the power to solve complex challenges and achieve improved supply chain traceability. In order to tap into this powerful technology, interoperability, enabled by robust data and transaction standards, are a must! Segments of the supply chain, such as the food industry, have made significant progress leveraging data standards to support food safety and product transparency use cases. The panelists discuss their companies’ work on improved supply chain traceability, the importance of standards and the role business interoperability plays in accelerating the success of new technologies like blockchain. 

Join the conversation about blockchain-based identity technologies and solutions with #HyperledgerInterop this month on social channels.

Cover image by Clker-Free-Vector-Images from Pixabay

Apr 15
Love0

Hyperledger Besu Security Audit 2020

By Blog, Hyperledger Besu

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.

Mar 30
Love0

Hyperledger Besu Graduates to Active Status

By Blog, Hyperledger Besu

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? 

Feb 27
Love0

Announcing Hyperledger Besu v1.4 – Available Now

By Blog, Hyperledger Besu

Learn about the improved enterprise functionality and performance in the latest release of Hyperledger’s first and only public chain-compatible Ethereum client.

Evolution of Hyperledger Besu

Hyperledger Besu was contributed to the Hyperledger organization in August of 2019 as the sole Ethereum blockchain client. Since then several notable improvements have been made that have continued to bridge the gap between permissioned and public chains.

The v1.3 release of Besu released in October 2019 included state pruning, allowing organizations to save money on storage costs by reducing storage size in a node. It also offers relational database support allowing customers with local storage requirements to choose from a selection of DB storage options through transaction manager, Orion. Besu v1.3 was also upgraded to be compatible with the “Istanbul Hard Fork Upgrade,” which took place earlier this year.

The Besu team is pleased to announce the next major release, Hyperledger Besu v1.4, which launched  February 26, 2020, and includes a number of much-anticipated features focusing on performance and enterprise-driven functionality such as:

  • Plugin APIs
  • New tracing APIs
  • Multi-Tenancy
  • Advanced Key Management
  • End-to-End TLS support for incoming and outgoing RPC endpoints

Click here to download Hyperledger Besu 1.4.

Key Features in 1.4

Plugin APIs 

Hyperledger Besu v1.4 also exposes a plugin API, allowing anyone to write custom plugins for Besu and enabling users to take data from any Besu network, public or permissioned, and feed it into the rest of their applications and systems easily. The API exposes data about the following components:

  • Blocks
  • Balances
  • Transactions
  • Smart Contracts
  • Execution Results
  • Logs 
  • Syncing State

In the future, along with more data being exposed via the API, users can expect Besu to compartmentalize key supporting services, eventually allowing them to be swapped via a plugin.

New tracing APIs

As part of its 1.4 release, Besu will now support a new tracing API: trace_replayBlockTransaction. The addition of this API is a step towards Besu being fully compatible with all Ethereum clients on the network. For example, it enables the use of Parity-style traces, which are a more concise alternative to the current debug_* APIs in Besu.

Specifically, the vmTrace option provides an operation-by-operation trace of EVM execution, the stateDiff option highlights the differences in account and storage state before and after the transaction and the trace option details every type and result of calls to account and contracts.

More Parity-style traces will soon be added to Besu as well. The two next ones scheduled are trace_block and trace_transaction. 

Multi-Tenancy – Secure Private Transactions in a shared environment 

Hyperledger Besu v1.4 will be able to run in a “Multi-tenant environment,” allowing a number of users to use the same Ethereum node to connect to the network. The Hyperledger Besu multi-tenancy support enables a much wider user base to make use of the blockchain technology, reducing the barriers to entry associated with learning, upskilling, and additional costs associated with deploying  blockchain.

Support for authenticated API access will also be given, allowing hosts custom control on who to grant access to, depending on the user’s  need. This coupled with Orion, the open-sourced, Apache 2.0 licensed private transaction manager, enables private transactions to take place all while ensuring only the correct recipient can access the data. Through the use of JWT tokens, a user identity is tied to a privacy identity, validating every API call to ensure the user is part of the privacy group before any data is revealed.

Advanced Key Management

The release of Hyperledger Besu v1.4 also includes additional key management functionality through EthSigner. By design, Hyperledger Besu does not allow keys to be stored in the client or node. You have to use an external key manager. In this release, multi-Key support has been added. This support allows for a number of private keys to be securely stored in vaults accessible only when needed to be used for signing a transaction.

This advanced option adds the capability to select the correct key based on the details of transactions, regardless of where those keys are stored, allowing for rotation of keys and further security. 

End-to-end encryption with TLS 

While blockchain delivers significant security benefits, encryption is still critical across the transaction lifecycle. Hyperledger Besu v1.4 will offer end to-end encryption with TLS, meaning all communication from the generation of the private transaction to its signature using private keys stored in secure vaults (e.g., Hashicorp Keyvault), transmission through private transaction managers, and arriving at another node is encrypted. 

What’s Next 

The next quarterly release, v1.5, is scheduled for mid 2020 and will include our most ambitious features to date. In the meantime, Hyperledger Besu is happy to sit at the intersection of the Hyperledger and Ethereum communities and continue to grow its contributor network.  

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.

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

For those attending Hyperledger Global Forum, several project maintainers and contributors will also be present and speaking at the event and would love to chat with you. 

This blog was written by PegaSys Digital Marketing Specialist, Gina Rubino, with contributions from PegaSys Product Managers Tim Beiko and Arash Mahboubi. 

Jan 28
Love0

How Hyperledger Besu Will Help Solve the Pharmaceutical Waste Problem in the U.S.

By Blog, Healthcare, Hyperledger Besu

The problem of surplus medication is getting increasingly serious. Each year, tons of prescription drugs remain unused in clinics, assisted living facilities, and at individual patients’ homes. Often, the law demands that any unused medications be destroyed, which results in a whole complex set of problems. 

On the one hand, about $2 billion worth of prescription drugs are wasted every year. On the other hand, one in every three Americans cannot afford their prescribed medications due to the high cost or absence of medical insurance. At the same time, there is no unified procedure for using surplus medications and making them available to those who need it. 

Another issue to consider in this context is the cost of unused drug disposal, which can be around $1.25 per pound. The rules require that unused drugs be disposed of through incineration that creates additional environmental concerns. 

The obvious solution to this complex problem is establishing a mechanism for returning the unused medications and offering them to patients who need them. In fact, the drug donation and reuse programs have been researched for more than twenty years, but only 38 states have passed laws on drug reuse as of now. 

At the same time, the implementation of these laws gives hope that the multi-faceted problem of surplus drugs can be resolved. However, to achieve true effectiveness and prevent misuse, such programs need to take into account many practical aspects: 

– Control over the donated drugs’ quality and expiration. Of course, to be accepted, drugs must be unexpired and their packaging must be intact. 

– Motivation for pharmacies to act as drug acceptance facilities. Participation in the drug donation program has its costs, which pharmacies are not too eager to bear. 

– Motivation for clinics and patients to donate unused drugs. The law prohibits selling medications, thus, their owners should be motivated in a different way. 

– Data security. Medication-related data is highly sensitive and needs special protection from unauthorized access. 

How technology can help 

Our experience with blockchain and distributed applications proves that these technologies can become the core of an effective and secure platform for unused drug donation and redistribution. It resolves the problems of data security and traceability and can help to automate a number of processes. 

Together with the Save Pharmaceutical project, Adoriasoft is now building a blockchain-based platform to join drug donors (clinics, assisted living facilities, individual persons), drug repositories (pharmacies), and patients. The solution will be a multi-functional product allowing donors to donate the medications they do not need, and pharmacies to approve or reject the donations and, ultimately, to provide them to patients. 

We are using Hyperledger Besu as the base technology for this project. By choosing Hyperledger Besu, we plan to leverage the benefits of the protocol to enable transaction processing. Furthermore, we see Hyperledger Besu as a platform for building a permissioned enterprise-scale network to serve the drug repository system. 

In view of the high sensitivity of healthcare data that is going to be exchanged in the network, the transactions will be processed via smart contracts executed on Hyperledger Besu. Only the parties directly involved in the transaction will have access to its details. 

At the same time, blockchain provides the means of controlling the entire transaction flow from the drug donation by the owner to its final assignment to the patient. The platform will include a mechanism of monitoring the pharmacy income from reselling the donated drugs and distributing it among the other participants. 

Since the law explicitly prohibits donors from demanding payment for the drugs they donate, there should be other methods of motivating them to participate in the program. The state laws establish a tax deduction for drug donation, but our product can include an additional compensation in the form of a tradable digital token. 

The tokens issued on the blockchain can be used towards a discount on the platform or exchanged for other assets. The same tokens can be issued to pharmacies, too, to attract them to the program. 

Blockchain-based drug repository networks are going to be a true quantum leap in the healthcare industry, on the one hand, bringing significant cost savings, and, on the other hand, making medications accessible to patients who were otherwise unable to purchase them. We are proud to be a part of a project of such a social impact and to make the knowledge accumulated by the Hyperledger community serve this noble cause.