CN113946829A - Block chain-based vehicle networking distributed trust mechanism - Google Patents

Block chain-based vehicle networking distributed trust mechanism Download PDF

Info

Publication number
CN113946829A
CN113946829A CN202111169746.1A CN202111169746A CN113946829A CN 113946829 A CN113946829 A CN 113946829A CN 202111169746 A CN202111169746 A CN 202111169746A CN 113946829 A CN113946829 A CN 113946829A
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.)
Granted
Application number
CN202111169746.1A
Other languages
Chinese (zh)
Other versions
CN113946829B (en
Inventor
毕远国
黄子烜
李庆兵
蒋存宇
赵祉怡
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Northeastern University China
Original Assignee
Northeastern University China
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 Northeastern University China filed Critical Northeastern University China
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

Images

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 car networking safety, and provides a distributed trust mechanism of car networking based on a block chain. A novel trust model is provided in the mechanism, the model divides the whole Internet of vehicles into different autonomous regions, an RSU in each autonomous region autonomously operates a trust mechanism in the autonomous region, temporary block chains are used in the autonomous region to achieve data consistency in the autonomous region, and data global consistency is achieved between the autonomous regions through a permanent block chain consensus mechanism. A new trust calculation method and an improved permanent block chain consensus mechanism are provided to enable a trust mechanism and accelerate the block chain updating speed.

Description

Block chain-based vehicle networking distributed trust mechanism
Technical Field
The invention belongs to the technical field of car networking safety, and relates to a distributed trust mechanism of a car networking based on a block chain.
Background
The internet of vehicles mainly comprises an automobile provided with a sensor On Board Unit (OBU), a Road Side Unit (RSU) provided with a communication module and other entities. The network communication equipment is arranged on the entities such as vehicles and RSUs in the Internet of vehicles, so that mutual communication can be realized, and richer services are provided for the vehicles. The communication mode in the internet of vehicles is called Vehicle-To-Everything interconnection (V2X). The communication modes mainly include a Vehicle-To-Vehicle (V2V), a Vehicle-To-Infrastructure (V2I) and other communication modes. People pay attention to the convenience brought by the Internet of vehicles and also 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 vehicle mobility, wide activity range and short interaction time, a long-term stable trust relationship is difficult to establish between vehicle nodes in the internet of vehicles, only the vehicles or a third party cannot guarantee real-time performance and safety, malicious vehicles may exist in the internet of vehicles, and the malicious vehicles may issue false messages to maliciously distort the fact under the drive of own interests or other factors, or invade through the internet of vehicles to steal privacy information of other vehicles to gain benefits. This problem is mainly addressed in the internet of vehicles by using a trust management mechanism. A good trust management mechanism model is designed to reward honest vehicles or publish malicious vehicles through reputation evaluation and identity authentication, and reliability of internet of vehicles broadcast information is guaranteed.
Disclosure of Invention
The invention aims to provide a distributed trust mechanism based on a block chain for the Internet of vehicles, and provides a new trust calculation method and an improved permanent block chain consensus mechanism based on a mixed consensus mechanism of distributed calculation workload certificates (Proof of Work, PoW) and rights and interests certificates (Proof of Stack, PoS) to enable the trust mechanism to be available and accelerate the updating speed of the block chain.
The technical scheme of the invention is as follows: a distributed trust mechanism of Internet of vehicles based on block chain, first building an integral model structure of the trust mechanism; dividing the overall Internet of vehicles into a plurality of autonomous areas;
proposing an election process of a leader RSU, wherein the leader RSU is used as a main manager of the autonomous region and is mainly used for explaining an overall view of a trust mechanism and calculating information of trust correlation values:
the RSU will only perform the election of the new leader if there is no leader or if the leader is not functioning properly, there are four main aspects of the comparison during the election: participating in election of the latest block number ZXID, the spare calculation power HOLDID, the RSU number RSUID and the logic clock LOOPID of the RSU;
the RSU has 4 states in total, namely a follower state, a leader state, a voter state and an observer state; the RSU participates in the election only in the state of the election person; the selection process is different from the selection process in operation when the system is started;
under the condition that the RSU in the area is not provided with a leader RSU in the current autonomous region after being started, the current RSU automatically carries out RSU election and takes the current RSU as an election target;
after the leader RSU elects, sending heartbeat messages to carry out data connection with other RSUs within a specified time so as to inform the other RSUs that the leader RSU works normally; if other RSUs do not receive corresponding heartbeats and any message sent by the leader or receive wrong leader messages within a specified time, the RSUs automatically enter an election state to re-elect the leader;
(II) distinguishing the correctness of the event information in the Internet of vehicles and the trust related numerical 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 relevant values of the vehicle information;
a double-block chain mechanism is proposed, wherein the double-block chain is mainly a data storage part in a trust mechanism and mainly runs in an RSU; one block chain is used for recording event related trust data after calculation in an autonomous region, adopts a non-Hash autonomous region temporary chain consensus mechanism and is a structure for temporarily storing related event messages in the region; the other is an overall block chain of a permanent storage mechanism, a leader RSU in the region stores a certain number of event messages, and after the event messages are aggregated and calculated by an internal chain of the region, the related event messages are calculated to obtain related data changes of a vehicle trust account, the related data changes form an overall chain block chain, and block chain consistency consensus is performed by using a mixed consensus mechanism based on workload certification and rights and interests certification of distributed calculation;
the persistent blockchain consensus mechanism is a hybrid consensus mechanism based on workload proofs and equity proofs for distributed computing.
The method for distinguishing the correctness of the event information in the internet of vehicles and the trust related numerical values of each vehicle node is characterized in that: two entities, namely a vehicle and an RSU, are mainly arranged in the autonomous region; wherein the vehicle plays both the message sender and the message receiver roles; the method comprises the steps that an application for receiving event messages is started all the time in the running process of a vehicle, after a certain time of storage, the vehicle evaluates and calculates collected messages of the same event by utilizing influence inquired from an RSU, and uploads each message and an evaluation value thereof to the RSU after evaluation of each message is obtained; starting a corresponding vehicle-mounted sensor in the driving process, and sending out the sensed event message to other surrounding vehicles once the vehicle senses the occurrence of the event;
after the vehicle receives the relevant event message, calculating the message reliability, and according to the distance between the vehicle issuing the message and the accident point and the credibility of the vehicle issuing the message, calculating the formula as formula (1);
Figure BDA0003292428340000041
c in formula (1)jIndicating the trustworthiness of the message, djRepresenting the distance, w, between the vehicle and the place of occurrence1Weight representing distance impact, b is a confidence value representing minimum event, rjRepresenting the normalization of the self positive influence of the vehicle, wherein the normalization formula is shown as a formula (2);
Figure BDA0003292428340000042
in the formula RjIs the influence value of the vehicle, and the value range is (-1, 1); fjIs the number of consecutive positive/negative influencing events, F, of the vehiclejIf the number is less than or equal to 0, only relevant information is recorded and uploaded, and the relevant information does not participate in the calculation; rjAnd FjThe vehicle is stored in a global block chain and inquired through an RSU; r isjIs a number not greater than 1, RjAnd FjThe larger the rjThe larger RjRepresents the cumulative average of the vehicle's influence over all events experienced;
the vehicle with the data credibility can obtain a credibility set about a certain event j
Figure BDA0003292428340000043
Figure BDA0003292428340000044
Representing the reliability of the report message of the vehicle k to the event j, and carrying out the true and false judgment of the event by using a formula (3);
Figure BDA0003292428340000051
when P (e | C) ≧ Th in the formula (3), 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 the evaluation value of the message is obtained after the calculation is finished and is uploaded to the RSU; wherein
Figure BDA0003292428340000052
A contra event of e; p (c)k|e)＝ck，
Figure BDA0003292428340000053
Where P (e) is the prior probability of an event; evaluation value equation (4) of the message:
Figure BDA0003292428340000054
in the formula, gr is an evaluation value of the message, alpha is a current message source judgment coefficient, the size of the current message source judgment coefficient is determined by the reason of the vehicle judgment event, and the calculation process is as shown in a formula (5);
Figure BDA0003292428340000055
the RSU election is carried out after the RSU is started and is taken as an election target, and the election process comprises the following specific steps:
step 1.1, the RSU which is just started directly enters into the state of the voter, and the RSU broadcasts the election data of the RSU to the RSU of the autonomous region; the data structure is < RSUID, ZXID, HOLDID, LOOPID >, wherein RSUID is the number of the election person RSU, ZXID is the number of the latest block, HOLDID is the spare calculation power of the current RSU, LOOPID refers to the number of the current voting rounds, each voting value is increased by one, and only the LOOPID is larger than the value of the front round of the RSU and is recognized by other RSUs;
step 1.2, other RSUs are just started and do not detect the existence of the leader RSU, the operation of the step one is executed, feedback and election messages of other RSUs and election data of all other started RSUs are received, and LOOPID and the number of election rounds where the other RSUs are located are compared; setting LOOPID to be 0 when starting, changing the election round number of the RSU into 1 when the election result is obtained, continuously comparing ZXIDs if the round number is consistent, only the RSU with the latest and most verified event copy can be elected, and if the block chain in the autonomous region normally runs, most of the RSUs in the autonomous region should use the same ZXID; if the two numbers are different, abandoning the numbers, if the numbers are the same, continuously comparing the HOLDID numbers, which indicates that the RSU sends the competition information, the calculation power is free, if the HOLDID is larger than the RSU voted by the user, changing the voting result of the user into the current RSU, if the HOLDID is the same as the RSU voted by the user, continuously comparing the RSUID, and voting the RSU with the maximum RSUID; if an RSU does not cast a ticket to the RSU, the RSU enters a follower state from an elector state;
step 1.3, when the messages of all RSUs received in the specified time are processed according to the step two, the final voting result of the voting machine is obtained, and the voting result of the voting machine is sent to all other RSUs;
step 1.4, the RSU receives the voting results of all other RSUs and then processes the voting results; if more than 50% of tickets are thrown to the same RSU, the RSU is directly used as a preparation leader, and other RSUs except the preparation leader enter a watcher state;
step 1.5, the RSU serving as the preparation leader broadcasts a pre-submission command to carry out final leader confirmation, other RSUs receive and submit the command and then see whether the RSU is the RSU selected by the RSU, if so, an agreement command is sent, otherwise, the RSU is not processed;
and step six, the prepared leader RSU becomes a leader after receiving 50% of the responses of the pre-submitted commands, and the election is finished.
The election process in the operation of the RSU is as follows:
step 2.1, the RSU in the observer state does not receive any message sent by the leader RSU within the specified time, then the leader RSU is considered to be invalid, the RSU is changed into the election state from the observer state, the election process is started, the election information of the RSU is sent out, the election process is in a format of < RSUID, ZXID, HOLDID and LOOPID >, wherein the LOOPID is 1 more than the number of election rounds of the current RSU, and meanwhile election messages sent by other RSUs are also received;
step 2.2, after receiving other election messages, the RSU compares the LOOPID to see whether to start the next round of election; starting a new round, generating and sending own election messages after the time of the own timer is over or the own timer receives error messages sent by the leader RSU, and comparing all the election messages including the own election messages; firstly, comparing whether ZXID is the latest, comparing the sizes of HOLDID, if the ZXID is the latest, comparing the last RSUID, and selecting the serial number with the highest number;
step 2.3, all RSUs select the 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; if more than 50% of the RSUs vote, the RSU is taken as a preparation leader of the election, and other RSUs except the preparation leader RSU enter a watcher state;
step 2.5, preparing the leader RSU to broadcast the pre-submission command to carry out the final leader confirmation, and after receiving the pre-submission command, other RSUs see whether the RSU is the RSU selected by the RSU, if so, sending an agreement message, otherwise, not processing the agreement message;
and 2.6, the preparation leader RSU becomes a leader after receiving 50% of the pre-submission command reply, and the election is finished.
The specific operation steps of the autonomous region temporary chain consensus mechanism are as follows:
step 3.1: after an RSU completes the calculation of an Event, the RSU becomes a presenter, firstly, the result and Event data are sent to a leader RSU in a message format of < RSUID, message _ type, timestamp, data, hash and Event _ influece >, and release permission is obtained, wherein RSUID is the number of the RSU, message _ type indicates the type of the message, timestamp is a timestamp indicating the first time of applying for sharing, data part comprises Event content, hash is the hash value of the latest internal block chain in the RSU of the current message to be released, and Event _ influenc is Event influence;
step 3.2: the leader RSU carries out message verification after receiving the event sharing message; firstly, the signature of the RSU is verified, then the message type is verified, and finally whether the hash is the latest block hash is verified, and subsequent comparison can be carried out only if the verification is passed; when a leader RSU receives a plurality of event sharing requests at the same time, sharing of one event is received at one time, the influence of the events is compared after the request is verified to be legal, a numerical value with the largest influence is selected for allowing uplink, if the influence of a plurality of events is completely the same, the size of a timestamp is compared, the earlier the time is, the higher the probability of selection is, and if the influence of the plurality of events is the same, the message provided by the RSU with the largest number is directly selected;
step 3.3: after a leader RSU selects an event message, sending a sharing message permission to a corresponding RSU, wherein the message is mainly in a format of < message _ data, type, timestamp, leader _ sign, hash >, the message _ data is message data and contains all messages sent by the RSU to the leader RSU, the type is a message type, three conditions of permission, verification failure and waiting exist, the timestamp is a time stamp, the leader _ sign is a signature given by the leader RSU by integrating the content of the message _ data and the type, and the hash is a hash value of the content; the leader RSU receives the event sharing request before receiving the last confirmation message, gives permission if the event impact of the sharing request is greater than the event for which permission has been given, stores all event messages for which permission has been given, and gives up the other messages and gives the other messages a waiting permission message upon receiving a commit request of one of them;
step 3.4: after receiving the reply of the leader RSU, the presenter RSU firstly looks at what permission type is, if the permission type is the transmission-allowed type, the presenter RSU directly converts the message sent back by the leader RSU into a sharing announcement message and broadcasts the sharing announcement message to all RSUs; if the verification is not passed, the presenter RSU carries out event calculation again, converts the event calculation into a learner, interacts with the leader RSU and acquires the latest data, enters a receiver stage after the interaction is finished, and submits a request again; if the event is waiting, no message is sent, the message at the moment is stored, whether the event is continuously applied for submitting is determined after the block consensus is started in the next round, and the state is actively converted into a receiver state;
step 3.5: when other RSUs which are not submitted are in a receiver state, after relevant event sharing data are received, the allowed authenticity of the RSUs is verified, then the prehash of the data is seen, if the RSUs are not added to the latest autonomous area block chain, the RSUs are refused to be accepted, and then the RSUs are compared with blocks which are accepted by the RSUs but are not confirmed to be submitted, the submitter only accepts the blocks with larger event influence, and the initial value is 0 when the blocks are not accepted; if the current block is confirmed to be accepted, the submitter sends an acceptance message to the presenter RSU; and waits for a message sent by the submitter RSU;
step 3.6: after receiving 50% of the receiving information, the submitter RSU broadcasts a pre-submission message to all RSUs, and after receiving the message, the receiver RSU sends a confirmation message to the submitter RSU if the RSU currently receives the event message shared by the submitter RSU, and the submitter RSU is converted into a learner and does not receive other shared event messages received after the submitter RSU; if the message accepted by the RSU is not the message submitted by the RSU, no response is made;
step 3.7: if the submitting RSU receives the response of the RSU with the quantity more than or equal to 50 percent again, sending a submitting message to the leader RSU to request block uplink; the message format is as follows: < RSUID, type, signlist >, where signlist is a list of signatures; if the response of 50% is not received, waiting, if the update message of the leader RSU is received subsequently, converting the update message into a block chain update for the learner, and storing the block content of the learner for subsequent resubmission;
step 3.8: and the leader RSU carries out message verification after receiving the uplink request message of the RSU which self issues permission, the verification is carried out by putting the corresponding block into the block chain, and the broadcast intra-cell block chain updating message informs all the RSUs to carry out intra-cell block chain updating.
The distributed computing process is as follows:
step 4.1: firstly, determining an updating block by a leader RSU, and calculating the difficulty value required to be solved by the current block;
step 4.2: if the leader RSU calculates that the difficulty value is the maximum value, i.e., 2Nm-1, directly selecting an arbitrary value to fill in and finish the calculation without performing the distribution task, and if not, turning to the third step; dividing 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 when the communication is timed once, and the free computing power of the corresponding RSU; firstly, the delay of the RSU of the leader RSU and each reply message is calculated, a table for recording the delay is provided after each leader RSU is selected, one-way delay is obtained by calculating the time of the message and the receiving time of the leader RSU, three times of communication are carried out in a normal cycle because the RSU needs to receive the message of the leader RSU once to confirm that the leader RSU is alive, and when gamma is the one-way delay and needs 3 gamma, the RSU is consideredIn between, it is stipulated that if the RSU re-initiates leader election when the communication between the leader RSU and other RSUs is disconnected for more than s seconds, the maximum hash attempt range size should be given is the Rangmax＝(s-3γ)×M；
Step 4.4: the leader RSU sends a calculation request comprising an attempt range, the latest reply time of the request, the RSU number, the leader signature and the block header to the RSU corresponding to the RSU number;
step 4.5: the RSU serving as the observer performs calculation after receiving the corresponding request, and if the calculation task is completed within the specified time but the correct value is not found, and other messages sent by the leader RSU are not received, the result is sent to the leader RSU to reply the request for the 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; if the nonce value meeting the condition is obtained through calculation, stopping calculation and sending the block head and the nonce value to the leader RSU; if the calculation cannot be finished according to the normal condition, a request delay message is sent to the leader RSU, and the changed times of the hash calculation per second, the hash tasks which are already calculated and the range of the unfinished hash calculation tasks are contained in the request delay message;
step 4.6: after the leader RSU sends the calculation request message of the RSU, the leader RSU receives the value of successful calculation and broadcasts the value to all the RSUs to stop calculation; if the calculation request task is received, the step three is carried out continuously; when the delay message is received, recovering the tasks which are not completed and transferring to the third step; if the RSU is not received in the specified time, the RSU is considered to be failed, and the previous task is recycled and the step three is carried out.
The follower state is in communication with and synchronizes the leader RSU state while participating in the vote; the leader state is that the leader is the leader of the leader; the voter state initiates the election to hope to become a leader and participates in voting at the same time; the observer state is normal communication with the leader and no voting is performed.
Drawings
Fig. 1 is a block chain-based distributed trust mechanism flow diagram of the internet of vehicles.
Fig. 2 is a flow chart of RSU determining whether an event is true or false.
FIG. 3 is a flow diagram of leader election at RSU startup.
FIG. 4 is a permanent blockchain distributed computing allocation map.
FIG. 5 is a time-wise comparison of the consensus mechanism of the present invention with existing consensus mechanisms.
Detailed Description
The following detailed description of embodiments of the invention refers to the accompanying drawings.
In the method of the embodiment, the software environment is an ubuntu18.04 system, and the simulation environment is NS3 and a SUMO simulation platform.
The method comprises the following steps: a road network is generated.
The method is created by adopting a mode of automatically modifying the invention map, and comprises the following steps:
(1) and automatically generating an original road network file. Running python osmWebwizard. py under the tools folder in the SUMO installation folder;
(2) using sumo-c os.sumocfg-fcd-output sumottrace.xml to generate a corresponding xml file, which is a road network file, and then viewing it, command line: sumo-guihello. sumocfg;
(3) generating a tcl file by using python transport export, py-i submit, xml-NS 2mobility-output circuits, NS3mobility, tcl, wherein the generated circuits, NS3mobility, tcl, are track information of the vehicle and are input files 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 car networking trust mechanism application. The operating environment was tested as follows:
(1) generating a new module and compiling into the 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 the network nodes;
(6) installing a protocol stack for each node;
(7) installing an application layer;
(8) starting the simulator;
(9) and (6) testing on a machine.
Input of command line at 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 initial 32 ip, the ip of the vehicle is 10.1.0.1 initial 56 ip, wherein the RSU is the RSU node and the vehicle node. Input command line at startup: the sudo./NetAnim can pop up the interface. The menu bar in the figure can set the playing time, the left side interface displays the network topology process, the right side interface displays the node information, the left side interface displays the position coordinates of each point, the points 0-955 are the designated RSU, and the subsequent points are the RSU nodes. And the right interface displays information such as the id, the position, the allocated ip address and the like of the current driving node.
Step three: and verifying the effectiveness of the vehicle networking trust mechanism.
Firstly, a corresponding trust mechanism is installed for each vehicle and RSU in the road, the vehicles and the RSU are confirmed to communicate with each other, and the data center is installed on the RSU.
In conclusion, the system has successfully realized the function of the vehicle networking trust mechanism.

Claims (7)

1. A distributed trust mechanism of Internet of vehicles based on block chain is characterized in that an integral model structure of the trust mechanism is firstly established; dividing the overall Internet of vehicles into a plurality of autonomous areas;
the method comprises the following steps of (I) proposing an election process of a leader RSU, wherein the leader RSU is used as a main manager of an autonomous region and is mainly used for explaining an overall view of a trust mechanism and calculating information of trust correlation values:
the RSU will only perform the election of the new leader if there is no leader or if the leader is not functioning properly, there are four main aspects of the comparison during the election: participating in election of the newest block ZXID, the free computing power HOLDID, the RSU number RSUID and the logic clock LOOPID of the RSU;
the RSU has 4 states in total, namely a follower state, a leader state, a voter state and an observer state; the RSU participates in the election only in the state of the election person; the selection process is different from the selection process in operation when the system is started;
under the condition that the RSU in the area is not provided with a leader RSU in the current autonomous region after being started, the current RSU automatically carries out RSU election and takes the current RSU as an election target;
after the leader RSU elects, sending heartbeat messages to carry out data connection with other RSUs within a specified time so as to inform the other RSUs that the leader RSU works normally; if the other RSUs do not receive corresponding heartbeats and any message sent by the leader or receive wrong leader messages within a specified time, the RSUs automatically enter an election state to re-perform election of the leader;
distinguishing the correctness of event information in the Internet of vehicles and trust related numerical 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 relevant values of the vehicle information;
a double-block chain mechanism is proposed, wherein the double-block chain is mainly a data storage part in a trust mechanism and mainly runs in an RSU; one block chain is used for recording event related trust data after calculation in an autonomous region, adopts a non-Hash autonomous region temporary chain consensus mechanism and is a structure for temporarily storing related event messages in the region; the other is an overall blockchain of a permanent storage mechanism, after a certain number of event messages are stored in an internal chain of the region, a leader RSU in the region aggregates and calculates the related event messages to obtain related data changes of a vehicle trust account, the data changes form an overall chain blockchain, and a mixed consensus mechanism based on distributed calculation workload certification and rights and interests certification is used for block chain consistency consensus;
the persistent blockchain consensus mechanism is a hybrid consensus mechanism based on workload proofs and entitlement proofs for distributed computing.
2. The distributed trust mechanism for internet of vehicles based on block chain as claimed in claim 1, wherein the distinguishing of correctness of event information in the internet of vehicles and trust related numerical values of each vehicle node is represented by: two entities, namely a vehicle and an RSU, are mainly arranged in the autonomous region; wherein the vehicle plays both the message sender and the message receiver roles; the method comprises the steps that an application for receiving event messages is started all the time in the running process of a vehicle, after a certain time of storage, the vehicle calculates collected messages of the same event by utilizing influence inquired from an RSU, and uploads each message and an evaluation value thereof to the RSU after the evaluation of each message is obtained; starting a corresponding vehicle-mounted sensor in the driving process, and sending out the sensed event message to other surrounding vehicles once the vehicle senses the occurrence of the event;
after the vehicle receives the relevant event message, calculating the message reliability, and according to the distance between the vehicle issuing the message and the accident point and the credibility of the vehicle issuing the message, calculating the formula as the formula (1);
Figure FDA0003292428330000021
c in formula (1)jIndicating the trustworthiness of the message, djRepresenting the distance, w, between the vehicle and the place of occurrence1Weight representing distance impact, b is a confidence value representing minimum event, rjThe normalization formula represents the normalization of the self positive influence of the vehicle and is shown as the formula (2);
Figure FDA0003292428330000022
in the formula RjIs the influence value of the vehicle, and the value range is (-1, 1); fjIs a continuous positive/negative impact event of the vehicleQuantity, FjIf the number is less than or equal to 0, only recording related information and uploading the related information, and not participating in the calculation; rjAnd FjThe vehicle is stored in a global block chain and inquired through an RSU; r isjIs a number not greater than 1, RjAnd FjThe larger the rjThe larger RjRepresents the cumulative average of the vehicle's influence over all events experienced;
the vehicle with the data credibility can obtain a credibility set about a certain event j
Figure FDA0003292428330000031
Figure FDA0003292428330000032
The report message credibility of the vehicle k to the event j is shown, and the event true and false judgment is carried out by using a formula (3);
Figure FDA0003292428330000033
when P (e | C) ≧ Th in the formula (3), 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 the evaluation value of the message is obtained after the calculation is finished and is uploaded to the RSU; wherein
Figure FDA0003292428330000034
A contra event of e; p (c)k|e)＝ck，
Figure FDA0003292428330000035
Where P (e) is the prior probability of an event; evaluation value equation (4) of the message:
Figure FDA0003292428330000036
in the formula, gr is an evaluation value of the message, alpha is a current message source judgment coefficient, the size of the current message source judgment coefficient is determined by the reason of the vehicle judgment event, and the calculation process is as shown in a formula (5);
Figure FDA0003292428330000037
3. the distributed trust mechanism of the car networking based on the block chain as claimed in claim 2, wherein the RSU performs RSU election and takes itself as an election target immediately after the RSU starts to start, and the election process comprises the following specific steps:
step one, the RSU which is just started directly enters a voter 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 election person RSU, ZXID is the number of the latest block, HOLDID is the spare calculation power of the current RSU, LOOPID refers to the current number of voting rounds, each voting value is increased by one, and only the LOOPID is larger than the value of the front round of the RSU and is recognized by other RSUs;
step two, other RSUs are just started and do not detect the existence of the leader RSU, the operation of the step one is executed, feedback and election messages of other RSUs and election data of all other started RSUs are received, and LOOPID and the number of election rounds where the other RSUs are located are compared; setting LOOPID to be 0 when starting, changing the election round number of the RSU into 1 when the election result is obtained, continuously comparing ZXIDs if the round number is consistent, only the RSU with the latest and most verified event copy can be elected, and if the block chain in the autonomous region normally runs, most of the RSUs in the autonomous region should be the same ZXID; if the two numbers are different, abandoning the numbers, if the numbers are the same, continuously comparing the HOLDID numbers, which indicates that the RSU sends the competition information, the calculation power is free, if the HOLDID is larger than the RSU voted by the user, changing the voting result of the user into the current RSU, if the HOLDID is the same as the RSU voted by the user, continuously comparing the RSUID, and voting the RSU with the maximum RSUID; if an RSU does not vote for the RSU, the RSU enters a follower state from an elector 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 voting machine is obtained, and the voting result of the voting machine is sent to all other RSUs;
step four, the RSU receives the voting results of all other RSUs and then processes the voting results; if more than 50% of tickets are thrown to the same RSU, the RSU is directly used as a preparation leader, and other RSUs except the preparation leader enter a watcher state;
step five, the RSU serving as the preparation leader broadcasts a pre-submission command to carry out final leader confirmation, other RSUs receive and submit the command and then see whether the RSU is the RSU selected by the RSU, if so, an agreement command is sent, otherwise, the RSU is not processed;
and step six, the prepared leader RSU becomes a leader after receiving 50% of the responses of the pre-submitted commands, and the election is finished.
4. The distributed trust mechanism for internet of vehicles based on block chains as claimed in claim 3, wherein the RSU election process during operation is as follows:
step one, if the RSU in the observer state does not receive any message sent by the leader RSU within the specified time, the RSU is considered to be invalid, the RSU is changed into the election state from the observer state, the election process is started, the RSU sends the election information of the RSU per se, the election information is in a format of < RSUID, ZXID, HOLDID and LOOPID >, wherein the LOOPID is 1 greater than the number of election rounds where the current RSU is located, and meanwhile, election messages sent by other RSUs are also received;
step two, after receiving other election messages, the RSU compares the LOOPID to see whether to start the next round of election; starting a new round, generating and sending own election messages after the time of the own timer is over or the own timer receives error messages sent by the leader RSU, and comparing all the election messages including the own election messages; firstly, comparing whether ZXID is the latest, comparing the sizes of HOLDID, if the ZXID is the latest, comparing the last RSUID, and selecting the serial number with the highest number;
step three, all RSUs select the 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; if more than 50% of the RSUs vote, the RSU is taken as a preparation leader of the election, and other RSUs except the preparation leader RSU enter a watcher state;
step five, preparing a leader RSU to broadcast a pre-submission command to carry out final leader confirmation, and after receiving the pre-submission command, other RSUs see whether the RSU is the RSU selected by the RSU, if so, sending an agreement message, otherwise, not processing;
and step six, the prepared leader RSU becomes a leader after receiving 50% of the responses of the pre-submitted commands, and the election is finished.
5. The distributed trust mechanism for internet of vehicles based on block chains as claimed in claim 4, wherein the specific operation steps of the autonomous region temporary chain consensus mechanism are as follows:
the method comprises the following steps: after an RSU completes the calculation of an Event, the RSU becomes a presenter, the result and Event data are sent to a leader RSU in a message format of < RSUID, message _ type, timestamp, data, hash and Event _ influece > to obtain a publishing permission, wherein RSUID is the number of the RSU, message _ type indicates the type of the message, timestamp is a timestamp representing the first time application sharing is started, data part contains Event content, hash is the hash value of the latest internal block chain in the RSU of the current message to be published, and Event _ influece is the Event influence;
step two: the leader RSU carries out message verification after receiving the event sharing message; firstly, the signature of the RSU is verified, then the message type is verified, finally, whether the hash is the latest block hash is verified, and subsequent comparison can be carried out only if the verification is passed; when a leader RSU receives a plurality of event sharing requests at the same time, sharing of one event is received at one time, the influence of the events is compared after the request is verified to be legal, a numerical value with the largest influence is selected for allowing uplink, if the influence of a plurality of events is completely the same, the size of a timestamp is compared, the earlier the time is, the higher the selected probability is, and if the influence of the plurality of events is the same, the message provided by the RSU with the largest number is directly selected;
step three: after a leader RSU selects an event message, sending a sharing message permission to a corresponding RSU, wherein the message is mainly in a format of < message _ data, type, timestamp, leader _ sign, hash >, the message _ data is message data and contains all messages sent by the RSU to the leader RSU, the type is a message type, three conditions of permission, verification failure and waiting exist, the timestamp is a time stamp, the leader _ sign is a signature given by the leader RSU by integrating the content of the message _ data and the type, and the hash is a hash value of the content; the leader RSU receives the event sharing request before receiving the last confirmation message, gives permission if the event impact of the sharing request is greater than the event for which permission has been given, stores all event messages for which permission has been given, abandons the other messages and gives the other messages a waiting permission message upon receiving a commit request of one of them;
step four: after receiving the reply of the leader RSU, the presenter RSU firstly looks at what permission type is, if the permission type is the transmission-allowed type, the presenter RSU directly converts the message sent back by the leader RSU into a sharing announcement message and broadcasts the sharing announcement message to all RSUs; if the verification is not passed, the presenter RSU carries out event calculation again, converts the event calculation into a learner, interacts with the leader RSU and acquires the latest data, enters a receiver stage after the interaction is finished, and submits a request again; if the event is waiting, no message is sent, the message at the moment is stored, the next round of block consensus opening is waited, whether the event is continuously applied for submitting is determined, and the event is actively converted into a receiver state;
step five: at the moment, other non-submitted RSUs are in a receiver state, after relevant event sharing data are received, the allowed authenticity of the relevant event sharing data is verified, then the pre-hash of the data is seen, if the data are not added to the latest autonomous area block chain, the data are rejected, and then the data are compared with blocks which are already accepted by the self but are not confirmed to be submitted, at the moment, a submitter only accepts the blocks with larger event influence, and the initial value is 0 when the blocks are not accepted; if the current block is confirmed to be accepted, the submitter sends an acceptance message to the presenter RSU; and waits for a message sent by the submitter RSU;
step six: after receiving 50% of the receiving information, the submitter RSU broadcasts a pre-submission message to all RSUs, and after receiving the message, the receiver RSU sends a confirmation message to the submitter RSU if the RSU currently receives the event message shared by the submitter RSU, and the submitter RSU is converted into a learner and does not receive other shared event messages received after the submitter RSU; if the message accepted by the RSU is not the message submitted by the RSU, no response is made;
step seven: if the submitting RSU receives the response of the RSU with the quantity more than or equal to 50 percent again, sending a submitting message to the leader RSU to request block uplink; the message format is as follows: < RSUID, type, signlist >, where signlist is a list of signatures; if the response of 50% is not received, waiting, if the update message of the leader RSU is received subsequently, converting the update message into a block chain update for the learner, and storing the block content of the learner for later resubmission;
step eight: and the leader RSU carries out message verification after receiving the uplink request message of the RSU which self issues permission, the verification is carried out by putting the corresponding block into the block chain, and broadcasting the intra-cell block chain updating message to inform all the RSUs of updating the intra-cell block chain.
6. The distributed trust mechanism for vehicle networking based on block chains according to claim 5, wherein the distributed computing process is as follows:
the method comprises the following steps: firstly, determining an updating block by a leader RSU, and calculating the difficulty value required to be solved by the current block;
step two: if the leader RSU calculates that the difficulty value is the maximum value, that is to say
Figure RE-FDA0003363420610000081
If not, turning to the third step; dividing corresponding calculated amount according to the longest allowable time;
step three: computingThe range should be given according to the communication delay, the time when the communication is timed once, and the free power of the corresponding RSU; firstly, calculating the delay of each leader RSU and the delay of each RSU for replying messages, wherein each leader RSU is provided with a table for recording the delay after being selected, obtaining one-way delay by calculating the time of the messages and the receiving time of each leader RSU, considering that the RSU needs to receive the message of the leader RSU once to confirm that the leader RSU survives, and having three times of communication in a normal cycle, if gamma is one-way delay, 3 gamma time is needed, and if the condition that the RSU re-initiates leader election when the communication between the leader RSU and other RSUs is disconnected for more than s seconds at most is provided, the maximum value of the range of the given Hash attempt is Rangmax＝(s-3γ)×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: the RSU serving as the observer performs calculation after receiving the corresponding request, and if the calculation task is completed within the specified time but the correct value is not found, and other messages sent by the leader RSU are not received, the result is sent to the leader RSU to reply the request of the new calculation task; stopping the calculation and sending a calculation stopping message to the leader RSU if the block verification confirmation message sent by the leader RSU is received in the calculation; if the nonce value meeting the condition is obtained through calculation, stopping calculation and sending the block head and the nonce value to the leader RSU; if the calculation cannot be finished according to the normal condition, a request delay message is sent to the leader RSU, and the changed times of the hash calculation per second, the hash tasks which are already calculated and the range of the unfinished hash calculation tasks are contained in the request delay message;
step six: after the leader RSU sends the calculation request message of the RSU, the leader RSU receives the value of successful calculation and broadcasts the value to all the RSUs to stop calculation; if the calculation request task is received, the step three is carried out continuously; when the delay message is received, recovering the tasks which are not completed and transferring to the third step; if the RSU is not received in the specified time, the RSU is considered to be failed, and the previous task is recycled and the step three is carried out.
7. The distributed block chain-based vehicle networking trust mechanism of claim 6, wherein the follower state is to communicate with and synchronize the leader RSU state while participating in the vote; the leader state is that the leader is the leader of the leader; the voter state initiates the election to hope to become a leader and participates in voting at the same time; the observer state 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 true CN113946829A (en) 2022-01-18
CN113946829B 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)

Cited By (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", vol. 18, no. 4, 31 December 2020 (2020-12-31) *
张玲;陈思捷;严正;沈泽宇: "基于区块链共识机制的多区域最优潮流分布式算法", 中国电机工程学报, no. 020, 31 December 2020 (2020-12-31) *

Cited By (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

Also Published As

Publication number Publication date
CN113946829B (en) 2024-05-10

Similar Documents

Publication Publication Date Title
CN111601258B (en) Vehicle networking node data safety communication method based on block chain
Li et al. A reputation-based announcement scheme for VANETs
CN112039964B (en) Node reputation consensus method based on block chain
Guo et al. Proof-of-event recording system for autonomous vehicles: A blockchain-based solution
US20180372502A1 (en) Road traffic management
CN112541758A (en) Multi-round voting type fault-tolerant sequencing consensus mechanism and method based on block chain
Wang et al. Challenges and solutions in autonomous driving: A blockchain approach
CN109949034A (en) Block chain common recognition method based on Credibility Assessment
CN110445788B (en) Content-oriented trust evaluation system and method under vehicle-mounted ad hoc network environment
CN112929333B (en) Vehicle networking data safe storage and sharing method based on hybrid architecture
CN113268543A (en) Block chain-based security content sharing management method in Internet of vehicles
CN114745127A (en) Node credibility authentication method in Internet of vehicles environment based on block chain
CN113946829B (en) Block chain-based Internet of vehicles distributed trust system
CN113283778A (en) Layered convergence federated learning method based on security evaluation
CN111093189A (en) Emergency message dissemination method and system based on trust cascade in Internet of vehicles
CN116996521B (en) Relay committee cross-chain interaction system and method based on trust evaluation model
US20240103843A1 (en) Robust over the air reprogramming
CN113992526A (en) Credibility calculation-based alliance chain cross-chain data fusion method
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
CN112738090B (en) Data integrity detection method based on green calculation consensus mechanism block chain in edge calculation
CN115834512A (en) Data sharing method, system, electronic equipment and storage medium
CN116305239A (en) Privacy protection asynchronous federal learning method, system, equipment and storage medium
CN115189871A (en) Byzantine fault-tolerant consensus algorithm based on verifiable random function and threshold signature
CN111222057B (en) Information processing method, device and computer 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