A blockchain based lightweight peer-to-peer energy trading framework for secured high throughput micro-transactions

In this section the schematic of different modules of implemented Peer to Peer energy trading framework using IOTA blockchain in accordance with the present invention. A user connected to solar panel is an energy producer who sells its energy to consumer devices. A single channel low cost INA219 current/voltage/power sensor that comes in the form of a breakout board and is connected to the Raspberry PI controller pins. A potentionmeter is a variable resistor placed in the circuit to simulate variable power usage. At interval of 1 hour (callback function of MAM) we calculated the average power usage for that period and multiply with the time (one hour) and the energy price in IOTA’s network they both agree upon through smart contract. Finally, after interval of 1 hr, the PI automatically creates a new IOTA transaction and transfers the calculated IOTA light wallet 2.5.4 wallet tokens from the consumer to the producer address before starting a new period. The WiFi module and device controller are used to interface with the IOTA NW.

Figure 3 is an illustration of the schematic of different modules of claimed Peer to Peer energy trading framework using IOTA blockchain in accordance with the present invention. A user connected to solar panel 100 is an energy producer who sells its energy to consumer devices 111. For our invention we used a small panel capable of charging our 12 V rechargeable battery. 101, 102, and 103 is single channel low cost INA219 current/voltage/power sensor that comes in the form of a breakout board and is connected to the Raspberry PI controller pins 105. A potentiometer 106 is a variable resistor placed in the circuit to simulate variable power usage from battery 104. We used a 12 V small battery 104 with enough voltage to light up a bulb or charging mobile at the consumer side. Then, at interval of 1 h we calculated the average power usage for that period and multiply with the time (1 h) and the energy price in IOTA’s network 108 they both agree upon through smart contract. Finally, after interval of 1 h, the PI automatically creates a new IOTA transaction and transfers the calculated IOTA Trinity wallet tokens 110 from the consumer to the producer address before starting a new period. The Wi-Fi module 107 and device controller 109 are used to interface with the IOTA NW. First we take a single Raspberry PI 3 with an attached power monitoring sensor and puts it in the power circuit between the producer batteries and the consumer lights. Then, every second we have the PI take a reading from the sensor and log the current power usage. Then, at some predefined period of time (i.e. 1 h for our proposed work) we calculate the average power usage for that period and multiply with the time (one hour) and the energy price in IOTA’s they both agree upon. So all simulation does not pass through the PI 3. Finally, after each period (1 h), the PI automatically creates a new IOTA transaction and transfers the calculated IOTA tokens from the consumer to the producer address before starting a new period. The Tables 5, 6 and 7 in the result section has been revised that represents the Raspberry PI 3 estimated time (in s) to create payload, attach to the tangle, and fetch data from the tangle. The JavaScript code for this work contains some important variables such as pay frequency variable defines the period in seconds from where we calculate the average power consumption and issues the IOTA payment transaction. The mW price variable specifies the price of IOTA’s per milliwatt/second (mW/s) of energy as shown in listing 4. Any decimals from the calculated IOTA transaction value are removed as we cannot send fractions of an IOTA.

Setting up an IOTA node and seed generation

The IOTA node has been installed on a local machine. The IOTA node has integrated with the energy trading application. Although IOTA supports many languages, we considered Java. The Openjdk version 10.0.2 has installed in an Ubuntu 18.04.4 machine for the proposed application. Then we run the IOTA node after installing the iri java file. IOTA node is configured by setting the parameters in the iri.ini and a script for starting the IOTA network. The complete requirements with their specification are shown in Table 1 Finally when the node is running, we found the db and logs of that node has created. It provides two basic implementation specification one is iri and another is IOTA wallet. To execute the java archive we created a script file named as start.sh. we used the screen command to create node in console mode in the background. The basic configuration in iri.ini is set by setting the IRI port number to 14265, UDP_RECEIVER_PORT=14700, neighbors, ixi_dir, headless, debug, testnet and db_path. IRI port is configured so that the node is going to expose all its interfaces. The UDP receiver port is used to receive the connection from its peers to sync up its Tangle node. The neighbor’s configuration has the address of neighbor of peers that node needs to create a synced up database called tangle. The IXI directory is the directory of extensions like messaging that IOTA provides. The HEADLESS flag indicates that we are not running the nodes to be connecting to a ledger wallet. Listing 1, 2, 3 shows how the neighbours are added, attached to Tangle, and broadcast-ed to all node. Figure 4 shows a sample of IOTA transaction bundle structure. Similarly Fig. 5 refers to designing Masked Payload Energy Data of Consumer. To interact with IOTA network these commands are executed. We found the log files by tailing them.

Deployment of nodes and address generation

The Node.js, Rock DB and IOTA nodes have been installed. To run the client application the Javascript and React.js are installed. Deployment of the application is done in our local network. Both Hornet and Java IRI software are installed to run the nodes in IOTA network. It provides the facility to read and write access to the Tangle which also validates the transaction by the nodes and finally stores the transaction to the ledger. Other prerequisites are a dual core CPU, 4GB RAM, public IP address, storage docker and some other ports for internet. To, get the latest snapshot we migrated from IRI to hornet. To receive the transaction we create address. The function used for address generation are (gen_new_address(index, ,count, , security , level)). Index is the starting value for address generation. Count is the number of addresses that will be generated. We consider the security level as 2 for resulting multi-signature in the transaction.

Table 2 indicates scenario of energy trading between two communities has been simulated. The participant in the producer group has to broadcast or request their amount of energy to sell. Although they produces a sum of 66.5KW, but they have to sell only 50kw to consumers on the specified date and time. The IOTA Tip selection strategy is will consider the highest value (KW) first. As you can see, we have only considered 20KW of P102, 19KW of P103 and 11KW of P105 for selling. Figure 6 shows Tangle structure of our proposed model, where node C9 and C7 are the Tips before the arrival of new transaction C10. The shown DAG for the proposed framework can generate cumulative weight of 50. Consider each of the participant in producer group have 0 tokens as a balance except P107. After energy trading is completed the energy transaction and payment of IOTA tokens are updated in the Table 2. Similarly, Table 3 indicates energy trading within the same community. Although P107 is producer and produces very less amount of energy and need 10KW more amount of energy. It is observed from the Table 2 that the rest amount i.e., 11.5 KW is available to trade among themselves in producer community. Participants 107 of the producer wants to buy 20KW with the same condition. After 50KW trading is over the participants P101, P104, P105, P106 have balance of 5 KW, 2.5 KW, 1.5 KW, 1.5 KW. So, the energy transaction of 10 KW against 100 token takes place. Finally, the values are updated in the Table 3.

Setting up energy trading application by Java client (API)

We run IOTA nodes on Raspberry Pi 3 as a light node along with current and voltage sensor (INA219) for publishing to and fetching data from the Tangle. IOTA provides IOTA java which is a client API that is a thin wrapper over the JSON RPC calls. To interact with the energy trading IOTA application the API was run. Eclipse is used to setup the java IOTA client (JOTA) and ran the API through some test cases. Iota java is installed which is a repository of IOTA ledger. To interact with IOTA, we build an address through Trinty wallet which generates seeds. Further, we supplied the protocol i.e., https, host name and the port, as it is running locally. Provided the local PoW through Perl driver which is an engine that generates POW locally. Created the client separately where introducing the SSL certificate. To generate an address an IOTA needs a seed. Seed is like a password or a private key that maps to an address. We received the hashes for the tips. It is found out the effect of transaction by submitting to the API. From the Tangle explorer, we collected an address for which there is a transaction. To retrieve the transaction details like hash, address, timestamp, index values, transaction bundle, branch and trunk transaction, nonce, has been added with a list of addresses. getInputs function returns the combined balance of all the addresses available for our seed. It also transfers IOTA from one seed to the other. Passed the tips to find the milestone transaction hash. Attach to Tangle is an API that is needed to execute PoW and submitted.

Setting and integrating IOTA network

IOTA private network is designed, which is a collection of interconnected nodes, and each node stores a copy of the Tangle through a Hornet plugins. The energy trading private network essential means any access to the Tangle requires permission. Testing of our energy trading application conducted in a local environment. Retrieval of data at any time in future and confirming the signed transaction has been done. The timestamp is attached at which this transaction was sent.