WO2024066974A1 - 基于区块链的数据处理方法、设备以及可读存储介质 - Google Patents

基于区块链的数据处理方法、设备以及可读存储介质 Download PDF

Info

Publication number
WO2024066974A1
WO2024066974A1 PCT/CN2023/117186 CN2023117186W WO2024066974A1 WO 2024066974 A1 WO2024066974 A1 WO 2024066974A1 CN 2023117186 W CN2023117186 W CN 2023117186W WO 2024066974 A1 WO2024066974 A1 WO 2024066974A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
request message
response
message
node
Prior art date
Application number
PCT/CN2023/117186
Other languages
English (en)
French (fr)
Inventor
廖志勇
王宗友
时一防
朱耿良
刘区城
刘汉卿
Original Assignee
腾讯科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Publication of WO2024066974A1 publication Critical patent/WO2024066974A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • the present application relates to the field of Internet technology, and in particular to a data processing method, device, and readable storage medium based on blockchain.
  • the master node i.e., the block-producing node
  • the backup nodes i.e., other consensus nodes
  • the embodiments of the present application provide a blockchain-based data processing method, device, and readable storage medium, which can not only improve the consensus efficiency of the blockchain network, but also reduce the response delay of the client and improve the efficiency of the client in determining the request execution result.
  • the present application embodiment provides a data processing method based on blockchain, which is executed by a master node with consensus authority in a blockchain network, and includes:
  • n is a positive integer
  • the first request message and a first response result corresponding to the first request message are associated and stored in the account file, where the first response result is obtained by executing an operation corresponding to the first request message in response to the first request message having the first preparation certificate; while the first request message and the first response result are associated and stored in the account file, the request operation corresponding to the second request message is executed in parallel to obtain a second response result corresponding to the second request message, and the second response result is stored in the cache file;
  • the first initial response message generated according to the second response result is returned to the client that initiated the second request message, so that the client can generate a first initial response message according to the first initial response message and the backup node with consensus authority in the blockchain network.
  • the backup initial response messages returned by the points are used to determine the execution result of the first request corresponding to the second request message.
  • the present application embodiment provides a data processing method based on blockchain, which is executed by a client and includes:
  • Send the second request message to the node with consensus authority in the blockchain network so that the master node among the nodes with consensus authority: in response to the first request message with serial number n having the first preparation certificate, assign serial number n+1 to the second request message; n is a positive integer; in response to the second request message having the second preparation certificate, associate the first request message and the first response result corresponding to the first request message and store them in the ledger file, the first response result is that the master node has the first preparation certificate in response to the first request message, and is obtained by executing the operation corresponding to the first request message; while associating and storing the first request message and the first response result in the ledger file, execute the request operation corresponding to the second request message in parallel, obtain the second response result corresponding to the second request message, and store the second response result in the cache file; generate a first initial response message for the second request message according to the second response result;
  • the embodiment of the present application provides a data processing device based on blockchain, which runs on a master node with consensus authority in a blockchain network, and includes:
  • a sequence number allocation module configured to allocate a sequence number n+1 to a second request message in response to a first request message having a sequence number n having a first preparation certificate; n is a positive integer;
  • an associated storage module configured to associate and store the first request message and a first response result corresponding to the first request message in a ledger file in response to the second request message having a second preparation certificate, wherein the first response result is obtained by executing an operation corresponding to the first request message in response to the first request message having the first preparation certificate;
  • a request operation module configured to perform a request operation corresponding to a second request message in parallel while associating and storing the first request message and the first response result in the account file, obtain a second response result corresponding to the second request message, and store the second response result in a cache file;
  • the first return module is used to return the first initial response message generated according to the second response result to the client, so that the client determines the first request execution result corresponding to the second request message according to the first initial response message and the backup initial response message returned by the backup node with consensus authority in the blockchain network.
  • the embodiment of the present application provides a data processing device based on blockchain, which runs on a client and includes:
  • a first sending module is used to send a second request message to a node with consensus authority in a blockchain network, so that a master node among the nodes with consensus authority: in response to a first request message with a sequence number of n having a first preparation certificate, assign a sequence number of n+1 to the second request message; n is a positive integer; in response to a second request message having a second preparation certificate, associate and store the first request message and a first response result corresponding to the first request message in a ledger file, wherein the first response result is obtained by the master node having the first preparation certificate in response to the first request message by executing an operation corresponding to the first request message; while associating and storing the first request message and the first response result as a ledger file, execute the request operation corresponding to the second request message in parallel, obtain a second response result corresponding to the second request message, and store the second response result in a cache file; and generate a first initial response message for the second request message according to the second response result;
  • the first determination module is used to obtain a first initial response message returned by the primary node, and determine a first request execution result corresponding to the second request message based on the first initial response message and the backup initial response messages respectively returned by the backup nodes among the nodes with consensus authority.
  • the embodiment of the present application provides a computer device, including: a processor, a memory, and a network interface;
  • the above-mentioned processor is connected to the above-mentioned memory and the above-mentioned network interface, wherein the above-mentioned network interface is used to provide a data communication function, the above-mentioned memory is used to store a computer program, and the above-mentioned processor is used to call the above-mentioned computer program so that the computer device executes the method in the embodiment of the present application.
  • An embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored.
  • the computer program is suitable for being loaded by a processor and executing the method in the embodiment of the present application.
  • An embodiment of the present application provides a computer program product, which includes a computer program stored in a computer-readable storage medium; a processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, so that the computer device executes the method in the embodiment of the present application.
  • FIG1 is a schematic diagram of a system architecture provided by an embodiment of the present application.
  • FIG2 is a schematic diagram of a flow chart of a data processing method based on blockchain provided in an embodiment of the present application
  • FIG3 is a schematic diagram of a scenario of data processing based on blockchain provided in an embodiment of the present application.
  • FIG4 is a schematic diagram of another scenario of blockchain-based data processing provided by an embodiment of the present application.
  • FIG5 is another schematic diagram of a scenario of data processing based on blockchain provided in an embodiment of the present application.
  • FIG6 is a schematic diagram of a scenario of a data processing method based on blockchain provided in an embodiment of the present application.
  • FIG7 is another schematic diagram of a flowchart of a blockchain-based data processing method provided in an embodiment of the present application.
  • FIG8 is another flowchart of a blockchain-based data processing method provided in an embodiment of the present application.
  • FIG9 is another flowchart of a blockchain-based data processing method provided in an embodiment of the present application.
  • FIG10 is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of the present application.
  • FIG11 is another schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of the present application.
  • FIG. 12 is a schematic diagram of the structure of a computer device provided in an embodiment of the present application.
  • one of the core algorithms of the blockchain reaches consensus on request messages through a three-phase protocol.
  • the three-phase protocol includes a pre-preparation phase, a preparation phase, and a submission phase.
  • the submission phase can ensure the consistency of the order of cross-view requests, but the submission phase increases the number of network interactions for each consensus, which not only reduces the consensus efficiency of the blockchain network, but also prolongs the response time of the client, and reduces the efficiency of the client in determining the request execution result of the request message.
  • the present application embodiment proposes a data processing solution based on blockchain, which is introduced in detail below:
  • Blockchain In a narrow sense, blockchain is a chain data structure with blocks as the basic unit. The digital summary is used in the block to verify the previously obtained transaction history, which is suitable for the needs of tamper-proof and scalability in the distributed accounting scenario; in a broad sense, blockchain also refers to the distributed accounting technology implemented by the blockchain structure, including distributed consensus, privacy and security protection, peer-to-peer communication technology, network protocols, smart contracts, etc. The goal of the blockchain is to realize a distributed data record book, which only allows additions but not deletions.
  • the basic structure of the underlying ledger is a linear linked list. The linked list is composed of "blocks" connected in series, and the hash value of the previous block is recorded in the subsequent block. Whether each block (and the transactions in the block) is legal can be quickly verified by calculating the hash value. If a node in the network proposes to add a new block, it must reach a consensus on the block through the consensus mechanism.
  • Block It is a data packet that carries transaction data on the blockchain network. It is a data structure marked with a timestamp and the hash value corresponding to the previous block. The block is verified and confirmed by the consensus mechanism of the network.
  • the block includes a block header and a block body.
  • the block header can record
  • the block body records the metadata of the current block, including the current version number, the hash value corresponding to the previous block, the timestamp, the random number, the hash value of the Merkle Root, and other data.
  • the block body can record the detailed data generated within a period of time, including all transaction records or other information generated during the block creation process that have been verified by the current block, which can be understood as a form of account book.
  • the detailed data of the block body can include the unique Merkle Root generated through the hash process of the Merkle Tree and recorded in the block header.
  • the predecessor block also known as the parent block (Parent Block) is sorted in time by recording the hash value corresponding to the block and the hash value corresponding to the parent block in the block header.
  • Hash value Also known as information characteristic value or characteristic value, the hash value is generated by converting input data of any length into a password and performing a fixed output through a hash algorithm. The original input data cannot be retrieved by decrypting the hash value. It is a one-way encryption function. In the blockchain, each block (except the initial block) contains the hash value of the previous block. The hash value is the potential core foundation and the most important aspect of blockchain technology. It retains the authenticity of the recorded and viewed data, as well as the integrity of the blockchain as a whole.
  • Blockchain nodes The blockchain network divides nodes into consensus nodes (also called core nodes) and synchronization nodes (which can include data nodes and light nodes). Among them, the consensus node is responsible for the consensus business of the entire blockchain network; the synchronization node is responsible for synchronizing the ledger information of the consensus node, that is, synchronizing the latest block data. Whether it is a consensus node or a synchronization node, its internal structure includes network communication components, because the blockchain network is essentially a peer-to-peer (P2P) network, and it needs to communicate with other nodes in the blockchain network through P2P components.
  • P2P peer-to-peer
  • the resources and services in the blockchain network are scattered on various nodes, and the transmission of information and the implementation of services are directly carried out between nodes without the intervention of intermediate links or centralized servers (third parties).
  • a node with consensus authority in a blockchain network is a consensus node.
  • a consensus node may include a master node (with block generation authority) and a backup node.
  • the total number of consensus nodes is 3f+1, where the total number of backup nodes is 3f, f is a positive integer, and f represents the maximum number of illegal backup nodes.
  • Asymmetric signature The signature algorithm includes two keys, a public key (public key for short) and a private key (private key for short). The public key and the private key are a pair. If the private key is used to sign data, the signature can only be verified with the corresponding public key. Because the signing process and the verification process use two different keys, this algorithm is called an asymmetric signature.
  • the basic process of asymmetric signature to achieve confidential information exchange can be: Party A generates a pair of keys and makes the public key public. When Party A needs to send a message to another role (Party B), it uses its own private key to sign the confidential message and then sends it to Party B; Party B then uses Party A's public key to verify the signed message.
  • FIG. 1 is a schematic diagram of a system architecture provided by an embodiment of the present application.
  • the system architecture may include a terminal device cluster 100 and a blockchain network, and the terminal device cluster 100 may include a terminal device 100a, a terminal device 100b, a terminal device 100c, and a terminal device 100n. It is understood that the embodiment of the present application does not limit the number of terminal devices in the terminal device cluster 100, and may include one or more terminal devices.
  • the blockchain network may include a blockchain node cluster 10 with consensus authority, and the blockchain node cluster 10 may include a blockchain node 10A, a blockchain node 10B, a blockchain node 10C, and a blockchain node 10N.
  • the blockchain nodes in the blockchain node cluster 10 include one master node (e.g., blockchain node 10A) in the embodiment of the present application, and 3f backup nodes (e.g., blockchain node 10B, blockchain node 10C, and blockchain node 10N).
  • there may be a communication connection between the terminal devices in the terminal device cluster 100 for example, there is a communication connection between the terminal device 100c and the terminal device 100a.
  • there may be a communication connection between the blockchain nodes in the blockchain node cluster 10 for example, there is a communication connection between the blockchain node 10A and the blockchain node 10C, and there is a communication connection between the blockchain node 10A and the blockchain node 10N.
  • any blockchain node in the blockchain node cluster 10 can have a communication connection with any terminal device in the terminal device cluster 100, for example, there is a communication connection between the blockchain node 10A and the terminal device 100b, there is a communication connection between the blockchain node 10N and the terminal device 100n, there is a communication connection between the blockchain node 10C and the terminal device 100a, and there is a communication connection between the blockchain node 10A and the terminal device 100c.
  • the above-mentioned communication connection does not limit the connection method, and can be directly or indirectly connected through a wired communication method, or directly or indirectly connected through a wireless communication method, or through other methods, and this application is not limited here.
  • the communication connection between the above blockchain nodes can be based on node identification.
  • each blockchain node in the blockchain network there is a node identification corresponding to it, and each blockchain node can store the node identification of other blockchain nodes connected to itself, so that the acquired data or generated blocks can be broadcast to other blockchain nodes according to the node identification of other blockchain nodes.
  • blockchain node 10A can maintain a node identification list, which stores the node names and node identifications of other blockchain nodes, as shown in Table 1.
  • the node identifier can be the Internet Protocol (IP) address for interconnecting networks or any other information that can be used to identify a blockchain node in a blockchain network.
  • IP Internet Protocol
  • blockchain node 10A can send a pre-preparation message to blockchain node 10N through node identifier CCCCC, and blockchain node 10N can determine that the pre-preparation message is sent by blockchain node 10A through node identifier FFFFFF; similarly, blockchain node 10N can send a preparation message to blockchain node 10C through node identifier BBBBBB, and blockchain node 10C can know that the preparation message is sent by blockchain node 10N through node identifier CCCCCC, and the same is true for data transmission between other nodes, so they will not be elaborated one by one.
  • each blockchain node in the blockchain node cluster 10 When each blockchain node in the blockchain node cluster 10 is working normally, it can receive a request message sent by a client in a terminal device, generate a block based on the received request message, and then process the block on the chain. It is understandable that in the specific implementation of the present application, when the embodiment of the present application is applied to a specific product or technology, it is necessary to obtain user permission or consent, and the collection, use and processing of the relevant data need to comply with the relevant laws, regulations and standards of the relevant countries and regions.
  • each terminal device in the terminal device cluster 100 shown in FIG. 1 may be installed with a client, and when the client runs in each terminal device, it may interact with the blockchain node cluster 10 shown in FIG. 1, i.e., the above-mentioned communication connection.
  • the client may be an application client having a function of sending a request message, such as a video application, a social application, an instant messaging application, an office software application, a navigation application, a shopping application, a financial management application, a business application, a browser, etc.
  • the client may be an independent client, or an embedded sub-client integrated in a client (e.g., a social client, an educational client, and a multimedia client, etc.), which is not limited here.
  • the blockchain nodes in Figure 1 include but are not limited to mobile terminals or servers.
  • the above-mentioned server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (Content Delivery Network, referred to as CDN), and big data and artificial intelligence platforms.
  • the above-mentioned mobile terminals include but are not limited to mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, aircraft, etc. Among them, the mobile terminal and the server can be directly or indirectly connected by wire or wireless means, and the embodiments of the present application do not limit this.
  • Figure 2 is a flow chart of a data processing method based on blockchain provided in an embodiment of the present application.
  • the data processing method based on blockchain can be executed by a master node with consensus authority in a blockchain network.
  • the data processing method based on blockchain can at least include the following steps S101-S104.
  • Step S101 in response to a first request message with a sequence number of n having a first preparation certificate, assigning a sequence number of n+1 to a second request message; n is a positive integer;
  • the data processing method involved in the embodiments of the present application can be used to improve the consensus algorithm (for example, the PBFT algorithm) to reduce the network complexity during consensus.
  • the PBFT algorithm means a practical Byzantine fault-tolerant algorithm, which is a distributed consistency algorithm that can tolerate certain Byzantine errors.
  • the PBFT algorithm can reach a consensus in a scenario where a few nodes are malicious (such as forging messages). It uses cryptographic algorithms such as signatures, signature verification, and hashing to ensure tamper-proof, anti-counterfeiting, and non-repudiation during message transmission, and optimizes the work of predecessors, reducing the complexity of the Byzantine fault-tolerant algorithm from exponential to polynomial levels.
  • the total number of nodes with consensus authority can be a positive integer of (3f+1), where f can be used to indicate the maximum number of illegal nodes in the blockchain network.
  • the illegal nodes here may not transmit messages, or transmit inconsistent messages in an attempt to disrupt other nodes.
  • the PBFT algorithm does not rely on unrealistic assumptions, and can allow illegal nodes (i.e., malicious nodes) to delay network transmissions between legitimate nodes (i.e., non-malicious nodes), and can provide security and activity when the number of illegal nodes is less than 1/3 of the total number. For example, when no less than (2f+1) legitimate nodes are working normally, the nodes in the blockchain network can reach a consensus. For example: the maximum number of illegal nodes that can exist in a blockchain system with 7 nodes is 2.
  • the PBFT algorithm can use views to record the consensus state of each node. Under the same view (i.e., the same view number), all nodes in the blockchain network can maintain the same node list.
  • the node list may include a master node and a backup node.
  • a view switch occurs. Each view switch changes the master node, and the view number is continuous. If the view switch is successful, the PBFT algorithm can determine a new master node based on the new view.
  • the embodiment of the present application may refer to the node used to package the request message out of the block as the master node in the blockchain network.
  • the embodiment of the present application may refer to the node with consensus authority other than the master node in the blockchain network as a backup node.
  • Figure 3 is a schematic diagram of a scenario of data processing based on blockchain provided by the embodiment of the present application.
  • the terminal device 30a is installed with a client.
  • the embodiment of the present application does not limit the specific business of the client, and can be set according to the actual application scenario; therefore, the embodiment of the present application does not limit the specific content of the second request message initiated by the client, and should be set according to the specific business of the client, including but not limited to Issuance of electronic invoices and redemption, generation, transfer, and chain-up of digital assets, etc.
  • the client installed by the terminal device 30a can directly send the second request message to the master node 30b, or send the second request message to the backup node, and then the backup node forwards the second request message to the master node 30b.
  • the master node After receiving the second request message, the master node first verifies the second request message.
  • the embodiment of the present application does not describe the verification of the second request message for the time being. Please refer to the description of step S201 in the embodiment corresponding to Figure 7 below. It can be understood that the total number of the second request message can be one or more, and the embodiment of the present application does not limit the total number of the second request message.
  • the second request message 1, the second request message 2, ..., the second request message 4 can be sent by a client, that is, the total number of the terminal device 30a is one.
  • the second request message 1, the second request message 2, ..., the second request message 4 can be sent by different clients respectively, that is, the total number of the terminal device 30a can be multiple.
  • the request messages (including the first request message and the second request message) involved in the embodiments of the present application can be understood as business transactions, so when the second request message passes the verification, the master node 30b can add the second request message to the transaction cache pool.
  • the master node 30b can assign a sequence number n+1 to the second request message.
  • the first preparation certificate 301c can include 1 pre-prepared message 1 for the first request message, and 2f preparation messages 1.
  • the processing process of the pre-preparation message 1 (such as the generation process, the broadcast process, the verification process, etc.) is the same as the processing process of the pre-preparation message corresponding to the second request message (such as the pre-preparation message 30g as shown in Figure 3);
  • the processing process of the 2f preparation messages 1 (such as the generation process, the broadcast process, the verification process, etc.) is the same as the processing process of the preparation message corresponding to the second request message; therefore, the processing process of the pre-preparation message 1 and the processing process of the 2f preparation messages 1 are not described here, please refer to the processing process of the pre-preparation message 30g in step S102 below and the processing process of the preparation message corresponding to the second request message.
  • Step S102 In response to the second request message having a second preparation certificate, the first request message and the first response result corresponding to the first request message are associated and stored in the account book file.
  • a pre-preparation message is generated according to the serial number n+1 and the second request message; the pre-preparation message is broadcast to the backup nodes with consensus authority in the blockchain network, so that each backup node verifies the pre-preparation message to obtain a first verification result; the first verification result is used to instruct the backup node to generate a preparation message corresponding to the second request message when the first verification result is passed; the preparation message returned by each backup node is obtained, and a second preparation certificate corresponding to the second request message is generated according to the obtained preparation message.
  • the specific process of generating the pre-preparation message may include: The second request message is packaged and processed to obtain a block to be verified, and the block hash value of the block to be verified is determined as the block summary of the block to be verified; a pre-preparation identifier corresponding to the block to be verified is generated, and the pre-preparation identifier, the first view number of the blockchain network, the sequence number n+1 and the block summary are determined as pre-preparation information to be signed; the pre-preparation to be signed is signed by the master node private key to obtain the third signature information; and a pre-preparation message carrying the third signature information and the block to be verified is generated.
  • the preparation message carries fourth signature information and preparation information to be signed, and the fourth signature information is generated by the backup node that generates the preparation message to sign the preparation information to be signed by the backup node private key;
  • the specific process of generating the second preparation certificate corresponding to the second request message may include: for each preparation message obtained, the fourth signature information carried by the preparation message is verified by the backup node public key corresponding to the backup node that generates the preparation message, and the verification result corresponding to the fourth signature information is obtained; if the verification result corresponding to the fourth signature information is successful, the preparation information to be signed carried by the preparation message is verified to obtain a second verification result; if the second verification result is passed, the preparation message is added to the log database; if the log database includes preparation messages corresponding to 2f backup nodes respectively, the pre-preparation message and the 2f preparation messages are combined into the second preparation certificate corresponding to the second request message; wherein f is a positive integer, and f is used to represent the maximum number of illegal
  • the PBFT algorithm is a state machine replication algorithm that reaches consensus through a three-stage protocol.
  • the embodiment of the present application follows the pre-preparation stage and the preparation stage in the PBFT algorithm, and removes the submission stage, that is, the embodiment of the present application completes the request operation on the request message in the preparation stage. Please refer to Figure 3 again.
  • the master node 30b packages the second request message to obtain the block 30d to be verified, where the sequence number n+1 can be understood as the block height of the block 30d to be verified.
  • the master node 30b determines the block hash value of the block 30d to be verified, and determines the block hash value as the block summary 301d of the block 30d to be verified.
  • the master node 30b generates a pre-preparation identifier corresponding to the block 30d to be verified, and determines the pre-preparation identifier, the first view number of the blockchain network, the sequence number n+1, and the block summary 301d as the pre-preparation information to be signed 301e. Further, the master node 30b signs the pre-preparation information 301e to be signed through the master node private key 301f to obtain the third signature information 302e. Further, the master node 30b generates a pre-prepared message 30g carrying the third signature information 302e and the block to be verified 30d. Further, the master node 30b stores the pre-prepared message 30g in the log database of the master node 30b.
  • the pre-prepare message 30g may be represented as a pre-prepare message Among them, PRE-PREPARE indicates the pre-preparation flag, v indicates the first view number, m indicates the block to be verified 30d, and d indicates the block summary 301d. Indicates the third signature information 302e.
  • the master node 30b broadcasts the pre-prepared message 30g to 3f backup nodes, so that the 3f backup nodes respectively verify the pre-prepared message 30g. It is understandable that there may be an illegal backup node among the 3f backup nodes, and the illegal backup node may not verify the pre-prepared message 30g, and further, will not generate a preparation message corresponding to the second request message, so the illegal backup node will not return the preparation message corresponding to the second request message to the master node 30b. In some embodiments, the illegal backup node verifies the pre-prepared message 30g, but generates an erroneous preparation message to disrupt the subsequent processing of the second request message by the master node 30b.
  • Figure 4 is another schematic diagram of a scenario of data processing based on blockchain provided by an embodiment of the present application.
  • the backup node 30h is any one of the at least 2f legal backup nodes.
  • the backup node 30h obtains the pre-prepared message 30g sent by the master node 30b.
  • the backup node 30h first verifies the legitimacy of the pre-prepared message 30g, so the third signature information 302e carried by the pre-prepared message 30g is verified through the master node public key 302f corresponding to the master node 30b to obtain the first verification result. If the first verification result is successful, the backup node 30h determines that the pre-prepared message 30g is sent by the master node 30b.
  • the backup node 30h verifies the information to be signed 301e, specifically, whether the first view number is the same as its own view number, whether the sequence number n+1 already exists, and whether the block summary 301d is the same as the block hash of the block to be verified 30d generated by itself. If the first view number is the same as the view number of the backup node 30h itself, the sequence number n+1 does not exist, and the block summary 301d is the same as the block hash generated by itself, then the backup node 30h determines that the first verification result is passed.
  • the backup node 30h obtains the preparation identifier for the block to be verified 30d, as well as its own backup node identifier, and determines the preparation identifier, backup node identifier, sequence number n+1, first view number, and block summary 301d as the preparation information to be signed.
  • the backup node 30h signs the preparation information to be signed using its own backup node private key 30i to obtain the fourth signature information 30j, generates a preparation message carrying the fourth signature information 30j and the preparation information to be signed, and broadcasts the preparation message to the master node 30b and the remaining backup nodes, i.e., 3f-1 backup nodes except the backup node 30h; at the same time, the backup node 30h adds the preparation message to its own log database. It can be understood that each node has its own corresponding log database.
  • the preparation message carrying the fourth signature information 30j and the preparation information to be signed can be expressed as a preparation message Among them, PREPARE indicates the preparation mark, i Indicates the backup node identifier of the backup node 30h. Indicates the fourth signature information 30j.
  • the backup node 30h will also obtain the preparation message sent by other backup nodes, and the subsequent processing of the backup node 30h is the same as the subsequent processing of the primary node 30b.
  • the subsequent process of each legal backup node is the same as the subsequent process of the primary node 30b. Therefore, the following description is based on the example of the primary node 30b, and the subsequent processing of at least 2f legal backup nodes can be found in the following description.
  • the master node 30b After the master node 30b obtains the preparation message sent by the backup node 30h and carrying the fourth signature information 30j and the preparation information to be signed, it first verifies the legitimacy of the preparation message, and then verifies the fourth signature information 30j through the backup node public key corresponding to the backup node 30h, and obtains the verification result corresponding to the fourth signature information 30j (referred to as the second verification result). If the second verification result is successful, the master node 30b determines that the preparation message is sent by the backup node 30h, and if the second verification result is failed, it is determined that the preparation message is not sent by the backup node 30h.
  • the master node 30b verifies the preparation message sent by the backup node 30h, specifically, it can be verified whether the view number in the preparation message is the same as its own view number (i.e., the first view number), whether the serialization in the preparation message is the same as its own serialization (i.e., the serial number n+1), and whether the block digest in the preparation message is the same as its own block digest (i.e., the block digest 301d). It is understandable that, under the condition that backup node 30h is a legitimate backup node, the verification result (i.e., the second verification result) of the master node 30b on the preparation message is the second verification pass result. At this time, the master node 30b adds the preparation message sent by the backup node 30h to its own log database.
  • the verification result i.e., the second verification result
  • the master node 30b can obtain the preparation messages sent by other legitimate backup nodes, and the processing process of the preparation messages sent by other legitimate backup nodes is the same as the processing process of the preparation messages sent by the backup node 30h, so it will not be repeated here. If the log database of the master node 30b includes preparation messages corresponding to 2f backup nodes, the master node 30b combines the pre-preparation message 30g and the 2f preparation messages generated by itself into a second preparation certificate corresponding to the second request message.
  • Step S103 while associating and storing the first request message and the first response result in the account book file, executing the request operation corresponding to the second request message in parallel, obtaining the second response result corresponding to the second request message, and storing the second response result in the cache file.
  • the master node can determine that the second request message is ready. At this time, the master node skips the submission phase and executes the following three transactions in parallel: 1. Assign serial number n+2 to the third request message; 2. Execute the request operation corresponding to the second request message to obtain the second response result corresponding to the second request message; 3. Associate and store the first request message and the first response result. The generation of the first response result is based on the condition that the first request message has the first preparation certificate, that is, it is synchronized with the master node assigning serial number n+1 to the second request message. Executed.
  • the process in which the master node executes the request operation corresponding to the second request message and obtains the second response result corresponding to the second request message can be understood as the master node "pre-executing" the second request message, because the second response result and the second request message at this time are not persistently stored (i.e., not written) to the account file, but are saved in the cache file.
  • the request state of the second request message is changed to the request response state.
  • the master node stores the second request message and the second response result in the account file, i.e., persistent storage (i.e., writing to the account book).
  • This process can be understood as the master node "finally executing" the second request message.
  • the request state of the second request message is changed to the request write state.
  • Step S104 returning the first initial response message generated according to the second response result to the client, so that the client determines the request execution result corresponding to the second request message according to the first initial response message and the backup initial response information respectively returned by the backup node with consensus authority in the blockchain network.
  • an initial response identifier for the second request message is generated according to the second response result; the initial response identifier, the first view number of the blockchain network, the request timestamp corresponding to the second request message, the client identifier corresponding to the client, the master node identifier, and the second response result are determined as the initial response information to be signed; the initial response message to be signed is signed by the master node private key to obtain the second signature information; a first initial response message carrying the second signature information and the initial response information to be signed is generated, and the first initial response information is sent to the client, and the second signature information is used to instruct the client to determine the legitimacy of the first initial response message.
  • the second response result is returned to the client that initiated the second request message.
  • Figure 5 is another scenario schematic diagram of data processing based on blockchain provided by the embodiment of the present application.
  • the master node 30b after generating the second response result, the master node 30b generates an initial response identifier for the second request message, and further, the initial response identifier, the first view number of the blockchain network, the request timestamp corresponding to the second request message, the client identifier corresponding to the client, the master node identifier, and the second response result are determined as the initial response information to be signed.
  • the master node 30b signs the initial response information to be signed, obtains the second signature information 30k, and sends the first initial response message carrying the second signature information 30k and the initial response information to be signed to the terminal device 30a installed with the client, wherein the second signature information 30k is used to indicate that the client determines the legitimacy of the first initial response message.
  • the first initial response message carrying the second signature information 30k and the initial response information to be signed can be represented as the first initial response message Among them, PRE-REPLY represents the initial response identifier, t represents the request timestamp, c represents the client identifier, i represents the master node identifier, and r represents the second response result. Indicates the second signature information 30k.
  • the client also receives the initial response message sent by the backup node.
  • the initial response message sent by the backup node is called a backup initial response message.
  • the process of the legitimate backup node generating the backup initial response message is the same as the process of the primary node 30b generating the first initial response message.
  • the client determines the first request execution result corresponding to the second request message based on the first initial response message and the backup initial response information.
  • this process please refer to the description in the embodiment corresponding to Figure 7 below, which will not be described here.
  • the embodiment of the present application proposes an improved PBFT algorithm that can reduce delays, which can remove the submission stage, reduce the response delay of the client, and at the same time, because the number of network interactions for each consensus is reduced, the overall performance of PBFT is improved.
  • the process of this scheme can be seen in Figure 6, which is a flow chart of a data processing method based on blockchain provided by the embodiment of the present application.
  • example f is equal to 1, so the total number of backup nodes is 3, and the three backup nodes are node 1, node 2 and node 3.
  • node 3 in Figure 6 is an illegal backup node, that is, a malicious node, and the master node, node 1 and node 2 are all legal nodes.
  • the master node receives the second request message initiated by the client (abbreviated as request in Figure 6), and the master node broadcasts the second request message request to the backup node through a two-stage protocol, as follows.
  • Pre-preparation phase The master node determines whether there is a first preparation certificate for the first request message with sequence number n. If there is a first preparation certificate, it assigns sequence number n+1 to the second request message.
  • the master node broadcasts a pre-preparation message For all backup nodes, such as node 1, node 2 and node 3 as shown in FIG6 .
  • Preparation phase After receiving the pre-preparation message sent by the master node, node 1 verifies the pre-preparation message. After the verification passes, it accepts the pre-preparation message and writes it into the log database, and enters the preparation phase. At this time, node 1 broadcasts a preparation message To all nodes, namely the master node, node 2 and node 3, and write the prepared message generated by itself into its own log database. Later, node 1 will also receive the prepared message sent by node 2 And after the verification is successful, the preparation message is written into its own log database.
  • Figure 7 is another flow chart of a data processing method based on blockchain provided in an embodiment of the present application.
  • the data processing method based on blockchain can be executed by a master node with consensus authority in a blockchain network. As shown in Figure 7, the method may include at least the following steps.
  • Step S201 obtaining a second request message and determining a request status of the second request message; the second request message is initiated by the client.
  • the request message corresponding to the cache request hash in the cache file is the request message for which the request operation has been executed; if there is a cache request hash identical to the request hash in the cache file, determine that the request state of the second request message is the request response state; if there is no cache request hash identical to the request hash in the cache file, compare the request hash with the write request hash in the ledger text; the request message corresponding to the write request hash in the ledger file is the request message that has been stored; if there is a write request hash identical to the request hash in the ledger file, determine that the request state of the second request message is the request write state; if there is no write request hash identical to the request hash in the ledger file, determine that the request state of the second request message is the request initial state.
  • the master node obtains a second response result in response to executing the request operation of the second request message, and stores the request hash of the second request message as a cache request hash in the cache file; the master node stores the second request message and the second response result in association with each other in the ledger file in response, and stores the request hash of the second request message as a write request hash in the ledger file.
  • the master node receives the second request message initiated by the client
  • o is the request operation of the second request message
  • t is the request timestamp, which can be understood as the timestamp of initiating the second request message
  • c is the client identifier
  • ⁇ c is the signature of the client on the second request message.
  • the master node first verifies the legitimacy of the second request message through the signature ⁇ c . If the second request message is a legal request message, a request hash corresponding to the second request message is generated, and then the request status of the second request message is determined through the request hash. It can be understood that the master node needs to determine the request status of each request message it obtains, and then determine the response result of the request message based on the request status corresponding to the request message. The embodiment of the present application is described by way of example with the second request message.
  • the master node can first compare the request hash corresponding to the second request message with the cache request hash in the cache file of the master node.
  • the master node can then determine that the second request message has been executed, and its corresponding response result is the second response result stored in the cache file, but not written to the account file of the master node. If there is no cache request hash identical to the request hash in the cache file of the master node, the master node will request The request hash is compared with the write request hash in the account file of the master node.
  • the request state of the second request message can be determined to be the request write state, and then the master node can determine that the second request message has been executed, and the corresponding response result is the second response result that has been written into the account file of the master node. If the write request hash that is the same as the request hash does not exist in the account file of the master node, the master node can determine that the request state of the second request message is the request initial state.
  • the master node may also first compare the request hash of the second request message with the write request hash in the account file of the master node. If there is no write request hash identical to the request hash in the account file, the request hash of the second request message is then compared with the response request hash in the cache file of the master node. In some embodiments, the master node may compare the request hash of the second request message with the write request hash in the account file of the master node, and also compare the request hash of the second request message with the response request hash in the cache file of the master node.
  • Step S202 if the request status is a request response status, then the second response result corresponding to the second request message is obtained in the cache file, and the second initial response message generated according to the second response result is returned to the client, so that the client determines the second request execution result corresponding to the second request message according to the second initial response message and the backup initial response messages returned by each backup node respectively; the request response status is used to indicate that the second request message exists in the blockchain network and the request operation corresponding to the second request message has been executed.
  • the master node can determine that the second request message is sent repeatedly by the client, and the client has not previously executed the result of the first request through the second request message. Since the master node has not yet written the second response result and the second request message to the account book file, the specific implementation method of this step is the same as the specific implementation method of the request status of the second request message being the request initial state, that is, returning an initial response message (i.e., the second initial response message, mainly emphasizing that the generation time is different from the first initial response message) to the client according to the second response result, and the generation process of the second initial response message is the same as the generation process of the first initial response message in step S104 in the embodiment corresponding to FIG. 2 above. The difference between the two is that the generation time is different.
  • the first initial response message occurs in the scenario where the request status is the request initial state
  • the second initial response message occurs in the scenario where the request status is the request response state.
  • Step S203 if the request status is a request write status, then the second response result corresponding to the second request message is obtained in the account file, and the completion response message generated according to the second response result is returned to the client, so that the client determines the third request execution result corresponding to the second request message according to the completion response message and the backup completion response messages returned by each backup node respectively; the request write status is used to indicate that the second request message exists in the blockchain network, and the second request message and the second response result are stored in association.
  • a completion response identifier for the second request message is generated according to the second response result; the completion response identifier, the first view number of the blockchain network, the request timestamp corresponding to the second request message, the client identifier corresponding to the client, the master node identifier, and the second response result are determined as the completion response information to be signed; the completion response information to be signed is signed by the master node private key to obtain the first signature information; a completion response message carrying the first signature information and the completion response information to be signed is generated and sent to the client; the first signature information is used to instruct the client to determine the legitimacy of the completion response message.
  • the master node can determine that the second request message is sent repeatedly by the client, and the client has not previously executed the request result through the second request message. Since the master node has written the second response result and the second request message, a completion response identifier for the second request message is generated according to the second response result; the subsequent process is similar to the process of the master node generating the initial response message.
  • the master node first determines the completion response identifier, the first view number of the blockchain network, the request timestamp corresponding to the second request message, the client identifier corresponding to the client, the master node identifier, and the second response result as the completion response information to be signed; further, the master node signs the completion response information to be signed through the master node private key to obtain the first signature information, and then sends the completion response message carrying the first signature information and the corresponding information to be signed to the client.
  • the completion response message carrying the first signature information and the corresponding information to be signed can be expressed as a completion response message Among them, REPLY indicates the completion response mark. Indicates the first signature information.
  • the client will also receive a completion response message sent by the backup node.
  • the completion response message sent by the backup node is called a backup completion response message. It can be understood that the process of generating a backup completion response message by a legitimate backup node is the same as the process of generating a completion response message by the primary node.
  • the specific manner in which the client determines the execution result of the first request of the second request message based on the first initial response message and the backup initial response message is the same as the specific manner in which the client determines the execution result of the second request of the second request message based on the second initial response message and the backup initial response message, but the specific manner in which the client determines the execution result of the second request of the second request message based on the second initial response message and the backup initial response message is different from the specific manner in which the client determines the third request execution result of the second request message based on the completion response message and the backup completion response message.
  • Step S204 if the request status is the request initial status, then in response to the first request message with serial number n having a first preparation certificate, the second request message is assigned serial number n+1; the request initial status is used to indicate that the second request message does not exist in the blockchain network; n is a positive integer.
  • Step S205 In response to the second request message having the second preparation certificate, the first request message and the first request message are sent to the server.
  • the first response result corresponding to the request message is associated and stored in the account book file.
  • Step S206 while associating and storing the first request message and the first response result in the account book file, executing the request operation corresponding to the second request message in parallel, obtaining the second response result corresponding to the second request message, and storing the second response result in the cache file.
  • Step S207 returning the first initial response message generated according to the second response result to the client, so that the client determines the first request execution result corresponding to the second request message according to the first initial response message and the backup initial response message returned by the backup node with consensus authority in the blockchain network.
  • steps S204 to S207 please refer to steps S101 to S104 in the embodiment corresponding to FIG. 2 above, which will not be described in detail here.
  • the nodes described below are all nodes with consensus authority.
  • the second request message will eventually be executed by all correct nodes in the same order. That is, even if a view switch occurs, resulting in some nodes not executing the second request message, the second request message will be collected by the new master node and re-enter the consensus using the same sequence number as the original second request message, so that it can be executed by all nodes. This process can be called "request replay”.
  • the new master node collects "requests to be replayed” in the following way: collect preparation certificates from 2f+1 different nodes, where the sequence number corresponding to the collected preparation certificates is greater than the sequence number of the most recently requested "stable checkpoint" of the new master node.
  • the new master node "replays" all request messages corresponding to the collected preparation certificates.
  • the stable checkpoint refers to a state in the PBFT algorithm where the correct nodes have reached a consensus, and this state is obtained by executing z request messages.
  • Quorum means arbitration number, legal number of people.
  • Quorum represents a set of nodes that is not less than 2f+1.
  • Quorum certificate represents a set of certain messages from each node of a Quorum, called a certificate, such as a preparation certificate.
  • Quorum has two important properties:
  • Case 1 (most of the time): The client receives 2f+1 identical candidate initial responses to the second request message during the first request processing cycle of the second request message. This means that there are 2f+1 nodes There is a preparation certificate for the second request message. If the master node also has a preparation certificate for the second request message at this time, then the master node can send a pre-preparation message with a sequence number of n+1. At least 2f other nodes can send preparation messages with a sequence number of n+1. Therefore, the second request message with a sequence number of n+1 can be "pre-executed" by a certain node, that is, execute its corresponding request operation.
  • the second request message can be finally executed by a certain node, that is, the second request message and its corresponding response result are associated and stored.
  • the new master node collects the preparation certificates of 2f+1 nodes.
  • the two Quorums have at least one common correct node (that is, a legal node), so the preparation certificate of the second request message will definitely be collected by the new master node, and will definitely be "replayed”.
  • Case 2 For the case where the client receives f+1 identical candidate completion responses corresponding to the second request message during the second request processing cycle of the second request message. This means that at least one correct node "finally executes" the second request message, and it is only necessary to prove that the stored second request message will definitely be "replayed”.
  • the third request message with serial number n+2 has a third preparation certificate, that is, the node has received 1 pre-prepared message 3 and 2f preparation messages 3 of the third request message with serial number n+2, and the node will only send pre-prepared message 3 or preparation message 3 with serial number n+2 if it already has the second preparation certificate of the second request message with serial number n+1, so there are 2f+1 nodes with the second preparation certificate of the second request message with serial number n+1. So far, the subsequent proof sees case 1.
  • Figure 8 is another flow chart of a data processing method based on blockchain provided in an embodiment of the present application.
  • the data processing method based on blockchain can be executed by a client. As shown in Figure 8, the method may include at least the following steps.
  • Step S301 sending a second request message to a node with consensus authority in the blockchain network, so that the master node among the nodes with consensus authority: in response to the first request message with serial number n having a first preparation certificate, assigning a serial number n+1 to the second request message; n is a positive integer; in response to the second request message having a second preparation certificate; associating and storing the first request message and the first response result corresponding to the first request message in the ledger file, and while associating and storing the first request message and the first response result in the ledger file, executing the request operation corresponding to the second request message in parallel, obtaining a second response result corresponding to the second request message, and storing the second response result in the cache file; generating a first initial response message for the second request message according to the second response result.
  • step S301 please refer to steps S101 to S104 in the embodiment corresponding to FIG. 2 above, and step S201 in the embodiment corresponding to FIG. 7 above, which will not be described in detail here.
  • Step S302 obtain the first initial response message returned by the primary node, and determine the first request execution result corresponding to the second request message according to the first initial response message and the backup initial response messages respectively returned by the backup nodes with consensus authority in the blockchain network.
  • the primary node and at least 2f legal backup nodes in the blockchain network can return the initial response messages (including the first initial response message and the backup response initial message) generated by themselves to the client. It can be understood that the client's processing of the first initial response message is the same as the processing of each backup response initial message, so this step is described by taking the client's processing of the first initial response message as an example.
  • the first initial response message carries the second signature information and the initial response information to be signed;
  • the second signature information is obtained by the master node signing the initial response information to be signed through the master node private key;
  • the initial response message to be signed includes the initial response identifier, the first view number of the blockchain network, the request timestamp corresponding to the second request message, the client identifier, the master node identifier corresponding to the master node, and the second response result;
  • the second signature information is verified by the master node public key corresponding to the master node private key to obtain the verification result corresponding to the second signature information; if the verification result corresponding to the second signature information is successful, the request timestamp and the second response result are added as candidate initial responses De to the candidate initial response set corresponding to the initial response identifier;
  • the candidate initial response set includes G candidate initial responses;
  • the G candidate initial responses include candidate initial response De;
  • e is a positive integer, and e is less than or equal to 3f+1;
  • G is
  • the specific process of determining the execution result of the first request corresponding to the second request message based on the candidate initial response set may include: within the first request processing cycle, if there are 2f+1 identical candidate initial responses in the candidate initial response set, then the execution result of the first request corresponding to the second request message is determined to be successful; if there are not 2f+1 identical candidate initial responses in the candidate initial response set, then the execution result of the first request corresponding to the second request message is determined to be a failure.
  • the client can add the request timestamp and the second response result in the first initial response message as a candidate initial response to the candidate initial response set.
  • the candidate initial response set may include G candidate initial responses, wherein one candidate initial response corresponds to the initial response message of a node (a primary node or a backup node). If within the first request processing cycle, there are 2f+1 identical candidate initial responses in the candidate initial response set, that is, there are 2f+1 identical request timestamps, and 2f+1 identical response results, then the client can determine that the first request execution result of the second request message is successful.
  • the client can determine that the first request execution result is a failure. At this time, the client resends the second request message to the blockchain network.
  • the first request processing cycle can be understood as a waiting period for the client to determine the processing result of the blockchain network processing the request message sent for the first time.
  • Figure 9 is another flow chart of a data processing method based on blockchain provided in an embodiment of the present application.
  • the data processing method based on blockchain can be executed by a client. As shown in Figure 9, the method may include at least the following steps.
  • Step S401 sending a second request message to a node with consensus authority in the blockchain network, so that the master node among the nodes with consensus authority: in response to the first request message with serial number n having a first preparation certificate, assigning serial number n+1 to the second request message; n is a positive integer; in response to the second request message having a second preparation certificate, associating and storing the first request message and the first response result corresponding to the first request message in the ledger file, wherein the first response result is obtained by executing the operation corresponding to the first request message in response to the first request message having the first preparation certificate; while associating and storing the first request message and the first response result in the ledger file, executing the request operation corresponding to the second request message in parallel, obtaining the second response result corresponding to the second request message, and storing the second response result in the cache file; generating a first initial response message for the second request message according to the second response result.
  • Step S402 obtain the first initial response message returned by the master node, and determine the first request execution result corresponding to the second request message according to the first initial response message and the backup initial response messages respectively returned by the backup nodes among the nodes with consensus authority in the blockchain network.
  • step S401-step S402 For the specific implementation process of step S401-step S402, please refer to step S301-step S302 in the embodiment corresponding to FIG. 8 above, which will not be described in detail here.
  • Step S403 If the execution result of the first request is failure, determine the update timestamp corresponding to the second request message according to the first request processing cycle.
  • the master node resends the second request message at the time point corresponding to the update timestamp, wherein the time difference between the update timestamp and the request timestamp is the duration corresponding to the first request processing period.
  • Step S404 at the time point corresponding to the update timestamp, resend the second request message to 3f+1 nodes with consensus authority, so that the 3f+1 nodes with consensus authority respectively determine the request status of the second request message and return the actual response result corresponding to the request status.
  • node Ji determines the actual response result corresponding to the second request message according to the request status Hi of the second request message in node Ji; and generates an actual response message according to the actual response result; i is a positive integer, and i is less than or equal to 3f+1; the request status Hi belongs to 3f+1 request states; node Ji belongs to the node where the request status Hi is located among the 3f+1 nodes with consensus authority.
  • the master node obtains the second request message that is repeatedly sent, and broadcasts the second request message to all nodes. It can be understood that the processing process of the master node obtaining the second request message that is repeatedly sent is the same as the processing process of the legitimate backup node obtaining the second request message that is repeatedly sent, so the embodiment of the present application is described by the master node example.
  • the master node first determines the request status of the second request message. For the specific process of determining the request status, please refer to the description of step S201 in the embodiment corresponding to Figure 7 above. If the request status is the request response status, the actual response result is the second response result stored in the cache file, and the actual response message is the second initial response message.
  • the master node that receives the second request message sent for the first time and the master node that receives the second request message that is repeatedly sent may be the same or different. For example, between the two second request messages, the master node may switch due to a fault or other reasons, and the view changes.
  • Step S405 obtaining actual response messages respectively returned by multiple nodes with consensus authority, and determining the request update execution result corresponding to the second request message according to the actual response messages.
  • the request update execution result can be the second request execution result of the second request message determined based on the second initial response message returned by the master node and the backup initial response message returned by each backup node, or it can be the third request execution result of the second request message determined based on the completion response message returned by the master node and the backup completion response message returned by each backup node.
  • the update timestamp and the actual response result in the actual response message are determined as the candidate completion response Ki; the candidate completion response Ki is added to the candidate completion response set corresponding to the completion response identifier; the candidate completion response set includes L candidate completion responses; the L candidate completion responses include the candidate completion response Ki; L is a positive integer, and L is less than or equal to 3f+1; according to the candidate completion response set, the third request execution result corresponding to the second request message is determined.
  • the specific process of determining the execution result of the third request corresponding to the second request message based on the candidate completion response set may include: within the second request processing cycle, if there are f+1 identical candidate completion responses in the candidate completion response set, the execution result of the third request corresponding to the second request message is determined to be successful; if there are not f+1 identical candidate completion responses in the candidate completion response set, the execution result of the third request corresponding to the second request message is determined to be a failure.
  • the client can only obtain the first initial response message and the backup initial response message.
  • the client may obtain the second initial response message returned by the master node, or may obtain the completion response message returned by the master node.
  • the client may obtain a backup initial response message returned by the backup node, or may obtain a backup completion response message returned by the backup node. If the second initial response message and the backup initial response message are obtained, the processing process of the client in the second request processing cycle is the same as the processing process in the first request processing cycle, that is, it is necessary to collect 2f+1 identical candidate initial responses.
  • the candidate initial response set includes the candidate initial responses collected in the first request processing cycle and the candidate initial responses collected in the second request processing cycle, and if two candidate initial responses of the same node are collected in two request processing cycles, only one candidate initial response is retained, that is, different candidate initial responses correspond to different nodes. If the completion response message and the backup completion response message are obtained, the client needs to collect f+1 identical candidate completion responses in the second request processing cycle.
  • the client may obtain a completion response message while obtaining an initial response message (e.g., a second initial response message).
  • the client can generate a candidate initial response set corresponding to the initial response identifier and a candidate completion response set corresponding to the completion response identifier.
  • the client can determine that the second request execution result of the second request message is successful, or there are f+1 identical candidate completion responses in the candidate completion response set, the client can determine that the third request execution result of the second request message is successful.
  • the client determines that the second request execution result and the third request execution result are failures. In the scenario where the second request execution result and the third request execution result are failures, the client can send the second request message to the blockchain network again.
  • the embodiment of the present application starts consensus on the second request message when the first request message has the first preparation certificate, that is, there is no need to wait for the execution of the request operation corresponding to the first request message, so the consensus efficiency of the blockchain network can be improved; in addition, when the second request message has the second preparation certificate, the embodiment of the present application skips the submission stage of the second request message, not only the first request message and the first response result are associated and stored, but also the request message corresponding to the second request message is executed. Obviously, the embodiment of the present application performs the storage of the first request message and the execution of the second request message in parallel, and removes the submission stage, so the response delay of the client can be reduced.
  • the embodiment of the present application sends the first initial response message to the client, so the client does not need to wait for the storage of the second response result to determine the request execution result of the second request message, so the client's determination efficiency for the request execution result can be improved.
  • FIG 10 is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of the present application.
  • the blockchain-based data processing device can be run on a master node with consensus authority in a blockchain network.
  • the blockchain-based data processing device 1 can be used to execute the method provided in an embodiment of the present application.
  • the blockchain-based data processing device 1 may include: a sequence number allocation module 11, an association storage module 12, a request operation module 13 and a first return module 14.
  • a sequence number allocation module 11 is configured to allocate a sequence number n+1 to a second request message in response to the first request message having a sequence number n having a first preparation certificate; n is a positive integer;
  • An associated storage module 12 is used for associating and storing the first request message and the first response result corresponding to the first request message in a ledger file in response to the second request message having a second preparation certificate;
  • a request operation module 13 is used to perform a request operation corresponding to a second request message in parallel while associating and storing the first request message and the first response result in the account file, obtain a second response result corresponding to the second request message, and store the second response result in a cache file;
  • the first returning module 14 is used to return the first initial response message generated according to the second response result to the client that initiated the second request message, so that the client determines the first request execution result corresponding to the second request message according to the first initial response message and the backup initial response message returned by the backup node with consensus authority in the blockchain network.
  • sequence number allocation module 11 the associated storage module 12, the request operation module 13 and the first return module 14 can refer to the steps S101 to S104 in the embodiment corresponding to Figure 2 above, and will not be repeated here.
  • the blockchain-based data processing device 1 may also include: a state determination module 15, a second return module 16, a third return module 17 and a step execution module 18.
  • the status determination module 15 is used to obtain the second request message and determine the request status of the second request message
  • the second return module 16 is used to obtain the second response result corresponding to the second request message in the cache file if the request status is the request response status, and return the second initial response message generated according to the second response result to the client, so that the client can determine the second request execution result corresponding to the second request message according to the second initial response message and the backup initial response message respectively returned by the backup node with consensus authority in the blockchain network;
  • the request response status is used to indicate that the second request message exists in the blockchain network, and the master node has executed the request operation corresponding to the second request message to obtain the second response result and store the second response result in the cache file;
  • the third return module 17 is used to obtain the second response result corresponding to the second request message in the account file if the request status is the request write status, and return the completion response message generated according to the second response result to the client, so that the client can determine the third request execution result corresponding to the second request message according to the completion response message and the backup initial response message returned by the backup node with consensus authority in the blockchain network;
  • the request write status is used to indicate that the second request message exists in the blockchain network, and the master node has associated and stored the second request message and the second response result To the ledger file;
  • the step execution module 18 is used to execute the step of assigning a serial number n+1 to the second request message in response to the first request message with a serial number n having a first preparation certificate if the request status is a request initial status; the request initial status is used to indicate that the second request message does not exist in the blockchain network.
  • the specific functional implementation methods of the state determination module 15, the second return module 16, the third return module 17 and the step execution module 18 can refer to steps S201 to S204 in the embodiment corresponding to Figure 7 above, and will not be repeated here.
  • Figure 11 is another structural diagram of a blockchain-based data processing device provided in an embodiment of the present application.
  • the above-mentioned blockchain-based data processing device 2 can be run on a client, and the device can be used to execute the corresponding steps in the method provided in an embodiment of the present application.
  • the blockchain-based data processing device 2 may include: a first sending module 21 and a first determining module 22.
  • the first sending module 21 is used to send the second request message to the node with consensus authority in the blockchain network, so that the master node among the nodes with consensus authority: in response to the first request message with serial number n having the first preparation certificate, assign the second request message with serial number n+1; n is a positive integer; in response to the second request message having the second preparation certificate, associate the first request message and the first response result corresponding to the first request message and store them in the account file; while associating and storing the first request message and the first response result in the account file, execute the request operation corresponding to the second request message in parallel, obtain the second response result corresponding to the second request message, and store the second response result in the cache file; generate a first initial response message for the second request message according to the second response result;
  • the first determination module 22 is used to obtain a first initial response message returned by the primary node, and determine a request execution result corresponding to the second request message according to the first initial response message and the backup initial response messages respectively returned by the backup nodes among the nodes with consensus authority in the blockchain network.
  • the specific functional implementation of the first sending module 21 and the first determining module 22 can refer to steps S301 to S302 in the embodiment corresponding to FIG. 8 above, which will not be described in detail here.
  • the blockchain-based data processing device 2 may also include: a second determination module 23, a second sending module 24 and a third determination module 25.
  • a second determination module 23 is used to determine an update timestamp corresponding to the second request message according to the first request processing cycle if the request execution result is failure;
  • the second sending module 24 is used to resend the second request message to 3f+1 nodes with consensus authority at the time point corresponding to the update timestamp, so that the 3f+1 nodes with consensus authority can respectively determine the request status of the second request message;
  • the request status Hi is used to indicate the node Ji to determine the actual response result corresponding to the second request message;
  • the actual response result is used to instruct the node Ji to generate an actual response message;
  • i is a positive integer, and i is less than or equal to 3f+1;
  • the request state Hi belongs to 3f+1 request states;
  • the node Ji belongs to the node where the request state Hi is located among the 3f+1 nodes with consensus authority;
  • the third determination module 25 is used to obtain the actual response message returned by the node Ji, and determine the request execution result corresponding to the second request message according to the actual response message.
  • the specific functional implementation of the second determination module 23, the second sending module 24 and the third determination module 25 can refer to steps S403 to S405 in the embodiment corresponding to FIG. 9 above, which will not be described in detail here.
  • the computer device 1000 may include: at least one processor 1001, such as a CPU, at least one network interface 1004, a user interface 1003, a memory 1005, and at least one communication bus 1002.
  • the communication bus 1002 is used to realize the connection and communication between these components.
  • the user interface 1003 may include a display screen (Display), a keyboard (Keyboard), and the network interface 1004 may include a standard wired interface, a wireless interface (such as a WI-FI interface).
  • the memory 1005 may be a high-speed RAM memory, or it may be a non-volatile memory (non-volatile memory), such as at least one disk memory.
  • the memory 1005 may also be at least one storage device located away from the aforementioned processor 1001.
  • the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a device control application.
  • the network interface 1004 can provide a network communication function;
  • the user interface 1003 is mainly used to provide an input interface for the user; and
  • the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:
  • n is a positive integer
  • the first request message and a first response result corresponding to the first request message are associated and stored in the account file, wherein the first response result is obtained by executing an operation corresponding to the first request message in response to the first request message having the first preparation certificate; while the first request message and the first response result are associated and stored in the account file, the request operation corresponding to the second request message is executed in parallel to obtain a second response result corresponding to the second request message, and the second response result is stored in the cache file;
  • the first initial response message generated according to the second response result is returned to the client, so that the client determines the first request execution result corresponding to the second request message according to the first initial response message and the backup initial response message returned by the backup node with consensus authority in the blockchain network.
  • the processor 1001 may be configured to call a device control application stored in the memory 1005 to implement:
  • the computer device 1000 described in the embodiments of the present application can execute the description of the data processing method or device based on blockchain in the above embodiments, which will not be repeated here.
  • the description of the beneficial effects of using the same method will not be repeated.
  • the present application also provides a computer-readable storage medium, which stores a computer program.
  • the computer program is executed by a processor, the description of the data processing method or device based on blockchain in the above embodiments is implemented, which will not be repeated here.
  • the description of the beneficial effects of the same method will not be repeated.
  • the computer-readable storage medium may be a data processing device based on blockchain provided in any of the aforementioned embodiments or an internal storage unit of the computer device, such as a hard disk or memory of the computer device.
  • the computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a smart memory card (smart media card, SMC), a secure digital (secure digital, SD) card, a flash card (flash card), etc. equipped on the computer device.
  • the computer-readable storage medium may also include both an internal storage unit of the computer device and an external storage device.
  • the computer-readable storage medium is used to store the computer program and other programs and data required by the computer device.
  • the computer-readable storage medium may also be used to temporarily store data that has been output or is to be output.
  • the present application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium.
  • the processor of the computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, so that the computer device can execute the description of the data processing method or device based on blockchain in the above embodiments, which will not be repeated here.
  • the description of the beneficial effects of the method will not be repeated here.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请实施例公开了一种基于区块链的数据处理方法、设备以及可读存储介质，该方法由主节点执行，该方法包括：响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1；响应于第二请求消息具有第二准备证书将第一请求消息以及第一请求消息对应的第一响应结果进行关联存储；在关联存储第一请求消息以及第一响应结果的同时，并行执行第二请求消息对应的请求操作，得到第二请求消息对应的第二响应结果；将根据第二响应结果所生成的第一初始响应消息返回至客户端，以使客户端根据第一初始响应消息和区块链网络中具有共识权限的备份节点分别返回的备份初始响应消息，确定第二请求消息对应的第一请求执行结果。

Description

基于区块链的数据处理方法、设备以及可读存储介质
本申请要求于2022年9月26日提交中国专利局、申请号为202211182614.7，发明名称为“一种基于区块链的数据处理方法、设备以及可读存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及互联网技术领域，尤其涉及一种基于区块链的数据处理方法、设备以及可读存储介质。
背景技术
随着网络技术的快速发展以及企业对数据安全的重视，区块链得到了极大的重视和应用。
当获取到请求消息时，主节点(即出块节点)需要将该请求消息广播至备份节点(即其它共识节点)，以此对该请求消息进行共识。
技术内容
本申请实施例提供一种基于区块链的数据处理方法、设备以及可读存储介质，不仅可以提高区块链网络的共识效率，还可以减少客户端的响应延迟，提高客户端针对请求执行结果的确定效率。
本申请实施例提供了一种基于区块链的数据处理方法，该方法由区块链网络中具有共识权限的主节点执行，该方法包括：
响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1；n为正整数；
响应于第二请求消息具有第二准备证书，将第一请求消息以及第一请求消息对应的第一响应结果进行关联存储到账本文件，所述第一响应结果是响应于所述第一请求消息具有第一准备证书，通过执行所述第一请求消息对应的操作得到的；在关联存储第一请求消息以及第一响应结果到账本文件的同时，并行执行第二请求消息对应的请求操作，得到第二请求消息对应的第二响应结果，将第二响应结果存储到缓存文件；
将根据第二响应结果所生成的第一初始响应消息返回至发起所述第二请求消息的客户端，以使所述客户端根据第一初始响应消息和区块链网络中具有共识权限的备份节 点分别返回的备份初始响应消息，确定第二请求消息对应的第一请求执行结果。
本申请实施例提供了一种基于区块链的数据处理方法，该方法由客户端执行，该方法包括：
将第二请求消息发送至区块链网络中具有共识权限的节点，以使具有共识权限的节点中的主节点：响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1；n为正整数；响应于所述第二请求消息具有第二准备证书，将第一请求消息以及第一请求消息对应的第一响应结果关联存储到账本文件，所述第一响应结果是所述主节点响应于所述第一请求消息具有第一准备证书，通过执行所述第一请求消息对应的操作得到的；在关联存储第一请求消息以及第一响应结果到账本文件的同时，并行执行第二请求消息对应的请求操作，得到第二请求消息对应的第二响应结果，将第二响应结果存储到缓存文件；根据第二响应结果生成针对第二请求消息的第一初始响应消息；
获取主节点返回的第一初始响应消息，根据第一初始响应消息和具有共识权限的节点中的备份节点分别返回的备份初始响应消息，确定第二请求消息对应的第一请求执行结果。
本申请实施例提供了一种基于区块链的数据处理装置，该装置运行于区块链网络中具有共识权限的主节点，该装置包括：
序号分配模块，用于响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1；n为正整数；
关联存储模块，用于响应于所述第二请求消息具有第二准备证书，将第一请求消息以及第一请求消息对应的第一响应结果关联存储到账本文件，所述第一响应结果是响应于所述第一请求消息具有第一准备证书，通过执行所述第一请求消息对应的操作得到的；
请求操作模块，用于在关联存储第一请求消息以及第一响应结果到账本文件的同时，并行执行第二请求消息对应的请求操作，得到第二请求消息对应的第二响应结果，将第二响应结果存储到缓存文件；
第一返回模块，用于将根据第二响应结果所生成的第一初始响应消息返回至客户端，以使客户端根据第一初始响应消息和区块链网络中具有共识权限的备份节点分别返回的备份初始响应消息，确定第二请求消息对应的第一请求执行结果。
本申请实施例提供了一种基于区块链的数据处理装置，该装置运行于客户端，该装置包括：
第一发送模块，用于将第二请求消息发送至区块链网络中具有共识权限的节点，以使具有共识权限的节点中的主节点：响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1；n为正整数；响应于第二请求消息具有第二准备证书，将第一请求消息以及第一请求消息对应的第一响应结果关联存储到账本文件，所述第一响应结果是所述主节点响应于所述第一请求消息具有第一准备证书，通过执行所述第一请求消息对应的操作得到的；在关联存储第一请求消息以及第一响应结果当账本文件的同时，并行执行第二请求消息对应的请求操作，得到第二请求消息对应的第二响应结果，将第二响应结果存储到缓存文件；根据第二响应结果生成针对第二请求消息的第一初始响应消息；
第一确定模块，用于获取主节点返回的第一初始响应消息，根据第一初始响应消息和具有共识权限的节点中的备份节点分别返回的备份初始响应消息，确定第二请求消息对应的第一请求执行结果。
本申请实施例提供了一种计算机设备，包括：处理器、存储器、网络接口；
上述处理器与上述存储器、上述网络接口相连，其中，上述网络接口用于提供数据通信功能，上述存储器用于存储计算机程序，上述处理器用于调用上述计算机程序，以使得计算机设备执行本申请实施例中的方法。
本申请实施例提供了一种计算机可读存储介质，上述计算机可读存储介质中存储有计算机程序，上述计算机程序适于由处理器加载并执行本申请实施例中的方法。
本申请实施例提供了一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序存储在计算机可读存储介质中；计算机设备的处理器从计算机可读存储介质读取该计算机程序，处理器执行该计算机程序，使得该计算机设备执行本申请实施例中的方法。
附图简要说明
图1是本申请实施例提供的一种系统架构示意图；
图2是本申请实施例提供的一种基于区块链的数据处理方法的流程示意图；
图3是本申请实施例提供的一种基于区块链的数据处理的场景示意图；
图4是本申请实施例提供的一种基于区块链的数据处理的另一场景示意图；
图5是本申请实施例提供的一种基于区块链的数据处理的又一场景示意图；
图6是本申请实施例提供的一种基于区块链的数据处理方法的场景示意图；
图7是本申请实施例提供的一种基于区块链的数据处理方法的另一流程示意图；
图8是本申请实施例提供的一种基于区块链的数据处理方法的另一流程示意图；
图9是本申请实施例提供的一种基于区块链的数据处理方法的另一流程示意图；
图10是本申请实施例提供的一种基于区块链的数据处理装置的结构示意图；
图11是本申请实施例提供的一种基于区块链的数据处理装置的另一结构示意图；
图12是本申请实施例提供的一种计算机设备的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面结合附图对本申请作进一步的详细阐述。
在一些实施方式中，区块链的核心算法之一：实用拜占庭容错算法(Practical Byzantine Fault Tolerance，PBFT)，通过三阶段协议对请求消息进行共识。其中，三阶段协议包括预准备阶段、准备阶段、和提交阶段，其中，提交阶段可以保证跨视图请求顺序的一致，但提交阶段增加了每次共识的网络交互次数，不仅降低了区块链网络的共识效率，还延长了客户端的响应时间，降低了客户端对请求消息的请求执行结果的确定效率。
为解决上述问题，本申请实施例提出了一种基于区块链的数据处理方案，以下进行详细介绍：
为了便于理解，首先对部分名词进行以下简单解释：
1、区块链：狭义上，区块链是一种以区块为基本单位的链式数据结构，区块中利用数字摘要对之前获取的交易历史进行校验，适合分布式记账场景下防篡改和可扩展性的需求；广义上，区块链还指代区块链结构实现的分布式记账技术，包括分布式共识、隐私与安全保护、点对点通信技术、网络协议、智能合约等。区块链的目标是实现一个分布的数据记录账本，此账本只允许添加，不允许删除。账本底层的基本结构是一个线性的链表。链表由一个个“区块”串联组成，后继区块中记录前继区块的哈希(Hash)值，每个区块(以及区块中的交易)是否合法，可通过计算哈希值的方式进行快速检验。若网络中的节点提议添加一个新的区块，必须经过共识机制对区块达成共识确认。
2、区块(block)：是在区块链网络上承载交易数据的数据包，是一种被标记上时间戳和前继区块对应的哈希值的数据结构，区块经过网络的共识机制验证并确认区块中的交易。区块包括区块头(Block Header)以及区块体(Block Body)，区块头可以记 录当前区块的元信息，包含当前版本号、前继区块对应的哈希值、时间戳、随机数、默克尔树根(Merkle Root)的哈希值等数据。区块体可以记录一段时间内所生成的详细数据，包括当前区块经过验证的、区块创建过程中生成的所有交易记录或是其他信息，可以理解为账本的一种表现形式。此外，区块体的详细数据可以包括通过默克尔树(Merkle Tree)的哈希过程，生成唯一的Merkle Root记录于区块头。
前继区块，也称父区块(Parent Block)，区块链通过在区块头记录区块对应的哈希值以及父区块对应的哈希值实现时间上的排序。
3、哈希值(hash)：也称作信息特征值或特征值，哈希值是通过哈希算法将任意长度的输入数据转换为密码并进行固定输出而生成的，不能通过解密哈希值来检索原始输入数据，它是一个单向的加密函数。在区块链中，每个区块(除了初始区块)都包含前继区块的哈希值，哈希值是区块链技术中的潜力核心基础和最重要的方面，它保留了记录和查看数据的真实性，以及区块链作为一个整体的完整性。
4、区块链节点：区块链网络将节点区分为共识节点(也可以称作核心节点)以及同步节点(可以包括数据节点以及轻节点)。其中，共识节点负责区块链全网的共识业务；同步节点负责同步共识节点的账本信息，即同步最新的区块数据。无论是共识节点还是同步节点，其内部构造都包括网络通信组件，因为区块链网络本质是一个点对点(Peer to Peer，P2P)网络，需通过P2P组件与区块链网络中的其他节点进行通信。区块链网络中的资源和服务都分散在各个节点上，信息的传输和服务的实现都直接在节点之间进行，无需中间环节或中心化的服务器(第三方)介入。
在本申请实施例中，区块链网络中具有共识权限的节点即为共识节点，在实用拜占庭容错算法中，共识节点可包括主节点(具有出块权限)以及备份节点，共识节点的总数量为3f+1个，其中，备份节点的总数量为3f个，f为正整数，且f表示非法备份节点的最大数量。
5、非对称签名：签名算法包括两个密钥，公开密钥(简称公钥，public key)和私有密钥(简称私钥，private key)。公钥与私钥是一对，如果用私钥对数据进行签名，只有用对应的公钥才能验签。因为签名过程和验签过程分别使用两个不同的密钥，所以这种算法称作非对称签名。非对称签名实现机密信息交换的基本过程可以是：甲方生成一对密钥并将公钥公开，甲方需要向其他角色(乙方)发送消息时，使用自己的私钥对机密消息进行签名后再发送给乙方；乙方再用甲方的公钥对签名后的消息进行验签。
请参见图1，图1是本申请实施例提供的一种系统架构示意图。如图1所示，该系 统架构可以包括终端设备集群100以及区块链网络，终端设备集群100可以包括终端设备100a、终端设备100b、终端设备100c以及终端设备100n。可以理解的是，本申请实施例不对终端设备集群100中的终端设备的数量进行限制，可以包括一个或多个终端设备。
区块链网络可以包括具有共识权限的区块链节点集群10，区块链节点集群10可以包括区块链节点10A、区块链节点10B、区块链节点10C以及区块链节点10N。同理，不对区块链节点集群10中的区块链节点的数量进行限制，可以包括四个或四个以上区块链节点。其中，区块链节点集群10中的区块链节点，包括本申请实施例中的1个主节点(例如区块链节点10A)，以及3f个备份节点(例如区块链节点10B、区块链节点10C以及区块链节点10N)。
其中，终端设备集群100中的终端设备之间可以存在通信连接，例如终端设备100c与终端设备100a之间存在通信连接。其中，区块链节点集群10中的区块链节点之间可以存在通信连接，例如区块链节点10A与区块链节点10C之间存在通信连接，区块链节点10A与区块链节点10N之间存在通信连接。其中，区块链节点集群10中的任一区块链节点可以与终端设备集群100中的任一终端设备存在通信连接，例如区块链节点10A与终端设备100b之间存在通信连接，区块链节点10N与终端设备100n之间存在通信连接，区块链节点10C与终端设备100a之间存在通信连接，区块链节点10A与终端设备100c之间存在通信连接。其中，上述的通信连接不限定连接方式，可以通过有线通信方式进行直接或间接地连接，也可以通过无线通信方式进行直接或间接地连接，还可以通过其他方式，本申请在此不做限制。
可以理解的是，区块链节点之间可以通过上述通信连接进行数据或者区块传输。上述区块链节点之间的通信连接可以基于节点标识，对于区块链网络中的每个区块链节点，均具有与其对应的节点标识，而且上述每个区块链节点均可以存储与自身有相连关系的其他区块链节点的节点标识，以便后续根据其他区块链节点的节点标识，将获取到的数据或生成的区块广播至其他区块链节点，例如区块链节点10A可以维护一个节点标识列表，该节点标识列表保存着其他区块链节点的节点名称和节点标识，如表1所示。
表1

其中，节点标识可为网络之间互联的协议(Internet Protocol，IP)地址以及其他任意一种能够用于标识区块链网络中区块链节点的信息。
假设区块链节点10A的节点标识为FFFFFF，则区块链节点10A可以通过节点标识CCCCC，向区块链节点10N发送预准备消息，且区块链节点10N通过节点标识FFFFFF，可以确定该预准备消息是区块链节点10A所发送的；同理，区块链节点10N可以通过节点标识BBBBBB，向区块链节点10C发送准备消息，且区块链节点10C通过节点标识CCCCCC，可以知道该准备消息是区块链节点10N所发送的，其他节点之间的数据传输亦如此，故不再一一进行赘述。
区块链节点集群10中每个区块链节点在进行正常工作时，可以接收到终端设备中的客户端发送的请求消息，并基于接收到的请求消息生成区块，然后进行区块上链处理。可以理解的是，在本申请的具体实施方式中，涉及到用户信息(例如请求消息以及响应结果)等相关的数据，当本申请实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。
应当理解，如图1所示的终端设备集群100中的每个终端设备均可以安装有客户端，当该客户端运行于各终端设备中时，可以分别与上述图1所示的区块链节点集群10进行数据交互，即上述的通信连接。其中，该客户端可以为视频应用、社交应用、即时通信应用、办公软件应用、导航应用、购物应用、金融理财应用、商务应用、浏览器等具有发送请求消息功能的应用客户端。其中，该客户端可以为独立的客户端，也可以为集成在某客户端(例如，社交客户端、教育客户端以及多媒体客户端等)中的嵌入式子客户端，在此不做限定。
可以理解的是，图1中的区块链节点包括但不限于移动终端或服务器。上述服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，简称CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。上述移动终端包括但不限于手机、电脑、智能语音交互设备、智能家电、车载终端、飞行器等。其中，移动终端和服务器可以通过有线或无线方式进行直接或间接地连接，本申请实施例对此不做限制。
进一步地，请参见图2，图2是本申请实施例提供的一种基于区块链的数据处理方法的流程示意图。该基于区块链的数据处理方法可以由区块链网络中具有共识权限的主节点执行。如图2所示，该基于区块链的数据处理方法至少可以包括以下步骤S101-步骤S104。
步骤S101，响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1；n为正整数；
具体的，本申请实施例所涉及的数据处理方法可以用来改进共识算法(例如，PBFT算法)，以降低共识时的网络复杂度。PBFT算法意为实用拜占庭容错算法，是一种可容忍一定拜占庭错误的分布式一致性算法。该PBFT算法可以在少数节点作恶(如伪造消息)场景中达成共识，它采用签名、签名验证、哈希等密码学算法确保消息传递过程中的防篡改性、防伪造性、不可抵赖性，并优化了前人工作，将拜占庭容错算法复杂度从指数级降低到多项式级别。
在本申请实施例中，具有共识权限的节点的总数量可以为(3f+1)的正整数，这里的f可以用于指示该区块链网络中的非法节点的最大数量。这里的非法节点可能会不传输消息，或者传输不一致的消息以试图扰乱其他节点。该PBFT算法不依赖于不切实际的假设，可以允许非法节点(即恶意节点)延迟合法节点(即非恶意节点)间的网络传输，在非法节点少于所述总数量的1/3的情况下能够提供安全性和活动性。例如，当有不少于(2f+1)个合法节点正常工作时，该区块链网络中的节点可以达成一致性。例如：7个节点的区块链系统中可以允许存在的非法节点的最大数量为2。
其中，PBFT算法可以使用视图(view)来记录每个节点的共识状态，在相同视图(即同一视图号)下，区块链网络中的所有节点均可以维护相同的节点列表。该节点列表可以包括主节点和备份节点。当主节点出现故障时，会发生视图切换，每次视图切换会更改主节点，且视图的编号是连续的。若视图切换成功，则该PBFT算法可以根据新的视图确定出新的主节点。其中，本申请实施例可以将用于对请求消息进行打包出块的节点称之为该区块链网络中的主节点。本申请实施例可以将该区块链网络中除主节点之外的具有共识权限的节点称之为备份节点。
请一并参见图3，图3是本申请实施例提供的一种基于区块链的数据处理的场景示意图一。如图3所示，终端设备30a安装有客户端，本申请实施例不对客户端的具体业务进行限定，可以根据实际应用场景进行设定；故本申请实施例不对由客户端发起的第二请求消息的具体内容进行限定，应当根据客户端的具体业务进行设定，包括但不限于 电子发票的开具以及红冲、数字资产的生成、转移、上链等。
其中，终端设备30a所安装的客户端可以直接将第二请求消息发送至主节点30b，也可以将第二请求消息发送至备份节点，然后备份节点将第二请求消息转发至主节点30b。接收到第二请求消息后，主节点先对第二请求消息进行校验，本申请实施例暂不对第二请求消息的校验展开描述，请参见下文图7所对应的实施例中步骤S201的描述。可以理解的是，第二请求消息的总数量可以为一个或多个，本申请实施例不对第二请求消息的总数量进行限定。若第二请求消息的总数量为多个时，例如第二请求消息1、第二请求消息2、…、第二请求消息4，则第二请求消息1、第二请求消息2、…、第二请求消息4可以是由一个客户端发送的，即终端设备30a的总数量为一个。在一些实施例中，第二请求消息1、第二请求消息2、…、第二请求消息4可以由不同的客户端分别发送的，即终端设备30a的总数量可以为多个。
在区块链网络中，本申请实施例中所涉及的请求消息(包括第一请求消息以及第二请求消息)均可以理解为业务交易，故在第二请求消息通过校验时，主节点30b可以将第二请求消息添加至交易缓存池中。请再参见图3，响应于序列号为n的第一请求消息具有第一准备证书301c，主节点30b可以为第二请求消息分配序列号n+1。其中，第一准备证书301c可以包括针对第一请求消息的1个预准备消息1，以及2f个准备消息1。可以理解的是，预准备消息1的处理过程(例如生成过程、广播过程、校验过程等)，与第二请求消息对应的预准备消息(如图3所示例的预准备消息30g)的处理过程相同；2f个准备消息1的处理过程(例如生成过程、广播过程、校验过程等)，与第二请求消息对应的准备消息的处理过程相同；故此处不对预准备消息1的处理过程以及2f个准备消息1的处理过程进行描述，请参见下文步骤S102中预准备消息30g的处理过程以及第二请求消息对应的准备消息的处理过程。
步骤S102，响应于第二请求消息具有第二准备证书，将第一请求消息以及第一请求消息对应的第一响应结果关联存储到账本文件。
具体的，根据序列号n+1以及第二请求消息，生成预准备消息；将预准备消息广播至区块链网络中具有共识权限的备份节点，以使各备份节点对预准备消息进行校验，得到第一校验结果；第一校验结果用于指示该备份节点在第一校验结果为通过时，生成第二请求消息对应的准备消息；获取各备份节点返回的准备消息，根据获取的准备消息，生成第二请求消息对应的第二准备证书。
其中，根据序列号n+1以及第二请求消息，生成预准备消息的具体过程可以包括： 对第二请求消息进行打包处理，得到待验证区块，将待验证区块的区块哈希值确定为待验证区块的区块摘要；生成待验证区块对应的预准备标识，将预准备标识、区块链网络的第一视图号、序列号n+1以及区块摘要，确定为待签名预准备信息；通过主节点私钥，对待签名预准备进行签名，得到第三签名信息；生成携带第三签名信息以及待验证区块的预准备消息。
其中，准备消息中携带第四签名信息和待签名准备信息，该第四签名信息是生成该准备消息的备份节点通过备份节点私钥对待签名准备信息进行签名所生成的；根据获取的准备消息，生成第二请求消息对应的第二准备证书的具体过程可以包括：针对获取的每一准备消息，通过生成该准备消息的备份节点对应的备份节点公钥，对该准备消息携带的第四签名信息进行验签，得到第四签名信息对应的验签结果；若第四签名信息对应的验签结果为成功，则该准备消息携带的待签名准备信息进行校验处理，得到第二校验结果；若第二校验结果为通过，则将该准备消息添加至日志数据库；若日志数据库中包括2f个备份节点分别对应的准备消息，则将预准备消息以及2f个准备消息，组合成第二请求消息对应的第二准备证书；其中，f为正整数，且f用于表征非法备份节点的最大数量；3f用于表征区块链网络中具有共识权限的备份节点的总数量；非法备份节点以及2f个备份节点均属于3f个备份节点。
PBFT算法是一种状态机复制算法，通过三阶段协议达成共识，本申请实施例沿用PBFT算法中的预准备阶段以及准备阶段，去除提交阶段，即本申请实施例在准备阶段中完成对请求消息的请求操作。请再参见图3，主节点30b对第二请求消息进行打包处理，得到待验证区块30d，其中，序列号n+1可以理解为待验证区块30d的区块高度。主节点30b确定待验证区块30d的区块哈希值，将区块哈希值确定为待验证区块30d的区块摘要301d。进一步，主节点30b生成待验证区块30d对应的预准备标识，将预准备标识、区块链网络的第一视图号、序列号n+1以及区块摘要301d，确定为待签名预准备信息301e。进一步，主节点30b通过主节点私钥301f，对待签名预准备信息301e进行签名，得到第三签名信息302e。进一步，主节点30b生成携带第三签名信息302e以及待验证区块30d的预准备消息30g。进一步，主节点30b将预准备消息30g存储到主节点30b的日志数据库。
预准备消息30g可以表示为预准备消息其中，PRE-PREPARE表示预准备标识，v表示第一视图号，m表示待验证区块30d，d表示区块摘要301d，表示第三签名信息302e。
进一步，主节点30b将预准备消息30g广播至3f个备份节点，以使3f个备份节点分别对预准备消息30g进行校验。可以理解的是，3f个备份节点中可以存在非法备份节点，该非法备份节点可能不对预准备消息30g进行校验，进一步，不会生成第二请求消息对应的准备消息，故该非法备份节点不会返回第二请求消息对应的准备消息至主节点30b。在一些实施例中，非法备份节点对预准备消息30g进行校验，但会生成一个错误的准备消息，以扰乱主节点30b对第二请求消息的后续处理。
3f个备份节点中存在至少2f个合法备份节点，2f个合法备份节点对预准备消息30g分别进行校验处理的过程是相同的，且分别生成第二请求消息对应的准备消息的过程也是相同的，故下文以一个合法备份节点示例进行描述，其它合法备份节点的处理过程参见下文的描述。
请结合图3以及图4，图4是本申请实施例提供的一种基于区块链的数据处理的另一场景示意图。如图4所示，备份节点30h为至少2f个合法备份节点中的任意一个合法备份节点。备份节点30h获取到主节点30b发送的预准备消息30g，备份节点30h首先检验预准备消息30g的合法性，故通过主节点30b对应的主节点公钥302f，对预准备消息30g所携带的第三签名信息302e进行验签，得到第一验签结果。若第一验签结果为成功，则备份节点30h确定预准备消息30g是主节点30b发送的，若第一验签结果为失败，则确定预准备消息30g不是主节点30b发送的。在第一验签结果为成功时，备份节点30h对待签名信息301e进行校验处理，具体可以为校验第一视图号是否与自身的视图号相同，校验序列号n+1是否已存在，校验区块摘要301d是否与自身生成的待验证区块30d的区块哈希相同，若第一视图号与备份节点30h自身的视图号相同，且序列号n+1不存在，且区块摘要301d与自身生成的区块哈希相同，则备份节点30h确定第一校验结果为通过。进一步，备份节点30h获取针对待验证区块30d的准备标识，以及自己的备份节点标识，将准备标识、备份节点标识、序列号n+1、第一视图号以及区块摘要301d，确定为待签名准备信息。备份节点30h通过自己的备份节点私钥30i，对待签名准备信息进行签名，得到第四签名信息30j，生成携带第四签名信息30j和待签名准备信息的准备消息，将该准备消息广播至主节点30b，以及剩余的备份节点，即除了备份节点30h之外的3f-1个备份节点；同时，备份节点30h将该准备消息添加至自己的日志数据库，可以理解的是，每个节点具有自己对应的日志数据库。
携带第四签名信息30j和待签名准备信息的准备消息可以表示为准备消息其中，PREPARE表示准备标识，i 表示备份节点30h的备份节点标识，表示第四签名信息30j。
可以理解的是，备份节点30h也会获取其它的备份节点发送的准备消息，且备份节点30h的后续处理过程，与主节点30b的后续处理过程相同，实际上，是每一个合法备份节点的后续过程，均与主节点30b的后续过程相同。故下文以主节点30b示例进行描述，至少2f个合法备份节点的后续处理请参见下文的描述。
主节点30b获取到备份节点30h发送的携带第四签名信息30j和待签名准备信息的准备消息后，首先检验该准备消息的合法性，故通过备份节点30h对应的备份节点公钥，对第四签名信息30j进行验签，得到第四签名信息30j对应的验签结果(简称为第二验签结果)。若第二验签结果为成功，则主节点30b确定该准备消息是备份节点30h发送的，若第二验签结果为失败，则确定该准备消息不是备份节点30h发送的。在第二验签结果为成功时，主节点30b对备份节点30h发送的准备消息进行校验，具体可以为校验该准备消息中的视图号是否与自身的视图号(即第一视图号)相同，校验该准备消息中的序列化是否与自身的序列化(即序列号n+1)相同，校验该准备消息中的区块摘要是否与自身的区块摘要(即区块摘要301d)相同。可以理解的是，在备份节点30h为合法备份节点的条件下，主节点30b对该准备消息的校验结果(即第二校验结果)为第二校验通过结果。此时，主节点30b将备份节点30h发送的准备消息添加至自己的日志数据库。
可以理解的是，主节点30b可以获取到其它合法备份节点发送的准备消息，且对其它合法备份节点发送的准备消息的处理过程，与对备份节点30h发送的准备消息的处理过程相同，故此处不再一一进行赘述。若主节点30b的日志数据库中包括2f个备份节点分别对应的准备消息，则主节点30b将自己生成的预准备消息30g以及2f个准备消息，组合成第二请求消息对应的第二准备证书。
步骤S103，在关联存储第一请求消息以及第一响应结果到账本文件的同时，并行执行第二请求消息对应的请求操作，得到第二请求消息对应的第二响应结果，将第二响应结果存储缓存文件。
在第二请求消息具有第二准备证书时，主节点可以确定第二请求消息已准备，此时，主节点略过提交阶段，并行执行以下三件事务：1、为第三请求消息分配序列号n+2；2、执行第二请求消息对应的请求操作，得到第二请求消息对应的第二响应结果；3、将第一请求消息以及第一响应结果进行关联存储。其中，第一响应结果的生成，是在第一请求消息具有第一准备证书的条件下，即与主节点为第二请求消息分配序列号n+1是同步 执行的。其中，主节点执行第二请求消息对应的请求操作，得到第二请求消息对应的第二响应结果的过程，可以理解为主节点“预执行”第二请求消息，因为此时的第二响应结果以及第二请求消息并未持久化存储(即未写入)到账本文件，而是保存在缓存文件中，此时，第二请求消息的请求状态变更为请求响应状态。当第三请求消息具有第三准备证书时，主节点将第二请求消息以及第二响应结果关联存储于账本文件，即持久化存储(即写入账本)，该过程可以理解为主节点“最终执行”第二请求消息，此时，第二请求消息的请求状态变更为请求写入状态。
步骤S104，将根据第二响应结果所生成的第一初始响应消息返回至客户端，以使客户端根据第一初始响应消息和区块链网络中具有共识权限的备份节点分别返回的备份初始响应信息，确定第二请求消息对应的请求执行结果。
具体的，根据第二响应结果生成针对第二请求消息的初始响应标识；将初始响应标识、区块链网络的第一视图号、第二请求消息对应的请求时间戳、客户端对应的客户端标识、主节点标识，以及第二响应结果，确定为待签名初始响应信息；通过主节点私钥，对待签名初始响应消息进行签名，得到第二签名信息；生成携带第二签名信息和待签名初始响应信息的第一初始响应消息，将第一初始响应信息发送至客户端，第二签名信息用于指示客户端确定第一初始响应消息的合法性。
本申请实施例在未对第二请求消息以及第二响应结果进行持久化存储之前，就将第二响应结果返回至发起第二请求消息的客户端。请一并参见图5，图5是本申请实施例提供的一种基于区块链的数据处理的又一场景示意图。如图5所示，生成第二响应结果后，主节点30b生成针对第二请求消息的初始响应标识，进一步，将初始响应标识、区块链网络的第一视图号、第二请求消息对应的请求时间戳、客户端对应的客户端标识、主节点标识，以及第二响应结果，确定为待签名初始响应信息。通过主节点私钥301f，主节点30b对待签名初始响应信息进行签名，得到第二签名信息30k，将携带第二签名信息30k和待签名初始响应信息的第一初始响应消息发送至安装有客户端的终端设备30a，其中，第二签名信息30k用于指示客户端确定第一初始响应消息的合法性。
携带第二签名信息30k和待签名初始响应信息的第一初始响应消息可以表示为第一初始响应消息其中，PRE-REPLY表示初始响应标识，t表示请求时间戳，c表示客户端标识，i表示主节点标识，r表示第二响应结果，表示第二签名信息30k。
同时，客户端还会接收到备份节点发送的初始响应消息，为了区别与第一初始响应 消息，将备份节点发送的初始响应消息称为备份初始响应消息。可以理解的是，合法备份节点生成备份初始响应消息的过程，与主节点30b生成第一初始响应消息的过程相同。后续，客户端根据第一初始响应消息以及备份初始响应信息，确定第二请求消息对应的第一请求执行结果，该过程的具体实现方式，请参见下文图7所对应的实施例中的描述，此处暂不展开描述。
综上所述，本申请实施例提出一种可减少延迟的PBFT算法改进方案，可去除提交阶段，减少客户端的响应延迟，同时由于减少了每次共识的网络交互次数，整体上提高了PBFT的性能。本方案的流程可以一并参见图6，图6是本申请实施例提供的一种基于区块链的数据处理方法的流程示意图。图6示例f等于1，故备份节点的总数量为3，3个备份节点分别为节点1、节点2以及节点3。其中，图6示例节点3为非法备份节点，即恶意节点，主节点、节点1以及节点2均为合法节点。首先主节点接收由客户端发起的第二请求消息(图6简写为请求)，主节点通过两阶段协议将第二请求消息请求广播给备份节点，具体如下。
预准备阶段：主节点判断是否已经有序列号n的第一请求消息的第一准备证书，若具有第一准备证书，则分配序列号n+1给第二请求消息。主节点广播一条预准备消息给所有的备份节点，如图6中所示例的节点1、节点2以及节点3。
准备阶段：节点1收到主节点发送的预准备消息后，对预准备消息进行校验，校验通过后接受该预准备消息并将该预准备消息写入日志数据库，并进入准备阶段。此时，节点1广播一条准备消息给所有的节点，即主节点、节点2以及节点3，并将自己生成的准备消息写入自己的日志数据库。后续，节点1也会收到节点2发送的准备消息 且在校验成功后将该准备消息写入自己的日志数据库。当节点1的日志数据库中存在第二请求消息对应的1条预准备消息以及2条(因为f＝1)准备消息时，节点1可以确定第二请求消息已准备好，故将预准备消息以及2条准备消息组成为第二请求消息的第二准备证书。进一步，节点1可以“预执行”第二请求消息，即生成第二请求消息的第二响应结果，并向客户端发送备份初始响应消息同时，节点1可以“最终执行”第一请求消息，即将第一请求消息以及第一响应结果进行持久化存储，即写入节点1的账本文件。可以理解的是，上述是以节点1示例描述准备阶段，节点2在准备阶段的处 理过程，与节点1相同，故不进行赘述。
请参见图7，图7是本申请实施例提供的一种基于区块链的数据处理方法的另一流程示意图。该基于区块链的数据处理方法可以由区块链网络中具有共识权限的主节点执行。如图7所示，该方法至少可以包括以下步骤。
步骤S201，获取第二请求消息，确定第二请求消息的请求状态；第二请求消息由客户端发起。
具体的，确定第二请求消息对应的请求哈希，将请求哈希与缓存文件中的缓存请求哈希进行对比；缓存文件中的缓存请求哈希所对应的请求消息为已被执行请求操作的请求消息；若缓存文件中存在与请求哈希相同的缓存请求哈希，则确定第二请求消息的请求状态为请求响应状态；若缓存文件中不存在与请求哈希相同的缓存请求哈希，则将请求哈希与账本文本中的写入请求哈希进行对比；账本文件中的写入请求哈希所对应的请求消息为已被存储的请求消息；若账本文件中存在与请求哈希相同的写入请求哈希，则确定第二请求消息的请求状态为请求写入状态；若账本文件中不存在与请求哈希相同的写入请求哈希，则确定第二请求消息的请求状态为请求初始状态。
其中，主节点响应于执行第二请求消息的请求操作得到第二响应结果，将第二请求消息的请求哈希作为缓存请求哈希存储到缓存文件中；主节点响应于将第二请求消息以及第二响应结果关联存储到账本文件，将第二请求消息的请求哈希作为写入请求哈希存储到账本文件。
主节点接收由客户端发起的第二请求消息其中，o为第二请求消息的请求操作，t为请求时间戳，可以理解为发起第二请求消息的时间戳，c为客户端标识，σc为客户端对第二请求消息的签名。
同理，主节点首先通过签名σc检验第二请求消息的合法性。若第二请求消息为合法请求消息，则生成第二请求消息对应的请求哈希，然后通过请求哈希确定第二请求消息的请求状态。可以理解的，主节点获取到每一条请求消息，都需要先确定其请求状态，然后根据请求消息对应的请求状态，确定该请求消息的响应结果。本申请实施例以第二请求消息示例描述，主节点可以先将第二请求消息对应的请求哈希，与主节点的缓存文件中的缓存请求哈希进行对比，若缓存文件中存在与请求哈希相同的缓存请求哈希，则可以确定第二请求消息的请求状态为请求响应状态，进而主节点可以确定第二请求消息已被执行，其对应的响应结果为存储在缓存文件中第二响应结果，但未写入主节点的账本文件。若主节点的缓存文件中不存在与请求哈希相同的缓存请求哈希，则主节点将请 求哈希与主节点的账本文件中的写入请求哈希进行对比，若账本文件中存在与请求哈希相同的写入请求哈希，则可以确定第二请求消息的请求状态为请求写入状态，进而主节点可以确定第二请求消息已被执行，其对应的响应结果为已写入主节点的账本文件的第二响应结果。若主节点的账本文件中不存在与请求哈希相同的写入请求哈希，则主节点可以确定第二请求消息的请求状态为请求初始状态。
可以理解的是，主节点也可以先将第二请求消息的请求哈希与主节点的账本文件中的写入请求哈希进行对比，若账本文件中不存在与请求哈希相同的写入请求哈希，再将第二请求消息的请求哈希与主节点的缓存文件中的响应请求哈希进行对比。在一些实施例中，主节点可以将第二请求消息的请求哈希与主节点的账本文件中的写入请求哈希进行对比同时，还将第二请求消息的请求哈希与主节点的缓存文件中的响应请求哈希进行对比。
步骤S202，若请求状态为请求响应状态，则在缓存文件中获取第二请求消息对应的第二响应结果，将根据第二响应结果所生成的第二初始响应消息返回至客户端，以使客户端根据第二初始响应消息和各备份节点分别返回的备份初始响应消息，确定第二请求消息对应的第二请求执行结果；请求响应状态用于指示区块链网络中存在第二请求消息，且已执行第二请求消息对应的请求操作。
具体的，若请求状态为请求响应状态，则主节点可以确定第二请求消息为客户端重复发送的，且客户端先前未通过第二请求消息的第一请求执行结果。由于主节点仍然未写入第而响应结果以及第二请求消息到账本文件，故本步骤的具体实现方式，与第二请求消息的请求状态为请求初始状态的具体实现方式相同，即根据第二响应结果返回一个初始响应消息(即第二初始响应消息，主要强调与第一初始响应消息的生成时间不相同)至客户端，第二初始响应消息的生成过程，与上文图2所对应的实施例中步骤S104中的第一初始响应消息的生成过程相同，两者的区别在于生成时间不相同，第一初始响应消息是发生在请求状态为请求初始状态的场景下，第二初始响应消息是发生在请求状态为请求响应状态的场景下。
步骤S203，若请求状态为请求写入状态，则在账本文件中获取第二请求消息对应的第二响应结果，将根据第二响应结果所生成的完成响应消息返回至客户端，以使客户端根据完成响应消息和各备份节点分别返回的备份完成响应消息，确定第二请求消息对应的第三请求执行结果；请求写入状态用于指示区块链网络中存在第二请求消息，且已关联存储第二请求消息以及第二响应结果。
具体的，根据第二响应结果生成针对第二请求消息的完成响应标识；将完成响应标识、区块链网络的第一视图号、第二请求消息对应的请求时间戳、客户端对应的客户端标识、主节点标识，以及第二响应结果，确定为待签名完成响应信息；通过主节点私钥，对待签名完成响应信息进行签名，得到第一签名信息；生成携带第一签名信息和待签名完成响应信息的完成响应消息发送至客户端；第一签名信息用于指示客户端确定完成响应消息的合法性。
具体的，若请求状态为请求写入状态，则主节点可以确定第二请求消息为客户端重复发送的，且客户端先前未通过第二请求消息的请求执行结果。由于主节点已写入第二响应结果以及第二请求消息，故根据第二响应结果生成针对第二请求消息的完成响应标识；后续过程，与主节点生成初始响应消息的过程相似，主节点首先将完成响应标识、区块链网络的第一视图号、第二请求消息对应的请求时间戳、客户端对应的客户端标识、主节点标识，以及第二响应结果，确定为待签名完成响应信息；进一步，通过主节点私钥，主节点对待签名完成响应信息进行签名，得到第一签名信息，然后将携带第一签名信息和待签名完成相应信息的完成响应消息发送至客户端。
携带第一签名信息和待签名完成相应信息的完成响应消息可以表示为完成响应消息其中，REPLY表示完成响应标识，表示第一签名信息。
同时，客户端还会接收到备份节点发送的完成响应消息，为了区别与主节点发送的完成响应消息，将备份节点发送的完成响应消息称为备份完成响应消息。可以理解的是，合法备份节点生成备份完成响应消息的过程，与主节点生成完成响应消息的过程相同。
需要强调的是，客户端根据第一初始响应消息和备份初始响应消息确定第二请求消息的第一请求执行结果的具体方式，与客户端根据第二初始响应消息和备份初始响应消息确定第二请求消息的第二请求执行结果的具体方式相同，但客户端根据第二初始响应消息和备份初始响应消息确定第二请求消息的第二请求执行结果的具体方式，与客户端根据完成响应消息和备份完成响应消息确定第二请求消息的第三请求执行结果的具体方式不相同，具体请参见下文图8以及图9所分别对应的实施例中的描述。
步骤S204，若请求状态为请求初始状态，则响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1；请求初始状态用于指示区块链网络中不存在第二请求消息；n为正整数。
步骤S205，响应于第二请求消息具有第二准备证书，将第一请求消息以及第一请 求消息对应的第一响应结果关联存储到账本文件。
步骤S206，在关联存储第一请求消息以及第一响应结果到账本文件的同时，并行执行第二请求消息对应的请求操作，得到第二请求消息对应的第二响应结果，将第二响应结果存储到缓存文件。
步骤S207，将根据第二响应结果所生成的第一初始响应消息返回至客户端，以使客户端根据第一初始响应消息和区块链网络中具有共识权限的备份节点分别返回的备份初始响应消息，确定第二请求消息对应的第一请求执行结果。
其中，步骤S204-步骤S207的具体实现过程，请参见上文图2所对应的实施例中的步骤S101-步骤S104，此处不进行赘述。
下文描述本方案的可行性，下文所述的节点均为具有共识权限的节点。此处只需要证明，情况1：客户端已收到针对第二请求消息的2f+1个候选初始响应，或，情况2：客户端已收到针对第二请求消息的f+1个候选完成响应，最终第二请求消息一定会被所有正确节点按照相同顺序执行。也就是，即使发生视图切换，导致部分节点没有执行第二请求消息，第二请求消息也会被新的主节点收集，并使用与原第二请求消息相同的序列号，重新进入共识，使得能被所有节点执行，这个过程可以称作“请求重放”。在视图切换时，新主节点收集“待重放请求”的方式如下：收集来自2f+1个不同节点的准备证书，其中，收集的准备证书所对应的序列号，大于新主节点的“稳定检查点”的最近请求的序列号。新主节点将收集到的所有准备证书对应的请求消息均进行“重放”。其中，稳定检查点是指在PBFT算法中，正确节点已经达成一致共识的某个状态，这个状态由执行z个请求消息得到。
在开始证明之前，先说明PBFT算法的QC性质，这是证明PBFT算法正确性的重要前提。QC性质中的Q和C分别表示Quorum和Certificate。Quorum意为仲裁数，法定人数。在PBFT算法中，当总节点数为3f+1时，Quorum表示数量不少于2f+1的节点集合。Quorum certificate表示来自一个Quorum的每个节点的某种消息组成的一个集合，称为证书，如准备证书。
Quorum有两个重要的性质：
(性质1)相交性:任何两个Quorum至少有一个共同的正确节点。
(性质2)可得性:总能找到一个没有非法节点的Quorum。
情况1(大部分情况下)：对于客户端在第二请求消息的第一请求处理周期内，收到第二请求消息对应的2f+1个相同的候选初始响应的情况。此时说明有2f+1个节点 有第二请求消息的准备证书，如果此时主节点也有第二请求消息的准备证书，那么主节点可以发送序列号为n+1的预准备消息，其他至少有2f个节点可以发送序列号n+1的准备消息，所以序列号为n+1的第二请求消息，可以被某个节点“预执行”，即执行其对应的请求操作，故第二请求消息可以被某个节点最终执行，即将第二请求消息以及其对应的响应结果进行关联存储。另外，当视图切换时，新主节点收集2f+1个节点的准备证书，根据Quorum的性质1，这两个Quorum至少有一个共同的正确节点(即合法节点)，故第二请求消息的准备证书一定会被新主节点收集到，从而一定会被“重放”。
情况2：对于客户端在第二请求消息的第二请求处理周期内，收到第二请求消息对应的f+1个相同的候选完成响应的情况。这说明至少有一个正确节点“最终执行”了第二请求消息，只需证明已存储的第二请求消息一定会被“重放”。根据准备阶段，对于某个节点，若第二请求消息已被存储，则序列号为n+2的第三请求消息具有第三准备证书，即该节点已经收到了序列号为n+2的第三请求消息的1个预准备消息3和2f个准备消息3，而节点只有在已经有序列号n+1的第二请求消息的第二准备证书时，才会发送序列号n+2的预准备消息3或准备消息3，所以有2f+1个节点有序列号为n+1的第二请求消息的第二准备证书，至此，后续证明见情况1。
请参见图8，图8是本申请实施例提供的一种基于区块链的数据处理方法的另一流程示意图。该基于区块链的数据处理方法可以由客户端执行。如图8所示，该方法至少可以包括以下步骤。
步骤S301，将第二请求消息发送至区块链网络中具有共识权限的节点，以使具有共识权限的节点中的主节点：响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1；n为正整数；响应于第二请求消息具有第二准备证书；将第一请求消息以及第一请求消息对应的第一响应结果关联存储到账本文件，且在关联存储第一请求消息以及第一响应结果到账本文件的同时，并行执行第二请求消息对应的请求操作，得到第二请求消息对应的第二响应结果，将第二响应结果存储到缓存文件；根据第二响应结果生成针对第二请求消息的第一初始响应消息。
其中，步骤S301的具体实现过程，请参见上文图2所对应的实施例中的步骤S101-步骤S104，以及上文图7所对应的实施例中步骤S201，此处不进行赘述。
步骤S302，获取主节点返回的第一初始响应消息，根据第一初始响应消息和区块链网络中具有共识权限的备份节点分别返回的备份初始响应消息，确定第二请求消息对应的第一请求执行结果。
若客户端首次发起第二请求消息至区块链网络，则区块链网络中的主节点以及至少2f个合法备份节点可以分别将自己生成的初始响应消息(包括上述的第一初始响应消息以及备份响应初始消息)，返回至客户端。可以理解的是，客户端对第一初始响应消息的处理过程，与对每个备份响应初始消息的处理过程是相同的，故本步骤以客户端对第一初始响应消息进行处理示例进行描述。
具体的，第一初始响应消息携带第二签名信息和待签名初始响应信息；第二签名信息是主节点通过主节点私钥，对待签名初始响应信息进行签名处理所得到的；待签名初始响应消息包括初始响应标识、区块链网络的第一视图号、第二请求消息对应的请求时间戳、客户端标识、主节点对应的主节点标识，以及第二响应结果；通过主节点私钥对应的主节点公钥，对第二签名信息进行验签，得到第二签名信息对应的验签结果；若第二签名信息对应的验签结果为成功，则将请求时间戳以及第二响应结果作为候选初始响应De，添加至初始响应标识对应的候选初始响应集合；候选初始响应集合包括G个候选初始响应；G个候选初始响应包括候选初始响应De；e为正整数，且e小于或等于3f+1；G为正整数，且G小于或等于3f+1；3f+1用于表征具有共识权限的节点的总数量；f用于表征具有共识权限的节点中非法备份节点的最大数量；根据候选初始响应集合，确定第二请求消息对应的第一请求执行结果。
其中，根据候选初始响应集合，确定第二请求消息对应的第一请求执行结果的具体过程可以包括：在第一请求处理周期内，若候选初始响应集合中存在2f+1个相同的候选初始响应，则确定第二请求消息对应的第一请求执行结果为成功；若候选初始响应集合中不存在2f+1个相同的候选初始响应，则确定第二请求消息对应的第一请求执行结果为失败。
在检验第一初始响应消息为合法消息时，客户端可以将第一初始响应消息中的请求时间戳以及第二响应结果作为一个候选初始响应，添加至候选初始响应集合。可以理解的是，候选初始响应集合可以包括G个候选初始响应，其中，一个候选初始响应对应一个节点(主节点或一个备份节点)的初始响应消息。若在第一请求处理周期内，候选初始响应集合存在2f+1个相同的候选初始响应，即存在2f+1个相同的请求时间戳，以及2f+1个相同的响应结果，则客户端可以确定第二请求消息的第一请求执行结果为成功。如果超过第一请求处理周期，候选初始响应集合不存在2f+1个相同的候选初始响应，则客户端可以确定第一请求执行结果为失败，此时，客户端重新发送第二请求消息至区块链网络，该场景的具体实施方式请参见下文图9所对应的实施例中的描述，此处暂不 展开描述。其中，第一请求处理周期可以理解为客户端确定区块链网络处理首次发送的请求消息的处理结果的等待周期。
请参见图9，图9是本申请实施例提供的一种基于区块链的数据处理方法的另一流程示意图。该基于区块链的数据处理方法可以由客户端执行。如图9所示，该方法至少可以包括以下步骤。
步骤S401，将第二请求消息发送至区块链网络中具有共识权限的节点，以使具有共识权限的节点中的主节点：响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1；n为正整数；响应于第二请求消息具有第二准备证书将第一请求消息以及第一请求消息对应的第一响应结果关联存储到账本文件，所述第一响应结果是响应于所述第一请求消息具有第一准备证书，通过执行所述第一请求消息对应的操作得到的；在关联存储第一请求消息以及第一响应结果到账本文件的同时，并行执行第二请求消息对应的请求操作，得到第二请求消息对应的第二响应结果，将第二响应结果存储到缓存文件；根据第二响应结果生成针对第二请求消息的第一初始响应消息。
步骤S402，获取主节点返回的第一初始响应消息，根据第一初始响应消息和区块链网络中具有共识权限的节点中的备份节点分别返回的备份初始响应消息，确定第二请求消息对应的第一请求执行结果。
其中，步骤S401-步骤S402的具体实现过程，请参见上文图8所对应的实施例中的步骤S301-步骤S302，此处不进行赘述。
步骤S403，若第一请求执行结果为失败，则根据第一请求处理周期，确定第二请求消息对应的更新时间戳。
可以理解的是，如果超过第一请求处理周期，客户端还没收到2f+1个相同的候选初始响应，则主节点在更新时间戳对应的时间点重发第二请求消息。其中，更新时间戳与请求时间戳的时间差为第一请求处理周期对应的时长。
步骤S404，在更新时间戳对应的时间点，将第二请求消息重新发送至3f+1个具有共识权限的节点，以使3f+1个具有共识权限的节点分别确定第二请求消息的请求状态并返回与所述请求状态对应的实际响应结果。
其中，节点Ji根据第二请求消息在节点Ji中的请求状态Hi确定第二请求消息对应的实际响应结果；并根据实际响应结果生成实际响应消息；i为正整数，且i小于或等于3f+1；请求状态Hi属于3f+1个请求状态；节点Ji属于3f+1个具有共识权限的节点中请求状态Hi所在的节点。
具体的，主节点获取到重复发送的第二请求消息，会将第二请求消息广播给所有节点，可以理解的是，主节点获取到重复发送的第二请求消息的处理过程，与合法备份节点获取到重复发送的第二请求消息的处理过程是相同的，故本申请实施例以主节点示例进行描述。主节点首先确定第二请求消息的请求状态，具体确定请求状态的过程，请参见上文图7所对应的实施例中步骤S201的描述。若请求状态为请求响应状态，则实际响应结果为存储在缓存文件中的第二响应结果，实际响应消息为第二初始响应消息。若请求状态为请求完成状态，则实际响应结果为存储在账本文件中的第二响应结果，实际响应消息为完成响应消息。若请求状态为请求初始状态，则实际响应结果为第二响应结果，实际响应消息为第一初始响应消息。接收首次发送的第二请求消息的主节点和接收重复发送的第二请求消息的主节点可以相同，也可能不同，比如两次第二请求消息发送之间，主节点可能因故障或其它原因发生切换，视图发生变化。
步骤S405，获取多个具有共识权限的节点分别返回的实际响应消息，根据实际响应消息，确定第二请求消息对应的请求更新执行结果。
所述请求更新执行结果，可以是根据主节点返回的第二初始响应消息和各备份节点返回的备份初始响应消息确定的第二请求消息的第二请求执行结果，也可以是根据主节点返回的完成响应消息和各备份节点返回的备份完成响应消息确定的第二请求消息的第三请求执行结果。
具体的，若实际响应消息包括完成响应标识，则将实际响应消息中的更新时间戳以及实际响应结果，确定为候选完成响应Ki；将候选完成响应Ki添加至完成响应标识对应的候选完成响应集合；候选完成响应集合包括L个候选完成响应；L个候选完成响应包括候选完成响应Ki；L为正整数，且L小于或等于3f+1；根据候选完成响应集合，确定第二请求消息对应的第三请求执行结果。
其中，根据候选完成响应集合，确定第二请求消息对应的第三请求执行结果的具体过程可以包括：在第二请求处理周期内，若候选完成响应集合中存在f+1个相同的候选完成响应，则确定第二请求消息对应的第三请求执行结果为成功；若候选完成响应集合中不存在f+1个相同的候选完成响应，则确定第二请求消息对应的第三请求执行结果为失败。
不同于首次发送第二请求消息至区块链网络，客户端只能获取第一初始响应消息以及备份初始响应消息，在重复发送第二请求消息至区块链网络的场景下，客户端可能获取主节点返回的第二初始响应消息，也可能获取主节点返回的完成响应消息；同理，客 户端可能获取备份节点返回的备份初始响应消息，也可能获取备份节点返回的备份完成响应消息。若获取的是第二初始响应消息以及备份初始响应消息，则客户端在第二请求处理周期内的处理过程，与在第一请求处理周期内的处理过程相同，即需要收集2f+1个相同的候选初始响应候选初始响应集合中包括在第一请求处理周期收集的候选初始响应和在第二请求处理周期收集的候选初始响应，且若在两个请求处理周期收集到同一节点的2个候选初始响应，则只保留一个候选初始响应，即不同候选初始响应对应不同节点。若获取的是完成响应消息以及备份完成响应消息，则客户端需要在第二请求处理周期内，收集f+1个相同的候选完成响应。
可以理解的是，客户端可能在获取到初始响应消息(例如第二初始响应消息)的同时，还获取到完成响应消息，此时，客户端可以生成初始响应标识对应的候选初始响应集合，以及完成响应标识对应的候选完成响应集合，在第二请求处理周期内，若两个集合中存在一个集合满足条件，例如候选初始响应集合存在2f+1相同的候选初始响应，则客户端就可以确定第二请求消息的第二请求执行结果为成功，或候选完成响应集合存在f+1相同的候选完成响应，则客户端就可以确定第二请求消息的第三请求执行结果为成功。若两个集合均不满足条件，则在超过第二请求处理周期时，客户端确定第二请求执行结果和第三请求执行结果为失败。在第二请求执行结果和第三请求执行结果为失败的场景下，客户端可以再次发送第二请求消息至区块链网络。
上述可知，本申请实施例对第二请求消息开始共识是在第一请求消息具有第一准备证书的情况下，即无需等待第一请求消息对应的请求操作的执行，故可以提高区块链网络的共识效率；此外，本申请实施例在第二请求消息具有第二准备证书时，略过对第二请求消息的提交阶段，不仅对第一请求消息以及第一响应结果进行关联存储，还执行第二请求消息对应的请求消息，明显地，本申请实施例是将第一请求消息的存储以及第二请求消息的执行并行执行，且去除了提交阶段，故可以减少客户端的响应延迟，同时由于减少了每次共识的网络交互次数，故进一步提高了区块链网络的共识效率；此外，本申请实施例在生成第二响应结果时，就将第一初始响应消息发送至客户端，故客户端无需等待第二响应结果的存储，就可以确定第二请求消息的请求执行结果，故可以提高客户端针对请求执行结果的确定效率。
进一步地，请参见图10，图10是本申请实施例提供的一种基于区块链的数据处理装置的结构示意图。该基于区块链的数据处理装置可以运行于区块链网络中具有共识权限的主节点，上述基于区块链的数据处理装置1可以用于执行本申请实施例提供的方法 中的相应步骤。如图10所示，该基于区块链的数据处理装置1可以包括：序号分配模块11、关联存储模块12、请求操作模块13以及第一返回模块14。
序号分配模块11，用于响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1；n为正整数；
关联存储模块12，用于响应于第二请求消息具有第二准备证书，将第一请求消息以及第一请求消息对应的第一响应结果关联存储到账本文件；
请求操作模块13，用于在关联存储第一请求消息以及第一响应结果到账本文件的同时，并行执行第二请求消息对应的请求操作，得到第二请求消息对应的第二响应结果，将第二响应结果存储到缓存文件；
第一返回模块14，用于将根据第二响应结果所生成的第一初始响应消息返回至发起第二请求消息的客户端，以使所述客户端根据第一初始响应消息和区块链网络中具有共识权限的备份节点分别返回的备份初始响应消息，确定第二请求消息对应的第一请求执行结果。
其中，序号分配模块11、关联存储模块12、请求操作模块13以及第一返回模块14的具体功能实现方式，可以参见上述图2对应实施例中的步骤S101-步骤S104，这里不再进行赘述。
再请参见图10，基于区块链的数据处理装置1还可以包括：状态确定模块15、第二返回模块16、第三返回模块17以及步骤执行模块18。
状态确定模块15，用于获取第二请求消息，确定第二请求消息的请求状态；
第二返回模块16，用于若请求状态为请求响应状态，则在缓存文件中获取第二请求消息对应的第二响应结果，将根据第二响应结果所生成的第二初始响应消息返回至客户端，以使客户端根据第二初始响应消息和区块链网络中具有共识权限的备份节点分别返回的备份初始响应消息，确定第二请求消息对应的第二请求执行结果；请求响应状态用于指示区块链网络中存在第二请求消息，且主节点已执行第二请求消息对应的请求操作得到第二响应结果并将第二响应结果存储到缓存文件；
第三返回模块17，用于若请求状态为请求写入状态，则在账本文件中获取第二请求消息对应的第二响应结果，将根据第二响应结果所生成的完成响应消息返回至客户端，以使客户端根据完成响应消息和区块链网络中具有共识权限的备份节点分别返回的备份初始响应消息，确定第二请求消息对应的第三请求执行结果；请求写入状态用于指示区块链网络中存在第二请求消息，且主节点已关联存储第二请求消息以及第二响应结果 到账本文件；
步骤执行模块18，用于若请求状态为请求初始状态，则执行响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1的步骤；请求初始状态用于指示区块链网络中不存在第二请求消息。
其中，状态确定模块15、第二返回模块16、第三返回模块17以及步骤执行模块18的具体功能实现方式，可以参见上述图7对应实施例中的步骤S201-步骤S204，这里不再进行赘述。
进一步地，请参见图11，图11是本申请实施例提供的一种基于区块链的数据处理装置的另一结构示意图。上述基于区块链的数据处理装置2可以运行于客户端，该装置可以用于执行本申请实施例提供的方法中的相应步骤。如图11所示，该基于区块链的数据处理装置2可以包括：第一发送模块21以及第一确定模块22。
第一发送模块21，用于将第二请求消息发送至区块链网络中具有共识权限的节点，以使具有共识权限的节点中的主节点：响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1；n为正整数；响应于第二请求消息具有第二准备证书，将第一请求消息以及第一请求消息对应的第一响应结果关联存储到账本文件；在关联存储第一请求消息以及第一响应结果到账本文件的同时，并行执行第二请求消息对应的请求操作，得到第二请求消息对应的第二响应结果，将第二响应结果存储到缓存文件；根据第二响应结果生成针对第二请求消息的第一初始响应消息；
第一确定模块22，用于获取主节点返回的第一初始响应消息，根据第一初始响应消息和区块链网络中具有共识权限的节点中的备份节点分别返回的备份初始响应消息，确定第二请求消息对应的请求执行结果。
其中，第一发送模块21以及第一确定模块22的具体功能实现方式可以参见上述图8对应实施例中的步骤S301-步骤S302，这里不再进行赘述。
再请参见图11，基于区块链的数据处理装置2还可以包括：第二确定模块23、第二发送模块24以及第三确定模块25。
第二确定模块23，用于若请求执行结果为失败，则根据第一请求处理周期，确定第二请求消息对应的更新时间戳；
第二发送模块24，用于在更新时间戳对应的时间点，将第二请求消息重新发送至3f+1个具有共识权限的节点，以使3f+1个具有共识权限的节点分别确定第二请求消息的请求状态；请求状态Hi用于指示节点Ji确定第二请求消息对应的实际响应结果；实 际响应结果用于指示节点Ji生成实际响应消息；i为正整数，且i小于或等于3f+1；请求状态Hi属于3f+1个请求状态；节点Ji属于3f+1个具有共识权限的节点中请求状态Hi所在的节点；
第三确定模块25，用于获取节点Ji返回的实际响应消息，根据实际响应消息，确定第二请求消息对应的请求执行结果。
其中，第二确定模块23、第二发送模块24以及第三确定模块25的具体功能实现方式可以参见上述图9对应实施例中的步骤S403-步骤S405，这里不再进行赘述。
进一步地，请参见图12，图12是本申请实施例提供的一种计算机设备的结构示意图。如图12所示，该计算机设备1000可以包括：至少一个处理器1001，例如CPU，至少一个网络接口1004，用户接口1003，存储器1005，至少一个通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。其中，在一些实施例中，用户接口1003可以包括显示屏(Display)、键盘(Keyboard)，网络接口1004可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器1005还可以是至少一个位于远离前述处理器1001的存储装置。如图12所示，作为一种计算机存储介质的存储器1005可以包括操作系统、网络通信模块、用户接口模块以及设备控制应用程序。
在图12所示的计算机设备1000中，网络接口1004可提供网络通讯功能；而用户接口1003主要用于为用户提供输入的接口；而处理器1001可以用于调用存储器1005中存储的设备控制应用程序，以实现：
响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1；n为正整数；
响应于第二请求消息具有第二准备证书，将第一请求消息以及第一请求消息对应的第一响应结果关联存储到账本文件，所述第一响应结果是响应于所述第一请求消息具有第一准备证书，通过执行所述第一请求消息对应的操作得到的；在关联存储第一请求消息以及第一响应结果到账本文件的同时，并行执行第二请求消息对应的请求操作，得到第二请求消息对应的第二响应结果，将第二响应结果存储到缓存文件；
将根据第二响应结果所生成的第一初始响应消息返回至客户端，以使客户端根据第一初始响应消息和区块链网络中具有共识权限的备份节点分别返回的备份初始响应消息，确定第二请求消息对应的第一请求执行结果。
或者，处理器1001可以用于调用存储器1005中存储的设备控制应用程序，以实现：
将第二请求消息发送至区块链网络中具有共识权限的节点，以使具有共识权限的节点中的主节点：响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1；n为正整数；响应于第二请求消息具有第二准备证书将第一请求消息以及第一请求消息对应的第一响应结果关联存储到账本文件；在关联存储第一请求消息以及第一响应结果到账本文件的同时，并行执行第二请求消息对应的请求操作，得到第二请求消息对应的第二响应结果，将第二响应结果存储到缓存文件；根据第二响应结果生成针对第二请求消息的第一初始响应消息；
获取主节点返回的第一初始响应消息，根据第一初始响应消息和区块链网络中具有共识权限的备份节点分别返回的备份初始响应消息，确定第二请求消息对应的第一请求执行结果。
应当理解，本申请实施例中所描述的计算机设备1000可执行前文各实施例中对基于区块链的数据处理方法或装置的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现前文各实施例中对基于区块链的数据处理方法或装置的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
上述计算机可读存储介质可以是前述任一实施例提供的基于区块链的数据处理装置或者上述计算机设备的内部存储单元，例如计算机设备的硬盘或内存。该计算机可读存储介质也可以是该计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(smart media card，SMC)，安全数字(secure digital，SD)卡，闪存卡(flash card)等。进一步地，该计算机可读存储介质还可以既包括该计算机设备的内部存储单元也包括外部存储设备。该计算机可读存储介质用于存储该计算机程序以及该计算机设备所需的其他程序和数据。该计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的数据。
本申请实施例还提供了一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机程序，处理器执行该计算机程序，使得该计算机设备可执行前文各实施例中对基于区块链的数据处理方法或装置的描述，在此不再赘述。另外，对采用相同方 法的有益效果描述，也不再进行赘述。
本申请实施例的说明书和权利要求书及附图中的术语“第一”、“第二”等是用于区别不同对象，而非用于描述特定顺序。此外，术语“包括”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、装置、产品或设备没有限定于已列出的步骤或模块，而是还包括没有列出的步骤或模块，或还包括对于这些过程、方法、装置、产品或设备固有的其他步骤单元。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本发明的原则之内所作的任何修改、等同替换和改进等，均应包含在本申请的保护范围之内。

Claims (19)

  1. 一种基于区块链的数据处理方法，区块链网络中包括具有共识权限的主节点和备份节点，所述方法由主节点执行，所述方法包括：
    响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1；n为正整数；
    响应于所述第二请求消息具有第二准备证书，将所述第一请求消息以及所述第一请求消息对应的第一响应结果关联存储到账本文件，所述第一响应结果是响应于所述第一请求消息具有第一准备证书，通过执行所述第一请求消息对应的操作得到的；在关联存储所述第一请求消息以及所述第一响应结果到账本文件的同时，并行执行所述第二请求消息对应的请求操作，得到所述第二请求消息对应的第二响应结果并将所述第二响应结果存储到缓存文件；
    将根据所述第二响应结果所生成的第一初始响应消息返回至发起所述第二请求消息的客户端，以使所述客户端根据所述第一初始响应消息和各备份节点分别返回的备份初始响应消息，确定所述第二请求消息对应的第一请求执行结果。
  2. 根据权利要求1所述的方法，进一步包括：
    获取所述第二请求消息，确定所述第二请求消息的请求状态；
    若所述请求状态为请求响应状态，则在缓存文件中获取所述第二请求消息对应的第二响应结果，将根据所述第二响应结果所生成的第二初始响应消息返回至所述客户端，以使所述客户端根据所述第二初始响应消息和各备份节点分别返回的备份初始响应消息，确定所述第二请求消息对应的第二请求执行结果；所述请求响应状态用于指示所述区块链网络中存在所述第二请求消息，且所述主节点已执行所述第二请求消息对应的请求操作；
    若所述请求状态为请求写入状态，则在账本文件中获取所述第二请求消息对应的第二响应结果，将根据所述第二响应结果所生成的完成响应消息返回至所述客户端，以使所述客户端根据所述完成响应消息和各备份节点分别返回的备份完成响应消息，确定所述第二请求消息对应的第三请求执行结果；所述请求写入状态用于指示所述区块链网络中存在所述第二请求消息，且所述主节点已关联存储所述第二请求消息以及所述第二响应结果到账本文件；
    若所述请求状态为请求初始状态，则执行所述响应于序列号为n的第一请求消息具 有第一准备证书，为第二请求消息分配序列号n+1的步骤；所述请求初始状态用于指示所述区块链网络中不存在所述第二请求消息。
  3. 根据权利要求2所述的方法，其中，所述确定所述第二请求消息的请求状态，包括：
    确定所述第二请求消息对应的请求哈希，将所述请求哈希与所述缓存文件中的缓存请求哈希进行对比；所述缓存文件中的缓存请求哈希所对应的请求消息为已被执行请求操作的请求消息；
    若所述缓存文件中存在与所述请求哈希相同的缓存请求哈希，则确定所述第二请求消息的请求状态为所述请求响应状态；
    若所述缓存文件中不存在与所述请求哈希相同的缓存请求哈希，则将所述请求哈希与所述账本文本中的写入请求哈希进行对比；所述账本文件中的写入请求哈希所对应的请求消息为已被存储的请求消息；
    若所述账本文件中存在与所述请求哈希相同的写入请求哈希，则确定所述第二请求消息的请求状态为所述请求写入状态；
    若所述账本文件中不存在与所述请求哈希相同的写入请求哈希，则确定所述第二请求消息的请求状态为请求初始状态。
  4. 根据权利要求2所述的方法，其中，所述将根据所述第二响应结果所生成的完成响应消息返回至所述客户端，包括：
    根据所述第二响应结果生成针对所述第二请求消息的完成响应标识；
    将所述完成响应标识、所述区块链网络的第一视图号、所述第二请求消息对应的请求时间戳、所述客户端对应的客户端标识、主节点标识，以及所述第二响应结果，确定为待签名完成响应信息；
    通过主节点私钥，对所述待签名完成响应信息进行签名，得到第一签名信息；
    生成携带所述第一签名信息和所述待签名完成响应信息的完成响应消息，将所述完成响应消息发送至所述客户端；所述第一签名信息用于指示所述客户端确定所述完成响应消息的合法性。
  5. 根据权利要求1所述的方法，其中，所述将根据所述第二响应结果所生成的第 一初始响应消息返回至所述客户端，包括：
    根据所述第二响应结果生成针对所述第二请求消息的初始响应标识；
    将所述初始响应标识、所述区块链网络的第一视图号、所述第二请求消息对应的请求时间戳、所述客户端对应的客户端标识、主节点标识，以及所述第二响应结果，确定为待签名初始响应信息；
    通过主节点私钥，对所述待签名初始响应信息进行签名，得到第二签名信息；
    生成携带所述第二签名信息和所述待签名初始响应信息的第一初始响应消息，将所述第一初始响应消息发送至所述客户端，所述第二签名信息用于指示所述客户端确定所述第一初始响应消息的合法性。
  6. 根据权利要求1所述的方法，其中，生成所述第二请求消息对应的第二准备证书，包括：
    根据为所述第二请求消息分配的序列号n+1以及所述第二请求消息，生成预准备消息；
    将所述预准备消息广播至各备份节点，以使各备份节点对所述预准备消息进行校验，得到第一校验结果，所述第一校验结果用于指示该备份节点在所述第一校验结果为通过时，生成所述第二请求消息对应的准备消息；
    获取各备份节点返回的准备消息，根据获取的准备消息，生成所述第二请求消息对应的第二准备证书。
  7. 根据权利要求6所述的方法，其中，所述根据为所述第二请求消息分配的序列号n+1以及所述第二请求消息，生成预准备消息，包括：
    对所述第二请求消息进行打包处理，得到待验证区块，将所述待验证区块的区块哈希值确定为所述待验证区块的区块摘要；
    生成所述待验证区块对应的预准备标识，将所述预准备标识、所述区块链网络的第一视图号、所述序列号n+1以及所述区块摘要，确定为待签名预准备信息；
    通过主节点私钥，对所述待签名预准备信息进行签名，得到第三签名信息；
    生成携带所述第三签名信息以及所述待验证区块的预准备消息。
  8. 根据权利要求6所述的方法，其中，所述准备消息携带第四签名信息；所述第 四签名信息是生成所述准备消息的备份节点通过备份节点私钥对所述准备消息进行签名所生成的；
    所述根据获取的准备消息，生成所述第二请求消息对应的第二准备证书，包括：
    针对各准备消息，分别执行以下操作：
    通过生成该准备消息的备份节点对应的备份节点公钥，对该准备消息携带的第四签名信息进行验签，得到该第四签名信息对应的验签结果；
    若该第四签名信息对应的验签结果为成功，则对该准备消息进行校验，得到第二校验结果；
    若该第二校验结果为通过，则将该准备消息添加至日志数据库；
    若所述日志数据库中包括2f个备份节点分别对应的准备消息，则将所述预准备消息以及2f个准备消息，组合成所述第二请求消息对应的第二准备证书；所述2f个备份节点属于所述3f个备份节点，其中，f为正整数，且f用于表征非法备份节点的最大数量；3f用于表征所述区块链网络中具有共识权限的备份节点的总数量；所述非法备份节点以及所述2f个备份节点均属于3f个备份节点。
  9. 一种基于区块链的数据处理方法，所述方法由客户端执行，所述方法包括：
    将第二请求消息发送至区块链网络中具有共识权限的节点，以使所述具有共识权限的节点中的主节点：响应于序列号为n的第一请求消息具有第一准备证书，为所述第二请求消息分配序列号n+1；n为正整数；响应于所述第二请求消息具有第二准备证书，将所述第一请求消息以及所述第一请求消息对应的第一响应结果关联存储到账本文件，所述第一响应结果是响应于所述第一请求消息具有第一准备证书，通过执行所述第一请求消息对应的操作得到的；在关联存储所述第一请求消息以及所述第一响应结果到账本文件的同时，并行执行所述第二请求消息对应的请求操作，得到所述第二请求消息对应的第二响应结果，将所述第二响应结果存储到缓存文件；根据所述第二响应结果生成针对所述第二请求消息的第一初始响应消息；
    获取所述主节点返回的所述第一初始响应消息，根据所述第一初始响应消息和区块链网络中具有共识权限的节点中的备份节点分别返回的备份初始响应消息，确定所述第二请求消息对应的第一请求执行结果。
  10. 根据权利要求9所述的方法，其中，所述第一初始响应消息和各备份初始响应 消息均携带待签名初始响应信息，所述待签名初始响应信息包括：所述第二请求消息的请求时间戳和所述第二响应结果；
    所述根据所述第一初始响应消息和区块链网络中具有共识权限的节点中的备份节点分别返回的备份初始响应消息，确定所述第二请求消息对应的第一请求执行结果，包括：
    对所述第一初始响应消息进行验签处理，得到所述第一初始响应消息对应的验签结果，若所述第一初始响应消息延签结果为成功，则将所述第二请求消息请求时间戳以及所述第二响应结果作为候选初始响应，添加至所述初始响应标识对应的候选初始响应集合；
    对各备份初始响应消息分别进行验签处理，得到该备份初始响应消息对应的验签结果，若该备份初始响应消息对应的验签结果为成功，则将所述请求时间戳以及所述第二响应结果作为候选初始响应，添加至所述初始响应标识对应的候选初始响应集合；
    根据所述候选初始响应集合，确定所述第二请求消息对应的第一请求执行结果。
  11. 根据权利要求10所述的方法，其中，所述根据所述候选初始响应集合，确定所述第二请求消息对应的第一请求执行结果，包括：
    在第一请求处理周期内，若所述候选初始响应集合中存在2f+1个相同的候选初始响应，则确定所述第二请求消息对应的第一请求执行结果为成功；
    若所述候选初始响应集合中不存在2f+1个相同的候选初始响应，则确定所述第二请求消息对应的第一请求执行结果为失败。
  12. 根据权利要求11所述的方法，进一步包括：
    若所述第一请求执行结果为失败，则根据所述第一请求处理周期，确定所述第二请求消息对应的更新时间戳；
    在所述更新时间戳对应的时间点，将所述第二请求消息重新发送至3f+1个具有共识权限的节点，以使所述3f+1个具有共识权限的节点分别确定所述第二请求消息的请求状态；请求状态Hi用于指示节点Ji确定所述第二请求消息对应的实际响应结果；所述实际响应结果用于指示所述节点Ji生成实际响应消息；i为正整数，且i小于或等于3f+1；所述请求状态Hi属于3f+1个请求状态；所述节点Ji属于所述3f+1个具有共识权限的节点中所述请求状态Hi所在的节点；
    获取所述节点Ji返回的实际响应消息，根据所述实际响应消息，确定所述第二请求消息对应的请求更新执行结果。
  13. 根据权利要求12所述的方法，其中，所述根据所述实际响应消息，确定所述第二请求消息对应的请求更新执行结果，包括：
    若所述实际响应消息包括完成响应标识，则将所述第二请求消息的请求时间戳以及所述实际响应结果，确定为候选完成响应；
    将所述候选完成响应添加至所述完成响应标识对应的候选完成响应集合；所述候选完成响应集合包括L个候选完成响应；L为正整数，且L小于或等于3f+1；
    根据所述候选完成响应集合，确定所述第二请求消息对应的第三请求执行结果。
  14. 根据权利要求13所述的方法，其中，所述根据所述候选完成响应集合，确定所述第二请求消息对应的第三请求执行结果，包括：
    在第二请求处理周期内，若所述候选完成响应集合中存在f+1个相同的候选完成响应，则确定所述第二请求消息对应的第三请求执行结果为成功；
    若所述候选完成响应集合中不存在f+1个相同的候选完成响应，则确定所述第二请求消息对应的第三请求执行结果为失败。
  15. 一种基于区块链的数据处理装置，区块链网络中包括具有共识权限的主节点和备份节点，所述装置运行于所述主节点，所述装置包括：
    序号分配模块，用于响应于序列号为n的第一请求消息具有第一准备证书，为第二请求消息分配序列号n+1；n为正整数；
    关联存储模块，用于响应于所述第二请求消息具有第二准备证书，将所述第一请求消息以及所述第一请求消息对应的第一响应结果关联存储到账本文件，所述第一响应结果是响应于所述第一请求消息具有第一准备证书，通过执行所述第一请求消息对应的操作得到的；
    请求操作模块，用于在关联存储所述第一请求消息以及所述第一响应结果到账本文件的同时，并行执行所述第二请求消息对应的请求操作，得到所述第二请求消息对应的第二响应结果，将第二响应结果存储到缓存文件；
    第一返回模块，用于将根据所述第二响应结果所生成的第一初始响应消息返回至发 起所述第二请求消息的客户端，以使所述客户端根据所述第一初始响应消息和各备份节点分别返回的备份初始响应消息，确定所述第二请求消息对应的第一请求执行结果。
  16. 一种基于区块链的数据处理装置，所述装置运行于客户端，所述装置包括：
    第一发送模块，用于将第二请求消息发送至区块链网络中具有共识权限的节点，以使所述具有共识权限的节点中的主节点：响应于序列号为n的第一请求消息具有第一准备证书，为所述第二请求消息分配序列号n+1；n为正整数；响应于所述第二请求消息具有第二准备证书，将所述第一请求消息以及所述第一请求消息对应的第一响应结果关联存储到账本文件，所述第一响应结果是响应于所述第一请求消息具有第一准备证书，通过执行所述第一请求消息对应的操作得到的；在关联存储所述第一请求消息以及所述第一响应结果到账本文件的同时，并行执行所述第二请求消息对应的请求操作，得到所述第二请求消息对应的第二响应结果，将第二响应结果存储到缓存文件；根据所述第二响应结果生成针对所述第二请求消息的第一初始响应消息；
    第一确定模块，用于获取所述主节点返回的所述第一初始响应消息，根据所述第一初始响应消息和区块链网络中具有共识权限的备份节点分别返回的备份初始响应消息，确定所述第二请求消息对应的第一请求执行结果。
  17. 一种计算机设备，包括：处理器、存储器以及网络接口；
    所述处理器与所述存储器、所述网络接口相连，其中，所述网络接口用于提供数据通信功能，所述存储器用于存储计算机程序，所述处理器用于调用所述计算机程序，以使得所述计算机设备执行权利要求1至14任一项所述的方法。
  18. 一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序适于由处理器加载并执行，以使得具有所述处理器的计算机设备执行权利要求1-14任一项所述的方法。
  19. 一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序存储在计算机可读存储介质中，所述计算机程序适于由处理器读取并执行，以使得具有所述处理器的计算机设备执行权利要求1-14任一项所述的方法。
PCT/CN2023/117186 2022-09-26 2023-09-06 基于区块链的数据处理方法、设备以及可读存储介质 WO2024066974A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211182614.7 2022-09-26
CN202211182614.7A CN117811739A (zh) 2022-09-26 2022-09-26 一种基于区块链的数据处理方法、设备以及可读存储介质

Publications (1)

Publication Number Publication Date
WO2024066974A1 true WO2024066974A1 (zh) 2024-04-04

Family

ID=90428653

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/117186 WO2024066974A1 (zh) 2022-09-26 2023-09-06 基于区块链的数据处理方法、设备以及可读存储介质

Country Status (2)

Country Link
CN (1) CN117811739A (zh)
WO (1) WO2024066974A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109766673A (zh) * 2019-01-18 2019-05-17 四川大学 一种联盟式音视频版权区块链系统及音视频版权上链方法
US20190377648A1 (en) * 2018-06-11 2019-12-12 Vmware, Inc. Linear view-change bft
CN112101942A (zh) * 2020-09-18 2020-12-18 腾讯科技（深圳）有限公司 基于区块链的交易请求处理方法、系统、装置及设备
CN113055188A (zh) * 2021-03-02 2021-06-29 腾讯科技（深圳）有限公司 一种数据处理方法、装置、设备及存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190377648A1 (en) * 2018-06-11 2019-12-12 Vmware, Inc. Linear view-change bft
CN109766673A (zh) * 2019-01-18 2019-05-17 四川大学 一种联盟式音视频版权区块链系统及音视频版权上链方法
CN112101942A (zh) * 2020-09-18 2020-12-18 腾讯科技（深圳）有限公司 基于区块链的交易请求处理方法、系统、装置及设备
CN113055188A (zh) * 2021-03-02 2021-06-29 腾讯科技（深圳）有限公司 一种数据处理方法、装置、设备及存储介质

Also Published As

Publication number Publication date
CN117811739A (zh) 2024-04-02

Similar Documents

Publication Publication Date Title
TWI705690B (zh) 分布式網路中進行主節點變更的系統
WO2020168937A1 (zh) 区块链多方见证方法、装置、设备及计算机可读存储介质
CN112685796B (zh) 一种基于区块链的区块共识方法以及相关设备
US20210027289A1 (en) Asset transaction method, storage medium, and computer device
US11128522B2 (en) Changing a master node in a blockchain system
WO2023045620A1 (zh) 一种交易数据处理方法、装置、计算机设备以及存储介质
KR20200074911A (ko) 분산 시스템 내의 네트워크 노드를 위한 복구 프로세스의 수행
KR102566892B1 (ko) 블록체인 합의 방법, 디바이스 및 시스템
CN113055188B (zh) 一种数据处理方法、装置、设备及存储介质
CN112235420B (zh) 基于区块链的数据同步方法、系统及相关设备
US20230262126A1 (en) Blockchain-based data processing method and apparatus, device, and readable storage medium
CN113328997B (zh) 联盟链跨链系统及方法
WO2023020242A1 (zh) 基于区块链的数据处理方法、装置、计算机设备、计算机可读存储介质及计算机程序产品
WO2023011019A1 (zh) 基于区块链的数据处理方法、装置、设备、可读存储介质及计算机程序产品
CN113255014B (zh) 一种基于区块链的数据处理方法以及相关设备
CN111339551B (zh) 数据的验证方法及相关装置、设备
CN114519197A (zh) 一种基于区块链和云服务的数据存储架构和方法
US20240289179A1 (en) Blockchain-based data processing method and apparatus
CN116304265A (zh) 一种基于区块链的电子档案管理方法及系统
US20240163118A1 (en) Blockchain-based data processing method, device, and readable storage medium
WO2023231558A1 (zh) 区块链共识方法、装置、介质、电子设备和程序产品
WO2024066974A1 (zh) 基于区块链的数据处理方法、设备以及可读存储介质
Xie et al. A raft algorithm with byzantine fault-tolerant performance
WO2024037117A1 (zh) 一种基于区块链的数据处理方法、设备、介质和程序产品
WO2024103856A1 (zh) 一种基于区块链的数据处理方法、设备以及可读存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23870213

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023870213

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2023870213

Country of ref document: EP

Effective date: 20240930