Blockchain consensus method based on credibility and banzhaf index

Abstract

The application relates to a blockchain consensus method based on credibility and banzhaf indexes and belongs to the technical field of blockchain consensus. After system parameters are initialized, a node generates a random number through a timestamp and a private key, grouping and election are completed. An ordinary node is responsible for transaction block packaging, competes for block right by solving a hash problem, and the difficulty is adjusted according to the credibility; a super node randomly selects a block person. A verifier node checks the legality of an ordinary block and votes, and if more than half of the votes are supported by high-credibility nodes, the verification is passed and the chain is uploaded. After the consensus is ended, the credibility is updated according to the node performance, and the next round of consensus is started. The application improves the message processing speed of node devices in the blockchain network under high-concurrent transaction volume, increases the credibility of stored data in the node devices, has the characteristics of decentralization, high throughput and high security, and is suitable for various network information sharing and information tracing scenes.

Description

Technical Field

[0001] This invention belongs to the field of blockchain consensus technology and relates to a blockchain consensus method based on reputation and Banzhaf index. Background Technology

[0002] As a decentralized and tamper-proof distributed ledger technology, blockchain has not only brought unprecedented changes to the financial sector, but has also demonstrated its powerful potential in many other areas such as supply chain management, identity authentication, and copyright protection.

[0003] However, with the deepening application and expansion of blockchain technology, its core mechanism—the consensus mechanism—has become the focus of researchers' attention. As the core component ensuring data consistency among all nodes in a blockchain network, the importance of the consensus mechanism is self-evident. Traditional blockchain consensus mechanisms can be mainly divided into three categories: Proof of Work (PoW), Byzantine consensus, and Proof of Stake (PoS).

[0004] First, the proof-of-work mechanism requires nodes in the network to perform a large number of hash calculations to compete for the right to produce blocks. While this mechanism ensures network security, its enormous energy consumption and wasted computing resources pose challenges for its practical application. As the scale of the blockchain network expands, the computing power required to produce blocks also increases, which not only increases the economic burden on nodes but also puts considerable pressure on the environment.

[0005] Secondly, Byzantine-based consensus mechanisms are designed based on the famous Byzantine Generals Problem. In this mechanism, nodes in the network determine the consensus result through voting. However, when the number of nodes is large, the communication complexity increases dramatically, which not only affects the efficiency of consensus but also increases the difficulty of network maintenance.

[0006] Proof-of-Stake (PoS) is a relatively new consensus mechanism that has emerged in recent years. It allocates block-producing rights based on the amount of tokens held by nodes and the time they have held them, thereby reducing energy consumption. However, this mechanism also carries certain risks, such as the potential for resources to be monopolized by a few nodes, leading to increased network centralization.

[0007] To address the problems inherent in traditional consensus mechanisms, this invention proposes a blockchain consensus method based on reputation and the Banzhaf index. This method comprehensively considers both node reputation and the Banzhaf index, aiming to achieve a more efficient, secure, and decentralized consensus process, reduce the workload of node devices, significantly accelerate information synchronization between nodes, and increase the system's data processing capabilities under high concurrency environments. It is applicable to various network information sharing and information traceability scenarios. Summary of the Invention

[0008] In view of this, the purpose of this invention is to provide a blockchain consensus method based on reputation and Banzhaf index, which solves the technical problems of high resource consumption, centralization and low security in current blockchain consensus mechanisms.

[0009] To achieve the above objectives, the present invention provides the following technical solution:

[0010] A blockchain consensus method based on reputation and Banzhaf index, comprising the following steps:

[0011] S1: Initialize the system parameters and prepare the node devices for the blockchain consensus mechanism. The initialized system parameters include: node reputation, node public and private keys, and the duration T of this consensus round. Round Normal block production interval T Interva The number of election groups M and the initial consensus timestamp of this round (TimeStamp) cur ;

[0012] The node device preparation refers to the node device registering to join the blockchain network node, downloading a copy of the blockchain, synchronizing blockchain information on the local disk, and paying a deposit to the system. If the node device engages in dishonest behavior in the consensus process, the system will confiscate the deposit.

[0013] The node device can be any network electronic device that deploys this consensus algorithm, including servers and personal computers.

[0014] S2: Each node device will store the initial timestamp of this round of consensus. cur Combined with its own private key, it serves as a seed input to verify the random function, obtains a random number and a random number proof, calculates a classification number, and then broadcasts the generated random number, random number proof, and random classification number to all network node devices to group node devices.

[0015] S3: For node devices that have been grouped, an election is held within their respective groups. The election is based on the reputation value of the node devices to select super node devices, validator node devices, and ordinary node devices.

[0016] S4: All ordinary node devices are responsible for packaging transaction blocks. Ordinary node devices compete for the right to produce transaction blocks by solving hash problems. The difficulty adjustment coefficient is adjusted according to the reputation to reduce the difficulty of solving the problem for high-reputation node devices and reduce the amount of intensive CPU calculations required by honest node devices. The node device that successfully produces a block broadcasts the transaction block to the entire network. All node devices in the network verify whether the transaction block is valid. If it is valid, it is put into the transaction block pool on the node device's local disk. If it is invalid, the information of the ordinary node device that violated the block production rule is recorded and penalized at the end of the consensus phase.

[0017] S5: All supernode devices are responsible for packaging ordinary blocks. Every once in a while, the system randomly selects a supernode device with a high reputation as the producer of ordinary blocks, and is responsible for packaging transaction blocks and generating ordinary blocks. The ordinary blocks are connected to multiple transaction blocks through hash pointers to complete the packaging of transaction blocks by ordinary blocks.

[0018] S6: After a regular block is produced, it is broadcast to all validator node devices. All validator node devices check the legality of the regular block and vote. If the regular block receives more than half of the votes and is supported by a high-reputation validator node device, it passes the verification and is put on the chain.

[0019] S7: After a regular block is successfully added to the blockchain, the revenue distribution is calculated using the Banzhaf rights index, which combines reputation.

[0020] S8: When the system-defined consensus duration for this round ends, update the node device reputation based on the performance of the node device in this round of consensus, start the next round of consensus, and return to step S1.

[0021] Furthermore, in S2, each node device combines the initial consensus timestamp (TimeStampcur) of this round with its own private key as a seed input to a verifiable random function to obtain a random number and a random number proof, and calculates a classification number. Then, it broadcasts the generated random number, random number proof, and random classification number to all node devices in the network for node grouping. This specifically includes the following steps:

[0022] S21: All nodes in the network use the initial consensus timestamp (TimeStampcur) and their private key (Nsk) as initial parameters, inputting a verifiable random function (VRF) to calculate a random number (VRF_Group), a random proof (Proof), and a random classification number (GroupNumber); the calculation method is as follows:

[0023] VRF_Group = VRF_Hash(N) sk TimeStamp cur (1)

[0024] Proof = VRF_Proof(N sk TimeStamp cur (2)

[0025] GroupNumber=VRF_Group mod M (3)

[0026] The node then broadcasts VRF_Group, Proof, and GroupNumber to all other nodes in the network.

[0027] S22: After receiving VRF_Group, Proof and GroupNumber from other node devices, the node device uses the verification function VRF_Verify, which verifies the random function, to verify it. Based on the return value of Flag, it determines whether the random group number is valid.

[0028] Flag is calculated as follows:

[0029] Flag = VRF_Verify(N pk ,VRF_Group,VRF_Proof,TimeStamp cur (4)

[0030] Where, N pk This is the public key of the message sender;

[0031] If Flag returns true, the message sender honestly generated VRF_Group, and then calculates whether the message sender's group number GroupNumber is true;

[0032] S23: After all network nodes verify the correctness of the messages, each node obtains its own GroupNumber and is assigned to the corresponding group.

[0033] Furthermore, in S3, for the node devices that have already been grouped, an election is conducted within their respective groups. This election is based on the node device's reputation value, resulting in the selection of super node devices, validator node devices, and ordinary node devices. Specifically:

[0034] The higher the reputation of a node device, the more votes it receives in the group election. The specific number of votes depends on the reputation ranking. For example, if the reputation ranking is in the top 30%, the number of votes is 3; if the reputation ranking is in the top 31% to top 60%, the number of votes is 2; and if it is any other ranking, the number of votes is 1. The reputation ranking refers to the reputation ranking of the node device among all node devices.

[0035] Node devices vote among themselves within their groups, and their roles in this round of consensus are determined by the number of votes they receive. The node device with the most votes becomes the super node device, the second most becomes the validator node device, and the rest are ordinary node devices.

[0036] Furthermore, in S4, all ordinary node devices are responsible for packaging transaction blocks. Ordinary node devices compete for the right to produce a transaction block by solving a hash problem. The difficulty adjustment coefficient is adjusted according to reputation to reduce the difficulty for high-reputation node devices and decrease the workload of intensive CPU computation required by honest node devices. The node device that successfully produces a block broadcasts the transaction block to the entire network. All node devices in the network verify the validity of the transaction block. If valid, it is placed in the transaction block pool on the node device's local disk. If invalid, the information of the ordinary node device that violated the block production rule is recorded, and penalty processing is carried out at the end of the consensus phase. Specifically, this includes the following steps:

[0037] S41: Ordinary node devices begin competing for the right to produce a block. Ordinary nodes compete by solving a hash puzzle. The specific method for determining whether an ordinary node device has successfully obtained the right to produce a block is as follows:

[0038] Hash(header,nonce)<target*difficulty (5)

[0039] Where Hash is the hash function selected by the system, header is the block header information of the currently mined transaction block, nonce is the random number tried by ordinary nodes when solving the hash problem, target is the difficulty value specified by the current system, and difficulty is the difficulty adjustment coefficient.

[0040] When the Hash(header, nonce) calculated by a regular node device satisfies this inequality, the regular node device obtains the right to produce a block of the transaction.

[0041] The difficulty adjustment coefficient is adjusted based on the reputation of ordinary node devices. The higher the reputation ranking of an ordinary node device, the greater the difficulty, and the lower the difficulty of the hash problem that the ordinary node device needs to solve.

[0042] S42: After a regular node device successfully produces a block, it broadcasts the produced transaction block to other node devices across the network. All node devices across the network verify whether the transaction block is valid. If it is valid, it is placed into the transaction block pool on the node device's local disk. If it is invalid, the information of the regular node that violated the block production rule is recorded and penalized during the consensus phase. The transaction block pool stores transaction blocks that have not yet been packaged by regular blocks.

[0043] In this consensus mechanism, the structure of a transaction block is similar to that of a block in a traditional blockchain. A block consists of a block header and a block body. The block body records information about the transactions to be packaged in the block. The block header contains the hash (PrevHash) of the previous transaction block, the timestamp (TimeStamp), the difficulty value (target), the nonce, the difficulty adjustment factor (difficulty), and the public key (N) of the block producer. pk MerkleRoot is generated from the transaction information packaged in this transaction block and the hash of this transaction block, TransactionBlockHash.

[0044] Furthermore, in S5, all supernode devices are responsible for packaging ordinary blocks. The system randomly selects supernode devices with high credibility as ordinary block producers at regular intervals, and these producers are responsible for packaging transaction blocks and generating ordinary blocks. This increases the credibility of information on the blockchain and provides consistent and highly authentic shared data for a large number of node devices in an open network environment. The ordinary block connects multiple transaction blocks through hash pointers, completing the packaging of transaction blocks into ordinary blocks. Specifically, this includes the following steps:

[0045] S51, The supernode device begins producing regular blocks, every T... Interval At any given time, a supernode device will be randomly selected as the block producer for this ordinary block. The higher the reputation of the supernode, the higher the probability of it being selected as the block producer.

[0046] The specific extraction method is as follows:

[0047] The percentage RP of each supernode device's reputation relative to the sum of all supernode device reputations is calculated as follows:

[0048]

[0049] Among them, R i Let be the reputation value of node device i, and total be the number of supernode devices;

[0050] Each supernode device will obtain an interval from 0 to 100 based on its own RP size. For supernode device i, its obtained interval range is [Li, Ri), and the interval range of the last supernode device is [Li, Ri]. Li and Ri are calculated as follows:

[0051]

[0052]

[0053] When i = 1, L i =0;

[0054] Subsequently, the supernode device that previously produced a normal block calculates the random beacon Pivot. If the Pivot falls within the RP range of a certain supernode device, that supernode device gains the right to produce the next normal block. The Pivot is calculated as follows:

[0055] pivot = VRF_Hash(PrevHash, N) sk )mod 100 (9)

[0056] Where PrevHash is the hash value of the previous normal block;

[0057] S52: After the supernode device finishes producing a block, it broadcasts the ordinary block to the validator node device and waits for the validator node device to verify the ordinary block.

[0058] A regular block structure consists of a block header and a block body. The block body stores the hash values ​​of the transaction blocks packaged within that regular block. Regular blocks connect multiple transaction blocks using hash pointers. The block header contains the hash value of the previous regular block (PrevHash), a timestamp (TimeStamp), and the block producer's public key (N). pk MerkleRoot is generated from the transaction block information packaged in this ordinary block and the hash of this ordinary block.

[0059] Furthermore, in step S6, after a regular block is produced, it is broadcast to all validator node devices. All validator node devices check the legality of the regular block and vote on it. If the regular block receives more than half of the votes and is supported by high-reputation validator nodes, it passes verification and is added to the blockchain. This specifically includes the following steps:

[0060] S61: After receiving the ordinary block sent by the supernode device, the validator node begins to verify the legality of the ordinary block and checks whether there is any abnormal information in the ordinary block;

[0061] S62: After all validator node devices have finished checking, they vote on the ordinary block. If the validator node device believes that the ordinary block has passed the verification, it casts a vote.

[0062] Once a regular block receives more than half of the total number of votes, it is verified by the validator node device and confirmed to be eligible for blockchain upload.

[0063] Validator nodes with higher credibility have more votes. The number of votes a validator node holds is related to its credibility ranking among all validator nodes. Specifically, if its credibility ranking is in the top 30%, it receives 3 votes; if its credibility ranking is in the top 31% to top 60%, it receives 2 votes; and if its ranking is otherwise, it receives 1 vote. The credibility ranking refers to the node's credibility ranking among all nodes.

[0064] Furthermore, in S7, after a regular block is successfully added to the blockchain, the distribution of revenue is calculated using a Banzhaf rights index that combines reputation, specifically including the following steps:

[0065] S71: After a regular block is added to the blockchain, the revenue is distributed as follows: 20% of the revenue from producing a regular block is allocated to the block-producing node device of that regular block, 30% of the revenue is allocated to the block-producing node devices of the transaction blocks contained in that regular block, and is divided equally among all block-producing nodes; 50% of the revenue is allocated to the validator node devices in this round of consensus.

[0066] S72: The revenue allocated to validator node devices is calculated by combining the banzhaf weight index and the reputation evaluation value REV, as follows:

[0067] The REV (Reputation Value) of the validator node device is calculated as follows:

[0068]

[0069] Where α, β, and γ are the corresponding weight values, and R i Let A be the reputation value of validator node i, and let total be the number of validator nodes. total(i) A represents the total number of historical actions of validator node i. bad(i) Let δ be the number of times validator node i has committed a violation in its historical behavior, and let TRC be the system-defined tolerable node behavior error rate. average TRC is the average number of transactions initiated between validator nodes throughout history. average(i→other) This represents the average number of transactions that validator node i has initiated to other validator nodes throughout history.

[0070] The banzhaf weight index of the validator node device is calculated as follows:

[0071] A regular block is considered valid after receiving a majority of votes from all validator node devices. During the vote on the validity of a regular block, if a validator node device is missing a vote, the block cannot pass the vote. This validator node device is then considered the key voter in that voting situation. Validator node devices cast all their votes at once, choosing to approve or disapprove the validity of the regular block. All validator node voting results are listed, and the number of times validator node device i has been a key voter is recorded (key). i The final validator node device's banzhaf index is:

[0072]

[0073] Where total represents the total number of validator node devices;

[0074] The final profit of the validator node device is calculated as follows:

[0075] Profit i =banzhaf i *REV i *w*50% (12)

[0076] Where w is the reward for producing a normal block.

[0077] Furthermore, in step S8, when the system-defined duration of the current consensus round ends, the node reputation is updated based on the performance of the node devices in this consensus round, and the next consensus round is initiated, returning to step S1, specifically:

[0078] Node devices according to T Round and TimeStamp cur Check if the consensus of the current round has reached its end time. If it has, the consensus mechanism enters the end phase, updates the reputation of the node devices according to the behavior of the node devices in this round of consensus, and starts the next round of consensus, then jumps to step S1.

[0079] The specific mechanism for updating reputation is as follows:

[0080] If node device i does not exhibit malicious behavior during this consensus phase, its reputation will be updated as follows:

[0081]

[0082] If node device i exhibits malicious behavior during this consensus phase, including generating incorrect blocks and forging random numbers, its reputation will be updated as follows:

[0083]

[0084] Where k is the consensus round, m is the reward coefficient, a is the reward gradient coefficient, n is the penalty coefficient, b is the penalty gradient coefficient, and R... round(i) Let be the percentage of node i's reputation relative to the sum of all nodes' reputations in the current round, calculated as follows:

[0085]

[0086] Where Total is the total number of nodes;

[0087] If node device i engages in dishonest behavior during this consensus round, the deposit paid in step S1 will be forfeited; if the number of dishonest behaviors by node device i across all consensus rounds exceeds the maximum threshold A that the system can tolerate. total(i) If the number of consensus attempts reaches ×δ, the node device will be removed from the system and will no longer participate in the next round of consensus.

[0088] The beneficial effects of this invention are as follows:

[0089] First, this invention makes the blockchain consensus process more decentralized by combining node device reputation and Banzhaf rights index. Each node device plays a different role in the consensus process according to its reputation, effectively preventing single points of failure and centralization risks, enhancing the security and stability of the entire system, increasing the speed of information synchronization between node devices, and reducing unnecessary network transmission overhead caused by information inconsistency.

[0090] Secondly, by classifying and grouping node devices according to their reputation, this invention reduces the possibility of malicious devices controlling information on the blockchain, increases the reliability of data sharing between node devices, and reduces the network overhead of node devices polling and querying blockchain replica information due to data inconsistency. At the same time, by adjusting the difficulty coefficient, the CPU workload of high-reputation node devices when solving hash problems is reduced, thereby improving the consensus efficiency of the entire system and accelerating the information synchronization speed between node devices.

[0091] Third, this invention uses a reputation update mechanism to reward and punish node devices' behavior during the consensus process. Honest and actively participating nodes will receive reputation increases and rewards, while malicious nodes will suffer reputation decreases and penalties, and may even be removed from the system. This mechanism effectively incentivizes nodes to maintain honest behavior and promotes the healthy development of the entire system.

[0092] Fourth, this invention calculates revenue distribution through the Banzhaf rights index. This scheme encourages cooperation among node devices to jointly maintain the stability and security of the blockchain network. Node devices with high credibility have greater influence in the consensus process, thereby obtaining more revenue. This mechanism helps promote cooperation and collaborative work among node devices.

[0093] Fifth, this invention features decentralization, high throughput, and high security.

[0094] Other advantages, objectives, and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination, or may be learned from practice of the invention. The objectives and other advantages of the invention can be realized and obtained through the following description. Attached Figure Description

[0095] To make the objectives, technical solutions, and advantages of the present invention clearer, the preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings, wherein:

[0096] Figure 1 This is a schematic diagram of the overall process of the present invention;

[0097] Figure 2 This is a schematic diagram illustrating the division of labor among the node devices of the present invention;

[0098] Figure 3 This is a schematic diagram of the working process of the node device of the present invention;

[0099] Figure 4 This is a diagram of the blockchain structure of the present invention;

[0100] Figure 5 This is a schematic diagram of a common block of the present invention;

[0101] Figure 6 This is a schematic diagram of the transaction block of the present invention. Detailed Implementation

[0102] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0103] The accompanying drawings are for illustrative purposes only and are schematic diagrams, not actual pictures. They should not be construed as limiting the invention. To better illustrate the embodiments of the invention, some parts in the drawings may be omitted, enlarged, or reduced, and do not represent the actual product dimensions. It is understandable to those skilled in the art that some well-known structures and their descriptions may be omitted in the drawings.

[0104] In the accompanying drawings of the embodiments of the present invention, the same or similar reference numerals correspond to the same or similar components. In the description of the present invention, it should be understood that if terms such as "upper," "lower," "left," "right," "front," and "rear" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, the terms used to describe positional relationships in the drawings are only for illustrative purposes and should not be construed as limiting the present invention. For those skilled in the art, the specific meaning of the above terms can be understood according to the specific circumstances.

[0105] Please see Figures 1-6 This is a blockchain consensus method based on reputation and the Banzhaf index.

[0106] like Figure 1 As shown, Figure 1 This invention demonstrates the entire process of the blockchain consensus method based on reputation and Banzhaf index, with the division of labor among node devices as follows: Figure 2 As shown, the node device workflow is as follows: Figure 3 As shown, the main content is as follows:

[0107] A blockchain consensus method based on reputation and Banzhaf index includes the following steps:

[0108] S1: Node devices that share information register and join the blockchain network, initializing system parameters such as node device reputation, node device public and private keys, duration of this consensus round, and number of election groups. Node devices deposit a security deposit with the system. If a node device engages in malicious behavior during this consensus round, the security deposit will be deducted. This process includes the following steps:

[0109] S11. Initialize the following system parameters:

[0110] T Round : Duration of consensus rounds.

[0111] T Interval : Normal block production interval.

[0112] M: Number of groups.

[0113] TimeStampcur: The initial timestamp of this round of consensus.

[0114] S12. The node device downloads a copy of the blockchain, synchronizes the blockchain information on its local disk, and deposits a security deposit with the system. If the node device engages in dishonest behavior during consensus, the system forfeits the security deposit. The node device can be any network electronic device that has deployed this consensus algorithm, such as servers and personal computers.

[0115] S2: Each node device uses the timestamp of the start of this consensus round and its private key as a seed, inputs a verifiable random function to obtain a random number and a proof of the random number, and calculates a group number. It then broadcasts this message to all node devices in the network to group them. This node grouping based on the verifiable random function disperses potentially malicious clusters of node devices in the network, preventing such clusters from colluding to disrupt information synchronization and sharing between nodes. Specifically, this includes the following steps:

[0116] S21: All node devices in the network input the timestamp (TimeStampcur) of the current consensus start and the node device's private key (Nsk) as initial parameters into the verifiable random function (VRF) to calculate VRF_Group, Proof, and GroupNumber. Subsequently, the node devices broadcast VRF_Group, Proof, and GroupNumber to all other node devices in the network. GroupNumber is the random group number, which is the number of the group the node device joins after random grouping. The calculation method is as follows:

[0117] VRF_Group = VRF_Hash(N) sk TimeStamp cur (1)

[0118] Proof = VRF_Proof(N sk TimeStamp cur (2)

[0119] GroupNumber=VRF_Group mod M (3)

[0120] S22: After receiving VRF_Group, Proof, and GroupNumber from other node devices, the node device uses the verification function VRF_Verify, which verifies the random function, to perform verification. Based on the return value of Flag, it determines whether the random group number is valid. The VRF_Verify calculation method is as follows (where Npk is the public key of the message sender):

[0121] Flag = (N pk,VRF_Group,VRF_Proof,TimeStamp cur (4)

[0122] If Flag returns true, it means that the message sender honestly generated VRF_Group, and then it is calculated whether the message sender's group number GroupNumber is true.

[0123] S23: After all network node devices verify the correctness of the message, each node device obtains its own GroupNumber and is assigned to the corresponding group.

[0124] S3: Node devices conduct intra-group elections, with nodes having higher reputation scores receiving more votes. This intra-group election elects supernode devices, validator nodes, and ordinary nodes. Node elections reduce the possibility of malicious devices controlling on-chain information, increase the reliability of data sharing between nodes, and reduce the network overhead of nodes polling for blockchain replicas due to data inconsistencies. The intra-group election of node devices specifically includes the following steps:

[0125] S31: The higher the node's reputation, the more votes it receives in the group election. The specific vote distribution is as follows:

[0126] Table 1

[0127] Reputation ranking vote count Top 30% 3 Top 31% - Top 60% 2 Other rankings 1

[0128] S32: The group election begins, with nodes voting against each other to determine their roles in this round of consensus. The node with the most votes becomes the supernode, the node with the second most votes becomes the validator node, and the remaining nodes become ordinary nodes.

[0129] S4: All regular node devices are responsible for packaging transaction blocks. Regular node devices compete for the right to produce a transaction block by solving a hash puzzle. Regular node devices with higher reputations have a lower hash puzzle difficulty and are more likely to gain the right to produce a block. This reduces the CPU-intensive computation workload required by honest node devices, lowers the node device workload, and avoids wasting power resources. Specifically, this includes the following steps:

[0130] S41: Ordinary node devices begin competing for the right to produce a block. Ordinary node devices compete by solving a hash puzzle. The specific method for determining whether an ordinary node device has successfully acquired the right to produce a block is as follows:

[0131] Hash(header,nonce)<target*difficulty (5)

[0132] Wherein, Hash is the hash function selected by the system, header is the block header information of the currently mined transaction block, nonce is the random number tried by ordinary node devices when solving the hash problem, target is the difficulty value specified by the current system, and difficulty is the difficulty adjustment coefficient.

[0133] When the Hash(header, nonce) calculated by a regular node device satisfies this inequality, the regular node device obtains the right to produce a block for the transaction.

[0134] S42: The difficulty adjustment factor in S41 is adjusted based on the reputation of ordinary node devices. The higher the reputation ranking of a node device, the greater the difficulty, and the lower the difficulty of the hash problem that ordinary node devices need to solve.

[0135] S43: After a regular node successfully produces a block, it broadcasts the resulting transaction block to all other nodes on the network. All nodes verify the validity of the transaction block. If valid, it is added to the transaction block pool; if invalid, the information of the regular node that produced the block is recorded, and penalties are applied at the end of the consensus process. The transaction block pool stores transaction blocks that have not yet been packaged into regular blocks.

[0136] S44: The structure of transaction blocks in this consensus mechanism is similar to the block structure in traditional blockchains. For example... Figure 4 As shown, a block consists of two parts: a block header and a block body. The block body records information about the transactions to be included in the block. The block header contains the hash of the previous block (PrevHash), the timestamp (TimeStamp), the difficulty value (target), the nonce, the difficulty adjustment factor (difficulty), and the public key N of the block producer. pk MerkleRoot (generated from the transaction information packaged in this transaction block). The transaction block structure is simple and occupies less storage space, reducing the storage pressure on node devices.

[0137] S5: All supernode devices are responsible for packaging ordinary blocks. The system randomly selects a supernode device as the producer of the current ordinary block at regular intervals. The higher the reputation of a supernode device, the higher its probability of being selected as the producer of an ordinary block. Ordinary blocks contain hash pointers that connect multiple transaction blocks, thus completing the packaging of transaction blocks into an ordinary block. The uniform speed of ordinary block generation shortens the confirmation time of information in the blockchain for node devices, significantly accelerating the data synchronization speed between node devices. Specifically, this includes the following steps:

[0138] S51: The supernode device begins producing regular blocks. Every T... IntervalAt any given time, a supernode device will be randomly selected as the block producer for that block. The higher the reputation of the supernode device, the higher the probability of it being selected as the block producer.

[0139] S52: The specific extraction method is as follows:

[0140] The percentage RP of each supernode device's reputation relative to the sum of all supernode device reputations is calculated as follows:

[0141]

[0142] Ri is the reputation value of node device i, and total is the number of supernode devices.

[0143] Each supernode device receives a range from 0 to 100 based on its RP size. For supernode device i, the range is [Li, Ri). Specifically, the range for the last supernode device is [Li, Ri]. i and R i The calculation method is as follows:

[0144]

[0145]

[0146] Specifically, when i = 1, Li is 0.

[0147] Subsequently, the supernode that previously produced a normal block calculates the Pivot random beacon. The Pivot will eventually fall within the RP (Reference Point) range of a certain supernode, granting that supernode the right to produce the next normal block. The Pivot calculation method is as follows:

[0148] pivot = VRF_Hash(PrevHash, N) sk )mod 100 (9)

[0149] PrevHash is the hash value of the previous normal block.

[0150] S53: After the supernode device finishes producing a block, it broadcasts the ordinary block to the validator node device and waits for the validator node device to verify the ordinary block.

[0151] S54: A normal block structure consists of a block header and a block body, such as... Figure 5 As shown. The block body stores the hash values ​​of the transaction blocks packaged within the regular block. Multiple transaction blocks are linked together by hash pointers, as shown in the diagram. Figure 6As shown. The block header contains the hash value PrevHash of the previous normal block, the timestamp TimeStamp, and the block producer's public key N. pk MerkleRoot (generated from the transaction block information packaged in this ordinary block). Ordinary blocks increase the reliability of data stored on node devices at the cost of extremely low network resource overhead on node devices.

[0152] S6: After a regular block is produced, it is broadcast to all validator nodes. All validator nodes check the validity of the block and vote to decide whether it can be added to the blockchain. Validator nodes with higher credibility have more votes. The voting process includes the following steps:

[0153] S61: After receiving the ordinary block sent by the supernode device, the validator node device begins to verify the legality of the ordinary block and checks whether there is any abnormal information in the ordinary block.

[0154] S62: After all validator nodes have completed their checks, they vote on the ordinary block. If the validator node deems the ordinary block valid, it casts its vote.

[0155] When a regular block receives more than half of the total votes, it passes the verification by the validator nodes and is confirmed to be included on the blockchain. Validator nodes with higher credibility hold more votes. The number of votes a validator node holds is related to its credibility ranking among all validator nodes, and the specific numbers are as follows:

[0156] Table 2

[0157] Reputation ranking vote count Top 30% 3 Top 31% - Top 60% 2 Other rankings 1

[0158] S7: After a regular block is successfully added to the blockchain, the revenue distribution is calculated using the Banzhaf rights index, which combines reputation and other factors. The specific steps include:

[0159] S71: After a regular block is added to the blockchain, the revenue is distributed. 20% of the revenue from producing a regular block is allocated to the block-producing node device, 30% is allocated to the block-producing node devices of the transaction blocks contained in the regular block, and is equally divided among all block-producing node devices. 50% of the revenue is allocated to the validator node devices in this round of consensus.

[0160] S72: The revenue allocated to validator node devices is calculated by combining the banzhaf rights index and the reputation rating value REV.

[0161] The REV (Reputation Value) of the validator node device is calculated as follows:

[0162]

[0163] Where α, β, and γ are the corresponding weight values. Ri is the reputation value of validator node device i, total is the number of validator node devices, Atotal(i) is the total number of historical behaviors of validator node device i, Abad(i) is the number of violations in the historical behavior of validator node device i, δ is the system-defined tolerable node device behavior error rate, TRCaverage is the average number of transactions initiated between validator node devices in history, and TRCaverage(i→other) is the average number of transactions initiated by validator node device i to other validator node devices in history.

[0164] The banzhaf weight index of the validator node device is calculated as follows:

[0165] A regular block is considered valid only if it receives a majority of votes from all validator nodes. When voting on the validity of a regular block, if a validator node is missing a vote, the block cannot pass the vote; in this case, that validator node is the key voter. Validator nodes cast all their votes at once, choosing to approve or disapprove the validity of the regular block. List all possible validator node voting scenarios and record the number of times validator node i becomes a key voter. i The final validator node device's banzhaf index is:

[0166]

[0167] Where total represents the total number of validator node devices.

[0168] S73: Calculate the final profit of the validator node device, as follows:

[0169] Profit i =banzhaf i *REV i *w*50% (12)

[0170] Where w is the reward for producing a normal block.

[0171] S8: After the system-defined consensus duration for this round is reached, update the node device reputation based on the node device's performance in this consensus round, and start the next consensus round, returning to step S1, which specifically includes the following steps:

[0172] S8l: The node device checks whether the consensus of the current round has reached its end time based on TRound and TimeStampcur. If the end time has been reached, the consensus mechanism enters the end phase, updates its reputation based on the behavior of the node device in this round of consensus, and starts the next round of consensus, jumping to step S1.

[0173] S82: The specific mechanism for updating reputation is as follows:

[0174] If node device i does not exhibit malicious behavior during this consensus phase, its reputation will be updated as follows:

[0175]

[0176] If node device i exhibits malicious behavior (generating incorrect blocks, forging random numbers, etc.) during this consensus phase, its reputation will be updated as follows:

[0177]

[0178] Where k is the consensus round, m is the reward coefficient, a is the reward gradient coefficient, n is the penalty coefficient, and b is the penalty gradient coefficient. Rround(i) is the percentage of node device i's reputation in the current round relative to the sum of all node device reputations, calculated as follows:

[0179]

[0180] Where Total represents the total number of all node devices.

[0181] If node device i engages in dishonest behavior during this consensus round, the deposit paid in step S1 will be forfeited; if the number of dishonest behaviors by node device i across all consensus rounds exceeds the maximum threshold A that the system can tolerate. total(i) If the number of consensus attempts reaches ×δ, the node device will be removed from the system and will no longer participate in the next round of consensus.

[0182] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A blockchain consensus method based on reputation and Banzhaf index, characterized by: The method includes the following steps: S1: Initialize the system parameters and prepare the node devices for the blockchain consensus mechanism. The initialized system parameters include: node reputation, node public and private keys, and the duration T of this consensus round. Round Normal block production interval T Interva The number of election groups M and the initial consensus timestamp of this round (TimeStamp) cur ; The node device preparation refers to the node device registering to join the blockchain network node, downloading a copy of the blockchain, synchronizing blockchain information on the local disk, and paying a deposit to the system. If the node device engages in dishonest behavior in the consensus process, the system will confiscate the deposit. The node device can be any network electronic device that deploys this consensus algorithm, including servers and personal computers. S2: Each node device will store the initial timestamp of this round of consensus. cur Combined with its own private key, it serves as a seed input to verify the random function, obtains a random number and a random number proof, calculates a classification number, and then broadcasts the generated random number, random number proof, and random classification number to all network node devices to group node devices. S3: For node devices that have been grouped, an election is held within their respective groups. The election allocates votes based on the node device's reputation value and elects super node devices, validator node devices, and ordinary node devices based on the number of votes received through group voting. S4: All ordinary node devices are responsible for packaging transaction blocks. Ordinary node devices compete for the right to produce transaction blocks by solving hash problems. The difficulty adjustment coefficient is adjusted according to the reputation to reduce the difficulty of solving the problem for high-reputation node devices and reduce the amount of intensive CPU calculations required by honest node devices. The node device that successfully produces a block broadcasts the transaction block to the entire network. All node devices in the network verify whether the transaction block is valid. If it is valid, it is put into the transaction block pool on the node device's local disk. If it is invalid, the information of the ordinary node device that violated the block production rule is recorded and penalized at the end of the consensus phase. S5: All supernode devices are responsible for packaging ordinary blocks. The system randomly selects supernode devices with high reputation as ordinary block producers every once in a while. They are responsible for packaging transaction blocks and generating ordinary blocks. Ordinary blocks connect multiple transaction blocks through hash pointers to complete the packaging of transaction blocks by ordinary blocks. S6: After a regular block is produced, it is broadcast to all validator node devices. All validator node devices check the legality of the regular block and vote. If the regular block receives more than half of the total votes, the regular block passes the verification of the validator node devices and is confirmed to be able to be added to the chain. Among them, validator node devices with higher credibility have more votes. S7: After a regular block is successfully added to the blockchain, the revenue distribution is calculated using the Banzhaf rights index, which combines reputation. S8: When the system-defined consensus duration for this round ends, update the node device reputation based on the performance of the node device in this round of consensus, start the next round of consensus, and return to step S1.

2. The blockchain consensus method based on reputation and Banzhaf index according to claim 1, characterized in that: S2 specifically includes the following steps: S21: All nodes in the network will use the initial timestamp of this round of consensus. cur and the private key N of the node device sk As initial parameters, a verifiable random function (VRF) is input to calculate a random number VRF_Group, a random proof (Proof), and a random classification number (GroupNumber); the calculation method is as follows: （1） （2） （3） The node then broadcasts VRF_Group, Proof, and GroupNumber to all other nodes in the network. S22: After receiving VRF_Group, Proof and GroupNumber from other node devices, the node device uses the verification function VRF_Verify, which verifies the random function, to verify it. Based on the return value of Flag, it determines whether the random group number is valid. Flag is calculated as follows: （4） Where, N pk This is the public key of the message sender; If Flag returns true, the message sender honestly generated VRF_Group, and then calculates whether the message sender's group number GroupNumber is true; S23: After all network nodes verify the correctness of the messages, each node obtains its own GroupNumber and is assigned to the corresponding group.

3. The blockchain consensus method based on reputation and Banzhaf index according to claim 1, characterized in that: S3 specifically includes: The higher the reputation of a node device, the more votes it will receive in the group election. The specific number of votes depends on the reputation ranking. For example, if the reputation ranking is in the top 30%, the number of votes is 3; if the reputation ranking is in the top 31% to top 60%, the number of votes is 2; and if it is any other ranking, the number of votes is 1. The reputation ranking refers to the reputation ranking of the node device among all node devices. Node devices vote among themselves within their groups, and their roles in this round of consensus are determined by the number of votes they receive. The node device with the most votes becomes the super node device, the second most becomes the validator node device, and the rest are ordinary node devices.

4. The blockchain consensus method based on reputation and Banzhaf index according to claim 1, characterized in that: S4 specifically includes the following steps: S41: Ordinary node devices begin competing for the right to produce a block. Ordinary nodes compete by solving a hash puzzle. The specific method for determining whether an ordinary node device has successfully obtained the right to produce a block is as follows: （5） Where Hash is the hash function selected by the system, header is the block header information of the currently mined transaction block, nonce is the random number tried by ordinary nodes when solving the hash problem, target is the difficulty value specified by the current system, and difficulty is the difficulty adjustment coefficient. When the Hash(header, nonce) calculated by a regular node device satisfies this inequality, the regular node device obtains the right to produce a block of the transaction. The difficulty adjustment coefficient is adjusted according to the reputation of ordinary node devices. The higher the reputation ranking of ordinary node devices, the greater the difficulty, and the lower the difficulty of the hash problem that ordinary node devices need to solve. S42: After a regular node device successfully produces a block, it broadcasts the produced transaction block to other node devices across the network. All node devices across the network verify whether the transaction block is valid. If it is valid, it is placed into the transaction block pool on the node device's local disk. If it is invalid, the information of the regular node that violated the block production rule is recorded and penalized during the consensus phase. The transaction block pool stores transaction blocks that have not yet been packaged by regular blocks. In this consensus mechanism, the structure of a transaction block is similar to that of a block in a traditional blockchain. A block consists of a block header and a block body. The block body records information about the transactions to be packaged in the block. The block header contains the hash (PrevHash) of the previous transaction block, the timestamp (TimeStamp), the difficulty value (target), the nonce, the difficulty adjustment factor (difficulty), and the public key (N) of the block producer. pk MerkleRoot is generated from the transaction information packaged in this transaction block and the hash of this transaction block, TransactionBlockHash.

5. The blockchain consensus method based on reputation and Banzhaf index according to claim 1, characterized in that: In S5, all supernode devices are responsible for packaging ordinary blocks. The system randomly selects supernode devices with high credibility as ordinary block producers at regular intervals, and these producers are responsible for packaging transaction blocks and generating ordinary blocks. This increases the credibility of information on the blockchain and provides a large number of node devices in an open network environment with consistent and highly authentic shared data. Ordinary blocks connect multiple transaction blocks through hash pointers, completing the packaging of transaction blocks into ordinary blocks. Specifically, this includes the following steps: S51, The supernode device begins producing regular blocks, every T... Interval At any given time, a supernode device will be randomly selected as the block producer for this ordinary block. The higher the reputation of the supernode, the higher the probability of it being selected as the block producer. The specific extraction method is as follows: The percentage RP of each supernode device's reputation relative to the sum of all supernode device reputations is calculated as follows: （6） Among them, R i Let be the reputation value of node device i, and total be the number of supernode devices; Each supernode device will obtain an interval from 0 to 100 based on its own RP size. For supernode device i, the obtained interval range is [Li, Ri), and for the last supernode device, the interval range is [Li, Ri]. i and R i The calculation method is as follows: （7） （8） When i=1, L i =0; Subsequently, the supernode device that previously produced a normal block calculates the random beacon Pivot. If the Pivot falls within the RP range of a certain supernode device, that supernode device gains the right to produce the next normal block. The Pivot is calculated as follows: （9） Where PrevHash is the hash value of the previous normal block. The private key of the node device; S52: After the supernode device finishes producing a block, it broadcasts the ordinary block to the validator node device and waits for the validator node device to verify the ordinary block. A regular block structure consists of a block header and a block body. The block body stores the hash values ​​of the transaction blocks packaged within that regular block. Regular blocks connect multiple transaction blocks using hash pointers. The block header contains the hash value of the previous regular block (PrevHash), a timestamp (TimeStamp), and the block producer's public key (N). pk MerkleRoot is generated from the transaction block information packaged in this ordinary block and the hash of this ordinary block.

6. The blockchain consensus method based on reputation and Banzhaf index according to claim 1, characterized in that: S6 specifically includes the following steps: S61: After receiving the ordinary block sent by the supernode device, the validator node begins to verify the legality of the ordinary block and checks whether there is any abnormal information in the ordinary block; S62: After all validator node devices have finished checking, they vote on the ordinary block. If the validator node device believes that the ordinary block has passed the verification, it casts a vote. Once a regular block receives more than half of the total number of votes, it is verified by the validator node device and confirmed to be eligible for blockchain upload. Validator nodes with higher credibility have more votes. The number of votes a validator node holds is related to its credibility ranking among all validator nodes. Specifically, if its credibility ranking is in the top 30%, it receives 3 votes; if its credibility ranking is in the top 31% to top 60%, it receives 2 votes; and if its ranking is otherwise, it receives 1 vote. The credibility ranking refers to the node's credibility ranking among all nodes.

7. The blockchain consensus method based on reputation and Banzhaf index according to claim 1, characterized in that: S7 specifically includes the following steps: S71: After a regular block is added to the blockchain, the revenue is distributed as follows: 20% of the revenue from producing a regular block is distributed to the block-producing node device of that regular block, 30% of the revenue is distributed to the block-producing node devices of the transaction blocks contained in that regular block, and is divided equally among all block-producing nodes; 50% of the revenue is distributed to the validator node devices in this round of consensus. S72: The revenue allocated to validator node devices is calculated by combining the banzhaf weight index and the reputation evaluation value REV, as follows: The REV (Reputation Value) of the validator node device is calculated as follows: （10） Where α, β, and γ are the corresponding weight values, and R i Let A be the reputation value of validator node i, and let total be the number of validator nodes. total(i) A represents the total number of historical actions of validator node i. bad(i) Let δ be the number of times validator node i has committed a violation in its historical behavior, and let TRC be the system-defined tolerable node behavior error rate. average TRC is the average number of transactions initiated between validator nodes throughout history. average(i→other) This represents the average number of transactions that validator node i has initiated to other validator nodes throughout history. The banzhaf weight index of the validator node device is calculated as follows: A regular block is considered valid after receiving a majority of votes from all validator node devices. During the vote on the validity of a regular block, if a validator node device is missing a vote, the block cannot pass the vote. This validator node device is then considered the key voter in that voting situation. Validator node devices cast all their votes at once, choosing to approve or disapprove the validity of the regular block. All validator node voting results are listed, and the number of times validator node device i has been a key voter is recorded (key). i The final validator node device's banzhaf index is: （11） Where total represents the total number of validator node devices; The final profit of the validator node device is calculated as follows: （12） Where w is the reward for producing a normal block.

8. The blockchain consensus method based on reputation and Banzhaf index according to claim 1, characterized in that: Specifically, S8 is: Node devices according to T Round and TimeStamp cur Check if the consensus of the current round has reached the end time. If it has, the consensus mechanism enters the end phase, updates the reputation of the node device according to the behavior of the node device in this round of consensus, and starts the next round of consensus, then jumps to step S1. The specific mechanism for updating reputation is as follows: If node device i does not exhibit malicious behavior during this consensus phase, its reputation will be updated as follows: （13） If node device i exhibits malicious behavior during this consensus phase, including generating incorrect blocks and forging random numbers, its reputation will be updated as follows: （14） Where k is the consensus round, m is the reward coefficient, a is the reward gradient coefficient, n is the penalty coefficient, b is the penalty gradient coefficient, and R... round(i) Let be the percentage of node i's reputation relative to the sum of all nodes' reputations in the current round, calculated as follows: （15） Where Total is the total number of nodes; If node device i engages in dishonest behavior during this consensus round, the deposit paid in step S1 will be forfeited; if the number of dishonest behaviors by node device i across all consensus rounds exceeds the maximum threshold that the system can tolerate. If the node is removed from the system, it will no longer participate in the next round of consensus.

Images