The network setup for testing the physical implementation is based on the component layer described in the previous chapter. In total five nodes represent the Load, the PV-System (Photovoltaic System), the CHP-Unit (Combined Heat and Power Unit), the Battery-System and the Utility-Grid. The blockchain is established between these actors. For this purpose three of them are active miners and two of them are passive nodes. Powerful laptops are used for the miners, while Raspberry Pis are used for the nodes. Since the goal is to show, that the implementation of the blockchain in this scenario is possible, the focus lies on a proof of work. The central aspect of this implementation is the communication between the different nodes in form of a smart contract.
The 5 nodes and their caracteristics within the network:
The Load node is only able to conusme energy
The PV-System is generating electricity and is acting as an energy supplier
The CHP unit generates electricity and therefore acts as a supplier
The battery can store and emit electrical energy and is therefore able to act as a supplier or a consumer
The Grid is an electrical network for delivering electricity. It can act as a supplier or consumer
The Minimum Viable Product (MVP) can be derived from the previous assumption, that the central aspect is the communication between the nodes. Since the technical concept has a broad scope, the MVP got split up into two parts. The fundamental starting point for both aspects is the construction of the private (permissioned) blockchain based on the three miners and the two nodes. Based on this, the first step in the MVP is to develop a smart contract with different methods to enable the communication between the nodes. This includes methods to offer amounts of energy by supply nodes, methods to buy the offered energy by demand nodes and the transfer of ether between the involved parties. The second part of the MVP is to include the data generated by the Matlab simulation. The previously developed smart contract should be deployed with the provided data and automatically executed between the best fitting parties, with regards to offered amount and cheapest price.
The MVP is visualized in the following figure. Because of the broad scope, the focus lies on the basis and the first part of the MVP in this hackathon (illustrated in green in the figure).
There are three different ways in which communication via smart contracts can be ensured:
Variant 1: There is one smart contract that all parties access and through which each transfer is regulated
Variant 2: There are several smart contracts between always two parties. All of these smart contracts are always executed for one transaction, however for most, there will be no transfer of ether.
Variant 3: There are several smart contracts between always two parties. Only one of these smart contracts will be executed for one transaction.
The first Variant is the most suitable one, because for the other variants, there would be multiple work to be done. Since this would further restrict the available time, but the proof of work is fesaible with variant 1, option two and three drop out. In addition, every smart contract that gets executed, whether it is needed or not, costs (since every mathematical operation that is performed must be paid). This is another reason for why variant 2 is not chosen. Additionally for the third variant, a upstream logic has to be implemented, to determine which contract has to be executed. Because of cost reasons this logic should not be implemented in a smart contract itself, but must be determined beforehand. Since the MVP concentrates on the communication between smart contracts, this upstream logic is not part of the goal. Hence this option will not be implemented. Variant 1 is chosen because it is suitable for the Proof of Work and at the same time relatively easy to implement.
For testing, three laptops were set up as miners and two Raspberry Pi 3 as nodes.
Raspberry Pis were chosen because they are cheap and easy to set up compared to laptops or computers. Also, the computing power should be sufficient to operate a node.
The Raspberry Pi has been assembled according to the instructions included in the box and has a USB mouse and USB keyboard connected. A screen was connected via HDMI cable and a LAN cable was plugged in. After the installation they were operated via Wi-Fi.
The installation of the Raspberry Pis was done according to the instructions of ChainSkills. This series of tutorials describes how to set up a private Ethereum blockchain that will be composed of a computer (miner) and one or several Raspberry PI 3 devices (nodes). There, the concrete commands for the command line can be found.
The setup of the Raspberry Pi requires the following hardware:
A Raspberry Pi
An SD Card with at least 16Gb
A LAN cable
Steps to perform
Format the SD-Card in FAT32.
Download the Raspbian image and write it to the SD-Card using Etcher.
Make some preferred adjustments (language, keyboard layout, Wi-Fi, SSH).
Connect via PuTTY.
Install and run Geth.
For the installation of the Ethereum miners on Windows computers, the instruction of ChainSkills can be followed. There, the concrete commands for the command line can be found.
Steps to perform
Installation of Geth
Initialization of a private Blockchain with our genesis.json file for each miner.
Creation of accounts for each miner and node.
Preparation of each miner with the start parameters.
Testing of each miner.
Deleting the chaindata of each miner.
Pairing and synchronizing of the three miners by configuring our static-nodes.json parameters. (Hardest step.)
Pairing and Synchronizing the Raspberry Pis with our miners by configuring our static-nodes.json parameters.
Connecting to our mining network via Mist browser.
Characterisics of the Blockchain that was setup:
The network is established as a private or permissioned Ethereum blockchain
In total there are five nodes; two of them are passive nodes, three of them are active miners
As node implementation language Go was used, because Geth makes use of this specific language
The focus lies on a proof of work to show the possibility of the implementation in the given business use case