A hybrid consensus implementation device and implementation method for graph-based blockchain

Abstract

The present invention relates to a hybrid consensus implementation method for a graph blockchain, which at least includes: calling at least one module to generate a new data block and broadcast the new block; calling at least one module to check and verify the received new block based on preset rules; calling at least one module to generate an empty block; calling at least one module to update the committee member list. Existing graph blockchains can only reach a probabilistic consensus, while the hybrid consensus algorithm proposed in the present invention reaches a deterministic consensus on the graph blockchain for the first time, thereby speeding up the speed at which the graph blockchain reaches a consensus. The present invention decouples the generation of blocks and consensus for the first time, and modular designs can be performed for the two parts respectively. The present invention proposes a fully decentralized hybrid consensus algorithm on the graph blockchain for the first time, while many existing graph blockchains such as IOT A, Obyte, etc. cannot do this.

Description

Technical Field

[0001] The present invention relates to the field of computer application technology, and in particular to a hybrid consensus implementation device and implementation method for a graph-based blockchain. Background Art

[0002] In a narrow sense, blockchain is a special distributed database, which is composed of blocks formed by multiple data organizations, a chain data structure combined in a sequential manner, and cryptography is used to ensure that it has the characteristics of being tamper-proof and unforgeable. In a broad sense, blockchain technology is a new distributed infrastructure and computing paradigm that uses distributed consensus algorithms and cryptography to realize trusted distributed ledgers.

[0003] In any blockchain system, a group of distributed participants need to reach a consensus on certain values, so the blockchain consensus algorithm is the core of all blockchain systems. The working principle of the blockchain is as follows: every once in a while, the system elects a leader from all blockchain participants through some method. The leader collects the data to be stored in the blockchain from the client, organizes the single or multiple data into a certain data structure, that is, a block, and then the leader broadcasts the block information to other participants, and each participant can independently decide to accept or reject it. All blocks are connected in sequence to form a blockchain, and cryptographic means are used to ensure that the blockchain has the characteristics of being tamper-proof and unforgeable.

[0004] There are two main types of blockchain consensus algorithms at present. One is the competitive type. In each round of master node selection, the competitive consensus algorithm will set a standard for successful competition as a certain resource, and the consensus node that first reaches the standard will become the master node. All blockchain participants will compete with each other based on a certain resource. The resources controlled by the participants are proportional to the probability of winning the competition. Every once in a while, a participant will win and gain the power to propose a block. For example, in the PoW consensus algorithm, all nodes participating in the consensus compete to become the master node by consuming computing power to solve mathematical problems, and the node that solves the mathematical problem first becomes the master node. The other is the election type, in which all nodes vote to select. According to the voting results, some consensus algorithms generate a set of master nodes, and these nodes take turns to become the master node in turn. Some consensus algorithms only generate one master node to create blocks, and vote again in the next round. Through voting, all blockchain participants can reach a consensus on the new block. The consensus process of the election type includes: the first step is to select a set of trusted nodes, and the trusted nodes take turns to serve as the master node; the second step is block verification. The block verification methods are divided into two categories. One is similar to the competitive algorithm. The master node broadcasts the block to the other nodes for verification. The other is that the master node's block is verified through three rounds of BFT (Byzantine Fault-Tolerant) voting process; the third step is that the node submits the verified block to reach a consensus state. Election consensus algorithms include, for example, DPoS (Delegate Proof of Stake), PBFT (Practical Byzantine Fault Tolerance), DBFT (DelegatedByzantine Fault Tolerance), etc. The advantage of the first algorithm is that it can be applied to unlicensed and large-scale scenarios, but the disadvantage is that the consensus efficiency is low; the advantage of the second algorithm is that the consensus efficiency is high, but the disadvantage is that it cannot be applied to unlicensed and large-scale scenarios.

[0005] In recent years, blockchain has been widely used in smart contracts, financial transactions, e-commerce, the Internet of Things, international trade and other fields. However, at the same time, blockchain has also exposed the defects of poor performance, which is specifically manifested in two aspects: weak processing power and slow processing speed. One of the main reasons for the poor performance of blockchain is the low efficiency of the current blockchain consensus algorithm. Therefore, designing a high-performance blockchain consensus algorithm is of great significance to improving the performance of blockchain systems. In recent years, in order to improve the performance of blockchain, academia and industry have proposed a new architecture called graph blockchain. Its main feature is that each block in the blockchain can have multiple parent blocks, while each block in the traditional blockchain can only have one parent block. That is, in the traditional blockchain, participants only reach a consensus on one chain, while in the graph blockchain, participants reach a consensus on the entire directed acyclic graph (DAG).

[0006] For example, in the prior art, the patent document with publication number CN112202775B proposes a consensus mechanism for block directed acyclic graphs, targeting the problem that the underlying structure of block DAG is a network structure and faces more difficulties in achieving consensus than a chain structure. The consensus problem in block DAG is converted into a consensus problem in blockchain, and the consensus mechanism in a mature blockchain is used to solve the consensus problem in block DAG.The consensus mechanism architecture method proposed by it includes: first, generating ordinary blocks in the block DAG, that is, blocks before merging; when a new transaction is generated in the system, the transaction will be collected in its transaction pool by the node closest to it. When a node collects enough transactions or reaches a certain time interval, the node packs all transactions in its transaction pool to generate a new block; for a block DAG, it does not contain any blocks in the initial state. The system first generates a root genesis block as the first block in the system, and then generates m At the same time, the genesis block is used as the current leaf block of the system. After that, every time a node in the system generates a new block, it will reference the n leaf blocks of the node that generates the block. Then, the unconfirmed blocks in the unconfirmed block pool are sorted, which is executed by the master node in the consensus protocol of the merged blockchain. It includes two parts: block stratification and sorting. The physical blocks generated by the nodes are classified according to the parent blocks of the physical blocks. The physical blocks of the same type are merged into logical blocks, and all logical blocks generated within the same block time are blocks of the same layer. The logical block is the block DAG after stratification. After the block stratification, a layered block DAG structure is formed; the blocks in the block pool are sorted according to the layered structure of the block DAG, and the transactions in them are verified. The logical blocks with smaller layers are sorted first, and the blocks with larger layers are sorted later; for the logical blocks of the same layer, they are sorted according to the order of their parent blocks in the previous layer; when sorting transactions, transactions are first sorted according to the order of the blocks they are in, and the transactions with earlier blocks are sorted earlier; for transactions in the same block, they are sorted according to the time they are recorded by the node; at this time, the system obtains the global sequence of transactions, Detect transaction conflicts. If two transactions conflict, the transaction in the previous order is retained, and the transaction in the next order is marked as an invalid transaction, thereby eliminating double-spending attacks. After that, according to the sorting results, the blocks in the block sequence are merged into one or more merged blocks in order according to their position in the block sequence. At this time, the block pool stores ordered blocks. All blocks are merged into one or more merged blocks according to certain rules. After obtaining the logical block, the node responsible for sorting copies the merged block to other nodes according to the consensus protocol in order to merge the blockchain consensus. After that, consensus is reached on the merged blockchain, and the consensus process of the merged block DAG is completed with the help of the consensus mechanism of the blockchain; after the merged block is obtained through the block merging part, the master node copies the merged block to other slave nodes using the algorithm; after other slave nodes in the system receive the merged block, they add it to the local merged blockchain of the node, thereby completing the consensus on the merged blockchain; finally, after obtaining the merged block, the nodes independently use the block splitting algorithm to split the merged block to obtain the original physical block, and add the physical block to the local block DAG of the node according to the parent block field in each block.

[0007] In addition, on the one hand, there are differences in understanding among those skilled in the art; on the other hand, the applicant studied a large number of documents and patents when making the present invention, but due to space limitations, not all details and contents are listed in detail. However, this does not mean that the present invention does not have the characteristics of these prior arts. On the contrary, the present invention already has all the characteristics of the prior art, and the applicant reserves the right to add relevant prior art to the background technology. Summary of the invention

[0008] Although the graph blockchain has been developed and applied a lot recently, its consensus method still has many shortcomings in terms of efficiency, security, speed of reaching consensus, etc. To this end, the present invention proposes a hybrid consensus method for the graph blockchain, which can not only provide fast confirmation for the graph blockchain, but also provide a full order for all transactions. The hybrid consensus method is similar to indirect democracy in the real world. The basic idea is to first select a few participants from all blockchain participants to form a committee, and then the committee reaches a consensus on the content in the blockchain. However, the existing hybrid consensus methods are all designed for chain blockchains and cannot be used for graph blockchains. In addition, the consensus efficiency of the committee is likely to become a performance bottleneck for the entire system. To this end, the present invention designs a hybrid consensus method for the graph blockchain, and proposes a solution for how to safely and fairly elect a committee in the graph blockchain and how to reach a consensus on the graph blockchain within the committee. In addition, based on the hybrid consensus method designed and proposed by the present invention, the committee only needs to reach a consensus on a few blocks to use the topological relationship of the graph blockchain to reach an indirect consensus on all blocks. Under this setting, the burden of the committee consensus is greatly reduced, and the system performance bottleneck problem is solved.

[0009] To achieve the above objectives, the present application proposes a hybrid consensus implementation method for a graph-based blockchain, which at least includes: calling at least one module to generate a new data block and broadcast the new block; calling at least one module to check and verify the received new block based on preset rules; calling at least one module to generate an empty block; calling at least one module to update the committee member list. Each module is called by a blockchain participant or a central processor.

[0010] According to a preferred embodiment, a new data block is generated by: storing the data to be written into the blockchain into a constructed data structure; and generating a legal data block through competition.

[0011] According to a preferred embodiment, the preset rules for checking and verifying the new block include at least: the blockchain participant who receives the new block determines whether the new block has been received before; if the judgment result is no, the legitimacy of the new block is checked.

[0012] According to a preferred embodiment, the preset rules for checking and verifying the new block also include: checking whether the proof field of the new block is legal; and checking whether the data stored in the body part of the new block is legal.

[0013] According to a preferred embodiment, the preset rules for checking and verifying the new block also include: checking the data structure of the received new block; if the new block is an empty block, calling at least one module to sort all blocks in the illustrated blockchain.

[0014] According to a preferred embodiment, whether committee member update is required is determined based on the local blockchain copy.

[0015] According to a preferred embodiment, the hybrid consensus implementation method further includes: blockchain participants regularly check whether they are committee members; if the check result is yes, new empty blocks are regularly generated through voting.

[0016] According to a preferred embodiment, when constructing a new data block, the field proving that the participant who created the data block won the resource competition is empty by default.

[0017] According to a preferred embodiment, when constructing a new empty block, the proof field proving that the empty block has been recognized by enough participants is empty by default.

[0018] The present application also proposes a hybrid consensus implementation device for a graphical blockchain, which at least includes: a committee generation module, which is configured to select some blockchain participants to form a committee; an empty block generation module, which is configured to allow committee members to periodically generate new empty blocks through voting; and a block verification module, which is configured to check and verify the received new block according to preset rules when a new block is received.

[0019] The present application also proposes a hybrid consensus implementation system for a graph blockchain, which at least includes: a data structure construction module, which is configured to construct the data structure required to implement the hybrid consensus; a data block generation module, which is configured to select a winner through competition to generate a new data block; a committee generation module, which is configured to select some blockchain participants to form a committee; an empty block generation module, which is configured to allow committee members to regularly generate new empty blocks through voting; a block verification module, which is configured to check and verify the received new block according to preset rules when a new block is received; a local sorting module, which is configured to allow each blockchain participant to sort all blocks of the graph blockchain locally according to predetermined rules.

[0020] The operation process of the system at least includes: first, the data structure construction module packages the received user transactions into a template block and sends it to the data block generation module. Then the data block generation module generates a complete data block and broadcasts it according to the corresponding rules (such as proof of work). After any blockchain participant receives a new block from the network, it calls the block verification module to verify its legitimacy. If the verification passes, the new block is added to the locally stored graph blockchain. Each blockchain participant regularly calls the committee generation module to determine the current list of committee members. Participants belonging to the committee run the empty block generation module, which allows committee members to generate and broadcast new empty blocks through regular voting. Each empty block references multiple blocks in the graph blockchain. After receiving the empty block, each blockchain participant calls the block verification module to verify its legitimacy. If the verification passes, all blocks directly or indirectly referenced by the empty block are set as confirmed blocks.

[0021] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects:

[0022] (1) The existing graph blockchain can only reach a probabilistic consensus, while the hybrid consensus algorithm proposed in the present invention reaches a deterministic consensus on the graph blockchain for the first time, thereby speeding up the speed at which the graph blockchain reaches a consensus.

[0023] (2) This invention decouples block generation and consensus for the first time, and modular designs can be performed for the two parts separately.

[0024] (3) The consensus algorithm proposed in the present invention can establish a total order relationship between blocks, and thus can support applications such as smart contracts, while the consensus algorithms of many existing graph blockchains (such as IOTA) cannot do this.

[0025] (4) A fully decentralized hybrid consensus algorithm is proposed for the first time on the graph blockchain, while many existing graph blockchains (such as IOTA, Obyte, etc.) cannot do this. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 It is a simplified schematic diagram of the main framework of the hybrid consensus implementation device provided by the present invention;

[0027] Figure 2 It is a simplified schematic diagram of the main data structure of the hybrid consensus implementation device provided by the present invention;

[0028] Figure 3 It is a simplified flow chart of the committee random election algorithm provided by the present invention;

[0029] Figure 4 It is a simplified flowchart of the local sorting algorithm provided by the present invention. DETAILED DESCRIPTION

[0030] In order to further explain the purpose, technical solution and advantages of the present invention more clearly, the present invention is further described in detail below in conjunction with the accompanying drawings and the invention content. It should be understood that the specific implementation methods described herein are only used to explain the present invention and are not used to limit the present invention.

[0031] For ease of understanding, technical terms of the present invention are explained as follows.

[0032] A blockchain participant refers to a computer that joins the blockchain network, stores a copy of the blockchain locally, and runs the blockchain consensus protocol.

[0033] Block creator refers to the blockchain participant who creates a block. Each blockchain participant will locally generate a pair of key pairs required for an asymmetric encryption algorithm, where the public key is made public as the participant's identity, and the private key is kept secret by the participant. Each participant uses the private key to sign the block when creating a new block, and other participants use the public key to confirm the identity of the block creator.

[0034] References are divided into direct references and indirect references. If block 2 is the parent block of block 1, then block 1 is said to directly reference block 2. If block 3 is the parent block of block 2, then block 1 is said to indirectly reference block 3 through block 2, and indirect references will be passed according to this rule.

[0035] Probabilistic consensus means that after reaching a consensus, there is still a certain probability that the consensus will be overturned, but this probability decreases exponentially as time goes by.

[0036] Deterministic consensus means that once a consensus is reached, it can never be overturned. This is usually achieved through BFT (Byzantine Fault Tolerance algorithm).

[0037] Partial order, in blockchain, means that there may not be a clear order between two different transactions.

[0038] Total order, in blockchain, means that there must be a clear order between any two different transactions. For applications where the execution order does not affect the results, such as digital payments, total order is not necessary, but for applications where the execution order does affect the results, such as auctions and smart contracts, total order is necessary.

[0039] The consensus mechanism is to complete the verification and confirmation of transactions in a very short time through the voting of special nodes. For a transaction, if several nodes with irrelevant interests can reach a consensus, it can be considered that the whole network can also reach a consensus on it. Blockchain, as a data structure that stores data in chronological order, can support different consensus mechanisms. The consensus mechanism is an important component of blockchain technology. The goal of the blockchain consensus mechanism is to enable all honest nodes to save a consistent blockchain view while satisfying two properties: consistency, the prefix part of the blockchain saved by all honest nodes is exactly the same; validity. The information published by an honest node will eventually be recorded in its own blockchain by all other honest nodes. Common consensus mechanisms include: POW (Proof of Work), POS (Proof of Staked), POW+POS (hybrid consensus mechanism), DPOS (Dele gated Proof of Stake), etc. In addition, there are Pool verification pools, Ripp le consensus protocol, PBFT (using Byzantine fault tolerance algorithm), etc.

[0040] The scalability of the consensus mechanism refers to the changes in system load and network communication volume brought about by the increase in the number of system members and transactions to be confirmed, which is usually measured by network throughput.

[0041] POW (Proof of Work) works in the following way: In order to make the blockchain transaction data recorded on the blockchain and reach a consensus within a certain period of time, POW provides a way of thinking, that is, all the network node participants of the blockchain compete for bookkeeping. The so-called competitive bookkeeping means that if you want to generate a new block and write it into the blockchain, you must solve the proof of work puzzle of the digital currency network. Whoever solves the answer first will get the right to bookkeeping, and then start bookkeeping and broadcast the solved answer and transaction records to other nodes for verification, and then start the next round of problem solving. If the transaction of the block is verified to be valid by other node participants and the answer to the puzzle is correct, it means that the answer is credible, and the new node will be written into the node blockchain of the verifier, and the verifier will enter the next round of competitive problem solving. Satoshi Nakamoto used a secure hashing algorithm to design the mathematical problem as a double SHA256 hash operation on the block header information. The POW consensus algorithm includes: in the first step, all nodes in the entire network receive and forward transaction information, package the received transaction information into a new block, and then all nodes in the entire network set the Nonce field in the block header based on the new block packaged by this node, and calculate the hash value of the entire block header information to meet the target value requirements; the node that completes the calculation work first becomes the master node and broadcasts its own block to the remaining nodes; in the second step, the remaining nodes that have not successfully competed give up calculating the local new block after receiving the new block, and verify the received new block; in the third step, after the node verifies the new block, it adds it to the local blockchain, and all nodes reach a consensus on the latest height block.

[0042] POS (Proof of Staked) is an improved consensus mechanism designed to address the shortcomings of POW. PoS continues the competitive concept of the PoW algorithm, but compared to the large search space of the Nonce field in PoW, PoS limits the search space to an acceptable range of computational complexity. Unlike the proof of work mechanism, which requires nodes to continuously perform hash calculations to verify the validity of transactions, the principle of the proof of equity mechanism is to require users to prove that they own a certain amount of digital currency, that is, "equity". The biggest difference between the PoS mechanism and the PoW mechanism is that only people who hold digital currency can solve the problem, and it does not require a lot of computing power to mine currency, avoiding the trend of "computing power concentration" in the digital currency network and returning to the essential requirement of blockchain "decentralization".

[0043] PBFT (Practical Byzantine Fault Tolerance) is the basis of the consensus algorithm of Alliance Coin. PBFT implements the Byzantine problem with a limited number of nodes, has a 3f+1 fault tolerance, and guarantees a certain performance at the same time. PBFT reduces the operating complexity of the Byzantine protocol from the exponential level to the polynomial level, making it possible to apply the Byzantine protocol in distributed systems.

[0044] A replica is a copy of the same data distributed on different computers. The replica in this article refers to the blockchain stored locally by the blockchain participants. Due to network transmission delays and other reasons, there may be differences between the local copies of different blockchain participants.

[0045] IOTA (Internet of Things Application) is a public distributed ledger based on the Internet of Things (IOT), which is based on Tangle rather than blockchain. Tangle is a new data structure based on a directed acyclic graph (DAG) created specifically for the IOTA protocol, rather than a continuous chain architecture. Through DAG, IOTA is able to achieve a high transaction throughput (through parallel verification) and does not charge transaction fees. In Tangle, each node represents a transaction. The responsibility for verifying transactions in the entire network is transferred from traditional miners to each user of the network - if a blockchain participant wants to initiate a transaction, he must help verify other transactions in the network.

[0046] Transaction: A transaction can be considered as a piece of request data sent to the blockchain system, which is used to deploy contracts, call contract interfaces, maintain the life cycle of contracts, manage assets, and exchange value. The basic data structure of a transaction includes sender, receiver, transaction data, etc. Users can construct a transaction, sign the transaction with their own private key, and send it to the chain (through interfaces such as sendRawTransaction). The consensus mechanism of multiple nodes processes it, executes the relevant smart contract code, generates the state data specified by the transaction, and then packages the transaction into a block and stores it on disk together with the state data. The transaction is confirmed, and the confirmed transaction is considered to be transactional and consistent.

[0047] The present invention proposes a hybrid consensus implementation device for a graph blockchain, which includes at least one of a data structure construction module, a data block generation module, a committee generation module, an empty block generation module, a block verification module, and a local sorting module. The hybrid consensus implementation device of the present invention is preferably, for example, a computer, a server, etc., and other devices or systems using a hybrid consensus implementation device. According to an embodiment of the present invention, in addition to the data structure construction module, the data block generation module, the committee generation module, the empty block generation module, the block verification module, and the local sorting module, the hybrid consensus implementation device may also include other components such as a central processing unit, a communication unit, a storage unit, and an I / O unit. Preferably, the blockchain participant mentioned in this application may refer to the central processing unit in the hybrid consensus implementation device. For example, a blockchain participant regularly checks whether he is a member of the committee to determine whether he needs to participate in the committee consensus, which can also be described as the central processing unit regularly checking whether the corresponding blockchain participant or the node or itself is a member of the committee to determine whether it needs to participate in the committee consensus. For example, the data structure construction module, the data block generation module, the committee generation module, the empty block generation module, the block verification module and the local sorting module can be connected to the central processing unit respectively, and all interact with the central processing unit for information.

[0048] As an example, various exemplary logic blocks, modules and circuits described in conjunction with the present disclosure may be implemented or executed with a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components or any combination thereof for performing the functions described herein. A general-purpose processor may be a microprocessor, or a processor may be any common processor, controller, microcontroller or state machine. A processor may also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, a combination of one or more microprocessors and a DSP core, or any other such structure. As an example, embodiments of the present disclosure may be described in the context of machine executable instructions, such as program modules executed in a device on a real or virtual processor of a target. In general, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., which perform specific tasks or implement specific abstract data structures. In various embodiments, the functions of program modules may be merged or split between the described program modules. Machine executable instructions for program modules may be executed in local or distributed devices. In a distributed device, program modules may be located in both local and remote storage media.

[0049] The data structure construction module is used to construct at least one data structure required to achieve hybrid consensus. The data structure constructed by the data structure construction module includes at least a data block and an empty block. As shown in Figure 2, the data block is divided into two parts: body and head. The body part is used to store transactions (data). The head part contains metadata for constructing a graphical blockchain. The head part is used to construct a graphical blockchain.

[0050] Preferably, the body part can be configured to store only one transaction. In this setting, all data blocks are created by the client itself, similar to IOTA. Preferably, the body part can be configured to store a list of transactions. In this setting, miners package transactions instead of clients, similar to traditional blockchains.

[0051] The important fields contained in the head part of the data block include at least one or more of the timestamp field (timestamp), the number of data items contained in the body part (num), the unique identifier list field of all parent blocks (parents), and the field (proof) proving that the participant who created the data block won the resource competition. When the data structure construction module constructs a new data block, the field proving that the participant who created the data block won the resource competition is empty by default. The role of the data block is to store upper-layer application data in the main field (body). For example, in a digital payment system, this field is used to store transaction records.

[0052] like Figure 2 As shown in the figure, an empty block does not store data and only contains the head part. The important fields contained in the head part of the empty block include at least one or more of the timestamp field (timestamp), the unique identification list field of all parent blocks (parents), and the proof field (sign) that proves that the empty block has been recognized by enough participants. When the data structure construction module constructs a new empty block, the proof field that proves that the empty block has been recognized by enough participants is empty by default. The empty block is generated by a deterministic consensus algorithm, so all data blocks directly or indirectly referenced by the empty block are also irreversibly confirmed, and the upper-layer applications can safely use the data in these data blocks.

[0053] The data block generation module is configured to fairly and randomly select winners to generate new data blocks based on competition for certain resources. The data block generation module can use proof of work to obtain new data blocks. Specifically, all blockchain participants are required to continuously change the proof field in the data block until the summary value of the data block meets certain requirements, and the data block is legal at this time. Any other blockchain participant will first verify the legitimacy of the proof field when receiving this data block. The data block generation module can also use proof of equity to obtain new data blocks.

[0054] The committee generation module is configured to fairly and randomly select at least one blockchain participant to form a committee. When the committee generation module is called, the committee generation module selects n blockchain participants to form a committee. The committee generation module needs to randomly select a small number of blockchain participants to form a committee. Figure 3 The simplified flow diagram of the committee random selection algorithm shown is that, specifically, after each blockchain participant calls the local sorting module to sort all the data blocks of the schematic blockchain, it locks the latest n blocks according to the order of the data blocks and selects the creators of these n data blocks as members of the committee. Preferably, when the creators of m (m>1) blocks are the same blockchain participant, it can be determined in subsequent processing that this blockchain participant controls m votes in the voting.

[0055] The empty block generation module is configured to allow committee members to periodically vote to generate new empty blocks to confirm and sort data blocks. The specific voting process can be implemented using Byzantine fault-tolerant protocols such as PBFT. Any legal empty block needs to be approved by more than two-thirds of the committee members. Since most Byzantine fault-tolerant protocols require a leader, the leader of the Byzantine fault-tolerant protocol can be rotated according to the order of data blocks.

[0056] The block verification module is configured to verify whether a new block is legal according to a predetermined rule when receiving the new block. The predetermined rule for the block verification module to verify whether a block is legal may include: verifying whether all ancestor blocks of the block are known; verifying the validity of the block; and checking the data stored in the body according to the needs of the actual application.

[0057] Preferably, when the new block received by the block verification module is a data block, the new block is checked to see whether it meets the resource contention requirement. The resource contention requirement mentioned above may, for example, refer to whether the digest value of the block meets the requirement.

[0058] Preferably, when the new block received by the block verification module is a data block, the legitimacy of the data in the body is checked according to the upper-layer application logic, for example, by verifying through the signature whether the transaction is created by the correct user and whether the transaction meets the requirements of the upper-layer application.

[0059] Preferably, when the new block received by the block verification module is an empty block, it is checked whether the new block is approved by more than two-thirds of the committee members. A joint signature scheme can be used to check whether the new block is approved by more than two-thirds of the committee members.

[0060] The local sorting module is configured to allow each blockchain participant to sort all data blocks in the local schema blockchain according to a predetermined rule. The local sorting module can ensure that all blockchain participants have consistent sorting results for all blocks.

[0061] like Figure 4 As shown, the local sorting module is configured to first sort all empty blocks in order, and each empty block logically represents a round. Subsequently, the local sorting module assigns all data blocks to different rounds according to the reference relationship between the empty blocks and the data blocks. Between different rounds, the data blocks are sorted according to the order of the rounds they belong to, and within the same round, the data blocks are sorted according to the summary value.

[0062] In the case where the empty block Ei is the first empty block that directly or indirectly references the data block Dj, the local sorting module assigns the data block Dj to the round to which the empty block Ei belongs.

[0063] The local sorting module sorts data block D j Assigned to empty block E i In this case, the data block D j Sorted blocks.

[0064] In data block D s If it cannot be assigned to any empty block, the local sorting module will assign data block D s Treated as unsorted blocks.

[0065] The local sorting module sorts all sorted data blocks. Preferably, the local sorting module sorts all sorted data blocks according to the order of the empty blocks to which the data blocks belong. Preferably, for multiple data blocks belonging to the same empty block, the local sorting module can sort them according to the summary values ​​of the multiple data blocks.

[0066] like Figure 1As shown, a hybrid consensus implementation method for a graphical blockchain is proposed, comprising at least steps S1 to S5. Although the lightweight data storage method in the specific embodiment of the present invention is depicted in a specific order, this should not be understood as requiring such operations to be completed in the specific order shown or in a sequential order, or to perform all illustrated operations to obtain the desired results. In some cases, multitasking or parallel processing can be beneficial. Similarly, although the above discussion contains certain specific implementation details, this should not be interpreted as limiting the scope of any invention or claim, but rather as a description of a specific embodiment that can be directed to a specific invention. Certain features described in the context of separate embodiments in this specification may also be integrated and implemented in a single embodiment. Conversely, the various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination.

[0067] Figure 1 Medium i (i=1~5) refers to different blockchain participants. j (j=1-12) refers to different data blocks. a (a=1~3) refers to different empty blocks. EB1 is the first empty block, corresponding to the first round. Since EB1 directly or indirectly references B1B2B4, B1B2B4 is assigned to the first round. EB2 is the second empty block, corresponding to the second round. B3B5B6 is assigned to the second round (although B1B2B4 is also indirectly referenced by EB2, B1B2B4 has been assigned to the first round). Similarly, EB3 is the third empty block, corresponding to the third round, B7B8B9B 10 Assigned to the third round. B 11 B 12 It is not referenced by any empty blocks, so it belongs to the unsorted block.

[0068] S1: A blockchain participant calls the data structure construction module to construct a data block. The body field of the block stores the received user transactions, and the proof field is empty. Next, the generated data block is handed over to the data block generation module, which fills in the legal proof field for the data block based on a certain rule to generate a complete data block. Taking PoW as an example, the data block generation module will continuously change the value of the proof field until the summary value of the data block is less than the pre-set difficulty value. The complete data block is broadcast to the network.

[0069] When a blockchain participant receives a new block, step S2 is executed.

[0070] S2: The blockchain participant who receives the new block determines whether it has received this block before. If the blockchain participant who receives the new block has received this block before, no processing is done. Otherwise, the block verification module is called to check the legitimacy of the new block.

[0071] Checking the legitimacy of a new block at least includes: whether all ancestor blocks of the new block have been received locally. If all ancestor blocks of the new block have not been received locally, the new block will not be processed temporarily until all ancestor blocks of the new block have been received.

[0072] Checking the legitimacy of the new block also includes: checking whether the proof field of the new block is legal according to certain rules, and checking whether the data stored in the body of the new block is legal according to specific application requirements. If any check fails, the block is discarded and the processing flow is terminated.

[0073] After the legality check, execute step S3.

[0074] S3: Every time a new block is received, its type is determined to be a data block or an empty block based on its data structure (whether the block contains the body field). Different types of blocks have different processing procedures. If the new block is a data block, no processing is performed. If the new block is an empty block, the local sorting module is called to sort all blocks in the graph blockchain.

[0075] S4: Blockchain participants periodically call the committee generation module to determine whether committee member updates are required based on the local blockchain copy. For example, the committee generation module can be configured to be called once every n empty blocks added to the blockchain. If it is determined that committee member updates are required, the committee member list is updated; otherwise, no processing is performed.

[0076] S5: Blockchain participants regularly check whether they are committee members to determine whether they need to participate in the committee consensus. If the blockchain participant is not a committee member, no action is taken; otherwise, the participant joins the committee consensus and completes the proposal and voting of new empty blocks by calling the empty block generation module. Each empty block will reference multiple data blocks, and the empty blocks that pass the vote will be broadcast to the network. After receiving the empty blocks, other blockchain participants will sort and confirm the data blocks according to the reference relationship between the empty blocks and the data blocks.

[0077] It should be noted that the above-mentioned specific embodiments are exemplary, and those skilled in the art can come up with various solutions inspired by the disclosure of the present invention, and these solutions also belong to the disclosure scope of the present invention and fall within the protection scope of the present invention. Those skilled in the art should understand that the present invention specification and its drawings are illustrative and do not constitute a limitation on the claims. The scope of protection of the present invention is defined by the claims and their equivalents. The present invention specification contains multiple inventive concepts, such as "preferably", "according to a preferred embodiment" or "optionally", all of which indicate that the corresponding paragraph discloses an independent concept, and the applicant reserves the right to file a divisional application based on each inventive concept.

Claims

1. A hybrid consensus implementation method for graph-based blockchain, characterized in that: At least: Call at least one module to generate a new data block and broadcast the new block; Calling at least one module to check and verify the received new block based on preset rules; Call at least one module to generate empty blocks, sort all empty blocks in order, each empty block logically represents a round, and assign all data blocks to different rounds according to the reference relationship between the empty blocks and the data blocks; Calls at least one module to update the committee membership list.

2. The hybrid consensus implementation method according to claim 1, characterized in that: New data blocks are generated by: Store the data that needs to be written to the blockchain into the constructed data structure; Legal data blocks are generated through competition.

3. The hybrid consensus implementation method according to claim 1 or 2, characterized in that: The preset rules for checking and verifying new blocks include at least: The blockchain participants who receive the new block determine whether they have received the new block before; If the judgment result is no, check the legitimacy of the new block.

4. The hybrid consensus implementation method according to claim 1, characterized in that: The preset rules for checking and verifying new blocks also include: Check whether the proof field of the new block is legal; Check whether the data stored in the body of the new block is legal.

5. The hybrid consensus implementation method according to claim 1, characterized in that: The preset rules for checking and verifying new blocks also include: Check the data structure of the new block received; If the new block is an empty block, call at least one module to sort all blocks in the graph blockchain.

6. The hybrid consensus implementation method according to claim 1, characterized in that: Determine if committee membership updates are needed based on the local blockchain copy.

7. The hybrid consensus implementation method according to claim 1, characterized in that: The hybrid consensus implementation method further includes: Blockchain participants regularly check if they are members of the committee; If the check result is yes, new empty blocks are generated regularly through voting.

8. The hybrid consensus implementation method according to claim 1, characterized in that: When constructing a new data block, the proof field that proves that the participant who created the data block won the resource competition is empty by default.

9. The hybrid consensus implementation method according to claim 1, characterized in that: When constructing a new empty block, the proof field that proves that the empty block has been recognized by enough participants is empty by default.

10. A hybrid consensus implementation device for a graph-based blockchain, characterized in that: At least: A committee generation module, which is configured to select some blockchain participants to form a committee; An empty block generation module, which is configured to allow committee members to periodically generate new empty blocks through voting; A block verification module, which is configured to check and verify the received new block according to preset rules when a new block is received; The local sorting module is configured to sort all empty blocks in order, each empty block logically represents a round, and allocate all data blocks to different rounds according to the reference relationship between the empty blocks and the data blocks.

Images