Block chain-based anomaly detection method and related equipment

Abstract

The embodiment of the invention provides a blockchain-based anomaly detection method and related equipment, at least one smart contract is deployed on a blockchain, and the method comprises the steps of obtaining execution parameters of transaction data in a process of being executed by a target smart contract; obtaining M isolation forests; selecting K prediction isolation trees from the M isolation forests, and determining the path depth of the transaction data in each prediction isolation tree and the node value of a corresponding leaf node of the transaction data in each prediction isolation tree based on the index data of P dimensions included in the execution parameters; according to the path depth of the transaction data in each prediction isolation tree and the node value of the transaction data in the corresponding leaf node in each prediction isolation tree, determining the prediction value of the transaction data in each isolation forest; and performing anomaly detection on the target smart contract according to the predicted value of the transaction data in each isolation forest to obtain a detection result. According to the embodiment of the invention, anomaly detection can be performed on the smart contract.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and specifically to a blockchain-based anomaly detection method and related equipment. Background Art

[0002] Blockchain is a combination of innovative technologies, including distributed data storage, smart contracts, consensus mechanisms, encryption algorithms, and other technologies. Its core mechanism is a distributed accounting technology maintained by multiple parties in an untrusted competitive environment. It has the characteristics of openness, tamper-proofing, anonymity, decentralization, and traceability, which can greatly expand the breadth and depth of people's collaboration.

[0003] However, current blockchains (such as consortium chains) find it difficult to manage and perceive anomalies and problems in smart contracts, which may result in problematic smart contracts not being detected for a long time, and their continued execution affecting the operation of existing blockchain node devices. Summary of the Invention

[0004] The embodiments of the present application provide a blockchain-based anomaly detection method and related equipment, which can perform anomaly detection on smart contracts.

[0005] In one aspect, an embodiment of the present application provides a blockchain-based anomaly detection method, wherein at least one smart contract is deployed on the blockchain, and the method includes:

[0006] Obtain the execution parameters of the transaction data during the execution of the target smart contract. The execution parameters include indicator data of p dimensions; p is a positive integer; the target smart contract is any smart contract in at least one smart contract;

[0007] Obtain M isolation forests. Isolation forests are constructed based on sample execution parameters of sample transaction data during smart contract execution. Each isolation forest contains n isolation trees, where n is an integer greater than 1 and M is a positive integer.

[0008] Select K prediction isolation trees from M isolation forests, and determine the path depth of the transaction data in each prediction isolation tree and the node value of the corresponding leaf node of the transaction data in each prediction isolation tree based on the indicator data of P dimensions; K is a positive integer and K is less than or equal to n×M;

[0009] Determine the predicted value of the transaction data in each isolation forest based on the path depth of the transaction data in each prediction isolation tree and the node value of the corresponding leaf node in each prediction isolation tree;

[0010] According to the predicted values ​​of transaction data in each isolation forest, anomaly detection is performed on the target smart contract to obtain the detection results.

[0011] In one aspect, an embodiment of the present application provides a blockchain-based anomaly detection device, wherein at least one smart contract is deployed on the blockchain, and the device includes:

[0012] An acquisition unit, configured to acquire execution parameters of the transaction data during execution by the target smart contract, wherein the execution parameters include indicator data of p dimensions; p is a positive integer; and the target smart contract is any smart contract among the at least one smart contract;

[0013] The acquisition unit is further used to obtain M isolation forests. The isolation forests are constructed based on sample execution parameters of the sample transaction data during the execution of the smart contract. Each isolation forest includes n isolation trees, where n is an integer greater than 1; and M is a positive integer.

[0014] a processing unit, configured to select K prediction isolation trees from the M isolation forests, and determine, based on the indicator data of the P dimensions, the path depth of the transaction data in each prediction isolation tree and the node value of the leaf node corresponding to the transaction data in each prediction isolation tree; K is a positive integer, and K is less than or equal to n×M;

[0015] The processing unit is further configured to determine a predicted value of the transaction data in each isolation forest based on a path depth of the transaction data in each prediction isolation tree and a node value of a leaf node corresponding to the transaction data in each prediction isolation tree;

[0016] The processing unit is further used to perform anomaly detection on the target smart contract based on the predicted value of the transaction data in each isolation forest to obtain a detection result.

[0017] In one aspect, an embodiment of the present application provides a computer device, comprising:

[0018] a processor suitable for executing a computer program;

[0019] A computer-readable storage medium having a computer program stored therein. When the computer program is executed by a processor, the above-mentioned blockchain-based anomaly detection method is implemented.

[0020] On the one hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program, and the computer program is loaded by a processor and executes the above-mentioned blockchain-based anomaly detection method.

[0021] On the one hand, an embodiment of the present application provides a computer program product, which includes a computer program or computer instructions, and when the computer program or computer instructions are executed by a processor, implements the above-mentioned blockchain-based anomaly detection method.

[0022] In an embodiment of the present application, at least one smart contract is deployed on the blockchain, and execution parameters of transaction data during the execution process of the target smart contract are obtained, and the execution parameters include index data of p dimensions; p is a positive integer; the target smart contract is any smart contract in the at least one smart contract; then, M isolation forests are obtained, and the isolation forest is constructed based on the sample execution parameters of the sample transaction data during the execution process of the smart contract; each isolation forest includes n isolation trees, n is an integer greater than 1; M is a positive integer; K predicted isolation trees are selected from the M isolation forests, and based on the index data of P dimensions, the path depth of the transaction data in each predicted isolation tree and the node value of the corresponding leaf node of the transaction data in each predicted isolation tree are determined; K is a positive integer, and K is less than or equal to n×M; according to the path depth of the transaction data in each predicted isolation tree and the node value of the corresponding leaf node of the transaction data in each predicted isolation tree, the predicted value of the transaction data in each isolation forest is determined; according to the predicted value of the transaction data in each isolation forest, anomaly detection is performed on the target smart contract to obtain a detection result. It can be seen that the embodiment of the present application realizes unsupervised detection of smart contracts by constructing an isolation forest through the sample execution parameters of sample transaction data, which avoids the time-consuming labeling caused by supervised learning. At the same time, through the indicator data of transaction data in different dimensions, the path depth of transaction data in the predicted isolation tree and the node value of the corresponding leaf node can be predicted more accurately. In this way, the predicted value of transaction data in each isolation forest can be determined according to the path depth and node value, and then the smart contract can be effectively detected for anomalies based on the predicted value. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0024] Figure 1A An architectural diagram of a blockchain-based anomaly detection system provided in an embodiment of the present application;

[0025] Figure 1B A schematic diagram of a blockchain provided in an embodiment of the present application;

[0026] Figure 1C A schematic diagram of a block generation process provided in an embodiment of the present application;

[0027] Figure 2 A schematic diagram of the structure of an anomaly detection device provided in an embodiment of the present application;

[0028] Figure 3AA schematic diagram of a process for constructing an isolation forest provided in an embodiment of the present application;

[0029] Figure 3B A schematic diagram of uploading initial sample execution parameters provided in an embodiment of the present application;

[0030] Figure 4 A flowchart of anomaly detection based on isolation forests provided in an embodiment of the present application;

[0031] Figure 5 A schematic diagram of an optimization process for an isolation forest provided in an embodiment of the present application;

[0032] Figure 6 A flowchart of a blockchain-based anomaly detection method provided in an embodiment of the present application;

[0033] Figure 7 A schematic diagram of an isolation tree provided in an embodiment of the present application;

[0034] Figure 8 A schematic diagram of a process for determining an anomaly score provided in an embodiment of the present application;

[0035] Figure 9 A schematic diagram of a process for constructing an isolation forest provided in an embodiment of the present application;

[0036] Figure 10A A schematic diagram of a process for updating a target isolation tree provided in an embodiment of the present application;

[0037] Figure 10B A schematic diagram of a process for updating a target isolation tree provided in an embodiment of the present application;

[0038] Figure 10C A schematic diagram of a process for updating an isolation tree provided in an embodiment of the present application;

[0039] Figure 11 A schematic diagram of the structure of a blockchain-based anomaly detection device provided in an embodiment of the present application;

[0040] Figure 12 A schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0041] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0042] The present application embodiment relates to a blockchain network, such as Figure 1A The blockchain network 101 shown is a network used for data sharing between node devices, and the blockchain network may include multiple node devices. Each node device can receive input transaction data during normal operation and maintain the shared data within the blockchain network based on the received transaction data. To ensure information interoperability within the blockchain network, information connections can exist between each node device in the blockchain network, and information can be transmitted between node devices through such information connections. For example, when any node device in the blockchain network receives input transaction data, the other node devices in the blockchain network obtain the input transaction data according to the consensus algorithm and store the transaction data as data in the shared data, so that the data stored on all node devices in the blockchain network is consistent.

[0043] Each node device in a blockchain network has a corresponding node identifier, and each node device in the blockchain network can store the node identifiers of other node devices in the blockchain network so that the generated blocks can be broadcast to other node devices in the blockchain network based on the node identifiers of other node devices. Each node device can maintain a node identifier list as shown in the table below, and the node device name and node identifier are stored in the node identifier list. The node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address or any other information that can be used to identify the node device. Table 1 only uses the IP address as an example for explanation.

[0044] Table 1

[0045] Node device name Node ID Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N XXX.XXX.XXX.XXX

[0046] Every node in a blockchain network stores an identical blockchain. Blockchain is a novel application model that combines distributed data storage, peer-to-peer transmission, consensus mechanisms, encryption algorithms, and other computer technologies. Blockchain is essentially a decentralized database, a series of data blocks linked using cryptographic methods. Each block contains information about a batch of network transactions, which is used to verify the validity of the information (to prevent counterfeiting) and generate the next block.

[0047] The blockchain consists of multiple blocks, see Figure 1BThe blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the characteristic value, version number, timestamp, and difficulty value of the input transaction data, and the block body stores a set of transaction data. The next block of the genesis block uses the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the characteristic value of the input transaction data of the current block, the characteristic value of the block header of the parent block, the version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input transaction data in the block. It should be understood that the blockchain includes blocks for storing transaction data and may also include configuration blocks. The configuration blocks are used to store configuration information for all node devices. Configuration information may include, but is not limited to, certificate information.

[0048] When generating each block in the blockchain, see Figure 1C When the node device of the blockchain receives the input transaction data, it verifies the input transaction data. After the verification is completed, the input transaction data is stored in the transaction pool and the hash tree used to record the input transaction data is updated. The transaction pool (also known as the memory pool or mempool) is a data structure in the blockchain network that is used to store pending transactions that have not yet been packaged into blocks. When an object submits a new transaction to the data blockchain network, the transaction data will first enter the transaction pool. When the node device corresponding to the blockchain is preparing to generate a new block, it will select a certain amount of transaction data from the transaction pool for packaging. The transaction pool helps to improve the processing capacity of the blockchain network. It can also be used as a strategy to give priority to packaging transaction data with higher handling fees. Afterwards, the update timestamp is updated to the time when the input transaction data is received, and different random numbers are tried, and the eigenvalue calculation is performed multiple times so that the calculated eigenvalue can satisfy the following formula:

[0049] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET

[0050] Among them, SHA256 is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block; merkle_root is the eigenvalue of the input transaction data; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value within a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the eigenvalue threshold, which can be determined based on nbits.

[0051] In this way, when a random number that satisfies the above formula is calculated, the transaction data can be stored accordingly, and the block header and block body can be generated to obtain the current block. Subsequently, the node device of the blockchain will send the newly generated block to other node devices in the blockchain network according to the node identification of other node devices in the blockchain network. The other node devices will verify the newly generated block and add it to the blockchain they store after verification.

[0052] Blockchains primarily include private, public, and consortium chains. Private chains are typically deployed within a single organization and are suitable for internal data management and auditing. Consensus nodes are all internal to the organization. Private chains generally have smaller network sizes, making them more efficient than consortium chains and even comparable in performance to centralized databases. Public chains are the most open and decentralized types of blockchains. In public chains, data storage, updates, maintenance, and operations no longer rely on a centralized server, but rather on every network node. This means that data on public chains is recorded and maintained by thousands of nodes across the global internet, making it impossible for entities to tamper with the data. Consortium chains are typically comprised of multiple organizations with similar industry backgrounds. Application scenarios include payment settlements between multiple banks and supply chain management between various enterprises. Consensus nodes in consortium chains come from various organizations within the consortium, and the number of nodes is far smaller than in public chains. A blockchain can host at least one smart contract. A smart contract is a computer protocol designed to communicate, verify, or enforce contracts in an information-based manner. Smart contracts allow for trusted transactions without a third party, with traceable and irreversible transaction data. Different transaction data will correspond to different smart contracts. For example, if the transaction data is resource exchange, then the smart contract is used for resource exchange; if the transaction data is risk assessment, then the smart contract is used for risk assessment. By deploying smart contracts, the corresponding transaction data can be processed.

[0053] However, currently, it is difficult to manage and detect anomalies and problems in smart contracts for blockchains (such as consortium chains). Although some solutions can detect anomalies in smart contracts, such as using supervised training models to troubleshoot smart contracts, this requires large-scale data annotation in advance, which is time-consuming and labor-intensive, and has high requirements for data volume. In other words, in the process of anomaly detection in smart contracts, supervised learning methods with large amounts of labeled data are relied upon. This requires a large amount of labeled data for training models. However, in the blockchain environment, since abnormal behaviors can be rare and diverse, obtaining a large amount of accurately labeled anomaly data is very difficult. In addition, manually annotating data is a time-consuming and error-prone process, which leads to the problem that it takes a long time to detect anomalies in smart contracts. Due to the difficulty in detecting and troubleshooting anomalies, abnormal smart contracts or transaction data cannot be detected for a long time, and their continued execution affects the operation of the corresponding node devices of the existing blockchain. Based on this, an embodiment of the present application provides a blockchain-based anomaly detection solution. This blockchain-based anomaly detection solution can use an unsupervised learning approach to construct an anomaly detection model based on an isolation forest. That is, the isolation forest is constructed using indicator data such as CPU usage, network I / O, and contract size during the execution of the smart contract on the blockchain, thereby obtaining an anomaly detection model. The anomaly detection model may include one or more isolation forests. Afterwards, the isolation forest in the anomaly detection model is used to predict the transaction data based on the execution parameters of the transaction data during the execution of the target smart contract, and the predicted value of the transaction data in the isolation forest is obtained. Then, based on the predicted value of the transaction data in the isolation forest, anomaly detection is performed on the target smart contract.

[0054] In some implementations, during the anomaly detection process, the embodiments of the present application provide a time-weighted dynamic adjustment mechanism to assign different weights to the predicted values ​​of transaction data in each isolation forest, thereby improving the accuracy of anomaly detection for the target smart contract. The time-weighted adjustment mechanism is specifically as follows: when there are multiple isolation forests, each isolation forest corresponds to a sampling time interval, and different weights can be assigned to the predicted values ​​of transaction data in each isolation forest based on the time interval between the execution time of the transaction data and the sampling time interval corresponding to each isolation forest. Among them, the smaller the time interval, the closer the execution time of the current transaction data is to the corresponding sampling time interval, and the predicted value of the transaction data in the isolation forest will be assigned a higher weight. Finally, different weights are assigned based on the predicted values ​​of the transaction data in each isolation forest to determine the anomaly score of the smart contract during execution. Based on the anomaly score, it can be determined whether the transaction data or the target smart contract has an anomaly.

[0055] Furthermore, the solution provided by the embodiments of this application can also optimize the anomaly detection model, specifically by updating each isolation forest within the anomaly detection model, thereby improving the isolation forest's adaptability to emerging anomaly patterns. Specifically, the latest transaction data can be obtained from the transaction data stream, and each isolation forest can be updated based on the execution parameters of the latest transaction data during smart contract execution to obtain the latest anomaly detection model, thereby improving the isolation forest's adaptability to emerging anomaly patterns.

[0056] In summary, the blockchain-based anomaly detection solution provided by the embodiment of the present application can have the following beneficial effects: (1) Effective anomaly detection of smart contracts: The solution provided by the embodiment of the present application adopts the isolation forest algorithm of unsupervised learning, which does not require large-scale labeled data. It solves the time-consuming and labor-intensive problem of relying on supervised learning to train the model with a large amount of labeled data. It also solves the problem of difficulty in obtaining sufficient labeled data in the blockchain environment, and achieves more effective detection of abnormal behavior in smart contracts. It can adapt to new data patterns and significantly reduce the workload and cost of data preparation. (2) Improve the accuracy of anomaly detection of smart contracts through the time-weighted dynamic adjustment mechanism: This solution introduces a time-weighted dynamic adjustment mechanism, which enables the weight of transaction data in each isolation forest to be dynamically adjusted according to the execution time of the transaction data. In this way, the accuracy of anomaly detection of smart contracts can be improved. (3) The isolation forest can be updated in real time based on the latest transaction data, which improves the adaptability of the isolation forest to newly emerging abnormal patterns and also ensures the accuracy and stability of the isolation forest model in long-term operation. (4) Efficient anomaly detection performance: The data involved in the execution of smart contracts is usually multidimensional, and traditional machine learning algorithms may require complex feature engineering or face dimensionality disasters when processing such data. This not only increases the time cost of model training and prediction, but may also lead to a decline in model performance. Therefore, the isolation forest algorithm used in the embodiment of the present application can process high-dimensional data and can show relatively efficient computing performance in anomaly detection. In addition, due to the low computational complexity of the isolation forest algorithm, this solution can quickly analyze multi-dimensional indicator data during the execution of smart contracts, promptly discover potential abnormal behaviors, and thus ensure the stable operation of the blockchain system.

[0057] To facilitate understanding, the relevant technical terms provided in the embodiments of this application are explained below.

[0058] 1. Unsupervised Learning

[0059] Unsupervised learning is a method of machine learning that models data without labeled data (i.e., data without a given correct answer or result). The goal of unsupervised learning is to discover hidden structures, patterns, or associations in the data. In the scenario of anomaly detection, unsupervised learning algorithms attempt to identify data points that are significantly different from the majority of the data without knowing in advance which data points are normal and which are abnormal. In an embodiment of the present application, unsupervised learning is used to identify whether a smart contract is an anomaly.

[0060] 2. Isolation Forest

[0061] Isolation Forest is an ensemble learning algorithm based on isolation trees that can be used for anomaly detection. It consists of multiple isolation trees, each of which is constructed independently. When constructing each isolation tree, the Isolation Forest algorithm randomly selects a subsample from the dataset and randomly chooses a feature along a dimension and its corresponding split value to isolate the data point. The algorithm determines whether a data point is anomalous by evaluating its average path length across all isolation trees. A shorter average path length generally indicates that the data point is more likely to be an anomaly. The Isolation Forest algorithm is efficient when processing high-dimensional data and large datasets and does not require prior knowledge, making it well-suited for unsupervised anomaly detection.

[0062] The isolation tree is a specific data structure used in the isolation forest algorithm. It is a binary tree that isolates data points by recursively selecting a dimension feature and a corresponding split value. In each iteration, the dataset is divided into two subsets until every data point is isolated at a leaf node of the isolation tree or a preset limit is reached. The core idea of ​​the isolation tree is that outliers, due to their small number and uniqueness, are usually isolated earlier. Therefore, their paths in the isolation tree are shorter than those of normal data points. In other words, the path depth of outliers in the isolation tree is smaller than that of normal data points. The so-called path depth refers to the length of the path from the root node to the target tree node in the isolation tree.

[0063] In an embodiment of the present application, sample execution parameters of sample transaction data during the execution of the smart contract can be obtained. The sample execution parameters may include sample indicator data of P dimensions, that is, the sample indicator data of each dimension can be used as a feature of a dimension to segment the sample transaction data, thereby constructing an isolation tree, and then constructing an isolation forest for anomaly detection of smart contracts.

[0064] 3. Sample execution parameters

[0065] Sample execution parameters include indicator data that the sample transaction data needs to involve in the smart contract execution process. Indicator data can refer to some resource data (such as hardware resource data, time resources, etc.) during the sample transaction data execution process. Specifically, the sample execution parameters include indicator data of at least one of the following dimensions: CPU usage, memory usage, disk I / O, network I / O, number of contract calls, contract execution time, contract call depth, contract size, contract complexity, contract transaction fees, etc. The following describes these indicator data separately:

[0066] 1.CPU usage (%)

[0067] CPU utilization refers to the percentage of CPU resources used during smart contract execution. A high CPU utilization rate may indicate that the smart contract's computational workload is excessive or inefficient. Specifically, if the CPU utilization rate is greater than the utilization threshold, the CPU utilization rate is considered excessive. Conversely, if the CPU utilization rate is less than or equal to the utilization threshold, the CPU utilization rate is considered low.

[0068] 2. Memory usage (%):

[0069] Memory usage refers to the percentage of memory resources occupied during smart contract execution. A high memory usage rate may indicate excessive data processing workload or a memory leak. A memory leak occurs when dynamically allocated heap memory within a program is not released or cannot be released for some reason, resulting in wasted system memory and potentially causing serious consequences such as program slowdowns or even system crashes. Specifically, if the memory usage rate is greater than the memory usage threshold, it is considered excessive; conversely, if the memory usage rate is less than or equal to the memory usage threshold, it is considered low.

[0070] 3. Disk I / O (MB / s):

[0071] Disk I / O refers to the speed of disk reads and writes during smart contract execution, measured in megabytes per second. If disk I / O is too high, it may indicate that the smart contract is overloaded with data reads and writes. Specifically, if disk I / O is greater than the disk threshold, it is considered too high.

[0072] 4. Network I / O (MB / s):

[0073] Network I / O refers to the speed of network usage during smart contract execution, measured in megabytes per second. If the network I / O is too high, it may mean that the smart contract is overloaded with network communication tasks. Specifically, if the network I / O is greater than the network threshold, the network I / O is considered too high.

[0074] 5. Number of contract calls (times):

[0075] The number of contract calls refers to the frequency with which a smart contract is called. If the number of smart contract calls is too high (for example, the number of smart contract calls is greater than the threshold), it is considered that the number of smart contract calls is too high, which may mean that the smart contract is used too frequently.

[0076] 6. Contract execution time (seconds):

[0077] Contract execution time refers to the time from the start to the end of a smart contract's execution, measured in seconds. If a smart contract's execution time is too long, it may indicate inefficiency. Specifically, if the smart contract's execution time exceeds the time threshold, the smart contract's execution time is considered excessive.

[0078] 7. Contract call depth (layer):

[0079] The contract call depth refers to the depth at which a smart contract calls other smart contracts. For example, if smart contract 1 calls smart contract 2, and smart contract 2 calls smart contract 3, then the contract call depth of smart contract 1 is 2. If the contract call depth is too deep, it may mean that the smart contract's logic is highly complex. Specifically, if the contract call depth exceeds the depth threshold, the contract call depth is considered too deep.

[0080] 8. Contract size (KB):

[0081] Contract size refers to the length or byte size of the smart contract's code, measured in kilobytes. A large contract size may indicate high code complexity. Specifically, a smart contract is considered too large if its contract size exceeds the contract threshold.

[0082] 9. Contract complexity:

[0083] Contract complexity refers to the number of functions in a smart contract. A high contract complexity may indicate high code complexity, while a low contract complexity may indicate low code complexity. Specifically, if the contract complexity exceeds the complexity threshold, the contract complexity is considered high.

[0084] 10. Contract transaction fees:

[0085] Contract transaction fees refer to the transaction fees required to execute a smart contract. If a smart contract's contract transaction fee is too high, it may indicate that the smart contract's execution cost is high; conversely, if a smart contract's contract transaction fee is low, it may indicate that the smart contract's execution cost is low. Specifically, if a smart contract's contract transaction fee is greater than the fee threshold, the smart contract's contract transaction fee is considered too high.

[0086] 4. Anomaly Detection

[0087] Anomaly detection is the process of identifying data points, events, or observations in a dataset that do not conform to expected patterns. These unpredictable data points are often called anomalies or outliers and can be caused by measurement errors, system flaws, or new, unknown behavior. In the context of blockchain smart contracts, anomaly detection is used to identify possible errors, vulnerabilities, or malicious behavior in smart contracts, which could threaten the security and stability of the blockchain network.

[0088] It should be understood that the blockchain-based anomaly detection solution provided in the embodiments of this application can be applied in various scenarios, including but not limited to consortium chain smart contract monitoring and security audit scenarios, financial scenarios, smart contract development and deployment scenarios, blockchain service provider scenarios, supply chain scenarios, IoT and blockchain integration scenarios, etc. The following describes in detail the application of the solution provided in the embodiments of this application in various scenarios:

[0089] 1. Alliance chain smart contract monitoring and security audit

[0090] In a consortium blockchain, multiple organizations jointly manage the blockchain network, and smart contracts are key to implementing business logic. This solution can be integrated into the consortium blockchain's monitoring system to monitor smart contract execution in real time and promptly detect and report abnormal behavior, such as performance bottlenecks, resource misuse, or potential security vulnerabilities. By integrating an unsupervised anomaly detection solution based on isolation forests, real-time monitoring and security auditing of blockchain smart contracts are achieved, significantly improving the efficiency and accuracy of detecting abnormal smart contract behavior. This provides an efficient and reliable smart contract risk management solution for consortium blockchains and other blockchain environments.

[0091] 2. Fraud Detection in Financial Services

[0092] In financial scenarios, such as on financial blockchain platforms, smart contracts are often used to process complex transaction data (financial transactions and contracts). This solution can help financial institutions detect potential fraud, such as unusual transaction patterns or unusual fund flows during smart contract execution, thereby protecting user assets and complying with regulatory requirements.

[0093] 3. Quality Assurance of Smart Contract Development and Deployment

[0094] During the development and deployment phases of smart contracts, this solution can serve as a quality assurance tool, helping developers and auditors identify potential issues and performance bottlenecks in smart contracts. By performing unsupervised anomaly detection on developed smart contracts, issues can be prevented and fixed before they go live, ensuring the stability and security of smart contracts.

[0095] 4. Value-added services provided by blockchain service providers

[0096] In the blockchain service provider scenario, Blockchain as a Service (BaaS) providers can offer this solution as a value-added service to their clients. Clients can leverage this service to enhance the security of their blockchain applications without having to build their own anomaly detection systems from scratch. Blockchain as a Service (BaaS) embeds the blockchain framework into a cloud computing platform, leveraging the deployment and management advantages of cloud service infrastructure to provide developers with a convenient, high-performance blockchain ecosystem and supporting services, supporting business expansion and operational support.

[0097] 5. Abnormal behavior detection in supply chain management

[0098] In supply chain scenarios, such as blockchain-based supply chain management systems, smart contracts are used to automate transaction execution and logging. This solution can be used to monitor smart contract execution, ensuring that each step in the supply chain follows predetermined rules and promptly detecting and responding to anomalies, such as inconsistent cargo data. This solution can ensure security throughout the supply chain.

[0099] 6. Integration of the Internet of Things (IoT) and blockchain

[0100] In scenarios where Internet of Things (IoT) devices are combined with blockchain technology, smart contracts are used to process device data and execute automated tasks. This solution can help detect anomalies in device data processing, such as device failures or data tampering, and safeguard the integrity and security of the entire system.

[0101] In summary, the above application scenarios demonstrate the broad applicability of this solution across various industries and environments, particularly in blockchain applications that require high security and stability. Through real-time anomaly detection and adaptive model optimization, this solution can improve the reliability of smart contracts, reduce operational risks, and enhance the user experience.

[0102] Next, the blockchain-based anomaly detection system provided in the embodiments of the present application is described.

[0103] See Figure 1A , is an architectural diagram of a blockchain-based anomaly detection system provided in an embodiment of the present application. The blockchain-based anomaly detection system includes a blockchain network 101 and an anomaly detection device 102, wherein the anomaly detection device 102 can exchange information with the blockchain network 101. Among them:

[0104] Node devices in the blockchain network can call smart contracts deployed on the blockchain to execute transaction data and generate blocks. The transaction data will involve execution parameters during the smart contract execution process. These execution parameters can be indicators of various dimensions, such as CPU usage, memory usage, contract size, and so on. Node devices can collect the execution parameters generated by the transaction data during the smart contract execution process and send them to the anomaly detection device 102.

[0105] The anomaly detection device 102 is used to detect anomalies in transaction data or smart contracts. Specifically, the anomaly detection device 102 is used to detect anomalies in the transaction data or smart contracts based on the execution parameters of the transaction data sent by the node device during the execution of the smart contract. In addition, the anomaly detection device 102 can deploy an anomaly detection model for detecting anomalies in smart contracts or transaction data. The anomaly detection model can include one or more isolation forests. The anomaly detection device 102 can use each isolation forest to predict the transaction data based on the execution parameters of the transaction data during the execution of the smart contract, and then determine whether the smart contract has abnormal behavior based on the predicted value.

[0106] Among them, the node device and the anomaly detection device 102 can be a terminal device or a server. The terminal device can include but is not limited to: smart phones, tablet computers, smart wearable devices, smart voice interaction devices, smart home appliances, personal computers, vehicle-mounted terminals, smart cameras, virtual reality devices (such as AR (Augmented Reality, augmented reality) devices) and other devices, and this application does not impose any restrictions on this. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network, content distribution network), and big data and artificial intelligence platforms.

[0107] It should be understood that the anomaly detection device 102 can be any node device in the blockchain network, that is, any node device can perform anomaly detection on the smart contract; of course, the anomaly detection device 102 can be a device outside the blockchain network. The embodiment of the present application does not impose any restrictions on this. Among them, in order to realize anomaly detection of smart contracts or transaction data, the anomaly detection device 102 provided in the embodiment of the present application is deployed with an anomaly detection center module. It should be understood that when the anomaly detection device 102 is any node device in the blockchain network, in addition to the anomaly detection center module, the anomaly detection device 102 is also deployed with other modules. For the sake of ease of explanation, the embodiment of the present application takes the anomaly detection device as a node device in the blockchain as an example for relevant explanation; please refer to Figure 2 , is a schematic diagram of the structure of an anomaly detection device provided in an embodiment of the present application. The anomaly detection device can deploy multiple modules to implement anomaly detection of smart contracts. The following is a detailed introduction to each module of the anomaly detection device:

[0108] 1. Network module: Responsible for communication between node devices in the blockchain network, including data transmission, reception, and broadcast. It ensures that node devices can pass transaction data and block information within the network and maintains the connection status of the blockchain network.

[0109] 2. Verification module: responsible for verifying the legitimacy of transactions and blocks; the verification module can include two submodules, namely the certificate verification submodule and the permission verification submodule; among them:

[0110] (1) Certificate verification submodule: responsible for verifying the identity certificates of node devices and initiating objects (such as users) in the blockchain network to ensure that the initiating objects of transaction data have legal identities.

[0111] (2) Permission verification submodule: Checks whether the initiator of the transaction data has the permission to perform specific smart contract operations, preventing unauthorized access and operations by the initiator.

[0112] 3. Transaction pool module: responsible for managing all pending transaction data received by node devices. The transaction pool module maintains a transaction pool from which transaction data is selected for packaging and execution.

[0113] 4. Anomaly Detection Center Module: This is the core module for anomaly detection of smart contracts, responsible for anomaly detection of smart contracts. When the anomaly detection device is a device outside the blockchain network, the anomaly detection center module is independently deployed in the anomaly detection device. The anomaly detection center module contains multiple submodules, namely:

[0114] (1) Data collection module: responsible for collecting various indicator data of transaction data during the execution of smart contracts, such as CPU usage, memory usage, contract size, etc.

[0115] (2) Data storage module: responsible for storing various collected indicator data. This data storage module is used to provide data support for anomaly detection of smart contracts and model optimization of isolation forests.

[0116] (3) Data preprocessing module: responsible for cleaning, formatting and standardizing the various indicator data collected, so that the anomaly detection module can detect anomalies on the smart contract based on the preprocessed indicator data. Here, cleaning can, for example, delete indicator data that does not meet the requirements or convert indicator data that does not meet the requirements into indicator data that meets the requirements. The so-called non-compliance means that the value of a certain indicator data deviates significantly from the normal indicator data. For example, if the CPU usage value of the transaction data during the execution of the smart contract is 90%, which obviously does not meet the requirements, then the indicator data can be deleted, that is, the transaction data can be removed. Of course, it is also possible to average the CPU usage values ​​of other transaction data during the execution of the smart contract to obtain an average value, and use the average value as the CPU usage value of the transaction data during the execution of the smart contract. Formatting or standardization refers to normalizing the various indicator data collected, such as normalizing the indicator data of each dimension so that the indicator data is between 0 and 1.

[0117] (4) Anomaly detection module: responsible for using the pre-built isolation forest to perform anomaly detection on smart contracts based on the pre-processed indicator data and identify abnormal behaviors in smart contracts.

[0118] (5) Model optimization module: responsible for updating and optimizing the isolation forest. For example, the isolation forest is updated and optimized according to the execution parameters of the latest transaction data in the block during the execution of the smart contract to maintain the timeliness and accuracy of the isolation forest.

[0119] (6) Isolation forest module: stores the constructed isolation forest, which is used to perform anomaly detection on smart contracts.

[0120] 5. Scheduling module: Responsible for coordinating various tasks of node devices in the blockchain network, including but not limited to the packaging of transaction data, block generation, and the execution of smart contracts. The scheduling module includes the following submodules:

[0121] (1) Block transaction packager: responsible for selecting transaction data from the transaction pool and packaging it into blocks.

[0122] (2) Block generator: responsible for generating new blocks and adding them to the blockchain.

[0123] (3) Virtual machine engine: responsible for executing the smart contract code and processing the contract logic.

[0124] (4) Data upload module: responsible for uploading the execution parameters (including indicator data of various dimensions) of transaction data during the execution of the smart contract to the anomaly detection center.

[0125] (5) Contract process pool: manages the execution process of smart contracts to ensure that smart contracts can be executed efficiently and concurrently.

[0126] 6. Consensus module: Responsible for implementing the consensus mechanism in the blockchain network and ensuring that all node devices reach an agreement on the state of the blockchain, which is crucial for maintaining the security and consistency of the blockchain.

[0127] 7. Storage module: responsible for storing all blockchain data. The storage module includes two sub-modules:

[0128] (1) Blockchain ledger: stores all blocks of the blockchain and records transaction history. The blockchain ledger is the core data structure in the blockchain system, used to store and manage all confirmed blocks. The blockchain ledger is organized in a chain structure, and each block contains a set of transactions, a block header (including the hash value of the previous block, timestamp and other metadata), and other information. The blockchain ledger provides a public, tamper-proof transaction history record for the blockchain system, ensuring the transparency and consistency of the system.

[0129] (2) State database: responsible for storing the current state of the blockchain, including account balances, smart contract status, etc.

[0130] It should be understood that when anomaly detection device 102 is a device outside the blockchain network, the anomaly detection device independently deploys the anomaly detection center module, while the node devices in the blockchain network can deploy other modules in addition to the anomaly detection center module, namely, a network module, a verification module, a transaction pool module, a scheduling module, a consensus module, and a storage module. Through the anomaly detection modules deployed by the anomaly detection device, anomaly detection of transaction data or smart contracts can be achieved.

[0131] Based on the above-mentioned blockchain-based anomaly detection system and the modules deployed by the anomaly detection device, the following describes the blockchain-based anomaly detection process provided by the embodiment of the present application. The blockchain-based anomaly detection process provided by the embodiment of the present application includes the following three parts: (1) an isolation forest construction process for anomaly detection of smart contracts; (2) an anomaly detection process based on the isolation forest; and (3) an optimization process of the isolation forest. The following describes them one by one:

[0132] (1) Isolation forest construction process for anomaly detection of smart contracts: In this process, the anomaly detection center module in the anomaly detection device can collect the execution parameters of each node device in the blockchain network during the process of transaction data being executed by the smart contract, and construct an isolation forest based on the collected execution parameters during the process of transaction data being executed by the smart contract. For the isolation forest construction process, please refer to Figure 3A ,The isolation forest construction process includes the following steps:

[0133] S1. A master node device in a blockchain network receives a block generation signal or a slave node device in a blockchain network receives a block to be verified. When the master node device receives a block generation signal, the master node device can call a smart contract to execute the corresponding transaction data to generate a block. When a slave node device receives a block to be verified, the slave node device can verify the block. It should be understood that in the embodiments of the present application, the node device that receives a block generation signal or packages and generates a block is referred to as a master node device, and the node device that needs to verify the block is referred to as a slave node device.

[0134] S2. Determine whether the current time is within the sampling time interval. If it is within the sampling time interval, go to S3. If it is not within the sampling time interval, no operation is required.

[0135] S3. When a node device (such as a master node device or a slave node device) in the blockchain network begins to collect and generate blocks or verify blocks, the initial sample execution parameters of each sample transaction data during the execution of the smart contract. The initial sample execution parameters include the initial sample indicator data of each dimension.

[0136] S4. After the block is generated or verified, each node device sends the initial sample execution parameters of each sample transaction data during the execution of the smart contract to the anomaly detection center module through the data upload module in the scheduling module of the node device. In one implementation, Figure 3B The figure shows a schematic diagram of uploading initial sample execution parameters provided by an embodiment of the present application. The master node device can send the initial sample execution parameters of the sample transaction data during the smart contract execution process to the data collection module in the anomaly detection center module through the data upload module. Slave node device 1, slave node device 2, and slave node device 3 can also send the initial sample execution parameters of the corresponding sample transaction data during the smart contract execution process to the data collection module in the anomaly detection center module through their respective data upload modules.

[0137] S5. The data collection module in the anomaly detection center module receives the initial sample execution parameters of all sample transaction data during the execution of the smart contract.

[0138] S6. The data preprocessing module in the anomaly detection center module preprocesses the initial sample execution parameters of all sample transaction data during the execution of the smart contract to obtain the sample execution parameters of all sample transaction data during the execution of the smart contract.

[0139] S7. The anomaly detection center adds the sample execution parameters of each sample transaction data during the smart contract execution process to the transaction collection table corresponding to the data storage module. The transaction collection table includes sample execution parameters corresponding to multiple sampling time intervals.

[0140] S8. The anomaly detection center module determines whether the sampling time interval in the transaction collection table meets the sampling conditions. Schematically, the sampling conditions include: a cycle number threshold. That is, if the cycle number of the same sampling time interval meets the cycle number threshold, it means that the sampling time interval meets the sampling conditions, and then the process proceeds to S9. If the cycle number of the same sampling time interval does not meet the cycle number threshold, it means that the sampling time interval does not meet the sampling conditions, and then the execution parameters of the sample transaction data during the execution of the smart contract will continue to be collected in the sampling time interval of the next cycle. If the cycle number threshold is a day number threshold, that is, whether the number of days corresponding to the same sampling time interval reaches the day number threshold, if so, the sampling time interval meets the sampling conditions; otherwise, the execution parameters of the transaction data during the execution of the smart contract will continue to be collected. Schematically, the sampling time interval is 10:00-10:01; that is, the execution parameters of the transaction data will be collected from 10:00-10:01 every day. When the number of days in the sampling time interval (e.g., 7 days) reaches the day number threshold (e.g., 7 days), step S9 is executed.

[0141] S9. The anomaly detection center module waits for the sampling time interval to end. Schematically, the sampling time interval is 10:00-10:01, and the anomaly detection center module waits for the sampling time interval 10:00-10:01 to end.

[0142] S10. The anomaly detection center module starts generating an isolation forest and executes step S11.

[0143] S11. The anomaly detection center module randomly samples sample transaction data corresponding to the collection time interval from the transaction collection table, and divides the sampled transaction data into n groups of sample data, each group of sample data includes m sample transaction data, each sample transaction data corresponds to a sample execution parameter, and the sample execution parameter includes sample indicator data of p dimensions; P is a positive integer.

[0144] S12. For each set of m sample transaction data, the anomaly detection center module segments the m sample data in each set of sample data according to the indicator data in each dimension and the segmentation value corresponding to each dimension to generate an isolation tree. For example, for the m sample transaction data in sample data 1, the anomaly detection center module may segment the m sample transaction data in sample data 1 according to the indicator data in each dimension and the segmentation value corresponding to each dimension to generate an isolation tree. For the m sample transaction data in sample data 2, the anomaly detection center module may segment the m sample transaction data in sample data 2 according to the indicator data in each dimension and the segmentation value corresponding to each dimension to generate an isolation tree. The isolation tree includes multiple tree nodes, which may be root nodes, intermediate nodes, or leaf nodes. The node value corresponding to a tree node is the number of transactions of the sample transaction data passing through the tree node. The tree node may record the identifier of the sample transaction data passing through the tree node.

[0145] S13. The anomaly detection center module determines whether the isolation tree corresponding to each of the n groups of sample data has been generated. If the isolation trees corresponding to all n groups of sample data have been generated, the process proceeds to S14. If the isolation tree for any sample data has not been generated, the process proceeds to S12 to continue generating the isolation tree corresponding to that sample data.

[0146] S14. The anomaly detection center module constructs an isolation forest from the generated n isolation trees and stores the isolation forest in the isolation forest module, so that it can be subsequently retrieved from the isolation forest module to perform anomaly detection on the smart contract. The n groups of sample data are derived from the same sampling time interval; that is, the isolation forest ultimately constructed from these n groups of sample data corresponds to the sampling time interval.

[0147] S15. When there are multiple sampling time intervals, the anomaly center module can determine whether corresponding isolation forests have been generated for all sampling time intervals. Each sampling time interval corresponds to one isolation forest. If corresponding isolation forests have been generated for all sampling time intervals, step S16 is executed. If any sampling time interval has not yet generated an isolation forest, isolation forests are generated for the corresponding sampling time interval, i.e., steps S11-S15 are executed.

[0148] S16. Complete the construction of multiple isolation forests.

[0149] In summary, the embodiments of this application use an unsupervised learning approach to construct an isolation forest for anomaly detection in smart contracts. This eliminates the need for large-scale labeled data to train the model, addressing the time-consuming and labor-intensive nature of supervised learning and the difficulty of obtaining sufficient labeled data in a blockchain environment. This embodiment of the solution uses an unsupervised learning isolation forest algorithm to effectively detect anomalous behavior in smart contracts without pre-labeled data, significantly reducing the workload and cost of data preparation.

[0150] (2) Anomaly detection process based on isolation forest: The anomaly detection center module uses the pre-established isolation forest to detect anomalies in smart contracts; see Figure 4 , is a flowchart of an anomaly detection process based on isolation forests provided in an embodiment of the present application. The anomaly detection process includes the following steps:

[0151] S21. The master node device in the blockchain network receives a block generation signal or the slave node device in the blockchain network receives a block to be verified.

[0152] S22. The node device in the blockchain network obtains the execution parameters of the transaction data during the execution of the target smart contract from the executed block (i.e., the generated block) or the verified block, and sends the execution parameters of the transaction data during the execution of the target smart contract to the anomaly detection center module. The execution parameters include indicator data of P dimensions.

[0153] S23. The anomaly detection center module receives the execution parameters of the transaction data during the execution of the target smart contract, and calls the anomaly detection module included in the anomaly detection center module to perform anomaly detection on the target smart contract based on the indicator data of P dimensions included in the execution parameters.

[0154] S24. The anomaly detection module obtains M isolation forests from the isolation forest module and randomly selects K isolation trees from the M isolation forests. In one implementation, the anomaly detection module may randomly select k1 isolation trees from each isolation forest, ultimately obtaining K isolation trees.

[0155] S25. The anomaly detection module puts the execution parameters of the above-mentioned transaction data in the process of being executed by the target smart contract into each isolation tree of the K isolation trees for prediction, and obtains the predicted value of the transaction data in each isolation tree. In one implementation, it is assumed that according to the execution parameters of the transaction data in the process of being executed by the target smart contract, the depth when reaching the leaf node in the current isolation tree is a, and the node value of the leaf node is b, then the predicted value in the isolation tree is a+b; wherein, the depth refers to the number of layers where the deepest tree node in the isolation tree is located, for example, the execution parameter has gone through 3 tree nodes in the isolation tree (such as root node-intermediate node-leaf node), then the depth is 2; for another example, the execution parameter has gone through 4 tree nodes in the isolation tree (such as root node-intermediate node-intermediate node-leaf node), then the depth is 3. In the embodiment of the present application, the smaller the depth, the rarer it is, and the node value of the leaf node is also smaller and rarer, which means that the transaction data is abnormal, and then it can be determined that the target smart contract is also abnormal. Among them, the node value of the tree node of the isolation tree is the intersection.

[0156] S26: The anomaly detection center module determines whether all K isolation trees participate in the prediction of transaction data. If so, the module proceeds to S27; if not, the module proceeds to S25.

[0157] S27. Assign weights to the predicted values ​​of the transaction data in each isolation tree based on the execution time of the transaction data. Since the various indicators of transaction data during smart contract execution are related to the execution time, the closer the execution time is to the sampling time interval of the isolation forest where the isolation tree is located, the more relevant the isolation tree in that isolation forest is for predicting the transaction data. Therefore, a higher weight can be assigned to that isolation forest, and the corresponding predicted value of the transaction data in that isolation tree will have a higher weight.

[0158] S28. The anomaly detection center module performs a weighted summation on the predicted value of the transaction data in each isolation tree and the corresponding weight to obtain the anomaly score of the transaction data. Since the predicted value is determined based on the execution parameters of the transaction data during the execution of the target smart contract, the anomaly score of the transaction data can be used as the anomaly score during the execution of the smart contract.

[0159] S29. The anomaly detection center module determines whether the anomaly score is greater than the anomaly threshold. If the anomaly score is greater than the anomaly threshold, the process proceeds to S30. If the anomaly score is less than or equal to the anomaly threshold, the process proceeds to S31. The anomaly threshold can be set as needed and is not limited in this embodiment.

[0160] S30. Return the detection result that the target smart contract is abnormal.

[0161] S31. Return the detection result that the target smart contract is normal.

[0162] In summary, the unsupervised anomaly detection technology based on Isolation Forest enables real-time monitoring of blockchain smart contracts, significantly improving the efficiency and accuracy of detecting anomalous smart contract behavior. It does not require extensive annotated data and can adapt to new data patterns, providing an efficient and reliable smart contract risk management solution for blockchain environments such as consortium chains. Furthermore, during anomaly detection, a time-weighted approach is used to enhance the accuracy of Isolation Forest in detecting smart contract anomalies. In this mechanism, Isolation Forests generated at different sampling time intervals are assigned different weights based on their proximity to the execution time of the transaction data being tested. This dynamic weighting approach accounts for the temporal correlation of smart contract execution, enabling Isolation Forest to more accurately identify anomalous smart contract behavior. This approach can effectively improve the sensitivity and accuracy of smart contract anomaly detection, particularly in consortium chain environments.

[0163] (3) Isolation Forest Optimization Process: The anomaly detection center uses transaction data (such as the latest transaction data in the block) to quickly update and iterate the isolation forest. Figure 5 , is a schematic diagram of an optimization process for an isolation forest provided in an embodiment of the present application. The optimization process for the isolation forest includes the following steps:

[0164] S41. The master node device in the blockchain network receives a block generation signal or the slave node in the blockchain network receives a block to be verified.

[0165] S42. The node devices in the blockchain network obtain the execution parameters of the updated transaction data during the execution of the target smart contract from the executed or verified blocks, and send the execution parameters of the updated transaction data during the execution of the target smart contract to the anomaly detection center module. The execution parameters include indicator data of P dimensions. The number of updated transaction data can be one or more, and the following description will take the number of updated transaction data as one. The updated transaction data can be the transaction data with the latest execution time in the block (i.e., the latest transaction data), or it can be transaction data randomly selected from the block. This embodiment of the application does not impose any restrictions on this.

[0166] S43. The anomaly detection center module receives the execution parameters of the updated transaction data during the execution of the smart contract, and calls the model optimization module to optimize the isolation forest based on the execution parameters of the updated transaction data during the execution of the smart contract, that is, executing steps S44-S52.

[0167] S44. The anomaly detection center module determines the historical transaction data with the earliest sample execution time among all transaction data participating in the isolation forest construction, and deletes the historical transaction data. For example, if the execution time of the updated transaction data is Monday, then the historical transaction data with the earliest execution time on Monday can be deleted.

[0168] S45. The anomaly detection center module starts to update the isolation forest according to the execution parameters of the updated transaction data during the execution of the smart contract.

[0169] S46. The anomaly detection center module determines, in the isolation forest, a target isolation tree constructed using the execution parameters of the historical transaction data.

[0170] S47. The anomaly detection center module retraces the target isolation tree based on the execution parameters of the historical transaction data during the smart contract execution process until it reaches a leaf node of the target isolation tree based on the execution parameters of the historical transaction data, thereby obtaining a predicted path for the historical transaction data. The predicted path for the historical transaction data includes tree nodes in the target isolation tree, which may include, for example, root nodes, intermediate nodes, or leaf nodes.

[0171] S48. The anomaly detection center module reduces the node values ​​of all tree nodes in the prediction path of the historical transaction data by one.

[0172] S49: The anomaly detection center module determines whether the node value of a leaf node in the target isolation tree after the node value is decremented by one is empty (e.g., 0). If there is a leaf node with an empty node value, the process proceeds to step S50. If there is no leaf node with an empty node value, the process determines a first updated isolation tree based on the target isolation tree after the node value is decremented by one, and the process proceeds to step 52.

[0173] S50. The anomaly detection center module deletes leaf nodes with empty node values ​​from the target isolation tree and executes S51.

[0174] S51. The anomaly detection center module backtracks the target isolation tree after the node value is reduced by one according to the predicted path of the historical transaction data. If a tree node with a node value equal to the target value (e.g., 1) is encountered, the child node with the node value equal to the target value is deleted to obtain the first updated isolation tree. This ensures that each partition of the target isolation tree after the node value is reduced by one ensures that data exists on both sides, and a node value of 1 indicates that no further partitioning is required.

[0175] S52: The anomaly detection center module adds the updated transaction data to the first updated isolation tree. Specifically, the module walks through the first updated isolation tree according to the execution parameters of the updated transaction data during the smart contract execution process, obtains the target predicted path of the updated transaction data, and increments the node value of each tree node in the target predicted path by one to obtain a second updated isolation tree. Finally, the isolation forest where the target isolation tree is located can be updated based on the second updated isolation tree.

[0176] In summary, the Isolation Forest model's adaptive optimization strategy, based on real-time data streams (i.e., the stream of transaction data from the currently generated or verified block), can update the Isolation Forest in real time based on blockchain transaction data. By continuously removing the oldest transactions from the Isolation Forest and adding new ones, the Isolation Forest can self-adjust to changes in smart contract behavior. This strategy not only improves the adaptability and robustness of the Isolation Forest model but also reduces misjudgments caused by outdated historical data, ensuring, to a certain extent, that the Isolation Forest model remains efficient and accurate in the dynamically changing blockchain environment.

[0177] Next, the blockchain-based anomaly detection method provided in the embodiments of the present application is described.

[0178] See Figure 6, which is a flow chart of a blockchain-based anomaly detection method provided in an embodiment of the present application. The blockchain-based anomaly detection method can be executed by the anomaly detection device in the above-mentioned system. At least one smart contract can be deployed on the blockchain. The blockchain-based anomaly detection method provided in an embodiment of the present application can include the following steps S601-S604:

[0179] S601. Obtain execution parameters of the transaction data during execution by the target smart contract, where the execution parameters include indicator data of p dimensions; p is a positive integer; and the target smart contract is any smart contract among at least one smart contract.

[0180] In a specific implementation, node devices in a blockchain network can call smart contracts to execute transaction data. During the execution of transaction data or smart contracts, some resources will be consumed, such as hardware resources (such as memory usage, CPU usage, etc.), software resources (such as contract size, contract complexity, network I / O, etc.), and time resources (such as the execution time of the smart contract, etc.). Accordingly, indicator data may include but is not limited to hardware resources (such as memory usage, CPU usage, etc.), software resources (such as contract size, contract complexity, network I / O, etc.), and time resources (such as the execution time of the smart contract, etc.). It should be understood that the execution parameters including indicator data of p dimensions can be understood as the execution parameters including indicator data of at least one dimension.

[0181] In one implementation, when a master node device generates a block or a slave node device completes verification of a block, execution parameters of the transaction data in the generated block or the verified block during execution by the target smart contract can be obtained.

[0182] S602. Obtain M isolation forests. The isolation forests are constructed based on sample execution parameters of sample transaction data during smart contract execution. M is a positive integer.

[0183] The isolation forest is constructed using the isolation forest algorithm based on the sample execution parameters of the sample transaction data during the execution of the smart contract. Each isolation forest can include n isolation trees, where n is an integer greater than 1. Each isolation tree can be constructed based on a sample data, which includes m sample transaction data. The sample execution parameters include sample indicator data of P dimensions. Schematically, Figure 7 FIG. 1 is a schematic diagram of an isolation tree provided by an embodiment of the present application. The isolation tree includes multiple tree nodes, and the node value of each tree node is the transaction number of sample transaction data.

[0184] S603. Select K predicted isolation trees from the M isolation forests; K is a positive integer, and K is less than or equal to n×M.

[0185] In one implementation, K predicted isolation trees can be randomly selected from M isolation forests, that is, the number of predicted isolation trees selected from each isolation forest can be different. In another implementation, k1 isolation trees are selected from each isolation forest as predicted isolation trees, and K predicted isolation trees are ultimately obtained. In other words, the same number of isolation trees are selected from each isolation forest as predicted isolation trees, and the value of K is M×K1. For example, if isolation forest 1 includes 6 isolation trees and isolation forest 2 includes 6 isolation trees, then 3 isolation trees are randomly selected from isolation forest 1 as predicted isolation trees, and 3 isolation trees are randomly selected from isolation forest 2 as isolation trees, and 6 predicted isolation trees are ultimately obtained.

[0186] S604. Based on the indicator data of P dimensions, determine the path depth of the transaction data in each prediction isolation tree and the node value of the corresponding leaf node of the transaction data in each prediction isolation tree; K is a positive integer, and K is less than or equal to n×M.

[0187] Next, we will take the example of determining the predicted value of transaction data in a prediction isolation tree as an example. The specific implementation of step S604 includes the following steps:

[0188] ① According to the indicator data of P dimensions, determine the prediction path of transaction data in the i-th prediction isolation tree, where i is a positive integer less than or equal to K; the prediction path of transaction data can include the tree nodes in the i-th prediction isolation tree, where the tree nodes can be root nodes, intermediate nodes, or leaf nodes. For example, the i-th prediction isolation tree is Figure 7 The isolation tree shown in the figure has P dimensions of indicator data, including: memory usage is 20%, network I / O is 30, contract size is 100, contract complexity is 6, contract transaction fee is 0.15, and contract call count is 2. According to the indicator data of P dimensions, Figure 7 In the isolation tree shown, the predicted path for determining transaction data is: root node 71 - intermediate node 72 - intermediate node 73 - leaf node 74 .

[0189] ② When the predicted path of the transaction data reaches the leaf node of the i-th prediction isolation tree, the path depth of the transaction data in the i-th prediction isolation tree is determined based on the tree nodes of the i-th prediction isolation tree included in the predicted path, and the node value of the leaf node in the predicted path is used as the node value of the corresponding leaf node of the transaction data in the i-th prediction isolation tree. For example, in the above example, when the predicted path of the transaction data is root node 71-intermediate node 72-intermediate node 73-leaf node 74, when it reaches leaf node 74, it is determined that the transaction data is at Figure 7The path depth in the predicted isolation tree shown is 3, and the node value of the corresponding leaf node of the transaction data in the i-th predicted isolation tree is the node value of the leaf node 74.

[0190] S605 : Determine the predicted value of the transaction data in each isolation forest based on the path depth of the transaction data in each prediction isolation tree and the node value of the leaf node corresponding to the transaction data in each prediction isolation tree.

[0191] In one implementation, the predicted value of the transaction data in each predicted isolation tree is determined based on the path depth of the transaction data in each predicted isolation tree and the node value of the corresponding leaf node of the transaction data in each predicted isolation tree; and the predicted value of the transaction data in each isolation forest is determined based on the predicted value of the transaction data in each predicted isolation tree.

[0192] Among them, here, the prediction value of the transaction data in the i-th prediction isolation tree is still used as an example to explain the relevant words. Specifically, according to the path depth of the transaction data in each prediction isolation tree and the node value of the leaf node corresponding to the transaction data in each prediction isolation tree, determining the prediction value of the transaction data in each prediction isolation tree may include: determining the prediction value of the transaction data in the i-th prediction isolation tree according to the path depth of the transaction data in the i-th prediction isolation tree and the node value of the leaf node corresponding to the transaction data in the i-th prediction isolation tree. In one implementation, the path depth of the transaction data in the i-th prediction isolation tree and the node value of the leaf node corresponding to the transaction data in the i-th prediction isolation tree can be summed to obtain the prediction value of the transaction data in the i-th prediction isolation tree. For example, the path depth of the transaction data in the i-th prediction isolation tree is 3, and the node value of the transaction data in the i-th prediction isolation tree corresponding to the leaf node 74 is 50. According to the path depth and the node value of the leaf node, the predicted value of the transaction data in the i-th prediction isolation tree is determined. Figure 7 The predicted value in the isolation tree shown is 53.

[0193] It should be noted that the predicted value of the transaction data in each prediction isolation tree can refer to the method for determining the predicted value of the transaction data in the i-th prediction isolation tree, which will not be repeated here.

[0194] It should be understood that the smaller the path depth, the rarer the transaction data and the more it deviates from the majority of normal transaction data, that is, the greater the possibility that the transaction data is abnormal, and thus the target smart contract can be determined to be abnormal. The smaller the node value of the leaf node, the rarer the transaction data and the more it deviates from the majority of normal transaction data, that is, the greater the possibility that the transaction data is abnormal, and thus the target smart contract can be determined to be abnormal. Correspondingly, the smaller the predicted value of the transaction data in the prediction isolation tree determined based on the path depth and the leaf node, the greater the possibility that the transaction data is abnormal, and thus the target smart contract can be determined to be abnormal. In other words, the predicted value of the transaction data in the prediction isolation tree is used to indicate whether the transaction data deviates from the sample execution parameters corresponding to the majority of sample transaction data in the corresponding prediction isolation tree. The smaller the predicted value, the more likely the transaction data deviates from the sample execution parameters corresponding to the majority of sample transaction data, and the transaction data is likely to be abnormal, which means that the target smart contract corresponding to the transaction data is likely to be abnormal when it is executed.

[0195] Among them, determining the predicted value of the transaction data in each isolation forest based on the predicted value of the transaction data in each prediction isolation tree can specifically include: determining the isolation forest where each prediction isolation tree is located, and for the target isolation forest, the predicted value of the transaction data in the prediction isolation tree of the target isolation forest can be averaged to obtain the predicted value of the transaction data in the target isolation forest. The target isolation forest is any isolation forest among the M isolation forests. For example, the isolation forest where prediction isolation tree 1 and prediction isolation tree 2 are located is isolation forest 1, then the predicted value of the transaction data in prediction isolation tree 1 and the predicted value of the transaction data in prediction isolation tree 2 can be averaged to obtain the predicted value of the transaction data in isolation forest 1; for another example, the isolation forest where prediction isolation tree 3 and prediction isolation tree 4 are located is isolation forest 2, then the predicted value of the transaction data in prediction isolation tree 3 and the predicted value of the transaction data in prediction isolation tree 4 can be averaged to obtain the predicted value of the transaction data in isolation forest 2.

[0196] S606. Based on the predicted values ​​of the transaction data in each isolation forest, perform anomaly detection on the target smart contract to obtain a detection result.

[0197] In one implementation, the anomaly score of the target smart contract during execution is determined based on the predicted value of the transaction data in each isolation forest, and it is judged whether the anomaly score is greater than the anomaly threshold. If the anomaly score is greater than the anomaly threshold, the detection result of the target smart contract anomaly is obtained; if the anomaly score is less than or equal to the anomaly threshold, the detection result of the target smart contract being normal is obtained.

[0198] Among them, according to the predicted value of transaction data in each isolation forest, determining the anomaly score of the target smart combination during execution can include but is not limited to the following implementation methods:

[0199] Method 1: Average the predicted values ​​of transaction data in each isolation forest to obtain the anomaly score of the target isolated smart contract during execution. For example, the predicted value of transaction data 1 in isolation forest 1 is 50, and the predicted value of transaction data 2 in isolation forest 2 is 20. Averaging 50 and 20 gives an anomaly score of 35 for the transaction data.

[0200] Method 2: Sum the predicted values ​​of transaction data in each isolation forest to obtain the anomaly score of the target isolated smart contract during execution. For example, the predicted value of transaction data 1 in isolation forest 1 is 50, and the predicted value of transaction data 2 in isolation forest 2 is 20. The sum of 50 and 20 gives the anomaly score of 70.

[0201] Method 3: Assign corresponding weights to the predicted values ​​of transaction data in each isolation forest. Based on the predicted values ​​of transaction data in each isolation forest and the corresponding weights, determine the anomaly score during the execution of the target smart contract. In one implementation, a time-weighted dynamic threshold adjustment mechanism is introduced. This takes into account the similarity of execution parameters of transaction data at similar time points during the execution of the smart contract. Therefore, in this embodiment of the application, the closer the execution time of transaction data is to the sampling time interval corresponding to a particular isolation forest, the higher the weight assigned to the predicted value of the transaction data in that isolation forest. This allows the isolation forest to more accurately identify abnormal behavior of smart contracts, improving the accuracy and sensitivity of anomaly detection for smart contracts. Among them, each isolation forest can correspond to a sampling time. Under this implementation method, determining the anomaly score during the execution of the target smart contract based on the predicted value of the transaction data in each isolation forest can include: obtaining the execution time of the transaction data when it is executed by the target smart contract; determining the weight corresponding to the predicted value of the transaction data in each isolation forest based on the execution time and the sampling time interval corresponding to each isolation forest; wherein, the longer the time interval between the execution time and the sampling time interval corresponding to the isolation forest, the greater the weight corresponding to the predicted value of the transaction data in the isolation forest; performing weighted summation of the predicted value of the transaction data in each isolation forest and the corresponding weight to obtain the anomaly score during the execution of the target smart contract.

[0202] For example, see Figure 8 , is a schematic diagram of an abnormality score determination process provided in an embodiment of the present application. Figure 8In the example, the sampling time interval corresponding to isolation forest 1 is 4:00-4:01, and isolation forest 1 includes 6 isolation trees (such as isolation tree 1 to isolation tree 6); the sampling time interval corresponding to isolation forest 2 is 5:00-5:01, and isolation forest 2 includes 6 isolation trees (such as isolation tree 1 to isolation tree 6); the sampling time interval corresponding to isolation forest 3 is 6:00-6:01, and isolation forest 3 includes 6 isolation trees (such as isolation tree 1 to isolation tree 6); the sampling time interval corresponding to isolation forest 4 is 7:00-7:01, and isolation forest 4 includes 6 isolation trees (such as isolation tree 1 to isolation tree 6). Among them, the predicted value of transaction data in Isolation Forest 1 is 20, and the predicted value of transaction data in Isolation Forest 2 is 5; the predicted value of transaction data in Isolation Forest 3 is 3, and the predicted value of transaction data in Isolation Forest 4 is 10; suppose the execution time of transaction data when it is executed by the target smart contract is 5:30; it can be seen that the execution time of transaction data is close to Isolation Forest 2 and Isolation Forest 3, and far from Isolation Forest 1 and Isolation Forest 4. At this time, the predicted value of transaction data in Isolation Forest 2 and the predicted value of transaction data in Isolation Forest 3 can be given a higher weight. Figure 8 In the example, the predicted values ​​of transaction data in Isolation Forest 2 and Isolation Forest 3 are weighted 0.4, and the predicted values ​​of transaction data in Isolation Forest 1 and Isolation Forest 4 are weighted 0.1. Therefore, the anomaly score of the smart contract during execution is: 20×0.1+5×0.4+2×0.4+10×0.1=5.8.

[0203] Among them, the sampling time interval includes a start time and an end time, and the time interval between the execution time and the sampling time interval corresponding to the isolation forest can be the time interval between the execution time and the start time in the sampling time interval corresponding to the isolation forest; or, the time interval between the execution time and the sampling time interval corresponding to the isolation forest can be the time interval between the determined execution time and the end time in the sampling time interval corresponding to the isolation forest. The embodiments of the present application do not impose any restrictions on this.

[0204] In an embodiment of the present application, at least one smart contract is deployed on the blockchain, and execution parameters of transaction data during the execution process of the target smart contract are obtained, and the execution parameters include index data of p dimensions; p is a positive integer; the target smart contract is any smart contract in the at least one smart contract; then, M isolation forests are obtained, and the isolation forest is constructed based on the sample execution parameters of the sample transaction data during the execution process of the smart contract; each isolation forest includes n isolation trees, n is an integer greater than 1; M is a positive integer; K predicted isolation trees are selected from the M isolation forests, and based on the index data of P dimensions, the path depth of the transaction data in each predicted isolation tree and the node value of the corresponding leaf node of the transaction data in each predicted isolation tree are determined; K is a positive integer, and K is less than or equal to n×M; according to the path depth of the transaction data in each predicted isolation tree and the node value of the corresponding leaf node of the transaction data in each predicted isolation tree, the predicted value of the transaction data in each isolation forest is determined; according to the predicted value of the transaction data in each isolation forest, anomaly detection is performed on the target smart contract to obtain a detection result. It can be seen that the embodiment of the present application realizes unsupervised detection of smart contracts by constructing an isolation forest through the sample execution parameters of sample transaction data, which avoids the time-consuming labeling caused by supervised learning. At the same time, through the indicator data of transaction data in different dimensions, the path depth of transaction data in the predicted isolation tree and the node value of the corresponding leaf node can be predicted more accurately. In this way, the predicted value of transaction data in each isolation forest can be determined according to the path depth and node value, which can make the smart contract anomaly detection faster and more effective.

[0205] Next, the isolation forest construction and update provided by the embodiment of the present application are described. In some optional embodiments, such as Figure 9 FIG. 1 is a flow chart of a method for constructing an isolation forest according to an embodiment of the present application. The isolation forest construction method can be executed by an anomaly detection device. The isolation forest construction method includes the following steps S901-S904:

[0206] S901. Obtain n groups of sample data, each group of sample data including m sample transaction data, each sample transaction data corresponding to a sample execution parameter. The sample execution parameter includes sample indicator data of p dimensions, where p is a positive integer.

[0207] For example, if p=10, the sample execution parameters include sample indicator data of 10 dimensions, as shown in Table 2. The sample indicator data of these 10 dimensions are as follows:

[0208] Table 2

[0209]

[0210] It should be understood that the embodiment of the present application does not impose any limitation on the value of p, that is, the sample execution parameters may include sample indicator data of at least one dimension, such as p may be 2, 4, 5, and so on.

[0211] In one implementation, obtaining n groups of sample data may include: obtaining n groups of sample transaction data from a blockchain. In another implementation, within a target sampling time interval, sample execution parameters of the sample transaction data in the block during the execution of the smart contract are obtained; the sample execution parameters of the obtained sample transaction data during the execution of the smart contract are stored in a transaction collection table; if the target sampling time interval in the transaction collection table meets the sampling conditions, the sample transaction data within the target sampling time interval in the transaction collection table is sampled; and the sampled sample transaction data is divided into n groups of sample data. The sampling conditions include a cycle number threshold. Schematically, the cycle number threshold includes a day number threshold. If the number of days in the target sampling time interval in the transaction collection table meets the day number threshold, the sample transaction data within the target sampling time interval in the transaction collection table is sampled. It should be understood that by setting a cycle number threshold, more authentic and comprehensive sample transaction data can be obtained. For example, for each dimension, the same sampling time interval of the past few days is selected to obtain the execution parameters corresponding to the sample transaction data from the block, and each sampling time interval will randomly select some sample transaction data for the generation of the isolation tree. This can ensure the construction of a more accurate isolation tree to a certain extent. For example, the transaction collection table shown in Table 3 only takes the execution parameters including CPU usage as an example. In actual application, the execution parameters also include indicator data of other dimensions. The day threshold is 7 days (i.e., Monday to Friday), which means that the sample execution parameters of the sample transaction data in the block during the execution of the smart contract are collected every day within the target sampling time interval. The target sampling time interval can be, for example, 00:00-00:01, 01:00:01:01, etc. in Table 3.

[0212] Table 3

[0213]

[0214] As can be seen from Table 3, the embodiment of the present application can obtain the CPU usage rate of sample transaction data in a block during the smart contract execution process from 00:00 to 01:01 on Monday, and obtain the CPU usage rate of sample transaction data in a block during the smart contract execution process from 00:00 to 01:01 on Tuesday. The blocks on Monday and Tuesday can be the latest blocks on the blockchain. It should be understood that in Table 3, the number of sample transaction data obtained from 00:00 to 00:01 on Monday can be multiple, that is, 9.61% can be the CPU usage rate of sample transaction data 1 during the smart contract execution process, 2.62% is the CPU usage rate of sample transaction data 2 during the smart contract execution process; 8.25% is the CPU usage rate of sample transaction data 3 during the smart contract execution process, and so on.

[0215] Sampling the sample transaction data within the target sampling time interval in the transaction collection table may include: randomly sampling all sample transaction data within the target sampling time interval in the transaction collection table. For example, in Table 3 above, assuming the target sampling time interval is 00:00-00:01, random sampling may be performed from all sample transaction data between 00:00-00:01 from Monday to Tuesday. Of course, sampling may also be performed from the sample transaction data on the days within the target sampling time interval in the transaction collection table. For example, in Table 3 above, assuming the target sampling time interval is 00:00-00:01, sampling may be performed from the sample transaction data between 00:00-00:01 on Monday, from the sample transaction data between 00:00-00:01 on Tuesday, and so on.

[0216] In one implementation, within a target sampling time interval, sample execution parameters of sample transaction data in a block during the execution of a smart contract are obtained, including: within the target sampling time interval, initial sample execution parameters of sample transaction data in a block during the execution of a smart contract are obtained; the initial sample execution parameters of the sample transaction data during the execution of the smart contract are preprocessed to obtain the sample execution parameters of the sample transaction data during the execution of the smart contract; wherein the preprocessing includes at least one of the following: normalizing the initial sample execution parameters of the sample transaction data during the execution of the smart contract; and cleaning the indicator data included in the initial sample execution parameters of the sample transaction data during the execution of the smart contract.

[0217] S902. Based on the sample execution parameters corresponding to the m transaction data included in any one group of sample data among the n groups of sample data, the m sample transaction data included in any one group of sample data are segmented and divided according to the sample indicator data of each dimension and the segmentation value corresponding to each dimension, so as to obtain multiple data sets, each of which corresponds to a tree node; the tree node records the identifier of the sample transaction data included in the corresponding data set.

[0218] Schematically, n=2, which are sample data 1 and sample data 2 respectively; suppose the sample execution parameters include indicator data of 6 dimensions, namely memory usage, network I / O, contract size, contract complexity, number of contract calls and contract transaction fee; sample data 1 includes 400 (i.e., m=400) sample transaction data. The isolation tree construction of sample data 1 includes: (1) randomly selecting a dimension from p dimensions. For example, if memory usage is selected, then the 400 sample transaction data included in sample data 1 can be divided according to the sample execution parameters corresponding to the 400 sample transaction data included in sample data 1, according to the memory usage and the split value corresponding to the memory usage (e.g., 40%), to determine two data sets, that is, the sample transaction data corresponding to the memory usage ≥ 40% are divided into a data set 1, and the sample transaction data corresponding to the memory usage < 40% are divided into a data set 2. Finally, the two data sets each include 200 transaction data. At this time, data set 1 corresponds to a tree node, and data set 2 corresponds to a tree node. (2) For the sample transaction data in dataset 1, randomly select a dimension from the remaining dimensions. For example, network I / O is selected. According to the sample execution parameters corresponding to the 200 sample transaction data included in dataset 1, the 200 sample transaction data included in dataset 1 are divided according to network I / O and the split value corresponding to network I / O (such as 150), and two datasets are determined. That is, the sample transaction data corresponding to network I / O ≥ 150 in dataset 1 are divided into dataset 3, and the sample transaction data corresponding to network I / O < 150 are divided into dataset 4. Finally, the two datasets each include 100 sample transaction data, among which dataset 3 corresponds to a tree node and dataset 4 corresponds to a tree node. The tree nodes corresponding to dataset 3 and dataset 4 are both child nodes of the tree node corresponding to dataset 1. (3) For the sample transaction data in dataset 3, randomly select a dimension from the remaining dimensions. For example, if contract size is selected, the 100 sample transaction data included in dataset 3 are segmented and divided according to the contract size and the split value corresponding to the contract size (e.g., 800) based on the sample execution parameters corresponding to the 100 sample transaction data included in dataset 3. Two data sets are determined, that is, the sample transaction data corresponding to the contract size ≥ 800 in dataset 3 are divided into a dataset 5, and the sample transaction data corresponding to the contract size < 800 are divided into a dataset 6. Finally, dataset 5 includes 75 sample transaction data and dataset 6 includes 25 sample transaction data. In which dataset 5 corresponds to a tree node and dataset 6 corresponds to a tree node. The tree nodes corresponding to dataset 5 and dataset 6 are both child nodes of the tree node corresponding to dataset 3. By analogy, sample data 1 can be segmented into multiple data sets, each corresponding to a tree node. Sample data 2 can also be segmented into multiple data sets, each corresponding to a tree node.

[0219] S903 , obtaining the node value of each corresponding tree node according to the transaction quantity of the sample transaction data in each data set, and generating an isolation tree corresponding to any set of sample data according to the node value of each tree node.

[0220] For example, in the above example, the node value of the tree node corresponding to dataset 5 is the number of transactions in the sample transaction data of dataset 5, which is 75; the node value of the tree node corresponding to dataset 6 is the number of transactions in the sample transaction data of dataset 6, which is 25. Then, based on each tree node and its node value, we can finally construct the following: Figure 7 The isolation tree shown.

[0221] S904: Construct an isolation forest based on the isolation tree corresponding to each set of sample data.

[0222] Each of the n sets of sample data corresponds to an isolation tree, and the isolation forest includes n isolation trees. It should be understood that if the n sets of sample data are acquired during a target sampling time interval, then the isolation forest constructed based on the n sets of sample data corresponds to the target sampling time interval. It should be understood that any isolation forest can be constructed according to the specific implementation methods of S701-S704.

[0223] In an embodiment of the present application, n groups of sample data are obtained, each group of sample data includes m sample transaction data, and each sample transaction data corresponds to a sample execution parameter; the sample execution parameter includes sample index data of p dimensions; according to the sample execution parameter corresponding to the m transaction data included in any group of sample data in the n groups of sample data, the m sample transaction data included in any group of sample data are segmented and divided according to the sample index data of each dimension and the segmentation value corresponding to each dimension, to obtain multiple data sets, each of which corresponds to a tree node; the tree node records the identifier of the sample transaction data included in the corresponding data set; according to the number of transactions of the sample transaction data in each data set, the node value of each corresponding tree node is obtained, and the isolation tree corresponding to any group of sample data is generated according to the node value of each tree node; according to the isolation tree corresponding to each group of sample data, an isolation forest is constructed. It can be seen that the embodiment of the present application adopts the isolation forest algorithm of unsupervised learning, which does not require pre-labeled data, thus solving the problem of time and labor consumption caused by the need for a large amount of labeled data to train the model, and also solving the problem of not being able to obtain sufficient labeled data in the blockchain environment. The isolation forest constructed can effectively detect abnormal behavior in smart contracts, significantly reducing the workload and cost of data preparation.

[0224] In some optional embodiments, the embodiments of the present application can also update the isolation forest in real time. By updating the isolation forest, the model's adaptability to emerging abnormal patterns can be improved, while also ensuring the accuracy and stability of the model in long-term operation. In one implementation, updating the isolation forest includes: obtaining the execution parameters of the updated transaction data in the block corresponding to the current block height when being executed by the smart contract; determining the target isolation forest to be updated from M isolation forests, and updating the target isolation forest to be updated based on the execution parameters of the updated transaction data when being executed by the smart contract. Determining the target isolation forest to be updated from M isolation forests can include: randomly selecting the target isolation forest from the M isolation forests, or determining historical transaction data from all transaction data participating in the construction of the M isolation forests; the historical transaction data is the sample transaction data with the earliest execution time among all sample transaction data participating in the construction of the target isolation forest, and determining the isolation forest where the historical transaction data is located as the target isolation forest based on the identifier of the historical transaction data; or, if the execution parameters of the updated transaction data when being executed by the smart contract are obtained within a target sampling time interval, then determining the isolation forest corresponding to the target sampling time interval as the target isolation forest.

[0225] Among them, updating the target isolation forest to be updated according to the execution parameters of the updated transaction data when being executed by the smart contract may include: directly updating the target isolation forest to be updated according to the execution parameters of the updated transaction data when being executed by the smart contract and the identifier of the updated transaction data, specifically, randomly selecting a target isolation tree from the target isolation forest, and determining the transaction prediction path of the updated transaction data in the selected target isolation tree according to the execution parameters of the updated transaction data when being executed by the smart contract, and recording the identifier of the updated transaction data in the tree node included in the transaction data prediction path, and adding one to the node value of the tree node of the target isolation tree included in the transaction prediction path to obtain an updated isolation tree, and updating the target isolation forest according to the updated isolation tree; or determining historical transaction data from all sample transaction data participating in the construction of the target isolation forest, and updating the target isolation forest according to the target identifier of the historical transaction data and the execution parameters of the updated transaction data when being executed by the smart contract.

[0226] In another implementation, updating the isolation forest includes: obtaining, within a target sampling time, the execution parameters of the updated transaction data during the smart contract execution process in the block corresponding to the current block height, then determining the target isolation forest corresponding to the target sampling time interval, and determining the historical transaction data involved in constructing the target isolation forest; this historical transaction data is the sample transaction data with the earliest execution time among all sample transaction data involved in constructing the target isolation forest; and updating the target isolation forest based on the historical transaction data and the execution parameters of the updated transaction data during the smart contract execution process. By obtaining the updated transaction data within the target sampling time, the corresponding target isolation forest can be quickly determined, thereby improving the efficiency of updating the isolation forest.

[0227] The M isolation forests described above correspond to sampling time intervals. A target isolation forest corresponding to the target sampling time interval can be determined from the M isolation forests. This target isolation forest is constructed based on the sample execution parameters of the sample transaction data during the smart contract execution process. The sample transaction data involved in constructing the target isolation forest corresponds to the execution time. The execution time refers to the time when the sample transaction data is executed. In this case, the sample transaction data with the earliest execution time among the sample transaction data involved in constructing the target isolation forest is determined as the historical transaction data. For example, if both sample transaction data 1 and sample transaction data 2 participate in constructing the target isolation forest, and the execution time of sample transaction data 1 is earlier than that of sample transaction data 2, then sample transaction data 1 is considered the historical transaction data.

[0228] In another implementation, updating the isolation forest includes the following steps S81-S84:

[0229] S81. Obtain execution parameters for updating transaction data in a block corresponding to the current block height during execution of the smart contract.

[0230] Specifically, when block generation or verification is complete, a new block is added to the blockchain. The execution parameters for the updated transaction data in the block corresponding to the current block height during the smart contract execution process can be obtained. It should be understood that the number of updated transaction data can be one or more, and this embodiment of the application does not impose any limitation on this. The following description assumes that the number of updated transaction data is one.

[0231] Among them, the block corresponding to the current block height includes a transaction data stream, which includes multiple transaction data, and each transaction data corresponds to an execution time. Transaction data can be randomly selected from the block corresponding to the current block height as the updated transaction data; or the transaction data with the latest execution time can be selected from the block corresponding to the current block height as the updated transaction data. In this way, the isolation forest can be updated in real time according to the latest transaction data.

[0232] S82. Determine the historical transaction data with the earliest execution time from all sample transaction data involved in constructing the M isolation forests. The number of historical transaction data can be one or more, and the following description will assume that the number of historical transaction data is one.

[0233] S83. Determine a target isolation forest constructed with historical transaction data from the M isolation forests.

[0234] In one implementation, the tree nodes of the isolation trees in each isolation forest record the identification of the transaction data, and the target isolation forest constructed with the historical transaction data can be determined from the M isolation forests based on the identification of the historical transaction data.

[0235] S84. Update the target isolation forest based on the historical transaction data and the execution parameters of the updated transaction data during the execution of the smart contract.

[0236] In one implementation, updating the target isolation forest based on historical transaction data and the execution parameters of the updated transaction data during the smart contract execution process may specifically include the following steps 1 to 4:

[0237] Step 1: In the target isolation forest, determine the target isolation tree where the historical transaction data is located.

[0238] In a specific implementation, the tree nodes of the isolation trees in the target isolation forest record the identifiers of the sample transaction data, and the target isolation tree where the historical transaction data is located can be determined according to the target identifier of the historical transaction data.

[0239] Step 2: Delete the target identifier of the historical transaction data from the target isolation tree to obtain a first updated isolation tree.

[0240] In one implementation, deleting the target identifier of the historical transaction data from the target isolation tree to obtain the first updated isolation tree may include: determining a transaction prediction path of the historical transaction data from the target isolation tree; including a tree node of the target isolation tree in the transaction prediction path; recording the target identifier of the historical transaction data in the tree node in the transaction prediction path; deleting the target identifier recorded in the tree node in the transaction prediction path, and subtracting one from the node value of the tree node included in the transaction prediction path to obtain the first updated isolation tree. For example, see Figure 10A , is a flow chart of updating a target isolation tree provided by an embodiment of the present application. Assume that the transaction prediction path of the historical transaction data determined from the target isolation tree is: root node 10-intermediate node 11-leaf node 12; the target identifier of the historical transaction data can be deleted from the root node 10, intermediate node 11 and intermediate node 13, and the node value of the root node 10, the node value of the intermediate node 11 and the node value of the leaf node 12 are respectively reduced by 1, and the following is obtained: Figure 10A The first updated isolation tree is shown.

[0241] Optionally, deleting the target identifier of the historical transaction data from the target isolation tree to obtain the first updated isolation tree may also include, after subtracting one from the node value of the tree node included in the transaction prediction path, determining whether there is a leaf node with an empty node value in the target isolation tree after the node value is subtracted by one, and if there is a leaf node with an empty node value in the target isolation tree after the node value is subtracted by one, deleting the leaf node with an empty node value. Then, it is necessary to analyze the target isolation tree after the node value is subtracted by one along the transaction prediction path to determine whether there is a tree node to be processed. Specifically, the target isolation tree after the node value is subtracted by one can be traced back along the transaction prediction path to determine whether there is a tree node to be processed, wherein the tree node to be processed refers to a tree node with a target value (such as 1) in the target isolation tree after the node value is subtracted by one. If there is a tree node to be processed, the node of the tree node to be processed is deleted from the target isolation tree after the node value is subtracted by one to obtain the first isolation tree. For example, see Figure 10B A flowchart of another method for updating a target isolation tree is provided in an embodiment of the present application; assuming that the transaction prediction path of the historical transaction data determined from the target isolation tree is: root node 13-intermediate node 14-leaf node 15; the target identifier of the historical transaction data can be deleted from the root node 13, the intermediate node 14 and the leaf node 15, and the node value of the root node 13, the node value of the intermediate node 14 and the node value of the leaf node 15 are respectively reduced by one; then, it is determined whether there is a leaf node with an empty node value in the target isolation tree after the node value is reduced by one, such as Figure 10B In the target isolation tree after the node value is reduced by one, if there is a leaf node 15 with an empty node value, then delete the leaf node 15; then backtrack upward along the root node 13-intermediate node 14-leaf node 15 to the target isolation tree after the node value is reduced by one, that is, first backtrack to the intermediate node 14, and find that the node value of the intermediate node 14 is the target value 1; then, continue to backtrack to the root node 13, the node value of the root node 13 is not the target value 1, and then delete the child node 16 of the intermediate node 14 from the target isolation tree after the node value is reduced by one, and get the following Figure 10B It should be understood that since the isolation tree is a binary tree, when the node value of a tree node is the target value, it means that it cannot be split, so the child nodes of the tree node with the target value need to be deleted.

[0242] Among them, determining the transaction prediction path of historical transaction data from the target isolation tree can be: directly searching the tree node recording the target identifier from the target isolation tree according to the target identifier of the historical transaction data, thereby obtaining the transaction prediction path of the historical transaction data; or, determining the transaction prediction path of the historical transaction data in the target isolation tree according to the sample execution parameters of the historical transaction data during the execution of the smart contract.

[0243] Step 3: Update the first update isolation tree according to the identifier of the update transaction data and the execution parameters of the update transaction data during the execution of the smart contract to obtain a second update isolation tree.

[0244] In one implementation, the specific implementation of step 3 includes: determining the target prediction path of the update transaction data in the first update isolation tree according to the execution parameters of the update transaction data during the execution of the smart contract; the target prediction path includes the target tree node of the first update isolation tree; recording the identifier of the update transaction data in the target tree node, and adding one to the node value of the target tree node of the first update isolation tree to obtain the second update isolation tree. For example, Figure 10C As shown, it is a flow chart of an update isolation tree provided in an embodiment of the present application. It is assumed that according to the execution parameters of the updated transaction data during the execution of the smart contract, the target predicted path of the updated transaction data is determined in the first update isolation tree as the root node 17-intermediate node 18-leaf node 19; the identifier of the updated transaction data can be recorded in the root node 17, the intermediate node 18 and the leaf node 19, and the node value of the root node 17, the intermediate node 18 and the leaf node 19 in the first update isolation tree is increased by one to obtain a second update isolation tree.

[0245] Step 4: Update the target isolation forest according to the second updated isolation tree.

[0246] In summary, the embodiments of the present application can update the isolation forest in real time by continuously deleting the oldest (i.e., the earliest executed) transaction data from the transaction data stream that constructs the isolation forest and adding new transaction data. This enables the isolation forest model to self-adjust to adapt to changes in smart contract behavior, which not only improves the adaptability and robustness of the isolation forest, but also reduces misjudgments caused by outdated historical transaction data, ensuring that the isolation forest remains efficient and accurate in a dynamically changing blockchain environment, which is conducive to improving the accuracy of smart contract anomaly detection.

[0247] Next, the blockchain-based anomaly detection device provided in the embodiment of the present application is described.

[0248] See Figure 11 , Figure 11 This is a schematic diagram of the structure of a blockchain-based anomaly detection device provided in an embodiment of the present application. The blockchain-based anomaly detection device can be a computer program (including program code) in a computer device. For example, the blockchain-based anomaly detection device can be an application software in a computer device. The blockchain-based anomaly detection device can be used to execute Figure 6 and Figure 9Some or all of the steps in the method embodiment shown. Figure 11 , the blockchain-based anomaly detection device includes the following units:

[0249] The acquisition unit 1101 is configured to acquire execution parameters of the transaction data during execution by the target smart contract, where the execution parameters include indicator data of p dimensions; p is a positive integer; and the target smart contract is any smart contract among the at least one smart contract.

[0250] An acquisition unit 1101 is configured to acquire M isolation forests, where the isolation forests are constructed based on sample execution parameters of sample transaction data during smart contract execution; each isolation forest includes n isolation trees, where n is an integer greater than 1; and M is a positive integer.

[0251] Processing unit 1102 is configured to select K prediction isolation trees from the M isolation forests and determine, based on the indicator data of P dimensions, the path depth of the transaction data in each prediction isolation tree and the node value of the leaf node corresponding to the transaction data in each prediction isolation tree; K is a positive integer and is less than or equal to n×M;

[0252] The processing unit 1102 is further configured to determine a predicted value of the transaction data in each isolation forest based on the path depth of the transaction data in each prediction isolation tree and the node value of the leaf node corresponding to the transaction data in each prediction isolation tree;

[0253] The processing unit 1102 is further configured to perform anomaly detection on the target smart contract based on the predicted values ​​of the transaction data in each isolation forest to obtain a detection result.

[0254] The processing unit 1102 is specifically configured to:

[0255] Determine the predicted value of the transaction data in each prediction isolation tree based on the path depth of the transaction data in each prediction isolation tree and the node value of the corresponding leaf node of the transaction data in each prediction isolation tree;

[0256] According to the predicted values ​​of the transaction data in each prediction isolation tree, the predicted values ​​of the transaction data in each isolation forest are determined.

[0257] The processing unit 1102 is specifically configured to:

[0258] Determine the anomaly score of the target smart contract during execution based on the predicted value of the transaction data in each isolation forest;

[0259] If the anomaly score is greater than the anomaly threshold, the detection result of the target smart contract anomaly is obtained.

[0260] The processing unit 1102 is specifically configured to:

[0261] Get the execution time of the transaction data when it is executed by the target smart contract;

[0262] Determine the weight corresponding to the predicted value of the transaction data in each isolation forest based on the execution time and the sampling time interval corresponding to each isolation forest. The greater the time interval between the execution time and the sampling time interval corresponding to the isolation forest, the greater the weight corresponding to the predicted value of the transaction data in the isolation forest.

[0263] The predicted values ​​of transaction data in each isolation forest and the corresponding weights are weighted summed to obtain the anomaly score of the target smart contract during execution.

[0264] The processing unit 1102 is specifically configured to:

[0265] According to the indicator data of p dimensions, the prediction path of the transaction data is determined in the i-th prediction isolation tree; i is a positive integer less than or equal to K;

[0266] When the predicted path of the transaction data reaches the leaf node of the i-th prediction isolation tree, the path depth of the transaction data in the i-th prediction isolation tree is determined based on the tree nodes of the i-th prediction isolation tree included in the predicted path;

[0267] The node value of the leaf node in the prediction path is used as the node value of the corresponding leaf node in the i-th prediction isolation tree of the transaction data.

[0268] The processing unit 1102 is further configured to:

[0269] Obtain n groups of sample data, each group of sample data includes m sample transaction data, each sample transaction data corresponds to a sample execution parameter; the sample execution parameter includes sample indicator data of p dimensions;

[0270] Based on the sample execution parameters corresponding to the m transaction data included in any one set of sample data among the n sets of sample data, the m sample transaction data included in any one set of sample data are segmented and divided according to the sample indicator data of each dimension and the segmentation value corresponding to each dimension, thereby obtaining multiple data sets, each of which corresponds to a tree node; the tree node records the identifier of the sample transaction data included in the corresponding data set;

[0271] According to the number of transactions in the sample transaction data in each data set, the node value of each corresponding tree node is obtained, and the isolation tree corresponding to any set of sample data is generated according to the node value of each tree node;

[0272] According to the isolation tree corresponding to each group of sample data, an isolation forest is constructed.

[0273] The processing unit 1102 is specifically configured to:

[0274] Within the target sampling time interval, obtain the sample execution parameters of the sample transaction data in the block during the smart contract execution process;

[0275] The sample execution parameters of the acquired sample transaction data during the smart contract execution process are stored in the transaction collection table;

[0276] If the target sampling time interval in the transaction collection table meets the sampling conditions, the sample transaction data within the target sampling time interval in the transaction collection table is sampled;

[0277] The sampled transaction data is divided into n groups of sample data.

[0278] The blockchain includes multiple blocks, and the processing unit 1102 is further configured to:

[0279] Get the execution parameters of the transaction data in the block corresponding to the current block height and update it during the execution of the smart contract;

[0280] From all the sample transaction data involved in constructing the M isolation forests, determine the historical transaction data with the earliest execution time;

[0281] Determine the target isolation forest constructed with historical transaction data from the M isolation forests;

[0282] Update the target isolation forest based on historical transaction data and the execution parameters of updated transaction data during the execution of the smart contract.

[0283] The processing unit 1102 is specifically configured to:

[0284] In the target isolation forest, determine the target isolation tree where the historical transaction data is located;

[0285] Deleting the target identifier of the historical transaction data from the target isolation tree to obtain a first updated isolation tree;

[0286] Update the first update isolation tree according to the identifier of the update transaction data and the execution parameters of the update transaction data during the execution of the smart contract to obtain a second update isolation tree;

[0287] The target isolation forest is updated according to the second updated isolation tree.

[0288] The processing unit 1102 is specifically configured to:

[0289] Determining a transaction prediction path of the historical transaction data from the target isolation tree; the transaction prediction path includes a tree node of the target isolation tree; the tree node in the transaction prediction path records a target identifier of the historical transaction data;

[0290] The target identifier recorded in the tree node in the transaction prediction path is deleted, and the node value of the tree node included in the transaction prediction path is reduced by one to obtain a first updated isolation tree.

[0291] The processing unit 1102 is further configured to:

[0292] If there is a leaf node with an empty node value in the target isolation tree after the node value is reduced by one, the leaf node with an empty node value is deleted;

[0293] Analyze the target isolation tree after the node value is reduced by one along the transaction prediction path to determine whether there is a tree node to be processed. The tree node to be processed refers to the tree node whose node value is the target value in the target isolation tree after the node value is reduced by one;

[0294] If there is a tree node to be processed, the child nodes of the tree node to be processed are deleted from the target isolation tree after the node value is reduced by one to obtain a first updated isolation tree.

[0295] The processing unit 1102 is specifically configured to:

[0296] Determining a target prediction path for the update transaction data in the first update isolation tree according to execution parameters of the update transaction data during execution of the smart contract; the target prediction path includes a target tree node of the first update isolation tree;

[0297] The identifier of the updated transaction data is recorded in the target tree node, and the node value of the target tree node of the first update isolation tree is increased by one to obtain a second update isolation tree.

[0298] The processing unit 1102 is specifically configured to:

[0299] Within the target sampling time interval, obtain the initial sample execution parameters of the sample transaction data in the block during the smart contract execution process;

[0300] Preprocessing the initial sample execution parameters of the sample transaction data during the smart contract execution process to obtain the sample execution parameters of the sample transaction data during the smart contract execution process;

[0301] Among them, the preprocessing includes at least one of the following: normalizing the initial sample execution parameters of the sample transaction data during the execution of the smart contract; cleaning the indicator data included in the initial sample execution parameters of the sample transaction data during the execution of the smart contract.

[0302] In an embodiment of the present application, at least one smart contract is deployed on the blockchain, and execution parameters of transaction data during the execution process of the target smart contract are obtained, and the execution parameters include index data of p dimensions; p is a positive integer; the target smart contract is any smart contract in the at least one smart contract; then, M isolation forests are obtained, and the isolation forest is constructed based on the sample execution parameters of the sample transaction data during the execution process of the smart contract; each isolation forest includes n isolation trees, n is an integer greater than 1; M is a positive integer; K predicted isolation trees are selected from the M isolation forests, and based on the index data of P dimensions, the path depth of the transaction data in each predicted isolation tree and the node value of the corresponding leaf node of the transaction data in each predicted isolation tree are determined; K is a positive integer, and K is less than or equal to n×M; according to the path depth of the transaction data in each predicted isolation tree and the node value of the corresponding leaf node of the transaction data in each predicted isolation tree, the predicted value of the transaction data in each isolation forest is determined; according to the predicted value of the transaction data in each isolation forest, anomaly detection is performed on the target smart contract to obtain a detection result. It can be seen that the embodiment of the present application realizes unsupervised detection of smart contracts by constructing an isolation forest through the sample execution parameters of sample transaction data, which avoids the time-consuming labeling caused by supervised learning. At the same time, through the indicator data of transaction data in different dimensions, the path depth of transaction data in the predicted isolation tree and the node value of the corresponding leaf node can be predicted more accurately. In this way, the predicted value of transaction data in each isolation forest can be determined according to the path depth and node value, and then the smart contract can be effectively detected for anomalies based on the predicted value.

[0303] Next, the computer device provided in the embodiments of the present application is described.

[0304] Furthermore, the present invention also provides a schematic diagram of the structure of a computer device. Figure 12 The computer device may be the aforementioned anomaly detection device and may include a processor 1201, an input device 1202, an output device 1203, and a memory 1204. The processor 1201, input device 1202, output device 1203, and memory 1204 are connected via a bus. Memory 1204 is configured to store a computer program, which includes program instructions. Processor 1201 is configured to execute the program instructions stored in memory 1204.

[0305] In the embodiment of the present application, the processor 1201 performs the following operations by running the program instructions in the memory 1204:

[0306] Obtain the execution parameters of the transaction data during the execution of the target smart contract. The execution parameters include indicator data of p dimensions; p is a positive integer; the target smart contract is any smart contract in at least one smart contract;

[0307] Obtain M isolation forests. Isolation forests are constructed based on sample execution parameters of sample transaction data during smart contract execution. Each isolation forest contains n isolation trees, where n is an integer greater than 1 and M is a positive integer.

[0308] Select K prediction isolation trees from M isolation forests, and determine the path depth of the transaction data in each prediction isolation tree and the node value of the corresponding leaf node of the transaction data in each prediction isolation tree based on the indicator data of P dimensions; K is a positive integer and K is less than or equal to n×M;

[0309] Determine the predicted value of the transaction data in each isolation forest based on the path depth of the transaction data in each prediction isolation tree and the node value of the corresponding leaf node in each prediction isolation tree;

[0310] According to the predicted values ​​of transaction data in each isolation forest, anomaly detection is performed on the target smart contract to obtain the detection results.

[0311] When determining the predicted value of the transaction data in each isolation forest based on the path depth of the transaction data in each prediction isolation tree and the node value of the leaf node corresponding to the transaction data in each prediction isolation tree, the processor 1201 may specifically perform the following operations:

[0312] Determine the predicted value of the transaction data in each prediction isolation tree based on the path depth of the transaction data in each prediction isolation tree and the node value of the corresponding leaf node of the transaction data in each prediction isolation tree;

[0313] According to the predicted values ​​of the transaction data in each prediction isolation tree, the predicted values ​​of the transaction data in each isolation forest are determined.

[0314] The processor 1201 performs anomaly detection on the target smart contract based on the predicted values ​​of the transaction data in each isolation forest. When the detection result is obtained, the processor 1201 may specifically perform the following operations:

[0315] Determine the anomaly score of the target smart contract during execution based on the predicted value of the transaction data in each isolation forest;

[0316] If the anomaly score is greater than the anomaly threshold, the detection result of the target smart contract anomaly is obtained.

[0317] When determining the anomaly score of the target smart contract during execution based on the predicted values ​​of the transaction data in each isolation forest, the processor 1201 may specifically perform the following operations:

[0318] Get the execution time of the transaction data when it is executed by the target smart contract;

[0319] Determine the weight corresponding to the predicted value of the transaction data in each isolation forest based on the execution time and the sampling time interval corresponding to each isolation forest. The greater the time interval between the execution time and the sampling time interval corresponding to the isolation forest, the greater the weight corresponding to the predicted value of the transaction data in the isolation forest.

[0320] The predicted values ​​of transaction data in each isolation forest and the corresponding weights are weighted summed to obtain the anomaly score of the target smart contract during execution.

[0321] When determining the path depth of the transaction data in each prediction isolation tree and the node value of the leaf node corresponding to the transaction data in each prediction isolation tree based on the indicator data of the P dimensions, the processor 1201 may specifically perform the following operations:

[0322] According to the indicator data of p dimensions, the prediction path of the transaction data is determined in the i-th prediction isolation tree; i is a positive integer less than or equal to K;

[0323] When the predicted path of the transaction data reaches the leaf node of the i-th prediction isolation tree, the path depth of the transaction data in the i-th prediction isolation tree is determined based on the tree nodes of the i-th prediction isolation tree included in the predicted path;

[0324] The node value of the leaf node in the prediction path is used as the node value of the corresponding leaf node in the i-th prediction isolation tree of the transaction data.

[0325] The processor 1201 may further perform the following operations:

[0326] Obtain n groups of sample data, each group of sample data includes m sample transaction data, each sample transaction data corresponds to a sample execution parameter; the sample execution parameter includes sample indicator data of p dimensions;

[0327] Based on the sample execution parameters corresponding to the m transaction data included in any one set of sample data among the n sets of sample data, the m sample transaction data included in any one set of sample data are segmented and divided according to the sample indicator data of each dimension and the segmentation value corresponding to each dimension, thereby obtaining multiple data sets, each of which corresponds to a tree node; the tree node records the identifier of the sample transaction data included in the corresponding data set;

[0328] According to the number of transactions in the sample transaction data in each data set, the node value of each corresponding tree node is obtained, and the isolation tree corresponding to any set of sample data is generated according to the node value of each tree node;

[0329] According to the isolation tree corresponding to each group of sample data, an isolation forest is constructed.

[0330] When acquiring n groups of sample data, the processor 1201 may specifically perform the following operations:

[0331] Within the target sampling time interval, obtain the sample execution parameters of the sample transaction data in the block during the smart contract execution process;

[0332] The sample execution parameters of the acquired sample transaction data during the smart contract execution process are stored in the transaction collection table;

[0333] If the target sampling time interval in the transaction collection table meets the sampling conditions, the sample transaction data within the target sampling time interval in the transaction collection table is sampled;

[0334] The sampled transaction data is divided into n groups of sample data.

[0335] The blockchain includes multiple blocks, and the processor 1201 can also perform the following operations:

[0336] Get the execution parameters of the transaction data in the block corresponding to the current block height and update it during the execution of the smart contract;

[0337] From all the sample transaction data involved in constructing the M isolation forests, determine the historical transaction data with the earliest execution time;

[0338] Determine the target isolation forest constructed with historical transaction data from the M isolation forests;

[0339] Update the target isolation forest based on historical transaction data and the execution parameters of updated transaction data during the execution of the smart contract.

[0340] When updating the target isolation forest based on historical transaction data and the execution parameters of the updated transaction data during the smart contract execution process, the processor 1201 may specifically perform the following operations:

[0341] In the target isolation forest, determine the target isolation tree where the historical transaction data is located;

[0342] Deleting the target identifier of the historical transaction data from the target isolation tree to obtain a first updated isolation tree;

[0343] Update the first update isolation tree according to the identifier of the update transaction data and the execution parameters of the update transaction data during the execution of the smart contract to obtain a second update isolation tree;

[0344] The target isolation forest is updated according to the second updated isolation tree.

[0345] When the processor 1201 deletes the target identifier of the historical transaction data from the target isolation tree to obtain the first updated isolation tree, it may specifically perform the following operations:

[0346] Determining a transaction prediction path of the historical transaction data from the target isolation tree; the transaction prediction path includes a tree node of the target isolation tree; the tree node in the transaction prediction path records a target identifier of the historical transaction data;

[0347] The target identifier recorded in the tree node in the transaction prediction path is deleted, and the node value of the tree node included in the transaction prediction path is reduced by one to obtain a first updated isolation tree.

[0348] The processor 1201 may further perform the following operations:

[0349] If there is a leaf node with an empty node value in the target isolation tree after the node value is reduced by one, the leaf node with an empty node value is deleted;

[0350] Analyze the target isolation tree after the node value is reduced by one along the transaction prediction path to determine whether there is a tree node to be processed. The tree node to be processed refers to the tree node whose node value is the target value in the target isolation tree after the node value is reduced by one;

[0351] If there is a tree node to be processed, the child nodes of the tree node to be processed are deleted from the target isolation tree after the node value is reduced by one to obtain a first updated isolation tree.

[0352] When the processor 1201 updates the first update isolation tree according to the identifier of the update transaction data and the execution parameters of the update transaction data during the execution of the smart contract to obtain the second update isolation tree, it may specifically perform the following operations:

[0353] Determining a target prediction path for the update transaction data in the first update isolation tree according to execution parameters of the update transaction data during execution of the smart contract; the target prediction path includes a target tree node of the first update isolation tree;

[0354] The identifier of the updated transaction data is recorded in the target tree node, and the node value of the target tree node of the first update isolation tree is increased by one to obtain a second update isolation tree.

[0355] When the processor 1201 obtains sample execution parameters of sample transaction data in a block during smart contract execution within the target sampling time interval, it may specifically perform the following operations:

[0356] Within the target sampling time interval, obtain the initial sample execution parameters of the sample transaction data in the block during the smart contract execution process;

[0357] Preprocessing the initial sample execution parameters of the sample transaction data during the smart contract execution process to obtain the sample execution parameters of the sample transaction data during the smart contract execution process;

[0358] Among them, the preprocessing includes at least one of the following: normalizing the initial sample execution parameters of the sample transaction data during the execution of the smart contract; cleaning the indicator data included in the initial sample execution parameters of the sample transaction data during the execution of the smart contract.

[0359] In an embodiment of the present application, at least one smart contract is deployed on the blockchain, and execution parameters of transaction data during the execution process of the target smart contract are obtained, and the execution parameters include index data of p dimensions; p is a positive integer; the target smart contract is any smart contract in the at least one smart contract; then, M isolation forests are obtained, and the isolation forest is constructed based on the sample execution parameters of the sample transaction data during the execution process of the smart contract; each isolation forest includes n isolation trees, n is an integer greater than 1; M is a positive integer; K predicted isolation trees are selected from the M isolation forests, and based on the index data of P dimensions, the path depth of the transaction data in each predicted isolation tree and the node value of the corresponding leaf node of the transaction data in each predicted isolation tree are determined; K is a positive integer, and K is less than or equal to n×M; according to the path depth of the transaction data in each predicted isolation tree and the node value of the corresponding leaf node of the transaction data in each predicted isolation tree, the predicted value of the transaction data in each isolation forest is determined; according to the predicted value of the transaction data in each isolation forest, anomaly detection is performed on the target smart contract to obtain a detection result. It can be seen that the embodiment of the present application realizes unsupervised detection of smart contracts by constructing an isolation forest through the sample execution parameters of sample transaction data, which avoids the time-consuming labeling caused by supervised learning. At the same time, through the indicator data of transaction data in different dimensions, the path depth of transaction data in the predicted isolation tree and the node value of the corresponding leaf node can be predicted more accurately. In this way, the predicted value of transaction data in each isolation forest can be determined according to the path depth and node value, and then the smart contract can be effectively detected for anomalies based on the predicted value.

[0360] In the embodiments of the present application, the term "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories), or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more units. In addition, each unit can be part of an overall unit that includes the function of the unit.

[0361] In addition, it should be noted that the present invention also provides a computer-readable storage medium, and the computer-readable storage medium stores a computer program, and the computer program includes program instructions. When the processor executes the above program instructions, it can execute the above Figure 6 or Figure 9 The method in the corresponding embodiment will therefore not be described in detail here. For technical details not disclosed in the computer-readable storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application. As an example, the program instructions can be deployed on a computer device, or executed on multiple computer devices located in one location, or executed on multiple computer devices distributed in multiple locations and interconnected by a communication network.

[0362] According to one aspect of the present application, a computer program product is provided, the computer program product comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, so that the computer device can perform the above-mentioned Figure 6 or Figure 9 The method in the corresponding embodiment will therefore not be described in detail here.

[0363] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware through a computer program. The program can be stored in a computer-readable storage medium, and when executed, the program can include the processes in the above-described method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0364] The above disclosure is only a preferred embodiment of the present application, and certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A blockchain-based anomaly detection method, characterized in that: At least one smart contract is deployed on the blockchain, and the method includes: Obtaining execution parameters of the transaction data during execution by the target smart contract, where the execution parameters include indicator data of p dimensions; p is a positive integer; and the target smart contract is any smart contract among the at least one smart contract; Obtain M isolation forests, each constructed based on sample execution parameters of sample transaction data during smart contract execution; each isolation forest includes n isolation trees, where n is an integer greater than 1; and M is a positive integer; Selecting K prediction isolation trees from the M isolation forests, and determining the path depth of the transaction data in each prediction isolation tree and the node value of the leaf node corresponding to the transaction data in each prediction isolation tree based on the indicator data of the P dimensions; K is a positive integer and is less than or equal to n×M; Determining a predicted value of the transaction data in each isolation forest based on the path depth of the transaction data in each prediction isolation tree and the node value of a leaf node corresponding to the transaction data in each prediction isolation tree; According to the predicted values ​​of the transaction data in each isolation forest, anomaly detection is performed on the target smart contract to obtain a detection result.

2. The method according to claim 1, wherein Determining the predicted value of the transaction data in each isolation forest according to the path depth of the transaction data in each prediction isolation tree and the node value of the leaf node corresponding to the transaction data in each prediction isolation tree includes: Determining a predicted value of the transaction data in each prediction isolation tree according to a path depth of the transaction data in each prediction isolation tree and a node value of a leaf node corresponding to the transaction data in each prediction isolation tree; Determine the predicted values ​​of the transaction data in each isolation forest according to the predicted values ​​of the transaction data in each prediction isolation tree.

3. The method according to claim 1 or 2, wherein: The performing anomaly detection on the target smart contract based on the predicted value of the transaction data in each isolation forest to obtain a detection result includes: Determining an anomaly score of the target smart contract during execution based on the predicted values ​​of the transaction data in each isolation forest; If the anomaly score is greater than the anomaly threshold, the detection result of the target smart contract anomaly is obtained.

4. The method according to claim 3, wherein Determining an anomaly score of the target smart contract during execution based on the predicted value of the transaction data in each isolation forest includes: Obtaining the execution time of the transaction data when it is executed by the target smart contract; determining, based on the execution time and the sampling time interval corresponding to each isolation forest, a weight corresponding to the predicted value of the transaction data in each isolation forest; wherein, the greater the time interval between the execution time and the sampling time interval corresponding to the isolation forest, the greater the weight corresponding to the predicted value of the transaction data in the isolation forest; The predicted values ​​of the transaction data in each isolation forest and the corresponding weights are weighted summed to obtain an anomaly score of the target smart contract during execution.

5. The method according to claim 1, wherein Determining the path depth of the transaction data in each prediction isolation tree and the node value of the leaf node corresponding to the transaction data in each prediction isolation tree based on the indicator data of the P dimensions includes: Determine, in the i-th prediction isolation tree, a predicted path of the transaction data according to the indicator data of the p dimensions; i is a positive integer less than or equal to K; When the predicted path of the transaction data reaches a leaf node of the i-th prediction isolation tree, determining the path depth of the transaction data in the i-th prediction isolation tree according to the tree nodes of the i-th prediction isolation tree included in the predicted path; The node value of the leaf node in the predicted path is used as the node value of the corresponding leaf node in the i-th predicted isolation tree of the transaction data.

6. The method according to claim 1, wherein Also includes: Obtain n groups of sample data, each group of sample data including m sample transaction data, each sample transaction data corresponding to a sample execution parameter; the sample execution parameter includes sample indicator data of p dimensions; Based on the sample execution parameters corresponding to the m transaction data included in any one group of sample data among the n groups of sample data, the m sample transaction data included in any one group of sample data are segmented and divided according to the sample indicator data of each dimension and the segmentation value corresponding to each dimension, thereby obtaining multiple data sets, each data set corresponding to a tree node; the tree node records the identifier of the sample transaction data included in the corresponding data set; Obtaining a node value of each corresponding tree node according to the transaction quantity of the sample transaction data in each data set, and generating an isolation tree corresponding to any set of sample data according to the node value of each tree node; An isolation forest is constructed based on the isolation trees corresponding to each group of sample data.

7. The method according to claim 6, wherein The obtaining of n groups of sample data includes: Within the target sampling time interval, obtain the sample execution parameters of the sample transaction data in the block during the smart contract execution process; The sample execution parameters of the acquired sample transaction data during the smart contract execution process are stored in the transaction collection table; If the target sampling time interval in the transaction collection table meets the sampling condition, sampling the sample transaction data within the target sampling time interval in the transaction collection table; The sampled transaction data is divided into n groups of sample data.

8. The method according to claim 1, wherein The blockchain includes a plurality of blocks, and the method further includes: Get the execution parameters of the transaction data in the block corresponding to the current block height and update it during the execution of the smart contract; Determine the historical transaction data with the earliest execution time from all sample transaction data involved in constructing the M isolation forests; Determining a target isolation forest constructed with the historical transaction data from the M isolation forests; The target isolation forest is updated according to the historical transaction data and the execution parameters of the updated transaction data during the execution of the smart contract.

9. The method according to claim 8, wherein Updating the target isolation forest according to the historical transaction data and the execution parameters of the updated transaction data during the smart contract execution process includes: In the target isolation forest, determining the target isolation tree where the historical transaction data is located; Deleting the target identifier of the historical transaction data from the target isolation tree to obtain a first updated isolation tree; Updating the first update isolation tree according to the identifier of the update transaction data and the execution parameters of the update transaction data during the execution of the smart contract to obtain a second update isolation tree; The target isolation forest is updated according to the second updated isolation tree.

10. The method according to claim 9, wherein The step of deleting the target identifier of the historical transaction data from the target isolation tree to obtain a first updated isolation tree includes: Determining a transaction prediction path of the historical transaction data from the target isolation tree; the transaction prediction path includes tree nodes of the target isolation tree; the tree nodes in the transaction prediction path record target identifiers of the historical transaction data; The target identifier recorded in the tree node in the transaction prediction path is deleted, and the node value of the tree node included in the transaction prediction path is reduced by one to obtain a first updated isolation tree.

11. The method according to claim 10, wherein The method further comprises: If there is a leaf node with an empty node value in the target isolation tree after the node value is reduced by one, then delete the leaf node with an empty node value; Analyzing the target isolation tree after the node value is reduced by one along the transaction prediction path to determine whether there is a tree node to be processed, wherein the tree node to be processed refers to a tree node whose node value is the target value in the target isolation tree after the node value is reduced by one; If the tree node to be processed exists, the child nodes of the tree node to be processed are deleted from the target isolation tree after the node value is reduced by one, so as to obtain a first updated isolation tree.

12. The method according to any one of claims 8 to 11, characterized in that The updating of the first update isolation tree according to the identifier of the update transaction data and the execution parameters of the update transaction data during the execution of the smart contract to obtain the second update isolation tree includes: Determining a target prediction path for the update transaction data in the first update isolation tree according to execution parameters of the update transaction data during execution of the smart contract; the target prediction path includes a target tree node of the first update isolation tree; The identifier of the update transaction data is recorded in the target tree node, and the node value of the target tree node of the first update isolation tree is increased by one to obtain a second update isolation tree.

13. The method according to claim 7, wherein The sample execution parameters of the sample transaction data in the block during the smart contract execution process are obtained within the target sampling time interval, including: Within the target sampling time interval, obtain the initial sample execution parameters of the sample transaction data in the block during the smart contract execution process; Preprocessing initial sample execution parameters of the sample transaction data during the execution of the smart contract to obtain sample execution parameters of the sample transaction data during the execution of the smart contract; Among them, the preprocessing includes at least one of the following: normalizing the initial sample execution parameters of the sample transaction data during the execution of the smart contract; cleaning the indicator data included in the initial sample execution parameters of the sample transaction data during the execution of the smart contract.

14. A blockchain-based anomaly detection device, characterized in that: At least one smart contract is deployed on the blockchain, and the device includes: an acquisition unit, configured to acquire execution parameters of the transaction data during execution by the target smart contract, wherein the execution parameters include indicator data of p dimensions; p is a positive integer; and the target smart contract is any smart contract among the at least one smart contract; The acquisition unit is configured to acquire M isolation forests, where the isolation forests are constructed based on sample execution parameters of the sample transaction data during execution of the smart contract; each isolation forest includes n isolation trees, where n is an integer greater than 1; and M is a positive integer; a processing unit, configured to select K predicted isolation trees from the M isolation forests, and determine, based on the indicator data of the P dimensions, a path depth of the transaction data in each predicted isolation tree and a node value of a leaf node corresponding to the transaction data in each predicted isolation tree; K is a positive integer, and K is less than or equal to n×M; The processing unit is configured to determine a predicted value of the transaction data in each of the isolation forests based on a path depth of the transaction data in each of the prediction isolation trees and a node value of a leaf node corresponding to the transaction data in each of the prediction isolation trees; The processing unit is further configured to perform anomaly detection on the target smart contract based on the predicted value of the transaction data in each isolation forest to obtain a detection result.

15. A computer device, characterized in that: include: a processor suitable for executing a computer program; A computer-readable storage medium having a computer program stored therein, wherein when the computer program is executed by the processor, the blockchain-based anomaly detection method according to any one of claims 1 to 13 is executed.

16. A computer-readable storage medium, characterized in that The computer storage medium stores a computer program, and when the computer program is executed by the processor, the blockchain-based anomaly detection method according to any one of claims 1 to 13 is executed.

17. A computer program product, characterized in that The computer program product includes a computer program, and when the computer program is executed by a processor, the blockchain-based anomaly detection method according to any one of claims 1 to 13 is implemented.

Images