Each year, more than 1.35 million people die in road traffic accidents worldwide [1], with 37.806 of deaths in the United States, in 2016 [2]. The WHO's Global status report on road safety 2018 [1] reported that road traffic injuries are the leading killer of people aged between 5 and 29, especially for pedestrians, cyclists and motorcyclists living in developing countries. The majority of traffic accidents can be blamed to human factors [3,4], especially to aggressive driving [5].
Letting drivers become aware of their driving style, through the monitoring and logging of driving events, could reduce aggressive driving behaviors [6] and, consequently, avoid 20% of road traffic accidents [7]; furthermore, exploiting incentives or penalties could improve this virtuous cycle [8]. Apart from the aspects related to drivers' security, a reduction of aggressive driving behavior could also result in a lowering of vehicle consumption and gas emissions [9,10] as aggressive driving has been estimated to increase fuel consumption by around 40% [11].
Technological advancements made it possible to detect driving styles or aggressive driving behavior by relying on acceleration data, among others: in fact, non-aggressive driving events generally generate low(er) accelerations, whereas aggressive ones are characterized by high(er) readings acquired from accelerometers.
Historically, accelerometer data started to be obtained through black-boxes, ad-hoc hardware installed on the vehicle able to collect its acceleration (by exploiting Inertial Measurement Units, IMUs), location and speed (through Global Positioning System, GPS), and possibly gather additional information from the on-board diagnostics (OBD).
As time passed, technological advancements made it possible to acquire this type of information by relying on smartphones' sensors. An advantage of smartphones is that they do not require additional costs to be paid by the driver (since he/she does not have to buy dedicated hardware), they have access to communication networks needed for data transfer, and can even process data onboard, as they generally have more powerful processors than those contained in black-boxes.
Applications able to detect driving behaviors could indeed generate new revenue streams [12], especially in fleet management and insurance telematics fields.
Regarding fleet management, the objective is to collect and monitor data on the location and current conditions of corporate vehicles to inspect drivers' behavior and motivate them, e.g, to reduce travel time, lower fuel consumption, etc.
For what it concerns insurance telematics, the above devices are increasingly exploited in Usage-Based Insurance, a new form of insurance, in which the cost of a car insurance policy is computed not only on driver demographics data such as age, vehicle characteristics and location, but also includes information on the annual kilometers driven (the so-called Pay-As-You-Drive insurance), or on the behavior of the driver (the so-called Pay-How-You-Drive insurance) [13]. In particular, in Pay-How-You-Drive insurance, a score is assigned to the driver, based on the amount (and, in some case, of the type) of harsh events generated in a selected period. In some cases, the driver can also receive a feedback after each driving session or even during the drive, on how safe was/is her driving style, and on possible corrective measures.
In this work, we take a step forward with respect to insurance telematics, and propose a decentralized system, based on blockchain technology, to support gamification with the objective of promoting good driving behaviors. The proposed system is composed of a mobile application, used to record and process driving-related data, and a smart contract, devoted to managing the gamification logic. Our solution uses blockchain to ensure complete transparency in the competition's standings, final scores, entry fees, and prize money. Smart contracts automate functions when conditions are met, guaranteeing that winners receive their prizes when the game ends. This level of certainty and transparency is unattainable with centralized systems, where data could be modified. Moreover, to the best of our knowledge, no other works exist, that address driving behaviors using gamification. Our system could be either exploited by end users in a decentralized way, or could be easily integrated in more complex Pay-How-You-Drive insurance applications.
The rest of the paper is organized as follows: Section 2 presents relevant research works in the context of this paper. Section 3 provides an overview of the proposed system, whereas Section 4 discusses its costs and limitations. Finally, conclusions and future works are reported in Section 5.
This Section reports the results of the analysis of the state of the art and solutions identified in the literature for blockchain-based car insurance solutions tailored to drivers' driving styles. Additionally, we compare the identified solutions with our implementation, highlighting the differences and novelties introduced by our work. We excluded works based on centralized architectures for two reasons:
β’ blockchain offers advantages such as trust, transparency, and accessibility that are difficult to achieve with centralized solutions. This is why we chose a decentralized architecture. β’ Since we have chosen a blockchain-based solution, it is more useful to compare our work with other works that use blockchain, rather than those based on centralized architectures.
As just mentioned, all identified works are blockchain-based. However, the proposed architectures utilize different blockchain frameworks based on implementation choices. For instance, [14] offers a consortium/private blockchain-based solution developed with Hyperledger Fabric. This solution has advantages in terms of cost, throughput, and customization. However, its limited number of nodes and node owners restrict the traditional advantages in terms of decentralization, making it more similar to a centralized solution. The solution presented by [15] describes an architecture based on the concept of cross-chain, that is, a set of blockchains (even of different types and with different characteristics) connected by a relay blockchain that allows interoperability to store and exchange data. The authors mention WeCross as a cross-chain platform to be used to develop their solution. Although a cross-chain strategy provides network actors with greater flexibility in choosing which blockchain to use, it also makes the entire architecture technically more complex and more exposed to security risks due to operations such as synchronization between different blockchains. In [16], a comparable approach was taken, utilizing Tendermint as the basis for the proposed architecture, a framework that allows for the construction of customizable, modular, and Cosmos Network-compatible blockchains, which differ from classical public blockchains such as Ethereum in that they support the concept of asynchrony. Furthermore, the consensus mechanism, which differs from Ethereum's, allows for reduced transaction costs and latency while still maintaining decentralization. However, similar to the previous solution, this approach also requires higher development complexity (developing the blockchain in addition to the smart contracts), which inevitably increases exposure to bugs and security risks. Finally, works such as [17,18,19], including ours, leverage the public Ethereum blockchain to implement their solution. This design choice simplifies development by allowing programmers focus solely on developing smart contracts and implementation strategies. Additionally, Ethereum is currently the most widely used blockchain for coding decentralized applications, providing ample developer support.
When managing data privacy, it is crucial to compare various solutions for protecting sensitive driver data. Blockchain technology is a solution that does not allow data to be deleted or modified once it is stored in it, and one of the most important features of public blockchains is that they allow everyone to read the data. These properties ensure reliability, transparency, and accessibility but compromise the privacy of the data. Therefore, if sensitive data is present, appropriate protection techniques must be implemented. For instance, in works such as [14,18,16,19], data is encrypted with suitable algorithms before being stored on the blockchain, making it readable only to those with the private keys for decryption. Furthermore, [14,19] add an additional layer of security by leveraging Zero Knowledge Proof (ZKP) to allow users to prove they have the right informations for the requested tasks, such as their identity in the case of authentication, without sharing any sensitive data. In [17], the authors propose a privacy protection strategy based on the use of multiple temporary addresses. In general, an address is considered pseudonymous because the identity of its owner is unknown. However, since it is fixed, it is possible to make assumptions and extrapolate insights that allow tracing back to the identity of users. To partially solve the problem associated with pseudonymizing, different and temporary addresses can be used. The solution proposed by [15] involves aggregating data and working with the resulting aggregations, making it difficult or impossible to apply the inverse function to trace back to the original data. Finally, in our solution we distinguish between sensitive and non-sensitive data, storing only the latter on the blockchain for ranking drivers. Sensitive data is protected and kept private within a centralized database. It is read exclusively to populate the mobile app user page for each individual user.
An important aspect to consider when comparing our solution with the existing ones is how to evaluate driving. The cited works mainly use two methods: statistical analysis of parameters obtained during driving and calculation of a single score. The first method, used in [18,19,15], involves extrapolating statistical data from values received from drivers/vehicles, such as acceleration, braking, steering, and timing, to evaluate users' driving. The second method, used both in our work and in [17,16], aggregates the parameters obtained during driving through mathematical functions to calculate and assign a score to users. Additionally, a logistic regression model is utilized in [14] to calculate the driving evaluation score.
Our proposal introduces a new concept of gamification, which we have not identified in any other state-of-the-art work. The idea is to create a competition among drivers to promote safe driving by ranking them based on their scores during drives and rewarding the best ones with prizes (that, in the current implementation, are represented by tokens, but, should the proposed solution be adopted by insurance companies, could result in better/cheaper insurance policies). By incentivizing drivers to adopt a safer driving style, we can reduce the risk of traffic accidents. In addition, we have developed a mobile application that simplifies users' interaction with our solution and allows them to automatically capture and send driving data to the gamification unit.
Table 1 summarizes the comparison between the various solutions and ours described above.
In order to better understand the functioning of the developed system, it could be worth considering the activity diagram shown in Figure 1.
Since the gamification mechanism is guaranteed by the blockchain, the user interested in joining a game needs an Ethereum wallet. Hence, after the login, in case he/she is not in possession of a wallet, a new one is created and added to the user's profile. Then, in case the user is not already involved in a game, he/she can decide whether to join an existing one, or create a new one. After this step, he/she could use the mobile app to insert details on the trip's destination (in this case, the mobile app displays the route), and he/she could start the trip. At the end of the trip, the number (and type) of harsh events triggered during the trip is computed, and this information is used to update the users' profile/score.
Figure 2 shows the system's architecture. As it is possible to see, smartphones' sensors are used to retrieve data related to the users' driving behavior. The computation is performed both on the smartphone itself (orange boxes), both on the blockchain (blue box). The developed modules/components are the following:
1. Sensors raw data acquisition/transformation module: this module acquires raw data from the smartphone sensors, and transforms them; 2. Events classification module: this module, starting from the transformed data, identifies and classifies driving events; 3. Score computation: this module computes a score for the just-ended trip, based on the identified harsh driving events; 4. Smart contract: the smart contract contains the gamification logic, and stores the scores obtained by the users involved in the game.
In the following, each module is described in detail.
This module relies on smartphone's sensors and retrieves acceleration and gps readings. In particular, accelerometer readings are acquired and then pre-processed through the gravity readings detected by the gravity sensor (in the data transformation phase), whereas the rotation sensor's readings are exploited for determining the device's orientation (more details will be provided in the following).
The accelerometer is a motion sensor that measures the acceleration force (in m/s 2 ) that is applied to a device on all the three physical axes (π₯, π¦, and π§), including the force of gravity. In particular, the three axes, when the device is held in the default orientation, are the following:
β’ The π₯ axis, that is horizontal. This axis is used to read lateral acceleration; β’ The π¦ axis, that is vertical and points up. This axis is used to read the force of gravity, as a stationary device has an acceleration value detected on the π¦ axis of +9.81 m/s 2 ; β’ The π§ axis, that points toward the outside of the screen face: in this system, coordinates behind the screen have negative π§ values. This axis is used to read frontal acceleration.
Based on the three readings acquired through the accelerometer, it is possibile to identify whether an event is harsh or not. In particular, in the case of harsh events, accelerometer readings along one or more axes are higher than those acquired during non-harsh events. An example is displayed in Figure 3.
Acquired raw data are then processed by using low-pass and high-pass filters. The objective of this transformation phase is to eliminate gravitational forces and reduce noise. In particular, for the application of low-and high-pass filters, the gravity sensor -a three-dimensional vector indicating the direction and magnitude of gravity -is used as in equations 1 and 2:
where π is a given axis (π₯, π¦ or π§), ππππ£ππ‘π¦ π is the gravity sensor's reading, πππππππππ‘πππ π is the acceleration data acquired for the axis π and πΌ is a constant.
Concerning GPS readings, raw data -acquired every second -are used as is, without further transformation, to record where a harsh event occurred.
This module takes as input the transformed sensors' data, and identifies harsh events, together with their type. In the literature, three main approaches have been explored to classify driving events: anomaly detection-, threshold-, and machine learning classifier-based methods [20].
For sake of simplicity, and to keep computation time low, we relied on threshold-based methods, and, in particular, on the "simple threshold" method reported in [20].
According to this approach, which refers to the individual sensors' readings:
β’ a sensor reading on the π§ axis (related to frontal acceleration) is labeled as "aggressive" when the value is higher than a certain acceleration threshold, or lower than a certain brake threshold; β’ a sensor reading on the π₯ axis (related to lateral acceleration) is labeled as "aggressive" when the absolute value of the acceleration is higher than a certain "harsh turn" threshold.
For the detection of harsh events, we considered the best configurations proposed by [20] and selected a moving windows of 4 seconds length. In particular, a moving window contains consecutive transformed sensors' data acquired in the last 4 seconds. If at least 50% of the sensors' readings in the window exceed a given threshold π‘, the event is labeled as "harsh". The threshold π‘ varies based on the event type, and, for the proposed system, we decided to rely on the following values: 0.25π for harsh accelerations and harsh braking -detected by analyzing accelerometer data acquired along the π§ axisand 0.3π for harsh turn events -detected by analyzing accelerometer data acquired along the π₯ axis -(an overview of thresholds proposed so far in the literature is reported in [20]). Once a harsh event has been detected, its transformed sensors' data, together with other information, are stored on the device's database, to be subsequently used for the computation of the driver's score (more details are provided in the following).
This module is in charge of computing the driver's score for both the single trip, and for the whole game.
Concerning a single trip, this module takes as input the number of harsh events identified by the event classification module, respectively, the harsh_acceleration_events_number, harsh_braking_events_number and harsh_cornering_events_number, and computes a score for the trip according to the following approach.
First of all, the score obtained by the user for harsh events is computed. In particular, the score depends on the number of different harsh events detected, and on the number of kilometers actually traveled during the trip (which is computed based on GPS data). In case of trips with the same number of harsh events, the shorter the trip (the lower the trip's number of kilometers) the more severe the impact of the detected harsh events is; i.e. two events of harsh acceleration detected on a trip of 100 kilometers have a different impact on the trip's score than two events of harsh acceleration detected on a trip of one kilometer.
In the former case, the score for the acceleration's driving behavior is higher than the one computed in the second case. The score is computed according to equation 3.
where πππ₯_π‘πππ_π ππππ is a parameter set to 100, by hypothesizing a maximum number of user's trips equal to 10, and a maximum score reachable in the whole game by each user equal to 1000 (the πππ₯_π‘πππ_π ππππ is equal to the maximum score obtainable in the game divided by the maximum number of user's trips); βπππ β_ππ£πππ‘π _ππ’ππππ contains the number of harsh events detected (per each harsh event type); π½ is introduced to distribute the number of detected harsh events on the trip's total kilometers, with the aim of differentiating the number of detected harsh events based on to the trip's length. As the trip's length is measured in kilometers, the value for π½ is set to 1000; the π ππ₯() function is used to avoid negative scores, in case of extremely bad driving behavior (the lowest assignable score is 0).
The reason behind the inclusion of the trip's length in the score computation is because some drivers could think that the less they travel, the lower the probability to commit harsh events will be, resulting in a higher score. Hence, we decided to introduce the trip's length, and to set a minimum amount of kilometers that need to be traveled for each trip, to avoid cheating (e.g., 10-meters travels with no harsh events).
Each βπππ β_ππ£πππ‘_π ππππ is then combined with the ones computed for other harsh events types, according to equation 4.
with 1 < π < 3, as the current system considers three types of harsh events (acceleration, braking, and cornering events). The βπππ β_ππ£πππ‘_π€πππβπ‘ is used to increase or reduce the contribution of a specific harsh events type (since we decided to assign the same weight to each harsh event type, we set the weight equal to 33.3% for each π).
It is worth remarking that the current equations currently consider all the harsh driving events as equals, without penalizing the score gained by the user based on "how harsh" the generated events were. In the future, the equations could be modified in order to take into account also how much the acceleration values recorded surpassed the threshold defined in Section 3.2.
The scores assigned to each trip are then added together to compute the overall score obtained by a driver during the whole game.
The Smart Contract1 is in charge of managing the competition, rankings, and prize distribution, whereas data related to the trip's scores and events is processed by the mobile app. In fact, once the user finishes a trip, all the sensors' data collected in the background are analyzed, in order to identify the number of harsh events and compute the score. Once the score has been calculated, this information is sent to the Smart Contract, that is in charge to manage the gamification part.
Given the public nature of the Ethereum blockchain, we had to pay particular attention to where to store data, in order to provide both transparency and driver privacy-preservation.
From the perspective of the drivers, the concept of transparency can be intended as related to the algorithms implemented to compute the score, to define the players' ranking, as well as to the way data acquired through the sensors are managed.
Table 2 provides an overview of the variables stored both on the mobile application and on the blockchain. In particular, concerning harsh events, we decided to store them only in the application's database. The information stored for each driving event is the location where the event occurred (longitude and latitude), the magnitude of the event (how "harsh" the event was), and the timestamp of the event. Also, the user can decide whether to store in the application's database the path he/she traveled, in order to have a diary of travels made. It is worth remarking that we decided to store information related to harsh events to increase transparency for the end user, as well as to make him/her better aware of his/her driving behavior. The user could also inspect previous trips by plotting the traveled path (if available) and harsh events generated on a map, as displayed in Figure 4 About the transparency of the gamification process, each player is allowed to look at the scores achieved by the other players, stored on the blockchain.
Concerning the transparency of the implemented algorithms, at the mobile app level, the user can inspect the mechanism behind the assigned scores, whereas at the blockchain level, the gamification logic is defined by the methods included in the Smart Contract, which are accessible and visible to everyone.
With regard to privacy-preservation, it is achieved, at the level of the mobile app, by allowing the users to access only those data related to their own trips and making other users' trips' data not visible. At the blockchain level, the privacy is preserved by making public only the scores achieved, without publishing the driving events, positions, and timestamps leading to those results.
Focusing on the gamification mechanism, the competition involves obtaining the highest score among participants within a limited time period. The driver should aim to drive accurately and avoid sudden maneuvers that could negatively impact the final score. Below is a comprehensive explanation of the developed process.
After registering in the app, drivers can choose to start a new game or join an existing one.
β’ Start a new game: the driver must call the init_game function of the smart contract through the app's GUI. This function requires the driver's nickname and the desired name of the game, which will serve as a unique identifier. Additionally, the function automatically initializes certain parameters, such as the started flag, which indicates whether the game is active, and the start and end timestamps of the competition. β’ Join an existing game: the add_player function of the smart contract is called, which requires the driver's nickname and the game identifier as parameters. The function will generate an error message if it cannot find a game with the requested identifier. Additionally, when a new player is added, the function verifies that the number of participants is equal to or greater than the minimum number of required participants defined by the variable N_MIN_PLAYERS. If this condition is met, the started flag is set to True and the game commences. A further check is performed to ensure that the number of participants does not exceed the maximum allowed, as defined by the variable N_MAX_PLAYERS.
To participate in the competition, drivers are required to pay an entry fee. The fees paid by all players are added together and stored in the variable total_amount for each game. The total_amount refers to the prize of the competition, which will be distributed in varying percentages to the players who finish in the top three positions of the final ranking.
At the start of the game, players can begin recording their trips through the mobile app. After each completed trip, the app calls the stop_trip function to end the current trip and interacts with the smart contract by calling the load_Trip function. The load_Trip function updates the score by storing it on the blockchain, receiving as parameters the score obtained during the trip and the name of the game in which one is participating.
Once the game is finished, the leaderboard becomes final and the competition winners are determined. They are rewarded with the amount collected during registration phase. The top three drivers are considered the winners and receive a portion of the total sum, with the first place winner receiving the largest percentage. To transfer funds to the winners, we have defined the sendPrize function, which transfers the established amounts to the players' addresses.
Competitions remain active for up to one year, after which they automatically end. The competition end date is updated when the minimum number of players is reached, and the one-year countdown starts from that time. If a player wishes to withdraw from the competition before its conclusion, they may do so by calling the Leave_game function. This function requires a string parameter containing the player's motivation and the name of the game from which they wish to withdraw. Once a player has withdrawn from the game, they will receive a refund of the registration fee, even though a penalty could be applied in the future.
The sequence diagram depicted in Figure 5 represents the main steps described above for the game process. Further information about the smart contract can be accessed via the Github repository.
This Section proposes a cost analysis for deploying the smart contract and executing its main functions. Additionally, our proposal serves as a prototype to demonstrate how adding gamification to the driving context, by leveraging blockchain technology, can incentivize users/drivers to adopt a safer driving style. However, there are several limitations that require further study and investigation to overcome.
Starting with the cost analysis, blockchains leverage consensus algorithms to ensure decentralization, reliability, and data security by allowing nodes in the network to agree and validate transactions. There are different types of consensus algorithms based on various strategies, but they all require computational effort, which must be paid for. Storing information or running code on a blockchain incurs a cost that varies depending on the blockchain, network congestion, and the value of the cryptocurrency used for payment. Currently, these parameters are highly variable, resulting in significant volatility in the cost of executing transactions over time.
Among the various public blockchains available, we chose Ethereum because, as stated in Section 2, it is the most commonly used blockchain for developing decentralized applications and programming smart contracts, despite not being the most cost-effective. Smart contracts on Ethereum are executed through the Ethereum Virtual Machine (EVM), which is a virtual machine shared among all nodes in the network. The cost of executing functions is measured in Gas Units, with the price per Gas Unit Table 3 displays the gas units required to execute the primary functions of our smart contract and the corresponding dollar value calculated by multiplying the gas units by the base cost of each unit. The calculation reveals that the most expensive function is Init_game, with a cost of $61.74, which is relatively high. Our focus was on the feasibility and operation of the smart contract. Therefore, we have not placed significant emphasis on optimizing the code, which could potentially reduce the number of gas units required for execution.
Despite the optimizations, Ethereum remains an expensive solution. To reduce costs, we decided to check the cost of our smart contract on a cheaper public blockchain. We chose Polygon, which is also based on EVM, allowing us to use the same smart contract without any changes from Ethereum. The units of gas required to execute the functions remain unchanged since they are always executed on EVM. The cost per unit of gas has changed, and as of the time of writing this paper, it is equivalent to 88 GWei, which is less than $0.01. Table 3 presents the same calculation on both Ethereum and Polygon, and it shows that the most expensive function remains Init_game, with a total cost of $0.03. Thus, regardless of optimizations, our solution would not only be functional but also cheap and exploitable if the smart contract were deployed on a Polygon-like blockchain.
In addition to the cost of functions and possible optimization of smart contract code, there are still limitations that require further attention. A first limitation concerns score computation transparency. Currently, computation occurs off-chain, so users lack access to the algorithm and intermediate values. At the same time, moving computation on-chain would raise costs and hinder real-time data reception from sensors. Therefore, a potential solution is introducing a network of oracles, which would provide greater trust through decentralized computation without an excessive increase in cost. However, this requires further investigation before integration. Moreover, currently, a user can initiate, complete, and store a trip even if they are not the driver or if they are not moving by car (e.g., walking or using public transportation). To address the issue of driver and vehicle checks, our solution proposes performing vehicle recognition by ID and allowing users to register and associate their vehicles within the app. Additionally, our solution aims to promote safe driving practices, which can lead to reduced pollution levels. However, users may be incentivized to use their vehicles more in order to climb the ranking and achieve the highest score, which could cancel out the benefits of safe driving from an environmental perspective. To address this issue, user registration could be limited to those with electric vehicles, thus incentivizing a transition to electric vehicles, a key aspect of reducing pollutant emissions. With regard to the security of our solution, although measures to protect users' privacy have already been implemented, additional analysis and integration of security tools would provide users with an even more secure and reliable solution that does not compromise their privacy.
Finally, we set one year as the duration of the game, as this is the average duration of a car insurance policy in the event that our solution is integrated into a "Pay-How-You-Drive" system. Consequently, it was difficult to concretely demonstrate our solution's efficiency in promoting safer driving. However, we drew upon studies, such as [21,22], that have shown how introducing a gamification-based system engages users, motivating them to adopt new habits to achieve game goals.
This article presented a decentralized solution that incentivizes drivers to follow a safer driving style. Our proposal introduced gamification, which is an innovation in this context. The analysis of the state of the art and comparison with existing decentralized solutions revealed that no other solution has implemented this technique, to the best of our knowledge. In contrast, we used gamification to encourage safe driving by creating a competition based on rankings and scores that reflect users' driving style. Additionally, we planned to incentivize good driving behavior by rewarding the best drivers. To comprehend the development and implementation of our solution, we provided a detailed description of the architecture and its main components. This included the data receiving, event ranking, and scoring modules. Additionally, we explained the smart contract for managing the game stages and its interactions with the mobile application, demonstrating the entire process of participating in the competition. Finally, a cost analysis was conducted. The results showed that although the Ethereum blockchain is widely used, it may be too expensive for users during the production phase. The objective of this study was to develop and test a prototype platform (mobile app, smart contract, and DB) to demonstrate the feasibility and its benefits to users. Therefore, additional analysis of cybersecurity aspects is necessary before implementing a platform that can be usable. Additionally, the limitations outlined in Section 4 must be addressed. In future works, we plan to prioritize the security of both the smart contract and the mobile application to create a platform that is resilient to cyber-attacks and provides reliability to users. In terms of cost reduction, we plan to test and compare the implementation on various public blockchains to identify the ones that offer the necessary technical features and cost-effectiveness.
This study was carried out within the MICS (Made in Italy -Circular and Sustainable) Extended Partnership and received funding from the European Union Next-GenerationEU (PIANO NAZIONALE DI RIPRESA E RESILIENZA (PNRR) -MISSIONE 4 COMPONENTE 2, INVESTIMENTO 1.3 -D.D. 1551.11-10-2022, PE00000004). This manuscript reflects only the authors' views and opinions, neither the European Union nor the European Commission can be considered responsible for them.