Method, device and equipment for risk identification of smart contract

Abstract

This specification provides a method, apparatus, and device for risk identification of smart contracts. The method includes: acquiring transaction events of N historical transactions based on a target smart contract, and a first function signature of each transaction function processing the N historical transactions; acquiring a second function signature of each transaction function included in the target smart contract; identifying whether the target smart contract has a preset risk based on the tags associated with the acquired transaction events, the first function signature, and the second function signature, which characterize the corresponding transaction type; wherein, each transaction function included in the target smart contract performs transaction processing on the corresponding transaction when called by the callee through the function signature of the transaction function; N is an integer greater than 1; the second function signature includes the first function signature.

Description

TECHNICAL FIELD

[0001] The present document relates to the technical field of blockchains, and in particular to a risk identification method, device and equipment for a smart contract. BACKGROUND

[0002] At present, blockchains are widely used in many scenarios. In order to achieve fast processing of data, a user of a blockchain usually writes a smart contract in Solidity language, compiles a source code of the smart contract to obtain bytecode, and deploys the smart contract on the blockchain based on the bytecode, so as to process data through the smart contract. Since the bytecode of the smart contract cannot restore the source code of the smart contract, there may be an illegal smart contract in the blockchain that processes illegal data. In order to identify the illegal smart contract, the bytecode of the smart contract is usually decompiled, and the data processing logic thereof is manually analyzed. However, manual analysis is time-consuming and laborious, and when the data processing logic of the smart contract is complex, it is often difficult to identify, which increases the difficulty of management of the smart contract. SUMMARY

[0003] One or more embodiments of the present specification provide a risk identification method for a smart contract. The method includes obtaining a transaction event based on N historical transactions reached by a target smart contract, and processing a first function signature of each transaction function of the historical transactions. The target smart contract includes a plurality of transaction functions. Each transaction function performs transaction processing on a corresponding transaction when a calling party calls the function signature of the transaction function. N is an integer greater than 1. A second function signature of each transaction function included in the target smart contract is obtained. The second function signature includes the first function signature. According to a label associated with the transaction event, the first function signature and the second function signature, it is identified whether the target smart contract has a preset risk. The label is used to represent the transaction type of the corresponding transaction.

[0004] This specification provides one or more embodiments of a smart contract risk identification device. The device includes a first acquisition module, which acquires transaction events of N historical transactions based on a target smart contract, and first function signatures of each transaction function processing the historical transactions. The target smart contract includes multiple transaction functions. Each transaction function processes the corresponding transaction when invoked by a callee using its function signature. N is an integer greater than 1. The device also includes a second acquisition module, which acquires second function signatures of each transaction function included in the target smart contract. The second function signature includes the first function signature. The device further includes an identification module, which identifies whether the target smart contract has a preset risk based on tags associated with the transaction events, the first function signature, and the second function signature. The tags are used to characterize the transaction type of the corresponding transaction.

[0005] This specification provides one or more embodiments of a smart contract risk identification device. The device includes a processor. The device also includes a memory arranged to store computer-executable instructions. When executed, the computer-executable instructions cause the processor to acquire transaction events based on N historical transactions of a target smart contract, and first function signatures of each transaction function processing the historical transactions. The target smart contract includes multiple transaction functions. Each transaction function processes the corresponding transaction when invoked by a callee using its function signature. N is an integer greater than 1. Second function signatures of each transaction function included in the target smart contract are acquired. The second function signature includes the first function signature. Based on tags associated with the transaction events, the first function signatures, and the second function signatures, the device identifies whether the target smart contract carries a preset risk. The tags characterize the transaction type of the corresponding transaction.

[0006] This specification provides one or more embodiments of a storage medium for storing computer-executable instructions. When executed by a processor, the computer-executable instructions acquire transaction events of N historical transactions based on a target smart contract, and first function signatures of each transaction function processing the historical transactions. The target smart contract includes multiple transaction functions. Each transaction function processes the corresponding transaction when invoked by a callee using its function signature. N is an integer greater than 1. Second function signatures of each transaction function included in the target smart contract are acquired. The second function signature includes the first function signature. Based on tags associated with the transaction events, the first function signatures, and the second function signatures, the existence of a preset risk in the target smart contract is identified. The tags characterize the transaction type of the corresponding transaction. Attached Figure Description

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

[0008] Figure 1 A schematic diagram of a first process for a risk identification method for smart contracts provided in one or more embodiments of this specification;

[0009] Figure 2 A second flowchart illustrating a risk identification method for smart contracts provided in one or more embodiments of this specification;

[0010] Figure 3 A schematic diagram of a third process for a risk identification method for smart contracts provided in one or more embodiments of this specification;

[0011] Figure 4 A schematic diagram of the module composition of a risk identification device for a smart contract provided in one or more embodiments of this specification;

[0012] Figure 5 This is a schematic diagram of the structure of a risk identification device for smart contracts provided in one or more embodiments of this specification. Detailed Implementation

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

[0014] In current technologies, smart contract deployment typically involves first writing the smart contract's source code in Solidity, then compiling it into bytecode, and finally deploying the smart contract on the blockchain based on the bytecode. Since the source code cannot be reconstructed from the bytecode, it's difficult to identify the smart contract's data processing logic. Furthermore, when calling a smart contract for data processing, the data to be processed is usually encoded according to the order and type specified in the smart contract's source code, and the smart contract is called based on this encoded data. Since the encoded object only contains the data to be processed without data type information, it's impossible to obtain the data type and, consequently, to identify whether the data processed by the smart contract is legitimate. Because it's currently difficult to identify the data processing logic of smart contracts and whether the data processed by them is legitimate, there's a possibility that illegitimate smart contracts processing illegal data may exist on the blockchain. Currently, identifying illegal smart contracts typically involves decompiling the bytecode and manually analyzing the data processing logic. However, manual identification is time-consuming, labor-intensive, and prone to errors. Furthermore, it is often difficult to identify complex smart contracts. Therefore, this application provides one or more embodiments of a method, apparatus, and device for identifying risks in smart contracts. This method acquires transaction events from N historical transactions completed by a target smart contract, the first function signatures of each transaction function processing those historical transactions, and the second function signatures of each transaction function included in the target smart contract. Based on the tags associated with the acquired transaction events, first function signatures, and second function signatures, it identifies whether the target smart contract has pre-existing risks. Each transaction function in the target smart contract processes the corresponding transaction when called by the callee using its function signature. The tags characterize the transaction type of the corresponding transaction. Thus, based on the tags associated with transaction events and function signatures, intelligent identification of whether a smart contract has pre-existing risks is achieved without human intervention, improving the accuracy and efficiency of smart contract risk identification and reducing the management difficulty of smart contracts.

[0015] Figure 1 This is a flowchart illustrating a risk identification method for smart contracts provided in one or more embodiments of this specification. Figure 1 The method described can be executed by a risk identification device of the smart contract (hereinafter referred to as the risk identification device). This risk identification device can be set in a terminal device or on the server side; the terminal device can be a mobile phone, tablet computer, desktop computer, laptop computer, etc.; the server side can be a standalone server or a server cluster composed of multiple servers. Figure 1 As shown, the method includes the following steps:

[0016] Step S102: Obtain the transaction events of N historical transactions based on the target smart contract, and the first function signature of each transaction function that processes the N historical transactions; the target smart contract includes multiple transaction functions, and each transaction function performs transaction processing on the corresponding transaction when called by the callee through the function signature of the transaction function; N is an integer greater than 1;

[0017] In one or more embodiments of this application, the target smart contract deployed on the blockchain may be written in Solidity or other languages, and its source code cannot be reconstructed from its bytecode. The target smart contract may include multiple transaction functions, each handling a specific type of transaction. For example, transaction function 1 handles type A transactions, transaction function 2 handles type B transactions, etc., where type A and type B are different transaction types. The target smart contract provides function interfaces for each transaction function; these function interfaces are the entry point of the target smart contract. When a caller needs to process a transaction through a target transaction function in the target smart contract, it obtains the function signature of the target transaction function, the encoded data of the transaction data to be processed, etc., and calls the function interface of the target transaction function based on the function signature and encoded data to process the transaction through the target transaction function in the target smart contract. It is understood that once a transaction is successfully processed through a certain transaction function in the target smart contract, the transaction can be considered a transaction achieved based on the target smart contract.

[0018] The caller of a transaction function can be a transaction request user, a blockchain node, or any type of transaction system with transaction initiation capabilities. This application does not specifically limit the type of caller. In one implementation, the caller is a blockchain node. When the transaction request user has not deployed a blockchain node, the user can operate their terminal device to edit and submit the transaction data to be processed. In response to the user's submission, the terminal device determines the target transaction function in the target smart contract to be called based on the submitted transaction data, generates a function signature for the target transaction function according to a preset generation method, encodes the submitted transaction data according to a preset encoding method to obtain encoded data, and sends a transaction processing request to the blockchain node based on the function signature, encoded data, and the function identifier of the target function. The blockchain node obtains the function signature, encoded data, and function identifier from the transaction processing request and calls the function interface of the target transaction function corresponding to the function identifier in the target smart contract based on the obtained function signature and encoded data to perform transaction processing through the target transaction function. Alternatively, when the user requesting a transaction has not deployed a blockchain node, the user can edit and submit the transaction data to be processed on their terminal device. In response to the user's submission, the terminal device determines the target transaction function in the target smart contract to be invoked based on the submitted transaction data. It then encodes the submitted transaction data using a preset encoding method to obtain encoded data. Based on the encoded data and the function identifier of the target transaction function, the terminal device sends a transaction processing request to the blockchain node. The blockchain node retrieves the encoded data and function identifier from the transaction processing request, generates a function signature for the target transaction function corresponding to the function identifier using a preset generation method, and invokes the function interface of the target transaction function in the target smart contract based on the function signature and encoded data to process the transaction through the target transaction function. When a transaction requesting user has deployed a blockchain node, the user can edit and submit the transaction data to be processed. The blockchain node responds to the user's submission by determining the target transaction function in the target smart contract to be invoked based on the submitted transaction data. It then generates the function signature of the target transaction function according to a preset generation method, encodes the submitted transaction data according to a preset encoding method, and calls the function interface of the target transaction function in the target smart contract based on the function signature and encoded data to process the transaction. The preset generation method can be a hash calculation of the function name and parameter types of the target transaction function; the preset encoding method can be RLP (Recursive Length Prefix), etc.It should be noted that the process of calling transaction functions in smart contracts is not limited to the above process, and can be set according to needs in actual applications.

[0019] Furthermore, a transaction can have one transaction event, multiple transaction events, or no transaction event at all, and the number of transaction events can be the same or different for different transactions. Understandably, when a transaction has no transaction events, it may not generate any transaction events, or it may generate an empty transaction event. A transaction event includes an event signature, and may also include event content, the block height at which the event occurred, etc.; the event signature can be obtained by hashing the event name and the parameter types in the event content. The specific content of the transaction event and the method of obtaining the event signature can be set according to the needs of actual application, and this application does not impose specific limitations on them.

[0020] Step S104: Obtain the second function signature of each transaction function included in the target smart contract; the second function signature includes the first function signature;

[0021] Specifically, the process involves obtaining the bytecode of the target smart contract; decompiling the bytecode to obtain the processing result; and analyzing the processing result to obtain the second function signatures of each transaction function included in the target smart contract. More specifically, after writing the source code of the target smart contract, the deployer compiles the source code to obtain the bytecode of the target smart contract, and sends a contract deployment transaction to the blockchain based on the bytecode. After the blockchain nodes in the blockchain pass consensus verification of the contract deployment transaction, the target smart contract is deployed on the blockchain. Correspondingly, the risk identification device obtains the bytecode of the target smart contract from the blockchain and decompiles the obtained bytecode using a preset decompilation tool to obtain the processing result; the analysis of the obtained processing result yields the second function signatures of each transaction function included in the target smart contract.

[0022] Step S106: Based on the transaction event, the tags associated with the first function signature and the second function signature, identify whether the target smart contract has a preset risk; the tags are used to characterize the transaction type of the corresponding transaction.

[0023] Specifically, based on the specifications and protocols corresponding to the transaction functions and transaction events generated by each smart contract in the blockchain, the second function signatures of each transaction function and the event signatures in each transaction event are labeled in advance, resulting in at least one signature for each second function signature and at least one tag for each event signature, and an association relationship is established between each signature and tag. When the risk identification device obtains transaction events of N historical transactions based on the target smart contract, the first function signatures of each transaction function that processed the N historical transactions, and the second function signatures of each transaction function included in the target smart contract, it identifies whether the target smart contract has a preset risk based on the tags associated with the transaction events, first function signatures, and second function signatures. The specific content and form of each tag can be set as needed in practical applications, as long as it can characterize the transaction type processed by the corresponding transaction function and the transaction type corresponding to the corresponding transaction event. In one embodiment, the tag can be the specifications and protocols corresponding to each transaction function and each transaction event. For example, if the specification corresponding to a certain transaction function is a resource transfer specification, then it indicates that the transaction type processed by that transaction function is a resource transfer transaction.

[0024] In one or more embodiments of this specification, transaction events of N historical transactions completed based on a target smart contract, first function signatures of each transaction function processing these historical transactions, and second function signatures of each transaction function included in the target smart contract are obtained. Based on the tags associated with the obtained transaction events, first function signatures, and second function signatures, the existence of pre-existing risks in the target smart contract is identified. Each transaction function included in the target smart contract processes the corresponding transaction when invoked by the callee through its function signature. Tags are used to characterize the transaction type of the corresponding transaction. Therefore, based on the tags associated with transaction events and function signatures, intelligent identification of whether a smart contract has pre-existing risks is achieved without human intervention, improving the accuracy and efficiency of smart contract risk identification and reducing the management difficulty of smart contracts.

[0025] To facilitate transaction backtracking, in one or more embodiments of this application, after a transaction is completed based on a smart contract, a transaction record can be generated based on the smart contract's contract identifier, transaction time, transaction event, function signature, etc., and this transaction record can be saved to the blockchain or to a designated database. Correspondingly, step S102, obtaining the transaction events of N historical transactions completed based on the target smart contract, and the first function signatures of each transaction function processing the N historical transactions, can include the following steps S102-2 and S102-4:

[0026] Step S102-2: Based on the contract identifier of the target smart contract, retrieve the transaction records of the last N related historical transactions from the saved transaction records of each historical transaction in chronological order of transaction time.

[0027] Specifically, based on the contract identifier of the target smart contract, the transaction records of the last N related historical transactions are retrieved from the transaction records of all historical transactions stored in the blockchain or a designated database in chronological order of transaction time.

[0028] Step S102-4: Extract the first function signature of the transaction function that processes the corresponding historical transaction from each transaction record, and extract the transaction event if it is determined that the transaction record includes a transaction event.

[0029] As mentioned earlier, since the target smart contract is invoked through the first function signature and the encoded data of the transaction data to be processed, it is impossible to obtain the data type information of the transaction data. Therefore, it is difficult to determine the transaction type and whether the transaction data is legal, and consequently, it is difficult to determine whether the target smart contract has any pre-existing risks. In this embodiment, by obtaining the transaction event and the first function signature of the transaction function that processes historical transactions, it is possible to determine whether the target smart contract has any pre-existing risks based on the transaction event and the tag associated with the first function signature.

[0030] Furthermore, considering that transactions are dynamic, while the second function signatures of the various transaction functions included in the target smart contract are both dynamic and static, based on this, in one or more embodiments of this application, the transaction events of historical transactions and the first function signatures of the various transaction functions processing historical transactions are determined as tags to be processed, and the tags to be processed and the second function tags are processed respectively. Specifically, as follows... Figure 2 As shown, step S106 may include steps S106-2 to S106-6:

[0031] Step S106-2: Obtain the event signature of each transaction event;

[0032] In one embodiment, the event signature is four bytes long. Accordingly, the event signature of a transaction event can be obtained by retrieving the first four bytes of data from each transaction event. It should be noted that this application does not specifically limit the length of the event signature; it can be set as needed in practical applications. The event signature and the second function signature can be the same or different.

[0033] Step S106-4: Determine each first function signature and each event signature as signatures to be processed; based on the preset association between signatures and tags, determine the first candidate tag associated with each signature to be processed and the second candidate tag associated with each second function signature.

[0034] Specifically, each first function signature and each event signature are identified as signatures to be processed. From the preset association between signatures and tags, the first candidate tag associated with each signature to be processed and the second candidate tag associated with each second function signature are obtained.

[0035] Step S106-6: Identify whether the target smart contract has any pre-set risks based on the first candidate label and the second candidate label.

[0036] Specifically, such as Figure 3 As shown, step S106-6 may include steps S106-62 and S106-64:

[0037] Steps S106-62: Determine the target label that matches the target smart contract from the first candidate label and the second candidate label;

[0038] Considering that each candidate tag may be associated with multiple signatures, and the higher the ratio of associated tags, the more transactions of the corresponding transaction type are represented in the transactions processed by the target smart contract, the tag corresponding to the highest ratio can be determined as the target tag that matches the target smart contract. That is, step S106-62 can include the following steps S106-622 and S106-624:

[0039] Steps S106-622: Determine each first candidate label and each second candidate label as labels to be processed, and determine the target ratio of each label to be processed being associated.

[0040] Specifically, determine a first ratio for each first candidate label to be associated with the signature to be processed; determine a second ratio for each second candidate label to be associated with the second function signature; identify the first candidate label and the second candidate label as labels to be processed, and determine a target ratio for each label to be processed based on the first ratio and the second ratio.

[0041] More specifically, the process involves counting the first number of times each first candidate tag is associated with a signature to be processed, and counting the first number of signatures to be processed; based on the first count and the first number, determining the first ratio of each first candidate tag associated with a signature to be processed. The process also involves counting the second number of times each second candidate tag is associated with a second function signature; counting the second number of second function signatures; and based on the second count and the second number, determining the second ratio of each second candidate tag associated with a second function signature. Furthermore, the first and second candidate tags are identified as tags to be processed, and the first and second ratios corresponding to each tag to be processed are determined; a weighted average of the first and second ratios corresponding to each tag to be processed is then performed to obtain the target ratio of each tag to be processed.

[0042] Furthermore, let the total number of transaction events be denoted as C. Topic Let C be the total number of signatures for the first function. Sig Let the first number be denoted as C. Tagi Then the first quantity is C Topic +C Sig First ratio R i =CTagi / (C Topic +C Sig Let the second number be denoted as C. Tagi The second quantity is denoted as C. entry Then the second ratio S i =C Tagi / C entry The weighted average algorithm can be used for T. i =(aR i +bS i ) / (a+b), where a and b are preset parameters.

[0043] Understandably, when a pending tag is not associated with a pending signature (i.e., not associated with an event signature or a first function signature), the first ratio corresponding to that pending tag is zero. Furthermore, since each transaction function has only one function signature, and each transaction function processes one transaction when it is called, the total number of first function signatures C... Sig The total number of event signatures is C, which equals N. Since each transaction event has one event signature, the total number of event signatures is C. Topic .

[0044] As an example, a = 0.2, b = 0.5, N = 5, i.e., 5 historical transactions; the smart contract includes 8 transaction functions; for ease of description, the second function signatures of the 8 transaction functions included in the smart contract are denoted as function signature 1, function signature 2, function signature 3... function signature 8; among them, the first function signatures of the transaction functions that process the 5 historical transactions are function signature 1, function signature 3, function signature 4, function signature 6 and function signature 8; the total number of transaction events in the 5 historical transactions is 10, and the event signatures of the transaction events are denoted as event signature 1, event signature 2... event signature 10 respectively. Taking tags 1 and 2 as examples, based on the preset association relationship between signatures and tags, it is determined that tag 1 is associated with function signature 1, function signature 4, event signature 3, and event signature 6 in the signatures to be processed; tag 2 is associated with function signature 1, function signature 3, function signature 6, event signature 1, event signature 5, event signature 6, and event signature 10 in the signatures to be processed; tag 1 is associated with function signature 1, function signature 2, and function signature 4 in the second function signature; tag 2 is associated with function signature 1, function signature 3, function signature 5, and function signature 6 in the second function signature. The statistics show that the first number of times tag 1 is associated with the signatures to be processed is 4, and the first number of times tag 2 is associated with the signatures to be processed is 7; the second number of times tag 1 is associated with the second function signature is 3, and the second number of times tag 2 is associated with the second function signature is 4; the first number is 5 + 10 = 15, and the second number is 8. Therefore, the first ratio R of tag 1 being associated with the signatures to be processed can be determined. i =4 / 15, the first ratio R associated with tag 2 and the signature to be processed. i =7 / 15; Tag 1 is associated with the second ratio S of the second function signature. i =3 / 8, the second ratio S associated with tag 2 by the second function signature i =4 / 8; the target ratio T associated with label 1 i = (0.2*(4 / 15)+0.5*(3 / 8)) / (0.2+0.5), the target ratio T associated with label 2 i = (0.2*(7 / 15)+0.5*(4 / 8)) / (0.2+0.5).

[0045] Steps S106-624: The unprocessed label corresponding to the maximum target ratio is determined as the target label that matches the target smart contract.

[0046] Specifically, the target ratios are sorted to obtain the maximum target ratio, and the tag corresponding to the maximum target ratio is determined as the target tag that matches the target smart contract. The sorting process can be either ascending or descending order.

[0047] Step S106-64: Determine whether the target label is a preset risk label; if yes, determine that the target smart contract has a preset risk; if no, determine that the target smart contract does not have a preset risk.

[0048] Specifically, the target label is compared with the preset risk label. If the comparison result shows that there is a risk label that matches the target label, it is determined that the target smart contract has a preset risk; if the comparison result shows that there is no risk label that matches the target label, it is determined that the target smart contract does not have a preset risk.

[0049] In one or more embodiments of this specification, transaction events of N historical transactions completed based on a target smart contract, first function signatures of each transaction function processing these historical transactions, and second function signatures of each transaction function included in the target smart contract are obtained. Based on the tags associated with the obtained transaction events, first function signatures, and second function signatures, the existence of pre-existing risks in the target smart contract is identified. Each transaction function included in the target smart contract processes the corresponding transaction when invoked by the callee through its function signature. Tags are used to characterize the transaction type of the corresponding transaction. Therefore, based on the tags associated with transaction events and function signatures, intelligent identification of whether a smart contract has pre-existing risks is achieved without human intervention, improving the accuracy and efficiency of smart contract risk identification and reducing the management difficulty of smart contracts.

[0050] Corresponding to the risk identification method for smart contracts described above, and based on the same technical concept, one or more embodiments of this specification also provide a risk identification device for smart contracts. Figure 4 This specification provides a schematic diagram of the module composition of a risk identification device for smart contracts, as shown in one or more embodiments. Figure 4 As shown, the device includes:

[0051] The first acquisition module 201 acquires transaction events of N historical transactions based on the target smart contract, and the first function signature of each transaction function that processes the historical transactions; the target smart contract includes multiple transaction functions, and each transaction function processes the corresponding transaction when it is invoked by the callee through the function signature of the transaction function; N is an integer greater than 1.

[0052] The second acquisition module 202 acquires the second function signatures of each transaction function included in the target smart contract; the second function signature includes the first function signature.

[0053] The identification module 203 identifies whether the target smart contract has a preset risk based on the transaction event, the tags associated with the first function signature and the second function signature; the tags are used to characterize the transaction type of the corresponding transaction.

[0054] The smart contract risk identification device provided in one or more embodiments of this specification acquires transaction events of N historical transactions based on a target smart contract, the first function signatures of each transaction function processing the historical transactions, and the second function signatures of each transaction function included in the target smart contract. Based on the tags associated with the acquired transaction events, first function signatures, and second function signatures, it identifies whether the target smart contract has a pre-existing risk. Each transaction function included in the target smart contract processes the corresponding transaction when called by the callee through its function signature. The tags are used to characterize the transaction type of the corresponding transaction. Therefore, based on the tags associated with transaction events and function signatures, intelligent identification of whether a smart contract has a pre-existing risk is achieved without human intervention, improving the accuracy and efficiency of smart contract risk identification and reducing the management difficulty of smart contracts.

[0055] It should be noted that the embodiments of the risk identification device for smart contracts in this specification and the embodiments of the risk identification method for smart contracts in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can refer to the implementation of the corresponding risk identification method for smart contracts mentioned above, and the repeated parts will not be described again.

[0056] Furthermore, corresponding to the risk identification method for smart contracts described above, based on the same technical concept, one or more embodiments of this specification also provide a risk identification device for smart contracts, which is used to execute the aforementioned risk identification method for smart contracts. Figure 5 This is a schematic diagram of the structure of a risk identification device for smart contracts provided in one or more embodiments of this specification.

[0057] like Figure 5 As shown, the risk identification device for smart contracts can vary significantly due to differences in configuration or performance. It may include one or more processors 301 and a memory 302, with the memory 302 storing one or more applications or data. The memory 302 can be temporary or persistent storage. The applications stored in the memory 302 may include one or more modules (not shown), each module including a series of computer-executable instructions from the smart contract's risk identification device. Furthermore, the processor 301 may be configured to communicate with the memory 302, executing the series of computer-executable instructions stored in the memory 302 on the smart contract's risk identification device. The smart contract's risk identification device may also include one or more power supplies 303, one or more wired or wireless network interfaces 304, one or more input / output interfaces 305, one or more keyboards 306, etc.

[0058] In one specific embodiment, the risk identification device for smart contracts includes a memory and one or more programs, wherein one or more programs are stored in the memory, and one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the risk identification device for smart contracts, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following:

[0059] Obtain transaction events for N historical transactions based on the target smart contract, and the first function signature of each transaction function that processes the historical transactions; the target smart contract includes multiple transaction functions, and each transaction function processes the corresponding transaction when called by the callee through the function signature of the transaction function; N is an integer greater than 1;

[0060] Obtain the second function signature of each of the transaction functions included in the target smart contract; the second function signature includes the first function signature;

[0061] Based on the transaction event, the tags associated with the first function signature and the second function signature, it is determined whether the target smart contract has a preset risk; the tags are used to characterize the transaction type of the corresponding transaction.

[0062] The smart contract risk identification device provided in one or more embodiments of this specification acquires transaction events of N historical transactions based on a target smart contract, the first function signatures of each transaction function processing the historical transactions, and the second function signatures of each transaction function included in the target smart contract. Based on the tags associated with the acquired transaction events, first function signatures, and second function signatures, it identifies whether the target smart contract has pre-existing risks. Each transaction function included in the target smart contract processes the corresponding transaction when called by the callee through its function signature. The tags are used to characterize the transaction type of the corresponding transaction. Therefore, based on the tags associated with transaction events and function signatures, intelligent identification of whether a smart contract has pre-existing risks is achieved without human intervention, improving the accuracy and efficiency of smart contract risk identification and reducing the management difficulty of smart contracts.

[0063] It should be noted that the embodiments of the risk identification device for smart contracts in this specification and the embodiments of the risk identification method for smart contracts in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can refer to the implementation of the corresponding risk identification method for smart contracts mentioned above, and the repeated parts will not be described again.

[0064] Furthermore, corresponding to the risk identification method for smart contracts described above, based on the same technical concept, one or more embodiments of this specification also provide a storage medium for storing computer-executable instructions. In a specific embodiment, the storage medium can be a USB flash drive, optical disc, hard disk, etc. When the computer-executable instructions stored in the storage medium are executed by a processor, they can achieve the following process:

[0065] Obtain transaction events for N historical transactions based on the target smart contract, and the first function signature of each transaction function that processes the historical transactions; the target smart contract includes multiple transaction functions, and each transaction function processes the corresponding transaction when called by the callee through the function signature of the transaction function; N is an integer greater than 1;

[0066] Obtain the second function signature of each of the transaction functions included in the target smart contract; the second function signature includes the first function signature;

[0067] Based on the transaction event, the tags associated with the first function signature and the second function signature, it is determined whether the target smart contract has a preset risk; the tags are used to characterize the transaction type of the corresponding transaction.

[0068] The computer-executable instructions stored in the storage medium provided in one or more embodiments of this specification, when executed by a processor, acquire transaction events of N historical transactions based on the target smart contract, first function signatures of each transaction function processing the historical transactions, and second function signatures of each transaction function included in the target smart contract. Based on the acquired transaction events and the tags associated with the first and second function signatures, the instructions identify whether the target smart contract has any pre-existing risks. Each transaction function included in the target smart contract processes the corresponding transaction when called by the callee through its function signature. The tags characterize the transaction type of the corresponding transaction. This achieves intelligent identification of whether a smart contract has pre-existing risks without human intervention, improving the accuracy and efficiency of smart contract risk identification and reducing the management difficulty of smart contracts.

[0069] It should be noted that the embodiments concerning storage media in this specification and the embodiments concerning risk identification methods for smart contracts in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can refer to the implementation of the corresponding risk identification methods for smart contracts mentioned above, and the repeated parts will not be described again.

[0070] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

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

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

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

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

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

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

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

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

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

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

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

[0082] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

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

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

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

Claims

1. A method for risk identification of a smart contract, comprising: obtaining transaction events of N historical transactions reached based on a target smart contract, and processing first function signatures of each transaction function of the historical transactions; the target smart contract comprises a plurality of transaction functions, each of the transaction functions performs transaction processing on a corresponding transaction when being called by a calling party through a function signature of the transaction function; and N is an integer greater than 1; obtaining second function signatures of each of the transaction functions included in the target smart contract; the second function signatures include the first function signatures; identifying whether the target smart contract has a preset risk according to labels associated with the transaction events, the first function signatures and the second function signatures; the labels are used to represent transaction types of corresponding transactions; wherein the identifying whether the target smart contract has a preset risk according to labels associated with the transaction events, the first function signatures and the second function signatures comprises: obtaining an event signature of each of the transaction events from each of the transaction events; determining each of the first function signatures and each of the event signatures as a to-be-processed signature, determining a first candidate label associated with each of the to-be-processed signatures and a second candidate label associated with each of the second function signatures based on a preset association relationship between signatures and labels; identifying whether the target smart contract has a preset risk according to the first candidate label and the second candidate label; the identifying whether the target smart contract has a preset risk according to the first candidate label and the second candidate label comprises: determining a target label matched with the target smart contract from the first candidate label and the second candidate label; determining whether the target label is a preset risk label; if yes, determining that the target smart contract has a preset risk. 2.The method of claim 1, after the determining whether the target label is a preset risk label, the method further comprises: if it is determined that the target label is not a preset risk label, determining that the target smart contract does not have a preset risk. 3.The method of claim 2, the determining a target label matched with the target smart contract from the first candidate label and the second candidate label comprises: determining each of the first candidate label and the second candidate label as a to-be-processed label, and determining a target ratio associated with each of the to-be-processed label; determining a to-be-processed label corresponding to a maximum target ratio as the target label matched with the target smart contract. 4.The method of claim 3, the determining each of the first candidate label and the second candidate label as a to-be-processed label, and determining a target ratio associated with each of the to-be-processed label comprises: determining a first ratio associated with each of the first candidate label by the to-be-processed signature; determining a second ratio associated with each of the second candidate label by the second function signature; and determine the first candidate label and the second candidate label as a to-be-processed label, and determine a target ratio of association of each of the to-be-processed label according to the first ratio and the second ratio.

5. The method of claim 4, wherein the determining the first ratio of association of each of the first candidate label by the to-be-processed signature comprises: counting a first number of times of association of each of the first candidate label by the to-be-processed signature; counting a first number of the to-be-processed signature; determining the first ratio of association of each of the first candidate label by the to-be-processed signature according to the first number of times and the first number; the determining the second ratio of association of each of the second candidate label by the second function signature comprises: counting a second number of times of association of each of the second candidate label by the second function signature; counting a second number of the second function signature; determining the second ratio of association of each of the second candidate label by the second function signature according to the second number of times and the second number.

6. The method of claim 4, there being a same candidate label in the first candidate label and the second candidate label. the determining the target ratio of association of each of the to-be-processed label according to the first ratio and the second ratio comprises: determining the first ratio and the second ratio corresponding to each of the to-be-processed label; performing weighted average processing on the first ratio and the second ratio corresponding to each of the to-be-processed label to obtain the target ratio of association of each of the to-be-processed label.

7. The method of claim 1, wherein the obtaining transaction events of N historical transactions based on a target smart contract and processing first function signatures of each transaction function of the historical transactions comprises: obtaining transaction records of the last N historical transactions associated according to the order of transaction time from the saved transaction records of each historical transaction according to the contract identifier of the target smart contract; extracting the first function signature of the transaction function processing the corresponding historical transaction from each of the transaction records, and extracting the transaction event if it is determined that the transaction record includes the transaction event.

8. The method of claim 1, wherein the obtaining the second function signature of each of the transaction functions included in the target smart contract comprises: obtaining the bytecode of the target smart contract; performing decompilation processing on the bytecode to obtain a processing result; analyzing the processing result to obtain the second function signature of each of the transaction functions included in the target smart contract.

9. A risk identification device for a smart contract, comprising: a first obtaining module for obtaining transaction events of N historical transactions based on a target smart contract and processing first function signatures of each transaction function of the historical transactions; the target smart contract includes a plurality of transaction functions, each of which performs transaction processing on a corresponding transaction when called by a calling party through the function signature of the transaction function; and the N is an integer greater than 1; a second obtaining module for obtaining second function signatures of each of the transaction functions included in the target smart contract; the second function signature includes the first function signature. The identification module identifies whether the target smart contract has a preset risk according to labels associated with the transaction event, the first function signature, and the second function signature; the labels are used to represent transaction types of corresponding transactions. The identification of whether the target smart contract has a preset risk according to the labels associated with the transaction event, the first function signature, and the second function signature comprises: An event signature of the transaction event is obtained from each of the transaction events; Each of the first function signatures and each of the event signatures is determined as a to-be-processed signature, and a first candidate label associated with each of the to-be-processed signatures and a second candidate label associated with each of the second function signatures are determined based on a preset association relationship between signatures and labels; Whether the target smart contract has a preset risk is identified according to the first candidate label and the second candidate label; The identification of whether the target smart contract has a preset risk according to the first candidate label and the second candidate label comprises: A target label matched with the target smart contract is determined from the first candidate label and the second candidate label; Whether the target label is a preset risk label is determined; If yes, it is determined that the target smart contract has a preset risk. 10.A risk identification device of a smart contract, characterized in that, The processor; and The memory arranged to store computer-executable instructions that, when executed, cause the processor to: Obtain transaction events based on N pieces of historical transactions reached by a target smart contract, and obtain first function signatures of each transaction function of the historical transactions; the target smart contract comprises a plurality of transaction functions, each of the transaction functions performs transaction processing on a corresponding transaction when being called by a calling party through a function signature of the transaction function; N is an integer greater than 1; Obtain second function signatures of each of the transaction functions included in the target smart contract; the second function signatures include the first function signatures; Identify whether the target smart contract has a preset risk according to labels associated with the transaction event, the first function signature, and the second function signature; the labels are used to represent transaction types of corresponding transactions. The identification of whether the target smart contract has a preset risk according to the labels associated with the transaction event, the first function signature, and the second function signature comprises: An event signature of the transaction event is obtained from each of the transaction events; Each of the first function signatures and each of the event signatures is determined as a to-be-processed signature, and a first candidate label associated with each of the to-be-processed signatures and a second candidate label associated with each of the second function signatures are determined based on a preset association relationship between signatures and labels; Whether the target smart contract has a preset risk is identified according to the first candidate label and the second candidate label; The identification of whether the target smart contract has a preset risk according to the first candidate label and the second candidate label comprises: A target label matched with the target smart contract is determined from the first candidate label and the second candidate label; ​ ​ determining whether the target label is a preset risk label; if yes, determining that the target smart contract has a preset risk. 11.A storage medium, configured to store computer executable instructions, which, when executed by a processor, implement the following process: obtaining transaction events based on N pieces of historical transactions of a target smart contract, and processing first function signatures of each transaction function of the historical transactions; the target smart contract comprises a plurality of transaction functions, each of which, when called by a calling party through a function signature of the transaction function, performs transaction processing on a corresponding transaction; N is an integer greater than 1; obtaining second function signatures of each transaction function included in the target smart contract; the second function signatures comprise the first function signatures; according to labels associated with the transaction events, the first function signatures and the second function signatures, identifying whether the target smart contract has a preset risk; the labels are used to represent transaction types of corresponding transactions; wherein, according to the labels associated with the transaction events, the first function signatures and the second function signatures, identifying whether the target smart contract has a preset risk comprises: obtaining event signatures of the transaction events from each of the transaction events; determining each of the first function signatures and each of the event signatures as a to-be-processed signature, determining a first candidate label associated with each of the to-be-processed signatures and a second candidate label associated with each of the second function signatures based on a preset association relationship between signatures and labels; according to the first candidate label and the second candidate label, identifying whether the target smart contract has a preset risk; according to the first candidate label and the second candidate label, identifying whether the target smart contract has a preset risk comprises: determining a target label matched with the target smart contract from the first candidate label and the second candidate label; determining whether the target label is a preset risk label; if yes, determining that the target smart contract has a preset risk.

Images