Digital asset state updating method, apparatus, device, medium, and program product

Abstract

This application provides a method, apparatus, device, medium, and program product for updating the state of digital assets. The method is applied to a digital asset state machine system, which includes a state machine registry containing multiple states and state transition conditions. The method includes: receiving a state update request, the state update request including a target state to which a target digital asset needs to be updated; verifying, based on the state machine registry, whether the target digital asset meets the state transition conditions corresponding to the target state; and, if the target digital asset meets the state transition conditions, executing the state update request to update the state of the target digital asset to the target state. This method improves the state management capabilities of a digital asset state machine system in complex business scenarios.

Description

Technical Field

[0001] This application relates to the field of blockchain, and in particular to a method, apparatus, device, medium, and program product for updating the state of digital assets. Background Technology

[0002] The lifecycle management of digital collectibles involves the entire process from creation, binding to physical assets, trading, cross-chain circulation to destruction, with significant demand, especially in scenarios such as digital art, virtual asset trading, and digital copyright management.

[0003] In existing systems, users initiate operations (such as locking up assets or cross-chain transfers) through decentralized applications. The system needs to verify state transition rules in real time and trigger off-chain transactions (such as logistics notifications or compliance freezes). However, existing systems only use a single state labeling method, which cannot accurately describe the subtle state differences of digital collectibles in complex business scenarios.

[0004] Therefore, improving the system's ability to manage the state of digital collections in complex business scenarios is an urgent problem to be solved. Summary of the Invention

[0005] This application provides a digital asset state update method, apparatus, device, medium, and program product to improve the state management capabilities of a digital asset state machine system in complex business scenarios.

[0006] In a first aspect, embodiments of this application provide a method for updating the state of a digital asset. The method is applied to a digital asset state machine system, which includes a state machine registry, comprising multiple states and state transition conditions. The method includes:

[0007] Receive a status update request, the status update request including the target state to which the target digital asset needs to be updated;

[0008] Based on the state machine registry, verify whether the target digital asset meets the state transition conditions corresponding to the target state;

[0009] If the target digital asset meets the state transition conditions corresponding to the target state, the state update request is executed to update the state of the target digital asset to the target state.

[0010] In one possible implementation, the digital asset state machine system further includes: a non-fungible token (NFT) contract module, wherein verifying whether the target digital asset meets the state transition conditions corresponding to the target state based on the state machine registry includes:

[0011] The NFT contract module queries the state machine registry for the state transition conditions between the current state and the target state of the target digital asset.

[0012] The NFT contract module receives the state transition conditions returned by the state machine registry, as well as instructions on whether to allow the state transition.

[0013] In response to the instruction indicating permission for a state transition, the system verifies whether the target digital asset meets the state transition conditions based on the state transition conditions.

[0014] In one possible implementation, the digital asset state machine system further includes: an event listening layer, and an automated workflow engine, wherein executing the state update request when the target digital asset satisfies the state transition conditions corresponding to the target state includes:

[0015] When the target digital asset meets the state transition conditions corresponding to the target state, the NFT contract module sends a state transition event to the event listening layer based on the state update request.

[0016] The event listening layer captures the state transition event and converts it into a preset format to obtain the message to be processed.

[0017] The event listener layer pushes the message to be processed to the automated workflow engine.

[0018] The automated workflow engine updates the state of the target digital asset to the target state in response to the pending message.

[0019] In one possible implementation, the digital asset state machine system further includes: an execution gateway, wherein updating the state of the target digital asset to the target state in response to the pending message via the automated workflow engine includes:

[0020] The automated workflow engine initiates a pre-arranged workflow in response to the pending message; the workflow includes: invoking the execution gateway and updating the state of the target digital asset to the target state through the execution gateway.

[0021] In one possible implementation, the digital asset state machine system further includes: a write-back agent, and the method further includes:

[0022] After the workflow is completed, the automated workflow engine generates a write-back instruction and sends the write-back instruction to the write-back agent; the write-back instruction is used to indicate that the status update of the target digital asset is complete.

[0023] Through the write-back proxy, in response to the write-back instruction, a status update completion feedback is submitted to the NFT contract module;

[0024] The NFT contract module responds to the status update completion feedback by outputting a status update completion prompt.

[0025] In one possible implementation, the step of outputting a status update completion notification in response to the status update completion feedback via the NFT contract module includes:

[0026] The NFT contract module is used to verify whether the write-back agent is an authorized relay agent, and the verification result is obtained.

[0027] In response to the verification result indicating that the write-back agent is an authorized relay agent and the status of the status update completion feedback indication being the target status, the NFT contract module sends a status update completion prompt to the user terminal.

[0028] In one possible implementation, the digital asset state machine system is deployed on a first blockchain, and the method further includes:

[0029] If the target digital asset satisfies the state transition conditions corresponding to the target state, a state increment package is generated; the state increment package includes: incremental data, and Merkel proof data of the state change of the target digital asset; the incremental data is the incremental data generated when the target digital asset changes from the current state to the target state;

[0030] Generate a synchronization request that includes the state increment packet;

[0031] The synchronization request is sent to the second blockchain to enable the second blockchain to synchronize the state increment packet.

[0032] In one possible implementation, prior to sending the synchronization request to the second blockchain, the method further includes:

[0033] The state of the second blockchain is detected; the state includes at least one of the following: network connectivity with the first blockchain, the necessity assessment result of synchronizing state increment packets to the second blockchain, and the resource reserve assessment result of the second blockchain;

[0034] Sending the synchronization request to the second blockchain includes:

[0035] When the state of the second blockchain meets the data packet synchronization conditions, the synchronization request is sent to the second blockchain.

[0036] Secondly, embodiments of this application provide a digital asset state update device, which is applied to a digital asset state machine system. The digital asset state machine system includes a state machine registry, which includes multiple states and state transition conditions. The device includes:

[0037] The receiving module is used to receive a status update request, wherein the status update request includes the target status to which the target digital asset needs to be updated;

[0038] The verification module is used to verify, based on the state machine registry, whether the target digital asset meets the state transition conditions corresponding to the target state;

[0039] An execution module is configured to execute the state update request when the target digital asset meets the state transition conditions corresponding to the target state, so as to update the state of the target digital asset to the target state.

[0040] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0041] The memory stores computer-executed instructions;

[0042] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method described in any of the first aspects above.

[0043] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in any of the first aspects above.

[0044] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the first aspects above.

[0045] This application provides a digital asset state update method, apparatus, device, medium, and program product. Through a digital asset state machine system, it can receive state update requests and verify whether the target digital asset meets the state transition conditions corresponding to the target state based on a state machine registry. If the conditions are met, the state update request is executed. By precisely managing digital asset state transitions through a state machine registry, it reduces the problem of coarse-grained state management in traditional methods, accurately describes the state changes of digital assets under different business scenarios, and improves the state management capabilities of the digital asset state machine system in complex business scenarios. Attached Figure Description

[0046] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0047] Figure 1 A flowchart illustrating a digital asset status update method provided in this application embodiment;

[0048] Figure 2 A flowchart illustrating a verification of state transition conditions provided in an embodiment of this application;

[0049] Figure 3 A flowchart illustrating the execution of a status update request is provided for an embodiment of this application;

[0050] Figure 4 A flowchart illustrating an output status update completion notification provided in an embodiment of this application;

[0051] Figure 5 A flowchart illustrating a cross-chain synchronization method provided in an embodiment of this application;

[0052] Figure 6 A schematic diagram of the layered architecture of a digital collection state machine system provided in this application embodiment;

[0053] Figure 7 A schematic diagram illustrating cross-chain synchronization as provided in an embodiment of this application;

[0054] Figure 8 A schematic diagram illustrating the process of changing the status of a digital collection, provided as an embodiment of this application;

[0055] Figure 9 A flowchart illustrating an on-chain and off-chain state synchronization sequence provided in an embodiment of this application;

[0056] Figure 10 A flowchart illustrating a cross-chain condition determination provided in an embodiment of this application;

[0057] Figure 11A schematic diagram of a digital asset status update device provided in this application;

[0058] Figure 12 This is a schematic diagram of the structure of an electronic device provided in this application.

[0059] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0060] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0061] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0062] The following is an explanation of the terms used in the embodiments of this application.

[0063] State machine: A computational model that describes the various states a digital collectible may be in during its lifecycle and the rules governing the transitions between those states. State transitions are triggered by specific conditions and transactions.

[0064] Cross-chain state synchronization: The technical process of keeping the state of digital collectibles consistent across different blockchains, ensuring that state changes between the main chain and side chains can be synchronized atomically.

[0065] Nodemation (n8n) is an open-source, visual, and self-hosted workflow automation platform that uses a drag-and-drop node approach to build automated processes and supports integration with various applications and custom code.

[0066] Merkel-Patricia tree: A cryptographic data structure used for efficiently storing and verifying state information on a blockchain, generating cryptographic proofs of state changes.

[0067] State increment data: In the process of blockchain synchronization, data packets that only contain state change information rather than the complete state can improve synchronization efficiency.

[0068] Non-Fungible Tokens (NFTs): Blockchain can provide ownership proof for various digital assets, such as digital content, using NFTs as credentials. These NFTs are stored and distributed in a distributed manner, ensuring their uniqueness and immutability. This characteristic makes NFTs widely used in digital assets and other fields. Digital art is one of the main application scenarios for NFT technology. Through NFTs, the copyright ownership of digital art can be proven, allowing owners to use their tokens in various online social spaces.

[0069] The lifecycle management of digital collectibles involves the entire process from creation, binding to physical assets, trading, cross-chain circulation to destruction, with significant demand particularly in scenarios such as digital art, virtual asset trading, and digital copyright management. For example, in the field of digital art, artists need to bind unique proof of physical artworks through NFTs, and after the collectibles enter the secondary market, they need to undergo complex operations such as multiple transactions, exhibition collateralization, and cross-chain transfers.

[0070] In the existing system, when users initiate operations (such as locking up assets or transferring assets across chains) through decentralized applications (DApps), the system needs to verify the state transition rules in real time and trigger off-chain transactions (such as logistics notifications or compliance freezes).

[0071] However, most mainstream digital collectible platforms currently employ a single blockchain architecture, which presents significant limitations in state management. Most systems use simple state labeling methods, storing the state of digital collectibles in a mapping table within smart contracts, representing only basic states such as "not sold," "sold," and "frozen." This method provides coarse-grained state management and cannot accurately describe the nuanced state differences of digital collectibles in complex business scenarios. For example, it cannot accurately describe the subtle state differences in scenarios such as binding to physical assets, cross-chain transfers, and compliant freezing, making it difficult to flexibly adapt business rules.

[0072] Therefore, the digital asset state machine system of this application embodiment can receive state update requests, verify whether the target digital asset meets the state transition conditions corresponding to the target state based on the state machine registry, and execute the state update request if it does. By accurately managing the state transitions of digital assets through the state machine registry, the problem of coarse-grained state management in traditional methods is reduced, and the state changes of digital assets under different business scenarios can be accurately described, thereby improving the state management capability of the digital asset state machine system in complex business scenarios.

[0073] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0074] It should be noted that the implementing entity of this application may be a digital asset state machine system, which may be deployed on any electronic device with processing capabilities, such as a user terminal or a server, for example, a computer.

[0075] Figure 1 This is a flowchart illustrating a digital asset state update method provided in an embodiment of this application. The method is applied to a digital asset state machine system, which includes a state machine registry, comprising multiple states and state transition conditions.

[0076] Optionally, a digital asset state machine system can be used to handle transactions related to the state of digital assets. It utilizes the principles and mechanisms of state machines to manage the state of digital assets. A state machine is a mathematical model that describes the behavioral changes of a system under different inputs or events by defining different states and the transition conditions and actions between states. In the field of digital assets, this system can precisely control and update the state of digital assets according to preset rules.

[0077] A state machine registry can exist as a data structure or a table. It is used to record and manage various state information and the transition conditions between states in a digital asset state machine system. Through this registry, the system can clearly understand the specific definition of each state and the conditions that must be met to transition from one state to another.

[0078] The multiple states included in the state machine registry can be attributes or characteristics of a digital asset at a specific moment. For example, a digital asset may be in different states such as "not traded," "trading," "traded," or "frozen." State transition conditions can be specific requirements or triggering factors that a digital asset needs to meet to transition from one state to another.

[0079] For example, the state machine registry includes multiple states and state transition conditions as follows:

[0080] 1. Initial State: The data structure of the digital asset has just been established, but it has not yet been linked to a real asset. In this state, the digital asset only has metadata and cannot be traded or transferred.

[0081] 2. Binding Status: The digital asset has been bound to a real-world asset (such as physical artwork or collectibles). This binding information is recorded on the blockchain using a hash value to ensure authenticity and verifiability.

[0082] 3. Transaction Status: Digital assets can be traded on the secondary market, but they are not yet eligible to be redeemed for real assets. In this state, digital assets can change hands multiple times, and their status changes frequently.

[0083] 4. Locked Status: Digital assets are locked on the digital asset platform and are usually used for specific scenarios (such as exhibitions or mortgages), but they can still be traded in the digital asset exchange.

[0084] 5. Frozen Status: At the customer's request, digital assets have been temporarily frozen and cannot be traded or cashed out. This status usually requires administrator privileges or multi-signature to trigger.

[0085] 6. Redemption Status: Digital assets are being redeemed for corresponding real assets. This process usually involves off-chain logistics or service delivery and requires special monitoring.

[0086] 7. Destroyed Status: The digital asset has completed its lifecycle. The relevant records are permanently stored on the blockchain for querying, but the asset itself is no longer usable.

[0087] like Figure 1 As shown, the method includes:

[0088] S101. Receive a status update request. The status update request includes the target state to which the target digital asset needs to be updated.

[0089] Optionally, a status update request can be used to trigger an information instruction to change the status of a digital asset. It can specify which digital asset, i.e. the target digital asset, needs to have its status updated, and to what new status, i.e. the target status, the digital asset needs to be updated.

[0090] The target digital asset can be any digital asset whose state needs to be changed. It can be any type of asset with digital form and certain value, such as cryptocurrency, digital securities, digital collectibles, etc.

[0091] Optionally, users can initiate state update requests through the interactive interface of the digital asset state machine system, and the digital asset state machine system can receive state update requests through the call interface of the interactive interface. Optionally, the state update request can also be an automatically triggered state update request based on any one or more of the following: scheduled tasks, conditions being met, etc., in the digital asset state machine system.

[0092] For example, a digital asset state machine system can receive state update requests through any one or more of the following: user operations (transactions such as purchase, transfer, and gifting), automatic system triggers (timed tasks, condition fulfillment, etc.), administrator operations (freezing, unlocking, special handling, etc.), external events (cross-chain requests, external system calls, etc.), event classification (classifying and marking events according to their type, distinguishing their urgency and scope of impact), and priority assessment (determining the urgency of event processing and allocating corresponding computing resources).

[0093] S102. Based on the state machine registry, verify whether the target digital asset meets the state transition conditions corresponding to the target state.

[0094] Optionally, the state transition conditions corresponding to the target state can be the target state that the target digital asset is to be updated to, which is a series of requirements or rules that the target digital asset must meet when transitioning from the current state to the target state, as predefined in the state machine registry.

[0095] Optionally, the digital asset state machine system can use a state machine registry as a basis, reference, or foundation, retrieving relevant information and rules from the registry to verify whether the target digital asset meets the state transition conditions corresponding to the target state. Alternatively, the digital asset state machine system can use rule engines, machine learning, or other methods to verify whether the target digital asset meets the state transition conditions corresponding to the target state.

[0096] For example, the state machine registry can transition from "transaction state" to "frozen state." The transition conditions are that the user actively applies for freezing, and the platform administrator approves it or the multi-signature requirements are met. If the user actively applies for freezing, and the platform administrator approves the application after verifying that the information is correct, the conditions are met, the verification is successful, and the digital asset state is updated from "transaction state" to "frozen state." If the user applies for freezing, but the administrator does not approve it, or the multi-signature requirements are not met, the conditions are not met, the verification is successful, and the digital asset state remains "transaction state."

[0097] S103. If the target digital asset meets the state transition conditions corresponding to the target state, execute a state update request to update the state of the target digital asset to the target state.

[0098] Optionally, the digital asset state machine system can trigger a smart contract pre-deployed on the blockchain. This contract automatically verifies the state transition conditions (such as user permissions, asset binding status, etc.). If the verification is successful, the latest state of the target digital asset (such as changing from "transaction state" to "frozen state") is written to the blockchain ledger in an immutable manner through a blockchain transaction. At the same time, the state record in the state machine registry is updated to execute the state update request, so that the state of the target digital asset is updated to the target state.

[0099] The digital asset state machine system of this application embodiment can receive state update requests and verify whether the target digital asset meets the state transition conditions corresponding to the target state based on the state machine registry. If it does, the state update request is executed. By precisely managing the state transitions of digital assets through the state machine registry, the problem of coarse-grained state management in traditional methods is reduced. It can accurately describe the state changes of digital assets in different business scenarios and improve the state management capability of the digital asset state machine system in complex business scenarios.

[0100] In one implementation, the digital asset state machine system may further include a non-fungible token (NFT) contract module. Figure 2 This application provides a flowchart illustrating a verification of state transition conditions, as shown in the embodiments below. Figure 2 As shown, the above S102 may include:

[0101] S201. Through the NFT contract module, query the state machine registry for the state transition conditions between the current state and the target state of the target digital asset.

[0102] Optionally, the NFT contract module can be a collection of smart contracts built on blockchain technology for creating, managing, and trading non-fungible digital assets. It gives digital assets unique characteristics, with each NFT having its own specific attributes and value, and this information is recorded on the blockchain and cannot be tampered with.

[0103] Optionally, the NFT contract module of the digital asset state machine system can perform query operations by calling the preset query interface functions in the state machine registry smart contract.

[0104] S202. Through the NFT contract module, receive the state transition conditions returned by the state machine registry, as well as the instruction on whether to allow the state transition.

[0105] Optionally, the instruction to allow state transitions can be an indication issued by the digital asset state machine system after judging the queried state transition conditions, used to inform the NFT contract module whether to allow the target digital asset to undergo a state transition. The instruction is usually a clear signal; for example, the instruction can be "allow state transition" or "disallow state transition".

[0106] Optionally, the NFT contract module of the digital asset state machine system can perform the receiving operation by calling the receiving interface function preset in the state machine registry.

[0107] S203. In response to the instruction used to indicate that a state transition is permitted, based on the state transition conditions, verify whether the target digital asset meets the state transition conditions.

[0108] Optionally, upon receiving an instruction permitting a state transition, the NFT contract module checks and confirms whether the target digital asset meets the state transition conditions. This verification process is consistent with S102 described above and will not be repeated here.

[0109] This application embodiment utilizes the interaction between the NFT contract module and the state machine registry to automate the query and verification of state transition conditions, thereby improving the automation and accuracy of state transitions and reducing manual intervention and errors.

[0110] If the target digital asset meets the state transition conditions corresponding to the target state, the digital asset state machine system also includes: an event listening layer and an automated workflow engine. The event listening layer is a component within the digital asset state machine system responsible for monitoring and capturing specific events. It can monitor various events inside and outside the digital asset state machine system in real time. These events can originate from the blockchain network (such as the execution results of smart contracts, transaction confirmation events), external data sources (such as market price fluctuations, IoT device sensor data), or user operations (such as user-initiated transaction requests, state change applications).

[0111] An automated workflow engine can be a component in a digital asset state machine system that is responsible for managing and executing automated business processes. It can automatically handle tasks such as state transitions and business logic execution of digital assets according to preset rules and processes. For example, the automated workflow engine can be the n8n workflow automation platform.

[0112] Figure 3 This application provides a flowchart illustrating an execution status update request, as shown in the embodiments below. Figure 3 As shown, S103 above includes:

[0113] S301. When the target digital asset meets the state transition conditions corresponding to the target state, the NFT contract module sends a state transition event to the event listening layer based on the state update request.

[0114] Optionally, a state transition event may include information such as the digital asset's identifier, current state, and target state, which can indicate that the state of the digital asset is about to change.

[0115] Optionally, the NFT contract module can send state transition events to the event listening layer through the blockchain's event mechanism.

[0116] S302. Through the event listener layer, capture the state transition event and convert the state transition event into a preset format to obtain the message to be processed.

[0117] Optionally, the preset format can be a data structure and specification used to standardize the processing of state transition events, facilitating subsequent transmission and processing; for example, it could be JSON (a data structure). The message to be processed can be a state transition event that has undergone format conversion, conforming to the preset format requirements, and can be recognized and processed by other components such as the automated workflow engine.

[0118] Optionally, after receiving event data sent by blockchain nodes, the event listening layer can parse and identify the data, and determine whether it is a state transition event sent by the target NFT contract based on information such as the event type and contract address, and then capture the state transition event.

[0119] Optionally, the event listener layer can perform data format conversion on the captured state transition events according to preset format requirements. Preset formats may include one or more of the following: specific data structures, field naming rules, encoding methods, etc. After format conversion, a data object conforming to the preset format is generated, which is the message to be processed.

[0120] S303. Push the messages to be processed to the automated workflow engine through the event listener layer.

[0121] Optionally, the event listener layer can push pending messages to the automated workflow engine via network protocols or via message middleware.

[0122] S304. Through the automated workflow engine, in response to pending messages, update the state of the target digital asset to the target state.

[0123] Optionally, upon receiving a message to be processed, the automated workflow engine can trigger a corresponding process instance based on the content of the message. This process instance can also call external services or perform specific operations. Optionally, during the implementation of the process instance, the automated workflow engine can use blockchain smart contract calls to invoke the NFT contract module to update the state of the target digital asset.

[0124] In one implementation, the digital asset state machine system may further include an execution gateway, which may be a key component responsible for coordinating and controlling the execution of specific operations during state transitions. S304 above may include initiating a pre-arranged workflow in response to a pending message via an automated workflow engine. This workflow may include invoking the execution gateway and updating the state of the target digital asset to the target state through the execution gateway.

[0125] Optionally, a pre-arranged workflow can be an ordered set of predefined tasks and operations, specifying the execution order, conditions, and data interaction methods between tasks. The execution gateway can interact with multiple external systems or services, calling corresponding interfaces to perform specific operations based on instructions from the automated workflow engine, such as updating digital asset status or querying data.

[0126] Optionally, the automation workflow engine can search for a matching pre-arranged workflow based on information such as the type and content of the message to be processed. After the automation workflow engine finds a matching pre-arranged workflow, it can initialize the workflow execution environment to start the pre-arranged workflow according to the workflow definition. During workflow execution, the automation workflow engine can send a call request to the execution gateway using the corresponding communication protocol, based on the execution gateway interface information configured in the workflow definition. This request can include the operation instructions to be executed and related parameters.

[0127] Optionally, after receiving a call request from the automated workflow engine, the execution gateway can parse and verify the request. Once the verification is successful, the execution gateway will call the interface of the underlying system (such as blockchain nodes, databases, etc.) to complete the update operation of the target digital asset state according to the operation instructions and related parameters in the request.

[0128] This application embodiment achieves standardization and process-orientation of state updates through pre-arranged workflows and execution gateway calls, improving the reliability and consistency of state updates, while facilitating system expansion and maintenance.

[0129] This application embodiment achieves automated state transition processing through the integration of an event listener layer and an automated workflow engine, improving system response speed and processing efficiency while reducing system complexity and maintenance costs.

[0130] After the above workflow is completed, this embodiment of the application can also output a status update completion prompt, which will be described in detail below.

[0131] Digital asset state machine systems can also include write-back agents. Figure 4 This application provides a flowchart illustrating a status update completion notification. Figure 4 As shown, the process may include:

[0132] S401. After the workflow is completed, the automated workflow engine generates a write-back instruction and sends the write-back instruction to the write-back agent. The write-back instruction is used to indicate that the status update of the target digital asset is complete.

[0133] Optionally, the write-back instruction can be a data instruction that may include one or more pieces of information such as the unique identifier of the target digital asset, the updated status value, and the operation time, to indicate that the status update of the target digital asset is complete.

[0134] The writeback agent can receive writeback instructions from the automated workflow engine and forward them to the NFT contract module. It can also perform some preprocessing or format conversion on the instructions to ensure that the instructions can be correctly recognized and processed by the NFT contract module.

[0135] Optionally, the automated workflow engine can create write-back instructions through built-in code logic after the workflow execution is complete. For example, the automated workflow engine can generate specific write-back instructions by filling the template with relevant data during the workflow execution process (such as target digital asset information, updated status, etc.) based on a predefined write-back instruction template.

[0136] Optionally, the automated workflow engine can send the generated write-back instructions to the write-back agent via a pre-established communication connection, such as a network protocol call.

[0137] S402. Through the write-back agent, in response to the write-back instruction, submit status update completion feedback to the NFT contract module.

[0138] Optionally, the writeback agent can continuously listen for message input (i.e., writeback instructions) from the automated workflow engine. When a writeback instruction is received, the writeback agent will submit a status update completion feedback to the NFT contract module.

[0139] Optionally, after receiving the write-back instruction from the automated workflow engine, the write-back agent parses the instruction. Based on the target digital asset information, updated status, and other content contained in the instruction, combined with its own business logic and configuration, the write-back agent generates a status update completion feedback. For example, the write-back agent can extract the unique identifier of the target digital asset and the updated status value from the write-back instruction, then add the current timestamp, and decide whether to add related business information based on business needs, ultimately combining them into a complete status update completion feedback.

[0140] Optionally, the write-back agent can send status update completion feedback information to the NFT contract module according to the communication protocol and interface specifications agreed upon in advance with the NFT contract module.

[0141] S403. Through the NFT contract module, respond to the status update completion feedback and output a status update completion prompt.

[0142] Optionally, the status update completion notification can be a message that shows the user or other systems that the status of the target digital asset has been successfully updated. It can be any one or more forms such as text prompts, pop-up notifications, and log records.

[0143] Optionally, the NFT contract module can have its own logic for handling received state update completion feedback. When the NFT contract module receives state update completion feedback submitted by the write-back agent through its communication interface, it will trigger the corresponding processing function. For example, a specific function can be defined in the smart contract code to handle feedback information. When a transaction or request calling this function arrives, the contract will execute the corresponding logic.

[0144] The NFT contract module displays a status update completion notification message in an appropriate manner based on pre-defined rules and configurations. For example, if displayed in a blockchain explorer or related management interface, the NFT contract module may write the notification message to the blockchain's event log, and the front-end interface obtains and displays the notification message by listening to blockchain events.

[0145] In one implementation, the NFT contract module can verify whether the write-back agent is an authorized relay agent, obtain the verification result, and then, in response to the verification result indicating that the write-back agent is an authorized relay agent and the status update completion feedback indication is the target status, send a status update completion prompt to the user terminal.

[0146] Optionally, authorized relay agents can be write-back agents pre-authorized by the NFT contract module, qualified to act as intermediaries submitting status update completion feedback and other information to the NFT contract module. Only feedback submitted by authorized write-back agents will be recognized and processed by the NFT contract module. This is to ensure the reliability and security of the data source and prevent malicious or unauthorized agents from interfering with the normal state management of NFTs. For example, the NFT contract module can authorize several specific servers or services as relay agents to submit feedback.

[0147] A user terminal can be a device or software used to receive information and interact, such as mobile phones, computer applications, web browsers, or any one or more of these.

[0148] Optionally, the NFT contract module pre-stores relevant information about authorized relay agents, such as the agent's unique identifier (which may be a public key, address, etc.). When a status update submission from a write-back agent is received, the NFT contract module extracts the write-back agent's identifier from the feedback information and compares it with the pre-stored list of authorized agent identifiers. If a matching identifier is found, the write-back agent is determined to be an authorized relay agent, and the verification result is passed; otherwise, it is determined to be an unauthorized agent, and the verification result is failed.

[0149] When the verification result is detected as passed (i.e., the write-back agent is an authorized relay agent), and the status of the status update completion feedback indication is consistent with the pre-set target status, the NFT contract module will trigger the corresponding processing logic, that is, according to the pre-configured rules, determine to send a status update completion prompt to the user terminal.

[0150] Optionally, the NFT contract module can record the notification information as event data on the blockchain, and the user terminal can obtain the status update completion notification by listening to blockchain events. Alternatively, the NFT contract module can call an external service interface, which will then send the status update completion notification to the user terminal.

[0151] This application embodiment ensures the authenticity and reliability of status update prompts by verifying the authorization of the write-back agent and the accuracy of the status update completion feedback, thereby improving system security and user trust and preventing illegal operations and misleading prompts.

[0152] This application embodiment achieves reliable feedback and prompts on state update results through the interaction between the write-back agent and the NFT contract module, improving the closed-loop control capability and user experience of the system, and ensuring the integrity and traceability of state updates.

[0153] In existing technologies, cross-chain synchronization requires full block transaction verification and the transmission of all transaction data via a cross-chain bridge, resulting in low synchronization efficiency and susceptibility to state discrepancies due to network latency or node failures. Therefore, the following section provides a detailed explanation of how to achieve cross-chain synchronization when a digital asset state machine system is deployed on the first blockchain.

[0154] Figure 5 This is a flowchart illustrating a cross-chain synchronization method provided in an embodiment of this application, as shown below. Figure 5 As shown, the process includes:

[0155] S501. If the target digital asset meets the state transition conditions corresponding to the target state, generate a state increment package. The state increment package includes: incremental data, and Merkel proof data of the state change of the target digital asset. The incremental data is the incremental data generated when the target digital asset changes from the current state to the target state.

[0156] Optionally, the state increment package can be a dataset used to record changes in the target digital asset as it transitions from its current state to the target state. The increment data can be the specific changes that occur during the transition from the current state to the target state.

[0157] Merkle proof data can be a type of data proof generated based on a Merkle tree structure, which can be used to prove the existence and integrity of a data block in the Merkle tree. In the embodiments of this application, Merkle proof data can be used to verify whether incremental data truly exists in the original data set and has not been tampered with during the synchronization of state incremental packets.

[0158] Optionally, determining whether the target digital asset meets the state transition conditions corresponding to the target state is consistent with step S103 above, and will not be repeated here. The digital asset state machine system can calculate the changed parts by comparing the attribute values ​​of the target digital asset in the current state and the target state, and organize and encapsulate these changed data according to a predetermined format. For example, data structures in programming languages ​​(such as dictionaries, lists, etc.) can be used to store incremental data, facilitating subsequent processing and transmission.

[0159] Optionally, the Merkel proof data for the state change of the target digital asset can be obtained by first constructing a Merkel tree of the relevant data of the target digital asset. All relevant data of the target digital asset (including data for the current state and the target state) is divided into multiple data blocks. A hash calculation is performed on each data block, and these hash values ​​are then progressively combined according to the structure of the Merkel tree to obtain the root hash value. When generating the state increment packet, based on the position of the increment data in the original dataset, the corresponding Merkel proof path (i.e., all hash values ​​on the path from the data block containing the increment data to the root hash value) is extracted. These hash values ​​along with the root hash value are then included in the state increment packet as Merkel proof data.

[0160] S502. Generate a synchronization request that includes a state increment packet.

[0161] Optionally, a synchronization request can be used to transmit data between different blockchains to achieve data synchronization. It may include a state increment packet and some control information, such as the sender, receiver, and request type. The purpose of a synchronization request is to enable the receiver to obtain the sender's state change information and update its own data state, maintaining data consistency.

[0162] Alternatively, the digital asset state machine system can use programming languages ​​and related network communication libraries to construct synchronization requests according to a predetermined protocol format.

[0163] S503, Send a synchronization request to the second blockchain to synchronize the state increment packet of the second blockchain.

[0164] Optionally, the second blockchain can be a different blockchain network from the current blockchain that generates the state increment packet and sends the synchronization request, and it needs to maintain consistency with the current blockchain regarding the state of the target digital asset. Optionally, the current blockchain can send a synchronization request to the second blockchain via a communication protocol.

[0165] This application embodiment achieves rapid synchronization and consistency maintenance of digital asset states between different blockchains by generating state increment packets and synchronizing them across chains, thereby improving the efficiency and reliability of cross-chain applications and reducing the computational load and time consumption caused by full block transaction verification.

[0166] Before sending the synchronization request to the second blockchain, this embodiment of the application may also detect the state of the second blockchain. The state includes at least one of the following: network connectivity with the first blockchain, the necessity assessment result for synchronizing state increment packets with the second blockchain, and the resource reserve assessment result of the second blockchain. When the state of the second blockchain meets the data packet synchronization conditions, a synchronization request is sent to the second blockchain.

[0167] Optionally, network connectivity can be the ability for the first blockchain and the second blockchain to communicate normally over the network, which may include any one or more of the following: network connection stability, data transmission reliability, etc.

[0168] The necessity assessment for synchronizing state increment packets to the second blockchain can be a conclusion drawn from evaluating whether it is necessary to send state increment packets to the second blockchain. The assessment considers various factors, such as the degree of difference between the current state of the digital asset on the second blockchain and that on the first blockchain, and business logic requirements. If the assessment determines that synchronization is necessary, it means that the state of the digital asset on the second blockchain needs to be updated to be consistent with that of the first blockchain; if it determines that it is unnecessary, then no synchronization operation is required.

[0169] The resource reserve assessment result of the second blockchain can be the result of evaluating the resource status of the second blockchain, which may include any one or more of the following: computing resources, storage resources, network bandwidth, etc. Optionally, the digital asset state machine system can use existing technologies to detect the state of the second blockchain, which will not be elaborated here.

[0170] This application embodiment ensures the validity and timeliness of synchronization requests by detecting the state of the second blockchain and evaluating synchronization conditions, avoiding invalid synchronization and resource waste, improving the efficiency and success rate of cross-chain synchronization, and enhancing the stability and robustness of the system.

[0171] For example, taking the aforementioned digital assets as digital collectibles and the automated workflow engine as the n8n workflow, this application proposes a blockchain digital collectible cross-chain state synchronization system based on a state machine and the n8n workflow. The lifecycle of the digital collectible is modeled as a refined state machine, the n8n workflow engine handles cross-system automated logic, and an innovative state increment synchronization mechanism achieves efficient cross-chain state synchronization. The digital collectible state machine system adopts a layered architecture design, consisting of a blockchain state machine layer, an n8n workflow engine layer, a cross-chain synchronization layer, and an application interface layer. This layered architecture ensures clear responsibilities for each component, enabling both independent evolution and collaborative work, meeting the management needs of digital collectibles in complex multi-chain environments.

[0172] The digital collection state machine design in this embodiment is based on finite state machine theory, and the constraint rules for each state of the state machine are as follows:

[0173] 1. Initial State: The data structure of digital collectibles has just been established, but they are not yet linked to real assets. In this state, digital collectibles only exist as metadata and cannot be traded or transferred.

[0174] 2. Binding Status: The digital collectible has been bound to a real-world asset (such as physical artwork or collectibles). This binding information is recorded on the blockchain using a hash value, ensuring authenticity and verifiability.

[0175] 3. Transaction Status: Digital collectibles can be traded on the secondary market, but they are not yet eligible to be redeemed for real assets. Under this status, digital collectibles can change hands multiple times, and their status changes frequently.

[0176] 4. Locked Status: Digital collectibles are locked on digital asset platforms and are typically used for specific scenarios (such as exhibitions or mortgages), but they can still be traded in digital asset trading centers.

[0177] 5. Frozen Status: At the client's request, the digital collectible has been temporarily frozen and cannot be traded or cashed out. This status usually requires administrator privileges or multi-signature to trigger.

[0178] 6. Redemption Status: Digital collectibles are being redeemed for corresponding real assets. This process usually involves off-chain logistics or service delivery and requires special monitoring.

[0179] 7. Destruction Status: The digital collectible has completed its lifecycle. The relevant records are permanently stored on the blockchain for querying, but the asset itself is no longer usable.

[0180] State transitions are jointly managed by predefined rules and the n8n workflow. When a triggering event (such as a transaction request, administrator operation, or external event) occurs, the n8n workflow verifies the transition conditions, executes the relevant business logic, and finally realizes the state transition through a smart contract call.

[0181] The n8n workflow engine designed in this invention implements the following functions:

[0182] Multi-source event listening: Listen to multiple event sources through Webhook (an interactive mechanism) nodes.

[0183] Complex condition judgment: Execute complex business logic using function nodes.

[0184] Artificial Intelligence (AI) Enhances Decision Making: Integrates AI assistant nodes to provide intelligent analysis capabilities.

[0185] Cross-system collaboration: Interact with external systems through a rich set of connectors.

[0186] Figure 6 A schematic diagram of the layered architecture of a digital collection state machine system provided in this application embodiment is shown below. Figure 6 As shown, the layered architecture of the digital collection state machine system includes an on-chain layer, an off-chain layer, and a cross-chain layer. Each part will be described in detail below.

[0187] On-chain layer: Consists of a set of NFT contracts and state machine registry contracts; In addition to metadata, the NFT contracts have three additional fields: stateMachineId (state machine identifier), currentState (current state), and stateData (state data); The state machine registry contract stores the "state machine definition" bytecode and a list of "legal transfer functions", allowing the community to upload and ensuring version control.

[0188] The off-chain layer includes: an event listening layer: light nodes or decentralized data query protocol (TheGraph) subgraphs continuously scan on-chain events and push them to the message bus; an n8n instance cluster: encapsulates modules such as "state machine registry calls", "NFT metadata read and write", "InterPlanetary File System (IPFS) gateway", and "email / SMS / WeChat" through community nodes (custom-nodes); a state machine engine: runs on a deterministic finite state machine (DFSM) model, with on-chain events + off-chain context as input and "new state + list of off-chain tasks to be executed" as output; an execution gateway: converts the task list into representational state transfer (REST) ​​calls to the n8n workflow, supporting serial, parallel, conditional branching, and manually reviewed nodes; and a write-back proxy: after completing off-chain tasks, writes the new state back to the chain, achieving an on-chain-off-chain closed loop.

[0189] The cross-chain layer includes: the source chain registry master contract and the target chain mirror contract.

[0190] like Figure 6 As shown by the arrow, the main chain state transition process is as follows: When a user triggers a "lock" operation on the DApp frontend, the blockchain frontend calls the NFT contract's lock() function. The NFT contract queries the state machine registry to verify whether the "Normal→Locked" transition is valid. If the verification is successful, the state is updated and a StateTransfer (state update) event is thrown. The event listening service captures the event and pushes it to n8n. The n8n workflow executes to send an email notification to the user and broadcast it. After the task is completed, n8n calls the write-back agent to submit the meta-transaction and mark the on-chain task as completed.

[0191] The cross-chain synchronization process is explained in detail below. Figure 7 This is a schematic diagram of cross-chain synchronization provided in an embodiment of this application, such as... Figure 7 As shown, the StatePacket transmitter and StatePacket receiver are dedicated state machine synchronization components. They are deployed on the main chain and other chains via plug-ins and are specifically responsible for sending and receiving state update-related operations, actively handling state events, and synchronizing them to the corresponding chains.

[0192] When the main chain NFT contract state changes to "Cross-Chain Locked", the StatePacket transmitter generates data packets, which can be achieved through the following code:

[0193] {

[0194] stateRoot: 0xabc...,

[0195] nftId: 42,

[0196] newState: "Foreign Normal",

[0197] proof: 0xdef...,

[0198] srcBlockNumber: 18000000

[0199] }

[0200] Assuming Chain 2 is the Binance Coin (BNB) chain, data is sent to the BNB chain via LayerZero (a full-chain interoperability protocol). The BNB chain mirror contract verifies the proof and updates the state to "Foreign Normal". Users can then participate in modifying, buying and selling digital collectibles on the BNB chain (with state changes driven by a state machine engine).

[0201] It should be noted that Figure 7 The Cross-Chain Interoperability Protocol (CCIP) enables data and asset interoperability between different blockchains. ExitProof is used to verify the legitimacy of migrating assets or states from one chain to another.

[0202] Figure 8 This application provides a schematic diagram of a process for changing the status of a digital collection, as illustrated in the embodiments of this application. Figure 8 As shown, digital collectible status change events include: trigger source identification (user operations such as purchase, transfer, gift, etc.), automatic system triggers (timed tasks, condition fulfillment, etc.), administrator operations (freezing, unlocking, special handling, etc.), external events (cross-chain requests, external system calls, etc.), event classification (classifying and marking events according to their type, distinguishing their urgency and scope of impact), priority assessment (determining the urgency of event handling and allocating corresponding computing resources), etc.

[0203] The n8n workflow engine includes: workflow routing (selecting the corresponding workflow template based on the event type and dynamically loading the corresponding processing logic), resource initialization (allocating computing resources and establishing a processing context environment), parameter parsing (extracting key parameters from the event, parsing metadata information, and verifying parameter format and integrity), and permission verification (verifying the operation permissions of the event initiator, checking the validity of the access token, and confirming the operation scope restrictions).

[0204] The step event listening and parsing engine includes: multi-source listening (Webhook nodes listen for blockchain events, Application Programming Interface (API) endpoints receive external system requests, timers trigger periodic checks, and message queues process batch events), data standardization (data cleaning and formatting), integrity verification, and malicious filtering.

[0205] State transition condition verification includes: state confirmation, transition rule checking, business logic verification (ownership verification, time constraint verification, dependency condition verification), and resource availability verification.

[0206] Constructing a Merkel proof includes: data structure organization, proof generation (generating Merkel proofs for state changes, constructing corresponding path proofs, and generating integrity verification data), cryptographic signature, and proof packaging.

[0207] Parallel Synchronization Requests: After the target chain status is checked (network connectivity, chain status query, synchronization necessity assessment, resource preparation), a state increment packet is generated (the increment data and proof are packaged into a synchronization packet, synchronization-related metadata information is added, the data packet is serialized into a transmission format, and sensitive data is encrypted for protection). Multiple reliable target chain nodes are selected, and after evaluating the performance and reliability of the nodes, synchronization requests are sent to the selected nodes in parallel.

[0208] The target chain verification process includes: proof verification, signature verification, state consistency check, and business rule verification. After successful verification, a state update operation is performed on the target chain. After the transaction confirmation result is verified, the local state record is updated, and the synchronization transaction is marked as completed. If the verification fails, the occupied system resources are released, and a response containing error information is generated.

[0209] Figure 9 A flowchart illustrating an on-chain and off-chain state synchronization sequence provided in this application embodiment is shown below. Figure 9 As shown, the process includes:

[0210] The application for state transition includes: the user selects the collection operation to be performed (such as "lock", "unlock", "cross-chain") through the DApp front end, the front end assembles the transaction parameters and calls the corresponding function (lock / unlock / crossChain) of the NFT contract.

[0211] Transfer rule verification (on-chain rule verification) includes: After receiving the call, the NFT contract immediately queries the StateMachineRegistry for the transfer rules between the current state and the target state. The registry returns "allow / deny" and the required conditions (such as fees, permissions, freeze duration, etc.). If the verification is successful, the NFT contract rewrites the currentState field to the target state and throws the StateTransfer event.

[0212] Event listening and pushing include: the event listening layer captures StateTransfer events in real time, parses and formats them into JSON, and pushes the parsed messages to the internal message bus for n8n to subscribe to.

[0213] The n8n workflow engine includes: After receiving a message, the n8n NFT State Transfer trigger node starts a pre-arranged workflow; the data conversion node extracts the tokenId, fromState, and toState; the condition branch node makes judgments (toState == Locked, physical asset frozen; toState == Unlocked, physical asset unfrozen; toState == Cross-Chain gateway); calls off-chain service nodes to broadcast state changes and send notifications; and after the workflow is completed, n8n generates a write-back instruction.

[0214] The writeback agent submits a meta-transaction to update the status, including: after verifying the signature validity, the writeback agent submits a writeBack meta-transaction to the NFT contract. The NFT contract verifies that it is an authorized relayer and that the current status is consistent with the request, and throws a StateWritten event. After the DApp frontend listens to the StateWritten event, it updates the local user interface (UI) to show the user "State transfer completed" and information such as the off-chain business order number and email tracking link. At this point, the on-chain-off-chain-cross-chain closed loop is completed, and the entire process is auditable, rollbackable, and monitorable.

[0215] Figure 10 This application provides a flowchart illustrating a cross-chain condition determination process, as shown in the embodiments below. Figure 10 As shown, the process includes:

[0216] Cross-chain event listening includes: nodes deployed on each chain continuously scanning for CrossChainStateSynced (cross-chain state synchronization completed) events. The listener encapsulates the events into a unified JSON (including block number, block time, and transaction hash) and pushes it to the internal message bus. After message filtering and condition judgment, the subsequent workflow continues.

[0217] The timeout timer activation process includes: after successfully writing the mirror state, n8n starts a timeout timer through a waiting node. The timer waits for the on-chain SyncFinalized (synchronization completed) event or a manual callback. If the SyncFinalized event is received within the set time, n8n cancels the timer and continues. If no confirmation is received within the time, it enters an automatic rollback, calls the mirror contract, and reverts the NFT state to the previous stable state.

[0218] In summary, the technical effects of the embodiments of this application are as follows:

[0219] This application designs a sophisticated state machine model that can accurately describe the state transitions of digital collectibles throughout their entire lifecycle, from creation, binding, trading to destruction, and supports state management under complex business rules. It solves the problem of complex state modeling where traditional digital collectible state models are too simplistic and cannot accurately express the subtle state differences of digital collectibles in diverse application scenarios.

[0220] This application adopts a state incremental synchronization mechanism, which only synchronizes state change data instead of the entire transaction history, significantly reducing the amount of computation and time consumed in the synchronization process; it improves the efficiency of cross-chain state synchronization and solves the inefficiency problem caused by the need to perform full block transaction verification in traditional cross-chain synchronization.

[0221] This application integrates the n8n workflow automation platform with a blockchain state machine to achieve condition-triggered state transitions based on complex events and external system states, thereby realizing cross-system automated workflows and solving the problem that changes in the state of digital collectibles rely on manual triggering or simple rules.

[0222] This application uses a multi-operation node collaborative verification and Merkel proof verification mechanism to ensure the atomicity of state changes between the main chain and side chains, prevent state divergences caused by partial node failures or network anomalies, and solve the problem of potential inconsistencies in the state of digital collectibles on multiple blockchains.

[0223] The above are the method embodiments provided in this application. The apparatus provided in this application will be described below.

[0224] Figure 11 A schematic diagram of a digital asset status update device provided in this application is shown below. Figure 11As shown, the digital asset status update device 600 provided in this embodiment includes: a receiving module 601, a verification module 602, and an execution module 603. Optionally, the digital asset status update device 600 may further include a processing module 604.

[0225] The receiving module 601 is used to receive a status update request, which includes the target state to which the target digital asset needs to be updated.

[0226] Verification module 602 is used to verify whether the target digital asset meets the state transition conditions corresponding to the target state based on the state machine registry.

[0227] The execution module 603 is used to execute a state update request when the target digital asset meets the state transition conditions corresponding to the target state, so as to update the state of the target digital asset to the target state.

[0228] Optionally, the digital asset state machine system further includes: a non-fungible token (NFT) contract module. The verification module 602 is specifically used to query the state machine registry for the state transition conditions between the current state and the target state of the target digital asset. The NFT contract module receives the state transition conditions returned by the state machine registry, as well as an instruction on whether to allow the state transition. In response to the instruction indicating that the state transition is allowed, the module verifies whether the target digital asset meets the state transition conditions.

[0229] For example, the digital asset state machine system also includes an event listening layer and an automated workflow engine. The execution module 603 is specifically used to send a state transition event to the event listening layer based on a state update request, through the NFT contract module, when the target digital asset meets the state transition conditions corresponding to the target state. The event listening layer captures the state transition event and converts it into a preset format to obtain a message to be processed. The event listening layer pushes the message to be processed to the automated workflow engine. The automated workflow engine, in response to the message to be processed, updates the state of the target digital asset to the target state.

[0230] In one embodiment, the digital asset state machine system further includes an execution gateway, wherein the execution module 603 is specifically used to initiate a pre-arranged workflow in response to a pending message through an automated workflow engine; the workflow includes: calling the execution gateway and updating the state of the target digital asset to the target state through the execution gateway.

[0231] For example, the digital asset state machine system further includes a write-back agent. The processing module 604 generates a write-back instruction through the automated workflow engine after the workflow execution is complete, and sends the write-back instruction to the write-back agent. The write-back instruction indicates that the state update of the target digital asset is complete. In response to the write-back instruction, the write-back agent submits state update completion feedback to the NFT contract module. In response to the state update completion feedback, the NFT contract module outputs a state update completion prompt.

[0232] In one implementation, the processing module 604 is specifically used to verify whether the write-back agent is an authorized relay agent through the NFT contract module, and obtain a verification result. In response to the verification result indicating that the write-back agent is an authorized relay agent and the status update completion feedback indication being the target status, the NFT contract module sends a status update completion prompt to the user terminal.

[0233] Optionally, the digital asset state machine system is deployed on the first blockchain. The processing module 604 is further configured to generate a state increment package when the target digital asset meets the state transition conditions corresponding to the target state. The state increment package includes incremental data and Merkel proof data for the state change of the target digital asset. The incremental data is the incremental data generated when the target digital asset changes from its current state to the target state. A synchronization request including the state increment package is generated. A synchronization request is sent to the second blockchain to synchronize the state increment package.

[0234] For example, before sending a synchronization request to the second blockchain, the processing module 604 also detects the state of the second blockchain. The state includes at least one of the following: network connectivity with the first blockchain, the necessity assessment result for synchronizing state increment packets with the second blockchain, and the resource reserve assessment result of the second blockchain. Specifically, the processing module 604 sends a synchronization request to the second blockchain when the state of the second blockchain meets the data packet synchronization conditions.

[0235] The digital asset status update device provided in this embodiment can execute the methods provided in any of the above method embodiments. The implementation principle and technical effect are similar, and will not be described in detail here.

[0236] Figure 12 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 12 As shown, the electronic device 700 provided in this embodiment includes at least one processor 701 and a memory 702. Optionally, the device 700 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus 704.

[0237] In a specific implementation, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to perform the above-described method.

[0238] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0239] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0240] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0241] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0242] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0243] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0244] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0245] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0246] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0247] The units described as separate components may or may not be physically separate. The components shown 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0248] In addition, the functional units in the various embodiments of this application 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.

[0249] If a function 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 application, in essence, or the part that contributes to the prior art, or a 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.) to execute all or part of the steps of the methods of the various embodiments of this application. 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.

[0250] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0251] Finally, it should be noted that other embodiments of this application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes may be made without departing from its scope.

Claims

1. A method for updating the state of digital assets, characterized in that, The method is applied to a digital asset state machine system, which includes a state machine registry, comprising multiple states and state transition conditions. The method includes: Receive a status update request, the status update request including the target state to which the target digital asset needs to be updated; Based on the state machine registry, verify whether the target digital asset meets the state transition conditions corresponding to the target state; If the target digital asset meets the state transition conditions corresponding to the target state, the state update request is executed to update the state of the target digital asset to the target state.

2. The method according to claim 1, characterized in that, The digital asset state machine system further includes a non-fungible token (NFT) contract module. The step of verifying whether the target digital asset meets the state transition conditions corresponding to the target state, based on the state machine registry, includes: The NFT contract module queries the state machine registry for the state transition conditions between the current state and the target state of the target digital asset. The NFT contract module receives the state transition conditions returned by the state machine registry, as well as instructions on whether to allow the state transition. In response to the instruction indicating permission for a state transition, the system verifies whether the target digital asset meets the state transition conditions based on the state transition conditions.

3. The method according to claim 2, characterized in that, The digital asset state machine system further includes: an event listening layer, and an automated workflow engine. The step of executing the state update request when the target digital asset satisfies the state transition conditions corresponding to the target state includes: When the target digital asset meets the state transition conditions corresponding to the target state, the NFT contract module sends a state transition event to the event listening layer based on the state update request. The event listening layer captures the state transition event and converts it into a preset format to obtain the message to be processed. The event listener layer pushes the message to be processed to the automated workflow engine. The automated workflow engine updates the state of the target digital asset to the target state in response to the pending message.

4. The method according to claim 3, characterized in that, The digital asset state machine system further includes: an execution gateway, which, in response to the pending message, updates the state of the target digital asset to the target state via the automated workflow engine, including: The automated workflow engine initiates a pre-arranged workflow in response to the pending message; the workflow includes: invoking the execution gateway and updating the state of the target digital asset to the target state through the execution gateway.

5. The method according to claim 4, characterized in that, The digital asset state machine system further includes: a write-back agent, and the method further includes: After the workflow is completed, the automated workflow engine generates a write-back instruction and sends the write-back instruction to the write-back agent; the write-back instruction is used to indicate that the status update of the target digital asset is complete. Through the write-back proxy, in response to the write-back instruction, a status update completion feedback is submitted to the NFT contract module; The NFT contract module responds to the status update completion feedback by outputting a status update completion prompt.

6. The method according to claim 5, characterized in that, The step of the NFT contract module responding to the status update completion feedback by outputting a status update completion prompt includes: The NFT contract module is used to verify whether the write-back agent is an authorized relay agent, and the verification result is obtained. In response to the verification result indicating that the write-back agent is an authorized relay agent and the status of the status update completion feedback indication being the target status, the NFT contract module sends a status update completion prompt to the user terminal.

7. The method according to any one of claims 1-6, characterized in that, The digital asset state machine system is deployed on the first blockchain, and the method further includes: If the target digital asset satisfies the state transition conditions corresponding to the target state, a state increment package is generated; the state increment package includes: incremental data, and Merkel proof data of the state change of the target digital asset; the incremental data is the incremental data generated when the target digital asset changes from the current state to the target state; Generate a synchronization request that includes the state increment packet; The synchronization request is sent to the second blockchain to enable the second blockchain to synchronize the state increment packet.

8. The method according to claim 7, characterized in that, Before sending the synchronization request to the second blockchain, the method further includes: The state of the second blockchain is detected; the state includes at least one of the following: network connectivity with the first blockchain, the necessity assessment result of synchronizing state increment packets to the second blockchain, and the resource reserve assessment result of the second blockchain; Sending the synchronization request to the second blockchain includes: When the state of the second blockchain meets the data packet synchronization conditions, the synchronization request is sent to the second blockchain.

9. A digital asset status update device, characterized in that, The device is applied to a digital asset state machine system, which includes a state machine registry, comprising multiple states and state transition conditions. The device includes: The receiving module is used to receive a status update request, wherein the status update request includes the target status to which the target digital asset needs to be updated; The verification module is used to verify, based on the state machine registry, whether the target digital asset meets the state transition conditions corresponding to the target state; An execution module is configured to execute the state update request when the target digital asset meets the state transition conditions corresponding to the target state, so as to update the state of the target digital asset to the target state.

10. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-8.

12. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.

Images