CN116743771A

CN116743771A - Block chain consensus method, apparatus, electronic device and computer readable storage medium

Info

Publication number: CN116743771A
Application number: CN202311006689.4A
Authority: CN
Inventors: 黄方蕾; 邱炜伟; 袁超; 尚璇; 谢逸俊
Original assignee: Wuhan Qulian Digital Technology Co ltd; Hangzhou Qulian Technology Co Ltd
Current assignee: Wuhan Qulian Digital Technology Co ltd
Priority date: 2023-08-11
Filing date: 2023-08-11
Publication date: 2023-09-12
Anticipated expiration: 2043-08-11
Also published as: CN116743771B

Abstract

The present application relates to the field of consensus mechanisms, and in particular, to a blockchain consensus method, a blockchain consensus device, an electronic device, and a computer readable storage medium; the method comprises the following steps: receiving transaction data corresponding to the working nodes in the verification node cluster, wherein the transaction data is generated based on a transaction list of the fragments acquired by the working nodes; broadcasting the transaction data to the leader nodes in the other verification node clusters, and adding the transaction data to the vertexes of the directed acyclic graph structure after at least a legal number of signatures of the other leader nodes pass; distributing a transaction list of the fragments to the working node based on the submitting order corresponding to the sequence subgraphs in the directed acyclic graph structure; the transaction list is used to instruct the worker node to verify and execute in the order of submission. The throughput of the blockchain overall architecture is improved, the safety is ensured, the expandability of the blockchain overall architecture is also improved, and the problem that the leader node gathers transaction data is solved.

Description

Block chain consensus method, apparatus, electronic device and computer readable storage medium

Technical Field

The present application relates to the field of consensus mechanisms, and in particular, to a blockchain consensus method, a blockchain consensus device, an electronic device, and a computer readable storage medium.

Background

In existing blockchain systems, all nodes need to maintain a common distributed ledger, and each node in the system needs to execute each transaction in each block to ensure the synchronization of ledger data in order to achieve an agreed result. Since the processing speed of each node is limited, the overall throughput of the system is low, while each node is required to store data of all accounts, which results in low scalability of the system.

Disclosure of Invention

According to various embodiments of the present application, a blockchain consensus method, apparatus, electronic device, and computer readable storage medium are provided to solve the problems of low blockchain throughput and poor scalability.

In a first aspect, the present application provides a blockchain consensus method, applied to a leader node in a verification node cluster, where the verification node cluster further includes a plurality of working nodes, the working nodes are partitioned based on a slice, and the leader node maintains transaction data based on a directed acyclic graph structure; the method comprises the following steps:

Receiving transaction data corresponding to the working nodes in the verification node cluster, wherein the transaction data is generated by the working nodes based on the acquired transaction list of the fragments; broadcasting the transaction data to the leader nodes in the other verification node clusters, and adding the transaction data to the vertexes of the directed acyclic graph structure after at least a legal number of signatures of the other leader nodes pass; distributing a transaction list of the fragments to the working node based on the submitting order corresponding to the sequence subgraphs in the directed acyclic graph structure; the transaction list is used to instruct the worker node to verify and execute in the order of submission.

By the method, the leader node and the working node are divided in the verification node cluster, the working node is divided in a slicing way, and the leader node performs signature consensus; based on different fragments, transaction lists of the corresponding fragments are executed respectively, and based on load balancing of a plurality of nodes, throughput of the whole block chain architecture is improved; the transaction data of the working nodes of the partition architecture are maintained by the structure of the directed acyclic graph in the leader node based on the consensus mechanism of the leader node, so that the expandability of the whole block chain architecture is improved while the security is ensured, and the problem that the leader node gathers the transaction data is solved; has stronger usability and practicability.

In a second aspect, the application provides a blockchain consensus method applied to working nodes in a verification node cluster, wherein the verification node cluster further comprises a leader node, the working nodes are divided based on fragments, and the leader node maintains transaction data based on a directed acyclic graph structure; the method comprises the following steps:

transmitting transaction data to a leading node of the affiliated verification node cluster, wherein the transaction data is generated based on the acquired transaction list of the affiliated fragments; the transaction data is used for being sent to the leader nodes of other verification node clusters by the leader nodes and added to the vertexes of the directed acyclic graph structure after at least legal quantity of leader node signatures pass; receiving a transaction list of the affiliated fragments allocated by the leader node based on the submitting sequence corresponding to the sequence subgraphs in the directed acyclic graph structure; and verifying and executing the transaction list of the fragments according to the submitting sequence.

In a third aspect, the present application provides a blockchain consensus apparatus comprising:

the receiving unit is used for receiving transaction data corresponding to the working node in the affiliated verification node cluster, wherein the transaction data is generated based on a transaction list of affiliated fragments acquired by the working node;

A consensus unit, configured to broadcast the transaction data to a leader node in the other verification node cluster, and add the transaction data to vertices of a directed acyclic graph structure after at least a quorum of signatures of the other leader nodes pass;

the distribution unit is used for distributing the transaction list of the belonging fragments to the working node based on the submitting order corresponding to the sequence subgraphs in the directed acyclic graph structure; the transaction list is used for indicating the working node to verify and execute according to the submitting sequence;

the verification node cluster further comprises a plurality of working nodes, wherein the working nodes are divided based on the fragments, and the leader node maintains transaction data based on a directed acyclic graph structure.

In a fourth aspect, the present application provides a blockchain consensus device comprising:

the transmitting unit is used for transmitting transaction data to a leading node of the affiliated verification node cluster, wherein the transaction data is generated based on the acquired transaction list of the affiliated fragments; the transaction data is used for being sent to other verification node clusters by the leader node and added to the vertexes of the directed acyclic graph structure after at least a quorum of leader node signatures pass;

The receiving unit is used for receiving a transaction list of the fragments allocated by the leader node based on the submitting sequence corresponding to the sequence subgraphs in the directed acyclic graph structure;

the execution unit is used for verifying and executing the transaction list of the affiliated fragments according to the submitting sequence;

In a fifth aspect, the present application provides an electronic device comprising a memory storing a computer program and a processor implementing the method of any one of the first or second aspects when the computer program is executed.

In a sixth aspect, the present application provides a computer readable storage medium having stored thereon a computer program which when executed by a processor implements the method of any one of the first or second aspects.

In a seventh aspect, the application provides a computer program product for causing an electronic device to perform the method of any one of the first or second aspects as described above when the computer program product is run on the electronic device.

It will be appreciated that the advantages of the second to seventh aspects may be found in the relevant description of the first aspect, and are not described here again.

Drawings

In order to more clearly illustrate the embodiments of the application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a block chain system architecture diagram according to an embodiment of the present application;

FIG. 2 is a schematic diagram of a block chain consensus method according to an embodiment of the present application;

FIG. 3 is a schematic diagram of a DAG structure according to an embodiment of the present application;

FIG. 4 is a schematic diagram of a sequence sub-graph submission of a DAG provided by an embodiment of the present application;

FIG. 5 is a schematic diagram of a block chain consensus method according to an embodiment of the present application;

FIG. 6 is a block chain device according to an embodiment of the present application;

FIG. 7 is a block chain device according to an embodiment of the present application;

Fig. 8 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

Embodiments of the technical scheme of the present application will be described in detail below with reference to the accompanying drawings. The following examples are only for more clearly illustrating the technical aspects of the present application, and thus are merely examples, and are not intended to limit the scope of the present application.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having" and any variations thereof in the description of the application and the claims and the description of the drawings above are intended to cover a non-exclusive inclusion.

In the description of embodiments of the present application, the technical terms "first," "second," and the like are used merely to distinguish between different objects and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated, a particular order or a primary or secondary relationship. In the description of the embodiments of the present application, the meaning of "plurality" is two or more unless explicitly defined otherwise.

Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the application. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of skill in the art will explicitly and implicitly appreciate that the embodiments described herein may be combined with other embodiments.

In the description of the embodiments of the present application, the term "and/or" is merely an association relationship describing an association object, and indicates that three relationships may exist, for example, a and/or B may indicate: a exists alone, A and B exist together, and B exists alone. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.

The current research on blockchain scalability mainly includes two directions. The first method is a data slicing concept similar to a distributed database, and the account book data is stored in a plurality of distributed slicing blockchain nodes in a scattered mode. Each validation node assigns a set of transactions into the blockchain nodes of the shard after completing the ordering of the transactions. Each segmented blockchain node verifies the received transaction through a transaction executor and updates the state of a segmented account book of the received transaction, and the verification node verifies all segmented nodes and then generates a block. This approach can solve the problem of slow transaction verification efficiency, but cannot solve the bottleneck problem of throughput of the verification node to collect and determine the transaction order. And only expands in the process of executing the transaction and modifying the ledger, but the limit of the speed of receiving the consensus transaction by the single verification node is still a limiting factor of the overall expandability of the blockchain system.

The second is the slicing concept of the validation node cluster, the validation nodes are uniformly distributed in each slicing account book, and each validation node is only responsible for receiving and validating transactions related to own slicing data. This approach can solve the scalability problem, but since only a small fraction of the verifier makes a validation for each fragment update, security is sacrificed to a large extent and the delay of the final validation of the transaction is increased, resulting in a very difficult interaction between different fragments.

Based on the above problems, the embodiment of the application provides a blockchain consensus method, which can break the account structure of the traditional blockchain and adopts a directed acyclic graph to construct a distributed account of a slicing structure so as to solve the problem of expandability and throughput of a blockchain system.

To facilitate understanding of the principles of implementation of the solutions by those skilled in the art, related technical terms are first described.

1. Directed acyclic graph (Directed Acyclic Graph, DAG): each vertex of the DAG contains a number of transactions, replacing the "blocky" structure in the traditional blocky chain.

2. Quorum (quorum): the number of votes required to reach consensus in the bayer fault-tolerance algorithm.

3. Consensus clusters: and a block chain node set participating in consensus proposal and voting in the finger consensus algorithm.

4. Cluster verifier: each verifier in the consensus cluster is not a separate node, but a verification node cluster consisting of a leader node and a working node.

5. (transaction) throughput: refers to the number of transactions performed per unit time in a blockchain system.

6. (transaction) delay: sending a transaction to the blockchain system and waiting for the time required for the execution of the transaction to be completed.

7. Scalability: more nodes can be added in the blockchain system and throughput can be improved by increasing the number of nodes.

8. Slicing: in the blockchain system, data of different accounts are scattered to different nodes for storage, and transactions for changing the states of the accounts are scattered to the different nodes for verification and execution.

The following describes an application scenario of the blockchain consensus method according to the present application through a specific embodiment.

Referring to fig. 1, fig. 1 is a schematic diagram illustrating an overall architecture of a blockchain system according to an embodiment of the application. As shown in fig. 1, the architecture may include multiple groups of verification node clusters, where each verification node cluster may include a leader node and multiple working nodes, for example, a leader node a and its working node a1, a working node a2, and a working node a3 in the same verification node cluster.

Wherein multiple leader nodes (e.g., blockchain node a through blockchain node D) may synchronize ledger data with each other; the working nodes in the same verifying node cluster are divided according to slices, and the working nodes in different verifying node clusters can belong to the same slice and can synchronize slice ledger data with each other, for example, the working nodes belong to the same slice 1 from a blockchain node a1 to a blockchain node d1, the working nodes belong to the same slice 2 from a blockchain node a2 to a blockchain node d2 and the working nodes belong to the same slice 3 from a blockchain node a3 to a blockchain node d3.

As shown in fig. 1, the leader node in each verification node cluster may communicate with the working nodes in the same cluster to which the leader node belongs, for example, receive information such as transaction data of the corresponding fragment and the status of the execution result sent by each working node; each working node can communicate with the working node of the same slice to which the working node belongs, such as the data of the slice account book after the synchronization is modified; the working nodes belonging to different fragments in the same verification node cluster can also communicate with each other, for example, send cross-fragment transactions, etc., i.e. the working node a1 can communicate with the working node a2 or the working node a 3.

Illustratively, the working nodes belonging to the same segment are responsible for receiving the related transactions of the segment, updating and maintaining the segment account book data based on the verification and execution of the transactions, and the leader node maintains the transaction data reported by the working nodes belonging to the same verification node cluster and the state information of the transactions verified by the working nodes based on the DAG structure.

It should be noted that the blockchain system architecture shown in fig. 1 is only illustrative, and the architecture may further include a plurality of verification node clusters, not just four in fig. 1, and the working nodes belonging to the same slice in different verification node clusters may also correspond to two or more slices at the same time, for example, the working nodes a1 to d1 may correspond to different slices. Different slices can correspond to data of different accounts, and the mode of distributing the account data to the different slices can include modes of average distribution according to hash addresses of the accounts, distribution according to account weights, random factor distribution and the like, and is not particularly limited herein.

The following further describes a specific implementation process of the blockchain consensus method based on the blockchain system architecture.

Referring to fig. 2, a schematic implementation flow chart of a blockchain consensus method according to an embodiment of the present application is provided. The method can be applied to the leader node in the verification node cluster, as shown in fig. 2, and the method can include the following steps:

s201, transaction data corresponding to the working nodes in the affiliated verification node cluster are received, wherein the transaction data are generated by the working nodes based on the acquired transaction list of the affiliated fragments.

In some embodiments, the working nodes in each validation node cluster may obtain a transaction sent by the client, which may be a native transaction, i.e., the transaction is validated and performed by a working node of a certain shard; the transaction may also include a derivative transaction, i.e., a cross-sharded transaction, that is authenticated and executed together by the working nodes of the different shards.

For example, account data corresponding to a client is assigned to different shards, i.e., the working nodes of different shards may receive transactions corresponding to different accounts. After receiving the transaction of the own affiliated fragment, the working node can package the received transaction to obtain a transaction list, i.e. each working node can receive a plurality of transactions.

The transaction data may include a digest of a transaction list corresponding to each of the working nodes, and the working nodes generate the digest of the transaction list (i.e., a hash value calculated for the transaction list) based on the transaction list. The leader node can acquire the abstract of the transaction list corresponding to each working node; the transaction data acquired by the leader node may be a summary of transaction lists corresponding to all working nodes in the verification node cluster to which the leader node belongs, or may be a summary of transaction lists corresponding to part of the working nodes, that is, the leader node may acquire summaries of transaction lists corresponding to the working nodes of the plurality of fragments.

For example, as shown in fig. 1, the working nodes a1, a2 and a3 respectively obtain the transactions of the corresponding fragments (such as the fragment 1 corresponding to the working node a1, the fragment 2 corresponding to the working node a2 and the fragment 3 corresponding to the working node a 3), package the transactions to obtain a transaction list of the corresponding fragments, then generate a summary of the transaction list, and report the summary to the leader node a. Accordingly, the leader node B may also obtain digests of the transaction list of the partition 1 corresponding to the working node B1, the partition 2 corresponding to the working node B2, and the partition 3 corresponding to the working node B3.

In some embodiments, the transaction data includes a summary list; after receiving the transaction data sent by the working node in the affiliated verification node cluster, the method further comprises:

and packaging the abstract of the transaction list based on the received abstract of the transaction list of each working node to obtain an abstract list to be signed.

Illustratively, after receiving the summaries of the transaction lists sent by the working nodes, the leader node encapsulates and packages each summary to obtain a summary list of each working node.

It should be noted that, the data volume corresponding to the abstract of the transaction list is smaller, so that the leader node can package a plurality of abstracts acquired in different time periods together, or can only package a plurality of abstracts acquired in a certain time period together; the number of digests packaged by the leader node is not particularly limited, and can be set according to actual application requirements.

In some embodiments, packaging the summary of the transaction list based on the received summary of the transaction list for each working node includes:

and adjusting the quantity of the abstracts of the packaged transaction list according to the working state of the verification node cluster.

Illustratively, to ensure scalability of the blockchain system as a whole, the number of summary lists encapsulated by the leader node is variable, and the leader node may obtain higher throughput or lower latency by adjusting the number of summary lists at a time.

The working state of the verification node cluster includes the number of transactions to be processed by the working nodes, when the number of transactions to be processed is large, the leader node can adjust the number of digests of the transaction list to be packaged based on the number of digests of the transaction list reported by each working node, for example, when the number of transactions to be processed is large, the number of digests to be packaged is increased, so that higher throughput or lower delay is achieved in the following signing, verification and execution processes.

S202, broadcasting transaction data to leader nodes in other verification node clusters, and adding the transaction data to vertexes of the directed acyclic graph structure after at least a quorum of signatures of other leader nodes pass.

In some embodiments, the leader node in each verifying node cluster of the blockchain system may reliably broadcast the acquired transaction data to the leader nodes in other verifying node clusters, thereby sending to the leader nodes of other cluster verifiers, and after at least a quorum of the leader node signatures confirm and pass, add the transaction data to one vertex of the directed acyclic graph. Through signature consensus of all the leading nodes, the security of the blockchain system is ensured, and meanwhile, the problem of expansibility of transaction collection by the verification node is solved based on the architecture of the directed acyclic graph.

Illustratively, at least a quorum of the leader node's signatures, i.e., the number of votes required to reach consensus in the Bayesian fault tolerance algorithm. For example, a total of 3f+1 leader nodes participate in signature consensus, and when at least 2f+1 leader nodes signature passes, the consensus passes. As shown in fig. 1, when f=1, the leader nodes participating in the consensus may include a leader node a, a leader node B, a leader node C, and a leader node D. When at least three signatures pass, a consensus mechanism is reached, and transaction data can be added to the vertex of the position based on the position of the vertex in the directed acyclic graph structure confirmed by the leader node reaching the consensus.

As shown in the DAG structure diagram of fig. 3, all transactions requiring validation of the working node are associated by the structure of the directed acyclic graph. After the consensus of each round is completed, one or more vertices in the DAG structure may be determined for storing transaction data that participates in the consensus. For example, in fig. 3, the first, second, third, and fourth vertices in the round 1 consensus store transaction data, the first, second, and third vertices in round 2 store transaction data, and the 2 nd vertex store transaction data in round 3.

In the DAG structure, the transaction data of the vertex of the next round will refer to the transaction data of the vertex of the previous round, as shown by the reference relationship indicated by the arrow in fig. 3, the first vertex of the 2 nd round refers to the transaction data of the first vertex of the 1 st round, and the second vertex of the 2 nd round refers to the transaction data of the second vertex and the third vertex of the 1 st round respectively.

It should be noted that, each vertex in the DAG structure shown in fig. 3 may be a storage unit in a leader node, and the leader node stores the transaction commonly known by the signature to the corresponding vertex based on the structure of the directed acyclic graph.

S203, distributing a transaction list of the fragments to the working node based on the submitting order corresponding to the sequence subgraphs in the directed acyclic graph structure; the transaction list is used to instruct the worker node to verify and execute in the order of submission.

In some embodiments, in the directed acyclic graph structure, the leader node periodically (e.g., in a preset consensus round) determines a commit path, and vertices on the path are arranged in a certain order to form a sequence sub-graph, for example, sequence sub-graph 1 and sequence sub-graph 2 in fig. 4, and each vertex in sequence sub-graph 1 is committed first, and then, when the next commit is performed, each vertex in sequence sub-graph 2 is committed correspondingly.

Illustratively, each leader node assigns the transaction list corresponding to each vertex in the sequence sub-graph to the working node of the corresponding segment based on the order of vertices determined by the submitted sequence sub-graph, while informing the working node from which the transaction list originated of the order of verification and execution. For example, as shown in fig. 1, the leader node a allocates the transaction list corresponding to each vertex in the sequence sub-graph to the working node a1, the working node a2, or the working node a3, respectively.

For example, since the leader node actually encapsulates the digests of the transaction list, after signature consensus is performed, the transaction list corresponding to each digest may be determined based on the digest list, and then the transaction list and the execution sequence corresponding to the transaction list may be allocated to each working node based on the belonging fragment. Thus solving the bottleneck problem of throughput of the working node for collecting and determining the transaction sequence.

Illustratively, as shown in fig. 3 and 4, when submitting sequence sub-graph 2, since the second vertex of round 3 referenced by the second vertex of round 4 has already been submitted, the other vertices referenced by the second vertex of round 3 are also submitted, and when round 5 selects the submitted vertex, then the vertices in sequence sub-graph 1 are not submitted.

Illustratively, after the working node verifies and executes the transaction list, the leader node also receives the result state information fed back by each working node, for example, whether the verification is passed or not, executes the result state, and the like, and can synchronize the result state information with other leader nodes.

Accordingly, the leader node distributes the transaction list in the transaction data to each corresponding working node according to the fragments, each working node respectively verifies and executes the transaction list of the corresponding fragment, and throughput is improved based on load balancing of a plurality of working nodes.

In some embodiments, before assigning the transaction list of the belonging shard to the worker node based on the commit order corresponding to the sequence subgraphs in the directed acyclic graph structure, the method further comprises:

counting turns of adding transaction data to vertices of the directed acyclic graph structure; when the turn reaches a preset turn threshold, determining a submitting path of the vertex, wherein the submitting path is used for indicating an execution sequence corresponding to the vertex in the sequence subgraph, and a transaction list is stored in the vertex.

For example, rather than submitting transaction data once at the end of each round of consensus, a round threshold (e.g., 3 times) may be set, and when the round of consensus reaches the round threshold, one vertex in the DAG structure is selected for submission, and the submitted vertex also includes the vertex referenced by the submitted vertex.

As shown in FIG. 3, at the end of round 3 consensus, the second vertex corresponding to round 3 may be taken as the submitted vertex, while also including the transaction data in the vertices of rounds 1 and 2 that it references.

The vertex submitting path is a path based on the reference relationship of each vertex, for example, in fig. 3, the first vertex of the round 2 refers to the transaction data of the first vertex of the round 1, the second vertex of the round 2 refers to the transaction data of the second vertex and the third vertex of the round 1, and the second vertex of the round 3 refers to the first vertex, the second vertex and the third vertex of the round 2.

Accordingly, after determining the submitting path, the transaction data may be stored for each vertex on the submitting path, and the leader node may allocate to the fragmented transaction list to which each working node belongs, and instruct the working nodes to sequentially verify and execute the transaction list therein according to the vertex-corresponding round ordering. For example, first performing the transaction lists of the first, second, third and fourth vertices of round 1, then performing the transaction lists of the first, second and third vertices of round 2, and finally performing the transaction list of the second node of round 3.

It should be noted that, the submitted vertex and the submitted period may be set based on the actual application scenario, and this is only illustrative and not limited thereto. Wherein the submitted vertex may also be determined by the common selection of the leader nodes.

According to the embodiment of the application, the leader node and the working node are divided in the verification node cluster, the working node is divided in a slicing way, and the leader node performs a signature consensus process; based on different fragments, transaction lists of the corresponding fragments are executed respectively, and based on load balancing of a plurality of nodes, throughput of the whole block chain architecture is improved; the transaction data of the working nodes of the partition architecture are maintained by the structure of the directed acyclic graph in the leader node based on the consensus mechanism of the leader node, so that the expandability of the whole block chain architecture is improved while the security is ensured, and the problem that the leader node gathers the transaction data is solved; has stronger usability and practicability.

Referring to fig. 5, a schematic implementation flow chart of a blockchain consensus method according to an embodiment of the present application is provided. The method can be applied to the working nodes in the verification node cluster, and based on the same implementation principle as the embodiment, the description is omitted here. As shown in fig. 5, the method may include the steps of:

S501, transmitting transaction data to a leading node of the affiliated verification node cluster, wherein the transaction data is generated based on the acquired transaction list of the affiliated fragments; the transaction data is for transmission by the leader node to leader nodes of other clusters of verifying nodes and for addition to vertices of the directed acyclic graph structure after at least a quorum of leader node signatures pass.

For example, the working node may receive the transaction of the fragment to which the client sends, and package the acquired plurality of transactions into a transaction list.

In some embodiments, before sending the transaction data to the leader node of the affiliated authentication node cluster, the method further comprises:

the method comprises the steps of obtaining a primary transaction of a belonging fragment, packaging the primary transaction to obtain a transaction list of the primary transaction, wherein the primary transaction is a transaction verified and executed by a working node in the belonging fragment.

Illustratively, to address the problem of cross-shard interactions between different shards, the present application classifies blockchain transactions into two types, native transactions and derived transactions. Wherein, the transaction sent by the client is verified by the working node in the affiliated fragment; if the original transaction confirms that interaction with other fragments is needed in the verification of the executor of the working node of the fragment, generating a derivative transaction pointing to the target fragment; the derived transaction will be validated by the target fragmented worker node in the next sequence sub-graph.

In some embodiments, encapsulating the native transaction includes:

based on the traffic volume, the transaction quantity in the transaction list to be packaged is adjusted, so that the transaction quantity in the transaction list obtained by packaging is adapted to the traffic volume.

Illustratively, to ensure scalability, the number of transactions in each set of transaction lists is variable, and the worker node may package more transactions in each transaction list under high pressure conditions (i.e., with greater traffic or a greater number of transactions that need to be performed) to achieve greater throughput; or fewer transactions may be packaged under low pressure conditions (i.e., less traffic or fewer transactions need to be performed) to achieve lower acknowledgement latency.

S502, receiving a transaction list of the fragments allocated by the leader node based on the submitting sequence corresponding to the sequence subgraphs in the directed acyclic graph structure.

S503, verifying and executing the transaction list of the affiliated fragments according to the submitting sequence.

Illustratively, each working node individually verifies and executes its own fragmented transactions, and then reports the verification and execution results to the leader node.

In addition, if a transaction across fragments is found, a derived transaction is sent by the worker node to the target fragment, which will be preferentially executed in the next verification process of the sequence subgraph.

In some embodiments, after verifying and executing the transaction list, the method further comprises:

if the transaction list comprises the cross-fragment transaction, transmitting a derivative transaction to a working node of the target fragment; the derived transaction is used to instruct the working node of the target shard to execute the derived transaction preferentially in the next process of executing the transaction list based on the sequence sub-graph.

For example, as shown in fig. 4, when the working node performs the transaction of each vertex corresponding to the sequence sub-graph 1, it finds that there is a transaction of cross-fragment, and then the working node directly sends the transaction to the target fragment, namely, the derivative transaction; when the working node of the target fragment receives the transactions of the vertexes corresponding to the sequence sub-graph 2 distributed by the leading node, the derivative transaction is executed before the transactions corresponding to the sequence sub-graph 2 are executed. Thus enabling cross-slice interactions in a more compact and reliable manner.

Each working node may correspond to one or more slices, and store the slice ledger data of the one or more slices.

For example, the partition to which the working node belongs may not be unique and variable, and the working node may be responsible for transaction verification and execution of multiple partitions, for example, a partition with high activity and a partition with low activity, so as to improve the resource utilization rate of the working node.

In some embodiments, the verification node cluster further comprises a subordinate node of the working node; the working nodes correspond to the first-level classification, the subordinate nodes of the working nodes correspond to the second-level classification, and the working nodes can maintain transaction data of the subordinate nodes based on a directed acyclic graph structure; the method further comprises the steps of:

receiving transaction data corresponding to subordinate nodes, wherein the transaction data is generated by the subordinate nodes based on the acquired transaction list of the subordinate secondary components; broadcasting the transaction data to the working nodes of the same level of fragments in other verification node clusters, and adding the transaction data to the vertexes of the directed acyclic graph structure after at least legal number of working node signatures pass; distributing a transaction list of the secondary fragments to the subordinate node based on the submitting sequence corresponding to the sequence subgraphs in the directed acyclic graph structure; the transaction list is used for indicating subordinate nodes to verify and execute according to the submitting sequence.

For example, a second level of classification (even multiple levels) may be added under the working node, and the architecture is similar to that shown in fig. 1, where the working node in the first level of classification is used as the leading node of the subordinate node of the second level of classification, and the return information of the second level of classification is processed. For example, signature consensus is performed on the transaction data reported by the subordinate nodes of the secondary level, and the subordinate nodes of the secondary level are distributed with the transactions of the secondary level, so that the subordinate nodes are indicated to verify and execute, and infinite expansibility can be achieved.

In some embodiments, after receiving the transaction data corresponding to the subordinate node, the method further comprises:

transmitting transaction data to the leader node of the affiliated verification node cluster, wherein the transaction data is used for being transmitted to the leader nodes of other verification node clusters by the leader node of the affiliated verification node cluster and adding the transaction data into the vertexes of the directed acyclic graph structure after at least legal number of leader nodes pass the signature; and receiving a transaction list of the secondary stage allocated by the leading node based on the submitting sequence corresponding to the sequence subgraph in the directed acyclic graph structure, and allocating the transaction list of the secondary stage to the subordinate node, wherein the transaction list of the secondary stage is used for indicating the subordinate node to verify and execute according to the submitting sequence.

For example, the working node of the first stage of the segmentation and the subordinate node of the second stage of the segmentation may share a leading node of the verification node cluster, the subordinate node of the second stage of the segmentation may send the transaction data to the leading node of the same verification node cluster, the leading node of the first stage of the segmentation may initiate signature consensus, and the transaction of the second stage of the segmentation may be directly distributed or forwarded through the working node of the first stage of the segmentation.

For example, on the basis of the architecture shown in fig. 1, if the working node a1 corresponds to the subordinate nodes a11, a12 and a13, the working node b1 corresponds to the subordinate nodes b11, b12 and b13, the working node c1 corresponds to the subordinate nodes c11, c12 and c13, and the working node d1 corresponds to the subordinate nodes d11, d12 and d13; accordingly, the subordinate nodes a11, b11, c11 and d11 may be subordinate nodes of the same piece of mutually synchronizable information, the subordinate nodes a12, b12, c12 and d12 may be subordinate nodes of the same piece of mutually synchronizable information, and the subordinate nodes a13, b13, c13 and d13 may be subordinate nodes of the same piece of mutually synchronizable information; the types of the three different fragments can be secondary fragments corresponding to subordinate nodes; thus realizing infinite expansibility.

According to the embodiment of the application, the problem of expansibility of transaction collection of the verification node is solved while the safety is ensured, and the throughput is improved by balancing the loads of a plurality of working nodes; the leader node can confirm all the fragments, so that the overall delay of transaction processing is reduced; the cross-slice interaction is realized in a more concise and reliable way, and infinite capacity expansion of the block chain can be realized.

It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic, and should not limit the implementation process of the embodiment of the present application.

Corresponding to the blockchain consensus method provided in the above embodiment, fig. 6 shows a schematic structural diagram of the blockchain consensus device provided in the embodiment of the present application, and for convenience of explanation, only the parts related to the embodiment of the present application are shown.

Referring to fig. 6, the blockchain consensus device includes:

a receiving unit 61, configured to receive transaction data corresponding to a working node in a group of verification nodes to which the transaction data belongs, where the transaction data is generated based on a transaction list of a fragment to which the working node belongs, where the transaction list is acquired by the working node;

a consensus unit 62 for broadcasting the transaction data to the leader nodes in the other verification node clusters and adding the transaction data to vertices of the directed acyclic graph structure after at least a quorum of signatures of the other leader nodes pass;

an allocation unit 63, configured to allocate the transaction list of the belonging fragment to the working node based on a commit order corresponding to sequence subgraphs in the directed acyclic graph structure; the transaction list is used for indicating the working node to verify and execute according to the submitting sequence;

In one possible implementation, the apparatus further comprises a commit unit to count turns of adding the transaction data to vertices of the directed acyclic graph structure; and when the turn reaches a preset turn threshold, determining a submitting path of the vertex, wherein the submitting path is used for indicating an execution sequence corresponding to the vertex in the sequence subgraph, and the vertex stores the transaction list.

In one possible implementation, the transaction data includes a summary list; the device also comprises a packaging unit, which is used for packaging the abstract of the transaction list based on the received abstract of the transaction list of each working node to obtain the abstract list to be signed.

In a possible implementation manner, the packaging unit is further configured to adjust the number of digests of the packaged transaction list according to the working state of the verification node cluster.

Corresponding to the blockchain consensus method provided in the above embodiment, fig. 7 shows a schematic structural diagram of the blockchain consensus device provided in the embodiment of the present application, and for convenience of explanation, only the parts related to the embodiment of the present application are shown.

Referring to fig. 7, the blockchain consensus device includes:

A transmitting unit 71, configured to transmit transaction data to a leading node of the affiliated verification node cluster, where the transaction data is generated based on the acquired transaction list of the affiliated fragments; the transaction data is used for being sent to other verification node clusters by the leader node and added to the vertexes of the directed acyclic graph structure after at least a quorum of leader node signatures pass;

a receiving unit 72, configured to receive a transaction list of the belonging fragments allocated by the leader node based on a commit order corresponding to sequence subgraphs in the directed acyclic graph structure;

an execution unit 73, configured to verify and execute the transaction list of the corresponding fragments according to the submitting order;

In a possible implementation manner, the device further includes a packaging unit, configured to obtain a native transaction of the slice, and package the native transaction to obtain the transaction list of the native transaction, where the native transaction is a transaction verified and executed by a working node in the slice.

In a possible implementation manner, the packaging unit is further configured to adjust the number of transactions in the transaction list to be packaged based on the traffic volume, so that the number of transactions in the transaction list obtained by packaging is adapted to the traffic volume.

In a possible implementation manner, the execution unit is further configured to send a derived transaction to a working node of the target fragment if the transaction list includes a cross-fragment transaction; the derived transaction is used for indicating the working node of the target fragment to preferentially execute the derived transaction in the process of executing a transaction list based on the sequence subgraph next time.

In one possible implementation, the working node correspondingly stores the sliced ledger data for one or more slices.

In a possible implementation manner, the verification node cluster further comprises a subordinate node of the working node; the working nodes correspond to the first-stage classification, the subordinate nodes of the working nodes correspond to the second-stage classification, and the working nodes maintain transaction data of the subordinate nodes based on a directed acyclic graph structure; the receiving unit 72 is further configured to receive transaction data corresponding to the subordinate node, where the transaction data is generated by the subordinate node based on the acquired transaction list of the subordinate secondary segment; the device also comprises a consensus unit, a verification unit and a control unit, wherein the consensus unit is used for broadcasting the transaction data to the working nodes of the same first-level fragments in other verification node clusters, and adding the transaction data to the vertexes of the directed acyclic graph structure after at least legal number of working node signatures pass; the device also comprises an allocation unit, a processing unit and a processing unit, wherein the allocation unit is used for allocating the transaction list of the secondary level of the sub-nodes based on the submitting order corresponding to the sequence subgraphs in the directed acyclic graph structure; the transaction list is used for indicating the subordinate node to verify and execute according to the submitting sequence.

In a possible implementation manner, the sending unit 71 is further configured to send the transaction data to the leader node of the verifying node cluster to which the transaction data is to be sent by the leader node of the verifying node cluster to which the transaction data is to be applied to the leader nodes of other verifying node clusters and to add the transaction data to the vertices of the directed acyclic graph structure after at least a quorum of leader nodes have signed a signature; the receiving unit 72 is further configured to receive a transaction list of the second-level fragments allocated to the leader node based on the submitting sequence corresponding to the sequence subgraphs in the directed acyclic graph structure, and allocate the transaction list of the second-level fragments to the subordinate node, where the transaction list of the second-level fragments is used to instruct the subordinate node to verify and execute according to the submitting sequence.

Fig. 8 shows a schematic diagram of the hardware configuration of the electronic device 8.

As shown in fig. 8, the electronic device 8 of this embodiment includes: at least one processor 80 (only one is shown in fig. 8), a memory 81, said memory 81 having stored therein a computer program 82 executable on said processor 80. The steps in the above-described method embodiments are implemented when the processor 80 executes the computer program 82, for example S201 to S203 shown in fig. 2, or S501 to S503 shown in fig. 5. Alternatively, the processor 80, when executing the computer program 82, performs the functions of the modules/units of the apparatus embodiments described above.

It should be understood that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on the electronic device 8. In other embodiments of the application, the electronic device 8 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The electronic device 8 may be a leader node or a working node in the verification node cluster, for example, a computing device such as a desktop computer, a notebook computer, a palm computer, and a cloud server. The electronic device 8 may include, but is not limited to, a processor 80, a memory 81. It will be appreciated by those skilled in the art that fig. 8 is merely an example of the electronic device 8 and is not meant to be limiting as the electronic device 8, and may include more or fewer components than shown, or may combine certain components, or different components, e.g., the server may also include an input transmitting device, a network access device, a bus, etc.

The processor 80 may be a central processing unit (Central Processing Unit, CPU), but may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

A memory may also be provided in the processor 80 for storing instructions and data. In some embodiments, the memory in the processor 80 is a cache memory. The memory may hold instructions or data that the processor 80 has just used or recycled. If the processor 80 needs to reuse the instruction or data, it may be called directly from the memory. Repeated accesses are avoided and the latency of the processor 80 is reduced, thereby improving the efficiency of the system.

The above-mentioned memory 81 may in some embodiments be an internal storage unit of the electronic device 8, such as a hard disk or a memory of the electronic device 8. The memory 81 may also be an external storage device of the electronic device 8, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card) or the like, which are provided on the electronic device 8. Further, the memory 81 may also include both an internal storage unit and an external storage device of the electronic device 8. The memory 81 is used for storing an operating system, application programs, boot loader (BootLoader), data, other programs, etc., such as program codes of computer programs, etc. The memory 81 may also be used to temporarily store data that has been transmitted or is to be transmitted.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

It should be noted that the structure of the electronic device is only illustrated by way of example, and other entity structures may be included based on different application scenarios, and the entity structure of the electronic device is not limited herein.

In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.

Embodiments of the present application also provide a computer readable storage medium storing a computer program which, when executed by a processor, implements steps for implementing the various method embodiments described above.

Embodiments of the present application provide a computer program product which, when run on a server, causes the server to perform steps that enable the implementation of the method embodiments described above.

The integrated modules/units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application may implement all or part of the flow of the method of the above embodiment, or may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the steps of each method embodiment described above may be implemented. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, executable files or in some intermediate form, etc. The computer readable medium may include: any entity or device capable of carrying computer program code, a recording medium, a U disk, a removable hard disk, a magnetic disk, an optical disk, a computer Memory, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), an electrical carrier signal, a telecommunications signal, a software distribution medium, and so forth.

The algorithm development platform, the electronic device, the computer storage medium and the computer program product provided by the embodiments of the present application are all used for executing the method provided above, so that the beneficial effects achieved by the algorithm development platform, the electronic device, the computer storage medium and the computer program product can refer to the beneficial effects corresponding to the method provided above, and are not described herein again.

It should be understood that the above description is only intended to assist those skilled in the art in better understanding the embodiments of the present application, and is not intended to limit the scope of the embodiments of the present application. It will be apparent to those skilled in the art from the foregoing examples that various equivalent modifications or variations can be made, for example, certain steps may not be necessary in the various embodiments of the detection methods described above, or certain steps may be newly added, etc. Or a combination of any two or more of the above. Such modifications, variations, or combinations are also within the scope of embodiments of the present application.

The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.

It should also be understood that the manner, the case, the category, and the division of the embodiments in the embodiments of the present application are merely for convenience of description, should not be construed as a particular limitation, and the features in the various manners, the categories, the cases, and the embodiments may be combined without contradiction.

It is also to be understood that in the various embodiments of the application, where no special description or logic conflict exists, the terms and/or descriptions between the various embodiments are consistent and may reference each other, and features of the various embodiments may be combined to form new embodiments in accordance with their inherent logic relationships.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus/network device and method may be implemented in other manners. For example, the apparatus/network device embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions in actual implementation, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

The above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.

Finally, it should be noted that: the foregoing is merely illustrative of specific embodiments of the present application, and the scope of the present application is not limited thereto, but any changes or substitutions within the technical scope of the present application should be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. The block chain consensus method is characterized by being applied to a leader node in a verification node cluster, wherein the verification node cluster further comprises a plurality of working nodes, the working nodes are divided based on fragments, and the leader node maintains transaction data based on a directed acyclic graph structure; the method comprises the following steps:

receiving transaction data corresponding to the working node in the verification node cluster, wherein the transaction data is generated by the working node based on the acquired transaction list of the fragment;

broadcasting the transaction data to leader nodes in other verification node clusters, and adding the transaction data to the vertexes of the directed acyclic graph structure after at least a quorum of signatures of other leader nodes pass;

distributing the transaction list of the fragments to the working node based on the submitting order corresponding to the sequence subgraphs in the directed acyclic graph structure; the transaction list is used for indicating the working node to verify and execute according to the submitting sequence.

2. The method of claim 1, wherein prior to the assigning the transaction list of the belonging shard to the worker node based on a commit order corresponding to sequence subgraphs in the directed acyclic graph structure, the method further comprises:

Counting turns of adding the transaction data to vertices of the directed acyclic graph structure;

and when the turn reaches a preset turn threshold, determining a submitting path of the vertex, wherein the submitting path is used for indicating an execution sequence corresponding to the vertex in the sequence subgraph, and the vertex stores the transaction list.

3. The method of claim 1, wherein the transaction data comprises a summary list; after said receiving transaction data sent by said working node in said cluster of authentication nodes to which it belongs, said method further comprises:

based on the received abstracts of the transaction lists of the working nodes, packaging the abstracts of the transaction lists to obtain the abstracts list to be signed;

the method for packaging the abstract of the transaction list based on the received abstract of the transaction list of each working node comprises the following steps:

4. The block chain consensus method is characterized by being applied to working nodes in a verification node cluster, wherein the verification node cluster further comprises a leader node, the working nodes are divided based on fragments, and the leader node maintains transaction data based on a directed acyclic graph structure; the method comprises the following steps:

Transmitting transaction data to the leading node of the verification node cluster, wherein the transaction data is generated based on the acquired transaction list of the fragment; the transaction data is used for being sent to the leader nodes of other verification node clusters by the leader nodes and added to the vertexes of the directed acyclic graph structure after at least legal number of leader node signatures pass;

receiving a transaction list of the fragments allocated by the leader node based on the submitting sequence corresponding to the sequence subgraphs in the directed acyclic graph structure;

and verifying and executing the transaction list of the fragments according to the submitting sequence.

5. The method of claim 4, wherein prior to said sending transaction data to the lead node of the verifying node cluster to which it belongs, the method further comprises:

acquiring a primary transaction of the belonging fragment, and packaging the primary transaction to obtain the transaction list of the primary transaction, wherein the primary transaction is a transaction verified and executed by a working node in the belonging fragment;

said encapsulating said native transaction comprises:

and adjusting the transaction quantity in the transaction list to be packaged based on the traffic volume, so that the transaction quantity in the transaction list obtained by packaging is adapted to the traffic volume.

6. The method of claim 4, wherein after the verifying and executing the transaction list, the method further comprises:

if the transaction list comprises cross-fragment transactions, transmitting derived transactions to a target fragment work node; the derived transaction is used for indicating the working node of the target fragment to preferentially execute the derived transaction in the process of executing a transaction list based on the sequence subgraph next time.

7. The method according to any of claims 4 to 6, wherein the validation node cluster further comprises a subordinate node of the working node; the working nodes correspond to the first-stage classification, the subordinate nodes of the working nodes correspond to the second-stage classification, and the working nodes maintain transaction data of the subordinate nodes based on a directed acyclic graph structure; the method further comprises the steps of:

receiving transaction data corresponding to the subordinate node, wherein the transaction data is generated by the subordinate node based on the acquired transaction list of the subordinate secondary level;

broadcasting the transaction data to the working nodes of the same first-level fragments in other verification node clusters, and adding the transaction data to the vertexes of the directed acyclic graph structure after at least legal number of working node signatures pass;

Distributing the transaction list of the secondary class to the subordinate node based on the submitting order corresponding to the sequence subgraphs in the directed acyclic graph structure; the transaction list is used for indicating the subordinate node to verify and execute according to the submitting sequence.

8. The method of claim 7, wherein after said receiving transaction data corresponding to said subordinate node, the method further comprises:

transmitting the transaction data to the leader node of the verification node cluster to which the transaction data belongs, wherein the transaction data is used for being transmitted to the leader nodes of other verification node clusters by the leader node of the verification node cluster to which the transaction data belongs and adding the transaction data to the vertexes of the directed acyclic graph structure after at least a legal number of leader node signatures pass;

and receiving a transaction list of the secondary stage allocated to the leader node based on the submitting sequence corresponding to the sequence subgraphs in the directed acyclic graph structure, and allocating the transaction list of the secondary stage to the subordinate node, wherein the transaction list of the secondary stage is used for indicating the subordinate node to verify and execute according to the submitting sequence.

9. A blockchain consensus device, comprising:

10. A blockchain consensus device, comprising:

11. An electronic device comprising a memory storing a computer program and a processor implementing the method of any one of claims 1 to 8 when the computer program is executed by the processor.

12. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the method of any one of claims 1 to 8.