A blockchain protocol verification platform that supports multiple consensus protocols and cross-sharding mechanisms

Abstract

The present invention discloses a blockchain protocol verification platform that supports multiple consensus protocols and cross-sharding mechanisms. The platform adopts a modular layered architecture and includes: a client and a blockchain simulation module connected in communication; the client sets the experimental parameters of the blockchain simulation module, obtains transaction data and injects it into the blockchain simulation module, obtains and displays the experimental results of the blockchain simulation module on the transaction data, and the experimental parameters at least include the consensus protocol and sharding parameters; the blockchain simulation module constructs several simulated blockchain sharding networks according to the experimental parameters, and the simulated blockchain sharding networks reach a consensus on the transaction data according to the consensus protocol, and packages the consensus-reaching transaction data into blocks and uploads them to the chain; wherein the consensus protocol at least includes an intra-shard consensus protocol, which can reach a consensus on the transaction data of the simulated blockchain sharding network. The present invention can quickly build an experimental environment for verifying new blockchain protocols and can efficiently verify the correctness and performance of new blockchain protocols.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain technology, and in particular to a blockchain protocol verification platform that supports multiple consensus protocols and cross-sharding mechanisms. Background Art

[0002] Blockchain technology is a decentralized, distributed ledger database with advantages such as data privacy, tamper-proofing, and traceability. Consensus protocols, as the core technology of blockchain, enable multiple nodes in a blockchain to make decisions together and ultimately reach a unified consensus. Blockchain sharding is a blockchain scaling technology that divides the entire blockchain into multiple shards. Each shard can independently handle a portion of transactions and state transitions. This improves the blockchain's processing power and throughput while maintaining its distributed and decentralized nature, making it a key method for blockchain scaling.

[0003] When blockchain researchers propose a new consensus protocol or sharding expansion mechanism, they typically need to conduct extensive experiments to verify its feasibility. However, building a blockchain from scratch that meets these experimental requirements consumes considerable time and effort. Some commercial blockchain systems are extremely large, making their use, adaptation, and deployment difficult and costly. Summary of the Invention

[0004] The purpose of this invention is to provide a blockchain protocol verification platform that supports multiple consensus protocols and cross-sharding mechanisms, so as to solve the technical problems in the existing technology that it is difficult and time-consuming to verify new consensus protocols or sharding mechanisms.

[0005] The purpose of the present invention can be achieved through the following technical solutions:

[0006] A blockchain protocol verification platform that supports multiple consensus protocols and cross-sharding mechanisms. The platform adopts a modular layered system architecture, including:

[0007] Communication connection between client and blockchain simulation module;

[0008] The client sets experimental parameters for the blockchain simulation module to perform simulation, obtains transaction data and injects the transaction data into the blockchain simulation module, obtains and displays experimental results of the blockchain simulation module on the transaction data, and the experimental parameters include at least consensus protocol and sharding parameters;

[0009] The blockchain simulation module constructs a plurality of simulated blockchain shard networks according to the experimental parameters. The simulated blockchain shard networks reach a consensus on the transaction data according to the consensus protocol, and packages the transaction data that reaches consensus into blocks and uploads them to the blockchain.

[0010] Among them, the consensus protocol at least includes an intra-chip consensus protocol, and the intra-chip consensus protocol reaches a consensus on the transaction data within the simulated blockchain shard network.

[0011] Optionally, the layered system architecture includes:

[0012] The storage layer, data layer, network layer, consensus layer, and system layer are connected in sequence;

[0013] Among them, the storage layer stores data, the data layer defines the data structure of various types of data and provides data operation functions, the network layer controls network transmission, the consensus layer reaches consensus on transaction data, and the system layer ensures the normal operation of the experimental system.

[0014] Optionally, the consensus protocol of the consensus layer also includes: an inter-shard consensus protocol, which is used to reach consensus on the transaction data between the simulated blockchain shard networks.

[0015] Optionally, the sharding parameters include at least the number of shards and the number of blockchain nodes in each shard.

[0016] Optionally, the on-chip consensus protocol is a Byzantine fault-tolerant protocol.

[0017] Optionally, the inter-chip consensus protocol includes a preset first inter-chip consensus protocol and a second inter-chip consensus protocol customized by the client.

[0018] Optionally, the first inter-chip consensus protocol is a relay mechanism in Monoxide.

[0019] Optionally, it also includes:

[0020] A code interface module is used by the client to define the second inter-chip consensus protocol.

[0021] Optionally, the simulated blockchain shard network reaching consensus on the transaction data according to the consensus protocol includes:

[0022] Setting a master node for each of the simulated blockchain shard networks. The master node packages a preset amount of transaction data from the transaction pool of the shard in which it is located according to the block generation time to generate a new block and initiate a Byzantine consensus.

[0023] Determine whether there is cross-shard transaction data in the new block. If so, send the cross-shard transaction data to the corresponding target shard, and wait for the target shard to package the cross-shard transaction data and upload it to the chain.

[0024] Optionally, obtaining and displaying experimental results of the blockchain simulation module on the transaction data includes:

[0025] Obtain the protocol performance data and observation data obtained in the experiment, generate corresponding experimental charts based on the protocol performance data and observation data, and generate a log file for protocol debugging. The observation data at least includes information about newly generated blocks, transactions, and throughput of each shard.

[0026] The present invention provides a blockchain protocol verification platform that supports multiple consensus protocols and cross-sharding mechanisms, adopts a modular layered system architecture, and includes: a client and a blockchain simulation module that are communicatively connected; wherein the client sets experimental parameters for simulation by the blockchain simulation module, obtains transaction data and injects the transaction data into the blockchain simulation module, obtains and displays experimental results of the blockchain simulation module on the transaction data, and the experimental parameters at least include consensus protocol and sharding parameters; the blockchain simulation module constructs a plurality of simulated blockchain sharding networks according to the experimental parameters, and the simulated blockchain sharding networks reach consensus on the transaction data according to the consensus protocol, and packages the consensus-reaching transaction data into blocks and uploads them to the chain; wherein the consensus protocol at least includes an intra-chip consensus protocol, and the intra-chip consensus protocol reaches consensus on the transaction data within the simulated blockchain sharding network.

[0027] In view of this, the beneficial effects brought by the present invention are:

[0028] The present invention uses the client to set the experimental parameters of the blockchain simulation module, obtains transaction data and injects it into the blockchain simulation module to obtain experimental results of the transaction data; uses the blockchain simulation module to build one or more simple and practically operable simulated blockchain sharding networks according to the experimental parameters. The simulated blockchain sharding network can reach a consensus on transaction data within or between shards according to the consensus protocol. The blockchain simulation module only provides basic and necessary blockchain components. The present invention only implements the core functions of the blockchain. The system design is more lightweight, which reduces the cost and difficulty of building a blockchain experimental system. It can support users to quickly build an experimental environment for verifying new blockchain protocols, and can efficiently verify the correctness and performance of new blockchain protocols. At the same time, it supports cross-operating system use, which is convenient and fast for local or multi-machine experimental deployment.

[0029] The present invention provides a lightweight distributed blockchain architecture that not only supports traditional single-shard blockchain system experiments, but also supports multi-shard blockchain experiments. It can verify new consensus protocols in multiple blockchains, and support correctness verification and performance testing of multiple blockchain intra-shard consensus protocols and multiple cross-shard transaction mechanisms, making it convenient for users to directly use or conduct secondary development. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 It is a schematic diagram of the architecture of the present invention;

[0031] Figure 2 is a schematic diagram of a layered system architecture module according to an embodiment of the present invention;

[0032] Figure 3 Schematic diagram of the operation process of an embodiment of the present invention. DETAILED DESCRIPTION

[0033] Explanation of terms:

[0034] Blockchain Protocol: A blockchain protocol is a set of underlying rules that define how a blockchain operates. It defines many of the network's characteristics, including security, decentralization, scalability, availability, technical maturity, ecosystem development, and governance, and is one of the core factors affecting the performance and security of a blockchain system.

[0035] Consensus protocol: This allows multiple nodes to jointly make decisions and ultimately reach a unified consensus. The consensus protocol can generally be divided into two steps: block producer election and mainchain consensus. Together, these mechanisms ensure the accuracy and consistency of blockchain data, providing technical support for establishing trust between untrusted entities in a distributed environment.

[0036] Blockchain Sharding: Sharding is a blockchain scaling technology that divides the entire blockchain into multiple parts (shards), each of which can independently process a portion of transactions and state transitions. This technology can improve the processing power and throughput of blockchains while maintaining their distributed and decentralized characteristics, making it a key blockchain scaling tool.

[0037] The state tree is used to store the current state information of the blockchain network. In blockchain, the state tree is typically a data structure based on a Merkle Tree. It is a tree structure composed of a series of nodes, each representing a specific state. The root node of the state tree contains the current state information of the entire blockchain network, such as account balances.

[0038] PBFT: An efficient Byzantine fault-tolerant protocol, it has been widely used in distributed systems such as blockchains to ensure information consistency between nodes. The key concept of the PBFT protocol is to introduce master and slave nodes into the consensus process. These nodes communicate with each other to reach consensus, and a specific protocol is used to ensure message consistency and correctness. The core of the protocol consists of three steps: pre-prepare, prepare, and commit. The master node initiates the prepare message, and the slave nodes, upon receiving it, execute the three steps in sequence. All nodes must execute these steps in order to reach consensus. Relay Mechanism: The Relay mechanism is a cross-shard transaction mechanism (referred to as Relay transactions in this paper) proposed by monoxide at the NSDI 2019 Computer Networks Summit. When a cross-shard transaction occurs, the first half of the cross-shard transaction is packaged and uploaded to the chain. The cross-shard transaction is then sent to the target shard, which then packages the cross-shard transaction and uploads it to the chain, completing the cross-shard transaction.

[0039] Broker mechanism: The Broker mechanism is a cross-shard transaction mechanism proposed by the brokerChain paper presented at the INFOCOM2022 Computer Networks Conference. When a cross-shard transaction occurs, it is completed using a special account called a Broker (market maker). Broker accounts exist in every shard. When a cross-shard transaction is conducted using a Broker account, it is split into two intra-shard transactions: one between the initiator in the original shard and the Broker account in the original shard, and the other between the recipient in the target shard and the Broker account in the target shard.

[0040] BoltDB is an embedded key-value store written in pure Go. It is designed to provide high performance, high reliability, and ease of use, along with ACID transaction support. BoltDB is known for its fast read and write speeds and low-latency query performance. Thanks to its embedded design, BoltDB can be easily integrated into Go applications without requiring additional configuration or management.

[0041] Cross-shard transactions: To improve throughput and scalability, blockchains are typically divided into multiple shards, with each shard processing a portion of transactions. However, due to sharding, the initiator and recipient of a transaction may not be in the same shard, leading to cross-shard transactions. A cross-shard blockchain transaction refers to a transaction that is designed to be processed across different shards.

[0042] The embodiments of the present invention provide a blockchain protocol verification platform that supports multiple consensus protocols and cross-sharding mechanisms, so as to solve the technical problems in the prior art that verifying new consensus protocols or sharding mechanisms is difficult and time-consuming.

[0043] To facilitate understanding of the present invention, the present invention will be described more fully below with reference to the accompanying drawings. Preferred embodiments of the present invention are shown in the drawings. However, the present invention may be embodied in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and comprehensive disclosure of the present invention.

[0044] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this invention pertains. The terms used in this specification of the present invention are for the purpose of describing specific embodiments only and are not intended to limit the present invention. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0045] Blockchain technology is a new distributed infrastructure and computing paradigm that uses block chain data structures to verify and store data, distributed node consensus algorithms to generate and update data, cryptography to ensure the security of data transmission and access, and smart contracts composed of automated script codes to program and operate data. As the blockchain's requirements for network scalability gradually increase, blockchain expansion solutions such as sharding have gradually developed.

[0046] When blockchain researchers propose new consensus protocols or new sharding expansion mechanisms, they generally need to modify and rewrite the data structures and related implementations at the bottom of the original traditional blockchain system. In addition, blockchain researchers often need to conduct sufficient experiments to verify whether the newly proposed consensus protocol or new sharding mechanism is feasible.

[0047] However, building a blockchain that meets experimental requirements from scratch requires a lot of time and effort; moreover, some commercial blockchain systems are very large, and the costs of use, modification, and deployment are relatively expensive.

[0048] Among existing technical solutions, Blockbench is a performance testing framework for private blockchains (a private blockchain simulation and performance evaluation framework). It includes workloads for measuring data processing performance and for testing the performance of different layers of a blockchain system. These workloads can be used to analyze and debug the performance of a blockchain system.

[0049] simBlock is an open-source blockchain network simulator (an event-driven blockchain emulator) that doesn't rely on a real-world environment. It can simulate various network delays and the computing power of different nodes, reducing experimental costs. It also includes a visualization tool that allows users to intuitively see the transformation of data propagation between blocks.

[0050] The existing technology mainly has the following shortcomings:

[0051] (1) Existing technologies focus more on simulating completed blockchain systems or protocols, without considering how to verify newly proposed blockchain protocols and conduct a large number of test experiments.

[0052] (2) The existing blockchain experimental system has high technical complexity, high module coupling, high cost of secondary development, and poor support for blockchain sharding technology.

[0053] In order to solve the pain points of blockchain researchers in conducting experiments, such as the difficulty and high cost of conducting experiments, the present invention provides a simple, versatile, customizable blockchain experiment system BlockEmulator that is suitable for academic research and has a certain possibility of industrialization.

[0054] See also Figure 1 The present invention provides an embodiment of a blockchain protocol verification platform that supports multiple consensus protocols and a cross-sharding mechanism. The platform adopts a modular layered system architecture, including:

[0055] Communication connection between client and blockchain simulation module;

[0056] The client sets experimental parameters for the blockchain simulation module to perform simulation, obtains transaction data and injects the transaction data into the blockchain simulation module, obtains and displays experimental results of the blockchain simulation module on the transaction data, and the experimental parameters include at least consensus protocol and sharding parameters;

[0057] The blockchain simulation module constructs a plurality of simulated blockchain shard networks according to the experimental parameters. The simulated blockchain shard networks reach a consensus on the transaction data according to the consensus protocol, and packages the transaction data that reaches consensus into blocks and uploads them to the blockchain.

[0058] Among them, the consensus protocol at least includes an intra-chip consensus protocol, and the intra-chip consensus protocol reaches a consensus on the transaction data within the simulated blockchain shard network.

[0059] The primary purpose of this embodiment is to rapidly build a blockchain verification platform for verifying the performance of novel blockchain consensus protocols and sharding mechanisms. The blockchain verification platform provided in this embodiment is a lightweight distributed blockchain architecture that simplifies industrial-grade blockchain system implementation, implementing only core blockchain functions, including transaction pools, block packaging, block consensus, and transaction on-chain. It also supports common consensus protocols such as Practical Byzantine Fault Tolerance (PBFT) and provides underlying system support for mainstream blockchain sharding and expansion solutions. For example, classic state sharding and transaction sharding solutions have pre-implemented code modules that researchers can directly call upon based on their actual needs.

[0060] In addition, at the bottom layer of the system, this embodiment also provides a variety of code interface tools necessary for sharding, namely code interface modules. As far as the sharding scheme is concerned, if researchers want to adjust the existing sharding scheme or use a sharding scheme of their own design, they can also simply implement it based on the provided code interface tools.

[0061] The inter-shard consensus protocol in this paper also pre-defines two excellent and common cross-shard transaction schemes: the relay mechanism in Monoxide and the broker mechanism in BrokerChain. Both schemes have been accepted and recognized at top international conferences. In addition to the pre-define cross-shard transaction schemes, the blockchain simulation module also provides sufficient code interface tools for custom cross-shard transactions.

[0062] It should be noted that the consensus protocol (such as the PBFT protocol, the POW protocol, etc.) is a scheme for untrusted entities in a distributed environment to ultimately reach a unified data, and is a broader concept. Specifically, in the present invention, when the blockchain is a traditional non-sharded blockchain system (single-shard blockchain structure), all transaction data occurs within the shard, and there is only an intra-shard consensus protocol. The consensus protocol in this case refers to the intra-shard consensus protocol; when the blockchain is a multi-shard blockchain system, the consensus protocol of the present invention includes an intra-shard consensus protocol and an inter-shard consensus protocol. Transaction data may occur within a shard or across two shards, and can simultaneously support multiple intra-shard consensus protocols and multiple inter-shard consensus protocols.

[0063] In a preferred implementation manner, the consensus protocol of this embodiment may include an intra-shard consensus protocol and an inter-shard consensus protocol (cross-shard transaction mechanism). The intra-shard consensus protocol may be a traditional blockchain consensus protocol such as the Byzantine Fault Tolerant protocol (PBFT protocol) or the Proof of Work protocol (PoW protocol); the inter-shard consensus protocol may include a preset first inter-shard consensus protocol and a client-defined second inter-shard consensus protocol. The first inter-shard consensus protocol may be the relay mechanism in Monoxide or the Broker mechanism in BrokerChain.

[0064] It should be noted that cross-shard transaction data may appear in a multi-shard blockchain system, and it is necessary to design an inter-shard consensus mechanism to reach consensus on these cross-shard transaction data. Therefore, the inter-shard consensus protocol in this embodiment only needs to be designed in specific scenarios (such as a multi-shard blockchain system), and its essence is a cross-shard transaction mechanism.

[0065] In this embodiment, the client can use the code interface module to customize the second inter-chip consensus protocol, and can also modify the intra-chip consensus protocol and the first inter-chip consensus protocol.

[0066] This embodiment is mainly used when blockchain researchers need to verify and perform performance testing on a new blockchain on-chip consensus protocol or cross-shard transaction mechanism. It can quickly build a blockchain experimental system for a second time and perform statistical aggregation of experimental data to facilitate the smooth progress of blockchain experiments.

[0067] Compared with the existing blockchain experimental system with high technical complexity and high module coupling, the present invention adopts a low-coupling design for each part of the blockchain, which can customize the functions of each part of the blockchain very simply and conveniently.

[0068] In this embodiment, the blockchain experimental system consists of a client (a client simulator that generates transactions) and a blockchain simulation module. The client is the platform directly operated by the user and is also the entrance to the entire blockchain experimental system. It is mainly responsible for the following tasks:

[0069] (1) Reading in transaction data so that the accuracy and performance of the blockchain’s intra-shard consensus protocol and possible cross-shard transaction mechanisms can be verified and tested using this transaction data;

[0070] (2) Provide an interactive window between the user and the blockchain, set the experimental parameters for the blockchain simulation module to perform simulation, and the experimental parameters include at least the consensus protocol and sharding parameters. The sharding parameters include at least the number of shards of the blockchain, the number of blockchain nodes in each shard, etc. The consensus protocol may include the intra-shard consensus protocol of each shard and the inter-shard consensus protocol across different shards, etc.

[0071] (3) Observe the operation of the blockchain system, obtain and display the experimental results of the blockchain simulation module on the transaction data, and provide users with the current operation status of the blockchain system.

[0072] In this embodiment, the blockchain simulation module constructs several simulated blockchain shard networks (referred to as simulated blockchains) according to the experimental parameters. Each part of the simulated blockchain shard network is generated according to the parameters provided by the user. For more detailed adjustments or more customized designs, users can use the code interface tools provided by the system of the present invention to perform customized implementations, such as using the intra-shard consensus protocol designed by the user.

[0073] It can be understood that the simulated blockchain sharding network is a simulated blockchain constructed by the blockchain simulation module based on experimental parameters. The simulated blockchain is a simple but actually operational blockchain system. The simulated blockchain has the necessary functions of a real blockchain system, such as block generation, consensus agreement achievement, and transaction execution.

[0074] The blockchain simulation module in this embodiment constructs several simulated blockchain shard networks based on the experimental parameters. The simulated blockchain shard networks reach consensus on the transaction data according to the consensus protocol, and packages the consensus transaction data into blocks and uploads them to the chain.

[0075] See also Figure 2 In the present invention, BlockEmulator adopts a modular layered system architecture, including: a storage layer, a data layer, a network layer, a consensus layer, and a system layer that are sequentially connected in communication; among them, the storage layer stores data, the data layer defines the data structure of various types of data and provides data operation functions, the network layer controls network transmission, the consensus layer reaches consensus on transaction data, and the system layer ensures the normal operation of the experimental system.

[0076] BlockEmulator is designed with a layered architecture. Each layer is responsible for independent transactions and interacts only with its adjacent layers as much as possible to achieve a system-level functional structure, helping users quickly become familiar with the system and reuse and transform code. The entire architecture can be divided into five specific layers, which can be divided into the following according to how close the layers are to real data (transaction data): storage layer, data layer, network layer, consensus layer, and system layer.

[0077] Specifically, the storage layer is mainly responsible for the persistent storage of data. At this layer, the data content and related storage forms of the simulated blockchain storage will be designed, including block storage, blockchain state tree storage, public and private key storage, etc. The storage layer function is implemented based on the boltDB database at this layer.

[0078] The data layer primarily defines the specific form of data in the system. This layer describes the basic data structures of various types of data in the simulated blockchain, including blockchain accounts, transactions, blocks, state trees, nodes, and more. The content of this layer actively interacts with the storage layer. As the simulated blockchain sharding network operates, account information, transaction information, and block information are continuously passed to the storage layer for storage. At the same time, in certain situations (such as replaying the system from a certain moment), the data layer will also read content from the storage layer to instantiate the data. The data layer also provides data manipulation-related functions, such as data encoding and decoding.

[0079] The network layer primarily defines and controls end-to-end packet transmission. In the system of the present invention, end-to-end packet transmission methods include network communication methods, broadcast methods, network information encoding and decoding methods, and so on. Control of end-to-end packet transmission primarily focuses on controlling the transmission bandwidth of the entity (blockchain node). The system achieves this by controlling the frequency of message transmission by the consensus node at a certain moment, such as reducing the rate of ten messages per second to one message per second. Furthermore, the message size can also be controlled. The interaction between the network layer and the data layer involves the transmission of various types of transaction data, block information, and so on within the network layer.

[0080] The consensus layer primarily defines and operates two types of protocols: intra-shard consensus and inter-shard consensus. Intra-shard consensus primarily maintains data consistency across nodes within a shard, while inter-shard consensus maintains data consistency across the shards involved in cross-shard transactions. The consensus layer primarily operates on the network layer, as consensus requires the continuous exchange of various messages between nodes.

[0081] When constructing the entire BlockEmulator, the present invention adopts a layered system design concept, which includes a consensus layer, and then places the consensus protocol and any necessary cross-shard transaction mechanisms within the consensus layer. When the blockchain is a non-sharded blockchain system (such as a single-shard blockchain system), the consensus protocol acts as an intra-shard consensus protocol. In this case, the intra-shard consensus protocol is equivalent to the consensus protocol. Supporting multiple consensus protocols means supporting multiple intra-shard consensus protocols.

[0082] The system layer is mainly responsible for the overall operation of the system. Before the system is running, it reads local data, reads in parameter settings, and prepares the operating environment, including the construction of blockchain nodes. During system operation, it ensures that transaction data is injected according to parameter settings, maintains the stability of data exchange, ensures the preservation of logs and experimental data, etc. After the system is completed, it can draw relevant charts of the saved experimental data, such as the blockchain throughput changing over time.

[0083] The functional operation process of the BlockEmulator system in this embodiment is as follows:

[0084] When blockchain experiments are needed, the system provides default intra-shard consensus protocols and inter-shard consensus protocols. Users can directly select the protocols provided by the system, or modify, transform, or add new protocols to quickly complete the construction of the blockchain protocol experiment system. The main operating steps of the system are as follows:

[0085] (1) The user sets the configuration of the simulated blockchain sharding network according to the experimental needs, including the scale of the shards, the intra-shard and inter-shard protocols, logs, and storage of experimental data, etc.

[0086] (2) The user submits transaction data to the client, which reads the transaction data and continuously injects the transaction data into each shard according to the set experimental parameters.

[0087] (3) In the simulated blockchain, each shard reaches consensus based on the intra-shard consensus protocol. If there is a cross-shard transaction, the inter-shard consensus will also be reached based on the cross-shard protocol.

[0088] (4) When all experimental data are executed, the client sends a termination message to the consensus node. At the same time, the client outputs the protocol performance data obtained in the experiment and draws a chart of the relevant observation data indicators.

[0089] In this implementation, first, the client is used to set the experimental parameters for simulation of the blockchain simulation module, and transaction data is obtained and injected into the blockchain simulation module. The experimental parameters include at least the consensus protocol and sharding parameters; then, the blockchain simulation module is used to construct several simulated blockchain sharding networks according to the experimental parameters, and the simulated blockchain sharding networks are used to reach consensus on the transaction data according to the consensus protocol, and the transaction data that have reached consensus are packaged into blocks and uploaded to the chain; among them, the consensus protocol includes at least the intra-chip consensus protocol, and the intra-chip consensus protocol is used to reach consensus on the transaction data within the simulated blockchain sharding network; finally, the client is used to obtain and display the experimental results of the blockchain simulation module on the transaction data.

[0090] Specifically, when the on-chip consensus protocol is the Byzantine agreement, the simulated blockchain sharding network is used to reach consensus on transaction data according to the consensus protocol, including:

[0091] A master node is set up for each simulated blockchain shard network. The master node packs a preset amount of transaction data from the transaction pool of the shard where it is located according to the block time to generate a block and initiate a Byzantine consensus.

[0092] Determine whether there is cross-shard transaction data in the newly generated block. If so, send the cross-shard transaction data to the corresponding target shard, and wait for the target shard to package the cross-shard transaction data and upload it to the chain.

[0093] See also Figure 3 , the functional operation of BlockEmulator in the present invention is as follows:

[0094] This section uses PBFT intra-shard consensus and the Relay inter-shard mechanism as examples. Users set the relevant configurations of the simulated blockchain through the client, then import the corresponding experimental transaction dataset and run the system. After the system runs, the experimental results can be obtained. The process is as follows:

[0095] (1) The user sets the configuration of the simulated blockchain through the client. The system generates a blockchain of the corresponding scale based on the obtained configuration. According to the PBFT protocol (PBFT is used as an example here), the system sets a master node for each shard. After reading the local data, it starts the nodes of all shards. At the set rate, the system continuously injects experimental transaction data into the transaction pool of each shard until the experimental transaction data is empty.

[0096] (2) According to the block time set by the user, the master node of each shard will pack a certain number of transactions from the transaction pool of the shard to generate a block at the corresponding block time;

[0097] (3) After the master node of the shard packages the transaction to generate a new block, the master node of the shard will initiate the PBFT consensus;

[0098] (4) If there is a cross-shard transaction in the newly generated block (the block in the consensus), it will be processed according to the Relay inter-shard mechanism, that is, the transaction will be sent to the corresponding target shard, and the target shard will package the transaction and execute it on the chain in the target shard;

[0099] (5) After the consensus within the shard is reached (the cross-shard transaction is sent to the corresponding shard and then uploaded to the chain through the intra-shard consensus), the nodes that reach consensus within the shard will upload the block to the chain, update the state tree, and store the data locally persistently; at the same time as the block is uploaded to the chain, the block, transaction and other information will be recorded in the local file to facilitate subsequent analysis by researchers and the generation of charts of relevant indicators;

[0100] (6) When the entire simulated blockchain is running, the client will also observe the operation of the entire blockchain and continuously obtain observation data. This type of observation data includes information about newly generated blocks, transactions, and throughput of each shard;

[0101] (7) After obtaining the observation data, the client will continuously store it in the storage path specified by the local user, so that subsequent users can analyze the blockchain operation process and draw relevant experimental data charts;

[0102] (8) After all transactions are executed and uploaded to the chain, the client will inform all shard nodes to stop running, and organize the experimental results and display them to the user, including drawing relevant charts, etc.

[0103] The following is an example of the use of the present invention:

[0104] (1) System initialization

[0105] Check whether the log file in the log folder (log) in the project folder exists. You can choose to delete or retain it according to user needs. If you need to retain it, you need to change the log generation location or back up the log file.

[0106] Before the system runs, many things still need to be configured in the configuration folder (config), including the client initialization address, node initialization address, block interval, maximum block size, transaction injection speed, etc. However, these parameters all have default values, which can be used directly. For the default consensus protocol, such as the PBFT protocol, the default settings in the PBFT protocol can also be modified, such as the proportion of malicious nodes.

[0107] Open a new client (terminal), enter the project folder, test the system status, and run the following command to view the project help:

[0108] go run main.go utils.go –h

[0109] (2) System Quick Start

[0110] go run main.go utils.go-S[shardNum]-N[nodeNum]-t[path]

[0111] After entering the command, the system will start immediately.

[0112] The client first outputs the configuration information of the entire system, and reads the local transaction data according to the location of the local transaction data in the configuration information. The user can see some simple information obtained by reading the data on the terminal interface, including the number of transactions.

[0113] Then the system will start to build a simulated blockchain sharding network. During the construction process, the system will continuously output relevant configuration information to the client, such as the number of shards, the number of nodes, the addresses of the nodes, etc.

[0114] After the simulated blockchain is built, the client will continuously inject transaction information into the shards, imitating the process of real users submitting transactions. The simulated blockchain will continuously package transactions, generate blocks, and initiate consensus like a real blockchain system.

[0115] After all transactions are executed, the client sends a stop message to all nodes, and the simulated blockchain stops running. The client outputs the observed data, such as throughput, and verifies whether the executed transactions are correct.

[0116] It should be noted that, in addition to being implemented in golang, this embodiment can also be implemented in other languages.

[0117] The blockchain experiment system provided in this embodiment can solve the problems of complex and time-consuming construction of the experimental verification platform when verifying custom consensus protocols or sharding mechanisms in blockchain experiments, as well as the verification of custom blockchain protocols and mechanisms, the generation of experimental charts, and the difficulty of data replay, and provides log files that can be used for data replay and protocol debugging.

[0118] The blockchain experiment system provided in this embodiment has a more lightweight system design, provides basic and necessary blockchain components, and modularizes the system. Each module is decoupled from each other, and provides an API for the corresponding operation of the module. Users can quickly use and conduct secondary development. It can be developed in golang, and cross-operating system operations are relatively simple, and local or multi-machine experimental deployment can be quickly carried out.

[0119] This embodiment not only supports single-shard, that is, traditional single-chain structure blockchain system experiments, but also supports multi-shard blockchain experiments, supports the correctness verification and performance testing of multiple blockchain intra-shard consensus protocols and possible cross-shard transaction mechanisms, and facilitates direct use or secondary development by users.

[0120] The blockchain experimental system provided in this embodiment is an experimental platform that can verify the correctness and performance of new blockchain protocols, reducing the cost and difficulty of learning and transforming a blockchain experimental system. It can support users to quickly build an experimental environment for verifying new blockchain protocols, especially supporting the performance verification of new blockchain sharding protocols. It is written in the Go language, which is lightweight and efficient, with highly readable code and can support cross-operating system use.

[0121] The blockchain protocol verification platform of the present invention adopts a layered system architecture design, which not only provides support for single shards (i.e., traditional blockchain systems) and multi-shard blockchain systems, but also supports multiple traditional blockchain consensus protocols, such as PBFT and PoW protocols; at the same time, it supports popular sharded blockchain system mechanisms, such as Relay and BrokerChain protocols.

[0122] The blockchain experiment system provided in this embodiment uses the client to set the experimental parameters of the blockchain simulation module simulation, obtains transaction data and injects it into the blockchain simulation module to obtain experimental results of the transaction data; uses the blockchain simulation module to build one or more simple and practically operable simulated blockchain sharding networks according to the experimental parameters. The simulated blockchain sharding network can reach a consensus on transaction data within or between shards according to the consensus protocol. The blockchain simulation module only provides basic and necessary blockchain components. The present invention only implements the core functions of the blockchain. The system design is more lightweight, which reduces the cost and difficulty of building a blockchain experiment system. It can support users to quickly build an experimental environment for verifying new blockchain protocols, and can efficiently verify the correctness and performance of new blockchain protocols. At the same time, it supports cross-operating system use, which facilitates and quickly deploys local or multi-machine experiments.

[0123] This embodiment provides a lightweight distributed blockchain architecture that supports not only traditional single-shard blockchain system experiments, but also multi-shard blockchain experiments. It can verify new consensus protocols in multiple blockchains, and support correctness verification and performance testing of multiple blockchain intra-shard consensus protocols and possible multiple cross-shard transaction mechanisms, making it easy for users to directly use or conduct secondary development.

[0124] This embodiment can support both single-shard, i.e., traditional blockchain systems and multi-shard blockchain systems, and supports correctness verification and performance testing of multiple blockchain intra-shard consensus protocols and cross-shard transaction mechanisms, making it convenient for users to directly use or conduct secondary development.

[0125] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0126] In the embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0127] 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 these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0128] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0129] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0130] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A blockchain protocol verification platform that supports multiple consensus protocols and cross-sharding mechanisms, characterized by: The platform adopts a modular layered system architecture, including: Communication connection between client and blockchain simulation module; The client sets experimental parameters for the blockchain simulation module to perform simulation, obtains transaction data and injects the transaction data into the blockchain simulation module, obtains and displays experimental results of the blockchain simulation module on the transaction data, and the experimental parameters include at least consensus protocol and sharding parameters; The blockchain simulation module constructs a plurality of simulated blockchain shard networks according to the experimental parameters. The simulated blockchain shard networks reach a consensus on the transaction data according to the consensus protocol, and packages the transaction data that reaches consensus into blocks and uploads them to the blockchain. Among them, the consensus protocol at least includes an intra-chip consensus protocol, and the intra-chip consensus protocol reaches a consensus on the transaction data within the simulated blockchain shard network.

2. The blockchain protocol verification platform supporting multiple consensus protocols and cross-sharding mechanisms according to claim 1 is characterized in that: The layered system architecture includes: The storage layer, data layer, network layer, consensus layer, and system layer are connected in sequence; Among them, the storage layer stores data, the data layer defines the data structure of various types of data and provides data operation functions, the network layer controls network transmission, the consensus layer reaches consensus on transaction data, and the system layer ensures the normal operation of the experimental system.

3. The blockchain protocol verification platform supporting multiple consensus protocols and cross-sharding mechanisms according to claim 2 is characterized in that: The consensus protocol of the consensus layer also includes: an inter-shard consensus protocol, which is used to reach consensus on the transaction data between the simulated blockchain shard networks.

4. The blockchain protocol verification platform supporting multiple consensus protocols and cross-sharding mechanisms according to claim 1 or 3, characterized in that: The sharding parameters include at least the number of shards and the number of blockchain nodes in each shard.

5. The blockchain protocol verification platform supporting multiple consensus protocols and cross-sharding mechanisms according to claim 1 is characterized in that: The on-chip consensus protocol is a Byzantine fault-tolerant protocol.

6. The blockchain protocol verification platform supporting multiple consensus protocols and cross-sharding mechanisms according to claim 3 is characterized in that: The inter-chip consensus protocol includes a preset first inter-chip consensus protocol and a second inter-chip consensus protocol customized by the client.

7. The blockchain protocol verification platform supporting multiple consensus protocols and cross-sharding mechanisms according to claim 6 is characterized in that: The first inter-chip consensus protocol is the relay mechanism in Monoxide.

8. The blockchain protocol verification platform supporting multiple consensus protocols and cross-sharding mechanisms according to claim 6 is characterized in that: Also includes: A code interface module is used by the client to define the second inter-chip consensus protocol.

9. The blockchain protocol verification platform supporting multiple consensus protocols and cross-sharding mechanisms according to claim 3 is characterized in that: The simulated blockchain shard network reaches consensus on the transaction data according to the consensus protocol, including: Setting a master node for each of the simulated blockchain shard networks. The master node packages a preset amount of transaction data from the transaction pool of the shard in which it is located according to the block generation time to generate a new block and initiate a Byzantine consensus. Determine whether there is cross-shard transaction data in the new block. If so, send the cross-shard transaction data to the corresponding target shard, and wait for the target shard to package the cross-shard transaction data and upload it to the chain.

10. The blockchain protocol verification platform supporting multiple consensus protocols and cross-sharding mechanisms according to claim 1, characterized in that: Obtaining and displaying the experimental results of the blockchain simulation module on the transaction data includes: Obtain the protocol performance data and observation data obtained in the experiment, generate corresponding experimental charts based on the protocol performance data and observation data, and generate a log file for protocol debugging. The observation data at least includes information about newly generated blocks, transactions, and throughput of each shard.

Images