CN113946829B - Block chain-based Internet of vehicles distributed trust system - Google Patents

Block chain-based Internet of vehicles distributed trust system Download PDF

Info

Publication number
CN113946829B
CN113946829B CN202111169746.1A CN202111169746A CN113946829B CN 113946829 B CN113946829 B CN 113946829B CN 202111169746 A CN202111169746 A CN 202111169746A CN 113946829 B CN113946829 B CN 113946829B
Authority
CN
China
Prior art keywords
rsu
leader
message
event
election
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202111169746.1A
Other languages
Chinese (zh)
Other versions
CN113946829A (en
Inventor
毕远国
黄子烜
李庆兵
蒋存宇
赵祉怡
Original Assignee
东北大学
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 东北大学 filed Critical 东北大学
Priority to CN202111169746.1A priority Critical patent/CN113946829B/en
Publication of CN113946829A publication Critical patent/CN113946829A/en
Application granted granted Critical
Publication of CN113946829B publication Critical patent/CN113946829B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/30—Decision processes by autonomous network management units using voting and bidding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/009—Security arrangements; Authentication; Protecting privacy or anonymity specially adapted for networks, e.g. wireless sensor networks, ad-hoc networks, RFID networks or cloud networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

The invention belongs to the technical field of Internet of vehicles safety, and provides an Internet of vehicles distributed trust system based on a block chain. The system provides a new trust model, the model divides the whole Internet of vehicles into different autonomous areas, RSUs in each autonomous area autonomously operate the trust mechanism in the autonomous area, temporary blockchains are used in the autonomous area to achieve data consistency in the autonomous area, and a permanent blockchain consensus mechanism is used between the autonomous areas to achieve data global consistency. Trust mechanisms are made available and blockchain update speeds are increased by proposing new trust calculation methods and improving permanent blockchain consensus mechanisms.

Description

Block chain-based Internet of vehicles distributed trust system
Technical Field
The invention belongs to the technical field of Internet of vehicles safety, and relates to an Internet of vehicles distributed trust mechanism based on a blockchain.
Background
The internet of vehicles mainly comprises an automobile provided with a sensor On Board Units (OBU), and entities such as a Road Side Units (RSU) provided with a communication module. The network communication equipment is arranged in the entities such as vehicles and RSU in the Internet of vehicles, so that the communication between the vehicles can be realized, and richer services are provided for the vehicles. The communication mode in the internet of vehicles is currently called vehicle and everything interconnection (Vehicle To Everything, V2X). The communication modes mainly comprise a vehicle-to-vehicle (Vehicle To Vehicle, V2V), a vehicle-to-infrastructure (Vehicle To Infrastructure, V2I) and the like. People pay attention to the convenience brought by the internet of vehicles and pay attention to the safety problem of the internet of vehicles, wherein the trust problem is very prominent. Meanwhile, due to the characteristics of large mobility, wide range of motion and short interaction time of vehicles, a long-term stable trust relationship is difficult to establish between vehicle nodes in the internet of vehicles, real-time performance and safety cannot be guaranteed only by the vehicles or third parties, malicious vehicles possibly exist in the internet of vehicles, and the malicious vehicles can issue false messages to maliciously distort facts under the driving of own interests or other factors, or the internet of vehicles is used for invading and stealing privacy information of other vehicles to gain benefits. The internet of vehicles mainly solves this problem by using a trust management mechanism. And a well designed trust management mechanism model rewards honest vehicles or publishes malicious vehicles through reputation evaluation and identity authentication, so that the reliability of the Internet of vehicles broadcasting information is ensured.
Blockchain concepts have attracted worldwide attention since being proposed in bitcoin white paper in 2008. The blockchain employs a decentralised infrastructure and distributed storage consensus technique, allowing payments to be completed without any banks or any intermediaries, so the blockchain is used for various financial services. The method needs to ensure the consistency of the global distributed data without the existence of a third party certification authority, can enable any terminal to take the data from the terminal and verify the content of the data, and enables any part of the uplink data not to be tampered by means of file fingerprints. The system has natural trust and distributed attributes, and the blockchain is applied to the internet of vehicles trust mechanism to enhance the credibility of the trust mechanism, so that the uplink information in the internet of vehicles has non-falsifiability, and meanwhile, the data consistency of the internet of vehicles is ensured. The application of the block chain in the Internet of vehicles still has difficulty to be solved, the huge calculation power required by the block chain in the mining process is that the Internet of vehicles with limited resources is difficult to support, and the update speed of the block chain is also difficult to meet the data update requirement of the Internet of vehicles. By solving and relieving the problem of the application of the blockchain in the Internet of vehicles, an effective blockchain-based Internet of vehicles distributed trust mechanism is established, so that trust among vehicles can be established, communication quality is improved, malicious vehicles are eliminated, and the system is helpful for building a safe Internet of vehicles network environment.
Disclosure of Invention
The invention aims to provide a distributed trust mechanism of the Internet of vehicles based on a block chain, and provides a new trust calculation method and an improved permanent block chain consensus mechanism based on a mixed consensus mechanism of distributed computing Proof of Work (PoW) and Proof of rights (PoS) to enable the trust mechanism to be available and the block chain updating speed to be accelerated.
The technical scheme of the invention is as follows: the distributed trust mechanism of the Internet of vehicles based on the blockchain is characterized in that firstly, an integral model structure of the trust mechanism is built; dividing the overall Internet of vehicles into a plurality of autonomous areas;
Firstly, a election process of a leader RSU is proposed, wherein the leader RSU is used as a main manager of an autonomous area and is mainly used for explaining the general view of a trust mechanism and calculating information of a trust related value:
the RSU will only elect a new leader if it is deemed that there is no leader or that the leader is not functioning properly, and four aspects of the comparison are mainly performed during the election: the latest block number ZXID of the participated election RSU, the spare power HOLDID, the RSU number RSUID and the logic clock LOOPID;
The RSU has 4 states in total, namely a follower state, a leader state, a election person state and an observer state; the RSU only participates in election under the state of being in the election person; the starting process is different from the selecting process in operation;
Under the condition that the RSU in the area just starts to start and then finds that no leader RSU exists in the current autonomous area, the current RSU automatically performs RSU election and takes the current RSU as an election target;
After the leader RSU elects, sending heartbeat messages and other RSUs to conduct data connection in a specified time so as to inform the other RSUs that the leader RSU works normally; if other RSUs do not receive corresponding heartbeats or any message sent by the leader or an incorrect leader message is received within a set time, the RSU automatically enters an election state to reelect the leader;
secondly, distinguishing the correctness of event information in the Internet of vehicles and trust related values of all vehicle nodes; calculating the correctness of the event data sent by the vehicle according to the related trust data of the vehicle; the correctness of the data influences the relative value of the vehicle information;
Thirdly, a double-block chain mechanism is proposed, wherein the double-block chain is mainly a data storage part in a trust mechanism and mainly operates in an RSU; the block chain is used for recording event-related trust data after calculation is completed in the autonomous region, and a non-hash autonomous region temporary chain consensus mechanism is adopted, so that the block chain is a structure for temporarily storing event-related information in the region; the other is a total blockchain of a permanent storage mechanism, a leader RSU in an area after a certain number of event messages are stored in the internal chain of the area, the related event messages are gathered and calculated to obtain related data changes related to a related vehicle trust account, the related data changes are formed into a total blockchain, and a mixed consensus mechanism based on distributed calculation workload certification and rights and interests certification is used for carrying out blockchain consistency consensus;
The persistent blockchain consensus mechanism is a hybrid consensus mechanism based on workload certification and equity certification of distributed computing.
The method for distinguishing the correctness of the event information in the Internet of vehicles and the trust related numerical values of the vehicle nodes is specifically shown as follows: two entities, namely a vehicle and an RSU, are mainly arranged in the autonomous region; wherein the vehicle plays two roles, a message sender and a message receiver; the method comprises the steps that an application for receiving event messages is always started in the running process of a vehicle, after a certain time is stored, the vehicle carries out evaluation calculation on collected messages of the same event by using influence from an RSU, and each message and an evaluation value thereof are uploaded to the RSU after the evaluation of each message is obtained; starting a corresponding vehicle-mounted sensor in the running process, and once the vehicle senses the occurrence of an event, sending out the sensed event information to other surrounding vehicles;
After the vehicle receives the related event message, calculating the message reliability, wherein the calculation formula is shown as formula (1) according to the distance between the vehicle issuing the message and the accident point and the reliability of the vehicle issuing the message;
in the formula (1), c j represents the credibility of the message, d j represents the distance between the vehicle and the place where the event occurs, w 1 represents the weight of the influence of the distance, b represents the minimum event trust value, r j represents the normalization of the forward influence of the vehicle, and the normalization formula is shown in the formula (2);
wherein R j is the influence value of the vehicle, and the value range is (-1, 1); f j is the number of continuous positive/negative influence events of the vehicle, and F j only records related information and uploads the related information if the number is less than or equal to 0, and does not participate in the calculation; r j and F j are stored in the global blockchain, and the vehicle is queried by the RSU; r j is a number no greater than 1, the greater R j and F j are, the greater R j, and R j represents the cumulative average of the impact of the vehicle in all events experienced;
the vehicle with the data trust degree can obtain the trust degree set about a certain event j The report message credibility of the vehicle k to the event j is expressed, and the true and false judgment of the event is carried out by using a formula (3);
When P (eC) in the formula (3) is more than or equal to Th, wherein Th is a threshold value, the event is considered to be real, otherwise, the event is considered to be false, the result is recorded, and an evaluation value of the message is obtained after the calculation is finished and is uploaded to the RSU; wherein the method comprises the steps of Is the opposite event of e; p (c k|e)＝ck,/>)Where P (e) is the prior probability of the event; evaluation value of message formula (4):
wherein gr is an evaluation value of the message, alpha is a current message source judgment coefficient, the size of the message is determined by the reason of a vehicle judgment event, and the calculation process is as shown in formula (5);
The RSU is used for electing after starting, and takes the RSU as an election target, and the election process comprises the following specific steps:
Step 1.1, the RSU which is just started directly enters a election person state, and the RSU broadcasts own election data to the RSU of the autonomous region; the data structure is < RSUID, ZXID, HOLDID, LOOPID >, wherein RSUID is the number of the voter RSU, ZXID is the number of the latest block, HOLDID is the free calculation power of the current RSU, LOOPID is the current number of voting rounds, each time the voting value is increased by one, only the previous round value of LOOPID greater than the RSU will be accepted by other RSUs;
Step 1.2, the other RSU just starts and does not detect the existence of the leader RSU, the operation of step one is executed, feedback and competitive choice information of the other RSU and competitive choice data of all other starting RSU are received, and the size of the competitive choice rounds is compared LOOPID with the size of the competitive choice rounds per se; setting LOOPID at starting to be 0, changing the election round number of the RSU into 1 when the election result is obtained, continuing to compare ZXID if the round number is consistent, wherein only the RSU with the latest most verified event copy can be elected, and most RSUs in the autonomous region are ZXID when the block chain in the autonomous region normally operates; if the two RSUs are different, discarding the same, continuing to compare HOLDID the value, which represents the computational margin at the moment when the RSUs send the competitive information, if HOLDID is larger than the RSUs which vote by themselves, changing the voting result of the themselves to be the current RSUs, if HOLDID is the same, continuing to compare RSUID, voting to the RSUs with the maximum RSUID; if one RSU does not vote on itself, the RSU enters a follower state from an election state;
Step 1.3, when the messages of all RSUs received in the set time are processed according to the step two, the final voting result of the RSU is obtained, and the voting result of the RSU is sent to all other RSUs;
step 1.4, after the RSU receives voting results of all other RSUs, processing the voting results; more than 50% of tickets are thrown to the same RSU, the RSU is directly used as a preliminary leader, and other RSUs except the preliminary leader enter an observer state;
Step 1.5, broadcasting a pre-commit command by the RSU serving as a preparation leader to confirm the final leader, and after receiving and submitting the command, judging whether the RSU is the RSU selected by the RSU or not by other RSUs, if so, sending a consent command, otherwise, not processing;
And step six, the RSU of the preparation leader becomes the leader after receiving 50% of the resubmitting command reply, and the election is finished.
The election process in the running of the RSU is specifically as follows:
step 2.1, if the RSU in the observer state does not receive any message sent by the leader RSU within a specified time, the leader RSU is considered to be invalid, the observer state is changed into an election state, and an election process is started, and the RSU sends out own election information in a format < RSUID, ZXID, HOLDID > in which LOOPID is 1 more than the number of election rounds in which the current RSU is located, and also receives the election messages sent by other RSUs;
Step 2.2, after receiving other election messages, the rsu compares LOOPID to see if the next round of election is started; starting a new round, generating and transmitting own election messages after the time of the own timer is over or the own election messages are received by the own leader RSU, and comparing all the election messages including the own; comparing ZXID to determine whether it is up to date, comparing HOLDID, and comparing RSUID if it is the same, and selecting with large number;
Step 2.3, all RSUs select a final leader RSU approved by the RSU according to the method of the step two and send the result to other RSUs;
step 2.4, the RSU receives and processes all voting results; more than 50% of the RSU is voted, the RSU is used as a preliminary leader of the election, and other RSUs except the RSU of the preliminary leader enter an observer state;
step 2.5, the RSU of the preparation leader broadcasts the pre-submitting command to confirm the final leader, other RSUs see whether the RSU is the RSU selected by themselves after receiving the pre-submitting command, if yes, an agreement message is sent, otherwise, the RSU is not processed;
And 2.6, after receiving 50% of the resubmitted command replies, the RSU of the preparation leader becomes the leader, and the election is ended.
The autonomous region temporary chain consensus mechanism comprises the following specific operation steps:
Step 3.1: after an RSU completes calculation of an Event, it becomes a presenter, firstly, the result and the Event data are sent to the leader RSU in the message format of < RSUID, message_type, timestamp, data, prehash, event_in > to obtain the publishing license, wherein RSUID is the number of RSU, message_type indicates the type of the message, timestamp is the timestamp indicating the first start of application for sharing, data part contains Event content, prehash is the hash value of the latest internal blockchain in the RSU of the current message to be published, and event_ influenc is Event influence;
Step 3.2: after receiving the event sharing message, the leader RSU performs message verification; firstly, verifying the signature of the RSU, then verifying the message type, and finally verifying prehash whether the RSU is the latest block hash, and performing subsequent comparison only if the RSU is verified; when a leader RSU receives a plurality of event sharing requests at the same time, only one event sharing is accepted at a time, the influence of the event is compared after the legal request is verified, the value with the largest influence is selected to allow uplink, if the influence of a plurality of events is identical, the size of a timestamp is compared, the earlier the time is, the larger the selected probability is, and when the influence of the event is identical, the message provided by the RSU with the largest number is directly selected;
step 3.3: after an event message is selected by a leader RSU, a sharing message license is sent to a corresponding RSU, the message is mainly formatted as < message_data, type, timestamp, leader_sign, hash >, wherein message_data is all messages which are sent to the leader RSU by the RSU, type is a message type, three conditions of permission, verification failing and waiting exist, timestamp is a timestamp, leader_sign is a signature given by the leader RSU by integrating message_data and type content, and hash is a hash value of the content; the leader RSU receives an event sharing request before receiving the last confirmation message, if the event influence of the sharing request is larger than the event for which the permission of sharing is given, the permission is given, all event messages given the permission are stored, and once one of the event messages is received, other messages are abandoned and given to wait for permission messages;
Step 3.4: after receiving the reply of the leader RSU, the presenter RSU first looks at what permission type is, if the permission type is the permission type, the information sent back by the leader RSU is directly converted into a sharing notice information and broadcast to all RSUs; if the verification is not passed, the presenter RSU will re-calculate the event and convert it into a learner, interact with the leader RSU and acquire the latest data, enter the receiver stage after completion and re-request; if the block is waiting, no message is sent out, the message at the moment is stored, the next round of block consensus is started, whether to continue to apply for submitting the event is determined, and the block consensus is actively converted into a receiver state;
Step 3.5: at this time, other RSUs which do not submit are in the receiver state, after receiving the related event sharing data, verifying the authenticity of the permission, and then looking at prehash of the data, if not adding blocks which are to be refused to be accepted but not confirmed to be submitted on the latest autonomous area blockchain, comparing the blocks with the blocks which are accepted by the presenter but not confirmed to be submitted, wherein the presenter only accepts the blocks with larger influence of the event, and the initial value is 0 when the blocks are not accepted; if the current block is confirmed to be accepted, the presenter sends an acceptance message to the presenter RSU; and waits for a message sent by the presenter RSU;
Step 3.6: after receiving 50% of the acceptance information, the presenter RSU sends a broadcast pre-presenter message to all RSUs, and after receiving the information, the receiver RSU sends a confirmation message to the presenter RSU if the RSU currently accepts the event information shared by the presenter RSU, and the presenter RSU itself is converted into a learner and does not accept other sharing event information received later; if the message accepted by the RSU is not the message submitted by the RSU, the RSU does not respond;
Step 3.7: if the presenter RSU receives the responses of the RSU with the number greater than or equal to 50 percent again, a presenter RSU sends a presenter message to a leader RSU request block uplink; the message format is as follows: < RSUID, type, signslist >, wherein signslist is a signature list; waiting if 50% of responses are not received, and converting to a learner to update the blockchain if the update message of the leader RSU is received subsequently, and storing the own blockcontents to prepare for subsequent resubmitting;
step 3.8: and after receiving the uplink request message of the RSU which issues the license, the leader RSU performs message verification, wherein the verification is performed by putting the corresponding block into the blockchain, and broadcasting an intra-autonomous area blockchain update message to inform all RSUs of performing intra-autonomous area blockchain update.
The distributed computing flow is as follows:
Step 4.1: firstly, a leader RSU determines an update block and calculates the difficulty value required to be obtained by the current block;
Step 4.2: if the leader RSU calculates that the difficulty value is the maximum value, namely 2Nm-1, the task allocation is not carried out, an arbitrary value is directly selected by the leader RSU to be filled in and the calculation is finished, and if the difficulty value is not the maximum value, the step III is turned to; dividing the corresponding calculated amount according to the longest allowable time;
Step 4.3: the calculation range should be given according to the communication delay, the time of the communication timing once, and the free calculation force of the corresponding RSU; firstly, calculating the delay of the RSU of each reply message and each leader RSU, wherein each leader RSU is provided with a table for recording the delay after being selected, and obtaining one-way delay by calculating the time of the message and the receiving time of the leader RSU, wherein the RSU needs to receive the message of the leader RSU once in the middle to confirm that the leader RSU survives, so that three communication is carried out in a normal cycle, the time of 3 gamma is required when gamma is one-way delay, the RSU re-initiates leader election when the communication is disconnected between the leader RSU and other RSUs for the maximum of s seconds is provided, and the hash try range which should be given is Rang max = (s-3 gamma) x M at the maximum;
Step 4.4: the leader RSU sends a calculation request containing an attempt range, the latest reply time of the request, an RSU number, a leader signature and a block header to an RSU corresponding to the RSU number;
step 4.5: after receiving the corresponding request, the RSU serving as the observer calculates, and if the calculation task is completed in a specified time but the correct value is not found, and meanwhile, other messages sent by the leader RSU are not received, the result is sent to the leader RSU to reply to the request for a new calculation task; stopping the calculation and sending a calculation stopping message to the leader RSU if the block verification confirmation information sent by the leader RSU is received in the calculation; stopping calculating and sending the block header and the nonce value to the leader RSU if the nonce value meeting the conditions is obtained by calculating; if the calculation cannot be finished according to the normal condition, a request delay message is sent to the leader RSU, wherein the request delay message comprises the changed secondary value for carrying out hash calculation every second, the calculated hash task and the unfinished hash calculation task range;
Step 4.6: after the leader RSU sends the calculation request message of the RSU, the leader RSU receives the value of calculation success and broadcasts the value to all RSUs to stop calculation; the step three is transferred to the step three to continue execution when the calculation request task is received; after receiving the delay message, recovering the unfinished task and transferring to the third step; if the RSU does not receive the message of the RSU within the set time, the RSU is considered to be failed, the previous task is recovered and the step three is carried out.
The follower state is a state of communicating with and synchronizing the leader RSU while participating in voting; the leader state is itself the leader; the state of the election person initiates an election hopefully to become a leader for the person himself, and the person participates in voting at the same time; the observer status is normal communication with the leader and no voting is performed.
Drawings
FIG. 1 is a block chain based flow chart of a distributed trust mechanism for Internet of vehicles.
Fig. 2 is a flow chart of RSU judging whether an event is true or false.
Fig. 3 is a flow chart of leader election at RSU start-up.
FIG. 4 is a diagram of a persistent blockchain distributed computing distribution graph.
Fig. 5 is a time-comparison diagram of the consensus mechanism and the existing consensus mechanism in the present invention.
Detailed Description
The following detailed description of the invention refers to the accompanying drawings.
In the method of the embodiment, the software environment is Ubuntu18.04 system, and the simulation environment is NS3 and SUMO simulation platform.
Step one: a road network is generated.
The method is created by adopting an automatic map modification invention, and comprises the following steps:
(1) And automatically generating an original road network file. Operating python osmwebwizard. Py under the tools folder in the SUMO installation folder;
(2) Generating a corresponding xml file by using sumo-c osm-fcd-output sumo trace. Xml, wherein the generated sumo trace. Xml file is a road network file, and then the road network file can be checked, and the command line is: sumo-guihello.sumofg;
(3) Generating a tcl file by using python traceExporter.py-i sumo trace.xml-NS 2mobility-output circles _ns3mobility.tcl, wherein the generated circles _ns3mobility.tcl file is track information of a vehicle and is also an input file used by NS2/NS 3;
step two: and testing the simulation environment.
SUMO is used to generate mobile tracking files, and NS3 is used to load these tracking files and run the internet of vehicles trust mechanism application. The following test operating environment, the procedure is as follows:
(1) Generating a new module and compiling and adding the new module into NS 3;
(2) Defining a header file, an NS3 namespace and a log;
(3) Defining a main function;
(4) Generating a network node;
(5) Physically connecting network nodes;
(6) Installing a protocol stack for each node;
(7) Installing an application layer;
(8) Starting a simulator;
(9) And (5) testing on the machine.
Inputting a command line at a terminal: sudo./waf- -run vanet-ns-simulator-example
In the traffic environment, the invention sets 32 RSU nodes, 956 vehicle nodes are used for testing, the ip address of the RSU is 10.2.0.1 to start 32 ips, the ip of the vehicle is 10.1.0.1 to start 56 ips, and the RSU is both the RSU node and the vehicle node. Input command line at start-up: sudo/NetAnim can pop up the interface. The menu bar in the figure can set playing time, the left interface displays network topology process, the right interface displays node information, the left interface displays position coordinates of various points, the points 0-955 are designated RSU, and the following points are RSU nodes. The right interface displays information such as id, position, and allocated ip address of the current driving node.
Step three: and verifying the validity of the internet of vehicles trust mechanism.
First, a corresponding trust mechanism is installed for each vehicle and RSU in the road, communication between them is determined, and a data center is installed on the RSU.
In summary, the system has been successfully implemented for the internet of vehicles trust mechanism.

Claims (6)

1. The distributed trust system of the Internet of vehicles based on the block chain is characterized in that an integral model structure of the trust system is built; dividing the overall Internet of vehicles into a plurality of autonomous areas;
firstly, an election process of a leader RSU is proposed, wherein the leader RSU is used as a main manager of an autonomous area and is used for explaining the general view of a trust mechanism and calculating information of a trust related value:
The RSU will only elect a new leader if it is deemed that there is no leader or that the leader is not functioning properly, and four aspects of the comparison are mainly performed during the election: the latest block ZXID of the RSU, the free computing power HOLDID, the RSU number RSUID and the logic clock LOOPID are participated in election;
The RSU has 4 states in total, namely a follower state, a leader state, a election person state and an observer state; the RSU only participates in election under the state of being in the election person; the starting process is different from the selecting process in operation;
Under the condition that the RSU in the area just starts to start and then finds that no leader RSU exists in the current autonomous area, the current RSU automatically performs RSU election and takes the current RSU as an election target;
After the leader RSU elects, sending heartbeat messages and other RSUs to conduct data connection in a specified time so as to inform the other RSUs that the leader RSU works normally; if other RSUs do not receive corresponding heartbeats or any message sent by the leader or an incorrect leader message is received within a set time, the RSU automatically enters an election state to reelect the leader;
Secondly, distinguishing the correctness of event information in the Internet of vehicles and trust related values of all vehicle nodes; calculating the correctness of the event data sent by the vehicle according to the related trust data of the vehicle; the correctness of the data influences the relative value of the vehicle information;
(III), the double-block chain is mainly a data storage part in a trust mechanism and mainly runs in the RSU; the block chain is used for recording event-related trust data after calculation is completed in the autonomous region, and a non-hash autonomous region temporary chain consensus mechanism is adopted, so that the block chain is a structure for temporarily storing event-related information in the region; the other is a total blockchain of a permanent storage mechanism, a leader RSU in an area after a certain number of event messages are stored in the internal chain of the area, the related event messages are gathered and calculated to obtain related data changes related to a related vehicle trust account, the related data changes are formed into a total blockchain, and a mixed consensus mechanism based on distributed calculation workload certification and rights and interests certification is used for carrying out blockchain consistency consensus;
the permanent blockchain consensus mechanism is a mixed consensus mechanism based on workload certification and rights certification of distributed computation;
the autonomous region temporary chain consensus mechanism comprises the following specific operation steps:
Step one: after an RSU completes calculation of an Event, it becomes a presenter, firstly, the result and the Event data are sent to the leader RSU in the message format of < RSUID, message_type, timestamp, data, prehash, event_in > to obtain the publishing license, wherein RSUID is the number of RSU, message_type indicates the type of the message, timestamp is the timestamp indicating the first start of application for sharing, data part contains Event content, prehash is the hash value of the latest internal blockchain in the RSU of the current message to be published, event_in is the Event influence;
Step two: after receiving the event sharing message, the leader RSU performs message verification; firstly, verifying the signature of the RSU, then verifying the message type, and finally verifying prehash whether the RSU is the latest block hash, and performing subsequent comparison only if the RSU is verified; when a leader RSU receives a plurality of event sharing requests at the same time, only one event sharing is accepted at a time, the influence of the event is compared after the legal request is verified, the value with the largest influence is selected to allow uplink, if the influence of a plurality of events is identical, the size of a timestamp is compared, the earlier the time is, the larger the selected probability is, and when the influence of the event is identical, the message provided by the RSU with the largest number is directly selected;
Step three: after an event message is selected by a leader RSU, a sharing message license is sent to a corresponding RSU, the message is mainly formatted as < message_data, type, timestamp, leader_sign, hash >, wherein message_data is all messages which are sent to the leader RSU by the RSU, type is a message type, three conditions of permission, verification failing and waiting exist, timestamp is a timestamp, leader_sign is a signature given by the leader RSU by integrating message_data and type content, and hash is a hash value of the content; the leader RSU receives an event sharing request before receiving the last confirmation message, if the event influence of the sharing request is larger than the event for which the permission of sharing is given, the permission is given, all event messages given the permission are stored, and once one of the event messages is received, other messages are abandoned and given to wait for permission messages;
Step four: after receiving the reply of the leader RSU, the presenter RSU first looks at what permission type is, if the permission type is the permission type, the information sent back by the leader RSU is directly converted into a sharing notice information and broadcast to all RSUs; if the verification is not passed, the presenter RSU will re-calculate the event and convert it into a learner, interact with the leader RSU and acquire the latest data, enter the receiver stage after completion and re-request; if the block is waiting, no message is sent out, the message at the moment is stored, the next round of block consensus is started, whether to continue to apply for submitting the event is determined, and the block consensus is actively converted into a receiver state;
Step five: at this time, other RSUs which do not submit are in the receiver state, after receiving the related event sharing data, verifying the authenticity of the permission, and then looking at prehash of the data, if not adding blocks which are to be refused to be accepted but not confirmed to be submitted on the latest autonomous area blockchain, comparing the blocks with the blocks which are accepted by the presenter but not confirmed to be submitted, wherein the presenter only accepts the blocks with larger influence of the event, and the initial value is 0 when the blocks are not accepted; if the current block is confirmed to be accepted, the presenter sends an acceptance message to the presenter RSU; and waits for a message sent by the presenter RSU;
Step six: after receiving 50% of the acceptance information, the presenter RSU sends a broadcast pre-presenter message to all RSUs, and after receiving the information, the receiver RSU sends a confirmation message to the presenter RSU if the RSU currently accepts the event information shared by the presenter RSU, and the presenter RSU itself is converted into a learner and does not accept other sharing event information received later; if the message accepted by the RSU is not the message submitted by the RSU, the RSU does not respond;
step seven: if the presenter RSU receives the responses of the RSU with the number greater than or equal to 50 percent again, a presenter RSU sends a presenter message to a leader RSU request block uplink; the message format is as follows: < RSUID, type, signslist >, wherein signslist is a signature list; waiting if 50% of responses are not received, and converting to a learner to update the blockchain if the update message of the leader RSU is received subsequently, and storing the own blockcontents to prepare for subsequent resubmitting;
Step eight: and after receiving the uplink request message of the RSU which issues the license, the leader RSU performs message verification, wherein the verification is performed by putting the corresponding block into the blockchain, and broadcasting an intra-autonomous area blockchain update message to inform all RSUs of performing intra-autonomous area blockchain update.
2. The distributed trust system of the internet of vehicles based on the blockchain according to claim 1, wherein the distinguishing of the correctness of the event information in the internet of vehicles and the trust related values of each vehicle node is specifically shown as follows: two entities, namely a vehicle and an RSU, are mainly arranged in the autonomous region; wherein the vehicle plays two roles, a message sender and a message receiver; the method comprises the steps that an application for receiving event messages is always started in the running process of a vehicle, after a certain time is stored, the vehicle calculates collected messages of the same event by using influence from an RSU, and each message and an evaluation value thereof are uploaded to the RSU after evaluation of each message is obtained; starting a corresponding vehicle-mounted sensor in the running process, and once the vehicle senses the occurrence of an event, sending out the sensed event information to other surrounding vehicles;
After the vehicle receives the related event message, calculating the message reliability, wherein the calculation formula is shown as formula (1) according to the distance between the vehicle issuing the message and the accident point and the reliability of the vehicle issuing the message;
in the formula (1), c j represents the credibility of the message, d j represents the distance between the vehicle and the place where the event occurs, w 1 represents the weight of the influence of the distance, b represents the minimum event trust value, r j represents the normalization of the forward influence of the vehicle, and the normalization formula is shown in the formula (2);
wherein R j is the influence value of the vehicle, and the value range is (-1, 1); f j is the number of continuous positive/negative influence events of the vehicle, and F j only records related information and uploads the related information if the number is less than or equal to 0, and does not participate in the calculation; r j and F j are stored in the global blockchain, and the vehicle is queried by the RSU; r j is a number no greater than 1, the greater R j and F j are, the greater R j, and R j represents the cumulative average of the impact of the vehicle in all events experienced;
the vehicle with the data trust degree can obtain the trust degree set about a certain event j The report message credibility of the vehicle k to the event j is expressed, and the true and false judgment of the event is carried out by using a formula (3);
When P (eC) in the formula (3) is more than or equal to Th, wherein Th is a threshold value, the event is considered to be real, otherwise, the event is considered to be false, the result is recorded, and an evaluation value of the message is obtained after the calculation is finished and is uploaded to the RSU; wherein the method comprises the steps of Is the opposite event of e; p (c k|e)＝ck,/>)Where P (e) is the prior probability of the event; evaluation value of message formula (4):
wherein gr is an evaluation value of the message, alpha is a current message source judgment coefficient, the size of the message is determined by the reason of a vehicle judgment event, and the calculation process is as shown in formula (5);
3. The distributed trust system of the internet of vehicles based on the blockchain according to claim 2, wherein the RSU performs RSU election immediately after starting and takes itself as an election target, and the election process comprises the following specific steps:
Step one, the RSU which is just started directly enters a election person state, and the RSU broadcasts own election data to the RSU of the autonomous area; the data structure is < RSUID, ZXID, HOLDID, LOOPID >, wherein RSUID is the number of the voter RSU, ZXID is the number of the latest block, HOLDID is the free calculation power of the current RSU, LOOPID is the current number of voting rounds, each time the voting value is increased by one, only the previous round value of LOOPID greater than the RSU will be accepted by other RSUs;
Step two, the other RSU just starts and does not detect the existence of the leader RSU, the operation of step one is executed, feedback and competitive choice information of the other RSU and competitive choice data of all other starting RSU are received, and LOOPID is compared with the competitive choice round number of the RSU; setting LOOPID at starting to be 0, changing the election round number of the RSU into 1 when the election result is obtained, continuing to compare ZXID if the round number is consistent, wherein only the RSU with the latest most verified event copy can be elected, and most RSUs in the autonomous region are ZXID when the block chain in the autonomous region normally operates; if the two RSUs are different, discarding the same, continuing to compare HOLDID the value, which represents the computational margin at the moment when the RSUs send the competitive information, if HOLDID is larger than the RSUs which vote by themselves, changing the voting result of the themselves to be the current RSUs, if HOLDID is the same, continuing to compare RSUID, voting to the RSUs with the maximum RSUID; if one RSU does not vote on itself, the RSU enters a follower state from an election state;
Step three, when the messages of all RSUs received in the set time are processed according to the step two, the final voting result of the RSU is obtained, and the voting result of the RSU is sent to all other RSUs;
Step four, the RSU receives voting results of all other RSUs and processes the voting results; more than 50% of tickets are thrown to the same RSU, the RSU is directly used as a preliminary leader, and other RSUs except the preliminary leader enter an observer state;
Step five, broadcasting a pre-submitting command by the RSU serving as a preparation leader to confirm the final leader, and after receiving the pre-submitting command, judging whether the RSU is the RSU selected by the RSU or not by other RSUs, if so, sending a consent command, otherwise, not processing;
And step six, the RSU of the preparation leader becomes the leader after receiving 50% of the resubmitting command reply, and the election is finished.
4. A blockchain-based internet of vehicles distributed trust system according to claim 3, wherein the RSU in operation election process is specifically as follows:
Step one, if the RSU in the observer state does not receive any message sent by the leader RSU within a specified time, the leader RSU is considered to be invalid, the observer state is changed into an election state, an election process is started, the self election information is sent out, the format is < RSUID, ZXID, HOLDID, LOOPID >, LOOPID is 1 more than the number of election rounds in which the current RSU is positioned, and meanwhile, the election messages sent by other RSUs are also received;
Step two, after receiving other election messages, the RSU compares LOOPID to see whether to start the next round of election; starting a new round, generating and transmitting own election messages after the time of the own timer is over or the own election messages are received by the own leader RSU, and comparing all the election messages including the own; comparing ZXID to determine whether it is up to date, comparing HOLDID, and comparing RSUID if it is the same, and selecting with large number;
step three, all RSUs select a final leader RSU approved by the RSU according to the method of the step two and send the result to other RSUs;
step four, the RSU receives and processes all voting results; more than 50% of the RSU is voted, the RSU is used as a preliminary leader of the election, and other RSUs except the RSU of the preliminary leader enter an observer state;
step five, broadcasting a pre-commit command by the RSU of the preparation leader to confirm the final leader, and after receiving the pre-commit command, judging whether the RSU is the RSU selected by the RSU or not, if so, sending an agreement message, otherwise, not processing;
And step six, the RSU of the preparation leader becomes the leader after receiving 50% of the resubmitting command reply, and the election is finished.
5. The blockchain-based internet of vehicles distributed trust system of claim 4, wherein the distributed computing flow is as follows:
step one: firstly, a leader RSU determines an update block and calculates the difficulty value required to be obtained by the current block;
step two: if the leader RSU calculates the difficulty value to be the maximum value, that is Directly selecting a value to fill in without performing a task allocation, ending calculation, and turning to the third step if the value is not the value; dividing the corresponding calculated amount according to the longest allowable time;
Step three: the calculation range should be given according to the communication delay, the time of the communication timing once, and the free calculation force of the corresponding RSU; firstly, calculating the delay of the RSU of each reply message and each leader RSU, wherein each leader RSU is provided with a table for recording the delay after being selected, the single-way delay is obtained by calculating the time of the message and the receiving time of the RSU, the RSU needs to receive the message of the leader RSU once in the middle to confirm the survival of the leader RSU, three times of communication are carried out in a normal cycle, 3 gamma time is required when gamma is the single-way delay, the leader RSU and other RSUs are provided to disconnect the communication for a maximum of more than s seconds, the RSU reinitiates leader election, and the given hash try range is Rang max = (s-3 gamma) multiplied by M;
step four: the leader RSU sends a calculation request containing an attempt range, the latest reply time of the request, an RSU number, a leader signature and a block header to an RSU corresponding to the RSU number;
Step five: after receiving the corresponding request, the RSU serving as the observer calculates, and if the calculation task is completed in a specified time but the correct value is not found, and meanwhile, other messages sent by the leader RSU are not received, the result is sent to the leader RSU to reply to the request for a new calculation task; stopping the calculation and sending a calculation stopping message to the leader RSU if the block verification confirmation information sent by the leader RSU is received in the calculation; stopping calculating and sending the block header and the nonce value to the leader RSU if the nonce value meeting the conditions is obtained by calculating; if the calculation cannot be finished according to the normal condition, a request delay message is sent to the leader RSU, wherein the request delay message comprises the changed secondary value for carrying out hash calculation every second, the calculated hash task and the unfinished hash calculation task range;
Step six: after the leader RSU sends the calculation request message of the RSU, the leader RSU receives the value of calculation success and broadcasts the value to all RSUs to stop calculation; the step three is transferred to the step three to continue execution when the calculation request task is received; after receiving the delay message, recovering the unfinished task and transferring to the third step; if the RSU does not receive the message of the RSU within the set time, the RSU is considered to be failed, the previous task is recovered and the step three is carried out.
6. The blockchain-based internet of vehicles distributed trust system of claim 5, wherein the follower status is in communication with and synchronizes a leader RSU status while participating in voting; the leader state is itself the leader; the state of the election person initiates an election hopefully to become a leader for the person himself, and the person participates in voting at the same time; the observer status is normal communication with the leader and no voting is performed.
CN202111169746.1A 2021-10-08 2021-10-08 Block chain-based Internet of vehicles distributed trust system Active CN113946829B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111169746.1A CN113946829B (en) 2021-10-08 2021-10-08 Block chain-based Internet of vehicles distributed trust system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111169746.1A CN113946829B (en) 2021-10-08 2021-10-08 Block chain-based Internet of vehicles distributed trust system

Publications (2)

Publication Number Publication Date
CN113946829A CN113946829A (en) 2022-01-18
CN113946829B true CN113946829B (en) 2024-05-10

Family

ID=79329947

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111169746.1A Active CN113946829B (en) 2021-10-08 2021-10-08 Block chain-based Internet of vehicles distributed trust system

Country Status (1)

Country Link
CN (1) CN113946829B (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115460222A (en) * 2022-09-05 2022-12-09 蚂蚁区块链科技(上海)有限公司 Block chain data flow calculating device

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108154704A (en) * 2017-12-27 2018-06-12 武汉邮电科学研究院 Wisdom shutdown system and method based on block chain
WO2019027889A1 (en) * 2017-08-02 2019-02-07 Bae Systems Information And Electronic Systems Integration Inc. System and method for incident reconstruction utilizing v2x communications
KR20190100092A (en) * 2019-08-08 2019-08-28 엘지전자 주식회사 Method for user authentication of vehicle in autonomous driving system and apparatus thereof
CN110933091A (en) * 2019-12-03 2020-03-27 丁奇娜 Block chain communication node verification method and device and electronic equipment
CN111756546A (en) * 2020-06-15 2020-10-09 杭州电子科技大学 Block chain consensus method based on dynamic credit mechanism in Internet of vehicles environment
CN111800421A (en) * 2020-07-06 2020-10-20 东北大学 Vehicle networking intrusion detection system based on hidden Markov model
WO2020258060A2 (en) * 2019-06-25 2020-12-30 南京邮电大学 Blockchain-based privacy protection trust model for internet of vehicles

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019027889A1 (en) * 2017-08-02 2019-02-07 Bae Systems Information And Electronic Systems Integration Inc. System and method for incident reconstruction utilizing v2x communications
CN108154704A (en) * 2017-12-27 2018-06-12 武汉邮电科学研究院 Wisdom shutdown system and method based on block chain
WO2020258060A2 (en) * 2019-06-25 2020-12-30 南京邮电大学 Blockchain-based privacy protection trust model for internet of vehicles
KR20190100092A (en) * 2019-08-08 2019-08-28 엘지전자 주식회사 Method for user authentication of vehicle in autonomous driving system and apparatus thereof
CN110933091A (en) * 2019-12-03 2020-03-27 丁奇娜 Block chain communication node verification method and device and electronic equipment
CN111756546A (en) * 2020-06-15 2020-10-09 杭州电子科技大学 Block chain consensus method based on dynamic credit mechanism in Internet of vehicles environment
CN111800421A (en) * 2020-07-06 2020-10-20 东北大学 Vehicle networking intrusion detection system based on hidden Markov model

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Huiqun Yuan ; Hongbin Qiu ; Ya Bi ; Sheng-Hung Chang ; Anthony Lam.Analysis of coordination mechanism of supply chain management information system from the perspective of block chain.2020,18(4),全文. *
基于区块链共识机制的多区域最优潮流分布式算法;张玲;陈思捷;严正;沈泽宇;中国电机工程学报;20201231(020);全文 *

Also Published As

Publication number Publication date
CN113946829A (en) 2022-01-18

Similar Documents

Publication Publication Date Title
CN111601258B (en) Vehicle networking node data safety communication method based on block chain
Guo et al. Proof-of-event recording system for autonomous vehicles: A blockchain-based solution
US11411721B2 (en) Systems and methods for selecting and utilizing a committee of validator nodes in a distributed system
Li et al. A reputation-based announcement scheme for VANETs
CN112541758A (en) Multi-round voting type fault-tolerant sequencing consensus mechanism and method based on block chain
EP3418998A1 (en) Road traffic management
Mišić et al. Adapting PBFT for use with blockchain-enabled IoT systems
CN104702418B (en) A kind of vehicle identity authentication method for dividing equally RSU calculation amounts
CN110445788B (en) Content-oriented trust evaluation system and method under vehicle-mounted ad hoc network environment
CN113099418B (en) Optimization method of block chain task for data transmission of Internet of vehicles
CN113992526B (en) Coalition chain cross-chain data fusion method based on credibility calculation
CN113946829B (en) Block chain-based Internet of vehicles distributed trust system
CN114745127A (en) Node credibility authentication method in Internet of vehicles environment based on block chain
Xu et al. Wireless distributed consensus for connected autonomous systems
Feng et al. Wireless distributed consensus in vehicle to vehicle networks for autonomous driving
CN112019380B (en) Right excitation-based block chain consensus method combining Raft and PBFT algorithm
CN110874738A (en) Method and device for collecting and processing traffic violation information of intelligent traffic control and intelligent traffic control
CN116582550A (en) Method for constructing cross-chain system based on trust evaluation, transaction transfer method and device
CN116761148A (en) V2X identity management system and authentication method based on blockchain
CN116389478A (en) Four-network fusion data sharing method based on blockchain and federal learning
CN115834512A (en) Data sharing method, system, electronic equipment and storage medium
Diallo et al. An improved PBFT-based consensus for securing traffic messages in VANETs
CN115189871A (en) Byzantine fault-tolerant consensus algorithm based on verifiable random function and threshold signature
CN114912137A (en) Vehicle reputation determination method and device based on vehicle running state information
CN116614311B (en) Mirror image signature method, device, service node, terminal and readable storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant