Blockchain consensus method, device, electronic device and program

Abstract

The present application belongs to the field of blockchain technology, and specifically relates to a blockchain consensus method, a blockchain consensus device, a computer-readable medium, an electronic device, and a computer program product. The method includes: broadcasting a consensus request corresponding to at least two consensus stages in a blockchain network, where the blockchain network includes at least two blockchain nodes that run different types of consensus algorithms; respectively obtaining a response message broadcast by the blockchain network in each consensus stage; counting the number of blockchain nodes that issue a response message in the same consensus stage; and if the number of nodes meets the consensus condition of the first consensus algorithm, achieving consensus on the blockchain node that runs the first consensus algorithm, and synchronizing the consensus result of the first consensus algorithm to the blockchain node that runs the second consensus algorithm, where the first consensus algorithm and the second consensus algorithm are different types of consensus algorithms. The present application can enhance the flexibility of blockchain consensus.

Description

[Technical Field]

[0001] This application claims priority from a Chinese patent application filed with the China Patent Office on June 2, 2022, bearing application number 202210622140.7 and entitled "Blockchain consensus method, apparatus, medium and electronic device," the entire contents of which are incorporated herein by reference.

[0002] This application belongs to the field of blockchain technology, and specifically relates to blockchain consensus. [Background technology]

[0003] In a blockchain network containing multiple blockchain nodes, in order to realize a distributed trust environment, all blockchain nodes generally need to run a unified consensus algorithm to synchronize data consistency among each node. However, a unified consensus algorithm has problems such as difficulty in meeting the business requirements of a diversified system and low flexibility. Summary of the Invention [Problem to be solved by the invention]

[0004] The present application provides a blockchain consensus method, a blockchain consensus device, a computer-readable medium, an electronic device, and a computer program product, with the purpose of enhancing the flexibility of blockchain consensus. [Means for solving the problem]

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

[0006] According to one aspect of the present invention, there is provided a blockchain consensus method, the method being executed by a current blockchain node in a blockchain network, the method comprising: Broadcasting consensus requests corresponding to at least two consensus stages in the blockchain network, where the blockchain network includes blockchain nodes that execute at least two different types of consensus algorithms, and the different types of consensus algorithms include a first consensus algorithm and a second consensus algorithm; Obtaining a response message broadcast by the blockchain network in each consensus stage, where the response message is a message in which the blockchain node responds to the consensus request; Counting the number of blockchain nodes that issued the response messages in the same consensus stage, where the number of nodes includes the number of blockchain nodes that execute at least two different types of consensus algorithms; If the number of nodes satisfies the consensus condition of the first consensus algorithm, achieving consensus on the blockchain nodes that execute the first consensus algorithm, and synchronizing the consensus result of the first consensus algorithm to the blockchain nodes that execute the second consensus algorithm.

[0007] According to one aspect of the present invention, there is provided a blockchain consensus device, the device comprising: a request module configured to broadcast a consensus request corresponding to at least two consensus stages in a blockchain network, the blockchain network including at least two blockchain nodes that execute consensus algorithms of different types, the different types of consensus algorithms including a first consensus algorithm and a second consensus algorithm; A response module configured to respectively obtain response messages broadcast by the blockchain network in each of the consensus stages, wherein the response messages are messages in which the blockchain nodes respond to the consensus request; A statistics module configured to count the number of blockchain nodes that issued the response messages in the same consensus stage, wherein the number of nodes includes the number of blockchain nodes that execute at least two different types of consensus algorithms; and a synchronization module configured to achieve consensus on the blockchain nodes that execute the first consensus algorithm if the number of nodes satisfies the consensus condition of the first consensus algorithm, and synchronize the consensus result of the first consensus algorithm to the blockchain nodes that execute the second consensus algorithm.

[0008] According to one aspect of the present embodiment, a computer-readable medium is provided, which stores a computer program, and when the computer program is executed by a processor, the blockchain consensus method in the above technical solution is realized.

[0009] According to one aspect of an embodiment of the present application, an electronic device is provided, the electronic device including a processor and a memory for storing executable instructions of the processor, the processor being configured to execute the blockchain consensus method in the above technical solution by executing the executable instructions.

[0010] According to one aspect of the present embodiment, a computer program product is provided, which includes a computer program, and when the computer program is executed by a processor, the blockchain consensus method in the above technical solution is realized.

[0011] In some embodiments of the present application, the computer program product or computer program includes a computer program stored in a computer-readable storage medium, and a processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program to cause the computer device to perform the blockchain consensus method in the above technical solution.

[0012] In the technical solution provided by the embodiments of the present application, by configuring at least two blockchain nodes that run different types of consensus algorithms in the blockchain network, the number of blockchain nodes that issue consensus responses can be counted in the process of implementing node consensus. If the number of nodes meets the consensus conditions of any one consensus algorithm, the consensus result can be synchronized from the blockchain nodes that meet the consensus conditions to the blockchain nodes that do not meet the consensus conditions, thereby increasing the flexibility of blockchain consensus.

[0013] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory and are not intended to limit the present application. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 is a schematic diagram illustrating the configuration of a blockchain system according to an embodiment of the present invention. [Figure 2] It is the structural structure of a blockchain maintained on a blockchain network. [Figure 3] 1 is an exemplary network structure of a blockchain network to which the present technical solution is applied. [Figure 4] FIG. 1 is a step flow diagram of a blockchain consensus method in one embodiment of the present application. [Figure 5] 10 illustrates a data structure of a response message in one embodiment of the present application. [Figure 6] 1 is a block chain consensus method for counting the number of nodes based on the consensus stage in one embodiment of the present application. [Figure 7] 1 illustrates a consensus flow of a low fault-tolerance consensus algorithm in one embodiment of the present application. [Figure 8] 1 illustrates a consensus flow of a highly fault-tolerant consensus algorithm in one embodiment of the present application. [Figure 9] 10 is a diagram illustrating an example of a scene in the process of executing algorithm switching in an embodiment of the present invention. [Figure 10] FIG. 1 is a step flow diagram of a method for performing consensus authentication in an application scenario according to an embodiment of the present invention. [Figure 11] FIG. 1 is a structural block diagram of a blockchain consensus device provided by an exemplary embodiment of the present application. [Figure 12] FIG. 1 is an architectural block diagram of a computer system of an electronic device suitable for implementing exemplary embodiments of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0015] Exemplary embodiments will now be described more fully with reference to the accompanying drawings, which illustrate, by way of example, that exemplary embodiments may be embodied in many different forms and should not be construed as being limited to the examples set forth herein; rather, the embodiments are provided to make this application more complete and complete so as to fully convey the concept of exemplary embodiments to those skilled in the art.

[0016] Furthermore, the depicted features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to facilitate a thorough understanding of the embodiments of the present application. However, as will be recognized by those skilled in the art, one or more of the details may not be specified when practicing the technical solutions of the present application, or other methods, units, devices, steps, etc. may be employed. In other cases, well-known methods, devices, implementations, and operations are not shown or described in detail to avoid obscuring aspects of the present application.

[0017] The block diagrams shown in the accompanying drawings are merely functional entities that do not necessarily correspond to physically separate entities, i.e., they may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different network and / or processor and / or microcontroller devices.

[0018] The flow charts shown in the accompanying drawings are merely illustrative and may not necessarily include all contents and operations / steps, or may not necessarily be performed in the order depicted. For example, some operations / steps may be further decomposed, and some operations / steps may be merged or partially merged, so that the actual order of execution may be changed according to actual circumstances.

[0019] In specific embodiments of the present application, with regard to related data such as requests and responses generated by users when applying blockchain products, permission or consent from users must be obtained when implementing each embodiment of the present application in a specific product or technology, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0020] A blockchain is a digital ledger with a chained-block data structure that is forgery-proof, tamper-proof, and traceable and is shared among peers in a peer network environment, built on transparent and trustworthy rules. A blockchain data structure stores transactions that occur over a certain period of time as blocks, and links the blocks in chronological order into a chain using an encryption algorithm. The ledger is distributed to all member nodes in the network, and the history of asset transactions that occur between peer nodes in the network is permanently recorded in a sequential chain of blocks linked using a hash encryption algorithm. All confirmed and verified transactions are chained from the chain header to the latest block, hence the name blockchain. The blockchain can be used as a single source of truth, and members in the blockchain network can only verify their own transactions.

[0021] FIG. 1 shows a schematic diagram of the configuration of a blockchain system in an embodiment of the present application. The blockchain system 100 may include at least one client 110 and a blockchain network 120, and the blockchain network 120 may include at least one blockchain node 121. The client 110 may be various electronic devices such as smartphones, tablet PCs, laptops, desktop computers, wearable devices, smart in-vehicle devices, smart payment terminals, and facial recognition terminals, and may provide blockchain data services to users by implementing corresponding client application programs. 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 even a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud memory, network services, cloud communications, middleware services, domain services, security services, CDNs, and big data and artificial intelligence platforms.

[0022] In the blockchain network 120, each blockchain node 121 can receive input information during normal operation and maintain shared data within the blockchain network based on the received input information. To ensure information interconnection, information links can exist between each blockchain node 121, and each blockchain node 121 can transmit information to each other through the information links. For example, when any blockchain node 121 in the blockchain network 120 receives input information and broadcasts the input information within the blockchain network 120, other node devices within the blockchain network 120 can obtain the input information based on a consensus algorithm and store the input information as shared data.

[0023] Each blockchain node 121 in the blockchain network 120 has a corresponding node identifier, and each blockchain node 121 in the blockchain network 120 stores the node identifiers of other blockchain nodes in the same blockchain network, and in a subsequent process can broadcast generated blocks to other nodes in the blockchain network 120 based on the node identifiers of other blockchain nodes. The blockchain node 121 can maintain a node identifier list shown in Table 1, and can associate and store node names and node identifiers in the node identifier list. The node identifier can be an IP (Internet Protocol, an interconnection protocol between networks) address or any other type of information that can be used to identify the node, and Table 1 is a node identifier list using IP addresses as an example.

[0024] [Table 1]

[0025] Figure 2 shows the configuration structure of a blockchain maintained on a blockchain network. As shown in Figure 2, a blockchain consists of multiple sequentially linked blocks. When new data needs to be written to the blockchain, the data is aggregated into a newly created block, which is then linked to the end of the blockchain. A consensus algorithm ensures that newly added blocks at each node device 121 are completely identical. The current block data is recorded in the block body of each block, and the hash value of the previous block linked to it is also stored in the block header. If a change occurs in the transaction data in the previous block, the hash value of the current block also changes accordingly. This makes it difficult to tamper with data uploaded to the blockchain network, thereby increasing the reliability of shared data.

[0026] The network structure of a blockchain network to which the technical solution of the present application is applied is schematically shown in Figure 3. As shown in Figure 3, in an application scenario for realizing network transactions and network payments, a transaction subject node 310, a transaction platform node 320, and a resource allocation node 330 located in the blockchain network jointly maintain one or more blockchains 340.

[0027] The transaction subject node 310 is a blockchain node that provides transaction services for users, and may be, for example, a shop or individual merchant that conducts network transactions with users.

[0028] The transaction platform node 320 is a blockchain node that provides a transaction scene for network transactions, and can be, for example, an e-commerce site, an online shopping mall, or any business platform that provides network transaction services.

[0029] The resource allocation node 330 is a blockchain node that provides fund management and allocation services for network transactions, and may be, for example, a third-party payment institution.

[0030] When a user conducts a network transaction with the transaction subject node 310, the user pays the transaction funds to the transaction subject node 310 through an account opened on the resource allocation node 330, and the transaction platform node 320, in providing the transaction scenario, needs to deduct a certain amount of funds from the transaction funds as a platform service fee. To achieve reliable fund allocation between the transaction subject node 310 and the transaction platform node 320, a smart contract (e.g., a separate account contract) for appropriate fund allocation can be concluded based on the blockchain network. When a network transaction occurs, the resource allocation node 330 allocates funds to each subject in the transaction scenario according to the smart contract. All transaction data generated by network transactions on each blockchain node can be uploaded and stored via the blockchain 340. Distributed data storage can effectively avoid crises that could lead to a loss of trust.

[0031] Although errors such as node downtime, network failures, software errors, and malicious nodes can cause data stored between blockchain nodes to become inconsistent, a consensus algorithm defines a distributed algorithm for network interaction between a pair of nodes, ensuring data consistency between blockchain nodes even in a system environment where such errors occur. In the related technology of this application, all blockchain nodes in a blockchain network must adopt a unified consensus algorithm to perform consensus authentication and ensure consistency in the consensus process and consensus results. However, in actual blockchain business processes, upper-level business systems that use blockchain services are constantly changing in response to user demand, resulting in different requirements in terms of performance, availability, fault tolerance, scalability, and so on. Current blockchain networks only use a single consensus algorithm, which makes it difficult to adapt to the requirements of upper-level business systems. When it is necessary to change the consensus algorithm of blockchain nodes in a blockchain network, the entire blockchain network must be stopped, the algorithm change must be completed for all blockchain nodes, and then the blockchain network must be restarted with the new consensus algorithm. This type of consensus algorithm switching method is prone to long and frequent service interruptions, which not only reduces the efficiency of consensus algorithm switching but also has a significant impact on the continuity and stable reliability of services in the blockchain network.

[0032] In response to the above technical problems present in the related art, the present application provides a technical solution that enables online flexible switching between multiple different types of consensus algorithms, so that the consensus algorithm can be changed in real time to meet the requirements of the business system without the need for the blockchain system to stop service.

[0033] The following describes in detail the technical solutions provided by the present application, including the blockchain consensus method, blockchain consensus device, computer-readable medium, electronic device, and computer program product, in combination with specific embodiments.

[0034] Figure 4 shows a step flow diagram of a blockchain consensus method in one embodiment of the present application, which can be executed by the client or blockchain node shown in Figure 1. However, for the sake of convenience of explanation, any one blockchain node in the blockchain network is taken as the current blockchain node, the current blockchain node is taken as the executing entity that executes the embodiment of the present application, and the current blockchain node is set as the client shown in Figure 1. The blockchain consensus method in this embodiment will be described using the blockchain consensus method executed on the current blockchain node as an example. As shown in Figure 4, the blockchain consensus method in this embodiment of the present application includes the following steps S410 to S440.

[0035] S410: Broadcast a consensus request corresponding to at least two consensus stages in a blockchain network, where the blockchain network includes at least two blockchain nodes that execute different types of consensus algorithms.

[0036] The blockchain network in this embodiment may include any one of the following: a public chain, a private chain, or a consortium chain. A public chain has the highest degree of decentralization. Any node / participant on a public chain can read data on the chain, propose transactions, and compete for the right to record new blocks. Each node / participant can freely join and leave the public chain. A private chain is the opposite: its recording rights are controlled by an organization or institution, and data access rights are also controlled by that organization or institution. It has a smaller number of participants, and participants cannot join a private chain at will; they must pass the organization or institution's screening process. A consortium chain, also known as a community blockchain, refers to a blockchain in which the consensus process is controlled by pre-selected nodes. It is a hybrid of a public chain and a private chain, achieving "partial decentralization." Each node on the chain typically has a corresponding entity or organization, and participants are authorized to join the network, forming interest-based consortia to jointly maintain the operation of the blockchain. A consortium chain allows new participants to join an already established blockchain and share data, eliminating the need to build one from scratch. Whether it's a public chain, private chain, or consortium chain, they can all provide smart contract functionality. A smart contract on a blockchain is a contract that can be executed in response to transactions on the blockchain system. Smart contracts can be defined in code format.

[0037] A smart contract, also known as chaincode or application code, is a computer protocol designed to transmit, verify, and execute contracts in an information-based manner. It is placed in a program within a node of a blockchain network, contains the business logic that executes transactions, and operates in an isolated operating environment (e.g., a container or virtual machine). Each node in a blockchain system can manipulate data stored on the chain based on a contract program that is automatically executed under specific conditions. This allows for two-way interaction between the business entity and the blockchain, and is an important route for implementing business logic using the blockchain. The purpose of smart contracts is to provide better security than traditional contracts and reduce other transaction costs associated with contracts. They allow reliable transactions without third parties, and these transactions are traceable and irreversible.

[0038] Transaction data generated based on smart contracts must be authenticated by consensus 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 the present application, when a user performs a network transaction through a client operating a blockchain system to generate transaction data, the client can send a consensus request to the blockchain node communicating with it, and the blockchain node that receives 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.

[0039] In an embodiment of the present application, at least two different types of consensus algorithms can be simultaneously operated on a blockchain network. For example, some blockchain nodes in the blockchain network can run a first consensus algorithm, and other blockchain nodes can run 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 different consensus conditions. The first consensus algorithm and the second consensus algorithm can have the same number of consensus stages or different numbers of consensus stages.

[0040] In one embodiment of the present application, one or more blockchain nodes can be selected from the blockchain network as master nodes to process consensus requests, and other blockchain nodes in the blockchain network other than the master node are slave nodes. When a client generates a consensus request, it can first send the consensus request to the master node, and the master node will again distribute the consensus request to each slave node. Master nodes can be generated by voting election, rotation assignment, random selection, or other methods.

[0041] S420: Obtain the response messages broadcast by the blockchain network at each consensus stage, where the response messages are messages from blockchain nodes responding to the consensus request.

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

[0043] In one embodiment of the present application, a blockchain node can perform consensus verification on a received consensus request and broadcast a response message on the blockchain network after passing the verification. The consensus verification of a blockchain node's consensus request can include two aspects: signature verification and data verification. Signature verification is used to verify the authenticity of the source of the consensus request, and data verification is used to verify the authenticity of the content of the consensus request.

[0044] In one embodiment of the present application, a consensus request broadcast within a blockchain network carries the digital signature of the blockchain node that issued the consensus request, and a response message broadcast within the blockchain network similarly carries the digital signature of the blockchain node that issued the response message. Each blockchain node in the blockchain network may possess a public key and a private key that constitute an asymmetric cryptographic key pair. When digitally signing a consensus request or response message, the node first extracts a content digest from the data content using a digest extraction algorithm, and then uses the private key to encrypt the content digest to form a digital signature, which can be verified using the public key.

[0045] A content digest is a string of a fixed length uniquely corresponding to one item of data content, and is generated by applying a one-way hash encryption function to the data content. If the data content has been tampered with during network transmission, the content digests before and after transmission can be compared to determine whether the data content has been altered. Therefore, the integrity of the data content can be verified based on the content digest. The content digest uses a one-way hash function to map the plaintext of the data content to be transmitted into a series of ciphertexts, which are also called digital fingerprints. The content digest has a fixed length, and when different plaintext digests are ciphertexted, the results are always different, but the digests of similar plaintexts always match. The digest extraction algorithm in this embodiment can include, for example, MD (Message Digest), SHA (Secure Hash Algorithm), MAC (Message Authentication Code), and other algorithms.

[0046] A digital signature is a message digest algorithm with cryptographic keys, including a public key and a private key, that is used to verify data integrity, authenticate data source and non-repudiation, comply with the OSI reference model, and verify private key signature and public key verification. It is also a combination of an asymmetric encryption algorithm and a message digest algorithm, and the three most commonly used digital signature algorithms are RSA, DSA, and ECDSA.

[0047] Based on the RSA algorithm, a pair of RSA private keys can be generated. One is a secret private key kept by the business entity, and the other is a public private key that can be registered on a network server and made public. To ensure confidentiality, the RSA private key should be at least 500 bits long, with 1024 bits being the recommended length. This significantly increases the amount of computation required for encryption. To reduce computational complexity, a combination of traditional encryption and public key encryption is always used during information transmission. That is, the information is encrypted using an improved DES or IDEA session key, and then the RSA encryption key is used to encrypt the session key and information digest. After receiving the information, the other party can decrypt it using a different private key and check the information digest.

[0048] One important feature of DSA (Digital Signature Algorithm) is the publication of two prime numbers, so that anyone using p and q of another entity can verify whether they were generated randomly or whether they were forged or altered, without knowing the private key.

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

[0050] In one embodiment of the present application, after signature verification for the consensus request is completed, the data content included in the consensus request can be verified. The data verification method can, for example, include checking the consistency between the data content included in the consensus request and the data content temporarily stored locally in the current blockchain node. If the verification is successful, it indicates that the same data content is temporarily stored in the blockchain node that issued the consensus request and the current blockchain node, and that the data content has not been modified during network transmission.

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

[0052] When a blockchain node receives the response message broadcast in the blockchain network, it can determine the message source of each response message by analyzing the response message, and use the statistics of the response messages with different message sources to count the number of blockchain nodes that issued the response messages, which indicates the number of blockchain nodes that executed different types of consensus algorithms in the blockchain network in response to the consensus request.

[0053] In one embodiment of the present application, each blockchain node can receive and count response messages sent from other blockchain nodes. For example, if a blockchain network includes n blockchain nodes, each blockchain node can receive at most n-1 response messages sent from other blockchain nodes. At the same time, each blockchain node also sends its own response messages externally. Therefore, the maximum number of blockchain nodes that have sent response messages counted by one blockchain node is the total number of blockchain nodes in the blockchain network. Each blockchain node independently performs message source statistics, which can improve the reliability of the consensus process.

[0054] In one embodiment of the present application, one or more master nodes in a blockchain network can collect source statistics for response messages, while other slave nodes do not need to perform quantity statistics. For example, in one consensus process, master nodes are generated by voting, rotation, or random selection, and after sending a consensus request to the blockchain network, the master nodes can monitor the response messages returned from the slave nodes in the blockchain network and count the number of slave nodes that have issued response messages. The advantage of performing message source statistics through the master node is that it can reduce the computational costs of other slave nodes and avoid unnecessary data costs.

[0055] In one embodiment of the present application, in order to improve consensus efficiency, the number of blockchain nodes that issue response messages within a preset time range can be counted, and if a new response message is received beyond the time range, it can be discarded and not included in the statistics.

[0056] In one embodiment of the present application, the time range for counting the number of nodes can be a fixed time window having a specified time length with the starting point of the range being a first time point when the current blockchain node receives a consensus request, and can also be a fixed time window having a specified time length with the starting point of the range being a second time point when the current blockchain node issues a response message.

[0057] In one embodiment of the present application, the time range for counting the number of nodes may be a dynamic time window with a variable length, the end point of which is determined based on the third time point at which the most recent response message was received and a preset time length. For example, if the time point at which a blockchain node most recently received a response message is A, the end point of the time range may be determined as A+B based on the time length B. If the blockchain node does not receive a new response message between time points A and A+B, the source statistics of the response message may be stopped. If the blockchain node receives another new response message between time points A and A+B, for example, if a new response message is received at time point C, the end point of the time range may be updated to C+B. Similarly, if the blockchain node does not receive a new response message for a long period of time, the source statistics of the response message may be stopped.

[0058] In one embodiment of the present application, the time range for performing response message source statistics can be a time range with a static start point and a dynamic end point, for example, the static start point is any one of receiving a consensus request, issuing a response message, or receiving a response message for the first time, and the dynamic end point is determined based on the most recent reception of a new response message and a preset time length. Using a dynamically changing time range to perform message source statistics can improve statistical efficiency while ensuring the accuracy of data statistics, avoiding the impact on consensus progress caused by an overly long time range, and also avoiding the problem of incomplete data statistics caused by an overly short time range.

[0059] S440: If the number of nodes meets the consensus conditions of the first consensus algorithm, achieve consensus on the blockchain nodes that run the first consensus algorithm, and synchronize the consensus result of the first consensus algorithm to the blockchain nodes that run the second consensus algorithm, where the first consensus algorithm and the second consensus algorithm are different types of consensus algorithms.

[0060] The consensus condition of a consensus algorithm is used to determine whether the judgment condition for the consensus result can be obtained. For example, the consensus condition of one consensus algorithm may be that the number of blockchain nodes that issued response messages exceeds a predetermined ratio to the total number of blockchain nodes. Different types of consensus algorithms configured in a blockchain network may have the same consensus condition or different consensus conditions.

[0061] In one embodiment of the present application, a blockchain node in a blockchain network can determine whether the number of nodes obtained by statistics satisfies the consensus conditions based on the consensus algorithm it executes. For example, if the consensus algorithm executed by the current blockchain node is a first consensus algorithm, it can determine whether the consensus conditions of the first consensus algorithm are met based on the number of nodes obtained by statistics; if the consensus algorithm executed by the current blockchain node is a second consensus algorithm, it can determine whether the consensus conditions of the second consensus algorithm are met based on the number of nodes obtained by statistics.

[0062] In one embodiment of the present application, when some blockchain nodes in a blockchain network run a first consensus algorithm and other blockchain nodes run a second consensus algorithm, the consensus condition of the first consensus algorithm is that the statistical proportion of the number of blockchain nodes that issue response messages to the total number of blockchain nodes exceeds a first proportion threshold, and the consensus condition of the second consensus algorithm is that the statistical proportion of the number of blockchain nodes that issue response messages to the total number of blockchain nodes exceeds a second proportion threshold, and the second proportion threshold is greater than the first proportion threshold. If the proportion of the statistically obtained number of nodes to the total number of blockchain nodes is greater than the first proportion threshold but less than the second proportion threshold, it can be determined that the number of nodes meets the consensus condition of the first consensus algorithm but does not meet the consensus condition of the second consensus algorithm. Based on this, the blockchain node that implemented the first consensus algorithm can obtain a consensus result of successful consensus, and although the blockchain node that implemented the second consensus algorithm has not yet succeeded in reaching consensus, it can synchronize data with the blockchain node that implemented the second consensus algorithm through the blockchain node that implemented the first consensus algorithm, and the blockchain node that implemented the second consensus algorithm can also complete consensus.

[0063] In the blockchain consensus method provided in the embodiments of the present application, by configuring blockchain nodes that run at least two different types of consensus algorithms within the blockchain network, the number of blockchain nodes that issue consensus response messages can be counted in the process of implementing node consensus. If the number of nodes meets the consensus conditions of any one consensus algorithm, the consensus result can be synchronized from the blockchain nodes that meet the consensus conditions to the blockchain nodes that do not meet the consensus conditions, thereby increasing the flexibility of blockchain consensus.

[0064] In one embodiment of the present application, different types of consensus algorithms have different numbers of consensus stages, and the response message carries the algorithm type and node signature of the blockchain node, where 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.

[0065] 5 shows the data structure of a response message in one embodiment of the present application. As shown in FIG. 5, 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.

[0066] The type field 501 is used to indicate the algorithm type of the consensus algorithm implemented by the blockchain node that issued the response message, and may include, for example, a CFT-based consensus algorithm or a BFT-based consensus algorithm.

[0067] A CFT-based consensus algorithm, or crash fault tolerance algorithm (CFT), is a type of consensus algorithm that can guarantee the consistency of node data in the face of crash errors, including benign errors such as node downs and network errors.

[0068] A BFT-based consensus algorithm, or Byzantine Fault Tolerance algorithm (BFT), is a type of consensus algorithm that can guarantee the consistency of node data when faced with Byzantine errors. Byzantine errors include the above-mentioned fault-based errors, as well as software errors and malicious errors such as malicious nodes.

[0069] The signature field 502 is used to store the digital signatures of the blockchain node that issued the response message at each consensus stage, and may include, for example, a pre-preparation signature, a preparation signature, and a commitment signature.

[0070] When a blockchain node running a CFT-based consensus algorithm generates a response message, it can use the pre-preparation phase signature and the commit phase signature in the data structure, and when a blockchain node running a BFT-based consensus algorithm generates a response message, it can use all three phases of signatures.

[0071] In one embodiment of the present application, a response message of one stage carries the digital signatures of all previous stages, for example, a first-stage response message contains the digital signature of the first stage, a second-stage response message contains the digital signatures of the first and second stages simultaneously, and a third-stage response message contains the digital signatures of the first, second, and third stages simultaneously.

[0072] Data field 503 is used to store data requiring consensus validation, which may be, for example, transaction data for a network transaction.

[0073] The response message data structure provided in the present embodiment can be applied to multiple different types of consensus algorithms at the same time, and consensus algorithms with different numbers of consensus stages can be consensus authenticated using the same response message, thereby improving the matching diversity of different consensus algorithms in the blockchain network.

[0074] For consensus algorithms with different numbers of consensus stages, each blockchain node in a blockchain network may have different computing capabilities and network transmission speeds. Therefore, during consensus authentication, each blockchain node may be located in a different consensus stage. Therefore, when a previous blockchain node receives a response message from another blockchain node, it must identify the corresponding consensus stage based on the response message to effectively count the number of blockchain nodes located in different consensus stages. Figure 6 illustrates a blockchain consensus method for counting the number of nodes based on consensus stages in one embodiment of the present application. As shown in Figure 6, the method includes the following steps S610 to S670:

[0075] S610: Broadcast a consensus request corresponding to at least two consensus stages in a blockchain network, where the blockchain network includes at least two blockchain nodes that execute different types of consensus algorithms.

[0076] In an embodiment of the present application, at least two different types of consensus algorithms can be simultaneously operated on the blockchain network, for example, some blockchain nodes in the blockchain network run a first consensus algorithm, and other blockchain nodes run 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 different consensus conditions.

[0077] In one embodiment of the present application, one or more blockchain nodes can be selected from the blockchain network as master nodes to process consensus requests, and other blockchain nodes in the blockchain network except the master node can be slave nodes. When a client generates a consensus request, it can first send the consensus request to the master node, and the master node will further distribute the consensus request to each slave node. The master node can be generated by voting election, rotation assignment, random selection, etc.

[0078] S620: Obtain the response messages broadcast by the blockchain network at each consensus stage, where the response messages are messages sent by blockchain nodes in response to the consensus request.

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

[0080] In one embodiment of the present application, a blockchain node can perform consensus verification on a received consensus request and broadcast a response message on the blockchain network after passing the verification. The consensus verification of a blockchain node's consensus request can include two aspects: signature verification and data verification. Signature verification is used to verify the source authenticity of the consensus request, and data verification is used to verify the authenticity of the content of the consensus request.

[0081] In one embodiment of the present application, a consensus request broadcast in a blockchain network carries the digital signature of the blockchain node that issued the consensus request, and a response message broadcast in the blockchain network similarly carries the digital signature of the blockchain node that issued the response message. Each blockchain node in the blockchain network may possess a public key and a private key that constitute an asymmetric cryptographic key pair. When digitally signing a consensus request or response message, the blockchain node first extracts a content digest from the data content using a digest extraction algorithm, and then further encrypts the content digest using the private key to form a digital signature, which can be verified using the public key.

[0082] In one embodiment of the present application, after signature verification for the consensus request is completed, data verification can be performed on the data content included in the consensus request. The data verification method can, for example, include checking the consistency between the data content included in the consensus request and the data content temporarily stored locally in the current blockchain node. If the verification is successful, it indicates that the same data content is temporarily stored in the blockchain node that issued the consensus request and the current blockchain node, and that the data content has not been modified during network transmission.

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

[0084] The response message transmits the algorithm type and node signature of the blockchain node, where the algorithm type is used to indicate the consensus algorithm implemented by the blockchain node, and the node signature includes the digital signature of the blockchain node at each consensus stage.

[0085] By analyzing the response message, we can obtain the data structure shown in Figure 6. Based on the type field in the response message, we can obtain the algorithm type, and based on the signature field in the response message, we can obtain the node signature corresponding to each consensus stage.

[0086] S640: Based on the algorithm type, identify the consensus algorithm executed by the message sending node, where the message sending node is the blockchain node that issued the response message.

[0087] Each blockchain node in the blockchain network has a corresponding node identifier, and each blockchain node in the blockchain network stores the node identifiers of other blockchain nodes in the blockchain network. In subsequent processes, data such as generated consensus requests, response messages, and blocks waiting to be linked to the chain can be broadcast to other blockchain nodes in the blockchain network based on the node identifiers of other blockchain nodes. Each blockchain node can maintain a node identifier list, and node names and node identifiers are correspondingly stored in the node identifier list. The node identifier can be an IP (Internet Protocol, an interconnection protocol between networks) address or any other information that can be used to identify the blockchain node.

[0088] When a blockchain node broadcasts a response message to the blockchain network, it can package its own node identifier in the response message.When the current blockchain node receives the response message broadcast on the blockchain network, it can determine the message sending node that issued the response message based on the node identifier obtained by analyzing the response message.It can determine the consensus algorithm being executed by the message sending node based on the algorithm type obtained by analyzing the response message.

[0089] S650: Based on the node signature, identify the consensus stage in which the message sending node is located.

[0090] By analyzing the response message, the signature field can be read to obtain the node signature corresponding to each consensus stage. Since each blockchain node may have different consensus progress, the response message 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, it will carry the node signature of the pre-preparation stage in the response message it issues. For example, if a blockchain node has already completed consensus authentication for the pre-preparation stage and is currently in the preparation stage, it will carry the node signatures of both the pre-preparation stage and the preparation stage in the response message it issues.

[0091] In one embodiment of the present application, the response message can be analyzed to screen one or more consensus stages of the node signatures present therein, and the consensus stage in which the message sending node is currently located can be determined based on the execution order of each consensus stage.

[0092] If a node signature exists in only one consensus stage in the signature field, it can be determined that the message sending node is in that consensus stage. For example, if a node signature exists only in the pre-preparation stage in the signature field of a response message and the signature fields corresponding to the other consensus stages are blank, it can be determined that the message sending node that issued the response message is currently in the pre-preparation stage.

[0093] If a node signature exists in at least two consensus stages in the signature field, then based on the execution order of the at least two consensus stages, it can be determined that the consensus stage with the later execution order is the consensus stage that the message sending node is currently in. For example, if a node signature exists in both the pre-preparation stage and the preparation stage in the signature field of a response message, and the signature fields corresponding to the other consensus stages are blank, then the preparation stage in the consensus algorithm is executed after the pre-preparation stage, so it can be determined that the message sending node of the response message is currently in the preparation stage.

[0094] S660: Count the number of message sending nodes 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.

[0095] According to the consensus algorithm implemented by the message sending node, it can be determined whether the message sending node is implementing the same type of consensus algorithm as the current blockchain node.If the message sending node is implementing the same type of consensus algorithm as the current blockchain node, it can be determined directly based on the consensus stage in which the message sending node is located whether the message sending node is in the same consensus stage as the current blockchain node.If the message sending node is implementing a different type of consensus algorithm from the current blockchain node, it is necessary to determine whether the consensus stage in which the message sending node is located is the same as the current blockchain node based on a preset matching relationship.

[0096] Before counting the number of message sending nodes in the same consensus stage as the current blockchain node, the current blockchain node can first obtain the matching relationship of the consensus stages between different types of consensus algorithms. If the message sending node is running a different type of consensus algorithm from the current blockchain node, determine the message sending node in the same consensus stage as the current blockchain node based on the matching relationship.

[0097] For any two different types of consensus algorithms, it can be determined whether each blockchain node is at the same consensus stage based on the matching relationship. For example, if a message sending node runs one of a first consensus algorithm and a second consensus algorithm, and a current blockchain node runs the other of the first consensus algorithm and the second consensus algorithm, where the first consensus algorithm includes N consensus stages and the second consensus algorithm includes M consensus stages, the matching relationship of the consensus stages between different types of consensus algorithms includes the mutual matching of the first P consensus stages of the first consensus algorithm and the second consensus algorithm, where P is the smaller of N-1 and M-1, and the mutual matching of the last NP consensus stages of the first consensus algorithm and the last MP consensus algorithm of the second consensus algorithm.

[0098] For example, if the first consensus algorithm is a CFT-based consensus algorithm, it includes two consensus stages, namely, a preparation stage and a commitment stage, and if the second consensus algorithm is a BFT-based consensus algorithm, it includes three consensus stages, namely, a pre-preparation stage, a preparation stage, and a commitment stage.

[0099] Based on the above matching relationships, the first consensus phase of the first consensus algorithm matches with the first consensus phase of the second consensus algorithm; that is, the preparatory phase of the CFT-based consensus algorithm matches with the pre-preparatory phase of the BFT-based consensus algorithm; the last consensus phase of the second consensus algorithm matches with the last two consensus phases of the second consensus algorithm; that is, the commit phase of the CFT-based consensus algorithm matches with the preparatory and commit phases of the BFT-based consensus algorithm.

[0100] Based on this, if one blockchain node is in the preparation stage of a CFT-based consensus algorithm and another blockchain node is in the pre-preparation stage of a BFT-based consensus algorithm, it can be determined that they are in the same consensus stage. Similarly, if one blockchain node is in the commitment stage of a CFT-based consensus algorithm and another blockchain node is in the preparation or commitment stage of a BFT-based consensus algorithm, it can be determined that they are in the same consensus stage.

[0101] In one embodiment of the present application, after counting the number of message sending nodes in the same consensus stage as the current blockchain node, the current blockchain node can determine the subsequent algorithm execution operation based on the consensus stage it is in. If the consensus stage in which the current blockchain node is located is the last consensus stage in which the consensus algorithm is executed, 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 stage in which the current blockchain node is located is not the last consensus stage in which the consensus algorithm is executed, the consensus result of the consensus algorithm is determined based on whether the number of nodes meets the consensus conditions of the consensus algorithm.

[0102] For example, if the consensus stage in which the current blockchain node is located is the preparation stage of a CFT-based consensus algorithm, it can determine whether the number of nodes satisfies the consensus conditions of the CFT-based consensus algorithm by counting the number of blockchain nodes in the same consensus stage (including the preparation stage of a CFT-based consensus algorithm or the pre-preparation stage of a BFT-based consensus algorithm). If the consensus conditions of the CFT-based consensus algorithm are met, it can proceed to the commit stage. If the consensus conditions of the CFT-based consensus algorithm are not met, it must continue to wait for response messages issued by other blockchain nodes and update the statistical number of nodes in real time.

[0103] In one embodiment of the present application, each blockchain node can receive and count response messages sent by other blockchain nodes. For example, if a blockchain network includes n blockchain nodes, each blockchain node can receive up to n-1 response messages sent by other blockchain nodes at most, and at the same time, each blockchain node also sends its own response messages externally. Therefore, the maximum number of blockchain nodes that send response messages counted by one blockchain node is the total number of blockchain nodes in the blockchain network. Each blockchain node independently performs message source statistics, which can improve the reliability of the consensus process.

[0104] In one embodiment of the present application, one or more master nodes in a blockchain network can perform source statistics of response messages, while other slave nodes do not need to perform quantity statistics. For example, in a consensus process, master nodes are generated by voting, rotation, or random selection, and when a master node sends a consensus request to the blockchain network, it can monitor the response messages returned from the slave nodes in the blockchain network and count the number of slave nodes that have issued response messages. The advantage of performing message source statistics through a master node is that it can reduce the computational costs of other slave nodes and avoid unnecessary data costs.

[0105] In one embodiment of the present application, in order to improve consensus efficiency, the number of blockchain nodes that issue response messages within a preset time range can be counted, and if a new response message is received beyond the time range, it can be discarded and not included in the statistics.

[0106] In one embodiment of the present application, the time range for counting the number of nodes can be a fixed time window having a specified time length with the starting point of the range being a first time point when the current blockchain node receives a consensus request, and can also be a fixed time window having a specified time length with the starting point of the range being a second time point when the current blockchain node issues a response message.

[0107] In one embodiment of the present application, the time range for counting the number of nodes may be a dynamic time window with a variable length, the end point of which is determined based on the third time point at which the most recent response message was received and a preset time length. For example, if the time point at which a blockchain node most recently received a response message is A, the end point of the time range may be determined as A+B based on the time length B. If the blockchain node does not receive a new response message between time points A and A+B, the source statistics of the response message may be stopped. If the blockchain node receives another new response message between time points A and A+B, for example, if a new response message is received at time point C, the end point of the time range may be updated to C+B. Similarly, if the blockchain node does not receive a response message for a long period of time, the source statistics of the response message may be stopped.

[0108] In one embodiment of the present application, the time range for performing response message source statistics can be a time range with a static start point and a dynamic end point, for example, the static start point is any one of receiving a consensus request, issuing a response message, or receiving a response message for the first time, and the dynamic end point is determined based on the most recent reception of a new response message and a preset time length. Using a dynamically changing time range to perform message source statistics can improve statistical efficiency while ensuring the accuracy of data statistics, avoiding the impact on consensus progress caused by an overly long time range, and also avoiding the problem of incomplete data statistics caused by an overly short time range.

[0109] S670: If the number of nodes meets the consensus conditions of the first consensus algorithm, achieve consensus on the blockchain nodes that run the first consensus algorithm, and synchronize the consensus result of the first consensus algorithm to the blockchain nodes that run the second consensus algorithm, where the first consensus algorithm and the second consensus algorithm are different types of consensus algorithms.

[0110] The consensus condition of a consensus algorithm is used to determine whether the judgment condition for the consensus result can be obtained. For example, the consensus condition of one consensus algorithm may be that the number of blockchain nodes that issued response messages exceeds a predetermined ratio to the total number of blockchain nodes. Different types of consensus algorithms configured in a blockchain network may have the same consensus condition or different consensus conditions.

[0111] In one embodiment of the present application, a blockchain node in a blockchain network can determine whether the number of nodes obtained by statistics satisfies the consensus conditions based on the consensus algorithm it executes. For example, if the consensus algorithm executed by the current blockchain node is a first consensus algorithm, it can determine whether the consensus conditions of the first consensus algorithm are met based on the number of nodes obtained by statistics; if the consensus algorithm executed by the current blockchain node is a second consensus algorithm, it can determine whether the consensus conditions of the second consensus algorithm are met based on the number of nodes obtained by statistics.

[0112] In one embodiment of the present application, when some blockchain nodes in a blockchain network run a first consensus algorithm and another part of blockchain nodes run a second consensus algorithm, the consensus condition of the first consensus algorithm is that the statistical proportion of the number of blockchain nodes that issued response messages to the total number of blockchain nodes exceeds a first proportion threshold, and the consensus condition of the second consensus algorithm is that the statistical proportion of the number of blockchain nodes that issued response messages to the total number of blockchain nodes exceeds a second proportion threshold, and the second proportion threshold is greater than the first proportion threshold. If the proportion of the statistically obtained number of nodes to the total number of blockchain nodes is greater than the first proportion threshold but less than the second proportion threshold, it can be determined that the number of nodes meets the consensus condition of the first consensus algorithm but does not meet the consensus condition of the second consensus algorithm. Based on this, the blockchain node that implemented the first consensus algorithm can obtain a consensus result of successful consensus, and although the blockchain node that implemented the second consensus algorithm has not yet succeeded in consensus, it can synchronize data with the blockchain node that implemented the second consensus algorithm through the blockchain node that implemented the first consensus algorithm, and the blockchain node that implemented the second consensus algorithm can also complete consensus.

[0113] In one embodiment of the present application, 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 another one of the low-fault-tolerance consensus algorithm and the high-fault-tolerance consensus algorithm that is different from the first consensus algorithm. The consensus condition of the low-fault-tolerance consensus algorithm is that the proportion of the number of blockchain nodes that issue response messages to all blockchain nodes is greater than a first proportion threshold, and the consensus condition of the high-fault-tolerance consensus algorithm is that the proportion of the number of blockchain nodes that issue response messages to all blockchain nodes is greater than a second proportion threshold, and the first proportion threshold is less than the second proportion threshold. The first proportion threshold and the second proportion threshold are both constants greater than 0 and less than 1. For example, the first proportion threshold is 1 / 2, and the second proportion threshold is 2 / 3.

[0114] If the proportion of the number of blockchain nodes that issue response messages to all blockchain nodes is less than 1 / 2, the number of nodes not only does not meet the consensus conditions of the low fault-tolerance consensus algorithm, but also does not meet the consensus conditions of the high fault-tolerance consensus algorithm, and all blockchain nodes running the two consensus algorithms cannot complete consensus authentication.

[0115] If the proportion of blockchain nodes that issue response messages to all blockchain nodes is greater than 1 / 2 and less than 2 / 3, the number of nodes meets the consensus conditions for the low fault-tolerance consensus algorithm but does not meet the consensus conditions for the high fault-tolerance consensus algorithm, and blockchain nodes that implement the low fault-tolerance consensus algorithm can complete consensus authentication, but blockchain nodes that implement the high fault-tolerance consensus algorithm cannot. Based on this, blockchain nodes that implement the low fault-tolerance consensus algorithm can synchronize their consensus results with blockchain nodes that implement the high fault-tolerance consensus algorithm, allowing all blockchain nodes in the blockchain network to complete consensus authentication.

[0116] If the proportion of blockchain nodes that issue response messages to all blockchain nodes is greater than 2 / 3, the number of nodes not only meets the consensus conditions of the low fault-tolerance consensus algorithm, but also meets the consensus conditions of the high fault-tolerance consensus algorithm, and all blockchain nodes running the two consensus algorithms can complete consensus authentication.

[0117] In one embodiment of the present application, 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, the first number being less than the second number. Increasing the number of consensus stages can increase the fault-tolerance of the consensus algorithm.

[0118] In one embodiment of the present application, the consensus phase of the low-fault-tolerance consensus algorithm includes a preparation phase and a commit phase that are executed sequentially, and the consensus phase of the high-fault-tolerance consensus algorithm includes a pre-preparation phase, a preparation phase, and a commit phase that are executed sequentially, wherein the preparation phase of the low-fault-tolerance consensus algorithm and the pre-preparation phase of the high-fault-tolerance consensus algorithm are matched with each other, and the commit phase of the low-fault-tolerance consensus algorithm and the preparation phase and commit phase of the high-fault-tolerance consensus algorithm are matched with each other.

[0119] 7 shows the consensus flow of a low-fault-tolerance consensus algorithm in one embodiment of the present application, where the low-fault-tolerance consensus algorithm is, for example, the Paxos algorithm, a CFT-based consensus algorithm. The low-fault-tolerance consensus algorithm in this embodiment is based on two-stage node-to-node interactions, and its advantage is that the node-to-node interactions are relatively simple, making it easier to implement and providing relatively high performance.

[0120] As shown in FIG. 7, the flow of implementing consensus authentication based on a low fault-tolerance consensus algorithm may include the following steps:

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

[0122] S702: The master node performs the first stage of node interaction (preparation stage) and distributes the authentication request to other slave nodes. After the slave nodes receive the authentication request and perform consensus processing, they can return a response message to the master node.

[0123] In the preparation stage, the authentication request sent by the master node to other slave nodes contains the data that needs to be written to the blockchain and the master node's digital signature obtained after digesting and encrypting the data using the master node's private key. Taking the data structure shown in Figure 5 as an example, the authentication request sent by the master node to the slave nodes contains the master node's digital signature written in the field "pre-preparation stage signature".

[0124] When a slave node receives an authentication request sent by the master node, it can use the master node's public key to verify the digital signature included in the authentication request. After signature verification is passed, the slave node can obtain the slave node's digital signature after using its own private key to digest and encrypt the data that needs to be written to the blockchain. Taking the data structure shown in Figure 5 as an example, the preparation response message sent by the slave node to the master node contains the master node's digital signature and the slave node's digital signature written in the field "pre-preparation signature".

[0125] 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), in which the master node commits the data and notifies the other slave nodes of the data commit. When the slave node receives the commit notification, it can write the data to the blockchain it stores and return a response message to the master node.

[0126] When the master node receives the preliminary response messages returned by the slave nodes, it can collect and aggregate the digital signatures of the slave nodes included in each response message.

[0127] After proceeding to the commit phase, the master node can send a commit notification to each slave node, carrying the aggregated digital signature. Taking the data structure shown in Figure 5 as an example, the commit notification sent by the master node to the slave nodes includes the master node digital signature and multiple slave node digital signatures written in the field "pre-preparation phase signature", and also includes the master node digital signature written in the field "commit phase signature". The number of master node digital signatures and slave node digital signatures in the field "pre-preparation phase signature" must exceed half the total number of nodes, which means it must meet the consensus conditions for the preparatory phase of the low fault-tolerance consensus algorithm.

[0128] When a slave node receives the commit notification sent by the master node, it verifies the signature using the same method as in the previous stage, and after passing the verification, it can write its own slave node digital signature in the response message. Taking the data structure shown in Figure 5 as an example, the commit stage response message sent by the slave node to the master node includes the master node digital signature and multiple slave node digital signatures written in the field "pre-preparation stage signature", and at the same time, it also includes the master node digital signature and the slave node's own slave node digital signature written in the field "commit stage signature".

[0129] S704: The master node returns a response to the client indicating that the data has been successfully written, allowing the client to determine that the data has been successfully written to the entire blockchain system.

[0130] When the master node receives the commit phase response messages returned by the slave nodes, it can collect and aggregate the slave node digital signatures included in each response message. Taking the data structure shown in Figure 5 as an example, the response message returned by the master node to the client includes the master node digital signature and multiple slave node digital signatures written in the "pre-preparation phase signature" field, and also includes the master node digital signature and multiple slave node digital signatures written in the "commit phase signature" field. The number of master node digital signatures and slave node digital signatures in the "pre-preparation phase signature" field must exceed half the total number of nodes, and the number of master node digital signatures and slave node digital signatures in the "commit phase signature" field must also exceed half the total number of nodes, which means that the consensus conditions for the preparation phase and commit phase of the low fault-tolerance consensus algorithm must be met.

[0131] 8 shows the consensus flow of a highly fault-tolerant consensus algorithm in one embodiment of the present application, where the highly fault-tolerant consensus algorithm is, for example, the PBFT algorithm, which is a BFT-based consensus algorithm. Compared to a CFT-based consensus algorithm, a BFT-based consensus algorithm must still ensure system consistency even in the event of a software error or a malicious node. Therefore, the node interactions of a BFT-based algorithm are more complex, generally requiring three stages of interaction, and the number of fault-tolerant nodes is even smaller, generally allowing one-third of the nodes to be faulty.

[0132] As shown in FIG. 8, the flow of implementing consensus authentication based on a highly fault-tolerant consensus algorithm may include the following steps:

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

[0134] S802: The master node executes the first stage of node interaction (preparation stage) and distributes authentication requests to other slave nodes. When a slave node receives an authentication request and performs a consensus process, it can return a response message to the master node. The purpose of this stage is to confirm that the requests received by multiple slave nodes are the same, and to prevent the master node from maliciously sending different messages to different slave nodes.

[0135] In the pre-preparation stage, the authentication request sent by the master node to other slave nodes contains the data that needs to be written to the blockchain, and the master node's digital signature obtained after digesting and encrypting the data using the master node's private key. Taking the data structure shown in Figure 5 as an example, the authentication request sent by the master node to the slave nodes contains the master node's digital signature written in the field "pre-preparation stage signature".

[0136] When a slave node receives an authentication request sent by the master node, it can use the master node's public key to verify the digital signature included in the authentication request. If the signature verification passes, the slave node can obtain the slave node's digital signature after using its own private key to digest and encrypt the data that needs to be written to the blockchain. Taking the data structure shown in Figure 5 as an example, the pre-preparation response message sent by the slave node to the master node contains the master node's digital signature and the slave node's digital signature written in the field "pre-preparation signature".

[0137] S803: When the master node receives a pre-preparation response message from more than two-thirds of the total number of nodes (including the master node itself), the master node executes the second stage (preparation stage) and the master node again sends the message signature to the other slave nodes. The slave nodes verify whether the number of message signatures exceeds two-thirds of the total number of nodes, and if it does, the slave nodes return a response message indicating successful voting to the master node.

[0138] When the master node receives the pre-preparation response messages sent back by the slave nodes, it can collect and aggregate the slave node digital signatures included in each response message.

[0139] After proceeding to the preparation stage, the master node can send a preparation message to each slave node, carrying the aggregated digital signature. Taking the data structure shown in Figure 5 as an example, the preparation message sent by the master node to the slave nodes includes the master node digital signature and multiple slave node digital signatures written in the field "pre-preparation stage signature", and also includes the master node digital signature written in the field "pre-preparation stage signature". The number of master node digital signatures and slave node digital signatures in the field "pre-preparation stage signature" must exceed two-thirds of the total number of nodes, which means it must meet the consensus conditions for the pre-preparation stage of the high-fault-tolerance consensus algorithm.

[0140] When a slave node receives the preparation message sent by the master node, it verifies the signature using the same method as in the previous stage, and after passing the verification, it can write its own slave node digital signature in the response message. Taking the data structure shown in Figure 5 as an example, the preparation stage response message sent by the slave node to the master node includes the master node digital signature and multiple slave node digital signatures written in the field "pre-preparation stage signature", and at the same time, it also includes the master node digital signature and the slave node's own slave node digital signature written in the field "commit stage signature".

[0141] S804: When the master node receives response messages from more than two-thirds of the total number of nodes (including the master node itself), the master node executes the third phase (commit phase), in which the master node commits the data and notifies the other slave nodes of the data commit. When a slave node receives the commit notification, it can write the data to the blockchain it stores and return a response message to the master node.

[0142] When the master node receives the preliminary response messages returned by the slave nodes, it can collect and aggregate the slave node digital signatures included in each response message.

[0143] After proceeding to the commit phase, the master node can send a commit notification to each slave node, carrying the aggregated digital signature. Taking the data structure shown in FIG. 5 as an example, the commit notification sent by the master node to the slave nodes includes the master node's digital signature and multiple slave node digital signatures written in the "pre-preparation signature" field, as well as the master node's digital signature and multiple slave node digital signatures written in the "preparation signature" field, and the master node's digital signature written in the "commit phase signature" field. The number of master node digital signatures and slave node digital signatures in the "preparation signature" field must exceed two-thirds of the total number of nodes, and the number of master node digital signatures and slave node digital signatures in the "preparation signature" field must also exceed two-thirds of the total number of nodes, which means that the consensus conditions for the pre-preparation and preparation phases of the high-fault-tolerance consensus algorithm must be met.

[0144] When a slave node receives the prepare message sent by the master node, it verifies the signature using the same method as in the previous stage, and after verification is passed, it can write its own slave node digital signature in the response message. Taking the data structure shown in Figure 5 as an example, the commit stage response message sent by the slave node to the master node includes the master node digital signature and multiple slave node digital signatures written in the field "pre-preparation stage signature", and also includes the master node digital signature and multiple slave node digital signatures written in the field "preparation stage signature", and the master node signature and the slave node's own slave node digital signature written in the field "commit stage signature".

[0145] S805: The slave node returns a response to the client indicating that the data has been successfully written, allowing the client to determine that the data has been successfully written to the entire blockchain system.

[0146] When the master node receives the commit phase response messages returned by the slave nodes, it can collect and aggregate the slave node digital signatures included in each response message. Taking the data structure shown in FIG. 5 as an example, the response message returned by the master node to the client includes the master node digital signature and multiple slave node digital signatures written in the field "pre-preparation phase signature," as well as the master node digital signature and multiple slave node digital signatures written in the field "preparation phase signature," and the master node digital signature and multiple slave node digital signatures written in the field "commit phase signature." The number of master node digital signatures and slave node digital signatures in the field "preparation phase signature" must exceed two-thirds of the total number of nodes, the number of master node digital signatures and slave node digital signatures in the field "preparation phase signature" must also exceed two-thirds of the total number of nodes, and the number of master node digital signatures and slave node digital signatures in the field "commit phase signature" must also exceed two-thirds of the total number of nodes, which means that the consensus conditions for the pre-preparation phase, preparation phase, and commit phase of the high-fault-tolerance consensus algorithm must be met.

[0147] In related blockchain systems, some systems pursue system performance by adopting CFT-based consensus, such as Fabric, while other systems pursue broader fault tolerance by adopting BFT-based consensus, such as Tendermint. In actual enterprise applications, upper-level business systems using blockchain services have different requirements in terms of performance, availability, fault tolerance, scalability, etc., as user demands constantly change. However, current blockchain systems only use a single consensus algorithm, which makes it impossible to adapt to the requirements of upper-level business systems. The technical solution provided in the embodiments of this application for flexibly switching between CFT and BFT algorithms online allows the blockchain system to change consensus algorithms to meet the requirements of business systems without interrupting service.

[0148] In one embodiment of the present application, in the process of broadcasting a consensus request in a blockchain network, some or all of the blockchain nodes in the blockchain network may switch algorithms to change the consensus algorithm executed by some or all of the blockchain nodes.

[0149] If some blockchain nodes have completed the algorithm switchover while other blockchain nodes have not, there will be at least two blockchain nodes running different consensus algorithms in the blockchain network. On this basis, consensus authentication can be implemented using the above embodiments of the present application.

[0150] In one embodiment of the present application, a method for switching algorithms of some or all blockchain nodes in a blockchain network includes: Performing a trust prediction on the blockchain network to determine whether the operating environment of the blockchain network is a trust environment; If the operating environment of the blockchain network is a trust environment, switching some or all of the blockchain nodes that run a low fault-tolerance consensus algorithm in the blockchain network to run a high fault-tolerance consensus algorithm; If the operating environment of the blockchain network is not a trusted environment, this may include switching some or all of the blockchain nodes in the blockchain network that run a high fault-tolerance consensus algorithm to run a low fault-tolerance consensus algorithm.

[0151] In one embodiment of the present application, a method for predicting the trustworthiness of a blockchain network includes: Obtaining the operation time length of each blockchain node in the blockchain network; If the operation time length is shorter than the time length threshold, determining the blockchain node as an untrusted node; If the number of untrusted nodes in the blockchain network is greater than a threshold number, determining that the operating environment of the blockchain network is an untrusted environment; If the number of untrusted nodes in the blockchain network is less than a threshold number, determining that the operating environment of the blockchain network is a trusted environment may include:

[0152] For example, in supply chain management scenarios, a blockchain system is often proposed by some companies in the supply chain flow. In this case, the blockchain system can be recognized as being in a trusted environment, and there is no need to consider the presence of malicious nodes; a simple CFT algorithm can be used as the consensus algorithm. However, when other companies in the supply chain join the blockchain system, it is necessary to prevent the other companies from being malicious. Therefore, the algorithm switching step of the present embodiment can be performed to switch the consensus algorithm to a BFT-based algorithm without interrupting service. After the blockchain system has been operating stably for a certain period of time and each participating company has been recognized as a trusted node, the algorithm switching step of the present embodiment can be performed again to switch the consensus algorithm to a CFT-based algorithm, thereby improving the performance of the blockchain system.

[0153] Figure 9 illustrates a scenario in which the algorithm switching process is performed in this embodiment. It takes the algorithm switching of four nodes as an example, and each blockchain node runs a different consensus algorithm at a different time of the algorithm switching.

[0154] When two consensus algorithms with different distribution rates exist within a blockchain network, five scenes can be formed, as shown in Figure 8. When CFT consensus is switched to BFT consensus, nodes gradually switch from an all-CFT consensus algorithm to an all-BFT consensus algorithm, and scene 1 gradually switches to scene 5. When BFT consensus is switched to CFT consensus, nodes gradually switch from an all-BFT consensus algorithm to an all-CFT consensus algorithm, and scene 5 gradually switches to scene 1.

[0155] Table 2 shows the proportion of blockchain nodes that run different consensus algorithms in the total number of nodes in five scenarios.

[0156] [Table 2]

[0157] Below, we will explain the consensus proposals for five different application scenarios.

[0158] Scene 1: In scene 1, the consensus algorithm of all nodes is CFT, so this scene corresponds to the scene where the CFT algorithm is used alone. All nodes can reach a consensus on the system data by simply following their local CFT algorithm steps.

[0159] Scene 2: In Scene 2, only node 1 uses the BFT algorithm, while the other three nodes use the CFT algorithm. Since the total number of CFT nodes (3) is greater than half the total number of nodes (4), a consensus can be reached among the three CFT nodes according to the consensus conditions of the CFT algorithm. After reaching a consensus, node 1 synchronizes with the consensus result, ensuring consistency of system data.

[0160] Scene 3: In scenario 3, the number of CFT nodes cannot meet the consensus condition of being greater than 1 / 2 required by the CFT algorithm, and at the same time, the number of BFT nodes cannot meet the consensus condition of being greater than 2 / 3 required by the BFT algorithm. In this case, none of the nodes in the system can reach a consensus according to the normal CFT or BFT algorithm.

[0161] In this scenario, the embodiment of the present invention can implement data interaction between nodes using a response message having a data structure as shown in FIG.

[0162] Referring to Figure 5, the data structure includes three signature fields: pre-preparation signature, pre-preparation signature, and commit signature. CFT consensus nodes use pre-preparation signature and commit signature, while BFT consensus nodes use all three signature fields.

[0163] 10 shows a flow chart of the method steps for performing consensus authentication in an application scenario of an embodiment of the present application. As shown in FIG. 10, in the above scenario 3, the method for performing consensus authentication can include the following steps:

[0164] S1001: The master node receives a consensus request sent by a client.

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

[0166] S1003: The slave node returns a <preparation> message to the master node.

[0167] Since the preparation stage of the CFT-based consensus algorithm matches the pre-preparation stage of the BFT-based consensus algorithm, nodes using the CFT-based consensus algorithm can respond by substituting a <preparation> message for a <preparation> message. In this case, both slave nodes using the CFT-based consensus and slave nodes using the BFT-based consensus will return a <preparation> message to the master node.

[0168] S1004: The master node determines whether or not it has received <preparation> messages at a rate exceeding two-thirds of the total number of nodes.

[0169] If it is not more than 2 / 3, return to S1003 and continue to receive <preparation> messages returned by other slave nodes. If it is more than 2 / 3, consensus authentication of the preparatory stage is completed, so proceed to the preparation stage and execute S1005.

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

[0171] S1006: <Preparation> Determine whether the slave node that received the message is a CFT node that executes a CFT-based consensus algorithm. If the result of the determination is "Yes," execute S1007. If the result of the determination is "No," this indicates that the slave node is a BFT node that executes a BFT-based consensus algorithm, so skip to S10010.

[0172] S1007: The slave node commits the data.

[0173] When a slave node using a CFT-based consensus algorithm receives a <prepare> message from a master node, it can be interpreted as the master node already receiving a <pre-prepare> message that is greater than 2 / 3, which is greater than the 1 / 2 condition required by the CFT algorithm. In this case, the slave node running the CFT-based consensus algorithm can convert the <prepare> message into a <commit> message and commit the data directly. At this time, the nodes using the CFT-based consensus algorithm can reach consensus and the data is consistent.

[0174] S1008: The slave node returns a <commit> message to the master node.

[0175] After completing the data commit, the slave node running the CFT consensus algorithm sends a <commit> message back to the master node, causing other BFT nodes to achieve the commit condition that the total number of <prepare> + <commit> reaches 2 / 3. Then, execute S1010.

[0176] S1009: The slave node returns a <prepare> message to the master node.

[0177] S1010: The master node determines whether or not it has received <prepare> messages at a rate exceeding two-thirds of the total number of nodes.

[0178] If it is determined that the number of participants has not exceeded 2 / 3, continue to execute S1011. If it is determined that the number of participants has exceeded 2 / 3, the consensus verification for the preparation stage has been completed, so proceed to the commit stage and skip to execute S1012.

[0179] S1011: The master node determines whether or not it has received <prepare> messages and <commit> messages at a rate exceeding two-thirds of the total number of nodes.

[0180] The commit phase of a CFT-based consensus algorithm is consistent with the prepare and commit phases of a BFT-based consensus algorithm. Therefore, when a master node receives a response to a <commit> message sent by a CFT node, the master node can use the response to the <commit> message as a response to a <prepare> message. Based on this, if the master node determines that it has received <prepare> and <commit> messages at a rate exceeding two-thirds of the total number of nodes, consensus authentication for the prepare phase is complete, and it proceeds to the commit phase and continues to execute S1012. If the master node determines that it has not received <prepare> and <commit> messages at a rate exceeding two-thirds of the total number of nodes, it returns to S1005, and the master node continues to send <prepare> messages to other slave nodes.

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

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

[0183] Nodes using BFT-based consensus can reach a condition for responding to a <prepare> message that is greater than 2 / 3, while still being able to reach consensus according to the steps of the BFT-based algorithm and guaranteeing data consistency with CFT-based nodes.

[0184] Scene 4: In scene 4, node 4 runs a CFT-based consensus algorithm, and the remaining three nodes run a BFT-based consensus algorithm. Since the total number of BFT nodes (3) is greater than two-thirds of the total number of nodes (4), a consensus can be reached among the three BFT nodes according to the BFT-based consensus algorithm. After reaching a consensus, node 4 synchronizes with the consensus result, ensuring consistency of system data.

[0185] Scene 5: In scene 5, all nodes are running the BFT-based consensus algorithm, so the system can reach a consistent consensus by following the steps of the BFT-based consensus algorithm.

[0186] Based on the above description of various application scenarios, it can be seen that the online consensus algorithm switching scheme provided in the embodiments of the present application supports consensus algorithm switching without service interruption, allowing the blockchain system to adapt more flexibly to the needs of upper-level business, and enabling the blockchain system to be applied more widely in different scenarios.

[0187] It should be noted that although the accompanying figures depict steps in the methods of the present invention in a particular order, this does not require or imply that the steps must be performed in that particular order or that desired results are achieved by performing all of the steps presented. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into a single step, and / or a single step may be separated into multiple steps.

[0188] The following introduces an embodiment of the present application that can be used to implement the blockchain consensus method in the above embodiment of the present application. Figure 11 shows a schematic block diagram of the structure of the blockchain consensus device provided in the embodiment of the present application. As shown in Figure 11, the blockchain consensus device 1100 includes: a request module 1110 configured to broadcast a consensus request corresponding to at least two consensus stages in a blockchain network, the blockchain network including at least two blockchain nodes that implement different types of consensus algorithms; and A response module 1120 configured to respectively obtain response messages broadcast by the blockchain network in each of the consensus stages, where the response messages are messages in which the blockchain nodes respond to the consensus requests, and the different types of consensus algorithms include a first consensus algorithm and a second consensus algorithm; and a statistics module 1130 configured to count the number of blockchain nodes that issued the response messages in the same consensus stage, where the number of nodes includes the number of blockchain nodes that execute at least two different types of consensus algorithms; and a synchronization module 1140 configured to achieve consensus on the blockchain nodes that execute the first consensus algorithm and synchronize the consensus result of the first consensus algorithm to the blockchain nodes that execute the second consensus algorithm if the number of nodes satisfies the consensus condition of the first consensus algorithm.

[0189] In one embodiment of the present application, based on the above embodiments, different types of consensus algorithms have different numbers of consensus stages, and the response message includes an algorithm type and a node signature of the blockchain node, where the algorithm type is used to indicate the consensus algorithm executed by the blockchain node, and the node signature includes a digital signature of the blockchain node at each consensus stage.

[0190] In one embodiment of the present application, based on the above embodiments, the statistics module 1030 further comprises: a parsing module configured to parse the response message to obtain an algorithm type and a node signature included in the response message; an algorithm identification module configured to identify a consensus algorithm executed by a message sending node based on the algorithm type, the message sending node being the blockchain node that issued the response message; and a tier identification module configured to identify a consensus tier in which the message sending node is located based on the node signature; and a quantity statistics module configured to count the number of message sending nodes 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.

[0191] In one embodiment of the present application, based on the above embodiments, the statistics module 1030 further comprises: a relationship acquisition module configured to acquire a matching relationship of consensus stages between different types of consensus algorithms; If the message sending node is running a different type of consensus algorithm than the current blockchain node, the node determination module may include a node determination module configured to determine a message sending node that is in the same consensus stage as the current blockchain node based on the matching relationship.

[0192] In one embodiment of the present application, based on the above embodiments, the first consensus algorithm includes N consensus stages, and the second consensus algorithm includes M consensus stages, and the matching relationship of the consensus stages between different types of consensus algorithms includes: Matching the first P consensus steps of the first consensus algorithm and the second consensus algorithm with each other, where P is the smaller of N-1 and M-1; and matching the last NP consensus stages of the first consensus algorithm with the last MP consensus stages of the second consensus algorithm.

[0193] In one embodiment of the present application, based on the above embodiments, after the current blockchain node counts the number of message sending nodes in the same consensus stage, the statistics module 1030 further: a consensus result determination module configured to determine a consensus result of the consensus algorithm based on whether the number of nodes meets the consensus condition for executing the consensus algorithm if the consensus stage in which the current blockchain node is located is the last consensus stage for executing the consensus algorithm; and a consensus stage execution module configured to determine whether to execute the next consensus stage of the consensus algorithm based on whether the number of nodes meets the consensus conditions for executing the consensus algorithm if the consensus stage in which the current blockchain node is located is not the last consensus stage for executing the consensus algorithm.

[0194] In one embodiment of the present 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 a different type from the first consensus algorithm among the low fault-tolerance consensus algorithm and the high fault-tolerance consensus algorithm.

[0195] The consensus condition of the low fault-tolerance consensus algorithm is that the proportion of the number of blockchain nodes that have issued response messages to all blockchain nodes is greater than a first proportion threshold, and the consensus condition of the high fault-tolerance consensus algorithm is that the proportion of the number of blockchain nodes that have issued response messages to all blockchain nodes is greater than a second proportion threshold, and the first proportion threshold is smaller than the second proportion threshold.

[0196] In one embodiment of the present application, based on each of 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, and the first number is smaller than the second number.

[0197] In one embodiment of the present application, based on the above embodiments, the consensus phase of the low fault-tolerance consensus algorithm includes a preparation phase and a commit phase that are executed sequentially, the consensus phase of the high fault-tolerance consensus algorithm includes a pre-preparation phase, a preparation phase and a commit phase that are executed sequentially, the preparation phase of the low fault-tolerance consensus algorithm is mutually matched with the pre-preparation phase of the high fault-tolerance consensus algorithm, and the commit phase of the low fault-tolerance consensus algorithm is mutually matched with the preparation phase and the commit phase of the high fault-tolerance consensus algorithm.

[0198] In one embodiment of the present application, based on the above embodiments, the blockchain consensus apparatus 1000 further comprises: The blockchain network may also include an algorithm switching module configured to cause some or all of the blockchain nodes in the blockchain network to switch algorithms to change the consensus algorithm executed by the some or all of the blockchain nodes.

[0199] In one embodiment of the present application, based on the above embodiments, the algorithm switching module further comprises: A trust detection module configured to perform a trust prediction on the blockchain network to determine whether the operation environment of the blockchain network is a trust environment; A first algorithm switching module configured to switch some or all of the blockchain nodes that run a low fault-tolerance consensus algorithm in the blockchain network to run a high fault-tolerance consensus algorithm when the operating environment of the blockchain network is a trust environment; and a second algorithm switching module configured to switch some or all of the blockchain nodes that run the high fault-tolerance consensus algorithm in the blockchain network to run the low fault-tolerance consensus algorithm if the operating environment of the blockchain network is not a trusted environment.

[0200] In one embodiment of the present application, based on the above embodiments, the trustworthiness detection module that performs trustworthiness prediction on the blockchain network further comprises: a time length obtaining module configured to obtain an operation time length of each blockchain node in the blockchain network; an untrusted node determination module configured to determine the blockchain node as an untrusted node if the operation time length is shorter than a time length threshold; an untrusted environment determination module configured to determine an operating environment of the blockchain network as an untrusted environment when the number of untrusted nodes in the blockchain network is greater than a number threshold; The network may include a trust environment determination module configured to determine the operating environment of the blockchain network as a trust environment if the number of untrusted nodes in the blockchain network is less than a number threshold.

[0201] The specific details of the blockchain consensus device provided in each embodiment of the present application have already been described in detail in the corresponding method embodiments, so they will not be described in detail again here.

[0202] FIG. 12 is a schematic block diagram showing the structure of a computer system in an electronic device for implementing the present embodiment.

[0203] It should be noted that the computer system 1200 of the electronic device shown in FIG. 12 is merely an example and does not impose any limitations on the functions and scope of use of the embodiments of the present invention.

[0204] As shown in FIG. 12, computer system 1200 includes a central processing unit (CPU) 1201, which performs various appropriate operations and processes based on programs stored in read-only memory (ROM) 1202 or programs loaded from memory portion 1208 into random access memory (RAM) 1203. Random access memory 1203 also stores various programs and data necessary for the operation of the system. Central processing unit 1201, read-only memory 1202, and random access memory 1203 are interconnected via bus 1204. Input / output port 1205 (I / O port) is also connected to bus 1204.

[0205] The following components are connected to the input / output port 1205: an input section 1206 including a keyboard, a mouse, etc.; an output section 1207 including, for example, a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, a storage section 1208 including a hard disk, etc.; and a communication section 1209 such as a network interface card including a local area network card, a modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A driver 1210 is also connected to the input / output port 1205 as needed. A removable medium 1211, for example, a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the driver 1210 as needed, and a computer program read from the removable medium 1211 is installed in the storage section 1208 as needed.

[0206] In particular, in accordance with an embodiment of the present application, the steps depicted in each method flow diagram are implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program stored on a computer-readable medium, the computer program including program code for executing the method illustrated in the flow diagram. In such an embodiment, the computer program is downloaded and implemented from a network via the communication unit 1209 and / or from a removable medium 1211. When the computer program is executed by the central processing unit 1201, various functions defined in the system of the present application are performed.

[0207] The computer-readable medium described in the embodiments of the present application may be a computer-readable signal medium, a computer-readable storage medium, or any combination of the above. The computer-readable storage medium may be, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of the computer-readable storage medium may include, but are not limited to, an electrical connection having one or more conductors, a compact computer magnetic disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be a tangible medium that contains or stores a program, and the program is used by or in connection with an instruction execution system, apparatus, or device. As used herein, a computer-readable signal medium may include a propagated data signal, either baseband or as part of a carrier wave, having computer-readable program code embodied therein. Such propagated data signals may take a variety of forms, including, but not limited to, electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which may transmit, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device.The program code contained in the computer readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, or the like, or any suitable combination of the above.

[0208] The flow diagrams and block diagrams in the accompanying drawings illustrate possible organizational structures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in a flow diagram or block diagram may represent a module, program section, or portion of code, which includes executable instructions for implementing one or more specified logical functions. It should also be noted that in some alternative implementations, the functions depicted in the blocks may occur in a different order than depicted in the accompanying drawings. For example, two blocks shown as connected may actually be essentially executed in parallel, and they may sometimes be executed in the reverse order, depending on the functionality described. It should also be noted that each block in a block diagram or flow diagram, and combinations of blocks in a block diagram or flow diagram, may be implemented by a dedicated hardware-based system that performs the specified functions or operations, or by a combination of dedicated hardware and computer instructions.

[0209] It should be noted that although the detailed description in the above text refers to several modules or units used in the device to perform the operations, this type of division is not mandatory. In fact, based on the embodiment of the present application, the features and functions of two or more modules or units described in the above text may be embodied in one module or unit. Conversely, the features and functions of one module or unit described in the above text may be further divided so that they are embodied in multiple modules or units.

[0210] Regarding the above description of the embodiments, as can be understood by those skilled in the art, the exemplary embodiments described herein can be realized by software, or can also be realized by combining necessary hardware through software. Therefore, the technical solutions according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which may be a CD-ROM, USB, portable hard disk, etc.) or on a network, and includes some instructions for causing a computing device (which may be a personal computer, a server, a touch-control terminal, or a network device, etc.) to perform the method according to the embodiments of the present application.

[0211] Those skilled in the art will be able to easily conceive of other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any variations, uses, or preferred modifications of the present application, provided that such variations, uses, or preferred modifications comply with the general principles of the present application and include common knowledge or customary technical means in the art that are not disclosed in the present application.

[0212] It should be understood that the present application is not limited to the exact construction already described above and shown in the accompanying drawings, and that various modifications and changes can be made without departing from the scope thereof, which is intended to be limited by the appended claims.

Claims

1. A blockchain consensus method executed by a current blockchain node in a blockchain network, comprising: Broadcasting consensus requests corresponding to at least two consensus stages in the blockchain network, where the blockchain network includes blockchain nodes that execute at least two different types of consensus algorithms, and the different types of consensus algorithms include a first consensus algorithm and a second consensus algorithm; Obtaining a response message broadcast by the blockchain network in each consensus stage, where the response message is a message in which the blockchain node responds to the consensus request; Counting the number of blockchain nodes that issued the response messages in the same consensus stage, where the number of nodes includes the number of blockchain nodes that execute at least two different types of consensus algorithms, and the same consensus stage includes consensus stages that are determined to be the same based on a matching relationship between consensus stages of the different types of consensus algorithms; and If the number of nodes satisfies the consensus condition of the first consensus algorithm, achieving consensus on the blockchain nodes that execute the first consensus algorithm, and synchronizing the consensus result of the first consensus algorithm to the blockchain nodes that execute the second consensus algorithm.

2. 2. The blockchain consensus method of claim 1, wherein different types of consensus algorithms have different numbers of consensus stages, and the response message transmits the algorithm type and node signature of the blockchain node, the algorithm type being used to indicate the consensus algorithm executed by the blockchain node, and the node signature including the digital signature of the blockchain node at each consensus stage.

3. Counting the number of blockchain nodes that issued the response messages in the same consensus stage Parsing the response message to obtain an algorithm type and a node signature included in the response message; Identifying a consensus algorithm executed by a message sending node according to the algorithm type, wherein the message sending node is a blockchain node that issued the response message; and Identifying a consensus phase in which the message sending node is located according to the node signature; Counting the number of message sending nodes that are in the same consensus stage as the current blockchain node according to the consensus algorithm executed by the message sending node and the consensus stage in which the message sending node is located.

4. Before counting the number of message sending nodes that are in the same consensus stage as the current blockchain node, Obtaining a matching relationship of consensus stages between the different types of consensus algorithms; If the message sending node and the current blockchain node are running different types of consensus algorithms, determining a message sending node that is in the same consensus stage as the current blockchain node according to the matching relationship.

5. The first consensus algorithm includes N consensus steps, and the second consensus algorithm includes M consensus steps, and the matching relationship of the consensus steps between the different types of consensus algorithms is: Matching the first P consensus stages of the first consensus algorithm and the second consensus algorithm with each other, where P is the smaller of N-1 and M-1; and matching the last N-P consensus stages of the first consensus algorithm with the last M-P consensus stages of the second consensus algorithm.

6. Counting the number of message sending nodes that are in the same consensus stage as the current blockchain node, and then If the consensus stage in which the current blockchain node is located is the final consensus stage in which a consensus algorithm is executed, determining the consensus result of the consensus algorithm according to whether the number of nodes meets the consensus conditions of the consensus algorithm being executed; If the consensus stage in which the current blockchain node is located is not the final consensus stage in which a consensus algorithm is executed, determining whether the consensus stage is the next consensus stage in which a consensus algorithm is executed according to whether the number of nodes satisfies the consensus conditions of the consensus algorithm to be executed.

7. 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 another of the low-fault-tolerance consensus algorithm and the high-fault-tolerance consensus algorithm that is different from the first consensus algorithm; 2. The blockchain consensus method of claim 1, wherein the consensus condition of the low fault-tolerance consensus algorithm is that the proportion of the number of blockchain nodes that have issued response messages to all blockchain nodes is greater than a first proportion threshold, and the consensus condition of the high fault-tolerance consensus algorithm is that the proportion of the number of blockchain nodes that have issued response messages to all blockchain nodes is greater than a second proportion threshold, and the first proportion threshold is smaller than the second proportion threshold.

8. 8. The blockchain consensus method of claim 7, wherein 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, the first number being less than the second number.

9. 9. The blockchain consensus method of claim 8, wherein the consensus phase of the low fault-tolerance consensus algorithm includes a preparation phase and a commit phase that are executed sequentially, and the consensus phase of the high fault-tolerance consensus algorithm includes a pre-preparation phase, a preparation phase, and a commit phase that are executed sequentially, wherein the preparation phase of the low fault-tolerance consensus algorithm is mutually matched with the pre-preparation phase of the high fault-tolerance consensus algorithm, and the commit phase of the low fault-tolerance consensus algorithm is mutually matched with the preparation phase and the commit phase of the high fault-tolerance consensus algorithm.

10. In the step of broadcasting a consensus request in the blockchain network, the method further comprises:

2. The blockchain consensus method of claim 1, comprising switching 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.

11. Switching the algorithm of some or all of the blockchain nodes in the blockchain network includes: Performing a trust prediction on the blockchain network to determine whether the operating environment of the blockchain network is a trust environment; If the operating environment of the blockchain network is a trusted environment, switching some or all of the blockchain nodes that run a low fault-tolerance consensus algorithm in the blockchain network to run a high fault-tolerance consensus algorithm; If the operating environment of the blockchain network is not a trusted environment, switching some or all of the blockchain nodes in the blockchain network that run a high fault-tolerance consensus algorithm to run a low fault-tolerance consensus algorithm.

12. The performing of a trust prediction on the blockchain network includes: Obtaining an operation time length of each blockchain node in the blockchain network; If the operation time length is shorter than a time length threshold, determining the blockchain node as an untrusted node; If the number of untrusted nodes in the blockchain network is greater than a threshold number, determine that the operating environment of the blockchain network is an untrusted environment; The blockchain consensus method of claim 11, further comprising: if the number of untrusted nodes in the blockchain network is less than a number threshold, determining that the operating environment of the blockchain network is a trusted environment.

13. a request module configured to broadcast a consensus request corresponding to at least two consensus stages in a blockchain network, the blockchain network including at least two blockchain nodes that execute consensus algorithms of different types, the different types of consensus algorithms including a first consensus algorithm and a second consensus algorithm; A response module configured to respectively obtain response messages broadcast by the blockchain network in each of the consensus stages, wherein the response messages are messages in which the blockchain nodes respond to the consensus request; A statistics module configured to count the number of blockchain nodes that issued the response messages in the same consensus stage, wherein the number of nodes includes the number of blockchain nodes that execute at least two different types of consensus algorithms, and the same consensus stage includes consensus stages that are determined to be the same based on a matching relationship between consensus stages of the different types of consensus algorithms; and and a synchronization module configured to achieve consensus on the blockchain nodes that execute the first consensus algorithm if the number of nodes satisfies the consensus condition of the first consensus algorithm, and synchronize the consensus result of the first consensus algorithm to the blockchain nodes that execute the second consensus algorithm.

14. a processor; a memory for storing executable instructions for said processor, The processor is configured to cause the electronic device to perform the blockchain consensus method described in any one of claims 1 to 12 by executing the executable instructions.

15. A computer program causing a computer to execute the blockchain consensus method according to any one of claims 1 to 12.

Images