CN111162970A

CN111162970A - Method and device for testing decentralized application server in block chain system

Info

Publication number: CN111162970A
Application number: CN201911389907.0A
Authority: CN
Inventors: 陈盛龙; 杨达一
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2019-12-30
Filing date: 2019-12-30
Publication date: 2020-05-15
Anticipated expiration: 2039-12-30
Also published as: CN111162970B

Abstract

An embodiment of the present specification provides a method and an apparatus for testing a decentralized application server in a blockchain system, where the method includes: performing a predetermined test operation in the blockchain system; executing, by the decentralized application server, a predetermined service request in the blockchain system; and acquiring an execution result of the decentralized application server aiming at the preset service request, wherein the execution result is used for determining the running state of the decentralized application server.

Description

Method and device for testing decentralized application server in block chain system

Technical Field

Embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and an apparatus for testing a decentralized application server in a blockchain system.

Background

Decentralized Applications (DAPP) are applications that run in decentralized networks (i.e., blockchain networks) where there are typically no centralized nodes that can fully control the decentralized applications. A full decentralized application needs to be a fully open source and autonomous application. Upgrades to decentralized applications must be agreed upon by most users before they can be made. Data involved in the decentralized application must be stored encrypted on the decentralized application platform. A decentralized application typically includes an on-chain intelligent contract module and an off-chain service module for a blockchain. The on-chain intelligent contract module can write an intelligent contract according to a virtual machine provided by the blockchain system, and the off-chain service module provides a user service function and can be developed according to a software development kit corresponding to the blockchain system.

The decentralized application server needs to be tested when put into use or when problems arise after put into use. There is a need in the art for a solution that can adequately and efficiently test a decentralized application server.

Disclosure of Invention

In view of the foregoing, embodiments of the present specification provide a method and apparatus for testing a decentralized application server in a blockchain system.

According to an aspect of embodiments herein, there is provided a method of testing a decentralized application server in a blockchain system, comprising: performing a predetermined test operation in the blockchain system; executing, by the decentralized application server, a predetermined service request in the blockchain system; and acquiring an execution result of the decentralized application server aiming at the preset service request, wherein the execution result is used for determining the running state of the decentralized application server.

Optionally, in an example, the method may include: determining an operating state of the decentralized application server based on the execution result.

Optionally, in an example, the predetermined service request may include a blockchain data query request, the execution result includes first predetermined data provided after the execution of the blockchain data query request by the decentralized application server, and the performing the predetermined test operation in the blockchain system may include: calling a data query instruction aiming at block chain data in a block chain, and acquiring second preset data from the block chain; determining the operational state of the decentralized application server based on the execution result may include: determining an operational state of the decentralized application server based on a correspondence between the first predetermined data and the second predetermined data.

Optionally, in an example, the blockchain system may include a distributed consensus network, and performing a predetermined test operation in the blockchain system may include: controlling a network state in the distributed consensus network and/or a node state of each network node in the distributed consensus network, the executing of the predetermined service request by the decentralized application server in the blockchain system comprising: in the blockchain system after the predetermined test operation is performed, causing the decentralized application server to perform a predetermined service request for the blockchain system.

Optionally, in an example, performing a predetermined test operation in the blockchain system may include: performing, via the decentralized application server, intelligent contract testing operations for intelligent contracts in the blockchain system; executing, by the decentralized application server, the predetermined service request in the blockchain system may include: in the blockchain system after the intelligent contract testing operation is performed, causing the decentralized application server to perform a predetermined service request for the blockchain system.

Optionally, in one example, the intelligent contract testing operation may include: configuring a new intelligent contract in the blockchain system; and/or adjusting contract parameters of the intelligent contract.

Optionally, in an example, the performing a predetermined test operation in the blockchain system may include: defining a blockchain system event, the executing of the predetermined service request in the blockchain system by the decentralized application server comprising: performing, by the decentralized application server, an event subscription operation for the blockchain system event.

Optionally, in an example, performing a predetermined test operation in the blockchain system may include: controlling the database of the decentralized application server to simulate a database failure event; and/or performing corresponding operation on the data in the database based on the operation instruction for the database.

Optionally, in an example, performing a predetermined test operation in the blockchain system may include: the method comprises the steps of running a decentralized application client on a plurality of terminal devices, and sending a predetermined service request to a decentralized application server through the decentralized application client running on the plurality of terminal devices.

According to another aspect of the embodiments of the present specification, there is further provided an apparatus for testing a decentralized application server in a blockchain system, including: a test operation execution unit that executes a predetermined test operation in the blockchain system; a service request execution unit for executing a predetermined service request in the blockchain system by the decentralized application server; and an execution result acquisition unit, configured to acquire an execution result of the predetermined service request from the decentralized application server, where the execution result is used to determine an operation state of the decentralized application server.

Optionally, in an example, the apparatus may further include: and the running state determining unit is used for determining the running state of the decentralized application server based on the execution result.

Optionally, in an example, the predetermined service request may include a blockchain data query request, the execution result includes first predetermined data provided after the execution of the blockchain data query request by the decentralized application server, and the test operation performing unit includes: the data query module calls a data query instruction aiming at the block chain data in the block chain and acquires second preset data from the block chain; the operation state determination unit determines the operation state of the decentralized application server based on the consistency between the first predetermined data and the second predetermined data.

Optionally, in an example, the blockchain system may include a distributed consensus network, and the test operation performing unit may include: a distributed consensus network environment control module controlling a network state in the distributed consensus network and/or a node state of each network node in the distributed consensus network, the service request execution unit causing the decentralized application server to execute a predetermined service request for the blockchain system in the blockchain system after the predetermined test operation is performed.

Optionally, in an example, the test operation performing unit may include: an intelligent contract testing operation execution module for executing intelligent contract testing operation aiming at the intelligent contract in the blockchain system through the decentralized application server; the service request execution unit causes the decentralized application server to execute a predetermined service request for the blockchain system in the blockchain system after the intelligent contract testing operation is executed.

Optionally, in one example, the intelligent contract testing operation may include: configuring a new intelligent contract in the blockchain system; and/or altering contract parameters of the intelligent contract.

Optionally, in an example, the test operation performing unit may include: and the subscription service testing module defines a block chain system event, and the service request execution unit enables the decentralized application server to execute an event subscription operation aiming at the block chain system event.

Optionally, in an example, the test operation performing unit may include: the database fault simulation module is used for controlling the database of the decentralized application server so as to simulate a database fault event; and/or the data operation testing module executes corresponding operation on the data in the database based on the operation instruction aiming at the database.

Alternatively, in an example, the test operation execution unit may run a decentralized application client on a plurality of terminal devices, and the service request transmission unit may transmit a predetermined service request to the decentralized application server via the decentralized application client running on the plurality of terminal devices.

According to another aspect of embodiments of the present specification, there is also provided a computing device including: at least one processor; and a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the method as described above.

According to another aspect of embodiments herein, there is also provided a non-transitory machine-readable storage medium storing executable instructions that, when executed, cause the machine to perform the method as described above.

By utilizing the method and the device in the embodiment of the specification, the operation environment of the decentralized application server in the formal use process can be comprehensively and really simulated by uniformly testing the decentralized application server in the block chain system, so that the decentralized application server can be fully and effectively tested, and the influence on the formal use caused by the fact that potential problems cannot be found in the test process is avoided.

Drawings

A further understanding of the nature and advantages of the contents of the embodiments of the present specification may be realized by reference to the following drawings. In the drawings, similar components or features may have the same reference numerals. The accompanying drawings, which are included to provide a further understanding of the embodiments of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the detailed description serve to explain the embodiments of the invention. In the drawings:

FIG. 1 illustrates a schematic diagram of an example of an environment that may be used to perform a method of testing a decentralized application server in a blockchain system in accordance with an embodiment of the present specification;

FIG. 2 illustrates a schematic diagram of an example of a system architecture to perform a method of testing a decentralized application server in a blockchain system according to an embodiment of the present description;

FIG. 3 is a block diagram of an exemplary block chain system to which embodiments of the present disclosure are applicable;

FIG. 4 is a flow diagram of a method of testing a decentralized application server in a blockchain system according to one embodiment of the present description;

FIG. 5 is a flow diagram of a method of testing a decentralized application server in a blockchain system, according to another embodiment of the present description;

FIG. 6 is a flow diagram of a method of testing a decentralized application server in a blockchain system, according to another embodiment of the present description;

FIG. 7 is a flow diagram of a method of testing a decentralized application server in a blockchain system according to another embodiment of the present description;

FIG. 8 is a flow diagram of a method of testing a decentralized application server in a blockchain system, according to another embodiment of the present description;

FIG. 9 is a flow diagram of a method of testing a decentralized application server in a blockchain system according to another embodiment of the present description;

FIG. 10 is a block diagram of an apparatus for testing a decentralized application server in a blockchain system, according to one embodiment of the present description;

FIG. 11 is a block diagram of an example of a test operation execution unit in the apparatus for testing a decentralized application server in a blockchain system as shown in FIG. 10; and

FIG. 12 is a block diagram of a computing device for a method of testing a decentralized application server in a blockchain system, according to one embodiment of the present description.

Detailed Description

The subject matter described herein will be discussed with reference to example embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and thereby implement the subject matter described herein, and are not intended to limit the scope, applicability, or examples set forth in the claims. Changes may be made in the function and arrangement of elements discussed without departing from the scope of the embodiments of the disclosure. Various examples may omit, substitute, or add various procedures or components as needed. In addition, features described with respect to some examples may also be combined in other examples.

As used herein, the term "include" and its variants mean open-ended terms in the sense of "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, whether explicit or implicit, may be included below. The definition of a term is consistent throughout the specification unless the context clearly dictates otherwise.

The method and apparatus for testing decentralized application servers in a blockchain system according to embodiments of the present disclosure will now be described with reference to the drawings.

The block chain is a chain data structure formed by connecting and combining data blocks according to a time sequence, and the data blocks are guaranteed to be not falsifiable and not forged in a cryptographic mode. A block chain includes one or more blocks. Each chunk in the chain of chunks is linked to the immediately preceding chunk in the chain of chunks by including a cryptographic hash of the preceding chunk. Each chunk also includes a timestamp, a cryptographic hash of the chunk, and one or more transactions (transactions). Transactions that have been verified by nodes of the blockchain network are hashed and form a Merkle tree. In a Merkle tree, data at leaf nodes is hashed and, for each branch of the Merkle tree, all hash values of the branch are concatenated at the root of the branch. The above process is performed for the Merkle tree up to the root node of the entire Merkle tree. The root node of the Merkle tree stores a hash value representing all the data in the Merkle tree. When a hash value claims to be a transaction stored in the Merkle tree, a quick verification can be performed by determining whether the hash value is consistent with the structure of the Merkle tree.

A blockchain is a data structure used to store transactions. A blockchain network is a network of computing nodes used to manage, update and maintain one or more blockchain structures. As described above, the blockchain network may include a public blockchain network, a private blockchain network, or a federated blockchain network.

In a public blockchain network, the consensus process is controlled by nodes of the consensus network. For example, there may be thousands of entity co-processes in a public blockchain network, each entity operating at least one node in the public blockchain network. Thus, a public blockchain network may be considered a public network of participating entities. In some examples, most entities (nodes) must sign each chunk in sequence and add the signed chunk to the blockchain of the blockchain network. An example of a public blockchain network may include a particular peer-to-peer payment network. Furthermore, the term "blockchain" does not particularly refer to any particular blockchain.

Public blockchain networks support public transactions. Public transactions are shared among all nodes within a public blockchain network and are stored in a global blockchain. A global blockchain refers to a blockchain that is replicated across all nodes. To achieve consensus (e.g., agree to add blocks to a blockchain), a consensus protocol is implemented within a public blockchain network. Examples of consensus protocols include, but are not limited to: proof of work (POW), proof of rights (POS), and proof of authority (POA). In the embodiments of the present specification, POW is taken as a non-limiting example.

A private blockchain network is provided for a particular entity. The read-write authority of each node in the private blockchain network is strictly controlled. Thus, private blockchain networks, also commonly referred to as licensed networks, limit who is allowed to participate in the network and the level of network participation (e.g., only in certain transaction scenarios). In private blockchain networks, various types of access control mechanisms may be used (e.g., existing participants voting for adding new entities, regulatory body controlled permissions, etc.).

A federation blockchain network is private between participating entities. In a federated blockchain network, the consensus process is controlled by an authorizing node. For example, a federation consisting of several (e.g., 10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, each entity operating at least one node in the federated blockchain network. Thus, a federated blockchain network can be considered a private network of participating entities. In some examples, each participating entity (node) must sign each chunk in sequence and add the chunk to the chain of chunks. In some examples, each tile may be signed by a subset of participating entities (nodes) (e.g., at least 7 entities) and added to the tile chain.

Embodiments of the present specification embodiments are described in detail with reference to a federated blockchain network in the present specification embodiments. However, it is contemplated that embodiments of the present specification can be implemented in any suitable blockchain network.

Blockchains are tamper-resistant shared digital ledgers that record transactions in public or private peer-to-peer networks. Ledgers are distributed to all member nodes in the network and asset transaction histories occurring in the network are permanently recorded in blocks.

The consensus mechanism ensures that all network nodes in the distributed blockchain network perform transactions in the same order and then write the same ledger. The consensus model aims at solving the byzantine problem. In the byzantine problem, components such as servers or network nodes in a distributed blockchain network may fail or intentionally propagate erroneous information to other nodes. Other network nodes have difficulty declaring the component as a failure and excluding it from the blockchain network because they need to agree first on which network node failed first.

Fig. 1 illustrates a schematic diagram of an example of an environment 100 that may be used to perform a method of testing a decentralized application server in a blockchain system according to an embodiment of the present description. In some examples, environment 100 enables entities to participate in blockchain network 102. As shown in FIG. 1, 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 connects websites, user devices (e.g., computing devices), and backend systems. In some examples, network 104 may be accessed through wired and/or wireless communication links. In some examples, computing devices/

systems

106, 108 communicate with each other over network 104, as well as with blockchain network 102 over network 104, and nodes (or node devices) in blockchain network 102 communicate over network 104. In general, 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 that includes multiple computers interconnected by the network 104 and functions as a distributed processing system.

In the illustrated example, each of the computing devices/

systems

106, 108 may comprise 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, smartphones, and the like. In some examples, one or more computer-implemented services may be installed on the computing devices/

systems

106, 108 for interacting with the blockchain network 102. For example, the computing device/system 106 may have installed thereon a service of a first entity (e.g., user a), such as a transaction management system used by the first entity to manage its transactions with one or more other entities (e.g., other users). The computing device/system 108 may have installed thereon a service of a second entity (e.g., user B), such as a transaction management system used by the second entity to manage its transactions with one or more other entities (e.g., 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 act as nodes for first and second entities participating in the blockchain network 102, respectively.

Fig. 2 shows a schematic diagram of an example of a system architecture 200 that performs a method of testing a decentralized application server in a blockchain system according to an embodiment of the present description. An example of system architecture 200 includes

participant systems

202, 204, 206 corresponding to participant a, participant B, and participant C, respectively. Each participant (e.g., user, enterprise) participates in blockchain network 212, which is 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 blockchain 216, and the recorded information is not alterable. Although a single blockchain 216 is schematically shown within blockchain network 212, multiple copies of blockchain 216 may be provided and maintained in blockchain network 212, as described in detail later.

In the illustrated example, each

participant system

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

participant systems

202, 204, 206 communicate with the blockchain network 212 using a protocol (e.g., hypertext transfer protocol secure (HTTPS)) and/or using Remote Procedure Calls (RPCs), or communicate over the blockchain network 212.

The node 214 may have different participation in the blockchain network 212. For example, some nodes 214 may participate in the consensus process (e.g., as miners' nodes that add tiles to the blockchain 216), while other nodes 214 do not participate in the consensus process. As another example, some nodes 214 store a full copy of blockchain 216, while other nodes 214 store only partial copies of blockchain 216. In the example of fig. 2, the

participant systems

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

A block chain (e.g., block chain 216 in fig. 2) consists of a series of blocks, each of which stores data. Examples of data may include transaction data representing transactions between two or more parties. In the present specification embodiments, transactions are used as non-limiting examples, and it is contemplated that any suitable data may be stored in the blockchain (e.g., documents, images, video, audio). Examples of transactions may include, but are not limited to, exchanging things of value (e.g., assets, products, services, and currency, etc.). Transaction data is unalterably stored in the blockchain.

The transaction data is hashed prior to storage in the block. The hash process is a process of converting transaction data (provided as character string data) into a hash value of a fixed length (also provided as character string data). After the transaction data is subjected to the hash processing, even if slight change occurs in the transaction data, completely different hash values can be obtained. The hash value is typically generated by hashing the 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.

Transaction data for a plurality of transactions may 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 a Merkle root hash and is stored at the head of the chunk. Any change to a transaction will cause its hash value to change, eventually causing the Merkle root hash value to change.

The blocks are added to the block chain by a consensus protocol. Multiple nodes in a blockchain network participate in a consensus protocol and add blocks to the blockchain after contention. Such nodes are referred to as miner nodes (or accounting nodes). The POW introduced above is used as a non-limiting example.

The miner node performs a consensus process to add the transaction (the corresponding tile) to the chain of tiles. Although multiple miner nodes participate in the consensus process, only one miner node may write a block into the blockchain. That is, the miners 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 (e.g., until a predetermined limit, if any, on the number of transactions that may be included in the block is reached). The transaction pool includes transaction messages from participants in the blockchain network. The miner node creates a block and adds the transaction to the block. Before adding a transaction to a block, the miner node checks whether there is a transaction in the block of the blockchain in the transaction to be added. If the transaction has been added to another block, the transaction will be discarded.

The mineworker node generates a chunk header, hashes all transactions in the chunk, and combines the hash values in pairs to generate further hash values until a single hash value (Merkle root hash) is obtained for all transactions in the chunk. The Merkle root hash is then added to the chunk header. The miners also determine the hash value of the latest chunk in the blockchain (i.e., the last chunk added to the blockchain). The mineworker node may also add a random value (a noune value) and a timestamp in the block header. During the mining process, the miners' nodes attempt to find hash values that satisfy the required parameters. The mineworker node continually changes the nonce value until a hash value is found that meets the required parameters.

Each miner in the blockchain network attempts to find a hash value that satisfies the required parameters and competes with each other in this manner. Finally, one miner node finds a hash value that satisfies the required parameters and advertises the hash value to all other miner nodes in the blockchain network. Other miners nodes verify the hash value, and if determined to be correct, verify each transaction in the block, accept the block, and append the block to their blockchain copy. In this way, the global state of the blockchain is made consistent across all miner nodes within the blockchain network. The above process is a POW consensus protocol.

In the example provided in fig. 2, party a wants to send a certain amount of funds to party B. Party a generates a transaction message and sends the transaction message to the blockchain network, which is added to the transaction pool. Each mineworker node in the blockchain network creates a block and obtains transactions from the transaction pool and adds the transactions to the block. In this manner, the transaction issued by party a is added to the block of the miner node.

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

Asymmetric encryption refers to encryption using a key pair. Each key pair comprises a private key and a public key, the private key being known only to the respective node, and the public key being known to any or all other nodes in the blockchain network. A node may encrypt data using a public key of another node and may decrypt the encrypted data using a private key of the other node. For example, refer again to fig. 1. Party a may encrypt data using party B's public key and send the encrypted data to party B. Messages encrypted using a node's public key can only be decrypted using the node's private key.

Asymmetric encryption is used to provide a digital signature that enables a party in a transaction to confirm the validity of other parties in the transaction and the transaction. For example, a node may digitally sign a message, and another node may confirm that the message was sent by the node based on the digital signature of party a. Digital signatures can also be used to ensure that messages are not tampered with during transmission. For example, refer again to fig. 1. Party a will send a message to party B. Party a generates a hash value of the message and then encrypts the hash value using its private key to generate a digital signature. Party a attaches the digital signature to the message and sends the message with the digital signature to party B. Party B decrypts the digital signature using party a's public key, thereby decrypting the corresponding hash value. Party B hashes the received message to get another hash value and then compares the two hash values. If the hash values are the same, party B can confirm that the message is indeed from party A and has not been tampered with.

Although the above description has been made on a block chain scenario to which the embodiments of the present specification can be applied, the embodiments of the present specification can also be applied to other block chain scenarios. For example, embodiments of the present description may also be applicable to class blockchain systems. In a class blockchain system, data may be stored in a blockchain structure as well, unlike blockchain systems, in which blockchain data stored in a blockchain structure need not be subject to consensus processing.

Fig. 3 is a block diagram of an exemplary block chain system to which embodiments of the present disclosure are applicable. As shown in fig. 3, blockchain system 300 includes a distributed consensus network 310, a decentralized application server 320, and a decentralized application client 330. The distributed consensus network 310 comprises a communication network of individual consensus nodes, such as the networks described above with reference to fig. 1 and 2. The decentralized application server provides a running platform of the decentralized application, and the running platform is provided by a decentralized application service provider. The decentralized application client 330 is an entry for a user to access the blockchain, and may run on a terminal device of the user, and the user may initiate a service request to the decentralized application server via the decentralized application client. The decentralized application server 320 also includes a database of decentralized application servers and may also include a client business interface (which may be, for example, a DAPP API interface) for the decentralized application service. The client business interface is used to interface with the decentralized application client. The client service interfaces correspond to different types of service requests. The service request type may include, for example, a transfer operation, a data query operation, a data modification operation, and the like. The service modules of the decentralized application can be configured for different service request types.

The transaction initiated by the decentralized application client may be sent via the decentralized application server into the distributed consensus network 310 to perform a consensus process by each consensus node in the distributed consensus network and store transaction data into the blockchain after the consensus process. In addition, a service request which is initiated by the decentralized application client and does not need to be identified can also be sent to the distributed consensus network by the decentralized application server, and then the consensus node in the distributed consensus network can respond to the service request. For example, when a user wants to query for data on a certain tile, a data query request for the data may be sent to the decentralized application server via the decentralized application client. When receiving a data query request, a consensus node in the distributed consensus network can access a corresponding block on the block chain to obtain corresponding data, and send the corresponding data to the decentralized application client through the decentralized application server.

FIG. 4 is a flow diagram of a method of testing a decentralized application server in a blockchain system according to one embodiment of the present description.

As shown in FIG. 4, at block 402, a predetermined test operation is performed in the blockchain system. The blockchain system may be a test blockchain system built to mimic the blockchain system in a formal application. In the block chain system for testing, a distributed consensus network formed by all network nodes simulating real consensus nodes, a decentralized application server and a decentralized application client can be included. The predetermined testing operation may be a testing operation for one or more of a distributed consensus network and a decentralized application service platform in a blockchain system.

As an example, the predetermined test operation may be a test operation simulating unavailability of a communication network, packet loss, network delay, failure of a consensus node, and the like in a blockchain system in use, a test operation controlling an operating environment of a distributed consensus network (e.g., server system time of a blockchain node, allocation of computational resources, and the like), and a test operation controlling an operating environment of a decentralized application server (e.g., system parameters of the decentralized application server). The testing operation may also include invoking the testing operation for an interface of the client traffic interface. The specific test operation will be described in detail below with reference to fig. 5 to 9.

Next, at block 404, a predetermined service request for the blockchain system is performed by the decentralized application server. The service request may be, for example, a transfer operation, a data query operation, a data modification operation, etc. as mentioned above. When the test operation is a test operation invoked for an interface of a client service interface, the corresponding client service interface may be invoked to execute the corresponding service request. The predetermined service request may be sent to the decentralized application server via the decentralized application client. In a test scenario, the service request may not be sent to the decentralized application server via the decentralized application client.

After having the decentralized application server execute the predetermined service request, at block 406, the execution result of the decentralized application server for the predetermined service request is obtained. When the test system includes a decentralized application client, the execution results may be obtained via the decentralized application client. Then, at block 408, an operational status of the decentralized application server is determined based on the execution results. For example, when the predetermined test operation is an operation that changes the system environment of the blockchain system (e.g., makes a database of common nodes unavailable, makes a common node unable to connect, etc.), after the test operation is performed, the execution result obtained by the decentralized application server after executing the predetermined service request may also change accordingly due to the change in the blockchain system environment. In this case, if the execution result obtained by the decentralized application server does not change after the blockchain system environment is changed, it may be determined that the operation status of the decentralized application server is often abnormal. For another example, when the predetermined test operation is a query operation for data in the blockchain, it may be determined whether the operation state of the decentralized application server is abnormal based on whether the queried data is consistent with data obtained by performing a data query request via the decentralized application server.

In another example, the operations shown in block 408 may not be performed. In this example, the execution results may be provided to a technician to determine, by the technician, the operating states of the decentralized application server and the decentralized application server based on the execution results.

The various components of the blockchain system are interconnected organic entities. On one hand, each component can respectively affect the operation of the decentralized application server, and on the other hand, the mutual influence among the components can also affect the operation state of the decentralized application server. In this embodiment, by testing the decentralized application server in the real blockchain system, the influence that each component of the blockchain system may have on the decentralized application server can be uniformly tested to test the disturbance rejection capability of the decentralized application server. Therefore, the decentralized application server can be tested more comprehensively corresponding to the single test of a certain block chain system component. In addition, compared with a virtual blockchain system constructed by using an algorithm for testing, the method can reflect the shadow response of each blockchain system component to the running state of the decentralized application server more truly. Thus, the embodiment can more sufficiently and effectively test the decentralized application server.

The decentralized application testing method provided in the present specification will be described in more detail below with reference to fig. 5 to 9.

Fig. 5 is a flow diagram of a method of testing a decentralized application server in a blockchain system, according to another embodiment of the present description.

As shown in fig. 5, at block 502, a data query instruction for blockchain data is invoked to obtain second predetermined data from the blockchain data. The data query instruction may be invoked from a query function provided by the blockchain SDK.

Then, at block 504, a predetermined service request data query request is sent to the decentralized application server via the decentralized application client. Next, at block 506, a predetermined service request is executed in the blockchain system by the decentralized application server. The data query request corresponds to the data query instruction and is used for querying the data queried by the data query instruction. Next, at block 508, first predetermined data obtained by the decentralized application server executing the data query request is obtained via the decentralized application client.

After the first predetermined data and the second predetermined data are acquired, at block 510, a determination is made as to whether the first predetermined and second predetermined data are consistent. If the two are in agreement, then at block 512, it is determined that the operational status of the decentralized application server is normal. If the two are not consistent, then at block 514, it is determined that the operational status of the decentralized application server is not normal. Further, problems with the decentralized or decentralized application server may also be analyzed based on differences between the first predetermined data and the second predetermined data.

In the absence of an anomaly in the operating states of the decentralized application server and the decentralized application server, the second predetermined data resulting from the query from the blockchain across the decentralized application server should be consistent with the first predetermined data queried via the decentralized application server. Thus, the operational state of the decentralized application server may be determined based on a correspondence between the first predetermined data and the second predetermined data.

By the embodiment, whether an exception exists in the data query operation execution process of the decentralized application server can be judged.

Fig. 6 is a flow diagram of a method of testing a decentralized application server in a blockchain system, according to another embodiment of the present description.

As shown in fig. 6, at block 602, a network state in the distributed consensus network and/or a node state of each consensus node in the distributed consensus network is controlled. Network status may include unavailability of the network for a predetermined period of time, network latency, network bandwidth increase or decrease, network zoning, and the like. Network partitioning refers to one or more consensus nodes in a distributed consensus network being located in a different network region than other consensus nodes due to a network failure. For example, if there are A, B, C, D, E five consensus nodes in the distributed consensus network. If A, B, C, D and E can communicate normally due to network reasons, but the two sets of consensus nodes cannot communicate normally, then there are two network partitions, one of which includes A, B, C and the other includes D and E. The node states may include states of normally enabled consensus nodes, disabled consensus nodes, consensus node no response, consensus node response delay, and the like.

The Jepsen test (Jepsen test) method can be utilized to simulate chaotic environment in a distributed consensus network, including randomly turning on or off consensus nodes, randomly manufacturing network partitions between consensus nodes, and the like. The node state control instructions may also be invoked to accurately control the node state of the designated one or more consensus nodes, or the network state control scripts may be invoked to accurately control the network state of the designated consensus nodes. The state control instruction may be, for example, a node state control script based on Linux system configuration. The node state control script can be used to turn on or off the designated consensus node, and the network state control script can be used to control the network state of the designated consensus node, such as to make the network of the designated consensus node unavailable, to make the designated consensus node delayed in response to data in the network, and so on.

After performing the predetermined testing operations as described above, at block 604, a predetermined service request is sent to the decentralized application server via the decentralized application client. Then, at block 606, the decentralized application server is caused to perform a predetermined service request for the blockchain system in the blockchain system after performing the predetermined test operation. Then, at block 608, the results of the execution of the decentralized application for the predetermined service request are obtained. For some state changes of the consensus node or the distributed network, the execution result of the service request by the decentralized application server is changed correspondingly. While certain state changes to the consensus node or the distributed network do not affect the execution result of the decentralized application, for these state changes the execution result of the decentralized application should not change. It is therefore possible to determine whether there is a problem with the operating state of the decentralized application server on the basis of the execution result.

For example, when the number of unavailable consensus nodes (or network partitions are present) is such that the number of available consensus nodes does not reach the legal number required for reaching consensus, a transaction initiated via the decentralized application will not be able to agree or be unable to determine whether the data it wants to query is agreed by the legal number of consensus nodes, at which point the execution result returned by the decentralized application should be a transaction failure or a data query failure, indicating an anomaly in the operation of the decentralized application if a transaction success or a queried data is returned. For another example, if the distributed consensus network fails, the service request initiated by the decentralized application cannot be successfully executed, and if the execution result returned by the decentralized application after executing the predetermined service request is successfully executed, it indicates that the decentralized application is abnormal.

By the embodiment, whether the running state of the decentralized application server meets the expectation or not can be tested when the network environment of the distributed consensus network is disturbed, so that whether the decentralized application is abnormal or not can be tested.

Fig. 7 is a flow diagram of a method of testing a decentralized application server in a blockchain system, according to another embodiment of the present description.

As shown in FIG. 7, at block 702, an intelligent contract testing operation for an intelligent contract is performed in a blockchain system via a decentralized application. For example, a new intelligent contract may be configured in the blockchain system via the decentralized application, and the configured intelligent contract may be a system contract of the blockchain system or a business contract for processing a business request of the decentralized application client. Contract parameters of an existing intelligent contract may also be altered via the decentralized application. For example, the system configuration of the blockchain system may be modified by modifying parameters of the system contract.

Then, at block 704, a predetermined service request is sent to the decentralized application server via the decentralized application client. Next, at block 706, the decentralized application server is caused to execute a predetermined business request in the blockchain system after the intelligent contract testing operation is performed. At block 708, the execution results of the decentralized application server for the predetermined service request are obtained via the decentralized application client. After the execution result is obtained, whether the decentralized application server has an abnormality or not can be determined based on the execution result, and when the abnormality exists, the specific problem of the decentralized application server can be further determined.

The service requests sent by the decentralized application client may be associated with intelligent contracts in the blockchain system. For example, a corresponding service contract may need to be invoked when executing a service request. In addition, the contract parameters of the blockchain system contract also influence the execution result of the business request. Thus, after the testing operations associated with the smart contracts are performed, the results of the execution of the decentralized application server may also change accordingly. For example, the transaction result or the queried data can be returned before the test operation is performed, but the transaction result or the queried data cannot be returned after the test operation is performed, or the transaction result returned before and after the test operation is performed may be changed, and the like. Thus, based on whether the execution results are consistent with expected results after executing the smart contract test operation, it may be determined whether the decentralized application is anomalous.

Fig. 8 is a flow diagram of a method of testing a decentralized application server in a blockchain system, according to another embodiment of the present description.

As shown in FIG. 8, at block 802, a blockchain system event is defined. The system event may be, for example, a new block generation, a transaction executed, a system contract changed, a new business contract successfully configured, a new consensus node joining the distributed consensus network, a consensus node exiting the distributed consensus network, or the like.

After defining the blockchain system event, at block 804, an event customization request for the system event is sent to the decentralized application server via the decentralized application client. The decentralized application server is then caused to perform an event subscription operation for the blockchain system event at block 806. At block 808, a subscription result obtained by the decentralized application server performing the fixed event subscription operation is obtained via the decentralized application client. The user can subscribe the block chain system event concerned by the user through the decentralized application, and the decentralized application server executes the corresponding event subscription operation. When a blockchain system event to which the user subscribes occurs, the decentralized application may notify the user of the system event. If the decentralized application can successfully provide the notification content aiming at the system event in the execution result when the system event corresponding to the event subscription operation occurs, the abnormity of the decentralized application is indicated. If the decentralized application fails to provide notification content that would be relevant to the system event, or provides erroneous notification content, an exception to the decentralized application is indicated.

Although in the embodiments described above with reference to fig. 6 to 8 the service request is sent to the decentralized application server via the decentralized application client and the execution result is obtained via the decentralized application client, in practice the service request in the above-described embodiments may not be sent to the decentralized application server via the decentralized server and the execution result may not be obtained via the decentralized application client.

Fig. 9 is a flow diagram of a method of testing a decentralized application server in a blockchain system, according to another embodiment of the present description.

As shown in FIG. 9, at block 902, a decentralized application is run on a plurality of terminal devices. For example, the decentralized application may be run on a cell phone, a computer, a tablet, or on multiple cell phones or multiple computers, respectively. Next, at block 904, a predetermined service request is sent to the decentralized application server via the decentralized application client running on the plurality of terminal devices.

Then, at block 906, the respective predetermined service requests received from the plurality of terminal devices are executed by the decentralized application server. Next, at block 908, the execution results corresponding to the predetermined service request are obtained via a decentralized application running on the plurality of terminal devices.

After obtaining the plurality of execution results, at block 910, an operational state of the decentralized application server is determined based on a correspondence between the obtained plurality of execution results. The execution results obtained by the decentralized application executing the same service request on different terminal devices should be consistent, and if inconsistent execution results occur, it indicates that the decentralized application is abnormal. When inconsistent execution results exist, the inconsistent execution results and other execution results can be analyzed to obtain the problem of the decentralized application. In addition, the problems of decentralized application can be analyzed by combining the device environment (such as memory occupation condition, system time, network connection state and the like) of the terminal device.

By the embodiment, the stability of the decentralized application when running in different equipment environments can be tested, so as to test whether the decentralized application can correctly execute the service request in different equipment environments.

In addition to the test operations described in the above embodiments, test operations may also be performed on the database of the decentralized application server. For example, a database of a decentralized application server may be controlled to simulate a database failure event. A database interface (e.g., a database API interface) may be configured to access the database through the data API to control the database to simulate a failure event of the database. In this example, the predetermined service request performed by the decentralized application server may be a data query request directed to the database. When the database fails, the decentralized application server will not be able to retrieve the queried data from the database. In one example, a decentralized application server may be configured to obtain data to a consensus node in a blockchain system when data cannot be obtained from a database. At this time, it may be based on whether the decentralized application server can obtain the corresponding data from the consensus node when the database fails. In addition, the decentralized application server may be configured to execute the data query request again after a predetermined time has elapsed when the data cannot be acquired from the database. In this example, the simulated database failure event may be that the database is unavailable for a predetermined period of time or randomly temporarily (e.g., a period of time 10 seconds or one minute in duration). In this example, it may be determined whether the decentralized application has an anomaly based on whether the decentralized application server is able to acquire the correct data after a certain time has elapsed.

In addition, corresponding operations can be executed on the data in the database based on the operation instructions for the database. The operation on the data may be an operation of adding data, deleting data, changing data, querying data, and the like. Whether an anomaly exists with the decentralized application server may be determined based on whether the decentralized application is able to successfully add data to the database while removing data, whether the queried data is able to be successfully queried, and whether changes to the data can be correctly performed.

The test operations described in the above embodiments may be performed individually or a plurality of test operations may be performed simultaneously. Because the components in the blockchain system are mutually related and disturbance may occur in the system environment in the blockchain system at any time under a formal application scene, the influence of the disturbance of the blockchain system on the decentralized application server can be reflected more truly when a plurality of test operations are executed simultaneously, and whether the decentralized application server is abnormal or not can be tested more truly. In one example, the various test operations may be performed randomly, each of which may be performed for a random period of time, thereby enabling the various test operations to be performed simultaneously or individually in random combinations. In addition, one or more of the test operations for the databases of the distributed consensus network, the decentralized application server and the decentralized application server may be respectively specified, and the specified test operations may be randomly executed.

FIG. 10 is a block diagram of an apparatus for testing a decentralized application server in a blockchain system, according to another embodiment of the present description. As shown in fig. 10, the decentralized application testing device 1000 includes a test operation execution unit 1010, a service request execution unit 1020, an execution result acquisition unit 1030, and an operation state determination unit 1040.

The test operation performing unit 1010 performs a predetermined test operation in the blockchain system. The service request execution unit 1020 executes a predetermined service request in the blockchain system by the decentralized application server. The execution result acquisition unit 1030 acquires the execution result of the decentralized application server for a predetermined service request. After acquiring the execution result, the operation state determination unit 1040 determines the operation state of the decentralized application server based on the execution result.

In one example, the test operation performing unit 1010 may run a decentralized application client on a plurality of terminal devices and transmit a predetermined service request to the decentralized application server via the decentralized application client running on the plurality of terminal devices. In this example, the service request performing unit 1020 may cause the decentralized application server to perform the reception of the plurality of predetermined service requests from the plurality of terminal devices, respectively. The execution result acquisition unit 1030 may acquire a corresponding plurality of execution results via decentralized clients operating on a plurality of terminal devices. Then, the operation state determination unit 1040 may determine the operation state of the decentralized application server based on the consistency between the plurality of execution results.

In another example, the operation state determination unit may not be included. The obtained execution results may be manually analyzed by a technician for the operational status of the decentralized application server.

Fig. 11 is a block diagram showing an example of a test operation execution unit in the apparatus for testing a decentralized application server in a blockchain system as shown in fig. 10. As shown in fig. 11, the test operation execution unit 1010 includes a data query module 1011, a distributed network environment control module 1012, an intelligent contract test operation execution module 1013, a subscription service test module 1014, a database failure simulation module 1015, and a data operation test module 1016.

The data query module 1011 calls a data query command for the blockchain data in the blockchain to obtain the second predetermined data from the blockchain. The operation state determination unit 1040 may determine the operation state of the decentralized application server based on the correspondence between the first predetermined data and the second predetermined data. The first predetermined data is provided by the decentralized application server after executing the blockchain data query request.

The distributed consensus network environment control module 1012 controls a network state in the distributed consensus network and/or a node state of each network node in the distributed consensus network. The service request execution unit 1020 may cause the decentralized application server to execute a predetermined service request for the blockchain system in the blockchain system after performing the predetermined test operation.

The intelligent contract testing operation execution module 1013 executes an intelligent contract testing operation for an intelligent contract in a blockchain system via a decentralized application server. The intelligent contract testing operation may include configuring a new intelligent contract in the blockchain system, and may also include adjusting contract parameters of the intelligent contract. After performing the intelligent contract testing operation, the service request execution unit 1020 may cause the decentralized application server to execute a predetermined service request for the blockchain system in the blockchain system after performing the intelligent contract testing operation.

The subscription service test module 1014 defines blockchain system events. The service request execution unit 1020 may cause the decentralized application server to perform an event subscription operation for the system event.

The database fault simulation module 1015 controls the database of the decentralized application server to simulate a database fault event. The database fault simulation module may include a database interface such that the database may be controlled via the database interface. The data operation testing module 1016 performs corresponding operations on data in the database based on the operation instructions for the database.

Although fig. 11 illustrates a case where the test operation performing unit includes various modules, in other examples, the test operation performing unit may include one or more modules illustrated in fig. 11.

Embodiments of a method and apparatus for testing decentralized application servers in a blockchain system according to embodiments of the present disclosure are described above with reference to fig. 1 to 11. The details mentioned in the above description of the method embodiments apply equally to the embodiments of the device of the embodiments of the present description.

The apparatus for testing a decentralized application server in a blockchain system according to the embodiments of the present disclosure may be implemented by hardware, or may be implemented by software, or a combination of hardware and software. The various embodiments in this specification are described in a progressive manner, with like reference to each other.

The apparatus for testing a decentralized application server in a blockchain system according to the embodiments of the present disclosure may be implemented by hardware, or may be implemented by software, or a combination of hardware and software. In the case of software implementation, the logical means is formed by reading corresponding computer program instructions in the memory into the memory for execution by the processor of the device in which the logical means is located. In the embodiment of the present specification, the multi-layer block chain structure generation means and the trust point update means may be implemented by using a computing device, for example.

FIG. 12 is a block diagram of a computing device in a method of testing a decentralized application server in a blockchain system, according to one embodiment of the present description. As shown in fig. 12, the computing device 1200 includes a processor 1210, a memory 1220, a memory 1230, a communication interface 1240, and an internal bus 1250, and the processor 1210, the memory (e.g., a non-volatile memory) 1220, the memory 1230, and the communication interface 1240 are connected together via the bus 1250. According to one embodiment, the computing device 1200 may include at least one processor 1210 that executes at least one computer-readable instruction (i.e., an element described above as being implemented in software) stored or encoded in a computer-readable storage medium (i.e., memory 1220).

In one embodiment, computer-executable instructions are stored in the memory 1220 that, when executed, cause the at least one processor 1210 to: performing a predetermined test operation in the blockchain system; executing, by the decentralized application server, a predetermined service request in the blockchain system; and acquiring an execution result of the decentralized application server aiming at the preset service request, wherein the execution result is used for determining the running state of the decentralized application server.

It should be appreciated that the computer-executable instructions stored in the memory 1220, when executed, cause the at least one processor 1210 to perform the various operations and functions described above in connection with fig. 1 through 11 in various ones of the embodiments of the present specification.

According to one embodiment, a program product, such as a non-transitory machine-readable medium, is provided. A non-transitory machine-readable medium may have instructions (i.e., elements described above as being implemented in software) that, when executed by a machine, cause the machine to perform various operations and functions described above in connection with fig. 1 through 11 in various ones of the embodiments of the present specification.

Specifically, a system or apparatus may be provided which is provided with a readable storage medium on which software program code implementing the functions of any of the above embodiments is stored, and causes a computer or processor of the system or apparatus to read out and execute instructions stored in the readable storage medium.

In this case, the program code itself read from the readable medium can realize the functions of any of the above-described embodiments, and thus the machine-readable code and the readable storage medium storing the machine-readable code form part of the present invention.

Examples of the readable storage medium include floppy disks, hard disks, magneto-optical disks, optical disks (e.g., CD-ROMs, CD-R, CD-RWs, DVD-ROMs, DVD-RAMs, DVD-RWs), magnetic tapes, nonvolatile memory cards, and ROMs. Alternatively, the program code may be downloaded from a server computer or from the cloud via a communications network.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

Not all steps and elements in the above flows and system structure diagrams are necessary, and some steps or elements may be omitted according to actual needs. The execution order of the steps is not fixed, and can be determined as required. The apparatus structures described in the above embodiments may be physical structures or logical structures, that is, some units may be implemented by the same physical entity, or some units may be implemented by a plurality of physical entities, or some units may be implemented by some components in a plurality of independent devices.

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, the techniques may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the described embodiments.

Although the embodiments of the present disclosure have been described in detail with reference to the accompanying drawings, the embodiments of the present disclosure are not limited to the specific details of the embodiments, and various simple modifications may be made to the technical solutions of the embodiments of the present disclosure within the technical concept of the embodiments of the present disclosure, and all of them fall within the scope of the embodiments of the present disclosure.

The previous description of the contents of the embodiments of the present specification is provided to enable any person skilled in the art to make or use the contents of the embodiments of the present specification. Various modifications to the disclosure of the embodiments herein will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the embodiments herein. Thus, the present specification embodiments are not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method of testing a decentralized application server in a blockchain system, comprising:

performing a predetermined test operation in the blockchain system;

executing, by the decentralized application server, a predetermined service request in the blockchain system; and

and acquiring an execution result of the decentralized application server aiming at the preset service request, wherein the execution result is used for determining the running state of the decentralized application server.

2. The method of claim 1, further comprising:

determining an operating state of the decentralized application server based on the execution result.

3. The method of claim 2, wherein the predetermined service request comprises a blockchain data query request, the execution result comprises first predetermined data provided by the decentralized application server after the execution of the blockchain data query request, and the performing a predetermined test operation in the blockchain system comprises:

calling a data query instruction aiming at block chain data in a block chain, and acquiring second preset data from the block chain;

determining an operational state of the decentralized application server based on the execution result comprises:

determining an operational state of the decentralized application server based on a correspondence between the first predetermined data and the second predetermined data.

4. The method of any of claims 1-3, wherein the blockchain system includes a distributed consensus network, performing a predetermined test operation in the blockchain system includes:

controlling a network state in the distributed consensus network and/or a node state of each network node in the distributed consensus network,

executing, by the decentralized application server, the predetermined service request in the blockchain system comprises:

in the blockchain system after the predetermined test operation is performed, causing the decentralized application server to perform a predetermined service request for the blockchain system.

5. The method of any one of claims 1-3, wherein performing a predetermined test operation in the blockchain system comprises:

performing, via the decentralized application server, intelligent contract testing operations for intelligent contracts in the blockchain system,

in the blockchain system after the intelligent contract testing operation is performed, causing the decentralized application server to perform a predetermined service request for the blockchain system.

6. The method of claim 5, wherein the intelligent contract testing operations comprise:

configuring a new intelligent contract in the blockchain system; and/or

And adjusting contract parameters of the intelligent contract.

7. The method of any one of claims 1-3, wherein performing a predetermined test operation in the blockchain system comprises:

the system event of the block chain is defined,

performing, by the decentralized application server, an event subscription operation for the blockchain system event.

8. The method of any one of claims 1-3, wherein performing a predetermined test operation in the blockchain system comprises:

controlling the database of the decentralized application server to simulate a database failure event; and/or

And performing corresponding operation on the data in the database based on the operation instruction for the database.

9. The method of any one of claims 1-3, wherein performing a predetermined test operation in the blockchain system comprises:

running a decentralized application client on a plurality of terminal devices,

sending a predetermined service request to a decentralized application server via a decentralized application client running on the plurality of terminal devices.

10. An apparatus for testing a decentralized application server in a blockchain system, comprising:

a test operation execution unit that executes a predetermined test operation in the blockchain system;

a service request execution unit for executing a predetermined service request in the blockchain system by the decentralized application server; and

and the execution result acquisition unit is used for acquiring the execution result of the predetermined service request from the decentralized application server, and the execution result is used for determining the running state of the decentralized application server.

11. The apparatus of claim 10, further comprising:

and the running state determining unit is used for determining the running state of the decentralized application server based on the execution result.

12. The apparatus of claim 11, wherein the predetermined service request comprises a blockchain data query request, the execution result comprises first predetermined data provided by the decentralized application server after the execution of the blockchain data query request, and the test operation performing unit comprises:

the data query module calls a data query instruction aiming at the block chain data in the block chain, acquires second preset data from the block chain,

the operation state determination unit determines the operation state of the decentralized application server based on the consistency between the first predetermined data and the second predetermined data.

13. The apparatus of any of claims 10-12, wherein the blockchain system includes a distributed consensus network, the test operation execution unit comprising:

a distributed consensus network environment control module controlling a network state in the distributed consensus network and/or a node state of each network node in the distributed consensus network,

the service request execution unit enables the decentralized application server to execute the predetermined service request aiming at the blockchain system in the blockchain system after the predetermined test operation is executed.

14. The apparatus of any one of claims 10-12, wherein the test operation performing unit comprises:

an intelligent contract testing operation execution module that executes an intelligent contract testing operation for an intelligent contract in the blockchain system via the decentralized application server,

the service request execution unit causes the decentralized application server to execute a predetermined service request for the blockchain system in the blockchain system after the intelligent contract testing operation is executed.

15. The apparatus of claim 14, wherein the intelligent contract testing operations comprise:

configuring a new intelligent contract in the blockchain system; and/or

Contract parameters of the intelligent contract are modified.

16. The apparatus of any one of claims 10-12, wherein the test operation performing unit comprises:

a subscription service test module defining a blockchain system event,

the service request execution unit enables the decentralized application server to execute an event subscription operation aiming at the block chain system event.

17. The apparatus of any one of claims 10-12, wherein the test operation performing unit comprises:

the database fault simulation module is used for controlling the database of the decentralized application server so as to simulate a database fault event; and/or

And the data operation testing module executes corresponding operation on the data in the database based on the operation instruction aiming at the database.

18. The apparatus according to any of claims 10-12, wherein the test operation execution unit runs a decentralized application client on a plurality of terminal devices,

the service request transmitting unit transmits a predetermined service request to the decentralized application server via the decentralized application client running on the plurality of terminal devices.

19. A computing device, comprising:

at least one processor; and

a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the method of any of claims 1 to 9.

20. A machine-readable storage medium storing executable instructions that, when executed, cause the machine to perform the method of any of claims 1 to 9.