WO2021143364A1

WO2021143364A1 - Method and apparatus for acquiring transaction processing state in decentralized application cluster

Info

Publication number: WO2021143364A1
Application number: PCT/CN2020/132432
Authority: WO
Inventors: 杨达一
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2020-01-14
Filing date: 2020-11-27
Publication date: 2021-07-22
Also published as: CN110852887B; CN110852887A

Abstract

A method for acquiring a transaction processing state in a decentralized application cluster. The method comprises: on the basis of a transaction tracking identifier, in a decentralized application cluster, of a transaction, generating a transaction processing state acquisition request (402), wherein the transaction tracking identifier is used for uniquely identifying the transaction in the decentralized application cluster; sending the transaction processing state acquisition request to a decentralized application in the decentralized application cluster (404); and the decentralized application acquiring a transaction processing state of the transaction (406), and sending the transaction processing state of the transaction to a transaction processing state acquirer (408).

Description

Method and device for obtaining transaction processing status in decentralized application cluster

Technical field

The present disclosure relates to the field of blockchain technology, and in particular, to a method and device for obtaining transaction processing status in a decentralized application cluster.

Background technique

A decentralized application (DAPP) is an application running on a decentralized network (ie, a blockchain network). In a decentralized network, there is usually no centralized node that can fully control the decentralized application. A completely decentralized application needs to be completely open source and autonomous applications. The upgrade of decentralized applications can only be upgraded after most users reach a consensus. The data involved in decentralized applications must be encrypted and stored on the decentralized application platform. Decentralized applications usually include the on-chain smart contract module of the blockchain and the off-chain service module. The on-chain smart contract module can write smart contracts based on the virtual machine provided by the blockchain system, and the off-chain service module provides user service functions, which can be developed based on the software development kit of the corresponding blockchain system.

In practice, in order to meet the needs of collaboration between different institutions, it is usually necessary to deploy decentralized application clusters to interface with the blockchain system. The transactions between various cooperative institutions can be stored on the blockchain after being processed in the decentralized application cluster. In this scenario, a transaction involves multiple decentralized applications. When it is necessary to know the processing status of a certain transaction, it will be difficult to locate each decentralized application, which also brings difficulties to obtaining the transaction processing status.

Summary of the invention

In view of the above, the present disclosure provides a method and device for acquiring transaction processing status in a decentralized application cluster and a method and device for processing transaction processing status acquisition request processing.

According to one aspect of the present disclosure, there is provided a method for acquiring transaction processing status in a decentralized application cluster, including: generating a transaction processing status acquisition request based on a transaction tracking identifier of a transaction in the decentralized application cluster , The transaction tracking identifier is used to uniquely identify the transaction in the decentralized application cluster; sending the transaction processing status acquisition request to the decentralized application in the decentralized application cluster; and The decentralized application obtains the transaction processing status of the transaction.

Optionally, in an example, the transaction tracking identifier may be generated based on an identifier generation rule agreed upon by each decentralized application in the decentralized application cluster.

Optionally, in an example, the transaction tracking identifier may be generated by the transaction initiator of the transaction.

Optionally, in an example, the transaction tracking identifier may be generated by the decentralized application when the transaction data of the transaction does not include the transaction tracking identifier.

Optionally, in an example, the transaction tracking identifier may be regenerated by the decentralized application when the transaction processing for the transaction fails.

Optionally, in an example, the transaction tracking identifiers corresponding to each decentralized application in the decentralized application cluster may be the same.

According to another aspect of the present disclosure, there is also provided a method for processing a transaction processing status acquisition request, the method is executed by a decentralized application in a decentralized application cluster, and the method includes: receiving transaction processing status acquisition Request, the transaction processing status acquisition request is generated based on the transaction tracking identifier of the transaction in the decentralized application cluster, and the transaction tracking identifier is used to uniquely identify the transaction in the decentralized application cluster Based on the transaction tracking identifier in the transaction processing status acquisition request, the transaction processing status of the transaction is acquired from local transaction processing data; and the transaction processing status is sent to the sender of the transaction processing status acquisition request.

According to another aspect of the present disclosure, a device for acquiring transaction processing status in a decentralized application cluster is also provided, including: a processing status acquisition request generating unit based on the transaction tracking identifier of the transaction in the decentralized application cluster , Generate a transaction processing status acquisition request, where the transaction tracking identifier is used to uniquely identify the transaction in the decentralized application cluster; a processing status acquisition request sending unit sends the transaction processing status acquisition request to the A decentralized application in a decentralized application cluster; and a transaction processing status acquisition unit, which acquires the transaction processing status of the transaction from the decentralized application.

According to another aspect of the present disclosure, a device for processing a transaction processing status acquisition request is also provided, the device is used for a decentralized application in a decentralized application cluster, and the device includes: a processing status acquisition request receiving unit, Receive a transaction processing status acquisition request, the transaction processing status acquisition request is generated based on the transaction tracking identifier of the transaction in the decentralized application cluster, and the transaction tracking identifier is used to be unique in the decentralized application cluster The transaction processing status acquisition unit, based on the transaction tracking identifier in the transaction processing status acquisition request, acquires the transaction processing status of the transaction from the local transaction processing data; and the transaction processing status sending unit The transaction processing status is sent to the sender of the transaction processing status acquisition request.

According to another aspect of the present disclosure, there is also provided a computing device, including: at least one processor; and a memory, the memory stores instructions, and when the instructions are executed by the at least one processor, the at least one The processor executes the method for acquiring the transaction processing status as described above. According to another aspect of the present disclosure, there is also provided a machine-readable storage medium that stores executable instructions that, when executed, cause the machine to execute the method for obtaining transaction processing status as described above.

According to another aspect of the present disclosure, there is also provided a computing device, including: at least one processor; and a memory, the memory stores instructions, and when the instructions are executed by the at least one processor, the at least one The processor executes the transaction status acquisition request processing method as described above.

According to another aspect of the present disclosure, there is also provided a non-transitory machine-readable storage medium that stores executable instructions, which when executed, cause the machine to execute the transaction status acquisition request processing method described above .

Using the method and device of the present disclosure, the transaction tracking identifier that uniquely identifies the transaction in the decentralized application cluster can be used to quickly and accurately locate the transaction processing status of each decentralized application, so that the transaction processing status can be quickly obtained.

Description of the drawings

By referring to the following drawings, a further understanding of the nature and advantages of the present disclosure can be achieved. In the drawings, similar components or features may have the same reference signs. The drawings are used to provide a further understanding of the embodiments of the present disclosure, and constitute a part of the specification. Together with the following specific implementations, they are used to explain the embodiments of the specification, but do not constitute a limitation to the embodiments of the specification. In the attached picture:

FIG. 1 shows a schematic diagram of an example of an environment that can be used to execute the method for obtaining transaction processing status in a decentralized application cluster and the method for processing transaction processing status acquisition requests according to the present disclosure;

2 shows a schematic diagram of an example of a system architecture that executes the method for obtaining transaction processing status in a decentralized application cluster and the method for processing transaction processing status acquisition requests according to the present disclosure;

Fig. 3 is a schematic diagram for explaining an example of a decentralized cluster in the present disclosure;

Fig. 4 is a flowchart of a method for obtaining transaction processing status in a decentralized application cluster according to an embodiment of the present specification;

FIG. 5 is a flowchart of an example of the transaction processing process of the decentralized application in the present disclosure;

Fig. 6 is a structural block diagram of an apparatus for obtaining transaction processing status in a decentralized application cluster according to an embodiment of the present specification;

Fig. 7 is a structural block diagram of an apparatus for processing a transaction processing status acquisition request according to an embodiment of the present specification;

Fig. 8 is a structural block diagram of a computing device for executing a method for acquiring a transaction processing status in a decentralized application cluster or a method for processing a transaction processing status acquisition request according to an embodiment of the present specification.

Detailed ways

The subject described herein will be discussed below with reference to example embodiments. It should be understood that the discussion of these embodiments is only to enable those skilled in the art to better understand and realize the subject described herein, and is not to limit the scope of protection, applicability, or examples set forth in the claims. The function and arrangement of the discussed elements can be changed without departing from the scope of protection of the present disclosure. Various examples can omit, substitute, or add various procedures or components as needed. In addition, features described with respect to some examples can also be combined in other examples.

As used herein, the term "including" and its variations mean open terms, meaning "including but not limited to". The term "based on" means "based at least in part on." The terms "one embodiment" and "an embodiment" mean "at least one embodiment." The term "another embodiment" means "at least one other embodiment." Other definitions can be included below, whether explicit or implicit. Unless clearly indicated in the context, the definition of a term is consistent throughout the specification.

The method and device for obtaining transaction processing status in a decentralized application cluster and the method and device for processing transaction processing status acquisition requests of the present disclosure will now be described with reference to the accompanying drawings.

Blockchain is a chain data structure that connects and combines data blocks sequentially in chronological order, and cryptographically ensures that the data blocks cannot be tampered with or forged. The blockchain includes one or more blocks. Each block in the blockchain is linked to the previous block by including the encrypted hash of the immediately preceding block in the blockchain. Each block also includes a timestamp, a cryptographic hash of the block, and one or more transactions. The transaction that has been verified by the nodes of the blockchain network is hashed and a Merkle tree is formed. In the Merkle tree, the data at the leaf nodes is hashed, and for each branch of the Merkle tree, all the hash values of the branch are concatenated at the root of the branch. The above processing is performed on the Merkle tree until the root node of the entire Merkle tree. The root node of the Merkle tree stores hash values representing all data in the Merkle tree. When a hash value claims to be a transaction stored in the Merkle tree, it can be quickly verified by judging whether the hash value is consistent with the structure of the Merkle tree.

Blockchain is a data structure used to store transactions. The blockchain network is a network of computing nodes used to manage, update and maintain one or more blockchain structures. As mentioned above, the blockchain network can include a public blockchain network, a private blockchain network, or a consortium blockchain network.

In the public blockchain network, the consensus process is controlled by the nodes of the consensus network. For example, there may be thousands of entities in a public blockchain network for collaborative processing, and each entity operates at least one node in the public blockchain network. Therefore, the public blockchain network can be considered as a public network of participating entities. In some examples, most entities (nodes) must sign each block in sequence, and add the signed block to the blockchain of the blockchain network. Examples of public blockchain networks may include specific peer-to-peer payment networks. In addition, the term "blockchain" does not specifically refer to any particular blockchain.

The public blockchain network supports public transactions. Public transactions are shared among all nodes in the public blockchain network and stored in the global blockchain. A global blockchain refers to a blockchain that is replicated across all nodes. In order to reach a consensus (for example, agree to add a block to the blockchain), a consensus agreement is implemented in the public blockchain network. Examples of consensus protocols include but are not limited to: proof-of-work (POW), proof-of-stake (POS), and proof-of-authority (POA). In this disclosure, POW is taken as a non-limiting example.

Private blockchain networks are provided for specific entities. The read and write permissions of each node in the private blockchain network are strictly controlled. Therefore, a private blockchain network is usually also called a permissioned network, which restricts who is allowed to participate in the network and the level of network participation (for example, only in certain transaction situations). In a private blockchain network, various types of access control mechanisms can be used (for example, existing participants vote to add new entities, regulatory agencies control permissions, etc.).

The alliance blockchain network is private among participating entities. In the alliance blockchain network, the consensus process is controlled by authorized nodes. For example, a consortium composed of several (for example, 10) entities (for example, financial institutions, insurance companies) can operate a consortium blockchain network, and each entity operates at least one node in the consortium blockchain network. Therefore, the consortium blockchain network can be considered as a private network of participating entities. In some examples, each participating entity (node) must sign each block in sequence and add the block to the blockchain. In some examples, each block may be signed by a subset of participating entities (nodes) (for example, at least 7 entities), and the block may be added to the blockchain.

In the present disclosure, the embodiments of the present disclosure are described in detail with reference to the alliance blockchain network. However, it is expected that the embodiments of the present disclosure can be implemented in any suitable blockchain network.

Blockchain is a tamper-proof shared digital ledger that records transactions in a public or private peer-to-peer network. The ledger is distributed to all member nodes in the network, and the history of asset transactions that occurred in the network is permanently recorded in the block.

The consensus mechanism ensures that all network nodes in the distributed blockchain network execute transactions in the same order and then write to the same ledger. The consensus model aims to solve the Byzantine problem. In the Byzantine problem, components such as servers or network nodes in the distributed blockchain network may malfunction or deliberately spread wrong information to other nodes. Since other network nodes need to reach a consensus on which network node fails first, it is difficult for other network nodes to declare the component failure and exclude it from the blockchain network.

FIG. 1 shows a schematic diagram of an example of an environment 100 that can be used to execute the method for obtaining transaction processing status in a decentralized application cluster and the method for processing transaction processing status acquisition requests according to the present disclosure. In some examples, the environment 100 enables entities to participate in the blockchain network 102. As shown in FIG. 1, the environment 100 includes a network 104, and computing devices/

systems

106, 108. In some examples, the network 104 may include a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, and connect a website, a user device (eg, a computing device), and a back-end system. In some examples, the network 104 may be accessed through a wired and/or wireless communication link. In some examples, the computing devices/

systems

106 and 108 communicate with each other through the network 104, and communicate with the blockchain network 102 through the network 104, and the nodes (or node devices) in the blockchain network 102 pass through The network 104 communicates. Generally, the network 104 represents one or more communication networks. In some cases, the computing devices/

systems

106, 108 may be nodes of a cloud computing system (not shown), or each computing device/

system

106, 108 may be a separate cloud computing system, including interconnection through the network 104 Multiple computers and used as a distributed processing system.

In the illustrated example, each of the computing devices/

systems

106, 108 may include any suitable computing system capable of participating as a node in the blockchain network 102. Examples of computing devices/systems include, but are not limited to, servers, desktop computers, laptops, tablet devices, smart phones, etc. In some examples, one or more computer-implemented services for interacting with the blockchain network 102 may be installed on the computing device/

system

106, 108. For example, the computing device/system 106 may be installed with services of the first entity (for example, user A). For example, the first entity is used to manage transactions with one or more other entities (for example, other users). system. The computing device/system 108 may be installed with services of a second entity (for example, user B), for example, a transaction management system used by the second entity to manage transactions with one or more other entities (for example, other users). In the example of FIG. 1, the blockchain network 102 is represented as a peer-to-peer network of nodes, and the computing devices/

systems

106, 108 serve as the nodes of the first entity and the second entity participating in the blockchain network 102, respectively.

FIG. 2 shows a schematic diagram of an example of a system architecture 200 that executes the method for obtaining transaction processing status in a decentralized application cluster and the method for processing transaction processing status acquisition requests according to the present disclosure. An example of the system architecture 200 includes the

participant systems

202, 204, and 206 corresponding to the participant A, the participant B, and the participant C, respectively. Each participant (eg, user, enterprise) participates in the blockchain network 212 provided as a peer-to-peer network. The blockchain network 212 includes a plurality of nodes 214, wherein at least some of the nodes 214 record information in the blockchain 216, and the recorded information cannot be changed. Although a single blockchain 216 is schematically shown within the blockchain network 212, multiple copies of the blockchain 216 may be provided, and multiple copies are maintained in the blockchain network 212, as described in detail later of.

In the example shown, each

participant system

202, 204, 206 is provided by participant A, participant B, and participant C, or provided as participant A, participant B, and participant C, respectively, And it serves as the corresponding node 214 in the blockchain network 212. As used herein, a node generally refers to a single system (eg, computer, server) connected to the blockchain network 212 and enables corresponding participants to participate in the blockchain network. In the example shown in FIG. 2, the participant corresponds to each node 214. However, one participant can operate multiple nodes 214 within the blockchain network 212, and/or multiple participants can share a single node 214. In some examples, the

participant systems

202, 204, 206 use protocols (e.g., Hypertext Transfer Protocol Security (HTTPS)) and/or use remote procedure calls (RPC) to communicate with the blockchain network 212, or through the blockchain The chain network 212 communicates.

The degree of participation of the node 214 in the blockchain network 212 may vary. For example, some nodes 214 may participate in the consensus process (eg, as miner nodes that add blocks to the blockchain 216), while other nodes 214 do not participate in the consensus process. As another example, some nodes 214 store a complete copy of the blockchain 216, while other nodes 214 only store a partial copy of the blockchain 216. In the example of Figure 2, the

participant systems

202, 204, 206 each store a complete copy of the block chain 216 216', 216", 216"'.

A blockchain (for example, the blockchain 216 in FIG. 2) is composed of a series of blocks, and each block stores data. Examples of data may include transaction data representing transactions between two or more participants. In this disclosure, transactions are used as a non-limiting example, and it is expected that any appropriate data can be stored in the blockchain (for example, documents, images, videos, audios). Examples of transactions may include, but are not limited to, the exchange of valuable things (for example, assets, products, services, currency, etc.). Transaction data is stored immutably in the blockchain.

Before storing in the block, hash the transaction data. Hashing is the process of converting transaction data (provided as string data) into a fixed-length hash value (also provided as string data). After the transaction data is hashed, even a slight change in the transaction data will result in a completely different hash value. The hash value is usually generated by hashing transaction data using a hash function. Examples of hash functions include, but are not limited to, Secure Hash Algorithm (SHA)-256, which outputs a 256-bit hash value.

The transaction data of multiple transactions can be stored in the block after being hashed. For example, two transaction data are hashed to obtain two hash values, and then the two obtained hash values are hashed again to obtain another hash value. This process is repeated until a single hash value is obtained for all transactions to be stored in the block. This hash value is called the Merkle root hash and is stored at the head of the block. Any change in the transaction will cause its hash value to change, and eventually the Merkle root hash value will change.

The block is added to the blockchain through a consensus protocol. Multiple nodes in the blockchain network participate in the consensus protocol and add blocks to the blockchain after competition. Such nodes are called miner nodes (or accounting nodes). The POW introduced above serves as a non-limiting example.

Miner nodes perform a consensus process to add transactions (corresponding blocks) to the blockchain. Although multiple miner nodes participate in the consensus process, only one miner node can write a block to the blockchain. In other words, miner nodes compete in the consensus process to add their blocks to the blockchain. In more detail, the miner node periodically collects pending transactions from the transaction pool (for example, until a predetermined limit on the number of transactions that can be included in the block is reached, if any). The transaction pool includes transaction messages from participants in the blockchain network. Miner nodes create blocks and add transactions to the blocks. Before adding the transaction to the block, the miner node checks whether there is a transaction in the block of the blockchain among the transactions to be added. If the transaction has been added to another block, the transaction will be discarded.

The miner node generates a block header, hashes all transactions in the block, and combines the hash values in pairs to generate further hash values until a single hash value (Merkle root) is obtained for all transactions in the block. Hash). Then, add the Merkle root hash to the block header. The miner also determines the hash value of the latest block in the blockchain (ie, the last block added to the blockchain). Miner nodes can also add random values (nonce values) and timestamps to the block header. During the mining process, the miner node tries to find a hash value that meets the required parameters. The miner node keeps changing the nonce value until it finds a hash value that meets the required parameters.

Every miner in the blockchain network tries to find a hash value that meets the required parameters and competes with each other in this way. Finally, a miner node finds a hash value that meets the required parameters and advertises the hash value to all other miner nodes in the blockchain network. Other miner nodes verify the hash value, and if it is determined to be correct, verify each transaction in the block, accept the block, and attach the block to their copy of the blockchain. In this way, the global state of the blockchain is agreed upon on all miner nodes within the blockchain network. The above process is a POW consensus protocol.

In the example provided in Figure 2, participant A wants to send a certain amount of funds to participant B. Participant A generates a transaction message and sends the transaction message to the blockchain network, and the transaction message is added to the transaction pool. Each miner node in the blockchain network creates a block, obtains transactions from the transaction pool, and adds the transaction to the block. In this way, the transaction issued by participant A is added to the block of the miner node.

In some blockchain networks, cryptography is implemented to maintain the privacy of transactions. For example, if two nodes want to maintain the privacy of the transaction so that other nodes in the blockchain network cannot learn the details of the transaction, the node can encrypt the transaction data. Examples of encryption methods include, but are not limited to, symmetric encryption and asymmetric encryption. Symmetric encryption refers to the encryption process that uses a single key to encrypt (generate ciphertext based on plaintext) and decrypt (generate plaintext based on ciphertext). In symmetric encryption, multiple nodes can use the same key, so each node can encrypt/decrypt transaction data.

Asymmetric encryption refers to the use of key pairs for encryption. Each key pair includes a private key and a public key. The private key is only known to the corresponding node, and the public key is known to any or all other nodes in the blockchain network. A node can use another node's public key to encrypt data, and can use another node's private key to decrypt the encrypted data. For example, refer to Figure 2 again. Participant A can use the public key of participant B to encrypt data and send the encrypted data to participant B. Participant B can use its private key to decrypt the encrypted data (ciphertext) and extract the original data (plain text). Messages encrypted with the public key of the node can only be decrypted with the private key of the node.

Asymmetric encryption is used to provide digital signatures, which enables participants in a transaction to confirm other participants in the transaction and the validity of the transaction. For example, a node can digitally sign a message, and another node can confirm that the message was sent by the node based on the digital signature of participant A. Digital signatures can also be used to ensure that messages are not tampered with during transmission. For example, refer to Figure 2 again. Participant A will send a message to participant B. Participant A generates a hash value of the message, and then uses its private key to encrypt the hash value to generate a digital signature. Participant A attaches the digital signature to the message, and sends the message with the digital signature to participant B. Participant B uses the public key of participant A to decrypt the digital signature, thereby decrypting the corresponding hash value. Participant B hashes the received message to obtain another hash value, and then compares the two hash values. If the hash value is the same, participant B can confirm that the message is indeed from participant A and has not been tampered with.

Although the block chain scenarios to which the present disclosure can be applied are described above, the present disclosure can also be applied to other block chain scenarios. For example, the present disclosure can also be applied to blockchain-like systems. In the quasi-blockchain system, data can be stored in the same block-chain structure. Unlike the blockchain system, in the quasi-blockchain system, the block-chain data stored in the block-chain structure does not need After consensus processing.

FIG. 3 is a schematic diagram for explaining an example of the decentralized cluster in the present disclosure. As shown in Figure 3, the decentralized cluster (DAPP cluster) may include three DAPPs (DAPP1 to DAPP3), and each decentralized application is responsible for the transaction processing of the corresponding process. Figure 3 is just an example of a decentralized cluster. Any number of multiple decentralized applications can exist in a decentralized cluster. The transaction initiator sends the transaction data of the transaction to DAPP1. After DAPP1 completes the corresponding processing, it sends the transaction data processed by DAPP1 to DAPP2. After DAPP3 completes the transaction processing of the last process, the transaction processing result is sent to the blockchain system. China-Israel realizes blockchain accounting processing. In one example, DAPP3 may send the transaction processing result to all nodes in the blockchain network to perform accounting processing. In this specification, a decentralized application can be a decentralized application running on a decentralized application server (or an application running on a decentralized application server side), or a decentralized application running on a user terminal device. Centralized application client. As an example of an application scenario, DAPP1 may be a shopping server of a shopping platform, DAPP2 may be a settlement server of a third-party settlement platform, and DAPP3 may be a bank server.

Fig. 4 is a flowchart of a method for obtaining transaction processing status in a decentralized application cluster and a method for processing transaction processing status acquisition requests according to an embodiment of the present specification. In FIG. 4, the method for acquiring the transaction processing status in the decentralized application cluster is executed by the transaction processing status acquirer, and the method for processing the transaction processing status acquiring request is executed by the decentralized application.

As shown in FIG. 4, in block 402, the transaction processing status acquisition party generates a transaction processing status acquisition request based on the transaction tracking identifier of the transaction in the decentralized application cluster.

The acquirer of the transaction processing status may be, for example, the transaction initiator. When the transaction initiator wants to pay attention to the transaction processing process or transaction processing results and other information, it can be used as the transaction processing status acquisition direction to request the decentralized application to obtain the transaction processing status. The acquirer of the transaction processing status may also be an affiliate of the transaction initiator, and the affiliate may acquire the transaction tracking identifier of the transaction from the transaction initiator to obtain the transaction processing status. In addition, each decentralized application in the decentralized application cluster can also be used as a transaction processing status acquirer to obtain transaction processing status in other decentralized applications. For example, a decentralized application can obtain transaction processing status from other decentralized applications for analysis of the cause of transaction failure or for other business analysis. The transaction processing status can be the transaction processing status being processed, or the transaction processing result after the transaction has been processed by various decentralized applications.

The transaction tracking identifier is used to uniquely identify the transaction in the decentralized application cluster. The transaction tracking identifier can be generated by the transaction initiator. When the transaction initiator initiates a transaction, the transaction data can include a transaction tracking identifier field, and write the transaction tracking identifier generated for the transaction. Each transaction initiator can generate a transaction tracking identifier for its initiated transaction in accordance with its business processing rules, so as to identify the transaction initiated by it in the decentralized application cluster. After each decentralized application receives the transaction data, it performs the transaction processing of the corresponding processing flow on the transaction data, and then sends the transaction data processed by the decentralized application including the transaction tracking identifier to the decentralized application in the next process . As a result, the transaction data always carries the transaction tracking identifier during the entire process of transaction processing, so that the decentralized applications that the transaction passes through can be located according to the transaction tracking identifier, and the transaction status in each decentralized application can be located.

In order to avoid overlap of transaction tracking identifiers generated by different transaction initiators, each decentralized application in the decentralized application cluster can agree on identifier generation rules, and each transaction initiator can generate transaction tracking identifiers based on the identifier generation rules. , To ensure that the generated transaction tracking identifier can uniquely identify each transaction.

The same transaction can have multiple transaction tracking identifiers. For example, in the example of the transaction tracking identifier generated by the transaction initiator, if the transaction initiator sends the transaction data to the decentralized application cluster, the transaction processing failure occurs (the decentralized application that fails the transaction processing can report to the transaction initiator Sending a notification message of transaction processing failure), the transaction initiator can send transaction data to the decentralized application cluster again for the transaction to initiate the transaction again. When sending transaction data again, a new transaction tracking identifier can be regenerated and included in the transaction data sent this time, and the previous transaction tracking identifier in the transaction data sent last time can be included in the transaction data sent this time In the transaction data. The previous transaction tracking identifier can be written into the historical transaction tracking identifier field. Including the previous transaction tracking identifier in the transaction data helps each decentralized application analyze the historical transaction processing that failed to process, analyze the cause of the processing failure, and take optimization measures.

The transaction processing status acquisition party may assemble the transaction tracking identifier into the transaction tracking identifier field of the transaction processing status acquisition request to generate the transaction processing status acquisition request. In another example, after the transaction tracking identifier is encrypted, the transaction processing status acquisition request may be generated based on the encryption processing result.

After the transaction processing status acquisition request is generated, at 404, the transaction processing status acquisition party sends the transaction processing status acquisition request to the decentralized application in the decentralized application cluster. The transaction processing status acquisition request can be sent to one or more decentralized applications in the decentralized application cluster. Taking Figure 3 as an example, when the transaction processing fails, the transaction initiator can send transaction processing status acquisition requests to DAPP1 to DAPP3 one by one to determine the processing flow in which the processing failed, and analyze the reason for the failure. After analyzing the reason for the failure, corrective measures can be taken and the transaction can be initiated again. In another example, after the transaction processing is completed and successfully connected to the chain, any decentralized application in the decentralized application cluster can send transaction processing status acquisition requests to other decentralized applications to obtain transactions in each decentralized application. The transaction processing results in the application for business analysis.

After the decentralized application receives the transaction status acquisition request, in 406, based on the transaction tracking identifier in the transaction status acquisition request, acquire the transaction processing status of the corresponding transaction from the local transaction processing data. When the transaction status acquisition request or the transaction tracking identifier is encrypted, the decentralized application can also use the corresponding decryption algorithm to decrypt the transaction tracking identifier.

After the decentralized application obtains the transaction processing status locally, in 408, the acquired transaction tracking identifier is sent to the transaction processing status acquirer. As a result, the transaction processing status acquirer can acquire the transaction processing status of the transaction from the decentralized application.

Through this embodiment, the transaction tracking identifier of the transaction can be used to obtain the transaction processing status of each decentralized application in the decentralized application cluster. And in the process of obtaining the transaction processing status, there is no need to perform additional calculations based on the business logic of each decentralized application, so that the efficiency of obtaining the transaction processing status can be improved. In a scenario that does not include the transaction tracking identifier, each decentralized application can generate a transaction processing identifier for the transaction (for example, the transaction serial number in each decentralized application) when processing the corresponding transaction process, so as to The decentralization should identify the corresponding transaction. After the current decentralized application completes processing, its transaction processing identifier is included in the transaction processing result data and sent to the subsequent decentralized application. After the latter decentralized application receives the transaction processing identifier of the previous decentralized application, the transaction processing identifier is stored as the parent identifier of the transaction. In this scenario, the transaction processing identifiers of each decentralized application are related to each other. When it is necessary to obtain the processing status of the transaction in the decentralized application, it is necessary to first analyze the transaction data processing link between each decentralized application. This increases the complexity of the acquisition process. With this embodiment, this complexity can be avoided.

The transaction tracking identifier may also be generated by a decentralized application in a decentralized application cluster. This example will be described below with reference to FIG. 5. FIG. 5 is a flowchart of an example of the transaction processing process of the decentralized application in the present disclosure.

As shown in Figure 5, at block 502, the decentralized application receives transaction data for the transaction. Taking Figure 3 as an example, when the decentralized application is DAPP1, the transaction data can be received from the transaction initiator, and when the decentralized application is DAPP2 or DAPP3, the transaction data can be received from the previous decentralized application.

After the transaction data is received, at block 504, it is determined whether the transaction tracking identifier is included in the transaction data. When the transaction data does not include the transaction tracking identifier field or the transaction tracking identifier field is empty, it can be determined that the received transaction data does not include the transaction tracking identifier.

When it is determined that the received transaction data does not include a transaction tracking identifier, in block 506, a transaction tracking identifier is generated for the corresponding transaction. The generated transaction tracking identifier can be written into the transaction tracking identifier field of the transaction data, or the transaction tracking identifier can be written after the transaction tracking identifier field is created. In one example, the transaction tracking identifier can be generated by the first decentralized application that the transaction passes through in the decentralized application cluster, so as to avoid overlapping of each transaction tracking identifier, so that the transaction tracking identifier of each transaction can be Uniquely identify the transaction.

In one example, the transaction initiator may not pay attention to the processing status of the transaction, and thus may not generate the transaction tracking identifier when initiating the transaction. However, even if the transaction initiator does not pay attention to the transaction processing status, decentralized applications may require transaction processing status in other decentralized applications due to business analysis and other reasons. Therefore, the decentralized application that receives the transaction data can generate a transaction tracking identifier for the transaction, so that when there is a need to obtain the transaction processing status, the transaction processing status of the subsequent transaction processing flow can be obtained based on the transaction tracking identifier. In addition to the first decentralized application in the transaction processing flow, other decentralized applications in the transaction processing flow can also generate a transaction tracking identifier when there is no transaction tracking identifier in the transaction data.

In an example, the transaction tracking identifiers corresponding to each decentralized application may be the same. For example, in an example where the transaction tracking identifier is generated by the transaction initiator or the first decentralized application, the transaction tracking identifier follows the transaction data of the transaction until the final processing is completed. In this case, the transaction processing status acquirer can acquire the transaction processing status from each decentralized application based on the same transaction tracking identifier. In another example, the transaction tracking identifiers corresponding to various decentralized applications may also be different. For example, the transaction may include a transaction tracking identification field corresponding to each decentralized application. After each decentralized application receives the transaction data, if the transaction tracking identifier field corresponding to the decentralized application is empty, it can generate its own transaction tracking identifier and write it into the corresponding transaction tracking identifier field. A decentralized application that does not pay attention to the transaction processing status may not generate a transaction tracking identifier corresponding to the decentralized application. In this way, it is possible to analyze the transaction processing issues concerned by each decentralized application according to whether the transaction tracking identifier corresponding to each decentralized application is empty.

The transaction tracking identifier generated by the decentralized application can be sent to the transaction initiator. When the decentralized application that generates the transaction tracking identifier is not the first decentralized application in the transaction processing flow, the generated transaction tracking identifier can also be sent to the previous decentralized application.

After the transaction tracking identifier is generated or when the received transaction data includes the transaction tracking identifier, at block 508, transaction processing is performed based on the transaction data, and after the transaction processing is completed, the transaction data including the transaction tracking identifier is sent to the next Decentralized application. When the decentralized application is the last decentralized application in the transaction processing path, the transaction processing data can be sent to the blockchain node that performs accounting processing.

In one example, in a process in which a decentralized application executes corresponding transaction processing based on transaction data, if the transaction processing fails, the corresponding transaction processing can be executed again based on the received transaction data. In this example, if the transaction processing fails, the decentralized application can include the original transaction tracking identifier in the transaction processing data of the previous processing and store it in the transaction processing record, and regenerate transaction tracking for the transaction And then include the regenerated transaction tracking identifier in the transaction processing data of the transaction processing to be executed again. As a result, the decentralized application or other decentralized applications can obtain transaction processing data of each transaction processing based on the transaction tracking identifier to perform business analysis, for example, the reason for transaction failure can be analyzed. The regenerated transaction tracking identifier can also be generated based on the original transaction tracking identifier, so as to establish a connection between the two, so that one can obtain the other. For example, the original transaction tracking identifier can be obtained based on the regenerated transaction tracking identifier. In another example, when the transaction processing is executed again, the original transaction tracking identifier may be included in the transaction processing data when the transaction processing is executed again.

Fig. 6 is a structural block diagram of an apparatus for obtaining transaction processing status in a decentralized application cluster according to an embodiment of the present specification. As shown in FIG. 6, the transaction processing state obtaining device 600 includes a processing state obtaining request generating unit 610, a processing state obtaining request sending unit 620 and a transaction processing state obtaining unit 630.

The processing state acquisition request generating unit 610 generates a transaction processing state acquisition request based on the transaction tracking identifier of the transaction in the decentralized application cluster. The transaction tracking identifier is used to uniquely identify the transaction in the decentralized application cluster. After the processing state acquisition request is generated, the processing state acquisition request sending unit 620 sends the transaction processing state acquisition request to the decentralized application in the decentralized application cluster. The transaction processing status acquiring unit 630 acquires the transaction processing status of the transaction from the decentralized application.

The transaction tracking identifier may be generated by the transaction initiator of the transaction, or it may be generated by the decentralized application when the transaction tracking identifier field of the transaction is empty. In an example, the transaction tracking identification may be generated based on identification generation rules agreed by each decentralized application in the decentralized application cluster. The transaction tracking identifier may also be regenerated by the decentralized application when the transaction processing for the transaction fails. In addition, the transaction tracking identifier corresponding to each decentralized application in the decentralized application cluster may be the same.

Fig. 7 is a structural block diagram of an apparatus for processing a transaction processing status acquisition request according to an embodiment of the present specification. As shown in FIG. 7, the transaction processing status acquisition request processing device 700 includes a processing status acquisition request receiving unit 710, a transaction processing status acquisition unit 720, and a transaction processing status sending unit 730.

The processing status acquisition request receiving unit 710 receives the transaction processing status acquisition request. The transaction processing status acquisition request is generated based on the transaction tracking identifier of the transaction in the decentralized application cluster, and the transaction tracking identifier is used in the decentralized application cluster. Uniquely identify the transaction. The transaction processing status acquisition unit 720 acquires the transaction processing status of the transaction from the local transaction processing data based on the transaction tracking identifier in the transaction processing status acquisition request. After the transaction processing status is acquired locally, the transaction processing status sending unit 730 sends the transaction processing status to the sender of the transaction processing status acquisition request.

1 to 7, the embodiments of the method and device for obtaining transaction processing status in a decentralized application cluster and the method and device for processing transaction processing status acquisition requests according to the present disclosure have been described above. The details mentioned in the above description of the method embodiment are also applicable to the embodiment of the device of the present disclosure.

The device for acquiring transaction processing status in a decentralized application cluster and the device for processing transaction processing status acquisition requests of the present disclosure can be implemented by hardware, or can be implemented by software or a combination of hardware and software. The various embodiments in this specification are described in a progressive manner, and the same or similar parts among the various embodiments are referred to each other.

The device for acquiring transaction processing status in a decentralized application cluster and the device for processing transaction processing status acquisition requests of the present disclosure can be implemented by hardware, or can be implemented by software or a combination of hardware and software. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions in the memory into the memory by the processor of the device where it is located. In the present disclosure, the device for generating a multi-layer block chain structure and the device for updating the trust point can be implemented using a computing device, for example.

Fig. 8 is a structural block diagram of a computing device for executing a method for acquiring a transaction processing status in a decentralized application cluster or a method for processing a transaction processing status acquisition request according to an embodiment of the present specification. As shown in FIG. 8, the computing device 800 includes a processor 810, a memory 820, a memory 830, a communication interface 840, and an internal bus 850, and the processor 810, a memory (for example, a non-volatile memory) 820, a memory 830, and a communication interface 840 are connected together via a bus 850. According to an embodiment, the computing device 800 may include at least one processor 810 that executes at least one computer-readable instruction (ie, the aforementioned Elements implemented in software).

In one embodiment, computer-executable instructions are stored in the memory 820, which when executed, cause at least one processor 810 to: generate a transaction processing status acquisition request based on the transaction tracking identifier of the transaction in the decentralized application cluster, The transaction tracking identifier is used to uniquely identify the transaction in the decentralized application cluster; send the transaction processing status acquisition request to the decentralized application in the decentralized application cluster; The decentralized application office obtains the transaction processing status of the transaction.

In another embodiment, computer-executable instructions are stored in the memory 820, which, when executed, cause at least one processor 810 to: receive a transaction processing status acquisition request, the transaction processing status acquisition request being based on the transaction in the decentralized The transaction tracking identifier in the application cluster is generated, and the transaction tracking identifier is used to uniquely identify the transaction in the decentralized application cluster; the transaction tracking identifier in the request is acquired based on the transaction processing status, and the transaction tracking identifier is obtained locally Acquiring the transaction processing status of the transaction from the transaction processing data; and sending the transaction processing status to the sender of the transaction processing status acquisition request.

It should be understood that the computer-executable instructions stored in the memory 820, when executed, cause at least one processor 810 to perform various operations and functions described above in conjunction with FIGS. 1 to 7 in the various embodiments of the present disclosure.

According to one embodiment, a program product such as a non-transitory machine-readable medium is provided. The non-transitory machine-readable medium may have instructions (ie, the above-mentioned elements implemented in the form of software), which when executed by a machine, cause the machine to execute the various embodiments described above in conjunction with FIGS. 1 to 7 in the various embodiments of the present disclosure. Operation and function.

Specifically, a system or device equipped with a readable storage medium may be provided, and the software program code for realizing the function of any one of the above-mentioned embodiments is stored on the readable storage medium, and the computer or device of the system or device The processor reads and executes the instructions stored in the readable storage medium.

In this case, the program code itself read from the readable medium can implement the function of any one of the above embodiments, so the machine readable code and the readable storage medium storing the machine readable code constitute the present disclosure a part of.

Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD-RW), magnetic tape, Volatile memory card and ROM. Alternatively, the program code can be downloaded from the server computer or the cloud via the communication network.

The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than in the embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Not all steps and units in the above processes and system structure diagrams are necessary, and some steps or units can be omitted according to actual needs. The order of execution of each step is not fixed and can be determined as needed. The device structure described in the foregoing embodiments may be a physical structure or a logical structure, that is, some units may be implemented by the same physical entity, or some units may be implemented by multiple physical entities, or may be implemented by multiple physical entities. Some components in independent devices are implemented together.

The term "exemplary" used throughout this specification means "serving as an example, instance, or illustration", and does not mean "preferred" or "advantageous" over other embodiments. The detailed description includes specific details for the purpose of providing an understanding of the described technology. However, these techniques can be implemented without these specific details. In some instances, in order to avoid incomprehensibility to the concepts of the described embodiments, well-known structures and devices are shown in the form of block diagrams.

The above describes the optional implementation manners of the embodiments of the present disclosure in detail with reference to the accompanying drawings. However, the embodiments of the present disclosure are not limited to the specific details in the above-mentioned implementation manners. Within the scope of the technical concept of the embodiments of the present disclosure, the present disclosure can be modified. The technical solutions of the disclosed embodiments are subjected to a variety of simple modifications, and these simple modifications all fall within the protection scope of the embodiments of the present disclosure.

The foregoing description of the present disclosure is provided to enable any person of ordinary skill in the art to implement or use the present disclosure. For those of ordinary skill in the art, various modifications to the present disclosure are obvious, and the general principles defined herein can also be applied to other modifications without departing from the scope of protection of the present disclosure. . Therefore, the present disclosure is not limited to the examples and designs described herein, but is consistent with the widest scope that conforms to the principles and novel features disclosed herein.

Claims

A method for obtaining transaction processing status in a decentralized application cluster, including:

Generating a transaction processing status acquisition request based on the transaction tracking identifier of the transaction in the decentralized application cluster, where the transaction tracking identifier is used to uniquely identify the transaction in the decentralized application cluster;

Sending the transaction processing status acquisition request to the decentralized application in the decentralized application cluster; and

Obtain the transaction processing status of the transaction from the decentralized application.
The method according to claim 1, wherein the transaction tracking identifier is generated based on an identifier generation rule agreed upon by each decentralized application in the decentralized application cluster.
The method of claim 1, wherein the transaction tracking identifier is generated by a transaction initiator of the transaction.
The method of claim 1, wherein the transaction tracking identifier is generated by the decentralized application when the transaction data of the transaction does not include the transaction tracking identifier.
The method of claim 1, wherein the transaction tracking identifier is regenerated by the decentralized application when the transaction processing for the transaction fails.
The method according to claim 1, wherein the transaction tracking identifiers corresponding to each decentralized application in the decentralized application cluster are the same.
A method for processing a transaction processing status acquisition request, the method being executed by a decentralized application in a decentralized application cluster, the method comprising:

Receive a transaction processing status acquisition request, the transaction processing status acquisition request is generated based on the transaction tracking identifier of the transaction in the decentralized application cluster, and the transaction tracking identifier is used to be unique in the decentralized application cluster To identify the transaction;

Obtain the transaction processing status of the transaction from the local transaction processing data based on the transaction tracking identifier in the transaction processing status acquisition request; and

The transaction processing status is sent to the sender of the transaction processing status acquisition request.
A device for obtaining transaction processing status in a decentralized application cluster includes:

The processing state acquisition request generating unit generates a transaction processing state acquisition request based on the transaction tracking identifier of the transaction in the decentralized application cluster, where the transaction tracking identifier is used to uniquely identify the transaction in the decentralized application cluster. Said transaction;

A processing state acquisition request sending unit, which sends the transaction processing state acquisition request to the decentralized application in the decentralized application cluster; and

The transaction processing status acquiring unit acquires the transaction processing status of the transaction from the decentralized application.
The apparatus of claim 8, wherein the transaction tracking identifier is generated based on the identifier generation rules agreed by each decentralized application in the decentralized application cluster.
8. The apparatus of claim 8, wherein the transaction tracking identifier is generated by a transaction initiator of the transaction.
The device of claim 8, wherein the transaction tracking identifier is generated by the decentralized application when the transaction data of the transaction does not include the transaction tracking identifier.
8. The device of claim 8, wherein the transaction tracking identifier is regenerated by the decentralized application when the transaction processing for the transaction fails.
8. The apparatus according to claim 8, wherein the transaction tracking identifiers corresponding to each decentralized application in the decentralized application cluster are the same.
A device for processing a transaction processing status acquisition request, the device being used for a decentralized application in a decentralized application cluster, the device comprising:

The processing status acquisition request receiving unit receives a transaction processing status acquisition request, where the transaction processing status acquisition request is generated based on the transaction tracking identifier of the transaction in the decentralized application cluster, and the transaction tracking identifier is Uniquely identify the transaction in the decentralized application cluster;

A transaction processing status acquiring unit, which acquires the transaction processing status of the transaction from the local transaction processing data based on the transaction tracking identifier in the transaction processing status acquisition request; and

The transaction processing status sending unit sends the transaction processing status to the sender of the transaction processing status acquisition request.
A computing device including:

At least one processor; and

A memory, where the memory stores instructions, and when the instructions are executed by the at least one processor, the at least one processor executes the method according to any one of claims 1 to 6.
A machine-readable storage medium storing executable instructions, which when executed, cause the machine to execute the method according to any one of claims 1 to 6.
A computing device including:

At least one processor; and

A memory, where the memory stores instructions, and when the instructions are executed by the at least one processor, the at least one processor executes the method according to claim 7.
A machine-readable storage medium storing executable instructions, which when executed, cause the machine to execute the method according to claim 7.