All Posts By

Nima Afraz, Connect Centre for Future Networks and Communications, Trinity College Dublin

Sep 16
Love0

Hyperledger is Enabling New Blockchain-Based Business Models for 5G

By Blog, Hyperledger Fabric, Telecom

The fifth generation of cellular networks or 5G promises revolutionary improvements compared to the previous generation that reaches beyond merely multiplying the bandwidth and reducing latency. 5G is expected to enable a wide range of new internet-based services such as vehicular communications and Smart City infrastructure that, in addition to connectivity, require on-demand fine-grained infrastructure and resource access to operate. Hence, the allocation of the underlying resources has to be capable of supporting and adapting to sudden changes in demand for resources and be able to flexibly provide customized bundles of resources to fit the demands of the vertical industries using the 5G infrastructure.

Entering the 5G market, an operator may experience up to 65% increase in RAN deployment and infrastructure costs [1]. Discovering new ways to more efficiently allocate resources can, to some extent, alleviate the massive increase in the infrastructure cost. Network and infrastructure sharing is one of the solutions that could help major operators to gain considerable returns by leasing out portions of their idle resources to other service providers that o are willing to operate in the same geographical region.

A Decentralized Marketplace for Network Infrastructure Sharing

The practice of infrastructure/network sharing dates back to the previous generations of cellular networks. However, these sharing models were typically in the form of bilateral agreements and were limited to long-term sharing of passive and seldom active network resources. Such sharing models cannot support either the on-demand short term sharing requests or the larger markets where the parties involved in resource trading exceed only two operators. On the other hand, the intense competition in the telecoms industry rules out the prospect of a centralized marketplace where a trusted intermediary is in charge of the market and makes the final decision regarding the allocation of the resources and the price. Therefore, a decentralized approach is required to incentivize participation by the infrastructure providers, network operators, and over-the-top service providers.

Hyperledger Fabric blockchain technology can provide the foundation for the described decentralized marketplace where all the market players could participate in the resource allocation and pricing process in a transparent and trustworthy way and without relying on a third party. 

Case Study: 5G Network Slicing

Network virtualization technology allows the division of network resources into isolated virtual slices of the network that could be then offered to other users. This creates a new business opportunity for network operators and infrastructure providers to monetize their idle resources. Therefore a new business model has been gaining attention where operators and service providers can trade network resources in a marketplace equipped with a market mechanism(e.g., auctions). The aim is to develop a marketplace that does not rely on a third-party broker to conduct the market.

Why Hyperledger?

Hyperledger Fabric is an open-source project that is built as a modular software so that every piece of it can be tailored into the needs of the developers. Besides, with Hyperledger Fabric, there are no coding language lock-ins as the platform does not force the developer to use a particular language for the smart contracts. Finally, compared to other blockchain frameworks, the supported high transaction throughput and low latency make it a right candidate for 5G use cases.

Scenario:

A number of operators and service providers are participating in a marketplace to buy/sell network slices [2]. They each offer ask/bid prices for the offered quantity of a network slice and the smart contract that has to be endorsed by every single operator decides the final allocation and price of the network slices.

  • The commodity: A network slice consisting of computing, RAN, and storage resources.
  • Member organizations: Infrastructure providers, network operators, and service providers.
  • Technology: Hyperledger Fabric v 1.4.1, Raft ordering service
  • Architecture: Five organizations each with one peer node and 10 Raft orderers.
  • The Smart Contract: A sealed-bid double-sided auction mechanism that allows bilateral trade of network slices.

Conclusions:

The research team at Connect Centre [3] have developed the smart contracts and deployed the Hyperledger Fabric network on one of the major public cloud provider’s infrastructure. The results of the performance benchmarks of the blockchain solution are reported in [2]. In addition to the 5G slicing, other resource sharing problems in 5G are expected to benefit from the blockchain technology. One other example is Virtual Network Function (VNF) marketplaces where network operators and software vendors could offer their virtualized network services such as Firewall, DNS, CDN, etc. 

[1] Future Networks. “5G-Era Mobile Network Cost Evolution.” Accessed September 10, 2020. https://www.gsma.com/futurenetworks/wiki/5g-era-mobile-network-cost-evolution/.

[2] N. Afraz. and M. Ruffini, “5G Network Slice Brokering: A Distributed Blockchain-based Market,” in EuCNC conference 2020.

[3] CONNECT – the Science Foundation Ireland Research Centre for Future Networks and Communications, https://connectcentre.ie/

If you’re interested in how blockchain is being used in the telecom industry, get involved with the Hyperledger Telecom Special Interest Group. 

About the author
Nima Afraz is a postdoctoral researcher with Connect Centre for Future Networks and Communications, Trinity College Dublin. He is a member of Hyperledger Telecom Special Interest Group. His research interests include network economics, network virtualization and blockchain for telecoms.

Cover image by mohamed Hassan from Pixabay

Sep 02
Love0

Hyperledger for the Blockchain Skeptic

By Blog, Hyperledger Fabric, Special Interest Group

As an enterprise software developer, I’m used to thinking about solving real world business problems. So, naturally, I was pretty skeptical of bitcoin and the blockchain when I first heard about it.  

Yet the idea of a “distributed ledger” kept tugging at me. Since all the apps we’ve built, from ERP to CRM to e-commerce, revolved around a ledger of transactions, what could a global, distributed ledger allow us to build?  

It took me three years of off-and-on studying and a few very smart people to finally make me realize that the blockchain, or distributed ledger technologies (DLTs), is just a small step from what we’re already used to. But that little step could unlock a new world of possibilities.  

In this post, let me address some of the common skepticism I’ve encountered as part of the Hyperledger Climate Action and Accounting Special Interest Group. Then in a follow-up post, I’ll show you why I believe climate change is the killer app for the blockchain.

I Don’t Need a Blockchain

Are you sure? Because you’ve probably already started building a few.  

With enterprise software, we often have to prove that the data we’re using is authentic. So how would you assure someone that the data you’re using has not been altered or tampered with?  You know that the data provider might change its API or the data you get from it, so 

  • Did you make a local copy of the data you got?  
  • Did you record the date and time you got it?  
  • Did you record a hash of the data, so it could be compared with the data you used for your application?  
  • Did you store archival copies of the data and the hash so that you could prove that they are all correct?  
  • Did you store multiple copies just to be sure?

If so, then you’ve built much of what goes into a blockchain or distributed ledger. A blockchain is really a protocol to store data across multiple nodes while assuring their consistency. It follows all the steps outlined above, plus a few more, to make sure that once stored, data cannot be lost or altered.  

So if you’ve already been building your own “distributed” data records, then you obviously need what the blockchain offers. It addresses many of the pain points of data integration that we deal with every day in enterprise software.  

The advantages of an open source blockchain platform such as Hyperledger Fabric or Hyperledger Sawtooth, compared to a homegrown solution, are many: Most obviously, there is security and scalability of a developed solution. Then there is the support for the “unknown unknowns,” use cases you may not realize exist but would surface over time. Finally, there’s the chance to work with some very smart people and learn more about this emerging technology.

Databases Are Faster than Blockchains

This is certainly true, and nobody would suggest that you replace your database with a blockchain. The two have different but very complementary uses.

Databases are great for fast read and write access of data within an organization. Blockchains are great for making sure data is stored immutably, so that its authenticity could be proven across multiple organizations.  

Another way to think about it is that databases are for building applications, while blockchains are for building collaboration.

There Are too Many Competing Blockchains for Me to Use Them Now

This probably stems from confusing blockchain with Bitcoin, just like people once confused Compuserve or AOL with the internet.  

Remember that blockchain is a technology, while Bitcoin is a protocol and a cryptocurrency implemented with blockchain. There will always be many different protocols, cryptocurrencies, and frameworks implemented with blockchain technologies, just like there were many different websites implemented on the internet.  

Blockchains are Too Energy Intensive and Bad for the Environment

I get this from climate activists, some of whom actually got angry when I mentioned the blockchain.  Again, this stems from confusing blockchain with Bitcoin, Ethereum, and other implementations of the blockchain.

The early blockchain protocols such as Bitcoin and Ethereum used proof-of-work consensus mechanisms, which required a lot of energy-intensive “mining” of cryptographic puzzles. Their  creators probably never imagined them to become as popular as they did, or that they would consume as much energy as whole countries.

Fortunately, we’re all moving away from proof-of-work because it is so energy intensive and simply slow. Hyperledger Fabric, for example, is both fast and energy efficient because it does not use proof-of-work.

Blockchains are Too Immature Right Now

This may have been true five years ago but is definitely not true any more.  There are plenty of blockchain applications — Bitcoin, Ethereum, Compound to name a few — that have billions of dollars of stored value. On the enterprise side, Hyperledger platforms have been used in production for a range of interesting use cases for a while now.

The field will continue to evolve, but, as a whole, blockchain has probably reached the level of maturity of the internet around when Amazon got started, if not further.

There is No Killer App for Blockchain

Which brings us back to the original question: What could a global, distributed ledger allow us to build?

I believe it would allow us to create collaboration on an unprecedented scale, across traditional national and industry boundaries and over long time horizons. And there’s no use case better suited, or more urgent, than climate change. Stay tuned.

About the author
Si Chen has been developing open source enterprise software since 2005.  He is a part of the Hyperledger Climate Action and Accounting Special Interest Group, which is working on using Hyperledger and blockchain to solve the climate change problem. 

Cover image: https://www.needpix.com/photo/1214471/blockchain-block-chain-technology-computer-symbol-network-connection-web

Aug 19
Love5

Blockchain Stories 2020: Highlights from Five Weeks of Community Sharing in Asia Pacific

By Blog, Community Spotlight

We all have heard blockchain stories. Stories that redefined the way businesses operate. Stories that created new business across the domains. Stories that propelled innovation. Stories that are defining the future of technology. Stories that helped others run their business in decentralized fashion. And a lot more.

Blockchain technology has seen increasingly wider adoption across the industries. Digital transformation of businesses and innovation in the healthcare industry have seen unprecedented demand like never before during the challenging times of COVID-19. What seemed impossible in the past is now turning to be reality.

The Hyperledger India Chapter aims to bridge the gap between the blockchain technology enthusiasts and the blockchain technology experts. To us, it seemed it was time for an event to bring together booming startups and established organizations to share their blockchain journey. In these demanding times, having physical get-togethers is impossible around the world. There is a saying in Sanskrit “Vasudhaiva Kutumbakam,” which translates to “World is Indeed One Family.” The idea of having the virtual event in India transformed to one that could benefit the whole Asia Pacific audience. The event time was chosen so that everybody in the Asia Pacific region from the Middle East to Australia/New Zealand could attend.

In the last week of May and through June, Hyperledger India Chapter proudly organized a series of interactive events, the most anticipated “Blockchain Stories 2020.”

The series was an attempt to answer the questions one normally hears. Is blockchain really being adopted across the industries? What uses can blockchain solve? How do you effectively use a blockchain solution? Can blockchain transform agriculture? How does blockchain transform education and certification in the future? Is blockchain an answer to all the healthcare problems? What are the barriers for the adoption of blockchain technology?

Highlights:

  • 25+ organizations presented their solutions. The topics covered a range of domains including supply chain, telecom, healthcare, agriculture, digitally verifiable certificates, self sovereign identity and security, digital currency, global trade, research and education. 
  • More than 1,000 blockchain enthusiasts from across the Asia Pacific region signed up for the events.
  • Community engagement continued across five weeks.
  • 20+ volunteers helped tirelessly, physically separated but virtually connected. 

That’s not all. Since Hyperledger believes in inclusive community growth, sessions not only showcased solutions built on Hyperledger projects but also ones built on other platforms. These sessions focused more on how blockchain as a technology pillar is helping to design solutions to the demanding problems. The series also featured talks on how to measure and improve the performance of blockchain frameworks.

Indian blockchain firms have made an impact on Industry 4.0, which created massive hype amongst the young, brilliant and blooming minds of India. Blockchain tech has already made its way into many mainstream industries. The emerging technology startups thanked the Hyperledger India Chapter for organizing an event and providing them an opportunity to present their solution alongside the lights of big establishments. AyanWorks, a blockchain startup based in Pune, India, presented their immunity passport solution for safe reopening of the post pandemic world. Snapper Future Tech & IIT Alumni Association presented their solution on COVID-19 X-Ray analysis using  blockchain & AI, reducing the cost of testing. Tech Mahindra showed how blockchain is helping to solve the telecom’s billion subscriber problem, and countries including the USA are requesting a similar solution. The dltledgers, a blockchain startup based in Singapore, shared their digital transformation journey for cross border trade finance. Soramitsu, a blockchain technology firm based in Japan, shared their payment solution.

Arun S M, Walmart Global Tech, says “It feels amazing to see the great response from the community. What started as a thought late last year took multiple turns, shapes and forms to be finally called Blockchain Stories 2020. Hyperledger staff members made it easy for us to turn a local event into a virtual one that reached an audience throughout Asia Pacific. The community stood by us through a technical glitch on our first day of the event, showing quality and a high level of interest and engagement.”

Julian Gordon, VP, Asia Pacific, Hyperledger, says “Hyperledger’s India Chapter volunteers worked tirelessly and enthusiastically to produce this wonderful series of ‘Blockchain Stories 2020’ for the Hyperledger and wider blockchain communities. Each event featured cutting-edge blockchain solutions, addressed opportunities and challenges, and showcased exciting developments in blockchain. Hyperledger has received excellent and appreciative feedback from the series’ virtual audience. It’s particularly timely and heartening to see quality virtual events like these take place in this challenging time of Covid-19. It’s a pleasure to support Hyperledger’s India Chapter, and I would like to thank them for all their work on the ‘Blockchain Stories 2020’ series.”

Did you miss the event? We have got it covered. Watch the recap on YouTube. The Hyperledger India Chapter thanks all the volunteers and organizers for helping to make this event a success story.

About Us: The Hyperledger India Chapter is responsible for growing the Hyperledger community in India, promoting contributions to Hyperledger projects and providing a platform for collaboration, mentoring and support. The chapter aims to showcase the broad range of Hyperledger projects and initiatives to the Indian audience. Join us and share your ideas! Weekly meeting details can be found at the Hyperledger Calendar of Public Meetings.

Future Plans: There is a huge interest in the community to contribute back to open source projects. We are happy to provide a platform and connect, guide and mentor the technical community in India. Following the success of the “Blockchain Stories 2020,” we will organize a “Hyperledger Project Connect Series” to benefit tech enthusiasts in Africa, Europe and the Asia Pacific regions.

Aug 06
Love5

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
Love5

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
Love5

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
Love5

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

Jul 14
Love5

How to quickly deploy blockchain networks that can scale to production With Blockchain Automation Framework, a Hyperledger Lab

By Blog, Hyperledger Labs

One of the key deterrents in the adoption of blockchain/DLT today is that it is perceived as a complex technology, with a time-consuming network setup and operations. Accenture’s Future Systems research shows that, for companies across the world, the biggest barrier to innovation at scale is the ability to build flexible, uniform architectures capable of responding to market demands. This is in line with what we hear from our blockchain clients who want to know how to scale a blockchain trial to a production environment while safeguarding their investments.

The presence of a variety of enterprise DLT providers today such as Hyperledger Fabric, Hyperledger Indy, Hyperledger Besu, R3 Corda, Quorum and more, each with their own architecture and disparate services, compound the complexity in the world of DLT. 

We get it. Getting started can be hard.

Setting up a new DLT network or maintaining an existing DLT network in a production-scale environment is not straightforward. For the existing DLT platforms, the steps in setting up one DLT network cannot be applied to others. When blockchain developers are asked to use an unfamiliar DLT platform, it requires a great deal of effort for even experienced technicians to properly setup the DLT network. This is especially true in large-scale production projects across multiple corporate environments more focused on other key aspects such as security and service availability.

Another problematic trend across many different organizations’ blockchain/DLT implementations is the PoC (Proof of Concept) first approach. While this is a sound way to test whether the technology can work, scalability and security are not part of the design at the outset, and so significant efforts are required to rearchitect and rebuild for production deployments. 

Cloud vendors such as AWS and Azure offer managed blockchain services (aka Blockchain as a Service or BaaS) to help alleviate various pain points during the process of preparing a production-scale DLT network. However, these solutions have network size limitations, lock all nodes into a single cloud provider, or offer few choices for DLT platforms, which may be deal-breakers in some scenarios. 

What if it didn’t have to be? 

Imagine if the several weeks of development time required to set up and deploy a DLT network could be reduced to a matter of hours. What if the same framework developed for a PoC could scale to pilots and production, evolving along with the applied solution for faster innovation and more seamless innovation?  

With these opportunities in mind, our team at Accenture Blockchain and Multiparty Systems started conceptualizing “Blockchain Automation Framework.” BAF helps developers rapidly set up and deploy secure, scalable and production-ready solutions that also allow new organizations to be easily onboarded on the network. BAF accelerates delivery and lets developers focus on building blockchain applications without having to waste precious time standing up the environment or worrying whether the network will scale and meet production requirements.

How does it work?

Using a single configuration file, you deploy the distributed network on a cloud infrastructure of your choice, including certificate management and smart contract installation. Whether developing an early stage PoC, late stage pilot, or scaling for production, Blockchain Automation Framework can reduce the time required to bring up the network from days to hours. The secure, fault tolerant framework helps to ease onboarding of new organizations and accelerate testing or production deployments in multicloud or multiparty systems.

Here is a quick look at the components and features BAF uses to automate network deployment:

  • Ansible playbooks and role definitions that follow a specific order to automate the entire DLT network setup
  • HashiCorp Vaults to securely store tokens, passwords and certificates
  • Kubernetes services, including Ambassador or HAProxy Ingress Controller, to route traffic and enable inter cluster communication
  • GitOps method for continuous deployment to Kubernetes clusters via Flux operator
  • Helm Charts for designing and configuring the architecture
  • The ability to share a configured network.yaml file without disclosing any confidentiality

Learn more with this video overview of the Blockchain Automation Framework:

Collaborate with us!

We are actively searching for potential contributors, maintainers, and partners who understand the value of Blockchain Automation Framework and share the vision of building and owning well architected solutions. We wish to work with the Hyperledger community to identify the needs and requirements of other network operators and to further reduce the barriers in blockchain adoption. As we roll out new features and further DLT platform support, all are welcome and encouraged to collaborate with us and share their feedback. Check out the source code and documentation on GitHub and please do bring technical questions to our Chat channel or join our open BAF meetings.