Systems and methods for blockchain-based notifications

Abstract

Methods, systems, and apparatus, including computer programs encoded on computer storage media, for blockchain-based notifications are provided. One of the methods includes obtaining, from a computing device, a notification message indicating that a current state of a workflow is one of one or more states of the workflow, wherein a blockchain contract deployed in a blockchain is executable to update the current state among the one or more states of the workflow; in response to the notification message, performing a function associated with the one state; and in response to completion of the function, sending a reply message to the computing device to indicate completion of the performance of the function associated with the one state.

Description

Technical Field

[0001] This application generally relates to systems and methods for blockchain-based notifications. Background Technology

[0002] Workflow management is often tedious and inefficient. For example, when a workflow involves multiple different stakeholders managing different stages, it may be necessary to notify a stakeholder of the completion of the previous stage so that they can begin their own stage. However, delegating notification tasks among stakeholders is typically unreliable and inefficient. The chance of errors increases exponentially with the number of stakeholders or the complexity of the workflow. Furthermore, significant resources are required to ensure that such workflow notifications are accurate and timely. Therefore, there is a need to develop effective and reliable systems and methods to improve workflow management.

[0003] Blockchain provides decentralized data storage by storing data in a series of sequentially related data blocks. The chain of blocks is maintained and updated by a network of blockchain nodes, which are also responsible for verifying the data under a consensus mechanism. The stored data can include many data types, such as purchase order status, financial transactions between parties, and historical access information.

[0004] The blockchain can be maintained and updated by adding blocks containing information about blockchain transactions. To store data on the blockchain, data can be included in blockchain transactions to be added to new blocks. Furthermore, many blockchains (e.g., the Ethereum blockchain) have enabled blockchain contracts (also known as smart contracts), which can be executed via blockchain transactions. For example, a blockchain transaction can include a signed message issued by an externally owned account (e.g., a blockchain account), sent by the blockchain network, and recorded on the blockchain. Blockchain contracts can be executed to implement programmed functions. Summary of the Invention

[0005] Various embodiments described herein include, but are not limited to, systems, methods, and non-transitory computer-readable media for blockchain-based notifications.

[0006] According to some embodiments, a computer-implemented method for blockchain-based notifications includes: obtaining from a computing device a notification message indicating that the current state of a workflow is one of one or more states of the workflow, wherein a blockchain contract deployed in the blockchain can be executed to update the current state in one or more states of the workflow; in response to the notification message, performing a function associated with a state; and in response to the completion of the execution of the function, sending a reply message to the computing device to indicate that the execution of the function associated with the one state has been completed.

[0007] In some embodiments, obtaining a notification message from a computing device indicating that the current state of a workflow is a state of the workflow includes: connecting to a message queue on the computing device to place the notification message; and obtaining the notification message from the message queue.

[0008] In some embodiments, this functionality can be configured by the subscribers of the state.

[0009] In some embodiments, the computing device is configured to: obtain information from one or more blocks of a blockchain to determine a current state; update a locally maintained state machine based on the determined current state; determine whether the updated state machine corresponds to the state; and in response to determining that the updated state machine corresponds to the state, generate a notification message for one or more subscribers who subscribe to the state.

[0010] In some embodiments, the locally maintained state machine includes one or more local states that are respectively mapped to one or more states; and one or more states are registered in the blockchain.

[0011] In some embodiments, the one or more local states are configured in a cyclic triggering flow; the cyclic triggering flow starts from a start local state in one or more local states, passes through each of the one or more local states once in one direction, until an end local state, and then returns to the start local state.

[0012] In some embodiments, one or more states are configured in another cyclic triggering flow; the other cyclic triggering flow starts from a start state in one or more states, passes through each of the one or more states in one direction at a time until an end state, and then returns to the start state; each of the one or more states is triggered by the completion of a previous state in the other cyclic triggering flow; and a start local state is mapped to the start state.

[0013] In some embodiments, the state can be configured to trigger flow avoidance from another loop in response to a notification to deactivate the state; and a local state mapped to the state can be configured to trigger flow avoidance from the loop in response to a notification to deactivate the state.

[0014] In some embodiments, the state may be configured to be restored in another cyclic trigger stream in response to a notification that the state is re-enabled; and the local state mapped to the state may be configured to be restored in the cyclic trigger stream in response to a notification that the state is re-enabled.

[0015] In some embodiments, each of one or more states may be configured by a subscriber of one or more substates to include the one or more substates; the method further includes: establishing an association between the subscriber and one or more substates to send notifications associated with the one or more substates to the subscriber.

[0016] In some embodiments, one or more substates form a cyclic triggering flow; one or more states are public to one or more subscribers; and one or more substates are private to the subscribers of one or more substates.

[0017] In some embodiments, sending a response message to a computing device to indicate the completion of the execution of a function associated with the state includes: sending an update of the state to the computing device so that the computing device begins to obtain information from the blockchain to re-determine the current state.

[0018] In some embodiments, sending a response message to a computing device to indicate the completion of the function associated with the state includes: sending a response message to the computing device to cause the computing device to generate a blockchain transaction for updating the state, and sending the blockchain transaction to one or more blockchain nodes to be added to the blockchain, thereby causing the current state of the workflow to be updated to the state after that state.

[0019] According to some embodiments, a system for blockchain-based notifications includes: one or more processors and one or more computer-readable storage devices coupled to the one or more processors and storing instructions thereon, the instructions being executable by the one or more processors to perform the method described in any of the foregoing embodiments.

[0020] According to some embodiments, an apparatus for blockchain-based notification includes multiple modules for performing the method described in any of the foregoing embodiments.

[0021] According to some embodiments, a non-transitory computer-readable medium storing instructions that, when executed by a processor of a device, cause the device to perform any of the methods described in the foregoing embodiments.

[0022] According to other embodiments, a system for blockchain-based notifications includes one or more processors and one or more non-transitory computer-readable storage devices, said one or more non-transitory computer-readable storage devices being coupled to the one or more processors and configured to have instructions executable by said one or more processors to cause the system to perform operations, including: obtaining from a computing device a notification message indicating that the current state of a workflow is one of one or more states of the workflow, wherein a blockchain contract deployed in the blockchain can be executed to update the current state in one or more states of the workflow; in response to the notification message, performing a function associated with the state; and in response to the completion of said function execution, sending a reply message to the computing device to indicate the completion of said function execution associated with said state.

[0023] According to other embodiments, a non-transitory computer-readable storage medium for blockchain-based notifications is configured with instructions executable by one or more processors to cause the one or more processors to perform operations, including: obtaining from a computing device a notification message indicating that the current state of a workflow is one of one or more states of the workflow, wherein a blockchain contract deployed in the blockchain can be executed to update the current state in one or more states of the workflow; in response to the notification message, performing a function associated with the state; and in response to the completion of the function, sending a reply message to the computing device to indicate the completion of the function associated with the state.

[0024] According to some other embodiments, an apparatus for blockchain-based notification may include: an acquisition module for acquiring from a computing device a notification message indicating that the current state of a workflow is one of one or more states of the workflow, wherein a blockchain contract deployed in the blockchain can be executed to update the current state in one or more states of the workflow; a processing module for performing a function associated with the state in response to the notification message; and a sending module for sending a reply message to the computing device in response to the completion of the function to indicate the completion of the function associated with the state.

[0025] The embodiments disclosed herein have one or more technical effects. In some embodiments, a service provider can provide and manage convenient blockchain-based message subscriptions and notifications. In one embodiment, a blockchain contract including one or more states of a workflow is deployed in the blockchain and can be executed to update the current state in the one or more states, and the service provider can record subscribers to any of the states and maintain a local state machine mapped to the current state. Therefore, the service provider can keep the workflow progress up-to-date to notify subscribers. In some embodiments, by subscribing to the state of the workflow, participants in the workflow no longer have to constantly obtain information from blockchain blocks to determine progress. In one embodiment, participants can automatically receive notifications through message queues they have subscribed to that are related to their relevant states, without having to filter information from irrelevant states. In one embodiment, based on the notification, corresponding execution steps for the relevant state can be automatically triggered and executed. In some embodiments, computational power is saved and workflow efficiency is improved. In some embodiments, workflow information is efficiently collected from participants, organized by the system, and distributed to the appropriate participants. In some embodiments, participants can intuitively enable notifications by subscribing to one or more states of the workflow and receive notification messages promptly when one or more states become the current state. In some embodiments, participants are also provided with customization options regarding the state to be subscribed to and the substates to be created and subscribed to. In one embodiment, privacy is provided for subscribers of the substate because the substates are private.

[0026] These and other features of the systems, methods, and non-transitory computer-readable media disclosed herein, as well as the operation and function of the related elements of the structure, the combination of components, and the economy of manufacture, will become clearer after considering the following description and appended claims with reference to the accompanying drawings, all of which form part of this document, wherein, in the various drawings, the same reference numerals denote corresponding parts. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not restrictive. Attached Figure Description

[0027] Figure 1 An environment for blockchain-based notifications is illustrated according to some embodiments.

[0028] Figure 2 A framework for blockchain-based notifications is shown according to some embodiments.

[0029] Figure 3A An interactive diagram for blockchain-based notifications is shown according to some embodiments.

[0030] Figure 3BA cyclic triggering flow for one or more local states of a local state machine is illustrated according to some embodiments.

[0031] Figure 3C The diagram illustrates a cyclically triggered flow for one or more states of a workflow, and corresponding functionality for blockchain-based notifications, according to some embodiments.

[0032] Figure 4A A flowchart is shown for a method for registering subscribing-able state in a blockchain, according to some embodiments.

[0033] Figure 4B A flowchart is shown for a method for registering subscribing substates in a blockchain, according to some embodiments.

[0034] Figure 4C A flowchart of a method for blockchain-based notifications according to some embodiments is shown.

[0035] Figure 4D A flowchart of a method for blockchain-based notifications according to some embodiments is shown.

[0036] Figure 5 A flowchart of a method for blockchain-based notifications according to some embodiments is shown.

[0037] Figure 6 A block diagram of an apparatus for blockchain-based notifications according to some embodiments is shown.

[0038] Figure 7 A block diagram of a computer system is shown, in which any of the embodiments described herein may be implemented. Detailed Implementation

[0039] In some embodiments, blockchain can be used to store the purchase-delivery status of online shopping and facilitate the sharing of status information among various participants. For example, an online purchase may involve a series of stages, such as: placing an order, retrieving the goods from a warehouse, delivering the goods from the warehouse to the recipient, and the recipient's confirmation. Sales, warehousing, and delivery can be managed by different participants, each depending on the "completion" status of the previous stage to begin their own. For example, a warehouse needs to know that the seller has accepted the order to begin its goods retrieval stage, while a delivery company needs to know that the goods have been retrieved from the warehouse to begin its loading, shipping, and delivery stages. Some stages may each include granular sub-stages. For example, the stage of delivering goods from the warehouse to the recipient may include sub-stages such as the delivery person receiving the goods and delivering the goods to a local facility. And the delivery company may want to know the progress within each sub-stage.

[0040] In some blockchain schemes, to determine whether to begin their own phase, participants in an online shopping event (such as sellers, warehousing, and delivery companies) must constantly retrieve information from blockchain blocks to check whether the previous phase or sub-phase has been completed. As a result, each participant in the online shopping event must frequently explore various blocks in the blockchain to update the purchase-delivery status. Much of this browsing information may even be meaningless to the participant initiating the query. Therefore, this process wastes significant computational resources, and the overall efficiency of the workflow is low. The system and method disclosed in this paper can improve workflow management in processes such as purchase-delivery.

[0041] Figure 1 An environment 100 for registering subscribing-able state in a blockchain, according to some embodiments, is illustrated. As shown, in environment 100, one or more client-side computing devices (e.g., 111a, 111b, 111c, 111d) can be coupled to server 118 via various communication networks. Server 118 can be coupled to one or more blockchain systems (e.g., 112, 113) via various communication networks. Each blockchain system can maintain one or more blockchains. Each blockchain can correspond to a unique blockchain ID. Additional computing devices can be coupled to each of the one or more blockchain systems. For example, blockchain user-side computing devices (e.g., 114a, 114b) can be coupled to blockchain system 112 via various communication networks.

[0042] In some embodiments, the client-side computing device (e.g., a computer, server, mobile phone, etc.) is not limited to a single device and may include one or more computing devices in a cluster. The client-side computing device may have dedicated software installed, such as message queue (MQ) service software for communicating with the server. This software may be embodied in software applications, software terminals, websites, etc. The client-side computing device may be implemented by an entity (e.g., an organization, company, enterprise, individual). This entity may be a participant in a workflow. For example, an entity may be involved in a part of the workflow and thus become a participant. As described herein, a participant can subscribe to the workflow state corresponding to that part of the workflow to receive notifications.

[0043] In some embodiments, blockchain system 112 may include multiple blockchain nodes (e.g., blockchain node 1, blockchain node 2, blockchain node 3, blockchain node 4, blockchain node i, etc.) that maintain one or more blockchains (e.g., public blockchain, private blockchain, consortium blockchain, etc.). Other blockchain systems (e.g., blockchain system 113, etc.) may include a similar arrangement of blockchain nodes for maintaining another blockchain. Each blockchain node can be found in one or more blockchain systems. Blockchain nodes may include full nodes. Full nodes can download each block and blockchain transaction and check it against the consensus rules of the blockchain. Blockchain nodes can form a network in which blockchain nodes communicate with each other. The order and number of blockchain nodes shown are merely illustrative examples. Blockchain nodes can be implemented in servers, computers, etc. For example, each blockchain node can be implemented in a server or server cluster. Server clusters may use load balancing. Each blockchain node may correspond to one or more physical hardware devices or virtual devices coupled together via various types of communication methods such as TCP / IP. Depending on the classification, blockchain nodes may also be referred to as full nodes, Geth nodes, consensus nodes, etc.

[0044] In some embodiments, the blockchain user-side computing device may include a light node. A light node may not be able to download the entire blockchain, but may instead download only the block headers to verify the authenticity of blockchain transactions. Light nodes may be served by full nodes (e.g., blockchain nodes in blockchain system 112) and effectively rely on full nodes to access more of the blockchain's functionality. Light nodes can be implemented in electronic devices such as laptops, mobile phones, etc., by installing appropriate software. In one embodiment, the blockchain user-side computing device may send blockchain transactions to blockchain system 112 to be added to the blockchain.

[0045] In some embodiments, server-side 118 can provide Blockchain as a Service (BaaS) and is referred to as the BaaS endpoint. In one embodiment, BaaS is a cloud service model in which clients or developers outsource the behind-the-scenes aspects of web or mobile applications. BaaS can provide pre-written software for activities occurring on the blockchain, such as subscriptions and notifications, user authentication, database management, and remote updates. The BaaS endpoint can be implemented in servers, server clusters, or other devices. In one embodiment, the BaaS endpoint provides enterprise-grade platform services based on blockchain technology. This service helps clients build secure and stable blockchain environments and easily manage the deployment, operation, maintenance, and development of blockchains. The service features high security, high stability, ease of use, and openness and sharing. Based on rich cloud security policies and multi-tenant isolation, the BaaS endpoint can provide advanced security protection using chip encryption technology. Based on highly reliable data storage, this service provides end-to-end and highly available services that can be rapidly scaled without interruption. The BaaS endpoint can provide enhanced management capabilities to help clients build enterprise-grade blockchain network environments. BaaS can provide native support for standard blockchain applications and data, supporting mainstream open-source blockchain technologies such as Hyperledger Fabric and Ethereum Enterprise Edition (Quorum) to build an open and inclusive technology ecosystem.

[0046] In environment 100, each system, node, and device may be equipped with appropriate software (e.g., application programming interface) and / or hardware (e.g., wired, wireless connectivity) to access other devices in environment 100. Typically, systems, nodes, and devices may be able to communicate with each other via one or more wired or wireless networks (e.g., the Internet), through which data can be communicated. Each of the systems, nodes, and devices may include one or more processors and one or more memories coupled to the one or more processors. The memory may be non-transitory and computer-readable, and configured with instructions executable by the one or more processors to facilitate the one or more processors in performing the operations described herein. The instructions may be stored in memory or downloaded via a communication network without necessarily being stored in memory. Although systems, nodes, and devices are shown as separate components in this figure, it should be understood that these systems, nodes, and devices may be implemented as a single device or multiple devices coupled together.

[0047] Server-side 118 and blockchain user-side computing devices may be equipped with appropriate blockchain software for initiating, forwarding, or accessing blockchain transactions. The term "blockchain transaction" can refer to a unit of task executed within the blockchain system and recorded in the blockchain upon verification. In some embodiments, server-side 118 may construct a blockchain contract based on information obtained from one or more client-side computing devices. Server-side 118 may add blockchain contracts to blockchain transactions. After server-side 118 submits a blockchain transaction to the blockchain system, blockchain nodes can verify the blockchain transaction to add it to the blockchain. If a blockchain transaction is added to the blockchain, the blockchain contract is deployed in the blockchain. In some embodiments, the deployed blockchain contract may include a workflow with one or more states. The current state of the workflow may be referred to as the current state. The deployed blockchain contract can be invoked to update the current state through one or more additional blockchain transactions.

[0048] Blockchain transactions can be verified according to consensus rules. For example, the Proof-of-Work (PoW) consensus process is provided below. Nevertheless, other types of consensus processes, such as Proof-of-Stake (PoS), Delegated Proof-of-Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT), can be similarly applied to the disclosed systems and methods.

[0049] In some embodiments concerning blockchain transaction verification, upon receiving an unconfirmed blockchain transaction request, the receiving blockchain node can perform preliminary verification of the blockchain transaction. For example, blockchain node 1 can perform preliminary verification after receiving the blockchain transaction from server 118. Once verified, the blockchain transaction can be stored in the database of the receiving blockchain node (e.g., blockchain node 1), which can also forward the blockchain transaction to one or more other blockchain nodes (e.g., blockchain node 2, blockchain node 3, blockchain node 4). Similarly, each blockchain node may include or be coupled to a storage device that stores the database. The database can store multiple unconfirmed blockchain transactions. After receiving a blockchain transaction, one or more other blockchain nodes can repeat the preliminary verification and broadcasting process performed by the receiving blockchain node.

[0050] To verify the blockchain, each node can select some blockchain transactions from the database based on its preferences and form them into a new block to be proposed to the blockchain. Blockchain nodes can "mine" these new blocks by contributing computing power to solve complex mathematical problems. If a blockchain transaction involves a blockchain contract, the blockchain node can execute the contract locally in the corresponding virtual machine (VM). To process blockchain contracts, each blockchain node in the blockchain network runs a corresponding VM and executes the same instructions within the blockchain contract. A VM is a software simulation of a computer system based on a computer architecture and provides the functionality of a physical computer. In the context of blockchain, a VM can be understood as a system designed to serve as the runtime environment for blockchain contracts.

[0051] A specific blockchain node that successfully mines a new block of proposed blockchain transactions according to the consensus rules can package the new block into a local copy of its blockchain and multicast the result to other blockchain nodes. This specific blockchain node could be one that first successfully completed verification, has acquired verification privileges, or has been selected based on another consensus rule. Other blockchain nodes can then locally execute the blockchain transactions in the new block, following the same execution order as the specific blockchain node, verifying the execution results with each other (e.g., by performing hash calculations), and synchronizing their blockchain copies with those of the specific blockchain node. By updating their local blockchain copies, other blockchain nodes can similarly write this information from the blockchain transactions into their corresponding local storage. Thus, blockchain contracts can be deployed on the blockchain. If verification fails at any point, the blockchain transaction is rejected.

[0052] Deployed blockchain contracts can have an address that allows access to the contract. A blockchain node can invoke a deployed blockchain contract by inputting certain parameters. In one embodiment, a deployed blockchain contract can be invoked to add or update certain information, thereby updating one or more states within the contract. In another embodiment, one or more states of a blockchain contract can be retrieved from the blockchain by querying the corresponding blockchain transactions added to the blockchain. The latest state can be reflected in the latest relevant blockchain transactions. While described above, other types of blockchain systems and associated consensus rules can be applied to the disclosed devices and methods.

[0053] Figure 2A framework for implementing blockchain transactions according to some embodiments is illustrated. In some embodiments, client-side computing device 111a may send information to server-side 118. In one embodiment, the information may include a request to register a workflow comprising one or more states in the blockchain. The blockchain may be maintained by blockchain system 112. To perform the registration, server-side 118 may construct a blockchain contract based on information obtained from client-side computing device 111a. Server-side 118 may add the blockchain contract to blockchain transaction A. Server-side 118 may sign the blockchain transaction on behalf of a user associated with client-side computing device 111a. For example, blockchain transaction A may include various information such as a random number (e.g., transaction sequence number), from (e.g., the user's blockchain address), to (e.g., empty if a blockchain contract is deployed), transaction fee, signature (e.g., the signature of server-side 118, the signature of users managed by server-side 118), value (e.g., transaction amount), data (e.g., blockchain contract), etc. Server-side 118 may then submit blockchain transaction A to one or more blockchain nodes of blockchain system 112 to add it to the blockchain.

[0054] After a blockchain transaction is added to the blockchain, a blockchain contract is deployed within the blockchain. The workflow within the deployed blockchain contract may be in one of the aforementioned states. For example, a workflow could include states 1, 2, and 3, and could begin at state 1. Therefore, the current state is state 1. The deployed blockchain contract can be invoked to update the current state via one or more additional blockchain transactions. For example, the deployed blockchain contract can be invoked to advance the workflow from state 1 to state 2, thereby changing the current state to state 2.

[0055] In some embodiments, a blockchain user-side computing device (e.g., blockchain user-side computing device 114a) can construct a signed blockchain transaction B and transmit it to the blockchain system 112 for execution. In one embodiment, blockchain transaction B can be executed to invoke a deployed blockchain contract. This invocation can update the current state of the workflow. In some embodiments, blockchain transaction B can be programmed in source code at a user-side application 221. For example, a user or machine can program blockchain transaction B. The blockchain user-side computing device can use a suitable compiler to compile the source code, which converts the source code into bytecode. Blockchain transaction B may include information such as a random number, source, destination, transaction fee, value, signature, data, etc. Blockchain user-side computing device 114a can send blockchain transaction B to one or more blockchain nodes of the blockchain system 112 via a remote procedure call (RPC) interface 223. RPC is a protocol that a first program (e.g., a user-side application) can use to request services from a second program located on another computer (e.g., a blockchain node) on a network without having to understand network details. When the first program causes a process to execute in a different address space, it appears as if it were coded as a normal (local) process call, without requiring the programmer to explicitly code the details of the remote interaction.

[0056] In some embodiments, upon receiving a blockchain transaction (e.g., blockchain transaction A or B), the receiving blockchain node can verify the validity of the blockchain transaction. For example, it can verify the signature and other formatting. If verification is successful, the receiving blockchain node can broadcast the received blockchain transaction to a blockchain network that includes various other blockchain nodes. Some blockchain nodes can participate in the mining process of blockchain transactions. Blockchain transactions can be selected by specific nodes for consensus verification and thus packaged into a new block. If the blockchain transaction involves deploying a blockchain contract, a specific node can create a contract account for the blockchain contract associated with a blockchain account address. If the blockchain transaction involves invoking a deployed blockchain contract, a specific node can trigger its local VM to execute the received blockchain transaction, thereby invoking the deployed blockchain contract from its local copy of the blockchain and updating the state in the deployed blockchain contract.

[0057] If a specific node successfully mines a new block, that node can broadcast the new block to other blockchain nodes. Upon receiving the new block, other blockchain nodes can perform verification. If consensus is reached on the validity of the new block, it is packaged into local copies of the blockchain maintained by the blockchain nodes. Blockchain nodes can similarly trigger their local VMs (e.g., local VM1, local VMi, local VM2) to execute blockchain transactions in the new block, thereby invoking and updating local copies of the blockchain (e.g., local blockchain copy 1, local blockchain copy i, local blockchain copy 2). Each blockchain node's hardware can access one or more virtual machines, which can be part of or coupled to the corresponding blockchain node. The corresponding local VM can be triggered each time to execute blockchain transactions. Similarly, all other blockchain transactions in the new block will be executed. Light nodes can also synchronize with the updated blockchain.

[0058] Figure 3A An interactive diagram for registering subscribing-able state in a blockchain is shown according to some embodiments. Figure 3B A cyclic triggering flow for one or more local states of a local state machine is illustrated according to some embodiments. Figure 3C A cyclically triggered flow for one or more states in a workflow, according to some embodiments, and corresponding functionality for registering subscribingable states in a blockchain are illustrated. The operation of the methods presented below is intended to be illustrative. Depending on the embodiment, the following steps may include additional, fewer, or alternative steps performed in various orders or in parallel. The order of the steps is also illustrative, as some orders may be switched or processed in parallel.

[0059] Reference Figure 3A In some embodiments, blockchain system 112 may include multiple blockchain nodes that maintain one or more blockchains (e.g., public blockchain, private blockchain, consortium blockchain, etc.). Although the following description uses a consortium blockchain as an example, other types of blockchains can be similarly applied to the embodiments described herein.

[0060] In one embodiment, a consortium blockchain refers to a blockchain where consensus processing is controlled by pre-configured nodes. The blockchain can allow access from anyone, or only permitted participants, or a hybrid access approach. For example, the root hash and its API (Application Programming Interface) can be made public, allowing external participants to use the API to perform a limited number of queries and obtain information related to the blockchain's state.

[0061] In one embodiment, consortium blockchains can be better understood when compared to their more general counterpart, public blockchains. Public blockchains have no access restrictions, meaning anyone with an internet connection can naturally participate. For example, anyone in the world can read the data contained in the blockchain, allowing anyone in the world to execute transactions on a public blockchain. Furthermore, there are no restrictions on who can participate in the blockchain's consensus process, which is the process of determining the individuals or entities that can add blocks to the blockchain. Public blockchains are considered completely decentralized, and control of the blockchain is not in the hands of any single individual or entity.

[0062] In one embodiment, a consortium blockchain differs from a public blockchain in that it is permissioned; therefore, not just anyone with an internet connection can access it. These types of blockchains can also be described as semi-decentralized. Control over a consortium blockchain is not granted to a single entity, but rather to a group of permitted individuals. Consensus processing in a consortium blockchain may differ from that in a public blockchain. Consensus participants in a consortium blockchain may be a pre-permitted group of nodes on the network, rather than anyone being able to participate in the process. Nodes can correspond to different countries, businesses, or other entities. Therefore, consortium blockchains possess the inherent security features of public blockchains while also allowing for a greater degree of control over the network.

[0063] In some embodiments, each participant in the workflow can access server 118 or one or more similar computing devices to obtain workflow information stored on the blockchain. The workflow may include ongoing events, changing situations, etc. A workflow may include a series of stages, where triggering of one stage depends on the preceding stage. In one embodiment, each state in one or more stages of the workflow can transition from one state to another. For example, a workflow may include an online purchase event that includes stages from placing an order to retrieving goods from a warehouse, then to delivering the goods from the warehouse to the recipient, and finally to recipient confirmation. For example, the warehouse needs to know that an order has been placed to begin its goods retrieval stage, while the delivery company needs to know that the goods have been retrieved from the warehouse to begin its loading, shipping, and delivery stages. Similarly, other types of workflows, such as calendar events, work schedules, production schedules, event schedules, etc., can also be applied in a similar manner.

[0064] In some embodiments, participants can collaboratively engage in the workflow. In one example, for an online purchase-delivery event, workflow participants may include a workflow administrator, the online platform, the seller, a warehousing company, and a delivery company. Each participant can participate in one or more stages of the workflow. The order placement stage may be managed by the seller; the product retrieval stage may be managed by the warehousing company; and the product delivery and recipient confirmation stage may be managed by the delivery company. These stages can be configured by an administrator, who may be selected by the seller, warehousing company, and delivery company, or otherwise selected or designated. In one embodiment, the workflow participants may be parties to a consortium blockchain. For example, each participant may be associated with a consortium blockchain address, which can be used for identification, obtaining information, sending information, etc.

[0065] In some embodiments, each participant in the workflow may be represented by one or more computing devices, and corresponding steps (e.g., sending or receiving information, displaying information) may be automatically executed by one or more computing devices. For example, an administrator may be represented by client-side computing device 111a, a seller by client-side computing device 111b, a warehouse by client-side computing device 111c, and a delivery company by client-side computing device 111d. Client-side computing devices may have software such as an MQ service installed to access server-side 118. These representations are merely examples, and various computing devices may have additional or alternative associations.

[0066] In some embodiments, at step 301, server 118 may obtain a request from client-side computing device 111a for registering a workflow comprising one or more states. In some embodiments, obtaining the request to register one or more states corresponding to the workflow may include obtaining a request from a workflow administrator for registering one or more states corresponding to the workflow. An administrator may refer to a computing device associated with authorizing the addition, disabling, or restoration of one or more states as a group of states. An administrator may also have the authority to add, disabling, or restore individual states. The blockchain may include a consortium blockchain.

[0067] In some embodiments, server-side 118 may include various components implemented as software and / or hardware. These components may include, but are not limited to, a blockchain contract generator 311, a local state management module 312, a local state machine 313, a state trigger 314, an MQ management module 315, and a subscription management module 316. These components may be implemented collectively or individually as one or more processors and one or more non-transitory computer-readable storage media storing instructions thereon, which, when executed by the one or more processors, cause server-side 118 to perform the disclosed steps. These components and their arrangements are merely examples, and there may be fewer, more, or alternative components and alternative arrangements.

[0068] In one embodiment, after receiving the information from step 301, in step 302, server-side 118 (e.g., blockchain contract generator 311) can generate a blockchain contract including the workflow. For example, the blockchain contract can define the workflow, one or more states, and the relationships between states. The blockchain contract can further define that the workflow may be in one of the states at any given time. The one or more states can include a start state, an end state, and other logically related states between the start and end states. For example, one or more states can be configured in a cyclically triggered flow registered in the blockchain. The cyclically triggered flow can start from the start state of one or more states, pass through each of the one or more states in one direction at a time until the end state, and then return to the start state. Each of the one or more states can be triggered by the completion of a previous state in the cyclically triggered flow.

[0069] In some embodiments, in step 303, server 118 can deploy the blockchain contract in the blockchain. For example, server 118 can generate a blockchain transaction including the generated blockchain contract and transmit the blockchain transaction to one or more blockchain nodes of blockchain system 112 to add the blockchain transaction to the blockchain. As described above, through blockchain node verification, the blockchain contract can be added to a block of the blockchain, thereby being deployed in the blockchain.

[0070] In some embodiments, server-side 118 may execute a blockchain contract to initialize the current state as a start state of one or more states. For example, one or more states of the workflow may include a start state. This execution can be programmed into generated blockchain transactions to initialize the current state of the workflow as a start state during or after blockchain contract deployment.

[0071] In some embodiments, deployed blockchain contracts can be executed to update the current state of the workflow in one or more states. For example, various computing devices can transmit blockchain transactions to be added to the blockchain, and such blockchain transactions can invoke deployed blockchain contracts to advance the workflow from the start state to the next state, and so on, thereby changing the current state. If a consensus-verified blockchain transaction is added to a new block of the blockchain, all blockchain nodes can execute the blockchain contract based on the consensus-verified blockchain transaction to update the current state of the workflow. Through this execution, local copies of the blockchain can be updated individually for the current state.

[0072] In one embodiment, for an online buy-delivery event, each buy-delivery process can correspond to one round of workflow. For example, a seller can sell goods from an online platform. The current state of the workflow in the blockchain contract can be initialized to the start state: (State 1) Waiting for an order. When an order is placed in the seller's virtual store on the online platform, whether or not through server-side 118, the online platform can transmit the blockchain transaction (e.g., along with the online platform's signature) to the blockchain, which moves the workflow to: (State 2) Order received. If the seller has subscribed to State 2, the seller will be able to receive notification of the received order. If the seller accepts the order and updates the blockchain (e.g., by transmitting the blockchain transaction signed by the seller to the blockchain), the workflow can proceed to: (State 3) Retrieving goods from the warehouse. If the warehouse has subscribed to State 3, the warehouse will be able to receive notification of retrieving the ordered goods. If the warehouse retrieves the goods and updates the blockchain (e.g., by sending the blockchain transaction signed by the warehouse to the blockchain), the workflow can proceed to: (State 4) Goods delivery. If the delivery company has subscribed to State 4, the delivery company will be able to receive notification of delivering the ordered goods. If the delivery company completes the delivery and updates the blockchain (e.g., by transmitting a blockchain transaction signed by the delivery company or the recipient to the blockchain), the workflow can return to: (State 1) Waiting for orders. This completes one round of the workflow.

[0073] In some embodiments, in step 304, server 118 may receive a request from a subscriber to subscribe to a notification of one of the one or more states. Similarly, server 118 may receive one or more requests from a single subscriber to subscribe to one or more notifications of one or more of the one or more states, or from multiple subscribers to subscribe to a notification of one of the one or more states. That is, a subscriber may subscribe to one or more states in one or more state groups, and one or more subscribers may subscribe to a single state. In one embodiment, for an online purchase-delivery event, to confirm an order, the seller may subscribe to (state 2): Order Received; to begin retrieving goods, the warehouse may subscribe to (state 3): Retrieving Goods from Warehouse; and to begin delivery, the delivery company may subscribe to (state 4): Goods Delivered. The subscription requests may require approval from a workflow administrator.

[0074] Optionally, server 118 can receive one or more requests through gateway 319. A gateway can be a type of networking hardware used in telecommunications networks to allow data to flow from one discrete network to another. Gateway 319 can provide load balancing to improve communication between client-side computing devices and server 118.

[0075] Furthermore, in step 305, server-side 118 can establish an association between a subscriber and a state. For example, subscription management module 316 can establish and store the association. If the subscriber later cancels their subscription, server-side 118 can delete the association accordingly.

[0076] In some embodiments, in step 306, server 118 may obtain information from one or more blocks of the blockchain to determine the current state. In some embodiments, when the starting state is initialized to the current state, further blockchain transactions added to the blockchain may invoke a blockchain contract and advance the workflow, thereby changing the current state of the workflow. In some embodiments, server 118 may obtain blockchain transactions from one or more blocks of the blockchain, wherein the blockchain transactions trigger the execution of a blockchain contract to update the current state of the workflow. Server 118 may also determine the current state of the workflow based on the obtained blockchain transactions.

[0077] In some embodiments, in step 307, server-side 118 (e.g., local state management module 312) may update the locally maintained state machine (e.g., local state machine 313) based on the current state of the determined workflow. In one embodiment, server-side 118 may maintain the state machine. The state machine may also be referred to as a finite state machine. The state machine may be an abstract machine (e.g., a computational model) that can be in exactly one of a finite number of states at any given time.

[0078] Reference Figure 3B and Figure 3C In some embodiments, the locally maintained state machine may include one or more local states (e.g., local state L1, local state L2, local state L3, local state L4) that are respectively mapped to one or more states (e.g., state 1, state 2, state 3, state 4) of a workflow registered in the blockchain. Figure 3B As shown, the one or more local states are configured in a locally maintained cyclic triggering flow. The cyclic triggering flow begins with a start local state among the one or more local states, passes through each of the one or more local states in one direction at a time until an end local state, and then returns to the start local state. In one example, for an online purchase-delivery event, local state L1 maps to (state 1) waiting for an order, local state L2 maps to (state 2) receiving an order, local state L3 maps to (state 3) retrieving goods from the warehouse, and local state L4 maps to (state 4) goods being delivered. Since state 1 is the start state, and the start local state has been mapped to the start state, local state L1 is the local start state. Similarly, local state L2 is mapped to state 2, local state L3 is mapped to state 3, and so on. Figure 3C In this process, one or more states registered in the blockchain are configured in another cyclically triggered flow registered in the blockchain. This other cyclically triggered flow starts from a start state among the one or more states, traverses each of the one or more states in one direction at a time until an end state, and then returns to the start state. A start local state is mapped to the start state. Each of the one or more states is triggered by the completion of a previous state in the other cyclically triggered flow registered in the blockchain. Because local states are correspondingly mapped to the states of the workflow in the blockchain, each of the one or more local states can be effectively triggered by the completion of a previous local state in a locally maintained cyclically triggered flow.

[0079] By updating the locally maintained state machine based on the current state of the defined workflow, the state of the local state machine synchronously reflects the current state of the workflow in the blockchain. For example, if the workflow in the blockchain is in state 2, the local state machine can remain in local state L2; if the workflow then progresses to state 3, the local state machine can switch to local state L3.

[0080] In some embodiments, each of one or more states may be configured by a subscriber to include one or more substates. For example, based on a blockchain contract or further modifications thereof, the workflow may be in a subdivided state under one or more states, which may be referred to as a substate of that state. In some embodiments, server 118 may receive a request to register one or more substates of a state, wherein a registered workflow includes that state. This request may be obtained from the creator-subscriber of one or more substates. The configuration may require approval from the workflow administrator. Server 118 may receive the state included in a deployed blockchain contract, and the state configured with one or more substates, obtain information from the blockchain to determine whether the state can be configured to include one or more substates, and in response to determining that the state can be configured to include one or more substates, generate a blockchain contract including one or more substates. For example, some states may already be configured in their deployed blockchain contracts to allow the addition of substates to their states, while other states are not allowed. In some embodiments, the generated blockchain contract is configured to invoke the deployed blockchain contract to update the state to include one or more substates. Therefore, based on the deployed blockchain contracts that provide a large workflow framework, individual participants can add more sub-steps to the workflow for customization and refinement. Server 118 can deploy the generated blockchain contracts in the blockchain, whereby the deployed blockchain contracts can be executed to update the current sub-state of the state corresponding to the workflow in one or more sub-states. The steps for generating and deploying sub-states are similar to the description of the registered state above.

[0081] In one example, such as Figure 3C As shown, for online purchase-delivery events, the delivery company can configure additional sub-states (e.g., sub-state 41, sub-state 42, sub-state 43) via server-side 118 under the initially configured state 4 by the administrator. Accordingly, as... Figure 3B As shown, the client-side computing device 111d can be configured by the server 118 to map to one or more local substates of one or more substates respectively.

[0082] In some embodiments, server 118 can obtain information from one or more blocks of the blockchain to determine the current sub-state. Furthermore, server 118 can update its locally maintained state machine based on the determined current sub-state. In one embodiment, the locally maintained state machine includes local states mapped to states of workflows registered in the blockchain, and includes one or more local sub-states mapped to one or more sub-states registered in the blockchain. The one or more sub-states registered in the blockchain and the states can form a cyclically triggered flow registered in the blockchain. For example, as... Figure 3C As shown, substates 41, 42, 43 and 4 form a loop triggering flow registered in the blockchain.

[0083] In some embodiments, one or more local substates are configured in a locally maintained cyclic triggering stream; the locally maintained cyclic triggering stream starts from the local state, passes through each of the one or more local substates in one direction at a time, and returns to the local state. For example, through mapping, such as Figure 3B As shown, local substates L41, L42, L43, and L4 form a locally maintained cyclically triggered flow. A cyclically triggered flow containing substates can operate in a similar manner to a cyclically triggered flow containing only states. Because local substates are mapped to corresponding substates of workflows registered in the blockchain, each of one or more local substates can be effectively triggered by the completion of a local state in the locally maintained cyclically triggered flow or by the completion of a previous local substate. For example, when state 4 becomes the current state of the workflow, the workflow may not proceed to the next state (state 1) until the configured logic containing the substate is completed. For example, substates 41, 42, and 43 can be configured such that when state 4 is the current state, substate 41 is triggered, the completion of substate 41 triggers substate 42, and so on. Here, substate 41 can be a start substate, and substate 43 can be an end substate. The workflow must complete substates 41, 42, and 43 consecutively, one or more times, to proceed to the next state (state 1). For online purchase-delivery events, the delivery company can configure (sub-state 41) the delivery person to receive the goods, (sub-state 42) the goods to be delivered to a local facility, and (sub-state 43) the recipient to sign a receipt.

[0084] In step 308, server-side 118 (e.g., subscription management module 316) can establish associations between subscribers and one or more substates to send notifications associated with the one or more substates to the subscriber. The subscriber to the one or more substates can be the user who created the one or more substates. In one example, an association can be established between a client-side computing device 111d, representing a delivery company on behalf of the subscriber, and substates 41, 42, and 43. Through these associations, server-side 118 can schedule notifications for the substates in which the workflow is located for client-side computing device 111d. If the subscriber later unsubscribes, server-side 118 can delete the association accordingly.

[0085] In some embodiments, the one or more states are public to all subscribers of the one or more states. For example, states 1, 2, 3, and 4 are known to other participants in the workflow and / or other users of the blockchain for client-side computing devices 111b, 111c, and 111d. Client-side computing devices 111b, 111c, and 111d can each subscribe to one or more states. In some embodiments, the one or more substates are private to subscribers of the one or more substates. Since a subscriber configures one or more substates, one or more substates can be private to the subscriber. Subscribers can manage one or more substates, such as further configuring their access authorization. In one example, substates 41, 42, and 43 configured by client-side computing device 111d can be private to client-side computing device 111d and therefore unknown to other participants in the workflow.

[0086] In some embodiments, in step 309, server 118 (e.g., state trigger 314) can determine that the updated state machine corresponds to a state. Further, in step 310, in response to determining that the updated state machine corresponds to one or more states, server 118 can transmit a notification message to subscribers who have subscribed to a state (or similarly, to one or more subscribers who have subscribed to a state). In some embodiments, the notification message includes a message indicating that a state is the current state and / or a result returned by completing a previous state in one or more states. For example, if state 3 becomes the current state, server 118 can send a notification message to client-side computing device 111c because the warehousing company has subscribed to state 3. The notification message may include a message indicating that state 3 is the current state and / or a result returned by completing state 2. In one example, for an online purchase-delivery event, the result returned from completing state 2 may include proof of the goods' identity and the seller's digital signature representing the seller's approval of the order.

[0087] In some embodiments, similarly, in step 310, server 118 may send a corresponding notification message to subscribers of the sub-state. The notification message includes a message indicating the determined current sub-state and a result returned from the completion of the state and / or from a previous sub-state among one or more sub-states. Client-side computing devices may receive notification messages from computing devices (e.g., server 118) indicating that the current state of the workflow is one or more states of the workflow. A blockchain contract deployed in the blockchain can be executed to update the current state in one or more states of the workflow.

[0088] In some embodiments, sending a notification message to one or more subscribers subscribed to a state may include placing the notification message in a message queue for one or more computing devices associated with the one or more subscribers to receive the notification message. For example, the MQ management module 315 may place notification messages about a specific state into the message queue. Client-side computing devices associated with subscribers to a specific state may connect to the message queue to receive the notification message.

[0089] In some embodiments, the client-side computing device may connect to and receive notification messages from a message queue where notification messages are placed by a computing device (e.g., server 118). The client-side computing device may further perform a function associated with the state in response to the notification message. In some embodiments, the function may be configured by subscribers to the state. For example, referring to 3C, each subscriber may configure a function for the states or sub-states they have subscribed to. For example, state 1 may correspond to function H1, state 2 may correspond to function H2, state 3 may correspond to function H3, state 4 may correspond to function H4, sub-state 41 may correspond to function H41, sub-state 42 may correspond to function H42, and sub-state 43 may correspond to function H43. Each state may not correspond to a function, may correspond to one function of one or more subscribers, or may correspond to multiple functions of one or more subscribers. Each sub-state may not correspond to a function, or may correspond to one or more functions of a subscriber.

[0090] In some embodiments, a function may include a named portion of a program that performs a specific task. In one embodiment, a function may be a procedure or a routine. A function may or may not return a value. For example, executing function H2 could trigger the compilation of a received order in a predetermined format, and, once the current state is 2, automatically sign it on behalf of the seller to approve the order.

[0091] In some embodiments, in response to the completion of a function's execution, the client-side computing device may send a response message to the computing device (e.g., server 118) to indicate the completion of a function's execution associated with a state. In one embodiment, the client-side computing device may send an update of a state to the computing device so that the computing device can begin obtaining information from the blockchain to redetermine the current state. For example, the update may indicate the completion of a state. In one embodiment, the client-side computing device may transmit a response message to the computing device for the computing device to (1) generate a blockchain transaction to update a state (e.g., state 2), and (2) transmit the blockchain transaction to one or more blockchain nodes to add it to the blockchain, thereby causing the current state of the workflow to be updated to a state following said state (e.g., state 3). The computing device can then begin obtaining information from the blockchain to redetermine the current state. If the blockchain transaction is successfully added to the blockchain, the information obtained (e.g., a new block in the blockchain) may include a blockchain transaction indicating that the workflow is updated to a state following said state, identical to that in the blockchain. By redetermining the current state, the computing device can discover that the workflow has progressed to a state following said state, identical to that in the blockchain.

[0092] One or more states of a workflow can be referred to as a state group. In some embodiments, obtaining a request to register one or more states corresponding to a workflow may include obtaining a request to register a state group corresponding to one or more states of a workflow. In some embodiments, one or more valid state groups may exist in a blockchain and operate simultaneously. A state cannot be shared between any two or more state groups.

[0093] In some embodiments, a workflow administrator may have permissions to add, disable, or restore state groups at server-side 118. Non-administrator participants in the workflow may not have permissions to add, disable, or restore state groups at server-side 118. Permissions may be managed by server-side 118. By disabling or restoring a state group, status notifications for that state group can be disabled or restored. In some embodiments, server-side 118 may receive a request to stop notifying a state group and, in response to the request, stop notifying one or more subscribers of that state group. To do this, server-side 118 may stop updating the local state mapped to the workflow state or stop placing notifications in a message queue. Furthermore, server-side 118 may receive a request to restore a state group and, in response to the request, restore notifications for that state group to one or more subscribers of that state group. To do this, server-side 118 may restore updating the local state mapped to the workflow state or restore placing notifications in a message queue.

[0094] In some embodiments, workflow administrators may have permissions to add, disable, restore, or subscribe to individual states. Adding a state allows a new state to be added to an existing state group. Non-administrator participants in the workflow may not have permission to add, disable, or restore states, but they may have permission to subscribe to them. Both administrator and non-administrator participants may have permissions to configure substates. Permissions can be managed by the server-side. Disabling or restoring a state allows state notifications to be disabled or restored. In some embodiments, if a state is disabled or deactivated, its associated substates are also disabled or deactivated. If a subscriber unsubscribes from a state, its associated substates configured by that subscriber will be disabled or deactivated.

[0095] In some embodiments, server 118 may receive a request to deactivate one of one or more states. In response to the request to deactivate the state, server 118 may generate a blockchain transaction to shorten the state from another circular trigger flow registered in the blockchain, and send the generated blockchain transaction to one or more blockchain nodes to add it to the blockchain; and may map locally maintained circular trigger flow shortening to the local state of that state. For example, if notification of state 3 is prohibited, server 118 may generate a transaction to shorten the state from another circular trigger flow registered in the blockchain. Figure 3C The workflow shown circumvents the state 3 blockchain transaction in another loop trigger flow within one or more states, and sends the blockchain transaction to one or more blockchain nodes to be added to the blockchain. Once the blockchain transaction is added to the blockchain, state 3 will be removed from the blockchain. Figure 3C Another loop in one or more states of the workflow triggers flow avoidance. Server-side 118 can further... Figure 3B Local state L3 is evaded in one or more local state cyclic trigger streams. Therefore, the blockchain contract's state will no longer include state 3, and states before and after state 3 will be connected in another trigger stream. Similarly, the local state machine will not retain local state L3, and local states before and after local state L3 will be connected in the trigger stream. As a result, notifications for state 3 are effectively muted. Therefore, this state is configured to be evaded from another cyclic trigger stream registered in the blockchain in response to notifications to deactivate it, and the local states mapped to this state are configured to be evaded from the locally maintained cyclic trigger stream in response to notifications to deactivate it.

[0096] In some embodiments, server 118 may receive a request to reactivate one or more states. In response to the request to reactivate the state, server 118 may generate a blockchain transaction to restore the state in another cyclic triggering stream registered in the blockchain, and send the generated blockchain transaction to one or more blockchain nodes to add it to the blockchain; it may also restore the local state mapped to the state in a locally maintained cyclic triggering stream. For example, if to restore notification of state 3, server 118 may generate a transaction to restore the state in a cyclic triggering stream such as... Figure 3C In another loop trigger flow of one or more states of the workflow shown, the blockchain transaction in state 3 is restored (e.g., by deleting the circumvention and restoring the initial connection), and this blockchain transaction is sent to one or more blockchain nodes to be added to the blockchain. Once the blockchain transaction is added to the blockchain, state 3 will be restored. Figure 3C In a cyclically triggered flow of one or more states of the workflow. Server-side 118 can further... Figure 3B Local state L3 is restored in a cyclic triggering stream of one or more local states (e.g., by removing evasion). As a result, notification for state 3 is effectively restored. Therefore, this state is configured to be restored in another cyclic triggering stream registered in the blockchain in response to a notification to re-enable the state, and the local state mapped to this state is configured to be restored in a locally maintained cyclic triggering stream in response to a notification to re-enable the state.

[0097] In some embodiments, substates can be similar to states that are disabled and restored. In one embodiment, server 118 may receive a request to disable one or more substates. In response to the request to disable the substate, server 118 may generate a blockchain transaction to bypass the substate from another cyclically triggered stream registered in the blockchain and send the generated blockchain transaction to one or more blockchain nodes to add it to the blockchain. Server 118 may further bypass local substates mapped to the substate from locally maintained cyclically triggered streams. In this way, server 118 can effectively notify substate subscribers of the disabling of the substate.

[0098] In one embodiment, server 118 may receive a request to reactivate the sub-state. In response to the request, server 118 may generate a blockchain transaction to restore the sub-state in another cyclically triggered stream registered in the blockchain, and send the generated blockchain transaction to one or more blockchain nodes to add it to the blockchain. Server 118 may also restore a local sub-state mapped to the sub-state in a locally maintained cyclically triggered stream. In this way, server 118 can effectively notify sub-state subscribers of the restoration of the sub-state.

[0099] In this way, through the platform provided by server 118, workflow participants can subscribe to the various states they are interested in and configure and subscribe to sub-states for their own use. The tasks of obtaining information from the blockchain, determining state triggers, and scheduling message delivery can be efficiently centralized on the platform, thereby minimizing overall computational input and energy consumption. The platform also offers customization and privacy protection for its users. Using this platform, workflows similar to the purchase and delivery of goods can be processed simultaneously for efficient subscription and notification.

[0100] Figure 4A A flowchart of a method 410 for registering a subscribing-able state in a blockchain, according to some embodiments, is shown. The operation of method 410 presented below is intended to be illustrative. Depending on the embodiment, method 410 may include additional, fewer, or alternative steps performed in various orders or in parallel. Method 410 may correspond to the above references. Figures 3A to 3C The steps described. Further details of method 410 can be found in [reference needed]. Figures 1 to 3C And the related descriptions above.

[0101] In some embodiments, in step 411, the client-side computing device 111a can communicate with the server 118 via an optional gateway 319 to configure one or more states of the workflow. For example, the client-side computing device 111a can define the workflow and its states, and configure a cyclical triggering flow for those states, for example... Figure 3C The workflow is triggered cyclically by states 1, 2, 3, and 4, as shown. One of these states can be designated as a start state, and another state can be designated as an end state. Once designated, the start and end states cannot be changed. At any given time, the workflow may be in one of these states.

[0102] In step 412, server-side 118 can record the one or more states and generate a blockchain contract including a workflow. For example, server-side 118 can configure a locally maintained state machine that includes one or more local states mapped to the one or more states respectively. Therefore, the local states can have similar cyclically triggered flows. Server-side 118 can further generate a blockchain contract defining the workflow, states, and cyclically triggered flows.

[0103] In step 413, server 118 may include the blockchain contract in the blockchain transaction and transmit the blockchain transaction to one or more blockchain nodes of blockchain system 112.

[0104] In step 414, the blockchain nodes of blockchain system 112 can verify the blockchain transaction to add it to the blockchain. Once added, the blockchain contract is deployed on the blockchain. The algorithm contained in the blockchain transaction can initiate the workflow from its current state in the initially deployed blockchain transaction to its starting state.

[0105] In step 415, the blockchain system 112 can return the deployment result to the server 118. Therefore, the state machine can be started in a local state mapped to the initial state. In step 416, the server 118 can report the deployment result to the client-side computing device 111a.

[0106] In step 417, server 118 can begin retrieving information from the blockchain. For example, whenever a new block is added to the blockchain, server 118 can retrieve information from that new block and search its blockchain transactions for updates to the deployed blockchain contract. If the state of the deployed blockchain contract changes, corresponding to a change in the workflow state, server 118 can update its local state machine. Based on the state of the state machine, server 118 can determine whether a notification should be triggered. For example, if a state is subscribed to by a subscriber and the state machine has switched to the local state corresponding to that specific state, server 118 can place the corresponding notification message in a message queue so that the subscriber receives the notification message. Alternatively, server 118 can send the notification message to the subscriber's computing device.

[0107] Figure 4B A flowchart of a method 420 for registering subscribing substates in a blockchain, according to some embodiments, is shown. The operation of method 420 presented below is intended to be illustrative. Depending on the embodiment, method 420 may include additional, fewer, or alternative steps performed in various orders or in parallel. Method 420 may correspond to the above references. Figures 3A to 3C The steps described. Further details of method 420 can be found in [reference needed]. Figures 1 to 3C And the related descriptions above.

[0108] In some embodiments, in step 421, via optional gateway 319, client-side computing device 111d can communicate with server 118 to configure one or more sub-states of a workflow state. This workflow may have been registered in the blockchain and included in a deployed blockchain contract. For example, client-side computing device 111d can define one or more sub-states of a registered state and configure a cyclical triggering flow for that state and its sub-states, such as... Figure 3C The diagram shows a cyclical triggering flow for state 4 and substates 41, 42, and 43. The order of this state and substates within the cyclical triggering flow can be specified. Within the cyclical triggering flow, at a given time, the workflow may be in this state or one of the substates.

[0109] In step 422, server 118 can check whether the state exists in the blockchain. For example, server 118 can query blockchain system 112 to determine whether the registered state and the deployed blockchain contract including the registered state exist in the blockchain.

[0110] In step 423, if the state exists, the blockchain system 112 can check whether the deployed blockchain contract allows the creation of one or more sub-states. For example, when registering the state, the administrator may have allowed or prohibited the creation of sub-states for certain states. In step 424, the blockchain system can return the check result to the server 118.

[0111] In step 425, server 118 may record one or more sub-states and generate a blockchain contract that includes one or more sub-states. For example, server 118 may configure a locally maintained state machine that includes one or more local sub-states mapped to one or more sub-states respectively. Server 118 may further generate a blockchain contract that defines one or more sub-states associated with the state and defines a cyclic trigger flow. When the state becomes the current state, the starting sub-state can be initialized as the first sub-state to become the current state.

[0112] In step 426, server 118 may include the blockchain contract in the blockchain transaction and send the blockchain transaction to one or more blockchain nodes of blockchain system 112.

[0113] In step 427, the blockchain nodes of blockchain system 112 can verify the generated blockchain transaction to add it to the blockchain. Once added, the generated blockchain contract will be deployed in the blockchain. The algorithm included in the blockchain transaction can initialize the current state of the workflow in the initially deployed blockchain transaction to the start state.

[0114] In step 428a, the blockchain system 112 can return the deployment result to the server 118. In step 428b, the server 118 can report the deployment result to the client-side computing device 111d.

[0115] In step 429, server 118 can begin retrieving information from the blockchain. For example, whenever a new block is added to the blockchain, server 118 can retrieve information from that new block and search its blockchain transactions for updates regarding the workflow's state. If the state changes to the current state, server 118 can update the state machine and iterate through the cyclical trigger flow of substates. Based on the state machine's state, server 118 can determine whether a notification should be triggered. For example, if a substate is subscribed to by a subscriber, and the state machine has switched to the local substate corresponding to that specific substate, server 118 can place the corresponding notification message in a message queue so that the subscriber receives the notification message. Alternatively, server 118 can send the notification message to the subscriber's computing device.

[0116] Figure 4C A flowchart of a method 430 for blockchain-based notification according to some embodiments is shown. The operation of method 430 presented below is intended to be illustrative. Depending on the embodiment, method 430 may include additional, fewer, or alternative steps performed in various orders or in parallel. Method 430 may correspond to the above references. Figures 3A to 3C The steps described. Further details of method 430 can be found in [reference needed]. Figures 1 to 3C And the related descriptions above.

[0117] In some embodiments, in step 431, the client-side computing device 111c can communicate with the server 118 via an optional gateway 319 to subscribe to the state of a workflow. The subscribed state may be referred to as a second state. The second state may be triggered by a first state in a cyclically triggered flow registered in the blockchain. The workflow may have been registered in the blockchain and included in a deployed blockchain contract. Although state subscription and notification are described below, sub-state subscription and notification can be performed similarly. The server 118 may store the association between subscriptions and states and subscribers. The server 118 may configure a message queue (MQ) 499 based on this association.

[0118] In steps 432 and 433, via optional gateway 319, client-side computing device 111b can communicate with server 118 to update the first state of the workflow. The first state may also be referred to as the previous state to distinguish it from states already subscribed to by the client-side computing device and to indicate its relative position in the cyclic triggering flow. The first state (previous state) can trigger a second state (state) in the cyclic triggering flow. Server 118 can receive an update to the first state, i.e., an update to the previous state of that state. In one embodiment, client-side computing device 111b may have already performed an action to update the workflow state. In one example, for an online purchase-delivery event, the seller may have already approved the received order and can notify server 118 to update state 2 to completed.

[0119] In step 434, server-side 118 may generate a blockchain transaction to update the first state (previous state) and transmit the blockchain transaction to one or more blockchain nodes to add it to the blockchain and cause the current state of the workflow to be updated to that state. In one example, for an online purchase-delivery event, server-side 118 may generate a blockchain transaction that invokes a deployed blockchain contract, adds seller approval for the received order, and / or advances the workflow. From steps 431 to 434, the current state of the workflow can remain the first state until step 435, which advances the workflow to the second state.

[0120] In step 435, through consensus verification, blockchain system 112 can execute blockchain transactions to initiate a second state (state) following the first state (previous state). For example, the current state of the workflow in the blockchain can thus be updated from the first state (previous state) subscribed to by client-side computing device 111c to the second state (state). In step 436, blockchain system 112 can return the verification and execution results to server 118. For example, server 118 can receive a reply message from blockchain system 112 indicating the completion of the first state (previous state) in one or more states of the workflow.

[0121] Instead of steps 433 to 436, client-side computing device 111b can directly send blockchain transactions to blockchain system 112 to invoke the deployed blockchain contract and update the current state of the workflow.

[0122] In step 437, server 118 can obtain information from the blockchain. For example, whenever a new block is added to the blockchain, server 118 can obtain information from that new block and search its blockchain transactions for updates regarding the deployed blockchain contract. If the state of the deployed blockchain contract changes, corresponding to a change in the workflow state, server 118 can update the state machine. Based on the state of the state machine, server 118 can determine whether a notification should be triggered. In one example, for an online purchase-delivery event, based on the update to state 2, the workflow has progressed to state 3. Therefore, the state machine can progress to local state L3.

[0123] In step 438, server 118 can place the corresponding notification message in message queue 499 for subscribers (e.g., client-side computing device 111c) to receive the notification message. For example, server 118 can place a notification message about state 3 in MQ 499. This notification message can be configured to be available to subscribers subscribing to state 3. Client-side computing device 111c can have software installed to listen for notification messages in MQ 499. Once the placed notification message is detected, in step 439, client-side computing device 111c can retrieve the notification message about state 3 from MQ 499 and consume it. Alternatively, server 118 can send the notification message to client-side computing device 111c.

[0124] Figure 4D A flowchart of a method 440 for blockchain-based notification according to some embodiments is shown. The operation of method 440 presented below is intended to be illustrative. Depending on the embodiment, method 440 may include additional, fewer, or alternative steps performed in various orders or in parallel. Method 440 may correspond to the above references. Figures 3A to 3C The steps described. Further details of method 440 can be found in [reference needed]. Figures 1 to 3C And the related descriptions above.

[0125] In some embodiments, steps 441 and 442 may be similar to steps 438 and 439 described above. In step 441, after triggering a notification (e.g., for state 3), server 118 may place the corresponding notification message in message queue 499 for subscribers (e.g., client-side computing device 111c) to receive the notification message. For example, server 118 may place a notification message about state 3 in MQ 499. This notification message may be configured to be available to subscribers who subscribe to state 3. Client-side computing device 111c may have software installed for listening to notification messages in MQ 499 (e.g., MQ service 488). Once the placed notification message is detected, in step 442, client-side computing device 111c can retrieve the notification message about state 3 from MQ 499 and consume the notification message.

[0126] In step 443, the MQ service 488 may, in response to a received notification message, perform a function associated with a state (e.g., state 3). To perform this function, the MQ service 488 may invoke and execute one or more corresponding algorithms. For example, performing function H2 may trigger the compilation of the received order in a predetermined format, and, once the current state is 2, automatically sign on behalf of the seller to approve the order.

[0127] In step 444, MQ service 488 can update the status (e.g., status 3). For example, MQ service 488 can update the status of this status to complete.

[0128] In steps 445 and 446, the MQ service 488 can generate a reply message through the optional gateway 319 and send the reply message to the server 118. The reply message may include status updates, such as completion status, execution results of updates, etc. Steps 445 and 446 can be similar to step 432 above, except that steps 445 and 446 send updates to the current status, while step 432 sends updates to the previous status. Therefore, it can be... Figure 4C and Figure 4D Combine them into a process and repeat them in each state of the workflow.

[0129] Figure 5 A flowchart illustrating an exemplary method 510 for blockchain-based notifications according to some embodiments herein is shown. Method 510 can be performed by a device, apparatus, or system for blockchain-based notifications (e.g., server-side 118). Method 510 can be performed by... Figure 1The method 510 is executed by one or more components of environment 100 (e.g., server-side 118). Server-side 118 may implement Blockchain as a Service (BaaS). Server-side 118 may include one or more servers or other computing devices. Method 510 may be implemented by a system or device (e.g., computer, server) including various hardware machines and / or software. For example, the system or device may include one or more processors and one or more non-transitory computer-readable storage media (e.g., one or more memories), said one or more non-transitory computer-readable storage media being coupled to one or more processors and configured with instructions executable by one or more processors to cause the system or device (e.g., processor) to perform method 510.

[0130] The operation of method 510 presented below is intended to be illustrative. Depending on the embodiment, method 510 may include additional, fewer, or alternative steps performed in various orders or in parallel. Further details of method 510 can be found in [reference needed]. Figures 1 to 4D And the related descriptions above. (Reference) Figures 1 to 4D The steps for blockchain-based notifications are described in method 510.

[0131] Box 511 includes obtaining a notification message from a computing device indicating that the current state of the workflow is one of one or more states of the workflow, wherein a blockchain contract deployed in the blockchain can be executed to update the current state in one or more states of the workflow. In some embodiments, obtaining a notification message from a computing device indicating that the current state of the workflow is one of the states of the workflow includes: connecting to a message queue on the computing device to place the notification message; and obtaining the notification message from the message queue.

[0132] In some embodiments, prior to block 511, the computing device is configured to: obtain information from one or more blocks of the blockchain to determine a current state; update a locally maintained state machine based on the determined current state; determine whether the updated state machine corresponds to the state; and in response to determining that the updated state machine corresponds to the state, generate a notification message for one or more subscribers who subscribe to the state.

[0133] In some embodiments, the locally maintained state machine includes one or more local states, each mapped to one or more states; and the one or more states are registered in the blockchain. In some embodiments, the one or more local states are configured in a cyclic triggering stream; the cyclic triggering stream starts from a start local state among the one or more local states, passes through each of the one or more local states in one direction at a time until an end local state, and then returns to the start local state. In some embodiments, the one or more states are configured in another cyclic triggering stream; the other cyclic triggering stream starts from a start state among the one or more states, passes through each of the one or more states in one direction at a time until an end state, and then returns to the start state; each of the one or more states is triggered by the completion of a previous state in the other cyclic triggering stream; and the start local state is mapped to the start state.

[0134] In some embodiments, the state may be configured to be evaded from another loop-triggered stream in response to a notification to deactivate the state; and the local state mapped to the state may be configured to be evaded from the loop-triggered stream in response to a notification to deactivate the state.

[0135] In some embodiments, a state may be configured to be restored in another cyclic trigger stream in response to a notification that the state is re-enabled; and a local state mapped to the state may be configured to be restored in the cyclic trigger stream in response to a notification that the state is re-enabled.

[0136] In some embodiments, each of one or more states may be configured by a subscriber of one or more substates to include the one or more substates; the method further includes: establishing an association between a subscriber and one or more substates to send a notification associated with the one or more substates to the subscriber.

[0137] In some embodiments, one or more substates form a cyclically triggered flow; one or more states are public to one or more subscribers; and one or more substates are private to the subscribers of one or more substates.

[0138] Box 512 includes performing a function associated with the state in response to a notification message. In some embodiments, this function may be configured by the subscriber to the state.

[0139] Box 513 includes sending a response message to the computing device in response to the completion of the function's execution, indicating the completion of the function's execution associated with the state.

[0140] In some embodiments, sending a response message to a computing device to indicate the completion of the execution of a function associated with the state includes: sending an update of the state to the computing device to enable the computing device to begin obtaining information from the blockchain to re-determine the current state.

[0141] In some embodiments, sending a response message to a computing device to indicate the completion of the execution of a function associated with the state includes: sending a response message to the computing device to cause the computing device to generate a blockchain transaction for updating the state, and sending the blockchain transaction to one or more blockchain nodes to be added to the blockchain, thereby causing the current state of the workflow to be updated to the state after the state.

[0142] Figure 6 A block diagram of a system 610 for blockchain-based notifications according to some embodiments is shown. System 610 (e.g., a computer system) may be an example of an implementation of the aforementioned server 118, a similar device or system of devices, or a combination of server 118 and one or more additional devices. For example, method 440 and / or method 510 may be implemented by system 610. System 610 may include one or more processors and one or more non-transitory computer-readable storage media (e.g., one or more memories) coupled to and configured to be executable by the one or more processors to cause the system or device (e.g., a processor) to perform the methods and operations described above, such as method 440 and method 510. System 610 may include various units / modules corresponding to instructions (e.g., software instructions).

[0143] In some embodiments, system 610 may be referred to as an apparatus for blockchain-based notification. The apparatus may include: an acquisition module 611 for acquiring from a computing device a notification message indicating that the current state of a workflow is one of one or more states of the workflow, wherein a blockchain contract deployed in the blockchain can be executed to update the current state in one or more states of the workflow; a processing module 612 for executing a function associated with a state in response to the notification message; and a sending module 613 for sending a reply message to the computing device in response to the completion of the execution of the function to indicate the completion of the execution of the function associated with the state.

[0144] The techniques described herein are implemented by one or more dedicated computing devices. A dedicated computing device can be a desktop computer system, server computer system, portable computer system, handheld device, networking device, or any other device or combination of devices including hard-wired and / or program logic to implement the technology. A dedicated computing device can be implemented as a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination thereof. Computing devices are typically controlled and coordinated by operating system software. Traditional operating systems control and schedule computer processes for execution, perform memory management, provide file systems, networking, I / O services, and provide user interface functionality, such as a graphical user interface (“GUI”), etc. The various systems, apparatuses, storage media, modules, and units described herein can be implemented in a dedicated computing device or in one or more computing chips of one or more dedicated computing devices. In some embodiments, the instructions described herein can be implemented in a virtual machine on a dedicated computing device. When executed, the instructions can cause the dedicated computing device to perform the various methods described herein. A virtual machine can include software, hardware, or a combination thereof.

[0145] Figure 7 This is a block diagram illustrating a computer system 700 on which any of the embodiments described herein may be implemented. System 700 can perform any of the methods described herein (e.g., method 440 and related steps, method 510 and related steps). System 700 can be implemented in any system described herein (e.g., system 610, server 118). Computer system 700 includes a bus 702 or other communication mechanism for transmitting information, and one or more hardware processors 704 coupled to the bus 702 for processing information. Hardware processor 704 may be, for example, one or more general-purpose microprocessors.

[0146] Computer system 700 also includes main memory 706, such as random access memory (RAM), cache, and / or other dynamic storage devices, coupled to bus 702 for storing information and instructions executable by processor 704. Main memory 706 may also be used to store temporary variables or other intermediate information during the execution of instructions executable by one or more processors 704. When these instructions are stored in storage media accessible to processor 704, they present computer system 700 as a dedicated machine customized to perform the operations specified in the instructions. Computer system 700 further includes read-only memory (ROM) 708 or other static storage devices coupled to bus 702 for storing static information and instructions for processor 704. Storage devices 710, such as disks, optical discs, or USB thumb drives (flash drives), are provided and coupled to bus 702 for storing information and instructions.

[0147] Computer system 700 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic, wherein the firmware and / or program logic, combined with the computer system, enables computer system 700 to be a special-purpose machine or to be programmed as such. According to one embodiment, the operations, methods, and processes described herein are performed by computer system 700 in response to processor 704 executing one or more sequences of one or more instructions contained in main memory 706. These instructions may be read into main memory 706 from another storage medium, such as storage device 710. Execution of the sequence of instructions contained in main memory 706 causes processor 704 to perform the processing steps described herein. In alternative embodiments, hardwired circuitry may be used instead of or in combination with software instructions.

[0148] Main memory 706, ROM 708, and / or storage device 710 may include non-transitory storage media. As used herein, the term "non-transitory media" and similar terms refer to a medium that stores data and / or instructions that enable a machine to operate in a particular manner, excluding transient signals. Such non-transitory media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical discs or magnetic disks, such as storage device 710. Volatile media include dynamic memory, such as main memory 706. Common forms of non-transitory media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or cassette tapes, and their networking versions.

[0149] Computer system 700 also includes a network interface 718 coupled to bus 702. Network interface 718 provides bidirectional data communication coupled to one or more network links connected to one or more local networks. For example, network interface 718 may be an Integrated Services Digital Network (ISDN) card, cable modem, satellite modem, or modem for providing data communication connectivity to a corresponding type of telephone line. As another example, network interface 718 may be a Local Area Network (LAN) card for providing data communication connectivity to a LAN-compatible (or WAN component communicating with a WAN) network. Wireless links may also be implemented. In any such embodiment, network interface 718 transmits and receives electrical, electromagnetic, or optical signals carrying streams of digital data representing various types of information.

[0150] Computer system 700 can send and receive messages, including program code, via a network, network link, and network interface 718. In the Internet example, the server can send application request codes via the Internet, ISP, local network, and network interface 718.

[0151] The received code may be executed by processor 704 upon receipt and / or stored in storage device 710 or other non-volatile storage device for later execution.

[0152] Each process, method, and algorithm described in the foregoing sections can be implemented in a code module executed by one or more computer systems or a computer processor including computer hardware, and can be implemented automatically, either entirely or partially, by said code module. The processes and algorithms can be implemented, either partially or entirely, in dedicated circuitry.

[0153] The various features and processes described above can be used independently of each other or combined in various ways. All possible combinations and sub-combinations fall within the scope of this document. Additionally, certain methods or processing block diagrams may be omitted in some embodiments. The methods and processes described herein are not limited to any particular sequence, and the block diagrams or states associated with them can be executed in other suitable sequences. For example, the described block diagrams or states may be executed in a different order than specifically disclosed, or multiple block diagrams or states may be combined in a single block diagram or state. Examples of block diagrams or states may be executed serially, in parallel, or in some other manner. Block diagrams or states may be added to or removed from the disclosed embodiments. Examples of systems and components described herein may be configured differently from those described. For example, elements may be added, removed, or rearranged compared to the disclosed embodiments.

[0154] The various operations of the methods described herein can be performed, at least in part, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute the engine of a processor implementation that operates to perform one or more of the operations or functions described herein.

[0155] Similarly, the methods described herein can be implemented at least in part by a processor, where one or more specific processors are examples of hardware. For example, at least some operations of the methods can be performed by one or more processors or an engine implemented by a processor. Furthermore, one or more processors can also operate to support the performance of related operations in a “cloud computing” environment or as “Software as a Service” (SaaS). For example, at least some operations can be performed by a set of computers (as an example of a machine including processors) that can be accessed via a network (e.g., the Internet) and via one or more suitable interfaces (e.g., application programming interfaces (APIs)).

[0156] The performance of certain operations can be distributed across processors, not just residing within a single machine, but deployed across multiple machines. In some embodiments, the processor or processor-implemented engine may reside in a single geographic location (e.g., within a home environment, office environment, or server cluster). In other embodiments, the processor or processor-implemented engine may be distributed across multiple geographic locations.

[0157] In this document, multiple instances can implement components, operations, or structures described as single instances. Although the individual operations of one or more methods are shown and described as independent operations, one or more of these independent operations can be performed simultaneously, and these operations are not required to be performed in the order shown. Structures and functions presented as independent components in a configuration can be implemented as composite structures or components. Similarly, structures and functions presented as single components can be implemented as independent components. These and other variations, modifications, additions, and improvements all fall within the scope of the subject matter of this document. Furthermore, the related terms used herein (e.g., “first,” “second,” “third,” etc.) do not indicate any order, hierarchy, or importance, but are used to distinguish one element from another. Additionally, the terms “a,” “an,” and “a plurality” do not indicate a limitation on the quantity in this document, but rather indicate the presence of at least one of the mentioned items.

[0158] Although an overview of the subject matter has been described with reference to specific embodiments, various modifications and changes may be made to these embodiments without departing from the broader scope of the embodiments herein. The specific implementation should not be construed as limiting, and the scope of each embodiment is defined only by the appended claims and the full scope of their equivalents.

Claims

1. A computer-implemented method for blockchain-based notifications, comprising: A notification message indicating that the current state of the workflow is a target state in one or more states of the workflow is obtained from a computing device that interfaces with the blockchain node, wherein a blockchain contract deployed in the blockchain can be executed to update the current state in the one or more states of the workflow. In response to the notification message, perform a function associated with the target state; and in response to the completion of the function, send a reply message to the computing device to indicate the completion of the function associated with the target state. The computing device is configured as follows: The state machine maintained locally on the computing device is updated based on the current state; the locally maintained state machine includes one or more local states that are respectively mapped to one or more states of workflows registered in the blockchain; Determine whether the updated state machine corresponds to the target state; and In response to determining that the updated state machine corresponds to the target state, the notification message is generated for one or more subscribers who subscribe to the target state; The one or more states are configured in a cyclic triggering stream registered in the blockchain; the cyclic triggering stream starts from a start state in the one or more states, triggers each state sequentially until an end state, and returns to the start state, each state being triggered by the completion of a previous state in the cyclic triggering stream.

2. The method of claim 1, wherein, Obtaining a notification message from the computing device indicating that the current state of the workflow is a target state of the workflow includes: A message queue connected to the computing device is used to place the notification messages; and The notification message is obtained from the message queue.

3. The method according to any one of claims 1 to 2, wherein: The functionality can be configured by the subscribers of the target state.

4. The method of claim 1, wherein, The computing device is configured as follows: Obtain information from one or more blocks of the blockchain to determine the current state; update the locally maintained state machine based on the determined current state.

5. The method according to claim 1, wherein: Each of the one or more states can be configured to be evaded from the loop trigger flow in response to a notification to deactivate the state.

6. The method according to claim 5, wherein: Each of the one or more states can be configured to be restored in the cyclic trigger stream in response to a notification to re-enable the state.

7. The method according to claim 1, wherein: Each of the one or more states can be configured by a subscriber of one or more substates to include the one or more substates; and The method further includes: establishing an association between subscribers of one or more substates and the one or more substates, so as to send notifications associated with the one or more substates to subscribers of the one or more substates.

8. The method according to claim 7, wherein: The one or more sub-states constitute a cyclic trigger flow; The one or more states are public to one or more subscribers; and The one or more substates are private to the subscribers of the one or more substates.

9. The method of claim 1, wherein, Sending a response message to the computing device to indicate the completion of the function associated with the target state includes: An update of the current state is sent to the computing device so that the computing device can begin to obtain information from the blockchain to redetermine the current state.

10. The method of claim 1, wherein, Sending a response message to the computing device to indicate the completion of the function associated with the target state includes: The response message is sent to the computing device to cause the computing device to generate a blockchain transaction for updating the current state. The blockchain transaction is sent to one or more blockchain nodes to be added to the blockchain, thereby causing the current state of the workflow to be updated to the state after the current state.

11. A system for blockchain-based notifications, comprising: One or more processors; as well as One or more computer-readable storage devices coupled to the one or more processors and storing instructions thereon, the instructions being executable by the one or more processors to perform the method of any one of claims 1 to 9.

12. An apparatus for blockchain-based notification, comprising a plurality of modules for performing the method of any one of claims 1 to 9.

13. A non-transitory computer-readable medium storing instructions that, when executed by a processor of a device, cause the device to perform the method of any one of claims 1 to 9.

Images