Category

Blog

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 04
Love0

A Contributor Story: The Path from Custom APIs to Commercial Solutions and Bug Fixes to Fabric 2.1 Documentation

By Blog, Hyperledger Fabric

In 2016, SIMBA Chain was awarded one of the very first DARPA Small Business Innovation Research contracts for blockchain on secure messaging. Dr. Ian Taylor, our CTO, has spent years in distributed computing, but, at the time, Ian and I knew very little of blockchain. I had done some Bitcoin mining in the early years, but had no experience with smart contracts. 

As part of the contract, Adam Brinckman, a senior research programmer at the Center for Research Computing at the University of Notre Dame, wrote the chaincode (the “smart contract”) for an application enabling military agencies to create military interdepartmental purchase requests (MIPR transactions) on a privately shared Hyperledger Fabric distributed ledger for our project with DARPA. The goal of this project was to securely provide full traceability of all provisions as they were awarded through a very complicated procurement process. 

The initial solution sought to take advantage of the tools provided by Hyperledger, which included  Hyperledger Composer, an interface designed to help developers define assets written to the ledger. However, as we developed the application, we were challenged by the sheer complexity of the MIPR acquisition process. The numerous ways in which transactions could be modeled and the different ways each agency had defined MIPR assets presented major challenges. It would be difficult to capture the problem correctly using a written piece of chaincode. 

We realized quickly that we needed to build an auto-generated smart contract and API based on the assets and transactions to help simplify and capture this entire process. This proved to be a good solution for the challenges we faced. Over time, we developed this solution into a tool that would allow low code enthusiasts and business analysts to utilize blockchain and create adoption outside the normal community of interest. 

The rest is history. We went on, and continue, to build solutions for the Department of Energy, the United States Navy, Air Force, and USMC, all utilizing Hyperledger Fabric. Many of these solutions are around supply chain traceability, provenance, risk mitigation, sustainability, and lifecycle management. 

Hyperledger Fabric was the DLT platform of choice because it provides the following:

  • Open source!
  • Supply chain specific capabilities 
  • High throughput
  • Permissioned membership
  • Scalability
  • Levels of trust
  • Data on a “need to know” basis
  • Rich queries
  • Architecture that supports plugins
  • Protection of keys and sensitive data
  • Integration with the Fabric EVM that allows us to write Solidity-based smart contracts

Our extensive work with Hyperledger Fabric and smart contracts has given us the expertise to contribute back to the development effort. Adam recently collaborated with Fabric developers working on the Fabric EVM chaincode to fix a minor bug. The exact problem occurred when attempting to use the Fab3 proxy with web3 python libraries (web3.py). Unlike its JavaScript counterpart, web3.py enforces all input data to conform to Ethereum’s yellow paper specifications, and data returned by Fab3 was failing these validations. Fab3 isn’t the only service that fails these validations; Quorum and other private EVM implementations also fail validation due to the extra bytes they pack into transactions and blocks. Tapping into his experience as an Ethereum Solidity developer, Adam worked with Hyperledger’s development community to make Fab3 compatible with web3.py’s strict validation rules and added new regression tests to ensure that future releases remain compatible.

Adam also developed a guide for deploying Fabric EVM onto Hyperledger Fabric v2.1. The official documentation shows examples for installing Fabric EVM onto a 1.4 network so this guide will help developers transition their Fabric EVM chaincode as they begin to upgrade their network. 

As a firm that has benefited from open source development of Hyperledger Fabric and other tools, we recognize the value of contributed code and expertise. We’ve been able to build Hyperledger-powered solutions that add the efficiency and effectiveness of key government services and want to help drive more open source innovation in the blockchain space. We encourage others to get involved. Check our this guide to contributing to Hyperledger Fabric or join #Fabric in the Hyperledger Chat channel to talk to the maintainers about your needs and ideas and about how to get involved or suggest a feature or fix. 

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

Weekend Update: This Week’s Round-up of Remote Blockchain Learning Resources

By Blog, Weekend Update

Welcome to the Weekend Update. Our goal with this weekly post is to share quick updates about online education, networking and collaboration opportunities and resources for the open source enterprise blockchain community. 

If you have suggestions for resources or events that we should spotlight in a future Weekend Update, let us know here using #HLWeekendUpdate.

Hyperledger Project Webinar: Hyperledger Besu

Hear from Hyperledger Besu developers about the new features introduced with version 1.5.  As part of the project update, the team will provide a demo of the new features and talk about the roadmap. Come prepared with questions!

The webinar will be at 10:00 a.m. EDT on August 5. Go here to register.

Webinar: COVID Pandemic Accelerating Industry 4.0, What is the Role of AI, Blockchain, & Digital Identity?

Join Chainyard’s Gigo Joseph, vice president, blockchain services, and Isaac Kunkel, senior vice president, for a panel discussion on the impact of the pandemic on new technology adoption and use cases. The discussion is part of a webinar series presented by the University of Dubai’s Center of Business Research and Consultancy.

The webinar will be at 1:00 p.m. UTC on August 5. Go here to register.

Webinar: Building and Scaling Blockchain Solutions for the Greater Good

CoinDesk and IBM are teaming up for a discussion on how IBM Blockchain solutions are being used to help corporations deliver technology for social good and for a variety of industry solutions. The discussion will include technology options for deploying blockchain network components on-premises with System Z, in public clouds, or in hybrid cloud architectures.

The webinar will be at 11:00 a.m. EDT on August 6. Go here to register.

Virtual Meetups

See the full Virtual Meetup schedule here. 

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 24
Love0

Weekend Update: This Week’s Round-up of Remote Blockchain Learning Resources

By Blog, Weekend Update

Welcome to the Weekend Update. Our goal with this weekly post is to share quick updates about online education, networking and collaboration opportunities and resources for the open source enterprise blockchain community. 

If you have suggestions for resources or events that we should spotlight in a future Weekend Update, let us know here using #HLWeekendUpdate.

Free training courses

The Linux Foundation offers free online-learning courses on a range of open source topics from Linux to blockchain, networking to cloud, and everything in between. Below are some options for those looking to dive deeper into Hyperledger and enterprise blockchain:

Introduction to Hyperledger Blockchain Technologies
This free introductory course is carefully curated for nontechnical, business-oriented audiences and examines blockchains for the enterprise. 

To learn more, go here.

Hyperledger Sawtooth for Application Developer
This course covers the basics of blockchain and permissioned networks and then introduces students to Hyperledger Sawtooth. Students will learn the principles of application design and development for the Hyperledger Sawtooth platform and create a full-featured Hyperledger Sawtooth blockchain application. The course is free, but there is a paid certificate option as well. 

To learn more, go here.

Virtual Meetups

See the full Virtual Meetup schedule here. 

Jul 20
Love0

New release: Hyperledger Fabric 2.2 LTS

By Blog, Hyperledger Fabric

The Hyperledger Fabric community is very excited about the release of Fabric v2.2 LTS. Fabric v2.2 represents the first LTS release in Fabric v2.x.  Further enhancing the new features that make developing and deploying Hyperledger Fabric networks easier than ever before, we have added updated tutorials on the “how to” that allow developers to take full advantage of these features with tutorials supporting multiple languages so as Go, JavaScript, and TypeScript with support for Java coming soon. There are many exciting new features to be aware of, so let’s dive right into the highlights:

  • Decentralized governance for smart contracts: This is actually a huge change from earlier 1.x versions of Fabric where one company had the ability to influence chaincode parameters and endorsement policies for the entire consortium on a channel. In Fabric v2.2, multiple organizations must agree to the chaincode parameters and there is a much more deliberate process to upgrade chaincode that now requires a sufficient number of organizations within a consortium to agree ahead of time before the chaincode can become active on the channel.
  • New chaincode lifecycle: This feature has to be one of my favorites because packaging, installing, approving, and committing the chaincode on a channel is much easier and can even be used in a “chaincode-as-an-external-service” model. Chaincode is now packaged in easily readable tar files that make it much easier to inspect and coordinate the installation across multiple organizations in a consortium.
  • New chaincode application patterns: This includes the ability to add automated checks for chaincode validation prior to endorsing a transaction proposal and the ability to decentralize agreement across multiple transactions that relate to specific terms and conditions in a business case.  
  • Private data enhancements: This enables the sharing and verification of private data without actually exposing data to those who are not supposed to see it by allowing them to compare on-chain hashes of the data to ensure they match. The many other features that these private data enhancements enable are too numerous to cover in this blog, so be sure to check out the “What’s new in Hyperledger Fabric v2.2” linked below.
  • External chaincode launcher: This is a seriously cool feature that I am pretty excited about and one that most developers would probably say is long overdue. Now there’s no requirement that a peer node have access to a Docker daemon in order to build and launch chaincode. What a game-changer! Chaincode is no longer required to be run in containers, leaving the developer with more flexibility than ever before!

Other noteworthy things to consider for Fabric v2.2 LTS:

  • Build Your First Network (BYFN) has been deprecated as of this v2.2 and is replaced by the Fabric Test Network.  You can find the updated tutorial here.
  • The updated tutorials will all use new fabric samples based on Asset Transfer chaincodes and applications and the Fabcar chaincode will get retired.
  • The new Fabric Test Network allows you to start the network in a much more flexible manner and can be chaincode agnostic if you want it to be.

These are just a few of the highlights, so I highly recommend that you visit the Hyperledger Fabric docs to read in full detail all the exciting new features and the possibilities they open up.

You do not need to be an expert to be an effective contributor to the Hyperledger project. In fact, I think you will be amazed at the welcoming nature of the community and how quickly you can build on your skills simply by engaging as a contributor.

Remember, all are welcome so if you’d like to join the community or learn more, you can find more information here:

Chat: #Fabric in Hyperledger Chat
Docs: Fabric 2.2 Documentation
Code: Fabric Github
Issues & Roadmap: Fabric JIRA
Website: Hyperledger Fabric Homepage

Thanks for reading about our newest Fabric release. We encourage developers to try these new features out and give us feedback!

Jul 17
Love0

Weekend Update: This Week’s Round-up of Remote Blockchain Learning Resources

By Blog, Weekend Update

Welcome to the Weekend Update. Our goal with this weekly post is to share quick updates about online education, networking and collaboration opportunities and resources for the open source enterprise blockchain community. 

If you have suggestions for resources or events that we should spotlight in a future Weekend Update, let us know here using #HLWeekendUpdate.

Singapore Blockchain Week (July 21-23)

This year’s Singapore Blockchain Week will be hosted online and bring together governments, industry leaders, academics and innovators, and aid collaboration on both regional and international level. 

As part of the program, Hyperledger’s Brian Behlendorf will be part of the panel “Accelerating the Adoption of Blockchain at the Enterprise Level” taking place Tuesday, July 21, at 10:00 a.m. SGT.

Free passes are available. Once you register, make sure to stop by the Hyperledger virtual booth. The Trade Finance SIG will be meeting there from 3:30-5:00 p.m. SGT on July 21. The meeting will include a panel with speakers from ABN AMRO, dltledgers, IBM and We.trade.

Registration details are here.

Webinar: Observability of multi-party computation with OpenTelemetry

Tune in to a webinar led by Splunk detailing how the latest innovation in managing logs through OpenTelemetry, a project of the Cloud Native Computing Foundation, makes it possible to combine multiple blockchain systems to report fine-grained information into a comprehensive consortium view. As part of their talk, Antoine Toulme and DaveMcAllister Sr of Spunk will share a reference architecture to integrate best of breed technologies: Kubernetes, OpenTelemetry Collector and Hyperledger Fabric.

The webinar will be at 10:00 a.m. PDT on July 23. Go here to register.

Capital Markets Special Interest Group Digital Dollar Project (DDP) discussion

This week, the Hyperledger Capital Markets SIG fielded a detailed discussion about the prospect of a digital version of the U.S. dollar as outlined in the Digital Dollar Project whitepaper. Go here to find a recording of the meeting as well as links to the white paper and to added background documents.

Virtual Meetups

See the full Virtual Meetup schedule here. 

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.