A sender-based lightweight blockchain architecture

Abstract

This invention discloses a lightweight blockchain architecture based on the sender, including a core structure, a reputation model, and a consensus mechanism. The consensus mechanism is built based on reputation and PBFT. The core structure includes several nodes, including light nodes and full nodes. Each light node stores blocks that are correlated with itself. When each block is constructed, the sender's wallet address is recorded. The hash value of the latest block generated by each node is stored in the node user's wallet. The reputation model is used in conjunction with the core structure design to implement rewards and penalties for nodes and calculate their reputation values. The consensus mechanism selects reliable nodes based on their reputation values ​​to perform block generation and verification operations, and updates the reputation value of each proxy node among the reliable nodes after the consensus period ends. This invention improves the efficiency of transaction queries, achieves lightweight storage, and reduces system risk through the reputation model.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, and in particular relates to a lightweight blockchain architecture based on the sender. Background Technology

[0002] With the development of information technology, blockchain is maturing in various aspects. Regarding 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, thereby improving system throughput. Kenza proposed an adaptive PBFT protocol, APBFT, which reduces communication volume and response latency. David proposed Helix, used to fairly order transactions between nodes in a distributed network. Na proposed DPNPBFT, achieving a balance between communication complexity, efficiency, and security. In terms of storage, some scholars have rewritten the blockchain architecture to achieve lightweight storage, such as LDAGB and LDV. Other researchers have reduced storage redundancy in blockchain data processing based on erasure coding, sharding technology, data compression, and offloading.

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

[0004] While blockchain technology boasts immense potential and numerous advantages, many aspects still require optimization and improvement. Over time, due to its immutable nature, data accumulates on the blockchain, impacting network performance due to the uncontrolled growth of the ledger—essentially a performance bottleneck caused by insufficient scalability. Furthermore, issues such as low node engagement, node failures, or malicious data tampering exist, affecting data consistency.

[0005] To address the above issues, this invention proposes a LightweightSender-based Blockchain (LSB) architecture that optimizes the storage structure and consensus mechanism of the blockchain. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention proposes a lightweight blockchain architecture based on the sender, thereby resolving the issues present in the existing technologies.

[0007] To achieve the above objectives, the present invention provides a lightweight blockchain architecture based on the sender, 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, which include light nodes and full nodes. Each light node stores blocks that are related to itself.

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

[0010] The reputation model is used in conjunction with the design of the core structure to realize the reward and punishment of nodes and the calculation of reputation value;

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

[0012] Optionally, each block may also include the block's hash value, the block's timestamp, the transaction sent by the user, and the block's preceding address; there are two preceding addresses, one for the previous block and the other for the previous block sent by the same sender.

[0013] Optionally, the light node stores the blocks it constructs and the blocks constructed by the light node whose number of mutual pointers with the preceding address meets the requirement; the full node stores the blocks under all nodes; and the user wallet corresponding to each node also stores the wallet balance.

[0014] Optionally, the reputation model implements the reward and punishment and reputation value calculation for on-chain nodes by constructing a node reputation value calculation formula, which is as follows:

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

[0016] In the formula, i represents the index of the node, and R i This represents the current reputation value of node i, with the maximum reputation value set to R. max W i It is the percentage of equity held by the node, P i For node activity, α and β are proportional adjustment parameters with values ​​ranging from (0,1); w iWhere i is the amount of equity held by node i itself, and n is the total number of nodes. This represents the sum of the stakes of all nodes.

[0017] Optionally, the formula for calculating the node's activity level is as follows:

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

[0019] In the formula, P i This round of activity is a key indicator of the node's enthusiasm. It refers to the level of enthusiasm in the previous round at the node; e represents the percentage of valid votes for a node in this round. i a represents the number of valid votes initiated by node i in this round. i is the total number of votes held by node i; m is the evil factor.

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

[0021]

[0022] In the formula, x is the number of times a node is an anomaly.

[0023] Optionally, the consensus mechanism includes: selecting several light nodes as proxy nodes and several full nodes as verification nodes based on their reputation values; unselected nodes as candidate nodes for this round of consensus; and marking nodes with more than a threshold of abnormal occurrences as malicious nodes and clearing their reputation values; all nodes voting on the proxy nodes and verification nodes, and determining the block production order of the proxy nodes, the master node of the verification nodes, and the slave nodes of the verification nodes based on the number of votes; verifying the legitimacy of newly generated blocks by the proxy nodes based on the verification nodes and the PBFT algorithm, and allowing the block to be added to the chain if the verification passes, until all proxy nodes have completed block production, ending this round of consensus, wherein the number of verification nodes is obtained based on the number of malicious nodes.

[0024] Optionally, the process of validating the validity of a block includes:

[0025] The proxy node packages and signs the transaction data to obtain a newly generated block, and sends the block to the client node. The client node adds the block to a request message and sends it to the master node of the verification node. After receiving the request message and verifying that the client's signature is correct, the master node sends a pre-prepare message to each slave node. Each slave node verifies the pre-prepare message. After successful verification, the master node broadcasts the prepare message to other verification nodes. Each verification node receives the prepare message and verifies it. If the verification is successful and the number of received prepare messages reaches 2f+1, the master node broadcasts a commit message to other verification nodes. Each verification node receives the commit message and verifies it. If the verification is successful and the number of received commit messages reaches 2f+1, the master node sends a reply message to the client. If the client receives f+1 reply messages, the verification is successful and the block is valid, where f represents the number of malicious nodes.

[0026] Optionally, the process of updating the reputation value of each proxy node in the reliable nodes includes: after rewarding the reliable nodes with equity, calculating the reputation value of each reliable node, and if it reaches the maximum reputation value R... max If the number of abnormal occurrences exceeds the threshold, the corresponding node's activity level will be reset to zero. The number of abnormal occurrences for each node will be checked, and if it exceeds the threshold, it will be marked as a malicious node and its reputation level will be cleared to zero.

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

[0028]

[0029] The reward package includes a base reward B and an additional reward E, based on the node's current activity level P. i In reputation value R i The coefficient E is used to determine the percentage of a node that receives an additional reward; the base reward of a node is adjusted using 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 is the proxy node.

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

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

[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, reducing the possibility of nodes acting maliciously. Attached Figure Description

[0034] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

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

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

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

[0038] Figure 4 This is a schematic diagram illustrating view changes according to an embodiment of the present invention;

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

[0040] Figure 6 This is a schematic diagram illustrating the changes in transaction storage overhead according to an embodiment of the present invention;

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

[0042] Figure 8 This is a schematic diagram illustrating the multi-round reputation value test results of normal nodes and malicious nodes in an embodiment of the present invention;

[0043] Figure 9 This is a schematic diagram illustrating the malicious node removal rate at different consensus rounds in an embodiment of the present invention.

[0044] Figure 10 This is a schematic diagram illustrating the number of blocks generated by RP-DPoS and HL-DPoS in an embodiment of the present invention. Detailed Implementation

[0045] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

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

[0047] Example 1

[0048] like Figure 1-10 As shown, this embodiment provides a lightweight blockchain architecture based on the sender, 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, which include light nodes and full nodes. Each light node stores blocks that are related to itself.

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

[0051] Furthermore, each block also includes the block's hash value, the block's timestamp, the transaction sent by the user, and the block's preceding address; there are two preceding addresses, one for the previous block and the other for the previous block sent by the same sender.

[0052] Furthermore, the light node stores the blocks it constructs and the blocks constructed by the light node whose mutual pointing to the preceding address meets the requirement; the full node stores the blocks under all nodes; and the user wallet corresponding to each node also stores the wallet balance.

[0053] Specifically, elements within a block, such as Figure 1 As shown, the explanation is as follows:

[0054] 1) hash: The hash value of a block, which is related to the block's transactions, timestamps, and pre-hash.

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

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

[0057] 4) Wallet address: Stores the wallet address of the user associated with the block.

[0058] 5) Previous hash: The previous address of a block. There are two previous hashes within 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, corresponding sequentially to wallet addresses A through E. Each node generates 10 blocks, which are connected by directed edges. The direction of the arrows between blocks indicates the order in which they were generated. For example, if block 2 points to block 1, it means block 2 was generated after block 1; similarly, if block 4 points to block 1, it means block 1 was generated before block 4.

[0060] In a blockchain, most users are more concerned about 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 time sequence, while a dashed directed edge points to the previous block generated by the same sender. Figure 2 Block 1, as the genesis block, has no predecessor, so the values ​​in `previous hash1` and `previous hash2` are empty (the dotted lines pointing to the wallet address indicate the sender of the transaction). The sender of the transaction in block 2 is node A, so the wallet address stored in block 2 is wallet address A, and `previous hash1` points to the previous block 1. Because 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 the same as block 2, node A. At the same time, block 2 is the block preceding block 3, so both `previous hash1` and `previous hash2` of block 3 point to block 2. Block 4 was generated by node C after block 3. The previous block sent by node C was block 1. Therefore, 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 are closely related and continuously send information to each other over a period of time, there will be frequent pointers between their previous hash1 of the blocks generated on the chain, such as blocks 6 to 10, which are connected sequentially by solid arrows.

[0062] Users are typically only interested in transactions relevant to themselves, and not in others. Therefore, lightweight nodes only need to store relevant transaction data to save storage space. Figure 3As shown, blocks 6, 8, and 10 stored in node E are generated sequentially by E. The value of the address stored in the wallet address within each block is walletaddress E. The same applies to the blocks stored in nodes C and B; blocks stored in the same node have the same walletaddress.

[0063] When a light node has surplus storage space, it can store not only its own transaction data but also data from nodes with close transaction relationships. For example, node D in the diagram stores not only its own blocks 7 and 9 but also blocks 6 through 10 from node E. When a node possesses significant storage capacity and can store transaction data from all nodes, it is considered a full node in an LSB (Less-Side Block).

[0064] To better leverage the advantages of lightweight storage, the concept of a user wallet is introduced in LSB, as 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 Wallet balance

[0067] LSB has two types of nodes: light nodes and full nodes. The wallets associated with these two types of nodes differ. The light node wallet only contains the node's own wallet address, the hash of the last block issued by the node, and the user's balance; the full node wallet contains the wallet addresses of all nodes. The user's wallet can be used to quickly query the node's transaction history, as follows:

[0068] 1) Enter the wallet address of the block you want to query, 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 using the last hash, and then iterate through all the blocks generated by the node using the previous hash (previous hash2) until the required transaction is obtained.

[0070] The reputation model is used in conjunction with the design of the core structure to realize the reward and punishment of nodes and the calculation of reputation value;

[0071] Specifically, the traditional DPoS consensus algorithm lacks a reward and punishment mechanism, leading some nodes to become malicious nodes in pursuit of profit, thus jeopardizing blockchain security. This embodiment introduces the concept of a reputation model to measure a node's specific performance on the chain, rewarding nodes that participate normally in consensus and punishing malicious nodes.

[0072] To better divide and manage the system, the nodes are divided into client nodes, consensus nodes, and candidate nodes, with consensus nodes further divided into proxy nodes and verification nodes.

[0073] 1) Client Nodes: Client nodes are special nodes in the blockchain. They do not store data or participate in information retrieval; their main function is to send data to other nodes. In this embodiment, client nodes are honest nodes established by the system.

[0074] 2) Proxy nodes: Proxy nodes are selected from the 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 Nodes: In LSB, lightweight nodes only store a portion of the entire chain structure, so the verification capability of a single lightweight node is limited. Full nodes hold a copy of the entire ledger and can independently check the validity of blocks; therefore, a subset of full nodes in the network are selected as verification nodes.

[0076] 4) Candidate Nodes: Nodes that are not selected to participate in the accounting process during this consensus cycle will become candidate nodes. Candidate nodes are ranked according to their reputation, and higher-ranked candidate nodes have a chance to become proxy nodes or validator nodes.

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

[0078] The reputation value is a specific manifestation of a node's honesty. The more stable and reliable a node is, the higher its reputation value, and the greater its probability of being selected as a consensus node. In this embodiment, a node's reputation value is related to its performance 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, and R i This represents the current reputation value of node i, with the maximum reputation value set to R. max W i It represents the proportion of equity held by the node, P i To represent the level of enthusiasm of nodes in participating in consensus, α and β are proportional adjustment parameters with values ​​ranging from (0,1).

[0082] In the DPoS consensus algorithm, the more stake a node holds, the greater its probability of being selected as a proxy node and gaining the opportunity to produce blocks, thus acquiring more benefits. This mechanism leads to nodes with a large amount of stake controlling the entire blockchain network, undermining the initiative and fairness of node voting competition. This embodiment addresses this problem by no longer using the stake held by a node as a determining factor influencing its participation in block production, but rather as a factor constituting part of its reputation value. This enhances the decentralization of the system and also incentivizes honest nodes with smaller stakes.

[0083] The formula for calculating the percentage of equity held by a node is as follows:

[0084]

[0085] In formula (2), W i w represents the weight of node i. i Where i is the amount of equity held by node i itself, and n is the total number of nodes. This represents the sum of the stake of all nodes, i.e., the total stake value in the system. Each time a node successfully participates in block production, it will receive a certain reward. The formula shows that the weight of a node is directly proportional to the amount of stake it possesses.

[0086] Node activity is a numerical standard for evaluating a node's performance in the network. A node's activity level increases as it actively participates in on-chain activities; conversely, if a node is passive, unproductive, or even malicious, undermining system security, its activity level will rapidly decline, reducing its probability of being elected as a consensus node. Nodes that repeatedly commit malicious acts will be removed from the system.

[0087] Determining whether a node is malicious is related to the number of times it exhibits anomalies. When a node behaves abnormally during the consensus process, its behavior is observed, and the cause of the anomaly is determined. Network instability can also prevent nodes from participating in consensus normally; this is not necessarily due to the node's active malicious intent, and therefore cannot be directly considered a malicious node. To prevent misjudgments, this embodiment introduces the concept of a "malicious factor." For a node exhibiting anomalies for the first time, no penalty is imposed; if a node exhibits anomalies repeatedly, the penalty is significantly increased.

[0088] The formula is as follows:

[0089]

[0090] In formula (3), x is the number of times a node is abnormal, and m is the malicious factor. When a 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 in voting enhances a node's reputation. Within the system, consensus nodes (both proxy and verification nodes) participate in the sending and verification of a transaction. Nodes with higher reputations are chosen for this role, so votes cast for consensus nodes are meaningful, while votes for other nodes are meaningless. Therefore, it is stipulated that votes cast for consensus nodes are valid, while votes cast for other nodes or no vote is invalid.

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

[0093]

[0094] In formula (4), when the consensus round is j, Let e ​​be the effective voting weight of node i in round j. i a represents the number of valid votes initiated by node i in this round. i It is the total number of votes held by node i.

[0095] The formula for calculating node activity is as follows:

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

[0097] Where P i This round of activity is a key indicator of the node's enthusiasm. It refers to the level of enthusiasm in the previous round at the node. This indicates the percentage of valid votes for a node in this round.

[0098] The formula for a node's reputation value is expanded as follows:

[0099]

[0100] As nodes actively participate in voting, their reputation gradually increases. Even nodes with low weight have a chance to be selected as consensus nodes to participate in block production. Conversely, if a node repeatedly commits malicious acts, its reputation will rapidly decline, making it difficult for it to be selected as a consensus node in the next cycle. The reputation model ensures that the generation and verification of blocks are handled by stable and reliable nodes, thus improving the system's security.

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

[0102] Furthermore, the consensus mechanism includes: selecting several light nodes as proxy nodes and several full nodes as verification nodes based on their reputation values; unselected nodes as candidate nodes for this round of consensus; and marking nodes with more than a threshold of abnormal occurrences as malicious nodes and clearing their reputation values. All nodes vote on the proxy nodes and verification nodes, and determine the block production order of the proxy nodes, the master node of the verification nodes, and the slave nodes of the verification nodes based on the number of votes. The validity of newly generated blocks by the proxy nodes is verified based on the verification nodes and the PBFT algorithm. If the verification passes, the block is allowed to be added to the chain until all proxy nodes have completed block production, ending this round of consensus. 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 and signs the transaction data to obtain a newly generated block, and sends the block to the client node. The client node adds the block to a request message and sends it to the master node of the verification node. After receiving the request message and verifying that the client's signature is correct, the master node sends a pre-prepare message to each slave node. Each slave node verifies the pre-prepare message. After successful verification, the master node broadcasts the prepare message to other verification nodes. Each verification node receives the prepare message and verifies it. If the verification is successful and the number of received prepare messages reaches 2f+1, the master node broadcasts a commit message to other verification nodes. Each verification node receives the commit message and verifies it. If the verification is successful and the number of received commit messages reaches 2f+1, the master node sends a reply message to the client. If the client receives f+1 reply messages, the verification is successful and the block is valid, where f represents the number of malicious nodes.

[0105] Furthermore, the process of updating the reputation value of each proxy node among the reliable nodes includes: after rewarding the reliable nodes with equity, calculating the reputation value of each reliable node, and if it reaches the maximum reputation value R... max If the number of abnormal occurrences exceeds the threshold, the corresponding node's activity level will be reset to zero. The number of abnormal occurrences for each node will be checked, and if it exceeds the threshold, it will be marked as a malicious node and its reputation level will be cleared to zero.

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

[0107] (1) Node partitioning

[0108] To ensure blockchain security, nodes with higher reputation values ​​will be prioritized for block production. Before the formal accounting activity begins, the system calculates the reputation value of nodes using the reputation value formula (1) and sorts light nodes and full nodes according to the value. Since newly joined nodes have not yet participated in on-chain activities, their node activity P is relatively low. i Since the initial reputation value of a node is 0, 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 selects the top M light nodes with the highest reputation scores as proxy nodes for this round. Correspondingly, validator nodes will be selected from the top N full nodes with the highest reputation scores. Nodes not selected will automatically become candidate nodes for this round of consensus. Nodes that repeatedly commit malicious acts will be marked by the system, their reputation scores will be cleared and cannot be increased in any way, and they will not be selected to participate in consensus.

[0110] (2) Node voting

[0111] In RP-DPoS, the on-chaining of blocks is not a one-step process. The generation and verification of blocks are completed by proxy nodes and verification nodes respectively. Therefore, voting is required for both types of nodes.

[0112] After the node categories are defined, the system initiates a vote. Nodes must cast their votes for the validator nodes and proxy nodes selected in this round (nodes can also vote for themselves). Proxy nodes determine the block production order based on the number of votes they receive, with nodes receiving more votes being prioritized for recording transactions. Once all proxy nodes have completed block production, this round of consensus ends. Accordingly, the validator node with the most votes becomes the master node N0 for block verification. The remaining validator nodes are then converted into slave nodes N1, N2, N3, and so on, in order of their vote count. The validator nodes form a committee to accept newly generated blocks and use the PBFT algorithm to verify their validity. Valid blocks are uploaded to the blockchain, while invalid blocks are discarded.

[0113] (3) Block on-chain

[0114] In DPoS, newly generated blocks by proxy nodes require confirmation from two-thirds of the witnesses, which significantly prolongs transaction confirmation time. To address this issue, validator nodes are added to RP-DPoS to verify the validity of blocks, thus reducing verification latency.

[0115] The proxy node packages and signs the transactions, and sends the block to the client node. To prevent malicious behavior by some validator nodes, the PBFT algorithm is used. The number of validator nodes N selected 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 Send to verifier node N0, where cRequest is the message type, t is the timestamp, c represents the client address, BlockData is the serialized block data, and σ... 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 nodes. The message structure is as follows:<cPrePrepare,m,d,s> σ p cPrePrepare is the message type, m stores the request sent by the client, d is the message digest, s represents the message sequence ID, and σ p It is the signature of the node.

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

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

[0120] (b) Whether the block's hash points to the correct value.

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

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

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

[0124] 6) When the client receives f+1 reply messages, it means that the verification is successful and the block is valid. 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 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 values ​​from holding block production rights for a long time, when the node's reputation reaches its maximum value R... max At that time, the node's activity value P in this round will be... i Reset to 0. Simultaneously check the node's anomaly count; when the anomaly count x reaches 5, mark it as a malicious node and reset its reputation score to 0.

[0127] View Change

[0128] In RP-DPoS, if a proxy node or slave node fails to respond within the specified maximum time, it is determined that the node timeout is caused by network problems or malicious behavior. The system will increase the node's abnormal count by x, which will be included in the next node reputation value settlement.

[0129] When the master node N0 encounters an anomaly, to prevent the slave nodes from waiting indefinitely, the slave node N1, which ranks last in votes among the verification nodes in this round, is automatically converted into a candidate 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 node verifies the received information, and if it is correct, it adds it to the message set. 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 set of verification nodes. The view change is successful, and the new view number is changed to v+1.

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

[0132]

[0133] The reward package includes a base reward B and an additional reward E, based on the node's current activity level P. i In reputation value R i The coefficient E is used to determine the percentage of a node that receives an additional reward; the base reward of a node is adjusted using 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 is the proxy node.

[0134] Experimental analysis

[0135] To simulate a real blockchain environment as closely as possible, this embodiment uses an Intel(R) Core(TM) i5-10400F CPU, 8GB of memory, and a 64-bit Windows 10 operating system for simulation experiments, and implements the RP-DPoS consensus algorithm using the GoLang language.

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

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

[0138] (1) Transaction query delay

[0139] The experiment compares the time required to query a specified transaction for three blockchain architectures: LSB, LDAGB, and DPoS. To ensure that the data is compared on the same dimension, 10 nodes are selected for each architecture to send and store transactions, and each block stores only one transaction.

[0140] exist Figure 5 The query latency for transactions was recorded when the number of transactions was 100, 200, 300, 400, and 500, and repeated 30 times. Experimental results show that the transaction query time for all three architectures increases linearly with the number of transactions. The increase for DPoS is significantly greater than the other two architectures. This is because DPoS requires traversing backwards from the latest block until a block containing the transaction is found, while LSB and LDAGB record the node's wallet address. Using the corresponding previous hash, only a portion of the chain structure needs to be traversed to find a specific transaction. Since LDAGB's previous hash involves both the sender and receiver of the transaction, while LSB only involves the sender, LSB requires fewer blocks to traverse than LDAGB when querying a specific transaction, resulting in the shortest query time.

[0141] By comparison, when the number of transactions reaches 500, LSB reduces transaction query latency by 89.8% compared to traditional blockchain architectures and by 45.6% compared to LDAGB architectures. This indicates that LSB has higher transaction query efficiency.

[0142] (2) Node storage overhead

[0143] To evaluate the impact of the lightweight architecture on storage overhead, this embodiment deploys 10 light nodes, each storing the same number of transactions. The storage overhead of light nodes and full nodes is recorded when the number of transactions is 10,000, 20,000, 30,000, 40,000, and 50,000.

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

[0145] (3) Block verification delay

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

[0147] Experimental results show that RP-DPoS verifies a single block in between 900ms and 1100ms, remaining relatively stable even when the number of proxy nodes increases to 30. In contrast, DPoS requires 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, a block needs confirmation from at least two-thirds of the proxies to reach an irreversible state, which significantly prolongs the confirmation time. In RP-DPoS, blocks are verified by selected nodes, with a verification latency of around 1 second. Furthermore, because block generation and verification are performed by different nodes, the verification latency does not change excessively with the increase of proxy nodes, thus improving the overall efficiency of the system.

[0148] (4) Reputation Value Test

[0149] This embodiment selects honest and reliable nodes that actively participate in voting to produce blocks using a reputation model. The reputation value is related to the node's own weight and its performance on the chain. To test the impact of node behavior on reputation value, representative normal nodes and malicious nodes were selected, and the changes in their reputation values ​​were recorded over five consensus rounds.

[0150] Depend on Figure 8It can be seen that normal nodes have an initial weight of 0, actively participate in voting and block production, and receive rewards in each round. Their reputation value steadily increases with each consensus round, increasing by approximately 0.2 per round. Malicious nodes have a higher initial weight of 0.25. After being selected as proxy nodes, they refuse to produce blocks, and after two rounds of consensus, their reputation value drops significantly to around 0.1, making it difficult for them to compete with other nodes. The experimental results show that even if a node has a low initial stake, positive behavior will help it gain a higher reputation value and have a chance to be selected as a proxy node. This indicates that the reputation model has an incentive effect on user nodes to some extent.

[0151] (5) Malicious Node Handling

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

[0153] like Figure 9 As shown, 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 decreasing trend with the increase of consensus rounds. The curve representing RP-DPoS fluctuates relatively steadily, and the proportion of malicious nodes is lower than that of DPoSDWE after the 7th round. When the consensus round reaches 19, the proportion of malicious nodes in RP-DPoS approaches 0. Experimental results show that the improved RP-DPoS can effectively suppress malicious nodes from participating in block production and improve system security.

[0154] (6) Block output throughput

[0155] To evaluate the efficiency of RP-DPoS in producing blocks, this embodiment compares the number of blocks produced by RP-DPoS and HL-DPoS within the same time period. The experiment recorded the number of blocks generated at five time spans: 10 min, 20 min, 30 min, 40 min, and 50 min.

[0156] like Figure 10As shown, both RP-DPoS and HL-DPoS have high throughput in block generation. At time 10 minutes, RP-DPoS generates 87 blocks, while QDPoSB generates around 50 blocks. Furthermore, the difference in the total number of blocks generated by the two algorithms gradually widens as time progresses from 10 minutes to 50 minutes. The comparison reveals that HL-DPoS produces a block approximately every 12 seconds, while RP-DPoS takes between 6 and 7 seconds. Therefore, the RP-DPoS algorithm has a more significant advantage in block generation efficiency.

[0157] (7) Comparison of Improvement Schemes

[0158] The following table summarizes the comparison between the improved DPoS consensus algorithms HADPoS, HL-DPoS, and DPoSDWE in recent years and the scheme in this embodiment. The comparison results are shown in Table 2 below.

[0159] Table 2

[0160]

[0161] By comparing with existing improvement schemes, it can be seen that this embodiment has improved in three aspects: suppressing malicious nodes, incentivizing nodes, and reducing block verification latency, thereby enhancing the overall efficiency and security of the blockchain system.

[0162] (8) Application Scenarios

[0163] Blockchain technology offers the possibility of establishing reliable messaging and privacy protection in the Internet of Vehicles (IoV). However, with the increasing scale of these systems, many devices, such as mobile phones and in-vehicle systems, are finding it difficult to handle large-capacity blockchain copies. LSB inherits the advantages of traditional blockchain while avoiding excessive reliance on storage resources.

[0164] Taking in-vehicle systems as an example, in emerging in-vehicle social networks, drivers obtain various daily messages through social software, such as traffic information, social updates, 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. Furthermore, with the continuous growth of data volume and the increasing variety of data types, data classification and selective storage become particularly important. In LSB (Limited Block Storage), different information can be categorized by wallet address. For example, in an in-vehicle network, messages sent by newspaper A can be stored in light node A corresponding to wallet address A. Similarly, news from newspaper B is stored in light node B. Drivers who prefer newspaper A can quickly search for all news sent by newspaper A and download it to their in-vehicle system using only wallet address A, instead of backing up the entire chain.

[0165] Security Analysis

[0166] This embodiment introduces concepts such as node activity and malicious factor to select honest and reliable nodes to participate in block production, and uses the PBFT consensus method to verify whether the block is legitimate, thus ensuring system security.

[0167] In traditional blockchain architectures using the DPoS consensus algorithm, the selection of proxy nodes is related to the number of votes held by each node. Malicious nodes can bribe nodes with high stakes to vote for them, launching a bribery attack. In LSB, stake is only one part of a node's reputation value. Nodes, for their own benefit, tend to vote for nodes with high reputation values, making bribery attacks difficult to execute.

[0168] LSB also possesses immutability because it inherits the decentralized nature 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 are linked by hash values ​​to previous blocks. Once a transaction is tampered with, the hash within the block will also be changed. Nodes determine whether the data has been tampered with based on the pointer of the previous hash.

[0169] Attackers can also gain control of the entire blockchain network by creating multiple nodes to join it; this is known as a Sybil attack. In LSB, node selection is determined by reputation value. New nodes created by attackers have a weight and activity level of 0 and will not be selected as consensus nodes, effectively preventing Sybil attacks.

[0170] A malicious node might send the same transaction twice, attempting to fork the blockchain and achieve a double-spending attack. In an LSB (Local Blockchain Service), blocks produced by proxy nodes are received by client nodes and sent to validator nodes to run the PBFT algorithm to determine the correctness of the block height and hash value, thus preventing double-spending.

[0171] To avoid excessive centralization, LSB introduces concepts such as node weight and activity level into its reputation value model to comprehensively evaluate node performance. This weakens the connection between node selection and weight in traditional DPoS, preventing high-weight nodes from holding block production rights for a long time. At the same time, it incentivizes ordinary nodes to participate in consensus, fully mobilizing the enthusiasm of nodes and promoting the fairness and impartiality of the system.

[0172] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A lightweight blockchain architecture based on the sender, characterized in that, This includes a core structure, a reputation model, and a consensus mechanism; the consensus mechanism is constructed based on reputation and PBFT. The core structure includes several nodes, which include light nodes and full nodes. Each light node stores blocks that are related to itself. The sender's wallet address is recorded when each block is built; the hash value of the latest block generated by each node is stored in the node user's wallet; The reputation model is used in conjunction with the design of the core structure to realize the reward and punishment of nodes and the calculation of reputation value; The consensus mechanism is used to select reliable nodes based on reputation value to perform block generation and verification operations, and to update the reputation value of each proxy node among the reliable nodes after the consensus period ends.

2. The lightweight blockchain architecture based on the sender as described in claim 1, characterized in that, Each block also includes the block's hash value, the block's timestamp, the transaction sent by the user, and the block's preceding address; there are two preceding addresses, one for the previous block and the other for the previous block sent by the same sender.

3. The lightweight blockchain architecture based on the sender as described in claim 2, characterized in that, The light node stores the blocks it constructs and the blocks constructed by the light node whose mutual pointing to the preceding address meets the requirement; the full node stores the blocks under all nodes; and the user wallet corresponding to each node also stores the wallet balance.

4. The lightweight blockchain architecture based on the sender as described in claim 1, characterized in that, The reputation model calculates rewards and penalties for nodes on the blockchain and their reputation values ​​by constructing a node reputation value calculation formula, which is as follows: R i =α·W i +β·P i ; In the formula, i represents the subscript of the node, and R i This represents the current reputation value of node i, with the maximum reputation value set to R. max W i It is the percentage of equity held by the node, P i For node activity, α and β are proportional adjustment parameters with values ​​ranging from (0,1); w i Where i is the amount of equity held by node i itself, and n is the total number of nodes. This represents the sum of the stakes of all nodes.

5. The lightweight blockchain architecture based on the sender as described in claim 4, characterized in that, The formula for calculating the node's activity level is as follows: P i =m·(P i j-1 +V i j ); In the formula, P i This round of activity is a key indicator of the node's enthusiasm. It refers to the level of enthusiasm in the previous round at the node; e represents the percentage of valid votes for a node in this round. i a represents the number of valid votes initiated by node i in this round. i is the total number of votes held by node i; m is the evil factor.

6. The lightweight blockchain architecture based on the sender as described in claim 5, characterized in that, The evil factor is represented as follows: In the formula, x is the number of times a node is an anomaly.

7. The lightweight blockchain architecture based on the sender as described in claim 5, characterized in that, The consensus mechanism includes: selecting several light nodes as proxy nodes and several full nodes as verification nodes based on their reputation values; unselected nodes as candidate nodes for this round of consensus; and marking nodes with more than a threshold of abnormal occurrences as malicious nodes and clearing their reputation values. All nodes vote on the proxy nodes and verification nodes, and determine the block production order of the proxy nodes, the master node of the verification nodes, and the slave nodes of the verification nodes based on the number of votes. The validity of newly generated blocks by the proxy nodes is verified based on the verification nodes and the PBFT algorithm. If the verification passes, the block is allowed to be added to the chain until all proxy nodes have completed block production, ending this round of consensus. The number of verification nodes is obtained based on the number of malicious nodes.

8. The lightweight blockchain architecture based on the sender as described in claim 7, characterized in that, The process of verifying the legitimacy of a block includes: The proxy node packages and signs the transaction data to obtain a newly generated block, and sends the block to the client node. The client node adds the block to a request message and sends it to the master node of the verification node. After receiving the request message and verifying that the client's signature is correct, the master node sends a pre-prepare message to each slave node. Each slave node verifies the pre-prepare message. After successful verification, the master node broadcasts the prepare message to other verification nodes. Each verification node receives the prepare message and verifies it. If the verification is successful and the number of received prepare messages reaches 2f+1, the master node broadcasts a commit message to other verification nodes. Each verification node receives the commit message and verifies it. If the verification is successful and the number of received commit messages reaches 2f+1, the master node sends a reply message to the client. If the client receives f+1 reply messages, the verification is successful and the block is valid, where f represents the number of malicious nodes.

9. The lightweight blockchain architecture based on the sender as described in claim 8, characterized in that, The process of updating the reputation value of each proxy node in the reliable nodes includes: after rewarding the reliable nodes with equity, calculating the reputation value of each reliable node, and if it reaches the maximum reputation value R... max If the number of abnormal occurrences exceeds the threshold, the corresponding node's activity level will be reset to zero. The number of abnormal occurrences for each node will be checked, and if it exceeds the threshold, it will be marked as a malicious node and its reputation level will be cleared to zero.

10. The lightweight blockchain architecture based on the sender according to claim 9, characterized in that, The formula for the equity reward is as follows: The reward package includes a base reward B and an additional reward E, based on the node's current activity level P. i In reputation value R i The coefficient E is used to determine the percentage of a node that receives an additional reward; the base reward of a node is adjusted using 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 is the proxy node.

Images