Monitoring-oriented blockchain intelligent contract byte code instrumentation method

Abstract

A monitoring-oriented blockchain smart contract byte code instrumentation method comprises the following steps: a compiling command processing unit analyzes a smart contract and a compiling command input by a smart contract monitoring person, and sends the smart contract and instrumentation parameters to a contract analyzer and an instrumentation engine respectively; performing contract analysis on the intelligent contract by a contract analyzer; an instrumentation engine receives the instrumentation parameters and the semantic information table and the abstract syntax tree output by the contract analyzer to perform instrumentation operation; and a byte code generator extracts corresponding instructions and data from the intermediate expression after contract instrumentation to obtain a final byte code and an application program interface after instrumentation. And then deploying to an intelligent contract running environment, executing the instrumentation operation code by starting a series of components of a calling command processing unit, a byte code parser, a monitoring engine and an execution engine, and obtaining a monitoring result from the instrumentation operation code.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a monitoring-oriented blockchain smart contract bytecode plugging method. Background Art

[0002] Blockchain technology is expected to reshape the working mode of traditional industries such as finance, medical care, logistics, and supply chain management by providing distributed management, security, and transparent operation methods, and gradually become an essential component of important areas of 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. At present, the application of smart contracts has expanded to many fields such as insurance and e-commerce, which will help promote the development of a trusted economic model.

[0003] Although smart contracts have played an important role in the development of distributed applications, they also face some problems, mainly in the following two aspects: (1) The design and implementation of smart contracts are relatively complex. Their writing requires certain technical knowledge and experience. Improper writing can easily lead to logical errors or unconsidered boundary anomalies, which may lead to unexpected behavior and asset losses. For example, the famous "The DAO attack" was caused by a vulnerability in a smart contract, resulting in a large amount of funds being stolen; (2) The execution efficiency of smart contracts is also an issue that needs to be considered. Complex contract calculations may cause 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] The technical methods to improve the security and efficiency of smart contracts are mainly divided into two categories: one is to use static analysis tools (such as Slither and SmartCheck, etc.) to check the contract before the smart contract is deployed on the chain to reduce vulnerabilities. However, this method has problems such as limited coverage and false positives, and cannot reflect the actual situation at runtime; the other is to understand the execution behavior of the contract by monitoring and tracking the actual runtime state of the smart contract, and analyze the problems in the contract logic. Compared with the static analysis method, it has a higher coverage rate and can identify potential problems at runtime. The bytecode plugging method studied in this invention is used to achieve the goal of smart contract monitoring. For blockchain and smart contracts, monitoring technology can effectively determine the correctness of the contract execution logic and the use of resources, and can also help users to promptly discover risks such as security vulnerabilities and permission issues, reduce common security issues such as reentry attacks and overflow vulnerabilities, and also help users understand the contract execution behavior and improve the performance and efficiency of the contract.

[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] 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;

[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 completes the generation of the intermediate expression on this basis;

[0013] 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.

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

[0015] 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.

[0016] 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;

[0017] 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;

[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. 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 monitoring information and the plug-in operation code;

[0019] The execution engine executes the opcodes of the 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. The character sequence is converted into the required tokens through lexical analysis to generate a token stream;

[0022] b. Syntax analysis: The token flow undergoes syntax analysis to construct an abstract syntax tree, which represents the grammatical structure of the contract;

[0023] c. Pile parameter analysis: Analyze the input pile parameters to check whether the pile parameters entered by the monitoring personnel are correct;

[0024] 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.

[0025] Preferably, the intermediate expression includes an instrumentation instruction, and the generation process of the intermediate expression includes two steps:

[0026] 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;

[0027] 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.

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

[0029] The syntax analysis includes three steps: a) constructing an abstract syntax tree according to the tag 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, and the recording format is "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;

[0030] The plugging parameter analysis includes three steps: a) establishing a plugging information table Map1_2; b) obtaining the contract name and state variable name of the target plugging according to the input plugging 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 plugged 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 plugged exist;

[0031] The semantic analysis and preprocessing include three steps: a) initializing the contract context, during which the variables in the smart contract are traversed; b) establishing a variable state table Map1_3; c) storing the target instrumented variables and variable states; first determine whether the variable is in Map1_2, that is, determine whether the variable is the target instrumented variable. If it is the target instrumented variable, store the variable 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 instrumentation engine later, the variable state value will be changed.

[0032] Preferably, the plugging requirement classification includes: judging that the selected plugging category is a plugging for state variable monitoring according to the input plugging parameters;

[0033] 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";

[0034] 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;

[0035] 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.

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

[0037] 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;

[0038] 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;

[0039] The semantic analysis and preprocessing includes three steps: a) initializing the contract context, during which the functions in the smart contract are traversed; b) establishing a function call table Map2_3; c) storing 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", and multiple target functions are separated by brackets and commas.

[0040] Preferably, the instrumentation requirement classification includes: judging that the selected instrumentation category is instrumentation oriented to function monitoring according to the input instrumentation parameters;

[0041] The plugging processing operation includes: the plugging processing for function monitoring includes two parts: the declaration module and the 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 processing function module part is further divided into two parts: the function header and the function body; in the function header part, check whether the function name is in Map2_3, if it is not the target function, call the default instruction to generate the default module; if it is the target function and it is an external function, add the external function start instruction to generate a module with a monitoring function; if it is the target function and it is an internal function, the function header part is not processed, and the default instruction is called to generate the default module; in the function body part, check the function name and type through Map2_3 and Map2_1, if it is an external function, the function header inserts the external function start instruction, and 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Hereinafter, some specific embodiments of the present invention will be described in detail in an exemplary and non-limiting manner with reference to the accompanying drawings. The same reference numerals in the accompanying drawings indicate the same or similar components or parts. It should be understood by those skilled in the art that these drawings are not necessarily drawn to scale. The objects and features of the present invention will become more apparent in view of the following description in conjunction with the accompanying drawings, in which:

[0043] Figure 1 A flowchart of the bytecode instrumentation method for blockchain smart contracts;

[0044] Figure 2 Run a detailed flowchart for the blockchain smart contract bytecode instrumentation method;

[0045] Figure 3 This is the flow chart of the instrumentation compilation phase for state variable monitoring;

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

[0047] Figure 5 This is the flow chart of the instrumentation compilation phase for function monitoring;

[0048] Figure 6 This is a diagram of the instrumentation storage space relationship for function monitoring. DETAILED DESCRIPTION

[0049] In order to overcome the defects of the prior art, the present invention proposes a monitoring-oriented blockchain smart contract bytecode plugging method. According to actual needs, the method can be further divided into a blockchain smart contract bytecode plugging method for state variable monitoring and a blockchain smart contract bytecode plugging method for function monitoring. The operation and implementation of the method depends on the smart contract compiler and the smart contract operating environment, completing the full process design of the smart contract from analysis, plugging, bytecode generation, deployment, operation to identification and processing of plugging instructions, providing a solution for bytecode precise plugging for monitoring needs.

[0050] The overall operation summary process of the blockchain smart contract bytecode plugging method for monitoring proposed in the present invention is as follows: Figure 1 shown.

[0051] The overall operation process is mainly divided into two stages: smart contract compilation and smart contract operation. It depends on the smart contract compiler and the operating environment. The smart contract compiler performs compilation command processing, contract analysis, plugging processing and bytecode generation operations according to the input smart contract and compilation commands to obtain the plugged bytecode and application interface. The plugged bytecode and application interface will be used as the input of the smart contract operating environment in the operation phase together with the call command. The smart contract operating environment will perform call command processing, bytecode parsing, monitoring function retrieval and opcode execution operations to finally obtain the monitoring results. Further, the detailed description of the operation process is as follows: Figure 2 shown.

[0052] The method has six key components in the smart contract compiler, which are described as follows:

[0053] Compilation command processing unit. Parse the smart contract and compilation command input by the smart contract monitoring personnel. The command includes the instrumentation parameters. The monitoring personnel 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 smart contracts. The specific description is as follows: a. The smart contract is passed into the contract parser in the form of a character stream. The character sequence is converted into the required tags through lexical analysis to generate a tag stream; b. The tag stream is parsed through syntax analysis to construct an abstract syntax tree, which represents the grammatical structure of the contract; c. The input instrumentation parameters are analyzed to check whether the instrumentation parameters entered by the monitoring personnel are correct; d. The abstract syntax tree is semantically analyzed to obtain the semantic information table of the smart contract. The semantic information table contains type information, scope information and access control information. At the same time, preprocessing is performed to prepare for subsequent instrumentation operations;

[0055] Insertion instruction table. It stores newly added insertion instructions, including insertion instructions for state variable monitoring and insertion 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 completes the generation of the intermediate expression on this basis. The intermediate expression contains instrumentation instructions, and its generation process includes two steps: a. Determine the instrumentation category based on the instrumentation parameters, that is, determine whether it is instrumentation for state variable monitoring or instrumentation for function monitoring; b. Execute the instrumentation processing operation to generate an intermediate expression containing instrumentation instructions. The instrumentation processing operation is also performed for different categories;

[0058] Bytecode generator. According to the intermediate expression of the contract after the instrumentation, the corresponding instructions and data are extracted from it to obtain the final output, that is, the bytecode and application interface after the instrumentation. At the same time, the bytecode optimization work can be completed in the bytecode generator;

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

[0060] Call command processing unit. Parse the call command entered by the smart contract monitoring personnel and the bytecode after the plugging. The call command contains monitoring parameters, which indicate 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. Convert the input bytecode into the corresponding opcode, convert the default operation instruction into the default opcode, and convert the newly added plug-in instruction into the corresponding plug-in opcode;

[0062] Monitoring operation library. It stores monitoring function modules corresponding to the plug-in operation code, and the monitoring function modules include state variable monitoring function modules and function monitoring function modules;

[0063] Monitoring engine. Receives monitoring parameters output by the call command processing unit and operation codes output by the bytecode parser to determine specific monitoring logic. The specific operations are: a. Analyze monitoring requirements and determine target monitoring information; b. Find the corresponding monitoring function module from the monitoring operation library and associate it according to the monitoring information and the plug-in operation code;

[0064] Execution engine: The smart contract runtime environment executes the opcodes of the 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 in the present invention is described as follows:

[0066] like Figure 2 As shown in ①, the smart contract monitoring personnel first start the compilation operation, input the smart contract and compilation command, and the compilation command processing unit processes and parses to obtain the corresponding plug-in parameters and smart contract (character stream). Figure 2 As shown in ③, the smart contract is parsed and preprocessed by the contract parser to obtain the semantic information table and abstract syntax tree. As shown in ② and ④, the instrumentation engine performs instrumentation based on the instrumentation parameter information, semantic information table, abstract syntax tree, instrumentation instruction table and default instruction library, generates the intermediate expression of the instrumented contract (including instrumentation information), and finally outputs the instrumented bytecode and application interface through the bytecode generator. Figure 2 ⑤ and ⑥. Deploy smart contracts based on the bytecode and application programming interface after the plug-in. Figure 2 As shown in ⑦, the smart contract monitoring personnel can start the contract call operation, pass in the call command to call the deployed smart contract, and obtain the monitoring parameters and the bytecode corresponding to the smart contract after parsing by the call command processing unit, as shown in Figure 2 As shown in ⑨, the bytecode will be converted into the corresponding opcode in the bytecode parser. The monitoring engine generates the monitoring opcode containing the monitoring logic according to the monitoring parameters, opcode and the monitoring function module in the corresponding monitoring library, which is executed by the execution engine and generates the final monitoring result, see Figure 2 ⑩~ .

[0067] 1. Blockchain smart contract bytecode instrumentation method for state variable monitoring

[0068] The implementation of the blockchain smart contract bytecode stubbing method for state variable monitoring depends on the compilation and running stages, which are located in the compiler and the running environment respectively. The stubbing of the state variables specified by the smart contract can monitor the changes in the running environment. The difficulty lies in how to record the data value of the state variable after each assignment statement, that is, to monitor the dynamic changes of the state variable.

[0069] The specific process of the compilation phase is as follows Figure 3 As shown, the description is as follows:

[0070] Input. As shown in Figure ①, the smart contract monitoring personnel starts the compilation operation, inputs 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 the smart contract (character stream) and instrumentation parameters. As shown in Figure ②, the instrumentation parameters are passed to the instrumentation engine. As shown in Figure ③, the smart contract (character stream) and instrumentation parameters are passed to the contract parser;

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

[0072] a. Lexical analysis. Convert the smart contract in the form of character stream into the 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 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 (considering that the input smart contract file may contain multiple smart contracts), and "variable1,...,variablen" represents the name of the state variable in the smart contract;

[0074] c. Instrumentation parameter analysis. Instrumentation parameter analysis includes three steps: a) Establishing the instrumentation information table Map1_2; b) Obtaining the contract name and state variable name of the target instrumentation according to the incoming instrumentation parameter information, and recording them in Map1_2 in the form of "d_contractname:d_variable1,…,d_variablen", where "d_contractname" indicates the name of the smart contract and "d_variable1,…,d_variablen" indicates the name of the state variable; c) Performing 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 so, check whether the variables in Map1_2 are in the variable table corresponding to the target contract in Map1_1. This avoids incorrect input of compilation commands;

[0075] d. Semantic analysis and preprocessing. 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 the variable state table Map1_3; c) Store the target instrumented variable and the variable state value (that is, the number of times the variable is accessed). First, determine whether the variable is in Map1_2, that is, determine whether the variable is the target instrumented variable; if it is the target instrumented variable, store the variable 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 subsequently processed in the instrumentation engine, the variable state value will be changed. After the semantic analysis and preprocessing are completed, the generated semantic information table and abstract syntax tree are passed into the instrumentation engine, as shown in Figure ④;

[0076] The relevant operations of the instrumentation engine are described as follows:

[0077] a. Classification of instrumentation requirements. According to the input instrumentation parameters, the selected instrumentation category is determined to be instrumentation for state variable monitoring;

[0078] b. Instrumentation processing operation. The instrumentation processing for state variable monitoring includes two parts: the declaration module and the function module. Each part is divided into three steps: checking, inserting default instructions, and inserting instrumentation instructions. In the checking stage, the declaration module needs to check whether the variable is in Map1_3 and whether it is assigned 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 default instruction placement stage, the instruction generation logic module is called from the default library. When inserting the instrumentation instruction, the instrumentation instruction is selected according to the variable status value ("0" when not operated), 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"; the instrumentation instruction is selected according to the variable status value, if the variable status value is "0", select variable monitoring instruction 1; if the variable status value is "1", select 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: the processing declaration module and the processing function module. The processing process of each module includes three steps: checking, inserting default instructions, and inserting instrumentation instructions. The following describes them separately:

[0081] a) Processing declaration module. The processing declaration module includes three steps: I. Checking; II. Inserting default instructions; III. Inserting plugging instructions. The plugging method for state variable monitoring designed by the present invention includes two plugging 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 (that is, the starting position of the variable in the storage unit, used to support subsequent read operations), and the operands in variable monitoring instruction 2 are only variable names. By designing different plugging instructions, redundant information is avoided in the bytecode generated subsequently. First, a check step is performed, which includes two operations: first, a variable check is performed, that is, whether the variables involved in the declaration statement currently being processed are in Map1_3; then a statement check is performed, that is, whether the current statement performs an assignment operation after declaring the variable. Only when the above two conditions are met at the same time can the declaration statement currently being processed be considered as an operation statement for the target variable, and the plugging instruction will be inserted. Then the default instruction is called to complete the basic logical operation. Otherwise, directly proceed to the step of inserting the default instruction, which includes two operations: i. Retrieve the default instruction from the default instruction library; ii. Generate a default module based on the default instruction. When inserting the plug-in instruction, three operations are required: i. Check whether the operation statement is the first operation for the target variable, that is, check the status value corresponding to the variable in Map1_3; ii. Retrieve the corresponding plug-in instruction according to the variable status value. If the status value is "0", it means that it is the first operation, and the variable monitoring instruction 1 needs to be called. If the status value is "1", it means that there is already a statement for operating the target variable, and the variable monitoring instruction 2 needs to be called; iii. First generate different plug-in modules according to different plug-in instructions, put the variable monitoring instruction 1 (or 2) at the forefront of the current monitoring variable operation statement, and then modify the variable status value. If the variable status value is "0", change it to "1", indicating that the variable has been operated. If the variable status value is already "1", no modification is made;

[0082] b) Processing function module. The processing function module also includes three steps: Ⅰ. Check; Ⅱ. Place default instructions; Ⅲ. Insert stub instructions. The specific execution content of the steps of placing default instructions and inserting stub instructions is the same as that of the processing declaration module, but the specific execution content of the checking step is different from that of the processing declaration module. In the checking step, the statement check is first performed to determine whether the current position is a statement expression. If so, it is then determined whether the statement expression is an assignment statement. After the above two conditions are met, a variable check is performed, that is, whether the variables involved in the assignment statement are in Map1_3. Similarly, only statements that meet both statement checks and variable checks can be considered as operation statements for the target variable. Otherwise, the step of placing default instructions (calling default instructions and generating default logical operations) can be directly executed. When inserting stub instructions, the status value of the variable is also checked first. If it is "0", it means that the variable has not been operated. 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. Simply insert variable monitoring instruction 2 at the front of the current statement;

[0083] After the above processing, the intermediate expression of the contract after instrumentation will be generated. After conversion by the bytecode generator, the instrumented bytecode and application interface will be generated, as shown in ⑤~⑥ in the figure.

[0084] The above process involves three newly created storage spaces: contract variable table Map1_1, plugging information table Map1_2, and variable status table Map1_3. Map1_1 records all status variables in all smart contracts; Map1_2 records the target plugging variables in all smart contracts to be plugged; Map1_3 records the target plugging variables and variable status values ​​in the currently processed smart contract. The relationship between the three storage spaces is as follows: Figure 4 shown.

[0085] After deploying the bytecode after the stub and the corresponding application interface to the smart contract running environment, the contract monitoring personnel will start the contract call operation. The bytecode after the stub and the call command containing the monitoring parameters will be parsed into bytecode and monitoring parameters by the call command processing unit. After that, the bytecode is parsed into operation code by the bytecode parser. The monitoring engine will read the monitoring parameters and operation code. The operation code corresponding to variable monitoring instruction 1 is variable monitoring operation code 1, and the operation code corresponding to variable monitoring instruction 2 is variable monitoring operation code 2. The monitoring engine will call the corresponding monitoring function module when it recognizes the variable monitoring operation code, and then send the monitoring operation code with the monitoring function attached to the execution engine. The execution engine will execute the operation code sequentially. If it encounters the variable monitoring operation code 1, it will create a variable history information record table. First, the operands following the variable monitoring operation code 1, namely the variable name, variable type and offset, will be recorded. Then, the specific storage location of the variable will be determined according to the offset and the storage unit sequence number of the variable output by the running environment, and the value therein will be read and stored in the variable history information record table. If the variable monitoring operation code 2 is encountered, the operand following the operation code, i.e. the variable name, is first read, and whether the historical information record table corresponding to the variable already exists. If so, the specific storage location of the variable is determined according to the offset recorded in the table and the variable storage unit sequence number output by the operating environment, and the value therein is read and stored in the corresponding variable historical information record table. In this way, the monitoring of the state variable 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 the compilation and operation links, which are located in the compiler and the runtime environment respectively. The instrumentation of the smart contract specified function can monitor the function runtime information in the runtime environment. The difficulty of implementation lies in accurately identifying the calling relationship between runtime functions.

[0088] The specific process of the compilation phase is as follows Figure 5 As shown, the description is as follows:

[0089] Input. As shown in Figure ①, the smart contract monitoring personnel starts the compilation operation, inputs 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 the smart contract (character stream) and instrumentation parameters. As shown in Figure ②, the instrumentation parameters are passed to the instrumentation engine. As shown in Figure ③, the smart contract (character stream) and instrumentation parameters are passed to the contract parser;

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

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

[0092] b. Syntax analysis includes three steps: a) construct an abstract syntax tree based on the token stream; b) establish a contract function table Map2_1; c) record the function-related information in the smart contract in the contract function table, and the record 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 the pointer to the function definition. The pointer is the address of the function. According to the pointer, the relevant information of the function definition can be obtained, including the function's input parameters, return value, keywords and function body information;

[0093] c. Analysis of instrumentation parameters. The analysis of instrumentation parameters includes three steps: a) Establishing the 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" represents the name of the function; c) Performing parameter rationality check, first check whether the contract name in Map2_2 is in the record 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 avoids incorrect input of compilation commands.

[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 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, just write "d_functionname". Multiple target functions are separated by brackets 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, find all the functions to be plugged, and record them in Map2_3. Traverse Map2_3 and process the functions to be plugged. The processing method is as follows:

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

[0096] ② Find the function body according to the pointer, which contains the name of the called function;

[0097] ③Append the called function name to Map2_3;

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

[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 to the instrumentation engine, as shown in Figure ④;

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

[0101] a. Classification of instrumentation requirements. According to the input instrumentation parameters, the selected instrumentation category is determined to be instrumentation for function monitoring;

[0102] b. Instrumentation processing operation. The instrumentation processing for function monitoring includes two parts: the declaration module and the function module. Before instrumenting a function, determine whether it is an external function or an internal function, and the two have different instrumentation methods. The external function exits the context at the end of the call. The end position of the external function can be identified by the exit instruction of the default library, so it is only necessary to instrument at the beginning of the function. Internal functions cannot be directly captured because of the call operation and return value processing, so they need to be instrumented at the beginning and end of the function respectively. The instrumentation instructions include external function start instructions, internal function start instructions, and internal function end instructions, which are used to identify the corresponding positions.

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

[0104] Processing function header: Check whether the function name is in Map2_3. If it is not the target function, call the default instruction to generate the default module. If it is the target function and it is an external function, add the external function start instruction to generate a module with monitoring function. If it is the target function and it is an internal function, do not process the function header part, call the default instruction 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, the function body will not be processed because the external function start instruction has been inserted in the function header. If it is an internal function, the internal function start instruction will be inserted at the beginning and the internal function end instruction will be inserted at the end to generate a module with monitoring function.

[0106] Specifically:

[0107] Before inserting a function, it is necessary to determine whether the current function is an external function or an internal function. The two types of functions have their own characteristics and are suitable for different insertion methods. If it is an external function, each call ends and the current function context needs to be exited. There is a corresponding exit instruction in the default instruction library, so the function end position can be accurately identified at runtime, and it is only necessary to insert the pile at the beginning of the function. The internal function is called within the contract, and the call operation cannot be captured by special instructions. In addition, when processing the return value, it is processed by ordinary instructions in the default instruction library. The function end position cannot be accurately identified at runtime, so it is necessary to insert the pile at the beginning and end of the function respectively. At the same time, only external functions have function headers. When processing smart contracts, the smart contract compiler will first process the function header part and then process the function body part. The function monitoring-oriented insertion method designed by the present invention includes three insertion instructions, namely, the external function start instruction, the internal function start instruction and the internal function end instruction, which correspond to the identification of the external function start position, the internal function start position and the internal function end position. The entire function insertion processing operation includes two parts: a) processing declaration module; b) processing function module. The processing declaration module does not perform any processing related to the plug-in, but only calls the default instruction and generates the default module. The processing function module can be subdivided into two parts: the processing function header module and the processing function body module. The processing process of each module includes three steps: function check, calling the default instruction or monitoring instruction, and generating the default function module or the function module with monitoring function. The following describes them respectively:

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

[0109] Ⅱ. Processing function body module. Processing function body module includes three operations. Because both external functions and internal functions have function bodies, the function check operation includes checking the function name and function type. First, execute operation i to obtain the name of the function currently being processed, and query Map2_3 according to the function name. If the query result is empty, it means that the current function is not the target stub function. Execute operation ii to call the default instruction and generate the corresponding default function module. On the contrary, it means that the current function is the target stub function. It is necessary to continue to execute operation i to determine the type of the function. According to the function name, find the pointer corresponding to the function in Map2_1, obtain the function keyword, and determine whether it is an external function or an internal function according to the keyword. Because the external function has been stubbed in the function header, no processing is done in the function body. The internal function needs to be stubbed at the beginning and end of the function processing respectively. Execute operation iii to insert the internal function start instruction at the beginning of the function and 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 expression of the contract after instrumentation will be generated. After the bytecode generator extracts and processes the instructions, the instrumented bytecode and application interface will be generated, as shown in Figure ⑤~⑥.

[0111] The above process involves three newly created storage spaces: contract function table Map2_1, plugging information table Map2_2, and function call table Map2_3. Map2_1 records all functions in all smart contracts and their defined pointers; Map2_2 records all functions in the smart contracts to be plugged; Map2_3 records the target plugging function in the currently processed smart contract and its call-related functions. The relationship between the three storage spaces is as follows: Figure 6 shown.

[0112] After deploying the stubbed bytecode and the corresponding application program interface to the smart contract running environment, the contract monitoring personnel will start the contract call operation. The stubbed bytecode and the call command containing the monitoring parameters will be parsed into bytecode and monitoring parameters by the call command processing unit. After that, the instructions in the bytecode are parsed into opcodes by the bytecode parser. The opcode corresponding to the external function start instruction is the external function start opcode in the monitoring instruction, the internal function start instruction corresponds to the internal function start opcode in the monitoring instruction, the internal function end instruction corresponds to the internal function end opcode in the monitoring instruction, and the default instruction corresponds to the default opcode. The monitoring engine will read the monitoring parameters and opcodes, and will call the corresponding function module when it recognizes the function monitoring opcode (for example, to monitor the actual running time of the function, you can add a timestamp recording function to the function module of the opcode), and then send the opcode with the monitoring function attached to the execution engine. The execution engine will execute the opcodes sequentially. If it encounters the external function start opcode, it means that this is the entrance of the external function, and it will continue to process the opcodes backwards. If the exit opcode in the default opcode is recognized, it means that this is the exit of the external function. Similarly, recognizing the internal function start opcode indicates that this is the entry of the internal function, and recognizing the internal function end opcode indicates that this is the exit of the internal function. Through these plug-in instruction opcodes and the exit opcode in the default instruction of the external function, the recording function can be called according to the monitoring parameters to achieve the purpose of monitoring.

[0113] The present invention supports the simultaneous execution of a blockchain smart contract bytecode plugging method for state variable monitoring and a blockchain smart contract bytecode plugging method for function monitoring, thereby completing multi-type mixed monitoring.

[0114] Beneficial effects of the present invention:

[0115] A monitoring-oriented blockchain smart contract bytecode instrumentation method is proposed, which supports both state variable and function monitoring requirements, and 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 can be implemented by software, hardware, or a combination of software and hardware. When implemented using software, it can 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 process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or a data center that includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)), etc.

[0117] The above is only a specific implementation of the embodiment of the present application, but the protection scope of the embodiment of the present application is not limited thereto, and any changes or replacements within the technical scope disclosed in the embodiment of the present application should be included in the protection scope of the embodiment of the present application. Therefore, the protection scope of the embodiment of the present application should be based on 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 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; 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.

2. The method according to claim 1, characterized in that: 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 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.

3. 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 character sequence is converted into the required tokens through lexical analysis to generate a token stream; b. Syntax analysis: The token flow undergoes syntax analysis 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.

4. The method according to claim 1 or 3, 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.

5. The method according to claim 3 or 4, 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 variables in the smart contract; The plugging parameter analysis includes three steps: a) establishing a plugging information table Map1_2; b) obtaining the contract name and state variable name of the target plugging according to the input plugging 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 plugged exists; if it exists, 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 plugged exist; The semantic analysis and preprocessing include three steps: a) initializing the contract context, during which the variables in the smart contract are traversed; b) establishing a variable state table Map1_3; c) storing the target instrumented variables and variable states; first determine whether the variable is in Map1_2, that is, determine whether the variable is the target instrumented variable. If it is the target instrumented variable, 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 state value of the state variable. The initial value is "0", and the variable state value will be changed during subsequent processing in the instrumentation engine.

6. The method according to claim 5, characterized in that: The plugging requirement classification includes: judging that the selected plugging category is a plugging for state variable monitoring according to the input plugging parameters; The plug-in processing operation includes: the plug-in processing for state variable monitoring includes two parts: the declaration module and the function module, each of which is divided into three steps: checking, inserting default instructions, and inserting plug-in 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 plug-in instruction, the plug-in instruction is 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"; 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.

7. The method according to claim 3 or 4, characterized in that: Under the condition of function-oriented monitoring, The grammatical 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, with the recording format being "contractname:functionname,functionpointer", where "contractname" represents the name of the smart contract, "functionname" represents the name of the function in the smart contract, and "functionpointer" represents a pointer to the function definition, which is the address of the function. The relevant information of the function definition can be obtained according to the pointer, 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) initializing the contract context, during which the functions in the smart contract are traversed; b) establishing a function call table Map2_3; c) storing 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", and multiple target functions are separated by brackets and commas.

8. The method according to claim 7, characterized in that: The instrumentation requirement classification includes: judging that the selected instrumentation category is instrumentation oriented to function monitoring according to the input instrumentation parameters; The plug-in processing operation includes: the plug-in processing 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 processing function module part is further divided into a function header and a function body; in the function header part, check whether the function name is in Map2_3, if it is not the target function, call the default instruction to generate the default module; if it is the target function and it is an external function, add the external function start instruction to generate a module with a monitoring function; if it is the target function and it is an internal function, the function header part is not processed, and the default instruction is called to generate the default module; in the function body part, check the function name and type 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, insert the internal function start instruction at the beginning and the internal function end instruction at the end to generate a module with a monitoring function.

Images