V-Lattice: A Lightweight Blockchain Architecture Based on DAG-Lattice Structure for Vehicular Ad Hoc Networks

. With the development of wireless communication technology and the automobile industry, the Vehicular Ad Hoc Networks bring many conveniences to humans in terms of safety and entertainment. In the process of communication between the nodes, security problems are the main concerns. Blockchain is a decentralized distributed technology used in nonsecure environments. Using blockchain technology in the VANETs can solve the security problems. However, the characteristics of highly dynamic and resource-constrained VANETs make the traditional chain blockchain system not suitable for actual VANETs scenarios. Therefore, this paper proposes a lightweight blockchain architecture using DAG-lattice structure for VANETs, called V-Lattice. In V-Lattice, each node (vehicle or roadside unit) has its own account chain. The transactions they generated can be added to the blockchain asynchronously and parallelly, and resource-constrained vehicles can store the pruned blockchain and execute blockchain related operations normally. At the same time, in order to encourage more nodes to participate in the blockchain, a reputation-based incentive mechanism is introduced in V-Lattice. This paper uses Colored Petri Nets to verify the security of the architecture and veriﬁes the feasibility of PoW anti-spam through experiment. The validation results show that the architecture proposed in this paper is security, and it is feasible to prevent nodes from generating malicious behaviors by using PoW anti-spam.


Introduction
With the development of wireless communication technology and the automobile industry, the Vehicular Ad Hoc Networks (VANETs) have developed significantly, which brings many conveniences to humans in terms of safety and entertainment.
rough the collaboration of Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I), Vehicle-to-Pedestrians (V2P), and Vehicle-to-Cloud (V2C) communication, VANETs can enhance driving safety and traffic efficiency and realize Intelligent Traffic System (ITS) better. In ITS, a lot of sensor data need to be transferred between nodes. In particular, video data collected by cameras, such as traffic accident information and road condition information, need to be transmitted to other nodes through mobile video communication technology. However, in the process of communication between the nodes in the VANETs, security and privacy are the main concerns [1], including the security protection issues (such as integrity and correctness) of the VANETs data in transmission process, the security issues (such as non-tampering) of VANETs data stored in the data center, the access control issues (such as identity verification), and privacy protection issues. e traditional approach to solve security problems is based on centralized approach which requires a trusted central entity. However, through a trusted central entity, there is a single point of failure problem. Moreover, the data stored in a trusted central do not have a technical method to ensure its security (nontampering, traceability), and they are only guaranteed at the legal level. ere are also some approaches based on the distributed approach, but the lack of trust between distributed entities makes it difficult to implement in actual environments.
Blockchain is a distributed technology. It uses cryptography and hash functions to store data in a chain to ensure that data are tamper-resistant and traceable. And the technology uses a consensus protocol to ensure data consistency. At present, the use of blockchain is very extensive, including supply chain management, agriculture, Internet of ings (IoT), artificial intelligence (AI), and autonomous vehicles. It can be seen that using blockchain technology in the VANETs environment can solve the security problems and the dependence on trusted central entities.
ese studies mainly focus on the architecture of the combination of blockchain and the VANETs and how to use the blockchain to solve the security issues in the VANETs environment. Moreover, they are all based on the traditional chain blockchain structure. However, the VANETs is selforganizing and highly dynamic. Moving vehicles will gather at intersections to form a multidomain network. e data sharing between V2V and V2I is mostly temporary and dynamic, which make it difficult to synchronize data between nodes and resulting in more forks and low consensus efficiency. At the same time, vehicles in the VANETs usually have limited resources. e compute and storage capabilities are usually not particularly strong. So, a complete blockchain cannot be run and stored on the vehicle. It can be seen that the characteristics of highly dynamic and resource-constrained of the VANETs make the traditional chain blockchain system not suitable for actual VANETs scenarios.
With the development of blockchain technology, the structure of the blockchain has also evolved from a traditional chain structure to a directed acyclic graph (DAG) structure. In the DAG structure, the constituent unit is a transaction which does not need to be packaged into blocks. Moreover, in the DAG structure, each transaction can point to multiple previous transactions, allowing the blockchain to generate forks. erefore, the DAG structure can make transactions reach consensus parallelly, which greatly improves the speed of processing transactions, that is, TPS. It can be seen that through the DAG structure, the consensus efficiency and transaction throughput of the system can be improved, meanwhile the problem of low scalability can be solved. Currently, the researches using DAG structure include IOTA [19], Byteball [20], InterValue [21], Nano [22], and JURA [23]. ese researches use DAG structure to build a blockchain that can run stably for a long time. It shows that the DAG structure can replace the traditional chain structure to show better performance. In particular, the DAGlattice structure is used in both the Nano and JURA projects. In the DAG-lattice structure, each node account has its own account chain, and only the node itself can add transactions to its own account chain. So, the transactions between accounts can be added to the blockchain asynchronously and parallelly. Moreover, in the lattice DAG structure, the node can prune the transactions from the account chain of the node out of communication and only keep their latest transactions without affecting the system consensus. It can be seen that using the DAG-lattice structure in the VANETs environment can solve the problems caused by high dynamics and resource constraints. erefore, this paper proposes a lightweight blockchain architecture using DAG-lattice structure for VANETs, called V-Lattice.
is architecture is general and suitable for highway and urban road. In this architecture, each node has its own account chain. e transactions they generated can be added to the blockchain asynchronously and parallelly, and resource-constrained vehicles can store the pruned blockchain and execute blockchain related operations normally. At the same time, in order to incentivize vehicle and roadside unit (RSU) to participate in the blockchain network actively and without malicious intent, this paper uses a reputation-based incentive mechanism; that is, each node participating in the blockchain has a reputation score, and the reputation score of nodes can be updated dynamically based on the node's behavior. e main contributions to this paper are as follows.
(1) Based on the DAG-lattice structure, this paper proposes a lightweight blockchain architecture for VANETs. e lightweight nature is reflected in two aspects. One is the small amount of calculation. In this paper, the PBFT consensus algorithm is used, which is not discriminatory in computing power. e other is the small storage capacity. Vehicles with limited storage capacity store pruned blockchain instead of full blockchain.
(2) is paper introduces a reputation-based incentive mechanism to encourage more nodes to participate in the blockchain, and through updating the node's reputation score dynamically, it motivates normal nodes and punishes malicious nodes. (3) is paper proposes a consensus method that can conduct asynchronous consensus on transactions generated by nodes. (4) Aiming at the lightweight blockchain architecture for VANETs proposed, this paper describes how common applications in the VANETs work under this architecture. e rest of the paper is organized as follows. Section 2 describes research on the architecture introducing blockchain technology in VANETs and the current using of the DAG-lattice structure; Section 3 introduces the relevant components of the architecture proposed in this paper; Section 4 introduces the proposed lightweight blockchain architecture in detail; Section 5 describes the malicious attack scenarios that may occur in this architecture and analyzes how this paper deals with these malicious attacks; Section 6 verifies the proposed architecture; finally, the full paper is summarized in Section 7.

Research on the Architecture of Using Blockchain in
VANETs. At present, there have been many researches on proposing the security architecture for VANETs using blockchain.
ese studies mainly include two categories. One is that the nodes (vehicle and RSU) in VANETs do not participate in the blockchain, and the other is that the nodes in VANETs participate in the blockchain.
In the research case where the nodes in VANETs do not participate in the blockchain, the blockchain is deployed as a storage service in nodes or platforms which maintain the operation of the blockchain outside the VANETs. Rahman et al. [4] proposed a secure Internet of Vehicles (IoV) framework that allowed vehicle data to be stored in blockchain and off-chain repositories for secure sharing with one's community of interest. In this framework, the blockchain provides storage as a service. Xu et al. [24] introduced a new framework for secured intelligent vehicle data sharing, namely, biometric blockchain (BBC). In the BBC, each vehicle can be connected to the BBC-based platform and store their IV-BC through the BBC-based cloud service. Kulathunge and Dayarathna [25] proposed a VANET communication framework based on blockchain functions. In this architecture, data are stored in the Hyperledger Fabric blockchain, and the VANETs nodes communicate with the blockchain through the REST protocol.
However, the blockchain runs on nodes outside the VANETs as a distributed storage environment, which can only guarantee the security of the data in the storage process and cannot improve the security of the data in the communication process through blockchain technology. erefore, researchers have proposed some architectures in which the nodes in the VANETs participate in the blockchain. In these architecture studies, the blockchain runs in vehicles or RSUs in the VANETs, and the operation of the blockchain is maintained by the vehicles or RSUs. Yuan and Wang designed a seven-layer conceptual model for ITS in [26] and proposed a B2ITS framework. Dorri et al. [27] proposed a blockchain-based distributed privacy protection and security architecture for smart vehicles. e nodes in the architecture are clustered, and only the cluster heads (CHs) are responsible for managing the blockchain and executing its core functions. Singh and Kim [28] proposed an Intelligent Vehicle-Trust Point (IV-TP) mechanism for IV communication among IVs using blockchain technology. In this mechanism, the IV-TP data are managed through the blockchain. Leiding et al. [29] proposed a transparent, selfmanaged, and decentralized system which combined Ethereum and VANETs. In this system, each entity has an Ethereum address, and RSU provides Ethereum-based applications which have been deployed to the Ethereum blockchain. Sharma et al. [2] proposed a vehicle network architecture based on blockchain in the smart city (Block-VN). Block-VN includes controller nodes, miner nodes, and ordinary nodes. e ordinary nodes can send service request messages to miner nodes (vehicles) or controller nodes. Jiang et al. proposed a blockchain-based distributed VANETs architecture in [30]. According to different application purposes, the blockchain is divided into 5 types. e various blockchains do not communicate with each other, and they also have 5 different types of blockchain nodes. e current architecture researches are considered from the perspective of application. e use of blockchain can solve some security issues, privacy, and so on. Moreover, the proposed architectures mainly study that the blockchain runs on which entities, what information is stored on the entities, and how the entities interact to ensure security in the VANETs. However, they do not consider the high dynamics of the VANETs and the problems caused by the use of blockchain under the condition of limited node resources.

Usage of DAG-Lattice Structure.
e DAG-lattice structure is a kind of DAG structure. e first to use this structure was the Nano project [22]. In this project, each account has its own blockchain. e sending transaction and receiving transaction are separated, which can provide almost instantaneous transaction speed and unlimited scalability. Moreover, the transaction tracks the account balance, so that blockchain can be pruned without affecting the performance and security. In view of the limitations of current blockchain technology and the scalability requirement of having millions of TPS in the future, the JURA team proposed the decentralized JURA [23], in which novel data structure Fusus, PoU consensus mechanism, verifiable random function technology, dynamic monitored and distributed sharding, and artificial intelligence is used. e essence of Fusus is the DAG-lattice structure. e transaction records of accounts form the lattice, and the transaction records of each account are organized by DAG structure.
Both Nano and JURA are cryptocurrencies based on blockchain. However, some researchers have used the DAGlattice structure in a noncryptocurrency environment. Zhou et al. [31] used the DAG-lattice structure in data tokenization and proposed the lattice blockchain model, namely, DLattice.
is model has a double-directed acyclic graph (Double-DAG) structure, and each account is composed of a Token-Chain and a Data-Tree.
At present, the DAG-lattice structure has not been used in the VANETs environment.

The Components of V-Lattice
is section defines the basic components of V-Lattice from four aspects: node, account, transaction, and ledger.

Node.
e node is software that runs on entities in the blockchain network. It follows the relevant protocols of the blockchain and can run all or part of the blockchain-related operations, including generating transaction, verifying transaction, transaction consensus, and storing transaction. In the VANETs environment, the entities are mainly mobile vehicles and RSUs fixed on both sides of the road. When a blockchain node is running on a moving vehicle, the mobility of the vehicle causes the vehicle to frequently join or leave the blockchain network. Moreover, the moving vehicle often forms small clusters at intersections, which makes it difficult to maintain a unified ledger among vehicles; when the blockchain node is running in fixed RSUs, the RSUs are Security and Communication Networks fixed and can maintain a stable network. However, because the blockchain ledger is stored on the RSUs, it cannot be guaranteed to keep communicating with the RSUs during the movement of vehicles. When the vehicles cannot communicate with the RSUs through a single hop or multiple hops, it is impossible to obtain data from blockchain or synchronize the transactions to the RSUs in real time.
erefore, both vehicles and RSUs participate in the blockchain network as blockchain node and jointly maintain the blockchain in V-Lattice. e node running on the vehicle is called vehicle node, denoted as VNode i ∈ VNode 1 , VNode 2 , . . . , VNode N }, where N is the number of vehicles. e node running on RSU is called RSU node, denoted as RNode i ∈ RNode 1 , RNode 2 , . . . , RNode M , where M is the number of RSUs.

Account.
e account is the identity of a blockchain node participating in the system. For ease of management, each blockchain node has only one account. Each account consists of a public key and private key pair P r , S r , where the public key P r is publicly available on the entire network to identify each account, and the private key S r is kept by the account itself and is not publicly disclosed. e public and private key pair of the account is generated by the Trust Center (TC). e trusted center is an absolutely trusted infrastructure that will not be maliciously attacked and used for generating public and private key pair, authenticating identity, and issuing certificates. Before joining the blockchain network, vehicle nodes and RSU nodes firstly need to generate public and private key pair through the TC. e public and private key pair of the vehicle account is generated by the fixed attributes of the vehicle (vehicle license plate, vehicle type, vehicle manufacturer, vehicle owner information, etc.). e public and private key pair of the RSU account is generated by the fixed attribute (number, etc.) of the RSU. e V-Lattice contains vehicle accounts and RSU accounts, which represent vehicle nodes and RSU nodes, respectively.
e vehicle account is denoted as VAC i ∈ VAC 1 , VAC 2 , . . . , VAC N , where N is the number of vehicles. RSU account is denoted as RAC i ∈ RAC 1 , RAC 2 , . . . , RAC M }, where M is the number of RSUs.

Transaction.
e transaction is a series of operations that cause state change in the blockchain. In a traditional blockchain, multiple transactions need to be packaged into a block firstly. It takes a certain amount of time to pack a block, and the packed block is generally relatively large, which is not conducive to transmission in a highly dynamic and bandwidth limited VANETs environment. erefore, a transaction is regarded as a block in V-Lattice. Transaction and block can be used interchangeably.
In the traditional blockchain, a chain is maintained between all accounts. One operation is a transaction, and a transaction may involve two accounts. However, for a blockchain with a lattice structure, each account maintains its own account chain. In order to reduce the coupling and enable transactions to operate asynchronously between account chains, a transaction under the traditional blockchain is separated into a sending transaction and a receiving transaction in V-Lattice, which is stored in sending and receiving account chains, respectively.
In the VANETs environment, the main behaviors of nodes include that node creates account, node broadcasts messages, node obtains messages from other nodes, and RSU updates node's reputation score. erefore, the transaction types involved in V-Lattice include creating account transaction (T acount create ), sending message transaction (T message send ), sending reputation score transaction (T reputation send ), and receiving transaction (T receive ).T acount create is used to create the node's account; T message send and T receive appear in pairs to complete a message transmission together; T reputation send and T receive appear in pairs to complete a reputation score updating operation together. In particular, T acount create only involves one account, so there is no need for T receive .

Ledger.
e ledger is the data maintained by all accounts, and each account has an account chain. For each account, the transaction content on the account chain includes message-related transactions and reputation-related transactions. In order to improve transaction processing speed, facilitate transaction query, and process transactions asynchronously, the V-Lattice divides the account chain into Message Chain (MC) and Reputation Chain (RC). e ledger is stored by the structure of a directed acyclic graph (DAG). e DAG-lattice structure of the ledger is shown in Figure 1.
e genesis block is generated by the system during initialization, and it is the parent block of all creating account transaction. T acount create is the genesis transaction of the account chain. e MC and RC are, respectively, linked to T acount create . T message send and T receive exist in pairs, and T message send must be quoted by the corresponding T receive . Similarly, T reputation send and T receive exist in pairs, and T reputation send must be quoted by the corresponding T receive . e change of node's reputation score is caused by the behavior of the node. In this architecture, the behavior of the node refers to whether the node sends the correct message. In other words, the behavior of the node can be reflected by T message send . erefore, T reputation send must quote the corresponding T message send that resulted in the reputation score changing.
rough the DAG-lattice structure shown in Figure 1, the transactions can be performed asynchronously between accounts. At the same time, the transactions on MC and RC can also be performed asynchronously within the same account.

Proposed V-Lattice
is section introduces the proposed V-Lattice in detail.

e Overview of V-Lattice.
In V-Lattice, vehicles, and RSUs together form a blockchain network. When the vehicles and the RSUs join the blockchain network, firstly they need to obtain the public and private key pair through the trusted center and then create account according to public key. e communication method between vehicles or between vehicles and RUSs is wireless communication, such as DSRC and 5G. e communication method between RUSs is wire communication. ey communicate through the Gossip protocol to ensure the consistency of the blockchain. Figure 2 shows the network structure diagram. e entities of this architecture mainly include Trust Center, vehicle, and RSU. e overall workflow chart between entities is shown in Figure 3.
Trusted Center, as an absolutely trusted entity, is used to generate public and private key pairs for vehicles and RSUs. Moreover, it is also used for assisting RSUs to verify the account information created by blockchain nodes. Vehicle, as a lightweight node, has limited storage capacity and stores the pureed blockchain. In order to verify transactions and participate in consensus, the pureed blockchain stored in the vehicle should at least contain the creating account transaction and the latest message-related transactions and reputation-related transactions of the vehicle itself and other surrounding vehicles. However, as the vehicle is moving, the surrounding vehicles constantly change, which cause the vehicles to frequently update the locally pureed blockchain. erefore, in order to prevent this problem and to improve the overall security of the blockchain, vehicles are encouraged to store more transactions. RSU, as a full node, has the characteristics of large storage capacity and strong computing power. It can perform all blockchain functions and store all transaction records. e update of the reputation score requires a large amount of calculations, and the transaction information of other vehicles is required, so it is completed by the RSU. For the message sent by the node, the RSU needs to judge whether the message is true or false (the method of judging whether the message sent by the node is true or false is mainly realized through trust management in the VANETs. is part is not the focus of this paper and will not be discussed in detail). If it is found that a fake message is sent by a node, its reputation is reduced; otherwise, its reputation is increased. For nodes with high reputation score, there are more opportunities to generate blocks and get rewards. Meanwhile, the messages generated by them are processed firstly. For nodes with low reputation score, the messages will not be accepted by other nodes and they cannot get priority services. is can help encourage the vehicle to stay normal.
In V-Lattice, the operations performed by the vehicle include generating transactions, verifying transactions, forwarding transactions, and participating in consensus. e operations performed by RSU include generating transactions, verifying transactions, forwarding transactions, participating in consensus, and updating node's reputation score.

Creating Account Transaction.
To create an account, the blockchain node needs to send a creating account transaction as shown in Table 1. e type field identifies the type of transaction, and its value is account_create. e account field indicates the address of the account to be created. e difficulty field is the difficulty of Proof of Work (PoW), and the nonce is a random number that meets the difficulty of PoW. e difficulty and nonce will be described in detail in Section 4.5. e timestamp field indicates the Security and Communication Networks 5 time when the transaction is created. e signature field is the signature of the transaction by the node creating transaction. rough signature, on the one hand, the node cannot deny its signature. On the other hand, it can also determine whether the transaction content has been tampered by malicious nodes, thereby ensuring the integrity of the information transmission process. e signature is generated by the transaction producer using his own private key S r to encrypt the hash value of the transaction content (except the signature field), that is, signature � E S r H 1 (type, account, nonce, difficulty, timestamp) , where H 1 is the hash algorithm.

Sending Message Transaction.
When the node sends message content, it firstly needs to send a sending message transaction as shown in Table 2. e type field identifies the type of transaction, and the value is message_send. e previous field identifies the hash value of the previous block. e source field is the address of the account that sent the transaction, and the destination field is the address of the account that receive the transaction. e msg field is used to indicate the message sent by node, including desc field and    content field. e desc field is the description information of content, and content field refers to the specific message content to be sent which includes public content plaintext_cont field and encrypted content ciphertext_cont field. e desc field and plaintext_cont field are displayed in plaintext in the transaction, which can be directly read by other nodes, whereas the ciphertext_cont field is displayed in ciphertext in the transaction. Only after the sender authorizes it, it can be decrypted and read through the decryption key.
e signature field is generated by the transaction producer using his own private key S r to encrypt the hash value of the transaction content (except for the signature field), namely, signature � E S r H 1 (type, previous, source, destination, nonce, difficulty, timestamp, msg)}, where H 1 is the hash algorithm.

Sending Reputation Score Transaction.
When RSU updates the reputation score of nodes, it needs to send a sending reputation score transaction as shown in Table 3 to the nodes. e type field identifies the type of transaction, and its value is reputation_send. e destination field indicates the account address of the node (vehicle or RSU) whose reputation score needs to be updated. e associate field is the hash value of the corresponding transaction that causes the node's reputation score to change. It is used to associate the change of node's reputation score with the node's behavior. e reputation field records the reputation score of the node, where desc field describes the update method of the node's reputation score, and the score field records the updated reputation score of the node. e timestamp dest field is the timestamp when the node whose reputation score is updated signs the transaction. e signature field and signature dest field, respectively, represent the signature of the transaction producer (i.e., the RSU updating the node's reputation score) and the node whose reputation score is updated. As the reputation score update is completed by the RSU, and the reputation score needs to be recorded on the Reputation Chain of the node whose reputation is updated, so the RSU and the node whose reputation is updated need to sign the transaction jointly. rough the joint signature method, the updated node can not only track the change of reputation score but also can prevent the updated node from modifying the reputation score, and at the same time can prevent the RSU from being attacked and maliciously updating the node's reputation score. e signature field is generated by the transaction producer using his own private key to encrypt the hash value of the transaction content (except for the signature field and signature dest field), that is, signature � E S r H 1 (type, previous, source, destination, associate, nonce, difficulty, timestamp, reputation)}, where S r is the private key of the transaction producer and H 1 is the hash algorithm.
e signature dest field means that the node whose reputation score is updated uses its own private key to encrypt the hash value of the transaction content (except for the signature field and signature dest field), that is, signature dest � E D S r H 1 (type, previous, source, destination, associate, nonce, difficulty, timestamp, reputation, timestamp dest )}, where D S r is the private key of the node whose reputation is updated, and H 1 is hash algorithm.

Receiving Transaction.
When node receives a sending message transaction or a sending reputation score transaction, it needs to send a receiving transaction as shown in Table 4. e type field is used to identify the type of the receiving transaction. If a receiving transaction is initiated for a sending message transaction, the type field is message_receive. And if a receiving transaction is initiated for a sending reputation score transaction, the type field is reputation_receive. e destination field indicates the address of the account that receives the transaction, which is consistent with the content of the source field. e associate field points to the hash value of the corresponding sending transaction and is used to associate the receiving transaction with the sending transaction. e signature field is generated by the transaction producer using his own private key to encrypt the hash value of the transaction content (except the signature field), that is, signature � E S r H 1 (type, previous, source, destination, associate, nonce, difficulty, timestamp)}, where S r is the private key of the transaction producer, and H 1 is the hash algorithm. Only after the receiving transaction and the corresponding sending transaction are both agreed and added to the blockchain can an operation be considered complete.

Transaction Verification.
After blockchain node receives the transaction T sent by the node K, (K ∈ VNode i � � � �RNode i ),

Whether the Transaction Is Received for the First Time.
Upon receiving a transaction T, first it is necessary to verify whether the transaction is received for the first time. e verification method is to check the recent historical transaction information under the account that sent the transaction T to determine whether there is a copied transaction. If there is a copied transaction, that is, the transaction has been received before, it may be a copied transaction generated by a malicious node, and the transaction needs to be discarded.

e Nonce Value.
e correctness of the nonce value can determine whether the blockchain node K has completed proof of work. Only when the node has completed the proof of work can it send transactions to the blockchain network. So, the verification of the correctness of the nonce value is very important. e method of verification is to combine the type field, the difficulty field, the timestamp field, and the nonce field of the transaction to calculate the hash value and determine whether the Hash(type, difficulty, timestamp, nonce) meets the PoW difficulty. If the nonce value meets the value of the difficulty field in the transaction, it means that the node has completed the corresponding proof of work; otherwise, the transaction is discarded.

e Timestamp.
e purpose of verifying the timestamp is to determine whether the node K sends the transaction immediately after it generates the transaction and to prevent malicious nodes from generating precomputed POW attacks (detailed in Section 5. It should be noted that, for the sending reputation score transaction, it contains the timestamp and timestamp dest . If the transaction is issued by the RSUs which update the reputation score, the timestamp will be verified. If the transaction is issued by the node whose reputation score is updated, then verify the timestamp dest . Under normal circumstances, the determinants of the time interval Δt include the PoW time t pow T of the transaction, the queue time t que T of the transaction in the node, and the transmission time t trans T from the sending node to the destination node of the transaction. erefore, the threshold Threshold T is expressed as follows: (1) t pow T is the time required for the node to complete PoW for the transaction. is time usually varies and is specifically related to the node's reputation score and computing power. However, the computing power between nodes is usually similar, so the main influencing factor of this time is the reputation score of the node. t que T is the queuing time of transactions in the node, which is determined by the frequency of the sending packets and the frequency of generating transactions. If there is no malicious attack (e.g., Denial of Service), the frequency of transactions generated by the node is generally not too high. t trans T is the transmission time of the transaction from the sending node to the receiving node, and this time is related to the network topology. η T is the error time. Since there may be error in the calculation of the times t pow T , t que T and t trans T , they need to be corrected by η T . e value of η T needs to be determined according to the real network environment and historical experience. If η T is too small, it will cause normal transactions to fail to be verified. On the contrary, if the value of η T is too large, transactions generated by malicious nodes may be mistaken for normal transactions.

4.3.4.
e Signature of the Transaction. By verifying the signature of the transaction, it can be determined that the transaction is indeed generated by the producer of the transaction rather than forged by other malicious nodes. e method to verify the signature is firstly to calculate the hash value of the transaction (except for the signature field or signature dest field) hash 1 � H 1 (type, account, nonce, difficulty, timestamp) (here we take the creating account transaction as an example), where H 1 is the hash algorithm, which is the same hashing algorithm as when signing. en, it needs to use the public key P r of the transaction producer to decrypt the signature and obtain the decrypted hash value hash 2 � D P r signature . Finally, it needs to judge whether hash 1 and hash 2 are the same. If hash 1 � hash 2 , the signature e specific verification process is as shown in Figure 5. It is particularly important to note that, for the sending reputation score transaction, if the transaction is generated by the RSU that updates the node's reputation score, it only needs to verify the signature. If the transaction is sent by the node whose reputation score is updated, the signature and the signature dest need to be verified at the same time.

e Associated Transaction.
For the creating account transaction and sending message transaction, this process can be ignored because they do not involve related transactions. However, for the sending reputation score transaction, it is necessary to associate the corresponding transaction that causes the reputation score change. For the receiving transaction, the corresponding sending message transaction and the sending reputation score transaction need to be associated. erefore, after receiving the sending reputation score transaction and receiving transaction, it is necessary to verify whether the associated transaction has been added to the blockchain. If the associated transaction exists, the transaction verification is passed; otherwise, the transaction is discarded.
Transactions that have passed the above 5-step verification are added to the transaction candidate set. e transaction candidate set is used to temporarily store verified transactions and wait for consensus.

Consensus Scheme.
Consensus algorithm is the core part of the blockchain, and it can guarantee the consensus of distributed blockchain nodes. Common consensus algorithms currently include Proof of Work (PoW) used in Bitcoin system, Proof of Stake (PoS) used in Ethereum, and Practical Byzantine Fault Tolerance (PBFT) used in Hyperledger. By comparing PoW, PoS, and PBFT, Ayaz et al. [32] believe that PBFT has the most potential to become the consensus algorithms in the VANETs environment. e PoW consensus algorithm is discriminatory in computational power, and the POS consensus algorithm is discriminatory in stakes owned. However, the PBFT consensus algorithm is based on voting, which is not discriminatory in computational power and stakes owned. It can be seen that it is suitable for use in the VANETs environment. erefore, PBFT-based consensus algorithm is adopted in this architecture.
e PBFT consensus algorithm has relatively high communication complexity, and its complexity is Ο(n 2 ), where n is the number of nodes participating in the consensus. As you can see, performance degrades dramatically when there are many nodes in the network. Moreover, in PBFTconsensus algorithm, if the byzantine nodes exceed 1/3 of the total number of participating consensus nodes, the consensus algorithm will fail. Based on these two considerations, this architecture selects nodes within M hop around the transaction producer rather than all nodes in the network, which can improve consensus efficiency. As a parameter in the consensus process, M is dynamically Security and Communication Networks 9 adjusted according to the network environment. At the same time, node with reputation score greater than a certain threshold T is selected to participate in the consensus, so as to avoid the byzantine nodes participating in the consensus from exceeding 1/3 of the total number of nodes. If a node participating in the consensus is attacked and behaves maliciously, the RSU can quickly find and reduce its reputation score, thus preventing the attacked node from participating in the consensus process.
In this architecture, transaction consensus can be asynchronous, that is, transactions of different accounts, or transactions related to messages and reputation scores of the same account can be asynchronously agreed. erefore, in the consensus process, all nodes can become the master node and present a consensus on transaction. But for a certain transaction, only one node can become the master node to avoid the occurrence of forks. However, in the traditional PBFT consensus algorithm, the selection method of the master node has the problem of forecasting in advance. In order to avoid a malicious attack on a certain transaction, the master node proposing a certain transaction should not be predicted in advance. e verifiable random function VRF [33] maps the input value to a verifiable output. It is characterized by not being able to predict the random result and verifying the correctness of the result. In Algorand [34] and Ouroboros Praos [35], the authors use VRF to select the node proposing block, which has high security. erefore, VRF is used to determine the master node of the consensus in this paper and PBFT consensus algorithm is improved. To achieve asynchronous consensus, this paper appends transaction information (the account‖source field and the timestamp field) to the VRF verification information. Transaction can be uniquely identified by additional transaction information. e detailed procedures are as follows.
(1) Each node G i of scheduled generation block selects a transaction from the local transaction candidate set, uses the timestamp of transaction and the private key G S r i of node G i as the input of VRF to generate the hash output of hash value and proof_value through the VRF calculation function VRF_HASH and VRF proof function VRF_Proof. e calculation method of hash_value and proof_value is shown in the following: (2) e node G i sends the VRF verification message hash value, proof value, account‖source, timestamp, account G i } to the surrounding nodes in the preprepare phase of the PBFT consensus algorithm, where the account G i is the account of the node G i . In particular, it should be noted that the nodes participating in the consensus are both the master node and the client node in this architecture. erefore, the request phase is not involved in this architecture.
(3) After the surrounding nodes as VRF verifier receiving hash value , proof value , account‖source, timestamp, account G i }, firstly they need to verify whether hash value � VRF P2H(proof value) is true. If true, then zero-knowledge proof is performed through the VRF verification function VRF Verify(G P r i , timestamp, proof value), where G P r i is the public key of the node G i . If the verification result is true, this means that the hash value is generated by the node G i through timestamp. (4) Among the verified VRF verifiers for the same transaction account‖source, timestamp , only the node whose hash value meets a certain condition is selected as the master node to perform other stages of the PBFT consensus, including prepare stage, commit stage, and reply stage. It should be noted that the client is not involved in this architecture, so the message is sent to the master node during the reply phase.
rough the above process, the master node can be randomly generated without being predicted in advance. At the same time, the asynchronous transaction consensus can be achieved.
As the vehicle moves, it may not be able to communicate with the RSU. In this case, the transaction that has reached consensus can only synchronize with the surrounding vehicles but cannot synchronize with the RSUs in real time.
erefore, it is necessary to use the Delay Tolerant Network (DTN). e vehicle firstly saves the transaction that has  Figure 5: e signature verification process of the transaction.
reached consensus locally, and when it moves to the communication range of the RSU, it synchronizes the transaction to the RSU. In this way, all the transactions that have reached consensus can eventually be synchronized with the RSUs.

PoW
Anti-Spam. Before nodes send a transaction, they first need to compute a random number satisfying a particular difficulty to complete the proof of work. Transactions cannot be sent until PoW is complete. When other nodes receive a transaction, they first need to verify whether nonce value is correct. Unlike PoW in Bitcoin, it is only used as an anti-spam tool in this paper. Since the amount of calculation is consumed during PoW, this can prevent malicious nodes from always sending malicious messages to occupy network bandwidth and perform DoS attacks. In this paper, the difficulty of POW is related to the node's reputation score. e higher the node's reputation score, the lower the difficulty of POW. On the contrary, the lower the node's reputation score, the higher the difficulty of POW. e specific calculation method is shown in the following equations: difficulty⇐ 0 · · · 0 √√ √√ N zero where N hash is the length of the hash value, which depends on the specific hash algorithm (e.g., the MD5 algorithm is 128 bits, the SHA-1 algorithm is 160 bits, and the SHA-256 algorithm is 256 bits). e specific selection of hash algorithms needs to be determined according to the application requirements. N zero is the number of the first 0 in the POW difficulty string. e Score is the node's reputation score. ϑ and μ are two preset parameters, which are used to control the change rate and upper limit of POW difficulty. ⌊ · ⌋ indicates that the number is rounded down to the integer part. (·)B means convert a decimal number into a binary number. As shown in Figure 6, POW is relatively difficult when the node's reputation score is very low. But with the increase of reputation score, the difficulty of PoW decreases gradually.
After the difficulty is determined, the PoW can be carried out for the transaction. e method is to try random numbers until a random number is found that satisfies the difficulty. e specific PoW method is shown in the following: Hash(type, difficulty, timestamp, nonce) ≤ difficulty. (6) 4.6. Application Cases. In the VANETs environment, the communication between vehicles or between vehicles and RSUs is mainly used to improve traffic safety and efficiency and realize intelligent traffic management. erefore, in the proposed architecture, application cases mainly include node creates accounts, node broadcasts messages, node obtains messages from other nodes, and RSU updates nodes' reputation score. Under this architecture, the working methods of these four application cases are as follows.

e Node Creates Accounts.
When a node joins the blockchain for the first time, an account needs to be created. e specific procedures are as follows: 1) Node A ∈ VNode i � � � �RNode i registers information in the trusted center and obtains the public and private key pair A P r , A S r . (2) Node A generates a creating account transaction T acount create , signs the transaction, and sends it to the RSU. e account field is the public key A P r of node A. (3) RSU B ∈ RNode i that receives T acount create verifies whether the public key account A P r has been registered in the TC. (4) If the verification is successful, T acount create will be verified, reached consensus, and added to the account chain of the account as the genesis transaction of the account.

e Node Broadcasts Messages.
Vehicles or RSUs need to frequently broadcast some warning messages, road condition messages, and so on to improve traffic safety and efficiency. e specific procedures are as follows: (1) Node A ∈ VNode i � � � �RNode i generates a sending message transaction T message send , signs it, and broadcasts it to surrounding nodes. It should be noted that the broadcast message does not have a definite destination node, and the transaction corresponding to the message needs to be stored in the node A's Message Chain. So, the destination field and the source field have the same content, that is, the account address of node A. e description information info desc of the message is recorded in the desc field of msg, and the content info pub that is publicly accessible by other nodes is recorded in the plaintext_cont field. e content info auth that needs to be authorized for other nodes to access is encrypted and recorded in the ciphertext_cont field, that is, ciphertext_cont � E A P r (info auth ).
(2) After receiving T message_send sent by node A, other nodes verify it, reach a consensus, and add it to the node A's Message Chain. (3) After T message_send is added to the blockchain, node A generates a receiving transaction T receive , signs it, and sends it to the network. (4) Once T receive is received, other nodes verify the transaction, reach a consensus, and add it to the node A's Message Chain.

e Node Obtains Messages from Other Nodes.
Node B ∈ VNode i � � � �RNode i in network needs to obtain content from another node A ∈ VNode i � � � �RNode i or obtain access to encrypted content in the Message Chain from node A. For node A, decrypting the ciphertext on the blockchain every time, encrypting it with the public key of node B, and then sending it to node B would undoubtedly cause a lot of trouble for node A as the data owner. erefore, using proxy reencryption technology [36] in this paper adopts, node A only needs to encrypt the ciphertext with the reencryption key and send it to node B. e specific procedures for node B to obtain a message from node A are as follows: (1) Node B generates a sending message transaction T message_send , signs it, and broadcasts to the surrounding nodes. e destination field is the account address of node A, and the desc field in the msg field records the content name that will be obtained from node A or the hash value of a block in the node A's Message Chain.
(2) After receiving T message_send sent by node B, other nodes verify it, reach a consensus, and add it to the node B's Message Chain.
(3) Node A generates a receiving transaction T receive , signs it, and sends it to the network. At the same time, node A generates ciphertext Data Encry based on what node B needs to obtain. e procedures of generating Data Encry are as follows: (a) Node A generates a reencryption key Re − Key A⟶B based on its own public key A P r and public key B S r of node B. (b) Node A generates the data Data s sent to node B.
If the content that node B needs to obtain is common content C comm which is not on the blockchain, then C comm needs to be encrypted with its own public key; that is, Data s � E A P r (C comm  (1) Node A generates a sending reputation score transaction T reputation_send , signs it, and sends it to node B. e destination field is the account address of node B. e associate field is the hash value of the corresponding transaction that causes the reputation score to change. e desc field of the reputation field describes the method of updating the reputation score, and the score field records the updated reputation score of node B. During the reputation score update process, the RSU and the updated node are required to sign transaction simultaneously.
e RSU signs the sending reputation score transaction and sends it to the corresponding vehicle. e corresponding vehicle signs again and then sends the transaction to the network to be added to blockchain. However, if the node (especially a moving vehicle) leaves the communication range of the current RSU when its reputation is updated, the forwarding is done with the assistance of other RSUs; if the node completely leaves the network (in an offline state), the RSU saves the relevant transaction temporarily until the node joins the network and then updates. If a node performs malicious behavior and does not sign the sending reputation score transaction, the node will be punished and pulled into the blacklist so that it can no longer generate new transactions.

Security Analysis
is section describes the malicious attack scenarios that may occur in architecture and analyzes how this architecture deals with these malicious attacks.

e Sybil Attack.
A malicious node may create multiple accounts and launch sybil attack on the network. However, in this architecture, public key, and private key pairs of vehicle and RUS are issued by TC, which is confirmed when the account is created. So, the malicious node cannot create large numbers of accounts to carry out the sybil attack.

e Transaction Flooding Attack.
A malicious node may send a large number of malicious transactions to the network, which affects other nodes' judgment on the correctness of messages in the network. In this architecture, the node needs to complete the PoW before sending a transaction. e difficulty of PoW is related to the node's reputation score. After a node sends a malicious transaction, it will be discovered by the RSU and its reputation score will be reduced.
is makes it increasingly difficult for node to initiate malicious attack. e node will abandon the attack voluntarily until PoW consumes more computational resources than the benefits of launching an attack.

e Precomputed PoW Attack.
e timestamp is generated automatically by the system and cannot be changed by the node that generates the transaction. However, malicious node can save transactions that have completed PoW locally without sending them to the surrounding nodes. After a period of waiting, transactions within this period are sent out simultaneously, and then the network or node is attacked. In this architecture, after the node receives a transaction, it first verifies the transaction including the verification of the timestamp. If a malicious node waits for a period of time before sending a transaction, the interval between the timestamp of the transaction and the current time exceeds the threshold, and the verification cannot be passed. As a result, the transaction is discarded and cannot generate a valid attack.

e Conspiracy Attack.
Two or more malicious nodes in the network may join together to provide false voting information during consensus process to conduct a conspiracy attack. e PBFT consensus method is used in this architecture. Consensus results can be affected when 1/3 of the malicious nodes participating in the consensus conduct a conspiracy attack. However, in this architecture, nodes within the M hop range around the production transaction node and with a reputation score greater than a certain threshold are selected to participate in the consensus. Because this architecture uses reputation score to motivate and punish nodes. Malicious nodes usually have low reputation scores, thus greatly reducing the probability of conspiracy attacks.

Architecture Verification
is section verifies proposed architecture, including the security verification of using Petri nets and the feasibility verification of PoW anti-spam through experiments.
6.1. Security Verification Based on Petri Net. Petri net is a mathematical tool for researching system. It can be used to describe and analyze asynchronous and concurrent system, as well as design and optimize system. Colored Petri Net (CPN) is a kind of advanced Petri Net that combines Petri Net and programming language. A token represents an object with a set of attributes. In CPN, each color set represents a different resource in the system, and the color set can be of multiple data types. At the same time, CPN supports hierarchical modeling, allowing the model to be partitioned into manageable parts that can be reused. erefore, this paper adopts a top-down method to establish a hierarchical CPN model for the proposed V-Lattice.
e top layer CPN model is shown in Figure 7, and the transition Verify Transaction is substitution transition as shown in Figure 8. e detailed introduction of the nine-tuple is as follows: P is set of places, which is identified by an ellipse in figure. e upper right corner of each place is the initial function I, and the lower right corner is the color set function C. ere are 6 places in the top layer CPN model, and 8 places in the substitution transition Verify Transaction. A is the set of arcs that are used to connect places and transitions. Each arc contains an arc expression function E. Σ is the set of color sets, and V is the set of variables. In this model, the definition of set of color sets and set of variables are shown in Table 5.
As shown in Figure 7, in the top layer CPN model, the Generate transition generates transactions which need to be sent and adds them to the list of transactions.
e Send transition broadcasts the next transaction to be sent to the Add to BC if n = 2 orelse n = 3 then ns^^ [4] else ns 1`(1, "creating account transaction")++ 1`(2, "sending message transaction")++ 1`(3, "sending reputation score transaction")++ 1`(4, "receiving transaction")    e Transaction to add transaction adds consensus-completed transactions to the blockchain. At the same time, for the sending message transaction and sending reputation score transaction, a receiving transaction is generated and added to the list of transactions that need to be sent.
In the subpage model of the Replacement Verify as shown in Figure 8, the Check whether existing transition checks whether transaction already exists in the blockchain.
e Check nonce transition checks whether nonce value in the transaction is correct. e Check timestamp transition is used to check whether timestamp in the transaction is correct.
e Check signature transition is used to check whether transaction is correctly signed by the sender of the transaction. e Check related transaction transition is used to check whether related transaction information is correct and has been added to the blockchain.

Security Analysis.
e number of nodes in VANETs is finite, so the transactions generated by the Generate transition are also finite.
ere exists an integer M and the number of tokens in any place in the CPN model will not exceed M. erefore, the CPN is bounded, that is, M-secure. e specific value of M depends on the speed with which transactions are generated and processed in the network. Modeling and simulating the network using CPN tools show that all transitions in the CPN are alive and can be fired indefinitely; that is, there is no dead transition. It can be seen that the workflow of architecture is secure. At the same time, through the analysis of CPN state space, it is found that every sending message transaction and sending reputation score transaction has a corresponding receiving transaction in the blockchain ledger, which ensures the existence of their pairing. It can be seen that the availability of architecture is secure.
In a word, using CPN to model architecture, it can be concluded that the architecture proposed in this paper is security.

Feasibility Verification of PoW Anti-Spam.
In this section, the impact of different difficulty values on PoW time is analyzed by experiments, and the feasibility of PoW antispam is verified. e experiment in this paper is carried out in the environment of 2.8 GHz processor and 8 GB memory. At different difficulty values, 500 experiments were carried out independently, and then the average value was taken as the experimental result.
First, this paper verifies the impact of difficulty value on the times to find the nonce. As shown in Figure 9, the abscissa represents difficulty value (ranging from 1 to 24), and the ordinate represents the average times to find the nonce. It can be concluded from Figure 9 that the times for attempting to find a nonce increase exponentially as the difficulty value increases. is paper then verifies the impact of difficulty value on time required to find the nonce. As shown in Figure 10, abscissa represents difficulty value (ranging from 1 to 24), and ordinate represents average time required to find the nonce. It can be concluded from Figure 10 that time required to find a nonce increase exponentially as the difficulty value increases. When difficulty value is small, time required to complete the PoW is also short, basically in milliseconds level, which satisfies the needs of VANETs applications. When difficulty value is greater than or equal to 20, time required to complete the PoW reaches the second level. e messages sent by the nodes cannot satisfy the real-time requirements in the VANETs environment, especially for safety-related messages. However, for nodes with high difficulty values, their reputation scores are relatively low, and generated messages are also with low credibility. It can be seen that it is feasible to use PoW anti-spam in this architecture, and it can prevent nodes from performing malicious behaviors without affecting the performance of VANETs. e average number of times to find nonce is not directly related to the hardware environment but is related to the selected hash algorithm. However, for the same hash algorithm, the average number of times is basically the same for all nodes. e main factor that affects time to find nonce is the computational power of the node. e more computational power, the less time required for the node to complete proof of work. erefore, in order not to affect the performance of VANETs, it is necessary to dynamically adjust ϑ and μ shown in Section 4.5 according to the computational power of the nodes in the network.

Conclusions
is paper proposes a lightweight blockchain architecture using DAG-lattice structure for VANETs, called V-Lattice. In V-Lattice, each node (vehicle or roadside unit) has its own account chain, the transactions they generated can be added to the blockchain asynchronously and parallelly, and resource-constrained vehicles can store the pruned blockchain and execute blockchain related operations normally. In order to encourage more nodes to participate in the blockchain, a reputation-based incentive mechanism is introduced in V-Lattice. At the same time, this paper proposes an asynchronous consensus scheme for transactions generated by nodes and describes how common applications (including node creates accounts, node broadcasts messages, node obtains messages from other nodes, and RSU updates nodes' reputation score) in the VANETs work under this architecture. is paper uses Colored Petri Nets to verify the security of the architecture and verifies the feasibility of PoW anti-spam through experiment. e validation results show that the architecture proposed in this paper is security and it is feasible to prevent nodes from generating malicious behaviors by using PoW anti-spam.
In future work, we will further study how to achieve efficient and asynchronous consensus on transactions under the architecture. At the same time, a blockchain pruning scheme will be designed to ensure that the blockchain can run normally on resource-constrained vehicles.

Data Availability
No data were used to support this study.

Conflicts of Interest
e authors declare that they have no conflicts of interest.