## 3 VaNetChain: Architecture  
Figure 1 shows the difference between the protocol stacks of a traditional use of blockchain technology in VANETs and our proposal in this paper: VaNetChain. The key ideas of the latter are (i) to introduce the virtualization layer to support the operation of the routing algorithms (variations of the non-virtualized counterparts) and (ii) to entwine the operation of the blockchain protocols with the virtualization constructs. The virtualization layer that supports our approach is called the VaNetLayer, introduced in [30] as an evolution of the VNLayer, a foundational proposal from the MIT [62]. The VaNetLayer defines procedures by which the moving vehicles collaborate to emulate fixed virtual nodes (VNs) that altogether cover the whole area of the VANET. The layout of the VNs is defined by first placing one VN at each intersection, and then covering the road segments with as many VNs as needed, depending on the maximum distance for one-hop communications. Figure 2 shows one example with 11 VNs, colored differently depending on whether they are covering one intersection, they are neighboring one intersection, or they are placed elsewhere on a road segment. The emulation of the VNs is supported by one-hop communications among the vehicles that happen to be within the corresponding region at any given moment. These physical nodes can have three different roles: leader nodes, backup nodes, and regular nodes. As we will explain in Section 4, these roles are relevant at the blockchain level, too. Essentially, leaders are in charge of receiving/forwarding packets from/to neighboring VNs, as well as storing the persistent information state (PSI) kept in the region to support the operation of the protocols at higher layers. Backups, in turn, keep copies of the PSI as a mechanism to fight failures, and they support the leader's work in cases of intense traffic. Finally, the regular nodes listen to the dynamics of leader and backup appointments to replace them whenever needed. At the blockchain layer, VaNetChain implements mining as a proof of work (PoW), designating RSUs as miners (mRSUs) that try to solve the block hash calculation by applying the Keccak ([[https://keccak.team/keccak.html](https://keccak.team/keccak.html)]([https://keccak.team/keccak.html](https://keccak.team/keccak.html))) or SHA-3 algorithm. This idea goes hand in hand with the proposals that rely on RSUs to perform different computing tasks, taking advantage of computer and connectivity benefits [63]. The number of zeros required at the beginning of the hash is set so that an mRSU takes around 10 seconds to add a new block to the blockchain. If the time decreases for whichever reason, the number of zeros will increase accordingly, in order to ensure the immutability of the ledger. Likewise, if the time increases (e.g., due to periods of excessive work), mRSUs can choose to merge blocks of transactions and reduce the number of zeros in order to speed up things. The mRSUs set their gas limit (\"gas\" is the cost of making a transaction or executing a contract in Ethereum) to 1M. For the propagation of the new blocks (needed to achieve distributed consensus among the mRSUs and thus keep a unique record of transactions), the virtual nodes give the second greatest priority to the corresponding data packets --only second to the control packets of the VaNetLayer. Figure 1: The protocol stack of previous uses of blockchain in vehicular ad hoc networks (VANETs) vs. the VaNetChain approach. Figure 2: A sample deployment of virtual nodes with the VaNetLayer. We assume that all VaNetChain participants can execute smart contracts and verify that their terms have been met. Reputation scores and a blacklist of MAC addresses are recorded in the blockchain along with the completed transactions.