A Bytecode Instrumentation Method for Monitoring-Oriented Blockchain Smart Contracts

Abstract

A blockchain smart contract bytecode instrumentation method for monitoring. The compilation command processing unit parses the smart contract and compilation command input by the smart contract monitor, and sends the smart contract and instrumentation parameters to the contract parser and instrumentation engine respectively. The contract parser performs contract analysis on the smart contract. The instrumentation engine receives the instrumentation parameters, the semantic information table and the abstract syntax tree output by the contract parser to perform instrumentation operations. The bytecode generator extracts the corresponding instructions and data from the intermediate representation after contract instrumentation to obtain the final instrumented bytecode and application programming interface. Then it is deployed to the smart contract running environment. By starting a series of components such as the call command processing unit, bytecode parser, monitoring engine, and execution engine, the execution of the instrumented opcode is completed, and the monitoring results are obtained from it.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and particularly to a bytecode instrumentation method for blockchain smart contracts for monitoring. Background Art

[0002] Through providing a distributed management, secure and transparent operation mode, blockchain technology is expected to reshape the working modes of traditional industries such as finance, healthcare, logistics, and supply chain management, and gradually become an essential part of important fields for future development. Smart contract technology and blockchain are natural allies, which can automatically execute predetermined logic based on trust, reduce human intervention and fraud risks, and improve execution efficiency. Currently, the applications of smart contracts have extended to multiple fields such as insurance and e-commerce, which helps to promote the development of a trustworthy economic model.

[0003] Although smart contracts have played an important role in the development of distributed applications, they also face some problems, mainly including the following two aspects: (1) The design and implementation complexity of smart contracts is relatively high. Their writing requires certain technical knowledge and experience. Improper writing is likely to result in logical errors or unconsidered boundary exception situations, which may lead to unexpected behaviors and asset losses. For example, the famous "The DAO attack" was caused by a vulnerability in a smart contract, resulting in the theft of a large amount of funds; (2) The execution efficiency of smart contracts is also an issue that needs to be considered. Complex contract calculations may lead to execution delays, affecting the application scope of the system and user experience. Therefore, improving the security and efficiency of smart contracts is an important factor in ensuring the healthy development of the blockchain ecosystem.

[0004] Technical methods for improving the security and efficiency of smart contracts are mainly divided into two categories: One category is to use static analysis tools (such as Slither and SmartCheck, etc.) to check the contracts before deploying the smart contracts onto the blockchain to reduce vulnerabilities. However, this method has problems such as limited coverage and false positives, and cannot reflect the real situation at runtime; The other category is to monitor and track the actual runtime state of smart contracts to understand the execution behavior of the contracts, and potential problems existing in the contract logic can be analyzed. Compared with the static analysis method, it has a higher coverage rate and can identify potential problems at runtime. The bytecode instrumentation method studied in the present invention is used to achieve the monitoring goal of smart contracts. For blockchain and smart contracts, monitoring technology can effectively determine the correctness of the contract execution logic and the usage of resources, and can also help users discover risks such as security vulnerabilities and permission issues in a timely manner, reduce common security problems such as re-entrancy attacks and overflow vulnerabilities, and at the same time, it also helps users understand the contract execution behavior and improve the performance and efficiency of the contracts.

[0005] Instrumentation technology is an effective way to implement runtime monitoring of applications. Specifically, it refers to a method of inserting monitoring modules or additional instructions at specific locations in the program to collect information for analysis and optimization. It is particularly important in the process of software analysis and testing, and can help developers and users record program execution, analyze performance, and debug faults. Existing more mature languages ​​(such as Java and C, etc.) have used instrumentation technology for program monitoring and optimization. For example, the instrumentation package provided by the Java standard library allows Java bytecode to be instrumented at runtime. The proxy class modifies the bytecode when the class is loaded, inserts a monitoring module into the class method, and is used for logging, performance monitoring, and security checks. The JVM Profiler tool uses the underlying instrumentation technology to analyze Java applications, and can monitor memory usage, CPU occupancy, thread status, etc. The GCC compiler provides a function instrumentation option that can automatically insert callback functions at the entry and exit of the function to help monitor function calls, parameter passing, performance analysis, etc., and is widely used for system-level performance debugging.

[0006] For blockchain smart contracts, plugging technology is equally important. It is of great significance in strengthening the security and efficiency of smart contracts. It is an important means to ensure the stable operation of smart contract systems and reduce potential losses. At present, there are plugging methods for smart contracts based on source code level. This method will increase the complexity of the contract, affect the readability of the application, and has a strong dependence on the source code of the smart contract. The plugging method based on bytecode has strong flexibility. However, after the smart contract is compiled into bytecode, the original hierarchical relationship will be disrupted, and it is difficult to determine the exact plugging point. In addition, the different focus points of variable tracking and function execution monitoring will also bring challenges to the plugging method. The present invention designs a monitoring-oriented blockchain smart contract bytecode plugging method, which realizes fine-grained tracking of state variables and accurate recording of function call relationships for different monitoring needs, meets a variety of monitoring scenarios, and promotes the development of smart contract engineering optimization technology. Summary of the invention

[0007] A monitoring-oriented blockchain smart contract bytecode instrumentation method, characterized in that the following operations are performed in a smart contract compiler, including:

[0008] The compilation command processing unit parses the smart contract and compilation command input by the smart contract monitoring personnel, the command includes the plugging parameter, the monitoring personnel selects different plugging levels and target plugging variables or target plugging functions according to the plugging parameters, and then sends the smart contract and plugging parameters to the contract parser and the plugging engine respectively;

[0009] The contract parser performs lexical analysis, syntax analysis, instrumentation parameter analysis, semantic analysis and preprocessing on the smart contract;

[0010] Store the newly added instrumentation instructions in the instrumentation instruction table, where the instrumentation instructions include instrumentation instructions for state variable monitoring and instrumentation instructions for function monitoring;

[0011] Save the original default operation instructions provided by the smart contract compiler in the default instruction library;

[0012] The instrumentation engine receives the instrumentation parameters output by the compilation command processing unit and the semantic information table and abstract syntax tree output by the contract parser, and generates the intermediate representation on this basis;

[0013] The bytecode generator extracts the corresponding instructions and data from the intermediate representation after contract instrumentation to obtain the instrumented bytecode and application programming interface.

[0014] Preferably, perform the following operations in the smart contract running environment, including:

[0015] The call command processing unit parses the call command input by the smart contract monitor and the instrumented bytecode. The call command contains monitoring parameters indicating the information that the user wants to monitor, including the historical change situation of state variables or the execution time of functions;

[0016] The bytecode parser converts the input bytecode into the corresponding operation code, the default operation instructions into the default operation code, and the newly added instrumentation instructions of the method into the corresponding instrumentation operation code;

[0017] Store the monitoring function modules corresponding to the instrumentation operation codes in the monitoring operation library, where the monitoring function modules include state variable monitoring function modules and function monitoring function modules;

[0018] The monitoring engine receives the monitoring parameters output by the call command processing unit and the operation code output by the bytecode parser to determine the specific monitoring logic, including: a. Analyze the monitoring requirements to determine the target monitoring information; b. Find the corresponding monitoring function module from the monitoring operation library according to the monitoring information and the instrumentation operation code and associate them;

[0019] The execution engine executes the operation code with additional monitoring functions in the smart contract running environment and outputs the monitoring results.

[0020] Preferably, the contract parser performs lexical analysis, syntax analysis, instrumentation parameter analysis, semantic analysis and preprocessing on the smart contract, including:

[0021] a. Lexical analysis: The smart contract is passed into the contract parser in the form of a character stream. After lexical analysis, the character sequence is converted into the required tokens to generate a token stream;

[0022] b. Syntax analysis: The token stream constructs an abstract syntax tree through syntax analysis, representing the syntax structure of the contract;

[0023] c. Analysis of instrumentation parameters: Analyze the input instrumentation parameters to check whether there are errors in the instrumentation parameters input by the monitoring personnel;

[0024] d. Semantic analysis and preprocessing: The abstract syntax tree obtains the semantic information table of the smart contract through semantic analysis. The semantic information table includes type information, scope information, and access control information. At the same time, preprocessing work is carried out to prepare for subsequent instrumentation operations.

[0025] Preferably, the intermediate representation includes instrumentation instructions, and the generation process of the intermediate representation includes two steps:

[0026] a. Classification of instrumentation requirements: Determine the instrumentation category according to the instrumentation parameters, that is, determine whether it is instrumentation for monitoring state variables or instrumentation for monitoring functions;

[0027] b. Instrumentation processing operation: Execute the instrumentation processing operation to generate an intermediate representation containing instrumentation instructions, and perform the instrumentation processing operation for different categories.

[0028] Preferably, under the condition of monitoring state variables,

[0029] The syntax analysis includes three steps: a) Construct an abstract syntax tree according to the token stream; b) Establish a contract variable table Map1_1; c) Record the information related to state variables in the smart contract in the contract variable table, and the record format is "contractname:variable1,…,variablen", where "contractname" represents the name of the smart contract, and "variable1,…,variablen" represents the names of state variables in the smart contract;

[0030] The instrumentation parameter analysis includes three steps: a) Establish an instrumentation information table Map1_2; b) Obtain the contract name and state variable names of the target instrumentation according to the incoming instrumentation parameter information, and record them in Map1_2 in the form of "d_contractname:d_variable1,…,d_variablen", where "d_contractname" represents the name of the smart contract, and "d_variable1,…,d_variablen" represents the names of state variables; c) Perform parameter rationality check. First, check whether the contract name in Map1_2 is in the record of Map1_1, that is, check whether the smart contract to be instrumented exists. If it exists, then check whether the variables in Map1_2 are in the variable table corresponding to the target contract in Map1_1, that is, check whether the variables to be instrumented exist;

[0031] The semantic analysis and preprocessing include three steps: a) Initialize the contract context, during which the variables in the smart contract are traversed; b) Establish a variable status table Map1_3; c) Store the target instrumented variables and variable status. First, it is judged whether the variable is in Map1_2, that is, whether the variable is a target instrumented variable. If it is a target instrumented variable, the variable is stored in Map1_3 in the form of "m_variable:statevalue", where "m_variable" represents the name of the state variable and "statevalue" represents the status value of the state variable, with the initial value of "0". When processed in the instrumentation engine later, the variable status value will be changed.

[0032] Preferably, the instrumentation requirement classification includes: judging the selected instrumentation category as the instrumentation for state variable monitoring according to the incoming instrumentation parameters;

[0033] The instrumentation processing operation includes: The instrumentation processing for state variable monitoring includes a declaration module and a function module. Each part is divided into three steps: inspection, inserting default instructions, and inserting instrumentation instructions. In the inspection stage, the declaration module needs to check whether the variable is in Map1_3 and whether it is assigned a value after declaration; the function module needs to check whether the statement is an assignment statement and whether the variable is in Map1_3. In the stage of inserting default instructions, instructions are retrieved from the default library to generate a logic module. When inserting instrumentation instructions, the instrumentation instructions are selected according to the variable status value, inserted in front of the statement, and updated to "1" when the variable status value is "0", and not updated when the status value is "1";

[0034] When selecting the instrumentation instructions according to the variable status value, if the variable status value is "0", select the variable monitoring instruction 1; if the variable status value is "1", select the variable monitoring instruction 2;

[0035] The operands of the variable monitoring instruction 1 include the variable name, variable type, and offset, and the operands of the variable monitoring instruction 2 only include the variable name.

[0036] Preferably, under the condition of function monitoring,

[0037] The syntax analysis includes three steps: a) constructing an abstract syntax tree based on the token stream; b) establishing a contract function table Map2_1; c) recording information related to functions in the smart contract in the contract function table in the format of "contractname:functionname,functionpointer", where "contractname" represents the smart contract name, "functionname" represents the function name in the smart contract, and "functionpointer" represents the pointer to the function definition. The pointer is the address of the function, and relevant information about the function definition, including the names of the input parameters, return value names, keywords, and function body information, can be obtained according to the pointer.

[0038] The stubbing parameter analysis includes three steps: a) establishing a stubbing information table Map2_2; b) obtaining the contract name and function name of the target stubbing according to the incoming stubbing parameters and recording them in the storage space Map2_2 in the form of "d_contractname:d_functionname1,…,d_functionnamen", where "d_contractname" represents the name of the smart contract and "d_functionname1,…,d_functionnamen" represent the function names; c) performing parameter rationality checks. First, check whether the contract name in Map2_2 is in the records of Map2_1, that is, check whether the smart contract to be stubbed exists. If it exists, then check whether the function in Map2_2 is the function name corresponding to the target contract in Map2_1, that is, determine whether the function to be stubbed exists.

[0039] The semantic analysis and preprocessing include three steps: a) initializing the contract context, and traversing the functions in the smart contract during this process; b) establishing a function call table Map2_3; c) storing the function to be stubbed and the functions it calls in the form of "d_functionname:d_functionname1_1,…d_functionname1_n". If no other functions are called, it is directly written as "d_functionname", and multiple target functions are separated by parentheses and commas.

[0040] Preferably, the stubbing requirement classification includes: judging that the selected stubbing category is function-oriented monitoring stubbing according to the incoming stubbing parameters.

[0041] The stubbing process operation includes: The stubbing process for function monitoring includes a declaration module and a function module. Before function stubbing, it is determined whether the function is an external function or an internal function. The declaration module retrieves default instructions to generate a default module. The function module part is further divided into a function header and a function body. In the function header part, it is checked whether the function name is in Map2_3. If it is not the target function, default instructions are retrieved to generate a default module. If it is the target function and an external function, an external function start instruction is added to generate a module with monitoring functionality. If it is the target function and an internal function, no processing is done to the function header part, and default instructions are retrieved to generate a default module. In the function body part, the function name and type are checked through Map2_3 and Map2_1. If it is an external function, an external function start instruction is inserted into the function header, and the function body part is not processed. If it is an internal function, an internal function start instruction is inserted at the beginning and an internal function end instruction is inserted at the end to generate a module with monitoring functionality. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Some specific embodiments of the present invention will be described in detail hereinafter with reference to the drawings in an exemplary but not restrictive manner. The same reference numerals in the drawings denote the same or similar components or parts. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. The objectives and features of the present invention will become more apparent in view of the following description in conjunction with the drawings, in which:

[0043] Figure 1 is a schematic flowchart of the bytecode stubbing method for blockchain smart contracts;

[0044] Figure 2 is a detailed flowchart of the operation of the bytecode stubbing method for blockchain smart contracts;

[0045] Figure 3 is a flowchart of the stubbing compilation link for state variable monitoring;

[0046] Figure 4 is a relationship diagram of the stubbing storage space for state variable monitoring;

[0047] Figure 5 is a flowchart of the stubbing compilation link for function monitoring;

[0048] Figure 6 is a relationship diagram of the stubbing storage space for function monitoring. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0049] To overcome the defects of the prior art, the present invention proposes a bytecode instrumentation method for blockchain smart contracts oriented to monitoring. According to actual requirements, the method can be further divided into a bytecode instrumentation method for blockchain smart contracts oriented to state variable monitoring and a bytecode instrumentation method for blockchain smart contracts oriented to function monitoring. The operation and implementation of the method rely on two parts: a smart contract compiler and a smart contract runtime environment, completing the full-process design of smart contracts from analysis, instrumentation, bytecode generation, deployment, operation to identification and processing of instrumentation instructions, providing a solution for accurate bytecode instrumentation for monitoring requirements.

[0050] The overall operation summary process of the bytecode instrumentation method for blockchain smart contracts oriented to monitoring proposed by the present invention is as Figure 1 shown.

[0051] The overall operation process is mainly divided into two stages: smart contract compilation and smart contract operation, relying on a smart contract compiler and a runtime environment. The smart contract compiler performs compilation command processing, contract analysis, instrumentation processing, and bytecode generation operations according to the input smart contract and compilation command, obtaining the instrumented bytecode and application programming interfaces. The instrumented bytecode and application programming interfaces will be used as the input of the smart contract runtime environment during the operation stage together with the call command. The smart contract runtime environment will perform call command processing, bytecode parsing, monitoring function invocation, and opcode execution operations, and finally obtain the monitoring results. Further, the detailed description of the operation process is as Figure 2 shown.

[0052] There are 6 key components in the smart contract compiler of the method, described as follows:

[0053] Compilation command processing unit. Parse the smart contract and compilation command input by the smart contract monitor. The command includes instrumentation parameters. The monitor can select different instrumentation levels and target instrumentation variables (or target instrumentation functions) through the instrumentation parameters, and then send the smart contract and instrumentation parameters to the contract parser and instrumentation engine respectively;

[0054] Contract parser. Perform lexical analysis, syntax analysis, instrumentation parameter analysis, semantic analysis, and preprocessing on the smart contract. The specific description is as follows: a. The smart contract is passed into the contract parser in the form of a character stream. After lexical analysis, the character sequence is converted into the required tokens, generating a token stream; b. The token stream constructs an abstract syntax tree through syntax analysis, representing the syntax structure of the contract; c. Analyze the input instrumentation parameters to check whether the instrumentation parameters input by the monitor are incorrect; d. The abstract syntax tree obtains the semantic information table of the smart contract through semantic analysis. The semantic information table contains type information, scope information, and access control information, and at the same time performs preprocessing work to prepare for subsequent instrumentation operations;

[0055] Instrumentation Instruction Table. Stores newly added instrumentation instructions, which include instrumentation instructions for state variable monitoring and instrumentation instructions for function monitoring;

[0056] Default Instruction Library. The original default operation instructions provided by the smart contract compiler;

[0057] Instrumentation Engine. Receives the instrumentation parameters output by the compilation command processing unit and the semantic information table and abstract syntax tree output by the contract parser, and generates the intermediate representation on this basis. The intermediate representation contains instrumentation instructions, and its generation process includes two steps: a. Determine the instrumentation category according to the instrumentation parameters, that is, determine whether it is instrumentation for state variable monitoring or instrumentation for function monitoring; b. Perform the instrumentation processing operation to generate the intermediate representation containing the instrumentation instructions. The instrumentation processing operation is also carried out for different categories;

[0058] Bytecode Generator. Extracts the corresponding instructions and data from the intermediate representation after contract instrumentation to obtain the final output, that is, the instrumented bytecode and application programming interface. At the same time, bytecode optimization work can be optionally completed in the bytecode generator;

[0059] The key components in the smart contract running environment of the method also include 5, which are described as follows:

[0060] Call Command Processing Unit. Parses the call command input by the smart contract monitor and the instrumented bytecode. The call command contains monitoring parameters, indicating the information that the user wants to monitor, such as the historical changes of state variables or the execution time of functions;

[0061] Bytecode Parser. Converts the input bytecode into the corresponding operation code, converts the default operation instructions into the default operation code, and converts the newly added instrumentation instructions of the method into the corresponding instrumentation operation code;

[0062] Monitoring Operation Library. Stores the monitoring function modules corresponding to the instrumentation operation codes, and the monitoring function modules include state variable monitoring function modules and function monitoring function modules;

[0063] Monitoring Engine. Receives the monitoring parameters output by the call command processing unit and the operation code output by the bytecode parser to determine the specific monitoring logic. The specific operation is: a. Analyze the monitoring requirements and determine the target monitoring information; b. Find the corresponding monitoring function module from the monitoring operation library according to the monitoring information and the instrumentation operation code and associate them;

[0064] Execution Engine. The smart contract running environment executes the operation codes with additional monitoring functions and outputs the monitoring results.

[0065] Based on the above components, the operation process of the blockchain smart contract bytecode instrumentation method for monitoring proposed by the present invention is described as follows:

[0066] As Figure 2 shown in ① of [], the smart contract monitor first starts the compilation operation, inputs the smart contract and the compilation command, and after being processed and parsed by the compilation command processing unit, the corresponding instrumentation parameters and the smart contract (character stream) are obtained. Furthermore, as Figure 2 shown in ③ of [], the smart contract is parsed and preprocessed by the contract parser to obtain the semantic information table and the abstract syntax tree. As shown in ② and ④ of the figure, the instrumentation engine performs instrumentation according to the instrumentation parameter information, the semantic information table, the abstract syntax tree, the instrumentation instruction table, and the default instruction library, generates the intermediate representation after contract instrumentation (including instrumentation information), and finally outputs the instrumented bytecode and the application programming interface through the bytecode generator, as shown in Figure 2 ⑤ and ⑥ of. The smart contract is deployed according to the instrumented bytecode and the application programming interface. As Figure 2 shown in ⑦ of [], the smart contract monitor can start the contract call operation, pass in the call command to call the deployed smart contract, and after being parsed and processed by the call command processing unit, the monitoring parameters and the bytecode corresponding to the smart contract are obtained. As Figure 2 shown in ⑨ of [], the bytecode will be converted into the corresponding operation code in the bytecode parser. The monitoring engine then generates the monitoring operation code containing the monitoring logic according to the monitoring parameters, the operation code, and the monitoring function modules in the corresponding monitoring library, and is executed by the execution engine to generate the final monitoring result, as shown in Figure 2 ⑩ - .

[0067] 1. Blockchain Smart Contract Bytecode Instrumentation Method for State Variable Monitoring

[0068] The implementation of the blockchain smart contract bytecode instrumentation method for state variable monitoring depends on two links: compilation and operation, which are located in the compiler and the operation environment respectively, and realizes the instrumentation of specified state variables of the smart contract so as to monitor the change situation in the operation environment. The difficulty lies in how to record the data values of state variables after each assignment statement, that is, to monitor the dynamic changes of state variables.

[0069] The specific process of the compilation link is as Figure 3 shown and described as follows:

[0070] Input. As shown in ① of the figure, the smart contract monitor starts the compilation operation, inputs the smart contract file and the compilation command containing the instrumentation parameters. The input is processed and parsed by the compilation command processing unit and separated and generated into the smart contract (character stream) and the instrumentation parameters. As shown in ② of the figure, the instrumentation parameters are passed into the instrumentation engine. As shown in ③ of the figure, the smart contract (character stream) and the instrumentation parameters are passed into the contract parser;

[0071] The working process of the contract parser is described as follows:

[0072] a. Lexical analysis. Convert the smart contract in the form of a character stream into a corresponding token stream;

[0073] b. Syntax analysis. Syntax analysis includes three steps: a) Construct an abstract syntax tree based on the token stream; b) Establish a contract variable table Map1_1; c) Record the information related to state variables in the smart contract in the contract variable table, and the recording format is "contractname:variable1,…,variablen", where "contractname" represents the name of the smart contract (considering that there may be multiple smart contracts in the input smart contract file), and "variable1,…,variablen" represents the names of the state variables in the smart contract;

[0074] c. Instrumentation parameter analysis. Instrumentation parameter analysis includes three steps: a) Establish an instrumentation information table Map1_2; b) Obtain the contract name and state variable names of the target instrumentation according to the incoming instrumentation parameter information, and record them in Map1_2 in the form of "d_contractname:d_variable1,…,d_variablen", where "d_contractname" represents the name of the smart contract, and "d_variable1,…,d_variablen" represents the names of the state variables; c) Perform parameter rationality checking. First, check whether the contract name in Map1_2 is in the record of Map1_1, that is, check whether the smart contract to be instrumented exists. If it exists, then check whether the variables in Map1_2 are in the variable table corresponding to the target contract in Map1_1. This is to avoid incorrect compilation commands input;

[0075] d. Semantic analysis and preprocessing. Semantic analysis and preprocessing include three steps: a) Initialize the contract context, and variables in the smart contract will be traversed during this process; b) Establish a variable status table Map1_3; c) Store the target instrumentation variables and variable status values (i.e., the access times of the variables). First, judge whether the variable is in Map1_2, that is, judge whether the variable is a target instrumentation variable; if it is a target instrumentation variable, then store the variable in Map1_3 in the form of "m_variable:statevalue", where "m_variable" represents the state variable name, and "statevalue" represents the status value of the state variable, and the initial value is "0". During subsequent processing in the instrumentation engine, the variable status value will be changed. After semantic analysis and preprocessing are completed, the generated semantic information table and abstract syntax tree are passed into the instrumentation engine, as shown in ④ in the figure;

[0076] The related operation descriptions of the instrumentation engine are as follows:

[0077] a. Instrumentation requirement classification. Determine the selected instrumentation category as the instrumentation for state variable monitoring based on the incoming instrumentation parameters;

[0078] b. Instrumentation processing operation. The instrumentation processing for state variable monitoring includes a declaration module and a function module. Each part is divided into three steps: inspection, inserting default instructions, and inserting instrumentation instructions. In the inspection stage, the declaration module needs to check whether the variable is in Map1_3 and whether it is assigned a value after declaration; the function module needs to check whether the statement is an assignment statement and whether the variable is in Map1_3. In the stage of inserting default instructions, instructions are retrieved from the default library to generate a logic module. When inserting instrumentation instructions, select the instrumentation instruction according to the variable status value (which is "0" when not operated), insert it in front of the statement, and update it to "1" when the variable status value is "0", and do not update when the status value is "1"; when selecting the instrumentation instruction according to the variable status value, if the variable status value is "0", select the variable monitoring instruction 1; if the variable status value is "1", select the variable monitoring instruction 2; the operands of the variable monitoring instruction 1 include the variable name, variable type, and offset, and the operands of the variable monitoring instruction 2 only include the variable name.

[0079] Specifically:

[0080] The instrumentation processing operation for state variable monitoring includes two parts: a processing declaration module and a processing function module. Each module's processing process includes three steps: inspection, inserting default instructions, and inserting instrumentation instructions. The following is a description of each step:

[0081] a) Processing Declaration Module. The processing declaration module includes three steps: Ⅰ. Check; Ⅱ. Insert Default Instruction; Ⅲ. Insert Stakeholder Instruction. The stakeholding method for state variable monitoring designed in the present invention includes two stakeholding instructions, namely variable monitoring instruction 1 and variable monitoring instruction 2, which are used to identify the first operation position of the target state variable and the non-first operation position of the target variable. The operands in variable monitoring instruction 1 include variable name, variable type, and offset (i.e., the starting position of the variable in the storage unit, which is used to support subsequent read operations). The operand in variable monitoring instruction 2 is only the variable name. By designing different stakeholding instructions, redundant information in the subsequently generated bytecode is avoided. First, the check step is carried out, which includes two operations: first, variable check, that is, to judge whether the variable involved in the currently processed declaration statement is in Map1_3; then statement check, that is, to judge whether the current statement performs an assignment operation after the variable declaration. Only when both of the above conditions are met can the currently processed declaration statement be considered an operation statement for the target variable, and then the stakeholding instruction will be inserted. Then, the default instruction is retrieved to complete the basic logical operation. Otherwise, the default instruction insertion step is directly carried out, which includes two operations: i. Retrieve the default instruction from the default instruction library; ii. Generate the default module according to the default instruction. When inserting the stakeholding instruction, three operations need to be carried out: i. Check whether the operation statement is the first operation for the target variable, that is, check the state value corresponding to the variable in Map1_3; ii. Retrieve the corresponding stakeholding instruction according to the variable state value. If the state value is "0", it means it is the first operation, and variable monitoring instruction 1 needs to be retrieved. If the state value is "1", it means that there has already been a statement operating on the target variable, and variable monitoring instruction 2 needs to be retrieved; iii. First, generate different stakeholding modules according to different stakeholding instructions, place variable monitoring instruction 1 (or 2) at the front of the currently monitored variable operation statement, and then modify the variable state value. If the variable state value is "0", it is modified to "1", indicating that the variable has been operated on. If the variable state value is already "1", no modification is made;

[0082] b) Processing function module. The processing function module also includes three steps: Ⅰ. Check; Ⅱ. Insert default instructions; Ⅲ. Insert instrumentation instructions. The specific execution content of the steps of inserting default instructions and inserting instrumentation instructions is the same as that of the processing declaration module, but the specific execution content of the check step is different from that of the processing declaration module. In the check step, first perform a statement check to determine whether the current position is a statement expression. If so, then determine whether the statement expression is an assignment statement. After satisfying the above two conditions, perform a variable check, that is, check whether the variables involved in the assignment statement are in Map1_3. Similarly, only those that satisfy both the statement check and the variable check can be considered as operation statements for the target variable. Otherwise, directly execute the step of inserting default instructions (retrieve default instructions and generate default logical operations). When inserting instrumentation instructions, first check the status value of the variable. If it is "0", it means that the variable has not been operated on, and insert variable monitoring instruction 1 at the front of the current statement and change the status value to "1". If the status value is "1", it means that the variable has been operated on, and only insert variable monitoring instruction 2 at the front of the current statement;

[0083] After the above processing, an intermediate representation after contract instrumentation is generated. After being transformed by the bytecode generator, instrumented bytecode and application programming interfaces are generated, as shown in ⑤ - ⑥ in the figure.

[0084] Three new storage spaces are involved in the above process: the contract variable table Map1_1, the instrumentation information table Map1_2, and the variable status table Map1_3. Map1_1 records all state variables in all smart contracts; Map1_2 records the target instrumentation variables in all smart contracts to be instrumented; Map1_3 records the target instrumentation variables and variable status values in the currently processed smart contract. The relationship between the three storage spaces is as Figure 4 shown.

[0085] After deploying the instrumented bytecode and the corresponding application programming interface to the smart contract runtime environment, the contract monitor will initiate a contract call operation. The instrumented bytecode and the call command containing the monitoring parameters will be parsed by the call command processing unit into bytecode and monitoring parameters. Subsequently, the bytecode will be parsed into opcodes by the bytecode parser. The monitoring engine will read the monitoring parameters and opcodes. The opcode corresponding to variable monitoring instruction 1 is variable monitoring opcode 1, and the opcode corresponding to variable monitoring instruction 2 is variable monitoring opcode 2. When the monitoring engine recognizes a variable monitoring opcode, it will invoke the corresponding monitoring function module, and then send the monitoring opcode with the monitoring function attached to the execution engine. The execution engine will sequentially execute the opcodes. If it encounters variable monitoring opcode 1, it will create a variable history information record table, first record the operands following variable monitoring opcode 1, i.e., the variable name, variable type, and offset. Then, based on the offset and the storage unit number of the variable output by the runtime environment, it will determine the specific storage location of the variable, read the value therein, and store it in the variable history information record table. If it encounters variable monitoring opcode 2, it will first read the operand following the opcode, i.e., the variable name, and query whether there is already a corresponding variable history information record table. If it exists, based on the offset recorded in the table and the variable storage unit number output by the runtime environment, it will determine the specific storage location of the variable, read the value therein, and store it in the corresponding variable history information record table. In this way, the monitoring of state variables can be completed.

[0086] 2. Blockchain Smart Contract Bytecode Instrumentation Method for Function Monitoring

[0087] The implementation of the blockchain smart contract bytecode instrumentation method for function monitoring depends on two links: compilation and runtime, which are located in the compiler and runtime environment respectively, to achieve the instrumentation of specified functions in the smart contract so as to monitor the information during function runtime in the runtime environment. The implementation difficulty lies in accurately identifying the call relationships between functions during runtime.

[0088] The specific process of the compilation link is as Figure 5 shown and described as follows:

[0089] Input. As shown in ① in the figure, the smart contract monitor initiates a compilation operation, inputting the smart contract file and the compilation command containing the instrumentation parameters. The input is parsed and processed by the compilation command processing unit and separated into a smart contract (character stream) and instrumentation parameters. As shown in ② in the figure, the instrumentation parameters are passed into the instrumentation engine. As shown in ③ in the figure, the smart contract (character stream) and instrumentation parameters are passed into the contract parser;

[0090] The working process of the contract parser is described as follows:

[0091] a. Lexical analysis. Convert the smart contract in character stream form into the corresponding token stream;

[0092] b. The syntax analysis includes three steps: a) constructing an abstract syntax tree according to the token stream; b) establishing a contract function table Map2_1; c) recording information related to functions in the smart contract in the contract function table, and the recording format is "contractname:functionname,functionpointer", where "contractname" represents the smart contract name, "functionname" represents the function name in the smart contract, and "functionpointer" represents the pointer to the function definition. The pointer is the address of the function, and relevant information about the function definition, including the input parameters, return value, keywords, and function body information of the function, can be obtained according to the pointer;

[0093] c. Instrumentation parameter analysis. The instrumentation parameter analysis includes three steps: a) establishing an instrumentation information table Map2_2; b) obtaining the contract name and function name of the target instrumentation according to the incoming instrumentation parameters, and recording them in the storage space Map2_2 in the form of "d_contractname:d_functionname1,…,d_functionnamen", where "d_contractname" represents the name of the smart contract, and "d_functionname1,…,d_functionnamen" represent the function names; c) performing parameter rationality checks. First, check whether the contract name in Map2_2 is in the records of Map2_1, that is, check whether the smart contract to be instrumented exists; if it exists, then check whether the function in Map2_2 is the function name corresponding to the target contract in Map2_1, that is, determine whether the function to be instrumented exists. This is to avoid incorrect compilation commands being input.

[0094] d. Semantic analysis and preprocessing. Semantic analysis and preprocessing include three steps: a) Initialize the contract context, during which the functions in the smart contract are traversed; b) Establish the function call table Map2_3; c) Store the functions to be instrumented and the functions they call in the form of "d_functionname:d_functionname1_1,…d_functionname1_n". If no other functions are called, it is directly written as "d_functionname", and multiple target functions are separated by parentheses and commas. For example, "(d_functionname1:d_functionname1_1,d_functionname1_2),(d_functionname2:d_functionname2_1,d_functionname2_2)" means there are two target functions d_functionname1 and d_functionname2. d_functionname1 calls functions d_functionname1_1 and d_functionname1_2, and d_functionname2 calls functions d_functionname2_1 and d_functionname2_2. At this time, traverse Map2_2 to find all the functions to be instrumented and record them in Map2_3. Traverse Map2_3 and process the functions to be instrumented. The processing method is as follows:

[0095] ① Obtain the function name and find the pointer to the function definition in Map2_1 according to the function name;

[0096] ② Find the function body according to the pointer. The function body contains the names of the called functions;

[0097] ③ Append the names of the called functions to Map2_3;

[0098] ④ Find the pointer to the function definition in Map2_1 according to the name of the called function, and repeat steps ① - ③ until there are no more function calls;

[0099] According to the above processing method, all function call relationships in the current smart contract can be found. After the semantic analysis is completed, the generated semantic information table and abstract syntax tree are passed into the instrumentation engine, as shown in ④ in the figure;

[0100] The related operations of the instrumentation engine are described as follows:

[0101] a. Instrumentation requirement classification. Determine that the selected instrumentation category is function-oriented monitoring instrumentation according to the incoming instrumentation parameters;

[0102] b. Staking processing operation. The staking processing for function monitoring includes a declaration module and a function module; it is determined whether it is an external function or an internal function before function staking, and the staking methods for the two are different. The external function exits the context at the end of the call, and the end position of the external function can be identified by the exit instruction of the default library, so it is only necessary to stake at the beginning of the function. Since the call operation and return value processing of the internal function cannot be directly captured, it is necessary to stake at the beginning and end of the function respectively. The staking instructions include the external function start instruction, the internal function start instruction, and the internal function end instruction, which are used to identify the corresponding positions.

[0103] The staking is divided into two parts: the declaration module only retrieves the default instruction to generate the default module; the function module includes the processing of the function header and the function body.

[0104] Process the function header: Check whether the function name is in Map2_3. If it is not the target function, retrieve the default instruction to generate the default module; if it is the target function and an external function, add the external function start instruction to generate a module with monitoring function. If it is the target function and an internal function, the function header part is not processed, and the default instruction is retrieved to generate the default module;

[0105] Process the function body: Check the function name and type through Map2_3 and Map2_1. If it is an external function, since the external function start instruction has been inserted at the function header, the function body part is not processed; if it is an internal function, insert the internal function start instruction at the beginning and the internal function end instruction at the end to generate a module with monitoring function.

[0106] Specifically:

[0107] Before instrumenting a function, it is necessary to determine whether the current function is an external function or an internal function. These two types of functions have their own characteristics and different instrumentation methods are applicable. If it is an external function, it is necessary to exit the current function context at the end of each call. There is a corresponding exit instruction in the default instruction library, so the end position of the function can be accurately identified during runtime, and only the beginning of the function needs to be instrumented. Internal functions are called within the contract, and the call operation cannot be captured by special instructions. Moreover, when processing the return value, it is processed through ordinary instructions in the default instruction library, and the end position of the function cannot be accurately identified during runtime. Therefore, it is necessary to instrument the beginning and the end of the function respectively. At the same time, only external functions have function headers. When the smart contract compiler processes a smart contract, it will first process the function header part and then the function body part. The instrumentation method for function monitoring designed by the present invention includes three instrumentation instructions, namely the external function start instruction, the internal function start instruction, and the internal function end instruction, which respectively identify the start position of the external function, the start position of the internal function, and the end position of the internal function. The instrumentation processing operation of the entire function includes two parts: a) the processing declaration module; b) the processing function module. Among them, the processing declaration module does not perform any processing related to instrumentation, but only retrieves the default instructions and generates the default module. The processing function module can be further divided into the processing function header module and the processing function body module. The processing process of each module includes three steps: function check, retrieving the default instructions or monitoring instructions, and generating the default function module or the function module with monitoring functions. The following will be described separately:

[0108] Ⅰ. Processing function header module. The processing function header module includes three operations. First, perform operation i for function check, that is, obtain the name of the currently processed function, query according to the function name in Map2_3. If the query result is empty, it means that the current function is not the target instrumented function, and perform operation ii to retrieve the default instructions and generate the default function module. On the contrary, it means that the current function is the target instrumented function and is an external function. Perform operation iii, call the monitoring instruction, add the external function start instruction at the beginning of the function, complete the instrumentation, and generate the function module with monitoring functions;

[0109] Ⅱ. Processing function body module. The processing function body module includes three operations. Since both external functions and internal functions have function bodies, the function check operation includes checking both the function name and the function type. First, perform operation i to obtain the name of the currently processed function. Query according to the function name in Map2_3. If the query result is empty, it means that the current function is not the target instrumented function, and perform operation ii to retrieve the default instruction and generate the corresponding default function module. Otherwise, it means that the current function is the target instrumented function, and operation i needs to be continued to judge the type of the function. According to the function name, find the corresponding pointer of the function in Map2_1, obtain the keyword of the function, and judge whether it is an external function or an internal function according to the keyword. Since the external function has been instrumented at the function header, no processing is done in the function body part. For internal functions, instrumentation needs to be performed at the start and end positions of the function processing. Perform operation iii to insert the internal function start instruction at the start of the function and insert the internal function end instruction at the end of the function, and finally generate a function module with monitoring function.

[0110] After the above processing, the intermediate representation after contract instrumentation is generated. After the bytecode generator extracts and processes the instructions, the instrumented bytecode and application programming interface are generated, as shown in ⑤ - ⑥ in the figure.

[0111] Three new storage spaces are involved in the above process: the contract function table Map2_1, the instrumentation information table Map2_2, and the function call table Map2_3. Map2_1 records all functions in all smart contracts and their defined pointers; Map2_2 records the functions in all smart contracts to be instrumented; Map2_3 records the target instrumented functions in the currently processed smart contract and the functions related to their calls. The relationship between the three storage spaces is as Figure 6 shown.

[0112] After deploying the instrumented bytecode and the corresponding application programming interface to the smart contract runtime environment, the contract monitor will initiate a contract call operation. The instrumented bytecode and the call command containing the monitoring parameters will be parsed by the call command processing unit into bytecode and monitoring parameters. Subsequently, the instructions in the bytecode are parsed into operation codes by the bytecode parser. The operation code corresponding to the external function start instruction is the external function start operation code in the monitoring instruction, the operation code corresponding to the internal function start instruction is the internal function start operation code in the monitoring instruction, the operation code corresponding to the internal function end instruction is the internal function end operation code in the monitoring instruction, and the default instruction corresponds to the default operation code. The monitoring engine will read the monitoring parameters and operation codes. When it identifies a function monitoring operation code, it will invoke the corresponding functional module (for example, to monitor the actual running time of a function, a timestamp recording function can be added to the functional module of the operation code). Then, the operation code appended with the monitoring function will be sent to the execution engine. The execution engine will sequentially execute the operation codes. If it encounters the external function start operation code, it indicates the entry of the external function here, and it will continue to process the operation codes backward. If it identifies the exit operation code in the default operation code, it indicates the exit of the external function here. Similarly, when it identifies the internal function start operation code, it indicates the entry of the internal function here, and when it identifies the internal function end operation code, it indicates the exit of the internal function here. Through these instrumented instruction operation codes and the exit operation code in the default instruction of the external function, the recording function can be called according to the monitoring parameters, thus achieving the purpose of monitoring.

[0113] The present invention supports the simultaneous execution of the blockchain smart contract bytecode instrumentation method for state variable monitoring and the blockchain smart contract bytecode instrumentation method for function monitoring, so as to complete multi-type hybrid monitoring.

[0114] Advantages of the present invention:

[0115] A blockchain smart contract bytecode instrumentation method for monitoring is proposed, which supports two requirements of state variable and function monitoring, helps to enrich the blockchain smart contract monitoring technology, so as to better understand the runtime behavior and problems of smart contracts, further improve the contract quality, and expand the application scope of blockchain technology.

[0116] In the above embodiments, all or part of the functions may be implemented by software, hardware, or a combination of software and hardware. When implemented by software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or a data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)), etc.

[0117] As described above, the above are only the specific implementation manners of the embodiments of the present application, but the protection scope of the embodiments of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the embodiments of the present application should be covered by the protection scope of the embodiments of the present application. Therefore, the protection scope of the embodiments of the present application shall be subject to the protection scope of the claims.

Claims

1. A monitoring-oriented blockchain smart contract bytecode plugging method, characterized in that: The following operations are performed in the smart contract compiler, including: The compilation command processing unit parses the smart contract and compilation command input by the smart contract monitoring personnel, the compilation command includes the instrumentation parameters, the monitoring personnel select different instrumentation levels through the instrumentation parameters, and select the target instrumentation variable or target instrumentation function through the instrumentation parameters, and then send the smart contract and instrumentation parameters to the contract parser and instrumentation engine respectively; The contract parser performs lexical analysis, syntax analysis, instrumentation parameter analysis, semantic analysis and preprocessing on the smart contract; Storing newly added plugging instructions in the plugging instruction table, wherein the plugging instructions include plugging instructions for state variable monitoring and plugging instructions for function monitoring; Save the original default operation instructions provided by the smart contract compiler in the default instruction library; The instrumentation engine receives the instrumentation parameters output by the compilation command processing unit and the semantic information table and abstract syntax tree output by the contract parser, and completes the generation of the intermediate expression on this basis; The bytecode generator extracts the corresponding instructions and data from the intermediate expression after the contract is inserted, and obtains the inserted bytecode and application program interface; Perform the following operations in the smart contract runtime environment, including: The call command processing unit parses the call command and the bytecode after the plugging input by the smart contract monitoring personnel. The call command contains monitoring parameters, which indicate the information that the user wants to monitor, including the historical changes of state variables or the execution time of functions. The bytecode parser converts the input bytecode into the corresponding operation code, the default operation instruction is converted into the default operation code, and the newly added plugging instruction of the method is converted into the corresponding plugging operation code; The monitoring function module corresponding to the plugging operation code is stored in the monitoring operation library, and the monitoring function module includes a state variable monitoring function module and a function monitoring function module; The monitoring engine receives the monitoring parameters output by the call command processing unit and the operation code output by the bytecode parser to determine the specific monitoring logic, including: a. analyzing the monitoring requirements and determining the target monitoring information; b. finding the corresponding monitoring function module from the monitoring operation library and associating it according to the target monitoring information and the plug-in operation code; The execution engine executes the opcodes of the additional monitoring functions in the smart contract running environment and outputs the monitoring results.

2. The method according to claim 1, characterized in that: The contract parser performs lexical analysis, syntax analysis, instrumentation parameter analysis, semantic analysis and preprocessing on the smart contract, including: a. Lexical analysis: The smart contract is passed into the contract parser in the form of a character stream. The lexical analysis converts the character sequence into the required tokens to generate a token stream. b. Syntax analysis: The token stream is analyzed to construct an abstract syntax tree, which represents the grammatical structure of the contract; c. Pile parameter analysis: Analyze the input pile parameters to check whether the pile parameters entered by the monitoring personnel are correct; d. Semantic analysis and preprocessing: The abstract syntax tree is semantically analyzed to obtain the semantic information table of the smart contract, which contains type information, scope information, and access control information. At the same time, preprocessing is performed to prepare for subsequent plug-in operations.

3. The method according to claim 2, characterized in that: The intermediate expression includes the instrumentation instruction, and the generation process of the intermediate expression includes two steps: a. Classification of instrumentation requirements: Determine the instrumentation category based on the instrumentation parameters, that is, determine whether it is an instrumentation for state variable monitoring or an instrumentation for function monitoring; b. Instrumentation processing operation: Execute the instrumentation processing operation, generate an intermediate expression including instrumentation instructions, and perform the instrumentation processing operation for different categories.

4. The method according to claim 3, characterized in that: Under the condition of state variable monitoring, The grammatical analysis includes three steps: a) constructing an abstract syntax tree according to the token stream; b) establishing a contract variable table Map1_1; c) recording information related to state variables in the smart contract in the contract variable table, with the recording format being "contractname: variable1,…,variablen", where "contractname" represents the name of the smart contract, and "variable1,…,variablen" represents the name of the state variable in the smart contract; The instrumentation parameter analysis includes three steps: a) establishing an instrumentation information table Map1_2; b) obtaining the contract name and state variable name of the target instrumentation according to the input instrumentation parameter information, and recording them in Map1_2 in the form of "d_contractname: d_variable1, ..., d_variablen", where "d_contractname" represents the name of the smart contract, and "d_variable1, ..., d_variablen" represents the name of the state variable; c) performing a parameter rationality check, first checking whether the contract name in Map1_2 is in the record of Map1_1, that is, checking whether the smart contract to be instrumented exists; if so, then checking whether the variables in Map1_2 are in the variable table corresponding to the target contract in Map1_1, that is, checking whether the variables to be instrumented exist; The semantic analysis and preprocessing include three steps: a) Initialize the contract context, during which the variables in the smart contract will be traversed; b) Establish a variable state table Map1_3; c) Store the target plug-in variable and variable state; First, determine whether the variable is in Map1_2, that is, determine whether the variable is the target plug-in variable. If it is the target plug-in variable, the variable is stored in Map1_3 in the form of "m_variable: statevalue", "m_variable" represents the state variable name, "statevalue" represents the state value of the state variable, and the initial value is "0". When it is processed in the plug-in engine later, the variable state value will be changed.

5. The method according to claim 4, characterized in that: The plugging requirement classification includes: judging that the plugging category is a plugging for state variable monitoring according to the input plugging parameters; The plugging operation includes: the plugging process for state variable monitoring includes two parts: a declaration module and a function module, each part is divided into three steps: checking, inserting default instructions, and inserting plugging instructions. In the checking stage, the declaration module needs to check whether the variable is in Map1_3 and whether it is assigned after the declaration; the function module needs to check whether the statement is an assignment statement and whether the variable is in Map1_3. In the default instruction stage, the instruction generation logic module is called from the default library. When inserting the plugging instruction, the plugging instruction is selected according to the variable state value, inserted in front of the statement, and updated to "1" when the variable state value is "0", and not updated when the state value is "1"; The insert instruction is selected according to the variable state value. If the variable state value is "0", variable monitoring instruction 1 is selected; if the variable state value is "1", variable monitoring instruction 2 is selected; The operand of the variable monitoring instruction 1 includes the variable name, variable type and offset, and the operand of the variable monitoring instruction 2 includes only the variable name.

6. The method according to claim 3, characterized in that: Under the condition of function-oriented monitoring, The syntax analysis includes three steps: a) constructing an abstract syntax tree according to the tag stream; b) establishing a contract function table Map2_1; c) recording information related to the function in the smart contract in the contract function table, and the recording format is "contractname: functionname, functionpointer", where "contractname" represents the name of the smart contract, "functionname" represents the function name in the smart contract, and "functionpointer" represents a pointer to the function definition. The pointer is the address of the function. According to the pointer, relevant information of the function definition can be obtained, including the function's input parameter name, return value name, keywords and function body information; The plugging parameter analysis includes three steps: a) establishing a plugging information table Map2_2; b) obtaining the contract name and function name of the target plugging according to the incoming plugging parameters, and recording them in the storage space Map2_2 in the form of "d_contractname: d_functionname1, ..., d_functionnamen", where "d_contractname" represents the name of the smart contract, and "d_functionname1, ..., d_functionnamen" represents the name of the function; c) performing a parameter rationality check, first checking whether the contract name in Map2_2 is in the record of Map2_1, that is, checking whether the smart contract to be plugged exists. If so, then checking whether the function in Map2_2 is the function name corresponding to the target contract in Map2_1, that is, judging whether the function to be plugged exists; The semantic analysis and preprocessing includes three steps: a) Initialize the contract context, during which the functions in the smart contract will be traversed; b) Create a function call table Map2_3; c) Store the function to be plugged and the function it calls in the form of "d_functionname: d_functionname1_1,... d_functionname1_n". If no other function is called, it is directly written as "d_functionname".

7. The method according to claim 6, characterized in that: The instrumentation requirement classification includes: judging that the instrumentation category is instrumentation oriented to function monitoring according to the input instrumentation parameters; The plugging operation includes: the plugging process for function monitoring includes two parts: a declaration module and a function module; before the function is plugged in, it is determined whether it is an external function or an internal function, and the declaration module calls the default instruction to generate a default module; the function module part is further divided into a function header and a function body; in the function header part, it is checked whether the function name is in Map2_3, and if it is not a target function, the default instruction is called to generate a default module; if it is a target function and an external function, an external function start instruction is added to generate a module with a monitoring function; if it is a target function and an internal function, the function header part is not processed, and the default instruction is called to generate a default module; in the function body part, the function name and type are checked through Map2_3 and Map2_1, if it is an external function, the function body part is not processed; if it is an internal function, the internal function start instruction is inserted at the beginning, and the internal function end instruction is inserted at the end to generate a module with a monitoring function.

Images