Blockchain consensus method, apparatus, medium, and electronic device

Abstract

The application belongs to the technical field of blockchains, and particularly relates to a blockchain consensus method, a blockchain consensus device, a computer readable medium, an electronic device and a computer program product. The method comprises the following steps: broadcasting a consensus request corresponding to at least two consensus stages in a blockchain network, the blockchain network comprising at least two blockchain nodes executing different types of consensus algorithms; respectively acquiring response messages broadcast by the blockchain network in each consensus stage; counting the number of nodes of the blockchain nodes sending the response messages in the same consensus stage; if the number of nodes satisfies a consensus condition of a first consensus algorithm, reaching a consensus on the blockchain node executing the first consensus algorithm, and synchronizing a consensus result of the first consensus algorithm to the blockchain node executing a second consensus algorithm, the first consensus algorithm and the second consensus algorithm being different types of consensus algorithms. The application can improve the flexibility of blockchain consensus.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, specifically relating to a blockchain consensus method, a blockchain consensus device, a computer-readable medium, an electronic device, and a computer program product. Background Technology

[0002] In a blockchain network comprising multiple blockchain nodes, to achieve a decentralized and trusted environment, all blockchain nodes typically need to execute a unified consensus algorithm to ensure consistent data synchronization across nodes. However, a unified consensus algorithm struggles to meet diverse system business requirements and suffers from poor flexibility. Summary of the Invention

[0003] This application provides a blockchain consensus method, a blockchain consensus device, a computer-readable medium, an electronic device, and a computer program product, with the aim of improving the flexibility of blockchain consensus.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to one aspect of the embodiments of this application, a blockchain consensus method is provided, the method comprising:

[0006] Broadcasting consensus requests corresponding to at least two consensus phases in a blockchain network, the blockchain network comprising at least two types of blockchain nodes executing different types of consensus algorithms;

[0007] The response messages broadcast by the blockchain network in each consensus phase are obtained respectively, and the response messages are messages in which the blockchain nodes respond to the consensus request;

[0008] The number of blockchain nodes that send the response message in the same consensus phase is counted, including the number of blockchain nodes that execute at least two different types of consensus algorithms;

[0009] If the number of nodes meets the consensus conditions of the first consensus algorithm, a consensus is reached on the blockchain nodes executing the first consensus algorithm, and the consensus result of the first consensus algorithm is synchronized to the blockchain nodes executing the second consensus algorithm. The first consensus algorithm and the second consensus algorithm are different types of consensus algorithms.

[0010] According to one aspect of the embodiments of this application, a blockchain consensus device is provided, the device comprising:

[0011] The request module is configured to broadcast consensus requests corresponding to at least two consensus phases in a blockchain network, the blockchain network comprising at least two types of blockchain nodes that execute different types of consensus algorithms;

[0012] The response module is configured to acquire response messages broadcast by the blockchain network in each consensus phase, wherein the response message is a message in which the blockchain node responds to the consensus request;

[0013] The statistics module is configured to count the number of blockchain nodes that issue the response message in the same consensus phase, the number of nodes including the number of blockchain nodes that execute at least two different types of consensus algorithms;

[0014] The synchronization module is configured to reach a consensus on the blockchain nodes executing the first consensus algorithm if the number of nodes meets the consensus conditions of the first consensus algorithm, and to synchronize the consensus result of the first consensus algorithm to the blockchain nodes executing the second consensus algorithm. The first consensus algorithm and the second consensus algorithm are different types of consensus algorithms.

[0015] According to one aspect of the embodiments of this application, a computer-readable medium is provided, on which a computer program is stored, which, when executed by a processor, implements the blockchain consensus method as described in the above technical solutions.

[0016] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute a blockchain consensus method as described above by executing the executable instructions.

[0017] According to one aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the blockchain consensus method as described in the above technical solutions.

[0018] In some embodiments of this application, the computer program product or computer program includes computer instructions stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain consensus method as described in the above technical solutions.

[0019] In the technical solution provided in this application embodiment, by configuring at least two types of blockchain nodes that execute different types of consensus algorithms in the blockchain network, the number of blockchain nodes that issue consensus responses can be counted during the node consensus process. When the number of nodes meets the consensus conditions of any one of the consensus algorithms, the blockchain nodes that meet the consensus conditions can synchronize the consensus results to the blockchain nodes that do not meet the consensus conditions, thereby improving the flexibility of blockchain consensus.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0022] Figure 1 A schematic diagram of the composition of the blockchain system in an embodiment of this application is shown.

[0023] Figure 2 The structure of a blockchain maintained on a blockchain network is shown.

[0024] Figure 3 The network architecture of a blockchain network applying the technical solution of this application is illustrated schematically.

[0025] Figure 4 A flowchart illustrating the steps of a blockchain consensus method in one embodiment of this application is shown.

[0026] Figure 5 The data structure of the response message in one embodiment of this application is shown.

[0027] Figure 6 This application illustrates a blockchain consensus method based on the number of nodes counted in the consensus phase, as shown in one embodiment.

[0028] Figure 7 The consensus process of a low-fault-tolerant consensus algorithm in one embodiment of this application is illustrated.

[0029] Figure 8 The consensus process of a high fault-tolerant consensus algorithm in one embodiment of this application is shown.

[0030] Figure 9 This paper illustrates a scenario example of an algorithm switching process according to an embodiment of this application.

[0031] Figure 10 The flowchart illustrating the steps of a consensus authentication method in an application scenario according to an embodiment of this application is shown.

[0032] Figure 11 A schematic block diagram of the blockchain consensus device provided in the embodiments of this application is shown.

[0033] Figure 12 A schematic diagram of a computer system architecture suitable for implementing the embodiments of this application is shown. Detailed Implementation

[0034] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0035] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0036] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0037] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0038] In the specific implementation of this application, requests, responses and other related data generated when users apply blockchain products are involved. When the various embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0039] A blockchain is a shared, chained-block data structure built on transparent and trusted rules in a peer-to-peer network environment. It is designed to be tamper-proof, tamper-proof, and traceable. The chained-block data structure stores transactions occurring over a period of time in blocks, which are then linked chronologically using cryptographic algorithms. The ledger is distributed to all member nodes in the network, permanently recording the history of asset transactions between peer nodes in the sequential chain of blocks linked by hash cryptographic algorithms. All confirmed and verified transactions are linked from the beginning of the chain to the latest block, hence the name blockchain. A blockchain can serve as a single source of truth, and members of a blockchain network can only view transactions relevant to them.

[0040] Figure 1 The diagram illustrates the composition of a blockchain system according to an embodiment of this application. The blockchain system 100 may include at least one client 110 and a blockchain network 120. The blockchain network 120 includes at least one blockchain node 121. The client 110 may be various electronic devices such as smartphones, tablets, laptops, desktop computers, smart wearable devices, smart in-vehicle devices, smart payment terminals, and facial recognition terminals. By installing the corresponding client application, it can provide blockchain data services to users. The blockchain node 121 may be a terminal device or a server. For example, the blockchain node 121 may be an independent physical server, a server cluster consisting of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0041] In blockchain network 120, each blockchain node 121 receives input information during normal operation and maintains shared data within the blockchain network based on the received input information. To ensure information interoperability, information connections can exist between the various blockchain nodes 121, allowing them to transmit information to each other. For example, when any blockchain node 121 in blockchain network 120 receives input information and broadcasts it within the blockchain network 120, other node devices in blockchain network 120 can obtain the input information according to a consensus algorithm and store it as shared data.

[0042] Each blockchain node 121 in the blockchain network 120 has a corresponding node identifier. Each blockchain node 121 can also store the node identifiers of other blockchain nodes in the same blockchain network, so that the generated block can be broadcast to other nodes in the blockchain network 120 based on their node identifiers. Each blockchain node 121 can maintain a node identifier list as shown in Table 1, storing the node name and node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node. Table 1 shows a node identifier list using IP addresses as an example.

[0043] Table 1

[0044] Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258

[0045] Figure 2 This illustrates the structural composition of a blockchain maintained on a blockchain network. For example... Figure 2 As shown, a blockchain consists of multiple sequentially linked blocks. Whenever new data needs to be written to the blockchain, this data is aggregated into a newly generated block. This newly generated block is then linked to the end of the blockchain. A consensus algorithm ensures that the blocks added on each node device 121 are identical. The block body of each block records the data of the current block, while its block header stores the hash value of the preceding block. If the transaction data in the preceding block changes, the hash value of the current block will also change accordingly. Therefore, data uploaded to the blockchain network is difficult to tamper with, improving the reliability of shared data.

[0046] Figure 3 The network architecture of a blockchain network applying the technical solution of this application is illustrated schematically. For example... Figure 3 As shown, in application scenarios that realize online transactions and online payments, the transaction entity node 310, the transaction platform node 320, and the resource allocation node 330 located in the blockchain network jointly maintain one or more blockchains 340.

[0047] Transaction entity node 310 is a blockchain node that provides transaction services to users. For example, it can be a merchant or individual seller who conducts online transactions with users.

[0048] Transaction platform node 320 is a blockchain node that provides transaction scenarios for online transactions. For example, it can be an e-commerce website, an online mall, or various business platforms that provide online transaction services.

[0049] Resource allocation node 330 is a blockchain node that provides fund management and allocation services for network transactions, such as a third-party payment institution.

[0050] When a user conducts a network transaction with the transaction entity node 310, they can pay transaction funds to the transaction entity node 310 through an account opened on the resource allocation node 330. The transaction platform node 320, as the provider of the transaction scenario, needs to deduct a certain amount of funds from these transaction funds as a platform service fee. To achieve reliable fund allocation between the transaction entity node 310 and the transaction platform node 320, a corresponding smart contract (such as a revenue-sharing contract) can be established based on the blockchain network for fund allocation. When a network transaction occurs, the resource allocation node 330 can allocate funds to various objects in the transaction scenario according to the smart contract. Transaction data generated by network transactions on each blockchain node can be stored on the blockchain 340. Decentralized data storage can effectively avoid trust crises.

[0051] Errors such as node downtime, network failures, software bugs, and malicious nodes can cause inconsistencies in the data stored between blockchain nodes. Consensus algorithms define a distributed algorithm for network interaction between nodes, ensuring data consistency across blockchain nodes even in systems experiencing such errors. In the related technologies of this application, all blockchain nodes in a blockchain network must use a unified consensus algorithm for consensus authentication to ensure consistency in the consensus process and results. However, in actual blockchain business processing, upper-layer business systems using blockchain services have varying requirements in terms of performance, availability, fault tolerance, and scalability as user needs change. Current blockchain networks, employing single consensus algorithms, cannot meet the requirements of these upper-layer business systems. If the consensus algorithm of a blockchain node needs to be changed, the entire blockchain network must be shut down until the algorithm change for all nodes is complete, and then the network with the new consensus algorithm can be restarted. This method of switching consensus algorithms easily leads to prolonged and frequent service interruptions, resulting not only in low efficiency but also severely impacting the service continuity and reliability of the blockchain network.

[0052] In view of the above-mentioned technical problems in related technologies, this application provides a solution that enables flexible online switching between multiple different types of consensus algorithms, allowing the blockchain system to change the consensus algorithm in real time without stopping service to meet the requirements of the business system.

[0053] The following detailed description of the technical solutions provided in this application, including blockchain consensus methods, blockchain consensus devices, computer-readable media, electronic devices, and computer program products, is based on specific implementation methods.

[0054] Figure 4 This application illustrates a flowchart of the steps of a blockchain consensus method in one embodiment. This blockchain consensus method can be implemented by… Figure 1 The client or blockchain node shown executes the method; this application embodiment uses the blockchain consensus method executed on a blockchain node as an example for illustration. For example... Figure 4 As shown, the blockchain consensus method in this application embodiment includes the following steps S410 to S440.

[0055] S410: Broadcasting consensus requests corresponding to at least two consensus phases in a blockchain network, which includes at least two types of blockchain nodes that execute different types of consensus algorithms.

[0056] The blockchain network in this application embodiment can include any one of a public blockchain, a private blockchain, or a consortium blockchain. Among these, the public blockchain offers the highest degree of decentralization. Nodes / participants joining a public blockchain can read data on the chain, publish transactions, and compete for the right to record new blocks; moreover, nodes / participants can freely join and leave the public blockchain. Conversely, in a private blockchain, the recording rights and data reading rights are controlled by a specific organization or institution. There are fewer participants, and joining a private blockchain requires approval from the organization or institution. A consortium blockchain, also known as a community blockchain, refers to a blockchain whose consensus process is controlled by pre-selected nodes. It is a hybrid of public and private blockchains, achieving "partial decentralization." Each node on the chain typically has a corresponding entity or organization; participants join the network through authorization and form a consortium of interested parties to jointly maintain the blockchain's operation. Through a consortium blockchain, new participants can join an existing blockchain and share data without having to build it from scratch. Whether it's a public blockchain, a private blockchain, or a consortium blockchain, they can all potentially offer smart contract functionality. A smart contract on a blockchain is a contract that can be triggered and executed through transactions within the blockchain system. Smart contracts can be defined in the form of code.

[0057] Smart contracts, also known as chaincode or application code, are computer protocols designed to disseminate, verify, or execute contracts in an informational manner. Deployed on nodes within a blockchain network, they carry the business logic for executing transactions and run in an isolated environment (such as a container or virtual machine). These contract programs, automatically executed by nodes in a blockchain system based on specific conditions, can manipulate data stored on the chain and are a crucial means for business entities to interact with the blockchain and utilize it to implement business logic. The purpose of smart contracts is to provide a more secure method than traditional contracts and reduce other transaction costs associated with contracts. They allow for trusted transactions without a third party, and these transactions are traceable and irreversible.

[0058] Transaction data generated based on smart contracts needs to undergo consensus authentication among different blockchain nodes through a consensus algorithm to ensure that consistent transaction data can be stored on each blockchain node. In one embodiment of this application, after a user conducts a network transaction and generates transaction data through a client running the blockchain system, the client can send a consensus request to the blockchain node it is communicating with. The blockchain node receiving the consensus request can broadcast it on the blockchain network, so that the consensus request can be transmitted to all blockchain nodes in the blockchain network.

[0059] In this embodiment, at least two different types of consensus algorithms can run simultaneously on the blockchain network. For example, some blockchain nodes in the network execute a first consensus algorithm, while other blockchain nodes execute a second consensus algorithm different from the first consensus algorithm. The first and second consensus algorithms can have the same consensus conditions or different consensus conditions. The first and second consensus algorithms can have the same number of consensus stages or different numbers of consensus stages.

[0060] In one embodiment of this application, one or more blockchain nodes can be selected from the blockchain network as master nodes to handle consensus requests, and the other blockchain nodes in the blockchain network besides the master node serve as slave nodes. When a client generates a consensus request, it can first send the consensus request to the master node, which then distributes the consensus request to each slave node. The master node can be generated through voting, round-robin assignment, or random selection.

[0061] S420: Retrieves the response messages broadcast by the blockchain network at each consensus stage. The response message is the message in which the blockchain node responds to the consensus request.

[0062] When a blockchain node in a blockchain network receives a consensus request, it can respond to the consensus request, generate a response message, and broadcast the response message on the blockchain network.

[0063] In one embodiment of this application, a blockchain node can perform consensus verification on a received consensus request and broadcast a response message to the blockchain network after successful verification. The consensus verification of the consensus request by the blockchain node can include two aspects: signature verification and data verification. Signature verification is used to verify the reliability of the source of the consensus request, while data verification is used to verify the authenticity of the content of the consensus request.

[0064] In one embodiment of this application, the consensus request broadcast in the blockchain network carries the digital signature of the blockchain node that issued the consensus request, and the response message broadcast in the blockchain network also carries the digital signature of the blockchain node that issued the response message. Each blockchain node in the blockchain network can hold a public key and a private key that make up an asymmetric key pair. When digitally signing a consensus request or response message, a digest can first be extracted from the data content using a digest extraction algorithm, and then the digest can be encrypted using the private key to form a digital signature. This digital signature can be verified using the public key.

[0065] A content digest is a fixed-length string that uniquely corresponds to a piece of data content. It is generated by applying a one-way hash encryption function to the data content. If the data content is tampered with during network transmission, the alteration of the data content can be determined by comparing the content digests before and after transmission. Therefore, the integrity of data content can be verified based on the content digest. The content digest uses a one-way hash function to map the plaintext data content to be transmitted into a string of ciphertext, also known as a digital fingerprint. The content digest has a fixed length, and different plaintexts will always result in different ciphertexts, while the same plaintext will always have the same digest. The digest extraction algorithm in the embodiments of this application may include, for example, MD (Message Digest), SHA (Secure Hash Algorithm), MAC (Message Authentication Code), and other algorithms.

[0066] A digital signature is a message digest algorithm with a key, consisting of a public key and a private key, used to verify data integrity, authenticate data origin, and prevent repudiation. It follows the OSI reference model, involving private key signing and public key verification. It is also a combination of asymmetric encryption and message digest algorithms. Common digital signature algorithms include RSA, DSA, and ECDSA.

[0067] Based on the RSA algorithm, a pair of RSA keys can be generated first. One is a secret key, which is kept by the business entity; the other is a public key, which can be made public and even registered on a web server. To improve security, RSA keys should be at least 500 bits long, with 1024 bits generally recommended. This makes the encryption computationally intensive. To reduce computation, when transmitting information, a combination of traditional encryption methods and public-key encryption methods is often used. That is, the information is encrypted using an improved DES or IDEA session key, and then the session key and message digest are encrypted using the RSA key. After receiving the information, the recipient decrypts it using different keys and can verify the message digest.

[0068] A key feature of DSA (Digital Signature Algorithm) is that two prime numbers are publicly disclosed. This allows any entity using p and q to verify whether they were randomly generated or forged / modified, even without knowing the private key.

[0069] ECDSA (Elliptic Curve Digital Signature Algorithm) is a combination of ECC (Elliptic Curve Cryptography) and DSA. The entire signing process is similar to DSA, but the difference is that the algorithm used in the signature is ECC, and the final signed value is also divided into two parameters, r and s.

[0070] In one embodiment of this application, after completing the signature verification of the consensus request, data verification can be performed on the data content carried in the consensus request. The data verification method may include, for example, performing a consistency check between the data content carried in the consensus request and the data content cached locally by the current blockchain node. If the verification passes, it indicates that the blockchain node that issued the consensus request and the current blockchain node cache the same data content, and that this data content has not been modified during network transmission.

[0071] S430: Count the number of blockchain nodes that send response messages in the same consensus phase, including the number of blockchain nodes that execute at least two different types of consensus algorithms.

[0072] When a blockchain node receives a response message broadcast in the blockchain network, it can parse the message to determine its source. By counting response messages with different sources, the number of blockchain nodes that sent the response message can be obtained. This number represents the number of blockchain nodes in the network that responded to the consensus request and are executing different types of consensus algorithms.

[0073] In one embodiment of this application, each blockchain node can receive and count response messages from other blockchain nodes. For example, if the blockchain network includes n blockchain nodes, each blockchain node can receive at most n-1 response messages from other blockchain nodes. Simultaneously, each blockchain node also sends response messages to other nodes. Therefore, the maximum number of blockchain nodes a single blockchain node can count as having sent response messages is the total number of blockchain nodes in the blockchain network. Having each blockchain node separately count the message sources improves the reliability of the consensus process.

[0074] In one embodiment of this application, one or more master nodes in the blockchain network can perform source statistics on response messages, while other slave nodes do not need to perform quantity statistics. For example, during a consensus process, master nodes are generated through voting, round-robin designation, or random selection. After sending a consensus request to the blockchain network, the master node can monitor the response messages returned by slave nodes in the blockchain network and count the number of slave nodes that sent response messages. The advantage of having the master node perform message source statistics is that it can reduce the computational cost of other slave nodes and avoid generating unnecessary data overhead.

[0075] In one embodiment of this application, to improve consensus efficiency, the number of blockchain nodes that send response messages can be counted within a preset time range. If a new response message is received outside the time range, it can be discarded and no longer counted.

[0076] In one embodiment of this application, the time range for counting the number of nodes can be a fixed time window with a specified length, starting from the first time point when the current blockchain node receives the consensus request, or a fixed time window with a specified length, starting from the second time point when the current blockchain node sends the response message.

[0077] In one embodiment of this application, the time range for counting the number of nodes can be a dynamic time window with varying lengths, where the end point of the range is determined based on the third time point of the most recent received response message and a preset time length. For example, if a blockchain node last received a response message at time point A, the end point of the time range can be determined as A+B based on the time length B. If the blockchain node does not receive a new response message between time point A and A+B, the counting of response message sources can be stopped. If the blockchain node receives a new response message between time point A and A+B, for example, at time point C, the end point of the time range can be updated to C+B. This process continues until the blockchain node has not received a new response message for an extended period, at which point the counting of response message sources can be stopped.

[0078] In one embodiment of this application, the time range for source statistics of response messages can be a time range with a static start point and a dynamic end point. For example, the static start point can be any one of the following: receiving a consensus request, sending a response message, or receiving a response message for the first time. The dynamic end point is determined by the most recent receipt of a new response message and a preset time length. Using a dynamically changing time range for message source statistics can improve statistical efficiency while ensuring the accuracy of data statistics. It avoids affecting the consensus progress due to an excessively long time range, and also avoids the problem of incomplete data statistics due to an excessively short time range.

[0079] S440: If the number of nodes meets the consensus conditions of the first consensus algorithm, a consensus is reached on the blockchain nodes executing the first consensus algorithm, and the consensus result of the first consensus algorithm is synchronized to the blockchain nodes executing the second consensus algorithm. The first consensus algorithm and the second consensus algorithm are different types of consensus algorithms.

[0080] The consensus condition of a consensus algorithm is the criterion used to determine whether a consensus result can be obtained. For example, the consensus condition of a consensus algorithm could be that the number of blockchain nodes that send response messages exceeds a preset proportion of the total number of blockchain nodes. Different types of consensus algorithms configured in a blockchain network can have the same consensus condition or different consensus conditions.

[0081] In one embodiment of this application, blockchain nodes in a blockchain network can determine whether the statistically obtained number of nodes meets the consensus conditions based on the consensus algorithm they execute. For example, if the consensus algorithm currently executed by the blockchain node is a first consensus algorithm, the consensus conditions of the first consensus algorithm can be determined based on the statistically obtained number of nodes; if the consensus algorithm currently executed by the blockchain node is a second consensus algorithm, the consensus conditions of the second consensus algorithm can be determined based on the statistically obtained number of nodes.

[0082] In one embodiment of this application, a portion of the blockchain nodes in the blockchain network execute a first consensus algorithm, while another portion executes a second consensus algorithm. The consensus condition for the first consensus algorithm is that the proportion of blockchain nodes sending response messages to the total number of blockchain nodes exceeds a first threshold. The consensus condition for the second consensus algorithm is that the proportion of blockchain nodes sending response messages to the total number of blockchain nodes exceeds a second threshold, where the second threshold is greater than the first threshold. If the ratio of the number of nodes to the total number of blockchain nodes is greater than the first threshold but less than the second threshold, it can be determined that the number of nodes meets the consensus condition for the first consensus algorithm but not the consensus condition for the second consensus algorithm. Based on this, the blockchain nodes executing the first consensus algorithm can achieve a successful consensus result. Although the blockchain nodes executing the second consensus algorithm fail to achieve consensus, they can synchronize data with each other through the blockchain nodes executing the first consensus algorithm, enabling the blockchain nodes executing the second consensus algorithm to also achieve consensus.

[0083] In the blockchain consensus method provided in this application embodiment, by configuring at least two blockchain nodes that execute different types of consensus algorithms in the blockchain network, the number of blockchain nodes that send consensus response messages can be counted during the node consensus process. When the number of nodes meets the consensus conditions of any one of the consensus algorithms, the blockchain nodes that meet the consensus conditions can synchronize the consensus results to the blockchain nodes that do not meet the consensus conditions, thereby improving the flexibility of blockchain consensus.

[0084] In one embodiment of this application, different types of consensus algorithms have different numbers of consensus stages. The response message carries the algorithm type and node signature of the blockchain node. The algorithm type is used to indicate the consensus algorithm executed by the blockchain node, and the node signature includes the digital signature of the blockchain node at each consensus stage.

[0085] Figure 5 The data structure of the response message in one embodiment of this application is shown. For example... Figure 5As shown, a response message generated based on a certain consensus algorithm may include a type field 501, a signature field 502, and a data field 503.

[0086] The type field 501 is used to indicate the type of consensus algorithm executed by the blockchain node that issued the response message, such as CFT-type consensus algorithms or BFT-type consensus algorithms.

[0087] Crash Fault Tolerance (CFT) consensus algorithms are a class of consensus algorithms that can guarantee data consistency among nodes in the face of fault-based errors. Fault-based errors include benign errors such as node crashes and network errors.

[0088] BFT-type consensus algorithms, or Byzantine Fault Tolerance algorithms (BFT), are a class of consensus algorithms that can guarantee data consistency among nodes in the face of Byzantine faults. Byzantine faults include the aforementioned failure-type errors, as well as malicious errors such as software errors and malicious nodes.

[0089] The signature field 502 is used to store the digital signatures of the blockchain node that issued the response message at various consensus stages, such as the pre-preparation stage signature, the preparation stage signature, and the commit stage signature.

[0090] When generating a response message, blockchain nodes executing CFT-type consensus algorithms can use the pre-preparation phase signature and the commit phase signature in the data structure; blockchain nodes executing BFT-type consensus algorithms can use all three phases of signature when generating a response message.

[0091] In one embodiment of this application, a response message at one stage carries digital signatures from all preceding stages. For example, a first-stage response message carries the digital signature of the first stage, a second-stage response message carries both the digital signatures of the first and second stages, and a third-stage response message carries the digital signatures of the first, second, and third stages.

[0092] Data field 503 is used to store data requesting consensus authentication, such as transaction data from network transactions.

[0093] The response message data structure provided in this application embodiment can be applied to multiple different types of consensus algorithms simultaneously, enabling consensus algorithms with different numbers of consensus stages to perform consensus authentication through the same response message, thereby improving the matching diversity of blockchain networks for different consensus algorithms.

[0094] For consensus algorithms with different numbers of consensus stages, due to differences in computing power and network transmission speed among blockchain nodes, each node may be in a different consensus stage during the consensus authentication process. Therefore, when a blockchain node receives a response message from another blockchain node, it needs to identify the corresponding consensus stage based on the response message to effectively count the number of nodes in different consensus stages. Figure 6 This application illustrates a blockchain consensus method based on the number of nodes counted during the consensus phase, as shown in one embodiment. Figure 6 As shown, the method includes the following steps S610 to S670.

[0095] S610: Broadcasting consensus requests corresponding to at least two consensus phases in a blockchain network, which includes at least two types of blockchain nodes that execute different types of consensus algorithms.

[0096] In this embodiment of the application, at least two different types of consensus algorithms can run simultaneously on the blockchain network. For example, some blockchain nodes in the blockchain network execute a first consensus algorithm, while other blockchain nodes execute a second consensus algorithm different from the first consensus algorithm. The first consensus algorithm and the second consensus algorithm can have the same consensus conditions, or they can have different consensus conditions.

[0097] In one embodiment of this application, one or more blockchain nodes can be selected from the blockchain network as master nodes to handle consensus requests, and the other blockchain nodes in the blockchain network besides the master node serve as slave nodes. When a client generates a consensus request, it can first send the consensus request to the master node, which then distributes the consensus request to each slave node. The master node can be generated through voting, round-robin assignment, or random selection.

[0098] S620: Retrieves the response messages broadcast by the blockchain network at each consensus stage. The response message is the message in which the blockchain node responds to the consensus request.

[0099] When a blockchain node in a blockchain network receives a consensus request, it can respond to the consensus request, generate a response message, and broadcast the response message on the blockchain network.

[0100] In one embodiment of this application, a blockchain node can perform consensus verification on a received consensus request and broadcast a response message to the blockchain network after successful verification. The consensus verification of the consensus request by the blockchain node can include two aspects: signature verification and data verification. Signature verification is used to verify the reliability of the source of the consensus request, while data verification is used to verify the authenticity of the content of the consensus request.

[0101] In one embodiment of this application, the consensus request broadcast in the blockchain network carries the digital signature of the blockchain node that issued the consensus request, and the response message broadcast in the blockchain network also carries the digital signature of the blockchain node that issued the response message. Each blockchain node in the blockchain network can hold a public key and a private key that make up an asymmetric key pair. When digitally signing a consensus request or response message, a digest can first be extracted from the data content using a digest extraction algorithm, and then the digest can be encrypted using the private key to form a digital signature. This digital signature can be verified using the public key.

[0102] In one embodiment of this application, after completing the signature verification of the consensus request, data verification can be performed on the data content carried in the consensus request. The data verification method may include, for example, performing a consistency check between the data content carried in the consensus request and the data content cached locally by the current blockchain node. If the verification passes, it indicates that the blockchain node that issued the consensus request and the current blockchain node cache the same data content, and that this data content has not been modified during network transmission.

[0103] S630: Parse the response message to obtain the algorithm type and node signature carried in the response message.

[0104] The response message carries the algorithm type and node signature of the blockchain node. The algorithm type indicates the consensus algorithm executed by the blockchain node, and the node signature includes the digital signature of the blockchain node at each consensus stage.

[0105] By parsing the response message, we can obtain the following: Figure 6 The data structure shown can be used to obtain the algorithm type from the type field and the node signature corresponding to each consensus stage from the signature field.

[0106] S640: Identify the consensus algorithm executed by the message sending node based on the algorithm type. The message sending node is the blockchain node that sends the response message.

[0107] Each blockchain node in a blockchain network has a corresponding node identifier. Furthermore, each blockchain node can store the node identifiers of other blockchain nodes in the network. This allows for the subsequent broadcasting of consensus requests, response messages, and blocks to be added to the chain to other blockchain nodes based on their node identifiers. Each blockchain node can maintain a list of node identifiers, storing the node name and its corresponding node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the blockchain node.

[0108] When a blockchain node broadcasts a response message to the blockchain network, it can encapsulate its own node identifier within the message. When a current blockchain node receives the response message broadcast on the network, it can determine the sending node based on the node identifier parsed from the response message. The consensus algorithm executed by the sending node can be determined based on the algorithm type parsed from the response message.

[0109] S650: Identify the consensus phase of the message-sending node based on the node signature.

[0110] By parsing the response message, its signature field can be read to obtain the node signature corresponding to each consensus stage. Since different blockchain nodes may have different consensus progress, the response messages broadcast on the blockchain network may also carry node signatures corresponding to different consensus stages. For example, if a blockchain node is in the pre-preparation stage, its response message will carry the node signature for the pre-preparation stage; or, if a blockchain node has completed the consensus authentication of the pre-preparation stage and is currently in the preparation stage, its response message will carry node signatures for both the pre-preparation and preparation stages.

[0111] In one embodiment of this application, by parsing the response message, one or more consensus stages containing node signatures can be filtered out. Based on the execution order of each consensus stage, the consensus stage currently being performed by the message-sending node can be determined.

[0112] If a node's signature is present in the signature field for only one consensus phase, then the message-sending node is in that consensus phase. For example, if a response message's signature field only shows a node's signature for the pre-preparation phase, and the signature fields for other consensus phases are empty, then it can be determined that the message-sending node that sent the response message is currently in the pre-preparation phase.

[0113] If the signature field contains node signatures in at least two consensus phases, the consensus phase executed later in the execution order of these two phases can be determined as the current consensus phase of the message-sending node. For example, if the signature field of an acknowledgment message contains node signatures in both the pre-preparation and preparation phases, while the signature fields for other consensus phases are empty, it can be determined that the message-sending node of this acknowledgment message is currently in the preparation phase, since the preparation phase in the consensus algorithm executes after the pre-preparation phase.

[0114] S660: Based on the consensus algorithm executed by the message sending node and the consensus stage in which the message sending node is located, count the number of message sending nodes that are in the same consensus stage as the current blockchain node.

[0115] Based on the consensus algorithm executed by the message-sending node, it can be determined whether the message-sending node and the current blockchain node are executing the same type of consensus algorithm. If the message-sending node and the current blockchain node are executing the same type of consensus algorithm, it can be directly determined whether the message-sending node and the current blockchain node are in the same consensus stage based on the consensus stage they are in. If the message-sending node and the current blockchain node are executing different types of consensus algorithms, it is necessary to determine whether the consensus stage of the message-sending node is the same as that of the current blockchain node based on a pre-configured matching relationship.

[0116] Before counting the number of message-sending nodes that are in the same consensus stage as the current blockchain node, the current blockchain node can first obtain the matching relationship between consensus stages of different types of consensus algorithms. If the message-sending nodes and the current blockchain node execute different types of consensus algorithms, then the message-sending nodes that are in the same consensus stage as the current blockchain node are determined based on the matching relationship.

[0117] For any two different types of consensus algorithms, it can be determined whether the blockchain nodes are in the same consensus phase based on the matching relationship. For example, the message sending node executes one of the first consensus algorithm and the second consensus algorithm, and the current blockchain node executes the other of the first consensus algorithm and the second consensus algorithm. The first consensus algorithm includes N consensus phases, and the second consensus algorithm includes M consensus phases. The matching relationship between the consensus phases of different types of consensus algorithms includes: the first consensus algorithm and the second consensus algorithm match for the first P consensus phases, where P is the smaller value between (N-1) and (M-1); the last (NP) consensus phases of the first consensus algorithm match for the last (MP) consensus phases of the second consensus algorithm.

[0118] For example, the first consensus algorithm is a CFT-type consensus algorithm, which includes two consensus phases: the preparation phase and the submission phase; the second consensus algorithm is a BFT-type consensus algorithm, which includes three consensus phases: the pre-preparation phase, the preparation phase, and the submission phase.

[0119] Based on the above matching relationships, it can be seen that the preceding consensus phase of the first consensus algorithm matches the preceding consensus phase of the second consensus algorithm; that is, the preparation phase of the CFT-type consensus algorithm matches the pre-preparation phase of the BFT-type consensus algorithm. The following consensus phase of the second consensus algorithm matches the following two consensus phases; that is, the submission phase of the CFT-type consensus algorithm matches the preparation and submission phases of the BFT-type consensus algorithm.

[0120] Based on this, if one blockchain node is in the preparation stage of a CFT-type consensus algorithm and another blockchain node is in the pre-preparation stage of a BFT-type consensus algorithm, it can be determined that the two are in the same consensus stage; similarly, if one blockchain node is in the submission stage of a CFT-type consensus algorithm and another blockchain node is in the preparation or submission stage of a BFT-type consensus algorithm, it can be determined that the two are in the same consensus stage.

[0121] In one embodiment of this application, after counting the number of message-sending nodes that are in the same consensus stage as the current blockchain node, the current blockchain node can determine the subsequent algorithm execution action based on its current consensus stage. If the current blockchain node is in the last consensus stage of the consensus algorithm, the consensus result of the consensus algorithm is determined based on whether the number of nodes meets the consensus condition of the consensus algorithm; if the current blockchain node is not in the last consensus stage of the consensus algorithm, the next consensus stage of the consensus algorithm is determined based on whether the number of nodes meets the consensus condition of the consensus algorithm.

[0122] For example, if the current consensus stage of a blockchain node is the preparation stage of a CFT-type consensus algorithm, by counting the number of blockchain nodes in the same consensus stage (including the preparation stage of a CFT-type consensus algorithm or the pre-preparation stage of a BFT-type consensus algorithm), it can be determined whether the number of nodes meets the consensus conditions of a CFT-type consensus algorithm. If the consensus conditions of a CFT-type consensus algorithm are met, the node can proceed to the commit stage; otherwise, it needs to continue waiting to receive response messages from other blockchain nodes, and the count of nodes will be updated in real time.

[0123] In one embodiment of this application, each blockchain node can receive and count response messages from other blockchain nodes. For example, if the blockchain network includes n blockchain nodes, each blockchain node can receive at most n-1 response messages from other blockchain nodes. Simultaneously, each blockchain node also sends response messages to other nodes. Therefore, the maximum number of blockchain nodes a single blockchain node can count as having sent response messages is the total number of blockchain nodes in the blockchain network. Having each blockchain node separately count the message sources improves the reliability of the consensus process.

[0124] In one embodiment of this application, one or more master nodes in the blockchain network can perform source statistics on response messages, while other slave nodes do not need to perform quantity statistics. For example, during a consensus process, master nodes are generated through voting, round-robin designation, or random selection. After sending a consensus request to the blockchain network, the master node can monitor the response messages returned by slave nodes in the blockchain network and count the number of slave nodes that sent response messages. The advantage of having the master node perform message source statistics is that it can reduce the computational cost of other slave nodes and avoid generating unnecessary data overhead.

[0125] In one embodiment of this application, to improve consensus efficiency, the number of blockchain nodes that send response messages can be counted within a preset time range. If a new response message is received outside the time range, it can be discarded and no longer counted.

[0126] In one embodiment of this application, the time range for counting the number of nodes can be a fixed time window with a specified length, starting from the first time point when the current blockchain node receives the consensus request, or a fixed time window with a specified length, starting from the second time point when the current blockchain node sends the response message.

[0127] In one embodiment of this application, the time range for counting the number of nodes can be a dynamic time window with varying lengths, where the end point of the range is determined based on the third time point of the most recent received response message and a preset time length. For example, if a blockchain node last received a response message at time point A, the end point of the time range can be determined as A+B based on the time length B. If the blockchain node does not receive a new response message between time point A and A+B, the counting of response message sources can be stopped. If the blockchain node receives a new response message between time point A and A+B, for example, at time point C, the end point of the time range can be updated to C+B. This process continues until the blockchain node has not received a new response message for an extended period, at which point the counting of response message sources can be stopped.

[0128] In one embodiment of this application, the time range for source statistics of response messages can be a time range with a static start point and a dynamic end point. For example, the static start point can be any one of the following: receiving a consensus request, sending a response message, or receiving a response message for the first time. The dynamic end point is determined by the most recent receipt of a new response message and a preset time length. Using a dynamically changing time range for message source statistics can improve statistical efficiency while ensuring the accuracy of data statistics. It avoids affecting the consensus progress due to an excessively long time range, and also avoids the problem of incomplete data statistics due to an excessively short time range.

[0129] S670: If the number of nodes meets the consensus conditions of the first consensus algorithm, a consensus is reached on the blockchain nodes executing the first consensus algorithm, and the consensus result of the first consensus algorithm is synchronized to the blockchain nodes executing the second consensus algorithm. The first consensus algorithm and the second consensus algorithm are different types of consensus algorithms.

[0130] The consensus condition of a consensus algorithm is the criterion used to determine whether a consensus result can be obtained. For example, the consensus condition of a consensus algorithm could be that the number of blockchain nodes that send response messages exceeds a preset proportion of the total number of blockchain nodes. Different types of consensus algorithms configured in a blockchain network can have the same consensus condition or different consensus conditions.

[0131] In one embodiment of this application, blockchain nodes in a blockchain network can determine whether the statistically obtained number of nodes meets the consensus conditions based on the consensus algorithm they execute. For example, if the consensus algorithm currently executed by the blockchain node is a first consensus algorithm, the consensus conditions of the first consensus algorithm can be determined based on the statistically obtained number of nodes; if the consensus algorithm currently executed by the blockchain node is a second consensus algorithm, the consensus conditions of the second consensus algorithm can be determined based on the statistically obtained number of nodes.

[0132] In one embodiment of this application, a portion of the blockchain nodes in the blockchain network execute a first consensus algorithm, while another portion executes a second consensus algorithm. The consensus condition for the first consensus algorithm is that the proportion of blockchain nodes sending response messages to the total number of blockchain nodes exceeds a first threshold. The consensus condition for the second consensus algorithm is that the proportion of blockchain nodes sending response messages to the total number of blockchain nodes exceeds a second threshold, where the second threshold is greater than the first threshold. If the ratio of the number of nodes to the total number of blockchain nodes is greater than the first threshold but less than the second threshold, it can be determined that the number of nodes meets the consensus condition for the first consensus algorithm but not the consensus condition for the second consensus algorithm. Based on this, the blockchain nodes executing the first consensus algorithm can achieve a successful consensus result. Although the blockchain nodes executing the second consensus algorithm fail to achieve consensus, they can synchronize data with each other through the blockchain nodes executing the first consensus algorithm, enabling the blockchain nodes executing the second consensus algorithm to also achieve consensus.

[0133] In one embodiment of this application, the first consensus algorithm is one of a low-fault-tolerant consensus algorithm and a high-fault-tolerant consensus algorithm, and the second consensus algorithm is the other of the same algorithm. The consensus condition for the low-fault-tolerant consensus algorithm is that the ratio of the number of blockchain nodes sending response messages to the total number of blockchain nodes is greater than a first ratio threshold. The consensus condition for the high-fault-tolerant consensus algorithm is that the ratio of the number of blockchain nodes sending response messages to the total number of blockchain nodes is greater than a second ratio threshold, where the first ratio threshold is less than the second ratio threshold. Both the first and second ratio thresholds are constants greater than 0 and less than 1. For example, the first ratio threshold is 1 / 2, and the second ratio threshold is 2 / 3.

[0134] If the ratio of the number of blockchain nodes sending response messages to the total number of blockchain nodes is less than 1 / 2, then the number of nodes does not meet the consensus conditions of either the low fault tolerance consensus algorithm or the high fault tolerance consensus algorithm, and all blockchain nodes executing either consensus algorithm will fail to complete consensus authentication.

[0135] If the ratio of blockchain nodes sending response messages to all blockchain nodes is greater than 1 / 2 and less than 2 / 3, then the number of nodes meets the consensus condition for a low-fault-tolerance consensus algorithm but not for a high-fault-tolerance consensus algorithm. Blockchain nodes executing the low-fault-tolerance consensus algorithm can complete consensus authentication, while those executing the high-fault-tolerance consensus algorithm cannot. Based on this, blockchain nodes executing the low-fault-tolerance consensus algorithm can synchronize their consensus results with those executing the high-fault-tolerance consensus algorithm, thus enabling all blockchain nodes in the blockchain network to complete consensus authentication.

[0136] If the ratio of the number of blockchain nodes sending response messages to the total number of blockchain nodes is greater than 2 / 3, then the number of nodes satisfies the consensus conditions of both the low fault tolerance consensus algorithm and the high fault tolerance consensus algorithm. All blockchain nodes executing both consensus algorithms can complete consensus authentication.

[0137] In one embodiment of this application, the low-fault-tolerant consensus algorithm has a first number of consensus stages, and the high-fault-tolerant consensus algorithm has a second number of consensus stages, where the first number is less than the second number. Increasing the number of consensus stages can improve the fault tolerance of the consensus algorithm.

[0138] In one embodiment of this application, the consensus phase of the low fault tolerance consensus algorithm includes a preparation phase and a submission phase executed sequentially, and the consensus phase of the high fault tolerance consensus algorithm includes a pre-preparation phase, a preparation phase, and a submission phase executed sequentially. The preparation phase of the low fault tolerance consensus algorithm matches the pre-preparation phase of the high fault tolerance consensus algorithm, and the submission phase of the low fault tolerance consensus algorithm matches the preparation phase and the submission phase of the high fault tolerance consensus algorithm.

[0139] Figure 7 This paper illustrates the consensus process of a low-fault-tolerant consensus algorithm according to one embodiment of this application. The low-fault-tolerant consensus algorithm can be, for example, the Paxos algorithm in the CFT-type consensus algorithm. The low-fault-tolerant consensus algorithm in this embodiment is based on two-stage inter-node interaction. Its advantage is that the inter-node interaction is relatively simple, thus easier to implement and has higher performance.

[0140] like Figure 7 As shown, the consensus authentication process based on a low-fault-tolerance consensus algorithm may include the following steps.

[0141] S701: The client sends a consensus request to the master node. A consensus request can be, for example, a write request to write data to the blockchain.

[0142] S702: The master node performs the first phase of node interaction (preparation phase), distributing the authentication request to other slave nodes. After a slave node receives the authentication request and performs consensus processing, it can return a response message to the master node.

[0143] During the preparation phase, the master node sends authentication requests to other slave nodes, carrying the data to be written to the blockchain, and then uses its private key to perform digest processing and encryption on that data to obtain the master node's digital signature. Figure 5 Taking the data structure shown as an example, the authentication request sent by the master node to the slave node carries the master node's digital signature written in the "preparation phase signature" field.

[0144] When a slave node receives an authentication request from the master node, it can use the master node's public key to verify the digital signature carried in the authentication request. After successful signature verification, the slave node can use its own private key to perform digest processing and encryption on the data to be written to the blockchain to obtain the slave node's digital signature. Figure 5 Taking the data structure shown as an example, the response message from the slave node to the master node during the preparation phase carries the master node's digital signature and the slave node's digital signature, which are written to the "preparation phase signature" field.

[0145] S703: When the master node receives response messages from more than half of the total number of nodes (including the master node itself), the master node executes the second phase (commit phase), committing the data and notifying other slave nodes to commit their data. Upon receiving the commit notification, a slave node can write data to its own blockchain and return a response message to the master node.

[0146] When the master node receives the preparation phase response message returned by the slave node, it can collect and aggregate the slave node's digital signature carried in each response message.

[0147] After entering the commit phase, the master node can send a commit notification carrying the aggregated digital signature to each slave node. Figure 5 Taking the data structure shown as an example, the commit notification sent by the master node to the slave nodes carries the master node's digital signature and multiple slave node digital signatures written to the "Preparation Phase Signature" field, as well as the master node's digital signature written to the "Commit Phase Signature" field. The number of master node and slave node digital signatures in the "Preparation Phase Signature" field should exceed half the total number of nodes, thus satisfying the consensus condition for the low-fault-tolerance consensus algorithm during the preparation phase.

[0148] When a slave node receives a commit notification from the master node, it can perform signature verification in the same way as in the previous stage, and write its own slave node digital signature into the response message after successful verification. Figure 5 Taking the data structure shown as an example, the response message of the commit phase returned by the slave node to the master node carries the master node's digital signature and multiple slave node digital signatures written in the "preparation phase signature" field, as well as the master node's digital signature written in the "commit phase signature" field and the slave node's own slave node digital signature.

[0149] S704: The master node returns a response to the client indicating that the data has been successfully written. At this point, the client can confirm that the data has been successfully written into the entire blockchain system.

[0150] When the master node receives the commit phase response message from the slave node, it can collect and aggregate the slave node's digital signature carried in each response message. Figure 5 Taking the data structure shown as an example, the response message returned by the master node to the client carries the master node's digital signature and multiple slave node digital signatures written to the "Preparation Phase Signature" field, as well as the master node's digital signature and multiple slave node digital signatures written to the "Commit Phase Signature" field. The number of master node and slave node digital signatures in the "Preparation Phase Signature" field should exceed half the total number of nodes, and the number of master node and slave node digital signatures in the "Commit Phase Signature" field should also exceed half the total number of nodes, thus satisfying the consensus conditions for the low-fault-tolerance consensus algorithm in the preparation and commit phases.

[0151] Figure 8 The diagram illustrates the consensus process of a high fault-tolerant consensus algorithm in one embodiment of this application. The high fault-tolerant consensus algorithm can be, for example, the PBFT algorithm within the BFT-type consensus algorithm. Compared to CFT-type consensus algorithms, BFT-type consensus algorithms need to maintain system consistency even in the event of software errors or malicious node behavior. Therefore, node interactions in BFT-type algorithms are more complex, typically requiring three stages of interaction; they also have fewer fault-tolerant nodes, generally tolerating 1 / 3 of faulty nodes.

[0152] like Figure 8 As shown, the consensus authentication process based on a high fault-tolerant consensus algorithm can include the following steps.

[0153] S801: The client sends a consensus request to the master node. A consensus request can be, for example, a write request to write data to the blockchain.

[0154] S802: The master node performs the first phase of node interaction (preparation phase), distributing the authentication request to other slave nodes. Once a slave node receives the authentication request and completes consensus processing, it can return a response message to the master node. The purpose of this phase is to confirm that multiple slave nodes have received the same request, preventing the master node from maliciously sending different messages to different slave nodes.

[0155] During the pre-preparation phase, the master node sends authentication requests to other slave nodes, carrying the data to be written to the blockchain, and using the master node's private key to perform digest processing and encryption on that data to obtain the master node's digital signature. Figure 5 Taking the data structure shown as an example, the authentication request sent by the master node to the slave node carries the master node's digital signature written in the "preparation phase signature" field.

[0156] When a slave node receives an authentication request from the master node, it can use the master node's public key to verify the digital signature carried in the authentication request. After successful signature verification, the slave node can use its own private key to perform digest processing and encryption on the data to be written to the blockchain to obtain the slave node's digital signature. Figure 5 Taking the data structure shown as an example, the response message of the pre-preparation phase returned by the slave node to the master node carries the master node's digital signature and the slave node's digital signature written in the "pre-preparation phase signature" field.

[0157] S803: When the master node receives response messages from more than 2 / 3 of the total number of nodes in the pre-preparation phase (including the master node itself), the master node executes the second phase (preparation phase), in which the master node signs the message and sends it to the other slave nodes. The slave nodes verify whether the number of message signatures is greater than 2 / 3 of the total number of nodes. If it is greater than 2 / 3, the slave node returns a response message to the master node indicating that it has successfully voted.

[0158] When the master node receives the pre-preparation phase response message from the slave node, it can collect and aggregate the slave node's digital signature carried in each response message.

[0159] After entering the preparation phase, the master node can send a preparation message carrying the aggregated digital signature to each slave node. Figure 5 Taking the data structure shown as an example, the preparation message sent by the master node to the slave nodes carries the master node's digital signature and multiple slave node digital signatures written into the "Pre-preparation Phase Signature" field, as well as the master node's digital signature written into the "Preparation Phase Signature" field. The number of master node and slave node digital signatures in the "Pre-preparation Phase Signature" field should exceed 2 / 3 of the total number of nodes, thus satisfying the consensus condition for a high-fault-tolerant consensus algorithm in the pre-preparation phase.

[0160] After receiving the preparation message from the master node, the slave node can perform signature verification in the same way as in the previous stage, and write its own slave node digital signature into the response message after successful verification. Figure 5 Taking the data structure shown as an example, the response message returned by the slave node to the master node during the preparation phase carries the master node's digital signature and multiple slave node digital signatures in the "Preparation Phase Signature" field, as well as the master node's digital signature and the slave node's own digital signature in the "Commit Phase Signature" field.

[0161] S804: When the master node receives response messages from more than 2 / 3 of the total number of nodes (including the master node itself), the master node executes the third phase (commit phase), committing the data and notifying other slave nodes to commit their data. Upon receiving the commit notification, a slave node can write data to its own blockchain and return a response message to the master node.

[0162] When the master node receives the preparation phase response message returned by the slave node, it can collect and aggregate the slave node's digital signature carried in each response message.

[0163] After entering the commit phase, the master node can send a commit notification carrying the aggregated digital signature to each slave node. Figure 5 Taking the data structure shown as an example, the commit notification sent by the master node to the slave nodes carries the master node's digital signature and multiple slave node digital signatures written to the "Preparation Phase Signature" field, as well as the master node's digital signature and multiple slave node digital signatures written to the "Preparation Phase Signature" field, and the master node's digital signature written to the "Commit Phase Signature" field. The number of master node and slave node digital signatures in the "Preparation Phase Signature" field should exceed 2 / 3 of the total number of nodes, and the number of master node and slave node digital signatures in the "Preparation Phase Signature" field should also exceed 2 / 3 of the total number of nodes, thus satisfying the consensus conditions of the high fault-tolerant consensus algorithm in the preparation and preparation phases.

[0164] When a slave node receives a preparation message from the master node, it can perform signature verification in the same way as in the previous stage, and write its own slave node digital signature into the response message after successful verification. Figure 5 Taking the data structure shown as an example, the response message of the commit phase returned by the slave node to the master node carries the master node's digital signature and multiple slave node digital signatures written in the "preparation phase signature" field, as well as the master node's digital signature and multiple slave node digital signatures written in the "preparation phase signature" field, and the master node's digital signature and the slave node's own slave node digital signature written in the "commit phase signature" field.

[0165] S805: The master node returns a successful data write response to the client. At this point, the client can confirm that the data has been successfully written into the entire blockchain system.

[0166] When the master node receives the commit phase response message from the slave node, it can collect and aggregate the slave node's digital signature carried in each response message. Figure 5Taking the data structure shown as an example, the response message returned by the master node to the client carries the master node's digital signature and multiple slave node digital signatures written to the "Preparation Phase Signature" field, as well as the master node's digital signature and multiple slave node digital signatures written to the "Preparation Phase Signature" field, and the master node's digital signature and multiple slave node digital signatures written to the "Commit Phase Signature" field. The number of master node and slave node digital signatures in the "Preparation Phase Signature" field, the number of master node and slave node digital signatures in the "Preparation Phase Signature" field, and the number of master node and slave node digital signatures in the "Commit Phase Signature" field should all exceed 2 / 3 of the total number of nodes. This satisfies the consensus conditions of the high fault-tolerant consensus algorithm in the preparation, preparation, and commit phases.

[0167] In existing blockchain systems, one type prioritizes system performance and employs CFT-type consensus mechanisms, such as Fabric; the other prioritizes broader fault tolerance and employs BFT-type consensus mechanisms, such as Tendrmint. In practical enterprise applications, upper-layer business systems using blockchain services have varying requirements in terms of performance, availability, fault tolerance, and scalability as user needs evolve. Current blockchain systems, employing a single consensus algorithm, cannot meet the requirements of these upper-layer business systems. This application provides a solution for flexible online switching between CFT and BFT algorithms, allowing the blockchain system to change its consensus algorithm to meet the requirements of the business system without interrupting service.

[0168] In one embodiment of this application, during the broadcasting of a consensus request in a blockchain network, the algorithm of some or all blockchain nodes in the blockchain network can be switched to change the consensus algorithm executed by some or all blockchain nodes.

[0169] When some blockchain nodes complete the algorithm switch while others do not, there will be at least two types of blockchain nodes executing different consensus algorithms in the blockchain network. Based on this, consensus authentication can be performed using the embodiments described above in this application.

[0170] In one embodiment of this application, a method for switching the algorithm of some or all blockchain nodes in a blockchain network may include:

[0171] Trustworthiness prediction is performed on blockchain networks to determine whether the operating environment of the blockchain network is a trustworthy environment;

[0172] If the blockchain network operates in a trusted environment, then some or all of the blockchain nodes in the blockchain network will be switched from executing a low fault-tolerant consensus algorithm to executing a high fault-tolerant consensus algorithm.

[0173] If the blockchain network operates in an untrusted environment, some or all of the blockchain nodes in the blockchain network will be switched from executing a high fault-tolerant consensus algorithm to executing a low fault-tolerant consensus algorithm.

[0174] In one embodiment of this application, a method for predicting the trustworthiness of a blockchain network may include:

[0175] Obtain the runtime of each blockchain node in the blockchain network;

[0176] If the runtime is less than the duration threshold, the blockchain node is determined to be an untrusted node.

[0177] If the number of untrusted nodes in the blockchain network exceeds a certain threshold, the operating environment of the blockchain network is determined to be an untrusted environment.

[0178] If the number of untrusted nodes in the blockchain network is less than a threshold, then the operating environment of the blockchain network is determined to be a trusted environment.

[0179] For example, in supply chain management scenarios, blockchain systems are often initiated by companies at a specific link in the supply chain process. In this case, the blockchain system can be considered to be in a trusted environment, and there is no need to consider the possibility of malicious nodes. A simple CFT algorithm can be used as the consensus algorithm. When other companies in the supply chain join the blockchain system, to prevent other companies from intentionally causing harm, the algorithm switching steps of this application embodiment can be executed to switch the consensus algorithm to a BFT-type algorithm without stopping the service. After the blockchain system has been running stably for a period of time and all participating companies can be considered trusted nodes, the algorithm switching steps of this application embodiment can be executed again to switch the consensus algorithm to a CFT-type algorithm to improve the performance of the blockchain system.

[0180] Figure 9 This illustration shows a scenario example of algorithm switching in an embodiment of this application. Taking the algorithm switching of four nodes as an example, each blockchain node will execute different consensus algorithms at different times during the algorithm switching.

[0181] When two consensus algorithms with different distribution ratios exist in a blockchain network, it can form a... Figure 8The five scenarios are illustrated. In the transition from CFT consensus to BFT consensus, nodes gradually switch from all using CFT consensus algorithms to all using BFT-like consensus algorithms; that is, scenario one gradually changes into scenario five. Conversely, in the transition from BFT consensus to CFT consensus, nodes gradually switch from all using BFT consensus algorithms to all using CFT-like consensus algorithms; that is, scenario five gradually changes into scenario one.

[0182] Table 1 shows the proportion of blockchain nodes executing different consensus algorithms to the total number of nodes in five different scenarios.

[0183] Table 1

[0184] Scene 1 ＝1 ＝0 Scene 2 >1 / 2 <1 / 2 Scene 3 <1 / 2 and >1 / 3 >1 / 2 and <2 / 3 Scene 4 <1 / 3 >2 / 3 Scene 5 ＝0 ＝1

[0185] The consensus schemes for five application scenarios are described below.

[0186] Scene 1:

[0187] In Scenario 1, since all nodes use CFT as their consensus algorithm, this scenario is equivalent to using CFT as the sole algorithm. As long as all nodes follow their local CFT algorithm steps, the system data can reach consensus.

[0188] Scene 2:

[0189] In scenario two, only node one uses the BFT algorithm for consensus, while the other three nodes use the CFT algorithm. At this point, the total number of CFT nodes (3) is greater than half the total number of nodes (4). According to the consensus conditions of the CFT algorithm, the three CFT nodes can reach a consensus. After reaching a consensus, node one synchronizes the consensus result, ensuring data consistency across the system.

[0190] Scene 3:

[0191] In scenario three, the number of CFT nodes does not meet the consensus condition of more than 1 / 2 required by the CFT algorithm, and the number of BFT nodes also does not meet the consensus condition of more than 2 / 3 required by the BFT algorithm. In this situation, according to the normal CFT or BFT algorithm, all nodes in the system will fail to reach a consensus.

[0192] In this scenario, embodiments of this application may use devices having, for example... Figure 5 The data structure shown enables data interaction between nodes through response messages.

[0193] refer to Figure 5 As shown, this data structure includes three signature fields: pre-preparation phase signature, preparation phase signature, and submission phase signature. CFT consensus nodes use the pre-preparation phase signature and the submission phase signature; BFT consensus nodes use the signatures of all three phases.

[0194] Figure 10 This document illustrates a flowchart of the method steps for performing consensus authentication in an application scenario according to an embodiment of this application. Figure 10 As shown, in Scenario 3 above, the method for performing consensus authentication may include the following steps.

[0195] S1001: The master node receives consensus requests sent by the client.

[0196] S1002: The master node sends a <prepared> message to the slave node.

[0197] S1003: The slave node replies to the master node with the <Preparation> message.

[0198] The preparation phase of CFT-type consensus algorithms matches the pre-preparation phase of BFT-type consensus algorithms. Therefore, nodes using CFT-type consensus algorithms can treat the <preparation> message as a <preparation> message. In this case, both slave nodes using CFT-type consensus and slave nodes using BFT-type consensus will reply with the <preparation> message to the master node.

[0199] S1004: The master node determines whether it has received more than 2 / 3 of the total number of nodes' <preparation> messages.

[0200] If less than 2 / 3 are reached, return to step S1003 and continue receiving <pre-preparation> messages from other slave nodes. If more than 2 / 3 are reached, the consensus authentication in the pre-preparation phase is completed, the process enters the preparation phase, and step S1005 is executed.

[0201] S1005: The master node sends a <prepared> message to the slave node.

[0202] S1006: Determine whether the slave node that received the <Prepare> message is a CFT node executing a CFT-type consensus algorithm. If the determination result is yes, proceed to step S1007. If the determination result is no, it means that the slave node is a BFT node executing a BFT-type consensus algorithm, and jump to step S10010.

[0203] S1007: Submit data from the node.

[0204] When a slave node using a CFT-type consensus algorithm receives a "Ready" message from the master node, it indicates that the master node has received more than 2 / 3 of the "Pre-Ready" messages. This exceeds the 1 / 2 requirement of the CFT algorithm, so the slave node executing the CFT-type consensus algorithm can treat the "Ready" message as a "Commit" message and directly commit the data. At this point, the nodes using the CFT-type consensus algorithm can reach a consensus, and the data is consistent.

[0205] S1008: The slave node replies to the master node with a <commit> message.

[0206] After completing the data submission, the slave node executing the CFT-type consensus algorithm returns a <commit> message to the master node, so that other BFT-type nodes reach the submission condition that the total number of <prepared> + <committed> messages reaches 2 / 3. Then, step S1010 is executed.

[0207] S1009: The slave node replies to the master node with the <Prepare> message.

[0208] S1010: The master node determines whether it has received more than 2 / 3 of the total number of nodes' <Ready> messages.

[0209] If the consensus is less than 2 / 3, proceed to step S1011. If the consensus is greater than 2 / 3, complete the consensus authentication in the preparation phase, enter the submission phase, and proceed to step S1012.

[0210] S1011: The master node determines whether it has received more than 2 / 3 of the total number of nodes' <Prepare> and <Commit> messages.

[0211] The commit phase of CFT-type consensus algorithms matches the preparation and commit phases of BFT-type consensus algorithms. Therefore, when the master node receives a <commit> message response from a CFT node, it can treat the <commit> message response as a <preparation> message response. Based on this, if the master node receives more than two-thirds of the total number of <preparation> and <commit> messages, it completes the consensus authentication in the preparation phase, enters the commit phase, and continues executing step S1012. If the master node does not receive more than two-thirds of the total number of <preparation> and <commit> messages, it returns to step S1005, and the master node continues to send <preparation> messages to other slave nodes.

[0212] S1012: The master node sends a <commit> message to the slave node.

[0213] S1013: Each slave node submits data and returns a <commit> message to the master node, and the system reaches a consensus.

[0214] Nodes using BFT-based consensus can reach a response rate greater than 2 / 3 of the <ready> messages. At this point, BFT-based consensus nodes can reach consensus by following the steps of the BFT algorithm, and data consistency with CFT-based nodes can be guaranteed.

[0215] Scene 4:

[0216] In scenario four, node four executes the CFT-type consensus algorithm, while the other three nodes execute the BFT-type consensus algorithm. At this point, the total number of BFT nodes (3) is greater than 2 / 3 of the total number of nodes (4). According to the BFT-type consensus algorithm, the three BFT nodes can reach a consensus. After reaching a consensus, node four synchronizes the consensus result, which can ensure the consistency of system data.

[0217] Scene 5:

[0218] In scenario five, all nodes execute a BFT-type consensus algorithm, and the system can reach a consensus by following the steps of the BFT-type consensus algorithm.

[0219] As can be seen from the above descriptions of various application scenarios, the online consensus algorithm switching scheme provided in this application embodiment can support switching consensus algorithms without stopping the service, making the blockchain system more flexible in adapting to the needs of upper-layer business, and enabling the blockchain system to be more widely used in different scenarios.

[0220] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0221] The following describes an apparatus embodiment of this application, which can be used to execute the blockchain consensus method in the above embodiments of this application. Figure 11 A schematic block diagram of a blockchain consensus device provided in an embodiment of this application is shown. Figure 11 As shown, the blockchain consensus device 1100 includes:

[0222] Request module 1110 is configured to broadcast consensus requests corresponding to at least two consensus phases in a blockchain network, said blockchain network comprising at least two types of blockchain nodes that execute different types of consensus algorithms;

[0223] The response module 1120 is configured to acquire response messages broadcast by the blockchain network in each consensus phase, wherein the response message is a message in which the blockchain node responds to the consensus request;

[0224] The statistics module 1130 is configured to count the number of blockchain nodes that issue the response message in the same consensus phase, the number of nodes including the number of blockchain nodes that execute at least two different types of consensus algorithms;

[0225] The synchronization module 1140 is configured to reach a consensus on the blockchain nodes executing the first consensus algorithm if the number of nodes meets the consensus conditions of the first consensus algorithm, and to synchronize the consensus result of the first consensus algorithm to the blockchain nodes executing the second consensus algorithm. The first consensus algorithm and the second consensus algorithm are different types of consensus algorithms.

[0226] In one embodiment of this application, based on the above embodiments, different types of consensus algorithms have different numbers of consensus stages. The response message carries the algorithm type and node signature of the blockchain node. The algorithm type is used to indicate the consensus algorithm executed by the blockchain node, and the node signature includes the digital signature of the blockchain node in each consensus stage.

[0227] In one embodiment of this application, based on the above embodiments, the statistics module 1030 may further include:

[0228] The parsing module is configured to parse the response message to obtain the algorithm type and node signature carried in the response message;

[0229] The algorithm identification module is configured to identify the consensus algorithm executed by the message sending node according to the algorithm type, wherein the message sending node is the blockchain node that sends the response message;

[0230] The phase identification module is configured to identify the consensus phase of the message sending node based on the node signature.

[0231] The quantity statistics module is configured to count the number of message sending nodes that are in the same consensus stage as the current blockchain node, based on the consensus algorithm executed by the message sending node and the consensus stage in which the message sending node is located.

[0232] In one embodiment of this application, based on the above embodiments, the statistics module 1030 may further include:

[0233] The relationship acquisition module is configured to acquire the matching relationship between consensus stages of different types of consensus algorithms;

[0234] The node determination module is configured to determine the message sending node that is in the same consensus stage as the current blockchain node based on the matching relationship if the message sending node and the current blockchain node execute different types of consensus algorithms.

[0235] In one embodiment of this application, based on the above embodiments, the first consensus algorithm includes N consensus stages, and the second consensus algorithm includes M consensus stages; the matching relationship of consensus stages between different types of consensus algorithms includes:

[0236] The first consensus algorithm and the second consensus algorithm are matched in the first P consensus stages, where P is the smaller of (N-1) and (M-1);

[0237] The last (NP) consensus phases of the first consensus algorithm are matched with the last (MP) consensus phases of the second consensus algorithm.

[0238] In one embodiment of this application, based on the above embodiments, after counting the number of message-sending nodes that are in the same consensus stage as the current blockchain node, the statistics module 1030 may further include:

[0239] The consensus result determination module is configured to determine the consensus result of the consensus algorithm based on whether the number of nodes meets the consensus conditions of the consensus algorithm if the consensus stage in which the current blockchain node is in is the last consensus stage of the consensus algorithm.

[0240] The consensus phase execution module is configured to determine whether to execute the next consensus phase of the consensus algorithm if the current consensus phase of the blockchain node is not the last consensus phase of the consensus algorithm, based on whether the number of nodes meets the consensus conditions of the consensus algorithm.

[0241] In one embodiment of this application, based on the above embodiments, the first consensus algorithm is one of a low fault tolerance consensus algorithm and a high fault tolerance consensus algorithm, and the second consensus algorithm is the other of the low fault tolerance consensus algorithm and the high fault tolerance consensus algorithm;

[0242] The consensus condition for the low fault tolerance consensus algorithm is that the ratio of the number of blockchain nodes sending response messages to the total number of blockchain nodes is greater than a first ratio threshold. The consensus condition for the high fault tolerance consensus algorithm is that the ratio of the number of blockchain nodes sending response messages to the total number of blockchain nodes is greater than a second ratio threshold, where the first ratio threshold is less than the second ratio threshold.

[0243] In one embodiment of this application, based on the above embodiments, the low fault tolerance consensus algorithm has a first number of consensus stages, and the high fault tolerance consensus algorithm has a second number of consensus stages, wherein the first number is less than the second number.

[0244] In one embodiment of this application, based on the above embodiments, the consensus phase of the low fault tolerance consensus algorithm includes a preparation phase and a submission phase executed sequentially, and the consensus phase of the high fault tolerance consensus algorithm includes a pre-preparation phase, a preparation phase, and a submission phase executed sequentially. The preparation phase of the low fault tolerance consensus algorithm matches the pre-preparation phase of the high fault tolerance consensus algorithm, and the submission phase of the low fault tolerance consensus algorithm matches the preparation phase and the submission phase of the high fault tolerance consensus algorithm.

[0245] In one embodiment of this application, based on the above embodiments, the blockchain consensus device 1000 may further include:

[0246] The algorithm switching module is configured to switch the algorithms of some or all of the blockchain nodes in the blockchain network to change the consensus algorithm executed by the some or all of the blockchain nodes.

[0247] In one embodiment of this application, based on the above embodiments, the algorithm switching module may further include:

[0248] The credibility detection module is configured to perform credibility prediction on the blockchain network to determine whether the operating environment of the blockchain network is a trustworthy environment.

[0249] The first algorithm switching module is configured to switch some or all of the blockchain nodes in the blockchain network from executing a low fault-tolerant consensus algorithm to executing a high fault-tolerant consensus algorithm if the operating environment of the blockchain network is a trusted environment.

[0250] The second algorithm switching module is configured to switch some or all of the blockchain nodes in the blockchain network from executing a high fault-tolerant consensus algorithm to executing a low fault-tolerant consensus algorithm if the operating environment of the blockchain network is an untrusted environment.

[0251] In one embodiment of this application, based on the above embodiments, the credibility prediction of the blockchain network may be performed, and the credibility detection module may further include:

[0252] The duration acquisition module is configured to acquire the runtime of each blockchain node in the blockchain network;

[0253] The untrusted node determination module is configured to determine the blockchain node as an untrusted node if the runtime is less than a duration threshold.

[0254] The untrusted environment determination module is configured to determine that the operating environment of the blockchain network is an untrusted environment if the number of untrusted nodes in the blockchain network is greater than a number threshold.

[0255] The trusted environment determination module is configured to determine the operating environment of the blockchain network as a trusted environment if the number of untrusted nodes in the blockchain network is less than a number threshold.

[0256] The specific details of the blockchain consensus device provided in the various embodiments of this application have been described in detail in the corresponding method embodiments, and will not be repeated here.

[0257] Figure 12 A schematic block diagram of a computer system architecture for implementing an electronic device according to embodiments of the present application is shown.

[0258] It should be noted that, Figure 12The computer system 1200 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0259] like Figure 12 As shown, the computer system 1200 includes a central processing unit (CPU) 1201, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1202 or programs loaded from storage section 1208 into random access memory (RAM). The RAM 1203 also stores various programs and data required for system operation. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An input / output interface 1205 (I / O interface) is also connected to the bus 1204.

[0260] The following components are connected to the input / output interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a local area network card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to the input / output interface 1205 as needed. A removable medium 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1210 as needed so that computer programs read from it can be installed into the storage section 1208 as needed.

[0261] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by central processing unit 1201, it performs various functions defined in the system of this application.

[0262] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0263] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0264] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0265] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0266] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0267] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A blockchain consensus method, characterized in that, The method includes: Broadcasting consensus requests corresponding to at least two consensus phases in a blockchain network, the blockchain network comprising at least two types of blockchain nodes executing different types of consensus algorithms; The response messages broadcast by the blockchain network in each consensus phase are obtained respectively, and the response messages are messages in which the blockchain nodes respond to the consensus request; The number of blockchain nodes that send the response message in the same consensus phase is counted, including the number of blockchain nodes that execute at least two different types of consensus algorithms; If the number of nodes meets the consensus condition of the first consensus algorithm, a consensus is reached on the blockchain node executing the first consensus algorithm, and the consensus result of the first consensus algorithm is synchronized to the blockchain node executing the second consensus algorithm. The first consensus algorithm and the second consensus algorithm are different types of consensus algorithms. Wherein, the first consensus algorithm is one of a low fault tolerance consensus algorithm and a high fault tolerance consensus algorithm, and the second consensus algorithm is the other of the low fault tolerance consensus algorithm and the high fault tolerance consensus algorithm; the consensus condition of the low fault tolerance consensus algorithm is that the ratio of the number of blockchain nodes that send response messages to the total number of blockchain nodes is greater than a first ratio threshold, and the consensus condition of the high fault tolerance consensus algorithm is that the ratio of the number of blockchain nodes that send response messages to the total number of blockchain nodes is greater than a second ratio threshold, wherein the first ratio threshold is less than the second ratio threshold; The first consensus algorithm includes N consensus phases, and the second consensus algorithm includes M consensus phases. The matching relationship between consensus phases of different types of consensus algorithms includes: the first consensus algorithm and the second consensus algorithm are matched with each other for the first P consensus phases, where P is the smaller value between (N-1) and (M-1); the last (NP) consensus phases of the first consensus algorithm are matched with the last (MP) consensus phases of the second consensus algorithm.

2. The blockchain consensus method according to claim 1, characterized in that, Different types of consensus algorithms have different numbers of consensus stages. The response message carries the algorithm type and node signature of the blockchain node. The algorithm type is used to indicate the consensus algorithm executed by the blockchain node, and the node signature includes the digital signature of the blockchain node at each consensus stage.

3. The blockchain consensus method according to claim 2, characterized in that, The number of blockchain nodes that issued the response message during the same consensus phase includes: Parse the response message to obtain the algorithm type and node signature carried in the response message; The consensus algorithm executed by the message sending node is identified according to the algorithm type, and the message sending node is the blockchain node that issued the response message; The consensus phase of the message-sending node is identified based on the node signature. Based on the consensus algorithm executed by the message sending node and the consensus stage in which the message sending node is located, count the number of message sending nodes that are in the same consensus stage as the current blockchain node.

4. The blockchain consensus method according to claim 3, characterized in that, Before counting the number of message-sending nodes that are at the same consensus stage as the current blockchain node, the method further includes: Obtain the matching relationship of consensus stages between different types of consensus algorithms; If the message sending node and the current blockchain node execute different types of consensus algorithms, then the message sending node that is in the same consensus stage as the current blockchain node is determined according to the matching relationship.

5. The blockchain consensus method according to claim 3, characterized in that, After counting the number of message-sending nodes that are at the same consensus stage as the current blockchain node, the method further includes: If the consensus stage currently being reached by the blockchain node is the last consensus stage of the consensus algorithm, then the consensus result of the consensus algorithm is determined based on whether the number of nodes meets the consensus conditions of the consensus algorithm. If the consensus phase currently being reached by the blockchain node is not the last consensus phase of the consensus algorithm, then the decision on whether to execute the next consensus phase of the consensus algorithm is made based on whether the number of nodes meets the consensus conditions of the consensus algorithm.

6. The blockchain consensus method according to claim 1, characterized in that, The low-fault-tolerant consensus algorithm has a first number of consensus stages, and the high-fault-tolerant consensus algorithm has a second number of consensus stages, wherein the first number is less than the second number.

7. The blockchain consensus method according to claim 6, characterized in that, The consensus phase of the low fault tolerance consensus algorithm includes a preparation phase and a submission phase executed sequentially. The consensus phase of the high fault tolerance consensus algorithm includes a pre-preparation phase, a preparation phase, and a submission phase executed sequentially. The preparation phase of the low fault tolerance consensus algorithm matches the pre-preparation phase of the high fault tolerance consensus algorithm, and the submission phase of the low fault tolerance consensus algorithm matches the preparation phase and the submission phase of the high fault tolerance consensus algorithm.

8. The blockchain consensus method according to claim 1, characterized in that, During the process of broadcasting consensus requests in a blockchain network, the method further includes: Algorithm switching is performed on some or all of the blockchain nodes in the blockchain network to change the consensus algorithm executed by those some or all blockchain nodes.

9. The blockchain consensus method according to claim 8, characterized in that, Algorithm switching is performed on some or all of the blockchain nodes in the blockchain network, including: The credibility of the blockchain network is predicted to determine whether the operating environment of the blockchain network is a trustworthy environment. If the blockchain network operates in a trusted environment, then some or all of the blockchain nodes in the blockchain network will be switched from executing a low-fault-tolerant consensus algorithm to executing a high-fault-tolerant consensus algorithm. If the blockchain network operates in an untrusted environment, some or all of the blockchain nodes in the blockchain network will be switched from executing a high-fault-tolerant consensus algorithm to executing a low-fault-tolerant consensus algorithm.

10. The blockchain consensus method according to claim 9, characterized in that, The credibility prediction of the blockchain network includes: Obtain the runtime of each blockchain node in the blockchain network; If the runtime is less than the runtime threshold, the blockchain node is determined to be an untrusted node. If the number of untrusted nodes in the blockchain network exceeds a threshold, then the operating environment of the blockchain network is determined to be an untrusted environment. If the number of untrusted nodes in the blockchain network is less than a threshold, then the operating environment of the blockchain network is determined to be a trusted environment.

11. A blockchain consensus device, characterized in that, include: The request module is configured to broadcast consensus requests corresponding to at least two consensus phases in a blockchain network, the blockchain network comprising at least two types of blockchain nodes that execute different types of consensus algorithms; The response module is configured to acquire response messages broadcast by the blockchain network in each consensus phase, wherein the response message is a message in which the blockchain node responds to the consensus request; The statistics module is configured to count the number of blockchain nodes that issue the response message in the same consensus phase, the number of nodes including the number of blockchain nodes that execute at least two different types of consensus algorithms; The synchronization module is configured to reach a consensus on the blockchain nodes executing the first consensus algorithm if the number of nodes meets the consensus conditions of the first consensus algorithm, and synchronize the consensus result of the first consensus algorithm to the blockchain nodes executing the second consensus algorithm. The first consensus algorithm and the second consensus algorithm are different types of consensus algorithms. Wherein, the first consensus algorithm is one of a low fault tolerance consensus algorithm and a high fault tolerance consensus algorithm, and the second consensus algorithm is the other of the low fault tolerance consensus algorithm and the high fault tolerance consensus algorithm; the consensus condition of the low fault tolerance consensus algorithm is that the ratio of the number of blockchain nodes that send response messages to the total number of blockchain nodes is greater than a first ratio threshold, and the consensus condition of the high fault tolerance consensus algorithm is that the ratio of the number of blockchain nodes that send response messages to the total number of blockchain nodes is greater than a second ratio threshold, wherein the first ratio threshold is less than the second ratio threshold; The first consensus algorithm includes N consensus phases, and the second consensus algorithm includes M consensus phases. The matching relationship between consensus phases of different types of consensus algorithms includes: the first consensus algorithm and the second consensus algorithm are matched with each other for the first P consensus phases, where P is the smaller value between (N-1) and (M-1); the last (NP) consensus phases of the first consensus algorithm are matched with the last (MP) consensus phases of the second consensus algorithm.

12. A computer-readable medium, characterized in that, The computer-readable medium stores a computer program that, when executed by a processor, implements the blockchain consensus method according to any one of claims 1 to 10.

13. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to cause the electronic device to perform the blockchain consensus method according to any one of claims 1 to 10 by executing the executable instructions.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the blockchain consensus method according to any one of claims 1 to 10.

Images