Table of content
Sustainability is one of the hottest topics nowadays as it’s crucial to focus on meeting the needs of the present without compromising the ability of future generations to meet their needs. Lots of companies are trying to implement blockchain technology into sustainable projects and the 4ire Labs team is happy to make this impact. We’ve already published our use case about blockchain in sustainable finance. In this article, we review the case of the implementation of blockchain technology in the energy sector.
Blockchain technology in the energy sector
Blockchain development is influencing different industries now, and the environment as well. According to the report of the World Economic Forum, Stanford Woods Institute for the Environment, and PwC, nowadays there are more than 65 existing blockchain use-cases for the environment and these numbers are increasing.
These cases are covering new business models for energy markets, real-time data management, and moving carbon credits or renewable energy certificates onto the blockchain.
The main reason why companies prefer blockchain is that the technology promises transparent, tamper-proof, and secure systems that can enable novel business solutions.
Blockchains are shared and distributed data structures or ledgers that can securely store digital transactions without using a central point of authority. Also, blockchains allow for the automated execution of smart contracts in peer-to-peer (P2P) networks.
You may also be interested in: How to Build a P2P Payment App
One of the first blockchain applications in the energy sector was the acceptance of cryptocurrencies for energy and electricity payments. Now there are hundreds of blockchain initiatives in the energy sector being pursued by a large number of companies, startups, and research institutions.
Blockchain technology for renewable energy
Renewable energy is the energy that is collected from renewable resources, which are naturally replenished on a human timescale, such as sunlight, wind, rain, tides, waves, and geothermal heat.
Blockchain and smart contracts may have a great impact on renewable energy. An example is the use of blockchain to manage renewable energy certificate transactions. What do we call a Renewable Energy Certificate (REC)?
Renewable Energy Certificates (or simply RECs) are green energy certificates or tradable renewable certificates. They usually work as proof that energy has been generated from renewable sources such as solar or wind power. Such certificates can be purchased on the trading platforms.
Our experience in implementing blockchain into the REC trading platform
4ire labs team had a chance to work on the development of such kind of platform. It was a marketplace for RECs for green gas. Green gas (also known as biomethane) is made from biodegradable materials which can then be used in the same way as energy from fossil fuels.
Biomethane is renewable and virtually carbon neutral, so it doesn’t contribute to climate change. US Government supports using the green gas and provides special grants to popularize eco-friendly technologies.
Our clients decided to create a platform where it’s possible to buy and verify certificates for green gas. As there are lots of parties within the platform (gas manufacturers, buyers, companies that provide certificates) it was really important to keep transparent relations between them and at the same time to protect their data. That’s why it was agreed on using blockchain technology.
Our team was responsible for making the system ready for production. Our engineers had worked on the consulting part helping to set the Hyperledger Fabric in production for a few organizations with logging, monitoring, and backups.
Technical details of the development
Here is the architectural diagram of the platform:
Here are a few important steps in the development process
1. Selecting the baseline solution for the Hyperledger Fabric
Developers of Hyperledger Fabric have already containerized all modules, so it was easy to use Kubernetes to set up the production infrastructure.
There are a couple of companies who had developed their own solution:
- Aidtechnology has developed very convenient helm packages. Unfortunately, there was no info about the installation and upgrading of chaincode and extending network to more organizations.
- Accenture from the Netherlands has developed a tool based on Argo that uses native fabric configuration files to deploy a network of multiple organizations with support for RAFT and automated scripts to deploy and upgrade the chaincode.
- IBM Blockchain Platform is a very convenient tool that allows you to run hyperledger fabric network in Kubernetes on IBM. It provides the possibility to configure organizations just in the IBM cloud without need to write complex config files.
- AWS Managed Blockchain, unfortunately, supports only outdated Fabric 1.3 at the date of this article was written.
2. Decision-making process for Hyperledger fabric solution
As Aidtechnlogy gave a very good possibility to run the very custom network, they don’t provide tools to deploy and upgrade the chaincode and no instructions on how to add new organizations to the network. Also, helm packages are having a couple of bugs.
It seems that Aidtechnlogy stops supporting it and there is no documented TLS support IBM’s solution is very expensive if you need to run it in own cloud. One of the requirements was to run the infrastructure in AWS.
It was the reason why we took Accenture’s solution as a baseline. They have very good documentation with the step by step instructions of how to setup RAFT or Kafka based clusters with the support of TLS and scripts to extend the network to multiple organizations.
3. Fault tolerance
Using multiple peers in the network allows having high availability and fault tolerance. You can use Kubernetes hard anti-affinity to setup good topology of the network inside the cluster. Rules that we’ve used:
- Peer pod and its couch DB pod must be on the same EC2 instance
- Peers of one organization cannot run on the same EC2 instance
- Raft orders should have hard anti-affinity rules set.
4. Consensus
We’ve chosen the RAFT consensus as it makes the process of deployment and support much easier in comparison with Kafka. Also in the case of RAFT, all organizations can maintain their own orders. In the case of Kafka, there can be only one organization that maintains all orders and it makes the network more centralized.
5. Logging and monitoring
ELK stack is very good optimized for running in Kubernetes. We’ve run elasticsearch, kibana, filebeat and prometheus to get logs and monitor the state of the network.
Additionally, we’ve installed a fabric block explorer.
6. Accessing cluster for different services
To access the network different backend services need to use fabric SDK (js/go/java). To leverage the threshold of using fabric network for multiple organizations and standardize the interfaces we’ve decided to wrap fabric libraries with the API server written in NodeJS and provide organizations with the typescript library that their developer can use to interact with the network.
7. Network decentralization by using multiple clusters
The client’s goal was to run the MVP version of the product, that’s why we haven’t supported multiple Kubernetes clusters operated by different organizations, but the current solution fully supports the possibility for different organizations to connect to the network from their own infrastructure.
This case shows that blockchain implementation requires a high-level expert as there are lots of details to be figured out, especially in cases with sustainable projects. It was such a great experience for our team.
