Gobierno y colaboración

An approach for collecting VANET data for purposes of reconstructing the events taking place before and after an accident is described in [29]. The proposed solution consists of integrating vehicles with improved log recording triggering mechanisms, logging VANET communication data, and a GPS data rectification mechanism that processes data submitted by other entities. This solution maintains all logged events within the vehicle’s data recorder, therefore requiring an owner’s consent or a court order to get access to it. This data needs to be parsed, filtered, and appended to already acquired witness data in order to perform the forensic analysis on it. In this case, the data stored in vehicles is potentially at risk of tampering by either modification or deletion and may not always be accessible.

In [24], the authors describe a BC architecture and model for decentralized ve- hicle applications. Their ITS-oriented model consists of a seven-tier architecture for managing different aspects of the DLT and ITS ecosystem. On top, the application layer provides services to allow consortium members to develop applications for vehi- cle management, logistics, and history. Below the application layer sits the contract layer, where self-executing smart contracts can be triggered as a result of predefined conditions met by the protocol. The incentive layer follows the contract layer. This layer is where the issuance and allocation of tokens would take place. Although to- kenized incentives are not a requirement in the implementation of a DLN, there are applications, such as a reputation system, where having an incentive layer would

prove useful. Next, is the network layer which describes how the nodes communicate in a decentralized, P2P way, and how to validate blocks and transactions. The next tier down, the data-layer, defines the data structure used for the DL, the encryption mechanisms, hashing algorithms, and other functions such as timestamping. Lastly, the physical layer encapsulates the physical devices and entities in the ITS which include but are not limited to vehicles, roadside units, electronic toll stations, and managed lanes.

Dorri et al. [18] proposes the use of a blockchain-based DL to address scalability issues with centralized systems (e.g., cloud services), preserve the privacy of vehicle owners and passengers, and enhance the security of smart transportation systems. Unlike permissionless public BCs such as Bitcoin, their solution clusters the network and moves the managing of the DL to nodes whose sole purpose is to broadcast and verify transactions and append blocks to the ledger. Furthermore, the author lists a series of use cases and their respective advantages, some of which include wireless software update hash checks, secure data exchange with insurance providers, and car- sharing services to name a few. Dorri et al. identified the chain of block hashes, the encryption of transactions, and the use of PKI authentication to submit transactions

as significant security features of their blockchain design [18]. Also, the authors

describe how the distributed architecture of the network prevents service disruption due to DDoS attacks by filtering out transactions from devices with invalid keys. Unfortunately, the research described in [18] does not include the experimentation of these services in a simulated transportation environment.

In [30], a 7-Tier blockchain architecture and framework was proposed for sharing data among vehicles on public roads. It relies on all vehicles or devices participating in the network being peer nodes. Their approach requires all peers to keep a copy of the ledger and participate in the consensus process for appending blocks to the

ledger. Moreover, their approach involves a rewards layer, where a token is rewarded to vehicles “winning” consensus. Unfortunately, there are no details regarding how their proposed consensus algorithm, proof-of-driving, prevents Byzantine Faults [15] and helps with maintaining the integrity of the network. It is also unclear how their proposed approach handles a high volume of transactions made by a large number of vehicles in populated locations or how these peak times would affect their time- to-consensus. The authors also state that “the vehicle having the maximum IV-TP token, leads the communication network” leaving unclear what actions the staking leader can perform on the network (e.g., append new blocks to the ledger) or other useful purposes for the tokens rewarded.

Oham et al. in [31] described their blockchain liability attribution framework for autonomous vehicles based on a consortium of transportation and governmental organizations. This framework utilizes two partitions for communications, the oper- ational and decision partitions, to collect or share data among different entities or sensors. Furthermore, the authors present a qualitative analysis of their framework that evaluates its resiliency against a series of malicious activities such as transac- tion deletion, collusion, and spoofing. A performance evaluation is presented which describes average verification and validation times for the different types of transac- tions. Their results show less overhead when compared to the approach described in [32]. Also, in [33] Oham et al. developed a BC based framework for auto-insurance claims and adjudication for connected and automated vehicles. The main purpose of their framework is to facilitate adjudication and claims processing. Both [31] and [33] are unclear about how the consensus algorithm operates to ensure the integrity of the network and omit design considerations for enabling such services to operate with current ITSs. Unlike the ad-hoc solutions in [31, 33, 32], the proposed imple- mentation in this work utilizes an open-source framework that has been tested in

production environments and has both community and commercial support, ongoing developmental upgrades, and can enable a number of other applications within the same platform.