Discrete state event-driven energy blockchain system simulation test method

Abstract

A discrete state event-driven energy blockchain system simulation test method, including: constructing an energy blockchain node simulation model and an energy blockchain network simulation model, respectively simulating the core functions of the actual energy blockchain node and network, and abstracting them into node objects and network objects when the program of the simulation test method is implemented; creating a discrete state event set and its event scheduling timing rules for driving the dynamic operation of the energy blockchain simulation model, corresponding to event objects and event scheduling objects when the program of the simulation test method is implemented; designing a discrete state event-driven energy blockchain simulation process, and realizing the simulation of the dynamic operation of the energy blockchain system according to the simulation process. The present invention can flexibly and efficiently simulate the energy blockchain system of large-scale nodes on a single computer, flexibly test the influence of energy blockchain parameters on the operating performance of large-scale energy blockchain systems, and assist in the parameter design of large-scale energy blockchain systems.

Description

Technical Field

[0001] The present invention relates to a simulation testing technology in the field of energy blockchain, specifically a discrete state event-driven energy blockchain system simulation testing method. Background Art

[0002] The engineering process of energy blockchains is steadily advancing. Due to the vast number of entities in the energy sector, the number of energy blockchain nodes is becoming increasingly large. Existing simulation and testing methods for energy blockchain systems primarily fall into three categories: 1. Simulation and testing based on public test chains; 2. Simulation and testing based on self-built test chains; and 3. Simulation and testing based on container virtualization technology. Method 1 can verify the correctness of energy application smart contracts, but cannot test energy blockchain system parameters. Method 2, constrained by time and cost, typically requires only a dozen consensus nodes for self-built test chains, making it suitable only for simulating energy blockchain systems with a relatively small number of nodes. Method 3 can build a multi-node energy blockchain system on a single computer, but when the number of nodes is large, the excessive number of containers exceeds the computer's capacity, limiting the number of simulated nodes to a few dozen, and maintaining significant limitations on simulation scale. Therefore, existing simulation and testing methods struggle to simulate large-scale energy blockchain systems, flexibly test the impact of energy blockchain parameters on their performance, and assist in parameter design for large-scale energy blockchain systems. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this paper provides a discrete-state event-driven energy blockchain system simulation and testing method. This method uses a discrete-state event-driven mechanism to implement dynamic operation simulation of the energy blockchain system. A discrete-state event-driven energy blockchain system simulation model is designed, comprising a node simulation model and a network simulation model, which respectively simulate the core functions of energy blockchain nodes and networks. This provides a complete, lightweight, and flexibly configurable simulation model for the simulation testing method. Based on this simulation model, a discrete-state event set, event scheduling timing rules, and simulation process are designed to implement dynamic process simulation of the discrete-state event-driven energy blockchain system.

[0004] The present invention is achieved through the following technical solutions:

[0005] The present invention relates to a discrete state event-driven energy blockchain simulation testing method, comprising: constructing an energy blockchain node simulation model and an energy blockchain network simulation model to respectively simulate the core functions of actual energy blockchain nodes and networks, which are abstracted into node objects and network objects during program implementation of the simulation testing method; creating a discrete state event set and its event scheduling timing rules for driving the dynamic operation of the energy blockchain simulation model, which correspond to event objects and event scheduling objects during program implementation of the simulation testing method; designing a discrete state event-driven energy blockchain simulation process, and realizing simulation of the dynamic operation of the energy blockchain system according to the simulation process.

[0006] The energy blockchain node simulation model includes: a transaction layer model, a consensus layer model, an application layer model and a data layer model, wherein: the transaction layer model, the consensus layer model and the application layer model respectively simulate the specific functions of the energy blockchain; the transaction layer model includes transaction creation, transaction sending, transaction receiving and transaction processing functions; the consensus layer model includes block creation, consensus message sending, consensus message receiving, consensus algorithm, execution block transaction and block chain function, wherein the consensus algorithm function varies depending on the specific consensus algorithm; the application layer includes: energy business transaction request, energy business execution result data query request, energy business execution result data query processing, energy business execution result data sending and energy business execution result data receiving functions; the data layer includes the transaction pool, blockchain, world state database, and state cache data during system operation, such as cached data in the sending queue, cached messages in the consensus process, etc.

[0007] The energy blockchain network simulation model includes a sending node, a sending node edge link, a sending companion node, an intermediate link, a receiving companion node, a receiving edge link, and a receiving node. Edge links represent all links in the access network portion of the wide area internet (WAN), intermediate links represent all links in the backbone network portion of the WAN, and companion nodes represent the demarcation point between the access network and the backbone network. Links from a sending node to a sending companion node represent a sending edge link, from a receiving companion node to a receiving node represent a receiving edge link, and from a sending companion node to a receiving companion node represent an intermediate link. The delay of each link segment consists of three components: transmission delay, propagation delay, and queuing delay. Transmission delay is calculated based on link bandwidth and data size; propagation delay is calculated based on link distance and the speed of light in optical fibers; and queuing delay is the sum of the transmission delays for data in the queue that has not yet been sent. Because the backbone network bandwidth is much larger than that of the access network, the transmission delay and queuing delay of intermediate links are negligible compared to the transmission delay and queuing delay of edge links.

[0008] The discrete state event set and its event scheduling timing rules include: network discrete state event set and its scheduling timing rules; transaction layer discrete state event set and its scheduling timing rules; consensus layer discrete state event set and its scheduling timing rules; application layer discrete state event set and scheduling timing rules.

[0009] The network discrete state event set includes: Event A0: a certain data is pushed into the sending queue of the sending node, and the execution time is recorded as T A0 ; Event A1: The sending node sends the data event, and the execution time is recorded as T A1 Event A2: The data is pushed into the receiving node's send queue, and the execution time is recorded as T A2 ; Event A3: The receiving side companion node sends the data, and the execution time is recorded as T A3 ; Event A4: The receiving node receives the data, and the execution time is recorded as T A4 .

[0010] The network discrete state event scheduling timing rules include: the execution time of event A0 is determined by the data sending event scheduling generation of the transaction layer, consensus layer, and application layer, and events A1 to A4 are triggered in sequence. The execution time corresponding to each event is: Among them: α is the sending side node, α * is the companion node of the sending side node, β is the receiving side node, β * is the companion node of the receiving side node; They are respectively the sending side node α to the accompanying node α * Transmission delay, propagation delay, and queuing delay of sending data; is the sending side companion node α * To the receiving side accompanied by node β * Propagation delay of sending data; They are the receiving side companion nodes β * Transmission delay, propagation delay, and queuing delay when sending data to the receiving node β.

[0011] The discrete state event set of the transaction layer includes: Event B0: a node creates a transaction, the specific content of the transaction comes from the application layer, and the execution time is recorded as T B0 Event B1: The node sends the transaction and stores it in the local transaction pool. The execution time is recorded as T B1 Event C0: A node receives a transaction and forwards it. The transaction comes from the energy blockchain network. The execution time is recorded as T C0 ; Event C1: The node starts processing the transaction, and the execution time is recorded as T C1 ; Event C2: The node stores the transaction into the local transaction pool, and the execution time is recorded as TC2 .

[0012] The transaction layer discrete state event scheduling timing rules include: event B0 is triggered by the application layer to create a transaction event to trigger the scheduling generation; event B1 is then triggered to schedule the generation, and the execution time of event B1 is T B1 =T B0 +t B1 , where: t B1 The transaction creation time is mainly the signature time of the transaction and the queuing time of the transaction creation process. After the execution of event B1 is completed, it will trigger the scheduling to generate the energy blockchain network data sending event A0; event C0 is triggered by the network layer receiving a transaction data event. Event C0 will trigger the scheduling to generate the energy blockchain network data sending event A0. Events C1~C2 are triggered in sequence after the execution of event C0. The execution time of events C1 and C2 are T C1 =T B0 +t C1 、T C2 =T C1 +t C2 , where t C1 is the queuing time of the transaction processing process, t C2 Transaction processing takes time, mainly due to transaction signature verification.

[0013] The consensus layer discrete state event set includes: consensus initiation discrete state event set, consensus process discrete state event set, and consensus achievement discrete state event set; the consensus initiation discrete state event set includes two events: Event D0: the master node creates a block, and the execution time is recorded as T D0 Event D1: The master node sends the first consensus message of the block, starting the consensus process. The execution time is recorded as T D1 The consensus discrete state event set includes two events: Event H0: A node receives a consensus message that satisfies the consensus, determines that the consensus is reached, and executes the transaction in the block. The execution time is recorded as T H0 Event H1: The node uploads the consensus block to the blockchain. The execution time is recorded as T H1 The discrete state event set of the consensus process is related to the specific consensus algorithm, and an example will be given in conjunction with the embodiments.

[0014] The consensus layer discrete state event scheduling timing rules include: consensus initiation discrete state event scheduling timing rules, consensus process discrete state event scheduling timing rules, consensus achievement discrete state event scheduling timing rules; consensus initiation discrete state event scheduling timing rules include: the execution time of event D0 is determined according to the consensus algorithm rules, event D1 is triggered by event D0 and the execution time is T D1 =T D0 +t D1, where t D1 The time taken to create a block and the time taken to create the first consensus message are mainly the time taken to sign the block and generate the hash summary. Event D1 will trigger the scheduling to generate the data sending event A0 corresponding to the energy blockchain network. The scheduling timing rules for discrete state events of consensus achievement include: event H0 is triggered to schedule when a consensus message that satisfies the consensus is received, and event H1 is triggered by event H0. The execution times of events H0 and H1 are T H0 =T H ′0+t H0 、T H1 =T H0 +t H1 , where t H0 The time it takes to process the last message that meets the consensus is mainly the time it takes to verify the message signature; T′ H0 The time when the last message that satisfies the consensus is received; t H1 It is the execution time of transactions in the block, mainly the execution time of smart contracts. The discrete state event scheduling timing rules of the consensus process are related to the specific consensus algorithm, and an example will be given in conjunction with the implementation examples.

[0015] The application layer discrete state event set includes: Event I0: a node generates the data required for the energy service request according to the energy service demand, and the execution time is recorded as T I0 ; Event J0: A light node sends an energy business execution result query request to an energy blockchain consensus node through the energy blockchain network. The execution time is recorded as T J0 Event K0: A consensus node receives a request to query the energy business execution result from the energy blockchain network. The execution time is recorded as T K0 ; Event K1: This node processes the request to query the execution result of the energy business, and the execution time is recorded as T K1 ; Event K2: The node sends the query result reply data to the energy blockchain network, and the execution time is recorded as T K2 .

[0016] The application layer discrete state event scheduling timing rules include: the execution time of event I0 is determined by the time when the node initiates the energy service request, which will trigger the scheduling to generate the transaction layer event B0 corresponding to the energy service request. Event J0 will trigger the scheduling to generate the energy blockchain network event A0. Event K0 is triggered by the data reception event of the energy blockchain network's query energy service execution result request. The execution times of events K1 and K2 are T K1 =T K0 +t K1 、T K2 =T K1 +t K2 , where tK1 The queuing time for querying the energy business execution result processing process; t K2 In order to query the time consumed in processing the energy business execution results, event K2 will trigger the scheduling to generate energy blockchain network data sending event A0.

[0017] The discrete state event-driven energy blockchain simulation process:

[0018] Step 1: Simulation test starts;

[0019] Step 2: Configure the energy blockchain node model parameters. Once completed, proceed to step 3.

[0020] Step 3: Configure the energy blockchain network model parameters. After completing the configuration, proceed to step 4.

[0021] Step 4: Configure the energy blockchain application simulation data. After execution, proceed to step 5.

[0022] Step 5: Register an account and generate the public and private keys and address of the account. After completing the process, proceed to step 6.

[0023] Step 6: Register the smart contract, generate the contract address and call interface, and then call the contract program file through the reflection mechanism. After execution, proceed to step 7;

[0024] Step 7: Instantiate the energy blockchain node and network model objects to complete the deployment of all nodes and network models of the entire energy blockchain system. After execution, proceed to step 8;

[0025] Step 8: Initialize the event queue, including the creation events of all transactions within the energy blockchain application simulation time and the creation event of the first block. After execution, proceed to step 9.

[0026] Step 9: reset the simulation clock to zero, and then proceed to step 10;

[0027] Step 10: Get an event from the event queue and proceed to step 11 after execution.

[0028] Step 11: The simulation clock advances to the current event execution time, and after execution, it goes to step 12;

[0029] Step 12: Determine whether the simulation has timed out. If so, proceed to step 17; if not, proceed to step 13.

[0030] Step 13: Execute the event retrieved from step 10, and then proceed to step 14;

[0031] Step 14: Generate a future event judgment. If the execution result of step 10 will generate a future event, then the judgment is yes.

[0032] Go to step 15, otherwise the judgment is no, go to step 16;

[0033] Step 15: Insert the future event into the event queue and proceed to step 10 after execution.

[0034] Step 16: Check whether the event queue is empty. If so, proceed to step 10; if not, proceed to step 17.

[0035] Step 17: Statistical analysis outputs simulation test results. If completed, proceed to step 18;

[0036] Step 18: The simulation test ends.

[0037] Technical Effects

[0038] The present invention designs a lightweight, flexibly configurable simulation model that encompasses energy blockchain nodes and core network functions through a discrete state event-driven mechanism. Based on the discrete state event-driven mechanism, the present invention designs a discrete state event set and its event scheduling timing rules that drive the dynamic operation of the energy blockchain simulation model.

[0039] Compared with the existing technology, the lightweight node and network simulation model designed by the present invention, which includes core functions, replaces the real energy blockchain nodes and networks, taking into account the simulation fidelity while significantly reducing the consumption of storage resources, and realizing the construction of a large-scale energy blockchain simulation system on a single ordinary computer. The discrete state event set and event scheduling timing rules designed by the present invention realize the discrete state event drive of the dynamic operation of the simulated energy blockchain system, significantly reduce the consumption of computing resources, and realize high-efficiency dynamic simulation of a large-scale energy blockchain system with hundreds of consensus nodes on a single ordinary computer. The present invention can flexibly test the impact of energy blockchain system parameters on the performance of large-scale energy blockchain systems, and assist in the design of large-scale energy blockchain system parameters. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 Schematic diagram of energy blockchain node simulation model and network simulation model;

[0041] Figure 2 This is a schematic diagram of the energy blockchain simulation process;

[0042] Figure 3 This is a schematic diagram of the average transaction confirmation delay for different numbers of consensus nodes and network bandwidth parameters in the embodiment;

[0043] Figure 4 Schematic diagram of average transaction confirmation delay for different network topology parameters in the embodiment;

[0044] Figure 5Schematic diagram of block delay for different consensus algorithm type parameters in the embodiment. DETAILED DESCRIPTION

[0045] This example simulates an energy blockchain system with 10,000 distribution network users. Each user is a node in the energy blockchain system, and nodes are categorized as consensus nodes and light nodes. Of these 10,000 users, 4,000 have distributed power sources installed, and the distributed power generated is consumed collaboratively with other power users. Energy application services implemented by the energy blockchain system include: sharing information on power surpluses and shortages, allocating collaborative consumption of distributed power, and sharing the collaborative costs of distributed power. These services are implemented through the configuration of corresponding smart contracts within the energy blockchain. Each collaborative cycle is 15 minutes, and the simulation period runs from 12:00 PM to 1:00 PM on a given day, for a total of four collaborative cycles. Taking the Nth 15-minute collaborative cycle as an example, from 0 to 5 minutes, each node initiates a request for sharing surplus and shortage information for the N+1 period; from 5 to 10 minutes, each node initiates a request for collaborative cost sharing for the N-1 period; from 7.5 to 8 minutes, the consensus node initiates collaborative consumption allocation for the N+1 period; from 10 to 12 minutes, each node queries the collaborative consumption allocation result for the N+1 period; and from 12 to 15 minutes, each participating entity arranges its electricity consumption plan for the N+1 period.

[0046] The simulation tests conducted in this scenario include: simulation tests of network bandwidth and consensus node number parameters, simulation tests of network topology parameters, and simulation tests of consensus algorithm type parameters.

[0047] The consensus algorithms include: Byzantine Fault Tolerance (PBFT) algorithm, Delegated Proof of Stake (DPOS) algorithm, PBFT and DPOS hybrid consensus (DPOS+PBFT) algorithm, and Proof of Work (POW) consensus algorithm.

[0048] The discrete state event set of the consensus process of the PBFT algorithm includes: Event E0: The secondary node receives the Pre-Prepare message and forwards the message at the same time. The execution time is recorded as T E0 ; Event E1: The secondary node processes the Pre-Prepare message, and the execution time is recorded as T E1 ; Event E2: The secondary node sends a Prepare message, and the execution time is recorded as T E2 ; Event F0: A node receives a Prepare message and forwards it at the same time. The execution time is recorded as T F0 ; Event F1: This node processes the Prepare message, and the execution time is recorded as T F1 ; Event F2: The node sends a Commit message, and the execution time is recorded as T F2 Event G0: A node receives a Commit message and forwards it. The execution time is recorded as TG0 Event G1: The node processes the Commit message, and the execution time is recorded as T G1 .

[0049] The discrete state event scheduling timing rules of the consensus process of the PBFT algorithm include: Event E0 is triggered by the energy blockchain network receiving a Pre-Prepare message data. Event F0 is triggered by the energy blockchain network receiving a Prepare message data. Event F2 is triggered by event F1 when 2f valid Prepare messages are received. Event G0 is triggered by the network layer receiving a Commit message data. The execution time of events E1, E2, F1, F2, and G1 is T E1 =T E0 +t E1 、T E2 =T E1 +t E2 、T F1 =T F0 +t F1 、T F2 =T F ′1+t F2 、T G1 =T G0 +t G1 , where t E1 The queuing time of the consensus message processing process; t E2 The time consumed in processing Pre-Prepare messages and creating Prepare messages is mainly due to the time consumed in message signature verification and encryption; F1 The queuing time of the consensus message processing process; t F2 The time consumed in processing the Prepare message and creating the Commit message, mainly due to the time consumed in message signature verification and encryption; T′ F1 The time when the 2fth (excluding itself) Prepare message is received; t G1 The queuing time for consensus message processing. Events E0, E2, F0, F2, and G0 will each trigger the generation of the corresponding data transmission event A0 for the energy blockchain network. Consensus initiation event D1 is the master node sending the Pre-Prepare consensus message for the block. Consensus confirmation event H0 is the receipt of 2f+1 valid Commit messages, triggered by event G1.

[0050] The discrete state event sets and their scheduling timing rules of the consensus process of the DPOS algorithm, DPOS+PBFT algorithm, and POW consensus algorithm are similar to those determined by the PBFT consensus algorithm. Corresponding discrete state events are established according to the process steps of the corresponding consensus algorithm to form a discrete state event set, and the scheduling timing rules of the events are determined according to the temporal correlation relationship between the various process steps of the algorithm.

[0051] This embodiment provides a discrete state event-driven energy blockchain simulation test method for the above scenario, specifically including:

[0052] Step 1: Based on the energy blockchain node simulation model, an object-oriented technology is used to create a node model object. Specifically, the node model object's member variables include storage layer data and node information such as node number and node type. The node object's member functions include implementation functions for specific functions at the transaction layer, consensus layer, and application layer.

[0053] Step 2: Based on the energy blockchain network simulation model, object-oriented technology is used to establish a network model object. Specifically, the member variables of the network model object include the topological relationship of the connection between each node in the energy blockchain network, the bandwidth of the link, the distance of the link and other network parameters as well as the network cache data of each node. The member functions of the network model object include the implementation functions of the specific functions of data sending and data receiving.

[0054] Step 3: Based on the discrete state event set that drives the dynamic operation of the energy blockchain simulation model and its event scheduling timing rules, object-oriented technology is used to establish event objects and event scheduling objects. Specifically, the member variables of the event object include the execution time of the event, the energy blockchain node to be called by the event, or a specific function in the network model; the member variables of the event scheduling object include the event queue. The events generated by the scheduling during the simulation process are stored in the event queue in the order of the execution time. The member functions of the event scheduling object include the scheduling generation function of each event, and scheduling is performed according to the scheduling timing rules of each event.

[0055] Step 4: According to the discrete state event-driven energy blockchain simulation process, complete the development of the discrete state event-driven energy blockchain system simulation program based on steps 1-3.

[0056] Step 5: Based on the 10,000-user energy blockchain system case, configure simulation parameters, execute the simulation program, and implement simulation testing of the energy blockchain system.

[0057] The above steps 1-4 do not need to be repeated in multiple simulation tests performed in the embodiment. It is only necessary to change the simulation parameters and repeat step 5.

[0058] The simulation test of the network bandwidth and the number of consensus nodes is as follows: network bandwidth and the number of consensus nodes are used as test parameters; the parameter interval of the number of consensus nodes is [4,200], and the 10,000 users except the consensus nodes are light nodes; the network bandwidth parameters are: downlink 100Mb / uplink 20Mb, downlink 50Mb / uplink 10Mb, downlink 25Mb / uplink 5Mb; a mesh-like fully connected network topology is used between the consensus nodes, and a radial network topology centered on the consensus node is used between the light nodes and the consensus nodes. The light nodes are evenly connected to the consensus nodes, and each light node is connected to the consensus node. The node maintains a backup connection with f (the number of fault-tolerant nodes) consensus nodes, which is activated when the normally connected consensus node fails. The consensus algorithm uses PBFT, and the block time is set to 4s. The propagation delay of the edge link is set to 0.1ms, and the propagation delay of the mid-link is set to 0.2ms. That is, assuming that the communication link distance between any two nodes is 80km, the network link distance of the distribution network user will not exceed this distance. Based on the computing power of ordinary computers, the signing time is set to 0.1ms, the verification time is set to 0.4ms, and the hash calculation rate is set to 200MB / s.

[0059] This test uses the average transaction confirmation delay as a performance indicator to test the energy blockchain system. The relationship between the average transaction confirmation delay and the network bandwidth and number of nodes is shown in the following figure: Figure 3 As shown in the figure, at bandwidths of 100Mb downlink / 20Mb uplink, 50Mb downlink / 10Mb uplink, and 25Mb downlink / 5Mb uplink, the system failed to produce blocks when the number of consensus nodes exceeded 136, 73, and 37, respectively. The test results provide the upper limit of the number of consensus nodes under the corresponding bandwidth conditions, as well as the average transaction confirmation latency for different node numbers.

[0060] The simulation test of the network topology parameters is as follows: the number of neighboring consensus nodes of the consensus node is changed to form different topologies. The number of consensus nodes is 25, the number of light nodes is 9975, the network bandwidth is 100Mb downlink / 20Mb uplink, and the other parameters are consistent with the simulation test implementation of the network bandwidth and node number parameters. The relationship between the average transaction confirmation delay and the network topology parameters is as follows: Figure 4 As shown in the figure, as the number of neighbors increases, the bandwidth usage of a single consensus node increases, leading to increased queuing delays. However, the number of message forwarding hops decreases with the number of neighbors, reducing propagation delays. Since bandwidth dominates the total delay in this simulation scenario, the average transaction confirmation delay increases with the number of neighbors. It should be noted that network topologies with fewer neighbors have poor reliability. When a faulty node exists, the network may become fragmented and disconnected, indirectly increasing the number of faulty nodes and jeopardizing the normal operation of the system. Therefore, when the number of consensus nodes is small and the network bandwidth is sufficient, the consensus nodes should form a fully connected network to ensure system reliability.

[0061] The simulation test of the consensus algorithm type parameters is as follows: using the consensus algorithm as the test parameter, the energy blockchain is simulated and tested for four consensus algorithms: PBFT, DPOS, DPOS+PBFT, and POW. Other parameters are consistent with the simulation test implementation of the network topology. It is set that three consecutive master nodes are disconnected at the same time at 120s. Figure 5 Figure 2 shows simulation results of block latency for four consensus algorithms before and after a failure. The PBFT consensus algorithm requires a lengthy master node replacement process when a master node fails. Three consecutive master node failures resulted in a block latency of up to 56 seconds for the first block (block height 30) after the failure. The latency returned to normal for the third block (block height 32) after the failure. The DPOS algorithm, in which consensus nodes rotate block production according to time slots, continues to produce blocks normally even after a failure, with only a hiccup occurring when the failed node's turn comes. The latency increases to 16 seconds for the 51st block, and normality returns to normal for the 52nd block. The block latency of the PBFT+DPOS consensus algorithm is essentially the same as that of DPOS. The POW block latency is controlled by the Proof-of-Work difficulty, which only controls the average block time. Therefore, individual block latency is random but is minimally affected by node failures. The PBFT consensus algorithm maintains stable low latency for block production and transaction confirmations under normal conditions, but can experience significant fluctuations due to failures. The DPOS consensus algorithm can maintain relatively low fluctuations in block generation latency during failures, but its transaction confirmation latency is relatively high, requiring blocks from two-thirds of the consensus nodes to be confirmed. The POW consensus algorithm is least susceptible to failures and offers the best fault tolerance, but its block generation times are random and lack eventual consistency. Confirmation typically requires six consecutive blocks, resulting in higher transaction confirmation latency and only probabilistic confirmation. DPOS+PBFT combines the advantages of DPOS in maintaining relatively low fluctuations in block generation latency during failures while overcoming the long transaction confirmation latency of DPOS. However, since block finalization and generation are decoupled asynchronous processes, transaction confirmation latency during normal operation is still greater than that of PBFT consensus. In summary, each consensus algorithm has its own unique characteristics, and it is difficult to find a consensus algorithm that is absolutely superior in all aspects. Selection should be based on actual business needs.

[0062] Compared with existing technologies, this method can simulate the dynamic processes of large-scale energy blockchain systems with hundreds of consensus nodes and nearly 10,000 light nodes on a single computer, solving the simulation challenges of large-scale energy blockchain systems. This embodiment offers flexible parameterized simulation capabilities, allowing for flexible configuration of parameters such as network bandwidth, network topology, number of consensus nodes, and consensus algorithm, and rapid deployment and completion of simulations. This allows for flexible testing of the impact of energy blockchain parameters on the operational performance of large-scale energy blockchain systems, assisting in the parameter design of large-scale energy blockchain systems.

[0063] The above-mentioned specific implementation can be partially adjusted in different ways by those skilled in the art without departing from the principles and purpose of the present invention. The scope of protection of the present invention shall be based on the claims and shall not be limited by the above-mentioned specific implementation. All implementation schemes within its scope shall be subject to the constraints of the present invention.

Claims

1. A discrete state event-driven energy blockchain simulation test method, characterized in that: include: Construct energy blockchain node simulation model and energy blockchain network simulation model to simulate the core functions of actual energy blockchain nodes and networks respectively, and abstract them into node objects and network objects in the program implementation of simulation test methods; Create a discrete state event set and its event scheduling timing rules for driving the dynamic operation of the energy blockchain simulation model, which correspond to event objects and event scheduling objects in the program implementation of the simulation test method; Design a discrete state event-driven energy blockchain simulation process, and simulate the dynamic operation of the energy blockchain system according to the simulation process; The energy blockchain node simulation model includes: a transaction layer model, a consensus layer model, an application layer model and a data layer model, wherein: the transaction layer model, the consensus layer model and the application layer model respectively simulate the specific functions of the energy blockchain; the transaction layer model includes transaction creation, transaction sending, transaction receiving and transaction processing functions; the consensus layer model includes block creation, consensus message sending, consensus message receiving, consensus algorithm, execution of block transactions and block chain functions, wherein the consensus algorithm function varies depending on the specific consensus algorithm; the application layer includes: energy business transaction request, energy business execution result data query request, energy business execution result data query processing, energy business execution result data sending and energy business execution result data receiving functions; the data layer includes the transaction pool, blockchain, world state database and state cache data during system operation; The energy blockchain network simulation model includes: a sending side node, a sending side node edge link, a sending side companion node, an intermediate link, a receiving side companion node, a receiving side edge link, and a receiving side node, wherein: the edge link represents all links of the access network part of the wide area Internet, the intermediate link represents all links of the backbone network part of the wide area Internet, and the companion node represents the boundary point between the access network and the backbone network; the sending side node to the sending side companion node represents the edge link of the sending side, the receiving side companion node to the receiving side node represents the edge link of the receiving side, and the sending side companion node to the receiving side companion node represents the intermediate link; the delay of each link segment includes three parts: transmission delay, propagation delay, and queuing delay: the transmission delay is calculated by the link bandwidth and the data size; the propagation delay is calculated by the link distance and the optical fiber speed; the queuing delay is the sum of the transmission delays of the data that has not been sent in the queue; since the backbone network bandwidth is much larger than the access network, the transmission delay and queuing delay of the intermediate link are ignored compared with the transmission delay and queuing delay of the edge link; The discrete state event set and its event scheduling timing rules include: network discrete state event set and its scheduling timing rules; transaction layer discrete state event set and its scheduling timing rules; consensus layer discrete state event set and its scheduling timing rules; application layer discrete state event set and scheduling timing rules, where: The network discrete state event set includes: Event A0: some data is pushed into the sending queue of the sending node, and the execution time is recorded as T A0 ; Event A1: The sending node sends this data event, and the execution time is recorded as T A1 ; Event A2: The data is pushed into the receiving node's sending queue, and the execution time is recorded as T A2 ; Event A3: The receiving side companion node sends the data, and the execution time is recorded as T A3 ; Event A4: The receiving node receives the data, and the execution time is recorded as T A4 ; The timing rules for scheduling network discrete state events include: the execution time of event A0 is determined by the data sending event scheduling generation of the transaction layer, consensus layer, and application layer, and events A1 to A4 trigger scheduling generation in turn. The execution times corresponding to each event are: Where: α is the sending side node, α * is the companion node of the sending side node, β is the receiving side node, β * is the companion node of the receiving side node; t1 (αα*) , t2 (αα*) , t3 (αα*) They are respectively the sending node α to the accompanying node α * Transmission delay, propagation delay, and queuing delay of sending data; t2 (α*β*) is the companion node α on the sending side * To the receiving side, the accompanying node β * Propagation delay of sending data; t1 (β*β) , t2 (β*β) , t3 (β*β) are the receiving side companion nodes β * Transmission delay, propagation delay, and queuing delay of sending data to the receiving node β; The discrete state event set of the transaction layer includes: Event B0: A node creates a transaction. The specific content of the transaction comes from the application layer. The execution time is recorded as T B0 ; Event B1: The node sends the transaction and stores it in the local transaction pool. The execution time is recorded as T B1 ; Event C0: A node receives a transaction and forwards it at the same time. The transaction comes from the energy blockchain network and the execution time is recorded as T C0 ; Event C1: The node starts processing the transaction, and the execution time is recorded as T C1 ; Event C2: The node stores the transaction in the local transaction pool, and the execution time is recorded as T C2 ; The scheduling rules of discrete state events in the transaction layer include: event B0 is triggered by the creation of a transaction event in the application layer; event B1 is subsequently triggered and scheduled, and the execution time of event B1 is T B1 =T B0 +t B1 , where: t B1 is the transaction creation time, the transaction signature time and the transaction creation process queue time. After the event B1 is executed, it will trigger the scheduling to generate the energy blockchain network data sending event A0; event C0 is triggered by the network layer receiving a transaction data event. Event C0 will trigger the scheduling to generate the energy blockchain network data sending event A0. Events C1~C2 are triggered in sequence after the event C0 is executed. The execution time of events C1 and C2 are T respectively. C1 =T B0 +t C1 、T C2 =T C1 +t C2 , where t C1 is the queuing time of the transaction processing process, t C2 It takes time to process transactions and verify signatures; The consensus layer discrete state event set includes: consensus initiation discrete state event set, consensus process discrete state event set, and consensus achievement discrete state event set; the consensus initiation discrete state event set includes 2 events: Event D0: The master node creates a block, and the execution time is recorded as T D0 ; Event D1: The master node sends the first consensus message of the block, starting the consensus process, and the execution time is recorded as T D1 ; The consensus discrete state event set includes two events: Event H0: A node receives a consensus message that satisfies the consensus, determines that the consensus is reached, and executes the transaction in the block. The execution time is recorded as T H0 ; Event H1: The node will upload the consensus block to the chain, and the execution time is recorded as T H1 ; The discrete state event set of the consensus process is related to the specific consensus algorithm, and examples will be given in conjunction with the embodiments; The discrete state event scheduling timing rules of the consensus layer include: the discrete state event scheduling timing rules for consensus initiation, the discrete state event scheduling timing rules for consensus process, and the discrete state event scheduling timing rules for consensus achievement; the discrete state event scheduling timing rules for consensus initiation include: the execution time of event D0 is determined according to the consensus algorithm rules, event D1 is triggered by event D0, and the execution time is T D1 =T D0 +t D1 , where t D1 is the time taken to create a block and the time taken to create the first consensus message, is the time taken to sign the block and generate the hash summary, event D1 will trigger the scheduling to generate the data sending event A0 corresponding to the energy blockchain network; the scheduling timing rules for the discrete state events of consensus achievement include: event H0 triggers the scheduling generation when receiving the consensus message that satisfies the consensus, event H1 is triggered by event H0, and the execution time of events H0 and H1 are T respectively. H0 =T H ′0+t H0 、T H1 =T H0 +t H1 , where t H0 The time it takes to process the last message that meets the consensus and the time it takes to verify the message signature; T′ H0 is the time when the last message that satisfies the consensus is received; t H1 is the execution time of transactions in the block, and is the execution time of the smart contract; the discrete state event scheduling timing rules of the consensus process are related to the specific consensus algorithm, and an example will be given in conjunction with the implementation example; The discrete state event set of the application layer includes: Event I0: A node generates the data required for the energy service request according to the energy service demand, and the execution time is recorded as T I0 ; Event J0: A light node sends an energy business execution result query request to an energy blockchain consensus node through the energy blockchain network. The execution time is recorded as T J0 ; Event K0: A consensus node receives a request to query the execution result of energy business from the energy blockchain network, and the execution time is recorded as T K0 ; Event K1: This node processes the request to query the execution result of the energy business, and the execution time is recorded as T K1 ; Event K2: The node sends the query result reply data to the energy blockchain network, and the execution time is recorded as T K2 ; The application layer discrete state event scheduling timing rules include: the execution time of event I0 is determined by the time when the node initiates the energy business demand, which will trigger the scheduling to generate the transaction layer event B0 corresponding to the energy business request data, event J0 will trigger the scheduling to generate the energy blockchain network event A0, event K0 is triggered by the data reception event of the energy blockchain network query energy business execution result request, and the execution time of events K1 and K2 are T K1 =T K0 +t K1 、T K2 =T K1 +t K2 , where t K1 The time consumed in queuing the energy business execution result processing process; K2 In order to query the time consumed in processing the energy business execution results, event K2 will trigger the scheduling to generate energy blockchain network data sending event A0.

2. According to the discrete state event-driven energy blockchain simulation test method of claim 1, it is characterized in that: include: Step 1: Start the simulation test; Step 2: Configure the energy blockchain node model parameters. After execution, proceed to step 3; Step 3: Configure the energy blockchain network model parameters, and then proceed to step 4; Step 4: Configure energy blockchain application simulation data, and proceed to step 5 after execution; Step 5: Register an account, generate the public and private keys and address of the account, and then proceed to step 6; Step 6: Register the smart contract, generate the contract address and call interface, and then call the contract program file through the reflection mechanism. After execution, proceed to step 7; Step 7: Instantiate the energy blockchain node and network model objects, complete the deployment of all nodes and network models of the entire energy blockchain system, and proceed to step 8 after execution; Step 8: Initialize the event queue, including the creation events of all transactions within the energy blockchain application simulation time and the creation event of the first block. After execution, proceed to step 9; Step 9: reset the simulation clock to zero, and then proceed to step 10; Step 10: Get an event from the event queue, and go to step 11 after execution; Step 11: The simulation clock advances to the current event execution time, and after execution, it proceeds to step 12; Step 12: Determine whether the simulation has timed out. If it is determined to be yes, proceed to step 17; if it is determined to be no, proceed to step 13; Step 13, execute the event taken out in step 10, and then go to step 14 after execution; Step 14: Generate future event judgment. If the execution result of step 10 will generate a future event, the judgment is yes and the process goes to step 15. Otherwise, the judgment is no and the process goes to step 16. Step 15: insert the future event into the event queue, and go to step 10 after execution; Step 16: Check whether the event queue is empty. If it is, go to step 10; if it is not, go to step 17. Step 17: Statistical analysis outputs simulation test results. If the results are completed, proceed to step 18. Step 18: The simulation test ends.

Images