Block chain consensus method, system and device and medium

Abstract

The embodiment of the invention provides a block chain consensus method, system and device and a medium, and belongs to the field of block chains. The method comprises the following steps: when an nth round of consensus task starts, entering a proposal stage, sending an nth proposal by a master node of a block chain network, broadcasting the proposal to a slave node, entering a voting stage, generating a vote after the slave node receives the nth proposal from the master node, and sending the vote to the master node; and when the master node receives votes exceeding 2 / 3 of the slave nodes, verifying the votes, submitting a block, entering an (n + 1) th consensus, and sending an (n + 1) th proposal carrying all votes collected in the nth proposal to the slave nodes by the master node of the block chain network, so that the votes of the nth proposal are verified and discharged after the slave nodes receive the (n + 1) th proposal. By simplifying the traditional PBFT algorithm and combining with the pipeline parallel technology, the consensus efficiency and throughput are significantly improved, and efficient operation of the block chain network is accelerated.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a blockchain consensus method, system, device, and medium. Background Art

[0002] Blockchain technology holds enormous potential for driving the development of decentralized smart contracts. However, its inherent limitations, particularly high costs, low efficiency, and complex protocol management, are key factors hindering its widespread adoption. Among these, the traditional Practical Byzantine Fault Tolerance (PBFT) algorithm presents particular challenges.

[0003] The PBFT algorithm's four-phase communication mechanism—request, pre-prepare, prepare, and commit—ensures consistency in distributed systems, but it also incurs significant network overhead. Its complexity is O(n²), meaning that network communication and computational requirements increase exponentially as the number of nodes increases. This poses a significant challenge to building large-scale, efficient blockchain networks.

[0004] Furthermore, existing technologies typically require all nodes to participate in each round of voting, which not only results in a significant waste of computing resources but also limits the system's scalability. With a large number of nodes, this full-node participation approach significantly slows down consensus and reduces the efficiency of the entire system.

[0005] Under high network pressure, masternodes often become system bottlenecks, and their performance issues directly impact the stability and reliability of the entire blockchain network. This problem is particularly prominent when blockchain technology is applied in real-world scenarios, where network pressure is often extremely high and unpredictable. Summary of the Invention

[0006] The purpose of the embodiments of the present invention is to provide a blockchain consensus method, system, device, and medium. By simplifying the traditional PBFT algorithm and combining it with pipeline parallel technology, the consensus mechanism in the blockchain distributed computing environment is optimized. By introducing pipeline features, the consensus efficiency and throughput are significantly improved, thereby accelerating the efficient operation of the blockchain network.

[0007] To achieve the above objectives, an embodiment of the present invention provides a blockchain consensus method, including: Each round of tasks is divided into the proposal stage, voting stage, and submission stage, and is carried out in parallel using a pipeline. After each round of tasks passes verification, it enters the submission stage. At the beginning of the nth round of consensus, the proposal phase begins. The master node of the blockchain network issues the nth proposal and broadcasts it to the slave nodes. This phase begins with the voting phase. After receiving the nth proposal from the master node, the slave node generates a vote and sends it to the master node. When the master node receives votes from more than 2 / 3 of the slave nodes, it verifies the votes and submits them for block generation, and enters the n+1th round of consensus. The master node of the blockchain network sends the n+1th proposal carrying all the votes collected in the nth round of proposals to the slave nodes, so that after receiving the n+1th proposal, the slave nodes verify the votes for the nth proposal and generate blocks.

[0008] Optionally, the communication between the master node and the slave node is based on a decentralized P2P network built on the libp2p protocol stack, using the TCP transport protocol to achieve point-to-point transmission of proposal broadcasts and voting. The slave node locates the master node's PeerID through the libp2p distributed hash table, subscribes to the Leader's exclusive topic proposal, and the message is encoded in Protobuf.

[0009] Optionally, the blockchain consensus method further includes: Privacy mechanisms are set up between each node to ensure the security of data and sensitive information. The privacy mechanisms set up include: Inter-node communication uses a dynamic key exchange protocol to generate temporary session keys and implements forward secrecy through TLS1.3 transport layer encryption. Application layer data is end-to-end encrypted using the recipient's public key, and the encrypted ciphertext is transmitted through a predefined communication channel. Sensitive data is replaced with a hash value, encrypted and stored in an off-chain distributed storage system. A concatenated hash value containing a random number is generated and stored on the blockchain. The on-chain smart contract records the hash value of the encrypted data and the storage location metadata. When a consensus node accesses off-chain data, it needs to reorganize the decryption private key shards and meet the threshold signature conditions.

[0010] Optionally, the blockchain consensus method further includes: when a node receives an illegal task, confirming the authenticity of the source by verifying the digital signature of the task, and marking it as illegal if the digital signature does not match the preset authority certificate.

[0011] Optionally, the blockchain consensus method further includes: using hash summary comparison to detect whether the task data has been tampered with during transmission. If the hash does not match, the node will trigger an on-chain alarm event and record the sender address and load hash of the abnormal task.

[0012] Optionally, the blockchain consensus method further includes: verifying whether the initiating node is a consensus node according to preset rules of the node.

[0013] In a second aspect, the present invention further provides a blockchain consensus system, comprising: The planning module is used to split each round of tasks into the proposal stage, the voting stage, and the submission stage, and adopts pipeline parallelization. After each round of tasks passes verification, it enters the submission stage; The proposal and voting module is used to enter the proposal phase at the beginning of the nth round of consensus tasks. The master node of the blockchain network issues the nth proposal and broadcasts it to the slave nodes. Then, the voting phase begins. After receiving the nth proposal from the master node, the slave node generates a vote and sends it to the master node. The verification module is used to verify the votes and submit them for block generation after the master node receives votes from more than 2 / 3 of the slave nodes, and then enter the n+1th round of consensus. The master node of the blockchain network sends the n+1th proposal carrying all the votes collected in the nth round of proposals to the slave nodes, so that after receiving the n+1th proposal, the slave nodes will verify the votes for the nth proposal and generate blocks.

[0014] Optionally, the communication between the master node and the slave node is based on a decentralized P2P network built on the libp2p protocol stack, using the TCP transport protocol to achieve point-to-point transmission of proposal broadcasts and voting. The slave node locates the master node's PeerID through the libp2p distributed hash table, subscribes to the Leader's exclusive topic proposal, and the message is encoded in Protobuf.

[0015] In a third aspect, the present invention also provides an electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned blockchain consensus method when executing the program.

[0016] In a fourth aspect, the present invention also provides a storage medium on which a computer program is stored, and when the computer program is executed by a processor, the steps of the above-mentioned blockchain consensus method are implemented.

[0017] Through the above technical solution, the four stages in the traditional PBFT algorithm are reduced to three stages. Combined with the introduction of pipeline structure features, by introducing pipeline characteristics and parallel task processing, the PBFT algorithm can achieve higher throughput and faster consensus time in a distributed computing environment. The pipeline feature enables the system to complete task processing on each node quickly and efficiently, and significantly reduces computing resource consumption and response latency.

[0018] Other features and advantages of the embodiments of the present invention will be described in detail in the subsequent detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings are used to provide a further understanding of the embodiments of the present invention and constitute a part of the specification. Together with the following detailed description, they are used to explain the embodiments of the present invention, but do not constitute a limitation of the embodiments of the present invention. In the accompanying drawings: Figure 1 This is a flowchart of an implementation of a blockchain consensus method provided by an embodiment of the present invention; Figure 2 This is a detailed implementation flow chart of a blockchain consensus method provided by an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a blockchain consensus system provided by an embodiment of the present invention; Figure 4 The figure is a schematic diagram of the hardware structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0020] In the detailed description below, various embodiments of the present disclosure will be described more fully. The present disclosure can have various embodiments, and adjustments and changes can be made therein. However, it should be understood that there is no intention to limit the various embodiments of the present disclosure to the specific embodiments disclosed herein, but rather that the present disclosure should be understood to encompass all adjustments, equivalents, and / or alternatives that fall within the spirit and scope of the various embodiments of the present disclosure.

[0021] Hereinafter, the terms "include" or "may include" used in various embodiments of the present disclosure indicate the presence of the disclosed functions or operations and do not limit the addition of one or more functions or operations. In addition, as used in various embodiments of the present disclosure, the terms "include", "have" and their cognates are intended only to indicate specific features, numbers, steps, operations or combinations of the foregoing items, and should not be understood as first excluding the presence of one or more other features, numbers, steps, operations or combinations of the foregoing items or the possibility of adding one or more features, numbers, steps, operations or combinations of the foregoing items.

[0022] In various embodiments of the present disclosure, the expression "or" or "at least one of A or / and B" includes any or all combinations of the words listed simultaneously. For example, the expression "A or B" or "at least one of A or / and B" may include A, may include B, or may include both A and B.

[0023] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0024] See Figure 1 The flowchart of the blockchain consensus method in a specific embodiment includes the following steps: Step 100: Split each round of tasks into the proposal stage, voting stage, and submission stage, and use pipeline parallelism. After each round of tasks passes verification, it enters the submission stage.

[0025] Based on the pipeline execution method, different rounds of block generation requests are assigned to different nodes for processing, improving execution efficiency. Parallel processing between nodes eliminates the need for frequent interaction between them and reduces communication overhead. A node authentication stage has been added, and nodes that pass authentication can become master nodes, preventing malicious nodes from being selected as master nodes.

[0026] Step 101: At the beginning of the nth round of consensus task, the proposal phase begins. The master node of the blockchain network issues the nth proposal and broadcasts it to the slave nodes, entering the voting phase. After receiving the nth proposal from the master node, the slave node generates a vote and sends the vote to the master node.

[0027] By entering the proposal phase at the beginning of the nth round of consensus, with the master node issuing a proposal and broadcasting it to the slave nodes before entering the voting phase, the design can achieve the technical effects of clarifying task division, reducing network overhead, improving consensus efficiency, enhancing system scalability, improving system security, and simplifying protocol management. This design helps optimize the performance and reliability of blockchain technology in decentralized smart contract applications.

[0028] In some embodiments, the communication between the master node and the slave node is based on a decentralized P2P network built on the libp2p protocol stack, using the TCP transmission protocol to achieve point-to-point transmission of proposal broadcasting and voting, wherein the slave node locates the PeerID of the master node through the distributed hash table of libp2p, subscribes to the Leader's exclusive topic proposal, and the message is encoded using Protobuf.

[0029] For example, it contains the following fields:

[0030] Before communicating with the leader, nodes exchange TLS certificates. The certificate fingerprint must match the node's public key registered on the blockchain. Voting messages are doubly signed: the node's private key signature ensures the vote's authenticity. Leader public key encryption prevents intermediary nodes from eavesdropping.

[0031] Step 102: After the master node receives votes from more than 2 / 3 of the slave nodes, it verifies the votes and submits them for block generation, and enters the n+1th round of consensus. The master node of the blockchain network sends the n+1th proposal carrying all the votes collected in the nth round of proposals to the slave nodes, so that after receiving the n+1th proposal, the slave nodes verify the votes for the nth proposal and generate blocks.

[0032] It should be noted that although the leader node does not need to receive all votes to proceed to the subsequent operation steps, it still needs to meet the Byzantine fault tolerance rules, that is, at least 2 / 3 of the sub-leaders must be honest, and each system must follow the PBFT 3f+1 node fault tolerance.

[0033] By requiring the master node to receive votes from more than two-thirds of the slave nodes before verifying and submitting a block, sufficient support for the consensus result is ensured, thereby improving consensus reliability. When entering the n+1 round of consensus, the master node carries all voting information collected from the nth round of proposals, allowing the slave nodes to verify the voting results of the nth proposal, further enhancing the stability of consensus. In a distributed system, nodes may be unable to participate in voting in a timely manner due to network delays, failures, and other reasons. By requiring more than two-thirds of the votes before submitting a block, the system can tolerate delays or failures of some nodes without causing consensus failure.

[0034] In the n+1 consensus round, slave nodes can verify the voting results for the nth proposal, helping to identify potential errors or inconsistencies and take appropriate corrective measures. Dividing the consensus process into multiple rounds and clearly defining the tasks of proposals and voting within each round helps optimize consensus efficiency. Master nodes can quickly collect votes and verify the results, thereby accelerating block production. By carrying voting information for the nth round proposal in the n+1 consensus round, the overhead of repeated voting and verification is avoided, improving system throughput.

[0035] The traditional PBFT process's four phases (request, pre-prepare, prepare, commit) are simplified to three: proposal, vote, and commit. During the vote phase, a pipelined structure is introduced, requiring nodes to send their votes only to the leader node rather than broadcasting them to the entire network, significantly reducing the O(n²) network complexity. By streamlining the consensus process, inter-node communication is reduced, while broadcast messages are also reduced, alleviating network congestion. This reduces hardware design costs and resource consumption. The pipelined nature makes inter-node communication more efficient and reduces the complexity of the overall communication process.

[0036] To ensure reliability during the task waiting process, a pipeline structure is introduced to design a waiting process. After each node receives and processes the current round of tasks, it continues to process the previous round of tasks and passes the results to subsequent nodes. For example, the voting verification in the nth round and the proposal processing in the n+1th round can be carried out simultaneously.

[0037] In some implementations, during the prepare and commit phases of traditional PBFT, each node's vote must be broadcast to all nodes, and each node independently completes the verification and statistics of the vote. In the pipeline voting mode, each node only sends its vote to the leader node (not broadcast), and the verification and statistics of the vote only need to be completed by the leader node, saving computing resources. The number of communications per round is reduced from O(n 2 ) is reduced to the O(n) level. This design reduces the number of message sending and receiving to 1 per round, improving throughput and reducing latency. For example, assuming there are a total of 100 nodes, the number of messages drops from 1,9701 to 198. The number of messages in a PBFT round is calculated as follows: in the request phase, the leader sends a proposal to 99 nodes, accumulating 99; then in the pre-prepare phase, each node sends a pre-prepare message to the other 99 nodes, accumulating 9801+99=9900; in the prepare phase, each node sends a prepare message to the other 99 nodes, accumulating 9801+9900=19701; some protocols will have additional confirmation messages in their specific implementation, which are not included in the statistics for the time being. The fast consensus method of this application calculates the number of messages in one round as follows: in the proposal phase, the leader sends a proposal to 99 nodes, accumulating 99; in the vote phase, 99 nodes vote for the leader node, and the leader node votes for itself but does not pass through the network, accumulating 99+99=198.

[0038] In one embodiment, the blockchain consensus method process further includes the steps of: setting a privacy mechanism between each node to ensure the security of data and sensitive information; wherein the privacy mechanism set includes: Inter-node communication uses a dynamic key exchange protocol to generate temporary session keys and implements forward secrecy through TLS1.3 transport layer encryption. Application layer data is end-to-end encrypted using the recipient's public key, and the encrypted ciphertext is transmitted through a predefined communication channel. Sensitive data is replaced with a hash value, encrypted and stored in an off-chain distributed storage system. A concatenated hash value containing a random number is generated and stored on the blockchain. The on-chain smart contract records the hash value of the encrypted data and the storage location metadata. When a consensus node accesses off-chain data, it needs to reorganize the decryption private key shards and meet the threshold signature conditions.

[0039] For example, to ensure the security of data and sensitive information in the system, this application adds corresponding privacy mechanisms between various nodes.

[0040] 1. Inter-node communications (such as proposals and voting) are transmitted over encrypted channels, using symmetric encryption algorithms (such as AES-256) to protect data transmission and prevent man-in-the-middle attacks and eavesdropping. Inter-node communications use the dynamic key exchange protocol (Diffie-Hellman) to generate temporary session keys, and forward secrecy is achieved through TLS 1.3 transport layer encryption. Application layer data is end-to-end encrypted using the recipient's public key, and the encrypted ciphertext is transmitted over a predefined communication channel.

[0041] 2. Key data (such as user addresses) is replaced with a hash value (such as SHA3-256), encrypted, and stored in an off-chain distributed storage system (such as IPFS). A concatenated hash value containing a random number is generated and stored on the blockchain. The on-chain smart contract records the hash value of the encrypted data and the storage location metadata. Consensus nodes reassemble the decrypted private key shards through secure multi-party computation. Off-chain data can only be accessed if the threshold signature condition is met. Only consensus nodes can trace the original information. More specifically, when storing off-chain, the original data is concatenated with a random number (nonce) to calculate a hash H = HASH(data|nonce). H and the nonce are stored on-chain. During verification, the blockchain requires the data provider to submit the original data and nonce, recalculate the hash, and compare it with the on-chain record.

[0042] 3. Role-based access control: Consensus nodes can access the full proposal and voting data, but this requires authentication through an X509 permission certificate. This certificate is issued by an on-chain CA contract, with the issuance record recorded on-chain and associated with the node address to prevent forgery. Dynamic permission management is also implemented, with smart contracts monitoring certificate revocation lists and automatically freezing access rights for corresponding nodes.

[0043] These mechanisms ensure the privacy protection of the system and can effectively coordinate and share relevant security information among different nodes.

[0044] Specifically, when a node receives an illegal task, it verifies the authenticity of the source by verifying the digital signature of the task. If the digital signature does not match the preset authority certificate, it is marked as illegal.

[0045] In some embodiments, the blockchain consensus method further includes: using hash summary comparison to detect whether the task data has been tampered with during transmission. If the hash does not match, the node will trigger an on-chain alarm event and record the sender address and payload hash of the abnormal task.

[0046] In one example, the blockchain consensus method further includes: verifying whether the initiating node is a consensus node according to a preset rule of the node.

[0047] For example, in order to prevent malicious attacks from affecting the system, the present invention has designed a complete task waiting process. When a node receives an illegal task, the system will immediately check and take corresponding protective measures to ensure the security of the system.

[0048] 1. Digital Signature Verification. Nodes verify the authenticity of the source by verifying the digital signature of the task. If the signature does not match the pre-set authority certificate, it is marked as invalid. Digital signatures are implemented using the X509 certificate system. Only certificates pre-configured or subsequently registered for authentication can participate in on-chain activities. When verifying the task signature, nodes must recursively verify the X509 certificate chain to the root CA certificate (pre-installed in the blockchain genesis block). The smart contract then monitors the certificate revocation list to confirm that the certificate has not been revoked. Signing is performed using the classic ECDSA algorithm, a time-tested method.

[0049] 2. Data integrity verification. Hash digest comparison is used to detect whether task data has been tampered with during transmission. For example, the SHA hash value of the task payload must be consistent with the verification code provided by the sender. The hash calculation includes a timestamp and a random number (HASH(data | timestamp | nonce)) to prevent replay attacks. If the hashes do not match, the node will trigger an on-chain alarm event, recording the sender address and payload hash of the abnormal task.

[0050] 3. Match roles with permissions. Based on the preset rules of the nodes (for example, in practice, nodes in the system can be divided into consensus nodes, ordinary nodes, light nodes, etc.), verify whether the initiating node is a consensus node. Only consensus nodes can participate in tasks related to the consensus process. In addition to preset rules, dynamic updates of role permissions can also be achieved through smart contracts. For example:

[0051] For example, first, a series of verification rules for consensus nodes are set, including but not limited to: Node identity authentication: ensuring that the node has a legitimate identity, such as a digital certificate, public key, etc. Node reputation assessment: evaluating the node's reputation based on its historical behavior, transaction records, etc., to ensure that the node has a good record of behavior. Node resource requirements: setting the minimum resource requirements required for the node to participate in consensus, such as computing power, storage space, network bandwidth, etc. Node activity: requiring nodes to maintain a certain level of activity over a period of time, such as regular participation in network communications and transaction verification. The blockchain network collects and maintains information on all potential consensus nodes. This includes the node's identity, reputation score, resource status, activity records, etc. This information can be obtained through various methods such as node registration, network monitoring, and transaction records.

[0052] The collected node information is verified one by one according to pre-set verification rules. The specific process is as follows: Identity verification: Verifies the legitimacy of the node's identity, such as checking the validity of the digital certificate and whether the public key matches correctly. Reputation verification: Based on the node's reputation score, it is determined whether it meets the credibility requirements for participating in consensus. For example, a reputation threshold can be set, and only nodes with a reputation score above this threshold can participate in consensus. Resource requirement verification: Verifies whether the node's resource status meets the minimum requirements for participating in consensus. This can be achieved by providing resource proof (such as proof of computing power and storage space). Activity verification: Based on the node's activity records, it is determined whether the node has maintained sufficient activity within a specified period of time. For example, a activity threshold can be set, and only nodes with an activity score above this threshold can participate in consensus. Based on the verification results, the node is determined to be a consensus node or a non-consensus node. Nodes that meet all verification rules are marked as consensus nodes and allowed to participate in the consensus process. Nodes that do not meet the verification rules are marked as non-consensus nodes and are prohibited from participating in the consensus process. As the blockchain network operates, the status of nodes may change. Therefore, it is necessary to regularly update the node information and re-execute the verification rules to ensure the accuracy and reliability of the consensus node.

[0053] 4. Expired votes terminate. A node can proceed to the next steps after collecting a certain number of votes. If an expired vote is received due to network issues, the node will discard it. Furthermore, votes are only valid at the current block height; votes that do not meet the block height are automatically invalidated (the vote contains the current block height information). These protective measures can safely prevent malicious nodes, message tampering, and other illegal activities.

[0054] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0055] In some embodiments, see Figure 2 As shown in the figure, a detailed implementation flow chart of a blockchain consensus method provided by an embodiment of the present invention is shown. At the beginning of the first round of consensus, the proposal phase is entered first, and the leader node (node 1) issues the first proposal and broadcasts it to other nodes (node 2, node 3, node 4). In the vote phase, after nodes 2, 3, and 4 receive the proposal from the leader node, they verify the results of the previous round of voting and issue a block, generate a vote, and send the vote directly to the leader node; instead of broadcasting the vote to all nodes. In the commit phase, when the leader node receives votes from more than 2 / 3 of the number of nodes, it verifies the vote and commits the block, entering the second round. After entering the second round, the second proposal broadcast will carry all the votes collected in the first round. When other nodes receive the second proposal, they will verify the votes for the first proposal and issue a block, and then enter the next round.

[0056] In this embodiment, the traditional four-stage consensus process of request, pre-prepare, prepare, and commit is simplified to three stages: proposal, vote, and commit. The pipeline feature is then introduced to transform the consensus process into a pipeline structure, enabling parallel processing of tasks across nodes, significantly improving computational efficiency. Specifically, the pipeline feature allows each node to continue executing unfinished tasks from the previous round after completing its current round of tasks, reducing the number of inter-node communications and improving efficiency.

[0057] like Figure 3 As shown, the following is an embodiment of the blockchain consensus system provided by the embodiments of the present disclosure, which belongs to the same inventive concept as the blockchain consensus method of the above embodiments. For details not fully described in the embodiments of the blockchain consensus system, please refer to the embodiments of the above blockchain consensus method.

[0058] The planning module is used to split each round of tasks into the proposal stage, the voting stage, and the submission stage, and adopts pipeline parallelization. After each round of tasks passes verification, it enters the submission stage; The proposal and voting module is used to enter the proposal phase at the beginning of the nth round of consensus tasks. The master node of the blockchain network issues the nth proposal and broadcasts it to the slave nodes. Then, the voting phase begins. After receiving the nth proposal from the master node, the slave node generates a vote and sends it to the master node. The verification module is used to verify the votes and submit them for block generation after the master node receives votes from more than 2 / 3 of the slave nodes, and then enter the n+1th round of consensus. The master node of the blockchain network sends the n+1th proposal carrying all the votes collected in the nth round of proposals to the slave nodes, so that after receiving the n+1th proposal, the slave nodes will verify the votes for the nth proposal and generate blocks.

[0059] Specifically, the communication between the master node and the slave node is based on a decentralized P2P network built on the libp2p protocol stack, using the TCP transmission protocol to achieve point-to-point transmission of proposal broadcasts and voting. The slave node locates the master node's PeerID through the libp2p distributed hash table, subscribes to the Leader's exclusive topic proposal, and the message is encoded in Protobuf.

[0060] Figure 4 It is a schematic diagram of the hardware structure of an electronic device for implementing various embodiments of the present invention.

[0061] The blockchain consensus method provided in the embodiments of the present application can be applied to electronic devices. Those skilled in the art will understand that the electronic device structure involved in the embodiments of the present invention does not constitute a limitation of the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or arrange the components differently. In the embodiments of the present invention, the electronic device includes but is not limited to a laptop computer, a desktop computer, a workbench, a personal digital assistant, a server, a blade server, a mainframe computer, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of the present application described and / or required herein.

[0062] The electronic device may include a processor, an external memory interface, an internal memory, a universal serial bus (USB) interface, a charging management module, a power management module, a battery, a wireless communication module, an audio module, a speaker, a microphone, a sensor module, a button, a camera, a display, and a SIM card interface, etc.

[0063] It is understood that the structures illustrated in the embodiments of the present application do not constitute specific limitations on the electronic device. In other embodiments of the present application, the electronic device may include more or fewer components than shown, or combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0064] A processor may include one or more processing units, such as a central processing unit (CPU), an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0065] The processor can be the nerve center and command center of the electronic device. The controller can generate operation control signals based on the instruction opcode and timing signal to complete the control of instruction fetching and execution.

[0066] The processor may also include a memory for storing instructions and data. In some embodiments, the memory in the processor is a cache memory. This memory can store instructions or data that the processor has just used or is reusing. If the processor needs to use the instruction or data again, it can directly call it from the memory. This avoids repeated accesses, reduces processor latency, and thus improves system efficiency.

[0067] The external memory interface can be used to connect an external memory card, such as a MicroSD card, to expand the storage capacity of an electronic device. The external memory card communicates with the processor through the external memory interface, enabling data storage. For example, files such as music and videos can be stored on the external memory card.

[0068] Internal memory can be used to store computer-executable program code, which includes instructions. The processor executes the instructions stored in the internal memory to perform various functional applications and data processing of the electronic device. The internal memory can include a program storage area and a data storage area. The internal memory can include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0069] The wireless communication function of an electronic device can be implemented through an antenna, a wireless communication module, a modem processor, and a baseband processor.

[0070] Wireless communication modules can provide wireless communication solutions for electronic devices, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared technology (IR), etc.

[0071] Electronic devices can implement audio functions through audio modules, speakers, receivers, microphones, headphone jacks, and application processors.

[0072] Electronic devices can achieve shooting functions through ISP, camera, video codec, GPU, display and application processor.

[0073] Electronic devices can achieve display functions through GPU, display screen and application processor.

[0074] A GPU is a microprocessor for image processing that connects the display screen to the application processor. The GPU performs mathematical and geometric calculations for graphics rendering. A processor may include one or more GPUs, which execute program instructions to generate or modify display information.

[0075] The display screen is used to display images, videos, etc. The display screen includes a display panel.

[0076] The storage medium provided in this application stores a program product that can implement the blockchain consensus method.

[0077] The blockchain consensus method includes: splitting each round of tasks into a proposal stage, a voting stage, and a submission stage, and adopting pipeline parallelism. When each round of tasks passes verification, it enters the submission stage; among them, at the beginning of the nth round of consensus task, it first enters the proposal stage, and the master node of the blockchain network issues the nth proposal and broadcasts the proposal to the slave node, entering the voting stage. After the slave node receives the nth proposal from the master node, it generates a vote and sends the vote to the master node; when the master node receives votes from more than 2 / 3 of the slave nodes, it verifies the vote and submits the block, and enters the n+1th round of consensus. The master node of the blockchain network sends the n+1th proposal carrying all the votes collected in the nth round of proposals to the slave node, so that after the slave node receives the n+1th proposal, it verifies the vote of the nth proposal and produces a block.

[0078] In some possible implementations, the subject matter of the present disclosure, namely, blockchain consensus method and system, may be implemented in the form of a program product, which includes program code. When the program product is run on a terminal device, the program code is used to enable the terminal device to execute the steps of various exemplary implementations of the present disclosure described in the above “Exemplary Method” section of this specification.

[0079] The storage medium of the present disclosure can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, a system, device or component of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0080] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not limited to the embodiments shown herein but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A blockchain consensus method, characterized in that: include: Each round of tasks is divided into the proposal stage, voting stage, and submission stage, and is carried out in parallel using a pipeline. After each round of tasks passes verification, it enters the submission stage. At the beginning of the nth round of consensus, the proposal phase begins. The master node of the blockchain network issues the nth proposal and broadcasts it to the slave nodes. This phase begins with the voting phase. After receiving the nth proposal from the master node, the slave node generates a vote and sends it to the master node. When the master node receives votes from more than 2 / 3 of the slave nodes, it verifies the votes and submits them for block generation, and enters the n+1th round of consensus. The master node of the blockchain network sends the n+1th proposal carrying all the votes collected in the nth round of proposals to the slave nodes, so that after receiving the n+1th proposal, the slave nodes verify the votes for the nth proposal and generate blocks.

2. The blockchain consensus method according to claim 1, characterized in that: The communication between the master node and the slave node is based on the libp2p protocol stack to build a decentralized P2P network, using the TCP transmission protocol to achieve point-to-point transmission of proposal broadcasting and voting. Among them, the slave node locates the PeerID of the master node through the libp2p distributed hash table, subscribes to the Leader's exclusive topic proposal, and the message is encoded in Protobuf.

3. The blockchain consensus method according to claim 1, characterized in that: The blockchain consensus method further includes: Privacy mechanisms are set up between each node to ensure the security of data and sensitive information. The privacy mechanisms set up include: Inter-node communication uses a dynamic key exchange protocol to generate temporary session keys and implements forward secrecy through TLS1.3 transport layer encryption. Application layer data is end-to-end encrypted using the recipient's public key, and the encrypted ciphertext is transmitted through a predefined communication channel. Sensitive data is replaced with a hash value, encrypted and stored in an off-chain distributed storage system. A concatenated hash value containing a random number is generated and stored on the blockchain. The on-chain smart contract records the hash value of the encrypted data and the storage location metadata. When a consensus node accesses off-chain data, it needs to reorganize the decryption private key shards and meet the threshold signature conditions.

4. The blockchain consensus method according to claim 1, characterized in that: The blockchain consensus method also includes: when a node receives an illegal task, confirming the authenticity of the source by verifying the digital signature of the task, and marking it as illegal if the digital signature does not match the preset authority certificate.

5. The blockchain consensus method according to claim 1, characterized in that: The blockchain consensus method also includes: using hash summary comparison to detect whether the task data has been tampered with during transmission. If the hash does not match, the node will trigger an on-chain alarm event and record the sender address and payload hash of the abnormal task.

6. The blockchain consensus method according to claim 1, characterized in that: The blockchain consensus method further includes: verifying whether the initiating node is a consensus node according to preset rules of the node.

7. A blockchain consensus system, characterized in that: include: The planning module is used to split each round of tasks into the proposal stage, the voting stage, and the submission stage, and adopts pipeline parallelization. After each round of tasks passes verification, it enters the submission stage; The proposal and voting module is used to enter the proposal phase at the beginning of the nth round of consensus tasks. The master node of the blockchain network issues the nth proposal and broadcasts it to the slave nodes. Then, the voting phase begins. After receiving the nth proposal from the master node, the slave node generates a vote and sends it to the master node. The verification module is used to verify the votes and submit them for block generation after the master node receives votes from more than 2 / 3 of the slave nodes, and then enter the n+1th round of consensus. The master node of the blockchain network sends the n+1th proposal carrying all the votes collected in the nth round of proposals to the slave nodes, so that after receiving the n+1th proposal, the slave nodes will verify the votes for the nth proposal and generate blocks.

8. The blockchain consensus system according to claim 7, characterized in that: The communication between the master node and the slave node is based on the libp2p protocol stack to build a decentralized P2P network, using the TCP transmission protocol to achieve point-to-point transmission of proposal broadcasting and voting. Among them, the slave node locates the PeerID of the master node through the libp2p distributed hash table, subscribes to the Leader's exclusive topic proposal, and the message is encoded in Protobuf.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps of the blockchain consensus method according to any one of claims 1 to 6 are implemented.

10. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the blockchain consensus method according to any one of claims 1 to 6 are implemented.

Images