3.3. Smart Grid Security Performance and Blockchain Smart Grid Perspective
This study uses Blockchain in the share method structure used in the existing Blockchain and structured seven new chain methods using Rainbowchain including Blockchain.
If the certificate method is a centralized structure where CA and Roof-CA play an important role in the center, Rainbowchain verifies seven safe share methods escaping the first share method through seven various kinds of verification methods of Blockchain.
This is because security issues can arise with respect to a Blockchain due to the development of quantum computing. As for the competition of compensation, the transaction recorded on the block through reasonable decision-making can have an individual node. The problem is that the individual node must have synchronized to disperse risks. The resource retention of participating nodes wants all compensation. It is necessary to announce the most suitable purpose of compensation, and it must be shared reasonably. It is therefore necessary to provide compensation for competitive participation. Further, the information path is not a right in a specific place; it is owned by the subject creating information. If the subject creating information is recorded on a specific platform as a value of information and if the compensation is given through the value of the relevant record, it can be said that the value attribution is transferred. The problem is that it is difficult to verify that the value transfer is not an initiated value. Thus, Rainbowchain was proposed.
Blockchain is confirmed through the verification of Rainbowchain (
Figure 4). The Rainbowchain architecture is a tool to assist in rational decision-making. In addition, rational physicians will try to distinguish between meaningfulness and connectivity, and the transactions recorded in the blocks are held separately for each node. The problem is to distribute the risk by synchronizing all the nodes in each group. All you have to have is a book on individual transactions. It is important that you keep your books on individual transactions in hand. This should lead to the transaction of the node, whose verification of the block has been confirmed.
All the resource holding behaviors of the participating rainbow nodes want compensation. It is necessary to publicize what is most suitable for compensation during the resource maintenance act and share it reasonably. In order for this rational sharing to be undermined, we must determine the reasonable price for compensation that has a positive impact through the Rainbowchain theory. However, such a reasonable price decision should make the mode node fall into a prisoner’s dilemma. Here, the goal is to prevent the actors in the prisoner’s dilemma from making dangerous—though rational—decisions that will ultimately have negative implications for all the actors involved, and instead to reduce the risk of bad decision-making so that choices can be made that provide the best benefit. Thus, we need a game to encourage competitive participation.
These measurements serve to extract information about the process of the transaction. The path of information is not the right of a specific place but of the subject who created it. If the subject who created the information is recorded on a specific platform with the value of this information and wants to be compensated through the value of the record, the attribute of the value can be said to have been transferred. The problem is that it is difficult to prove that the transfer of these values is their leading value. It can also be a Byzantine process to compare whether values interpretations are favorable.
We assume that the rainbow nodes are A, B, C, D, E, F, and G. B, C, D, E, F, and G are allowed to participate in the probability that “0” will be generated according to the degree of difficulty of the hash of transaction of node A. We also assume that the following are true:
This participation is not necessary.
This participation must be rewarded.
This participation is granted at random.
In this paper, we propose a new method for selecting random nodes in order to reduce the number of random nodes.
Random nodes do a PoW (Proof of Work) to produce a result whereby the hash of the transaction is “0” according to the difficulty of the transaction. If a nonce is found to be “0”, it compensates according to the nascent value criterion constant from the first node to the last node that is found or not found.
The nonce of the first node that found the nonce is written to the block.
The node A does not participate in the operation of the next node A in order to prevent the one-way hash of the node from increasing. However, if it is not an operation of node A, participation is possible, and the possibility is low. Also, we want to eliminate random node operation and irrationality.
The following is a description of node creation of Rainbowchain (
Figure 5):
How to create a block;
Information to put in a block;
Rainbow chain trust credentials (trust: trust of business relationship, trust of time);
Unstructured blockchain: proof-of-work;
Orthogonal Whitechain: proof of block;
Increased reliability, increased security, increased availability;
Unstructured Blockchain;
Orthopedic Whitechain;
Based on Whitechain nodes through physical information.
Rainbowchain and the work node are determined by adjusting the block difficulty according to the participation rate and the coin trading volume. The difficulty determination is based on the acceleration of the traffic limit curve. In order to prevent infinite increases of the transaction compensation by the seismic cancellation rate, the addition of the previous block is calculated based on the increase/decrease ratio of the previous block based on the limit model. The difficulty constant of the traffic limit curve in the difficulty determination model is called the limited ovarian number threshold multiplier.
Also, the informal chain means that the structure of one block is not defined. This means that the attributes that make up the block are not structured. The existing Blockchain is structured with continuous bits, which is a limitation for application to the smart grid energy.
The elements constituting the informal chain have hash points considering extended chains in order to avoid using the fork method. The hash point is a structure for linking other chains considering that the existing chain structure should be extended. If the existing Blockchain is an independent chain structure of P2P and the block is exchanged through the fork, the unstructured chain structure we have devised is a way to maintain a connection link that utilizes extensions in view of the inability to create a full agreement between peers due to unstable network suspension behavior through these forks.
In addition to adding fields and adding and modifying tables in existing databases, you can extend them with a hash pointer to the element of the formatting block, just as you would add a field to the reference the table’s index.
These extensions can create processes for the interworking of various services and become flexible because the nodes in the central network can apply spontaneous extensions. If the length of the existing block is set to the standardized size, the informal chain allows the length of the block to be varied. Because the length of the variable block can extend infinitely, the concept of time to limit it is applied to induce a marginal block increase, thereby preventing the transaction from overflowing.
Trust in a Rainbowchain also means that transactions and time must at least have synchronous time intervals. The criterion for determining that the time interval is synchronous is that the process of confirming when the transaction has occurred should be through the Rainbowchain. The block transmitted through the Rainbowchain is time-sensitive considering the network transmission state of not exceeding 255 TTL: Talent Tech Lab (transactions that have gone to the router with time to live) is generated.
The trust to be described here is that transactions and time must have at least synchronous time intervals. The criterion for determining that the time interval is synchronous is that the process of confirming the point in time of the transaction should be through the Rainbowchain, and the blocks transmitted through the Rainbowchain should be transmitted over a network transmission rate not exceeding 25 TTL (10% of 255). This means that the time recognition considering the state has occurred.
The chain that maintains the trust is called the verification chain. In order to derive the agreement of the unstructured block, the hash of the previous block and the verification block are concurrently referenced so that the time information has the attribute of consensus.
In addition, it provides the trust of the generated block. It means to contain all the transaction information in 3 s, because it is an irregular block. It means to solve the situation where the false information in the Byzantine problem is not reached within a certain time. All block generation takes place every 3 s, and all transaction information should be contained within the 3 s interval, after which the block verification and time synchronization should be done.
You also have to define a hash function as follows:
The cipher block of the data created by applying the value of the specific header must be verified by using the block information of the Whitechain.
To prove a block, the role of the RainbowChain has an approver (intermediary) function that creates a block with a structured structure and generates the next block using the hash of the pointer issued by the chain. This sequence of information allows the next block to determine the degree of difficulty. The formula (t) block generation method for the hash generation cycle is reflected through the API relation used in the authentication and transaction process.
Finally, the intermediary role determines the hash difficulty based on the number of occurrences (frequency) of the transactions and the information associated with the previous block, and the next block is spontaneously generated every second. If no transaction occurs, a block is created. Therefore, users can create the difficulty and hash code generated in the previous block in the trusted role. The hash code is used to generate code that is interpreted based on the CPU (central processing unit), and it plays a role of maintaining the compensation of the block as long as the participation in the block continues. In addition, the role that maintains the block is maintained as an open pool of P2P, and the private key can be maintained over the broadcast network defined by the unstructured Blockchain.
The architecture is defined as a Rainbowchain architecture for smart grid measurements. It is proved from the creation of Rainbowchain. Each block has the hash of the previous block and the level of difficulty needed to contain a rapid transaction, to compete, and to compensate the transaction. With this level of difficulty, the number of “0” s generated to the block is found. Such verification is made through all nodes, which enables enhanced reliability.
A block quickly contains transactions, and it has reliability of transaction in terms of confidentiality, usability, functionality, and interoperability (
Figure 6). To prove integrity and to prevent denial, the transaction does not use saved nodes but provides random rights to other participating nodes. In this way, it forms a consent structure that verifies through the outcome of “0” in a specific time. Such a system is applied to the smart grid system and the energy exchange in order to design the systematization of power exchange and energy exchange.
Also, see the class diagram using Rainbowchain among the Blockchains (
Figure 7). We designed the Rainbowchain class using power, AMI, and an instruction table. We also designed a diagram of the Rainbowchain security scheme (
Figure 8).
If the trajectory in the
X direction of the end-effector is to be generated by reflecting location, velocity, and acceleration by making use of the Rainbowchain, then the trajectory can be expressed in the five-level polynomial equation about time,
t, as follows:
The above Equations (1)–(3) show six unknown numbers of A, B, C, D, E, and F, so we need six equations to obtain each of them.
If the value
t = 0 and the value
t =
T are as shown above, we have three initial conditions in Equation (4) and three final conditions, so we can obtain
A,
B,
C,
D,
E, and
F, the coefficients of the polynomial equation. If
t = 0, then
S(0) =
F =
S0, and F will be found by linear simultaneous equations. Therefore, if put in the format of a matrix, then it will appear as follows:
In the equation used to obtain A, B, C, D, E, and F, as shown in Equation (5), if the inverse matrix of the 6 × 6 matrix is multiplied on both sides, you will find that security is more enhanced than when we use Rainbowchain by creating a speed profile.
In pseudo Java code, a block is an individual unit constituting a Blockchain, and each block is connected to form a Blockchain. The key component of the block is the previous block’s hash information and transactions that are needed for the Blockchain connection. Each block has a value of the previous block hash in the block header, parent block. In this way, going back to the parent block, you will see the first block that can no longer find the parent, which is called the genesis block (
Figure 9).
Also, the block size, block header, transaction counter, and transaction information is defined as follows:
Block size: The block size is the size of the data except this field is expressed in bytes.
Block header: The block header is an object that contains the metadata of the block.
Transaction count: This field stores the number of transactions.
Transaction: A collection containing transaction information.
Now, in order to create a new block using the verification method of seven techniques of Rainbowchain, a hash value of a previous block to which a corresponding block is to be connected is set. The block hash value is not stored in the form of data in the block.
Figure 10 is a code that applies the above-described “Rainbow SHA-256” algorithm by adding the get block hash method to the block class to quickly perform block hash computations on the node.
In
Figure 11, you can see some strange occurrences in that the value of the block hash does not change even if the contents of the transactions are modified. If the transaction is forged, the value of the block hash is changed. Therefore, the previous block of the connected block does not match the previous hash value of the connected block. However, this code does not change the value of the block hash even if the array of transactions is changed. This is because the transaction history does not affect the block header data, while minimizing code writing to understand the concept. In the real Blockchain implementation, the contents of the block header are changed because the transaction details affect the Merkel root hash value in the block header. That is, the value of the block hash created through the data of the block header is also changed.
This being so, we will modify the code slightly so that the value of the block hash can be changed when the transaction is forged. First, in order to make the transaction history affect the block header data, after receiving the transaction details as a factor of the block header constructor, we modify the code to calculate this data by using a certain method (someMethod).
Figure 12 and
Figure 13 show an implementation in this content, and the computation logic of the actual muckle hash value is omitted.
The output code of the first block generation and block hash is now shown in
Figure 14. It can be seen that the change in the transaction details affects the value of the actual block hash.
Now that we have completed the creation of the initial block and the output test of the block hash, we will see how the Blockchain operates by creating two additional blocks and concatenating them to the original block.
Figure 15 generates two blocks and sets the hash value of the previous block to the previous block hash value of the linked block. Here, we confirm that when changing the floor value of the previous block, not only the hash value of the corresponding block, but also the hash value, is changed. However, if the transaction details of the second block are modified, there is no change in the hash value of the first block.
If you actually run this code, you can see that when you change the transaction history (string) of the previous block, the hash value of the block, as well as the hash value of the next block to be linked, are changed. Because of this chain effect, to change the transaction history of one of the blocks constituting the Blockchain, all the blocks associated with the block must be recalculated.
So far, we have implemented the structure of Java code to advance the security performance through the implementation of the data structure of the block constituting the Blockchain and the operation method of the Blockchain through the Java code.
We also show that the performance is improved when we derive the result using Rainbowchain using MATLAP using the blockchain algorithm.
We define the security performance, defense rate, and TPS (transactions per second) performance of the Rainbowchain as three values: acceleration, velocity, and position.
Also, measuring the security performance of Rainbowchain using MATLAP (
Figure 16) proves that the security is excellent.
We have simulated the security protection performance of the existing smart grid network by defining maximum concurrent, real-world traffic throughput, and HTTP (Hyper Text Transfer Protocol) response time.
The above graph shows the existing smart grid network (
Figure 17) and maximum concurrent (after generating a normal HTTP session, sending an exploit packet will result in a nonstateful).
HTTP response time (44 KB, 21 KB, 10 KB, 4.5 KB, and the maximum throughput for HTTP response size of 1.7 KB) and the real-world traffic throughput (
Figure 18) show that the TPS and throughput values are slightly higher when the test data are simulated. Therefore, security performance is improved.
As a result, when we simulate using Rainbowchain, we can see that the maximum concurrent, which is the security performance, is increased as shown in
Figure 17.