A blockchain simulation experiment method and experiment system

Abstract

The application provides a blockchain simulation experiment method and an experiment system.The blockchain simulation experiment method comprises: being divided into a single-process simulation experiment method, a distributed simulation experiment method and a whole-process simulation experiment method according to the requirements of a user; wherein the single-process simulation experiment method comprises: triggering the simulation to be performed through a control node / block operation interaction module; the distributed simulation experiment method comprises: being cooperatively executed by agents distributed on different devices, and starting and ending the distributed simulation operation by inputting configuration parameters and calling a simulation switch controller through a controller; and the whole-process simulation experiment method comprises: reading all simulation transactions at one time and performing continuous simulation transaction scheduling through an optimized discrete simulation transaction scheduling algorithm.The simulation experiment method can make the objects and results of the simulation more comprehensive.

Description

Technical Field

[0001] This invention relates to the field of blockchain virtual simulation, and more specifically, to a blockchain simulation experiment method and system. Background Technology

[0002] Currently, blockchain technology, as an important component of the next generation of information technology, solves the trust and security issues in cyberspace, drives the transformation of the internet from transmitting information to transmitting value, and restructures the information industry system. In recent years, blockchain technology has been widely applied in many fields such as finance, healthcare, the Internet of Things, and supply chains, attracting increasing attention. Against this backdrop, the demand for experiments targeting various blockchain applications is also growing.

[0003] Existing blockchain simulation tools mainly fall into the following model construction categories, as shown in the appendix. Figure 1 As shown.

[0004] A discrete event model is a model of a dynamic simulation process. Driven by events, the occurrence of events is discrete and random (i.e., the values ​​of the system state variables are discrete and randomly distributed along the time axis). Events are changes in the state of the network model or certain decisions. The simulator only performs simulations when the model state changes; it does not simulate time periods when the state does not change.

[0005] Agent-based models are derived from and variations of discrete event models, focusing on the behavior of agents in discrete simulation systems and the changes in the overall system characteristics caused by the actions of numerous individuals. Agents possess autonomy, capable of perceiving changes in the system environment and the behavior of other individuals within the system, making decisions and reacting based on the acquired information. Individuals possess memory and cognitive abilities, making decisions according to established rules and adjusting their behavior to achieve a degree of adaptability to the system. For complex agent-based simulation systems, when numerous individuals act in accordance with established rules, the system exhibits emergent characteristics, meaning the system displays features not possessed by individual individuals.

[0006] Virtualization models are mainly divided into three types: full virtualization, partial virtualization, and operating system virtualization. The main difference between these three types lies in whether the operating system and operating methods are modified, with operating system virtualization being the primary simulation model used in current simulation systems. Operating system-level virtualization refers to creating isolated operating execution environments by partitioning a specific part of a host operating system. Operating system-level virtualization is directly provided by the operating system kernel, and the virtualized operating systems share the underlying host operating system kernel and underlying hardware resources.

[0007] The main problems existing in the current technology are:

[0008] 1. Traditional blockchain simulation tools are mostly used only by blockchain researchers, and most of them are non-visual simulation tools, resulting in a small user base and low usability.

[0009] 2. Traditional blockchain simulation tools are all built on a single model (one of the three models mentioned above), resulting in low scalability and extensibility of the simulation model and low efficiency of the simulation model's scheduling mechanism.

[0010] 3. The transaction-driven mechanism of discrete event models is not suitable for blockchain technology architecture, and there is no effective simulation time control mechanism for agent-based and virtualization models. Furthermore, the simulation process of these three models has low controllability and is unsuitable for blockchain technology simulation.

[0011] 4. The simulation data of the above three models have lower accuracy and higher difficulty in data transfer compared to the object model (blockchain).

[0012] In view of this, the present invention is hereby proposed. Summary of the Invention

[0013] In view of this, the present invention discloses a multi-model blockchain simulation experiment method and system based on discrete events. This simulation experiment method mainly consists of three simulation process modules (single-process simulation, distributed simulation, and full-process simulation). The single-process simulation module can be unidirectionally converted into distributed simulation, and distributed simulation and full-process simulation can be mutually converted. This simulation method allows for a more comprehensive understanding of the simulation objects and results, is more flexible in use, and is more convenient to control.

[0014] Specifically, the present invention is achieved through the following technical solutions:

[0015] In a first aspect, the present invention discloses a blockchain simulation experiment method, comprising the following steps:

[0016] Based on user needs, simulation experiment methods are categorized into single-process simulation experiment methods, distributed simulation experiment methods, and full-process simulation experiment methods.

[0017] The single-process simulation experiment method includes: triggering the simulation by controlling the node / block operation interaction module;

[0018] The distributed simulation experiment method includes: collaborative execution by agents distributed on different devices, with a controller passing in configuration parameters and calling a simulation switch controller to control the start and end of the distributed simulation operation;

[0019] The full-process simulation experiment method includes: reading all simulation transactions at once and continuously scheduling simulation transactions using an optimized discrete simulation transaction scheduling algorithm.

[0020] Secondly, this invention discloses a blockchain simulation experiment system, comprising:

[0021] Single-process simulation experiment module: used to trigger the simulation through the control node / block operation interaction module;

[0022] Distributed simulation experiment module: This module is used for collaborative execution by agents distributed across different devices. The start and end of the distributed simulation operation are controlled by a controller that inputs configuration parameters and calls the simulation switch controller.

[0023] Full-process simulation experiment module: used to read all simulation transactions at once and perform continuous simulation transaction scheduling through an optimized discrete simulation transaction scheduling algorithm.

[0024] Thirdly, the present invention discloses a computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the steps of the blockchain simulation experiment method as described in the first aspect.

[0025] Fourthly, the present invention discloses a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the blockchain simulation experiment method as described in the first aspect.

[0026] The blockchain simulation experiment method and system of the present invention have the following advantages:

[0027] 1. This invention proposes a multi-model blockchain virtual simulation experiment method based on discrete events. The simulation experiment method mainly consists of three simulation process modules (single-process simulation, distributed simulation, and full-process simulation). The single-process simulation module can be unidirectionally converted into distributed simulation, and distributed simulation and full-process simulation can be mutually converted. This simulation allows for a more comprehensive understanding of the simulation objects and results.

[0028] 2. The solution of this invention belongs to a flexible system deployment architecture, which can be directly published to the web and supports multi-user concurrent simulation. It can also be deployed to the target machine to support high-volume blockchain virtual simulation.

[0029] 3. Flexible in use, applicable to different scenarios and user groups. For example, it supports simulations in different scenarios and allows different groups of people, such as blockchain technology beginners, researchers, and those interested in blockchain, to perform blockchain simulations according to their own needs.

[0030] 4. This invention proposes a user behavior-driven single-process simulation architecture, which simulates the blockchain technology architecture by breaking down the process into smaller parts, thereby enhancing researchers' interaction with users during the simulation process (scaling, filtering, associating, recording, extracting, providing details and overviews as needed, etc.), allowing simulators to participate more deeply in the simulation process.

[0031] 5. This invention employs a blockchain distributed simulation time and transaction control mechanism based on a DCPS data synchronization model and an improved PTP clock synchronization algorithm.

[0032] 6. A novel transaction layering architecture is proposed, which makes the driving architecture of the simulation model more adaptable to the blockchain technology architecture through transaction layering.

[0033] 7. This invention also proposes a flexible and universal simulation module. This module is a general architecture for generating simulation transactions. It can build different blockchain simulation object models through blockchain architecture modeling, and can be flexibly deployed according to different simulation scale requirements. Attached Figure Description

[0034] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0035] Figure 1 A structural diagram of existing blockchain simulation experimental tools;

[0036] Figure 2 This is a diagram of the blockchain simulation experiment system architecture according to an embodiment of the present invention;

[0037] Figure 3 This is a flowchart illustrating the single-process simulation experiment method according to an embodiment of the present invention;

[0038] Figure 4 This is a flowchart illustrating the distributed simulation experiment method according to an embodiment of the present invention;

[0039] Figure 5 This is a schematic flowchart of the simulation synchronization process according to an embodiment of the present invention;

[0040] Figure 6 This is a flowchart illustrating the full-process simulation experiment method according to an embodiment of the present invention;

[0041] Figure 7 This is an execution architecture diagram of the full-process simulation experiment method according to an embodiment of the present invention;

[0042] Figure 8 This is a flowchart illustrating the time advancement mechanism according to an embodiment of the present invention;

[0043] Figure 9 This is a diagram illustrating the interactive architecture of a discrete event simulator according to an embodiment of the present invention.

[0044] Figure 10 This is a general simulation module for the simulation experiment method of the present invention;

[0045] Figure 11-12 This is a schematic diagram of the simulated main page of the present invention;

[0046] Figure 13 This is a flowchart illustrating a computer device provided in an embodiment of the present invention. Detailed Implementation

[0047] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0048] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0049] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0050] This invention discloses a blockchain simulation experiment method, which is divided into a single-process simulation experiment method, a distributed simulation experiment method, and a full-process simulation experiment method according to user needs;

[0051] The single-process simulation experiment method includes: triggering the simulation by controlling the node / block operation interaction module;

[0052] The distributed simulation experiment method includes: collaborative execution by agents distributed on different devices, with a controller passing in configuration parameters and calling a simulation switch controller to control the start and end of the distributed simulation operation;

[0053] The full-process simulation experiment method includes: reading all simulation transactions at once and continuously scheduling simulation transactions using an optimized discrete simulation transaction scheduling algorithm.

[0054] This invention divides the simulation experiment method into three simulation process modules: single-process simulation, distributed simulation, and full-process simulation. The use of each simulation process module is controlled by the user module. The user mainly controls the start and end of the simulation, various behavioral controls during the simulation process, and the import and export of simulation data. A detailed simulation system architecture diagram is shown below. Figure 2 As shown, the overall architecture comprises a visualization layer, a web server layer, a business layer, a data access layer, and a data layer, and is rapidly deployed using Docker. The visualization layer includes functions such as user login, system information, simulation control, and simulation data management. The web server layer is built using Vue3 and Nginx. The business layer primarily implements single-process simulation, distributed simulation, and full-process simulation control, as well as data analysis, data evaluation, and data migration for simulation data management. Data access is implemented using Spring DataJPA. The data layer includes MySQL and Redis. The three simulation experiment methods will be explained in detail below.

[0055] (1) Single-process simulation experiment method:

[0056] The simulation module within the single-process simulation experimental method is primarily driven by user behavior. The user behavior-driven model consists of a simplified discrete event model, ensuring the isolation between simulation transactions and the process. By decomposing the process using blockchain technology architecture, the researcher's interactive behavior during simulation is enhanced (zooming, filtering, associating, recording, extracting, providing details and overviews as needed, etc.). The specific architecture is as follows... Figure 3 As shown, users trigger the simulation by controlling the node / block operation interaction module. Specific interactions include block operations, node operations, account operations, transaction operations, peer-to-peer network operations, and many others. These interactions are transmitted to the discrete event module, where transaction control, time control, and data management modules execute and process them. The processing results are fed back by the interaction and visualization module, which provides in-depth visualization of the interactions to enhance user operability. Improved interaction performance significantly enhances the user's control over the entire blockchain process during simulation research. Single-process simulations can be transformed into distributed simulations through unidirectional data import / export.

[0057] (2) Distributed simulation experiment method:

[0058] The simulation module within the distributed simulation experimental method is built upon an Agent (agent, autonomous system) model. Simulation is collaboratively executed by Agents distributed across different devices. Each Agent's service resources include the host resources hosted by the current user accessing the system, and the simulation process for each Agent is continuous and highly controllable. Distributed simulation typically involves a controller, which controls the start and end of the distributed simulation by passing configuration parameters and invoking the simulation switch controller. Simultaneously, the simulation controller creates an independent global data space for transaction synchronization. When performing simulation operations, Agents first call the synchronization controller to subscribe to simulation transaction processes that synchronously update the global transaction space. After the transaction update is complete, Agents request simulation transaction construction from the general simulation module. The constructed transaction is divided into a series of logical processes by the distributed process controller through algorithm scheduling. These processes are executed on the centralized server at the system's underlying layer and distributed to Agents through an interactive and visual configurator. Distributed simulation allows experimenters to more accurately observe the details of the blockchain simulation process. The distributed simulation experimental method has higher scalability and can deeply simulate blockchain entities under different technical architectures. The specific architecture is as follows... Figure 4 As shown.

[0059] Event and transaction synchronization control mechanisms in distributed simulation, such as Figure 5 As shown, an improved DCPS data synchronization model and an improved PTP clock synchronization algorithm are used to control the time and transaction synchronization of the simulation model. During the simulation, the simulation controller creates a global data space to store all transactions in the current simulation process. Each agent in the simulation has an independent data space. Updates to transactions in this data space and the global transaction space are conducted through a subscriber-publisher mechanism, following an optimistic synchronization mechanism. Subscription and publication permissions for each agent are granted by the simulation controller. The specific subscription and publication process is as follows:

[0060] subscription:

[0061] a) Data subscription request: When the Agent's independent data space is active, the Agent will initiate a simulation data subscription request to the global data space when relevant simulation data activities occur.

[0062] b) Data channel opening: After receiving a data subscription request, the global data space identifies the Agent's subscription permissions and opens the data channel to the Agent after confirming that it has subscription permissions.

[0063] c) Data packet update: After receiving the data channel opening message, the Agent begins to update and download the relevant simulation transaction data.

[0064] d) Subscription successful: After the simulation transaction data subscription is successful, the Agent will mark the independent data space with the corresponding version identifier according to the received data version.

[0065] release:

[0066] a) Data publishing request: When the Agent generates new simulated transaction data, it will send a transaction publishing request to the global data space (the publishing request will carry the version identifier of the simulated transaction data in the current independent data space, and the identifier point is the identifier before the new transaction was generated).

[0067] b) Data channel opening: After receiving a data publishing request, the global data space identifies the Agent's publishing permissions and opens the data channel to the Agent after confirming that it has publishing permissions.

[0068] c) Data packet synchronization: The global data space identifies the difference in the version identifier of the Agent's simulated transaction data, and sends the corresponding transaction data to the Agent according to the version identifier difference to perform synchronization.

[0069] d) Publishing data: After the simulation transaction data synchronization is completed, the latest simulation transaction data is published to the global data space.

[0070] e) Successful publication: After the simulation transaction data is successfully published, the global data space will send a publication success message to the Agent along with a new data version identifier. The Agent will then assign the corresponding identifier to the independent data space based on the received data version identifier.

[0071] The simulation's time synchronization mechanism primarily occurs when an agent joins the simulation and initiates a subscription. This occurs relatively infrequently, typically during the initial simulation joining. Subsequent occurrences are controlled by the global data space and whether time discrepancies arise with the agent. The time synchronization mechanism adapts to the blockchain block synchronization process. The specific time synchronization mechanism is as follows: Figure 5 The right half shows the specific process as follows:

[0072] (1) The Agent sends a request to join the simulation to the simulation controller. Upon receiving the request, the controller confirms and sends a start response message.

[0073] (2) The distributed simulation controller sends a simulation start command (INV message) to the Agent to request clock synchronization and records the sending time. The INV message contains the sending time. And the controller's trusted identifier.

[0074] (3) After a certain amount of network delay, the Agent receives the start command from the controller (INV message, which allows the message receiver to perform related operations on the message initiator. It is not the same type of transaction as the InvTask in the simulation). The Agent verifies the content of the INV message and starts the virtual clock of this node after the verification is successful.

[0075] (4) The Agent sends an initial response to the controller's request and sends a response REC message, which includes its own timestamp. Received timestamp And the trusted identifier of the Agent.

[0076] (5) After receiving the REC message from the Agent, the controller records the reception time. It immediately sends a LINK message to the Agent, notifying the Agent that communication between the two has been successfully established. The LINK message carries a timestamp. , , In a blockchain system, each node or agent is susceptible to loss (agent shutdown or disconnection). The purpose of LINK messages is to remind agents that the synchronization channel has been successfully opened and to require agents to maintain a stable online state, reducing the occurrence of interruptions during the simulation process.

[0077] (6) After receiving the LINK message from the controller and downloading the relevant timestamp data, the Agent sends a GETDATA request to the controller to obtain the final time data. The request includes the timestamp of the current time. and the timestamp in the LINK message , , .

[0078] (7) After receiving the GETDATA message from the Agent, the controller records the reception time. It calculates the precise network latency based on the timestamp of the received message and sends the calculated latency as a virtual time block message (BLOCK) calibration command to the Agent.

[0079] (8) After receiving the controller's BLOCK message, the Agent calibrates its clock by adjusting backward and clears the cache of other previous messages.

[0080] The formula for calculating the virtual clock offset is shown in Formula 1. The calibration result is the adjustment of the Agent's virtual clock offset by the clock's offset + . .

[0081] (1)

[0082] The PTP protocol is a clock synchronization method based on the assumption that transmission processing time is ignored. Based on this, we define the start time for calculation as... This way, only the last calibration command needs to tell the agent how much time to adjust; it doesn't need to be calculated in the synchronization model, while ensuring data accuracy through dual requests. To some extent, the improved PTP algorithm reduces errors caused by ignoring processing time.

[0083] (3) Full-process simulation experiment method:

[0084] The simulation modules within the full-process simulation experiment method are simulation modules built based on discrete event models, such as... Figure 6 As shown, the full-process simulation plan implements a blockchain simulation module with freely configurable blockchain-related parameters, enabling efficient and convenient large-scale blockchain simulation. It also deeply optimizes the p2p (peer-to-peer) network architecture to ensure reasonable simulation time. Users configure the simulation-related parameters once and submit a simulation request to the general simulation module. The full-process simulation reads all simulation transactions at once and continuously schedules simulation transactions using an optimized discrete simulation transaction scheduling algorithm. During the simulation, the simulation process is fed back to the user through an interactive and visual configurator. The simulation ends when the target value is reached. The simulation process is uncontrollable and cannot be interrupted. The process offers two options: process visualization and direct access to simulation results.

[0085] The transaction scheduling mechanism for the full-process simulation has been optimized compared to traditional scheduling mechanisms. Traditional transaction scheduling uses a queuing system to schedule and process simulated transactions. Using blockchain as the object model, the traditional transaction architecture is divided into intra-block transactions and inter-block transactions. Intra-block transactions are stored and executed using a heap, while inter-block transactions are stored and executed using a queue. Inter-block transactions are the primary execution queue, and their execution also triggers concurrent scheduling of corresponding intra-block transactions. The architecture diagram is as follows. Figure 7 As shown, the specific execution architecture is as follows:

[0086] (1) Before the simulation starts, the system will create a series of MiningTasks and store them in a queue. Except for the head of the queue, which will initialize the MiningTask transaction content and be in an active state, the other MiningTasks will be empty transactions and in an inactive state. The transactions in the queue are inter-block transactions. Under each MiningTask, a min-heap will be created to store and trigger intra-block transactions.

[0087] (2) Transactions within a simulation block are stored in a heap structure. Each transaction has a corresponding holding node. At the start of the simulation, the MiningTask at the top of the transaction stack is initialized. The MiningTask is retrieved and performs actions such as simulation consensus, simulation data uploading to the blockchain, and simulation transaction distribution. The simulation consensus will generate a verifiable block for this simulation and upload it to the blockchain by the corresponding block-producing node. After the simulation is uploaded to the blockchain, the block-producing node will distribute messages to its neighboring nodes and generate InvTask and AbsMinTask. The InvTask, BlockTask, and AbsMinTask generated after the MiningTask is executed all belong to transactions within the block.

[0088] (3) The function of InvTask transactions is to allow the receiving node to understand the status of the transaction initiating node. After the top of the stack is taken out and executed by the corresponding receiving node, a BlockTask will be generated.

[0089] (4) BlockTask transactions are mainly functional simulations of block transmission. Internally, it includes the getData function to respond to invTask and update the simulated blockchain of the receiving node. After the update is completed, it will generate message distribution to neighboring nodes and generate InvTask and AbsMinTask.

[0090] (5) When the top transaction is InvTask, the simulation will continue to execute steps (2) and (3).

[0091] (6) When the top transaction of the stack is AbsMinTask and is executed, it means that the node holding the corresponding transaction has won the block production competition in this round. The node will immediately fill the transaction content for the next MiningTask and dequeue it for execution. This MiningTask will generate a new round of intra-block transactions. Intra-block transactions that did not occur in the previous round will be executed concurrently on the basis of the intra-block transactions in this round, without affecting the occurrence of the simulation. In addition, all AbsMinTasks in the previous round are defined as invalid transactions and deleted to reduce the redundancy of simulation transactions.

[0092] Different AbsMinTasks have a probability of being triggered simultaneously, and this behavior will trigger a fork in the simulation chain.

[0093] The time progression mechanism for distributed simulation and full-process simulation adopts an improved subsequent event time progression mechanism. To make the simulation more closely resemble blockchain technology, subsequent event time progression uses a transaction round-robin architecture. Time progress occurs whenever an event occurs, and different transactions have different execution priorities. A time delay is set when an event occurs, and the distributed simulation time progresses after the transaction occurs. The specific architecture is as follows... Figure 8 As shown, the main propulsion mechanism is as follows:

[0094] (1) Simulation begins, the Genesis transaction is created and triggered, and the simulation time is initialized to t = 0.

[0095] (2) The originating transaction creates the first round of transactions. Each transaction within the round will be given a trigger delay. At the same time, initialize the first round of transaction identifiers. = 0, the simulation transaction identifier mainly controls the simulation time to proceed in parallel.

[0096] (3) When transaction 1-t2 is triggered, record the current simulation time t1=t (this time record is used for simulation data observation), and the system read delay. The simulation time is advanced, and simulation transactions are executed simultaneously. After the simulation transactions and time advancement are completed, the transaction identifier value for the simulation round is recalculated, as shown in the following formula.

[0097]

[0098] (4) After transaction 1-t2 is completed, the second round of transaction construction will be triggered and executed according to priority.

[0099] In addition, the present invention also provides a blockchain simulation experiment system, specifically including:

[0100] Single-process simulation experiment module: used to trigger the simulation through the control node / block operation interaction module;

[0101] Distributed simulation experiment module: This module is used for collaborative execution by agents distributed across different devices. The start and end of the distributed simulation operation are controlled by a controller that inputs configuration parameters and calls the simulation switch controller.

[0102] Full-process simulation experiment module: used to read all simulation transactions at once and perform continuous simulation transaction scheduling through an optimized discrete simulation transaction scheduling algorithm.

[0103] In practice, the above modules can be implemented as independent entities or combined in any way to be implemented as the same or several entities. For the specific implementation of each unit, please refer to the previous method implementation examples, which will not be repeated here.

[0104] In addition, both the full-process simulation experiment method and the distributed simulation experiment method include a general simulation module. This general simulation module ensures data interoperability and consistency between the full-process and distributed simulations. Its internal architecture is highly configurable, fully guaranteeing the diversity of simulation object models. The architecture diagram of the general simulation module is shown below. Figure 10 As shown.

[0105] (1) Simulation Container Module. The simulation container module is responsible for handling the simulation's input / configuration parameters, which are organized into a set of parameter files or request lists:

[0106] (a) Configuration file: The simulated blockchain configuration (consensus type, number of blocks produced, number of nodes, probability of orphan blocks, message size, block size and intermediary fee ratio).

[0107] (b) Delay and distribution file: Time probability distribution of block transaction verification, block production interval. Probability distribution of delays between possible node locations.

[0108] (c) Uplink and downlink bandwidth file of node domain: probability distribution of uplink and downlink bandwidth between and within node domains.

[0109] Once these parameters are assigned to the simulation container module, a list of callable variable data is generated, which can be passed to other different components to provide all characteristic properties during the simulation process.

[0110] (2) Transaction Factory. The transaction factory is responsible for creating batches of transactions, which are then processed by the time control module and passed to the discrete event simulator. The transaction factory also includes node creation transactions, mainly for creating nodes used during the simulation. Users can specify the location, number of nodes, and corresponding identifiers of the nodes.

[0111] (3) Discrete Event Simulator. The core of the discrete event simulator is the Discrete Event Simulation Engine (DESE). The discrete event simulator supports several core functions, including event scheduling, event queuing and processing, communication between various components, simulation clock management, and access control of entity resources. Simultaneously, it reads discrete event data into the corresponding simulation module for visualization interaction according to simulation requirements. The object architecture modeling within the discrete time simulator is a blockchain entity object model or virtual object model used to simulate the target architecture. The modeling process is implemented based on different models, including node models, consensus models, block models, network models, and chain models. Different models have high configurability to achieve the purpose of modeling multiple object models. The specific interactive architecture of the discrete time simulator is as follows: Figure 9 As shown:

[0112] (4) Time control module. Controls the coordination between simulated virtual time and actual time, and configures the time parameters for various transactions.

[0113] (5) Data Control Module. The data control module mainly monitors relevant data indicators and malicious transaction behaviors during the simulation process, and also updates relevant indicators as needed. Relevant data will be organized into relevant log files for storage and export.

[0114] The general simulation module can be deployed individually on the target machine by the simulation user according to the simulation scale requirements. Users configure the interface to execute simulation requests for each individually deployed module. See the specific simulation page for details. Figures 11-12 As shown.

[0115] Figure 13 This is a schematic diagram of the structure of a computer device disclosed in this invention. (Reference) Figure 13 As shown, the computer device 400 includes at least a memory 402 and a processor 401; the memory 402 is connected to the processor via a communication bus 403 and is used to store computer instructions executable by the processor 401. The processor 401 is used to read computer instructions from the memory 402 to implement the steps of the blockchain simulation experiment method described in any of the above embodiments.

[0116] For the above-described apparatus embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The apparatus embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this disclosure according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0117] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal disks or removable disks), magneto-optical disks, and CD-ROMs and DVD-ROMs. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0118] Finally, it should be noted that although this specification contains many specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily used to describe the features of specific embodiments of a particular invention. Certain features described in the various embodiments of this specification may also be implemented in combination in a single embodiment. On the other hand, various features described in a single embodiment may also be implemented separately in various embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation of a sub-combination.

[0119] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or requiring all illustrated operations to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0120] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0121] The above description is merely a preferred embodiment of this disclosure and is not intended to limit this disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A blockchain simulation experiment method, characterized in that, Based on user needs, simulation experiment methods are categorized into single-process simulation experiment methods, distributed simulation experiment methods, and full-process simulation experiment methods. The single-process simulation experiment method includes: triggering the simulation by controlling the node / block operation interaction module; The distributed simulation experiment method includes: collaborative execution by agents distributed on different devices, with a controller passing in configuration parameters and calling a simulation switch controller to control the start and end of the distributed simulation operation; The full-process simulation experiment method includes: reading all simulation transactions at once and continuously scheduling simulation transactions using an optimized discrete simulation transaction scheduling algorithm; The specific methods for distributed simulation operations include: calling the synchronization controller to subscribe to the simulation transaction synchronization process that synchronously updates the global transaction space; The subscription synchronization process triggers a time synchronization procedure, which includes the following operation methods: The Agent sends a join simulation request to the simulation controller, and the controller receives the request and confirms by sending a start response message. The controller sends an emulation start command to the agent requesting clock synchronization and recording the sending time , the sending time and the controller's trusted identification are contained in the INV message ​ Upon receiving the start command from the controller, the Agent verifies the INV message content. If verification is successful, the Agent starts the virtual clock of this node. The formula for calculating the offset value of the virtual clock is: The calibration result in the above equation is the offset by which the clock adjustment Agent virtualizes the clock ; The agent sends the first response to the request of the controller and sends the response REC message, and the agent's trusted identification is added in the response message , the time stamp of the reception and the agent's trusted identification After receiving the REC message from the Agent, the controller records the reception time. It immediately sends a LINK message to the Agent, notifying the Agent that communication between the two has been successfully established. The LINK message carries a timestamp. , , ; After receiving the LINK message from the controller and downloading the relevant timestamp data, the agent sends a GETDATA request to the controller to obtain the final time data. The request includes the timestamp of the currently sent data. and the timestamp in the LINK message , , ; The controller receives the GETDATA message of the agent, records the receiving time and calculates the accurate network delay according to the time stamp of the received message, and sends the calculated delay to the agent as a virtual time block message calibration command; After receiving the virtual time block message from the controller, the Agent calibrates its clock by adjusting backward and clears the cache of other previous messages.

2. The blockchain simulation experiment method of claim 1, wherein, The specific methods for the distributed simulation operation also include: After the transaction update is completed, it requests the simulation transaction construction from the general simulation module. The constructed transaction is divided into a series of logical processes by the distributed process controller through algorithm scheduling. The logical processes are executed on the centralized server at the bottom layer of the system and distributed to the Agent through the interactive and visual configurator.

3. The blockchain simulation experiment method of claim 2, wherein, The operation method of the simulation transaction synchronization process includes: a subscription and a publish process; wherein the subscription process includes: a) Data subscription request: When the Agent's independent data space is active, the Agent will initiate a simulation data subscription request to the global data space when relevant simulation data activities occur. b) Data channel opening: After receiving a data subscription request, the global data space identifies the Agent's subscription permissions and opens the data channel to the Agent after confirming that it has subscription permissions; c) Data packet update: After receiving the data channel opening message, the Agent begins the relevant simulation process. d) Subscription successful: After the simulation transaction data subscription is successful, the Agent will mark the independent data space with the corresponding version identifier according to the received data version; The publishing process includes: a) Data publication request: When the Agent generates new simulated transaction data, it will send a transaction publication request to the global data space; b) Data channel opening: After receiving a data publishing request, the global data space identifies the agent's publishing permissions and opens the data channel to the agent after confirming that it has publishing permissions; c) Data packet synchronization: The global data space identifies the version difference of the Agent's simulated transaction data and sends the corresponding transaction data to the Agent according to the version difference to perform synchronization. d) Publishing data: After the simulation transaction data synchronization is completed, the latest simulation transaction data is published to the global data space; e) Successful publication: After the simulation transaction data is successfully published, the global data space will send a publication success message to the Agent along with a new data version identifier. The Agent will then assign the corresponding identifier to the independent data space based on the received data version identifier.

4. The blockchain simulation experiment method of claim 1, wherein, The full-process simulation experiment method, with blockchain as the object model, divides the traditional transaction architecture into intra-block transactions and inter-block transactions. Intra-block transactions are stored and executed by the heap, while inter-block transactions are stored and executed by the queue. Inter-block transactions are the main execution queue, and the execution of inter-block transactions will also trigger the concurrent scheduling of corresponding intra-block transactions.

5. The blockchain simulation experiment method of claim 4, wherein, The execution architecture of the full-process simulation experiment method includes: S1. First, MiningTasks are created and stored in a queue. The head of the queue initializes the MiningTask transaction content and is in an active state. Other MiningTasks are empty transactions and are in an inactive state. Transactions in the queue are inter-block transactions. A min-heap is created under each MiningTask to store and trigger intra-block transactions. S2. Each transaction has a corresponding holding node. When the simulation starts, the MiningTask at the top of the transaction stack is initialized. The MiningTask is taken out and performs simulation consensus, simulation data uploading to the chain, and simulation transaction distribution. S3. The simulation consensus will generate a verifiable block for this simulation and the corresponding block-producing node will put it on the chain. After the simulation is put on the chain, the block-producing node will distribute messages to neighboring nodes and generate InvTask and AbsMinTask. The InvTask, BlockTask and AbsMinTask generated after the MiningTask is executed are all intra-block transactions. S4, InvTask transactions allow the receiving node to understand the state of the transaction initiating node. After the top of the stack is taken out and executed by the corresponding receiving node, a BlockTask will be generated. S5 BlockTask is a simulation of the block transmission function of transactions. It includes a getData function to respond to invTask and update the simulated blockchain of the receiving node. After the update is completed, it will generate message distribution to neighboring nodes and generate InvTask and AbsMinTask. When the top transaction in the stack is InvTask, the simulation will continue to execute steps S3-S4. When the top transaction of the stack is AbsMinTask and it is executed, the node will immediately fill the transaction content for the next MiningTask and dequeue it for execution. This MiningTask will generate a new round of intra-block transactions. Intra-block transactions that did not occur in the previous round will be executed concurrently based on the intra-block transactions in this round, and all AbsMinTasks in the previous round will be defined as invalid transactions and deleted.

6. The blockchain simulation experiment method of any one of claims 1-5, wherein, The distributed simulation experiment method and the full-process simulation experiment method adopt a time-progression mechanism. The operation method of the time-progression mechanism includes: The simulation begins with the creation and triggering of the originating transaction, and the simulation time is initialized to t = 0; The origin transaction creates the first round of transactions, each transaction within the round is given a delay time for the trigger while initializing the first round transaction identification = 0; When transaction 1-t2 is triggered, record the current simulation time t1=t, and the system read delay. The simulation time is advanced, and simulation transactions are executed simultaneously. After the simulation transactions and time advancement are completed, the simulation round transaction identifier value is recalculated. The calculation formula is as follows: After transaction 1-t2 is completed, the construction of the second round of transactions will be triggered and executed according to priority.

7. An experimental system employing the blockchain simulation experiment method according to any one of claims 1 to 6, characterized in that, include: Single-process simulation experiment module: used to trigger the simulation through the control node / block operation interaction module; Distributed simulation experiment module: This module is used for collaborative execution by agents distributed across different devices. The start and end of the distributed simulation operation are controlled by a controller that inputs configuration parameters and calls the simulation switch controller. Full-process simulation experiment module: used to read all simulation transactions at once and perform continuous simulation transaction scheduling through an optimized discrete simulation transaction scheduling algorithm.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that, When the program is executed, it implements the steps of the blockchain simulation experiment method according to any one of claims 1-6.

9. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the blockchain simulation experiment method as described in any one of claims 1-6.

Images