Blockchain parallel contract security checking method, system and device

Abstract

The application discloses a kind of blockchain parallel contract security check method, system and device, wherein the method comprises: contract source code is parsed into token stream, and target parallel contract is identified according to token stream;According to token stream, it is judged whether there is registered first contract function in target parallel contract, when there is not, first exception prompt is carried out;When there is, it is judged whether first contract function is consistent with cancelled second contract function;When it is not consistent, second exception prompt is carried out;When consistent, it is judged whether it can be parallel according to the read-write state of storage variable of first contract function, if there is write operation to storage variable of first contract function and the type of storage variable does not support concurrent access, third exception prompt is carried out;Otherwise, the current number of mutual exclusion variables of first contract function is calculated;When current number of mutual exclusion variables is consistent with the number of marked mutual exclusion variables, security check is carried out;Otherwise, fourth exception prompt is carried out, improve the reliability of parallel contract execution.

Description

Blockchain Parallel Contract Security Inspection Method, System and Device Technical Field

[0001] This invention relates to the field of blockchain, and in particular to a method, system and apparatus for security inspection of blockchain parallel contracts. Background Technology

[0002] A blockchain is essentially a chain of blocks. Each block stores specific information, and these blocks are linked together in chronological order of their creation. This chain is stored on servers called nodes, which provide storage and computing power for the entire blockchain system. Modifying information in the blockchain requires the consent of more than half of the nodes and modification of the information across all nodes. Since these nodes are typically controlled by different entities, tampering with information in the blockchain is extremely difficult. Compared to traditional networks, blockchain has two core characteristics: data immutability and decentralization. Based on these characteristics, the information recorded in the blockchain is more authentic and reliable, helping to solve the problem of mutual distrust.

[0003] During transaction execution, the execution module retrieves transactions one by one from the block and executes them sequentially. During execution, the latest world state is modified; after each transaction is executed, the state is accumulated to reach the latest world state after the block is completed. The next block's execution strictly depends on the world state after the previous block's execution. Therefore, the traditional linear transaction execution process cannot be well optimized for parallel execution. To improve transaction execution efficiency and fully utilize server computing resources, several parallel transaction solutions have emerged in the industry.

[0004] Existing technology provides a parallel transaction executor scheme based on the DAG (Directed Acyclic Graph) model. In a batch of transactions, the mutually exclusive resources occupied by each transaction can be identified through a certain method. Then, based on the order of transactions in the block and the occupancy relationship of mutually exclusive resources, a DAG graph of transaction dependencies is constructed. Based on the DAG graph, the dependencies of transactions can be determined, and transactions can be executed in the corresponding order. This scheme provides a parallelizable contract development framework. Developers only need to develop contracts according to the framework's specifications and define the mutual exclusion parameters of each contract interface to implement contracts that can be executed in parallel. However, when developing smart contracts based on this contract framework, contract developers are prone to various errors, and these errors are difficult to detect because there are no exception prompts during contract compilation and deployment. Anomalies are only discovered during high-concurrency contract calls, and the cost of consensus failure and transaction rollback is very high.

[0005] There is currently no effective solution to the problem of unreliable execution of parallel contracts in existing technologies. Summary of the Invention

[0006] To address the aforementioned issues, this invention provides a blockchain parallel contract security inspection method, system, and apparatus. The method performs compilation security checks on parallel contracts within a token stream. The inspection process recursively checks each contract in an inclusive manner to detect code with parallel security flags and outputs detailed error information (file containing the error code, line number of the error code, error code content, and suggested modifications). This prompts contract developers to make corresponding modifications, thereby resolving the unreliable execution of parallel contracts in existing technologies.

[0007] To achieve the above objectives, this invention provides a blockchain parallel contract security check method, comprising: parsing the contract source code into a token stream, identifying a target parallel contract based on the token stream; determining whether a registered first contract function exists in the target parallel contract based on the token stream, and issuing a first exception warning if it does not exist; determining whether the first contract function is consistent with a deregistered second contract function if it does not exist, and issuing a second exception warning if they do not exist; determining whether parallelism is possible based on the read / write status of the storage variables by the first contract function, and issuing a third exception warning if the first contract function performs write operations on the storage variables and the type of the storage variables does not support concurrent access; otherwise, calculating the current number of mutexes in the first contract function; passing the security check if the current number of mutexes is consistent with the number of marked mutexes; otherwise, issuing a fourth exception warning.

[0008] Optionally, the first exception prompt includes: when the first contract function has a type alias, throwing an exception prompt indicating a type error and prompting the replacement of the type alias with the actual type; when the first contract function has an approximate function name, throwing an exception prompt indicating that the function does not exist and asking whether it is an approximate function name; otherwise, directly throwing an exception prompt indicating that the function does not exist.

[0009] Further optionally, the second exception prompt includes: throwing an exception prompt for function inconsistency; and prompting a first contract function for which the registration and deregistration logics are inconsistent.

[0010] Further optionally, the fourth exception prompt includes: when the current number of mutexes is greater than the number of marked mutexes, issuing an exception prompt that the mutexes are not marked, and prompting that the number of marked mutexes should be the current number of mutexes; when the current number of mutexes is less than the number of marked mutexes, prompting that the number of marked mutexes should be the current number of mutexes.

[0011] On the other hand, embodiments of the present invention also provide a blockchain parallel contract security inspection system, comprising: a parallel contract identification module, used to parse contract source code into a token stream and identify a target parallel contract based on the token stream; a contract function detection module, used to determine whether a registered first contract function exists in the target parallel contract based on the token stream, and to issue a first exception prompt when it does not exist; a logic detection module, used to determine whether the first contract function is consistent with a deregistered second contract function when it exists, and to issue a second exception prompt when they are inconsistent; a parallel detection module, used to determine whether parallelism is possible based on the read / write status of the storage variables of the first contract function when they are consistent, and to issue a third exception prompt if the first contract function has write operations on the storage variables and the type of the storage variables does not support concurrent access; otherwise, to calculate the current number of mutexes of the first contract function; and a mutex count comparison module, used to pass the security check when the current number of mutexes is consistent with the number of marked mutexes; otherwise, to issue a fourth exception prompt.

[0012] Further optionally, the contract function detection module includes: a first prompting submodule, used to throw an exception prompt indicating a type error when the first contract function has a type alias, and to prompt that the type alias be replaced with the real type; a second prompting submodule, used to throw an exception prompt indicating that the function does not exist when the first contract function has an approximate function name, and to ask whether it is an approximate function name; and a third prompting submodule, used to throw an exception indicating that the function does not exist in other cases.

[0013] Further optionally, the logic detection module includes: an exception throwing submodule, used to throw an exception prompt for function inconsistency; and a logic prompt submodule, used to prompt the first contract function for which the registration and deregistration logics are inconsistent.

[0014] Further optionally, the mutual exclusion variable quantity comparison module includes: a fourth prompt submodule, used to throw an exception prompt that the mutual exclusion variable is not marked when the current number of mutual exclusion variables is greater than the number of marked mutual exclusion variables, and to make a prompt that the number to be marked is the current number of mutual exclusion variables; and a fifth prompt submodule, used to make a prompt that the number to be marked is the current number of mutual exclusion variables when the current number of mutual exclusion variables is less than the number of marked mutual exclusion variables.

[0015] On the other hand, the present invention also provides a blockchain parallel contract security inspection device, including the above-mentioned blockchain parallel contract security inspection system.

[0016] On the other hand, the present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described blockchain parallel contract security check method.

[0017] The above technical solution has the following beneficial effects: by checking that the contract function exists in the contract, it avoids the failure of functions with incorrect annotations to be executed; by analyzing whether the read and write status of stored variables can be parallelized, it avoids the impact of incorrect annotations on the consistency of transaction execution results of each node, thereby avoiding transaction rollback caused by consensus failure; by checking the number of mutually exclusive variables, it avoids the incorrect parallel execution of contract functions; and it improves the reliability of parallel contracts, enabling the DAG model to be executed smoothly. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 is a schematic diagram of the DAG model structure provided in the prior art;

[0020] Figure 2 is a flowchart of the blockchain parallel contract security check method provided in an embodiment of the present invention;

[0021] Figure 3 is a flowchart of the method for providing a first abnormality notification according to an embodiment of the present invention;

[0022] Figure 4 is a flowchart of the method for providing a second abnormality notification according to an embodiment of the present invention;

[0023] Figure 5 is a flowchart of the fourth abnormality prompting method provided in an embodiment of the present invention;

[0024] Figure 6 is a schematic diagram of the blockchain parallel contract security inspection system provided in an embodiment of the present invention;

[0025] Figure 7 is a schematic diagram of the contract function detection module provided in an embodiment of the present invention;

[0026] Figure 8 is a schematic diagram of the logic detection module provided in an embodiment of the present invention;

[0027] Figure 9 is a schematic diagram of the structure of the mutual exclusion variable quantity comparison module provided in an embodiment of the present invention.

[0028] Figure reference numerals: 100 - Parallel contract identification module; 200 - Contract function detection module; 2001 - First prompt submodule; 2002 - Second prompt submodule; 2003 - Third prompt submodule; 300 - Logic detection module; 3001 - Exception throwing submodule; 3002 - Logic prompt submodule; 400 - Parallel detection module; 500 - Mutual exclusion variable quantity comparison module; 5001 - Fourth prompt submodule; 5002 - Fifth prompt submodule. Detailed Implementation

[0029] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0030] Figure 1 is a schematic diagram of the DAG model structure provided in the prior art. As shown in Figure 1, all transactions with an in-degree of 0 (no dependent preceding tasks) can be executed in parallel. After topological sorting based on the order of the original transaction list in the left figure, the transaction DAG in the right figure can be obtained. Based on the DAG model, a parallel transaction execution scheme can be determined. However, the above method is prone to mislabeling, which can affect consensus. The applicant of this invention has found through research that contract developers are prone to the following errors:

[0031] 1. A non-parallelizable contract function was incorrectly labeled as a parallelizable function, causing inconsistent transaction execution results across nodes, leading to consensus failure and transaction rollback;

[0032] 2. A spelling error in the labeled function prevented functions that require parallel execution from running in parallel.

[0033] 3. An incorrect mutex parameter label caused the contract functions to be executed in parallel incorrectly.

[0034] To address the issue of potential anomalies during parallel contract execution in existing technologies, this invention provides a blockchain parallel contract security check method. Figure 2 is a flowchart of the blockchain parallel contract security check method provided by this invention. As shown in Figure 2, the method includes:

[0035] S1. Parse the contract source code into a token stream, and identify the target parallel contract based on the token stream;

[0036] Before starting the parallel contract security check, the contract source code needs to be parsed into a token stream. The entire security check process is based on the token stream for code security analysis.

[0037] Most contracts developed by contract developers are ordinary, serial contracts, with only a small number being parallelizable contracts. Therefore, when starting security checks, it is necessary to identify the type of parallel contracts, while ordinary serial contracts can skip the subsequent security check process.

[0038] As an optional implementation, the parallel contract type can be determined by checking whether it inherits from the ParallelContract framework and implements its two methods, enableParallel and disableParallel. If it is determined to be a parallel contract, the next security check begins; otherwise, the contract is considered a serial contract, the security check passes, and the process ends.

[0039] In this embodiment, a security check method for a target parallel contract is used for illustration. The other parallel contracts in the source code also use the same security check method as the target parallel contract.

[0040] S2. Determine whether there is a registered first contract function in the target parallel contract based on the token flow. If not, issue the first exception prompt.

[0041] The first contract function is registered in the enableParallel method using registerParallelFunction. The token flow is analyzed to determine whether the first contract function exists in the target parallel contract. If it exists, the current check passes and the next security check is performed. If it does not exist, different exception messages are required for different exceptions, i.e., the first exception message.

[0042] S3. If it exists, determine whether the first contract function is consistent with the cancelled second contract function; if they are inconsistent, issue a second exception prompt.

[0043] The first contract function is registered using `registerParallelFunction` in the `enableParallel` method, and the second contract function is unregistered using `unregisterParallelFunction` in the `disableParallel` method. If the first contract function exists in the target parallel contract, it is necessary to further determine whether the first contract function is completely identical to the second contract function based on the token flow.

[0044] If they are completely consistent, this round of checks passes and the next security check is performed; otherwise, a second anomaly alert is required to warn of logical inconsistencies.

[0045] For example, if the marked contract function set(uint256, bytes) exists and is consistent, then this round of checks passes and proceeds to the next security check.

[0046] S4. When consistent, determine whether parallelism is possible based on the read and write status of the storage variable in the first contract function. If the first contract function has a write operation on the storage variable and the type of the storage variable does not support concurrent access, then issue a third exception prompt; otherwise, calculate the current number of mutexes in the first contract function.

[0047] When the first contract function is identical to the second contract function, it is necessary to further determine whether the first contract function marked as parallel can be parallelized. This is achieved by analyzing the token flow to determine whether the first contract function can be processed in parallel, mainly by analyzing the first contract function's read and write operations on storage variables.

[0048] If a write operation is performed on the stored variable and the type of the stored variable does not support concurrent access, an exception for accessing a mutex stored variable will be thrown, i.e., the third exception message; otherwise, this round of checks will pass and proceed to the next security check.

[0049] For example, if the contract function saveProof supports parallel reading and writing of the storage variable type mapping, then this round of checks passes and proceeds to the next security check.

[0050] Further security checks require analyzing the token flow to determine whether the variables in the first contract function registered via registerParallelFunction within the enableParallel method are mutually exclusive variables. This mainly involves analyzing the impact of contract function parameters on the reading and writing of stored variables and calculating the number of mutually exclusive variables.

[0051] S5. If the current number of mutexes matches the number of marked mutexes, pass the security check; otherwise, issue the fourth exception warning.

[0052] If the calculated number of current mutexes equals the number of mutexes registered with registerParallelFunction, the security check passes and ends; otherwise, a fourth exception warning is issued.

[0053] For example: key is a mutex variable, while data is not a mutex variable. Therefore, the number of mutex variables marked is consistent, so the check passes and ends.

[0054] As an optional implementation, Figure 3 is a flowchart of a method for providing a first error message according to an embodiment of the present invention. As shown in Figure 3, providing a first error message includes:

[0055] S201. When the first contract function has a type alias, throw a type error exception and prompt the user to replace the type alias with the actual type.

[0056] Check if the first registered contract function has a type alias, such as uint, int, ufixed, fixed, byte, etc. If an alias exists, throw a type error exception and suggest replacing the alias with the actual type.

[0057] S202. When the first contract function has an approximate function name, throw an exception message indicating that the function does not exist, and ask whether it is an approximate function name;

[0058] Check if there is a similar function name among the registered functions, ignoring case and underscores. If a similar function name is found, throw an exception indicating that the function does not exist, and prompt whether it should be a similar function (the function matched after ignoring case and underscores).

[0059] S203. Otherwise, throw an exception indicating that the function does not exist.

[0060] If neither of the above two conditions applies, a function non-existent exception will be thrown.

[0061] As an optional implementation, Figure 4 is a flowchart of a method for providing a second error message according to an embodiment of the present invention. As shown in Figure 4, providing a second error message includes:

[0062] S301, Throws an exception message indicating function inconsistency;

[0063] S302, Provide a warning for the first contract function where the registration and deregistration logics are inconsistent.

[0064] If the token flow indicates that the first contract function registered via registerParallelFunction in the enableParallel method is inconsistent with the second contract function unregistered via unregisterParallelFunction in the disableParallel method, an exception message indicating that the registration and unregistration logics are inconsistent, an exception message will be thrown.

[0065] As an optional implementation, Figure 5 is a flowchart of a method for providing a fourth exception notification according to an embodiment of the present invention. As shown in Figure 5, providing a fourth exception notification includes:

[0066] S501. When the current number of mutexes is greater than the number of marked mutexes, throw an exception message indicating that the mutexes are not marked, and indicate that the number of marked mutexes should be the current number of mutexes.

[0067] If the calculated number of current mutexes is greater than the number of mutexes registered with registerParallelFunction, an exception is thrown indicating that the mutexes are unmarked, and the number that should be marked is "the current number of mutexes".

[0068] S502. When the current number of mutexes is less than the number of marked mutexes, a prompt should be made indicating that the number to be marked should be the current number of mutexes.

[0069] If the calculated number of current mutexes is less than the number of mutexes registered with registerParallelFunction, the warning message suggests that the number to be marked be "current number of mutexes".

[0070] As an optional implementation, this embodiment of the invention also provides a blockchain parallel contract security inspection system. Figure 6 is a schematic diagram of the structure of the blockchain parallel contract security inspection system provided in this embodiment of the invention. As shown in Figure 6, the system includes:

[0071] Parallel contract identification module 100 is used to parse the contract source code into a token stream and identify the target parallel contract based on the token stream.

[0072] Before starting the parallel contract security check, the contract source code needs to be parsed into a token stream. The entire security check process is based on the token stream for code security analysis.

[0073] Most contracts developed by contract developers are ordinary, serial contracts, with only a small number being parallelizable contracts. Therefore, when starting security checks, it is necessary to identify the type of parallel contracts, while ordinary serial contracts can skip the subsequent security check process.

[0074] As an optional implementation, the parallel contract type can be determined by checking whether it inherits from the ParallelContract framework and implements its two methods, enableParallel and disableParallel. If it is determined to be a parallel contract, the next security check begins; otherwise, the contract is considered a serial contract, the check passes, and the process ends.

[0075] In this embodiment, a security check method for a target parallel contract is used for illustration. The other parallel contracts in the source code also use the same security check method as the target parallel contract.

[0076] The contract function detection module 200 is used to determine whether there is a registered first contract function in the target parallel contract based on the token flow. If it does not exist, the first exception prompt is given.

[0077] The first contract function is registered in the enableParallel method using registerParallelFunction. The token flow is analyzed to determine whether the first contract function exists in the target parallel contract. If it exists, the current check passes and the next security check is performed. If it does not exist, different exception messages are required for different exceptions, i.e., the first exception message.

[0078] The logic detection module 300 is used to determine whether the first contract function is consistent with the cancelled second contract function when they exist; if they are inconsistent, a second exception prompt is given.

[0079] The first contract function is registered using `registerParallelFunction` in the `enableParallel` method, and the second contract function is unregistered using `unregisterParallelFunction` in the `disableParallel` method. If the first contract function exists in the target parallel contract, it is necessary to further determine whether the first contract function is completely identical to the second contract function based on the token flow. If they are completely identical, this round of checks passes and proceeds to the next security check; otherwise, a second exception message is required to alert for logical inconsistency.

[0080] For example, if the marked contract function set(uint256, bytes) exists and is consistent, then this round of checks passes and proceeds to the next security check.

[0081] The parallel detection module 400 is used to determine whether parallelism is possible based on the read and write status of the storage variable by the first contract function when the data is consistent. If the first contract function has a write operation on the storage variable and the type of the storage variable does not support concurrent access, a third exception prompt is given; otherwise, the number of mutexes in the first contract function is calculated.

[0082] When the first contract function is identical to the second contract function, it is necessary to further determine whether the first contract function marked as parallel can be parallelized. This is achieved by analyzing the token flow to determine whether the first contract function can be processed in parallel, mainly by analyzing the first contract function's read and write operations on storage variables.

[0083] If a write operation is performed on the stored variable and the type of the stored variable does not support concurrent access, an exception for accessing a mutex stored variable will be thrown, i.e., the third exception message; otherwise, this round of checks will pass and proceed to the next security check.

[0084] For example, if the contract function saveProof supports parallel reading and writing of the storage variable type mapping, then this round of checks passes and proceeds to the next security check.

[0085] Further security checks require analyzing the token flow to determine whether the variables in the first contract function registered via registerParallelFunction within the enableParallel method are mutually exclusive variables. This mainly involves analyzing the impact of contract function parameters on the reading and writing of stored variables and calculating the number of mutually exclusive variables.

[0086] The mutual exclusion variable count comparison module 500 is used to pass the security check when the current number of mutual exclusion variables is consistent with the number of marked mutual exclusion variables; otherwise, it will issue a fourth exception prompt.

[0087] If the calculated number of current mutexes equals the number of mutexes registered with registerParallelFunction, the security check passes and ends; otherwise, a fourth exception warning is issued.

[0088] For example, if key is a mutex variable while data is not, and the number of mutex variables marked is consistent, then the security check passes and ends.

[0089] As an optional implementation, Figure 7 is a schematic diagram of the structure of the contract function detection module provided in an embodiment of the present invention. As shown in Figure 7, the contract function detection module 200 includes:

[0090] The first prompt submodule 2001 is used to throw a type error exception when the first contract function has a type alias, and to prompt that the type alias be replaced with the real type;

[0091] Check if the first registered contract function has a type alias, such as uint, int, ufixed, fixed, byte, etc. If an alias exists, throw a type error exception and suggest replacing the alias with the actual type.

[0092] The second prompt submodule 2002 is used to throw an exception prompt that the function does not exist when the first contract function has an approximate function name, and to ask whether it is an approximate function name;

[0093] Check if there is a similar function name among the registered functions, ignoring case and underscores. If a similar function name is found, throw an exception indicating that the function does not exist, and prompt whether it should be a similar function (the function matched after ignoring case and underscores).

[0094] The third prompt submodule 2003 is used to throw an exception message indicating that the function does not exist when other conditions are met.

[0095] If neither of the above two conditions applies, a function non-existent exception will be thrown.

[0096] As an optional implementation, Figure 8 is a schematic diagram of the structure of the logic detection module provided in an embodiment of the present invention. As shown in Figure 8, the logic detection module 300 includes:

[0097] The exception-throwing submodule 3001 is used to throw an exception message indicating function inconsistency.

[0098] The logic prompt submodule 3002 is used to provide prompts for the first contract function where the registration and deregistration logics are inconsistent.

[0099] According to token flow analysis, when the first contract function registered via registerParallelFunction in the enableParallel method is inconsistent with the second contract function unregistered via unregisterParallelFunction in the disableParallel method, an exception message indicating function inconsistency is thrown, indicating that the registration and unregistration logics are inconsistent.

[0100] As an optional implementation, Figure 9 is a structural schematic diagram of the mutual exclusion variable quantity comparison module provided in an embodiment of the present invention. As shown in Figure 9, the mutual exclusion variable quantity comparison module 500 includes:

[0101] The fourth prompt submodule 5001 is used to throw an exception prompt that the mutexes are not marked when the current number of mutexes is greater than the number of marked mutexes, and to prompt that the number of mutexes that should be marked is the current number of mutexes.

[0102] If the calculated number of current mutexes is greater than the number of mutexes registered with registerParallelFunction, an exception is thrown indicating that the mutexes are unmarked, and the number that should be marked is "the current number of mutexes".

[0103] The fifth prompt submodule 5002 is used to prompt that the number of mutexes should be the current number of mutexes when the current number of mutexes is less than the number of marked mutexes.

[0104] If the calculated number of current mutexes is less than the number of mutexes registered with registerParallelFunction, the warning message suggests that the number to be marked be "current number of mutexes".

[0105] This invention also provides a blockchain parallel contract security inspection device, including the aforementioned blockchain parallel contract security inspection system.

[0106] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned blockchain parallel contract security check method.

[0107] The aforementioned storage medium stores the aforementioned software, and the storage medium includes, but is not limited to, optical discs, floppy disks, hard disks, and rewritable memory.

[0108] The above technical solution has the following beneficial effects: by checking that the contract function exists in the contract, it avoids the failure of functions with incorrect annotations to be executed; by analyzing whether the read and write status of stored variables can be parallelized, it avoids the impact of incorrect annotations on the consistency of transaction execution results of each node, thereby avoiding transaction rollback caused by consensus failure; by checking the number of mutually exclusive variables, it avoids the incorrect parallel execution of contract functions; and it improves the reliability of parallel contracts, enabling the DAG model to be executed smoothly.

[0109] The above-described specific embodiments of the invention further illustrate the purpose, technical solution, and beneficial effects of the invention. It should be understood that the above content is only for specific embodiments of the invention and is not intended to limit the scope of protection of the invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the scope of protection of the invention.

Claims

1. A method for security checking of parallel blockchain contracts, characterized in that, include: The contract source code is parsed into a token stream, and the target parallel contract is identified based on the token stream. Based on the token stream, determine whether there is a registered first contract function in the target parallel contract. If not, issue a first exception message; if so, determine whether the first contract function is consistent with the deregistered second contract function. When there is a discrepancy, a second exception message is displayed; when there is a consistency, it is determined whether parallelism is possible based on the read and write status of the storage variable by the first contract function. If the first contract function performs a write operation on the storage variable and the type of the storage variable does not support concurrent access, a third exception message is displayed. Otherwise, calculate the current number of mutexes in the first contract function; if the current number of mutexes matches the number of marked mutexes, pass the security check; otherwise, issue a fourth exception warning.

2. The blockchain parallel contract security check method according to claim 1, characterized in that, The first exception prompt includes: when the first contract function has a type alias, throwing an exception prompt indicating a type error and prompting to replace the type alias with the actual type; when the first contract function has an approximate function name, throwing an exception prompt indicating that the function does not exist and asking whether it is an approximate function name; otherwise, throwing an exception prompt indicating that the function does not exist.

3. The blockchain parallel contract security check method according to claim 1, characterized in that, The second exception prompt includes: throwing an exception prompt for function inconsistency; and prompting a first contract function for which the registration and deregistration logics are inconsistent.

4. The blockchain parallel contract security check method according to claim 1, characterized in that, The fourth exception prompt includes: when the current number of mutexes is greater than the number of marked mutexes, an exception prompt indicating that the mutexes are not marked is thrown, and a prompt indicating that the number of marked mutexes should be the current number of mutexes; when the current number of mutexes is less than the number of marked mutexes, a prompt indicating that the number of marked mutexes should be the current number of mutexes.

5. A blockchain parallel contract security inspection system, characterized in that, include: The parallel contract identification module is used to parse the contract source code into a token stream and identify the target parallel contract based on the token stream. The contract function detection module is used to determine whether there is a registered first contract function in the target parallel contract based on the token stream. If there is no registered first contract function, a first exception prompt is given. The logic detection module is used to determine, when present, whether the first contract function is consistent with the cancelled second contract function; When inconsistency occurs, a second exception message will be displayed; The parallel detection module is used to determine whether parallelism is possible based on the read and write status of the storage variable by the first contract function when the data is consistent. If the first contract function has a write operation on the storage variable and the type of the storage variable does not support concurrent access, a third exception prompt will be given. Otherwise, calculate the current number of mutexes in the first contract function; The mutual exclusion variable count comparison module is used to pass a security check when the current number of mutual exclusion variables matches the number of marked mutual exclusion variables; otherwise, it will issue a fourth exception warning.

6. The blockchain parallel contract security inspection system according to claim 5, characterized in that, The contract function detection module includes: a first prompting submodule, used to throw an error prompt indicating a type error when the first contract function has a type alias, and to prompt that the type alias be replaced with the real type; a second prompting submodule, used to throw an error prompt indicating that the function does not exist when the first contract function has an approximate function name, and to ask whether it is an approximate function name; and a third prompting submodule, used to throw an error prompt indicating that the function does not exist in other cases.

7. The blockchain parallel contract security inspection system according to claim 5, characterized in that, The logic detection module includes: an exception throwing submodule, used to throw an exception prompt for function inconsistency; and a logic prompt submodule, used to prompt the first contract function for which the registration and deregistration logics are inconsistent.

8. The blockchain parallel contract security inspection system according to claim 5, characterized in that, The mutual exclusion variable quantity comparison module includes: a fourth prompt submodule, used to throw an exception prompt that the mutual exclusion variable is not marked when the current number of mutual exclusion variables is greater than the number of marked mutual exclusion variables, and to make a prompt that the number to be marked is the current number of mutual exclusion variables; and a fifth prompt submodule, used to make a prompt that the number to be marked is the current number of mutual exclusion variables when the current number of mutual exclusion variables is less than the number of marked mutual exclusion variables.

9. A blockchain parallel contract security inspection device, characterized in that, Including the blockchain parallel contract security inspection system as described in any one of claims 5-8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the blockchain parallel contract security check method as described in any one of claims 1-4.

Images