Block consensus method and device

Abstract

The invention discloses a block consensus method and device, and relates to the technical field of block chains, and the method comprises the steps that a first node obtains an ith block broadcasted by a second node in sequence; the ith block is a new block generated by the second node in the round, and the ith block comprises position information of a plurality of historical blocks and aggregation pointers of the plurality of historical blocks; the plurality of historical blocks are a plurality of (i-1) th blocks in a local chain of the second node; the aggregation pointer is obtained by the second node based on the position certificates of the plurality of historical blocks; and the first node verifies the aggregation pointer, and adds the ith block to the local chain after the verification is passed and the fact that the position certificates of the plurality of historical blocks and the consistency certificates of the plurality of historical blocks are cached locally is confirmed. The communication complexity between global nodes and the global storage complexity are reduced under the condition that the security consensus of the block chain system is ensured.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of blockchains, and in particular to a block consensus method and device. BACKGROUND

[0002] The DAG-BFT consensus algorithm adopts a directed acyclic graph structure to replace the traditional linear blockchain, and the core feature is that each block can refer to multiple predecessor blocks instead of a single parent block, forming a mesh topology. Multiple validators generate blocks in parallel, generate authentication certificates for the blocks through node communication interaction, and weave them into a DAG according to the pointer reference relationship, significantly improving concurrency. The reference relationship between blocks naturally records the causal partial order, and the algorithm determines the total order of transactions by traversing the DAG topology.

[0003] However, in the existing DAG-BFT consensus algorithm, the certificate of each block is composed of a set of signatures of at least 2f+1 nodes, and the certificate size is O(n·λ) bits (n is the number of nodes, and λ is the signature length). These signatures are repeatedly referenced in the DAG, resulting in a large amount of redundant data. SUMMARY

[0004] Embodiments of the present application provide a block consensus method and device for reducing the communication complexity and global storage complexity between global nodes while ensuring safe consensus of the blockchain system.

[0005] In a first aspect, embodiments of the present application provide a block consensus method, comprising: A first node obtains an i-th block broadcasted in sequence by a second node; the i-th block is a new block generated by the second node in the current round, and the i-th block includes position information of a plurality of historical blocks and an aggregated pointer of the plurality of historical blocks; the plurality of historical blocks are a plurality of (i-1)-th blocks in a local chain of the second node; the aggregated pointer is obtained by the second node based on position certificates of the plurality of historical blocks; and the position certificate of any historical block is obtained by signing after a third node other than the block generation node authenticates the position information of the historical block; The first node verifies the aggregated pointer, and after verification is passed and it is confirmed that the position certificates of the plurality of historical blocks and consistency certificates of the plurality of historical blocks are cached locally, the i-th block is added to the local chain; and the consistency certificate of any historical block is obtained by signing after a third node other than the block generation node authenticates the content information of the historical block.

[0006] The double-certificate mechanism of the consistency certificate and the location certificate ensures that all honest nodes in the blockchain system eventually receive the same content, and ensures that at least 2f+1 nodes confirm the validity of the locations and the block and certificate information before the locations. Moreover, through the aggregation pointer, when subsequent blocks are referenced, only the aggregated signature needs to be verified, and each pointer does not need to be verified one by one, and the calculation overhead is greatly reduced. Through the entire method flow, the local DAG of each node in the blockchain system can ensure the complete consistency of the structure and content, and the verification calculation complexity is significantly reduced through the secondary aggregation signature.

[0007] In a possible implementation, the first node verifies the aggregation pointer, including: The first node verifies the aggregation pointer using a joint public key, the joint public key being generated by nodes in the blockchain system in cooperation, and each node holding a respective private key shard, and multiple private key shards being reconstructable into a joint private key corresponding to the joint public key. The location certificate of any historical block is signed by multiple third nodes using respective private key shards to authenticate location information of the historical block.

[0008] In a possible implementation, the method further includes: If the first node confirms that the local cache is missing the location certificate and / or the consistency certificate of at least one historical block, the first node broadcasts a help message, the help message including location information of the missing historical block. The first node accepts the location certificate and / or the consistency certificate of the missing historical block sent by other nodes.

[0009] In a possible implementation, after the ith block is added to the local chain, the method further includes: The first node receives the consistency certificate of the ith block and the location certificate of the ith block broadcast by the second node; If the first node authenticates the consistency certificate of the ith block and the location certificate of the ith block, the first node saves the consistency certificate of the ith block and the location certificate of the ith block to the local, and adds the ith block to the local chain.

[0010] In a possible implementation, the consistency certificate of any historical block is signed by a third node other than the block generation node after authenticating content information of the historical block, including: The third node performs validity verification on the historical block, performs share signature on a hash value of the historical block using a private key shard, and sends a first signature result to the block generation node; The third node receives the consistency certificate of the historical block sent by the block producing node. The consistency certificate of the historical block is obtained by the block producing node based on the aggregation of the first signature results sent by each third node. The third node uses the joint public key to verify the consistency certificate of the historical block. If the verification is successful, it is confirmed that the content information of the historical block has been authenticated by the third node that exceeds the authentication threshold.

[0011] In one possible implementation, the location certificate of any historical block is obtained by signing the location information of the historical block after authentication by a third node other than the block-producing node, including: The third node uses its private key to perform share signing on the location information of the historical block, and sends the second signature result to the block-producing node. The third node receives the location certificate of the historical block sent by the block-producing node. The location certificate of the historical block is obtained by the block-producing node based on the aggregation of the second signature results sent by each third node. The third node uses the joint public key to verify the location certificate of the historical block. If the verification is successful, it is confirmed that the location information of the historical block has been authenticated by the third node that exceeds the authentication threshold.

[0012] This application decomposes the original single certificate into two independent certificates: a Consistency Certificate, generated via the Bracha Consistent Broadcast (CBC) protocol, ensuring that all honest nodes receive the same block content. It is generated once and used multiple times, with a size of O(λ). A Position Certificate, generated by performing a BLS threshold signature on the block's position information (i, r) (where i is the node sequence number and r is the round number), is used as proof of the validity of pointer references and has a size of O(n+λ). This functional decoupling eliminates the redundancy between certificates and pointers found in traditional schemes. Content consistency is guaranteed once by CBC, while the position marker is handled independently using a lightweight signature.

[0013] Secondly, the present invention provides a block consensus device suitable for blockchain systems that generate blocks in parallel, the device comprising: The acquisition module is used to acquire the i-th block broadcast sequentially by the second node; the i-th block is a new block generated by the second node in this round, and the i-th block includes the location information of multiple historical blocks and an aggregation pointer of the multiple historical blocks; the multiple historical blocks are multiple (i-1)-th blocks in the local chain of the second node; the aggregation pointer is obtained by the second node based on the location certificates of the multiple historical blocks; the location certificate of any historical block is obtained by a third node other than the block-producing node authenticating and signing the location information of the historical block; The determination module is used to verify the aggregate pointer. After the verification is successful and it is confirmed that the location certificates and consistency certificates of the multiple historical blocks are cached locally, the i-th block is added to the local chain. The consistency certificate of any historical block is obtained by signing the content information of the historical block after authentication by a third node other than the block producing node.

[0014] By employing a dual-certificate mechanism of consistency and location certificates, it is ensured that all honest nodes in the blockchain system will ultimately receive the same content, guaranteeing the validity of at least 2f+1 nodes confirming the validity of these locations and the blocks and certificate information preceding them. Furthermore, by using aggregated pointers, subsequent block references only require verification of the aggregated signature, eliminating the need to verify each pointer individually, significantly reducing computational overhead. Through this entire process, the local DAG of each node in the blockchain system guarantees complete consistency in structure and content, while the secondary aggregated signature significantly reduces the computational complexity of verification.

[0015] In one possible implementation, the determining module is specifically used for: The first node uses a joint public key to verify the aggregate pointer; the joint public key is generated collaboratively by the nodes in the blockchain system, and each node holds its own private key shard, and multiple private key shards can reconstruct a joint private key corresponding to the joint public key; The location certificate for any historical block is obtained by multiple third-party nodes authenticating the location information of the historical block using their respective private key fragments and then signing it.

[0016] In one possible implementation, the determining module is specifically used for: If the first node confirms that its local cache is missing at least one historical block's location certificate and / or consistency certificate, the first node broadcasts a help message, which includes the location information of the missing historical block. The first node accepts the location certificate and / or consistency certificate of the missing historical block sent from other nodes.

[0017] In one possible implementation, the acquisition module is specifically used for: The first node receives the consistency certificate and location certificate of the i-th block broadcast by the second node; If the first node successfully authenticates the consistency certificate and location certificate of the i-th block, it saves the consistency certificate and location certificate of the i-th block locally and adds the i-th block to the local chain.

[0018] In one possible implementation, the determining module is specifically used for: After verifying the validity of the historical block, the third node uses its private key to perform a share signature on the hash value of the historical block and sends the first signature result to the block-producing node. The third node receives the consistency certificate of the historical block sent by the block producing node. The consistency certificate of the historical block is obtained by the block producing node based on the aggregation of the first signature results sent by each third node. The third node uses the joint public key to verify the consistency certificate of the historical block. If the verification is successful, it is confirmed that the content information of the historical block has been authenticated by the third node that exceeds the authentication threshold.

[0019] In one possible implementation, the determining module is specifically used for: The third node uses its private key to perform share signing on the location information of the historical block and sends the second signature result to the block-producing node. The third node receives the location certificate of the historical block sent by the block-producing node. The location certificate of the historical block is obtained by the block-producing node based on the aggregation of the second signature results sent by each third node. The third node uses the joint public key to verify the location certificate of the historical block. If the verification is successful, it is confirmed that the location information of the historical block has been authenticated by the third node that exceeds the authentication threshold.

[0020] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor performs any of the block consensus methods described in the first aspect above.

[0021] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform any of the block consensus methods described in the first aspect above.

[0022] Fifthly, embodiments of this application provide a computer program product including a computer program / instruction that, when executed by a processor, implements the block consensus method described in any of the first aspects above. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 A flowchart illustrating a block consensus method provided in an embodiment of this application; Figure 2 A flowchart illustrating a block consensus method provided in an embodiment of this application; Figure 3 A flowchart illustrating the process of block generation and consistency certificate broadcasting provided in this application embodiment; Figure 4 A flowchart illustrating the process of block location signing and location certificate generation provided in this application embodiment; Figure 5 A schematic diagram of a block consensus device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and beneficial effects of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0026] The following is an explanation of the terms that appear in this application: DAG: Directed Acyclic Graph, a data structure consisting of vertices and directed edges. "Directed" means the edges have a direction, and "acyclic" means that starting from any vertex and traversing along the edges, it's impossible to return to the origin. In blockchain, DAGs are used to organize blocks, allowing each new block to reference multiple predecessor blocks, forming a mesh-like rather than chain-like structure, thus supporting high-concurrency transaction processing.

[0027] BFT: Byzantine Fault Tolerance, refers to a class of distributed consensus algorithms whose core goal is to enable a distributed system to reach consensus and operate correctly even in the presence of malicious nodes (Byzantine nodes). The classic conclusion is that a system needs at least 3f+1 main nodes to tolerate f malicious nodes. BFT algorithms (such as PBFT and HotStuff) typically ensure security through multiple rounds of voting and message exchange.

[0028] BLS (Boneh-Lynn-Shacham) is a pairwise digital signature scheme. Its core feature is signature aggregation: multiple BLS signatures for different messages can be merged into a new signature of fixed size; the verifier only needs one pairwise operation to verify this aggregated signature, thereby simultaneously confirming the validity of all original signatures. This feature makes it a key technology for blockchain scaling.

[0029] CBC: Consistent Broadcast, in distributed systems, is a reliable broadcast primitive. It guarantees that if an honest node delivers (accepts) a message, then all honest nodes will eventually deliver the same message. It is stronger than "reliable broadcast" because it prevents malicious senders from sending different messages to different nodes. In the scenario you analyzed, it is used to ensure that block data is reliably and consistently propagated among all honest nodes.

[0030] DKG (Distributed Key Generation) allows multiple participants to collaboratively generate a distributed key without a trusted central authority. Ultimately, each participant holds a private key fragment, while the corresponding full public key is publicly available. A key cryptographic property is that the complete private key is never fully present on any single node, but by collecting a sufficient number (e.g., t) of private key fragments, the power to reconstruct or exercise the full private key can be granted.

[0031] Aggregate signature: A cryptographic technique that combines multiple signatures into a single signature. It can compress and merge multiple signatures from multiple signers (usually for different messages) into a short signature. The verifier only needs to verify this aggregate signature to confirm that all the original signatures are valid at once. BLS is currently the most mainstream aggregate signature scheme.

[0032] Threshold signatures are a combination of DKG (Data Key Group) and signatures. In a threshold signature scheme, the private key is sharded (t, n) and distributed to n participants. When a valid signature needs to be generated, any t participants only need to use their respective private key shards to generate "partial signatures," and these partial signatures can then be combined into a complete signature that is identical to the one generated using the full private key. Outsiders cannot distinguish between a threshold signature and a regular signature.

[0033] The DAG-BFT consensus algorithm replaces the traditional linear blockchain with a directed acyclic graph (DAG) structure. Its core feature is that each block can reference multiple predecessor blocks simultaneously, rather than a single parent block, forming a mesh topology. Multiple validators generate blocks in parallel, generating block authentication certificates through node communication and weaving them into a DAG based on pointer reference relationships, significantly improving concurrency. The reference relationships between blocks naturally record causal partial orders, and the algorithm determines the total order of transactions by traversing the DAG topology. Specifically, the formula for the DAG-BFT algorithm is as follows: 1. DAG block construction: When generating a block in a specific round, each validator node must reference at least two-thirds of the blocks from the previous round as its parent block. For example, in round 5, the block created by node A needs to reference the blocks from a majority of the nodes in round 4, forming a multi-parent reference relationship. This mandatory reference rule ensures the connectivity and complete recording of causal relationships in the DAG.

[0034] After a node broadcasts a block, other validators verify and sign it. When a block has collected signatures from more than 2 / 3 of the validators, a Quorum Certificate is formed, and the block is considered valid and can be referenced by blocks in the next round.

[0035] 2. Leader and Anchor Point Mechanism: In algorithms such as Narwhal-Bullshark, a leader node is selected in each round using a unified rule (e.g., taking the round number modulo a hash function in a semi-synchronous network, or using a random coin toss algorithm in an asynchronous network). The block proposed by the leader in that round is called the "anchor block." As the representative block of that round, the anchor block determines the final overall order of the DAG blockchain.

[0036] 3. Submission and sorting rules

[0037] The consensus layer continuously monitors the anchors in the DAG. A commit is triggered when a continuous chain of anchor references is detected: if the anchor of round r+2 can be traced back to the anchor of round r+1, and the anchor of round r+1 can be traced back to the anchor of round r, then the anchor of round r and all its ancestor blocks are committed.

[0038] This "two-round confirmation" mechanism ensures security: even if there are malicious nodes, as long as honest nodes exceed 2 / 3, a consistent anchor chain can be formed.

[0039] 4. Transaction full sequence generation

[0040] For a set of submitted blocks, the algorithm traverses the DAG to generate a deterministic sequence of transactions, prioritizing rounds and sorting by block hashes within the same round. All honest nodes execute the same sorting algorithm, resulting in a consistent anchor block and all its ancestor blocks, thus generating a consistent transaction order and achieving consensus. This process is entirely based on the DAG topology and requires no additional communication.

[0041] However, in the above process, existing DAG-BFT consensus algorithms (such as Narwhal-Bullshark) suffer from communication and storage bottlenecks: Question 1: Certificate Redundancy Problem: Each block's certificate consists of a set of signatures from at least 2f+1 nodes, and the certificate size is O(n^2). λ bits (n is the number of nodes, λ is the signature length). These signatures are repeatedly referenced in the DAG, generating a large amount of redundant data.

[0042] Question 2: Excessive pointer size: When subsequent blocks reference preceding blocks, the pointer must contain the complete certificate, causing the size of a single pointer to reach O(n^2). Each block requires references to approximately 2f+1 ≈ n preceding blocks, resulting in a total pointer overhead of O(n²). λ).

[0043] Question 3: High communication and storage complexity. Global communication complexity: O(λ) (Number of nodes n × Number of broadcasts per node n × Pointer size O(n)) Global storage complexity: O(λ) (Each node stores n rounds of blocks from n nodes and their pointers.)

[0044] Question 4: Functional coupling. In the existing solution, the certificate simultaneously undertakes the two functions of "ensuring content consistency" and "marking block position", and these two dimensions cannot be optimized independently.

[0045] Therefore, this application proposes as follows Figure 1 The diagram illustrates a block consensus method used in a blockchain system for parallel block generation. The following explanation uses the second node as the node currently producing blocks, and the first node as any other node in the blockchain system besides the second node, to illustrate the steps of the method. The steps include: Step S101: The first node obtains the i-th block broadcast sequentially by the second node; the i-th block is a new block generated by the second node in this round, and the i-th block includes the location information of multiple historical blocks and the aggregation pointer of multiple historical blocks; the multiple historical blocks are multiple (i-1)-th blocks in the local chain of the second node; the aggregation pointer is obtained by the second node based on the location certificates of multiple historical blocks; the location certificate of any historical block is obtained by a third node other than the block-producing node authenticating and signing the location information of the historical block.

[0046] For example, suppose a blockchain system has four nodes: Node0, Node1, Node2, and Node3. Currently, in round 6, the second node, Node1, generates its own block B(1,6), while the remaining nodes, Node0, Node2, and Node3, are the first nodes. In block B(1,6), 1 and 6 represent the block generated by node Node1 in round 6, and (1,6) represents the block's position. According to the theory of DAG block construction, Node1 needs to select a historical block from the previous round for reference. This historical block is a block generated by Node0, Node2, and Node3 in the first node's local chain. Assume that Node1 has already broadcast the block with index 4, where index is the sequence number of the locally generated block, counting from 0. Each node maintains a local counter to record how many blocks it has generated. This counter increments by 1 for each new block generated. The index is the value of this counter. Block B(1,6) of Node1 references (points to) historical blocks: Block B(0,5) of Node0 in round 5, Block B(2,5) of Node2 in round 5, and Block B(3,5) of Node3 in round 5. Therefore, the new block structure of Node1 is: B(1,6) = { node_id: 1, round: 6, index: 6, data: TransactionData, parent_positions:[

[0047] (0, 5), / / Points to the 5th block of Node0

[0048] (2, 5), / / Points to the 5th block of Node2

[0049] (3, 5) / / points to the 5th block of Node3]}, where TransactionData is the transaction data and parent_positions is the position information of historical blocks. Each historical block has its corresponding position certificate. Taking historical block B(0, 5) as an example, the position certificate of historical block B(0, 5) is obtained by the third nodes Node1, Node2, and Node3 (other than the block-producing node Node0 of the previous rounds) authenticating and signing the position information of B(0, 5). The position certificate indicates that any 2f+1 third nodes other than the block-producing node in the blockchain system recognize the position of the block, where f is the maximum number of malicious nodes tolerated in the blockchain system.

[0050] The second node, Node1, aggregates the position certificates of historical blocks B(0, 5), B(2, 5), and B(3, 5) to obtain an aggregate pointer. The final block structure for Node1 is: B(1,6) = B(1,6) = { node_id: 1, round: 6, data: TransactionData, parent_positions: [(0,5), (2,5), (3,5)], aggregate pointer}. Node1 then broadcasts this final block to all first nodes.

[0051] In step S102, the first node verifies the aggregate pointer. After the verification is successful and it is confirmed that there are multiple location certificates and multiple consistency certificates of historical blocks in the local cache, the i-th block is added to the local chain. The consistency certificate of any historical block is obtained by signing the content information of the historical block after being certified by a third node other than the block producing node.

[0052] As in the embodiment of step S101 above, in step S102, the first nodes (Node0, Node2, and Node3) receive block B(1,6) broadcast by the second node Node1. Taking any first node Node2 as an example, Node2 verifies the aggregation pointer. If the verification passes, it confirms that all historical blocks pointed to by block B(1,6) have been consensus verified. Then, Node2 checks whether each (i, r) ∈ parent_positions in the local DAG contains the location certificate and consistency certificate of the block at that position. If the complete information of all referenced positions (i, r) is confirmed, based on the property of ordered broadcast, once Node2 has confirmed that the location certificates of all historical blocks (i, r) are valid, it can be confirmed that all blocks before Nodei at that position have been broadcast. Each historical block has its corresponding consistency certificate. Taking historical block B (0, 5) as an example, the position certificate of historical block B (0, 5) is obtained by the third nodes Node1, Node2, and Node3 (other than the block-producing node Node0) of the previous rounds authenticating and signing the content information of B (0, 5). The consistency certificate indicates that, excluding the block-producing node, any 2f+1 third nodes in the blockchain system recognize the content of the block.

[0053] By employing a dual-certificate mechanism of consistency and location certificates, it is ensured that all honest nodes in the blockchain system will ultimately receive the same content, guaranteeing the validity of at least 2f+1 nodes confirming the validity of these locations and the blocks and certificate information preceding them. Furthermore, by using aggregated pointers, subsequent block references only require verification of the aggregated signature, eliminating the need to verify each pointer individually, significantly reducing computational overhead. Through this entire process, the local DAG of each node in the blockchain system guarantees complete consistency in structure and content, while the secondary aggregated signature significantly reduces the computational complexity of verification.

[0054] It should be noted that in existing technologies, to ensure the authentication of node block history during the block broadcasting phase through ordered broadcasting (requiring blocks to be broadcast in a fixed ascending order), the existing block pointer structure is {block hash, complete consistency certificate, block identifier (i, r)}, with a pointer size of O(2λ+log n). In this scheme, however, ordered broadcasting is combined with location information and location certificates as secure and reliable block pointers. The improved block pointer structure is {location information (i, r), location certificate σ_pos}, with a size of O(λ+log n), resulting in an improvement factor of O(λ) for the size of a single pointer. Since each block has O(n) pointers, the total pointer overhead is reduced by O(nλ), saving approximately 50% of the data. Furthermore, the location information of multiple historical blocks and the aggregated pointers of multiple historical blocks are further compressed, compressing the total pointer size from O(n·λ) to O(λ), an improvement factor of O(n).

[0055] The communication complexity in this scheme is as follows: CBC phase: O(λn²) (multiple rounds of hash broadcasting); location signature reply: O(λn²) (each node replies with a signature); location certificate broadcast: O(λn) (constant size after aggregation); total: O(λn² + n²logn). The storage complexity in this scheme is as follows: each node stores blocks from n nodes, each block has n pointers (nlogn), and the size of the pointer certificates within a block is O(λ). The total complexity is: n × n × O(n + λ) ≈ O(λn² + n²logn), which is significantly lower than the O(λn² + n²logn) complexity of DAG-BFT schemes such as Narwhal-Bullshark. The improvement factor is O(n²). Therefore, the method in this application greatly reduces the communication complexity and storage complexity in the blockchain system.

[0056] The following will detail how the consistency certificate and location certificate of any historical block are obtained in steps S101 and S102 above.

[0057] The consistency certificate of any historical block is obtained by signing the content information of the historical block after authentication by a third node other than the block-producing node. This process includes: after the third node verifies the validity of the historical block, it uses its private key to shard the hash value of the historical block to perform share signing, and sends the first signature result to the block-producing node. The third node receives the consistency certificate of the historical block sent by the block-producing node. The consistency certificate of the historical block is obtained by the block-producing node by aggregating the first signature results sent by each third node. The third node uses the joint public key to verify the consistency certificate of the historical block. If the verification is successful, it is confirmed that the content information of the historical block has been authenticated by a third node that exceeds the authentication threshold. The location certificate of any historical block is obtained by signing the location information of the historical block after authentication by a third node other than the block-producing node. This process includes: the third node using its private key to shard the location information of the historical block to perform share signing, and sending the second signature result to the block-producing node; the third node receiving the location certificate of the historical block sent by the block-producing node, which is obtained by the block-producing node by aggregating the second signature results sent by each third node; and the third node using a joint public key to verify the location certificate of the historical block. If the verification is successful, it is confirmed that the location information of the historical block has been authenticated by a third node that exceeds the authentication threshold.

[0058] For example, let's take a 4-node system (Node0-Node3) as an example. f=1 (therefore 2f+1=3, the system has 4 nodes (n=4). According to the BFT formula n ≥ 3f + 1, we can calculate f=1 (because 4 ≥ 3). (1 + 1). f is the maximum tolerable malicious node. The Pedersen DKG protocol is executed once at system startup, with all nodes collaborating to generate a joint public key PK and their respective private key fragments sk_j. It is guaranteed that any 2f+1 nodes can collaboratively reconstruct the private key sk, and any node with fewer than 2f nodes cannot obtain the information of sk. After DKG is completed, the joint public key PK is stored as a system-level constant by all nodes.

[0059] Taking a historical block B (0, 5) referenced in step S101 above as an example, such as Figure 2 As shown, Node0 generates block B(0,5), which contains transaction data. The system has completed DKG initialization, and all nodes hold private key shards sk_0, sk_1, sk_2, and sk_3, with the joint public key PK. The process of generating historical block B(0,5) and broadcasting the consistency certificate is as follows: Figure 3 As shown, it includes the following steps: Step S201: Node0 generates block B (0, 5) and initiates a broadcast; When Node0 has completed the consistent broadcast of the block with node_id=0 and index 3, and has locally confirmed the collection of 2f+1 round:4 blocks, Node0 enters round 5, generates a block, and initiates a consistent broadcast with its sequence number: Node0 generates a block: B(0,5) = { node_id: 0, round: 5, index: 4, data:TransactionData, parent_refs: [pointer information referencing the parent block of the previous round 4]}. `round` indicates the time stage of the node's broadcast and also represents the block's position on the DAG; `index` represents the sequence number of the block broadcast by the node. Here, `index` represents the sequence number of the block generated locally by the node. Each node maintains a local counter to record how many blocks it has generated. This counter increments by 1 for each new block generated. `index` is the value of this counter.

[0060] Next, Node0 calculates the full information hash of the block: h_full = H(B(0,5)) (using SHA-256, the result is 256 bits) and broadcasts the block content to all nodes: Node0 → All nodes: ("INIT", B(0,5)).

[0061] Step S202: Other nodes verify and sign the complete message; After Node1, Node2, and Node3 receive the INIT message: 1. Verify the validity of the block (including the correctness of transaction information, whether the block reference pointer is valid, etc.); 2. Check if the block with node_id=0 and index=3 has been stored locally. If not, query other nodes until the complete information of the block is obtained, and then proceed to the subsequent processing of B(0,5). 3. Calculate the same hash: h_full = H(B(0,5)); 4. Use your own private key to perform BLS signing: σ_1 = h_full^{sk_1} / / Share signature of Node1 σ_2 = h_full^{sk_2} / / Share signature of Node2 σ_3 = h_full^{sk_3} / / Share signature of Node3 4. Each node sends its share signature to Node0: Node1 → Node0: (σ_1, 1) Node2 → Node0: (σ_2, 2) Node3 → Node0: (σ_3, 3) Step S203: Node0 aggregates signatures to generate a consistency certificate; Node0 collects three share signatures from Node1, Node2, and Node3 and verifies their correctness, resulting in the set: S_cons = {1, 2, 3} Calculate the Lagrange coefficients (modulus p operation) for each node in S_cons: λ_1(0) = (0-2)·(0-3) / [(1-2)·(1-3)] = 6 / 2 = 3 λ_2(0) = (0-1)·(0-3) / [(2-1)·(2-3)] = 3 / (-1) ≡ p-3 (mod p) λ_3(0) = (0-1)·(0-2) / [(3-1)·(3-2)] = 2 / 2 = 1 Aggregate signature shares: σ_cons = σ_1^{λ_1(0)} · σ_2^{λ_2(0)} · σ_3^{λ_3(0)} = (h_full^{sk_1})^3 · (h_full^{sk_2})^{p-3} · (h_full^{sk_3})^1 = h_full^{3·sk_1 + (p-3)·sk_2 + 1·sk_3} = h_full^{sk} A valid consistency certificate is obtained: cert_cons(0,5) = σ_cons Step S204: Node0 broadcasts the consistency certificate; Node0 → All nodes: ("CONS_CERT", node_id: 0, round: 5, index: 4, σ_cons,) Upon receiving the data, all nodes verify it using the joint public key PK: the verification equation is: e(σ_cons, g) = e(h_full, PK), where e(·,·) are pairwise operations, g is the generator, and PK is the system's joint public key, which is publicly available from the beginning. If the verification passes, the node stores the complete content of B(0,5), h_full = H(B(0,5)) and σ_cons. This broadcast ensures that all honest nodes, through the consensus certificate, confirm that the complete information of B(0,5) has been recognized by at least 2f+1 nodes.

[0062] The process of generating the location signature and location certificate for historical block B (0, 5) is as follows: Figure 4 As shown, it includes the following steps: Step S301: Each node signs the location information; All nodes (including Node0 itself) sign the position of B(0,5): Location information: pos(0,5) = (node_id=0, round=5) Location information hash: h_pos = H(0 || 5) For each node j, calculate the partial signature of its position: σ'_1 = h_pos^{sk_1} / / Location share signature of Node1 σ'_2 = h_pos^{sk_2} / / Location share signature of Node2 σ'_3 = h_pos^{sk_3} / / Location share signature of Node3 Each node sends a location share signature to Node0: Node1 → Node0: (σ'_1, 1) Node2 → Node0: (σ'_2, 2) Node3 → Node0: (σ'_3, 3) Step S302: Node0 aggregates location signatures to generate a location certificate; Node0 collects partial signatures from Node1, Node2, and Node3 at three positions: S_pos = {1, 2, 3} / / The set of nodes participating in the position signature.

[0063] Calculate the Lagrange coefficient for each node in S_pos (same as in step S203): λ_1(0) = 3 λ_2(0) = p-3 λ_3(0) = 1 Aggregate location signature: σ_pos = σ'_1^{λ_1(0)} · σ'_2^{λ_2(0)} · σ'_3^{λ_3(0)} = (h_pos^{sk_1})^3 · (h_pos^{sk_2})^{p-3} · (h_pos^{sk_3})^1 = h_pos^{3·sk_1 + (p-3)·sk_2 + 1·sk_3} = h_pos^{sk} The location certificate is obtained using the properties of the Lagrange coefficient: cert_pos(0,5) = σ_pos Step S303: Node0 broadcasts its location certificate; Node0 → All nodes: ("POS_CERT", 0, 5, σ_pos, S_pos) All nodes verify the received data. Verify the equation: e(σ_pos, g) = e(h_pos, PK} If the verification passes, the node stores cert_pos(0,5) = σ_pos(0,5) in the corresponding position (0,5) on the DAG; at this point, position (0,5) has been fully confirmed, including the consistency certificate and the position certificate.

[0064] This application decomposes the original single certificate into two independent certificates: a Consistency Certificate, generated via the Bracha Consistent Broadcast (CBC) protocol, ensuring that all honest nodes receive the same block content. It is generated once and used multiple times, with a size of O(λ). A Position Certificate, generated by performing a BLS threshold signature on the block's position information (i, r) (where i is the node sequence number and r is the round number), is used as proof of the validity of pointer references and has a size of O(n+λ). This functional decoupling eliminates the redundancy between certificates and pointers found in traditional schemes. Content consistency is guaranteed once by CBC, while the position marker is handled independently using a lightweight signature.

[0065] Optionally, this application incorporates ordered broadcasting, using location information and location certificates as secure and reliable block pointers. During the block broadcasting phase, ordered broadcasting (requiring blocks to be broadcast in a fixed ascending order) ensures the authentication of node block history, allowing nodes to confirm the reliable propagation of blocks solely based on location certificates. The pointer structure in existing technologies is: {block hash, complete consistency certificate, block identifier (i, r)}, with a size of O(2λ+log n). The pointer structure in this application is: {location information (i, r), location certificate σ_pos}, with a size of O(λ+log n), where (i, r) accounts for O(log n) and σ_pos accounts for O(λ). Compared to existing technologies, this scheme improves the size of a single pointer by O(λ). Since each block has O(n) pointers, the total pointer overhead is reduced by O(nλ), saving approximately 50% of the data volume.

[0066] In step S102 above, the first node verifies the aggregate pointer, including: the first node verifies the aggregate pointer using the joint public key; the joint public key is generated collaboratively by each node in the blockchain system, and each node holds its own private key shard, and multiple private key shards can reconstruct the joint private key corresponding to the joint public key; wherein, the location certificate of any historical block is obtained by multiple third nodes authenticating the location information of the historical block using their respective private key shards and then signing it.

[0067] Taking the first and second nodes in steps S101 and S102 above as examples, the second node Node1 aggregates the location certificates of historical blocks B(0, 5), B(2, 5), and B(3, 5) to obtain the aggregate pointer σ_multi_refs. The calculation process is as follows: = σ_pos(0,5) · σ_pos(2,5) · σ_pos(3,5) = h_pos(0,5)^{sk} · h_pos(2,5)^{sk} · h_pos(3,5)^{sk} = [∏h_pos(i,5)]^{sk} Here, SK is the joint private key for the threshold signature within each location certificate (i.e., the private key that can be recovered by combining the private key shares sk_i of 2f+1 nodes). Since nodes use the same private key share for signing, each threshold signature is equivalent to a BLS signature obtained by signing different messages using the same private key. Based on this property, these threshold signatures can be aggregated again. The aggregation result is equivalent to signing the message ∏h_pos(i,5) using the joint private key SK, which can be verified by the joint public key PK.

[0068] Therefore, the final block B(1,6) of Node1 contains: B(1,6) = { node_id: 1, round: 6, data: TransactionData, parent_positions: [(0,5), (2,5), (3,5)], σ_multi_refs}

[0069] Node1 broadcasts this block: Node1 → All nodes: ("BLOCK", B(1,6))

[0070] When the first three nodes, Node0, Node2, and Node3, receive B(1,6), they use their public key PK to verify the aggregate signature of the multi-location certificates. If the verification passes, it confirms that all historical blocks referenced by the B(1,6) block have been verified by consensus. Next, Node0, Node2, and Node3 check whether their local DAG has stored complete information on the positions of all referenced historical blocks: for each (i, r) ∈ parent_positions, they check whether cert_cons(i,r) and cert_pos(i,r) are in the local DAG.

[0071] In this embodiment, the certificate based on BLS threshold signature technology is subjected to secondary aggregation and compression: 1. BLS threshold signature is used as the authentication certificate for each block; 2. The threshold signatures of block certificates of all nodes share the same public and private keys for signing; 3. The O(n) position certificates in the block, which serve as pointers, are aggregated in a secondary manner and aggregated into a single signature using Lagrange coefficients: Σ_pos = ∏_{j∈S} σ_j^{λ_j(0)} = H(i||r)^sk

[0072] The length of the aggregated signature is constant at λ bits, which is independent of the number of participating nodes. During verification, only the public key PK needs to be combined, without storing or transmitting the public keys of each node. The aggregated signature at the same position is the same for any 2f+1 node subset (deterministic). The total pointer size is further compressed from O(n·λ) to O(λ), with an improvement factor of O(n).

[0073] Optionally, if the first node confirms that its local cache is missing the location certificate and / or consistency certificate of at least one historical block, the first node broadcasts a help message, which includes the location information of the missing historical block; the first node accepts the location certificate and / or consistency certificate of the missing historical block sent by other nodes.

[0074] Specifically, if the first node's check fails to find a location certificate and / or consistency certificate for a certain position (i, r), the first node broadcasts a CallHelp message (CallHelp, i, r) to all nodes. Other nodes, upon receiving the message, will report back to the first node if they have complete information for that location locally. When a node receives f+1=2 identical complete information messages, it can store the missing location certificate and / or consistency certificate locally. Based on the ordered broadcast property, once the first node has confirmed that the location certificate for (i, r) is valid, it can confirm that all blocks before that position at Node i have been broadcast. Therefore, at least f+1 honest nodes will report back to the first node, ensuring that the first node can recover the information at all location pointers (i, r).

[0075] After adding the i-th block to the local chain in the above steps, the process further includes: the first node receiving the consistency certificate and location certificate of the i-th block broadcast by the second node; if the first node successfully authenticates the consistency certificate and location certificate of the i-th block, it saves the consistency certificate and location certificate of the i-th block to the local chain and adds the i-th block to the local chain.

[0076] As described in steps S101 and S102 above, after the first node (Node0, Node2, and Node3) adds block B(1,6) to the local chain, the second node Node1 repeats the above steps of generating the consistency certificate and location certificate to generate the consistency certificate and location certificate for block B(1,6). If the first node authenticates the consistency certificate and location certificate of block B(1,6), it is considered that the content and location of the block have reached the consensus of the first node. Then, the consistency certificate and location certificate of block B(1,6) are saved locally, and block B(1,6) is added to the local chain. At this time, block B(1,6) can be referenced by subsequent blocks.

[0077] Subsequently, through an anchor chain or a global sorting mechanism, the global consensus of block B(1,6) is achieved and uploaded to the chain. At this point, the transactions in block B(1,6) are given a unique and immutable order across the entire network, achieving finality. This is the traditional meaning of "on-chain".

[0078] Based on the same concept, this application also provides a block consensus device 500, which can execute the block consensus method described above.

[0079] Please see Figure 5 This application provides a schematic diagram of the structure of a block consensus device according to an embodiment of the present application, such as... Figure 5 As shown, the block consensus device 500 includes: The acquisition module 501 is used to acquire the i-th block broadcast sequentially by the second node; the i-th block is a new block generated by the second node in this round, and the i-th block includes the location information of multiple historical blocks and the aggregation pointer of the multiple historical blocks; the multiple historical blocks are multiple (i-1)-th blocks in the local chain of the second node; the aggregation pointer is obtained by the second node based on the location certificates of the multiple historical blocks; the location certificate of any historical block is obtained by a third node other than the block-producing node authenticating and signing the location information of the historical block; The determination module 502 is used to verify the aggregate pointer. After the verification is successful and it is confirmed that the location certificates and consistency certificates of the multiple historical blocks are cached locally, the i-th block is added to the local chain. The consistency certificate of any historical block is obtained by signing the content information of the historical block after authentication by a third node other than the block producing node.

[0080] By employing a dual-certificate mechanism of consistency and location certificates, it is ensured that all honest nodes in the blockchain system will ultimately receive the same content, guaranteeing the validity of at least 2f+1 nodes confirming the validity of these locations and the blocks and certificate information preceding them. Furthermore, by using aggregated pointers, subsequent block references only require verification of the aggregated signature, eliminating the need to verify each pointer individually, significantly reducing computational overhead. Through this entire process, the local DAG of each node in the blockchain system guarantees complete consistency in structure and content, while the secondary aggregated signature significantly reduces the computational complexity of verification.

[0081] In one possible implementation, the determining module 502 is specifically used for: The first node uses a joint public key to verify the aggregate pointer; the joint public key is generated collaboratively by the nodes in the blockchain system, and each node holds its own private key shard, and multiple private key shards can reconstruct a joint private key corresponding to the joint public key; The location certificate for any historical block is obtained by multiple third-party nodes authenticating the location information of the historical block using their respective private key fragments and then signing it.

[0082] In one possible implementation, the determining module 502 is specifically used for: If the first node confirms that its local cache is missing at least one historical block's location certificate and / or consistency certificate, the first node broadcasts a help message, which includes the location information of the missing historical block. The first node accepts the location certificate and / or consistency certificate of the missing historical block sent from other nodes.

[0083] In one possible implementation, the acquisition module 501 is specifically used for: The first node receives the consistency certificate and location certificate of the i-th block broadcast by the second node; If the first node successfully authenticates the consistency certificate and location certificate of the i-th block, it saves the consistency certificate and location certificate of the i-th block locally and adds the i-th block to the local chain.

[0084] In one possible implementation, the determining module 502 is specifically used for: After verifying the validity of the historical block, the third node uses its private key to perform a share signature on the hash value of the historical block and sends the first signature result to the block-producing node. The third node receives the consistency certificate of the historical block sent by the block producing node. The consistency certificate of the historical block is obtained by the block producing node based on the aggregation of the first signature results sent by each third node. The third node uses the joint public key to verify the consistency certificate of the historical block. If the verification is successful, it is confirmed that the content information of the historical block has been authenticated by the third node that exceeds the authentication threshold.

[0085] In one possible implementation, the determining module 502 is specifically used for: The third node uses its private key to perform share signing on the location information of the historical block and sends the second signature result to the block-producing node. The third node receives the location certificate of the historical block sent by the block-producing node. The location certificate of the historical block is obtained by the block-producing node based on the aggregation of the second signature results sent by each third node. The third node uses the joint public key to verify the location certificate of the historical block. If the verification is successful, it is confirmed that the location information of the historical block has been authenticated by the third node that exceeds the authentication threshold.

[0086] Based on the same technical concept, embodiments of this application provide a computer device, which can be... Figure 6 The terminal device 601 and / or server 602 shown are as follows: Figure 6 As shown, it includes at least one processor 601 and a memory 602 connected to at least one processor. In this embodiment, the specific connection medium between the processor 601 and the memory 602 is not limited. Figure 6 Taking the connection between the processor 601 and the memory 602 via a bus as an example, the bus can be divided into address bus, data bus, control bus, etc.

[0087] In this embodiment of the application, the memory 602 stores instructions that can be executed by at least one processor 601. By executing the instructions stored in the memory 602, at least one processor 601 can perform the steps of the above-described privacy transaction method.

[0088] The processor 601 serves as the control center of the computer device, connecting various parts of the device via interfaces and lines. It runs or executes instructions stored in the memory 602 and retrieves data stored in the memory 602, thereby reducing communication complexity and global storage complexity between global nodes while ensuring secure consensus within the blockchain system. Optionally, the processor 601 may include one or more processing units. The processor 601 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may not be integrated into the processor 601. In some embodiments, the processor 601 and the memory 602 may be implemented on the same chip; in other embodiments, they may be implemented on separate chips.

[0089] Processor 601 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0090] Memory 602, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 602 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic memory, magnetic disk, optical disk, etc. Memory 602 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer device, but is not limited thereto. In the embodiments of this application, memory 602 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0091] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of the above-described block consensus method.

[0092] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0093] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxesFigure 1 A device that provides the functions specified in one or more boxes.

[0094] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0095] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0096] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A block consensus method, characterized in that, A blockchain system suitable for parallel block generation, the method comprising: The first node obtains the i-th block broadcast sequentially by the second node; the i-th block is a new block generated by the second node in this round, and the i-th block includes the location information of multiple historical blocks and an aggregation pointer of the multiple historical blocks; the multiple historical blocks are multiple (i-1)-th blocks in the local chain of the second node; the aggregation pointer is obtained by the second node based on the location certificates of the multiple historical blocks; the location certificate of any historical block is obtained by a third node other than the block-producing node authenticating and signing the location information of the historical block; The first node verifies the aggregate pointer. If the verification is successful and the local cache contains the location certificates and consistency certificates of the multiple historical blocks, the first node adds the i-th block to the local chain. The consistency certificate of any historical block is obtained by signing the content information of the historical block after authentication by a third node other than the block-producing node.

2. The method as described in claim 1, characterized in that, The first node verifies the aggregate pointer, including: The first node uses a joint public key to verify the aggregate pointer; the joint public key is generated collaboratively by the nodes in the blockchain system, and each node holds its own private key shard, and multiple private key shards can reconstruct a joint private key corresponding to the joint public key; The location certificate for any historical block is obtained by multiple third-party nodes authenticating the location information of the historical block using their respective private key fragments and then signing it.

3. The method as described in claim 1, characterized in that, Also includes: If the first node confirms that its local cache is missing at least one historical block's location certificate and / or consistency certificate, the first node broadcasts a help message, which includes the location information of the missing historical block. The first node accepts the location certificate and / or consistency certificate of the missing historical block sent from other nodes.

4. The method according to any one of claims 1-3, characterized in that, After adding the i-th block to the local chain, the process further includes: The first node receives the consistency certificate and location certificate of the i-th block broadcast by the second node; If the first node successfully authenticates the consistency certificate and location certificate of the i-th block, it saves the consistency certificate and location certificate of the i-th block locally and adds the i-th block to the local chain.

5. The method as described in any one of claims 1-3, characterized in that, The consistency certificate for any historical block is obtained by signing the content information of the historical block after authentication by a third node other than the block-producing node, including: After verifying the validity of the historical block, the third node uses its private key to perform a share signature on the hash value of the historical block and sends the first signature result to the block-producing node. The third node receives the consistency certificate of the historical block sent by the block producing node. The consistency certificate of the historical block is obtained by the block producing node based on the aggregation of the first signature results sent by each third node. The third node uses the joint public key to verify the consistency certificate of the historical block. If the verification is successful, it is confirmed that the content information of the historical block has been authenticated by the third node that exceeds the authentication threshold.

6. The method according to any one of claims 1-3, characterized in that, The location certificate for any historical block is obtained by signing the location information of the historical block after authentication by a third node other than the block-producing node, including: The third node uses its private key to perform share signing on the location information of the historical block, and sends the second signature result to the block-producing node. The third node receives the location certificate of the historical block sent by the block-producing node. The location certificate of the historical block is obtained by the block-producing node based on the aggregation of the second signature results sent by each third node. The third node uses the joint public key to verify the location certificate of the historical block. If the verification is successful, it is confirmed that the location information of the historical block has been authenticated by the third node that exceeds the authentication threshold.

7. A block consensus device, characterized in that, A blockchain system suitable for parallel block generation, the device comprising: The acquisition module is used to acquire the i-th block broadcast sequentially by the second node; the i-th block is a new block generated by the second node in this round, and the i-th block includes the location information of multiple historical blocks and an aggregation pointer of the multiple historical blocks; the multiple historical blocks are multiple (i-1)-th blocks in the local chain of the second node; the aggregation pointer is obtained by the second node based on the location certificates of the multiple historical blocks; the location certificate of any historical block is obtained by a third node other than the block-producing node authenticating and signing the location information of the historical block; The determination module is used to verify the aggregate pointer. After the verification is successful and it is confirmed that the location certificates and consistency certificates of the multiple historical blocks are cached locally, the i-th block is added to the local chain. The consistency certificate of any historical block is obtained by signing the content information of the historical block after authentication by a third node other than the block producing node.

8. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of the method according to any one of claims 1 to 6.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the method described in any one of claims 1 to 6.

Images