A consensus method based on credit value power separation and balance suitable for a crowdsourcing system

Abstract

The application discloses a consensus method based on credit value power distribution balance suitable for a crowdsourcing system, adopts a hybrid blockchain architecture, and divides a blockchain network into an open network and a consensus network; ordinary nodes in the open network are engaged in transaction activities, and only have the right to check information on the blockchain; the ordinary nodes are divided into service providers and consumers according to the supply and demand relationship of services; the ledger management nodes of the consensus network are responsible for updating and maintaining the blockchain; the ledger management nodes are divided into verifiers responsible for transaction verification and block verification and leaders responsible for block packaging and block updating according to a credit value model. The consensus protocol mainly completes a consensus activity through four steps, namely, obtaining a consensus list, verifying a transaction group, verifying a block, and four steps of incentive and punishment. The consensus protocol proposed in the application can be applied to the crowdsourcing system, and can well solve the single-point failure problem and the unfair problem faced by the traditional crowdsourcing.

Description

Technical Field

[0001] This invention belongs to the field of blockchain and relates to a consensus method based on reputation value-based power-balancing applicable to crowdsourcing systems. Background Technology

[0002] Crowdsourcing, as a new business model, has made the internet service industry feasible. People can seek or provide services through crowdsourcing platforms, and the immediacy of internet communication allows for rapid connection between these needs and offerings. However, traditional crowdsourcing applications are generally built on a centralized structure, which limits the development of crowdsourcing systems while also constraining them. This is mainly reflected in two aspects: First, the problem of single point of failure. Crowdsourcing platform user data relies on a centralized database. Once the server crashes or is attacked, users will be unable to use the crowdsourcing service, and user privacy may be compromised. Second, fairness. When disputes arise between service providers and consumers, they rely on the subjective arbitration solution provided by the crowdsourcing platform. If the arbitration favors the consumer, the consumer can exploit this mechanism to steal the service provider's ideas without paying. If the arbitration favors the service provider, the service provider can obtain payment by providing no service or inferior service. Blockchain technology solves the problems faced by traditional crowdsourcing platforms. Deploying crowdsourcing applications on the blockchain and changing the centralized architecture to a distributed architecture effectively solves both the service paralysis problem caused by single point of failure and the unfairness caused by centralization.

[0003] Existing research on applying blockchain technology to crowdsourcing systems at the consensus layer mainly falls into two categories:

[0004] One is PoofofTrust [1] This type of protocol, characterized by separating the right to choose a transaction from the right to include it in a block, assigns these roles to different entities. It utilizes a pre-designed trust value model to calculate the trust value of each node, thus differentiating roles. Typically, the node with the highest trust value is the Leader, primarily responsible for including blocks, while the rest are validators, mainly responsible for verifying transactions and blocks. However, this protocol delegates the right to choose and verify transactions to nodes in an open network, without any incentives or penalties to constrain these consensus-participating nodes, which can easily lead to privacy breaches related to transactions.

[0005] Another one is zkCrowd [2]The dual-chain architecture, exemplified by zkCrowd, comprises a public chain and a private chain. The private chain stores sensitive user information and uses consensus protocols such as PBFT to generate blocks, which are then uploaded to the public chain using zero-knowledge proofs. The public chain then employs traditional consensus methods to confirm the transactions involved in new blocks. This approach reduces user privacy concerns through the private chain and a small number of consensus nodes. However, in practice, the dual-chain structure becomes increasingly time-consuming to generate a single block as the number of transactions increases, failing to adequately meet the real-time requirements of crowdsourcing systems. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention proposes a consensus method based on reputation-based power-balancing suitable for crowdsourcing systems. This method employs a hybrid blockchain architecture, dividing the blockchain network into an open network and a consensus network. Nodes in the open network engage in transaction activities and only have viewing rights to information on the blockchain; these are called ordinary nodes. Nodes in the consensus network are responsible for updating and maintaining the blockchain; these are called ledger management nodes. The open network is divided into service providers and consumers based on the supply and demand relationship of services. Ledger management nodes in the consensus network are divided into two roles based on a reputation-based model: verifiers responsible for transaction and block verification, and leaders responsible for block packaging and updates.

[0007] The consensus method based on reputation value-based power-sharing proposed in this invention utilizes a consensus mechanism based on reputation value-based power-sharing. The implementation process of the consensus method includes (unless otherwise specified, in the following description of the consensus mechanism, the node referred to only represents the ledger management node, and the verifier and verifier node, leader and leader node refer to the same object):

[0008] Step 1: Each ledger management node collects relevant data related to reputation score calculation from all ledger management nodes, including itself;

[0009] Step 2: Calculate the reputation value of all ledger management nodes according to the reputation value model to obtain the consensus node list for the current round, which includes all ledger management nodes. The node with the highest reputation value is the leader node, and the remaining nodes become validator nodes. The reputation value model refers to a model that integrates multiple reputation value calculation methods to calculate the final reputation value.

[0010] Step 3: The validator node selects a set of transactions from the transaction pool, verifies them successfully, and then sends them to the leader node;

[0011] Step 4: The leader packages the successfully verified transactions into a new block, and then broadcasts the new block to the validator nodes for verification.

[0012] Step 5: The leader updates the blockchain with the successfully verified blocks, completing one consensus activity and resetting the protocol state.

[0013] This invention proposes a consensus method based on reputation value-based power-balancing applicable to crowdsourcing systems. In step one, the ledger management node needs to collect the following data: the deposit D paid by the node, the incentive I obtained by the node from the consensus activity, and the service evaluation table FBScore obtained by ordinary nodes as service providers. provider ={fb1,fb2,…fb m}, The consumer behavior evaluation table FbScore obtained by ordinary nodes as consumers consumer ={fb1,fb2,…fb m The nodes have participated in consensus activities, and this includes the number of successful transactions (m) and the number of failed transactions (n) (if a new block is successfully generated, it is considered one successful transaction; otherwise, it is considered one failed transaction). The service evaluation table is generated as follows: after a service provider completes its service, it receives service evaluations from consumers. All service evaluations from transactions form a service evaluation table. The service evaluation refers to a rating given by a consumer to their service provider from 0 to k after a transaction is completed; this rating is represented by the service evaluation table FBScore. provider Evaluation score fb m ∈0…k. Similarly, after a consumer completes a transaction and evaluates the service, the service provider will score the consumer's behavior from 0 to k. The scores of all transactions form a consumer behavior evaluation table, i.e., FBScore. consumer .

[0014] This invention proposes a consensus method based on reputation value-based power-balancing applicable to crowdsourcing systems. In step two, the step of generating the consensus node list is as follows:

[0015] Step 2.1: Each ledger management node calculates the reputation value of all ledger management nodes, including itself, and ranks them according to their reputation values ​​to obtain a consensus node list. After the list is obtained, if node i has the highest reputation value, then node i becomes the leader, signs the list, and broadcasts it to other ledger management nodes. The other ledger management nodes then wait for the list sent by node i.

[0016] Step 2.2: After receiving the list, other ledger management nodes compare it with a consensus node list calculated locally. If they match, they broadcast a list confirmation message; otherwise, they discard the list.

[0017] Step 2.3: All ledger management nodes count the list confirmation messages transmitted over the network. If the number of messages collected within the timeout period exceeds two-thirds of the number of ledger management nodes, the list is considered valid; otherwise, the view switching protocol is triggered.

[0018] View switching is the handling state when a protocol enters an abnormal state. Its main purpose is to confirm whether the consensus cluster can regain consensus after the abnormality occurs. List confirmation, on the other hand, is a state in which the protocol is functioning normally. These two messages represent different states. View switching is used in common consensus protocols such as PBFT and RAFT.

[0019] A view switch will be triggered when the number of list confirmation messages does not exceed 2 / 3 of the number of ledger management nodes.

[0020] The present invention proposes a reputation-based decentralized consensus method suitable for crowdsourcing systems. Step 2.1, which calculates the reputation value of a single ledger management node, is as follows:

[0021] Step 2.1.1: Calculate the reputation value obtained by each ledger management node from wealth according to the wealth and reputation conversion formula. It mainly considers the deposit paid by the node and the incentive obtained through consensus activities. The calculation method is M(t)=sigmod(σlog(D+I)), where σ is the conversion factor, D is the deposit paid by the node, and I is the incentive obtained by the node.

[0022] Step 2.1.2: Based on the two evaluation tables (service evaluation table and consumer behavior evaluation table) generated by the ledger management nodes in transaction activities, calculate the positive feedback evaluation α and negative feedback evaluation β for each node. The service evaluation table or consumer behavior evaluation table {fb1, fb2, ... fb} of the nodes is known. m The fraction fb in} i If ∈[1,k], i∈[1,m], if This explains the node's evaluation in this transaction (fb). i It is a positive evaluation, which is recorded in a set P, resulting in P = {fb1, fb2, ..., fb}. s}, and then through calculation Obtain the positive feedback evaluation α of the current node. (t) ;if This explains the node's evaluation in this transaction (fb). i Negative evaluations are recorded in a set N, resulting in N = {fb1, fb2, ..., fb}. m-s}, and then through calculation Obtain the negative feedback evaluation β of the current node. (t) Positive feedback evaluation based on the two evaluation forms. and negative feedback evaluation The reputation value gained by a node through transaction activities in the current round is calculated as follows: Where k i The feedback weights of the two evaluation forms are represented by k1 = k2 = 0.5 in actual processing, and PR is the penalty factor (PR > 1).

[0023] Step 2.1.3: Based on the number of successful and failed attempts by the ledger management node in consensus activities, calculate the reputation value obtained by the node through consensus activities. The calculation method is as follows: Where m is the number of successful consensus activities that the node has participated in, n is the number of failed consensus activity verifications that the node has participated in, and PR represents the penalty factor (PR>1);

[0024] Step 2.1.4: Based on the three reputation values ​​generated in steps 2.1.1-2.1.3, calculate the node's final reputation value using the following formula: A node's reputation value depends more on its performance in transaction and consensus activities, so the weights should conform to the formula w2 = w3 > w1.

[0025] The present invention proposes a consensus method based on reputation value-based weighted checks and balances applicable to crowdsourcing systems. Step 2.3 involves the following steps during the view switching protocol:

[0026] Step 2.3.1: The ledger management node currently participating in the consensus activity sends a view switching message to all ledger management nodes except itself;

[0027] Step 2.3.2: If, within the timeout period, all ledger management nodes collect more than two-thirds of the view switching messages, the current view number is incremented by one; otherwise, the protocol state is reset and the view number is restored to its default value.

[0028] The present invention proposes a consensus method based on reputation value-based weighted checks and balances applicable to crowdsourcing systems. In step three, the verifier's verification of the transaction is as follows:

[0029] Step 3.1: The node with the highest reputation value among the validators (i.e., the node with the second highest reputation value among all ledger management nodes in the current round) is responsible for selecting a set of transactions from the transaction pool, signing it, and broadcasting it to other validator nodes;

[0030] Step 3.2: After receiving the group of transactions, other validator nodes check each transaction and perform transaction pre-execution. The purpose of transaction pre-execution is to generate corresponding transaction receipts. If the generated receipts are consistent with the number of transactions, the signatures of the transaction group initiating node and other validators are checked in turn. If they are all correct, it means that the transaction group has been successfully verified, and a transaction verification success message is sent to other validator nodes.

[0031] Step 3.3: If the number of successful transaction verification messages received by the validator node exceeds two-thirds of the current consensus node list, it means that the group of transactions has been successfully verified and sent to the leader node. If not enough successful transaction verification messages are received within the timeout period, the view switching protocol is triggered.

[0032] The present invention proposes a consensus method based on reputation value-based weighted checks and balances applicable to crowdsourcing systems. In step four, the block verification step is as follows:

[0033] Step 4.1: Check if the block creator's signature is correct. If it is incorrect, discard the block and do not broadcast it. If it is correct, proceed to the next step.

[0034] Step 4.2: Check if the list of signed validators is on the locally generated list. If not, discard the block without broadcasting. If all validators are on the list, sign the block and broadcast the block confirmation message to the network.

[0035] Step 4.3: During the timeout period, the leader checks whether enough block confirmation messages have been received. If the number exceeds two-thirds of the current consensus node list, it means that the block verification was successful; otherwise, the view switching protocol is triggered.

[0036] Step five also includes an incentive and penalty mechanism. When the leader submits a new block to the blockchain and executes a transaction, updating the result of the transaction execution to the local database, other ledger management nodes download the latest block from the leader node and update it locally. If the new block is successfully updated locally, the current round of consensus activity is considered successful, and all participating nodes receive an incentive based on their contribution, provided from a prize pool maintained by the system. If any action during protocol execution causes a block submission failure, the current round of consensus activity is considered a failure, and all participating nodes are penalized by collecting a portion of their deposit, which is deposited into the prize pool maintained by the system.

[0037] The communication between nodes in this invention is based on the IPFS communication protocol.

[0038] In this invention, "verifier" and "verifier node", "leader" and "leader node" can be used interchangeably.

[0039] The beneficial effects of this invention include: The consensus method proposed in this invention adopts the ProofofTrust model, which separates the right to choose transactions from the right to package blocks. However, it does not delegate the right to choose transactions and the verification work to trusted ordinary nodes in the open network, but rather the nodes of a small-scale consensus network are responsible for this. This can effectively reduce the exposure of privacy issues involved in transactions in the open network. The hybrid blockchain architecture adopted in this invention divides nodes into two networks, requiring only one chain to be maintained. Compared with the dual-chain structure of zkCrowd, the time required to generate a new block is significantly reduced. Experimental results show that when the number of transactions to be packaged is 1500, the time required to generate a new block under the dual-chain structure of zkCrowd is 40.0 seconds, while the consensus method proposed in this invention only takes 4.5 seconds. This invention proposes a new reputation value model, which affects the reputation performance of nodes by quantifying node transaction behavior, thereby further constraining the performance of nodes in consensus activities. This invention designs an incentive system and a penalty system, which encourage nodes to actively participate in consensus activities while preventing malicious behavior by nodes. Attached Figure Description

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

[0041] Figure 1 This is the overall architecture diagram of the crowdsourcing system designed in this invention.

[0042] Figure 2 This is a diagram of the communication protocol used in this invention.

[0043] Figure 3 This is the state machine diagram of the consensus protocol of this invention.

[0044] Figure 4 This is a schematic diagram illustrating the process of obtaining the consensus list in this invention.

[0045] Figure 5 This is a schematic diagram of the transaction verification process of this invention.

[0046] Figure 6 This is a schematic diagram of the block verification of the present invention.

[0047] Figure 7 This is a diagram showing the experimental simulation results of the present invention.

[0048] Figure 8 This is a flowchart of the consensus method based on reputation value-based power-sharing and checks and balances in this invention. Detailed Implementation

[0049] The invention will be further described in detail below with reference to the specific embodiments and accompanying drawings. Except for the contents specifically mentioned below, the processes, conditions, and experimental methods for implementing the invention are all common knowledge and general knowledge in the art, and the invention does not have any particular limitations.

[0050] The method described in this invention employs a hybrid blockchain architecture, dividing the blockchain network into an open network and a consensus network. Nodes in the open network engage in transaction activities and have only viewing permissions for information on the blockchain; these are called ordinary nodes. Ordinary nodes are further categorized into service providers and consumers based on the supply and demand of services. Nodes in the consensus network are responsible for updating and maintaining the blockchain; these are called ledger management nodes. Ledger management nodes are further divided into verifiers responsible for transaction and block verification, and leaders responsible for block packaging and updates, based on a reputation value model. The consensus protocol primarily completes a consensus activity through four steps: obtaining the consensus list, verifying transaction groups, verifying blocks, and implementing incentives and penalties. In this invention, only one leader is generated per round of consensus activity, and blocks are generated by the leader node. This avoids block forking issues. Furthermore, the verification of transactions and blocks is delegated to verifier nodes selected based on reputation values, effectively preventing unfairness. When applied to crowdsourcing systems, the consensus protocol proposed in this invention can effectively solve the single point of failure and unfairness problems faced by traditional crowdsourcing.

[0051] This invention addresses the consensus problem in crowdsourcing systems deployed on blockchain, specifically as shown in the appendix. Figure 1 As shown, the crowdsourcing system's data is deployed in a semi-open blockchain with Byzantine fault tolerance (BFT) nodes. Blockchain maintenance is primarily handled by the ledger management node. Ordinary crowdsourcing nodes can only read the blockchain data, and the identities of ordinary nodes and ledger management nodes can interchange. In such a semi-open environment, how to avoid BFT while simultaneously meeting the crowdsourcing system's requirements for low transaction latency, node scalability, and fairness in consensus activities is a pressing issue. This invention designs a reputation value model to determine the influence of the ledger management node in consensus activities, primarily considering three factors that measure the reputation value of the ledger management node:

[0052] (1) First, there's the reputation value derived from the deposit paid by the ledger management node to the platform and the incentives earned from participating in consensus activities. Unlike traditional consortium blockchains, the nodes responsible for maintaining the blockchain are not limited to a fixed cluster. Ordinary nodes in an open network can apply to become ledger management nodes by paying a deposit, thereby participating in consensus activities. Paying a deposit to participate in consensus can prevent ledger management nodes from acting maliciously, as they must consider the cost of such actions. On the other hand, including the incentives earned by ledger management nodes in consensus activities as part of the reputation value measurement can encourage them to actively participate in consensus. Simultaneously, the sigmoid function is used to limit the reputation value derived from the conversion of funds, preventing power from concentrating in the hands of the wealthy.

[0053] (2) Secondly, the interaction factors of the ledger management nodes in the crowdsourcing activity not only consider the subjective evaluation of consumers to service providers, but also the evaluation of consumers' consumption behavior by service providers. The two are mutually restrictive. For newly joined ledger management nodes, the historical evaluation formed by the node in the crowdsourcing activity is considered. This can allow them to obtain some reputation value, thus giving them a better chance to participate in consensus activities and preventing them from being at the edge of the consensus cluster due to their new identity.

[0054] (3) Finally, there is the performance of the ledger management node in consensus activities. The more successful consensus activities a node participates in, the better its reputation score will be. Considering the performance of nodes in consensus activities serves two purposes: firstly, to encourage nodes to actively participate in consensus activities; and secondly, to limit newly joined ledger management nodes from being in an advantageous position in the consensus cluster due to their new status (i.e., having a greater chance to participate in consensus activities), since newly joined ledger management nodes do not have this part of their reputation score.

[0055] In the specific implementation process, communication between nodes adopts an IPFS-based communication protocol, as shown in the attached diagram. Figure 2As shown in the diagram, the left figure illustrates that nodes N1, N2, N3, and N4 on the open network must first establish a connection with the bootstrap node before they can discover other nodes on the network and establish communication with them. The right figure shows that once nodes establish a connection, they can communicate directly without relying on the bootstrap node. The ledger management node on the consensus network contains the IPFS addresses of all nodes and does not need to establish a connection through the bootstrap node; it only needs to obtain the latest information about the ledger management node through the bootstrap node. Furthermore, the IPFS address of the ledger management node is publicly available throughout the open network, and ordinary nodes can directly connect to the corresponding ledger management node via the IPFS address. In addition, to better maintain the list of ledger management nodes, the functionality of the bootstrap node has been further improved in this invention. The bootstrap node is not only responsible for establishing connections throughout the open network but also for recording the information of each ledger management node.

[0056] In this invention, to better distinguish the asset issues involved in consensus activities and crowdsourcing activities, assets are further subdivided into current assets and fixed assets. Current assets are funds that can be traded in crowdsourcing transactions, while fixed funds (deposits and incentives obtained from participating in consensus activities) cannot be traded through crowdsourcing transactions and are only used to measure the reputation value of ledger management nodes. Fixed funds can be converted into current funds, but a certain amount of transaction fees must be paid.

[0057] In this invention, to better implement the reward and punishment mechanism, a reward pool maintained by all ledger management nodes is designed. Funds flowing into the reward pool include transaction fees, forfeited deposits from defaulting ledger management nodes, and incentives obtained from consensus activities.

[0058] In this invention, since the protocol adopts the PBFT voting method, according to existing research, the number of nodes in PBFT is between 16 and 32 to avoid the impact of communication overhead on consensus efficiency. Therefore, when the protocol is executed, the number of ledger management nodes participating in consensus is set to 16 each time.

[0059] The consensus method designed in this invention is as follows: Figure 3 As shown, a consensus activity mainly includes four steps: generating the consensus list, verifying transactions, verifying blocks, and incentivizing / penalizing transactions. Below, each step is explained in detail (the nodes referred to below all represent ledger management nodes):

[0060] (1) Generation of consensus list

[0061] Each ledger management node periodically obtains the latest list of ledger management nodes from the bootstrap node. After obtaining the list, it checks whether the nodes on the list are consistent with the locally maintained list. If there are any changes, the locally maintained list is updated.

[0062] In each round of consensus activities, each ledger management node calculates the reputation value of all ledger management nodes according to the reputation value model, and then sorts the nodes according to the size of the reputation value, as shown in the appendix. Figure 4 As shown, if the current node has the highest reputation value, it signs the list containing the reputation value and broadcasts it to other ledger management nodes. Upon receiving the list, other nodes compare it with their locally calculated list. If the lists match, they broadcast a list confirmation message. If more than two-thirds of the ledger management nodes receive list confirmation messages, the list is considered valid. Each node then uses this list to determine the leader and validators for this round of consensus activities.

[0063] (2) Transaction verification

[0064] As attached Figure 5 As shown, the node with the highest reputation among the validators is responsible for selecting a group of transactions from the transaction pool, signing the transaction group, and broadcasting it. When other validators receive the transaction group, they first check the legality of each transaction, perform pre-execution operations, and if the corresponding accounts exist and the amount involved in the transaction can be successfully deducted from the consumer's account, a transaction receipt is generated. If the number of transactions and the number of transaction receipts are the same, it means that the selected group of transactions is legal. Then, the signature of the initiating node of the transaction group is checked for correctness. If correct, the signatures of other validators are checked for correctness. If correct, a transaction confirmation message is broadcast to other validator nodes. If a validator node receives transaction confirmation messages from more than two-thirds of the consensus list, it means that the currently selected group of transactions can be packaged into a block.

[0065] (3) Block verification

[0066] like Figure 6 As shown, the leader node packages successfully verified transactions into a new block. During the packaging process, the leader node also performs a pre-execution operation on each transaction and packages the transaction receipt generated by the pre-execution operation along with the transaction into the block. After successful packaging, the block is broadcast to the validator nodes for secondary verification. Upon receiving the block, the validator verifies the block's hash value. If the verification is successful, a block confirmation message is sent. During the block verification timeout period, the leader continuously checks whether the received block confirmation messages exceed two-thirds of the current consensus list nodes. If so, the leader considers the block valid and submits it to the blockchain.

[0067] (4) Incentives and Punishments

[0068] The leader submits a new block to the blockchain and executes the transaction, updating the result to its local database. Other ledger management nodes download the latest block from the leader node and update it locally. If the new block is successfully updated locally, the current round of consensus activity is considered successful, and all participating nodes receive an incentive based on their contribution, provided from a system-maintained reward pool. If any action during protocol execution causes a block submission failure, the current round of consensus activity is considered a failure, and all participating nodes are penalized by collecting a portion of their deposit, which is then deposited into the system-maintained reward pool.

[0069] Figure 7 Based on the experimental simulation results, the ledger management node size was set to 16. It can be seen that when the transaction volume is small, the time taken for the consensus method proposed in this invention and the two-chain structure zkCrowd to generate a block is not much different. However, when the transaction volume increases, the time taken for zkCrowd to generate a block increases significantly. For example, when the transaction volume is 1500, zkCrowd takes 40.0 seconds to generate a block, while the consensus method proposed in this invention only takes 4.5 seconds. This shows that the consensus protocol proposed in this invention can better meet the timeliness requirements of crowdsourcing systems.

[0070] The references cited in this invention are:

[0071] [1] J.Zou, B.Ye, L.Qu, Y.Wang, MAOrgun, and L.Li, "A Proof-of-TrustConsensus Protocol for EnhancingAccountability in Crowdsourcing Services," IEEE Trans.Serv.Comput., vol.12, no.3, pp.429–445, May 2019,doi:10.1109 / TSC.2018.2823705.

[0072] [2] S.Zhu, H.Hu, Y.Li, and W.Li, "Hybrid Blockchain Design for PrivacyPreserving Crowdsourcing Platform," in 2019 IEEE International Conference onBlockchain (Blockchain), Atlanta, GA, USA, Jul.2019, pp.26–33.doi:10.1109 / Blockchain.2019.00013.

[0073] The scope of protection of this invention is not limited to the above embodiments. Any variations and advantages that can be conceived by those skilled in the art without departing from the spirit and scope of the inventive concept are included in this invention and are protected by the appended claims.

Claims

1. A consensus method based on reputation value-based power-balancing applicable to crowdsourcing systems, characterized in that, The method employs a hybrid blockchain architecture, dividing the blockchain network into an open network and a consensus network. Nodes in the open network engage in transaction activities and have only access to information on the blockchain; these are called ordinary nodes. Ordinary nodes are further divided into service providers and consumers based on the supply and demand of services. Nodes in the consensus network are responsible for updating and maintaining the blockchain; these are called ledger management nodes. Ledger management nodes are further divided into verifiers responsible for transaction verification and block verification, and leaders responsible for block packaging and updating, based on a reputation value model. The consensus method includes the following steps: Step 1: Each ledger management node collects relevant data related to reputation score calculation from all ledger management nodes, including itself; Step 2: Calculate the reputation value of all ledger management nodes according to the reputation value model to obtain the consensus node list for the current round, which includes all ledger management nodes. The node with the highest reputation value becomes the leader node, and the remaining nodes become validator nodes. The steps for generating the consensus node list in step two are as follows: Step 2.1: Each ledger management node calculates the reputation value of all ledger management nodes and arranges them according to the reputation value to obtain a consensus node list. After obtaining the list, if node i has the highest reputation value, then node i becomes the leader, and node i signs the list and broadcasts it to other ledger management nodes. Other ledger management nodes then wait for the list sent by node i. The step 2.1 described above for calculating the reputation value of a single ledger management node is as follows: Step 2.1.1: Based on the wealth and reputation conversion formula, calculate the reputation value that each ledger management node gains from wealth. The calculation method is as follows: ,in As the conversion factor, D is the deposit paid by the ledger management node, and I is the incentive received by the ledger management node; Step 2.1.2: Based on the service evaluation forms and consumer behavior evaluation forms generated by the ledger management nodes in transaction activities, calculate the positive feedback evaluation for each node. and negative feedback evaluation Service evaluation form or consumer behavior evaluation form for nodes fractions in ,if This indicates the node's evaluation in the formation of this transaction. It is a positive evaluation, which is recorded in a set P, and thus... ,calculate To obtain positive feedback evaluation of the current node. ;if This indicates the node's evaluation in the formation of this transaction. Negative evaluations are recorded in a set N, resulting in... ,calculate The negative feedback evaluation of the current node is obtained. ; Positive feedback evaluation based on the two evaluation forms and negative feedback evaluation The reputation value gained by a node through transactions in the current round is calculated as follows: ,in Represents the feedback weights of the two evaluation forms, PR is the penalty factor, PR > 1; Step 2.1.3: Based on the number of successful and failed attempts by the ledger management node in consensus activities, calculate the reputation value obtained by the node through consensus activities. The calculation method is as follows: ,in This represents the number of successful consensus activities in which the node participates. The number of failed verification attempts for node consensus activities; PR is the penalty factor, where PR >

1. Step 2.1.4: Based on the three reputation values ​​generated in steps 2.1.1-2.1.3, calculate the node's final reputation value using the following formula: Weight ; Step 2.2: After receiving the list, other ledger management nodes compare it with a consensus node list calculated locally. If they match, they broadcast a list confirmation message; otherwise, they discard the list. Step 2.3: Each ledger management node counts the list confirmation messages transmitted over the network. If the number of messages collected within the timeout period exceeds two-thirds of the number of ledger management nodes, the list is considered valid; otherwise, the view switching protocol is triggered. Step 3: The validator node selects a set of transactions from the transaction pool, verifies them successfully, and sends them to the leader node. Step 4: The leader packages the successfully verified transactions into a new block, and then broadcasts the new block to the validator nodes for verification. Step 5: The leader updates the blockchain with the successfully verified blocks, completing one consensus activity and resetting the protocol state.

2. The consensus method as described in claim 1, characterized in that, The data that the ledger management node needs to collect in step one includes: the deposits paid by the ledger management node. Incentives obtained by ledger management nodes from consensus activities Service evaluation form obtained by ordinary nodes as service providers Ordinary nodes serve as consumer behavior evaluation forms obtained by consumers. The number of times the ledger management node successfully participates in consensus activities and number of failures .

3. The consensus method as described in claim 2, characterized in that, The service evaluation form is generated by the service provider receiving service evaluations from consumers after the service is completed. All service evaluations from each transaction form a service evaluation form. The service evaluation refers to the consumer rating the service provided by their service provider from 0 to k after a transaction is completed; that is, the service evaluation form. Evaluation score The consumer behavior evaluation form is generated as follows: after a consumer completes a transaction and evaluates the service, the service provider scores the consumer behavior from 0 to k. All transaction scores are combined to form a consumer behavior evaluation form. Evaluation score When a ledger management node successfully generates a new block through a formula activity, it is counted as one success; otherwise, it is counted as one failure.

4. The consensus method as described in claim 1, characterized in that, In step 2.3, the steps for triggering the view switching protocol are as follows: Step 2.3.1: The ledger management node participating in the consensus activity sends a view switching message to all ledger management nodes except itself; Step 2.3.2: If, within the timeout period, all ledger management nodes collect more than two-thirds of the view switching messages, the current view number is incremented by one; otherwise, the protocol state is reset and the view number is restored to its default value.

5. The consensus method as described in claim 1, characterized in that, The steps for the verifier to verify the transaction in step three are as follows: Step 3.1: The node with the highest reputation among the validators is responsible for selecting a set of transactions from the transaction pool, signing it, and broadcasting it to the other validator nodes; Step 3.2: After receiving the group of transactions, other validator nodes check each transaction and perform transaction pre-execution operations to generate corresponding transaction receipts. If the number of generated receipts matches the number of transactions, they continue to check the signatures of the transaction group initiating node and other validators in turn. If all are correct, it means that the transaction group has been successfully verified, and a transaction verification success message is sent to other validator nodes. Step 3.3: If the number of successful transaction verification messages received by the validator node exceeds two-thirds of the current consensus node list, it means that the group of transactions has been successfully verified and sent to the leader node. If not enough successful transaction verification messages are received within the timeout period, the view switching protocol is triggered.

6. The consensus method as described in claim 1, characterized in that, The verification steps for the block by the validator in step four are as follows: Step 4.1: Check if the block creator's signature is correct. If it is incorrect, discard the block and do not broadcast it. If it is correct, proceed to the next step. Step 4.2: Check if the list of signed validators is on the locally generated list. If not, discard the block without broadcasting. If all validators are on the list, sign the block and broadcast the block confirmation message to the network. Step 4.3: During the timeout period, the leader checks whether enough block confirmation messages have been received. If the number exceeds two-thirds of the current consensus list, the block verification is successful; otherwise, the view switching protocol is triggered.

7. The consensus method as described in claim 1, characterized in that, In step five, when the leader submits the new block to the blockchain and executes the transaction execution operation, the result of the transaction execution operation is updated to the local database; Other ledger management nodes download the latest block updates from the leader node and update them locally. If the new block is successfully updated locally, the current round of consensus activity is considered successful, and all participating nodes receive an incentive based on their contribution. This incentive is given from the reward pool maintained by the system. If any action during the execution of the protocol causes a block submission to fail, the current round of consensus activity is considered a failure, and all nodes participating in this consensus activity will be penalized. The penalty mechanism is to collect a portion of the node's deposit, which will be used to maintain a prize pool for the system.

Images