5. Physical implementation in a Test Network

5. Physical implementation in a Test Network

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:

Load

The Load node is only able to conusme energy

PV

The PV-System is generating electricity and is acting as an energy supplier

CHP

The CHP unit generates electricity and therefore acts as a supplier

Battery

The battery can store and emit electrical energy and is therefore able to act as a supplier or a consumer

Grid

The Grid is an electrical network for delivering electricity. It can act as a supplier or consumer

5.1 Minimum Viable Product

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

Parts of the MVP

5.2 Comparison of Alternatives

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.

5.3 Used Hardware and setting it up

For testing, three laptops were set up as miners and two Raspberry Pi 3 as nodes.

Layout of the setup Network

5.3.1 Install an Ethereum node on a Raspberry Pi

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

  • A keyboard

  • A display

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.

5.3.2 Install an Ethereum miner on a computer and initializing the blockchain

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.

Please be aware, that the genesis.json, the start parameters and the static-nodes.json have to be modified so that they fit your needs.

****

Characterisics of the Blockchain that was setup:

Blockchain

The network is established as a private or permissioned Ethereum blockchain

Nodes

In total there are five nodes; two of them are passive nodes, three of them are active miners

Implementation

As node implementation language Go was used, because Geth makes use of this specific language

Consensus

The focus lies on a proof of work to show the possibility of the implementation in the given business use case