Lightweight block chain architecture based on sender

Abstract

The invention discloses a lightweight block chain architecture based on a sender. The lightweight block chain architecture comprises a core structure, a reputation model and a consensus mechanism, wherein a consensus mechanism is constructed based on the reputation degree and PBFT; the core structure comprises a plurality of nodes, the nodes comprise light nodes and full nodes, and each light node stores a block conforming to a correlation relationship with the node; recording a wallet address of a sender when each block is constructed; the hash value of the newly generated block of each node is stored in a node user wallet; the reputation degree model is used for realizing reward and punishment and reputation value calculation of the nodes in combination with the design of the core structure; and the consensus mechanism is used for selecting reliable nodes according to the reputation values, realizing block generation and verification operation, and updating the reputation value of each proxy node in the reliable nodes after the consensus period is ended. According to the method, the transaction query efficiency is improved, lightweight storage is realized, and meanwhile, the system risk is reduced through the reputation value model.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain, and in particular to a sender-based lightweight blockchain architecture. Background Art

[0002] With the development of information technology, blockchain is becoming more mature in all aspects. In terms of consensus, Lu proposed a novel multi-chain consensus method MC-RHotStuff, which selects nodes to join the consensus based on performance, and dynamically adjusts the number of nodes by detecting the number of transactions to improve the throughput of the system. Kenza proposed an adaptive PBFT protocol APBFT, which reduces communication volume and response delay. David proposed Helix, which is used to sort transactions between nodes fairly in a distributed network. Na proposed DPNPBFT to achieve a balance between traffic complexity, efficiency, and security. In terms of storage, some scholars have achieved lightweight storage by rewriting the blockchain architecture, such as LDAGB and LDV. There are also researchers who reduce the storage redundancy of blockchain in data processing based on erasure codes, sharding technology, data compression and offloading.

[0003] In the era of big data, blockchain needs to strengthen its processing and analysis capabilities in data query. Zhou proposed a lightweight searchable data sharing solution based on blockchain, BLDSS, which combines public key encryption with equality testing and proxy re-encryption to achieve efficient data matching and data sharing. Chen established a recording and replay mechanism in the contract container to trace the execution process of the transaction without interrupting the operation of the smart contract. Wang proposed MSMLI, which introduces a weight matrix, divides the blockchain into shards based on the main chain structure, and constructs a composite index, which improves query efficiency while reducing storage overhead.

[0004] Although blockchain technology has great potential and many advantages, there are still many aspects that need to be optimized and improved. Over time, due to its immutable nature, data will accumulate on the blockchain, and the performance of the blockchain network will be affected by the uncontrolled growth of the blockchain ledger. This is essentially a performance bottleneck problem caused by the lack of scalability of the blockchain. At the same time, there are also problems in the network such as low node enthusiasm, node failure, or malicious nodes tampering with data, which in turn affects data consistency.

[0005] In view of the above problems, the present invention proposes a sender-based lightweight blockchain architecture Lightweight Sender-based Blockchain (LSB) to optimize the storage structure and consensus mechanism of the blockchain. Summary of the invention

[0006] In order to solve the above technical problems, the present invention proposes a sender-based lightweight blockchain architecture to solve the problems existing in the above-mentioned prior art.

[0007] To achieve the above-mentioned purpose, the present invention provides a sender-based lightweight blockchain architecture, including a core structure, a reputation model and a consensus mechanism; wherein the consensus mechanism is constructed based on reputation and PBFT;

[0008] The core structure includes several nodes, including light nodes and full nodes, and each light node stores blocks that are related to the node itself;

[0009] The sender’s wallet address is recorded when each block is constructed; the hash value of the latest block generated by each node is stored in the node user wallet;

[0010] The reputation model is used to realize rewards and punishments for nodes and reputation value calculation in combination with the design of the core structure;

[0011] The consensus mechanism is used to select reliable nodes based on reputation values, implement block generation and verification operations, and update the reputation value of each proxy node in the reliable nodes after the consensus cycle ends.

[0012] Optionally, each block element also includes a hash value of the block, a timestamp of the block, transactions sent by the user, and a preceding address of the block; the preceding address includes two, one for the previously generated block, and the other for the previously generated block by the same sender.

[0013] Optionally, the light node stores the blocks constructed by itself and the blocks constructed by the light node whose preceding addresses point to each other a number of times that meets the requirements; the full node stores the blocks under all nodes; and the wallet balance is also stored in the user wallet corresponding to each node.

[0014] Optionally, the reputation model realizes the calculation of rewards and punishments and reputation values ​​for nodes on the chain by constructing a node reputation value calculation formula, and the node reputation value calculation formula is as follows:

[0015] R i =α·W i +β·P i ;

[0016] In the formula, i represents the subscript of the node, R i Represents the current reputation value of node i, and sets the maximum reputation value to R max , W i is the node holding equity ratio, P i is the node activity, α and β are proportional adjustment parameters, and their value range is (0,1); w iis the size of the stake owned by node i, n is the total number of nodes, Represents the sum of the interests of all nodes.

[0017] Optionally, the calculation formula of the node activity is as follows:

[0018] P i =m·(P i j-1 +V i j );

[0019] Where P i is the node's activity in this round, is the activity level of the node in the previous round; Indicates the ratio of valid votes of the node in this round, e i Indicates the number of valid votes initiated by node i in this round, a i is the total number of votes owned by node i; m is the malicious factor.

[0020] Optionally, the malicious factor is expressed as follows:

[0021]

[0022] Where x is the number of abnormalities of the node.

[0023] Optionally, the consensus mechanism includes: selecting a number of light nodes as proxy nodes and a number of full nodes as verification nodes based on the size of reputation values, and unselected nodes as candidate nodes for this round of consensus; nodes with anomalies exceeding a threshold are marked as malicious nodes and their reputation values ​​are cleared; all nodes vote on the proxy nodes and verification nodes, and determine the block generation order of the proxy nodes, the master node of the verification node, and the slave node of the verification node according to the number of votes; based on the verification node and the PBFT algorithm, the legitimacy of the newly generated blocks of the proxy nodes is verified. If the verification passes, the blocks are allowed to be put on the chain until all proxy nodes complete block generation and end this round of consensus, wherein the number of verification nodes is obtained based on the number of malicious nodes.

[0024] Optionally, the process of verifying the legitimacy of a block includes:

[0025] The proxy node packages the transaction data and signs it to obtain a newly generated block, and sends the block to the client node; the client node adds the block to the request message and sends it to the master node of the verification node; after the master node receives the request message and verifies that the client signature is correct, it sends a pre-prepare message to each slave node, and a single slave node verifies the pre-prepare message; after the verification is passed, the prepare message is broadcast to other verification nodes, and each verification node receives the prepare message and verifies it; if the verification is passed and the number of prepared messages received reaches 2f+1, a commit message is broadcast to other verification nodes, and each verification node receives the commit message and verifies it; if the verification is passed and the number of commit messages received reaches 2f+1, a reply message is sent to the client; if the client receives f+1 reply messages, the verification is passed and the block is legal, where f represents the number of malicious nodes.

[0026] Optionally, the process of updating the reputation value of each proxy node in the reliable node includes: after the reliable node is rewarded with equity, the reputation value of each reliable node is calculated. If the maximum reputation value R is reached, max , then the corresponding node activity is reset to zero, and the number of abnormalities of each node is judged. If it exceeds the threshold, it is marked as a malicious node and the reputation is cleared to zero.

[0027] Optionally, the equity reward formula is as follows:

[0028]

[0029] The equity reward includes the basic reward B and the additional reward E, which is based on the node's activity P at this time. i In reputation value R i The percentage of the node in the calculation is used to obtain the coefficient of the additional reward E; the basic reward of the node is adjusted by the coefficient c. b represents the number of blocks planned to be produced in one consensus cycle, agent node is the verification node; verification node represents the proxy node.

[0030] Compared with the prior art, the present invention has the following advantages and technical effects:

[0031] (1) Improved transaction query efficiency. The hash in the block is associated with the sender of the transaction. The newly generated block will point to the block with the same wallet address, and fast transaction query can be achieved through the node wallet.

[0032] (2) Lightweight storage is implemented. Lightweight nodes only store the transaction blocks they send, reducing storage overhead.

[0033] (3) Reduced system risk. A reputation value model is established to comprehensively evaluate the behavior of nodes and reduce the possibility of nodes doing evil. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The drawings constituting a part of the present application are used to provide a further understanding of the present application. The illustrative embodiments and descriptions of the present application are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0035] Figure 1 A schematic diagram of the internal structure of a block according to an embodiment of the present invention;

[0036] Figure 2 This is a LSB architecture diagram of an embodiment of the present invention;

[0037] Figure 3 A schematic diagram of lightweight storage according to an embodiment of the present invention;

[0038] Figure 4 A schematic diagram of view change according to an embodiment of the present invention;

[0039] Figure 5 This is a schematic diagram of transaction query delay results according to an embodiment of the present invention;

[0040] Figure 6 A schematic diagram of a transaction storage overhead change according to an embodiment of the present invention;

[0041] Figure 7 This is a block verification delay comparison diagram under different numbers of proxy nodes in an embodiment of the present invention;

[0042] Figure 8 A schematic diagram of multiple rounds of reputation value test results of normal nodes and malicious nodes according to an embodiment of the present invention;

[0043] Fig. 9 Schematic diagram of malicious node removal rate in different consensus rounds according to an embodiment of the present invention;

[0044] Fig.10 FIG. 4 is a schematic diagram of the number of blocks generated by RP-DPoS and HL-DPoS according to an embodiment of the present invention. DETAILED DESCRIPTION

[0045] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0046] It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and that, although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0047] Embodiment 1

[0048] like Figure 1-10 As shown, in this embodiment, a sender-based lightweight blockchain architecture is provided, including a core structure, a reputation model and a consensus mechanism; wherein the consensus mechanism is constructed based on reputation and PBFT;

[0049] The core structure includes several nodes, including light nodes and full nodes, and each light node stores blocks that are related to the node itself;

[0050] The sender’s wallet address is recorded when each block is constructed; the hash value of the latest block generated by each node is stored in the node user wallet;

[0051] Furthermore, the elements in each block also include the hash value of the block, the timestamp of the block, the transaction issued by the user, and the prefix address of the block; the prefix address includes two, one is the previously generated block, and the other is the previously generated block by the same sender.

[0052] Furthermore, the light node stores the blocks constructed by itself and the blocks constructed by the light node whose preceding addresses point to each other a number of times that meets the requirements; the full node stores the blocks under all nodes; and the wallet balance is also stored in the user wallet corresponding to each node.

[0053] Specifically, the elements in the block are as follows Figure 1 As shown, the explanation is as follows:

[0054] 1) hash: The hash value of the block, which is related to the block’s transactions, timestamp, and prefix hash.

[0055] 2) timestamp: The timestamp of the block, which is related to the generation time of the block and determines the order of the blocks.

[0056] 3) Transaction: A transaction initiated by a user to achieve the exchange of assets, information or services.

[0057] 4)wallet address: stores the wallet address of the user related to the block.

[0058] 5) Previous hash: The previous address of the block. There are two previous addresses in a block, previous hash1 and previous hash2, which are related to the previously generated block and the corresponding wallet address respectively.

[0059] For example, in Figure 2In the diagram, there are 5 nodes A, B, C, D, and E, which correspond to the wallet addresses from wallet address A to wallet address E. The nodes generate 10 blocks, which are connected by directed edges. The direction of the arrows between blocks indicates the order of block generation. For example, if block 2 points to block 1, it means that block 2 is generated after block 1; for example, if block 4 points to block 1, it also means that block 1 is generated before block 4.

[0060] In the blockchain, most users pay more attention to their own transaction information. Based on this, the address of the transaction sender is stored in walletaddress. When a new block is generated, a solid directed edge points to the previous block in chronological order, and a dotted directed edge points to the previous block generated by the same sender. Figure 2 Block 1 is the genesis block. Since there is no predecessor, the values ​​in previous hash1 and previous hash2 are empty (the dotted line from the block to the wallet address is to indicate the sender of the transaction). The transaction sender of block 2 is node A, so the address stored in the wallet address of block 2 is wallet address A, and previous hash1 points to the previous block 1. Since block 2 is the first block generated by node A, previous hash2 stores an empty value. Block 7 is similar to block 2. The sender of block 3 is node A, the same as block 2. At the same time, block 2 is also the previous block generated by block 3, so previous hash1 and previous hash2 of block 3 both point to block 2. Block 4 is generated by node C after block 3. The last block sent by node C is block 1, so the address stored in the wallet address of block 4 is wallet address C, previous hash1 points to block 3, and previous hash2 points to block 1.

[0061] If two nodes D and E have a close relationship and they keep sending information to each other over a period of time, there will be frequent pointing between the previous hash1 of the blocks they generate on the chain, such as blocks 6 to 10, which are connected in sequence by solid arrows.

[0062] Usually users are only interested in transactions related to themselves, and not in other transactions, so light nodes only need to store relevant transaction data to save storage space. Figure 3As shown in the figure, blocks 6, 8 and 10 stored in node E are generated by E successively. The value of the address stored in the wallet address inside the block is walletaddress E. The same is true for the blocks stored in nodes C and B. The blocks stored in the same node have the same walletaddress.

[0063] When a light node has extra storage space, in addition to storing the transaction data it issues, it can also store the data of nodes with which it has close transaction relationships. For example, node D in the figure not only stores blocks 7 and 9 it issues, but also blocks 6 to 10 of node E. When a node has significant storage capacity and can save the transaction data of all nodes, it is a full node in LSB.

[0064] In order to better utilize the advantages of lightweight storage, the concept of user wallet is introduced in LSB. The wallet is shown in Table 1:

[0065] Table 1

[0066] element illustrate walletaddress User's wallet address lasthash The hash value of the latest block generated by the node amount Balance in the wallet

[0067] There are two types of nodes in LSB: light nodes and full nodes. The wallets corresponding to the two types of nodes are different. The light wallet corresponding to the light node only contains the node's own wallet address, the hash of the block the node last sent, and the user's balance; the full node wallet contains the wallet addresses of all nodes. The user wallet can be used to quickly query the transaction records of the node. The specific steps are as follows:

[0068] 1) Enter the wallet address of the block to be queried, and find the hash value lasthash of the latest block generated by the node in the corresponding wallet.

[0069] 2) Find the last block sent by the node through last hash, and traverse all blocks generated by the node with the previous hash previous hash2 until the required transaction is obtained.

[0070] The reputation model is used to realize rewards and punishments for nodes and reputation value calculation in combination with the design of the core structure;

[0071] Specifically, the traditional DPoS consensus algorithm lacks a reward and punishment mechanism, which causes some nodes to become malicious nodes in order to gain benefits, endangering the security of the blockchain. This embodiment introduces the concept of reputation model to measure the specific performance of nodes on the chain, reward nodes that participate in consensus normally, and punish nodes that do evil.

[0072] For better division and management, the nodes in the system are divided into client nodes, consensus nodes and candidate nodes, among which the consensus nodes are divided into proxy nodes and verification nodes.

[0073] 1) Client node: As a special node in the blockchain, the client node does not store data or participate in information search, and is mainly used to send data to other nodes. In this embodiment, the client node is an honest node established by the system.

[0074] 2) Proxy nodes: Proxy nodes are selected from light nodes with high reputation, collect transaction information in the network and generate blocks in turn according to a predetermined schedule, but do not participate in the verification of blocks.

[0075] 3) Verification Node: In LSB, lightweight nodes only store part of the entire chain structure, so the ability of a single lightweight node to verify transactions is limited. Full nodes hold a copy of the entire ledger and can independently check whether the block is legal, so some full nodes in the network are selected as verification nodes.

[0076] 4) Candidate nodes: Nodes that are not selected to participate in bookkeeping in this round of consensus cycle will become candidate nodes. Candidate nodes are ranked according to their reputation, and the top candidate nodes have a higher probability of becoming proxy nodes or verification nodes.

[0077] 5) Malicious nodes: Nodes that have committed malicious acts multiple times will be marked by the system and cannot participate in the consensus.

[0078] The size of the reputation value is a specific manifestation of the honesty of a node. The more stable and reliable a node is, the higher its reputation value is, and the greater the probability of being selected as a consensus node. In this embodiment, the reputation value of a node is related to the performance of the node on the chain and its own weight.

[0079] The calculation formula is as follows:

[0080] R i =α·W i +β·P i (1)

[0081] In formula (1), i represents the subscript of the node, R i Represents the current reputation value of node i, and sets the maximum reputation value to R max , W i is the proportion of the node’s equity, P i It is the activeness of the node in participating in the consensus. α and β are proportional adjustment parameters with a value range of (0,1).

[0082] In the DPoS consensus algorithm, the more stake a node holds, the greater the probability of being selected as a proxy node to obtain a block generation opportunity, and thus obtain more benefits. This mechanism causes nodes with a large amount of stake to always control the entire blockchain network, destroying the initiative and fairness of node voting competition. This embodiment makes improvements to this problem. The stake held by the node is no longer a determining factor affecting the node's participation in block generation, but is used as a factor to constitute part of the reputation value. This not only enhances the degree of decentralization of the system, but also motivates some honest nodes with smaller holdings.

[0083] The calculation formula for the node's equity ratio is as follows:

[0084]

[0085] In formula (2), W i represents the weight of node i, w i is the size of the stake owned by node i, n is the total number of nodes, It represents the sum of the equity of all nodes, that is, the total equity value in the system. Every time a node successfully participates in a block, it will receive a certain reward. The formula shows that the weight of a node is proportional to the size of the equity it has.

[0086] Node activity is a numerical standard for evaluating the performance of nodes in the network. If a node actively participates in activities on the chain, its activity will increase. On the contrary, if a node is passive or even malicious, destroying the security of the system, its activity will drop rapidly, reducing the probability of being selected as a consensus node. Nodes that have repeatedly committed malicious acts will be removed from the system.

[0087] Whether a node is malicious or not is related to the number of abnormalities of the node. When a node behaves abnormally during the consensus process, the behavior of the node will be observed and the cause of the abnormality will be determined. The instability of the network environment may also cause the node to be unable to participate in the consensus normally. This is not the node actively doing evil, so it cannot be directly regarded as a malicious node. In order to prevent the occurrence of misjudgment, this embodiment introduces the concept of malicious factor. For the first abnormal node, no punishment will be imposed. If the node behaves abnormally many times, the punishment will be greatly increased.

[0088] The formula is as follows:

[0089]

[0090] In formula (3), x is the number of abnormalities of the node, and m is the malicious factor. When the node is abnormal for the first time, the value of m is 1, which has no effect on the node's reputation value. When the value of x is greater than 1, m will decrease rapidly, weakening the growth of the node's reputation. When the number of abnormalities x reaches 5, the node is judged to be a malicious node and the node's reputation value is cleared.

[0091] Active participation of nodes in voting will improve their reputation. Among the nodes in the system, consensus nodes (proxy nodes and verification nodes) participate in the sending and verification of a transaction, and are performed by nodes with higher reputations. Therefore, voting for consensus nodes is meaningful, and voting for other nodes is meaningless. Therefore, it is stipulated that voting for consensus nodes is a valid vote, and voting for other nodes or not voting is an invalid vote.

[0092] The formula for calculating valid votes is as follows:

[0093]

[0094] In formula (4), when the consensus round is j, is the effective voting proportion of node i in round j, e i Indicates the number of valid votes initiated by node i in this round, a i is the total number of votes that node i has.

[0095] The calculation formula of node activity is as follows:

[0096] P i =m·(P i j-1 +V i j ) (5)

[0097] Where P i is the node's activity in this round, is the activity of the node in the previous round, Indicates the ratio of valid votes of the node in this round.

[0098] The reputation value formula of a node is expanded as follows:

[0099]

[0100] The node actively participates in voting, and its reputation value will gradually increase. Even nodes with low weight have a chance to be selected as consensus nodes to participate in block generation. On the contrary, if a node repeatedly commits evil, its reputation value will drop rapidly, and it will be difficult to be selected as a consensus node in the next cycle. The reputation model ensures that the generation and verification of blocks are performed by stable and reliable nodes, which improves the security of the system.

[0101] The consensus mechanism is used to select reliable nodes based on reputation values, implement block generation and verification operations, and update the reputation value of each proxy node in the reliable nodes after the consensus cycle ends.

[0102] Furthermore, the consensus mechanism includes: selecting a number of light nodes as proxy nodes and a number of full nodes as verification nodes based on the size of the reputation value, and the unselected nodes as candidate nodes for this round of consensus. Nodes with anomalies exceeding a threshold are marked as malicious nodes and their reputation values ​​are cleared; all nodes vote on the proxy nodes and verification nodes, and determine the block generation order of the proxy nodes, the master node of the verification node, and the slave node of the verification node according to the number of votes; based on the verification node and the PBFT algorithm, the legitimacy of the newly generated blocks of the proxy nodes is verified. If the verification passes, the blocks are allowed to be chained until all proxy nodes complete the block generation and end this round of consensus, wherein the number of verification nodes is obtained based on the number of malicious nodes.

[0103] Furthermore, the process of verifying the legitimacy of a block includes:

[0104] The proxy node packages the transaction data and signs it to obtain a newly generated block, and sends the block to the client node; the client node adds the block to the request message and sends it to the master node of the verification node; after the master node receives the request message and verifies that the client signature is correct, it sends a pre-prepare message to each slave node, and a single slave node verifies the pre-prepare message; after the verification is passed, the prepare message is broadcast to other verification nodes, and each verification node receives the prepare message and verifies it; if the verification is passed and the number of prepared messages received reaches 2f+1, a commit message is broadcast to other verification nodes, and each verification node receives the commit message and verifies it; if the verification is passed and the number of commit messages received reaches 2f+1, a reply message is sent to the client; if the client receives f+1 reply messages, the verification is passed and the block is legal, where f represents the number of malicious nodes.

[0105] Furthermore, the process of updating the reputation value of each proxy node in the reliable node includes: after the reliable node is rewarded with equity, the reputation value of each reliable node is calculated. If the maximum reputation value R is reached, max , then the corresponding node activity is reset to zero, and the number of abnormalities of each node is judged. If it exceeds the threshold, it is marked as a malicious node and the reputation is cleared to zero.

[0106] Specifically, assume that in a consensus cycle T, M proxy nodes and N verification nodes are selected to participate in block generation. The RP-DPoS consensus mechanism can be divided into four steps: node division, node voting, block chaining, and node reputation value settlement.

[0107] (1) Node division

[0108] To ensure the security of the blockchain, nodes with higher reputation values ​​will be selected to participate in block generation. Before the formal accounting activity begins, the system calculates the reputation value of the node using the reputation value formula (1) and sorts the light nodes and full nodes according to the value. Since the newly joined nodes do not participate in the chain activities, the node activity P i is 0, so the only factor affecting the node’s initial reputation value is the node’s own weight W i .

[0109] The proxy nodes are light nodes, and the system will select the top M light nodes with the highest reputation values ​​as the proxy nodes for this round. Correspondingly, the verification nodes will be selected from the top N full nodes with the highest reputation values, and the unselected nodes will automatically become candidate nodes in this round of consensus. Nodes that have committed malicious acts many times will be marked by the system, their reputation values ​​will be cleared and cannot be increased in any way, and they will not be selected to participate in the consensus.

[0110] (2) Node Voting

[0111] In RP-DPoS, the uploading of blocks to the chain is not done in one go. The generation and verification of blocks are completed by proxy nodes and verification nodes respectively, so when voting, you need to vote for both types of nodes.

[0112] After the node categories are divided, the system will initiate a vote. The nodes need to cast their votes for the verification nodes and proxy nodes selected in this round (nodes can vote for themselves). The proxy nodes determine the order of block generation based on the number of votes they receive. Nodes with more votes are prioritized for accounting. When all proxy nodes have completed block generation, this round of consensus ends. Correspondingly, the verification node with the highest number of votes will serve as the master node N0 for block verification, and the remaining verification nodes will be converted into slave nodes N1, N2, N3, etc. in the order of the number of votes. The verification nodes form a committee to accept the newly generated blocks and use the PBFT algorithm to confirm whether they are legal. The blocks are legally on the chain, otherwise they are discarded.

[0113] (3) Blockchain

[0114] In DPoS, the newly generated blocks of the proxy nodes need to be confirmed by 2 / 3 of the witnesses, which greatly prolongs the transaction confirmation time. Based on this problem, verification nodes are added to RP-DPoS to verify whether the blocks are legal and shorten the verification delay.

[0115] The proxy node packages and signs the transaction and sends the block to the client node. To prevent some verification nodes from doing evil, the PBFT algorithm is used. The number of selected verification nodes N must satisfy N ≥ 3f + 1, where f is the number of malicious nodes. The block verification steps are as follows:

[0116] 1) The client will temporarily save the block data and add it to the request message<cRequest,t,c,BlockData> σ c Sent to verification node N0, cRequest is the message type sent, t is the timestamp, c represents the client address, BlockData is the serialized block data, σ c It is the client's signature on the information.

[0117] 2) After N0 receives the request and confirms that the signature is correct, it sends a pre-prepare message to broadcast the request to the slave node. The information structure is<cPrePrepare,m,d,s> σ p , cPrePrepare is the type of message sent, m contains the request sent by the client, d is the message digest, s represents the sequence ID of the message, σ p is the node's signature.

[0118] 3) After receiving the pre-prepare message, the verification node confirms whether the signature, message summary and sequence number are consistent. If correct, it verifies whether the block is legal. The verification rules are as follows:

[0119] (a) Whether the block height is consistent with the proxy node height.

[0120] (b) Whether the hash point of the block is correct.

[0121] If the above conditions are met, the node broadcasts the prepare message to other verification nodes, the structure is<cPrepare,v,d,s,i> σ i , where v is the view number and i is the node number.

[0122] 4) The node receives the prepare message, verifies the signature and confirms whether v, d, and s are consistent. After receiving 2f+1 messages (including its own), it broadcasts the commit message to other verification nodes.<cCommit,v,d,s,i> σ i .

[0123] 5) After receiving the commit message, the node will verify it. The verification rules are the same as step 4. When the number of messages received reaches 2f+1, the node sends a reply message to the client.

[0124] 6) The client receives f+1 reply messages, which means the verification is successful and the block is legal. The client node broadcasts the previously saved block to other nodes and then deletes the block data to start the next round of verification.

[0125] (4) Reputation Value Settlement

[0126] After the current consensus cycle T ends, the system updates the node’s reputation based on the node’s performance using formula (1). To prevent nodes with high reputation from occupying the right to generate blocks for a long time, when the node’s reputation reaches the maximum value R max When the node's activeness value P is i Reset to 0. At the same time, check the number of abnormalities of the node. When the number of abnormalities x reaches 5, mark it as a malicious node and the reputation of the node is reset to 0.

[0127] View Changes

[0128] In RP-DPoS, when the proxy node or slave node does not respond within the specified maximum time, it is determined that the node timeout is caused by network problems or node malicious behavior. The system will increase the number of node abnormalities by x and include it in the next node reputation value settlement.

[0129] When an exception occurs in the master node N0, to prevent the slave nodes from waiting endlessly, the slave node N1 with the lowest number of votes in this round of verification nodes is automatically converted to a backup node, and the view change begins.

[0130] like Figure 4 As shown, in this round of view v, the slave node broadcasts view-change information to all verification nodes. The nodes verify the received information and add it to the message set if it is correct. When the candidate node N1 confirms that the number of view-change information in the message set reaches 2f+1, it broadcasts new-view information to the verification node set. The view change is successful and the new view number is changed to v+1.

[0131] Furthermore, the equity reward formula is as follows:

[0132]

[0133] The equity reward includes the basic reward B and the additional reward E, which is based on the node's activity P at this time. i In reputation value R i The percentage of the node in the calculation is used to obtain the coefficient of the additional reward E; the basic reward of the node is adjusted by the coefficient c. b represents the number of blocks planned to be produced in one consensus cycle, agent node is the verification node; verification node represents the proxy node.

[0134] Experimental analysis

[0135] In order to simulate the real blockchain environment as much as possible, this embodiment uses Intel (R) Core (TM) i5-10400F CPU, 8GB memory, and 64-bit Windows 10 operating system for simulation experiments, and uses GoLang language to implement the RP-DPoS consensus algorithm.

[0136] To simulate the behavior of nodes in the blockchain, on the same host, the system generates a total of 200 account nodes to participate in the selection of consensus nodes. The generated blocks will be stored in the form of key-value pairs in the boltDB database that comes with the integrated development environment GoLand.

[0137] Based on the above conditions, the performance of LSB is evaluated from the aspects of transaction query latency, storage space overhead comparison, malicious node removal efficiency and some other aspects.

[0138] (1) Transaction query delay

[0139] The experiment compares the time required for querying a specified transaction among three blockchain architectures: LSB, LDAGB and DPoS. In order to compare the data in the same dimension, each architecture selects 10 nodes to send and store transactions, and each block only stores one transaction.

[0140] exist Figure 5 In the experiment, the query delay of transactions when the number of transactions is 100, 200, 300, 400, and 500 is recorded respectively, and repeated 30 times. The experimental results show that the transaction query time of the three increases linearly with the number of transactions, and the increase of DPoS is much greater than that of the other two architectures. This is because DPoS needs to traverse from the latest block forward until the block containing the transaction is found, while LSB and LDAGB both record the wallet address of the node, and only need to traverse part of the chain structure through the corresponding previous hash to find a specific transaction. Since the previous hash of LDAGB involves the sender and receiver of the transaction, while LSB only involves the sender of the transaction, when querying a specific transaction, LSB needs to traverse fewer blocks than LDAGB, and the query time is the shortest.

[0141] By comparison, when the number of transactions reaches 500, the transaction query latency of LSB is reduced by 89.8% compared with the traditional blockchain architecture, and the query latency is reduced by 45.6% compared with the LDAGB architecture. This shows that LSB has higher transaction query efficiency.

[0142] (2) Node storage overhead

[0143] To evaluate the impact of lightweight architecture on storage overhead, this embodiment deploys a total of 10 light nodes. Each light node stores the same number of transactions, and records the storage overhead of light nodes and full nodes when the number of transactions is 10,000, 20,000, 30,000, 40,000, and 50,000, respectively.

[0144] like Figure 6As shown in the figure, as the number of transactions increases, the storage space required by the node increases linearly, but the growth rate of light nodes is much smaller than that of full nodes. The size of a single transaction in LSB is about 200 bytes. When the number of transactions reaches 50,000, the storage overhead of the full node reaches about 10MB, while that of the light node is less than 1MB. This is because the light node only needs to store the transactions sent by the node itself, which greatly saves the space required for storage.

[0145] (3) Block verification delay

[0146] In order to evaluate the efficiency of block verification in RP-DPoS, this embodiment tests the block verification delay of RP-DPoS and DPoS under the same environment. The number of proxy nodes deployed in the network is 10, 15, 20, 25, and 30 respectively, and the confirmation time of the block under different numbers of proxy nodes is recorded. The results are as follows: Figure 7 shown.

[0147] Experimental results show that the time it takes for RP-DPoS to verify a single block is between 900ms and 1100ms, and it remains relatively stable when the number of proxy nodes increases to 30. In comparison, DPoS takes tens of seconds to confirm a block, and the confirmation time gradually increases with the number of proxy nodes. This is because in traditional DPoS, for a block to reach an irreversible state, it requires confirmation from at least 2 / 3 of the agents, which greatly prolongs the confirmation time of the block. In RP-DPoS, blocks are verified by selected nodes, and the verification delay is about 1s. Because the generation and verification of blocks are completed by different nodes, the verification delay will not change too much with the increase of proxy nodes, which improves the overall efficiency of the system.

[0148] (4) Reputation Value Test

[0149] This embodiment uses the reputation model to select honest and reliable nodes that actively participate in voting to produce blocks. The size of the reputation value is related to the node's own weight and performance on the chain. In order to test the impact of node behavior on the reputation value, representative normal nodes and malicious nodes are selected respectively, and the changes in the reputation values ​​of the two in 5 rounds of consensus are recorded.

[0150] Depend on Figure 8It can be seen that the initial weight of a normal node is 0. It actively participates in voting and completes block generation, and obtains equity rewards in each round. The reputation value increases steadily with the consensus rounds, and the reputation value increases by about 0.2 in each round. Malicious nodes have a higher initial weight of 0.25. After being selected as proxy nodes, they refuse to generate blocks. After two rounds of consensus, the node reputation drops sharply to about 0.1, making it difficult to compete with other nodes. The experimental results show that even if the initial equity held by the node is very low, active behavior will help the node have a higher reputation value and have the opportunity to be selected as a proxy node. This shows that the reputation model has a certain incentive effect on user nodes.

[0151] (5) Malicious Node Processing

[0152] RP-DPoS uses a reputation model to select proxy nodes. In order to analyze its ability to handle malicious nodes, 25% of malicious nodes are added to the proxy nodes. DPoSDWE is compared with the traditional DPoS consensus algorithm, and the proportion of malicious nodes in the proxy nodes within 30 consensus rounds is recorded.

[0153] like Fig. 9 As shown in the figure, the traditional DPoS consensus algorithm does not take effective measures to deal with malicious nodes, and the proportion of malicious nodes in the proxy nodes remains at around 20%. In RP-DPoS and DPoSDWE, the proportion of malicious nodes shows a significant downward trend with the increase of consensus rounds. The curve representing RP-DPoS fluctuates more stably, and the proportion of malicious nodes is less than DPoSDWE after the 7th round. When the consensus round reaches 19 rounds, the proportion of malicious nodes in RP-DPoS approaches 0. The experimental results show that the improved RP-DPoS can effectively inhibit malicious nodes from participating in block generation and improve the security of the system.

[0154] (6) Block output throughput

[0155] In order to evaluate the efficiency of RP-DPoS in producing blocks, this example compares the number of blocks generated by RP-DPoS and HL-DPoS in the same time. The experiment records the number of blocks generated in five time spans of 10min, 20min, 30min, 40min, and 50min.

[0156] like Fig.10As shown in the figure, both RP-DPoS and HL-DPoS have high throughput in block generation. At the time point of 10 minutes, RP-DPoS generated 87 blocks, and QDPoSB generated about 50 blocks. As time progressed from 10 minutes to 50 minutes, the difference in the total number of blocks generated by the two gradually widened. By comparison, it was found that HL-DPoS produced a block in about 12 seconds, and the block generation time of RP-DPoS was between 6 seconds and 7 seconds. The RP-DPoS algorithm has a more prominent advantage in block generation efficiency.

[0157] (7) Comparison of improvement plans

[0158] The recent DPoS improved consensus algorithms HADPoS, HL-DPoS, and DPoSDWE are compared with the solution of this embodiment, and the comparison results are shown in Table 2 below.

[0159] Table 2

[0160]

[0161] By comparing with the existing improvement scheme, it can be seen that this embodiment has improvements in suppressing malicious nodes, stimulating node enthusiasm, and reducing block verification delay, thereby enhancing the overall efficiency and security of the blockchain system.

[0162] (8) Application scenarios

[0163] Blockchain technology makes it possible to establish reliable message communication and privacy protection in the Internet of Vehicles. However, with the increasing size, many devices such as mobile phones and vehicle systems have been unable to carry large-capacity blockchain copies. LSB inherits the advantages of traditional blockchain while avoiding excessive reliance on storage resources.

[0164] Taking the in-vehicle system as an example, in the emerging in-vehicle social network, drivers use social software to obtain various messages released every day, such as traffic information, social information, and daily news. However, different users have different needs for various types of information. Taxi drivers are more concerned about traffic conditions; tourists are more interested in local attractions. With the continuous growth of data volume and the increase in data types, data classification and selective storage are particularly important. In LSB, different information can be divided by wallet address. Taking the in-vehicle network as an example, the message sent by newspaper A can be stored in the light node A corresponding to wallet address A. Similarly, the news of newspaper B is stored in light node B. Drivers who like to read newspaper A only need to use wallet address A to quickly search for all the news sent by newspaper A and download it to the in-vehicle system, instead of backing up the entire chain.

[0165] Security Analysis

[0166] This embodiment introduces concepts such as node enthusiasm and malicious factors, selects honest and reliable nodes to participate in block generation, and uses the PBFT consensus method to verify whether the block is legal to ensure system security.

[0167] In the traditional blockchain architecture that uses the DPoS consensus algorithm, the selection of proxy nodes is related to the number of votes held by the node. Malicious nodes can bribe high-stakes nodes to vote for themselves to launch bribery attacks. In LSB, stakes are only part of the node's reputation value. When voting, nodes tend to vote for nodes with high reputation values ​​for their own interests, so bribery attacks are difficult to implement.

[0168] LSB is also tamper-proof because it inherits the decentralized characteristics of blockchain. If a malicious node wants to tamper with the data, it needs to rewrite the ledgers of more than half of the nodes in the network. Blocks point to the previous block through hash values. Once the transaction is tampered with, the hash in the block will also be changed. The node determines whether the data has been tampered with based on the direction of the previous hash.

[0169] Attackers can also create multiple nodes to join the network to control the entire blockchain network, which is called a Sybil attack. In LSB, the selection of nodes is determined by the reputation value. The weight and activity of the newly added nodes created by the attacker are both 0, and they will not be selected as consensus nodes, which effectively prevents Sybil attacks.

[0170] Malicious nodes send the same transaction twice in an attempt to fork the blockchain to achieve a double-spending attack. In LSB, the blocks produced by the proxy node are accepted by the client node and sent to the verification node to run the PBFT algorithm to determine whether the block height and hash value are correct, avoiding the harm of double-spending.

[0171] At the same time, in order to avoid excessive centralization, LSB introduces concepts such as node weight and enthusiasm into the reputation value model, comprehensively evaluates the performance of nodes, weakens the connection between node selection and weight in traditional DPoS, prevents high-weight nodes from occupying the right to produce blocks for a long time, and at the same time encourages ordinary nodes to participate in consensus, fully mobilizes the enthusiasm of nodes, and promotes fairness and justice in the system.

[0172] The above are only preferred specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A sender-based lightweight blockchain architecture, characterized in that: It includes core structure, reputation model and consensus mechanism; wherein the consensus mechanism is constructed based on reputation and PBFT; The core structure includes several nodes, including light nodes and full nodes, and each light node stores blocks that are related to the node itself; The sender’s wallet address is recorded when each block is constructed; the hash value of the latest block generated by each node is stored in the node user wallet; The reputation model is used to realize rewards and punishments for nodes and reputation value calculation in combination with the design of the core structure; The consensus mechanism is used to select reliable nodes based on reputation values, implement block generation and verification operations, and update the reputation value of each proxy node in the reliable nodes after the consensus cycle ends.

2. The sender-based lightweight blockchain architecture according to claim 1, characterized in that: The elements in each block also include the hash value of the block, the timestamp of the block, the transaction issued by the user, and the preceding address of the block; the preceding address includes two, one for the previously generated block, and the other for the previously generated block by the same sender.

3. The sender-based lightweight blockchain architecture according to claim 2, characterized in that: The light node stores the blocks constructed by itself and the blocks constructed by the light node whose front address points to each other a number of times that meets the requirements; the full node stores the blocks under all nodes; and the wallet balance is also stored in the user wallet corresponding to each node.

4. The sender-based lightweight blockchain architecture according to claim 1, characterized in that: The reputation model realizes the calculation of rewards, punishments and reputation values ​​of nodes on the chain by constructing a node reputation value calculation formula. The node reputation value calculation formula is as follows: R i =α·W i +β·P i ; In the formula, i represents the subscript of the node, R i Represents the current reputation value of node i, and sets the maximum reputation value to R max , W i is the node holding equity ratio, P i is the node activity, α and β are proportional adjustment parameters, and their value range is (0,1); w i is the size of the stake owned by node i, n is the total number of nodes, Represents the sum of the interests of all nodes.

5. The sender-based lightweight blockchain architecture according to claim 4, characterized in that: The calculation formula of the node activity is as follows: P i =m·(P i j-1 +V i j ); Where P i is the node's activity in this round, is the activity level of the node in the previous round; Indicates the ratio of valid votes of the node in this round, e i Indicates the number of valid votes initiated by node i in this round, a i is the total number of votes owned by node i; m is the malicious factor.

6. The sender-based lightweight blockchain architecture according to claim 5, characterized in that: The evil factor is expressed as follows: Where x is the number of abnormalities of the node.

7. The sender-based lightweight blockchain architecture according to claim 5, characterized in that: The consensus mechanism includes: selecting a number of light nodes as proxy nodes and a number of full nodes as verification nodes based on the size of the reputation value, and the unselected nodes as candidate nodes for this round of consensus. Nodes with anomalies exceeding the threshold are marked as malicious nodes and their reputation values ​​are cleared; all nodes vote on the proxy nodes and verification nodes, and determine the block generation order of the proxy nodes, the master node of the verification node, and the slave node of the verification node according to the number of votes; based on the verification node and the PBFT algorithm, the legitimacy of the newly generated blocks of the proxy nodes is verified. If the verification passes, the blocks are allowed to be chained until all proxy nodes complete the block generation and end this round of consensus, wherein the number of verification nodes is obtained based on the number of malicious nodes.

8. The sender-based lightweight blockchain architecture according to claim 7, characterized in that: The process of verifying the legitimacy of a block includes: The proxy node packages the transaction data and signs it to obtain a newly generated block, and sends the block to the client node; the client node adds the block to the request message and sends it to the master node of the verification node; after the master node receives the request message and verifies that the client signature is correct, it sends a pre-prepare message to each slave node, and a single slave node verifies the pre-prepare message; after the verification is passed, the prepare message is broadcast to other verification nodes, and each verification node receives the prepare message and verifies it; if the verification is passed and the number of prepared messages received reaches 2f+1, a commit message is broadcast to other verification nodes, and each verification node receives the commit message and verifies it; if the verification is passed and the number of commit messages received reaches 2f+1, a reply message is sent to the client; if the client receives f+1 reply messages, the verification is passed and the block is legal, where f represents the number of malicious nodes.

9. The sender-based lightweight blockchain architecture according to claim 8, characterized in that: The process of updating the reputation value of each proxy node in the reliable node includes: after the reliable node is rewarded with equity, the reputation value of each reliable node is calculated. If the maximum reputation value R is reached, max , then the corresponding node activity is reset to zero, and the number of abnormalities of each node is judged. If it exceeds the threshold, it is marked as a malicious node and the reputation is cleared to zero.

10. The sender-based lightweight blockchain architecture according to claim 9, characterized in that: The equity reward formula is as follows: The equity reward includes the basic reward B and the additional reward E, which is based on the node's activity P at this time. i In reputation value R i The percentage of the node in the calculation is used to obtain the coefficient of the additional reward E; the basic reward of the node is adjusted by the coefficient c. b represents the number of blocks planned to be produced in one consensus cycle, agent node is the verification node; verification node represents the proxy node.

Images