6. Development of Technical Concept
Last updated
Last updated
The following picture gives an overview over the technical concept and will be described in detail afterwards.
The picture shows an example how the smart contract works: The PV system transmits an energy token to the grid and the grid pays for the energy with Ethereum. The necessary information are combined in a Smart Contract which is explained by the rest of the figure.
The initiation of a smart contract starts in the Matlab simulation. Obviously, in a real-life scenario this would be implemented in the smart contract's logic. The simulation generates data every 15 seconds and transfers the data to the JavaScript Webserver via UDP. The data includes the prices for the energy and the needed or provided amount of energy. This information is going to be part of the Smart Contract between (for example) the PV system and the grid. Every Smart Contract is deployed with truffle and has an individual identifier (the so-called address) and an ABI. When the Smart Contract is completed, the energy can be provided/used and the price is payed.
The Raspberry Pi has been assembled according to the instructions included in the package and a USB mouse and USB keyboard were connected. In the next step a microSD card was prepared with the use of a laptop. It was first formatted with the SD Formatter 5.0 for SD/SDHC/SDXC Tool application to make it writable. According to another manual, the operating system image (RASPBIAN STRETCH 4.14) was downloaded and transferred to the microSD card. Then the microSD card was inserted into the Raspberry Pi, the Micro-USB power adapter was connected and the Raspberry Pi started. The Raspbian installation was started by Raspbian itself before the language, the keyboard layout etc. were set manually and a user account (user name: pi, password: raspberry) was created.
It is recommended to use the Root-Account (command: sudo su) because one needs root permissions for everything. This has to be considered even after a restart of the Raspberry Pi. We will use our Raspberrys for different roles: Four will be used as miners while one will be a bootnode. But first of all we need to install geth - the go implementation of an Ethereum client - on all of our nodes. A big thank you to Salanfe from Hackernoon whose tutorial was used for this project.
1. Installing GETH
First we need to update the current Raspbian image on all our Raspberrys.
Afterwards we can install the necessary dependencies: git, go and libgmp3.
Now we create a new directory within our workspace which for us is "/usr/local/bin" and download the source code from github.
We use the make all command because we ran into some trouble with the standard make. In theory this should suffice for the four miners but there is no real disadvantage in using make all. Now that the foundation is laid let's set up the miners.
2. Setting up the Miners
Repeat these steps for each of the four raspberries (miners). First create the workspace. This is due to better clarity.
In our workspace we can use geth to create an account for the individual node.
This will generate a new account. This account will be linked to an unique account-address. Save this address in an easy to access file where you collect all the generated addresses for all the accounts. You will need them later.
3. Creating the network
By now you should have created four miners but you still have no Blockchain. For this we use the puppeth script that comes with the geth installation (Another benefit of using make all). This script will generate the genesis block we will be using for our own private Ethereum chain. You can execute this script on any computer that has geth with all executables installed. But remember that we will have to copy the genesis file to every other node.
Let's execute puppeth:
This will open a dialog. Since the Raspberries have very limited resources we can't really use proof-of-work. Since we are on a private network we will just use proof-of-authority as our consensus algorithm. That's one big advantage of puppeth - we can just say so in the build process. For our PoC we used a block time of five seconds. However there is no reason not to use another time. We need to specify accounts that are allowed to seal (mine) and accounts that are prefunded. For both points we use the four accounts we created beforehand.
After this you can stop puppeth with CTRL + C.
We could potentially just leave the gas-price at 0 so we would not need to prefund the accounts. However this could potentially result in unwanted behaviour (like nodes refusing to execute smart contracts). Prefunding the accounts makes them so rich that running out of Ether should not be a problem in the near future.
4. Initializing the nodes
The genesis.json file we just created must now be copied to every node. Be careful that you do not change it as every node has to be initialized with the exact SAME genesis-file. Copy the file to our geth directory /usr/local/bin. Execute the following command on every node.
5. Create a bootnode
Now we may have a network but our nodes do not know how to find each other. For this we will use the already mentioned bootnode. Potentially you could just do the following on one of the four nodes we configured to be miners. However this would require some extra attention to IP-addresses and ports. Therefore we used an extra Raspberry for the bootnode service. A bootnode's only purpose is to inform the other nodes about nodes in the network similar to what a router does in the standard IP-world. Yet another advantage of using the make all installation of geth: it comes with a bootnode executable.
This creates a value called the enode uniquely identifying your bootnode and we store this enode in the boot.key file. The keys are currently still in the overall keystore directory. We have to copy them to their respective node directories.
Obviously your keystore file has some name unique to it. It is definitely not called UTC-... .
1. Start the bootnode service
You are now ready to start your network. Let's start our bootnode first.
After we start our nodes we will see them ping-ponging each other in this window.
2. Starting the nodes
Now we will use one big command to start the individual nodes. The command is specific for the respective nodes. Therefore there are some variables (labelled with { } brackets) in it that are explained below. Do the following for every sealer and your network should be up and running.
This command should be executed as one. The line breaks are only used for sake of visualization.
ip-address: The node's ip-address
bootnode: The enode value that was saved in the bootnodes boot.key file
account: The account that was created on the individual node
The bootnode value can also be seen after starting the bootnode-service.
