Blockchain Architecture for Lightweight Storage

Abstract

Aiming to address the shortcomings of traditional blockchain technologies, characterized by high storage redundancy and low transaction query efficiency, we propose a lightweight sender-based blockchain architecture (LSB). In this architecture, the linkage between blocks is associated with the user initiating the transaction, and the hash of the newly generated block is recorded in the user’s wallet, thereby facilitating transaction retrieval. Each user node must store only the blocks that pertain to it, significantly reducing storage costs. To ensure the normal operation of the system, the Delegated Proof of Stake based on Reputation and PBFT (RP-DPoS) consensus algorithm is employed, establishing a reputation model to select honest and reliable nodes for consensus participation while utilizing the Practical Byzantine Fault Tolerance (PBFT) algorithm to verify blocks. The experimental results demonstrate that LSB reduces storage overhead while enhancing the efficiency of querying and verifying transactions. Moreover, in terms of security, it decreases the likelihood of malicious nodes being designated as agent nodes, thereby increasing the chances of honest nodes being selected for consensus participation.

1. Introduction

The blockchain concept was first proposed by Haber and Stornetta and is considered one of the most promising technologies [1]. Subsequently, Satoshi Nakamoto introduced Bitcoin [2], which propelled the blockchain trend to its peak. The core technology of blockchain is designed to facilitate peer-to-peer electronic transactions and data storage, enabling multiple participants to share ledger contents and synchronize them through community verification [3]. This technology has been extensively utilized in finance, transportation, education, healthcare, cybersecurity [4], and management science due to its decentralization, high reliability, data integrity, and traceability [5].

Nodes in the blockchain jointly maintain a distributed ledger that globally records events, utilizes asymmetric encryption algorithms to secure user transactions, and employs consensus algorithms to ensure orderly transaction execution [6]. As a distributed ledger, blockchain not only possesses inherent advantages in data processing [7], but its decentralized feature also addresses the limitations of traditional transactions, where confirmation and recording entirely rely on trusted institutions, thereby enhancing trust and improving transaction transparency [8].

As information technology advances, blockchain is evolving across multiple dimensions. Regarding consensus, Lu introduced a novel multi-chain method, MC-RHotStuff [9], which screens nodes based on performance and dynamically adjusts node numbers to enhance system throughput. Kenza proposed the adaptive PBFT protocol, APBFT [10], which minimizes communication overhead and response delay. David introduced Helix [11] to ensure fair transaction ordering among nodes in distributed networks, while Na introduced DPNPBFT [12], aiming to balance complexity, efficiency, and security. In storage, some scholars achieve lightweight solutions by restructuring blockchain, as seen in LDAGB [13] and LDV [14]. Additionally, researchers reduce blockchain storage redundancy through techniques like corrective deletion codes [15], sharding [16], data compression [17], and offloading [18].

In the era of big data, blockchain must enhance its processing and analytical capabilities for data querying. Zhou introduced a blockchain-based lightweight searchable data-sharing scheme, BLDSS [19], which combines public key encryption with equivalence testing and agent re-encryption features to facilitate efficient data matching and sharing. Chen monitors the execution of transactions without disrupting the operation of the smart contract by establishing a recording replay mechanism in the contract container [20]. Wang introduces MSMLI [21], which constructs a composite index through a weight matrix and slices the blockchain according to the mainchain structure, thereby enhancing query efficiency while minimizing storage overhead.

Although blockchain technology has great potential and many advantages, there are still numerous aspects requiring optimization and enhancement [22]. Over time, due to its immutable nature, data accumulates on the blockchain, and the performance of the blockchain network is hindered by the uncontrolled growth of the blockchain ledger [23], which is essentially a performance bottleneck due to the lack of blockchain scalability [24]. The network also suffers from poorly motivated nodes, node failures, or malicious nodes tampering with the data, thereby compromising data consistency.

To address the above issues, this paper proposes a lightweight sender-based blockchain architecture (LSB) to optimize the storage structure and consensus mechanism of the blockchain. The contributions of this paper to the existing literature are outlined as follows:

• Enhanced efficiency of transaction queries. The hash in the block is linked to the transaction sender, and the newly generated block will point to the block with the same wallet address, allowing for rapid transaction queries via the node wallet.
• Lightweight storage implemented. Lightweight nodes store only blocks sent by themselves, thereby minimizing storage overhead.
• Reduced system risk. Establishing a reputation value model to comprehensively assess node behavior minimizes the likelihood of malicious actions.

This paper is structured as follows: In Section 2, the lightweight sender-based blockchain architecture (LSB) is proposed. In Section 3, the reputation model of nodes is discussed. Section 4 details the consensus process of the blockchain system. The performance and security of LSB are analyzed and evaluated in Section 5 and Section 6. Finally, this paper concludes in Section 7.

2. LSB Framework

This chapter focuses on the specific framework of LSB, which will be detailed regarding the internal structure of blocks, the overall structure of the blockchain, and the implementation of lightweight storage.

2.1. LSB Structure

The structure of the blocks in the LSB structure is illustrated in Figure 1 below:

• hash: the hash value of the block, derived from the block’s transaction, timestamp, and previous hash.
• timestamp: based on the generation time of the blocks, establish the sequence of blocks preceding and following.
• transaction: transactions initiated by users to facilitate the exchange of assets, information, or services.
• wallet address: store the user’s wallet address associated with the block.
• previous hash: each block contains two previous hashes, previous_hash1, linked to the prior-generated block, and previous_hash2, associated with the relevant user.

Figure 1. Block structure.

Figure 1. Block structure.

In traditional blockchain platforms like Bitcoin, each node must store a complete copy of the ledger to ensure decentralization. However, users often prioritize transactions relevant to them over irrelevant ones. In contrast, the previous hash in the LSB points to the user’s wallet address, allowing the node to store only a partial copy of the ledger. The structure of the LSB is shown in the following figure:

Figure 2 illustrates five nodes—A, B, C, D, and E—which sequentially correspond to wallet addresses A through E. The nodes generate 10 blocks, connected by directed edges. The arrows between the blocks indicate the order of their generation. For instance, if block 2 points to block 1, it signifies that block 2 was generated after block 1. Similarly, if block 4 points to block 1, it indicates that block 1 was generated before block 4.

In blockchain, most users primarily focus on their transaction information. Consequently, the address of the transaction sender is stored in the wallet address. When a new block is generated, it points to the previous block in chronological order with a solid directed edge while also pointing to the previous block generated by the same sender with a dashed directed edge. Block 1, illustrated in Figure 2, functions as the genesis block. Since there is no predecessor, the values of previous_hash1 and previous_hash2 are set to null (the dotted line in the block, which points to the wallet address, indicates the sender of the transaction). The sender for block 2 is node A, so the wallet address in block 2 is wallet_address A. The previous_hash1 points to the previous block 1, and since block 2 is the first block generated by node A, a null value is assigned to previous_hash2. Similar to block 2, block 7 also exists. The sender for block 3 is node A, consistent with block 2. Meanwhile, block 2 serves as the previous block for block 3; thus, both previous_hash1 and previous_hash2 in block 3 point to block 2. Block 4 is generated by node C after block 3, with the last block sent by node C being number 1, resulting in the wallet address in block 4 being wallet_address C, previous_hash1 pointing to block 3, and previous_hash2 pointing to block 1.

If there exists a close relationship between two nodes, D and E, and both continue to exchange messages over some time, there will be frequent references to each other’s previous_hash1 in the blocks generated on the chain; for example, blocks 6 to 10 are sequentially connected by solid arrows.

2.2. Lightweight Storage

Users are typically only interested in transactions pertinent to them; thus, light nodes only need to retain relevant transaction data to optimize storage. As demonstrated in Figure 3, the ellipse enclosed by dashed lines represents the blocks stored by a single node; blocks 6, 8, and 10 stored in node E are generated successively by this node. The wallet address stored within the block corresponds to wallet_address E. This also applies to the blocks stored in nodes C and B, where blocks stored within the same node share the same wallet address.

When a light node has additional storage capacity, it can store not only its own transaction data but also the data of a node with which it maintains a close transactional relationship. If a close transactional relationship exists between node D and node E, node D can store the blockchain ledger of node E, provided it has sufficient storage space after storing its issued blocks 7 and 9. A node is classified as a full node in LSB when it has adequate storage capacity to retain the transaction data of all nodes.

2.3. Wallet Structure

To more effectively leverage the benefits of lightweight storage, the concept of a user wallet is introduced in LSB, and the structure of this wallet is illustrated in the subsequent

Table 1. Wallet structure.

Element	Description
wallet_address	user’s wallet address
last_hash	the hash of the latest block generated by the node
amount	balance inside the wallet

.

In LSB, there are two types of nodes: light nodes and full nodes. The wallets associated with these two types differ. The light wallet linked to a light node contains only the node’s wallet address, the hash of the most recent block issued by the node, as well as the user’s balance. In contrast, the full node wallet includes the wallet addresses of all nodes. The user wallet enables quick querying of the node’s transaction records through the following steps:

Input the wallet address of the block to be queried and retrieve the hash of the most recent block generated by the node from the corresponding wallet.

Locate the last block sent by the node using the last hash and traverse all blocks generated by that node using previous_hash2 until the desired transaction is retrieved.

3. Reputation Model

The lack of a reward and punishment model in traditional DPoS consensus allows some nodes to become malicious to gain benefits, jeopardizing the security of the blockchain. In this paper, we introduce the concept of reputation value, which rewards nodes that participate normally in the consensus and punishes those that act maliciously.

3.1. Types of Nodes

For improved organization and management, LSB categorizes nodes into client nodes, consensus nodes, and candidate nodes, with consensus nodes further classified into agent nodes and verification nodes.

• client node: The client node, as a specialized entity in the blockchain, does not store data or participate in information retrieval; rather, it primarily serves to transmit data to other nodes. In this paper, client nodes are characterized as honest nodes established by the system.
• agent node: Agent nodes are selected from light nodes with high reputations to gather transaction information and generate blocks according to a predetermined schedule but do not participate in block verification.
• verification node: In LSB, lightweight nodes store only part of the structure of the whole chain; therefore, a single lightweight node’s ability to verify transactions is limited. A full node holds a complete copy of the ledger and can independently verify the legitimacy of a block; thus, a full node within the network is chosen as the verification node.
• candidate node: Nodes not selected to participate in the bookkeeping for the current consensus cycle become candidate nodes. These candidate nodes are ranked based on their reputation, and the top-ranked candidates have the potential to transform into agent nodes or verification nodes.
• malicious nodes: nodes that have engaged in malicious behavior repeatedly are flagged by the system and are excluded from consensus participation.

3.2. Reputational Value

The size of the reputation value reflects a node’s honesty: the more stable and reliable a node is, the higher its reputation value and the greater the probability of it being selected as a consensus node. In this paper, a node’s reputation value is linked to its performance on the chain and its weight.

The calculation formula is as follows:

$$Ri=\alpha \cdot Wi+\beta \cdot Pi$$

(1)

As illustrated in Equation (1), the reputation value of node i is influenced by the weight of its equity holding, W_i, and its active performance in participating in the consensus, P_i. α and β are proportionality coefficients that regulate the relationship between the parameters and can vary within a specified range.

3.3. Node Weights

In DPoS, the greater the number of interests a node holds, the higher the probability that it will be selected as an agent for block creation, thereby increasing its benefits. This mechanism results in nodes with substantial interests consistently dominating the blockchain network, thereby undermining the initiative and fairness of node voting. In this paper, improvements have been implemented to address this issue, wherein the interests held by a node are no longer a determining factor for its participation in block production; instead, they contribute to the reputation value. This change enhances the system’s degree of decentralization and incentivizes honest nodes with smaller interests.

Node weights are calculated according to the following formula:

$$Wi={\displaystyle \frac{wi}{{\displaystyle {\sum }_{i=1}^{n}wi}}}$$

(2)

Node i holds interests of size w_i. To calculate the weight of node i, it is essential to know the total interests of all nodes, assuming there are n nodes in the system. The total interest value in the system is denoted by ${\displaystyle {\sum }_{i=1}^{n}wi}$. The weight of node i and the size of the interests it holds are directly proportional, as can be derived from the formula.

3.4. Node Positivity

The positivity degree is a numerical criterion used to evaluate a node’s performance in the network. If a node actively participates in on-chain activities, its positivity degree will increase. Conversely, if a node is passive or engages in malicious behavior that undermines system security, its positivity degree will decline rapidly, thereby reducing its likelihood of being selected as a consensus node. Nodes that consistently exhibit malicious behavior will be removed from the system.

Determining whether a node is malicious is contingent upon the number of anomalies exhibited by the node. When a node exhibits abnormal behavior during the consensus process, its actions will be monitored to ascertain the cause of the abnormality. Instability in the network environment may prevent a node from participating in the consensus process effectively; this does not imply malicious intent on the part of the node, and therefore it cannot be classified as a malicious node. To mitigate the risk of misjudgment, this paper introduces the concept of the evil-doing factor, which does not penalize a node for its first instance of abnormal behavior. However, if a node exhibits abnormal behavior multiple times, the penalties will be significantly increased.

The formula is as follows:

$$m\left\{\begin{array}{l}{x}^{-3},x>0\\ 1,x=0\end{array}\right.$$

(3)

When the node experiences its first abnormality, the anomaly count x will increase by one, from 0 to 1, and the evil-doing factor m will be set to 1. At this stage, there is no impact on the node’s reputation value. However, if abnormal behaviors occur again in the subsequent consensus process, the value of x will exceed 1, and m will decrease rapidly, weakening the growth of the node’s reputation. Once the anomaly count x reaches 5, the node will be classified as malicious, and its reputation value will be reset to 0.

Active participation of nodes in voting enhances their reputation. In the system, consensus nodes (agent and verification nodes) are responsible for sending and verifying transactions. Consequently, votes cast for consensus nodes are significant, while votes cast for other nodes are deemed insignificant. Therefore, it is specified that votes directed towards consensus nodes are valid, while votes cast for other nodes or abstentions are considered invalid.

The formula for calculating the weight of valid votes is as follows:

$$V_i^{\mathrm{j}}={\displaystyle \frac{e_i}{a_i}}$$

(4)

In the j-th consensus round, let α_i represent the number of votes that node i holds in this round, and let e_i denote the number of valid votes cast. The ratio of valid votes to the total number of votes determines the weight of the node’s valid votes in the j-th round.

The formula used to calculate node positivity is as follows:

$$P_i=m\cdot (P_i^{j-1}+V_i^j)$$

(5)

where P_i represents the node’s positivity for the current round, $P_i^{j-1}$ represents the node’s positivity for the previous round, and $V_i^j$ denotes the proportion of valid votes for the node in the current round.

3.5. Equity Reward

The block is successfully uploaded to the chain, and the nodes participating in this block receive a certain amount of equity as a reward. The formula for the equity reward is as follows:

$$Rewar{d}_i=c\cdot B+{\displaystyle \frac{\beta \cdot Pi}{Ri}}\cdot E$$

(6)

The rewards obtained by nodes are divided into two parts: the base reward B and the extra reward E. The coefficient for the extra reward E is linked to the proportion of the node’s positivity P_i and its reputation value at that moment (Equation (6) has the same value of β as in Equation (1)), encouraging honest behavior to yield more rewards. The number of blocks different types of nodes participate in during a consensus cycle varies, and the coefficient c adjusts the base reward for each node. The formula is as follows:

$$c\left\{\begin{array}{l}{b}^{-1},agent node\\ 1,verification node\end{array}\right.$$

(7)

As shown in Equation (7), b represents the planned number of blocks produced in a consensus cycle. The same agent node participates in block packing only once per consensus cycle, so the coefficient c is set to 1. The verification node participates in the verification of a total of b blocks in a consensus round, adjusting c to b⁻¹.

As nodes actively participate in voting, their reputation values will gradually increase. Even if their weight is low, they still have a chance to be selected as a consensus node to participate in the block. Conversely, if a node engages in malicious behavior, its reputation value will decline rapidly, making it difficult to be selected as a consensus node in the next cycle. The reputation model ensures that block generation and verification behaviors are carried out by stable and reliable nodes, which improves the security of the system.

The formula for the reputation value of a node can be derived as follows:

$$Ri=\alpha \cdot {\displaystyle \frac{wi}{{\displaystyle {\sum }_{i=1}^{n}wi}}}+\beta \cdot m\cdot (P_i^{j-1}+{\displaystyle \frac{e_i}{a_i}})$$

(8)

4. Consensus Process

Assuming that M agent nodes and N verification nodes are selected to participate in block production during a consensus cycle, the RP-DPoS consensus mechanism can be specifically divided into four steps: node division, node voting, block on chain, and settling node reputation values.

4.1. Node Division

To protect the security of the blockchain, nodes with the highest reputation values are prioritized for block production. Before accounting activities begin, the system calculates the reputation value of a node using the reputation value formula Equation (1) and ranks both light nodes and full nodes based on their values. Since newly joined nodes do not participate in accounting activities and have a node positivity P_i of 0, their initial reputation values are solely determined by their weights W_i.

As shown in Figure 4, agent nodes are served by light nodes, and the system will select the top M light nodes with the highest reputation values as the agent nodes for this round. Similarly, the verification node will be chosen from the N full nodes with the highest reputation values, and unselected nodes will automatically be classified as candidate nodes for this round of consensus. Nodes that repeatedly engage in malicious behavior will be flagged by the system, resulting in the loss of their reputation value, preventing any further growth, and they will not be eligible to participate in the consensus.

4.2. Node Voting

In RP-DPoS, the block accounting process is not completed overnight. The generation and verification of the block are performed by the agent node and the verification node, respectively; thus, voting must occur for both types of nodes. The node voting process is shown in Figure 5.

After dividing the node categories, the system initiates a voting process, and nodes must vote for the verification and agent nodes nominated in this round (nodes can vote for themselves). Agent nodes determine the order of blocks based on the number of votes received, with the node receiving the most votes taking priority for bookkeeping. Once all agent nodes finalize the blocks, the consensus round concludes. Accordingly, the verification node with the highest number of votes acts as the master node N0 for block verification, while the remaining verification nodes are assigned as slave nodes N1, N2, and N3 based on the number of votes. The verification nodes form a committee to accept the newly generated blocks and use the PBFT algorithm to verify their legality. The blocks are uploaded to the chain if deemed legal; otherwise, they are discarded.

4.3. Block on Chain

Newly generated blocks by agent nodes in DPoS must be validated by 2/3 of the witnesses [25], thereby significantly prolonging the transaction confirmation time. To address this issue, a verification node has been introduced into RP-DPoS to verify the legitimacy of the block, thereby reducing the verification delay.

In Figure 6, the dotted line shows the set of verification nodes and indicates the sequential steps of the consensus with numbers. The agent node packages and signs the transaction and transmits the block to the client node. To mitigate the risk of malicious verification nodes, the PBFT algorithm is employed. The number of selected verification nodes, denoted as N, must satisfy the condition N ≥ 3f + 1, where f represents the number of malicious nodes. The block verification steps are as follows:

The client will temporarily save the block data and send them to the authentication node N0 by appending it to the request message <cRequest, t, c, BlockData> σ_c. Here, cRequest represents the type of message sent, t is the timestamp, c indicates the client’s address, BlockData is the serialized block data, and σ_c is the client’s signature on the message.

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, structured as <cPrePrepare, m, d, s> σ_p. In this structure, cPrePrepare represents the type of message being sent, m contains the client’s request, d is the message digest, s indicates the message’s serial number, and σ_p is the signature of the node.

After receiving the pre-prepare message, the verification node confirms whether the signature, the message summary, and the serial number match, and if no errors are found, it verifies the legality of the block. The verification rules are as follows:

• Verify whether the block height matches the height of the agent node.
• Verify whether the hash of the block is correctly pointing.

Upon satisfying the aforementioned conditions, the node broadcasts a prepare message to the other verification nodes in the form of <cPrepare, v, d, s, i> σ_i, where v represents the view number and i denotes the node number.

The node receives the prepare message, verifies the signature, and ensures the consistency of v, d, and s. It then broadcasts the commit message <cCommit, v, d, s, i> σ_i to the other verifying nodes after receiving a total of 2f + 1 messages, including its own.

The node receives the commit message and validates it according to the same rules as in step 4. When the number of messages received reaches 2f + 1, the node sends a reply message to the client.

The client receives f + 1 commit messages, indicating that verification has passed and the block is legal. The client node broadcasts the previously saved block to other nodes and then deletes the block data to initiate the next verification round.

4.4. Reputation Settlement

At the end of the current consensus cycle T, the system updates the node’s reputation based on its performance through Equation (1) to prevent high-reputation nodes from monopolizing block rights for extended periods. If a node’s reputation reaches the maximum value R_max, its positivity degree P_i for the current round is reset to 0. Additionally, if the abnormality count x reaches 5, the node is marked as malicious, and its reputation degree is reset to 0.

4.5. View Change

In RP-DPoS, if an agent node or a slave node fails to respond within the specified maximum time, the timeout is attributed to either a network issue or potential node mischief. The system increases the node’s anomaly count by x to be considered in the next reputation settlement.

When an exception occurs in the master node N0, to prevent slave nodes from waiting indefinitely, the slave node N1, which is trailing in votes among verification nodes this round, is automatically promoted to an alternative node, initiating a view change.

As illustrated in Figure 7, in this round of view v, the slave node broadcasts a view-change message to notify the other nodes that the current view has failed and needs to be switched to a new view. The node verifies the received message and responds with an acknowledgment message, view-change-ack, if there are no errors. Once the alternative node N1 receives 2f + 1 acknowledgment messages, it broadcasts a new-view message, announcing that the new-view switch has been completed. The view change is successful, and the new-view number is incremented to v + 1.

5. Evaluation

To simulate a realistic blockchain environment, this study utilizes an Intel(R) Core(TM) i5-10400F CPU (Intel corporation, Santa Clara, CA, USA), 8 GB of RAM (Corsair Memory, San Jose, CA, USA), and a 64-bit Windows 10 operating system for simulation experiments, implementing the RP-DPoS consensus algorithm in the Go programming language.

To simulate the behavior of nodes within the blockchain, the system generates a total of 200 account nodes on the same host computer to participate in the selection of consensus nodes. The generated blocks are stored as key–value pairs in the BoltDB database that accompanies the integrated development environment, GoLand 2021.3.

Considering these factors, the performance of LSB is evaluated in terms of transaction query latency, storage space overhead comparison, malicious node removal efficiency, and additional aspects.

5.1. Transaction Query Latency

The experiment compares the time taken by the three blockchain architectures LSB, LDAGB, and DPoS when querying a specific transaction to ensure a comparable dataset. Ten nodes are selected for each architecture to send and store transactions, with only one transaction per block.

In Figure 8, the query latency of transactions is measured for transaction counts of 100, 200, 300, 400, and 500, repeated 30 times. The experimental results show that the transaction query time of the three architectures linearly increases with the number of transactions, with DPoS exhibiting a significantly larger increase than the other two architectures, due to DPoS needing to traverse from the newest block forward until it locates the block containing the transaction, whereas in both LSB and LDAGB, the node’s wallet address is recorded, allowing traversal through the corresponding previous hash to locate a specific transaction more efficiently. The previous hash in LDAGB includes both the sender and receiver of the transaction, while in LSB, it includes only the sender. As a result, LSB traverses fewer blocks than LDAGB when querying for a specific transaction, resulting in the shortest query time.

By comparison, when the number of transactions reaches 500, the transaction query latency of LSB is reduced by 89.8% compared to traditional blockchain architecture and by 45.6% compared to the LDAGB architecture. This indicates that LSB exhibits higher transaction query efficiency.

5.2. Comparison of Node Storage

To evaluate the impact of lightweight architecture on storage overhead, this paper deploys a total of 10 light nodes; each light node stores an equal number of transactions, recording the storage overhead for both the light nodes and the full nodes at transaction counts of 10,000, 20,000, 30,000, 40,000, and 50,000.

As shown in Figure 9, with the increase in the number of transactions, the storage space required by the node linearly rises, but the growth of the light node is much smaller than that of the full node. A single transaction in the LSB is approximately 200 bytes; by the time the number of transactions reaches 50,000, the storage overhead for the full node is around 10 MB, while the light node is under 1 MB. Compared to traditional blockchain architecture, the storage overhead of LSB is reduced by approximately 90%; this is because the light node only needs to store the transactions sent by the node itself, resulting in significant space savings.

5.3. Block Verification Latency

To evaluate the efficiency of block verification in RP-DPoS, this paper tests the block verification latency of both RP-DPoS and DPoS in the same environment, deploying agent nodes in quantities of 10, 15, 20, 25, and 30, and recording the confirmation times of the blocks across these varying node counts.

In Figure 10, experimental results indicate that RP-DPoS verifies a single block in 900 ms to 1100 ms, remaining relatively stable as the number of agent nodes increases to 30. In contrast, DPoS requires tens of seconds for block validation, with the validation time gradually increasing with more agent nodes. This delay occurs because traditional DPoS requires confirmation from at least 2/3 of the agents to achieve an irreversible state, significantly prolonging block confirmation times. In RP-DPoS, blocks are verified by elected nodes, resulting in a verification delay of around 1 s; since block generation and verification are handled by different nodes, this delay remains relatively unchanged as the number of agent nodes increases, thereby enhancing the overall system efficiency.

5.4. Reputation Value Test

In this paper, nodes that are honest, reliable, and actively participate in voting are selected for block production through a reputation model. The size of the reputation value is determined by the node’s weight and its performance on the chain. To evaluate the impact of node behavior on reputation values, representative normal and malicious nodes are selected, and the changes in their reputation values are recorded over five consensus rounds.

As illustrated in Figure 11, normal nodes have an initial weight of 0. They actively participate in voting and block production and are rewarded with equity in each round; consequently, their reputation value steadily increases over the consensus rounds, rising by approximately 0.2 in each round. Malicious nodes possess a higher initial weight of 0.25 but refuse to participate in block production after being selected as agent nodes, resulting in their reputation plummeting to approximately 0.1 after two consensus rounds, which significantly hinders their ability to compete with other nodes. The experimental results indicate that even when a node possesses a low initial equity, positive behavior can enhance its reputation value and increase the likelihood of being selected as an agent node, suggesting that the reputation model serves as an incentive for user nodes to some extent.

5.5. Malicious Node Removal

RP-DPoS employs a reputation model to select agent nodes. To assess its effectiveness in eliminating malicious nodes, 25% of the agent nodes are designated as malicious. This study records the percentage of malicious nodes among the agent nodes over 30 consensus rounds, as well as compares it with DPoSDWE [26] and traditional DPoS consensus algorithms.

As illustrated in Figure 12, the traditional DPoS consensus algorithm fails to implement effective measures against malicious nodes, maintaining a proportion of around 20% among the agent nodes. In contrast, the proportion of malicious nodes in RP-DPoS and DPoSDWE demonstrates a clear downward trend as the number of consensus rounds increases. The fluctuations of the RP-DPoS curve are more stable, and its proportion of malicious nodes is lower than that of DPoSDWE after the 7th round, approaching 0 by the 19th round. These experimental results indicate that the enhanced RP-DPoS effectively inhibits the participation of malicious nodes in out-of-block activities, thereby improving system security.

5.6. Throughput Analysis

To evaluate the efficiency of RP-DPoS in block production, this paper compares RP-DPoS with HL-DPoS [27] regarding the number of blocks generated within identical periods. The experiments measure the number of blocks generated over five specific intervals: 10 min, 20 min, 30 min, 40 min, and 50 min.

In Figure 13, both RP-DPoS and HL-DPoS demonstrate high throughput in block generation. At the 10 min mark, RP-DPoS generates 87 blocks, while QDPoSB produces approximately 50 blocks; the difference in the total number of blocks generated by the two gradually widens as time progresses from 10 min to 50 min. A comparison reveals that HL-DPoS produces a block in approximately 12 s, while the block output time for RP-DPoS ranges between 6 and 7 s, indicating that the RP-DPoS algorithm offers a significant advantage in block output efficiency.

5.7. Application Scenario

Blockchain technology provides a framework for establishing reliable message communication and privacy protection within the Internet of Vehicles. However, as data volume increases, many devices, such as mobile phones and in-vehicle systems, encounter difficulties in storing high-capacity blockchain copies. LSB retains the advantages of traditional blockchain technology while mitigating over-reliance on storage resources.

For instance, in the emerging in-vehicle social network, drivers utilize social software to access a range of messages released daily, including traffic updates, social information, and news. However, users have diverse needs for different types of information; for example, taxi drivers prioritize traffic conditions, while tourists are more interested in local attractions. As the volume and variety of data grow, it becomes increasingly important to classify and selectively store the information.

In LSB, messages can be categorized by wallet addresses. For example, in the in-vehicle network, messages sent by Newspaper A can be stored in light node A corresponding to wallet_address A. Similarly, the news from Newspaper B is stored in light node B. Drivers who prefer reading Newspaper A can quickly search for the news associated with Newspaper A using wallet_address A and download it to the in-vehicle system, rather than backing up the entire blockchain.

6. Security Analysis

This paper introduces the concepts of node positivity and the evil-doing factor, elects honest and reliable nodes for block generation, and employs the PBFT consensus method to verify the legitimacy of the blocks, thereby ensuring the security of the system.

In a traditional blockchain architecture that employs the DPoS consensus algorithm, the selection of agent nodes depends on the number of votes each node holds, and malicious nodes can bribe high-interest nodes to vote for them, facilitating bribery attacks. In LSB, interest constitutes only a part of a node’s reputation value, leading nodes to vote for those with higher reputations to protect their interests, making bribery attacks challenging to execute.

LSB is also tamperproof. To ensure the integrity of the block content, the elements inside the block are processed using the SHA-256 algorithm to generate a unique hash value. If the content of the block is tampered with, the hash value will change, ensuring the data on the blockchain cannot be tampered with. Due to the decentralized nature of blockchain, malicious nodes would need to rewrite the ledger of more than half of the nodes in the network to tamper with the data. The blocks are linked to the previous block by the hash value. If a transaction is tampered with, the hash within the block changes. Nodes can detect tampering by checking the integrity of the previous block’s hash.

Attackers can create multiple nodes to join the network, allowing them to control the entire blockchain; this is known as a witch attack. In LSB, node selection is based on reputation value, with the weight and positivity of newly joined nodes created by an attacker set to 0, preventing them from being selected as consensus nodes and effectively thwarting the witch attack.

A malicious node sends the same transaction twice in an attempt to fork the blockchain for a double-spend attack. In LSB, blocks produced by the agent node are accepted by the client node and sent to the verification node, which runs the PBFT algorithm to verify the block height and hash values, preventing double-spend attacks.

To avoid excessive centralization like DPoS, LSB introduces node weight and positivity in the reputation value model, comprehensively assesses node performance, weakens the link between node selection and weight, prevents high-weight nodes from monopolizing block exits, and incentivizes ordinary nodes to participate in consensus, thereby promoting system fairness and impartiality.

7. Conclusions

This paper addresses the low query efficiency and high storage overhead of traditional blockchain by proposing a lightweight blockchain architecture (LSB) based on the sender. In LSB, the connection between blocks is linked to the transaction user, and lightweight nodes only store the transactions they send. Compared to traditional blockchain architecture, the storage overhead of LSB is reduced by approximately 90%, significantly alleviating the storage burden on the device. Additionally, the concept of a wallet is introduced to the node, enabling fast transaction queries. Users can quickly find and download relevant information via their wallet address, without needing to traverse the entire blockchain. On the other hand, LSB’s consensus mechanism, RP-DPoS, establishes a reputation value model to evaluate node behavior and select consensus nodes. Additionally, it adopts the PBFT algorithm, which reduces block validation delays. Experimental results show that LSB reduces blockchain storage redundancy, improves transaction query efficiency, reduces block verification delays, suppresses node mischief, and enhances system security. However, LSB has some shortcomings: light nodes only store blocks related to themselves, and when certain blocks have less storage redundancy, it can affect transaction integrity. In the next phase, we will conduct a more detailed study and focus on improving data integrity.