A blockchain-based lightweight peer-to-peer energy trading framework for secure, high-throughput microtransactions

A blockchain-based lightweight peer-to-peer energy trading framework for secure, high-throughput microtransactions

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

Figure 3
A blockchain-based lightweight peer-to-peer energy trading framework for secure, high-throughput microtransactions

Work on proposed framework elements.

Figure 3 is an illustration of the schematic of various modules of a purported peer to peer energy trading framework using the IOTA blockchain in accordance with the present invention. A user connected to solar panel 100 is an energy producer that sells its energy to consumer units 111. For our invention, we used a small panel capable of charging our 12 V rechargeable battery. 101, 102 and 103 are single channel low cost INA219 current/voltage/power sensors that come in the form of a breakout board and are connected to the Raspberry PI controller pins 105. A potentiometer 106 is a variable resistor placed in the circuit to simulate variable current consumption from battery 104. We used a 12 V small battery 104 with enough voltage to light a bulb or charging mobile on the consumer side. Then, at intervals of 1 hour, we calculated the average power consumption for that period and multiplied by the time (1 hour) and the energy price in IOTA’s network 108 they both agree on through smart contract. Finally, after an interval of 1 hour, PI automatically creates a new IOTA transaction and transfers the calculated IOTA Trinity wallet 110 from the consumer to the producer address before a new period starts. The Wi-Fi module 107 and the device controller 109 are used to communicate with the IOTA NW. First, we take a single Raspberry PI 3 with an attached power monitoring sensor and put it in the power circuit between the producer batteries and the consumer lights. Every second we let the PI take a reading from the sensor and log the current power consumption. Then, on a predefined period of time (ie 1 hour for our proposed work) we calculate the average power consumption for that period and multiply by the time (one hour) and the energy price in IOTAs they both agree on. So all simulation does not go through PI 3. Finally, after each period (1 hour), PI automatically creates a new IOTA transaction and transfers the calculated IOTA tokens from the consumer to the producer address before a new period starts. Tables 5, 6 and 7 in the results section have been revised representing the Raspberry PI 3 estimated time (is) to create payload, attach to the tangle and retrieve data from the tangle. The JavaScript code for this work contains some important variables like payment frequency variable defines the period in seconds from which we calculate the average power consumption and issue the IOTA payment transaction. The MW price variable specifies the price of IOTA’s per milliwatt/second (mW/s) energy as shown in Listing 4. Any decimals from the calculated IOTA transaction value are removed as we cannot send fractional parts of an IOTA.

Table 1 Specifications and hardware requirements for comparison of proposed P2PET
Table 2 Case I: energy trade simulation between two different communities.
Table 3 Case II: energy trade simulation within the same community.

Setting up an IOTA node and seed generation

The IOTA node is installed on a local machine. The IOTA node has integrated with the energy trading application. Although IOTA supports many languages, we considered Java. The Opening time version 10.0.2 has installed in a Ubuntu 18.04.4 machine for the proposed application. Then we run the IOTA node after installing iri java file. The IOTA node is configured by setting the parameters i iri.ini and a script to start the IOTA network. The complete requirements with their specification are shown in table 1. Finally when the node is running, we found that the db and the logs for that node have created. It provides two basic implementation specifications, one is iri and another is IOTA wallet. To run the java archive, we created a script file called start.sh. we used the screen command to create node in console mode in the background. The basic configuration i 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. The IRI port is configured so that the node will expose all its interfaces. The UDP receiver port is used to receive the connection from its peers to synchronize the Tangle node. The neighbor’s configuration has the address of the neighbor’s peer that the node needs to create a synchronized database called tangle. The IXI directory is the directory of extensions such as messages that IOTA offers. The HEADLESS flag indicates that we do not run the nodes to connect to a ledger wallet. Listing 1, 2, 3 show how the neighbors are added, connected to the Tangle, and broadcast to all nodes. Figure 4 shows a sample of the IOTA transaction bundle structure. Correspondingly, fig. 5 for designing masked payload energy data for the consumer. To interact with the IOTA network these commands are executed. We found the log files by following them.

Figure 4
figure 4
Figure 5
figure 5

Masked payload energy data to the consumer.

Deployment of nodes and address generation

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

figure d
figure e
figure f
figure g
Figure 6
figure 6

DAY before and after allocation of the new transaction issued by node C10.

Table 2 shows that the scenario for energy trade between two communities has been simulated. The producer group participant must broadcast or request their amount of energy to sell. Although they produce a sum of 66.5KW, but they have to sell only 50kw to consumers on the specified date and time. The IOTA Tips selection strategy 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 sale. Figure 6 shows the Tangle structure of our proposed model, where node C9 and C7 are the tips before the arrival of new transaction C10. The shown DAG of the proposed framework can generate a cumulative weight of 50. Consider that each of the producer pool participants has 0 tokens as a balance except for P107. After the energy trade is completed, the energy transaction and payment of IOTA tokens are updated in Table 2. Similarly, Table 3 indicates energy trade within the same community. Although P107 is a producer and produces very less amount of energy and needs 10KW more amount of energy. It has been observed from table 2 that the remaining quantity, ie 11.5 KW, is available for trade among themselves in the producer community. Participants 107 of the manufacturer want to buy 20KW with the same condition. After 50KW trading is over, participants P101, P104, P105, P106 have a balance of 5 KW, 2.5 KW, 1.5 KW, 1.5 KW. So the energy transaction of 10 KW for 100 token takes place. Finally, the values ​​are updated in table 3.

Figure 7
figure 7

IoTA network node management.

Figure 8
figure 8

Producer, consumer token transfer.

Figure 9
figure 9

IoTA node initialization and milestone retrieval.

Figure 10
figure 10

Publication of manufacturer data to confuse.

Figure 11
figure 11

Consumers pick from the mess.

Table 4 Summary of performance evaluated for proposed P2PET IoTA nodes.

Setting up energy trading application by Java client (API)

We run IOTA nodes on Raspberry Pi 3 as a lightweight node along with current and voltage sensor (INA219) for publishing to and retrieving 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 set up the java IOTA client (JOTA) and ran the API through some test cases. Iota java is installed which is a repository for IOTA Ledger. To interact with IOTA, we build an address through the Trinty wallet that generates seeds. Furthermore, we provided the protocol i.e. https, hostname and port as it runs locally. Provides the local PoW through the Perl driver which is an engine that generates POW locally. Created the client separately where the SSL certificate was introduced. To generate an address, an IOTA needs a seed. Seed is like a password or private key that is assigned to an address. We received the hash for the tips. The effect of the transaction by sending to the API has been found out. 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, a list of addresses is added. The getInputs function returns the combined balance of all the addresses available to our seed. It also transfers IOTA from one seed to the other. Passed the hints to find the hash of the milestone transaction. Attach to Tangle is an API required to perform PoW and submitted.

See also  Facebook and Twitter will soon be obsolete thanks to blockchain technology

Deploy and integrate IOTA network

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

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *