Method and device for dynamic adaptation of cross-chain regulatory rules based on large models

CN122964139APending Publication Date: 2026-10-23HUA XIA BANK
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611146827.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-30
Publication Date
2026-10-23

AI Technical Summary

Technical Problem

然而各地法律规范持续更新,静态预置方式无法及时响应法规变化,频繁的合约升级既增加运维成本,也引入额外安全风险

Benefits of technology

[0021]本申请提供了一种基于大模型的跨链监管规则动态适配方法。在执行所述方法时,先提取跨境跨链交易的原始请求数据并转化为语义特征向量,为后续的规则检索提供结构化的查询依据;后利用大语言模型基于检索增强生成技术,根据所述语义特征向量在监管知识库中检索关联法律条文并生成针对当前交易的结构化监管规则包,实现监管规则的交易级动态生成;然后将所述监管规则包随跨链消息传递至各层级监管节点,使规则能够随交易流转至全链路各监管执行点;最后在各监管节点处利用大语言模型比较所述监管规则包与节点本地监管策略在语义层面是否一致,识别是否存在逻辑互斥,并在检测到所述逻辑互斥时根据预设的法律效力优先规则生成仲裁指令,调用链上智能合约控制接口执行合规干预,同时将全流程日志上链存证。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122964139A_ABST
    Figure CN122964139A_ABST
Patent Text Reader

Abstract

The application discloses a large model-based cross-chain supervision rule dynamic adaptation method and device, relates to the technical field of blockchains, and comprises the following steps: extracting transaction original data and converting the transaction original data into a semantic feature vector; searching for associated legal provisions in a supervision knowledge base by using a large language model, and generating a structured supervision rule package; transmitting the supervision rule package to each supervision node along with cross-chain messages; comparing the supervision rule package with a local supervision strategy by using the large language model, and identifying semantic conflicts; if there is a conflict, generating an arbitration instruction and calling an intelligent contract to execute intervention, and simultaneously uploading a log to a chain for storage. The application realizes dynamic generation of supervision rules and automatic arbitration of semantic-level conflicts, solves the problems of static pre-setting of rules, difficulty in identifying semantic conflicts and lack of intervention in the process in the prior art, and improves cross-chain compliance efficiency and safety.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a method and apparatus for dynamic adaptation of cross-chain regulatory rules based on a large model. Background Technology

[0002] As blockchain technology evolves towards open networks with multi-chain collaboration, cross-chain transaction scenarios are increasing. Different sovereign jurisdictions have significant differences in their legal systems, and their regulatory requirements are not the same. A single cross-chain transaction often needs to meet the compliance conditions of multiple jurisdictions simultaneously, making the regulatory complexity far higher than that of traditional centralized systems.

[0003] Currently, the mainstream approach to cross-chain regulation is to pre-deploy compliance logic as program code within smart contracts or relay chains. Once deployed, rules are fixed on the chain, and modifications require redeploying the contract or initiating a governance vote. However, with constantly updated laws and regulations in various regions, static pre-deployment methods cannot respond promptly to regulatory changes. Frequent contract upgrades increase operational costs and introduce additional security risks. Furthermore, while legal provisions in different jurisdictions may be similar in natural language, the actual regulatory requirements may contain deep logical contradictions. Relying solely on keyword matching or rule table comparison is insufficient to automatically identify such semantic conflicts. Existing systems largely rely on manual review, which is inefficient and cannot meet the real-time compliance needs of large-scale cross-chain transactions. On the other hand, most existing technologies focus compliance checks on the transaction approval stage, lacking in-process intervention mechanisms after the transaction is approved. Existing solutions cannot dynamically respond to new compliance issues that arise during execution, and compliance risks lack effective control during transaction flow.

[0004] Therefore, there is an urgent need in this field for a technical solution that can dynamically acquire and understand the semantics of regulations in various regions, automatically generate adaptive regulatory strategies for each transaction, and maintain regulatory consistency throughout the entire transaction chain. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a method, apparatus, device, and storage medium for dynamic adaptation of cross-chain regulatory rules based on a large model, including the following: Firstly, this application provides a method for dynamic adaptation of cross-chain regulatory rules based on a large model, the method comprising: Extract the original request data of cross-border and cross-chain transactions, and extract semantic feature vectors from the original request data. The semantic feature vectors include at least the transaction location tag, asset type and business logic description. Using a large language model based on retrieval enhancement generation technology, relevant legal provisions are retrieved from the regulatory knowledge base according to the semantic feature vector to generate a structured regulatory rule package for the current transaction; The regulatory rules package is transmitted to regulatory nodes at all levels along with cross-chain messages; At each regulatory node, a large language model is used to compare whether the regulatory rule package is semantically consistent with the node's local regulatory strategy, and to identify whether there is logical mutual exclusion. If the aforementioned logical mutual exclusion is detected, an arbitration instruction is generated using a large language model based on preset legal validity priority rules. The on-chain smart contract control interface is then invoked according to the arbitration instruction to perform compliance intervention, and the entire process log is recorded on the blockchain for evidence preservation.

[0006] Optionally, the semantic feature vector may also include participant identity information, and the business logic description may include a text explaining the purpose of the transaction and a business operation type label.

[0007] Optionally, the structured regulatory rule package is encapsulated in JSON or XML format, and includes authentication logic, data processing constraint rules, and compliance triggering conditions.

[0008] Optionally, comparing whether the regulatory rule package and the node's local regulatory policy are semantically consistent includes: The rule text in the regulatory rule package and the rule text in the node local regulatory strategy are converted into logical descriptive text using a large language model. The similarity between the vectors corresponding to the logical descriptive text is calculated, and the existence of logical mutual exclusion is determined by combining the stepwise reasoning process of the large language model.

[0009] Optionally, the method further includes: The regulatory knowledge base supports the addition of new legal provisions off-chain at any time. Each addition generates a hash value of the corresponding content and records it on the blockchain. This hash value is used to verify the completeness and version update time of the legal provisions during retrieval, ensuring that the legal provisions retrieved by the large language model are the latest and tamper-proof versions.

[0010] Optionally, the method further includes: Before transmitting the regulatory rule package to regulatory nodes at all levels along with cross-chain messages, the regulatory rule package is encrypted using zero-knowledge proofs so that the specific content of the regulatory rule package is not directly exposed during transmission. Before comparing the regulatory rule package with the node's local regulatory strategy at the semantic level using a large language model at each regulatory node, each regulatory node first verifies the zero-knowledge proof, and only performs subsequent reasoning after the verification is successful.

[0011] Optionally, the arbitration order is at least one of the following: Transaction blocking instructions are used to forcibly terminate cross-chain transactions; A compliance correction order is used to require the transaction initiator to provide supplementary compliance documentation. Degradation execution instructions are used to allow transactions to continue executing while restricting certain business functions.

[0012] Secondly, this application provides a dynamic adaptation device for cross-chain regulatory rules based on a large model, the device comprising: The semantic feature extraction module is used to extract the original request data of cross-border and cross-chain transactions, and extract semantic feature vectors from the original request data. The semantic feature vectors include at least the transaction location label, asset type and business logic description. The rule package generation module is used to utilize a large language model based on retrieval enhancement generation technology to retrieve relevant legal provisions in the regulatory knowledge base according to the semantic feature vector, and generate a structured regulatory rule package for the current transaction. The rule package delivery module is used to deliver the regulatory rule package to regulatory nodes at all levels along with cross-chain messages; The semantic conflict detection module is deployed at each regulatory node and is used to compare the regulatory rule package with the node's local regulatory strategy at the semantic level using a large language model to identify whether there is logical mutual exclusion. The arbitration execution module is used to generate an arbitration instruction based on a preset legal validity priority rule using a large language model when the logical mutual exclusion is detected, and to call the on-chain smart contract control interface to perform compliance intervention according to the arbitration instruction, while storing the entire process log on the chain for evidence.

[0013] Optionally, the semantic feature vector extracted by the semantic feature extraction module may also include participant identity information, and the business logic description may include transaction purpose description text and business operation type label.

[0014] Optionally, the structured regulatory rule package generated by the rule package generation module is encapsulated in JSON or XML format, and the structured regulatory rule package includes authentication logic, data processing constraint rules, and compliance triggering conditions.

[0015] Optionally, the semantic conflict detection module uses a large language model to compare whether the regulatory rule package and the node's local regulatory strategy are semantically consistent, specifically including: The rule text in the regulatory rule package and the rule text in the node local regulatory strategy are converted into logical descriptive text using a large language model. The similarity between the vectors corresponding to the logical descriptive text is calculated, and the existence of logical mutual exclusion is determined by combining the stepwise reasoning process of the large language model.

[0016] Optionally, the regulatory knowledge base supports the addition of new legal provisions off-chain at any time. After each addition, a hash value of the corresponding content is generated and recorded on the blockchain. This is used to verify the integrity and version update time of the legal provisions during retrieval, ensuring that the legal provisions retrieved by the large language model are the latest and tamper-proof versions.

[0017] Optionally, the device further includes: The rule package encapsulation module is used to encrypt the regulatory rule package with zero-knowledge proof before the rule package transmission module transmits the regulatory rule package to each level of regulatory nodes along with cross-chain messages, so that the specific content of the regulatory rule package is not directly exposed during transmission. Before the semantic conflict detection module compares the regulatory rule package with the node's local regulatory strategy at the semantic level using a large language model, each regulatory node first verifies the zero-knowledge proof and only performs subsequent reasoning after the verification is successful.

[0018] Optionally, the arbitration instruction generated by the arbitration enforcement module is at least one of the following: Transaction blocking instructions are used to forcibly terminate cross-chain transactions; A compliance correction order is used to require the transaction initiator to provide supplementary compliance documentation. Degradation execution instructions are used to allow transactions to continue executing while restricting certain business functions.

[0019] Thirdly, this application provides a device including a memory and a processor, the memory being used to store instructions or code, and the processor being used to execute the instructions or code to cause the device to perform the dynamic adaptation method for cross-chain regulatory rules based on a large model as described in any of the implementations of the first aspect.

[0020] Fourthly, this application provides a computer-readable storage medium storing code, wherein when the code is executed, the device running the code implements the dynamic adaptation method for cross-chain regulatory rules based on a large model as described in any of the implementations of the first aspect.

[0021] This application provides a method for dynamic adaptation of cross-chain regulatory rules based on a large-scale model. When executing the method, the original request data of cross-border cross-chain transactions is first extracted and converted into semantic feature vectors, providing a structured query basis for subsequent rule retrieval. Then, using a large-scale language model based on retrieval enhancement generation technology, relevant legal provisions are retrieved from the regulatory knowledge base according to the semantic feature vectors, and a structured regulatory rule package for the current transaction is generated, achieving transaction-level dynamic generation of regulatory rules. The regulatory rule package is then transmitted to regulatory nodes at each level along with cross-chain messages, enabling the rules to flow with the transaction to all regulatory execution points throughout the entire chain. Finally, at each regulatory node, the large-scale language model is used to compare whether the regulatory rule package is semantically consistent with the node's local regulatory strategy, identifying any logical mutual exclusion. When logical mutual exclusion is detected, an arbitration instruction is generated according to a preset legal validity priority rule, invoking the on-chain smart contract control interface to execute compliance intervention, and simultaneously uploading the entire process log to the blockchain for evidence storage.

[0022] By introducing the semantic understanding and logical reasoning capabilities of a large language model and dynamically retrieving legal provisions from a real-time updated regulatory knowledge base based on retrieval-enhanced generation technology, regulatory rules can be updated instantly as regulations change without manual contract redeployment. This solves the technical problem of existing solutions where statically pre-set regulatory rules cannot adapt to dynamic changes in regulations. Furthermore, by using a large language model to perform semantic comparison and step-by-step reasoning on the rule text, cross-jurisdictional rule conflicts can be automatically identified without manual review, solving the technical problem of traditional keyword matching schemes failing to identify deep semantic contradictions. By transmitting regulatory rule packages throughout the entire cross-chain message chain and combining this with the real-time intervention capabilities of smart contracts, compliance checks are extended from a single access stage to the entire transaction lifecycle, solving the technical problem of existing solutions lacking real-time intervention capabilities in regulatory execution. Thus, the dynamic adaptability, semantic conflict identification accuracy, and end-to-end compliance execution efficiency of cross-chain transaction supervision can be significantly improved. Attached Figure Description

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

[0024] Figure 1 A flowchart illustrating a method for dynamic adaptation of cross-chain regulatory rules based on a large model, provided for embodiments of this application; Figure 2 This is a schematic diagram of a cross-chain regulatory rule dynamic adaptation device based on a large model, provided in an embodiment of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0026] Figure 1 This is a flowchart illustrating a method for dynamically adapting cross-chain regulatory rules based on a large model, provided in an embodiment of this application. (Combined with...) Figure 1 As shown in the embodiments of this application, the method for dynamic adaptation of cross-chain regulatory rules based on a large model may include: S101. Extract the original request data of cross-border and cross-chain transactions, and extract semantic feature vectors from the original request data. The semantic feature vectors include at least the transaction location label, asset type, and business logic description.

[0027] The original request data refers to the transaction message generated and submitted by the initiating node when a cross-chain transaction is initiated. This message contains information such as the identity identifiers of the transaction participants, the attribute description of the transaction object, the transaction amount, and relevant business background information. The semantic feature vector is the result of converting the unstructured text information in the original request data into a numerical representation, facilitating semantic retrieval and reasoning by the subsequent large language model. The transaction location tag identifies the regulatory jurisdiction of the transaction initiator and receiver, used for subsequent matching with the corresponding legal provisions. The asset type identifies the category of digital or data assets involved in the transaction; different asset categories may be subject to different regulatory rules. The business logic description records the business scenario and operational purpose of the transaction.

[0028] In one implementation of this application, the semantic feature vector further includes participant identity information, and the business logic description includes a transaction purpose description text and a business operation type tag. The transaction purpose description text records the specific business intent of the transaction, used by the large language model to understand the business scenario in which the transaction occurs, thereby accurately matching relevant legal provisions. The business operation type tag is used to categorize transaction behaviors, such as asset transfer, data sharing, or payment settlement, facilitating quick identification of the business category to which the transaction belongs and invoking the corresponding regulatory policy template. The participant identity information includes an initiator identifier and a receiver identifier, used for subsequent identity verification logic. The transaction purpose description text records the specific business intent of the transaction, and the business operation type tag is used to categorize transaction behaviors, such as asset transfer, data sharing, or payment settlement.

[0029] For example, when a cross-chain transaction is initiated, the received original request data includes the initiator's jurisdiction being jurisdiction A, the recipient's jurisdiction being jurisdiction B, the asset type being a cross-border data packet containing personal data, and the business logic description being the transfer of user personal data from jurisdiction A to jurisdiction B for business analysis. The transaction location tags (jurisdictional A, jurisdiction B), asset type (personal data), and business logic description (cross-border data transfer) are extracted from the aforementioned original request data, and the identity information of the participating parties (initiator's company identifier, recipient's company identifier) ​​are also incorporated into the semantic feature vector.

[0030] This step transforms unstructured transaction messages into structured semantic feature vectors, providing accurate query basis for subsequent regulatory rule retrieval and avoiding the semantic information loss problem caused by relying solely on keyword matching in traditional solutions.

[0031] S102. Using a large language model based on retrieval enhancement generation technology, retrieve relevant legal provisions in the regulatory knowledge base according to the semantic feature vector, and generate a structured regulatory rule package for the current transaction.

[0032] Large language models refer to language models pre-trained on large-scale corpora, possessing the ability to perform semantic understanding and logical reasoning on natural language text. Retrieval-enhanced generation techniques involve retrieving document fragments relevant to the current query from an external knowledge base before the large language model generates its output. These retrieval results are then input into the large language model as part of the generation context, enabling the model's output to be based on external knowledge rather than solely relying on its own parameterized memory. This approach effectively mitigates the illusion problem that large language models may encounter when facing domain-specific knowledge, while ensuring that the generated regulatory rules are based on real-time updated legal texts.

[0033] The regulatory knowledge base is a structured database storing legal provisions from multiple regulatory jurisdictions. Each legal provision is stored in natural language text format, along with metadata such as jurisdictional tags, legal priority rules, effective date, and version number. During retrieval, semantic feature vectors are converted into query statements. The regulatory knowledge base is then searched for legal provisions that match the transaction's jurisdictional tag and asset type. Simultaneously, specific clauses relevant to the current transaction scenario are filtered based on the business logic description.

[0034] A structured regulatory rule package refers to a set of regulatory strategies with a unified data structure generated by semantic understanding and logical reorganization of retrieved legal provisions using a large language model. This regulatory rule package is organized in a structured data format, facilitating transmission in cross-chain messages and programmatic parsing and execution at various regulatory nodes.

[0035] In one implementation of this application, the structured regulatory rule package is encapsulated in JSON or XML format. The structured regulatory rule package includes authentication logic, data processing constraint rules, and compliance triggering conditions. The authentication logic specifies the authentication requirements that transaction participants must meet, such as what type of digital certificate or compliance proof the initiator must provide. The data processing constraint rules specify the operations that need to be performed on the data involved in the transaction during its flow, such as data anonymization, encrypted storage, or access control. The compliance triggering conditions define under what conditions the specific constraints in the rule package take effect, such as triggering corresponding compliance verification when the transaction amount exceeds a specific threshold or when the transaction involves a specific type of data asset.

[0036] Continuing with the previous example, the large language model, based on the jurisdiction A and jurisdiction B labels in the semantic feature vector, retrieves the legal requirements for cross-border transfer of personal data in jurisdiction A and the legal requirements for data receipt and processing in jurisdiction B from the regulatory knowledge base. The retrieved relevant provisions are processed by the large language model to generate a structured regulatory rule package. This package stipulates that data must be anonymized before leaving jurisdiction A, and only anonymized data can be transferred to jurisdiction B. Furthermore, the recipient in jurisdiction B must complete a data usage declaration and filing within 72 hours of receiving the data. These regulations are encapsulated in JSON format, including authentication logic (both parties must provide compliance qualification certificates), data processing constraints (source-side anonymization), and compliance trigger conditions (automatically triggered when personal data is involved).

[0037] This step utilizes search-enhanced generation technology to enable regulatory rules to be dynamically generated based on real-time updated legal texts, thus solving the technical problem of statically pre-set regulatory rules in traditional solutions, which cannot respond to changes in regulations in a timely manner.

[0038] In one implementation of this application, the regulatory knowledge base supports the addition of new legal provisions off-chain at any time. After each addition, a hash value of the corresponding content is generated and recorded on the blockchain. This hash value is used to verify the integrity and version update time of the legal provisions during retrieval, ensuring that the legal provisions retrieved by the large language model are the latest and tamper-proof versions.

[0039] Specifically, the regulatory knowledge base is deployed on an off-chain server. Operations personnel can add, modify, or delete legal provisions in the knowledge base without triggering the blockchain consensus process. After each addition, a hash operation is performed on the changed legal provision, generating a fixed-length hash value, which is then recorded on the blockchain along with the operation timestamp. During subsequent legal provision retrieval in S102, after retrieving a matching legal provision from the regulatory knowledge base, the retrieved content is hashed again. The result is compared with the hash value recorded on the blockchain. If they match, it indicates that the provision has not been tampered with since being stored in the knowledge base. Simultaneously, comparing the timestamp confirms whether the currently retrieved version is the latest. Through this method, the legal provision content of the regulatory knowledge base remains synchronized with the hash anchor record on the blockchain, ensuring the authenticity and timeliness of the retrieval results.

[0040] S103. The regulatory rule package is transmitted to each level of regulatory node along with the cross-chain message.

[0041] Cross-chain messages refer to data packets transmitted between different blockchains. These data packets contain both the payload data of the transaction itself and the structured regulatory rule package generated in this embodiment. Regulatory nodes at each level refer to the various regulatory enforcement points that pass sequentially along the cross-chain transaction path. These regulatory nodes can be deployed on the source chain, the target chain, and intermediate relay chains or cross-chain bridges. Each regulatory node independently verifies the transaction according to the local regulatory policy of its jurisdiction.

[0042] By transmitting the regulatory rules package along with the cross-chain message, it is ensured that each regulatory node can obtain the regulatory rules customized for the transaction throughout the entire process from transaction initiation to transaction completion, thereby achieving consistent execution of regulatory strategies throughout the entire transaction chain.

[0043] In one implementation of this application, before transmitting the regulatory rule package along with cross-chain messages to regulatory nodes at each level, zero-knowledge proof is used to encrypt the regulatory rule package, ensuring that its content is not directly exposed during transmission. Zero-knowledge proof is a cryptographic protocol in which the prover can prove a proposition to the verifier as true without revealing the specific information related to that proposition. In this application embodiment, after generating the structured regulatory rule package and before encapsulating it into a cross-chain message, zero-knowledge proof technology is used to process the rule package. Using the entire content of the regulatory rule package as input, a zero-knowledge proof is generated. This proof demonstrates to the verifier that the generation process of the regulatory rule package conforms to a preset rule synthesis logic, and that the compliance requirements contained in the rule package originate from valid legal provisions in the regulatory knowledge base. Simultaneously, the regulatory rule package itself is encrypted, ensuring that its content exists in ciphertext during cross-chain transmission and is not directly read by intermediate nodes. Upon receiving a cross-chain message, each level of regulatory node first verifies the attached zero-knowledge proof. Only after confirming the proof's validity will it decrypt the encrypted regulatory rule package and execute subsequent S104 semantic conflict detection reasoning. If the zero-knowledge proof verification fails, it indicates that the regulatory rule package may have an unknown source or be tampered with, and the regulatory node will directly refuse to process the transaction.

[0044] This step achieves secure transfer of regulatory rules in heterogeneous blockchain networks by transmitting the regulatory rule package along with cross-chain messages and using zero-knowledge proofs for privacy protection, thus avoiding the risk of unauthorized nodes obtaining or tampering with the rule content during transmission.

[0045] S104. At each regulatory node, a large language model is used to compare whether the regulatory rule package and the node's local regulatory strategy are consistent at the semantic level, and to identify whether there is logical mutual exclusion.

[0046] Upon receiving a cross-chain message, each regulatory node first verifies the completeness and authenticity of the attached regulatory rule package. Then, it compares the compliance requirements within the regulatory rule package with the local regulatory policies of its jurisdiction. Local regulatory policies refer to the legal regulations established in the regulatory jurisdiction where the node is located; these regulations are also pre-entered into the node's local system in the form of natural language text.

[0047] Logical mutual exclusion refers to a situation where a compliance requirement in a regulatory rule package and a compliance requirement in a local regulatory strategy cannot be logically satisfied simultaneously. For example, a regulatory rule package may require data to be anonymized before transmission to protect personal privacy, while a local regulatory strategy may require the recipient to verify the personal identification information associated with the transaction in plaintext to perform anti-money laundering checks. These two requirements are logically in direct conflict because once the data is anonymized, the recipient cannot perform plaintext verification.

[0048] In one implementation of this application, comparing whether the regulatory rule package and the node local regulatory strategy are consistent at the semantic level specifically includes: using a large language model to convert the rule text in the regulatory rule package and the rule text in the node local regulatory strategy into logical descriptive text respectively, calculating the similarity between the vectors corresponding to the logical descriptive text, and combining the step-by-step reasoning process of the large language model to determine whether there is logical mutual exclusion.

[0049] Logical descriptive text refers to transforming rules expressed in natural language into declarative or conditional sentences with a clear logical structure. For example, a privacy protection requirement might be transformed into a requirement that if data contains personally identifiable information, it must be anonymized before transmission, and the anonymization must be irreversible. Vector similarity calculations measure the semantic closeness between two rule texts. Higher similarity indicates greater semantic consistency between the two rules, while lower similarity indicates greater semantic differences and potential conflicts.

[0050] The stepwise reasoning process of a large language model refers to the process by which the large language model generates a series of intermediate reasoning steps before outputting a judgment result, demonstrating a complete reasoning chain from input to output. This method is called a thought chain. In conflict detection scenarios, the large language model is required to stepwise analyze the logical relationship between each requirement in the regulatory rule package and the corresponding clause in the local regulatory policy, determine one by one whether there is a possibility of simultaneous satisfaction, and finally draw a conclusion on whether there is logical mutual exclusion.

[0051] Continuing with the previous example, after the regulatory rule package reaches the regulatory node in jurisdiction B, the large language model compares the data anonymization requirements in the rule package with the local audit rules of jurisdiction B. The local audit rules of jurisdiction B require the recipient to verify the identity field in the data in plaintext upon receiving transaction data containing personally identifiable information to complete the compliance audit. The large language model converts the two rule texts into logical descriptive texts and calculates their similarity in the semantic vector space, finding a low similarity and semantic discrepancy. Subsequently, through step-by-step reasoning, it concludes that the anonymization requirements of the regulatory rule package and the local plaintext verification requirements cannot be simultaneously satisfied, indicating a logical mutual exclusion.

[0052] This step utilizes the semantic understanding and stepwise reasoning capabilities of a large language model to automate the detection of cross-jurisdictional regulatory rule conflicts, thus solving the technical problem that traditional keyword matching schemes cannot identify deep semantic contradictions.

[0053] S105. If the logical mutual exclusion is detected, an arbitration instruction is generated using a large language model according to the preset legal validity priority rule, and the on-chain smart contract control interface is called to perform compliance intervention according to the arbitration instruction. At the same time, the entire process log is uploaded to the chain for evidence storage.

[0054] The rule of legal priority refers to a pre-configured rule used to determine which legal norms from different regulatory jurisdictions take precedence in the event of a conflict. When a package of regulatory rules conflicts with local regulatory strategies, the pre-defined rule of legal priority is needed to determine which party's claim prevails.

[0055] In one implementation of this application, the arbitration instruction is at least one of the following: a transaction blocking instruction, used to forcibly suspend cross-chain transactions; a compliance correction instruction, used to require the transaction initiator to supplement compliance proof information; and a downgrade execution instruction, used to allow the transaction to continue execution under the condition of restricting some business functions.

[0056] Specifically, a transaction blocking instruction is a command generated by the large language model to terminate transaction execution when it determines that there is an irreconcilable logical mutual exclusion between the regulatory rule package and the local regulatory strategy, and there is no compliance remedy path. This instruction calls the on-chain smart contract's freeze interface, changing the current transaction status to blocked, and all subsequent cross-chain messages associated with this transaction are discarded or rejected. A compliance correction instruction is a command generated by the large language model to request additional compliance materials from the transaction initiator when it identifies a conflict but believes it can be resolved by supplementing information. This command calls the smart contract's notification interface to return specific supplementary material requirements to the initiator. Once the initiator submits the required materials, the transaction can continue. A downgrade execution instruction is a command generated by the large language model when it determines that the conflict only involves a part of the transaction's functionality and does not affect overall compliance. This command allows the transaction to continue execution under certain restricted conditions, such as limiting the transaction amount, shortening the data retention period, or adding intermediate audit nodes. This command calls the smart contract's configuration interface to adjust the transaction's execution parameters accordingly, allowing the transaction to be completed within the compliance framework.

[0057] A smart contract control interface refers to the external call portal provided by a smart contract deployed on a blockchain. External entities can trigger the smart contract to execute specific operations by calling this interface. Compliance intervention refers to the proactive adjustment of a transaction's status based on arbitration instructions, including but not limited to suspending transaction execution, modifying transaction parameters, requesting supplementary supporting documentation, or terminating the transaction process.

[0058] Continuing with the previous example, after the regulatory node in jurisdiction B detects a logical conflict between the anonymization requirement of the regulatory rule package and the local plaintext verification requirement, the large language model reasones based on the preset rule of legal priority and determines that the local audit rule has priority in application within jurisdiction B. The large language model generates an arbitration suggestion, arguing that privacy protection can be achieved using zero-knowledge proofs, provided the local plaintext verification requirement is met. Specifically, the initiator anonymizes the data at the source and simultaneously generates a zero-knowledge proof to demonstrate the authenticity of the original data to the auditor in jurisdiction B, without directly exposing their original identity information. Based on this arbitration suggestion, a compliance correction instruction is generated, invoking the on-chain smart contract control interface to require the transaction initiator to supplement the zero-knowledge proof materials before the transaction can continue.

[0059] In one implementation of this application, the regulatory knowledge base supports the addition of new legal provisions off-chain at any time. Each addition generates a hash value for the corresponding content and records it on the blockchain. This hash value is used to verify the completeness and version update time of the legal provisions during retrieval, ensuring that the legal provisions retrieved by the large language model are the latest and unaltered versions. Off-chain addition refers to the operator adding, modifying, or deleting legal provisions in the regulatory knowledge base without triggering the blockchain consensus process. After each addition operation, the hash value of the modified provision is calculated and recorded on the blockchain along with a timestamp. In subsequent retrieval processes, the hash value of the retrieved legal provision is first calculated and compared with the hash value recorded on the blockchain. If they match, it indicates that the provision has not been tampered with since being stored in the knowledge base. Simultaneously, the timestamp confirms the version update time of the provision.

[0060] This step, through a legally binding arbitration mechanism and automated smart contract execution, enables real-time handling of regulatory conflicts, resolving the technical issue of lacking closed-loop dynamism in traditional regulatory enforcement. Simultaneously, the on-chain storage of the entire process log provides an immutable chain of evidence for subsequent compliance audits and dispute resolution.

[0061] In the entire process of this application embodiment, from semantic feature vector extraction, structured regulatory rule package generation, cross-chain message passing, semantic conflict detection, and arbitration instruction execution, each step is interconnected. The output of the previous step serves as the input of the next step, together forming a complete dynamic regulatory closed loop. Cross-chain transactions are included in the regulatory scope from the moment they are initiated. During the flow, each regulatory node continuously performs compliance verification, intervenes immediately when compliance risks arise, and the entire process log is available for auditing and traceability after the transaction is completed, realizing full lifecycle supervision including pre-regulation, in-process intervention, and post-audit.

[0062] The technical solution provided in this application, by introducing the semantic understanding and logical reasoning capabilities of a large language model, effectively solves key technical problems in existing cross-chain regulatory schemes, such as the inability of statically pre-set rules to adapt to dynamic changes in regulations, the difficulty in automatically identifying semantic-level rule conflicts, and the lack of real-time intervention capabilities in regulatory execution. This significantly improves the compliance efficiency and security of cross-chain transactions.

[0063] The above are some specific implementations of a method for dynamic adaptation of cross-chain regulatory rules based on a large model provided in the embodiments of this application. Based on this, this application also provides a corresponding device. The device provided in the embodiments of this application will be described below from the perspective of functional modularization.

[0064] Figure 2 This is a schematic diagram of a cross-chain regulatory rule dynamic adaptation device based on a large model, provided as an embodiment of this application. (Combined with...) Figure 2 As shown in the embodiment of this application, the cross-chain regulatory rule dynamic adaptation device 200 based on a large model includes: The semantic feature extraction module 210 is used to extract the original request data of cross-border and cross-chain transactions and extract semantic feature vectors from the original request data. The semantic feature vectors include at least the transaction location label, asset type and business logic description. The rule package generation module 220 is used to generate a structured regulatory rule package for the current transaction by using a large language model based on retrieval enhancement generation technology, retrieving relevant legal provisions in the regulatory knowledge base according to the semantic feature vector; The rule package delivery module 230 is used to deliver the regulatory rule package along with cross-chain messages to regulatory nodes at all levels. The semantic conflict detection module 240 is deployed at each regulatory node and is used to compare the regulatory rule package with the node's local regulatory strategy at the semantic level using a large language model to identify whether there is logical mutual exclusion. Arbitration execution module 250 is used to generate an arbitration instruction based on a preset legal validity priority rule using a large language model when the logical mutual exclusion is detected, and to call the on-chain smart contract control interface to perform compliance intervention according to the arbitration instruction, while simultaneously storing the entire process log on the chain for evidence.

[0065] In one implementation of this application, the semantic feature vector extracted by the semantic feature extraction module further includes participant identity information, and the business logic description includes transaction purpose description text and business operation type label.

[0066] In one implementation of this application, the structured regulatory rule package generated by the rule package generation module is encapsulated in JSON or XML format, and the structured regulatory rule package includes authentication logic, data processing constraint rules, and compliance triggering conditions.

[0067] In one implementation of this application, the semantic conflict detection module uses a large language model to compare whether the regulatory rule package and the node's local regulatory strategy are semantically consistent, specifically including: The rule text in the regulatory rule package and the rule text in the node local regulatory strategy are converted into logical descriptive text using a large language model. The similarity between the vectors corresponding to the logical descriptive text is calculated, and the existence of logical mutual exclusion is determined by combining the stepwise reasoning process of the large language model.

[0068] In one implementation of this application, the regulatory knowledge base supports the addition of new legal provisions off-chain at any time. After each addition, a hash value of the corresponding content is generated and recorded on the blockchain. This hash value is used to verify the integrity and version update time of the legal provisions during retrieval, ensuring that the legal provisions retrieved by the large language model are the latest and unaltered versions.

[0069] In one implementation of this application, the apparatus further includes: The rule package encapsulation module is used to encrypt the regulatory rule package with zero-knowledge proof before the rule package transmission module transmits the regulatory rule package to each level of regulatory nodes along with cross-chain messages, so that the specific content of the regulatory rule package is not directly exposed during transmission. Before the semantic conflict detection module compares the regulatory rule package with the node's local regulatory strategy at the semantic level using a large language model, each regulatory node first verifies the zero-knowledge proof and only performs subsequent reasoning after the verification is successful.

[0070] In one implementation of this application, the arbitration instruction generated by the arbitration execution module is at least one of the following: Transaction blocking instructions are used to forcibly terminate cross-chain transactions; A compliance correction order is used to require the transaction initiator to provide supplementary compliance documentation. Degradation execution instructions are used to allow transactions to continue executing while restricting certain business functions.

[0071] This application also provides corresponding devices and computer storage media for implementing the solutions provided in this application.

[0072] The device includes a memory and a processor. The memory stores instructions or code, and the processor executes the instructions or code to cause the device to perform the method described in any embodiment of this application.

[0073] The computer storage medium stores code, and when the code is run, the device running the code implements the method described in any embodiment of this application.

[0074] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that all or part of the steps in the methods of the above embodiments can be implemented by means of software plus a general-purpose hardware platform. Based on this understanding, the technical solution of this application can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as a read-only memory (ROM) / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, a server, or a network communication device such as a router) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0075] It is understood that in the specific embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved need to obtain user permission or consent when the above embodiments of this application are applied to specific products or technologies, and the collection, use and processing of related data need to comply with the relevant laws, regulations and standards of relevant countries and regions.

[0076] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0077] It should also be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and apparatus embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and apparatus embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0078] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for dynamic adaptation of cross-chain regulatory rules based on a large model, characterized in that, The method includes: Extract the original request data of cross-border and cross-chain transactions, and extract semantic feature vectors from the original request data. The semantic feature vectors include at least the transaction location tag, asset type and business logic description. Using a large language model based on retrieval enhancement generation technology, relevant legal provisions are retrieved from the regulatory knowledge base according to the semantic feature vector to generate a structured regulatory rule package for the current transaction; The regulatory rules package is transmitted to regulatory nodes at all levels along with cross-chain messages; At each regulatory node, a large language model is used to compare whether the regulatory rule package is semantically consistent with the node's local regulatory strategy, and to identify whether there is logical mutual exclusion. If the aforementioned logical mutual exclusion is detected, an arbitration instruction is generated using a large language model based on preset legal validity priority rules. The on-chain smart contract control interface is then invoked according to the arbitration instruction to perform compliance intervention, and the entire process log is recorded on the blockchain for evidence preservation.

2. The method according to claim 1, characterized in that, The semantic feature vector also includes participant identity information, and the business logic description includes a text explaining the purpose of the transaction and a business operation type label.

3. The method according to claim 1, characterized in that, The structured regulatory rule package is encapsulated in JSON or XML format and includes authentication logic, data processing constraint rules, and compliance triggering conditions.

4. The method according to claim 1, characterized in that, The comparison of whether the regulatory rule package and the node's local regulatory strategy are semantically consistent includes: The rule text in the regulatory rule package and the rule text in the node local regulatory strategy are converted into logical descriptive text using a large language model. The similarity between the vectors corresponding to the logical descriptive text is calculated, and the existence of logical mutual exclusion is determined by combining the stepwise reasoning process of the large language model.

5. The method according to claim 1, characterized in that, The method further includes: The regulatory knowledge base supports the addition of new legal provisions off-chain at any time. Each addition generates a hash value of the corresponding content and records it on the blockchain. This hash value is used to verify the completeness and version update time of the legal provisions during retrieval, ensuring that the legal provisions retrieved by the large language model are the latest and tamper-proof versions.

6. The method according to claim 1, characterized in that, The method further includes: Before transmitting the regulatory rule package to regulatory nodes at all levels along with cross-chain messages, the regulatory rule package is encrypted using zero-knowledge proofs so that the specific content of the regulatory rule package is not directly exposed during transmission. Before comparing the regulatory rule package with the node's local regulatory strategy at the semantic level using a large language model at each regulatory node, each regulatory node first verifies the zero-knowledge proof, and only performs subsequent reasoning after the verification is successful.

7. The method according to claim 1, characterized in that, The arbitration order is at least one of the following: Transaction blocking instructions are used to forcibly terminate cross-chain transactions; A compliance correction order is used to require the transaction initiator to provide supplementary compliance documentation. Degradation execution instructions are used to allow transactions to continue executing while restricting certain business functions.

8. A dynamic adaptation device for cross-chain regulatory rules based on a large model, characterized in that, The device includes: The semantic feature extraction module is used to extract the original request data of cross-border and cross-chain transactions, and extract semantic feature vectors from the original request data. The semantic feature vectors include at least the transaction location label, asset type and business logic description. The rule package generation module is used to utilize a large language model based on retrieval enhancement generation technology to retrieve relevant legal provisions in the regulatory knowledge base according to the semantic feature vector, and generate a structured regulatory rule package for the current transaction. The rule package delivery module is used to deliver the regulatory rule package to regulatory nodes at all levels along with cross-chain messages; The semantic conflict detection module is deployed at each regulatory node and is used to compare the regulatory rule package with the node's local regulatory strategy at the semantic level using a large language model to identify whether there is logical mutual exclusion. The arbitration execution module is used to generate an arbitration instruction based on a preset legal validity priority rule using a large language model when the logical mutual exclusion is detected, and to call the on-chain smart contract control interface to perform compliance intervention according to the arbitration instruction, while storing the entire process log on the chain for evidence.

9. A computing device, characterized in that, The computing device includes: a memory and a processor; The memory is used to store computer programs; The processor is configured to implement the steps of the method as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 7.