A high-performance blockchain system supporting distributed parallel processing and bidirectional retrieval

Abstract

The present invention discloses a high-performance blockchain system supporting distributed parallel processing and bidirectional retrieval, which relates to the intersection of blockchain technology and parallel computing, including an initialization and resource scheduling module, a network data transceiver module, a retrieval service module and a parallel processing module. The parallel processing module includes a block data parallel processing module, a transaction data parallel processing module and a contract data parallel processing module. The retrieval service module includes a transaction query component and a contract query component. The present invention adopts the above-mentioned high-performance blockchain system supporting distributed parallel processing and bidirectional retrieval. For transaction data under the UTXO model, it not only stores transaction data in a distributed manner, but also extracts script contract data in transaction output and input, and also performs distributed storage, verification and query.

Description

Technical Field

[0001] The present invention relates to the intersection of blockchain technology and parallel computing, and in particular to a high-performance blockchain system that supports distributed parallel processing and bidirectional retrieval. Background Art

[0002] In the existing blockchain technology, a blockchain ledger network has tens of thousands of blockchain nodes, and each blockchain node is usually operated and supported by a single computer device. For example, the widely used Ethereum blockchain system repeatedly verifies the same transactions and blocks. Although there are tens of thousands of computer devices in the network, these blockchain systems are difficult to process and carry large-scale high-throughput transaction data, so the blockchain network is also an inefficient mirror computer network. In order to improve performance, it is usually necessary to distribute the consensus node system in a blockchain node in a cluster of multiple computer devices.

[0003] In a blockchain network based on the account model, the state associated with a certain account address needs to be updated sequentially. Changes in the order of updates will affect the final result of the state. At the same time, the subsequent update operation often requires the result of the previous update operation. Therefore, the previous and subsequent state updates often need to be processed serially. The state update instruction is triggered by sending a blockchain transaction. Therefore, it is difficult for a blockchain system based on the account model to process each transaction completely in parallel, and the proportion of parallelizable tasks in the entire system is low.

[0004] In a blockchain network based on the Unspent Transaction Output (UTXO) model, each Transaction Output (TXO) is an independent state data. Each TXO is uniquely specified by the identification number TXID of the transaction in which it is located and the output sequence number VOUT position in this transaction. The two data are called "output pointers", that is, the data set {TXID, VOUT} is called "TXO pointer". Different UTXOs can be independently verified when they are spent, so large-scale parallelism can be supported. However, large-scale parallel transaction processing will be accompanied by a large number of UTXO fragments, making retrieval difficult;

[0005] The blockchain systems based on the account model and the UTXO model have the characteristics of efficient retrieval and efficient parallelism respectively, and it is difficult to take both into account.

[0006] Therefore, this solution discloses a new parallel processing solution, providing a high-performance blockchain system that supports distributed parallel processing and bidirectional retrieval to solve the above problems. Summary of the invention

[0007] The purpose of the present invention is to provide a high-performance blockchain system that supports distributed parallel processing and bidirectional retrieval. By using hash table technology, the TXO pointer and token quantity data with the same locking script contract data are stored in the same storage location to provide a retrieval service that is as concise and efficient as the account model, solving the problem of balancing efficient parallel processing and efficient retrieval.

[0008] To achieve the above-mentioned object, the present invention provides a high-performance blockchain system supporting distributed parallel processing and bidirectional retrieval, including an initialization and resource scheduling module, a network data transceiver module, a retrieval service module and a parallel processing module, wherein the parallel processing module includes a block data parallel processing module, a transaction data parallel processing module and a contract data parallel processing module, and the retrieval service module includes a transaction query component and a contract query component;

[0009] The data processing process of the network data transceiver module specifically includes the following steps:

[0010] S1: Receive block data and transaction data from blockchain network nodes and user terminals, determine the corresponding processing unit based on the parallel task-processing unit mapping table constructed in the initialization and resource scheduling module, and if the received data is block data, send the data to the corresponding processing unit of the block parallel processing module; if the received data is transaction data, send the data to the corresponding parallel processing unit of the transaction parallel processing module;

[0011] S2: Receive the block data from the block parallel processing module and the transaction data from the transaction parallel processing module, and send the block data and transaction data to the corresponding blockchain network nodes and user terminals.

[0012] Preferably, in step S1, the initialization and resource scheduling module is responsible for processing the startup and initialization of the parallel task-processing unit, the parallel task-processing unit is set to single-threaded or multi-threaded, the initialization and resource scheduling module manages the allocation and scheduling of computing tasks, and determines the number of processing units that need to be started for the block parallel processing module and the transaction parallel processing module, the mapping relationship and topological structure of the parallel processing unit and a single computing device in the computer cluster by reading the configuration file or using the empirical algorithm, and constructs and manages the parallel task-processing unit mapping tables at three levels of block data verification, transaction data verification and contract data verification.

[0013] Preferably, in step S1, the process of processing the node data by the block data parallel processing module specifically includes:

[0014] S11: parse the block data received from the network data transceiver module, parse and check the legitimacy of the block header data, parse the transaction data contained therein, and send the transaction data to the transaction parallel processing module;

[0015] S12: receiving the processing and verification results sent back by the transaction parallel processing module, summarizing the processing and verification results, and marking the corresponding block as legal if both the block header data and the transactions within the block are legal; marking the corresponding block as illegal if the block header data or the transactions within the block are illegal;

[0016] S13: If the node where the block data is located undertakes the block propagation task, the corresponding block marked as legal is sent to the network data transceiver module.

[0017] Preferably, for low-load scenarios with a small amount of block data, the block data parallel processing module sets the number of parallel tasks to 1, and starts and uses a single processing unit.

[0018] Preferably, in step S1, the process of the transaction data parallel processing module processing the node data specifically includes:

[0019] Step 1: Receive and parse the transaction data from the network data transceiver module, calculate and construct a simplified set of transaction data, which includes the hash value data of the "unlocking script" and "locking script" contract data or the derivative data based on the hash value data of the "unlocking script" and "locking script" contract data, but does not include the complete "unlocking script" and "locking script" contract data;

[0020] Step 2: Process the transaction input data in sequence, locate the TXO of the parent transaction through the "output pointer", obtain the "locking script" contract data corresponding to the TXO, determine the position or number of the parallel processing unit of the "locking script" contract data based on the "parallel task-processing unit" mapping table of the contract data verification layer constructed in the initialization and resource scheduling module, and send the "unlocking dependency data" of the current transaction input to the parallel processing unit of the corresponding contract for verification. The "unlocking dependency data" includes the "unlocking script" contract data of the current transaction input and the simplified set of transaction data of the current transaction;

[0021] Step 3: Process the transaction output data in sequence, parse and obtain the TXO data including the "locking script" contract data, obtain the hash value of the "locking script" contract data according to the hash function, obtain the position or number of the corresponding parallel processing unit based on the "parallel task-processing unit" mapping table of the contract data verification layer constructed in the initialization and resource scheduling module, and define the data set containing the TXO data and the TXO pointer as "locking data" according to the position or number of the parallel processing unit, and send the "locking data" to the corresponding parallel processing unit of the contract data parallel processing module;

[0022] Step 4: Check the transaction legitimacy requirements except for the unlocking verification of a single transaction input, calculate the minimum transaction fee stipulated by the current blockchain network consensus based on the transaction data and transaction fee rate, and the actual transaction fee paid is higher than the minimum transaction fee;

[0023] Step 5: Receive the verification result sent back by the contract parallel processing unit for the transaction input data processed in step 2. If the verification result contains "failed", mark the entire transaction as an illegal transaction;

[0024] Step 6: Integrate the verification results of steps 1 to 5 to obtain the overall legitimacy verification result of the transaction data, and send the overall legitimacy verification result of the transaction data back to the block data parallel processing module.

[0025] Preferably, in step 3, the contract data parallel processing module processes the unlocking dependent data and the locking data in the following manner:

[0026] Step 3-1: Receive the “locking data” and “unlocking dependency data” from the transaction data parallel processing module, and parse the “locking data” and “unlocking dependency data”;

[0027] Step 3-2: When the received data is "locked data", determine the data table location of the corresponding contract according to the hash value of the TXO lock script in the "locked data", save the TXO pointer in the "locked data" in the data table, and mark the TXO pointer in the "locked data" as an unspent transaction output UTXO;

[0028] Step 3-3: When the received data is "unlock dependent data", obtain the data table location of the corresponding UTXO to be unlocked, check whether the corresponding TXO pointer is UTXO, if the corresponding TXO pointer is UTXO, the corresponding TXO has not been spent; if the corresponding TXO pointer is not UTXO, the corresponding TXO has been spent;

[0029] Step 3-4: If the corresponding TXO has been spent, the verification fails and the verification error result is returned to the transaction parallel processing unit;

[0030] Step 3-5: If the corresponding TXO has not been spent, concatenate the "unlock script" in the "unlock dependent data" and the "lock script" of the corresponding contract in sequence to obtain a new script, and execute the new script in the contract computing virtual machine, and send the verification result after execution back to the transaction parallel processing unit;

[0031] Step 3-6: If the verification is successful, mark the TXO pointer as spent TXO at the data table location corresponding to UTXO, and add the transaction number TXID of the transaction that unlocks and spends the UTXO.

[0032] Preferably, in steps 3-1 to 3-6, if the received "unlock dependency data" belongs to a transaction in a packaged block, the block height and block hash value of the corresponding block are added to the position of the data table where the corresponding UTXO is located, thereby increasing the amount of information of the contract query.

[0033] Preferably, the retrieval service module includes a distributed block query component, a transaction query component, a contract query component and a query forwarding component. The query forwarding component provides distributed bidirectional retrieval and query services and a unified external query interface service. Based on the "parallel task-processing unit" mapping table of the transaction data verification layer and the "parallel task-processing unit" mapping table of the contract data verification layer constructed in the initialization and resource scheduling module, it obtains the storage location of the transaction data and the contract data in the device, receives a query request, and forwards the query request to the transaction query component or the contract query component where the data to be queried is located.

[0034] Preferably, if the "locking script" of the contract to be queried is the same, the collection and calculation of the query are completed locally.

[0035] Preferably, when data is communicated between all the above modules, Infiniband or RoCE lossless network, RDMA technology on lossless network or message passing interface technology is used, and non-blocking sending and receiving functions are used to increase the parallel processing performance between modules.

[0036] Therefore, the present invention adopts the above-mentioned high-performance blockchain system that supports distributed parallel processing and bidirectional retrieval, which has the following beneficial effects:

[0037] (1) Fast verification speed: A multi-layer parallel processing model for UTXO model blockchain nodes is proposed, which enhances the precision of parallel tasks, increases the proportion of computing tasks that can be processed in distributed parallel, improves the large-scale scalability of transaction verification, and enhances transaction processing performance, making the blockchain system a high-throughput, low-cost infrastructure platform.

[0038] (2) High retrieval efficiency: By storing the transaction list of the same contract script (analogous to the capital account) locally or in the nearest neighbor, the collection operation is localized or processed in the nearest neighbor, which reduces the demand for communication between nodes, reduces retrieval delay and retrieval cost, improves the user experience of blockchain applications, and helps blockchain application software improve its competitiveness;

[0039] (3) The two-way search capability of checking transactions to obtain contracts and checking contracts to obtain transactions is realized at the bottom layer of the blockchain, which facilitates the development of application software;

[0040] (4) Because this design distributes the verification calculations of the same contract script to run on the same computing device, it provides an implementation basis for hardware customization of contract script verification, can support low-cost and high-performance hardware platforms, and help further reduce service costs.

[0041] The technical solution of the present invention is further described in detail below through the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 This is a system architecture diagram of an embodiment of a high-performance blockchain system supporting distributed parallel processing and bidirectional retrieval according to the present invention;

[0043] Figure 2 It is a transaction data transmission, parallel processing, storage and retrieval model diagram of a high-performance blockchain system embodiment supporting distributed parallel processing and bidirectional retrieval of the present invention;

[0044] Figure 3 It is a distributed topological structure of each module and processing unit of Embodiment 1 of a high-performance blockchain system supporting distributed parallel processing and bidirectional retrieval of the present invention;

[0045] Figure 4 This is a distributed topological structure of modules and processing units of a high-performance blockchain system embodiment 2 that supports distributed parallel processing and bidirectional retrieval in the present invention. DETAILED DESCRIPTION

[0046] The technical solution of the present invention is further described below through the accompanying drawings and embodiments.

[0047] Unless otherwise defined, technical or scientific terms used in the present invention shall have the common meanings understood by one having ordinary skills in the field to which the present invention belongs.

[0048] The words "include" or "comprises" and the like used in the present invention mean that the elements before the word include the elements listed after the word, and do not exclude the possibility of also including other elements. The orientation or position relationship indicated by the terms "inside", "outside", "upper", "lower", etc. is based on the orientation or position relationship shown in the drawings, which is only for the convenience of describing the present invention and simplifying the description, and does not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, it cannot be understood as a limitation of the present invention. When the absolute position of the described object changes, the relative position relationship may also change accordingly. In the present invention, unless otherwise clearly specified and limited, the terms "attachment" and the like should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral body; it can be directly connected, or indirectly connected through an intermediate medium, and it can be the internal connection of two elements or the interaction relationship between two elements. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0049] like Figure 1As shown, the present invention provides a high-performance blockchain system supporting distributed parallel processing and bidirectional retrieval, including an initialization and resource scheduling module, a network data transceiver module, a retrieval service module and a parallel processing module, the parallel processing module includes a block data parallel processing module, a transaction data parallel processing module and a contract data parallel processing module, and the retrieval service module includes a transaction query component and a contract query component;

[0050] like Figure 2 As shown, the data processing process of the network data transceiver module specifically includes the following steps:

[0051] S1: Receive block data and transaction data from blockchain network nodes and user terminals, determine the corresponding processing unit based on the parallel task-processing unit mapping table constructed in the initialization and resource scheduling module, and if the received data is block data, send the data to the corresponding processing unit of the block parallel processing module; if the received data is transaction data, send the data to the corresponding parallel processing unit of the transaction parallel processing module;

[0052] S2: Receive the block data from the block parallel processing module and the transaction data from the transaction parallel processing module, and send the block data and transaction data to the corresponding blockchain network nodes and user terminals.

[0053] In step S1, the initialization and resource scheduling module is responsible for processing the startup and initialization of the parallel task-processing unit. The parallel task-processing unit is set to single-threaded or multi-threaded. The initialization and resource scheduling module manages the allocation and scheduling of computing tasks. By reading the configuration file or using the empirical algorithm, it determines the number of processing units that need to be started for the block parallel processing module and the transaction parallel processing module, the mapping relationship and topological structure of the parallel processing unit and a single computing device in the computer cluster, and constructs and manages the parallel task-processing unit mapping tables at three levels: block data verification, transaction data verification, and contract data verification.

[0054] In step S1, the block data parallel processing module processes the node data in the following specific steps:

[0055] S11: Receive the block data from the network data transceiver module, parse and check the legitimacy of the block header data, parse the transaction data contained therein, check the legitimacy of the format of the transaction data, and send the parsed legal transaction data to the transaction parallel processing module;

[0056] S12: receiving the processing and verification results sent back by the transaction parallel processing module, summarizing the processing and verification results, and marking the corresponding block as legal if both the block header data and the transactions within the block are legal; marking the corresponding block as illegal if the block header data or the transactions within the block are illegal;

[0057] S13: If the node where the block data is located undertakes the task of block propagation, the corresponding block marked as legal will be sent to the network data transceiver module. If the node where the block data is located undertakes the task of block production, a legal transaction list will be created, and the legal transaction list will be assembled into a candidate block, which will be sent to a self-built or remote mining pool.

[0058] For low-load scenarios with small amounts of transaction data, the block data parallel processing module sets the number of parallel tasks to 1, starts, and uses a single processing unit.

[0059] In step S1, the process of the transaction data parallel processing module processing the node data specifically includes:

[0060] Step 1: Receive and parse the transaction data from the network data transceiver module, calculate and construct a simplified set of transaction data, which includes the hash value data of the "unlocking script" and "locking script" contract data or the derivative data based on the hash value data of the "unlocking script" and "locking script" contract data, but does not include the complete "unlocking script" and "locking script" contract data;

[0061] Step 2: Process the transaction input data in sequence, locate the TXO of the parent transaction through the "output pointer", obtain the "locking script" contract data corresponding to the TXO, determine the position or number of the parallel processing unit of the "locking script" contract data based on the "parallel task-processing unit" mapping table of the contract data verification layer constructed in the initialization and resource scheduling module, and send the "unlocking dependency data" of the current transaction input to the parallel processing unit of the corresponding contract for verification. The "unlocking dependency data" includes the "unlocking script" contract data of the current transaction input and the simplified set of transaction data of the current transaction;

[0062] Step 3: Process the transaction output data in sequence, obtain the corresponding "locking script" contract data and Token Value as TXO data, obtain the hash value of the "locking script" contract data according to the hash function, obtain the position or number of the corresponding parallel processing unit based on the "parallel task-processing unit" mapping table of the contract data verification layer constructed in the initialization and resource scheduling module, and define the data set containing TXO data and TXO pointer as "locking data" according to the position or number of the parallel processing unit, and send the "locking data" to the corresponding parallel processing unit of the contract data parallel processing module;

[0063] In step 3, the contract data parallel processing module and the transaction data parallel processing module use the same computer. The contract data parallel processing module processes the unlocking dependent data and the locking data in the following specific steps:

[0064] Step 3-1: Receive the “locking data” and “unlocking dependency data” from the transaction data parallel processing module, and parse the “locking data” and “unlocking dependency data”;

[0065] Step 3-2: If the received data is "locked data", determine the data table location of the corresponding contract according to the hash value of the TXO lock script in the "locked data", save the TXO pointer in the "locked data" in the data table, and mark the TXO pointer in the "locked data" as an unspent transaction output UTXO;

[0066] Step 3-3: If the received data is "unlock dependent data", obtain the data table location of the corresponding UTXO to be unlocked, check whether the corresponding TXO pointer is UTXO, if the corresponding TXO pointer is UTXO, the corresponding TXO has not been spent; if the corresponding TXO pointer is not UTXO, the corresponding TXO has been spent;

[0067] Step 3-4: If the corresponding TXO has been spent, the verification fails and the verification error result is returned to the transaction parallel processing unit;

[0068] Step 3-5: If the corresponding TXO has not been spent, concatenate the "unlock script" in the "unlock dependent data" and the "lock script" of the corresponding contract in sequence to obtain a new script, and execute the new script in the contract computing virtual machine, and send the verification result after execution back to the transaction parallel processing unit;

[0069] Step 3-6: If the verification is successful, mark the TXO pointer as spent TXO at the data table location corresponding to UTXO, and add the transaction number TXID of the transaction that unlocks and spends the UTXO.

[0070] In steps 3-1 to 3-6, if the received "unlock dependency data" belongs to a transaction in a packaged block, the block height and block hash value of the corresponding block are added to the location of the data table where the corresponding UTXO is located to increase the amount of information in the contract query.

[0071] Step 4: Check the transaction legitimacy requirements other than the single transaction input, calculate the minimum transaction fee stipulated by the current blockchain network consensus based on the transaction data volume and transaction fee rate, and the actual transaction fee paid is higher than the minimum transaction fee;

[0072] Step 5: Get the transaction input data processed in step 2, and receive the verification result sent back by the contract parallel processing unit. If the verification result contains "failed", mark the entire transaction as an illegal transaction;

[0073] Step 6: Integrate the verification results of steps 1 to 5 to obtain the overall legitimacy verification result of the transaction data, and send the overall legitimacy verification result of the transaction data back to the block data parallel processing module.

[0074] The retrieval service module includes a distributed block query component, a transaction query component, a contract query component and a query forwarding component. The query forwarding component provides distributed two-way retrieval and query services and a unified external query interface service. Based on the "parallel task-processing unit" mapping table of the transaction data verification layer and the "parallel task-processing unit" mapping table of the contract data verification layer constructed in the initialization and resource scheduling module, it obtains the storage location of the transaction data and the contract data in the device, receives a query request, and forwards the query request to the transaction query component or contract query component where the data to be queried is located.

[0075] If the "locking script" of the contract to be queried is the same, the collection and calculation of the query are completed locally.

[0076] When all the above modules communicate data, use Infiniband or RoCE network lossless network, RDMA technology on lossless network or message passing interface technology, and use non-blocking sending and receiving functions to increase the parallel processing performance between modules.

[0077] When the transaction parallel processing unit processes each transaction output in sequence, when the locking script of the processed transaction output is encoded as an unspendable transaction output, or when the specific type of transaction output is set to be unlocked in the blockchain consensus protocol, the transaction output cannot be recorded as an unspent transaction output UTXO, and the transaction output will not be sent to the contract parallel processing unit for distributed storage.

[0078] Example 1

[0079] In this embodiment, taking the blockchain using the UTXO model as an example, a model for the segmentation, distributed verification and storage of blockchain transaction data is disclosed. This embodiment does not limit the hardware type of the computer cluster. Computers based on processors of the X86 or ARM instruction set or hardware devices designed for this solution can be used as devices in the computer cluster. In order to reduce communication delay time and avoid the possibility of network data packet loss, data communication between all modules is designed using a lossless network based on Infiniband. If other lossy networks are used, it is necessary to add reception confirmation and packet loss detection during implementation. When packet loss occurs, the network data transceiver module can resend and receive;

[0080] In the initialization and resource scheduling module, the MPI function library and tools are used to start and manage processes in a distributed manner on computer cluster devices, allocate computing tasks on each process, and communicate between processes. The open source library OpenMPI that complies with the MPI specification is selected. The specific initialization and resource scheduling process in the initialization and resource scheduling module is as follows:

[0081] First, compile a text document hosts, which is a mapping table between processes and devices, and fill in the text as follows:

[0082] Host1 slots=2

[0083] Host2 slots=10

[0084] Host3 slots=10

[0085] Host4 slots=10

[0086] Host5 slots=10

[0087] On the computer device Host0, you can use the Secure Shell protocol to log in to Host1, Host2, Host3, Host4, and Host5. You can execute mpiexec--hostfile hosts program.exec on the Host0 system terminal. At this time, a process will be started on Host1, and 10 processes will be started on Host2-Host5 respectively, a total of 42 processes, and the program.exec program will be run at the same time. During the execution of any program.exec process, the MPI function library can be used to detect the number of all processes and the number of the current process. The specific MPI function library is as follows:

[0088] MPI_Comm_size(MPI_COMM_WORLD,&procSum);

[0089] MPI_Comm_rank(MPI_COMM_WORLD,&procIndex).

[0090] At this time, procIndex stores the number of the current process, and procSum stores the total number of all processes. The total number of all processes is 42. The 42 processes are numbered in sequence according to the node list and the number of processes in the hosts file. The values ​​of procIndex are 0 to 41. If the program detects that the current process number procIndex is 0, the corresponding process executes the network data receiving and sending module and the block data processing module; if the program detects that the current process number procIndex is 1, the corresponding process executes the two-way retrieval service module;

[0091] If the program detects that the current process number is greater than 1 and mod(procIndex-2,10) belongs to {0,…,3}, the corresponding program executes the transaction processing module, so there are 16 processes distributed on the 4 computing devices host2-host5 as 16 transaction processing units respectively; if the program detects that the current process number is greater than 1 and mod(procIndex-2,10) belongs to {4,…,7}, the corresponding program executes the contract processing module, so there are also 16 processes distributed on the 4 computing devices as 16 contract processing units respectively. If the program detects that the current process mod(procIndex-2,10) is 8, the corresponding program provides the local transaction query service of the device to which it belongs. If the program detects that the current process mod(procIndex-2,10) is 9, the corresponding program provides the local contract query service of the device to which it belongs, where the function mod is the remainder function, and mod(A,B) represents the remainder of A divided by B.

[0092] The distribution topology of the above modules and processing units is as follows: Figure 3 As shown;

[0093] If the program obtains a transaction data when executing the network data transceiver module, or executes step S11 in the block data processing module, the corresponding program calculates the transaction identification number TXID of the transaction data, and obtains the processing process number of the corresponding transaction according to the transaction identification number TXID. If the first 4 bits of the binary data of the transaction identification number TXID are taken to express 16 numbers from 0 to 15, the 16 numbers correspond to 16 transaction processing units respectively, and a "transaction ID-processing unit" mapping table is established. According to the "transaction ID-processing unit" mapping table, the processing unit of the current transaction and the processing process number of the corresponding transaction are determined, and the transaction data is sent to the remote processing unit through the non-blocking MPI point-to-point process communication function. Since the TXID calculation is based on the hash algorithm, the first 4 bits of the TXID value have a good uniform distribution feature, so that the 16 transaction processing units can obtain a relatively uniform number of processing tasks;

[0094] The transaction parallel processing unit receives the transaction data and performs checks and verifications other than contract script verification. When the transaction parallel processing unit processes the contract script verification of a single transaction input data in sequence, it needs to send the unlocking dependency data to the contract parallel processing unit where the corresponding locking script contract is located;

[0095] As shown in Table 1: Example of transaction data instances, the streamlined transaction data set can be set to any “intermediate transaction data set” when performing hierarchical pruning using the hierarchical hashing algorithm;

[0096] Table 1: Example of transaction data instance

[0097] ;

[0098] In this embodiment, all locking script data in the transaction data set are replaced with the locking script hash value, and all unlocking script data in the transaction data set that is not currently input is deleted to obtain a streamlined transaction data set. The selection method of the streamlined transaction data set is not limited. The purpose is to minimize the amount of data transmission while satisfying the premise of contract verifiability.

[0099] Taking the first input of the transaction as an example, the version number (Version), transaction freezing time (LockTime), input count (InputsCount), output count (OutputsCount), output sequence number (Vout), sequence (Sequence), "unlocking script" contract data (UnlockingScript), "locking script" contract data (LockingScript), amount (TokenValue), locking script hash value (LockingScriptHash), locking script hash value (LockingScriptHash) is defined as Hash (Output: LockingScript), "unlocking dependent data" is {Version, LockTime, InputsCount, OutputsCount, Input1: TXID, Input1: Vout, Input1: Sequence, Input1: UnlockingScript, Input2: TXID, Input2: Vout, Input2: Sequence, Input3..., Output1: TokenValue, Output1: LockingScriptHash, Output2: TokenValue, Output2: LockingScriptHash, Output3...};

[0100] The position of the locking script to be unlocked is located through the output pointer {TXID, VOUT}, wherein the "transaction ID-processing unit" mapping table established by the transaction identification number TXID is used, and the hash value of the locking script is queried through the MPI point-to-point communication function, or the locking script is first queried and the hash value of the locking script is obtained through hash calculation, and the method of establishing the "transaction ID-processing unit" mapping table by the transaction identification number TXID is used, and the "locking script hash value-contract processing unit" mapping table is established using the locking script hash value. The establishment method of the "transaction ID-processing unit" mapping table and the "locking script hash value-contract processing unit" mapping table is not limited, and the position starting point of the 4-bit data used can be changed, which will not affect the technical advantages and application effects of this solution;

[0101] According to the established "locking script hash value-contract processing unit" mapping table, obtain the contract parallel processing unit where the locking script contract of the UTXO to be unlocked is located, and send the "unlocking dependency data" to the corresponding processing process for contract verification through the MPI point-to-point communication function. At the same time, obtain the contract verification result under the corresponding transaction input number through the MPI point-to-point communication function. After the transaction processing unit obtains the verification results of all inputs of a transaction, the unlocking script and locking script of the transaction data are deleted and replaced with the hash values ​​of the unlocking script and locking script of the transaction data to reduce data storage pressure;

[0102] When the transaction parallel processing unit processes a single transaction output data in sequence, it queries the "locking script hash value-contract processing unit" mapping table according to the hash value of the locking script of the current transaction output, obtains the contract processing unit and its process number corresponding to the newly generated UTXO, and sends the output pointer of the output, that is, the TXID number of this transaction and the sequence number VOUT of this output, as well as the TokenValue and locking script of the output to the aforementioned queried contract parallel processing unit for processing and storage;

[0103] When the contract parallel processing unit receives a new UTXO, it saves the UTXO in a local data table. The key in the saved data "key-value pair" is the hash value of the locking script of the UTXO. The change in the hash value is to add a spendable "data strip", as shown in Table 2: UTXO information column in the contract data table. If and only if the transaction in which the UTXO is located has been effectively packaged into a block and has a block hash value, it is filled in the <block> column;

[0104] If the contract parallel processing unit receives the "unlock data", locate the data strip of the UTXO, splice the unlock script in the unlock data with the lock script of the current UTXO data strip to form a complete contract unlock instruction, and use other unlock data as context data for the instruction to execute the instruction and obtain the instruction execution result as the contract verification result, and update the UTXO data strip according to the execution result, as shown in Table 2: The spending information column in the contract data table. If and only if the transaction containing the unlock data has been effectively packaged into a block and has a block hash value, fill it in the <spending block> column;

[0105] Table 2: Contract data table

[0106] ;

[0107] The transaction data table and contract data table are stored in four devices distributed by 16 processing units. The processes with mod(procIndex-2,10) of 8 and 9 respectively process the transaction query service and contract query service of the device, which are also distributed in the same four devices.

[0108] The specific service process is as follows: when the two-way retrieval service module numbered 1 receives a transaction query request, it obtains the device location of the processing unit according to the TXID of the requested transaction and the "transaction ID-processing unit" mapping table, obtains the process number of the transaction query service process at the same device location, sends the request to the process number through MPI point-to-point communication, receives the return result, and finally returns the result to the requester. When the two-way retrieval service module numbered 1 receives a contract query request, it also obtains the device location of the processing unit of the locking script according to the hash value of the queried contract and the "locking script hash value-contract processing unit" mapping table, and forwards the request to the contract query service process at the device through MPI point-to-point communication. The contract query service process can process all related transactions related to the contract locally, and then return the complete result to the two-way retrieval service module. After receiving the return result, the two-way retrieval service module returns the result to the requester.

[0109] In this embodiment, after the transaction parallel processing unit receives the contract verification result of the contract parallel processing unit, the locking script and the unlocking script in the transaction data saved in the transaction parallel processing unit can be replaced with the hash values ​​of the locking script and the unlocking script; finally, the transaction data retained in the transaction parallel processing unit is: {Version, LockTime, InputsCount, OutputsCount, Input1: TXID, Input1: Vout, Input1: Sequence, Hash(Input1: UnlockingScript), Input2: TXID, Input2: Vout, Input2: Sequence, Hash(Input2: UnlockingScript), Input3…, Output1: TokenValue, Hash(Output1: LockingScript), Output2: TokenValue, Hash(Output2: LockingScript), Output3…};

[0110] In this embodiment, a method of layered trimming of transaction data is used. The transaction data retained in the transaction parallel processing unit is used. The locking script and the unlocking script are not used, but the hash value of the locking script and the hash value of the unlocking script are used instead. The transaction number TXID of the transaction can be recalculated, so that the retained transaction data has the ability to verify the authenticity, and can be identified when errors occur in the retained transaction data, thereby increasing the security of the data and providing secure, verifiable and trimmed transaction data for the transaction query component.

[0111] In this embodiment, the unspendable transaction output can be derived from the consensus protocol or from a specific script program written, for example, it can be set by the consensus protocol to have an "Op_Return<Other Script / Data> " structure, a locking script that is set by the consensus protocol to have a zero TokenValue for the output, and is written so that there is no unlocking script that can be verified (for example: "Op_False Op_Return <otherscript data>”).

[0112] Example 2

[0113] This embodiment is adjusted on the basis of the embodiment 1, and the implementation capability and superiority of this solution can be migrated under the distributed topology of different transaction types or different processing units.

[0114] In this embodiment, the compiled mapping table hosts text document of processes and devices is as follows:

[0115] Host1 slots=1

[0116] Host2 slots=1

[0117] Host3 slots=1

[0118] Host4 slots=9

[0119] Host5 slots=9

[0120] Host6 slots=9

[0121] Host7 slots=9

[0122] The number of devices and processes in the hosts file can be configured differently.

[0123] The system of this embodiment runs in a cluster consisting of 7 computers. The 7 computers start 1-9 processes respectively according to the mapping relationship of the hosts document, and a total of 39 processes are started in a distributed manner. The 39 processes are numbered 0-38 in sequence, and the network data transceiver module, the block parallel processing module, the retrieval service module, 8 transaction parallel processing units and 1 transaction query service component, 8 transaction parallel processing units and 1 transaction query service component, 8 contract parallel processing units and 1 contract query service component, and 8 contract parallel processing units and 1 contract query service component are run in sequence;

[0124] The distribution topology of the above modules and processing units is as follows: Figure 4 As shown;

[0125] In this embodiment, the transaction parallel processing unit and the contract parallel processing unit run in different computer devices. At this time, the computing and communication characteristics of different types of processing units are different, which can facilitate the design and use of customized computer devices respectively, but it does not affect the distributed data processing capabilities, and does not affect the application effect and advantages of this solution.

[0126] In this embodiment, for transactions with isolated witness zone data and payment to script hash value output, such as P2WSH transactions or P2TR transactions, it is necessary to implement them differently at the transaction and contract processing level. The specific implementation plan is as follows:

[0127] As shown in Table 3, in a transaction with isolated witness area data and payment to the script hash value output, the isolated witness label WitnessLabel is used to mark the transaction as an isolated witness transaction. The WitnessFlag data generally includes two parts: Marker and Flag. This type of transaction is in the input data space of the current transaction. The unlocking script can be blank. The unlocking script required for contract verification is moved to the witness area and is called the witness area unlocking data WitnessData.

[0128] Table 3: Transaction data table with segwit zone data and pay-to-script-hash output

[0129] ;

[0130] In the transaction output data space, the corresponding locking script is replaced by the locking script hash value. The locking script hash value LockingScriptHash and the original data of the locking script are moved to the witness area of ​​the child transaction ChildTX created when the UTXO is spent. It is called the witness area locking script WitnessScript. Therefore, the witness area of ​​the current transaction also stores the WitnessScript data of the parent transaction UTXO of this transaction.

[0131] In this embodiment, the transaction parallel processing unit processes each transaction output in turn, and sends the UTXO data of the transaction output to the corresponding contract parallel processing unit for distributed storage. First, the transaction parallel processing unit parses the transaction output and obtains the LockingScriptHash of the transaction output UTXO, which is used to create a "locking script hash value-contract processing unit" mapping table. In the process of building the mapping table, the integer format value of the tail 4-bit data is selected as the contract parallel processing unit serial number corresponding to the corresponding locking script, which does not affect the implementation efficiency;

[0132] Then, the transaction parallel processing unit obtains the contract parallel processing unit and its process number corresponding to the newly generated UTXO according to the "locking script hash value-contract processing unit" mapping table, and sends the output pointer of the corresponding output, that is, the TXID number of this transaction and the sequence number VOUT of this output, as well as the TokenValue of the output, to the corresponding contract query component for processing and storage. Since there is no original locking script in the transaction output of this embodiment, the "original locking script" of the new UTXO is no longer transmitted at this time;

[0133] When the contract parallel processing unit receives a new UTXO, it saves the UTXO in a local data table, which is specifically expressed as adding a spendable "UTXO data strip". The data table is referenced and queried through the locking script hash value of the UTXO, as shown in Table 4: P2WSH contract data table and Table 5: P2TR contract data table. Every time a new UTXO is received, a row of records is added and the UTXO information column is filled. When the transaction where the UTXO is located has been effectively packaged into a block and has a block hash value, the block hash value is filled in the <block> column, otherwise it is left blank;

[0134] Table 4: P2WSH contract data table

[0135] ;

[0136] Table 5: P2TR contract data table

[0137] ;

[0138] In this embodiment, the transaction parallel processing unit processes each transaction input and the witness area data corresponding to each transaction input in turn, first obtaining the "output pointer" of the UTXO that the current transaction input is verifying to spend, that is, TXID+VOUT, so as to obtain the LockingScriptHash of the UTXO;

[0139] For P2WSH type transactions, LockingScriptHash is represented as:

[0140] Input UTXO: LockingScriptHash=Hash(WitnessScript).

[0141] LockingScriptHash limits the unlocking script to the WitnessScript data in the witness area. LockingScriptHash is combined with WitnessData and recorded as WitnessTotal, which together constitute the locking script and unlocking script required for contract verification;

[0142] Therefore, "unlock dependency data" can be constructed as {Version, WitnessLabel, LockTime, InputsCount, OutputsCount, CurrentInputIndex=1, Input1: WitnessTotal, Input1: TXID, Input1: Vout, Input1: Sequence, Input2: TXID, Input2: Vout, Input2: Sequence, Input3..., Output1: TokenValue, Output1: LockingScriptHash, Output2: TokenValue, Output2: LockingScriptHash, Output3...};

[0143] Wherein CurrentInputIndex represents the number of the transaction input currently being processed, and CurrentInputIndex can be set according to the actual situation. In this embodiment, CurrentInputIndex is set to 1;

[0144] Finally, according to the "lock script hash value-contract processing unit" mapping table, the "unlock dependency data" is sent to the corresponding contract parallel processing unit. After receiving the "unlock dependency data", the contract parallel processing unit executes the verification contract, sends the execution result back to the corresponding transaction parallel processing unit, and fills in the spending information column after the execution is passed.

[0145] For P2TR type transactions, LockingScriptHash is represented as:

[0146] Input UTXO: LockingScriptHash = TaggedHashTree (WitnessScriptLeaf1, WitnessScriptLeaf2, ...), any WitnessScriptLeaf can be called a valid script branch through path proof, without revealing all valid scripts, so the same LockingScriptHash can have multiple valid WitnessScripts, and it is impossible to determine a fixed unlocking script.

[0147] When implementing distributed storage and verification for contracts in P2TR transactions, under the premise of retaining the use of LockingScriptHash as the hash table keyword for distributed contract storage, verification, and query, as shown in Table 5: P2TR Contract Data Table, the shared LockingScript or WitnessScript field is removed from the P2TR Contract Data Table, and each time the "unlock dependency data" is sent, the complete contract verification data including WitnessData and WitnessScript is used;

[0148] In contrast, in other types of transactions, LockingScript / WitnessScript can be shared and used after the first transmission and distributed storage, thus reducing repeated data transmission.

[0149] The rest of the specific implementation is the same as that of Example 1.

[0150] As mentioned above, the two-way retrieval service module not only provides services for querying contracts through transactions, but also provides services for querying all transactions through contracts. It relies on the status of all UTXO data tables stored on the same device during the distributed unlocking and verification of contracts, and realizes the unification of distributed verification and distributed query, so that querying all data of a UTXO contract is the same as querying the global data of a contract under the account model, and it can be completed by accessing only one storage location.

[0151] Therefore, the present invention adopts the above-mentioned high-performance blockchain system that supports distributed parallel processing and bidirectional retrieval. In the field of UTXO model blockchain, it is suitable for the refined parallel processing of current mainstream types of transaction data. The contract data in the transaction can be separated separately, and distributed storage and verification are performed, and localized fast query services from contracts to all transaction lists are provided. In terms of blockchain node software and underlying facilities, bidirectional retrieval or query capabilities from transactions to contracts and from contracts to transactions are realized.

[0152] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that they can still modify or replace the technical solution of the present invention with equivalents, and these modifications or equivalent replacements cannot cause the modified technical solution to deviate from the spirit and scope of the technical solution of the present invention.< / otherscript>

Claims

1. A high-performance blockchain system that supports distributed parallel processing and bidirectional retrieval, characterized by: It includes an initialization and resource scheduling module, a network data transceiver module, a retrieval service module and a parallel processing module. The parallel processing module includes a block data parallel processing module, a transaction data parallel processing module and a contract data parallel processing module. The retrieval service module includes a transaction query component and a contract query component. The data processing process of the network data transceiver module specifically includes the following steps: S1: Receive block data and transaction data from blockchain network nodes and user terminals, determine the corresponding processing unit based on the parallel task-processing unit mapping table constructed in the initialization and resource scheduling module, and if the received data is block data, send the data to the corresponding processing unit of the block parallel processing module; if the received data is transaction data, send the data to the corresponding parallel processing unit of the transaction parallel processing module; In step S1, the initialization and resource scheduling module is responsible for processing the startup and initialization of the parallel task-processing unit. The parallel task-processing unit is set to single thread or multi-thread. The initialization and resource scheduling module manages the allocation and scheduling of computing tasks. By reading the configuration file or using the empirical algorithm, the number of processing units that need to be started by the block parallel processing module and the transaction parallel processing module, the mapping relationship and topological structure of the parallel processing unit and the single computing device in the computer cluster are determined, and the parallel task-processing unit mapping table at three levels of block data verification, transaction data verification and contract data verification is constructed and managed; In step S1, the process of the transaction data parallel processing module processing the node data specifically includes: Step 1: Receive and parse the transaction data from the network data transceiver module, calculate and construct a simplified set of transaction data, which includes the hash value data of the "unlocking script" and "locking script" contract data or the derivative data based on the hash value data of the "unlocking script" and "locking script" contract data, but does not include the complete "unlocking script" and "locking script" contract data; Step 2: Process the transaction input data in sequence, locate the TXO of the parent transaction through the "output pointer", obtain the "locking script" contract data corresponding to the TXO, determine the position or number of the parallel processing unit of the "locking script" contract data based on the "parallel task-processing unit" mapping table of the contract data verification layer constructed in the initialization and resource scheduling module, and send the "unlocking dependency data" of the current transaction input to the parallel processing unit of the corresponding contract for verification. The "unlocking dependency data" includes the "unlocking script" contract data of the current transaction input and the simplified set of transaction data of the current transaction; Step 3: Process the transaction output data in sequence, parse and obtain the TXO data including the "locking script" contract data, obtain the hash value of the "locking script" contract data according to the hash function, obtain the position or number of the corresponding parallel processing unit based on the "parallel task-processing unit" mapping table of the contract data verification layer constructed in the initialization and resource scheduling module, define the data set containing the TXO data and the TXO pointer as "locking data" according to the position or number of the parallel processing unit, and send the "locking data" to the corresponding parallel processing unit of the contract data parallel processing module; Step 4: Check the transaction legitimacy requirements except for the unlocking verification of a single transaction input, calculate the minimum transaction fee stipulated by the current blockchain network consensus based on the transaction data and transaction fee rate, and the actual transaction fee paid is higher than the minimum transaction fee; Step 5: Receive the verification result sent back by the contract parallel processing unit for the transaction input data processed in step 2. If the verification result contains "failed", mark the entire transaction as an illegal transaction; Step 6: Integrate the verification results of steps 1 to 5 to obtain the overall legitimacy verification result of the transaction data, and send the overall legitimacy verification result of the transaction data back to the block data parallel processing module; S2: Receive the block data from the block parallel processing module and the transaction data from the transaction parallel processing module, and send the block data and transaction data to the corresponding blockchain network nodes and user terminals.

2. A high-performance blockchain system supporting distributed parallel processing and bidirectional retrieval according to claim 1, characterized in that: In step S1, the block data parallel processing module processes the node data in the following specific steps: S11: parse the block data received from the network data transceiver module, parse and check the legitimacy of the block header data, parse the transaction data contained therein, and send the transaction data to the transaction parallel processing module; S12: receiving the processing and verification results sent back by the transaction parallel processing module, summarizing the processing and verification results, and marking the corresponding block as legal if both the block header data and the transactions within the block are legal; marking the corresponding block as illegal if the block header data or the transactions within the block are illegal; S13: If the node where the block data is located undertakes the block propagation task, the corresponding block marked as legal is sent to the network data transceiver module.

3. A high-performance blockchain system supporting distributed parallel processing and bidirectional retrieval according to claim 2, characterized in that: For low-load scenarios with small amounts of block data, the block data parallel processing module sets the number of parallel tasks to 1, starts, and uses a single processing unit.

4. A high-performance blockchain system supporting distributed parallel processing and bidirectional retrieval according to claim 3, characterized in that: In step 3, the contract data parallel processing module processes the unlocking dependent data and locking data in the following specific steps: Step 3-1: Receive the "lock data" and "unlock dependency data" from the transaction data parallel processing module, and parse the "lock data" and "unlock dependency data"; Step 3-2: When the received data is "locked data", determine the data table location of the corresponding contract according to the hash value of the TXO lock script in the "locked data", save the TXO pointer in the "locked data" in the data table, and mark the TXO pointer in the "locked data" as an unspent transaction output UTXO; Step 3-3: When the received data is "unlock dependent data", obtain the data table location of the corresponding UTXO to be unlocked, check whether the corresponding TXO pointer is UTXO, if the corresponding TXO pointer is UTXO, the corresponding TXO has not been spent; if the corresponding TXO pointer is not UTXO, the corresponding TXO has been spent; Step 3-4: If the corresponding TXO has been spent, the verification fails and the verification error result is returned to the transaction parallel processing unit; Step 3-5: If the corresponding TXO has not been spent, concatenate the "unlock script" in the "unlock dependent data" and the "lock script" of the corresponding contract in sequence to obtain a new script, and execute the new script in the contract computing virtual machine, and send the verification result after execution back to the transaction parallel processing unit; Step 3-6: If the verification is successful, mark the TXO pointer as spent TXO at the data table location corresponding to UTXO, and add the transaction number TXID of the transaction that unlocks and spends the UTXO.

5. A high-performance blockchain system supporting distributed parallel processing and bidirectional retrieval according to claim 4, characterized in that: In steps 3-1 to 3-6, if the received "unlock dependency data" belongs to a transaction in a packaged block, the block height and block hash value of the corresponding block are added to the location of the data table where the corresponding UTXO is located to increase the amount of information in the contract query.

6. A high-performance blockchain system supporting distributed parallel processing and bidirectional retrieval according to claim 5, characterized in that: The retrieval service module includes a distributed block query component, a transaction query component, a contract query component and a query forwarding component. The query forwarding component provides distributed two-way retrieval and query services and a unified external query interface service. Based on the "parallel task-processing unit" mapping table of the transaction data verification layer and the "parallel task-processing unit" mapping table of the contract data verification layer constructed in the initialization and resource scheduling module, it obtains the storage location of the transaction data and the contract data in the device, receives a query request, and forwards the query request to the transaction query component or contract query component where the data to be queried is located.

7. A high-performance blockchain system supporting distributed parallel processing and bidirectional retrieval according to claim 6, characterized in that: If the "locking script" of the contract to be queried is the same, the collection and calculation of the query are completed locally.

8. A high-performance blockchain system supporting distributed parallel processing and bidirectional retrieval according to claim 1, characterized in that: When all the above modules communicate data, Infiniband or RoCE lossless network, RDMA technology on lossless network or message passing interface technology are used, and non-blocking sending and receiving functions are used to increase the parallel processing performance between modules.

Images