BUILDING DECENTRALIZED APPLICATIONS
OLI dApps Portal
A collection of Ethereum based dApps
The interest in blockchain and distributed ledger technology (DLT) has accelerated significantly since the emergence of Bitcoin back in 2008.
Though blockchain is still a very young technology and undergoing continuous development, its use is gaining momentum in various industry sectors including finance, real estate, healthcare, identity management, and the energy sector. Technologies built on top of blockchain are known as Decentralized Applications (dApps). dApps are web applications that have a frontend and a backend just like common web applications. However, their backend is running on a decentralized peer-to-peer network. One of the most popular blockchain networks to develop dApps is Ethereum. It is a public blockchain and has developed its own programming language called Solidity to encode logic, rules, and instructions as smart contracts.
As many sectors are actively experimenting with blockchain, the energy sector is no exception. Blockchain along with other DLT and distributed energy sources (DERs) have opened new opportunities and challenges to revolutionize the way energy is traded, distributed, and the energy market is regulated. The potential of blockchain can be utilized across the energy value chain, building a peer-to-peer trading platform enabling producers to sell their energy directly to the consumers, generating green energy certificates, and integrating energy production and consumption in the energy supply system in a distributed way, etc.
At OLI Systems, we are building decentralized applications for energy markets based on the Ethereum blockchain network and smart contract technology.
Overview of the Development Stack
The dApps were developed using the following development stack:
- Smart Contracts: developed using Solidity
- Frontend: written in JavaScript, HTML, CSS, Vue.js
- Backend: Volta Test network connected with Parity Ethereum client
The architecture of the dApp is shown in the following figure:
Dev Environments
Developer Tools and Libraries
The dApps were built with the help of the following tools and libraries:
- Truffle: smart contract development suite for compiling, migrating, deploying, run tests, and interacting with a smart contract.
- Web3.js: A collection of JavaScript libraries to set up a communication layer between the blockchain node and the frontend.
- Parity Ethereum Client: An Ethereum client to connect with the Ethereum blockchain node.
- Vue.js: A progressive JavaScript frame to develop the frontend of modern web applications.
- Solidity: An object-oriented programming language to write smart contracts.
- Solidity-Coverage: Code coverage for Solidity smart contracts.
- Plotly.js: A declarative charting library built on the top d3.js.
- Leaflet: A JavaScript library to build interactive web maps.
- Git: A distributed version control system.
The Development Workflow
The development of the dApp can be divided into the following parts:
- Backend Development: This part involves setting up a connection with the Volta node through the Parity client.
- Smart Contract Development: During this part, smart contracts are developed using Solidity programming language and then deployed over the blockchain.
- Development of the Web App: In this part, the front-end of the dApp is built with the Vue.js framework.
- Connecting Frontend with the Blockchain: The communication layer between the front-end and the blockchain backend is set up using the web3.js library.
1. Setting up the Volta node
The setup starts with setting up the Ethereum blockchain development environment as a backend that is connected with the Parity client. For dApps backend, we are using the Volta network that is a test replica of the Energy Web Chain (EWC) and mostly used to test applications in a robust quality assurance (QA) environment. The network is connected by the Parity Ethereum client and uses a Proof of Authority (PoA) consensus mechanism.
2. Smart Contract Development
The project implements the business logic through smart contracts which are deployed on the blockchain. Smart contracts are a piece of program that represent the core logic of a dApp and are an integral part of the Ethereum blockchain. These contracts are developed using an object-oriented high-level programming language called Solidity. The development life-cycle of the smart contract, from developing to deployment on the blockchain, can be summarized in the diagram below.
2.1 Truffle Framework
We are using the Truffle framework for the development of smart contracts. The Truffle provides a suite of tools to write smart contracts in Solidity, perform unit tests using Mocha and Chai, and deploy contracts on the Blockchain.
- Truffle Unit Test
We will be using the truffle unit testing to test the core functionality of our smart contract. Under the hood, Truffle uses the Mocha testing framework and Chai assertion library to write the tests in JavaScript.
Following is the result of running truffle test on one of our smart contracts:
Contract: ChargingOrigin
✓ should register a new asset (267764 gas)
✓ should fail to register an already registered asset (27720 gas)
✓ should send the charging info (33427 gas)
✓ should send the production value (281962 gas)
✓ should fail to send production value from the un-registered asset (24967 gas)
✓ should return the ETH address of given asset id
✓ should return the list of registered assets- Gas Cost Estimation
The following table shows the gas and cost calculations for the execution unit tests and contract deployment. The market price data is fetched from Coin Market Cap and gas price is fetched from Eth Gas Station.
3. Development of the Web App
To interact with the smart contract on the Volta network, we built a UI component of the dApp in the form of a web app. The front-end of the project was built using modern web standards such as CSS, HTML, and the Vue.js framework. Additionally, two other JavaScript libraries, Plotly.js and Leaflet.js, were used to plot graphs and display geospatial distribution of resources, respectively.
4. Connecting Frontend with the Blockchain
The front-end of the dApp communicates with the Ethereum network using the JSON-RPC which is a stateless, lightweight remote procedure call (RPC) protocol using JSON for payload. This communication is done using a JavaScript library called Web3.js. It is a collection of libraries that allows our client-side application to communicate with the Ethereum network.
The interaction with the Ethereum network would be:
- Listening to the blockchain events like production and consumption data
- Sending transactions (containing registration details, production, and consumption values) to the blockchain using smart contract methods
To connect to the Ethereum node with JSON-RPC, we need to access the node using an Ethereum client, parity, or geth. In this project, we will connect with a locally running node connected with the Volta network using the Parity client.
5. dApp UI Update Cycle
As an overview:
- Currently, we are using a simulation setup written in Python to send the energy statistics over the blockchain using methods from smart contracts.
- We are continuously polling the network to listen for the event emitted for successful transactions.
- For each past and upcoming event, we perform some business logic and display them in the frontend.
Energy Geo-Browser
Among many use cases that can be built on blockchain technology, the Energy Geo-Browser app focuses on a transparent and efficient mechanism for presenting the dynamic and static attributes of energy assets, a decentralized mechanism for energy certificate issuance, and geo-visualization of spatially distributed energy sources.
The basic concept of the project is to present real-time information in a dynamic, secure, and transparent way. Thus, significantly reducing the complexities and additional costs associated with the internal operations because of third-party involvement. Though, we still have to pay the fee for the blockchain transactions. The prime focus of the project is to strengthen the energy market by modeling the energy transaction system that could lead to the energy certification layer on top of it.
The idea can be further extended to decentralized energy trading that will enable a direct relationship between producers and consumers.
Key Features of Energy Geo Browser App
- A registration mechanism for energy producers and consumers
- Real-time energy production and consumption tracking
- The decentralized energy transaction system
- Geo visualization of energy resources
The app shows one of the potential use cases of blockchain technology in the energy sector. The current dapp shows the very basic features of the geo-energy browser. Depending on the context of the implementation, the integration of DIDs or privacy-enabling components is possible. So, some regulatory and economical hitches are yet to be resolved.
OLI Tokenization
Renewable Energy Certificates (RECs) are important tools that represent the energy attributes as well as the information about how energy is generated. The certificate includes device type, locational information, owner details, and the total amount of energy generated. However, the energy is not incorporated in the RECs themselves. But, the renewable energy plants can issue 1 REC for every 1 MWh of the energy generated after they have fulfilled the criteria of REC generation.
The project has a certification page where a list of certificates is available that basically contains the Ethereum address of all the registered users. Once an address is clicked, a certificate has displayed that shows the energy and non-energy attributes of the producer such as device type, location, owner name, the total amount of energy produced, and geographical coordinates.
The process of certification is further extended to issue the digital token against the amount of energy produced at the rate of one coin per 1 MWh of energy produced. The token is a utility token and is designed on the ERC20 standard.
Asset Logging and Flex Control
This application enables a DSO or TSO to transparently control assets in their respective grid area. Some examples of this are the curtailment of PV in case of a local over-supply or the control of a battery that is supplying a local energy community. This process is usually being done with uni-directional radio transmissions from the grid operator to the asset which is highly inaccurate and not suitable for state-of-the-art smart grids. Also, it is rather in-transparent. The asset owners have to trust the grid operators to make the right choices — and also to reimburse them correctly for any lost revenues in the case of PV curtailment.
With an increasing amount of assets, participants, and control processes in general, there is a demand for a platform that can integrate the following steps into one workflow:
- Onboard Assets, asset owners, and grid operators in a quick and simple way with low costs
- Enable the grid operators to securely control assets
- Log every control process to enforce transparency for the participants
The backbone of this application is the “Volta” test network of the Energy Web Foundation. Every device owns its own key-pair which is being registered inside the smart contracts. These smart contracts also take care of the access restriction and the logging process. The participants don´t have to trust each other because the blockchain takes care of this, which reduces administrative overhead.
Charging Origin App
The Charging Origin dApp is also built using smart contract technology on the top of the Ethereum network. The basic concept is to keep a record of events managing charging point power consumption and PV power generation data at a specific time interval.
The process starts with the one-time registration of the assets. After the registration, the assets will be able to send their data to the blockchain through smart contract methods. The front-end of the app will actively listen to the blockchain events in response to the transaction sent to the smart contract. Once an event is popped up, the event's return values will be processed to bind them to the respective asset and to calculate the energy share for each consumption event.
In case you have any feedback, please drop me a line!
