A lightweight blockchain consensus method for distributed networks

Abstract

The present invention belongs to the field of blockchain consensus mechanism, and relates to a lightweight blockchain consensus method for distributed networks; the method comprises that a distributed node submits a solution to a blockchain network in a current block generation round, and obtains a hash function value under a trusted proof of work; when the hash function value satisfies a reputation generation target but does not satisfy a block generation target, the distributed node generates a reputation proof, and increases the reputation value of the distributed node in the next block generation round; when the hash function value does not satisfy the reputation generation target, the reputation value of the distributed node in the next block generation round is kept unchanged; when the hash function value satisfies the block generation target, a block is successfully generated, and the reputation value of the distributed node in the next block generation round is reset; the reputation value set by the present invention can be used to adjust its block generation target, thereby reducing the difficulty of block generation, improving the degree of decentralization of a blockchain-assisted distributed Internet of Things system, and has a very broad application prospect.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain consensus mechanism, and specifically relates to a lightweight blockchain consensus method for distributed networks. Background Art

[0002] The centralized data management architecture with central servers or cloud servers as the core has problems such as single point failure, data privacy leakage and limited scalability. Therefore, the current research trend has shifted to distributed network architecture, and it is difficult for ubiquitous and open distributed networks to establish and maintain trust between nodes, which leads to inherent security issues in distributed networks. In response to the above problems, blockchain technology is a major solution. Due to its decentralized, trustless, traceable and tamper-proof characteristics, it is considered an effective solution to solve the lack of trust in distributed networks.

[0003] Although blockchain-assisted distributed network systems have broad prospects, there are still many obstacles to deploying blockchain in distributed networks. The most important problem is the incompatibility between the mainstream blockchain consensus mechanism and the large number of distributed nodes with limited computing resources. For example, Proof of Work (PoW), as the current mainstream consensus mechanism, consumes huge computing resources and is not suitable for distributed nodes with limited resources. In addition, PoW also has the phenomenon of computing power centralization and lacks an effective incentive mechanism to encourage nodes to participate in consensus. In addition, some blockchain-assisted distributed networks also use the Practical Byzantine Fault Tolerance (PBFT) consensus mechanism to reduce the consumption of computing resources for consensus, but PBFT is only suitable for small-scale blockchain networks. When the number of nodes in the network increases, the communication complexity will increase exponentially.

[0004] In order to solve the problem of incompatibility between the mainstream consensus mechanism and distributed nodes, the current improvement measure is to introduce reputation rights and interests, and change the difficulty of the node's block generation according to the size of the reputation, so as to reduce the energy consumed by reaching consensus, thereby adapting to IoT devices with limited computing resources. However, the proof-of-work consensus based on reputation rights and interests still has the following four problems: First, both ignore the interpretability and verifiability of reputation rights and interests, resulting in a disconnect between the on-chain reputation and reputation data; second, the phenomenon of computing power concentration in the original proof-of-work has not been suppressed; third, there is a lack of effective incentive mechanisms to encourage nodes to participate in consensus; fourth, both modify the consensus process of the original proof-of-work, resulting in certain obstacles to its deployment in the existing blockchain network based on the proof-of-work consensus mechanism. Summary of the invention

[0005] To achieve the above purpose, the present invention provides a lightweight blockchain consensus method for distributed networks. The core idea is to explore and utilize verifiable on-chain reputation. First, the present invention introduces two difficulties: reputation generation difficulty and block generation difficulty, where the reputation generation difficulty is much smaller than the block generation difficulty. In each round of block generation, when the workload of the distributed node meets any preset reputation generation target, but has not yet reached the corresponding block generation target, the system still recognizes the computing power investment of this distributed node in this round and generates a reputation certificate for it. The distributed node can increase the corresponding reputation value according to the reputation generation difficulty satisfied by the reputation certificate. The higher the reputation generation difficulty satisfied, the more reputation value can be obtained. In addition, the distributed node can adjust the block generation target according to its accumulated reputation value. When the reputation value accumulated by the distributed node exceeds the preset reputation threshold, the distributed node can reduce its own block generation difficulty. The higher the reputation threshold exceeded by the reputation value accumulated by the distributed node, the lower the corresponding block generation difficulty. Once the distributed node successfully generates a legal block, its accumulated reputation value will be automatically cleared, and the reputation will be accumulated again from the next block round. Secondly, after obtaining the reputation proof, each distributed node needs to publish it in the network for other nodes or devices to verify its rationality. In addition, the reputation proof generated by each distributed node needs to form a chain structure according to the connection order of the blocks, which are connected to each other through hash pointers, that is, the hash pointer of each round of reputation proof points to the reputation proof in the previous block round. Therefore, any node or device in the network can verify the authenticity and rationality of the reputation of the distributed node through the chain structure of reputation.

[0006] A lightweight blockchain consensus method for distributed networks of the present invention mainly includes the following steps:

[0007] The distributed node submits a solution to the blockchain network in the current block generation round, and obtains a hash function value under the trusted proof of work based on the block hash value of the previous block generation round, the reputation value of the distributed node in the current block generation round, the solution and the block information;

[0008] When the hash function value under the trusted proof of work of the distributed node meets the reputation generation target but does not meet the block generation target, the blockchain network generates a reputation certificate for the distributed node and increases the reputation value of the distributed node in the next block generation round;

[0009] When the hash function value under the trusted proof of work of the distributed node does not meet the reputation generation target, the reputation value of the distributed node in the next block generation round remains unchanged;

[0010] When the hash function value under the trusted proof of work of the distributed node meets the block generation target, the block is successfully generated and the reputation value of the distributed node in the next block generation round is reset;

[0011] Among them, the reputation generation target is much smaller than the block generation target, the reputation generation target is determined by the reputation generation difficulty, the reputation generation difficulty includes multiple reputation generation difficulties of different difficulty levels, and the block generation target is determined by the block generation difficulty, the block generation difficulty includes multiple block generation difficulties of different difficulty levels.

[0012] Furthermore, the calculation method of the hash function value under the trusted proof of work includes calculating the block hash value of the previous block generation round, the reputation value of the distributed node in the current block generation round, and the hash function value of the solution and block information through a hash operation function, that is, the hash function value under the trusted proof of work.

[0013] Furthermore, the method for calculating the hash function value under the trusted proof of work also includes: if the block hash value of the previous block generation round, the reputation value of the distributed node in the current block generation round, the hash function value of the solution and the block information are less than the reputation generation target or the block generation target, then the solution is a feasible solution, and the block hash value of the previous block generation round, the reputation value of the distributed node in the current block generation round, the hash function value of the feasible solution and the block information is calculated by a hash operation function, which is the hash function value under the trusted proof of work.

[0014] Furthermore, the increasing of the reputation value of the distributed node in the next block generation round includes that if the difficulty level of the reputation generation difficulty corresponding to the distributed node is greater, the increased reputation value is higher; if the difficulty level of the reputation generation difficulty corresponding to the distributed node is smaller, the increased reputation value is lower.

[0015] Furthermore, if the reputation value of the distributed node in the current block generation round exceeds the preset reputation threshold, the block generation difficulty is reduced, and the block generation target is updated according to the reduced block generation difficulty.

[0016] Furthermore, the block generation difficulty and the reputation value of the distributed node are in an inverse mapping relationship, and the inverse mapping relationship includes discrete mapping or continuous mapping.

[0017] Furthermore, after the blockchain network generates a reputation certificate for the distributed node, it also includes publishing the distributed node in the blockchain network for verification by other nodes in the blockchain network.

[0018] Furthermore, after the blockchain network generates the reputation certificate for the distributed node, it also includes forming a chain structure according to the connection method of the blocks, and the chain structure is interconnected through hash pointers, that is, the hash pointer of the reputation certificate of the current block generation round points to the reputation certificate of the previous block generation round.

[0019] Beneficial effects of the present invention:

[0020] (1) The present invention designs a reputation evaluation mechanism based on computing power contribution, which quantifies the actual workload of distributed nodes with reputation values. In addition, distributed nodes can reduce the difficulty of block generation based on their accumulated reputation values.

[0021] (2) The present invention designs a chain structure of reputation to achieve verifiability and traceability of reputation value, so that distributed nodes can verify the correctness of the reputation value of any peer device, thereby ensuring network security.

[0022] (3) The present invention proposes a trusted proof of work, which, compared with the traditional proof of work, can significantly reduce the block production ratio of the computing power alliance and increase the block production ratio of independent nodes, thereby reducing the enthusiasm of independent nodes to join the computing power alliance and achieving the purpose of suppressing the unlimited development of the computing power alliance.

[0023] (4) Compared with other lightweight proof-of-work consensus protocols, the present invention is based on the basic architecture of native proof-of-work and is therefore more compatible with existing blockchain systems based on the proof-of-work consensus mechanism. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 This is a flowchart of a blockchain consensus method according to an embodiment of the present invention;

[0025] Figure 2 is a schematic diagram of block generation according to an embodiment of the present invention;

[0026] Figure 3 It is a schematic diagram of the chain structure of blocks and reputation of the trusted proof of work in an embodiment of the present invention;

[0027] Figure 4 It is a performance diagram of the suppression computing power alliance of the trusted proof of work in an embodiment of the present invention;

[0028] Figure 5 This is a block production ratio diagram of the computing power alliance and independent nodes in an embodiment of the present invention. DETAILED DESCRIPTION

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

[0030] A distributed network is a network structure in which multiple independent computers or nodes work together to achieve data transmission, processing and storage through mutual cooperation and communication. A distributed network can be used as a topological structure of a wide area network, suitable for large-scale networks across regions, and can also provide an infrastructure for cloud computing to achieve elastic computing and on-demand expansion. The introduction of blockchain technology in a distributed network can ensure decentralized storage and verification of data. Taking the blockchain-based Internet of Things network as an example, distributed nodes can be various types of sensors, actuators, controllers or other intelligent devices. These nodes play different roles in the Internet of Things, such as data acquisition, data transmission, data processing, control execution, etc.

[0031] In a blockchain network, multiple distributed node devices may be included, and each node device may communicate peer-to-peer (P2P) with any other node device in the blockchain network. The node device may be an electronic device with computing and storage functions. The node device may communicate with the corresponding client. For example, the node device may receive transaction information sent by the corresponding client and reach a consensus on the transaction information. As an example and not a limitation, when the node device is a server of an application, the corresponding client may be a client of the application. Each node device in a distributed network ensures the consistency of data between each other through consensus operations.

[0032] Based on the above analysis, the present invention proposes a lightweight blockchain consensus method for distributed networks, such as Figure 1 As shown, the method includes:

[0033] 101. The distributed node submits a solution to the blockchain network in the current block generation round, and obtains a hash function value under the trusted proof of work based on the block hash value of the previous block generation round, the reputation value of the distributed node in the current block generation round, the solution and the block information;

[0034] In an embodiment of the present invention, an embodiment of the present invention provides a reputation-based hash operation function, which integrates the reputation value into the hash function. The calculation method of the hash function value under the trusted proof of work includes calculating the hash function value of the distributed node reputation value, the solution and block information, and the hash function value of the hash value of the previous block through the hash operation function, that is, the hash function value under the trusted proof of work.

[0035] It should be noted that the present invention innovatively integrates the reputation value into the hash operation function and constructs a chain verification mechanism based on reputation. Under this mechanism, other nodes in the distributed network can calculate the reputation value of the target node by themselves by accessing the reputation proof of the target node in the chain structure. Subsequently, these calculated reputation values ​​will be directly compared with the reputation value publicly declared by the target node in the hash operation function. Through this comparison process, it is possible to effectively identify and determine whether the reputation value of the node has been tampered with or forged. This innovative design not only enhances the transparency and credibility of the behavior of distributed nodes, but also significantly improves the overall security and reliability of the distributed network, ensuring the legitimacy and effectiveness of each node in the distributed network.

[0036] Specifically, in trusted proof of work, each distributed node needs to obtain credibility or block generation rights by solving a hash function. The hash function under trusted proof of work is expressed as:

[0037]

[0038] Among them, H PoTW (k,n) represents the hash function value of node n under the trusted proof of work at block round k; H(·) represents the hash operation function (such as SHA256), which outputs a binary sequence of L = 256 bits; b k-1 Indicates the hash value of the block generated at block round k-1; represents the reputation value of node n at block round k; x k represents the solution at block round k, which is a 32-bit Nonce; y k Indicates the block information at block round k. The block information includes some other necessary information, such as the hash of the Merkle tree root, timestamp, difficulty target, etc.

[0039] In a preferred embodiment of the present invention, the method for calculating the hash function value under the trusted proof of work also includes: if the block hash value of the previous block generation round, the reputation value of the distributed node, the hash function value of the solution and the block information is less than the reputation generation target or the block generation target, then the solution is a feasible solution, and the hash function value of the block hash value of the previous block generation round, the reputation value of the distributed node, the feasible solution and the block information is calculated by a hash operation function, which is the hash function value under the trusted proof of work.

[0040]

[0041] Among them, b k-1represents the hash value of the block at block round k-1. When formula (2) is satisfied, it indicates that the solution is a feasible solution. It should be emphasized that two types of target values ​​are introduced in the trusted proof of work, corresponding to two sets of difficulties: the block generation difficulty set and reputation generation difficulty set For formula (2), we have T(D)=2 L-D Indicates the block generation target corresponding to the block; D indicates the block generation difficulty corresponding to the target value.

[0042] In a preferred embodiment of the present invention, in order to ensure fairness, the trusted proof of work of the present invention stipulates that in each block round, any node can submit at most one solution to obtain reputation. This is to prevent nodes from accumulating reputation indefinitely in each block round, thereby preventing nodes with high reputation values ​​from always maintaining a low difficulty in generating blocks.

[0043] 102A. When the hash function value under the trusted proof of work of the distributed node meets the reputation generation target but does not meet the block generation target, the blockchain network generates a reputation certificate for the distributed node and increases the reputation value of the distributed node in the next block generation round;

[0044] 102B. When the hash function value under the trusted proof of work of the distributed node does not meet the reputation generation target, the reputation value of the distributed node in the next block generation round remains unchanged;

[0045] 102C. When the hash function value under the trusted proof of work of the distributed node meets the block generation target, the block is successfully generated, and the reputation value of the distributed node in the next block generation round is reset;

[0046] Among them, the reputation generation target is much smaller than the block generation target, the reputation generation target is determined by the reputation generation difficulty, the reputation generation difficulty includes multiple reputation generation difficulties of different difficulty levels, and the block generation target is determined by the block generation difficulty, the block generation difficulty includes multiple block generation difficulties of different difficulty levels.

[0047] In the embodiment of the present invention, it is assumed that the node set is {1,2,…,N}, where N represents the maximum number of nodes, that is, the total number of nodes, and n represents the index of the node; the set of block generation difficulty levels is {1,2,…,I}, where I represents the total number of block generation difficulty levels (for example: six different block generation difficulties are set, then I=6), i represents the index of the block generation difficulty level, i∈{1,2,…,I}; similarly, the set of reputation generation difficulty levels is {1,2,…,J}, where J represents the total number of reputation generation difficulty levels (for example: six different reputation generation difficulties are set, then J=6), j represents the index of the reputation generation difficulty level, j∈{1,2,…,J}.

[0048] In the embodiment of the present invention, in the trusted proof of work, each node has different block generation difficulties, that is, block generation difficulties, according to the different reputation values ​​accumulated by itself. Where D B1 >D B2 >...>D BI ; Similarly, the reputation increment of each node in a single block round may also be different, so And D R1 <D R2 <... <D RJ .

[0049] Through the above settings, an embodiment of the present invention provides a reputation-based multi-stage block generation difficulty adjustment mechanism, wherein the block generation difficulty is inversely mapped to the reputation value of the node, and the inverse mapping relationship includes discrete mapping or continuous mapping, that is, the greater the reputation value of the node, the smaller the corresponding block generation difficulty, and the smaller the reputation value of the node, the greater the corresponding block generation difficulty.

[0050] In some embodiments, taking discrete mapping as an example, the mapping function between the reputation value of a node and the difficulty level of block generation under trusted proof of work is expressed as:

[0051]

[0052] in, represents the difficulty of block generation of node n in block round k, f() represents the mapping function, {δ1,δ2,...,δ I-1} is a set of preset reputation thresholds, and δ1<δ2<...<δ I-1 .

[0053] It should be noted that, in addition to the discrete mapping relationship (3), a continuous mapping function that can reflect the inverse relationship between the reputation value and the block generation difficulty can also be used for difficulty adjustment. The embodiment of the present invention provides a reputation-based multi-order block generation difficulty adjustment mechanism, which can make the corresponding block generation difficulty different when the node's accumulated reputation value reaches different preset reputation thresholds; as the node's accumulated reputation value increases, its corresponding block generation difficulty will also decrease.

[0054] Through the above settings, the present invention also provides an on-chain reputation evaluation mechanism. The on-chain reputation evaluation mechanism in the trusted workload proof is used to give quantifiable reputation rewards to nodes that honestly participate in the consensus and make computing power contributions. As long as the node can submit a reputation generation target that meets the preset reputation generation target T(D Rj ) solution, even if the node fails to generate a block, it can still obtain a certain reputation reward. It is worth noting that the trusted workload proof stipulates that the difficulty of reputation generation is much lower than the difficulty of block generation. For example, the reputation generation difficulty can be less than 1 / 1000 of the difficulty of block generation. In this way, even nodes with very small computing power can obtain a certain reputation in each round of block generation. If the node provides a preset block generation target, The node can generate blocks at this time, and the reputation reward can be reset to make the node's reputation value 0 so as to enter the next round of block generation process; and when the node provides a value that does not meet the minimum reputation generation target T(D R1 ), since the reputation generation target is less than the block generation target, this indicates that the node also does not meet the preset block generation target The solution is that the reputation value of the distributed node in the next block generation round can remain unchanged and continue the reputation value of the previous round.

[0055] Corresponding to the above steps 102A to 102C, when a node successfully generates a block in block round k, the updated formula of the reputation value of the distributed node in the next block generation round is expressed as:

[0056]

[0057] Where (4a) indicates that the hash function value calculated by the solution submitted by node n under the trusted workload proof satisfies the reputation generation target T(D Rj ), but does not meet the block generation target If a block fails to be generated at this time, its reputation value will increase (4b) indicates that the hash function value calculated by the solution submitted by node n under the trusted proof of work fails to meet the minimum reputation generation target T(D R1 ), its reputation value remains unchanged; (4c) indicates that the hash function value calculated by node n under the trusted workload proof satisfies the block generation target At this time, the block is successfully generated and its reputation value is reset to 0. Reputation is accumulated again from the next block round, thus preventing nodes with high reputation values ​​from maintaining a low block generation difficulty.

[0058] like Figure 2 As shown, represents the block generation target of node n in block round k, T(D R1 ) represents the minimum reputation generation target. Outcome I indicates that the node meets the block generation target and successfully generates a block, corresponding to (4c), successfully generates a block, but the reputation is set to zero; Outcome II indicates that the node does not meet the block generation target but meets the reputation generation target. The node can increase the corresponding reputation value according to the size of the reputation generation difficulty it meets, corresponding to (4a); Outcome III indicates that the node does not meet the minimum reputation generation target, and the node reputation remains unchanged, corresponding to (4b).

[0059] In the embodiment of the present invention, with respect to step 102A and as shown in formula (4a), this embodiment considers allocating a reputation value increment to a node: The greater the reputation generation difficulty that a node meets, the higher the reputation increment it obtains, thus adapting to the characteristics of heterogeneous computing power among nodes. It is worth noting that when a solution submitted by a node meets multiple reputation generation targets at the same time, the reputation increment obtained by the node in the current block round is determined by the reputation generation difficulty with the highest difficulty it meets.

[0060] In a preferred embodiment of the present invention, the present invention also adopts a reputation-based chain structure. After the blockchain network generates a reputation certificate for the distributed node, it also includes forming a chain structure according to the connection method of the blocks. The chain structure is interconnected through hash pointers, that is, the hash pointer of the reputation certificate of the current block generation round points to the reputation certificate of the previous block generation round.

[0061] like Figure 3 As shown in the figure, assuming that node n successfully generates blocks in block rounds kv and k, the node can accumulate at most v reputation certificates {a n,k-v+1 ,a n,k-v+2 ,...,a n,k}, where a n,k Represents the reputation proof submitted by node n in block round k, k = k-v+1, k-v+2,…, k-1, k. The chain structure of reputation can be expressed as:

[0062]

[0063] Among them, <·> represents the concatenation operator; b k-1 It is the hash value of the previous block (i.e., block round k-1); is the solution to meet the reputation generation difficulty requirement. It can be seen from formula (5) that the reputation proof a n,k refers to the reputation proof generated in the previous block round. At the same time, the reputation proofs form a chain structure of reputation in the order of block connection. Therefore, one reputation proof of a node only corresponds to one block, and the latter reputation proof points to the previous one, forming a chain structure.

[0064] In the embodiment of the present invention, it is considered that the block generation process of each node in the blockchain network is time - continuous. The time - driven simulation idea is intuitive and easy to implement, but the disadvantage is that it is very time - consuming. By using the event - driven simulation method, the simulation time can be saved and the performance consistent with the time - driven simulation can be maintained. Its core idea is that the state of the blockchain system changes with the occurrence of events in the system. For example, the state of the blockchain system under the trusted proof - of - work consensus mechanism changes with events such as each node successfully generating a block or the reputation value changing.

[0065] In the embodiment of the present invention, the performance of the present invention is described in combination with the simulation results. The simulation conditions are as follows: The total number of Internet of Things devices in the distributed Internet of Things is N = 100. In addition, there is a computing power alliance in the network. The computing power includes N1 = rN distributed nodes. The main task of these distributed nodes is to package transactions and create new blocks. By solving the complex trusted proof - of - work to compete for the block packaging right, the successful distributed nodes will obtain corresponding block rewards; where the proportion coefficient of the computing power alliance satisfies 0 < r ≤ 30%. The reputation generation difficulty is set as {D R1 ,D R2} = {12, 15}, and the corresponding reputation increments are 1 and 2. The block generation difficulty is {D B1 ,D B2 ,D B3 ,D B4 ,D B5 ,D 86} = {38, 35, 32, 29, 26, 23}, and the reputation thresholds are {δ1, δ2, δ3, δ4, δ5} = {10, 20, 30, 40, 50}.

[0066] To illustrate that the trusted proof - of - work can effectively suppress the block generation ability of the computing power alliance, the relative throughput gain shows the multiple relationship between the block generation ability of the same - sized computing power alliance under the trusted proof - of - work and the block generation ability under the proof - of - work. As Figure 4 shown, the inhibitory ability of the trusted proof - of - work on the computing power alliance increases with the increase in the computing power of the computing power alliance. Secondly, it increases with the increase in the number of block generation difficulty levels of the trusted proof - of - work.

[0067] In order to compare the performance of trusted proof of work and traditional proof of work in suppressing hashrate alliances and encouraging independent nodes, Figure 5 It shows that the network generates 10 under the trusted workload proof and workload proof of block difficulty level 6. 6 The block production ratio of the computing power alliance and independent nodes when there are blocks. Among them, node 1 represents the computing power alliance with r=30%, and the other nodes are independent nodes, and each node has unit computing power. First, compared with the proof of work, the block production ratio of the computing power alliance in the trusted proof of work has dropped significantly, and the block production ratio of independent nodes has increased. In the proof of work, the block production ratio of the computing power alliance is 30 times that of the independent node, but in the trusted proof of work, the block production ratio of the computing power alliance is less than 2 times that of the independent node. Secondly, compared with the proof of work, the block production ratio of the computing power alliance in the trusted proof of work is much lower than its computing power ratio, while the block production ratio of independent nodes is higher than their computing power ratio.

[0068] Therefore, compared with proof of work, trusted proof of work significantly reduces the block production ratio of mining pools and increases the block production ratio of independent nodes, thereby reducing the enthusiasm of independent nodes to join the computing power alliance. In addition, the income of nodes in the computing power alliance is also far lower than the income obtained by their independent participation in consensus. Therefore, nodes in the computing power alliance will also tend to leave the computing power alliance and participate in consensus independently. Trusted proof of work is not only suitable for lightweight distributed nodes with limited computing resources, but also can prevent the centralization phenomenon of resource-consuming blockchain consensus, improve the degree of decentralization of blockchain-assisted distributed Internet of Things systems, and has a very broad application prospect.

[0069] A person skilled in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the relevant hardware through a program, and the program can be stored in a computer-readable storage medium, which can include: ROM, RAM, disk or CD, etc.

[0070] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0071] Those skilled in the art will appreciate that the logic and / or steps represented in the flowchart or otherwise described herein, for example, may be considered as an ordered list of executable instructions for implementing logical functions, and may be specifically implemented in any computer-readable storage medium for use by an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, apparatus, or device and execute instructions), or used in conjunction with such instruction execution systems, apparatuses, or devices.

[0072] It should be understood that the various parts of the present invention can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, a plurality of steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or a combination thereof: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0073] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. Although embodiments of the present invention have been shown and described, it will be understood by those of ordinary skill in the art that various changes, modifications, substitutions and variations may be made to these embodiments without departing from the principles and spirit of the present invention, and the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A lightweight blockchain consensus method for distributed networks, characterized in that: The method comprises: The distributed node submits a solution to the blockchain network in the current block generation round, and obtains a hash function value under the trusted proof of work based on the block hash value of the previous block generation round, the reputation value of the distributed node in the current block generation round, the solution and the block information; When the hash function value under the trusted proof of work of the distributed node meets the reputation generation target but does not meet the block generation target, the blockchain network generates a reputation certificate for the distributed node and increases the reputation value of the distributed node in the next block generation round; When the hash function value under the trusted proof of work of the distributed node does not meet the reputation generation target, the reputation value of the distributed node in the next block generation round remains unchanged; When the hash function value under the trusted proof of work of the distributed node meets the block generation target, the block is successfully generated and the reputation value of the distributed node in the next block generation round is reset; Among them, the reputation generation target is less than the block generation target, the reputation generation target is determined by the reputation generation difficulty, the reputation generation difficulty includes multiple reputation generation difficulties of different difficulty levels, and the block generation target is determined by the block generation difficulty, and the block generation difficulty includes multiple block generation difficulties of different difficulty levels.

2. A lightweight blockchain consensus method for distributed networks according to claim 1, characterized in that: The calculation method of the hash function value under the trusted proof of work includes calculating the block hash value of the previous block generation round, the reputation value of the distributed node in the current block generation round, the hash function value of the solution and the block information through a hash operation function, that is, the hash function value under the trusted proof of work.

3. A lightweight blockchain consensus method for distributed networks according to claim 2, characterized in that: The calculation method of the hash function value under the trusted proof of work also includes: if the block hash value of the previous block generation round, the reputation value of the distributed node in the current block generation round, the hash function value of the solution and the block information are less than the reputation generation target or the block generation target, then the solution is a feasible solution, and the block hash value of the previous block generation round, the reputation value of the distributed node in the current block generation round, the hash function value of the feasible solution and the block information is calculated by a hash operation function, which is the hash function value under the trusted proof of work.

4. A lightweight blockchain consensus method for distributed networks according to claim 1, characterized in that: The increasing of the reputation value of the distributed node in the next block generation round includes that if the difficulty level of the reputation generation difficulty corresponding to the distributed node is greater, the increased reputation value is higher; if the difficulty level of the reputation generation difficulty corresponding to the distributed node is smaller, the increased reputation value is lower.

5. A lightweight blockchain consensus method for distributed networks according to claim 1, characterized in that: If the reputation value of the distributed node in the current block generation round exceeds the preset reputation threshold, the block generation difficulty is reduced, and the block generation target is updated according to the reduced block generation difficulty.

6. A lightweight blockchain consensus method for distributed networks according to claim 5, characterized in that: The block generation difficulty and the reputation value of the distributed node are in an inverse mapping relationship, and the inverse mapping relationship includes discrete mapping or continuous mapping.

7. A lightweight blockchain consensus method for distributed networks according to claim 1, characterized in that: After the blockchain network generates a reputation certificate for the distributed node, the distributed node is published in the blockchain network for verification by other nodes in the blockchain network.

8. A lightweight blockchain consensus method for distributed networks according to claim 1, characterized in that: After the blockchain network generates the reputation certificate for the distributed node, it also includes forming a chain structure according to the connection method of the blocks, and the chain structure is connected to each other through hash pointers, that is, the hash pointer of the reputation certificate of the current block generation round points to the reputation certificate of the previous block generation round.

Images