Fast ledger consensus system and method for distributed wireless networks

Abstract

A computing device as a member of a distributed database system implemented using a wireless network. A member version of a chain graph is stored on the computing device. The chain graph includes events created by the computing device and events received from other computing devices that are members of the distributed database system via the wireless network. The computing device determines whether the computing device is a member of a voting committee, and the voting committee only includes a subset of computing devices that are members of the distributed database system. When the computing device is a member of the voting committee, the computing device uses the wireless network to participate in a distributed consensus algorithm with other members of the voting committee to define the order of events in the chain graph, and stores the order as a new event in the member version of the chain graph.

Description

Technical Field

[0001] The present disclosure relates to systems and methods for a distributed database in a vehicle-to-everything (V2X) network. Background Art

[0002] Vehicle-to-everything (V2X) communications enable vehicles to communicate with surrounding entities such as other vehicles, cellular towers, access points, road infrastructure elements, smart grid elements, and pedestrians. For example, V2X communications can include: device-to-device communications, such as vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-grid (V2G), and vehicle-to-pedestrian (V2P); and device-to-network (V2N) communications, such as cellular network-based C-V2X communications and wireless local area network (WLAN)-based communications. Different protocols have been or are being developed to support V2X communications, including, for example, the IEEE 802.11p protocol based on WLAN released in 2012, the 3rd Generation Partnership Project (3GPP) protocol, and the IEEE 802.11n protocol. rd The V2X protocol defined as long-term evolution (LTE) V2X in 3GPP (3rd Generation Partnership Project) Release 14 and 15, and the V2X protocol developed according to Release 15.

[0003] In some applications, the information provided and received by entities in the V2X network may affect the operation of traffic control systems and individual vehicle control systems, and entities such as insurance companies and governments may also trust this information. Given the potential security, financial, legal and regulatory implications of information exchanged in V2X networks, it is critical to maintain the integrity of the information. In this regard, V2X communications can be subject to traditional data integrity protection for a central database managed by a trusted central system or agency.

[0004] However, in some cases, the vehicle may be offline or have limited access to a trusted centralized authority. This may occur, for example, if the vehicle is out of range of a cellular network, the cellular network denies access to the vehicle due to network capacity issues or other reasons, there is a loss of communication between the cellular network and the centralized authority, or the centralized authority is temporarily down or currently unavailable for other reasons.

[0005] Therefore, there is a need for a method and system for implementing a distributed database of an entity such as a vehicle, wherein the distributed database does not rely on access to a trusted centralized authority. A known example of a distributed database system that does not rely on a trusted centralized authority is the peer-to-peer blockchain data structure used for cryptocurrencies such as Bitcoin. However, such systems are inefficient by design and are limited to processing only a small number of transactions per second.

[0006] Therefore, there is a need for a method and system for efficiently implementing a distributed database of entities such as vehicles. Summary of the invention

[0007] According to a first exemplary aspect of the present disclosure, a method is provided for execution at a computing device that is a member of a distributed database system implemented using a wireless network. The method includes storing a member version of a chain graph at the computing device. The chain graph includes events created by the computing device and events received from other computing devices that are members of the distributed database system via the wireless network. The method includes determining whether the computing device is a member of a voting committee, wherein the voting committee includes only a subset of computing devices that are members of the distributed database system. When the computing device is a member of the voting committee, the wireless network is used to participate in a distributed consensus algorithm with other members of the voting committee to define the order of events in the chain graph, and the order is stored as a new event in the member version of the chain graph.

[0008] In some exemplary embodiments, membership of the voting committee varies during a period of time during which the computing device is a member of the distributed database system, and determining whether the computing device is a member of the voting committee is performed multiple times during the period of time.

[0009] In some exemplary embodiments, the method includes exchanging events with other computing devices using a wireless network, wherein the computing device randomly sends created events to the other computing devices and receives events from the other computing devices according to a gossip protocol. In some exemplary embodiments, the distributed consensus algorithm includes a Byzantine protocol.

[0010] In some exemplary embodiments, determining whether the computing device is a member of the voting committee includes determining whether a member ID associated with the computing device matches a predetermined criterion, and if so, determining that the computing device is a member of the voting committee. In some examples, determining whether the member ID associated with the computing device matches a predetermined criterion includes determining whether a bit sequence within the member ID matches a predetermined bit sequence. In some examples, the member ID is updated at fixed time intervals by cyclically shifting bits of the member ID.

[0011] In other examples of the first exemplary aspect, the determining whether the computing device is a member of the voting committee includes: determining whether the computing device has received a voting committee token from a computing device that is an existing member of the voting committee. In some examples, the method includes designating a replacement computing device from the other computing devices to replace the computing device as a member of the voting committee. In some examples, the designating a replacement computing device includes: randomly selecting one of the other computing devices that are members of the distributed database system as the replacement computing device; sending the voting committee token to the replacement computing device; receiving a confirmation from the replacement computing device; and after authenticating the confirmation, notifying any other computing device that is a member of the voting committee that the replacement computing device is designated as a member of the voting committee.

[0012] According to a second exemplary aspect, a computing device for being a member of a distributed database system implemented using a wireless network is disclosed. The computing device can be used to perform the method of the first exemplary aspect. In some examples, the computing device includes: a processor system; a wireless transceiver connected to the processor system for exchanging signals with other computing devices using a wireless network; a non-transitory memory connected to the processor system. The non-transitory memory stores instructions for configuring the processor system to perform the following operations: storing a member version of a chain graph at the computing device, wherein the chain graph includes events created by the computing device and events received from other computing devices that are members of the distributed database system through the wireless network; determining whether the computing device is a member of a voting committee, wherein the voting committee only includes a subset of computing devices that are members of the distributed database system; when the computing device is a member of the voting committee, using the wireless network to participate in a distributed consensus algorithm with other members of the voting committee to define the order of events in the chain graph, and storing the order as a new event in the member version of the chain graph.

[0013] In at least some examples, the method of the first exemplary aspect and the computing device of the second aspect implement a V2X distributed database system that reaches consensus over a practical duration. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 A schematic diagram of a V2X distributed database system provided for an exemplary embodiment of the present disclosure.

[0015] Figure 2 The exemplary embodiments provided may be used to implement Figure 1 A block diagram of a computing device of a node member in a distributed database system.

[0016] Figure 3 A representation of a chain graph is provided for an exemplary embodiment.

[0017] Figure 4 An exemplary embodiment provides Figure 3 The events in the chain diagram.

[0018] Figure 5 A flow chart of one example of a randomized non-interactive selection process that may be used to select a voting committee.

[0019] Figure 6 A flow chart of an example of a randomized interactive selection process that may be used to select a voting committee.

[0020] Figure 7 for Figure 6 Another flow chart of the random interactive selection procedure.

[0021] Figure 8 A flow chart of one example of a method performed by a computing device is provided for an exemplary embodiment. DETAILED DESCRIPTION

[0022] For convenience, the present disclosure describes exemplary embodiments of methods and systems with respect to motor vehicles, such as automobiles, trucks, buses, boats or ships, submarines, airplanes, warehouse equipment, construction equipment, tractors or other farm equipment. The teachings of the present disclosure are not limited to any particular type of vehicle and may be applied to both non-passenger vehicles and passenger vehicles. The methods and systems described in the present disclosure may be implemented in non-autonomous vehicles, semi-autonomous vehicles, and autonomous vehicles, among others.

[0023] Exemplary embodiments relate to implementing a V2X distributed database using cascade messaging techniques. The distributed database may, among other things, enhance one or more of the following data communication related functions in some applications: authentication, auditability, anti-forgery, and integrity assurance. In some applications, the distributed database may help to one or more of the following: reduce the cost of V2X infrastructure, reduce the overhead required to provide redundancy, facilitate parallel processing, and provide offline database support.

[0024] Figure 1 A schematic diagram of an environment in which a distributed V2X distributed database can be implemented. Figure 1 Multiple entities are shown, including multiple vehicles 102(1)-102(m) (collectively referred to as vehicles 102, with individual vehicles generally referred to as vehicles 102(i)) and infrastructure elements 106 (e.g., fixed pole-mounted traffic cameras, traffic lights, programmable traffic signs, etc.). Each of the vehicles 102(1)-102(m) includes an onboard processor-enabled computing device 115(1)-115(m) (collectively referred to as computing device 115, with individual computing devices generally referred to as computing device 115(i)) capable of wireless communication. Similarly, at least some of the infrastructure elements 106 may include an onboard processor-enabled computing device 116 capable of wireless communication. In an exemplary embodiment, the computing devices 115 of the vehicles 102 and the computing devices 116 of the infrastructure elements 106 are respectively configured to communicate with a remote centralized agency 130 via a wireless wide area network (WAN) 136 (e.g., a cellular network). For example, computing devices 115 and 116 may be configured to communicate over WAN 136 using one or more cellular vehicle-to-network (C-V2N) protocols. In addition, computing devices 115 and 116 may also be capable of communicating peer to peer with each other using a wireless local area network. In this regard, computing devices 115 and 116 may be configured to enable a peer-to-peer sidelink (SL) V2X communication network 140 using one or more vehicle-to-everything (V2X) protocols. For example, communication network 140 may be a new air interface SL compatible network. Thus, in an exemplary embodiment, peer-to-peer SL V2X communication network 140 provides a medium or connection that enables computing devices 115 (1) to 115 (m) and computing device 116 to exchange wireless signals with each other.

[0025] In an exemplary embodiment, in addition to the processor-enabled computing device 115(i), as part of or in addition to the computing device 115(i), the exemplary vehicle 102(i) also includes a plurality of other onboard processor-enabled electronic devices 110(1)-110(k). Among other things, the electronic devices 110(1)-110(k) may include data capture devices or units capable of sensing, collecting, and processing information about the environment of the vehicle 102(i). For example, the onboard electronic devices 110(1)-110(k) associated with the vehicle 102(i) may include one or more devices that sense and process information about the physical environment surrounding the vehicle, such as a light detection and ranging (LIDAR) unit, a radio detection and ranging (RADAR) unit, and / or a camera unit. The electronic devices 110(1) to 110(k) may also include devices that collect and process information about the physical operating environment of the target vehicle 102(i), such as an inertial measurement unit (IMU), a speedometer unit, and other vehicle physical operating environment measurement units. For example, the information about the physical operating environment of the target vehicle 102(i) generated by the electronic devices 110(1) to 110(k) may include parameters representing one or more of the following: vehicle speed, engine RPM, angular acceleration, linear acceleration, throttle position, steering angle, brake position, vehicle posture, engine temperature, interior and exterior noise levels, number of people in the vehicle, and driver attention, among others. The electronic devices 110(1) to 110(k) may also include devices that collect and process information about the geographic location of the vehicle 102(i), such as a global positioning satellite unit. The computing device 116 of the infrastructure element 106 may also include or be connected to other processor-enabled electronic devices that sense and collect information about the physical environment surrounding the infrastructure element.

[0026] In an exemplary embodiment, when computing devices 115, 116 are online with respect to WAN 136, they can communicate with one or more remote central systems (including centralized institution 130) via WAN 136. In an exemplary embodiment, centralized institution 130 includes one or more computer systems, such as servers, for implementing trusted central ledger system 132. When computing devices 115, 116 are online, they can each communicate with central ledger system 132 via WAN 136 to implement data authentication, tracking, and auditing functions.

[0027] However, when one or more computing devices 115, 116 are offline relative to centralized authority 130 (e.g., when one or more vehicles 102 are located in an area not served by WAN 136, or computing devices 115, 116 are otherwise denied access to WAN 136 or centralized authority 130), computing devices 115 or 116 are unable to communicate with central ledger system 132 of centralized authority 130 via WAN 136. This situation may be problematic in situations where the functionality of trusted central ledger system 132 is required while computing devices 115 or 116 are offline. For example, in the event that vehicle 102(i) is involved in an accident while its corresponding computing device 115(i) is offline, an insurance provider may wish to be able to confirm the timing and authenticity of records generated by one or more of electronic devices 110(1)-110(k) regarding the physical environment surrounding vehicle 102(i) or the physical operating environment of the vehicle at the time of the accident.

[0028] Thus, in an exemplary embodiment, the computing devices 115(1) to 115(m) of the vehicle 102 are each configured to serve as a respective node or member that collectively implements a V2X distributed database system 150. In at least some examples, the computing device 116 of the infrastructure element 106 (labeled as representative member F in the figure) also serves as a member in the V2X distributed database system 150. In an exemplary embodiment, data exchange between the distributed database members implemented by the computing devices 115, 116 is performed using the peer-to-peer SL V2X communication network 140.

[0029] Figure 2 1 is a block diagram of an example of a computing device 115(i) that may be used to implement a vehicle-based distributed database module of a V2X distributed database system 150. As described above, the computing device 115(i) may be connected to or include a plurality of onboard electronic devices 110(1) to 110(k), which may include devices or units capable of sensing, collecting, and processing information about the surrounding physical environment and physical operating environment of the vehicle 102(i). In some examples, the computing device 115(i) may be connected to vehicle systems, such as a drive control system and an electromechanical system.

[0030] The computing device 115(i) includes a processor system 101 coupled to a plurality of components via a communication bus that provides a communication path between the components and the processor system 101. The processor system 101 is coupled to a memory 126 that may include random access memory (RAM), read-only memory (ROM), and persistent (non-volatile) memory, such as flash erasable programmable read only memory (EPROM) (flash memory). The computing device 115(i) includes one or more wireless transceivers 131 that enable the computing device 115(i) to exchange data with the WAN 136 and the peer-to-peer SL V2X communication network 140. The computing device 115 may also include a satellite receiver for receiving satellite signals from a positioning satellite network. The computing device 115(i) may also include one or more I / O interfaces 137, such as a touch screen and an audio input / output interface. The processor system 101 may include one or more processing units, such as one or more central processing units (CPUs), one or more graphic processing units (GPUs), and other processing units.

[0031] The memory 126 of the computing device 115 (i) stores thereon a set of software instructions executable by the processor system 101, which enables the computing device 115 (i) to implement a plurality of modules 161. The modules 161 include, among other things, a distributed database module 162, which configures the computing device 115 (i) to act as a member of the V2X distributed database system 150, as described in more detail below. The modules 161 may also include other modules 164, which may include, for example, a communication module, a mapping module, a navigation module, an automatic and assisted driving module, a climate control module, a media player module, a phone module, and a messaging module.

[0032] The memory 126 also stores various data for supporting the module 161 , including data representing the chain diagram 180 .

[0033] In an exemplary embodiment, the computing device 116 of the infrastructure element 106 may be implemented using an arrangement of electronic components similar to that of the computing device 115 ( i ).

[0034] In an exemplary embodiment, each distributed database module 162 serves as a member in the V2X distributed database system 150. Figure 1Throughout the remaining figures, letters A through E are used to label corresponding members implemented on vehicles 102 ( 1 ) through 102 ( m ), and letter F is used to label members implemented on infrastructure element 106 .

[0035] In an exemplary embodiment, members A to F are used to manipulate data, including storing, modifying and / or deleting data. In some embodiments, members A to F may implement a relational database, an object database, a post-relational database, and / or any other suitable type of database. For example, members A to E may store data related to the physical operating environment of the vehicle and the surrounding physical environment. In general, data may include any set of parameter values, and a parameter may be any data object and / or database field that can take different values.

[0036] In an exemplary embodiment, members A to F implemented on computing devices 115 (i) or 116 may exchange events with members A to F implemented by other computing devices 115 (i), 116, store events received by the members, and calculate the order of events based on a partial order defined by a reference pattern between the events. In this regard, in an exemplary embodiment, the set of events and their interconnections may form a chain graph 180 (see Figure 3 , showing members A to E). In an exemplary embodiment, at any given time, each of members A to F stores its own version of a chain graph 180 that represents that member's perception of events and interconnections of all members A to F that make up the V2X distributed database system 150.

[0037] In this regard, a corresponding version of the chain graph 180 is constructed at each member based on the communication between members through the V2X SL network 140. In an exemplary embodiment, the members are used to jointly implement a chat protocol to exchange chain graph information. As is known in the art, the chat protocol configures the members to randomly and repeatedly communicate with each other to synchronize the information stored in each member.

[0038] in this regard, Figure 3 is a graphical representation of an example of a chain graph 180 that grows over time. Each member A to F stores its own version of the chain graph 180. The chain graph 180 includes an event thread 304 for each member, each event thread 304 including multiple rounds (such as Figure 3 A set of events 302 occurs at a member (as shown by R1 to R4 in FIG. 1 ). An event 302 on an event thread 304 of a member can be connected to one or more events 302 on event threads 304 of one or more other members, as shown by inter-thread connections 306. For ease of illustration, Figure 3 Only the event thread 304 of members A to E is shown. Events are generally represented by reference numeral 302, and are particularly represented by Figure 3The notation (Xa,b) shown is represented, where X identifies the member that created the event 302, "a" identifies the round in which the event 302 was created, and "b" identifies the order in which the event 302 was created within the "a"th round. For example, B1,2 refers to the second event created by member B within round 1.

[0039] Each event 302 is a record or data structure, examples of which are shown in Figure 4 . In an exemplary embodiment, each event 302 includes a hash of two previous events (H1, H2), a timestamp (TS) asserting the time when the member created the event (e.g., date and UTC time), a concatenated message (data), and a digital signature (signature) applied by the member to the event. The data may include, among other things, information generated by one or more of the electronic devices 110(1) to 110(k) of the vehicle 102 implementing the member. For example, the data may include environmental data regarding the physical environment surrounding the vehicle and the physical operating environment of the vehicle.

[0040] In an exemplary embodiment, hashes (H1, H2) link each event 302 in the chain graph 180 to two earlier events. In some embodiments, hashes H1, H2 are based on cryptographic hashes so that the chain graph 180 is a hash graph. In an exemplary embodiment, hash H1 is a self-parent event hash, which means it is the hash of the previous event on the thread of the member that created the hash, and hash H2 is an other-parent event hash, which means it is the hash of the previous event on the thread of another member. For example, Figure 3 Event D1,2 in is a child of the parent event D1,1 and the other parent event C1,1. The hash H1 of event D1,2 is the hash of event D1,1, and the hash H2 of event D1,2 is the hash of event C1,1. Therefore, in an exemplary embodiment, the chain graph 180 directly encodes the partial order, which means that if event Y includes the hash of event X, or if Y includes the hash of an event that includes the hash of X, then it is known that event X occurs before event Y. However, if there is no path from X to Y or from Y to X, the partial order does not define which event occurs first. Therefore, members can calculate the total order based on the partial order. This can be done by any suitable deterministic function so that members all calculate the same order. In some embodiments, members can recalculate this order after each synchronization, and eventually these orders can converge so that consensus emerges. As will be explained in more detail below, in an exemplary embodiment, only a subset of members (e.g., members of the voting committee) are responsible for calculating the total order based on the partial order, and then propagating the total order through other members using the chat protocol.

[0041] In some instances, the first event 302 recorded by a member may include a hash of a single event defined by another distributed database module 162. In these instances, the member has not previously self-hashed (e.g., a hash of an event previously defined by the member, e.g., see Figure 3 In some instances, the first event in a distributed database does not include the hash of any previous event (because the distributed database has no previous events, e.g., see Figure 3 Event D1,1).

[0042] In an exemplary embodiment, the hash of an event (e.g., the hash of event D1,1 used as hash H1 in event D1,2) can be the value returned from a hash function that uses a predetermined selection of bytes of the event as input. In other embodiments, any other suitable data associated with an event (e.g., an identifier, a sequence number, bytes representing a specific portion of an event, etc.) can be used as input to a hash function to calculate the hash of the event. Any suitable hash function can be used to define a hash.

[0043] The distributed consensus algorithm may be used to determine the order of events 302 in the chain graph 180 and / or the order of data stored in the events 302. The order of events may in turn define the state of the database as a result of executing these events according to the order. The defined state of the database may be stored as a database state variable.

[0044] Although different consensus algorithms can be applied in various exemplary embodiments, in one exemplary embodiment, the Swirlds Hashgraph consensus algorithm is modified for use in the V2X distributed database system 150. An example of the Swirlds Hashgraph consensus algorithm is described in the following references: [1] "Leemon Baird. The Swirlds HashGraph Consensus Algorithm: Fair, Fast, Byzantine Fault Tolerance. SWIRLDS TECH REPORT SWIRLDS-TR-2016-01. May 31, 2016, Revision date: March 18, 2018", the contents of which are incorporated herein by reference. The Swirlds hashgraph consensus algorithm is a leaderless system where all members participate in voting. However, such a system can take a long time to converge, is resource-intensive and difficult to use efficiently and scalably in a V2X environment.

[0045] Therefore, in an exemplary embodiment, the consensus algorithm is modified so that voting is done by a subset or committee of members, rather than based on the votes of all members. For example, given a hash graph with a complete member set {A, B, C, D, E, F, G, H, I}, a voting committee is elected intermittently by randomly selecting a subset of the complete member set as the voting committee. For example, a new voting committee including a member subset V = {A, B, C, D, E} can be randomly selected as the voting committee VC to determine the order of events for a particular round (e.g., round R3) R2. Randomly selecting the voting committee VC in each round can mitigate fraud attacks while also providing a scalable technical solution that can be implemented in a dynamic V2X environment.

[0046] Non-interactive voting committee selection

[0047] In one exemplary embodiment, the committee members of the voting committee are selected at intermittent intervals using a random non-interactive selection procedure. In this regard, Figure 5An example of a random non-interactive selection procedure 500 that may be used to select a voting committee VC is shown. The procedure 500 is executed independently at each member. When a member joins the peer-to-peer SL V2X communication network 140, it becomes part of the V2X distributed database system 150 instance for recording events 302 that occur while the member is part of the peer-to-peer SL V2X communication network 140. After joining the V2X distributed database system 150, each member undergoes an initialization procedure in which the member is randomly assigned a member ID (block 502). Figure 5 In the illustrative example of , the random member ID is a binary digit ID of 10. In some examples, the random member ID can be assigned by an existing member of the voting committee VC, and in some examples, the random member ID can be self-assigned. In some examples, the random member ID can be based on a combination of committee assignment and self-assignment. In an exemplary embodiment, the random member ID can be assigned in a manner similar to the generation of a temporary mobile subscriber identity (TMSI) number in a mobile network. For example, a member can join the V2X distributed database system 150 using its own permanent member ID and then be assigned a random member ID, as will be described below, and the random member ID is updated intermittently, for example, at a fixed time interval T.

[0048] During operation of the V2X distributed database system 150, members are configured to self-assess whether they are on the voting committee based on their currently assigned member ID. For example, the member's member ID can be compared to a predetermined criteria (block 506) (e.g., do the 4 least significant bits (LSB) match a predetermined 4-bit value?). If the member's member ID matches the predetermined criteria, the member determines on its own that it is part of the voting committee VC (block 510), otherwise, the member determines on its own that it is not part of the voting committee VC (block 508). As shown in block 512, during the time interval that the member is a member of the voting committee VC, the member will participate in any consensus votes that occur during the time interval. In some exemplary embodiments, the member creates an event 302 to record that it has become a member of the voting committee.

[0049] As described above, the member ID is updated intermittently, for example, at a predefined time interval T (blocks 509, 514). In the example shown, the update is performed by cyclically shifting the member ID left by 1 bit. Then, taking into account the updated member ID, the actions indicated by blocks 506 and later are performed. In some exemplary embodiments, the member creates an event 302 to record that it is no longer a member of the voting committee.

[0050] Interactive voting committee selection

[0051] In an alternative exemplary embodiment, committee members of the voting committee are selected at intermittent intervals using a random interactive selection process in which members interact through the V2X SL network 140.

[0052] In this regard, Figure 6 and Figure 7 An example of a random interactive selection procedure that can be used to select a voting committee VC is shown. Figure 6 An initialization procedure 600 is shown that occurs for members when initializing an instance of the V2X distributed database system 150. Each member is assigned a corresponding member ID (block 602). In addition, voting committee tokens (e.g., 8-bit strings) are provided for a subset of members. For example, the first N nodes that become members may initially be assigned voting committee tokens.

[0053] In some examples, members initially assigned voting committee tokens may serve as initial voting committee VCs for a predefined fixed time interval T, after which each member designates a peer member as its voting committee member replacement, as shown in member designation procedure 603. In some examples, members initially assigned voting committee tokens may immediately designate other members as voting committee member replacements, as shown in member designation procedure 603.

[0054] As shown, during the member designation procedure 603, a member who is currently part of the voting committee VC (e.g., member B in the illustrative example) randomly selects at least one other member (e.g., member E in this example) as the intended designated member, where the at least one other member is part of the V2X distributed database system 150. The current voting committee member (member B) sends its member ID and voting committee token to the randomly selected designated member (member E) (block 604). The current voting committee member (member B) then receives a confirmation from the randomly selected designated member (member E) indicating acceptance or non-acceptance (block 606). If the confirmation indicates acceptance, it will include the member ID of the designated member (the member ID of the assigned member E). The current voting committee member (member B) then authenticates the designated member (member E) (block 607). In the example shown, the authentication is based on a combination of the voting committee, the member ID of the designated member, and the voting committee token. For example, if the following test equation is true, the current voting committee member (member B) can be configured to positively authenticate the designated member (member E):

[0055] Voting committee token = (current voting committee member ID) XOR (designated member ID) XOR (voting committee token).

[0056] If the designated member (member E) passes the authentication, the current voting committee member (member B) notifies the other existing current voting committee members that the member (member B) will be replaced by the designated member (member E) on the voting committee VC (block 608). In an example embodiment, the notification can be performed by a direct message sent to each other voting committee member. In addition, the outgoing voting committee member (member B) publishes an event 302 on its thread 304 indicating that the designated member (member E) has become part of the current voting committee VC. In some examples, the event 302 that the designated member (member E) has become part of the current voting committee VC can also be used to notify other voting committee members of the new designated member (member E) because the event will be propagated among the members through the chat protocol. In this case, the "notification" and "publish event" actions of blocks 608 and 610 can be combined.

[0057] like Figure 6 As shown, if the intended designated member (member E) does not accept the designation of the voting committee in block 606, or fails to be authenticated by the current voting committee member (member B) in block 607, the current voting committee member (member B) sends the voting committee token to a different random intended designated member among the members, and repeats the processes of blocks 604, 606, and 607 until the designated member accepts and passes the authentication.

[0058] Figure 7 The acceptance procedure 700 and the new voting committee member designation procedure 603 are shown from the perspective of the designated member (member E in this example). In particular, after receiving the voting committee token (block 702) from the current voting committee member (member B), the designated member (member E) sends a confirmation to the current voting committee member (member B) including the member ID of the designated member as part of the indication of acceptance of the voting committee VC designation (block 704). The designated member (member E) then becomes a current member of the voting committee VC and participates in the upcoming consensus vote (block 706). After participating as a current voting committee member for a predetermined duration T (block 708), the current voting committee member (member E) then undergoes the new voting committee member designation procedure 603 in the same manner as described above to replace itself in the voting committee VC.

[0059] Consensus Voting

[0060] Now refer to Figure 3 The exemplary chain diagram 180 describes an example of a committee-based consensus voting process performed by members of the voting committee VC.

[0061] like Figure 3As shown, each member (a subset of members A, B, C, D, and E is shown in Figure 3 ) creates and / or defines events 302. In an exemplary embodiment, the overall order of events 302 can be calculated by sorting the events 302 by their reception rounds (also referred to herein as order values), breaking ties by their reception timestamps, and breaking these ties by their signatures, as described below.

[0062] The following paragraphs specify functions for calculating and / or defining reception rounds and reception generations of events to determine the order of events.

[0063] "Parent": If event Y includes the hash of event X, then X is the parent of Y. For example, in Figure 3 , the parents of event D1,1 include event D1,1 and event C1,1.

[0064] "Ancestors": The ancestors of event X are X, its parent, its parent's parent, and so on. For example, in Figure 3 In , the ancestors of event E2,1 are events E1,1, D1,1, B1,2, and B1,1. An event's ancestors can be said to be linked to that event, and vice versa.

[0065] "Descendants": The descendants of event X are X, its children, its children's children, and so on.

[0066] “N”: The total number of members of the voting committee VC at the time of voting.

[0067] “M”: the smallest integer greater than a certain percentage of N (eg, greater than 2 / 3 of N). For example, if N=5, and the percentage is defined as 2 / 3, then M is equal to 4.

[0068] "Self-parent": The self-parent of event X is its parent event Y which is created and / or defined by the same member. For example, Figure 3 In the example, the parent of event D1,2 is D1,1.

[0069] "Self-ancestor": The self-ancestor of event X is X, its self-parent, its self-parent's self-parent, and so on.

[0070] "Sequence Number" (or "SN"): An integer attribute of an event, defined as the sequence number of the event's parent plus 1. For example, in Figure 3 , the parent of event D1,2 is D1,1. Since the sequence number of event D1,1 is 1, the sequence number of event D1,2 is 2 (i.e., 1 plus 1).

[0071] "Generation Number" (or "GN"): An integer attribute of an event, defined as the maximum of the generation numbers of the event's parents plus 1. For example, event E2,1 has two parents, events E1,1 and B1,2, with generation numbers 4 and 2, respectively. Therefore, the generation number of event E2,1 is 5 (i.e., 4 plus 1).

[0072] "Round Increment" (or "RI"): A property of an event, which can be either 0 or 1.

[0073] "Round Number" (or "RN"): An integer attribute of an event. In some instances, the round number may be defined as the maximum of the event's parent's round numbers plus the event's round increment. For example, in Figure 3 , event E2,1 has two parents, event B1,2 and E1,1, both of which have a round number of 1. Event E2,1 also has a round increment of 1. Therefore, the round number of event E2,1 is 2 (i.e., 1 plus 1). In other instances, an event can have a round number R if R is the smallest integer such that the event can strongly see (as described herein) at least M events defined and / or created by different members, each of which has a round number R–1. If there is no such integer, the round number of the event can be a default value (e.g., 0, 1, etc.). In such an instance, the round number of the event may not be calculated using a round increment. For example, in Figure 3 , if M is defined as the smallest integer greater than 1 / 2 times N, then M is 3. Then, event E2,1 strongly sees M events D1,1, C1,1, and E1,1, each of which is defined by a different member and has a round number of 1. Event E2,1 cannot strongly see at least M events with a round number of 2 defined by different members. Therefore, the round number of event E2,1 is 2. In some examples, the first event in the V2X distributed database system 150 includes a round number of 1. In other examples, the first event in the distributed database V2X distributed database system 150 may include a round number of 0 or any other suitable number.

[0074] "Fork": Event X is a fork of event Y if both event X and event Y are defined and / or created by the same member and neither is a self-ancestor of the other.

[0075] "Identification" of a fork: A fork can be "identified" by a third event that is created and / or defined after two events that forked from each other, if both events are ancestors of the third event. In some instances, the identification of a fork can indicate that a particular member is cheating.

[0076] "Identity" of events: If event X has no ancestor event Z that diverges from ancestor event Y, then X "identifies" or "sees" Y. For example, in Figure 3, event E2,1 identifies (also called "sees") event B1,1 because event B1,1 is an ancestor of event E2,1, and event E2,1 has no ancestor events that diverge from event B1,1. In some instances, event X can identify event Y if event X does not identify a fork before event Y. In such instances, event X can see event Y even if event X identifies a fork of a member that defines event Y after event Y. Event X does not identify events for the member after the fork. Furthermore, if a member defines two different events that are both the first events in the member's history, event X can identify the fork without identifying any events for the member.

[0077] "Strong identification" (also referred to herein as "strong seeing") of an event: If event X identifies ancestor event Y, then event X "strongly identifies" (or "strongly sees") ancestor event Y that was created and / or defined by the same member as X. Event X "strongly identifies" ancestor event Y that was not created and / or defined by the same member as X if there exists a set of events S that satisfies the following conditions: (1) includes X and Y; (2) is an ancestor of event X; (3) is a descendant of ancestor event Y; (4) is identified by X; (5) can identify Y; and (6) is created and / or defined by at least M different members. For example, in Figure 3 In , if M is defined as the smallest integer greater than 2 / 3 of N (i.e., M = 1 + floor(2N / 3), which is 4 in this example), then event E2,1 strongly identifies the ancestor event D1,1, because the event set D1,1, C1,1, B1,2, and E2,1 is a set of at least 4 events, which are ancestors of event E2,1 and descendants of event D1,1, and are created and / or defined by 4 members D, C, B, and E, respectively. Event E2,1 identifies events D1,1, C1,1, B1,2, and E2,1, respectively, and events D1,1, C1,1, B1,2, and E2,1 all identify event D1,1. Similarly, event X (e.g., event E2,1) can "strongly see" event Y (e.g., event D1,1) if X can see at least M events created or defined by different members that can all see Y (e.g., events D1,1, C1,1, B1,2, and E2,1).

[0078] "First in Round R" event (also referred to herein as "witness"): An event is a "first in Round R" event (or "witness") if (1) it has round number R, and (2) it has a parent with a round number less than R or no parent. For example, in Figure 3In , event E2,1 is a "first in round 2" event because it has round number 2 and its parent is event E1,1 with round number 1 (i.e., less than 2). In some examples, the round increment of event X is defined as 1 if and only if event X "strongly identifies" at least M "first in round R" events, where R is the largest round number of its parents. For example, in Figure 3 In , if M is defined as the smallest integer greater than 1 / 2 times N, then M is 3. Then, event E2,1 strongly identifies M events D1,1, C1,1, and E1,1, all of which are the first events of round 1. Both parents of E2,1 are round 1 events, and E2,1 strongly identifies at least M first events of round 1, so the round increment of E2,1 is 1. Events marked as "RI=0" in the figure cannot strongly identify at least M first events of round 1, so their round increments are 0.

[0079] "Famous" event: Round R event X is "famous" if (1) it is the "first" event (or "witness") in Round R, and (2) a "yes" decision is reached by performing Byzantine agreement among the voting committee members, as described below. In some embodiments, Byzantine agreement can be performed by the distributed database module 162 of the voting committee VC members. For example, in Figure 3 In FIG. 1 , five first events of round 1 are shown: D1,1, C1,1, B1,1, A1,1, and E1,1. If M is defined as the smallest integer greater than 1 / 2 times N, i.e., 3, then E2,1 is the first event of round 2. As the protocol runs longer, the chain graph 180 grows upward, as shown in FIG. Figure 3 As shown, the other 4 members also have round 2 first events. Each round 2 first event will "vote" on whether each round 1 first event is "famous". Event E2,1 will vote yes that D1,1, C1,1, and B1,1 are famous, because these events are round 1 first events that event E2,1 can identify. Event E2,1 will vote no that A1,1 is famous, because E2,1 cannot identify A1,1. For a given round 1 first event, such as C1,1, its "famous" or not status is determined by first calculating the votes of each round 2 first event to determine whether it is famous. These votes will then be propagated to the round 3 first event, and then to the round 4 first event, and so on, until a consensus is finally reached on whether C1,1 is famous. The same process is repeated for the other first events.

[0080] Byzantine agreement can collect and use votes and / or decisions of the "first event in round R" to identify "famous events". For example, if the "first event in round R+1" Y can "identify" event X, then Y votes in favor, otherwise it votes against. Then, votes are calculated for each round G, G=R+2, R+3, R+4, etc., until all members make a decision. Before making a decision, votes are calculated for each round G. Some of the rounds can be "majority" rounds, while other rounds can be "coin" rounds. In some instances, for example, round R+2 is a majority round, and subsequent rounds are designated as majority rounds or coin heads and tails decision rounds (e.g., according to a predefined schedule). For example, in some instances, whether a subsequent round is a majority round or a coin heads and tails decision round can be arbitrarily determined, but the condition is that there cannot be two consecutive coin heads and tails decision rounds. For example, it may be predefined that there will be 5 majority vote rounds, followed by 1 coin-heads-tails round, followed by 5 majority vote rounds, followed by 1 coin-heads-tails round, and repeated as long as agreement is reached.

[0081] In some instances, if round G is a majority round, the vote can be calculated as follows. If there is a round G event that strongly identifies at least M votes V (where V is "yes" or "no") for the first event of round G–1, then the consensus decision is V and Byzantine agreement ends. Otherwise, a new vote is calculated for each round G first event, which is a majority vote of the first events of round G–1 that every round G first event can strongly identify. In instances of a tie rather than a majority, the vote can be designated as "yes".

[0082] Similarly, if X is a witness in round R (or the first event in round R), the votes for rounds R+1, R+2, and so on can be calculated, where in each round witnesses vote to decide whether X is famous. In round R+1, every witness that can see X votes in favor, and the other witnesses vote against it. In round R+2, each witness votes according to the majority votes of the witnesses in round R+1 that it can strongly see. Similarly, in round R+3, each witness votes according to the majority votes of the witnesses in round R+2 that it can strongly see. This can continue for multiple rounds. In the case of a tie, the vote can be set to "yes". In other instances, the tie can be set to "no", or it can be set randomly. If at least M witnesses vote against in any round, the election ends and X is not famous. If at least M witnesses vote in favor in any round, the election ends and X is famous. If neither "yes" nor "no" has at least M votes, the election will continue to the next round.

[0083] For example, in Figure 3In , consider the first event X of a round that occurs in the timeline before the event shown in the figure. Then, each first event of round 1 will vote on whether X is famous. Event E2,1 can strongly identify the first events of round 1, D1,1, C1,1, and E1,1. Therefore, the vote of event E2,1 is based on the votes of events D1,1, C1,1, and E1,1. If this is a majority round, then E2,1 will check whether there are at least M votes in favor of {D1,1, C1,1, E1,1}. If there are indeed at least M votes in favor of it, then the decision is "yes" and an agreement has been reached. If there are at least M of them voting against it, then the decision is "no" and an agreement has been reached. If there are not at least M votes in either direction, then the vote of E2,1 is a majority of those of D1,1, C1,1, and E1,1 (in case of a tie, the tie will be broken by voting in favor). This vote will then be used in the next round, and the process continues until an agreement is reached.

[0084] In some examples, if round G is a heads-and-tails round, the vote can be calculated as follows. If event X can identify at least M votes V (where V is "yes" or "no") for the first event in round G–1, then event X changes its vote to V. Otherwise, if round G is a heads-and-tails round, then every first event X in round G changes its vote to a pseudo-randomly determined result (similar to a coin toss in some examples), which is defined as the least significant bit of event X's signature.

[0085] Likewise, in this instance, if the election reaches round R+K (a coin-snaps round), where K is a specified coefficient (e.g., a multiple of 3, 6, 7, 8, 16, 32, or any other suitable number), the election does not end in that round. If the election reaches this round, it may continue for at least one more round. In such rounds, if event Y is a witness in round R+K, then if it can strongly see that at least M witnesses in round R+K–1 are voting for V, then Y will vote for V. Otherwise, Y will vote according to a random value (e.g., according to bits of the signature of event Y (e.g., least significant bit, most significant bit, randomly selected bit), where 1 = "yes", 0 = "no", or vice versa, according to the timestamp of event Y, using a cryptographic "shared coin" protocol and / or any other random determination). Such random determination is unpredictable before the creation of Y, and therefore can improve the security of the event and the consensus protocol. For example, in Figure 3In , if round 2 is a heads-and-tails round, and the vote is about whether an event before round 1 is famous, event E2,1 will first check whether at least M of {D1,1, C1,1, E1,1} voted for or against. If so, then E2,1 will vote in the same way. If there are not at least M votes in either direction, then E2,1 will have a random or pseudo-random vote (e.g., based on the least significant bits of a digital signature created by E for event E2,1 when creating and / or defining event E2,1). In some instances, the pseudo-random determination result can be the result of a cryptographic shared coin protocol, which can be implemented, for example, as the least significant bits of a threshold signature of the round number.

[0086] The member's distributed database module 162 can be configured to implement the V2X distributed database system 150 using any of the methods for calculating the pseudo-random determination results described above. In some instances, the distributed database module 162 cycles through different methods in a certain order. In other instances, the distributed database module 162 can select among different methods according to a predefined pattern.

[0087] "Receiving Round": If R is the smallest integer such that at least half of the famous first events of round R (or famous witnesses) with round number R are descendants of event X and / or can see event X, then the event X has a "receiving round" R. In other examples, any other suitable percentages can be used. For example, in another example, if R is the smallest integer such that at least a predetermined percentage (e.g., 40%, 60%, 80%, etc.) of the famous first events of round R (or famous witnesses) with round number R are descendants of event X and / or can see event X, then the event X has a "receiving round" R.

[0088] In some instances, the "receiving generation" of event X can be calculated as follows: find which member created and / or defined the first event of each Rth round that can identify event X; then determine the generation number of the earliest event of that member that can identify X; then define the "receiving generation" of X as the median of this list.

[0089] In some instances, the "receive timestamp" T of event X can be the median of the timestamps in the event that includes the identification of each member and / or the first event that saw X. For example, the receive timestamp of event D1,1 can be the median of the values ​​of the timestamps of events C1,1, B1,1, A1,1, and E1,1. In some instances, the timestamp of event D1,1 can be included in the median calculation. In other instances, the receive timestamp of X can be any other value or combination of values ​​that is the timestamp in the event that identifies or sees the first event of X for each member. For example, the receive timestamp of X can be based on the mean of the timestamps, the standard deviation of the timestamps, a modified mean (e.g., by removing the earliest and latest timestamps from the calculation), and so on. In other instances, an extended median can be used.

[0090] In some instances, the total order and / or consensus order of events can be calculated by sorting the events by their reception round (also referred to herein as order value), breaking ties by their reception timestamps, and breaking these ties by their signatures. In other instances, the total order of events can be calculated by sorting the events by their reception round, breaking ties by their reception generation, and breaking these ties by their signatures.

[0091] In some instances, the state of the V2X distributed database system 150 may be defined after consensus is reached. For example, if S(R) is the set of events visible to the famous witnesses in round R of the voting committee VC, then eventually all events in S(R) will have known reception rounds and reception timestamps. At this point, the consensus order of events in S(R) is known and will not change. Once this point is reached, members may compute and / or define representations of events and their order. For example, members may compute hash values ​​of events in S(R) in the consensus order of events in S(R). The member may then digitally sign the hash value and include the hash value in the next event defined by the member. This may be used to notify other members that the member has determined that the events in S(R) have a given order that will not change. After at least M members (or any other appropriate number or percentage of members) of the voting committee VC sign the hash value of S(R) (and thereby agree to the order represented by the hash value), the consensus list of events and the members' signature list can form a single file (or other data structure) that can be used to prove that the consensus order is required by the events in S(R). In other examples, if the events include transactions that update the state of a distributed database system (as described herein), the hash value can be the state of the distributed database system after the transactions of the events in S(R) are applied in the consensus order.

[0092] In an exemplary embodiment, the event synchronization signal flow in the SL WLAN network 140 between two members of the V2X distributed database system 150 may be as follows. Specifically, in some embodiments, the distributed database members (e.g., members A and B) may exchange events to obtain convergence. Member A may randomly select to synchronize with member B. In some embodiments, since member B may be selected by member A from a set of computing devices belonging to the distributed database system 150, member A may select member B multiple times in a row, or may not select member B for a considerable period of time.

[0093] As mentioned above, Figure 3 An example of a chain graph 180 is shown for a voting committee VC with 5 members A to E. Except for the first event of each member, each event in this example has two downward lines (a dark line pointing to the same member and a light line pointing to another member). Time progresses upward.

[0094] In the example of members A and B, the synchronization between them can be described as follows: member A sends an event stored in member A's version 180 of the hashmap to member B; member B creates a new event, where the new event contains: the hash H1 of the last event created by member B and the hash H2 of the last event created by member A, and the digital signature of member B; member B sends an event stored in member B's version 180 of the hashmap to member A; member B creates a new event, where the new event contains: the hash H1 of the last event created by member A and the hash H2 of the last event created by member B, and the digital signature of member A. Member A sends the event to member B; member A calculates the total order of events as a function of member A's version 180 of the hashmap; member B calculates the total order of events as a function of member B's version 180 of the hashmap.

[0095] exist Figure 3In the example of , event B4,2 is created and / or defined by member B as a result of synchronization with member C and after. Event B4,2 includes a hash H1 of event B4,1 (previous event created by member B) and a hash H2 of event C4,1 (previous event created by member C). For example, in some embodiments, the hash of event B4,1 included in event B4,2 includes a pointer to its direct ancestor events (events A3,2 and B3,2). Therefore, member node B can use event B4,2 to reference events A3,2 and B3,2, and rebuild the hash map using pointers to previous events. In some instances, event B4,2 can be said to be linked to other events in chain graph 180, because event B4,2 can reference each event in chain graph 180 through an earlier ancestor event. For example, event B4,2 is linked to event A3,2 through event B4,1. As another example, event B4,2 is linked to event E3,1 through event C4,1 and event D3,2.

[0096] As described above, in an exemplary embodiment, each event 302 includes data (Data), which may include environmental data about the physical environment around the vehicle and the physical operating environment of the vehicle. This data can be used to update the hash map event using environmental activity information that has occurred since the member's previous event. For example, event B4,2 may include environmental data recorded by member B since event B4,1 was created. Therefore, when synchronizing event B4,2 with other members, member B can share this information. Therefore, the environmental data recorded by member B can be associated with the event and shared with other members.

[0097] In exemplary embodiments, synchronization between members is limited to unknown events. For example, member A does not send member B an event created by member B, nor does it send ancestor events of said event. Likewise, in these embodiments, member B sends member A an event that member A has not yet stored, and does not send an event that member A has already stored.

[0098] In an exemplary embodiment, once an event has been ordered and certified by members of the voting committee, that information is represented in a new event and then propagated to the rest of the members of the V2X distributed database system 150 using random synchronization exchanges.

[0099] Overview of the Random Voting Committee Consensus Process

[0100] As a summary, Figure 8A method is shown that may be performed by a computing device 115(i) that is a member of a V2X distributed database system 150 within a SL V2X communication network 140. As shown in block 802, the computing device 115(i) stores a member version of a chain graph 180. The chain graph 180 includes events 302 created by the computing device 115(i) and events 302 received over a wireless network from other computing devices 115 that are members of the V2X distributed database system 150. As shown in block 804, the computing device 115(i) determines whether it is a member of a voting committee VC that includes only a subset of computing devices 115 that are members of the V2X distributed database system 150. As shown in block 806, if the computing device 115 (i) is a member of the voting committee, the computing device 115 (i) uses the SL V2X communication network 140 to participate in the distributed consensus algorithm with other members of the voting committee VC to define the order of events 302 in the chain graph 180 and store the order as new events 302 in the member version of the chain graph 180.

[0101] In an exemplary embodiment, membership of the voting committee VC varies during a period of time that the computing device 115(i) is a member of the V2X distributed database system 150, and determining whether the computing device 115(i) is a member of the voting committee is performed multiple times during the period of time.

[0102] In an exemplary embodiment, a computing device randomly sends events that it has created to other computing devices and receives events from other computing devices according to a gossip protocol. In an exemplary embodiment, the distributed consensus algorithm includes a Byzantine protocol.

[0103] In an exemplary embodiment, computing device 115(i) performs the following operations: Figure 5 The random non-interactive selection procedure 500 shown is assigned to a voting committee VC. In this regard, the computing device 115(i) is used to determine whether the computing device 115(i) is a member of the voting committee VC by determining whether the member ID associated with the computing device 115(i) matches a predetermined criterion, and if so, determining that the computing device 115(i) is a member of the voting committee. In some examples, determining whether the member ID associated with the computing device matches the predetermined criterion includes determining whether a bit sequence within the member ID matches a predetermined bit sequence (e.g., a 4LSB match). In some examples, the computing device 115(i) updates its member ID by cyclically shifting bits of the member ID at fixed time intervals.

[0104] In an exemplary embodiment, computing device 115(i) performs the following operations: Figure 6 and Figure 7The random interactive selection procedure shown is assigned to a voting committee VC. In this regard, computing device 115(i) is used to determine whether computing device 115(i) is a member of the voting committee based on whether computing device 115(i) has received a voting committee token from another computing device 115 that is an existing member of the voting committee VC. In addition, after computing device 115(i) has been a member of the voting committee VC (e.g., after a predefined time interval), computing device 115(i) is used to designate a replacement computing device 115(j) from the other computing devices 115 to replace computing device 115(i) as a member of the voting committee VC. In an exemplary embodiment, designating a replacement computing device 115(j) includes: randomly selecting one of the other computing devices 115 that are members of the V2X distributed database system 150 as the replacement computing device 115(j); sending a voting committee token to the replacement computing device 115(j); receiving confirmation from the replacement computing device 115(j); and after authentication confirmation, notifying any other computing device 115 that is a member of the voting committee VC that the replacement computing device 115(j) is designated as a member of the voting committee VC.

[0105] Overview

[0106] The present disclosure is made with reference to the accompanying drawings, in which embodiments are shown. However, many different embodiments may be used, and therefore description should not be construed as being limited to the embodiments set forth herein. On the contrary, these embodiments are provided to make the present disclosure thorough and complete. The separate frame or the separation shown of the functional elements of the illustrated system, module, and device do not necessarily require these functional physical separations, because the communication between these elements can occur by means of message passing, function call, shared memory space, etc. without any such physical separation. Therefore, although these functions are described separately herein for ease of explanation, these functions do not need to be implemented in a physically or logically separated platform. Different devices may have different designs, so that although some devices implement some functions in fixed-function hardware, other devices may implement these functions in a programmable processor, which has a code obtained from a machine-readable medium.

[0107] All values ​​and subranges within the disclosed range are also disclosed. In addition, although the disclosed and illustrated systems, devices and processes herein may include a specific number of elements / components, these systems, devices and components may be modified to include more or less such elements / components. For example, although any disclosed element / component may be a single quantity, the embodiments disclosed herein may be modified to include a plurality of such elements / components. The subject matter described herein is intended to cover and encompass all appropriate technical changes.

[0108] Although the present disclosure is at least partially described in terms of methods, it will be understood by those skilled in the art that the present disclosure also relates to various components for performing at least some aspects and features of the described methods, whether by hardware (digital signal processor (DSP), GPU, application specific integrated circuit (ASIC) or field programmable gate array (FPGA), software or a combination thereof. Therefore, the technical solution of the present disclosure may be embodied in a non-volatile or non-transitory machine-readable medium (e.g., a CD, flash memory, etc.) having executable instructions tangibly stored therein, which enable a processing device (e.g., a vehicle control system) to perform an example of the method disclosed herein.

[0109] The present disclosure may be embodied in other specific forms without departing from the subject matter of the claims. The described example embodiments are merely illustrative and not restrictive in all respects. The present disclosure is intended to encompass and cover all appropriate technical changes. Therefore, the scope of the present disclosure is described by the appended claims rather than by the above description. The scope of the claims should not be limited by the embodiments set forth in the examples, but should be given the broadest interpretation consistent with the entire specification.

Claims

1. A method performed at a computing device, characterized in that The computing device is a member of a distributed database system implemented using a wireless network, and the method includes: storing a member version of a chain graph at the computing device, wherein the chain graph includes events created by the computing device and events received from other computing devices that are members of the distributed database system over the wireless network; determining whether the computing device is a member of a voting committee, wherein the voting committee includes only a subset of computing devices that are members of the distributed database system; When the computing device is a member of a voting committee, using the wireless network to participate in a distributed consensus algorithm with other members of the voting committee to define an order of events in the chain graph, and storing the order as a new event in the member version of the chain graph; Wherein, determining whether the computing device is a member of a voting committee comprises: Determine whether a bit sequence within a member ID associated with the computing device matches a predetermined bit sequence, and if so, determine that the computing device is a member of the voting committee; or determine whether the computing device has received a voting committee token from a computing device that is an existing member of the voting committee.

2. The method according to claim 1, characterized in that The membership of the voting committee varies during a time period during which the computing device is a member of the distributed database system, and the determining whether the computing device is a member of the voting committee is performed multiple times during the time period.

3. The method according to claim 1 or 2, characterized in that: include: Use the chat protocol to exchange events with other computing devices.

4. The method according to claim 1 or 2, characterized in that: The distributed consensus algorithm includes the Byzantine protocol.

5. The method according to claim 1, characterized in that include: The member ID is updated at fixed time intervals by cyclically shifting the bits of the member ID.

6. The method according to claim 1, characterized in that include: A replacement computing device is designated from among the other computing devices to replace the computing device as a member of the voting committee.

7. The method according to claim 6, characterized in that The designated replacement computing device includes: randomly selecting one of the other computing devices that are members of the distributed database system as the replacement computing device; sending the voting committee token to the replacement computing device; receiving a confirmation from the replacement computing device; After authenticating the confirmation, any other computing devices that are members of the voting committee are notified of the replacement computing device's designation as a member of the voting committee.

8. A computing device, characterized in that For being a member of a distributed database system implemented using a wireless network, the computing device comprises: Processor system; a wireless transceiver, connected to the processor system, for exchanging signals with other computing devices using a wireless network; A non-transitory memory, coupled to the processor system, storing instructions for configuring the processor system to: storing a member version of a chain graph at the computing device, wherein the chain graph includes events created by the computing device and events received from other computing devices that are members of the distributed database system over the wireless network; Determining whether the computing device is a member of a voting committee, wherein the voting committee includes only a subset of computing devices that are members of the distributed database system; when the computing device is a member of the voting committee, using the wireless network to participate in a distributed consensus algorithm with other members of the voting committee to define an order of events in the chain graph, and storing the order as a new event in the member version of the chain graph; The instructions configure the processor system to determine that the computing device is a member of the voting committee when a bit sequence within a member ID associated with the computing device matches a predetermined bit sequence; or to determine that the computing device is a member of the voting committee when the computing device has received a voting committee token from a computing device that is an existing member of the voting committee.

9. The computing device according to claim 8, characterized in that The membership of the voting committee varies during a period of time during which the computing device is a member of the distributed database system, and the instructions configure the processor system to determine whether the computing device is a member of the voting committee a plurality of times during the period of time.

10. The computing device according to claim 8 or 9, characterized in that The instructions configure the processor system to cause the computing device to randomly send events it creates to the other computing devices using a chat protocol.

11. The computing device according to claim 8 or 9, characterized in that The distributed consensus algorithm includes the Byzantine protocol.

12. The computing device according to claim 8, characterized in that The instructions configure the processor system to update the member ID at fixed time intervals by cyclically shifting bits of the member ID.

13. The computing device according to claim 8, characterized in that The instructions configure the processor system to designate a replacement computing device from among the other computing devices to replace the computing device as a member of the voting committee.

14. The computing device according to claim 13, characterized in that The instructions configure the processor system to designate the replacement computing device by: randomly selecting one of the other computing devices that are members of the distributed database system as the replacement computing device; transmitting the voting committee token to the replacement computing device using the wireless transceiver; receiving an acknowledgement from the replacement computing device using the wireless transceiver; After authenticating the confirmation, any other computing devices that are members of the voting committee are notified of the replacement computing device's designation as a member of the voting committee.

Images