A multi-agent collaborative supervision system and method

Abstract

The application discloses a multi-agent collaborative supervision system and method, and belongs to the technical field of data processing. The system comprises a service end and two or more agents; the service end is provided with a data subsystem and a multi-agent collaborative subsystem; the data subsystem is used for acquiring multiple blockchain data and constructing a distributed multi-chain data pool; the multi-agent collaborative subsystem is used for permission management, task flow transfer, rule synchronization, result sharing or / and signature verification of each agent; the agent is provided with a blockchain data processing subsystem and a multi-agent collaborative supervision platform; the blockchain data processing subsystem comprises an intelligent contract vulnerability detection engine, an abnormal transaction identification model and a rule engine; and the multi-agent collaborative supervision platform comprises an intelligent contract inspection platform and a risk transaction monitoring and identification platform. The application effectively solves key problems in multi-agent supervision, such as strategy conflict, result sharing, risk marking fusion, contract record signature and rule synchronization.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology and relates to a multi-entity collaborative supervision system and method. Background Technology

[0002] With the development of cross-border communication mechanisms, cross-border logistics, cross-border cultural exchanges, and cross-border transactions have gradually developed, expanding trade between countries.

[0003] However, the rapid development of cross-border technology has brought great challenges to regulation, especially when it comes to cross-border blockchain. Given the different regulatory policies of different entities (countries) on cross-border blockchain and assets, it is currently difficult to coordinate the regulation of data from multiple blockchains, thus failing to meet the actual regulatory needs of different entities.

[0004] For example, the standards for detecting smart contract vulnerabilities are not uniform among different entities, and there is still a lack of adaptability in multi-entity collaborative scenarios. It is difficult to take into account the different detection standards of multiple entities, and there is still room for improvement in detection efficiency, which cannot fully meet the actual needs of multi-entity collaborative auditing.

[0005] The anonymity of blockchain data also hinders the identification of abnormal transactions, which lacks multi-entity collaborative analysis capabilities. It fails to achieve the integration and sharing of risk characteristics among multiple entities, and the real-time performance and accuracy of risk monitoring still need to be optimized, thus failing to meet the linkage requirements of multi-entity collaborative supervision.

[0006] Moreover, the multi-entity collaboration process suffers from problems such as strategy conflicts, unreliable result sharing, and untimely rule synchronization. In particular, in cross-border regulatory scenarios, the differences in regulatory strategies between different countries (such as country A and country B) (such as the contradiction between prohibiting data export and transparent sharing), conflicting address risk marking, and asynchronous vulnerability rules are prominent issues. The security and verifiability of shared regulatory results are insufficient, and the contract filing and signing process is not standardized, which to some extent restricts the efficiency and compliance of multi-entity collaborative supervision. Summary of the Invention

[0007] To address the aforementioned shortcomings in existing technologies, this invention provides a multi-entity collaborative supervision system and method that takes into account multi-entity collaboration and resolves issues such as strategy conflicts, reliability of result sharing, effectiveness of risk labeling, and rule synchronization in multi-entity supervision.

[0008] To achieve the above-mentioned objectives, the present invention employs the following technical solutions.

[0009] This invention provides a multi-entity collaborative supervision system, which includes a server and two or more entities;

[0010] The server-side configuration includes a data subsystem and a multi-entity collaboration subsystem.

[0011] The data subsystem is used to acquire data from multiple blockchains and build a distributed multi-chain data pool.

[0012] The multi-subject collaborative subsystem is used for permission management, rule synchronization, result sharing and / or signature verification of each subject;

[0013] The main body is equipped with a blockchain data processing subsystem and a multi-entity collaborative supervision platform;

[0014] The blockchain data processing subsystem includes a smart contract vulnerability detection engine, an abnormal transaction identification model, and a rules engine.

[0015] The smart contract vulnerability detection engine is used to detect vulnerabilities in smart contracts on the blockchain; the abnormal transaction identification model is used to identify risks in blockchain transaction data submitted by the subject; the rule engine is used to match corresponding rules from the rule base according to the subject's needs and execute operations according to the rules.

[0016] The multi-entity collaborative regulatory platform includes a smart contract verification platform and a risk transaction monitoring and identification platform.

[0017] The smart contract verification platform is used to automatically detect, verify, and generate reports for smart contracts proposed by any entity through a smart contract vulnerability detection engine and a multi-entity collaborative subsystem.

[0018] The risk transaction monitoring and identification platform is used to conduct risk assessment and share blockchain transaction data through an abnormal transaction identification model and a multi-entity collaborative subsystem.

[0019] In the aforementioned multi-entity collaborative regulatory system, the entities are national regulatory agencies or core collaborative entities; the core collaborative entities are designated by all national regulatory agencies.

[0020] In the aforementioned multi-entity collaborative regulatory system, the data subsystem receives multiple blockchain data, including two or more from mainstream blockchain networks such as BTC, ETH, BSC, and Conflux. Based on the received blockchain data, the data subsystem independently stores and compliantly shares the regulatory data of each entity, resulting in a distributed multi-chain data pool. Specifically, the data subsystem sets corresponding data isolation nodes (entity nodes) for each entity and generates data that can be shared by each entity according to the data sharing strategy set by each entity; it can also store the data for sharing in a distributed shared library to achieve compliant sharing.

[0021] Furthermore, the data subsystem also includes a smart contract model library for classifying and managing smart contract vulnerabilities. This library is jointly built by multiple entities and shared by all entities.

[0022] In the aforementioned multi-entity collaborative supervision system, the multi-entity collaboration subsystem is mainly used to solve key issues in multi-entity supervision such as strategy conflicts, result sharing, risk tagging integration, contract filing and signing, and rule synchronization. It enables efficient collaboration among multiple entities, ensures that the collaboration process is traceable and auditable, and highlights the core value of multi-entity collaboration.

[0023] In the aforementioned multi-entity collaborative supervision system, the blockchain data processing subsystem integrates various technical modules to process blockchain data.

[0024] In one possible implementation, the smart contract vulnerability detection engine includes a smart contract matching module and a vulnerability scanning engine; the smart contract matching module is used to match corresponding contract models from a smart contract model library; the vulnerability scanning engine is used to scan the smart contract code and discover vulnerabilities.

[0025] In one possible implementation, the abnormal transaction identification model employs an unsupervised machine learning algorithm, such as the K-means algorithm, the Isolation Forest algorithm, or the DBSCAN algorithm.

[0026] In one possible implementation, the rule base includes data sharing policy priority rules, vulnerability rules, etc.

[0027] In the aforementioned multi-entity collaborative supervision system, the multi-entity collaborative supervision platform further includes a system dashboard, a comprehensive search unit, a real-time transaction risk display unit, and a strategy management unit. The system dashboard displays real-time blockchain data statistical analysis results, including transaction statistics, transaction risk statistics, and asset analysis. The comprehensive search unit assesses the risk of blockchain addresses or transaction targets based on the results identified by the abnormal transaction identification model. The real-time transaction risk display unit displays real-time risk transaction warnings on the blockchain. The strategy management unit includes a risk identification strategy subunit and a contract code risk strategy subunit. The risk identification strategy subunit defines rules for entities to identify risks on various blockchains. The contract code risk strategy subunit defines rules for entities to identify smart contract vulnerabilities.

[0028] Based on the aforementioned multi-entity collaborative supervision system, this invention also provides a multi-entity collaborative supervision method, which includes:

[0029] Smart contract vulnerability verification: Any smart contract proposed by any entity is first detected by the smart contract vulnerability detection engine, and then the signature verification of the multi-entity collaborative subsystem is triggered to output a vulnerability inspection report.

[0030] Address risk labeling fusion: For any transaction address, multiple entities conduct risk assessments separately, and then a multi-entity collaborative subsystem performs weighted scoring, combined with a set threshold, to label the address risk.

[0031] The aforementioned multi-entity collaborative regulatory approach also includes:

[0032] Synchronization of smart contract vulnerability rules (i.e., vulnerability rules): Any vulnerability rule submitted by any entity is first converted into a standardized rule package, then signature verification is triggered, and each entity signs and verifies the rule. After that, the rule is saved to the rule base of each entity.

[0033] The aforementioned multi-entity collaborative regulatory approach also includes:

[0034] Data sharing strategy conflict reconciliation: Based on the priority rules of the data sharing strategy determined by each subject, the blockchain data is classified according to the standards of core sensitive data, general regulatory data and public data through the rule engine. The core sensitive data is anonymized and then the anonymized data is saved together with the general regulatory data and public data to the distributed shared library.

[0035] Compared with existing technologies, the multi-entity collaborative supervision system and method provided by this invention, through a multi-entity collaborative mechanism and the introduction of a multi-system collaborative subsystem, effectively solves key problems in multi-entity supervision such as strategy conflict, result sharing, risk tag fusion, contract filing and signing, and rule synchronization. Through the innovative design of the multi-entity collaborative mechanism, it highlights the advantages of multi-entity collaboration and improves the efficiency, security, and compliance of multi-entity collaborative supervision, specifically in the following ways:

[0036] (1) This invention can effectively determine the type, location and risk of vulnerabilities by conducting collaborative inspection of smart contract vulnerabilities and verifying them through multi-party consensus, thereby improving detection efficiency and vulnerability detection rate.

[0037] (2) By fusing and marking risk addresses, this invention not only solves the problem of address risk marking conflicts, but also identifies risks more accurately and improves the accuracy of risk identification.

[0038] (3) By standardizing vulnerability rules and verifying multi-party consensus, this invention can achieve the unification of multi-party vulnerability detection standards and realize fair and effective multi-party supervision.

[0039] (4) This invention improves the security and credibility of shared results by performing multi-subject signature verification on the shared results and setting up dual verification during the verification of shared results;

[0040] (5) This invention achieves policy conflict reconciliation through multi-subject negotiation, performs desensitization processing on sensitive data, and meets the data sharing needs of other subjects while ensuring the security of the subject's data. Attached Figure Description

[0041] Figure 1 This is a schematic diagram of the multi-entity collaborative supervision system provided in Embodiment 1 of the present invention;

[0042] Figure 2 This is a schematic diagram of the data subsystem.

[0043] Figure 3 This is a schematic diagram of the composition of a multi-entity collaborative subsystem;

[0044] Figure 4 A schematic diagram of the components of a blockchain data processing subsystem;

[0045] Figure 5 This is a schematic diagram of the components of a multi-entity collaborative regulatory platform. Detailed Implementation

[0046] The specific embodiments of the present invention are described below to enable those skilled in the art to understand the present invention. However, it should be understood that the present invention is not limited to the scope of the specific embodiments. For those skilled in the art, various changes are obvious as long as they are within the spirit and scope of the present invention as defined and determined by the appended claims. All inventions utilizing the concept of the present invention are protected.

[0047] Example 1

[0048] To overcome the shortcomings of existing technologies, such as insufficient multi-entity collaboration, inefficient and high-consumption smart contract vulnerability detection, insufficient accuracy in identifying abnormal transactions, and frequent conflicts in multi-entity collaborative supervision, this embodiment provides a multi-entity collaborative supervision system. This system optimizes the overall architecture to adapt to the needs of multi-entity collaboration, constructs an efficient and accurate smart contract vulnerability discovery system and risk identification model, and achieves efficient detection of smart contract vulnerabilities, accurate identification and real-time monitoring of abnormal transactions. It focuses on solving key issues in multi-entity supervision, such as strategy conflicts, result sharing, risk tag fusion, contract registration and signing, and rule synchronization. Through the innovative design of the multi-entity collaboration mechanism, it highlights the advantages of multi-entity collaboration, improves the efficiency, security, and compliance of multi-entity collaborative supervision, and is suitable for cross-border multi-entity supervision scenarios.

[0049] The multi-entity collaborative supervision system provided in this embodiment, such as Figure 1 As shown, it includes a server and two or more entities. The server communicates with two or more entities, providing data support and collaborative services between them. The entities are national regulatory agencies or core collaborative entities; the core collaborative entities are designated by all national regulatory agencies.

[0050] (a) The server is equipped with a data subsystem and a multi-entity collaboration subsystem.

[0051] 1. Data Subsystem: Used to acquire data from multiple blockchains and build a distributed multi-chain data pool.

[0052] The system unifies the collection of data from multiple blockchains, including at least two of the mainstream blockchain networks such as BTC, ETH, BSC, and Conflux. Based on this received blockchain data (serving as foundational regulatory data), the data subsystem independently stores and compliantly shares regulatory data among various entities, resulting in a distributed multi-chain data pool. Specifically, for example... Figure 2 As shown, the data subsystem sets up corresponding data isolation nodes (i.e., independent storage databases) for each entity; and generates data that can be shared by each entity according to the data sharing strategy set by each entity; it can also store data for sharing in a distributed shared library to achieve compliant sharing.

[0053] The distributed shared library is deployed on all participating entity nodes (including Country A, Country B, and other core entities). Each entity node stores a complete copy of the shared data, ensuring that all entities can easily access and synchronize in real time, realizing "multi-entity co-construction and sharing" and avoiding the risk of a single entity controlling the shared data.

[0054] In one feasible approach, the core index information of the shared results in the distributed shared library (such as result summary, timestamp, multi-subject signature information, data source, etc.) can also be uniformly anchored to a designated public chain (such as the ETH public chain). By utilizing the blockchain's block-chain structure and hash encryption characteristics, the shared results can be made immutable and traceable. The anchoring process is witnessed by multiple subjects, and the anchoring information is synchronously pushed to all subject nodes to ensure transparency and verifiability.

[0055] The shared results in the distributed shared library are tamper-proof: when any subject generates a shared result, it first anchors the core index information of the shared result to the public chain and pushes the anchor information to all subject nodes in a synchronized manner; and triggers a multi-subject signature process. Subjects that pass the verification can submit verification confirmation opinions in the system, forming a multi-subject cross-verification record, which is synchronized to all subject nodes to further ensure the credibility of the shared results.

[0056] When any entity queries the shared result, it first queries the corresponding index information through the public chain and compares it with the shared result stored locally. If the hash values ​​match, it is preliminarily confirmed that the result has not been tampered with. Subsequently, the signature verification of the multi-entity collaborative subsystem verifies the multi-entity digital signature corresponding to the shared result (all participating entities must sign to confirm the shared result). The signature validity is verified through the public keys of each entity to confirm that the source of the result is legitimate and has not been tampered with.

[0057] The distributed shared library not only enables convenient sharing of regulatory results, but also completely solves the problem of preventing tampering of shared results through multi-entity distributed storage, multi-entity cross-verification, and multi-entity signature, highlighting the core value of multi-entity collaborative management and control.

[0058] The data subsystem also includes a smart contract model library for classifying and managing smart contract vulnerabilities. This library is collaboratively built by multiple entities and shared by all entities. Each entity can upload its own custom smart contract model, which is then cross-verified and signed by multiple entities before being stored in the smart contract model library.

[0059] 2. Multi-entity collaboration subsystem: As the core hub of multi-entity collaboration, it is mainly used for the permission management, rule synchronization, result sharing and / or signature verification of each entity.

[0060] The multi-entity collaboration subsystem integrates core functions such as permission management, rule synchronization, result sharing, and multi-entity negotiation. It optimizes the synchronization mechanism of the distributed shared library and adopts an incremental synchronization algorithm (i.e., only synchronizing the changed data each time) to improve sharing efficiency and reduce system resource consumption. It is used to solve key issues in multi-entity supervision, such as strategy conflict, result sharing, risk tag fusion, contract filing and signing, and rule synchronization, to achieve efficient collaboration among multiple entities, ensure that the collaboration process is traceable and auditable, and highlight the core value of multi-entity collaboration.

[0061] like Figure 3 As shown, the multi-entity collaborative subsystem includes a signature verification module, a negotiation module, a review module, an evidence sharing module, a rule synchronization module, and a result sharing module.

[0062] The signature verification module is used to send signatures or verification instructions to the corresponding entity, and can also be used to verify the validity of the entity's signature;

[0063] The negotiation module is used to send negotiation instructions received from any subject to a designated subject;

[0064] The review module is used to send review instructions received from any subject to a designated subject;

[0065] The rule synchronization module is used to synchronize rules received from any subject to all subjects;

[0066] The evidence sharing module is used to share received evidence from at least one subject to a designated subject;

[0067] The results sharing module is used to synchronize the results received from any subject to all subjects.

[0068] The aforementioned access control and signature verification can be implemented using conventional methods already disclosed in this field. Specifically, the signature employs blockchain-based multi-principal digital signature technology. Each signing entity uses its own exclusive key to sign, and the signature information is synchronously written to the blockchain filing node of the multi-principal collaborative subsystem, and simultaneously synchronized to all entity nodes. The entire signing process is traceable, and each signature is associated with the corresponding entity's identity information and signature time, ensuring that the signature is non-repudiable.

[0069] (ii) Each entity is equipped with a blockchain data processing subsystem and a multi-entity collaborative supervision platform.

[0070] 1. Blockchain data processing subsystem, integrating various technical modules to process blockchain data; it includes a smart contract vulnerability detection engine, an abnormal transaction identification model, and a rule engine, such as... Figure 4 As shown.

[0071] The smart contract vulnerability detection engine is used to detect vulnerabilities in smart contracts on the blockchain. It includes a smart contract matching module, a vulnerability scanning engine, and a formal verification engine.

[0072] The smart contract matching module is used to match corresponding contract models from the smart contract model library. The vulnerability scanning engine scans the smart contract code to discover vulnerabilities. The engine first performs a preliminary scan of the smart contract code to identify syntax vulnerabilities, interface errors, etc., reducing detection power consumption. Then, it verifies the smart contract vulnerabilities according to the set vulnerability rules, accurately identifying hidden logic vulnerabilities, reentrancy vulnerabilities, etc. The vulnerability scanning engine can employ technologies already disclosed in the field, such as the inventor's earlier patent applications CN108985073A, CN109063477A, ​​CN115310095A, etc.

[0073] In addition, the smart contract vulnerability detection engine also includes a business logic inspection module. Based on business logic specifications, it comprehensively examines the smart contract's permission allocation, transaction processes, and data interactions to identify business logic vulnerabilities (such as permission abuse and missing process loops), ensuring that the contract not only meets security requirements but also complies with multi-party regulatory compliance standards. The business logic specifications are collaboratively specified by multiple parties through a multi-party collaborative subsystem, verified through consensus among all parties, and stored in a distributed shared library.

[0074] The anomaly transaction identification model is used to identify risks in blockchain transaction data. It employs unsupervised machine learning algorithms, such as K-means, Isolation Forest, or DBSCAN. The model combines data feature profiling technology (extracting multi-dimensional features such as transaction amount, frequency, associated addresses, and fund flow) to train a basic model. It can also incorporate public opinion analysis data and real-time monitoring data from multiple entities, dynamically updating the model with a historical attack event feature database to improve identification accuracy and early warning response speed. Furthermore, the model can incorporate custom risk features from various entities (such as features associated with sanctions lists of concern to country A, or money laundering transaction features of concern to country B) for personalized fine-tuning. The model can capture multi-chain transaction data in real time, identify illegal transactions, and classify them into risk levels (e.g., low, medium, high risk), simultaneously pushing the data to corresponding collaborating entities and supporting multi-entity collaborative review.

[0075] The rule engine is used to match relevant rules from the rule base based on the needs of the main entity, and then execute operations according to the rules. The rule base includes data sharing policy priority rules, vulnerability rules, etc., and is set in a distributed shared library, with each rule associated with the rule engine.

[0076] 2. The multi-entity collaborative regulatory platform includes a smart contract verification platform and a risk transaction monitoring and identification platform, such as... Figure 5 As shown.

[0077] (1) Smart contract verification platform, which is used to automatically detect, verify and generate reports of smart contracts proposed by any subject through a smart contract vulnerability detection engine and a multi-subject collaborative subsystem.

[0078] To address the pain points of smart contract vulnerability detection and the need for multi-party supervision, this embodiment constructs a "multi-engine collaboration + multi-party consensus verification" vulnerability detection system based on smart contract vulnerability detection engines of various parties and a multi-party collaborative subsystem.

[0079] Each entity's smart contract vulnerability detection engine can perform vulnerability detection on smart contracts submitted by any entity on the blockchain.

[0080] After the smart contract vulnerability detection is completed, a multi-party consensus verification process is triggered. The signature verification module of the multi-party collaboration subsystem synchronizes the vulnerability detection results to other parties, and all parties perform cross-verification. After confirming that the person is correct, a vulnerability inspection report is output, which clarifies the vulnerability type, location, risk level and remediation suggestions, thereby improving detection efficiency and vulnerability detection rate.

[0081] The contract testing results require further contract registration. The entire contract registration process revolves around the core principles of multi-party collaborative management and equal rights and responsibilities, highlighting the advantages of multi-party participation, multi-party verification, and multi-party traceability. Specifically: ① Signing Entities: After the contract passes the vulnerability discovery system and multi-party consensus verification, the registration record must be jointly signed by three categories of entities. The scope of signing entities is determined through joint consultation among all participating entities in collaborative supervision, ensuring equal rights and responsibilities. Specifically, this includes: the smart contract submitting entity (responsible for submitting the contract and bearing the responsibility for contract compliance), the smart contract formal verification platform management entity (responsible for verifying process compliance and bearing verification responsibility), and all core entities participating in collaborative supervision (such as Country A, Country B, and other collaborative regulatory agencies in cross-border supervision, responsible for confirming that the contract meets the regulatory requirements of each entity). All signing entities are indispensable, ensuring multi-party joint management of the contract registration process; ② Signing Method: A blockchain-based multi-party digital signature technology is used. Each signing entity signs using its own exclusive key. The signature information is synchronously written to the blockchain registration node of the multi-party collaborative subsystem and simultaneously synchronized to all entity nodes. The entire signing process is traceable, and each signature is associated with the corresponding entity's identity information and signature time, ensuring that the signature is non-repudiable; ③ Verification Process: The verification process involves collaboration and cross-verification among multiple entities. When any entity queries the registration record, it can complete dual verification through the signature verification module of the multi-entity collaborative subsystem: First, the validity of the corresponding digital signature is verified using the public keys of each signing entity to confirm that the signature has not been forged and the identity of the signing entity is legitimate; second, the permissions of the signing entity are checked to ensure compliance with the multi-entity preset rules (i.e., whether the signing entity is a core entity determined through negotiation), confirming that the signature process is compliant. After successful verification, the registration record becomes effective, and the effectiveness information is simultaneously pushed to all collaborative entity nodes. The registration record and signature information are permanently stored and cannot be tampered with. All entities can query and verify them at any time, ensuring the legality and integrity of the contract registration and the equivalence of the multi-entity regulatory responsibilities, demonstrating the authority of multi-entity collaborative management.

[0082] (2) Risk transaction monitoring and identification platform, used to conduct risk assessment and sharing of blockchain transaction data through abnormal transaction identification model and multi-entity collaborative subsystem.

[0083] Each entity can upload local attack cases to the multi-entity collaborative subsystem. After consensus verification and signing by all entities, these cases are included in the shared attack signature database. The data in the shared attack signature database is then used to train the abnormal transaction identification model. The shared attack signature database can be stored in a distributed shared library.

[0084] Each entity can also upload its local address risk data, malicious address list, and associated risk characteristics to the multi-entity collaborative subsystem. After consensus verification and signing by all entities, these data are incorporated into the shared blockchain address risk characteristic database. An abnormal transaction identification model scans the addresses in the shared blockchain address risk characteristic database in real time, checking for risks such as address association with malicious transactions, illegal transfers, and association with sanctions lists. High-risk addresses are automatically pushed to all collaborating entities for collaborative review and joint risk level marking, synchronously updating the shared blockchain address risk characteristic database. The shared blockchain address risk characteristic database can be stored in a distributed shared library.

[0085] (3) The multi-entity collaborative supervision platform also includes system dashboards, comprehensive search units, real-time transaction risk display units, strategy management units, etc., such as Figure 5 As shown.

[0086] The system dashboard is used to display the results of blockchain data statistical analysis in real time, including transaction statistics, transaction risk statistics, asset analysis, etc.

[0087] The integrated search unit is used to perform risk assessments on blockchain addresses or transaction targets based on the results identified by the abnormal transaction identification model. Specifically, the integrated search unit receives requests for risk assessment of blockchain addresses or transaction targets, inputs them into the abnormal transaction identification model, outputs the risk identification results of the blockchain addresses or transaction targets, and provides real-time feedback through the integrated search unit.

[0088] The real-time transaction risk display unit is used to display risky transaction warnings on the blockchain in real time. Specifically, the abnormal transaction identification model performs risk analysis on the transaction data on the blockchain in real time. When the risk identification result is of a high-risk level, the risk identification result is pushed to the real-time transaction risk display unit for real-time display.

[0089] The strategy management unit includes a risk identification strategy subunit and a contract code risk strategy subunit. The risk identification strategy subunit is used by entities to define rules for identifying risks on various blockchains (e.g., country A sets risk thresholds related to data export, and country B sets rules for transparent sharing risks). The contract code risk strategy subunit is used by entities to define rules for identifying smart contract vulnerabilities. The identification rules defined by the risk identification strategy subunit and the contract code risk strategy subunit are associated with the corresponding rule engine.

[0090] When in use, each entity logs into the corresponding interface system through its account and accesses the corresponding modules according to its own role permissions; when problems such as address marking conflicts or vulnerability rule synchronization occur, each entity participates and makes collaborative decisions to achieve efficient collaborative supervision among multiple entities.

[0091] Example 2

[0092] This embodiment is a further improvement on Embodiment 1. This embodiment provides a multi-entity collaborative supervision method, including:

[0093] (1) Smart contract vulnerability verification: Any smart contract proposed by any entity is automatically detected, verified by multi-entity consensus and generated by the smart contract verification platform.

[0094] A smart contract verification platform can be a smart contract verification platform deployed on the current entity, or it can be a smart contract verification platform on a designated entity that specifically assumes verification responsibility.

[0095] Specifically, smart contract vulnerability verification includes the following steps:

[0096] (11) For any smart contract proposed by any entity, vulnerability detection is first performed through the smart contract vulnerability detection engine.

[0097] First, the smart contract matching module matches the contract model of the corresponding blockchain network based on the smart contract model library of the data subsystem. Then, the vulnerability scanning engine performs a preliminary scan of the contract code to identify obvious syntax vulnerabilities, interface errors, etc., reducing detection energy consumption. Next, the contract bytecode is converted into a standardized form, and then the core logic of the contract is deeply verified to accurately identify hidden logic vulnerabilities, reentrancy vulnerabilities, etc.

[0098] (12) After completing the initial detection of smart contract vulnerabilities, a multi-party consensus verification process is triggered. Each designated party and core collaborating party cross-verify the vulnerability detection results. After confirming that there are no errors, a vulnerability inspection report is output, which clarifies the vulnerability type, location, risk level and remediation suggestions, thereby improving detection efficiency and vulnerability detection rate.

[0099] (13) After the contract passes the test, the contract filing and signing process is initiated. The signing verification module of the multi-entity collaborative subsystem is used to sign the contract by the designated signing entities (including the smart contract submission entity, the smart contract verification platform management entity, the regulatory entities of various countries, and the core collaborative entities). Each signing entity signs with its own exclusive key, and the signature information is written into the blockchain filing node and synchronized to all nodes. The signing time and entity information are recorded throughout the process.

[0100] The results of smart contract vulnerability detection after signing are synchronized to the distributed shared library of all subject nodes through the result sharing module of the multi-subject collaborative subsystem.

[0101] In addition, smart contract vulnerability verification also includes the following steps:

[0102] (14) When any entity queries the filing record, it must complete the double verification through the signature verification module of the multi-entity collaborative subsystem: First, the validity of the corresponding digital signature is verified by using the public key of each signing entity to confirm that the signature has not been forged and the identity of the signing entity is legitimate; Second, the permissions of the signing entity are checked to see if they comply with the multi-entity preset rules (i.e., whether the signing entity is the core entity determined by negotiation) to confirm that the signing process is compliant; After the verification is passed, the filing record can take effect, and the effective information is pushed to all collaborative entity nodes at the same time. The filing record and signature information are permanently stored and cannot be tampered with. All entities can query and verify at any time to ensure the legality and integrity of the contract filing and the equivalence of the multi-entity supervision rights and responsibilities, and to demonstrate the authority of multi-entity collaborative management.

[0103] (2) Address risk labeling fusion: For any transaction address, multiple entities conduct risk assessments separately, and then a multi-entity collaborative subsystem performs weighted scoring, combined with a set threshold, to label the address risk.

[0104] Specifically, address risk label fusion includes the following steps:

[0105] (21) The multi-entity collaborative subsystem automatically extracts the core evidence of the risk-marked addresses of each country (e.g., the core evidence of the address marked by country A and country B, the sources of which include the analysis results of the abnormal risk identification model of each entity, local regulatory data (blockchain data that meets regulatory conditions), related transaction records, etc.), and shares the evidence with the designated entity (e.g., country A, country B and core collaborative entities) through the evidence sharing module of the multi-entity collaborative subsystem, so as to realize "multi-entity evidence sharing" and ensure that each entity can fully understand the basis for the other party's marking.

[0106] (22) Each designated entity shall negotiate and set the evidence weighting coefficient of each entity through the negotiation module of the multi-entity collaborative subsystem (the weight can be dynamically adjusted and shall take effect after being confirmed by the consensus of all participating entities) to ensure that the weight allocation is fair and reasonable; then, the marked evidence of the evidence submission entity shall be weighted and scored according to the weighting coefficient.

[0107] (23) Combining the preset malicious threshold and normal threshold, the address marking result is initially determined: if the weighted score is higher than the malicious threshold, it is marked as "malicious"; if it is lower than the normal threshold, it is marked as "normal"; if it is between the normal threshold and the malicious threshold, the multi-subject collaborative review process is immediately triggered; finally, the regulatory personnel of each designated subject participate in the multi-subject collaborative review, and through the review module of the multi-subject system subsystem, they view all evidence and weighted score details online, jointly negotiate to determine the final marking result, the review opinions and the negotiation process are recorded in the whole process, and all participating subjects sign to confirm, so as to ensure the rationality, traceability and multi-subject recognition of the fusion result, completely solve the problem of address risk marking conflict between different subjects, and highlight the advantages of multi-subject collaborative judgment and collaborative decision-making.

[0108] (24) The risk address marking results are synchronized to the distributed shared library of all subject nodes through the result sharing module of the multi-subject collaborative subsystem.

[0109] Example 3

[0110] This embodiment is a further improvement on embodiment 2. The multi-entity collaborative supervision method provided in this embodiment also includes:

[0111] (3) Synchronization of smart contract vulnerability rules: Any vulnerability rule submitted by any subject is generated into a standardized rule package by the multi-subject collaborative subsystem, and signature verification is triggered. Each subject signs and verifies the rule, and then it is saved to the rule library of each subject.

[0112] Specifically, the synchronization of smart contract vulnerability rules includes the following steps:

[0113] (31) Based on the preset vulnerability rule standardization specifications, parse the submitted vulnerability rules and generate a standardized rule package.

[0114] The standardized vulnerability rule specifications include vulnerability types, detection logic, risk levels, parameter formats, etc. These specifications become effective after consensus verification and signature by designated entities (e.g., Country A, Country B, and core collaborating entities), ensuring that vulnerability rules submitted by different entities have a unified format and are interoperable. The standardized vulnerability rule specifications can be stored in a distributed shared repository.

[0115] For any vulnerability rule submitted by any entity (such as Country A), the multi-entity collaborative subsystem performs standardized parsing of the rule according to the vulnerability rule standardization specification, extracts core information such as vulnerability type, detection logic, and risk level, generates a standardized rule package that conforms to the unified multi-entity specification, and records information such as rule submission time, submitting entity, rule details, and version number, and pushes it synchronously to the designated entity (such as Country A, Country B, and core collaborative entity nodes) for all entities to view.

[0116] (32) Trigger the multi-subject collaborative verification process, and other designated subjects besides the submitting subject perform consensus verification and signing.

[0117] For example, the B country's rule engine first conducts a preliminary verification of the rules' compatibility and validity (confirming that they do not conflict with existing local rules in B country and meet B country's regulatory requirements). At the same time, other core collaborating entities are invited to participate in the collaborative verification. Each entity can submit verification opinions within a specified time. If there are any objections, the rules can be communicated with the A country through the negotiation module of the multi-entity collaborative subsystem to optimize the rules.

[0118] (33) After verification, the standardized rule package will be synchronized to all subjects.

[0119] For example, standardized rules are synchronized to the rule engines of Country B and other relevant entities, the local rule bases and smart contract model bases of each entity are updated, version records are synchronized, and the vulnerability detection rules of all collaborating entities are consistent.

[0120] If verification fails, the reason for the failure (such as rule conflict or format mismatch) will be fed back to the submitting entity. The submitting entity will then optimize the rules based on the verification opinions from multiple entities and resubmit them. The entire synchronization process is recorded, including all stages such as rule submission, parsing, verification, synchronization, and updating. All participating entities can view and trace the process in real time, ensuring that the entire process of cross-entity synchronization of vulnerability rules is controllable and auditable. This achieves the unification of vulnerability detection standards among multiple entities and highlights the advantages of multi-entity collaborative optimization and linkage.

[0121] Example 4

[0122] This embodiment is a further improvement based on Embodiment 2 or Embodiment 3. The multi-entity collaborative supervision method provided in this embodiment also includes:

[0123] (4) Data sharing strategy conflict reconciliation: Based on the strategy priority rules determined by each subject, the blockchain data is classified according to the standards of core sensitive data, general regulatory data and public data through the rule engine. The core sensitive data is desensitized and then the desensitized data, general regulatory data and public data are saved to the distributed shared library.

[0124] This mainly involves multi-party collaborative consultation and the linkage of the rule engine to achieve compliant reconciliation of differentiated strategies, highlighting the participation and consensus of multiple parties throughout the process.

[0125] Specifically, resolving data sharing strategy conflicts includes the following steps:

[0126] (41) Based on the policy priority rules, the blockchain data is classified according to the data sharing policy priority rules determined by each subject through the rule engine, according to the standards of core sensitive data, general regulatory data and public data.

[0127] The data sharing strategy priority rules refer to the priority levels of the data sharing strategies of each entity. Combining relevant data security regulations of various countries (such as data export security assessments and personal information protection regulations), the rules are determined through the negotiation module of the multi-entity collaborative subsystem. Designated entities (e.g., Country A, Country B, and core collaborative entities) jointly negotiate and clarify the core principle of "data security compliance first, multi-entity collaborative needs second," thereby determining the priority level of each entity's data sharing strategy (e.g., if Country A prohibits data export and Country B requires transparent sharing, Country A's data sharing strategy takes precedence over Country B's). These rules take effect after consensus verification and signing. The data sharing strategy priority rules can be stored in a rule base. Simultaneously, a data grading standard is developed collaboratively by multiple entities, classifying blockchain data from Country A into three categories: core sensitive data (e.g., classifying personal information and important data as core sensitive data), general regulatory data (general transaction data), and public data (public regulatory information). This grading standard, combined with the regulatory needs of each entity, is confirmed through multi-entity voting to ensure adaptation to the differentiated requirements of each entity.

[0128] (42) The rule engine automatically adapts to the strategies of each subject according to the priority rules and data classification standards, performs desensitization processing on core sensitive data, and then saves the desensitized data, general regulatory data and public data to the distributed shared library.

[0129] For example, in response to Country A's core requirement of "prohibiting data from leaving the country", the rule engine uses privacy computing technology (such as federated learning and differential privacy) to achieve "data is usable but not visible" for core sensitive data (such as personal information and important data). It only shares the anonymized analysis results with Country B and does not transmit the original data, which strictly complies with Country A's data export control requirements.

[0130] For general regulatory data and publicly available data, in accordance with Country B's "transparent sharing" requirements, compliant sharing will be achieved through a distributed shared repository to ensure that Country B's regulatory transparency needs are met.

[0131] The entire reconciliation process is recorded, including the opinions of multiple parties, the results of priority confirmation, the data classification standards, and the details of reconciliation execution. All participating parties can view and trace the process in real time. The reconciliation results (i.e., the core sensitive data, general regulatory data, and public data after anonymization) take effect after being confirmed by countries A and B and the core collaborating parties, which completely resolves the problem of conflicting strategies among different parties and demonstrates the advantages of multi-party collaborative decision-making and collaborative adaptation.

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

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

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

[0135] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

[0136] Those skilled in the art will recognize that the embodiments described herein are intended to help the reader understand the principles of the invention, and should be understood that the scope of protection of the invention is not limited to such specific statements and embodiments. Those skilled in the art can make various other specific modifications and combinations based on the technical teachings disclosed in this invention without departing from the spirit of the invention, and these modifications and combinations are still within the scope of protection of this invention.

Claims

1. A multi-entity collaborative supervision system, characterized in that, Includes the server and two or more entities; The server-side configuration includes a data subsystem and a multi-entity collaboration subsystem. The data subsystem is used to acquire data from multiple blockchains and build a distributed multi-chain data pool. The multi-subject collaborative subsystem is used for permission management, rule synchronization, result sharing, and / or signature verification of each subject; The main body is equipped with a blockchain data processing subsystem and a multi-entity collaborative supervision platform; The blockchain data processing subsystem includes a smart contract vulnerability detection engine, an abnormal transaction identification model, and a rules engine. The smart contract vulnerability detection engine is used to detect vulnerabilities in smart contracts on the blockchain; the abnormal transaction identification model is used to identify risks in blockchain transaction data; and the rule engine is used to match corresponding rules from the rule base according to the needs of the subject and execute operations according to the rules. The multi-entity collaborative regulatory platform includes a smart contract verification platform and a risk transaction monitoring and identification platform. The smart contract verification platform is used to automatically detect smart contracts, verify multi-party consensus, and generate reports through a smart contract vulnerability detection engine and a multi-party collaborative subsystem. The risk transaction monitoring and identification platform is used to conduct risk assessment and share blockchain transaction data through an abnormal transaction identification model and a multi-entity collaborative subsystem.

2. The multi-entity collaborative supervision system according to claim 1, characterized in that, The data subsystem independently stores and compliantly shares regulatory data from various entities based on the received data from multiple blockchains, resulting in a distributed multi-chain data pool.

3. The multi-entity collaborative supervision system according to claim 2, characterized in that, The data subsystem sets up corresponding data isolation nodes for each entity and generates data that can be shared by each entity according to the data sharing strategy set by each entity; it also stores the data to be shared in a distributed shared library.

4. The multi-entity collaborative supervision system according to claim 1, characterized in that, The data subsystem also includes a smart contract model library, which is used to classify and manage smart contract vulnerabilities. This library is jointly built by multiple entities and shared by all entities.

5. The multi-entity collaborative supervision system according to claim 4, characterized in that, The smart contract vulnerability detection engine includes a smart contract matching module and a vulnerability scanning engine; the smart contract matching module is used to match corresponding contract models from the smart contract model library; the vulnerability scanning engine is used to scan the smart contract code and discover vulnerabilities.

6. The multi-entity collaborative supervision system according to claim 1, characterized in that, The abnormal transaction identification model employs an unsupervised machine learning algorithm, such as the K-means algorithm, the isolated forest algorithm, or the DBSCAN algorithm.

7. The multi-entity collaborative supervision system according to claim 1, characterized in that, The multi-entity collaborative supervision platform also includes a system dashboard, a comprehensive search unit, and a real-time transaction risk display unit or strategy management unit; the system dashboard is used to display the results of blockchain data statistical analysis in real time; the comprehensive search unit is used to conduct risk assessment on blockchain addresses or transaction targets based on the results identified by the abnormal transaction identification model; The real-time transaction risk display unit is used to display risk transaction warnings on the blockchain in real time. The strategy management unit includes a risk identification strategy subunit and a contract code risk strategy subunit; the risk identification strategy subunit is used by the subject to define the identification rules for risks on each blockchain; The contract code risk strategy subunit is used by the subject to define the rules for identifying smart contract vulnerabilities.

8. A multi-entity collaborative supervision method, characterized in that, The multi-entity collaborative supervision system according to any one of claims 1 to 7 includes: Smart contract vulnerability verification: Any smart contract proposed by any entity is first detected by the smart contract vulnerability detection engine, and then the signature verification of the multi-entity collaborative subsystem is triggered to output a vulnerability inspection report. Address risk labeling fusion: For any transaction address, multiple entities conduct risk assessments separately, and then a multi-entity collaborative subsystem performs weighted scoring, combined with a set threshold, to label the address risk.

9. The multi-entity collaborative supervision method according to claim 8, characterized in that, Also includes: Synchronization of smart contract vulnerability rules: Any vulnerability rule submitted by any entity is first converted into a standardized rule package, then signature verification is triggered, each entity signs and verifies the rule, and then it is saved to the rule base of each entity. or / and Data sharing strategy conflict reconciliation: Based on the priority rules of the data sharing strategy determined by each subject, the blockchain data is classified according to the standards of core sensitive data, general regulatory data and public data through the rule engine. The core sensitive data is anonymized and then the anonymized data is saved together with the general regulatory data and public data to the distributed shared library.

Images