Web3.0-based block chain compliance detection method and device, equipment, medium and product

Abstract

The embodiment of the invention discloses a Web3.0-based block chain compliance detection method and device, equipment, a medium and a product, and the method comprises the steps: obtaining at least one type of on-chain data in a target block chain; based on a preset rule and the on-chain data, executing at least one item of compliance detection on the target block chain to obtain at least one detection feature vector; the at least one compliance detection comprises at least one of node compliance detection, account transaction compliance detection, intelligent contract detection and uplink data compliance detection; determining at least one parameter value based on the at least one detection feature vector; performing weighting processing on the at least one parameter value through at least one weight value corresponding to the at least one parameter value, and determining a statistical abnormal value; and based on the statistical abnormal value and at least one abnormal threshold, determining an abnormal level of the target block chain. According to the embodiment of the invention, the accuracy of compliance detection of the multi-entity network in the block chain is improved.

Description

Technical Field

[0001] This disclosure relates to blockchain technology, and in particular to a method, apparatus, device, medium, and product for blockchain compliance testing based on Web3.0. Background Technology

[0002] Due to its decentralized and immutable nature, blockchain technology is widely used in finance, supply chain, and identity verification. However, the decentralized nature of blockchain platforms complicates regulation, especially when multiple entities (nodes, users, smart contracts, etc.) participate. The lack of effective compliance mechanisms on blockchains often leads to risks. Summary of the Invention

[0003] To address the aforementioned technical problems, this disclosure is proposed. Embodiments of this disclosure provide a method, apparatus, electronic device, medium, and product for blockchain compliance testing based on Web3.0.

[0004] According to one aspect of the embodiments of this disclosure, a blockchain compliance detection method based on Web3.0 is provided, comprising: Acquire at least one type of on-chain data from the target blockchain; Based on preset rules and the on-chain data, at least one compliance check is performed on the target blockchain to obtain at least one detection feature vector; the at least one compliance check includes at least one of the following: node compliance check, account transaction compliance check, smart contract check, and on-chain data compliance check; Determine at least one parameter value based on the at least one detection feature vector; By weighting the at least one parameter value with at least one weight value corresponding to the at least one parameter value, statistical outliers are determined. The anomaly level of the target blockchain is determined based on the statistical outliers and at least one anomaly threshold.

[0005] According to another aspect of the embodiments of this disclosure, a blockchain compliance testing device based on Web3.0 is provided, characterized in that it includes: The data acquisition module is used to acquire at least one type of on-chain data from the target blockchain. The compliance detection module is used to perform at least one compliance detection on the target blockchain based on preset rules and the on-chain data, and obtain at least one detection feature vector; the at least one compliance detection includes at least one of the following: node compliance detection, account transaction compliance check, smart contract detection, and on-chain data compliance detection; A parameter determination module is used to determine at least one parameter value based on the at least one detection feature vector; An outlier statistics module is used to weight the at least one parameter value using at least one weight value corresponding to the at least one parameter value to determine statistical outliers; The level determination module is used to determine the anomaly level of the target blockchain based on the statistical outliers and at least one anomaly threshold.

[0006] According to another aspect of the present disclosure, an electronic device is provided, characterized in that it includes: Memory, used to store computer program products; A processor is configured to execute a computer program product stored in the memory, and when the computer program product is executed, to implement the Web3.0-based blockchain compliance detection method described in any of the above embodiments.

[0007] According to another aspect of the present disclosure, a computer-readable storage medium is provided, on which computer program instructions are stored, characterized in that, when the computer program instructions are executed by a processor, they implement the Web3.0-based blockchain compliance detection method described in any of the above embodiments.

[0008] According to another aspect of the present disclosure, a computer program product is provided, including computer program instructions, characterized in that, when executed by a processor, the computer program instructions implement the Web3.0-based blockchain compliance detection method described in any of the above embodiments.

[0009] Based on the Web3.0-based blockchain compliance detection method, apparatus, device, medium, and product provided in the above embodiments of this disclosure, at least one type of on-chain data in the target blockchain is acquired; based on preset rules and the on-chain data, at least one compliance detection is performed on the target blockchain to obtain at least one detection feature vector; the at least one compliance detection includes at least one of the following: node compliance detection, account transaction compliance check, smart contract detection, and on-chain data compliance detection; at least one parameter value is determined based on the at least one detection feature vector; the at least one parameter value is weighted by at least one weight value corresponding to the at least one parameter value to determine statistical outliers; based on the statistical outliers and at least one outlier threshold, the outlier level of the target blockchain is determined. This embodiment performs at least one compliance detection on the target blockchain, supervising the blockchain from multiple aspects; the statistical outliers are determined based on parameter values ​​combined with weight values, reflecting the importance of different detections in the statistical outliers; the outlier level of the target blockchain is determined by statistical outliers to achieve a comprehensive evaluation of the target blockchain, improving the accuracy of compliance detection in multi-entity networks in the blockchain; and by processing according to the outlier level, the legality and compliance of nodes, transactions, data, smart contracts, etc. in the blockchain are ensured.

[0010] The technical solutions of this disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0011] The accompanying drawings, which form part of this specification, illustrate embodiments of this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0012] This disclosure will become clearer with reference to the accompanying drawings and the following detailed description, wherein: Figure 1 This is a flowchart illustrating a Web3.0-based blockchain compliance detection method provided in an exemplary embodiment of this disclosure; Figure 2 This is a schematic flowchart illustrating the process of determining a detection feature vector in an exemplary embodiment of this disclosure; Figure 3 This is a flowchart illustrating the process of determining a detection feature vector in a method provided by another exemplary embodiment of this disclosure; Figure 4 This is a flowchart illustrating the process of determining a detection feature vector in a method provided in yet another exemplary embodiment of this disclosure; Figure 5 This is a flowchart illustrating the process of determining a detection feature vector in a method provided by another exemplary embodiment of this disclosure; Figure 6 This is a schematic diagram of the structure of a Web3.0-based blockchain compliance testing device provided in an exemplary embodiment of this disclosure; Figure 7 A block diagram of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0013] Hereinafter, exemplary embodiments according to the present disclosure will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present disclosure, and not all embodiments of the present disclosure, and it should be understood that the present disclosure is not limited to the exemplary embodiments described herein.

[0014] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of this disclosure.

[0015] Those skilled in the art will understand that the terms "first," "second," etc., in the embodiments of this disclosure are only used to distinguish different steps, devices, or modules, and do not represent any specific technical meaning, nor do they indicate a necessary logical order between them.

[0016] It should also be understood that in the embodiments disclosed herein, "a plurality of" may refer to two or more, and "at least one" may refer to one, two or more.

[0017] It should also be understood that any component, data or structure mentioned in the embodiments of this disclosure can generally be understood as one or more unless expressly defined or given to the contrary in the context.

[0018] Furthermore, the term "and / or" in this disclosure is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this disclosure generally indicates that the preceding and following related objects have an "or" relationship. The data referred to in this disclosure can include unstructured data such as text, images, and videos, as well as structured data.

[0019] It should also be understood that the description of the various embodiments in this disclosure emphasizes the differences between the various embodiments, and the similarities or similarities can be referred to each other. For the sake of brevity, they will not be described in detail.

[0020] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

[0021] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use.

[0022] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0023] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0024] The embodiments disclosed herein can be applied to electronic devices such as terminal devices, computer systems, and servers, and can operate together with a wide range of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known terminal devices, computing systems, environments, and / or configurations suitable for use with electronic devices such as terminal devices, computer systems, and servers include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems, etc.

[0025] Electronic devices such as terminal devices, computer systems, and servers can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., which perform specific tasks or implement specific abstract data types. Computer systems / servers can be implemented in distributed cloud computing environments, where tasks are executed by remote processing devices linked through communication networks. In distributed cloud computing environments, program modules can reside on local or remote computing system storage media, including storage devices.

[0026] Application Overview In developing this disclosure, the inventors discovered that existing blockchains often lack effective compliance and oversight mechanisms, leading to the inclusion of illegal business entities, non-compliant transactions, and the uploading of non-compliant data to the blockchain. Especially in complex network environments with multiple chains and nodes, achieving comprehensive compliance oversight and timely handling of abnormal behavior becomes a significant challenge.

[0027] Exemplary methods Figure 1 This is a flowchart illustrating a Web3.0-based blockchain compliance detection method provided in an exemplary embodiment of this disclosure. This embodiment can be applied to electronic devices, such as… Figure 1 As shown, it includes the following steps: Step 102: Obtain at least one type of on-chain data from the target blockchain.

[0028] Optionally, at least one type of on-chain data may include at least one of the following: node data (such as consensus participation records, block generation logs, etc.), transaction data (such as transaction hashes, transaction amounts, accounts of the transfering parties, timestamps, etc.), smart contract data (such as contract code, call records, state variables, etc.), account data (such as account balances, transaction history, associated addresses, etc.), and on-chain data (such as data format, data source, etc.).

[0029] Optionally, on-chain data can be obtained through the blockchain node's Remote Procedure Call (RPC) interface to acquire native on-chain data of the target blockchain network, or through the Application Programming Interface (API) interface for data extraction and event listening. The RPC interface is a programming interface based on the Remote Procedure Call protocol, allowing clients (such as applications and development tools) to call local functions / methods of blockchain nodes over the network, enabling direct control and data interaction with the blockchain nodes. Its core is "simulating local calls," allowing clients to send instructions (such as querying block data or submitting transactions) to blockchain nodes and receive responses without needing to understand the underlying network details. The API interface is a high-level interface encapsulated by third-party service providers or the official blockchain project team. Based on standard protocols, it encapsulates complex blockchain node interaction logic (such as RPC calls, data parsing, and cross-node synchronization) into simple API endpoints for developers to quickly call without directly deploying and maintaining blockchain nodes.

[0030] Step 104: Based on preset rules and on-chain data, perform at least one compliance check on the target blockchain to obtain at least one detection feature vector.

[0031] Among them, at least one compliance test includes, but is not limited to, at least one of the following: node compliance test, account transaction compliance check, smart contract test, on-chain data compliance test, etc.

[0032] In this embodiment, each compliance test includes the detection of at least one indicator. In order to ensure that each indicator is reflected in the test results, this embodiment uses the form of a detection feature vector to display the test results. Each element in the detection feature vector represents the result of an indicator test, thereby realizing the unified representation of the results of multiple indicator tests through a single detection feature vector; and achieving multi-faceted testing of the target blockchain through at least one compliance test.

[0033] Step 106: Determine at least one parameter value based on at least one detection feature vector.

[0034] Each detection feature vector corresponds to a parameter value.

[0035] Optionally, at least one parameter value can be determined based on at least one detection feature vector through an encoding mapping method or a deep neural network model, thereby quantifying the detection result. This allows for a comprehensive evaluation of the abnormal state of the target blockchain based on at least one parameter value, avoiding the problem of inaccurate evaluation caused by relying solely on individual detection feature vectors and achieving a more comprehensive evaluation of the target blockchain.

[0036] Step 108: Weight at least one parameter value by at least one weight value corresponding to at least one parameter value to determine statistical outliers.

[0037] Each parameter value corresponds to a weight value.

[0038] In this embodiment, the contribution of the parameter value to the statistical outliers is measured by the weight value. The larger the weight value, the greater the contribution. The weight value can be set according to the scenario, determined by big data statistics, or determined by deep learning methods, etc.

[0039] Step 110: Determine the anomaly level of the target blockchain based on statistical outliers and at least one anomaly threshold.

[0040] This embodiment compares statistical outliers with outlier thresholds to perform risk assessment and quantitative analysis on entities such as nodes, transactions, and contracts in the blockchain, classifying risks into different levels. Optionally, different processing methods can be adopted for different outlier levels to achieve automated outlier handling of the target blockchain.

[0041] Based on the Web3.0-based blockchain compliance detection method provided in the above embodiments of this disclosure, at least one type of on-chain data from the target blockchain is obtained; based on preset rules and the on-chain data, at least one compliance detection is performed on the target blockchain to obtain at least one detection feature vector; the at least one compliance detection includes at least one of the following: node compliance detection, account transaction compliance check, smart contract detection, and on-chain data compliance detection; at least one parameter value is determined based on the at least one detection feature vector; the at least one parameter value is weighted by at least one weight value corresponding to the at least one parameter value to determine statistical outliers; based on the statistical outliers and at least one outlier threshold, the outlier level of the target blockchain is determined. This embodiment performs at least one compliance detection on the target blockchain, supervising the blockchain from multiple aspects; the statistical outliers are determined based on parameter values ​​combined with weight values, reflecting the importance of different detections in the statistical outliers; the outlier level of the target blockchain is determined by statistical outliers to achieve a comprehensive evaluation of the target blockchain, improving the accuracy of compliance detection in multi-entity networks in the blockchain; and by processing according to the outlier level, the legality and compliance of nodes, transactions, data, smart contracts, etc. in the blockchain are ensured.

[0042] This embodiment enables real-time response and automatic handling of blockchain compliance detection, comprehensively improving the compliance of multi-entity networks in the blockchain platform and ensuring the legality and compliance of nodes, transactions, data, smart contracts, etc. in the blockchain.

[0043] Optionally, after obtaining on-chain data, the data can be preprocessed, such as data cleaning, deduplication, and standardization.

[0044] Preprocessing removes invalid or abnormal data, reducing noise interference, computational redundancy, and improving computational efficiency.

[0045] In some alternative embodiments, compliance testing includes node compliance testing; node compliance testing includes sequentially executed node qualification testing, entity identity testing, and node behavior testing; on-chain data includes node qualification certification information, node identity identifiers, and node behavior data. Figure 2 This is a schematic flowchart illustrating the process of determining a detection feature vector in an exemplary embodiment of this disclosure. Figure 2 As shown above, in the above Figure 1 Based on the illustrated embodiment, step 104 may include the following steps: Step 201: Review the qualification certificate information corresponding to the node applying to join the target blockchain, determine whether the qualification certificate information meets the preset qualifications in the preset rules, and obtain the first node result of the node qualification test.

[0046] The first node result includes whether the test passed or failed.

[0047] Optionally, when each node joins the blockchain network, it provides relevant qualification certification information according to the blockchain network's business rules. The legality and compliance of this qualification certification information are automatically verified through preset qualifications. After verification, the node's decentralized identifier (DID) and some registration information are uploaded to the blockchain network for verification. Optionally, the preset qualifications can be determined according to relevant regulations or by obtaining a large amount of verified qualification certification information through big data scraping. The corresponding preset qualifications are determined by processing the verified qualification certification information.

[0048] Step 202: Verify the identity identifier corresponding to the node using the public key in the on-chain data to obtain the second node result corresponding to the subject identity detection.

[0049] The second node result includes whether the test passed or failed.

[0050] In this embodiment, identity compliance authentication is performed on participating nodes in the blockchain network using decentralized identity authentication technology. Specifically, each node is uniquely identified by a decentralized identifier, and the identity of each blockchain node is verified through Public Key Infrastructure (PKI) to ensure that nodes accessing the network are legitimate and authorized, rather than maliciously forged nodes; simultaneously, the integrity and confidentiality of data communicated between nodes are guaranteed. The core of PKI's verification of blockchain node identity is to confirm the legitimacy of the node's identity through digital certificates and asymmetric encryption. This process may include: 1. Node PKI certificate application and deployment: Each legitimate blockchain node first submits an identity application (such as node hardware information, affiliated organization, network permissions, etc.) to a network-recognized Certification Authority (CA); after the CA approves the application, it issues a digital certificate to the node (including: the node's public key, the CA's digital signature, certificate validity period, node identity identifier (such as node ID), and permission scope); the node stores this digital certificate locally and synchronizes it to the trusted node list (or distributed ledger) of the blockchain network as identity credentials. 2. Identity verification upon node access. 3. Public Key Consistency and Identity Verification: After obtaining Node B's public key through the certificate, Node A generates a random challenge string (such as a random number + timestamp), encrypts it with Node B's public key, and sends it to Node B. Upon receiving the encrypted challenge string, Node B decrypts it using its own private key (held only by Node B and paired with the public key in the certificate) and returns the decrypted string to Node A. Node A compares the returned string with its original string: if they match, it proves that Node B indeed holds the private key corresponding to the public key in the certificate, and its identity is legitimate; if they do not match, it is determined to be a malicious node / forged identity, the connection is refused, and the node is marked.

[0051] PKI is a security infrastructure based on asymmetric encryption technology. It solves problems such as identity authentication, data encryption, and integrity verification in network communication through standardized key management, digital certificate issuance and verification processes.

[0052] Step 203: Monitor node behavior, obtain node behavior data, determine whether the node behavior data conforms to the preset regulations in the preset rules, and obtain the third node result corresponding to the node behavior detection.

[0053] The third node result includes whether the test passed or failed.

[0054] After successful authentication, nodes establish secure communication channels based on PKI asymmetric encryption (such as TLS / SSL). In subsequent interactions (such as block synchronization and transaction verification), nodes periodically sign transmitted data with their private keys, and the receiver verifies the signature with its public key to ensure that the data comes from a legitimate node and has not been tampered with. If a CA revokes a node's certificate (e.g., if the node is deemed malicious), the network will synchronize the revocation list. When other nodes verify the certificate and find it invalid, they will immediately reject the node's access request. In this embodiment, the revocation list can be stored in preset regulations for rapid detection. By monitoring node behavior in real time, it is possible to detect whether nodes violate platform policies or regulations (such as not participating in consensus, malicious forks, malicious attacks, data tampering, etc.).

[0055] Step 204: Based on the results of the first node, the second node, and the third node, determine the detection feature vector corresponding to the node compliance detection.

[0056] Optionally, the results of the first node, the second node, and the third node can be quantized and converted into values ​​in the range [0,1] according to a unified rule. Compliance: 1 (e.g., certificate valid = 1, signature verification passed = 1), non-compliance: 0 (e.g., certificate revocation = 0, hash inconsistency = 0). Multiple quantization results can be fused to obtain a detection feature vector. For example, if the first node result is detection passed (1), the second node result is detection passed (1), and the third node result is failure (0), the resulting detection feature vector can be represented as [1,1,0]. That is, different elements in the detection feature vector represent different detection results.

[0057] In some alternative embodiments, compliance detection includes account transaction compliance detection; account transaction compliance detection includes sequential anti-money laundering detection, cumulative amount detection, transaction path detection and cross-border transaction detection; on-chain data includes: transaction amount information, transaction frequency information and transaction address information. Figure 3 This is a schematic flowchart illustrating the process of determining a detection feature vector in a method provided by another exemplary embodiment of this disclosure. Figure 3 As shown above, in the above Figure 1 Based on the embodiment shown in Or 2, step 104 may also include the following steps: Step 301: Based on the anti-money laundering rules in the preset rules, determine whether the account transaction is a suspicious transaction and obtain the first transaction result corresponding to the anti-money laundering detection.

[0058] The first transaction result includes whether it is a suspicious transaction or not a suspicious transaction.

[0059] Anti-Money Laundering (AML) refers to the use of a series of legal, regulatory, and technological measures to prevent, identify, monitor, and combat the act of disguising illicit proceeds as legitimate funds, thus blocking the channel for "legalizing illicit funds." The system monitors transactions in real time, sets specific AML rules according to AML regulations, and detects suspicious transactions. Optionally, AML rules may include, but are not limited to, at least one of the following: setting transaction limits; when a single transaction exceeds the limit, the transaction is deemed suspicious; setting a limit on the number of transactions within a certain period; when the number of transactions within a certain period exceeds the limit, the transaction is deemed suspicious; setting a limit on transaction addresses (determined through big data, statistics, or regulations); when one party's address is a limited transaction address, the transaction is deemed suspicious, etc.

[0060] Step 302: Determine the cumulative transaction amount of the account based on the transaction amount information and transaction frequency information, and determine the second transaction result corresponding to the cumulative amount detection according to the relationship between the cumulative transaction amount and the amount threshold in the preset rules.

[0061] The second transaction result includes whether it is an abnormal transaction or not.

[0062] In transactions, besides cases where a single transaction amount is large, there may also be instances where the cumulative transaction amount over a certain period is large. These transactions may also be considered abnormal. In such cases, transaction frequency and transaction amount information can be set within a preset period (the period length can be set according to the specific application scenario or based on big data statistics). The transaction amount information corresponding to all transactions within the preset period is added together to obtain the cumulative transaction amount. The relationship between the cumulative transaction amount and the amount threshold (the amount threshold can be set according to the specific application scenario or based on big data statistics) is compared. If the cumulative transaction amount is greater than or equal to the amount threshold, the second transaction result is determined to be an abnormal transaction; otherwise, the second transaction result is not an abnormal transaction.

[0063] Step 303: Based on the list of high-risk addresses in the preset rules and the transaction address information corresponding to the account transaction, determine whether the account transaction is a high-risk transaction and obtain the third transaction result corresponding to the transaction path detection.

[0064] The third transaction outcome includes whether it is a high-risk transaction or not.

[0065] Optionally, the transaction address information corresponding to each transaction is obtained, and the transaction address information is matched with a high-risk address list. When a match is found, the third transaction result corresponding to that transaction is determined to be a high-risk transaction; when no match is found, the third transaction result corresponding to that transaction is determined to be a non-high-risk transaction. The high-risk addresses included in the high-risk address list (blacklisted addresses, illegal financial networks, etc.) can be obtained offline (e.g., addresses corresponding to historical high-risk transactions). In this embodiment, the high-risk address list can be updated during the monitoring process to improve the accuracy of subsequent transaction risk detection.

[0066] Step 304: Based on the cross-border legality rules in the preset rules, determine whether the account transaction is a legal cross-border transaction and obtain the fourth transaction result corresponding to the cross-border transaction detection.

[0067] The fourth transaction outcome includes whether it is a legitimate cross-border transaction or not.

[0068] In this embodiment, the on-chain data may further include transaction process data. This data is matched against cross-border legal rules to determine whether the cross-border transaction complies with international laws and regulations. When the transaction process data matches the cross-border legal rules, the fourth transaction result is determined to be a legal cross-border transaction; otherwise, it is determined to be an illegal cross-border transaction. Optionally, cross-border legal rules can be obtained through offline data scraping.

[0069] Step 305: Based on the first transaction result, the second transaction result, the third transaction result, and the fourth transaction result, determine the detection feature vector corresponding to the account transaction compliance detection.

[0070] and Figure 2 The provided embodiments are similar. Optionally, the first, second, third, and fourth transaction results can be converted into values ​​in the range [0,1] according to a unified rule. Compliant: 1 (e.g., not an abnormal transaction = 1, not a high-risk transaction = 1, a legal cross-border transaction = 1), non-compliant: 0 (e.g., abnormal transaction = 0, a high-risk transaction = 0, a legal cross-border transaction = 0). Multiple quantitative results can be fused to obtain a detection feature vector. For example, if the first transaction result is a suspicious transaction (0), the second transaction result is an abnormal transaction (0), the third transaction result is a high-risk transaction (0), and the fourth transaction result is a legal cross-border transaction (1), the resulting detection feature vector can be represented as [0,0,0,1]. That is, different elements in the vector represent different detection results.

[0071] In some alternative embodiments, compliance testing includes smart contract testing; smart contract testing includes sequentially executed contract code testing and contract execution testing; on-chain data includes: smart contract code and contract execution results. Figure 4 This is a schematic flowchart illustrating the process of determining a detection feature vector in a method provided in yet another exemplary embodiment of this disclosure. For example... Figure 4 As shown above, in the above Figure 1 Based on the illustrated embodiment, step 104 may include the following steps: Step 401: Determine the first contract result of the contract code detection based on whether the smart contract code conforms to the contract rules in the preset rules.

[0072] The first contract result includes whether it complies with the contract rules or does not comply with the contract rules.

[0073] Optionally, before the smart contract is uploaded to the blockchain, automated tools are used to inspect the corresponding smart contract code. For example, through syntax parsing, pattern matching, and bytecode decompilation, obvious vulnerabilities / illegal logic can be quickly located to determine the smart contract code. Syntax errors: Check for unclosed parentheses, type mismatches, unhandled function return values, etc. (e.g., `uint256 a = "string"` is an incorrect type, which may cause contract execution errors); Deprecated / dangerous syntax: Check for the use of deprecated Solidity syntax (e.g., `suicide()` instead of `selfdestruct()`), or unverified low-version compilers (e.g., <0.8.0 does not have overflow checks enabled by default, easily triggering integer overflow vulnerabilities); Bytecode anomalies: Decompile the deployed bytecode and compare it with the source code for consistency (if the bytecode contains logic not disclosed in the source code, it may hide a backdoor). This embodiment detects whether the smart contract has vulnerabilities, backdoors, illegal operations, and whether it complies with business logic and legal regulations, ensuring that the contract code meets security and compliance requirements.

[0074] Step 402: Determine the second contract result corresponding to the contract execution detection based on whether the contract execution result conforms to the execution logic rules in the preset rules.

[0075] The second contract result includes those that conform to the execution logic rules and those that do not.

[0076] The execution logic of a smart contract is a deterministic, automated, and immutable sequence of instructions based on the underlying blockchain protocol, programming language specifications, and business rules. It follows a closed loop of "trigger-verification-execution-on-chain," and its rules can be broken down into three dimensions: underlying execution rules, core logic rules, and scenario-based execution rules. This embodiment examines the execution logic of a smart contract through the contract execution results, ensuring that the execution logic complies with industry regulations, platform rules, and legal requirements, thus avoiding non-compliant contract behaviors (such as privacy leaks and fraud). Optionally, if the actual contract execution result matches the expected execution result, and there are no abnormal rollbacks or consistent results across nodes, the execution logic is deemed to comply with the execution logic rules. If there are result mismatches (such as the balance not updating after a transfer), unexpected rollbacks, or inconsistent node results, logical vulnerabilities are identified (such as code logic errors or missing permission checks), and the execution logic is deemed to violate the execution logic rules.

[0077] Optionally, smart contract detection may further include: performing user deployment detection, deploying the smart contract using an unauthorized user; if the smart contract is successfully deployed, a warning is output; deploying the smart contract using an authorized user; if the smart contract deployment fails, a warning is output. Performing smart contract tampering detection, tampering with the smart contract during deployment; if the blockchain system does not detect it, a warning is output; tampering with the smart contract during update; if the blockchain system does not detect it, a warning is output; detecting whether the tampered smart contract can be successfully deployed; if the smart contract is successfully deployed, a warning is output; detecting whether the smart contract code uses cryptographic protection technology; if not, a warning is output; if any of the user deployment detection and contract tampering detection in the smart contract detection outputs a warning, the smart contract fails the detection. If each detection in the smart contract detection passes, the privacy protection detection proceeds. Smart contract detection ensures that the smart contract is not tampered with during deployment, ensures that the sensitive code of the smart contract is not accessed by malicious visitors, and ensures that the user deploying the smart contract has the correct permissions and that malicious smart contracts are not deployed.

[0078] Step 403: Based on the results of the first contract and the second contract, determine the detection feature vector corresponding to the smart contract detection.

[0079] Similar to the above embodiments, optionally, the first contract result and the second contract result can be converted into values ​​in the range [0,1] according to a unified rule, where compliance is 1 (e.g., compliance with contract rules = 1, compliance with execution logic rules = 1) and non-compliance is 0 (e.g., non-compliance with contract rules = 0, non-compliance with execution logic rules = 0). Multiple quantification results can be fused to obtain a detection feature vector. For example, if the first contract result is in compliance with contract rule (1) and the second contract result is in compliance with contract rule (0), the resulting detection feature vector can be represented as [1,0]. That is, different elements in the detection feature vector represent different detection results.

[0080] Smart contract detection may also include: determining whether the execution logic of the smart contract is compliant based on the execution result; tampering with the smart contract during deployment; issuing a warning if the blockchain system fails to detect it; tampering with the smart contract during update; issuing a warning if the blockchain system fails to detect it; detecting whether the tampered smart contract code can be successfully deployed; issuing a warning if the smart contract is successfully deployed; detecting whether the smart contract code uses cryptographic protection technology; issuing a warning if not; if any of the user deployment detection and contract tampering detection in the smart contract detection process issues a warning, the smart contract fails the detection.

[0081] In some alternative embodiments, compliance testing includes on-chain data compliance testing; on-chain data compliance testing includes sequentially executed data content testing, data format testing, privacy protection testing, and data source testing; on-chain data includes: on-chain data content information, on-chain data format information, sensitive content information, and data source information. Figure 5 This is a schematic flowchart illustrating the process of determining a detection feature vector in a method provided by another exemplary embodiment of this disclosure. For example... Figure 5 As shown above, in the above Figure 1 Based on the illustrated embodiment, step 104 may include the following steps: Step 501: Determine the first data result corresponding to the data content detection based on whether the on-chain data content information conforms to the compliance rules in the preset rules.

[0082] The first data result includes whether it complies with or does not comply with the rules.

[0083] Optionally, the compliance of the on-chain data content can be determined through keyword detection and / or image recognition and / or audio / video recognition. In this embodiment, the compliance rules can be set according to specific application scenarios or determined based on big data statistics. Optionally, the processing of the on-chain data content in this embodiment can be implemented based on a neural network model. The neural network model can directly detect or identify whether the on-chain data content includes the content determined by the compliance rules (e.g., verifying whether the transaction amount is reasonable), thereby realizing the compliance detection of the on-chain data content and ensuring that it complies with business rules and relevant laws and regulations.

[0084] Step 502: Determine the second data result corresponding to the data format detection based on whether the on-chain data format information conforms to the preset data format in the preset rules.

[0085] The second data result includes whether it conforms to the preset data format or not.

[0086] In this embodiment, a preset data format for the data to be uploaded to the target blockchain can be pre-set. This preset data format can be any data format, such as Xtensible Markup Language (XML), JavaScript Object Notation (JSON), etc. When data needs to be uploaded to the blockchain, the format information of the data to be uploaded is obtained, and this data format information is matched with the preset data format. If a match is found, the second data result is determined to conform to the preset data format; otherwise, the second data result is determined to not conform to the preset data format. Optionally, when the second data result does not conform to the preset data format, the data to be uploaded to the blockchain can also be converted to the preset data format to improve the efficiency of data uploading to the blockchain.

[0087] Step 503: Determine the third data result corresponding to the privacy protection detection based on whether the sensitive content information conforms to the encryption rules in the preset rules.

[0088] The third data result includes whether it conforms to the encryption rules or not.

[0089] In this embodiment, the encryption rules may include, but are not limited to: sensitive information (such as medical patient privacy data, identity information data, etc.) must be encrypted (the encryption method can be any encryption method in the prior art); the on-chain data is encrypted and tested, the consensus mechanism execution process is simulated, and the sensitive information transmitted during the execution process is tested to see if it is encrypted and protected; if it is not encrypted and protected, the third data result is not in compliance with the encryption rules, and if it is encrypted, the third data result is in compliance with the encryption rules.

[0090] Step 504: Determine the fourth data result corresponding to the data source detection based on whether the data source information conforms to the source credibility rule in the preset rules.

[0091] The fourth data result includes those that comply with the source trust rule (source trustworthy) or those that do not comply with the source trust rule (source untrustworthy).

[0092] Optionally, data source information may include, but is not limited to, data provider identification, data source address, etc.; source trust rules can be determined based on preset blacklist addresses and / or preset blacklist identifiers (the blacklist can be determined based on the crawled big data), for example, a source trust rule is that the data source address does not belong to a preset blacklist address, etc. The data source information is matched against the source trust rules. When the data provider identification matches a preset blacklist identifier, and / or the data source address matches a preset blacklist address, it indicates that the data source is untrustworthy; otherwise, it indicates that the data source is trustworthy.

[0093] Step 505: Based on the first data result, the second data result, the third data result, and the fourth data result, determine the detection feature vector corresponding to the compliance detection of the on-chain data.

[0094] Similar to the above embodiments, optionally, the first data result, the second data result, the third data result, and the fourth data result can be converted into values ​​in the range [0,1] according to a unified rule. Compliant: 1 (e.g., compliant with compliance rule = 1, compliant with compliance rule = 1, compliant with encryption rule = 1, compliant with source trust rule = 1), non-compliant: 0 (e.g., non-compliant with compliance rule = 0, non-compliant with compliance rule = 0, non-compliant with encryption rule = 0, non-compliant with source trust rule = 0). Multiple quantification results can be fused to obtain a detection feature vector. For example, if the first data result is compliant with compliance rule (1), the second data result is compliant with compliance rule (1), the third data result is non-compliant with encryption rule (0), and the fourth data result is compliant with source trust rule (1), the resulting detection feature vector can be represented as [1,1,0,1]. That is, different elements in the vector represent different detection results.

[0095] Optionally, when multiple detection feature vectors are included, they can be processed into vectors of the same dimension. For example, detection feature vectors with smaller dimensions can be padded with 0s. For instance, if one detection feature vector is [1,0,1] and another is [1,1,1,0], to achieve unified processing of the detection feature vectors, the detection feature vector [1,0,1] can be padded to [0,1,0,1], and then processed with multiple detection feature vectors of the same dimension to determine the anomaly level of the target blockchain.

[0096] In some alternative embodiments, based on the above embodiments, the following may be included before performing step 104: Acquire at least one type of off-chain data, and determine preset rules based on the off-chain data.

[0097] Off-chain data may include, but is not limited to, known risk address tag libraries, regulatory blacklists, source code, and other related data. Paths for obtaining off-chain data may include, but are not limited to, obtaining it through API interfaces or web crawlers from online forums, social media, etc. Optionally, this may involve accessing / crawling websites to obtain risk address tag libraries or regulatory blacklists; crawling social media to obtain data; or obtaining source code from code repositories.

[0098] Optionally, similar to on-chain data, after obtaining off-chain data, the obtained off-chain data can also be preprocessed, such as data cleaning, deduplication, and standardization.

[0099] Preprocessing removes invalid or abnormal data, reducing noise interference, computational redundancy, and improving computational efficiency.

[0100] In some alternative embodiments, step 106 may include: At least one detection feature vector is processed based on a preset network model to obtain at least one parameter value.

[0101] Each parameter value corresponds to a detection feature vector.

[0102] Optionally, the preset network model can be a deep neural network of any structure, such as a fully connected neural network (outputting parameter values ​​in the range of 0-1), a convolutional neural network (outputting parameter values ​​expressed as probabilities), a recurrent neural network, an attention mechanism network, etc. This embodiment processes the detection feature vector into parameter values ​​through the preset network model, enabling the representation of the detection results in numerical form, thus providing technical support for subsequent target blockchain level evaluation.

[0103] In some alternative embodiments, step 108 may include: For each parameter value among at least one parameter value, a corresponding weight value is determined to obtain at least one weight value; Statistical outliers are obtained by performing a weighted summation on at least one parameter value based on at least one weight value.

[0104] Optionally, the weight values ​​can be determined based on at least one of the following methods: pre-setting based on business rules; automatically calculating weights by learning the correlation between parameter values ​​and statistical outliers through historical data; or adaptive weight allocation through the model: adding an attention module (such as self-attention or multi-head attention) to the encoding layer of the detection results, and the model automatically learning the importance of different parameter values, etc. This embodiment accumulates parameter values ​​with different weight values ​​to reflect different importance in statistical outliers, overcoming the problem that simply summing all parameter values ​​to obtain statistical outliers ignores the impact of different detection results on the anomalies of the target blockchain.

[0105] In some optional embodiments, at least one anomaly threshold includes a first anomaly threshold, a second anomaly threshold, and a third anomaly threshold; the first anomaly threshold is greater than the second anomaly threshold, and the second anomaly threshold is greater than the third anomaly threshold. Step 110 may include: Statistical outliers are compared with the first outlier threshold, the second outlier threshold, and the third outlier threshold.

[0106] In response to statistical outliers being greater than or equal to the first outlier threshold, the target blockchain is determined to be of high risk. In response to a statistical outlier being less than the first outlier threshold and greater than or equal to the second outlier threshold, the outlier level of the target blockchain is determined to be medium risk. In response to a statistical outlier being less than the second outlier threshold and greater than or equal to the third outlier threshold, the outlier level of the target blockchain is determined to be low risk. If the statistical outlier is less than the third outlier threshold, the target blockchain is determined to be at a suspected risk level.

[0107] This embodiment achieves different levels of risk assessment for blockchain by setting multiple anomaly thresholds, realizing quantitative analysis of blockchain risk and classifying risks into four levels: suspected, low, medium, and high. When the risk value reaches the preset threshold for each level, the corresponding response mechanism is adopted to deal with the regulated entity.

[0108] In some alternative embodiments, after determining the anomaly level of the target blockchain, the following may also be included: Based on the anomaly level of the target blockchain, control the target blockchain to perform corresponding abnormal operations and issue corresponding alarm messages; different anomaly levels correspond to different abnormal operations and different alarm messages. In response to reaching the preset reporting period, alarm report data is generated by statistically analyzing the alarm information of the target blockchain within the preset reporting period.

[0109] Optionally, anomaly handling: An automated handling model is constructed. Based on the risk assessment results (anomaly level), the system will invoke smart contracts according to the handling model to automatically trigger the corresponding response mechanism, including: Suspected Risk – Level 1 Response Mechanism – Risk Warning: When the risk is determined to be suspected, the Level 1 response mechanism is adopted, and the system automatically sends notifications to relevant regulatory personnel, platform administrators, and relevant business parties. Low Risk – Level 2 Response Mechanism – Transaction Suspension: When the risk is determined to be low, the Level 2 response mechanism is adopted, and the system automatically suspends abnormal transactions to prevent erroneous or illegal transactions from affecting the network. Medium Risk – Level 3 Response Mechanism – Account Freezing: When the risk is determined to be medium, the Level 3 response mechanism is adopted, and the system automatically freezes suspicious accounts (accounts performing transaction transfer operations or accounts executing business logic in the smart contract blockchain) to prevent illegal transactions or serious contract risk issues. High Risk – Level 4 Response Mechanism – Node Isolation: When the risk is determined to be high, the Level 4 response mechanism is adopted, and the system automatically isolates malicious nodes from the blockchain network to prevent them from continuing to spread the risk; all on-chain operations cannot be executed.

[0110] Regular Compliance Reports: The system can regularly generate compliance reports to help regulatory agencies, platform administrators, and third-party auditing firms review and assess the platform's compliance status. Customizable Notifications: When potential compliance issues are detected, the platform can automatically send notifications to relevant personnel, including system administrators, compliance teams, and regulatory agencies, according to pre-defined rules. The report generation and notification module summarizes and processes regulatory results.

[0111] This embodiment achieves comprehensive and effective compliance supervision of the blockchain through rule definition and execution. Optionally, a rule engine defines platform compliance requirements and industry regulatory requirements, such as rules on anti-money laundering, tax compliance, privacy protection, and sensitive words. Furthermore, preset rules can be updated according to business needs, and the system will automatically synchronize and execute the new rules to ensure the platform continuously meets the latest compliance requirements, thus achieving rule updating and management.

[0112] Any of the Web3.0-based blockchain compliance detection methods provided in this disclosure can be executed by any suitable device with data processing capabilities, including but not limited to terminal devices and servers. Alternatively, any of the Web3.0-based blockchain compliance detection methods provided in this disclosure can be executed by a processor, such as by a processor executing any of the Web3.0-based blockchain compliance detection methods mentioned in this disclosure by calling corresponding instructions stored in memory. Further details will not be elaborated upon below.

[0113] Exemplary device Figure 6 This is a schematic diagram of the structure of a Web3.0-based blockchain compliance testing device provided in an exemplary embodiment of this disclosure. Figure 6 As shown, the apparatus provided in this embodiment includes: The data acquisition module 61 is used to acquire at least one type of on-chain data from the target blockchain.

[0114] The compliance detection module 62 is used to perform at least one compliance detection on the target blockchain based on preset rules and on-chain data, and obtain at least one detection feature vector.

[0115] Among them, at least one of the following compliance tests is required: node compliance test, account transaction compliance check, smart contract test, and on-chain data compliance test.

[0116] The parameter determination module 63 is used to determine at least one parameter value based on at least one detection feature vector.

[0117] The outlier statistics module 64 is used to weight at least one parameter value by at least one weight value corresponding to at least one parameter value to determine statistical outliers.

[0118] The level determination module 65 is used to determine the anomaly level of the target blockchain based on statistical outliers and at least one anomaly threshold.

[0119] The apparatus provided in the above embodiments of this disclosure acquires at least one type of on-chain data from a target blockchain; performs at least one compliance check on the target blockchain based on preset rules and the on-chain data, obtaining at least one detection feature vector; the at least one compliance check includes at least one of the following: node compliance check, account transaction compliance check, smart contract check, and on-chain data compliance check; determines at least one parameter value based on the at least one detection feature vector; performs weighted processing on the at least one parameter value using at least one weight value corresponding to the at least one parameter value to determine statistical outliers; and determines the anomaly level of the target blockchain based on the statistical outliers and at least one anomaly threshold. This embodiment performs at least one compliance check on the target blockchain, supervising the blockchain from multiple aspects; determines statistical outliers based on parameter values ​​combined with weight values, reflecting the importance of different checks within statistical outliers; determines the anomaly level of the target blockchain through statistical outliers, achieving a comprehensive evaluation of the target blockchain, improving the accuracy of compliance checks on multi-entity networks in the blockchain, and ensuring the legality and compliance of nodes, transactions, data, and smart contracts in the blockchain by processing according to the anomaly level.

[0120] In some optional embodiments, compliance testing includes node compliance testing; node compliance testing includes sequentially executed node qualification testing, entity identity testing, and node behavior testing; on-chain data includes node qualification certification information, node identity identifiers, and node behavior data.

[0121] The compliance detection module 62 is specifically used to review the qualification certificate information corresponding to the node applying to join the target blockchain, determine whether the qualification certificate information meets the preset qualifications in the preset rules, and obtain the first node result of the node qualification detection; verify the identity identifier corresponding to the node through the public key in the on-chain data, and obtain the second node result corresponding to the subject identity detection; monitor the node behavior, obtain node behavior data, determine whether the node behavior data meets the preset regulations in the preset rules, and obtain the third node result corresponding to the node behavior detection; and determine the detection feature vector corresponding to the node compliance detection based on the first node result, the second node result, and the third node result.

[0122] In some alternative embodiments, compliance detection includes account transaction compliance detection; account transaction compliance detection includes sequential anti-money laundering detection, cumulative amount detection, transaction path detection, and cross-border transaction detection; on-chain data includes: transaction amount information, transaction frequency information, and transaction address information.

[0123] The compliance detection module 62 is specifically used to determine whether an account transaction is suspicious based on the anti-money laundering rules in the preset rules, and obtain the first transaction result corresponding to the anti-money laundering detection; determine the cumulative transaction amount of the account transaction based on the transaction amount information and transaction frequency information, and determine the second transaction result corresponding to the cumulative amount detection based on the relationship between the cumulative transaction amount and the amount threshold in the preset rules; determine whether the account transaction is high-risk based on the high-risk address list in the preset rules and the transaction address information corresponding to the account transaction, and obtain the third transaction result corresponding to the transaction path detection; determine whether the account transaction is a legal cross-border transaction based on the cross-border legality rules in the preset rules, and obtain the fourth transaction result corresponding to the cross-border transaction detection; and determine the detection feature vector corresponding to the account transaction compliance detection based on the first, second, third, and fourth transaction results.

[0124] In some alternative embodiments, compliance testing includes smart contract testing; smart contract testing includes sequential execution of contract code testing and contract execution testing; on-chain data includes smart contract code and contract execution results.

[0125] The compliance detection module 62 is specifically used to determine the first contract result of the contract code detection based on whether the smart contract code conforms to the contract rules in the preset rules; to determine the second contract result of the contract execution detection based on whether the contract execution result conforms to the execution logic rules in the preset rules; and to determine the detection feature vector corresponding to the smart contract detection based on the first contract result and the second contract result.

[0126] In some alternative embodiments, compliance testing includes on-chain data compliance testing; on-chain data compliance testing includes sequentially executed data content testing, data format testing, privacy protection testing, and data source testing; on-chain data includes: on-chain data content information, on-chain data format information, sensitive content information, and data source information.

[0127] The compliance detection module 62 is specifically used to determine the first data result corresponding to data content detection based on whether the on-chain data content information conforms to the compliance rules in the preset rules; to determine the second data result corresponding to data format detection based on whether the on-chain data format information conforms to the preset data format in the preset rules; to determine the third data result corresponding to privacy protection detection based on whether the sensitive content information conforms to the encryption rules in the preset rules; to determine the fourth data result corresponding to data source detection based on whether the data source information conforms to the source trust rule in the preset rules; and to determine the detection feature vector corresponding to the on-chain data compliance detection based on the first data result, second data result, third data result, and fourth data result.

[0128] In some optional embodiments, the apparatus provided in this embodiment may further include: The off-chain data acquisition module is used to acquire at least one type of off-chain data and determine preset rules based on the off-chain data.

[0129] In some optional embodiments, the parameter determination module 63 is specifically used to process at least one detection feature vector based on a preset network model to obtain at least one parameter value.

[0130] Each parameter value corresponds to a detection feature vector.

[0131] In some optional embodiments, the outlier statistics module 64 is specifically used to determine a corresponding weight value for each of the at least one parameter value to obtain at least one weight value; and to perform a weighted summation on the at least one parameter value based on the at least one weight value to obtain statistical outliers.

[0132] In some optional embodiments, at least one abnormal threshold includes a first abnormal threshold, a second abnormal threshold, and a third abnormal threshold; the first abnormal threshold is greater than the second abnormal threshold, and the second abnormal threshold is greater than the third abnormal threshold.

[0133] The level determination module 65 is specifically used to compare statistical outliers with a first outlier threshold, a second outlier threshold, and a third outlier threshold; in response to a statistical outlier being greater than or equal to the first outlier threshold, the outlier level of the target blockchain is determined to be high risk; in response to a statistical outlier being less than the first outlier threshold but greater than or equal to the second outlier threshold, the outlier level of the target blockchain is determined to be medium risk; in response to a statistical outlier being less than the second outlier threshold but greater than or equal to the third outlier threshold, the outlier level of the target blockchain is determined to be low risk; and in response to a statistical outlier being less than the third outlier threshold, the outlier level of the target blockchain is determined to be suspected risk.

[0134] In some optional embodiments, the apparatus provided in this embodiment may further include: The detection and processing module is used to control the target blockchain to perform corresponding abnormal operations and issue corresponding alarm information based on the anomaly level of the target blockchain; different anomaly levels correspond to different abnormal operations and different alarm information.

[0135] The report generation module is used to generate alarm report data by statistically analyzing the alarm information of the target blockchain within the preset reporting period in response to the achievement of the preset reporting period.

[0136] The exemplary embodiment of the Web3.0-based blockchain compliance testing device provided in this disclosure corresponds to the aforementioned exemplary Web3.0-based blockchain compliance testing method in terms of implementation. The corresponding content between the two can be referenced, combined, and cited interchangeably, and will not be repeated here. The beneficial technical effects corresponding to the exemplary embodiment of the Web3.0-based blockchain compliance testing device provided in this disclosure can be found in the corresponding beneficial technical effects of the aforementioned exemplary Web3.0-based blockchain compliance testing method, and will not be repeated here.

[0137] Exemplary electronic devices Below, for reference Figure 7 This describes an electronic device according to embodiments of the present disclosure. The electronic device may be either or both of a first device and a second device, or a standalone device independent of them, which may communicate with the first device and the second device to receive acquired input signals from them.

[0138] Figure 7 A block diagram of an electronic device according to an embodiment of the present disclosure is shown.

[0139] like Figure 7 As shown, the electronic device includes one or more processors and memory.

[0140] A processor can be a central processing unit (CPU) or other form of processing unit with data processing and / or instruction execution capabilities, and can control other components in an electronic device to perform desired functions.

[0141] The memory can store one or more computer program products, and the memory can include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program products can be stored on the computer-readable storage medium, and the processor can run the computer program products to implement the Web3.0-based blockchain compliance detection methods and / or other desired functions described in the various embodiments of this disclosure above.

[0142] In one example, the electronic device may also include input devices and output devices, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0143] In addition, the input device may also include, for example, a keyboard, a mouse, etc.

[0144] This output device can output various information to the outside, including determined distance information, direction information, etc. The output device may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0145] Of course, for the sake of simplicity, Figure 7 Only some of the components of the electronic device relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device may include any other suitable components depending on the specific application.

[0146] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps in the Web3.0-based blockchain compliance detection method according to various embodiments of this disclosure as described in the foregoing portion of this specification.

[0147] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0148] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform the steps in the Web3.0-based blockchain compliance detection method according to various embodiments of this disclosure as described in the foregoing portion of this specification.

[0149] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0150] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0151] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0152] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0153] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the order specifically described above unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.

[0154] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions to this disclosure.

[0155] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0156] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A blockchain compliance detection method based on Web3.0, characterized in that, include: Acquire at least one type of on-chain data from the target blockchain; Based on preset rules and the on-chain data, at least one compliance check is performed on the target blockchain to obtain at least one detection feature vector; the at least one compliance check includes at least one of the following: node compliance check, account transaction compliance check, smart contract check, and on-chain data compliance check; Determine at least one parameter value based on the at least one detection feature vector; By weighting the at least one parameter value with at least one weight value corresponding to the at least one parameter value, statistical outliers are determined. The anomaly level of the target blockchain is determined based on the statistical outliers and at least one anomaly threshold.

2. The method according to claim 1, characterized in that, The compliance testing includes node compliance testing; the node compliance testing includes sequentially executed node qualification testing, entity identity testing, and node behavior testing; the on-chain data includes node qualification certification information, node identity identifier, and node behavior data; Based on preset rules and on-chain data, at least one compliance check is performed on the target blockchain to obtain at least one detection feature vector, including: The qualification certificate information corresponding to the node that applied to join the target blockchain is reviewed to determine whether the qualification certificate information meets the preset qualifications in the preset rules, and the first node result of the node qualification detection is obtained. The identity identifier corresponding to the node is verified using the public key in the on-chain data to obtain the second node result corresponding to the subject identity detection; Monitor the node behavior to obtain node behavior data, determine whether the node behavior data conforms to the preset regulations in the preset rules, and obtain the third node result corresponding to the node behavior detection. Based on the results of the first node, the second node, and the third node, the detection feature vector corresponding to the compliance detection of the node is determined.

3. The method according to claim 1, characterized in that, The compliance testing includes account transaction compliance testing; the account transaction compliance testing includes sequentially executed anti-money laundering testing, cumulative limit testing, transaction path testing, and cross-border transaction testing; The on-chain data includes: transaction amount information, transaction frequency information, and transaction address information; Based on preset rules and on-chain data, at least one compliance check is performed on the target blockchain to obtain at least one detection feature vector, including: Based on the anti-money laundering rules in the preset rules, determine whether the account transaction is a suspicious transaction, and obtain the first transaction result corresponding to the anti-money laundering detection; Based on the transaction amount information and the transaction frequency information, the cumulative transaction amount of the account is determined, and based on the relationship between the cumulative transaction amount and the amount threshold in the preset rules, the second transaction result corresponding to the cumulative amount detection is determined; Based on the high-risk address list in the preset rules and the transaction address information corresponding to the account transaction, determine whether the account transaction is a high-risk transaction and obtain the third transaction result corresponding to the transaction path detection; Based on the cross-border legality rules in the preset rules, determine whether the account transaction is a legal cross-border transaction, and obtain the fourth transaction result corresponding to the cross-border transaction detection; Based on the first transaction result, the second transaction result, the third transaction result, and the fourth transaction result, the detection feature vector corresponding to the account transaction compliance detection is determined.

4. The method according to any one of claims 1-3, characterized in that, The compliance testing includes smart contract testing; the smart contract testing includes sequentially executed contract code testing and contract execution testing; the on-chain data includes: smart contract code and contract execution results; Based on preset rules and on-chain data, at least one compliance check is performed on the target blockchain to obtain at least one detection feature vector, including: The first contract result of the contract code detection is determined based on whether the smart contract code conforms to the contract rules in the preset rules; Based on whether the contract execution result conforms to the execution logic rules in the preset rules, the second contract result corresponding to the contract execution detection is determined; Based on the first contract result and the second contract result, the detection feature vector corresponding to the smart contract detection is determined.

5. The method according to any one of claims 1-3, characterized in that, The compliance testing includes compliance testing of the on-chain data; the on-chain data compliance testing includes sequentially executed data content testing, data format testing, privacy protection testing, and data source testing; The on-chain data includes: on-chain data content information, on-chain data format information, sensitive content information, and data source information; Based on preset rules and on-chain data, at least one compliance check is performed on the target blockchain to obtain at least one detection feature vector, including: Based on whether the on-chain data content information conforms to the compliance rules in the preset rules, the first data result corresponding to the data content detection is determined; Based on whether the on-chain data format information conforms to the preset data format in the preset rules, the second data result corresponding to the data format detection is determined; The third data result corresponding to the privacy protection detection is determined based on whether the sensitive content information conforms to the encryption rules in the preset rules; Based on whether the data source information conforms to the source credibility rule in the preset rules, the fourth data result corresponding to the data source detection is determined; Based on the first data result, the second data result, the third data result, and the fourth data result, the detection feature vector corresponding to the on-chain data compliance detection is determined.

6. The method according to any one of claims 1-3, characterized in that, Before performing at least one compliance check on the target blockchain based on preset rules and the on-chain data to obtain at least one detection feature vector, the process further includes: Acquire at least one type of off-chain data, and determine the preset rule based on the off-chain data.

7. The method according to any one of claims 1-3, characterized in that, Determining at least one parameter value based on the at least one detection feature vector includes: The at least one detection feature vector is processed based on a preset network model to obtain the at least one parameter value; wherein each parameter value corresponds to one detection feature vector.

8. The method according to any one of claims 1-3, characterized in that, The step of weighting the at least one parameter value using at least one weight value corresponding to the at least one parameter value to determine statistical outliers includes: For each of the at least one parameter values, a corresponding weight value is determined to obtain the at least one weight value; The statistical outlier is obtained by performing a weighted summation on the at least one parameter value based on the at least one weight value.

9. The method according to any one of claims 1-3, characterized in that, The at least one abnormal threshold includes a first abnormal threshold, a second abnormal threshold, and a third abnormal threshold; the first abnormal threshold is greater than the second abnormal threshold, and the second abnormal threshold is greater than the third abnormal threshold. Determining the anomaly level of the target blockchain based on the statistical outliers and at least one anomaly threshold includes: The statistical outliers are compared with the first outlier threshold, the second outlier threshold, and the third outlier threshold. In response to the statistical outlier being greater than or equal to the first outlier threshold, the outlier level of the target blockchain is determined to be high risk; In response to the statistical outlier being less than the first outlier threshold and greater than or equal to the second outlier threshold, the outlier level of the target blockchain is determined to be medium risk. In response to the statistical outlier being less than the second outlier threshold and greater than or equal to the third outlier threshold, the outlier level of the target blockchain is determined to be low risk. In response to the statistical outlier being less than the third outlier threshold, the outlier level of the target blockchain is determined to be a suspected risk.

10. The method according to any one of claims 1-3, characterized in that, Also includes: Based on the anomaly level of the target blockchain, the system controls the target blockchain to perform corresponding abnormal operations and issue corresponding alarm messages; wherein, different anomaly levels correspond to different abnormal operations and different alarm messages. In response to reaching a preset reporting period, alarm report data is generated by statistically analyzing the alarm information of the target blockchain within the preset reporting period.

11. A blockchain compliance testing device based on Web3.0, characterized in that, include: The data acquisition module is used to acquire at least one type of on-chain data from the target blockchain. The compliance detection module is used to perform at least one compliance detection on the target blockchain based on preset rules and the on-chain data, and obtain at least one detection feature vector; the at least one compliance detection includes at least one of the following: node compliance detection, account transaction compliance check, smart contract detection, and on-chain data compliance detection; A parameter determination module is used to determine at least one parameter value based on the at least one detection feature vector; An outlier statistics module is used to weight the at least one parameter value using at least one weight value corresponding to the at least one parameter value to determine statistical outliers; The level determination module is used to determine the anomaly level of the target blockchain based on the statistical outliers and at least one anomaly threshold.

12. An electronic device, characterized in that, include: Memory, used to store computer program products; A processor is configured to execute a computer program product stored in the memory, wherein when the computer program product is executed, it implements the Web3.0-based blockchain compliance detection method as described in any one of claims 1-10.

13. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the Web3.0-based blockchain compliance detection method as described in any one of claims 1-10.

14. A computer program product comprising computer program instructions, characterized in that, When the computer program instructions are executed by the processor, they implement the Web3.0-based blockchain compliance detection method as described in any one of claims 1-10.

Images