A method and system for cross-chain trusted interaction and permission coordination and management of digital assets

Abstract

The application discloses a kind of digital asset cross-chain trusted interaction and permission coordination management method and system, it can be applied to the scene of digital asset cross-chain circulation in scenic spot, the method of this scheme generates cross-chain digital asset main identification, and then constructs permission vector, permission state machine and permission conflict matrix, obtains scenic off-chain event and generates dynamic state trigger instruction by multilayered oracle;Further, the corresponding permission is locked using the source chain and a state commitment is generated, a cross-chain trusted interaction voucher is generated by a cross-chain collaborative node, and a mapping permission voucher is generated after verification by the target chain and an interaction operation is performed;Then, the interaction results are batch aggregated, verified and integrated by the settlement node, and the permission changes, settlement results and audit summaries are written back to the related chain.This scheme can improve the credibility of digital asset cross-chain rights and interests mutual recognition, permission management and settlement audit.

Description

Technical Field

[0001] This invention relates to the field of digital asset management technology, and in particular to a method and system for cross-chain trusted interaction and permission collaborative control of digital assets. Background Technology

[0002] Digital assets are data objects that exist in digital form and possess certain economic, use, or equity value. In cultural tourism scenarios, digital collectibles, digital tickets, membership benefits, points benefits, visit experience certificates, and digital cultural and creative authorization certificates can all be used for ownership verification, transfer, and management through blockchain technology. With the development of digital collectibles, dynamic NFTs, and cultural tourism digital asset trading platforms, digital assets are no longer limited to static display within a single platform, but are gradually developing towards cross-scenic area, cross-platform, and cross-chain network mutual recognition of rights, transaction flow, and integrated settlement.

[0003] In existing technologies, some solutions use blockchain to record digital asset hashes, ownership certificates, NFT numbers, or transaction records to improve the credibility of digital asset ownership confirmation and traceability; others manage the registration, transfer, and traceability of digital assets through distributed digital identities, watermarks, or ownership verification certificates; still others propose improvements for on-chain and off-chain notarization of digital collectibles, batch minting, or on-chain trading of scenic spot tickets. These solutions can, to some extent, address the issues of single-chain ownership confirmation, single-platform trading, tamper-proof notarization, and ownership tracking of digital assets.

[0004] However, in scenarios involving cross-chain transfer of digital assets and cross-platform mutual recognition of rights in scenic areas, existing technologies still have the following shortcomings: (1) The asset identifiers, NFT standards, metadata formats and contract interfaces of heterogeneous chains are not uniform. The numbering, status and rights content of digital assets of the same scenic spot on different chains are difficult to form a consistent expression, which makes it difficult for the target chain to accurately identify the real rights status of the source chain assets.

[0005] (2) Existing cross-chain solutions mostly focus on asset ontology transfer or token mapping, and rarely conduct refined decomposition and coordinated management of the multiple types of rights contained in digital assets. When digital assets contain multiple rights such as display rights, write-off rights, usage rights, transfer rights, and revenue distribution rights, simple ownership transfer cannot determine whether a certain right has been occupied, frozen, written off, or revoked in other chains or other scenic areas, which can easily lead to duplicate authorization, duplicate write-off, and conflict of rights.

[0006] (3) Existing solutions lack sufficient linkage between off-chain events and on-chain states in scenic areas. The rights and interests of digital assets in scenic areas are often related to real-world events such as visitor entry, activity participation, ticket redemption, consumption payment, and points changes. However, the existing single on-chain evidence storage method is difficult to capture off-chain events in a timely and reliable manner and drive changes in the state of digital assets.

[0007] (4) Existing cross-chain transactions struggle to balance security, efficiency, and atomicity. Reliance on relay chains increases trust costs, atomic swaps are less efficient, and ordinary cross-chain bridge solutions may result in asset locking, unrevoked authorization on the target chain, or inconsistent settlement records when some transactions fail.

[0008] (5) Existing digital asset transaction settlement is usually processed on a per-transaction basis, which is difficult to adapt to the needs of high-frequency, small-amount, multi-entity rights verification, points redemption, cross-scenic area discounts and revenue sharing in scenic area scenarios. This results in high settlement costs, complex audit links, and difficulty for regulatory nodes to keep track of cross-chain circulation status in a timely manner.

[0009] Therefore, it is necessary to propose a method and system for trusted cross-chain interaction and permission coordination of digital assets. By unifying cross-chain asset identifiers, permission vectors, permission state machines, trusted cross-chain interaction credentials, multi-source oracle verification, hierarchical settlement and / or anomaly rollback mechanisms, the system can realize trusted interaction, permission coordination, mutual recognition of rights and interests, integrated settlement and / or auditable supervision of scenic area digital assets in a multi-chain environment. Summary of the Invention

[0010] In view of this, the purpose of this invention is to propose a method and system for trusted cross-chain interaction and permission collaborative management of digital assets, which aims to realize trusted interaction, permission collaboration, mutual recognition of rights and interests, integrated settlement and / or auditable supervision of digital assets in scenic areas in a multi-chain environment.

[0011] To achieve the above-mentioned technical objectives, the technical solution adopted by this invention is as follows: A method for trusted cross-chain interaction and permission coordination management of digital assets, applied to a digital asset management system including a source chain, a target chain, cross-chain collaboration nodes, oracle nodes, and settlement nodes, comprising: S1. Receive a cross-chain interaction request for the scenic area's digital assets. The cross-chain interaction request includes the original asset data of the digital asset to be interacted with, source chain information, target chain information, requesting entity identity information, target operation type, expected interaction permissions, and settlement rules. Then, generate a cross-chain digital asset master identifier based on the cross-chain interaction request. S2. Based on the target operation type and settlement rules, and in conjunction with the scenic area business rules, construct a permission vector and its corresponding permission state machine for the digital asset to be interacted with; S3. Obtain scenic area off-chain event data related to the digital asset to be interacted with through the oracle node, and preprocess and calculate the event credibility to obtain dynamic state triggering instructions; S4. The source chain performs locking processing on the permission item corresponding to the expected interaction permission in the digital asset to be interacted based on the cross-chain digital asset master identifier, permission vector, permission state machine and dynamic state triggering instruction, and generates source chain state commitment. S5. The cross-chain collaborative node generates a cross-chain trusted interaction certificate based on the source chain state commitment, the cross-chain digital asset master identifier, the permission vector, the target chain information, the settlement rules and / or the identity information of the requesting entity. S6. The target chain verifies the cross-chain trusted interaction certificate, and after the verification is successful, generates a target chain mapping permission certificate corresponding to the expected interaction permission, and writes the target chain mapping permission certificate into the target chain permission collaboration ledger. S7. The target chain performs the digital asset interaction operation corresponding to the target operation type based on the target chain mapping permission certificate, and generates an interaction result certificate; S8. The settlement node performs batch aggregation of multiple interaction result proofs within the same settlement period, generates transaction batch, batch Merkle root, aggregate signature and settlement details, and completes fusion settlement according to the settlement rules. S9. Write back the fusion settlement result, permission status change result and audit summary to the source chain and the target chain. When a permission conflict, verification failure, lock timeout or settlement abnormality is detected, execute permission release, mapping permission revocation and / or abnormal audit record generation according to the timeout rollback parameters.

[0012] As one possible implementation, further, in step S1 of this scheme, the cross-chain interaction request also includes a request random number, a validity period, and a request subject signature.

[0013] As a possible implementation, further, in step S1 of this solution, a cross-chain digital asset master identifier is generated based on the source chain information and the asset content fingerprint, source chain contract address, source chain asset number, metadata summary and / or dynamic status version number corresponding to the digital asset to be interacted with.

[0014] As a preferred implementation scheme, the source chain information in this scheme preferably includes the source chain identifier; the cross-chain interaction request also includes the asset business identifier corresponding to the digital asset to be interacted with, that is, the internal asset number of the digital asset to be interacted with in the scenic area's digital assets.

[0015] As a preferred implementation scheme, the cross-chain digital asset master identifier described in this scheme is obtained by hash calculation of the asset business identifier, source chain identifier, source chain contract address, source chain asset number, asset content fingerprint, metadata digest and / or dynamic status version number, and serves as a unified index for source chain permission locking, target chain mapping authorization, fusion settlement and / or audit trail.

[0016] As a preferred implementation scheme, preferably, in step S2 of this scheme, the permission vector is used to represent at least a number of permission states among holding rights, display rights, rights cancellation rights, limited use rights, transfer rights, time-sharing use rights, revenue distribution rights, settlement triggering rights and revocation rights.

[0017] As a preferred implementation scheme, preferably, in step S2 of this scheme, the permission state machine includes at least the following states: inactive state, interactive state, locked state, target chain pending authorization state, target chain authorized state, rights cancelled state, settlement pending confirmation state, settled state, abnormal freeze state, and / or rollback completed state. Each permission state change must satisfy a preset legal state transition path.

[0018] As a preferred implementation scheme, step S2 of this scheme preferably further includes: A permission conflict matrix is ​​constructed to determine the occupancy relationship of multiple permission items under the same cross-chain digital asset master identifier in different chains, different scenic spots and different platforms. When it is detected that the same right cancellation right is repeatedly activated, the time-sharing right and the transfer right overlap in time, or the target chain authorization request still exists after the revocation right is triggered, the corresponding permission status change is blocked.

[0019] As a preferred implementation scheme, in step S3 of this scheme, the scenic area off-chain event data related to the digital asset to be interacted with is obtained through the oracle node, and the scenic area off-chain event data is formatted, time-aligned, multi-source consistency verified and event credibility calculated to obtain dynamic state triggering instructions.

[0020] As a preferred implementation scheme, the off-chain event data of the scenic area in this scheme preferably includes: ticket verification data, POS payment data, visitor entry data, visitor behavior data, scenic area activity participation data, IoT device collection data and / or member point change data; the credibility of the event is calculated based on the data source credibility weight, time consistency, spatial consistency, signature validity and / or multi-source matching degree.

[0021] As a preferred implementation scheme, preferably, in step S5 of this scheme, the cross-chain trusted interaction certificate includes source chain state commitment, permission policy summary, zero-knowledge verification result, threshold signature result and / or timeout rollback parameters; The zero-knowledge verification result is used to prove that the requesting subject is qualified to invoke the expected interaction permission, that the permission item corresponding to the source chain state commitment has been locked, that the target operation type conforms to the permission policy summary, and that the complete identity information of the requesting subject and the source chain transaction details are not disclosed to the target chain.

[0022] As a preferred implementation scheme, in step S6 of this scheme, the target chain mapping permission certificate does not change the ownership status of the source chain digital assets, but only records the authorized permission items, validity period, applicable scenic spots, executable operations, settlement rule summary and permission version number in the target chain.

[0023] As a preferred implementation scheme, preferably, in step S8 of this scheme, the fusion settlement includes: Prove the generation of batch Merkle roots based on multiple interaction results in the transaction batch; Aggregate the signatures of scenic spot nodes, platform nodes, and / or content rights nodes participating in the settlement; The settlement share corresponding to the scenic area, content creator, operating platform, promotion node and / or regulatory record account is calculated according to the settlement rules. Write the settlement share summary and batch Merkle root into the source chain and the target chain.

[0024] As a preferred implementation scheme, in step S9 of this scheme, the anomaly audit record includes: cross-chain digital asset master identifier, anomaly type, anomaly occurrence chain, anomaly occurrence time, permission version number, executed permission status, rollback processing result, relevant node signature and / or audit summary.

[0025] In addition, when generating abnormal audit records, abnormal alerts are also sent to the scenic area's operation and supervision nodes.

[0026] Based on the above, this solution also proposes a cross-chain trusted interaction and permission collaborative management system for digital assets, which includes: The interactive access module is used to receive digital assets of scenic spots and their cross-chain interaction requests; The identifier generation module is used to generate a cross-chain digital asset master identifier based on the asset content fingerprint, source chain information, metadata digest, and dynamic status version number. The permission configuration module is used to build permission vectors, permission state machines, and permission conflict matrices. The multi-level oracle module is used to collect and verify off-chain event data of scenic spots and generate dynamic state triggering instructions; The source chain permissions module is used to lock the expected interaction permissions of the digital assets to be interacted with and generate source chain state commitments. The credential generation module is used to generate cross-chain trusted interaction credentials that include source chain state commitment, permission policy summary, zero-knowledge verification result, threshold signature result, and timeout rollback parameters. The mapping management module is used to verify cross-chain trusted interaction credentials and generate target chain mapping permission credentials; The integrated settlement module is used to batch summarize, aggregate, verify, and settle accounts for the verification results of interactions. The audit and oversight module is used to record permission status changes, cross-chain interaction results, fusion settlement results, and anomaly handling results.

[0027] By adopting the above technical solution, the present invention has the following beneficial effects compared with the prior art: The present invention uses a cross-chain digital asset master identifier to uniformly encode information such as source chain information, asset content fingerprint, source chain contract address, source chain asset number, metadata summary and dynamic status version number, so that digital assets of the same scenic spot can form a consistent identification basis between heterogeneous chains, and solve the problem of asset interoperability caused by the inconsistency of NFT standards, asset numbers and metadata structures of different chains.

[0028] The present invention also uses permission vectors, permission state machines, and permission conflict matrices to finely decompose the rights of holding, display, rights cancellation, limited use, transfer, time-sharing use, revenue distribution, settlement triggering, and revocation of digital assets. This makes the cross-chain interaction process no longer limited to the transfer of asset ownership, but can authorize, lock, occupy, cancel, revoke, and roll back specific rights, thereby reducing the risks of duplicate authorization, duplicate cancellation, and cross-chain rights conflicts.

[0029] In addition, the present invention also collects and verifies off-chain event data such as scenic spot ticketing, POS, IoT, tourist behavior and activity participation through multi-level oracles, and generates dynamic state triggering instructions, so that the on-chain permission status of digital assets can change synchronously with real scenic spot business events, thereby improving the credibility of the status update of dynamic NFTs and scenic spot equity assets.

[0030] To improve the privacy, trustworthiness, and efficiency of information interaction, this invention combines source chain state commitment, permission policy summary, zero-knowledge verification result, threshold signature result, and timeout rollback parameters into a single cross-chain trusted interaction certificate. This allows the target chain to verify the requesting entity's authorization and source chain asset status without obtaining complete identity information and complete source chain transaction details, thus balancing the trustworthiness, privacy, and execution efficiency of cross-chain interaction. Furthermore, this invention employs a layered settlement and aggregated verification mechanism to batch summarize, aggregate signatures, and merge settlements multiple interaction result proofs within the same settlement cycle. This is suitable for high-frequency, small-amount, multi-entity scenarios in scenic areas such as rights verification, points redemption, mutual recognition of discounts, and revenue sharing, which helps reduce on-chain settlement costs and improve settlement efficiency.

[0031] This invention also constructs a closed-loop cross-chain interaction mechanism through source chain permission locking, target chain mapping permission activation, interaction result write-back, and exception rollback. When target chain authorization fails, source chain lock times out, or settlement is abnormal, the system can automatically revoke the target chain mapping permission and release the source chain lock permission, reducing the risk of long-term asset lock-up or inconsistent permission status due to partial transaction failures.

[0032] In terms of business supervision, the present invention records the main identifier, permission version number, interaction results, settlement summary and anomaly handling results of cross-chain digital assets through the audit supervision module, so that the supervision node and scenic spot operation node can track the entire chain of cross-chain digital asset circulation, thereby improving the supervision and accountability of cross-chain digital asset business. Attached Figure Description

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

[0034] Figure 1 This is a simplified implementation flowchart of the digital asset cross-chain trusted interaction and permission collaborative management method in this solution; Figure 2 This is a schematic diagram of the internal unit modules of the digital asset management system involved in the cross-chain trusted interaction and permission collaborative management method of digital assets in this solution; Figure 3 This is a schematic diagram of the unit modules of the digital asset cross-chain trusted interaction and permission collaborative management system in this solution. Detailed Implementation

[0035] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be particularly noted that the following embodiments are for illustrative purposes only and do not limit the scope of the invention. Similarly, the following embodiments are only some, not all, embodiments of the present invention, and all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0036] Combination Figure 1 , Figure 2 As shown in the figure, this embodiment provides a method for trusted cross-chain interaction and permission coordination management of digital assets, applied to a digital asset management system including a source chain, a target chain, cross-chain coordination nodes, oracle nodes, and settlement nodes, comprising: S1. Receive a cross-chain interaction request for the scenic area's digital assets. The cross-chain interaction request includes the original asset data of the digital asset to be interacted with, source chain information, target chain information, requesting entity identity information, target operation type, expected interaction permissions, and settlement rules. Then, generate a cross-chain digital asset master identifier based on the cross-chain interaction request. S2. Based on the target operation type and settlement rules, and in conjunction with the scenic area business rules, construct a permission vector and its corresponding permission state machine for the digital asset to be interacted with; S3. Obtain scenic area off-chain event data related to the digital asset to be interacted with through the oracle node, and preprocess and calculate the event credibility to obtain dynamic state triggering instructions; S4. The source chain performs locking processing on the permission item corresponding to the expected interaction permission in the digital asset to be interacted based on the cross-chain digital asset master identifier, permission vector, permission state machine and dynamic state triggering instruction, and generates source chain state commitment. S5. The cross-chain collaborative node generates a cross-chain trusted interaction certificate based on the source chain state commitment, the cross-chain digital asset master identifier, the permission vector, the target chain information, the settlement rules and / or the identity information of the requesting entity. S6. The target chain verifies the cross-chain trusted interaction certificate, and after the verification is successful, generates a target chain mapping permission certificate corresponding to the expected interaction permission, and writes the target chain mapping permission certificate into the target chain permission collaboration ledger. S7. The target chain performs the digital asset interaction operation corresponding to the target operation type based on the target chain mapping permission certificate, and generates an interaction result certificate; S8. The settlement node performs batch aggregation of multiple interaction result proofs within the same settlement period, generates transaction batch, batch Merkle root, aggregate signature and settlement details, and completes fusion settlement according to the settlement rules. S9. Write back the fusion settlement result, permission status change result and audit summary to the source chain and the target chain. When a permission conflict, verification failure, lock timeout or settlement abnormality is detected, execute permission release, mapping permission revocation and / or abnormal audit record generation according to the timeout rollback parameters.

[0037] In cross-chain interaction scenarios of digital assets in scenic areas, the requested data usually comes from different scenic area platforms, digital collection platforms, ticketing platforms, membership points systems or third-party trading service platforms. Each platform expresses the asset number, user identity, operation type and settlement rules differently, which can easily lead to the inability of subsequent cross-chain verification to accurately identify the requesting subject, requesting object and request permissions.

[0038] Therefore, step S1 of this solution converts the original cross-chain interaction request into unified, verifiable, and traceable standardized request data, providing basic data for the subsequent generation of cross-chain digital asset master identifiers and permission vectors.

[0039] As one possible implementation, further, in step S1 of this scheme, the cross-chain interaction request also includes a request random number, a validity period, and a request subject signature.

[0040] As a possible implementation, further, in step S1 of this solution, a cross-chain digital asset master identifier is generated based on the source chain information and the asset content fingerprint, source chain contract address, source chain asset number, metadata summary and / or dynamic status version number corresponding to the digital asset to be interacted with.

[0041] As a preferred implementation scheme, the source chain information in this scheme preferably includes the source chain identifier; the cross-chain interaction request also includes the asset business identifier corresponding to the digital asset to be interacted with, that is, the internal asset number of the digital asset to be interacted with in the scenic area's digital assets.

[0042] As a preferred implementation scheme, the cross-chain digital asset master identifier described in this scheme is obtained by hash calculation of the asset business identifier, source chain identifier, source chain contract address, source chain asset number, asset content fingerprint, metadata digest and / or dynamic status version number, and serves as a unified index for source chain permission locking, target chain mapping authorization, fusion settlement and / or audit trail.

[0043] As an example of implementation, step S1 of this solution includes the following sub-steps: Upon receiving a cross-chain interaction request for digital assets of a scenic area, the request fields are first parsed. The cross-chain interaction request includes at least: the original data of the digital asset to be interacted with, source chain information (including the source chain identifier), target chain information (including the target chain identifier), the identity information of the requesting entity, the target operation type, the expected interaction permissions, settlement rules, valid time, a request random number, and the signature of the requesting entity.

[0044] Define the original request as:

[0045] in: This represents the original cross-chain interaction request; This represents the original asset data of the scenic area's digital assets to be interacted with; Indicates the source chain identifier; Indicates the target chain identifier; This indicates the wallet address or platform account address of the requesting entity; This indicates the identity credentials of the requesting entity; Indicates the type of target operation, such as display, cancellation, exchange, transfer, time-sharing authorization, or revenue sharing; This represents the set of permissions requested, i.e., the expected interaction permissions. Indicates the settlement rules; Indicates the validity period of the request; This indicates a request for a random number, used to prevent replay attacks; This represents the digital signature of the requesting entity for this request.

[0046] To ensure that the request data has not been tampered with, the system serializes the request content except for the signature field and calculates the request digest:

[0047] in: Indicates a request summary; Represents a hash function; This represents a standardized serialization function.

[0048] Then, the signature is verified based on the requester's public key. The function is defined as follows:

[0049] in: This indicates the verification result; a value of 1 indicates successful verification, and a value of 0 indicates failed verification. Indicates the public key of the requesting entity; This represents the signature verification function.

[0050] Under the reasoning logic of this formula, if the requesting subject does indeed use its private key to the request digest... If a signature is made, the system uses its public key. Able to check the signature result Perform verification; if the request content has been tampered with, recalculate the result. The verification failed because the digest did not match the one used for signing.

[0051] At the same time, the system determines whether the request is within the valid time period:

[0052] in: This indicates the result of the time validity assessment; Indicates the current time when the system received the request; Indicates the valid deadline for the request.

[0053] When satisfied and At that time, the system will convert the original request into a standardized cross-chain interaction request:

[0054] After the above sub-steps, the output is a standardization request. As data input for subsequent steps.

[0055] Among them: the original asset data of the digital assets of the scenic area to be interacted with. Used to extract asset content fingerprints; Source Chain Identifier Target chain identifier Used to identify the source chain and the target chain; Target operation type The set of permissions requested for invocation (Expected interaction permissions); Settlement rules Used to construct permission vectors, permission state machines, and settlement constraints; the requesting entity's wallet address or platform account address. Request subject identity certificate Used to generate cross-chain trusted interaction credentials; request digest Used to prove the original content of this cross-chain interaction request.

[0056] To address the issue of inconsistent asset identification across heterogeneous blockchains, this solution addresses the problem of different NFT standards, contract addresses, token numbers, and metadata structures used by different blockchain platforms. If only a token ID from a single chain is used as the asset identifier, the target chain cannot verify whether that token ID matches the source chain's asset, off-chain metadata, and dynamic state version. Therefore, step S1 of this solution also generates a cross-chain digital asset master identifier using asset content fingerprints, source chain information, metadata summaries, and state version numbers, providing a unified index for digital assets across multiple chains.

[0057] As an example of implementation, step S1 of this solution also includes the following sub-steps: First, the system treats interactive digital assets. Standardized asset data is obtained by performing normalization processing:

[0058] in: Represents standardized asset data; This represents an asset normalization function used to standardize file formats, character encodings, field naming, time formats, and metadata structures.

[0059] If the digital assets include text, images, videos, 3D models, or ticketing rights data, then corresponding feature summaries are extracted respectively. The asset content fingerprint can be defined as:

[0060] in: Represents the fingerprint of asset content; Indicates text content features; Indicates image content features; Indicates the characteristics of video content; Represents the content features of a 3D model; This indicates the characteristics of rights-based data such as ticketing, points, and membership benefits; Represents a hash function; This indicates field concatenation.

[0061] Under the reasoning logic of this formula, a single-modal hash can only reflect a single content type, making it difficult to cover the multimodal attributes of scenic area digital assets. Therefore, hashes are first calculated for each type of feature separately, and then multiple hash values ​​are concatenated and subjected to a second hash, so that the final asset content fingerprint can simultaneously reflect the consistency of multimodal content.

[0062] Next, the system extracts standardized metadata. And generate metadata digest:

[0063] in: Represents standardized metadata; Represents a metadata digest; This represents a hash function.

[0064] Then, a dynamic state version number is generated based on the current state of the source chain assets:

[0065] in: Indicates the source chain's dynamic state version number; Indicates the current asset status of the source chain; Indicates the time taken to read the status; This indicates the current block height or state root digest of the source chain.

[0066] Based on this, the system generates a cross-chain digital asset master identifier, which is defined as follows:

[0067] in: Indicates the main identifier of cross-chain digital assets; This indicates the internal asset number in the scenic area's business system. Indicates the source chain identifier; Indicates the source chain smart contract address; Indicates the source chain asset number; Represents the fingerprint of asset content; Represents a metadata digest; Indicates the dynamic status version number.

[0068] Under the reasoning logic of this formula, cross-chain asset identification cannot rely solely on the source chain's TokenID, nor solely on the asset file hash. If only the TokenID is relied upon, duplicate IDs may occur between different chains; if only the file hash is relied upon, it cannot reflect the equity status, contract location, and on-chain version. Therefore, the business identifier, chain identifier, contract address, Token number, asset content fingerprint, metadata digest, and state version number are all used as inputs to generate a unified identifier that reflects the asset content, on-chain location, and dynamic state—that is, the cross-chain digital asset master identifier.

[0069] Regarding the difficulty in precisely expressing the rights of digital assets, since scenic area digital assets may include not only ownership but also display rights, ticket redemption rights, membership rights, points redemption rights, time-sharing rights, and revenue distribution rights, etc., if cross-chain interactions only determine "whether the asset belongs to someone," it is impossible to determine whether a specific permission has been used, frozen, expired, or occupied on another chain. Therefore, step S2 of this solution decomposes digital asset rights into permission vectors and constrains the permission flow path through a permission state machine.

[0070] As a preferred implementation scheme, preferably, in step S2 of this scheme, the permission vector is used to represent at least a number of permission states among holding rights, display rights, rights cancellation rights, limited use rights, transfer rights, time-sharing use rights, revenue distribution rights, settlement triggering rights and revocation rights.

[0071] As a preferred implementation scheme, preferably, in step S2 of this scheme, the permission state machine includes at least the following states: inactive state, interactive state, locked state, target chain pending authorization state, target chain authorized state, rights cancelled state, settlement pending confirmation state, settled state, abnormal freeze state, and / or rollback completed state. Each permission state change must satisfy a preset legal state transition path.

[0072] As a preferred implementation scheme, step S2 of this scheme preferably further includes: A permission conflict matrix is ​​constructed to determine the occupancy relationship of multiple permission items under the same cross-chain digital asset master identifier in different chains, different scenic spots and different platforms. When it is detected that the same right cancellation right is repeatedly activated, the time-sharing right and the transfer right overlap in time, or the target chain authorization request still exists after the revocation right is triggered, the corresponding permission status change is blocked.

[0073] As an example of implementation, step S2 of this solution includes the following sub-steps: Based on the target operation type involved in the aforementioned steps Expected interaction permissions Settlement rules and cross-chain digital asset master identifier Construct a permission vector, which is defined as follows:

[0074] In this embodiment, as an example, the following function can be defined to represent the permission vector:

[0075] in: Indicates ownership; Indicates the right of display; Indicates the right to write off rights; This indicates a restriction on usage rights; Indicates the right of transfer; Indicates time-sharing usage rights; Indicates the right to share profits; Indicates the right to trigger settlement; This indicates the right of rescission.

[0076] Each permission item can be further represented as:

[0077] in: Indicates the first One permission item; Indicates whether the permission is active; the value is 0 or 1. Indicates the start time of the permission; Indicates the end time of the permission; This represents the set of chains or scenic areas to which the permissions apply; Indicates the remaining available credit limit or number of uses; This indicates the level of permissions that can be transferred. This indicates the permission version number.

[0078] Based on the target operation type The set of permissions that actually need to be invoked in this request is defined as follows:

[0079] in: This represents the set of permissions corresponding to the target operation type; A function representing the mapping between operation types and permission sets; This indicates the scenic area's business rules.

[0080] For example, when When performing "cross-scenic area rights verification", At least including and ;when When displaying digital collections, At least including ;when When it is "time-sharing licensed use", At least including and .

[0081] To determine whether the permissions meet the conditions for calling the target chain, the first step can be calculated. Availability of each permission item:

[0082] in: Indicates the first The availability of each permission item, with a value of 0 or 1; This indicates an indicator function that takes the value 1 if the condition is true and 0 otherwise. Indicates the current time; Indicates the target chain identifier; This indicates the amount or number of operations required for this transaction.

[0083] According to the reasoning logic of this formula, for a certain permission to be invoked by the target chain, four conditions must be met simultaneously: the permission is activated, the time has not expired, the target chain is within the permitted scope, and there is sufficient remaining quota. If any of these conditions are not met, the product result will be 0, indicating that the permission is unavailable.

[0084] Furthermore, this scheme also constructs a permission conflict matrix, which is defined as follows:

[0085] in: Represents the permission conflict matrix; Indicates the first The first permission item and the first Conflict relationships between permission items; when When indicates that the two permission items are mutually exclusive; when This indicates that the two permission items do not conflict.

[0086] The current activated permission status can be represented as a vector:

[0087] This permission request can be represented as:

[0088] Where: Definition Indicates the first This permission is currently occupied or activated; This indicates that this request requires calling the first... One permission.

[0089] The permission conflict value can then be calculated as follows:

[0090] in: Indicates a value indicating a permission conflict; This represents the transpose of the currently active permission vector.

[0091] Under the reasoning logic of this formula, if there is any mutual exclusion relationship between the currently activated permission and the permission requested this time, the matrix product result is greater than 0; if there is no conflict, the result is 0.

[0092] Therefore, when When this occurs, the system allows entry into the subsequent source chain locking process; when At that time, the system blocked the cross-chain interaction.

[0093] This solution also constructs a permission state machine, which is defined as follows:

[0094] in: Indicates the first Permission status before the next status change; Indicates the first Permission status after the next status change; This represents the permission state transition function; This indicates an event that triggers a state transition; This represents the set of permissions required for this operation; This represents the permission conflict matrix.

[0095] In this scheme, the permission status includes at least the following: inactive, interactive, locked, target chain pending authorization, target chain authorized, rights and interests cancelled, settlement pending confirmation, settled, abnormally frozen, and / or rollback completed.

[0096] To address the issue of unreliable off-chain event-driven changes in on-chain permission states in scenic areas, this solution addresses the problem that the status of digital assets in scenic areas often depends on real-world events such as visitor entry, ticket redemption, POS transactions, activity participation, device location tracking, and points changes. If on-chain contracts cannot reliably obtain these off-chain events, dynamic NFT status updates, rights redemption, and cross-scenic area mutual recognition lack credible triggering mechanisms. Therefore, step S3 of this solution utilizes a multi-level oracle to collect, clean, verify, and reach consensus on off-chain events.

[0097] As a preferred implementation scheme, in step S3 of this scheme, the scenic area off-chain event data related to the digital asset to be interacted with is obtained through the oracle node, and the scenic area off-chain event data is formatted, time-aligned, multi-source consistency verified and event credibility calculated to obtain dynamic state triggering instructions.

[0098] As a preferred implementation scheme, the off-chain event data of the scenic area in this scheme preferably includes: ticket verification data, POS payment data, visitor entry data, visitor behavior data, scenic area activity participation data, IoT device collection data and / or member point change data; the credibility of the event is calculated based on the data source credibility weight, time consistency, spatial consistency, signature validity and / or multi-source matching degree.

[0099] As an example of implementation, step S3 of this solution includes the following sub-steps: Oracle nodes collect data from multiple data sources and The relevant off-chain event data is defined as follows:

[0100] in: Represents the original set of off-chain events; definition Indicates the first One off-chain event; Indicates the number of event data.

[0101] Each off-chain event can be represented as:

[0102] in: Indicates the data source; Indicates the event type; Indicates the time when the event occurred; Indicates the location where the event occurred; Represents event business data; This indicates the signature of the data source.

[0103] First, the event data is formatted, deduplicated, and time-aligned to obtain a standardized event, which is defined as:

[0104] in: Represents the standardized event; This represents the data cleaning function.

[0105] Then calculate the time consistency of individual events:

[0106] in: Indicates the first Time consistency score for each event; Indicates the median time or reliable reference time for the same set of events; This represents the time decay coefficient.

[0107] Under the reasoning logic of this formula, the closer the event time is to the reference time of the multi-source data, the higher its reliability; the greater the deviation, the lower its reliability is through exponential decay.

[0108] The function for computational space consistency is defined as:

[0109] in: Indicates the first Spatial consistency score of each event; Indicates the distance between the event location and the reference location; Indicates the reference location for multi-source events; This represents the spatial attenuation coefficient.

[0110] The function for calculating signature validity is defined as:

[0111] in: This indicates the score for signature validity. This represents the public key of the data source.

[0112] The function for calculating multi-source matching degree is defined as:

[0113] in: Indicates the first The degree of match between an event and other events; This represents a function for calculating the similarity of event data. Indicates the first Individual event data.

[0114] Based on the above factors, the credibility of the event is as follows:

[0115] in: Indicates the overall credibility of the event; Indicates the first The credibility weight of each data source; These represent the weights for temporal consistency, spatial consistency, signature validity, and multi-source matching degree, respectively; they satisfy... .

[0116] Under the reasoning logic of this formula, the credibility of off-chain events should not be determined by a single indicator, but should comprehensively consider data source weight, temporal consistency, spatial consistency, signature validity, and multi-source matching degree. A weighted average method can achieve higher credibility for highly reliable data sources and multi-source consistent events.

[0117] As an example, when the following conditions are met: And the number of oracle consensus signatures satisfies: At that time, a dynamic state trigger instruction is generated, which is defined as:

[0118] in: Indicates the event credibility threshold; This indicates the number of oracle nodes that participated in the signing; Indicates the tolerable number of abnormal nodes; Indicates a dynamic state trigger command; Indicates the event type; Indicates a state change to be triggered; This indicates the new status version number. This is the version number of the previous source chain state; Indicates the time of credible confirmation of the event; This indicates the signature result of the oracle node.

[0119] To address the issues of double-spending, duplicate write-offs, and duplicate authorizations caused by unlocked source chain permissions during cross-chain interactions, this solution addresses the problem that if the source chain's digital assets remain available during the target chain's usage, the same stake may be simultaneously written off or authorized on multiple chains. Therefore, in step S4 of this solution, before activating the mapping permissions on the target chain, the source chain first locks the permissions to be interacted with and generates a source chain state commitment that can be verified by the target chain.

[0120] As an example of implementation, step S4 of this solution includes the following sub-steps: Based on the aforementioned output permission vector Request permission set Conflict judgment results and dynamic state triggering instructions Determine the set of permissions that need to be locked, defined as:

[0121] in: This represents the set of permissions to be locked. This indicates the set of permissions required for this operation; This represents the set of currently available permissions.

[0122] The currently available set of permissions can be determined by the following formula:

[0123] in: This represents the set of states that are allowed to enter the cross-chain locking process; Indicates the first Availability of each permission item; Indicates a value indicating a permission conflict; Indicates the current permission status.

[0124] Under this reasoning logic, access control must simultaneously satisfy three conditions: the access item itself must be available, it must not conflict with existing permissions, and its current state must be lockable. Only permissions that simultaneously meet these conditions can enter the lock set. .

[0125] The execution state transition of the source chain smart contract is defined as follows:

[0126] in: Indicates the permission status after locking; Indicates a locking action; This represents the state transition function.

[0127] The source chain generation lock version number is defined as follows:

[0128] in: Indicates the version number of the locked state; This is the source chain state version number.

[0129] Then, the source chain computes the locked permission set. The abstract is defined as follows:

[0130] in: Represents a summary of the set of locked permissions; Represents a hash function; This represents a standardized serialization function.

[0131] The source chain further generates state commitments:

[0132] in: Indicates a commitment to the source chain state; Indicates the current block height of the source chain; Indicates the root state of the source chain; Represents a summary of the set of locked permissions; Indicates the permission status after locking; This indicates that the version number is locked; Indicates the lock time; Indicates the lockout expiration time; This indicates the address of the source chain contract.

[0133] Finally, the source chain contract signs the state commitment, which is defined as follows:

[0134] in: Indicates the source chain signature; This represents the private key corresponding to the source chain contract or the source chain verification node.

[0135] Under the reasoning logic of this formula, the source chain state commitment needs to prove that a specific set of permissions for a digital asset has been locked at a certain block height and a certain state root. Therefore, writing the asset's master identifier, source chain identifier, block height, state root, locked permission digest, state version, lock time, and expiration time into the hash commitment can prevent subsequent tampering with the locked state.

[0136] To address the issue that the target chain cannot directly trust the source chain's state, the requesting entity's identity, and the scope of permissions, this solution addresses the problem that the target chain cannot directly read the source chain's internal state due to differences in contract systems, account systems, and state storage methods between different chains. Therefore, step S5 of this solution constructs a cross-chain trusted interaction credential, combining the source chain's lock state, permission policy, target chain's authorization scope, zero-knowledge verification result, threshold signature, and rollback parameters into a verifiable credential.

[0137] As a preferred implementation scheme, preferably, in step S5 of this scheme, the cross-chain trusted interaction certificate includes source chain state commitment, permission policy summary, zero-knowledge verification result, threshold signature result and / or timeout rollback parameters; The zero-knowledge verification result is used to prove that the requesting subject is qualified to invoke the expected interaction permission, that the permission item corresponding to the source chain state commitment has been locked, that the target operation type conforms to the permission policy summary, and that the complete identity information of the requesting subject and the source chain transaction details are not disclosed to the target chain.

[0138] As an example of implementation, step S5 of this solution includes the following sub-steps: Cross-chain collaboration nodes receive the source chain state commitment obtained in the aforementioned steps. Locking permission set Lock version number And combined with the identity of the requesting subject obtained in step S1 Target chain information Settlement rules Generate a summary of the permission policy:

[0139] in: This represents a summary of the access control policy. Represents the permission conflict matrix; Indicates the type of target operation; Indicates the settlement rules; Represents a hash function; This represents a standardized serialization function.

[0140] Under the reasoning logic of this formula, the permission policy summary needs to simultaneously constrain the asset object, locked permissions, permission conflict rules, target operation, target chain, and settlement rules. If any of these fields are tampered with, then... Changes will occur, and inconsistencies will be detected during target chain verification.

[0141] To protect the privacy of the requesting party, this scheme does not directly disclose complete identity credentials, but instead generates a zero-knowledge verification result. A public statement can be defined as:

[0142] Define privacy witnessing as:

[0143] in: This refers to public statements in zero-knowledge proofs; This represents privacy witnessing in zero-knowledge proofs; This indicates the identity credentials of the requesting entity; Indicates the private key of the requesting entity; This indicates that the requesting entity possesses or has the authority to invoke the permissions. This represents proof of the source chain state.

[0144] The zero-knowledge proof generation process is represented as follows:

[0145] The verification process is represented as follows:

[0146] in: This represents zero-knowledge proof; This represents the result of zero-knowledge verification. This indicates the proof generating function; This represents the proof verification function.

[0147] Under the reasoning logic of this formula, the prover uses privacy witnessing. Prove that it meets the public statement requirements The required conditions are that the target chain has the corresponding permissions, the source chain permissions are locked, and the scope of authorization to the target chain is legal, but the target chain does not disclose complete identity information, complete source chain transaction records, and complete source of permissions.

[0148] The cross-chain collaboration nodes further perform threshold signing on the credentials. Let the set of cross-chain collaboration nodes be:

[0149] in, A valid threshold signature can be generated after verification by more than one node, and its definition is:

[0150] when: At that time, generate an aggregate signature:

[0151] in: This represents the set of cross-chain collaboration nodes that have passed verification. Indicates the minimum number of nodes required for threshold signature; This indicates the threshold signature result; Indicates the aggregate signature function; This indicates a summary of the voucher to be signed.

[0152] A voucher summary can be defined as:

[0153] in: This indicates the target link's receiving address or the target link's account address.

[0154] Finally, a cross-chain trusted interaction credential is generated:

[0155] in: This represents a trusted cross-chain interaction credential. This indicates the timeout rollback parameter.

[0156] To address the issue of target chains blindly activating cross-chain permissions, this solution addresses the problem that if a target chain only receives authorization information from the source chain or a third-party platform without verifying the source chain's state commitment, permission policy, zero-knowledge proofs, and threshold signatures, it may lead to forged authorizations, excessive authorizations, or duplicate authorizations. Therefore, step S6 of this solution requires the target chain to perform multiple verifications on the cross-chain trusted interaction credentials and generate mapped permission credentials only after successful verification.

[0157] As a preferred implementation scheme, in step S6 of this scheme, the target chain mapping permission certificate does not change the ownership status of the source chain digital assets, but only records the authorized permission items, validity period, applicable scenic spots, executable operations, settlement rule summary and permission version number in the target chain.

[0158] As an example of implementation, step S6 of this solution includes the following sub-steps: Target link receives cross-chain trusted interaction credentials First, verify the source chain signature:

[0159] in: This indicates the source chain signature verification result; This represents the public key of the source chain contract or the source chain verification node; Indicates a commitment to the source chain state; This indicates the source chain signature.

[0160] Then verify the zero-knowledge proof:

[0161] in: This represents the zero-knowledge verification result on the target chain side; This represents zero-knowledge proof; It indicates a public statement.

[0162] Re-verify the threshold signature:

[0163] in: This indicates the threshold signature verification result; This represents the aggregated public key corresponding to the set of cross-chain collaborative nodes; Represents a summary of the voucher; This indicates the threshold signature result.

[0164] Meanwhile, the target chain determines whether there are any conflicts on the target chain side based on the local permission-based collaborative ledger:

[0165] in: Indicates the target chain-side permission conflict value; This represents the currently activated or occupied permission vector in the target chain; Represents the set of permissions to be mapped The corresponding permission vector.

[0166] When the following conditions are met:

[0167] At that time, the target chain generates a mapping permission credential:

[0168] in: Indicates the target chain mapping authorization credential; Indicates the start time of the target chain mapping permissions; Indicates the end time of the target chain mapping permission; This represents the target chain random number.

[0169] Under the reasoning logic of this formula, the target chain mapping permission certificate is not a copy of the source chain asset ontology, but rather a copy of the locked permission set. An executable authorization record on the target chain. Therefore, its generation must be bound to the asset master identifier, target chain, target account, permission set, permission policy, lock version, and validity period to prevent the target chain permissions from flowing independently from the source chain's lock state.

[0170] The target chain writes the credential to the authorization coordination ledger:

[0171] in: This represents the target chain's permission coordination ledger; Indicates the target chain mapping permission status.

[0172] To address the issue of difficulty in transmitting and auditing the business execution results after authorization on the target chain, after the target chain generates the mapped permission certificate, it is still necessary to perform operations such as display, resale, exchange, time-sharing authorization, and revenue sharing triggering according to specific business scenarios. If the execution results do not form a unified proof, the source chain and settlement node cannot confirm whether the target chain has actually completed the interaction operation. Therefore, step S7 of this solution generates an interaction result proof that can be used for settlement and write-back.

[0173] As an example of implementation, step S7 of this solution includes the following sub-steps: The target chain is based on the mapped permission credentials. and target operation type Execute the corresponding business function:

[0174] in: Indicates the result of business execution; This represents the target chain's business execution function; This represents target chain business data, such as reconciliation records, display records, redemption records, or time-sharing authorization records.

[0175] If this operation involves the consumption of credit limit, then update the remaining credit limit:

[0176] in: Indicates the remaining amount after execution; Indicates the remaining amount before execution; This indicates the amount consumed in this operation.

[0177] If this operation involves dynamic NFT state changes, then update the state version:

[0178] in: Indicates the state version after the target chain has been executed; This indicates a source chain locked version.

[0179] If this operation involves the cancellation of scenic area rights, a cancellation status will be generated:

[0180] in: Indicates the status of rights write-off; This indicates that the business operation was successfully executed; This indicates that the business operation failed.

[0181] Proof of the interaction result generated by the target chain:

[0182] in: This indicates that the interaction result is proof; Indicates the target chain permission status after execution; Indicates the target chain transaction hash; Indicates the execution time of the target chain.

[0183] The target chain further signs the proof of the interaction result:

[0184] in: Indicates the target chain signature; This represents the private key of the target chain contract or the validator node.

[0185] The final result is a signed record of the interaction outcome:

[0186] Under the reasoning logic of this formula, the interaction result proof must simultaneously bind the asset master identifier, target chain permission certificate, operation type, execution result, amount change, state change, transaction hash, and execution time. In this way, the settlement node and the source chain can, during subsequent processing, determine the appropriate information based on these parameters. Verify that the execution result of the target chain is consistent with the authorized permissions, transaction records, and state version.

[0187] To address the issues of low settlement efficiency and high on-chain costs in high-frequency, small-amount, multi-entity cross-chain interactions, this solution addresses the challenges of low settlement efficiency and high on-chain costs associated with high-frequency, small-amount, and multi-entity cross-chain interactions. Digital asset interactions within scenic areas typically involve numerous transactions such as visitor rights verification, points redemption, digital collectible display, cross-scenic area discounts, and revenue sharing. If each transaction were settled separately across chains, it would result in high on-chain transaction costs, long confirmation cycles, and fragmented settlement data. Therefore, step S8 of this solution achieves integrated settlement through transaction batch processing, Merkle root, aggregated signatures, and net settlement.

[0188] As a preferred implementation scheme, preferably, in step S8 of this scheme, the fusion settlement includes: Prove the generation of batch Merkle roots based on multiple interaction results in the transaction batch; Aggregate the signatures of scenic spot nodes, platform nodes, and / or content rights nodes participating in the settlement; The settlement share corresponding to the scenic area, content creator, operating platform, promotion node and / or regulatory record account is calculated according to the settlement rules. Write the settlement share summary and batch Merkle root into the source chain and the target chain.

[0189] As an example of implementation, step S8 of this solution includes the following sub-steps: Let the set of interaction result records collected within a settlement cycle be:

[0190] in: Indicates the first Transaction batches within a settlement cycle; Indicates the first One interaction result record.

[0191] Calculate a summary for each interaction result:

[0192] Then construct the batch Merkle root:

[0193] in: Indicates the first Merkle root for each settlement cycle; This represents the Merkle root calculation function.

[0194] Under the reasoning logic of this formula, a batch Merkle root can represent the entire transaction batch using a fixed-length summary. If it is subsequently necessary to verify whether a certain interaction result belongs to the settlement batch, only the Merkle path needs to be provided, eliminating the need to write all transaction details on-chain, thereby reducing on-chain storage costs.

[0195] For each interaction result record, the system applies the settlement rules. Calculate the allocation ratio of the participating entities. Let the first... The settlement amount or equity value of the transaction is The set of participating entities is as follows:

[0196] No. The subject in the first The allocation ratio in the transaction is Therefore, the share that the entity should receive in this settlement period is:

[0197] in: Indicates the first The settlement share of each entity; Indicates the first The settlement amount or equity value of the transaction; Indicates the first The subject in the first The allocation ratio in the transaction; This function indicates whether a transaction was successful; it returns 1 if the transaction was successful and 0 if it failed. Indicates the first The handling fees that each entity should bear; This indicates the amount of any abnormal adjustment, compensation, or preferential subsidy.

[0198] Under the reasoning logic of this formula, only the interaction results of the target chain that are actually successfully executed should enter the settlement; the revenue of different entities is distributed according to the preset settlement rules; at the same time, transaction fees are deducted and abnormal compensation or preferential subsidies are included to obtain the final settlement share.

[0199] To reduce cross-chain clearing amounts, the system can also perform net settlement:

[0200] in: Indicates the first Net settlement amount for each entity; This indicates the amount receivable by the entity; This indicates the amount payable by the entity.

[0201] The settlement node generates a settlement details summary, which is defined as follows:

[0202] in: This indicates a summary of the settlement details; Indicates the settlement cycle number; Indicates the settlement time.

[0203] Multiple settlement nodes aggregate and sign the settlement detail summary, which is defined as follows:

[0204] in: Indicates the settlement aggregation signature; This represents the set of settlement nodes that participated in the settlement signature process. Indicates the first The private key of each settlement node.

[0205] The final merged settlement result is defined as follows:

[0206] in, Indicates the settlement period. Indicates the settlement time. Indicates the first Net settlement amount for each entity Indicates the first Merkle root for each settlement cycle; This indicates a summary of the settlement details; Indicates the first The settlement share of each entity; This indicates the settlement aggregation signature.

[0207] To address the issues of inconsistent states across multiple chains after cross-chain interaction, unauditable settlement results, and long-term asset locking under abnormal circumstances, this solution addresses the problems of inconsistent states, unauditable settlement results, and long-term asset locking under abnormal circumstances. Cross-chain interaction involves multiple entities, including source chain locking rights, target chain usage rights, settlement node settlement, and regulatory node auditing. An abnormality in any of these stages can lead to inconsistent states. Therefore, step S9 of this solution establishes a closed loop for cross-chain interaction through state write-back, audit summary, and abnormal rollback mechanisms.

[0208] As a preferred implementation scheme, in step S9 of this scheme, the anomaly audit record includes: cross-chain digital asset master identifier, anomaly type, anomaly occurrence chain, anomaly occurrence time, permission version number, executed permission status, rollback processing result, relevant node signature and / or audit summary.

[0209] In addition, when generating abnormal audit records, abnormal alerts are also sent to the scenic area's operation and supervision nodes.

[0210] As an example of implementation, step S9 of this solution includes the following sub-steps: First, verify the fusion settlement results:

[0211] in: Indicates the settlement signature verification result; This represents the aggregate public key corresponding to the set of settlement nodes; This indicates a summary of the settlement details; This indicates the settlement aggregation signature.

[0212] when At that time, the permission state change result is written back to the source chain. The source chain state update can be represented as:

[0213] in: This represents the updated source chain state root; This represents the root state of the source chain before the update; Indicates the status of assets or permissions after the source chain is written back; This indicates the state version after the target chain has been executed.

[0214] The target chain state update can be represented as:

[0215] in: This represents the updated root state of the target chain; This represents the root state of the target chain before the update; This indicates the permission status after the target chain is executed.

[0216] Generate an audit summary, which is defined as:

[0217] in: Indicates an audit summary; Indicates the batch Merkle root; This indicates a summary of the settlement details; Indicates the time when the audit record was generated.

[0218] Under the reasoning logic of this formula, the audit summary needs to simultaneously cover the asset master identifier, source chain locking version, target chain execution version, transaction batch, settlement result, source chain state root, and target chain state root. In this way, subsequent regulatory nodes can use this summary to verify the complete chain of cross-chain interaction from authorization to settlement.

[0219] Finally, an audit log is generated:

[0220] in: This refers to audit records.

[0221] At the same time, the anomaly judgment function can be defined as follows, based on the detected abnormal state:

[0222] in: Indicates an abnormal value; Indicates the source chain lock expiration time; Indicates the target chain state; This indicates the source chain signature verification result; This represents the verification result of zero-knowledge proof; This indicates the threshold signature verification result; Indicates the target chain permission conflict value; This indicates the settlement verification result.

[0223] Under the reasoning logic of this formula, cross-chain interaction anomalies may arise from lock timeouts, invalid source chain proofs, invalid zero-knowledge proofs, invalid threshold signatures, permission conflicts, or invalid settlement signatures. If any of these anomaly conditions are met, the anomaly judgment value will be greater than 0, and the system will enter a rollback or freeze process.

[0224] when At that time, the system confirms that the cross-chain interaction is complete and updates the source chain permission status to "executed" or "settled".

[0225] when At that time, the system rolls back based on the timeout parameters. Perform exception handling. If the target chain has not yet executed successfully, release the source chain locking permissions:

[0226] in: This indicates the state of the source chain after the lock is released; This indicates the function for releasing permissions on the source chain.

[0227] If the target chain has generated mapping permissions but settlement fails or there is a permission conflict, then revoke the target chain mapping permissions:

[0228] in: Indicates the state of the target chain after cancellation; This indicates the function to revoke mapping permissions.

[0229] The system generates a rollback record summary:

[0230] in: This indicates a summary of the rollback record; Indicates the exception type; This indicates the execution time for rollback.

[0231] The final result is an abnormal audit record:

[0232] in, This indicates an abnormal audit record; This indicates the signature of the audit node.

[0233] Combination Figure 3 As shown above, this solution also proposes a cross-chain trusted interaction and permission collaborative management system for digital assets, which includes: The interactive access module is used to receive digital assets of scenic spots and their cross-chain interaction requests; The identifier generation module is used to generate a cross-chain digital asset master identifier based on the asset content fingerprint, source chain information, metadata digest, and dynamic status version number. The permission configuration module is used to build permission vectors, permission state machines, and permission conflict matrices. The multi-level oracle module is used to collect and verify off-chain event data of scenic spots and generate dynamic state triggering instructions; The source chain permissions module is used to lock the expected interaction permissions of the digital assets to be interacted with and generate source chain state commitments. The credential generation module is used to generate cross-chain trusted interaction credentials that include source chain state commitment, permission policy summary, zero-knowledge verification result, threshold signature result, and timeout rollback parameters. The mapping management module is used to verify cross-chain trusted interaction credentials and generate target chain mapping permission credentials; The integrated settlement module is used to batch summarize, aggregate, verify, and settle accounts for the verification results of interactions. The audit and oversight module is used to record permission status changes, cross-chain interaction results, fusion settlement results, and anomaly handling results.

[0234] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0235] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0236] The above description is only a part of the embodiments of the present invention and does not limit the scope of protection of the present invention. Any equivalent device or equivalent process transformation made based on the content of the present invention specification and drawings, or direct or indirect application in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for trusted cross-chain interaction and permission coordination management of digital assets, applied to a digital asset management system including a source chain, a target chain, cross-chain collaborative nodes, oracle nodes, and settlement nodes, characterized in that, It includes: S1. Receive a cross-chain interaction request for the scenic area's digital assets. The cross-chain interaction request includes the original asset data, source chain information, target chain information, requesting entity identity information, target operation type, expected interaction permissions, settlement rules, and asset business identifier of the digital asset to be interacted with. The source chain information includes the source chain identifier. Then, generate a cross-chain digital asset master identifier based on the cross-chain interaction request. The cross-chain digital asset master identifier is obtained by hashing the asset business identifier, source chain identifier, source chain contract address, source chain asset number, asset content fingerprint, metadata digest, and / or dynamic status version number, and serves as a unified index for source chain permission locking, target chain mapping authorization, fusion settlement, and / or audit trail. S2. Based on the target operation type and settlement rules, and in conjunction with the scenic area business rules, construct a permission vector and its corresponding permission state machine for the digital asset to be interacted with; S3. Obtain scenic area off-chain event data related to the digital asset to be interacted with through the oracle node, and preprocess and calculate the event credibility to obtain dynamic state triggering instructions; S4. The source chain performs locking processing on the permission item corresponding to the expected interaction permission in the digital asset to be interacted based on the cross-chain digital asset master identifier, permission vector, permission state machine and dynamic state triggering instruction, and generates source chain state commitment. S5. The cross-chain collaborative node generates a cross-chain trusted interaction certificate based on the source chain state commitment, the cross-chain digital asset master identifier, the permission vector, the target chain information, the settlement rules and / or the identity information of the requesting entity; the cross-chain trusted interaction certificate includes timeout rollback parameters; S6. The target chain verifies the cross-chain trusted interaction certificate, and after the verification is successful, generates a target chain mapping permission certificate corresponding to the expected interaction permission, and writes the target chain mapping permission certificate into the target chain permission collaboration ledger. S7. The target chain performs the digital asset interaction operation corresponding to the target operation type based on the target chain mapping permission certificate, and generates an interaction result certificate; S8. The settlement node performs batch aggregation of multiple interaction result proofs within the same settlement period, generates transaction batch, batch Merkle root, aggregate signature and settlement details, and completes fusion settlement according to the settlement rules. S9. Write back the fusion settlement result, permission status change result and audit summary to the source chain and the target chain. When a permission conflict, verification failure, lock timeout or settlement abnormality is detected, execute permission release, mapping permission revocation and / or abnormal audit record generation according to the timeout rollback parameters.

2. The method for cross-chain trusted interaction and permission collaborative management of digital assets as described in claim 1, characterized in that, In step S1, the cross-chain interaction request also includes a request random number, a validity period, and a request subject signature.

3. The method for cross-chain trusted interaction and permission collaborative management of digital assets as described in claim 1, characterized in that, In step S2, the permission vector is used to represent multiple permission states among the rights of holding, display, rights cancellation, limited use, transfer, time-sharing use, revenue distribution, settlement triggering, and revocation. In step S2, the permission state machine includes at least the following states: inactive state, interactive state, locked state, target chain pending authorization state, target chain authorized state, rights cancelled state, settlement pending confirmation state, settled state, abnormal freeze state, and / or rollback completed state. Each permission state change must satisfy a preset legal state transition path.

4. The method for cross-chain trusted interaction and permission collaborative management of digital assets as described in claim 3, characterized in that, Step S2 also includes: A permission conflict matrix is ​​constructed to determine the occupancy relationship of multiple permission items under the same cross-chain digital asset master identifier in different chains, different scenic spots and different platforms. When it is detected that the same right cancellation right is repeatedly activated, the time-sharing right and the transfer right overlap in time, or the target chain authorization request still exists after the revocation right is triggered, the corresponding permission status change is blocked.

5. The method for cross-chain trusted interaction and permission collaborative management of digital assets as described in claim 1, characterized in that, In step S3, the scenic area off-chain event data related to the digital asset to be interacted with is obtained through the oracle node, and the scenic area off-chain event data is formatted, time-aligned, multi-source consistency verified and event credibility calculated to obtain dynamic state triggering instructions; The off-chain event data of the scenic area includes: ticket verification data, POS payment data, visitor entry data, visitor behavior data, scenic area activity participation data, IoT device collection data and / or member point change data; the credibility of the event is calculated based on the data source credibility weight, time consistency, spatial consistency, signature validity and / or multi-source matching degree.

6. The method for trusted cross-chain interaction and permission collaborative management of digital assets as described in claim 1, characterized in that, In step S5, the cross-chain trusted interaction credential also includes a source chain state commitment, a permission policy digest, a zero-knowledge verification result, and / or a threshold signature result; The zero-knowledge verification result is used to prove that the requesting subject is qualified to invoke the expected interaction permission, that the permission item corresponding to the source chain state commitment has been locked, that the target operation type conforms to the permission policy summary, and that the complete identity information of the requesting subject and the source chain transaction details are not disclosed to the target chain.

7. The method for cross-chain trusted interaction and permission collaborative management of digital assets as described in claim 1, characterized in that, In step S6, the target chain mapping permission certificate does not change the ownership status of the source chain digital assets, but only records the authorized permission items, validity period, applicable scenic spots, executable operations, settlement rule summary and permission version number in the target chain; In step S8, the fusion settlement includes: Prove the generation of batch Merkle roots based on multiple interaction results in the transaction batch; Aggregate the signatures of scenic spot nodes, platform nodes, and / or content rights nodes participating in the settlement; The settlement share corresponding to the scenic area, content creator, operating platform, promotion node and / or regulatory record account is calculated according to the settlement rules. Write the settlement share summary and batch Merkle root into the source chain and the target chain.

8. The method for cross-chain trusted interaction and permission collaborative management of digital assets as described in claim 1, characterized in that, In step S9, the anomaly audit record includes: cross-chain digital asset master identifier, anomaly type, anomaly occurrence chain, anomaly occurrence time, permission version number, executed permission status, rollback processing result, relevant node signature and / or audit summary; When generating abnormal audit records, abnormal alerts are also sent to the scenic area's operation and supervision nodes.

9. A digital asset cross-chain trusted interaction and permission collaborative management system, which applies the digital asset cross-chain trusted interaction and permission collaborative management method as described in claim 1, characterized in that, It includes: The interactive access module is used to receive digital assets of scenic spots and their cross-chain interaction requests; The identifier generation module is used to generate a cross-chain digital asset master identifier based on the asset content fingerprint, source chain information, metadata summary, and dynamic status version number. The permission configuration module is used to build permission vectors, permission state machines, and permission conflict matrices. The permission conflict matrix is ​​used to determine the occupancy relationship of multiple permission items under the same cross-chain digital asset master identifier in different chains, different scenic spots and different platforms. When it is detected that the same right cancellation right is repeatedly activated, the time-sharing right and the transfer right overlap in time, or the target chain authorization request still exists after the revocation right is triggered, the corresponding permission status change is blocked. The multi-level oracle module is used to collect and verify off-chain event data of scenic spots and generate dynamic state triggering instructions; The source chain permissions module is used to lock the expected interaction permissions of the digital assets to be interacted with and generate source chain state commitments. The credential generation module is used to generate cross-chain trusted interaction credentials that include source chain state commitment, permission policy summary, zero-knowledge verification result, threshold signature result, and timeout rollback parameters. The mapping management module is used to verify cross-chain trusted interaction credentials and generate target chain mapping permission credentials; The integrated settlement module is used to batch summarize, aggregate, verify, and settle accounts for the verification results of interactions. The audit and oversight module is used to record permission status changes, cross-chain interaction results, fusion settlement results, and anomaly handling results.

Images