A risk detection method, apparatus and equipment for a blockchain system

Abstract

This specification discloses a risk detection method, apparatus, and device for a blockchain system. The method includes: acquiring transaction information of a transaction invoked through a smart contract and the opcode sequence executed by the transaction; based on the transaction information, running the opcode sequence through a blockchain client and calculating a first code coverage rate of the opcode sequence run by the blockchain client; performing mutation processing on the opcode sequence to obtain a mutated opcode sequence that meets preset target mutation conditions, wherein the change in the number of stack elements corresponding to the mutated opcode sequence meets a preset first sub-condition, and the code coverage rate of the mutated opcode sequence run by the blockchain client meets a preset second sub-condition with respect to the first code coverage rate; and sequentially executing the opcode sequence and the mutated opcode sequence in a local blockchain network composed of multiple blockchain nodes to obtain corresponding execution results, thereby determining the risks existing in the blockchain system.

Description

Technical Field

[0001] This document relates to the field of computer technology, and in particular to a risk detection method, apparatus and equipment for a blockchain system. Background Technology

[0002] Blockchain systems operate within a consensus network composed of distributed blockchain nodes. Each blockchain node needs to run a blockchain client to execute the full functionality of the blockchain system. Blockchain clients provide various RPC methods, allowing users to perform functions such as reading the current blockchain state, simulating transaction execution, and parsing existing blockchain transactions. Although blockchain clients are designed to strictly adhere to predetermined blockchain system design specifications, various code defects may exist during actual development, causing the blockchain client to malfunction. RPC handling code defects are a major type of blockchain client code defect, which may lead to users obtaining incorrect blockchain state information after making RPC requests. This can even be exploited by malicious attackers to launch denial-of-service attacks against the blockchain client, thus posing corresponding risks. Therefore, a better technical solution is needed to detect risks such as blockchain client code defects. Summary of the Invention

[0003] The purpose of the embodiments in this specification is to provide a better technical solution for detecting risks such as defects in blockchain client code.

[0004] To achieve the above technical solution, the embodiments in this specification are implemented as follows: This specification provides a risk detection method for a blockchain system. The method includes: acquiring transaction information of a transaction invoked through a smart contract and an opcode sequence executed by the transaction; based on the transaction information, running the opcode sequence through a blockchain client in the blockchain system and calculating a first code coverage rate of the opcode sequence run by the blockchain client; performing mutation processing on the opcode sequence to obtain a mutated opcode sequence that meets preset target mutation conditions, wherein the change in the number of stack elements corresponding to the mutated opcode sequence meets a preset first sub-condition, and the code coverage rate of the mutated opcode sequence run by the blockchain client meets a preset second sub-condition with respect to the first code coverage rate; sequentially executing the opcode sequence and the mutated opcode sequence in a local blockchain network composed of multiple blockchain nodes, obtaining corresponding execution results, and determining the risks existing in the blockchain system based on the obtained execution results.

[0005] This specification provides an embodiment of a risk detection device for a blockchain system. The device includes: a data acquisition module for acquiring transaction information of a transaction invoked through a smart contract and an opcode sequence of the transaction execution; a calculation module for running the opcode sequence through a blockchain client in the blockchain system based on the transaction information and calculating a first code coverage rate of the opcode sequence run by the blockchain client; a mutation module for mutating the opcode sequence to obtain a mutated opcode sequence that meets preset target mutation conditions, wherein the change in the number of stack elements corresponding to the mutated opcode sequence meets a preset first sub-condition, and the code coverage rate of the mutated opcode sequence run by the blockchain client meets a preset second sub-condition with respect to the first code coverage rate; and a risk detection module for sequentially executing the opcode sequence and the mutated opcode sequence in a local blockchain network composed of multiple blockchain nodes, obtaining corresponding execution results, and determining the risks existing in the blockchain system based on the obtained execution results.

[0006] This specification provides an embodiment of a risk detection device for a blockchain system. The device includes a processor and a memory configured to store computer-executable instructions. When executed, the processor: acquires transaction information of a transaction invoked through a smart contract and an opcode sequence for the transaction execution; based on the transaction information, runs the opcode sequence through a blockchain client in the blockchain system and calculates a first code coverage rate of the opcode sequence run by the blockchain client; mutates the opcode sequence to obtain a mutated opcode sequence that meets preset target mutation conditions, wherein the change in the number of stack elements corresponding to the mutated opcode sequence meets a preset first sub-condition, and the code coverage rate of the mutated opcode sequence run by the blockchain client satisfies a preset second sub-condition between the first code coverage rate and the mutated opcode sequence; and sequentially executes the opcode sequence and the mutated opcode sequence in a local blockchain network composed of multiple blockchain nodes, obtaining corresponding execution results, and determining the risks present in the blockchain system based on the obtained execution results.

[0007] This specification also provides a storage medium for storing computer-executable instructions. When executed by a processor, these instructions implement the following process: acquiring transaction information of a transaction invoked through a smart contract and an opcode sequence for the transaction execution; based on the transaction information, running the opcode sequence through a blockchain client in a blockchain system and calculating a first code coverage rate of the opcode sequence run by the blockchain client; mutating the opcode sequence to obtain a mutated opcode sequence that meets preset target mutation conditions, wherein the change in the number of stack elements corresponding to the mutated opcode sequence meets a preset first sub-condition, and the code coverage rate of the mutated opcode sequence run by the blockchain client meets a preset second sub-condition with respect to the first code coverage rate; sequentially executing the opcode sequence and the mutated opcode sequence in a local blockchain network composed of multiple blockchain nodes, obtaining corresponding execution results, and determining the risks present in the blockchain system based on the obtained execution results.

[0008] This specification also provides a computer program product, including a computer program that, when executed by a processor, implements the following process: acquiring transaction information of a transaction invoked through a smart contract and an opcode sequence for the execution of the transaction; based on the transaction information, running the opcode sequence through a blockchain client in a blockchain system and calculating a first code coverage rate of the blockchain client running the opcode sequence; performing mutation processing on the opcode sequence to obtain a mutated opcode sequence that satisfies a preset target mutation condition, wherein the change in the number of stack elements corresponding to the mutated opcode sequence satisfies a preset first sub-condition, and the code coverage rate of the mutated opcode sequence run through the blockchain client satisfies a preset second sub-condition between the first code coverage rate and the mutated opcode sequence; sequentially executing the opcode sequence and the mutated opcode sequence in a local blockchain network composed of multiple blockchain nodes, obtaining corresponding execution results, and determining the risks existing in the blockchain system based on the obtained execution results. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 This is a schematic diagram of the structure of a risk detection system for a blockchain system as described in this specification; Figure 2This is a schematic diagram of a risk detection process in a blockchain system as described in this specification; Figure 3 This is a schematic diagram illustrating the risk detection process of another blockchain system described in this specification; Figure 4 This is a schematic diagram illustrating the risk detection process of another blockchain system described in this specification; Figure 5 This is a schematic diagram illustrating the risk detection process of another blockchain system described in this specification; Figure 6 This is a schematic diagram illustrating the risk detection process of another blockchain system described in this specification; Figure 7 This is a schematic diagram illustrating the risk detection process of another blockchain system described in this specification; Figure 8 This is a schematic diagram illustrating the risk detection process of another blockchain system described in this specification; Figure 9 This is a schematic diagram of a risk detection device for a blockchain system as described in this specification; Figure 10 This is a schematic diagram of a risk detection device for a blockchain system, as described in this specification. Detailed Implementation

[0010] This specification provides a risk detection method, apparatus, and device for a blockchain system.

[0011] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0012] This specification provides a blockchain client code defect detection mechanism. The blockchain system operates in a consensus network composed of distributed blockchain nodes. Each blockchain node needs to run a blockchain client to execute the complete blockchain system functions. The blockchain client provides various RPC methods to allow users to perform functions such as reading the current blockchain state, simulating transaction execution, and parsing existing blockchain transactions. Although blockchain clients are designed to strictly adhere to predetermined blockchain system design specifications, various code defects may exist during actual development, causing the blockchain client to fail to operate according to the specifications. RPC handling code defects are a major type of blockchain client code defect. These defects may cause users to obtain incorrect blockchain state information after making RPC requests, and could even be exploited by malicious attackers to launch denial-of-service attacks against the blockchain client, thus posing corresponding risks.

[0013] Generally, blockchain client code defect detection technologies fall into two main categories: detection methods based on manually constructed rules and monitoring methods based on fuzzing. The latter targets a specific type of code defect risk. By manually constructing rules, it designs denial-of-service attacks targeting simulated transaction execution RPC methods to detect this type of code defect and generate corresponding attacks that exploit it. However, this method relies on a specific type of code defect and requires experts to manually construct detection and attack rules (requiring the manual construction of corresponding smart contracts), making it difficult to automatically extend to the detection of other types of code defects. The fuzzing-based monitoring method, on the other hand, builds a local blockchain network consisting of multiple local blockchain nodes. Blockchain clients implemented in different programming languages ​​(such as Go, Java, Rust, etc.) are deployed to this local blockchain network. The blockchain state is generated by deploying and calling some predefined smart contracts. Furthermore, this method generates multiple RPC requests by mutating the parameters of the RPC requests and sends these requests to different blockchain clients. Detection is performed by observing the consistency of the return values ​​from different blockchain clients. However, this method generates different RPC requests by mutating RPC request parameters, which cannot automatically generate RPC requests related to the blockchain system state based on the transactions recorded in the current blockchain system, making it difficult to trigger defect detection related to transaction processing. Therefore, the embodiments in this specification use blockchain state mutation technology and differential testing technology to automatically and accurately identify code defects in the remote procedure call processing of the blockchain client. Specific processing details can be found in the following embodiments.

[0014] The risk detection method for a blockchain system provided in one or more embodiments of this specification is applicable to the implementation environment of risk detection in a blockchain system. (Refer to...) Figure 1 The implementation environment includes at least: The testing equipment 100 and the local blockchain system 200 consisting of multiple blockchain nodes, wherein: The detection device 100 can be a terminal device or a server, etc. The terminal device can be a mobile phone, personal computer, tablet computer, e-book reader, wearable device, device for information interaction based on AR (Augmented Reality) or VR (Virtual Reality), and laptop computer, etc. The server can be one or more servers, a server cluster composed of several servers, or a cloud server of a cloud computing platform, etc.

[0015] The local blockchain system 200 includes multiple blockchain nodes, which can be terminal devices or servers, etc. Each blockchain node has a blockchain client installed to execute blockchain programs to perform the complete blockchain system functions, including transaction processing, data storage, blockchain network protocols, and block generation and verification.

[0016] In addition, it may include a database 300, which may be set in the detection device 100 or outside the detection device 100. The database 300 may store relevant data, rules, algorithms and so on in the risk detection process.

[0017] In this implementation environment, the detection device 100 acquires the transaction information of a transaction invoked through a smart contract and the opcode sequence executed by that transaction. Then, based on the transaction information, it can run the opcode sequence through a blockchain client in the blockchain system and calculate the first code coverage rate of the opcode sequence run by the blockchain client. Afterward, the opcode sequence can be mutated to obtain a mutated opcode sequence that meets the preset target mutation conditions. The change in the number of stack elements corresponding to the mutated opcode sequence satisfies the preset first sub-condition, and the code coverage rate of the mutated opcode sequence run by the blockchain client satisfies the preset second sub-condition between the first code coverage rate and the first code coverage rate. Finally, the opcode sequence and the mutated opcode sequence can be executed sequentially in the local blockchain network corresponding to the local blockchain system composed of multiple blockchain nodes to obtain the corresponding execution results. Based on the obtained execution results, the risks existing in the blockchain system are determined.

[0018] like Figure 2As shown in the embodiments of this specification, a risk detection method for a blockchain system is provided. The execution subject of this method can be a risk detection device applied to the blockchain system. This detection device can be a terminal device or a server, etc. The terminal device can be a mobile terminal device such as a mobile phone or tablet computer, or a computer device such as a laptop or desktop computer, or an IoT device (specifically, a smartwatch, in-vehicle device, etc.). The server can be a single server or a server cluster composed of multiple servers. The server can be a backend server in fields such as finance or online shopping, or a backend server for a specific application. This embodiment uses a server as the execution subject for detailed explanation. For the case where the execution subject is a terminal device, please refer to the following server-side processing, which will not be repeated here. The method specifically includes the following steps: In step S202, the transaction information of the transaction invoked through the smart contract and the opcode sequence of the transaction execution are obtained.

[0019] A smart contract is a computer protocol designed to disseminate, verify, or execute contracts in an informational manner. Smart contracts allow for trusted interaction without a third party; such interaction is traceable and irreversible. A smart contract includes an agreement on which the contract participants can execute their agreed-upon rights and obligations. A smart contract may include triggering conditions for execution and corresponding results. A smart contract may include one or more triggering conditions, each with a corresponding result, which can be set according to specific circumstances. Smart contracts are based on computer code and presented through a rigorous logical structure. Blockchain nodes can observe, record, and verify contract states through a user interface. Transactions invoked through smart contracts can occur within the blockchain system where a user or external account sends a transaction to trigger the execution of predefined functions within the smart contract. This transaction (which may be an RPC request) carries instructions and parameters for invoking the smart contract, which are verified and executed by blockchain nodes, ultimately changing the blockchain state or returning a computational result. The blockchain system involved in this embodiment can be a distributed ledger system. By chaining data together in the form of blocks, it ensures the security and immutability of information. Each block in the blockchain system contains a set of transaction data, a timestamp, and the hash value of the previous block, thus forming a continuous chain. The decentralized nature of the blockchain system allows data to be stored on multiple blockchain nodes. The failure or malicious behavior of any single blockchain node cannot affect the integrity of the entire blockchain network. This makes the blockchain system have broad application potential in multiple fields such as finance, supply chain management, and identity verification, because it can provide transparent, secure, and traceable transaction records. The opcode sequence can be a sequence of one or more opcodes arranged in a specified order. Opcodes can be code running on the blockchain system. Various tasks can be performed through opcodes, such as account management, saving transaction target information, viewing the remaining resource information in the account, tracking resource transfer, and determining resource ownership. Opcodes can also define smart contracts and can define complex transaction rules, automatic execution and management mechanism rules, etc., thereby changing the future transactions and interactions between entities and between businesses and consumers. Opcodes aim to achieve efficient resource storage and smart contract execution. Furthermore, for transactions invoked through smart contracts, the blockchain system will execute the smart contract opcodes one by one according to the invoked smart contract functions, and record the sequence of opcodes executed for the transaction by tracing the call sequence of smart contract opcodes.

[0020] In implementation, a blockchain transaction acquisition module can be installed in the detection equipment. This module collects an initial transaction dataset from the blockchain system. Specifically, this can be achieved by deploying blockchain nodes and randomly selecting a certain number (e.g., 1000 or 2000) of contract call transactions from designated blocks in the blockchain system (e.g., a certain number of recently generated blocks, such as 100,000 blocks, blocks generated within a preset time range, or blocks generated within a preset identifier range). For transactions called via smart contracts, the blockchain system executes the smart contract opcodes one by one according to the called smart contract functions. By tracing the call sequence of smart contract opcodes, the execution opcode sequence is recorded in the transaction dataset. The transaction information of transactions called via smart contracts and the execution opcode sequence of those transactions can be obtained from the aforementioned transaction dataset. This can be a single transaction and its execution opcode sequence, or multiple transactions and the execution opcode sequence of each of those transactions, depending on the specific circumstances.

[0021] In step S204, based on the transaction information of the above transactions, the above opcode sequence is run through the blockchain client in the blockchain system, and the first code coverage of the blockchain client running the opcode sequence is calculated.

[0022] In this context, a blockchain client can be a blockchain program executed on a blockchain node. The blockchain system runs in a consensus network composed of distributed blockchain nodes. For each blockchain node, a blockchain client needs to be run to execute the complete functions of the blockchain system, including transaction processing, data storage, blockchain network protocols, and block generation and verification.

[0023] In implementation, based on the collected transaction information (or the aforementioned transaction dataset), the transaction information is randomly mutated to automatically generate complex transaction sequences. The challenge of this mutation process lies in generating valid or compliant opcodes and generating opcode sequences that cover as many blockchain client code paths as possible. The blockchain system runs on a stack-based virtual machine. During transaction execution, the blockchain virtual machine executes the opcodes of the transaction sequence sequentially. Regarding the validity of the opcode sequence, the blockchain virtual machine parses the bytecode sequence according to the opcodes defined in the Yellow Paper. If the bytecode sequence does not meet the opcode definition, an execution exception is thrown, terminating bytecode execution. Furthermore, the code coverage obtained when the mutated opcode sequence is executed by the blockchain client should be better than the code coverage obtained when the unmutated opcode sequence is executed by the blockchain client. Therefore, for the acquired opcode sequence, the detection device can input the opcode sequence into the blockchain client. Simultaneously, it can also input the transaction information of the aforementioned transactions into the corresponding blockchain node. Through this blockchain client, the opcode sequence is run based on the transaction information of the aforementioned transactions, and the first code coverage of the blockchain client running the opcode sequence is calculated. The opcode sequence can be input into the blockchain clients of multiple different blockchain nodes, or it can be input into the blockchain client of a specific blockchain node. The specific settings can be configured according to the actual situation.

[0024] The code coverage (InitCoverage) of the blockchain client executing the opcode sequence can be calculated by actually running the opcode sequence on the blockchain client, and the calculated code coverage is used as the first code coverage.

[0025] In step S206, the above opcode sequence is mutated to obtain a mutated opcode sequence that meets the preset target mutation conditions. The change in the number of stack elements corresponding to the mutated opcode sequence meets the preset first sub-condition, and the code coverage of the mutated opcode sequence running through the blockchain client meets the preset second sub-condition between the first code coverage and the first code coverage.

[0026] The target mutation condition can be set by the change in the number of stack elements corresponding to the mutated opcode sequence satisfying a preset first sub-condition, and the code coverage of the mutated opcode sequence running through the blockchain client satisfying a preset second sub-condition between the first code coverage and the second sub-condition. The first sub-condition can be that the change in the number of stack elements corresponding to the mutated opcode sequence is within a preset range, such as [-1,1] or [-2,2], or other forms of conditions, which can be set according to the actual situation. The second sub-condition can be that the difference between the code coverage of the mutated opcode sequence running through the blockchain client and the first code coverage is within a preset numerical range, such as [0,0.1] or [0,0.2], or other forms of conditions, which can be set according to the actual situation.

[0027] In implementation and practical applications, the execution of each opcode changes the number of elements in the stack. For example, the ADD opcode takes the top two elements of the stack as input, sums them, and outputs the sum to the stack. Therefore, after executing the ADD opcode, the total stack height of the virtual machine will decrease by 1. If there are insufficient stack elements when executing the opcode, the blockchain virtual machine will throw a stack underflow error, thus terminating the transaction execution. To avoid generating illegal or non-compliant opcode sequences during random mutation, which could lead to abnormal stack element counts, a stack element-aware mutation algorithm can be set to prevent the mutated opcode sequence from triggering a stack underflow error, thereby improving the efficiency of generating valid opcode sequences.

[0028] Specifically, for each transaction in the transaction dataset, the stack element-aware mutation algorithm can be as follows: the input data of this algorithm is the opcode sequence of the transaction execution. The complete set of opcodes defined in the Yellow Paper on Blockchain Its output data is the mutated opcode sequence. The above opcode sequence can be mutated using a stack element-aware mutation algorithm in various ways. For example, it can be mutated using simple bit flipping. Specifically, the number of bits to be flipped each time can be preset, such as flipping 1 bit, 2 adjacent bits, or 4 adjacent bits. During each mutation, the change in the number of stack elements corresponding to the resulting opcode sequence is calculated, and it is determined whether the calculation result satisfies a preset first sub-condition. In addition, the code coverage of the opcode sequence obtained by running through the blockchain client is calculated and compared with the first code coverage, and it is determined whether the comparison result satisfies a preset second sub-condition. The mutation process can be repeated in this way until the change in the number of stack elements corresponding to the opcode sequence obtained by simple bit flipping satisfies the preset first sub-condition, and the code coverage of the opcode sequence obtained by running through the blockchain client (i.e., the opcode sequence obtained by simple bit flipping) satisfies the preset second sub-condition. The opcode sequence obtained by simple bit flipping can then be used as the mutated opcode sequence that satisfies the preset target mutation condition. The above simple bit-flipping mutation process can yield one or more different mutated opcode sequences that satisfy the preset target mutation conditions.

[0029] For example, the above mutation process can be performed using dictionary mutation. Specifically, mutation can be performed using dictionary contents, targeting specific, meaningful string content. The contents of this dictionary, called Tokens, are first sorted by string length in ascending order to quickly determine when a longer string cannot be added and break the loop. Then, strings are retrieved one by one from the dictionary, and mutation is performed using overwriting and insertion. During each mutation process, the number of stack elements corresponding to the calculated opcode sequence changes, and it is determined whether the calculation result meets the first preset sub-condition. Furthermore, the code coverage rate of the opcode sequence obtained through the blockchain client is calculated and compared with the first code coverage rate to determine whether the comparison result meets the second preset sub-condition. The above method allows for repeated mutation processing until the change in the number of stack elements corresponding to the opcode sequence obtained through dictionary mutation satisfies a preset first sub-condition, and the code coverage of the opcode sequence (i.e., the opcode sequence obtained through dictionary mutation) run through a blockchain client satisfies a preset second sub-condition between the first code coverage and the first code coverage. The opcode sequence obtained through dictionary mutation can then be considered a mutated opcode sequence that satisfies the preset target mutation condition. The above dictionary mutation process can yield one or more different mutated opcode sequences that satisfy the preset target mutation condition.

[0030] In practical applications, in addition to the above-mentioned mutation methods, the above-mentioned opcode sequence can also be mutated using various other mutation methods, such as addition and subtraction mutation, mutation of specified values ​​or characters, random deletion and random concatenation mutation, and any other mutation method that can produce a mutated opcode sequence that meets the preset target mutation conditions. The specific method can be set according to the actual situation.

[0031] In step S208, the above opcode sequence and the modified opcode sequence are executed sequentially in a local blockchain network composed of multiple blockchain nodes to obtain the corresponding execution results, and the risks existing in the blockchain system are determined based on the obtained execution results.

[0032] In implementation, a local blockchain network consisting of multiple blockchain nodes can be established first. Then, the transaction information in the aforementioned transaction dataset is published to the local blockchain network. For a given set of opcode sequences corresponding to a transaction, each blockchain node (i.e., the blockchain virtual machine) in the blockchain network can execute each opcode sequence sequentially, thereby changing the state of the blockchain and obtaining the corresponding execution result. This result can include information such as the hash value of the sent transaction, the remaining resources of the transaction sender, and the storage status of the transaction sender and receiver, which can be specifically configured according to actual conditions. The detection device can obtain the execution results of each opcode sequence and each mutated opcode sequence from each blockchain node in the local blockchain system corresponding to the local blockchain network. By comparing the execution results of the same opcode sequence or the same mutated opcode sequence returned by different blockchain nodes, it can determine whether there are code defects in the blockchain client of the blockchain node, thus posing a risk to the blockchain system. If so, an alarm can be triggered to update the blockchain client in a timely manner; otherwise, it indicates that there are no code defects in the blockchain client of the blockchain node.

[0033] This specification provides a risk detection method for a blockchain system. It obtains transaction information and the opcode sequence of a transaction invoked via a smart contract. Then, based on the transaction information, it runs the opcode sequence through a blockchain client within the blockchain system and calculates a first code coverage rate. Next, it mutates the opcode sequence to obtain a mutated opcode sequence that meets preset target mutation conditions. The change in the number of stack elements corresponding to the mutated opcode sequence satisfies a preset first sub-condition, and the code coverage rate of the mutated opcode sequence running through the blockchain client satisfies a preset second sub-condition compared to the first code coverage rate. Finally, it sequentially executes the operation within a local blockchain network composed of multiple blockchain nodes. The code sequence and the mutated opcode sequence are used to obtain corresponding execution results. Based on the obtained execution results, the risks existing in the blockchain system are determined. In this way, by automating the generation of blockchain state, code defects in the blockchain client processing process can be automatically and efficiently identified. Moreover, in the process of generating blockchain state, an initial transaction dataset is constructed based on the transactions collected in the blockchain system. By proposing a stack element-aware mutation algorithm, multiple blockchain transactions are generated efficiently and legally. The transactions and opcode sequences obtained by random mutation are published to the local blockchain network, and the blockchain state is tracked and recorded, thereby constructing diverse blockchain states. This allows for the rapid and effective detection of risks such as code defects in the blockchain client, improving the risk detection efficiency of the blockchain client.

[0034] In practical applications, the specific processing method of step S206 can vary. The following provides another optional processing method, which may specifically include the processing of steps S2062 to S2068. Based on this, in the above... Figure 2 Based on this, the specific steps included in this method can be as follows: Figure 3 As shown.

[0035] In step S2062, a portion of the opcodes is randomly deleted from the opcode sequence to obtain the opcode sequence after deletion.

[0036] In implementation, such as Figure 4 As shown, the stack-aware mutation algorithm can randomly select a position from the opcode sequence and delete the opcode of random length at that position, resulting in a deleted opcode sequence. Alternatively, it can randomly select a position from the opcode sequence and delete the opcode of a specified length (which can be preset) at that position, resulting in a deleted opcode sequence. Furthermore, it can determine a preset position from the opcode sequence and delete the opcode of random length at that position, resulting in a deleted opcode sequence; or it can determine a preset position from the opcode sequence and delete the opcode of a specified length (which can be preset) at that position, resulting in a deleted opcode sequence. The specific method can be set according to the actual situation.

[0037] In step S2064, the opcode sequence to be inserted is obtained, and the opcode sequence to be inserted is inserted into the opcode sequence after deletion to obtain the first opcode sequence. The change in the number of stack elements corresponding to the first opcode sequence satisfies the preset first sub-condition.

[0038] In implementation, the opcode sequence to be inserted can be obtained in various ways. For example, the opcode sequence can be obtained from a specified opcode database. Specifically, the opcode sequence can be randomly obtained from the specified opcode database, or the opcode sequence obtained from the specified opcode database with a similarity greater than a preset similarity threshold with the part of the opcode to be deleted can be obtained. The obtained opcode sequence can be inserted into the deleted opcode sequence. It is determined whether the change in the number of stack elements corresponding to the inserted opcode sequence satisfies a preset first sub-condition. If so, the obtained opcode sequence can be used as the opcode sequence to be inserted into the deleted opcode sequence to obtain the first opcode sequence.

[0039] In step S2066, based on the transaction information of the above transactions, the first opcode sequence is run through the blockchain client to calculate the corresponding second code coverage.

[0040] In implementation, for the first opcode sequence, the detection device can input the first opcode sequence into the blockchain client. Simultaneously, it can also input the transaction information of the aforementioned transaction into the corresponding blockchain node. Through the blockchain client, the first opcode sequence is executed based on the transaction information, and the corresponding second code coverage is calculated. The first opcode sequence can be input into the blockchain clients of multiple different blockchain nodes, or it can be input into the blockchain client of a specific blockchain node; the specific configuration can be determined according to the actual situation.

[0041] In step S2068, if the second code coverage is not less than the first code coverage, then the first opcode sequence is used as the mutated opcode sequence that satisfies the preset target mutation condition.

[0042] In practice, if the second code coverage rate is not less than the first code coverage rate, meaning the code coverage rate of the mutated first opcode sequence remains unchanged or increases compared to the code coverage rate of the original opcode sequence, then the first opcode sequence can be considered a mutated opcode sequence that meets the preset target mutation conditions. Furthermore, if the second code coverage rate is less than the first code coverage rate, then the code coverage rate of the mutated first opcode sequence decreases compared to the code coverage rate of the original opcode sequence. In this case, the first opcode sequence can be determined to be non-compliant and can be deleted.

[0043] In practical applications, the specific processing method of step S2064 can vary. The following provides another optional processing method, which may specifically include the processing of steps S206402 to S206414. Based on this, in the above... Figure 3 Based on this, the specific steps included in this method can be as follows: Figure 5 As shown.

[0044] In step S206402, information on the change in the number of stack elements corresponding to each opcode in the deleted opcode is obtained.

[0045] In implementation, the number of stack elements when each opcode in the deleted partial opcode is output, and the number of stack elements when each opcode in the deleted partial opcode is input, can be obtained. This information can then be input into the following formula.

[0046] This yields information on the change in the number of stack elements corresponding to each opcode in the deleted portion of the opcode. Among these, The number of stack elements when the opcode is output. The number of stack elements when the opcode is input.

[0047] In step S206404, the change information of the number of stack elements corresponding to the deleted partial opcodes is determined based on the change information of the number of stack elements corresponding to each opcode in the deleted partial opcodes.

[0048] In practice, after calculating the change in the number of stack elements corresponding to each opcode in the deleted partial opcode using the above method, the change in the number of stack elements corresponding to each opcode in the deleted partial opcode can be accumulated to obtain the change in the number of stack elements corresponding to the deleted partial opcode.

[0049] In step S206406, an empty opcode sequence is generated, one or more opcodes are randomly selected from a preset opcode set, and the randomly selected opcodes are added to the empty opcode sequence to obtain the initial opcode sequence to be inserted.

[0050] In implementation, an empty opcode sequence can be initialized. Then, one or more opcodes can be randomly selected from a preset opcode set. This preset opcode set can be constructed from opcodes in the aforementioned transaction dataset, or it can be constructed based on opcodes obtained from a specified database, etc., depending on the actual situation. The randomly selected opcodes can then be added to an empty opcode sequence to obtain the initial opcode sequence to be inserted.

[0051] In step S206408, the change information of the number of stack elements corresponding to each opcode in the initial opcode sequence to be inserted is obtained.

[0052] In implementation, the number of stack elements when each opcode in the initial opcode sequence to be inserted is output, and the number of stack elements when each opcode in the initial opcode sequence to be inserted is input can be obtained. The obtained information can be input into the formula to obtain the information on the change in the number of stack elements corresponding to each opcode in the initial opcode sequence to be inserted.

[0053] In step S206410, the change information of the number of stack elements corresponding to the initial opcode sequence to be inserted is determined based on the change information of the number of stack elements corresponding to each opcode in the initial opcode sequence to be inserted.

[0054] In implementation, after calculating the stack element change information corresponding to each opcode in the initial opcode sequence to be inserted in the above manner, the stack element change information corresponding to each opcode in the initial opcode sequence to be inserted can be accumulated to obtain the stack element change information corresponding to the initial opcode sequence to be inserted.

[0055] In step S206412, based on the stack element number change information corresponding to the deleted partial opcode and the stack element number change information corresponding to the initial opcode sequence to be inserted, it is determined whether the stack element number change corresponding to the second opcode sequence obtained after inserting the initial opcode sequence to be inserted into the deleted opcode sequence satisfies the preset first sub-condition.

[0056] In implementation, the final stack element quantity change information can be calculated based on the stack element quantity change information corresponding to the deleted opcode and the stack element quantity change information corresponding to the initial opcode sequence to be inserted. If the final stack element quantity change information is within the specified range, it is determined that the stack element quantity change corresponding to the second opcode sequence obtained after inserting the initial opcode sequence to be inserted into the deleted opcode sequence satisfies the preset first sub-condition; otherwise, the preset first sub-condition is not satisfied.

[0057] In step S206414, if so, the initial opcode sequence to be inserted is used as the opcode sequence to be inserted, and the opcode sequence to be inserted is inserted into the deleted opcode sequence to obtain the first opcode sequence.

[0058] In practical applications, the specific processing method of step S206412 can vary. The following provides another optional processing method, which may specifically include the processing of steps S2064122 and S2064124. Based on this, in the above... Figure 5 Based on this, the specific steps included in this method can be as follows: Figure 6 As shown.

[0059] In step S2064122, based on the stack element number change information corresponding to the deleted partial opcode and the stack element number change information corresponding to the initial opcode sequence to be inserted, the stack element number change information corresponding to the second opcode sequence is determined.

[0060] In implementation, the final stack element quantity change information can be calculated based on the stack element quantity change information corresponding to the deleted opcode and the initial opcode sequence to be inserted. The calculated final stack element quantity change information is then used as the stack element quantity change information corresponding to the second opcode sequence.

[0061] In step S2064124, if the stack element quantity change information corresponding to the second opcode sequence indicates that the stack element quantity has not changed, then it is determined that the stack element quantity change corresponding to the second opcode sequence satisfies the preset first sub-condition.

[0062] In implementation, it can be pre-set that the change in the number of stack elements corresponding to the opcode sequence obtained after the above mutation process is 0, and the mutation process is considered to be legal or compliant. At this time, the change information of the number of stack elements corresponding to the second opcode sequence can be analyzed. If the change information of the number of stack elements corresponding to the second opcode sequence indicates that the change in the number of stack elements corresponding to the second opcode sequence is 0 (or the number of stack elements has not changed), then it can be determined that the mutation process is legal or compliant. At this time, it can be determined that the change in the number of stack elements corresponding to the second opcode sequence satisfies the preset first sub-condition.

[0063] In practical applications, if the stack element count change information corresponding to the second opcode sequence indicates that the stack element count change is not 0, it can also be processed in the following way: If the stack element count change information corresponding to the second opcode sequence indicates that the stack element count change is not 0, then repeatedly execute the process of randomly selecting one or more opcodes from the preset opcode set, adding the randomly selected opcodes to the empty opcode sequence and its subsequent processing, until the stack element count change information corresponding to the opcode sequence obtained after inserting the initial opcode sequence to be inserted into the deleted opcode sequence indicates that the stack element count has not changed, and the opcode sequence to be inserted is obtained.

[0064] In practice, if the stack element quantity change information corresponding to the second opcode sequence indicates that the stack element quantity change is not 0, then the above mutation process can be considered illegal or non-compliant. In this case, step S206406, which involves randomly selecting one or more opcodes from the preset opcode set and adding the randomly selected opcodes to the empty opcode sequence to obtain the initial opcode sequence to be inserted, and the processing of steps S206408 to S206412, can be repeated until the stack element quantity change information corresponding to the opcode sequence obtained after inserting the initial opcode sequence to be inserted into the deleted opcode sequence indicates that the stack element quantity has not changed, thus obtaining the opcode sequence to be inserted.

[0065] In practical applications, if the second code coverage is less than the first code coverage, it can also be handled in the following way: If the second code coverage is less than the first code coverage, the random deletion of some opcodes from the opcode sequence and its subsequent processing are repeated until the code coverage of the opcode sequence corresponding to the change in the number of stack elements satisfies the preset first sub-condition is not less than the first code coverage or the number of repeated executions reaches the preset number, and the mutated opcode sequence that satisfies the preset target mutation condition is determined.

[0066] In implementation, if the second code coverage is less than the first code coverage, the processing steps S2062 to S2066 can be repeated (wherein, the specific processing of step S2064 includes the processing of steps S206402 to S206414, and step S206412 may include the processing of steps S2064122 and S2064124) until the code coverage of the opcode sequence corresponding to the change in the number of stack elements satisfies the preset first sub-condition is not less than the first code coverage or the number of repeated executions reaches the preset number (the specific number can be set according to the actual situation, such as 1000 times, 800 times, or 500 times, etc.), and the mutated opcode sequence that satisfies the preset target mutation condition is determined.

[0067] The entire process of the stack element-aware mutation algorithm described above can be seen in one possible implementation, the pseudocode of which is as follows:

[0068] In practical applications, the specific processing methods for sequentially executing the opcode sequence and the mutated opcode sequence in a local blockchain network composed of multiple blockchain nodes in step S208 above to obtain the corresponding execution results can vary. The following provides another optional processing method, which may specifically include the processing in steps S20802 and S20804. Based on this, in the above... Figure 2 Based on this, the specific steps included in this method can be as follows: Figure 7 As shown.

[0069] In step S20802, an opcode sequence is selected from the opcode sequence and the modified opcode sequence. The selected opcode sequence is used as the data field of the transaction, and the receiving address of the transaction is set to address 0. The transaction is then published to the local blockchain network to trigger the local blockchain system corresponding to the local blockchain network to execute the opcode sequence in the data field of the transaction.

[0070] In implementation, such as Figure 4 As shown, a local blockchain network consisting of multiple blockchain nodes can be built. Transaction information from the aforementioned transaction dataset can be published on this local blockchain network. For a given set of opcode sequences corresponding to a transaction, each blockchain node (i.e., the blockchain virtual machine) can select an opcode sequence from the original opcode sequence and its modified form. The selected opcode sequence is used as the transaction's data field, and the transaction's receiving address is set to address 0. The transaction is then published to the local blockchain network. Within the local blockchain network, when the transaction's receiving address is address 0, the transaction is considered a smart contract creation transaction. The blockchain nodes (i.e., the blockchain virtual machine) will sequentially execute the opcode sequence in the transaction's data field, thereby changing the state of the blockchain.

[0071] In step S20804, the blockchain state change information generated in the opcode sequence of the data field of the local blockchain system executing the above transaction is recorded, and the above execution result is determined based on the recorded blockchain state change information. The blockchain state change information includes one or more of the following: the hash value of sending the transaction, the remaining resource information of the transaction sender, the nonce value of the transaction sender, and the storage state change information of the transaction sender and receiver.

[0072] In implementation, such as Figure 4 As shown, during the execution of the above opcode sequence, the blockchain state change information generated in the opcode sequence in the data field of the transaction executed by the local blockchain system can be recorded, and the execution result can be determined based on the recorded blockchain state change information.

[0073] In practical applications, before determining the risks present in the blockchain system based on the obtained execution results, the RPC request can be configured in the following manner, as detailed in steps S210 and S212 below. Based on this, in the above... Figure 7 Based on this, the specific steps included in this method can be as follows: Figure 8 As shown.

[0074] In step S210, the remote procedure call (RPC) interface provided by the blockchain client in the local blockchain network is obtained.

[0075] In implementation, to efficiently explore the RPC executor space, efficiently generate RPC requests that trigger specific blockchain state code defects, and improve detection accuracy, such as... Figure 4 As shown, a blockchain state-aware RPC parameter mutation algorithm can be set. Specifically, it can collect the RPC interfaces provided by blockchain clients in the local blockchain network (it can be all RPC interfaces, or a specified part of the RPC interfaces, etc., which can be set according to the actual situation).

[0076] In step S212, for any RPC interface, a corresponding RPC request template is constructed. The RPC request template includes an RPC identifier and an RPC parameter type. The RPC parameter type includes blockchain state-related parameter types and numerical types.

[0077] In implementation, for each RPC interface, a corresponding RPC request template can be constructed: (RPC name, RPC parameter type). For blockchain clients, the types of parameters received by their RPCs can be divided into two categories: 1) Blockchain state-related parameter types. For example, if a blockchain client provides a trace_transaction RPC interface, its received parameter is the transaction hash value, and its return value is the opcode sequence of the blockchain client's transaction execution process and blockchain state change information, the generated RPC request template for this RPC interface is: (RPC name; trace_transaction, RPC parameter: [transaction hash value]); 2) Numerical types: such as the remaining resource quantity of the transaction sender.

[0078] Based on the processing of steps S210 and S212 above, the specific processing method for determining the risks existing in the blockchain system based on the obtained execution results in step S208 can be varied. Here is another optional processing method, which may include the processing of steps S20806 to S20810.

[0079] In step S20806, an RPC interface is selected from the RPC interfaces provided by the blockchain client. Based on the RPC parameter type in the RPC request template corresponding to the selected RPC interface and the recorded blockchain state change information, the corresponding RPC parameters are generated.

[0080] In implementation, during the RPC request generation process, an RPC interface can be selected from the RPC interfaces provided by the blockchain client (an RPC interface can be randomly selected or a specified RPC interface can be selected, etc.). Then, the RPC parameters can be mutated. Specifically, for blockchain state-related parameter types, the transaction hash value in the above-mentioned recorded sent transaction hash dataset can be randomly selected as the parameter; for numerical types, an integer can be randomly generated as the parameter from the feasible range.

[0081] In step S20808, a corresponding RPC request is generated based on the generated RPC parameters, and the generated RPC request is sent to the blockchain node in the local blockchain network. The RPC request is used to call the blockchain node to query the above execution result.

[0082] In implementation, the blockchain state-aware RPC parameter mutation algorithm can generate corresponding parameters for a specific RPC interface, thereby forming a sendable RPC request. The generated RPC request can be sent sequentially and simultaneously to blockchain nodes in the local blockchain network (this could be all blockchain nodes, or a specified subset of blockchain nodes, etc.).

[0083] In step S20810, the return value corresponding to the RPC request sent by the blockchain node is received, and the risks existing in the blockchain system are determined based on the received return value.

[0084] In implementation, the return values ​​corresponding to the RPC requests sent by the blockchain nodes can be collected. The received return values ​​can be compared with a preset threshold. If the received return values ​​match the preset threshold, it can be determined that there is no risk in the blockchain system; otherwise, it can be determined that there is a risk in the blockchain system.

[0085] In practical applications, the specific processing method for determining the risks existing in the blockchain system based on the received return value in step S20810 above can be varied. The following is another optional processing method, which may include the following: For the same RPC request, if different blockchain nodes return different values, it is determined that there is a risk in the blockchain client in the blockchain system.

[0086] In implementation, such as Figure 4 As shown, differential testing can be used to determine whether a blockchain client has risks. Specifically, for the same RPC request, the return values ​​of different blockchain nodes can be compared. If different blockchain nodes return different values, it is determined that the blockchain client in the blockchain system has risks.

[0087] Based on the above processing, a corresponding verification report can also be generated to verify and warn of risks existing in blockchain clients in the blockchain system. For details, please refer to the following: Generate a verification report on risks existing in blockchain clients in the blockchain system and output the verification report.

[0088] This specification provides a risk detection method for a blockchain system. It obtains transaction information and the opcode sequence of a transaction invoked via a smart contract. Then, based on the transaction information, it runs the opcode sequence through a blockchain client within the blockchain system and calculates a first code coverage rate. Next, it mutates the opcode sequence to obtain a mutated opcode sequence that meets preset target mutation conditions. The change in the number of stack elements corresponding to the mutated opcode sequence satisfies a preset first sub-condition, and the code coverage rate of the mutated opcode sequence running through the blockchain client satisfies a preset second sub-condition compared to the first code coverage rate. Finally, it sequentially executes the operation within a local blockchain network composed of multiple blockchain nodes. The code sequence and the mutated opcode sequence are used to obtain corresponding execution results. Based on the obtained execution results, the risks existing in the blockchain system are determined. In this way, by automating the generation of blockchain state, code defects in the blockchain client processing process can be automatically and efficiently identified. Moreover, in the process of generating blockchain state, an initial transaction dataset is constructed based on the transactions collected in the blockchain system. By proposing a stack element-aware mutation algorithm, multiple blockchain transactions are generated efficiently and legally. The transactions and opcode sequences obtained by random mutation are published to the local blockchain network, and the blockchain state is tracked and recorded, thereby constructing diverse blockchain states. This allows for the rapid and effective detection of risks such as code defects in the blockchain client, improving the risk detection efficiency of the blockchain client.

[0089] Furthermore, an automated blockchain transaction mutation technology is proposed. By designing a bytecode-based transaction mutation algorithm, complex blockchain transactions are automatically generated and deployed to a local blockchain network containing multiple blockchain nodes, thereby constructing diverse blockchain states. Simultaneously, a blockchain state-aware RPC code defect differential testing mechanism is proposed. By tracking transaction and contract states on the blockchain in real time and combining parameter mutation, it supports the generation of RPC requests related to specific transactions. Further, by sending the mutated RPC requests to blockchain nodes in the local blockchain network and comparing the consistency of the results returned by different blockchain nodes, blockchain RPC code defects are detected. This allows for faster and more effective detection of risks such as code defects in blockchain clients, further improving the risk detection efficiency of blockchain clients.

[0090] The above describes a risk detection method for a blockchain system provided in the embodiments of this specification. Based on the same idea, the embodiments of this specification also provide a risk detection device for a blockchain system, such as... Figure 9 As shown.

[0091] The risk detection device of this blockchain system includes: a data acquisition module 901, a calculation module 902, a mutation module 903, and a risk detection module 904, wherein: The data acquisition module 901 acquires the transaction information of the transaction invoked through the smart contract and the opcode sequence of the transaction execution; The calculation module 902, based on the transaction information of the transaction, runs the opcode sequence through the blockchain client in the blockchain system, and calculates the first code coverage of the blockchain client running the opcode sequence; The mutation module 903 performs mutation processing on the opcode sequence to obtain a mutated opcode sequence that meets the preset target mutation conditions. The change in the number of stack elements corresponding to the mutated opcode sequence meets the preset first sub-condition, and the code coverage of the mutated opcode sequence run by the blockchain client meets the preset second sub-condition between the first code coverage and the code coverage. The risk detection module 904 executes the opcode sequence and the mutated opcode sequence sequentially in a local blockchain network composed of multiple blockchain nodes, obtains the corresponding execution results, and determines the risks existing in the blockchain system based on the obtained execution results.

[0092] In the embodiments of this specification, the mutation module 903 includes: The deletion unit randomly deletes a portion of the opcodes from the opcode sequence to obtain a deleted opcode sequence; The opcode acquisition unit acquires the opcode sequence to be inserted, inserts the opcode sequence to be inserted into the opcode sequence after deletion, and obtains a first opcode sequence. The change in the number of stack elements corresponding to the first opcode sequence satisfies a preset first sub-condition. The first computing unit, based on the transaction information of the transaction, runs the first opcode sequence through the blockchain client to calculate the corresponding second code coverage. If the second code coverage is not less than the first code coverage, then the first opcode sequence is taken as the mutated opcode sequence that satisfies the preset target mutation condition.

[0093] In this embodiment of the specification, the opcode acquisition unit acquires information on the change in the number of stack elements corresponding to each opcode in the deleted opcodes; determines the change in the number of stack elements corresponding to the deleted opcodes based on the change in the number of stack elements corresponding to each opcode in the deleted opcodes; generates an empty opcode sequence, randomly selects one or more opcodes from a preset opcode set, and adds the randomly selected opcodes to the empty opcode sequence to obtain an initial opcode sequence to be inserted; acquires information on the change in the number of stack elements corresponding to each opcode in the initial opcode sequence to be inserted; determines the change in the number of stack elements corresponding to the initial opcode sequence to be inserted based on the change in the number of stack elements corresponding to each opcode in the initial opcode sequence to be inserted; and determines, based on the change in the number of stack elements corresponding to the deleted opcodes and the change in the number of stack elements corresponding to the initial opcode sequence to be inserted, whether the change in the number of stack elements corresponding to the second opcode sequence obtained after inserting the initial opcode sequence to be inserted into the deleted opcode sequence satisfies a preset first sub-condition; if so, the initial opcode sequence to be inserted is used as the opcode sequence to be inserted, and the opcode sequence to be inserted is inserted into the deleted opcode sequence to obtain a first opcode sequence.

[0094] In this embodiment of the specification, the opcode acquisition unit determines the stack element quantity change information corresponding to the second opcode sequence based on the stack element quantity change information corresponding to the deleted partial opcode and the stack element quantity change information corresponding to the initial opcode sequence to be inserted; if the stack element quantity change information corresponding to the second opcode sequence indicates that the stack element quantity has not changed, then it is determined that the stack element quantity change corresponding to the second opcode sequence satisfies a preset first sub-condition.

[0095] In the embodiments described in this specification, the device further includes: If the stack element count change information corresponding to the second opcode sequence indicates that the stack element count change is not 0, the first loop execution module repeatedly executes the process of randomly selecting one or more opcodes from the preset opcode set, adding the randomly selected opcodes to the empty opcode sequence and its subsequent processing, until the stack element count change information corresponding to the opcode sequence obtained after inserting the initial opcode sequence to be inserted into the deleted opcode sequence indicates that the stack element count has not changed, thus obtaining the opcode sequence to be inserted.

[0096] In the embodiments described in this specification, the device further includes: If the second code coverage rate is less than the first code coverage rate, the second loop execution module repeatedly executes the random deletion of some opcodes from the opcode sequence and their subsequent processing until the code coverage rate of the opcode sequence corresponding to the change in the number of stack elements is not less than the first code coverage rate or the number of repeated executions reaches a preset number, and then determines the mutated opcode sequence that meets the preset target mutation condition.

[0097] In this embodiment of the specification, the risk detection module 904 includes: The publishing unit selects an opcode sequence from the opcode sequence and the modified opcode sequence, uses the selected opcode sequence as the data field of the transaction, sets the receiving address of the transaction to address 0, and publishes the set transaction to the local blockchain network to trigger the local blockchain system corresponding to the local blockchain network to execute the opcode sequence in the data field of the transaction. The result determination unit records the blockchain state change information generated in the opcode sequence of the data field of the transaction executed by the local blockchain system, and determines the execution result based on the recorded blockchain state change information. The blockchain state change information includes one or more of the following: the hash value of the transaction sent, the remaining resource information of the transaction sender, the nonce value of the transaction sender, and the storage state change information of the transaction sender and receiver.

[0098] In the embodiments described in this specification, the device further includes: The interface acquisition module acquires the Remote Procedure Call (RPC) interface provided by the blockchain client in the local blockchain network. The template construction module constructs a corresponding RPC request template for any RPC interface. The RPC request template includes an RPC identifier and an RPC parameter type. The RPC parameter type includes blockchain state-related parameter types and numerical types. The risk detection module 904 includes: The parameter determination unit selects an RPC interface from the RPC interfaces provided by the blockchain client, and generates corresponding RPC parameters based on the RPC parameter type in the RPC request template corresponding to the selected RPC interface and the recorded blockchain state change information. The request unit generates a corresponding RPC request based on the generated RPC parameters and sends the generated RPC request to the blockchain node in the local blockchain network. The RPC request is used to call the blockchain node to query the execution result. The risk determination unit receives the return value corresponding to the RPC request sent by the blockchain node, and determines the risks existing in the blockchain system based on the received return value.

[0099] In the embodiments of this specification, the risk determination unit determines that the blockchain client in the blockchain system is at risk if different blockchain nodes return different values ​​for the same RPC request. The device further includes: The report generation module generates a verification report on the risks posed by blockchain clients in the blockchain system and outputs the verification report.

[0100] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more embodiments of this specification, the functions of each module or unit can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative; the division of each module and unit is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or modules can be combined or integrated into another system, or some features can be ignored or not executed, etc.

[0101] This specification provides a risk detection device for a blockchain system. It acquires transaction information and the opcode sequence of a transaction invoked via a smart contract. Then, based on the transaction information, it runs the opcode sequence through a blockchain client within the blockchain system and calculates a first code coverage rate. Next, it mutates the opcode sequence to obtain a mutated opcode sequence that meets preset target mutation conditions. The change in the number of stack elements corresponding to the mutated opcode sequence satisfies a preset first sub-condition, and the code coverage rate of the mutated opcode sequence running through the blockchain client satisfies a preset second sub-condition compared to the first code coverage rate. Finally, it sequentially executes operations within a local blockchain network composed of multiple blockchain nodes. The code sequence and the mutated opcode sequence are used to obtain corresponding execution results. Based on the obtained execution results, the risks existing in the blockchain system are determined. In this way, by automating the generation of blockchain state, code defects in the blockchain client processing process can be automatically and efficiently identified. Moreover, in the process of generating blockchain state, an initial transaction dataset is constructed based on the transactions collected in the blockchain system. By proposing a stack element-aware mutation algorithm, multiple blockchain transactions are generated efficiently and legally. The transactions and opcode sequences obtained by random mutation are published to the local blockchain network, and the blockchain state is tracked and recorded, thereby constructing diverse blockchain states. This allows for the rapid and effective detection of risks such as code defects in the blockchain client, improving the risk detection efficiency of the blockchain client.

[0102] Furthermore, an automated blockchain transaction mutation technology is proposed. By designing a bytecode-based transaction mutation algorithm, complex blockchain transactions are automatically generated and deployed to a local blockchain network containing multiple blockchain nodes, thereby constructing diverse blockchain states. Simultaneously, a blockchain state-aware RPC code defect differential testing mechanism is proposed. By tracking transaction and contract states on the blockchain in real time and combining parameter mutation, it supports the generation of RPC requests related to specific transactions. Further, by sending the mutated RPC requests to blockchain nodes in the local blockchain network and comparing the consistency of the results returned by different blockchain nodes, blockchain RPC code defects are detected. This allows for faster and more effective detection of risks such as code defects in blockchain clients, further improving the risk detection efficiency of blockchain clients.

[0103] The above are risk detection devices for blockchain systems provided in the embodiments of this specification. Based on the same idea, the embodiments of this specification also provide a risk detection device for blockchain systems, such as... Figure 10 As shown.

[0104] The risk detection device of the blockchain system can provide terminal equipment or servers, etc., for the above embodiments.

[0105] Risk detection devices in blockchain systems can vary significantly due to differences in configuration and performance. They may comprise a communication interface 1002, a user interface 1004, a processor 1006, and data storage 1008. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 1010. The communication interface 1002 enables the risk detection device 1000 of the blockchain system to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 1002 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 1002 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 1002 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 1002 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces.

[0106] User interface 1004 includes receiving user input and providing output to the user. Therefore, user interface 1004 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 1004 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 1004 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, the risk detection device 1000 of the blockchain system may support remote access from other devices via communication interface 1002 or another physical interface (not shown). User interface 1004 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 1004 can also be configured as a display device for rendering or displaying text fragments.

[0107] Processor 1006 may contain one or more general-purpose processors and / or special-purpose processors.

[0108] Data storage 1008 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 1006. Data storage 1008 may include removable and non-removable components.

[0109] Processor 1006 is capable of executing program instructions 1018 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 1008 to implement the various functions described herein. Data storage 1008 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by risk detection device 1000 of the blockchain system, enable risk detection device 1000 of the blockchain system to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Execution of program instructions 1018 by processor 1006 may result in processor 1006 using data 1012.

[0110] For example, program instructions 1018 may include an operating system 1022 (e.g., an operating system kernel, device drivers, and / or other modules) and one or more applications 1020 (e.g., a browser, social media application, or game application) installed on the risk detection device 1000 of the blockchain system. Similarly, data 1012 may include operating system data 1016 and application data 1014. Operating system data 1016 is primarily accessible to the operating system 1022, while application data 1014 is primarily accessible to one or more applications 1020. Application data 1014 may reside in a file system visible or hidden from the user of the risk detection device 1000 of the blockchain system.

[0111] Application 1020 can communicate with operating system 1012 through one or more application programming interfaces (APIs). These APIs help application 1020 read and / or write application data 1014, transmit or receive information via communication interface 1002, receive or display information on user interface 1004, etc.

[0112] In some terminology, application 1020 may be simply referred to as "app". Furthermore, application 1020 can be downloaded to the risk detection device 1000 of the blockchain system through one or more online app stores or app markets. However, the application can also be installed on the risk detection device 1000 of the blockchain system in other ways, such as through a web browser or a physical interface (e.g., a USB port) on the risk detection device 1000 of the blockchain system.

[0113] Specifically, in this embodiment, the risk detection device 1000 of the blockchain system includes a data storage 1008 and one or more program instructions 1018, wherein one or more program instructions 1018 are stored in the data storage 1008, and one or more program instructions 1018 are configured to be executed by one or more processors. The one or more program instructions include computer-executable instructions for performing the following: Obtain the transaction information of the transaction invoked through the smart contract and the opcode sequence of the transaction execution; Based on the transaction information of the transaction, the opcode sequence is run through the blockchain client in the blockchain system, and the first code coverage of the blockchain client running the opcode sequence is calculated; The opcode sequence is mutated to obtain a mutated opcode sequence that meets the preset target mutation conditions. The change in the number of stack elements corresponding to the mutated opcode sequence meets the preset first sub-condition, and the code coverage of the mutated opcode sequence run by the blockchain client meets the preset second sub-condition between the first code coverage and the code coverage. In a local blockchain network consisting of multiple blockchain nodes, the opcode sequence and the mutated opcode sequence are executed sequentially to obtain corresponding execution results, and the risks existing in the blockchain system are determined based on the obtained execution results.

[0114] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the risk detection device embodiment for the blockchain system is described simply because it is fundamentally similar to the method embodiment; relevant parts can be referred to the descriptions in the method embodiment.

[0115] This specification provides a risk detection device for a blockchain system. It acquires transaction information and the opcode sequence of a transaction invoked via a smart contract. Then, based on the transaction information, it runs the opcode sequence through a blockchain client within the blockchain system and calculates a first code coverage rate. Next, it mutates the opcode sequence to obtain a mutated opcode sequence that meets preset target mutation conditions. The change in the number of stack elements corresponding to the mutated opcode sequence satisfies a preset first sub-condition, and the code coverage rate of the mutated opcode sequence running through the blockchain client satisfies a preset second sub-condition compared to the first code coverage rate. Finally, it sequentially executes operations within a local blockchain network composed of multiple blockchain nodes. The code sequence and the mutated opcode sequence are used to obtain corresponding execution results. Based on the obtained execution results, the risks existing in the blockchain system are determined. In this way, by automating the generation of blockchain state, code defects in the blockchain client processing process can be automatically and efficiently identified. Moreover, in the process of generating blockchain state, an initial transaction dataset is constructed based on the transactions collected in the blockchain system. By proposing a stack element-aware mutation algorithm, multiple blockchain transactions are generated efficiently and legally. The transactions and opcode sequences obtained by random mutation are published to the local blockchain network, and the blockchain state is tracked and recorded, thereby constructing diverse blockchain states. This allows for the rapid and effective detection of risks such as code defects in the blockchain client, improving the risk detection efficiency of the blockchain client.

[0116] Furthermore, based on the above Figures 1 to 8 This specification also provides a storage medium for storing computer-executable instruction information in one or more embodiments. In one specific embodiment, the storage medium may be a USB flash drive, optical disc, hard disk, etc. When the computer-executable instruction information stored in the storage medium is executed by a processor, it can realize the following process: Obtain the transaction information of the transaction invoked through the smart contract and the opcode sequence of the transaction execution; Based on the transaction information of the transaction, the opcode sequence is run through the blockchain client in the blockchain system, and the first code coverage of the blockchain client running the opcode sequence is calculated; The opcode sequence is mutated to obtain a mutated opcode sequence that meets the preset target mutation conditions. The change in the number of stack elements corresponding to the mutated opcode sequence meets the preset first sub-condition, and the code coverage of the mutated opcode sequence run by the blockchain client meets the preset second sub-condition between the first code coverage and the code coverage. In a local blockchain network consisting of multiple blockchain nodes, the opcode sequence and the mutated opcode sequence are executed sequentially to obtain corresponding execution results, and the risks existing in the blockchain system are determined based on the obtained execution results.

[0117] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the above-described storage medium embodiment is basically similar to the method embodiment, so the description is relatively simple; relevant parts can be referred to the description of the method embodiment.

[0118] This specification provides a storage medium that acquires transaction information and an opcode sequence for a transaction invoked via a smart contract. Then, based on the transaction information, the opcode sequence can be run through a blockchain client in a blockchain system, and a first code coverage rate of the opcode sequence run by the blockchain client is calculated. Subsequently, the opcode sequence can be mutated to obtain a mutated opcode sequence that meets preset target mutation conditions. The change in the number of stack elements corresponding to the mutated opcode sequence satisfies a preset first sub-condition, and the code coverage rate of the mutated opcode sequence run by the blockchain client satisfies a preset second sub-condition between the first code coverage rate and the first code coverage rate. Finally, the opcode sequence and the first code coverage rate can be executed sequentially in a local blockchain network composed of multiple blockchain nodes. The mutated opcode sequences yield corresponding execution results, and risks within the blockchain system are identified based on these results. This automated blockchain state generation automatically and efficiently identifies code defects in the blockchain client's processing. Furthermore, during blockchain state generation, an initial transaction dataset is constructed based on collected transactions from the blockchain system. A stack-element-aware mutation algorithm is proposed to efficiently and legally generate multiple blockchain transactions. The randomly mutated transactions and opcode sequences are published to the local blockchain network, and the blockchain state is tracked and recorded, thus constructing diverse blockchain states. This allows for rapid and effective detection of risks such as code defects in the blockchain client, improving the efficiency of risk detection for the blockchain client.

[0119] Furthermore, based on the above Figures 1 to 8 This specification also provides one or more embodiments of a computer program product, including a computer program, which, when executed by a processor, can perform the following processes: Obtain the transaction information of the transaction invoked through the smart contract and the opcode sequence of the transaction execution; Based on the transaction information of the transaction, the opcode sequence is run through the blockchain client in the blockchain system, and the first code coverage of the blockchain client running the opcode sequence is calculated; The opcode sequence is mutated to obtain a mutated opcode sequence that meets the preset target mutation conditions. The change in the number of stack elements corresponding to the mutated opcode sequence meets the preset first sub-condition, and the code coverage of the mutated opcode sequence run by the blockchain client meets the preset second sub-condition between the first code coverage and the code coverage. In a local blockchain network consisting of multiple blockchain nodes, the opcode sequence and the mutated opcode sequence are executed sequentially to obtain corresponding execution results, and the risks existing in the blockchain system are determined based on the obtained execution results.

[0120] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the above-described embodiment of a computer program product is relatively simple in description because it is fundamentally similar to the method embodiment; relevant parts can be referred to the description of the method embodiment.

[0121] This specification provides a computer program product that acquires transaction information and an opcode sequence for a transaction invoked via a smart contract. Then, based on the transaction information, the opcode sequence is run through a blockchain client in a blockchain system, and a first code coverage rate is calculated. Subsequently, the opcode sequence is mutated to obtain a mutated opcode sequence that meets preset target mutation conditions. The change in the number of stack elements corresponding to the mutated opcode sequence satisfies a preset first sub-condition, and the code coverage rate of the mutated opcode sequence run through the blockchain client satisfies a preset second sub-condition compared to the first code coverage rate. Finally, the opcode sequence can be executed sequentially in a local blockchain network composed of multiple blockchain nodes. The sequence of columns and mutated opcodes are used to obtain corresponding execution results, and the risks existing in the blockchain system are determined based on the obtained execution results. In this way, by automating the generation of blockchain state, code defects in the blockchain client processing process can be automatically and efficiently identified. Moreover, in the process of generating blockchain state, an initial transaction dataset is constructed based on the transactions collected in the blockchain system. By proposing a stack element-aware mutation algorithm, multiple blockchain transactions are generated efficiently and legally. The transactions and opcode sequences obtained by random mutation are published to the local blockchain network, and the blockchain state is tracked and recorded, thereby constructing diverse blockchain states. This allows for the rapid and effective detection of risks such as code defects in the blockchain client, improving the risk detection efficiency of the blockchain client.

[0122] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than those shown in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are possible or may be advantageous. Moreover, although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is merely one possible execution order among many steps and does not represent the only execution order. Therefore, when method steps are involved in the claims, adjustments to the order of those steps, or parallelism between steps, are also within the scope of protection of the claims.

[0123] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0124] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0125] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0126] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing one or more embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0127] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0128] The embodiments described herein are illustrated with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0129] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0130] These computer program instructions may also be loaded onto a computer or other programmable device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0131] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0132] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0133] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0134] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical or equivalent elements in the process, method, article, or apparatus that includes said element. Furthermore, "a," "an," and "the" are not specifically singular and may include plural forms. Ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish objects. For example, "first server" and "second server" usually refer to two servers, described as "first server" and "second server" to differentiate them; however, sometimes these two servers may be the same server. Moreover, in this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can be indirect receiving and sending (i.e., receiving and sending indirectly through one or more entities). Similarly, in this specification, unless otherwise stated, the relationships between structures can be direct or indirect.

[0135] Furthermore, the specific terms used in this specification to describe embodiments, such as "an embodiment," "one embodiment," or "some embodiments," refer to a particular feature, structure, or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that "an embodiment," "one embodiment," or "an alternative embodiment" mentioned twice or more in different locations in this specification do not necessarily refer to the same embodiment. Moreover, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples, without contradiction.

[0136] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0137] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0138] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0139] The above description is merely an embodiment of this specification and is not intended to limit this document. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims in this document.

Claims

1. A risk detection method for a blockchain system, the method comprising: Obtain the transaction information of the transaction invoked through the smart contract and the opcode sequence of the transaction execution; Based on the transaction information of the transaction, the opcode sequence is run through the blockchain client in the blockchain system, and the first code coverage of the blockchain client running the opcode sequence is calculated; The opcode sequence is mutated to obtain a mutated opcode sequence that meets the preset target mutation conditions. The change in the number of stack elements corresponding to the mutated opcode sequence meets the preset first sub-condition, and the code coverage of the mutated opcode sequence run by the blockchain client meets the preset second sub-condition between the first code coverage and the code coverage. In a local blockchain network consisting of multiple blockchain nodes, the opcode sequence and the mutated opcode sequence are executed sequentially to obtain corresponding execution results, and the risks existing in the blockchain system are determined based on the obtained execution results.

2. The method according to claim 1, wherein performing mutation processing on the opcode sequence to obtain a mutated opcode sequence that satisfies a preset target mutation condition includes: Randomly delete a portion of the opcodes from the opcode sequence to obtain the opcode sequence after deletion; Obtain the opcode sequence to be inserted, insert the opcode sequence to be inserted into the opcode sequence after deletion, and obtain the first opcode sequence. The change in the number of stack elements corresponding to the first opcode sequence satisfies the preset first sub-condition. Based on the transaction information of the transaction, the first opcode sequence is run through the blockchain client to calculate the corresponding second code coverage. If the second code coverage is not less than the first code coverage, then the first opcode sequence is used as the mutated opcode sequence that satisfies the preset target mutation condition.

3. The method according to claim 2, wherein obtaining the opcode sequence to be inserted and inserting the opcode sequence to be inserted into the deleted opcode sequence to obtain the first opcode sequence comprises: Retrieve information on the change in the number of stack elements corresponding to each opcode in the deleted opcode; Based on the information on the change in the number of stack elements corresponding to each opcode in the deleted opcode, determine the information on the change in the number of stack elements corresponding to the deleted opcode. Generate an empty opcode sequence, randomly select one or more opcodes from a preset opcode set, and add the randomly selected opcodes to the empty opcode sequence to obtain the initial opcode sequence to be inserted; Obtain the information on the change in the number of stack elements corresponding to each opcode in the initial opcode sequence to be inserted; Based on the information on the change in the number of stack elements corresponding to each opcode in the initial opcode sequence to be inserted, determine the information on the change in the number of stack elements corresponding to the initial opcode sequence to be inserted. Based on the stack element change information corresponding to the deleted opcode and the stack element change information corresponding to the initial opcode sequence to be inserted, it is determined whether the stack element change corresponding to the second opcode sequence obtained after inserting the initial opcode sequence to be inserted into the deleted opcode sequence satisfies the preset first sub-condition. If so, the initial opcode sequence to be inserted is used as the opcode sequence to be inserted, and the opcode sequence to be inserted is inserted into the deleted opcode sequence to obtain the first opcode sequence.

4. The method according to claim 3, wherein determining whether the change in the number of stack elements corresponding to the second opcode sequence obtained after inserting the initial opcode sequence into the deleted opcode sequence satisfies a preset first sub-condition based on the change in the number of stack elements corresponding to the deleted partial opcode and the change in the number of stack elements corresponding to the initial opcode sequence to be inserted, includes: Based on the stack element number change information corresponding to the deleted partial opcode and the stack element number change information corresponding to the initial opcode sequence to be inserted, the stack element number change information corresponding to the second opcode sequence is determined. If the stack element quantity change information corresponding to the second opcode sequence indicates that the stack element quantity has not changed, then it is determined that the stack element quantity change corresponding to the second opcode sequence satisfies the preset first sub-condition.

5. The method according to claim 4, further comprising: If the stack element count change information corresponding to the second opcode sequence indicates that the stack element count change is not 0, then the process of randomly selecting one or more opcodes from the preset opcode set, adding the randomly selected opcodes to the empty opcode sequence and subsequent processing is repeated until the stack element count change information corresponding to the opcode sequence obtained after inserting the initial opcode sequence to be inserted into the deleted opcode sequence indicates that the stack element count has not changed, thus obtaining the opcode sequence to be inserted.

6. The method according to claim 2, further comprising: If the second code coverage is less than the first code coverage, the random deletion of some opcodes from the opcode sequence and its subsequent processing are repeated until the code coverage of the opcode sequence corresponding to the change in the number of stack elements satisfies the preset first sub-condition is not less than the first code coverage or the number of repeated executions reaches the preset number, and the mutated opcode sequence that satisfies the preset target mutation condition is determined.

7. The method according to claim 1, wherein executing the opcode sequence and the mutated opcode sequence sequentially in a local blockchain network composed of multiple blockchain nodes to obtain corresponding execution results includes: An opcode sequence is selected from the opcode sequence and the modified opcode sequence. The selected opcode sequence is used as the data field of the transaction. The receiving address of the transaction is set to address 0. The transaction is then published to the local blockchain network to trigger the local blockchain system corresponding to the local blockchain network to execute the opcode sequence in the data field of the transaction. The system records the blockchain state change information generated in the opcode sequence in the data field of the transaction executed by the local blockchain system, and determines the execution result based on the recorded blockchain state change information. The blockchain state change information includes one or more of the following: the hash value of the transaction sent, the remaining resource information of the transaction sender, the nonce value of the transaction sender, and the storage state change information of the transaction sender and receiver.

8. The method according to claim 7, further comprising: Obtain the Remote Procedure Call (RPC) interface provided by the blockchain client in the local blockchain network; For any RPC interface, a corresponding RPC request template is constructed. The RPC request template includes an RPC identifier and an RPC parameter type. The RPC parameter type includes blockchain state-related parameter types and numerical types. The determination of risks existing in the blockchain system based on the obtained execution results includes: Select an RPC interface from the RPC interfaces provided by the blockchain client, and generate corresponding RPC parameters based on the RPC parameter types in the RPC request template corresponding to the selected RPC interface and the recorded blockchain state change information; Based on the generated RPC parameters, a corresponding RPC request is generated and sent to the blockchain node in the local blockchain network. The RPC request is used to call the blockchain node to query the execution result. The system receives the return value corresponding to the RPC request sent by the blockchain node, and determines the risks existing in the blockchain system based on the received return value.

9. The method according to claim 8, wherein determining the risks present in the blockchain system based on the received return value includes: If different blockchain nodes return different values ​​for the same RPC request, then the blockchain client in the blockchain system is considered to be at risk. The method further includes: Generate and output a verification report on the risks posed by the blockchain client in the blockchain system.

10. A risk detection device for a blockchain system, the device comprising: The data acquisition module acquires transaction information and the opcode sequence of the transaction executed through the smart contract. The calculation module, based on the transaction information of the transaction, runs the opcode sequence through the blockchain client in the blockchain system, and calculates the first code coverage of the blockchain client running the opcode sequence; The mutation module performs mutation processing on the opcode sequence to obtain a mutated opcode sequence that meets the preset target mutation conditions. The change in the number of stack elements corresponding to the mutated opcode sequence meets the preset first sub-condition, and the code coverage of the mutated opcode sequence run by the blockchain client meets the preset second sub-condition between the first code coverage and the first code coverage. The risk detection module executes the opcode sequence and the mutated opcode sequence sequentially in a local blockchain network composed of multiple blockchain nodes, obtains the corresponding execution results, and determines the risks existing in the blockchain system based on the obtained execution results.

11. A risk detection device for a blockchain system, the risk detection device for the blockchain system comprising: processor; as well as A memory configured to store computer-executable instructions, which, when executed, cause the processor to: Obtain the transaction information of the transaction invoked through the smart contract and the opcode sequence of the transaction execution; Based on the transaction information of the transaction, the opcode sequence is run through the blockchain client in the blockchain system, and the first code coverage of the blockchain client running the opcode sequence is calculated; The opcode sequence is mutated to obtain a mutated opcode sequence that meets the preset target mutation conditions. The change in the number of stack elements corresponding to the mutated opcode sequence meets the preset first sub-condition, and the code coverage of the mutated opcode sequence run by the blockchain client meets the preset second sub-condition between the first code coverage and the code coverage. In a local blockchain network consisting of multiple blockchain nodes, the opcode sequence and the mutated opcode sequence are executed sequentially to obtain corresponding execution results, and the risks existing in the blockchain system are determined based on the obtained execution results.

Images