WO2023282884A1

WO2023282884A1 - 3d blockchain architecture for data management

Info

Publication number: WO2023282884A1
Application number: PCT/US2021/040458
Authority: WO
Inventors: Xiaoliang Zhu; Subrata Kumar KUNDU
Original assignee: Hitachi America Ltd
Current assignee: Hitachi America Ltd
Priority date: 2021-07-06
Filing date: 2021-07-06
Publication date: 2023-01-12
Anticipated expiration: 2024-01-06

Abstract

In some examples, a system may include a first computing device able to communicate with one or more second computing devices. The first computing device may receive data from a data source of a plurality of data sources. The first computing device may determine, based at least on information about the data source, a layer, row, and column in a three-dimensional (3D) blockchain data structure, which includes a plurality of layers, each layer including a plurality of rows of data blocks. The first computing device may generate a data block to add to the 3D blockchain data structure based on the determined layer, row, and column, the generated data block including the received data. Further, the first computing device may send the generated data block to one or more second computing devices for confirmation for adding to the 3D blockchain data structure.

Description

3D BLOCKCHAIN ARCHITECTURE FOR DATA MANAGEMENT

TECHNICAL FIELD

[0001] This disclosure relates to the technical field of blockchain data storage and data retrieval.

BACKGROUND

[0002] A blockchain is a type of distributed data structure that maintains a continuously growing series (i.e., a chain) of records called blocks. Each block contains a timestamp and a link to a previous block. The blocks may store any of various types of information. The verification process for a block may be performed fairly simply, which reduces the likelihood of fraudulent data. By storing data distributed in multiple locations across a network, a blockchain reduces or eliminates the risks that come with data being held centrally. Blockchain technology has been proven to be inherently secure by design, such as based on strong cryptography, digital signatures (asymmetric encryption/decryption), and a distributed consensus mechanism that validates and chains blocks of data together, making it extremely difficult to tamper with any individual data without being detected. Thus blockchains can provide decentralization, persistence, anonymity, and auditability.

[0003] Despite these advantages, conventional blockchain technology is not considered suitable for storing large quantities of data that may be received from multiple sources and/or over short periods of time. For example, the block size may be limited so that each block of the blockchain may store only a specified amount of data up to some maximum limit. As one example, in the case of a large number of connected vehicles that each send data to a blockchain database via a network, a traditional blockchain typically would not be able to handle the large amount of data that might be received from the connected vehicles. Furthermore, in some cases, the connected vehicles or other parties may desire to query certain data from the blockchain database. However, a conventional blockchain architecture may have difficulty responding to these data requests, such as due to an inefficient data extraction mechanism or the like.

SUMMARY

[0004] In some implementations, a system may include a first computing device able to communicate with one or more second computing devices. The first computing device may receive data from a data source of a plurality of data sources. The first computing device may determine, based at least on information about the data source, a layer, row, and column in a three- dimensional (3D) blockchain data structure, which includes a plurality of layers, each layer including a plurality of rows of data blocks. The first computing device may generate a data block to add to the 3D blockchain data structure based on the determined layer, row, and column, the generated data block including the received data. Further, the first computing device may send the generated data block to one or more second computing devices for confirmation for adding to the 3D blockchain data structure.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The detailed description is set forth with reference to the accompanying figures. In the figures, the leftmost digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items or features.

[0006] FIG. 1 illustrates an example 3D blockchain data structure according to some implementations .

[0007] FIG. 2 illustrates an example 3D blockchain data structure including an enlarged view of an example layer according to some implementations.

[0008] FIG. 3 illustrates an example architecture of a system in which the 3D blockchain data structure may be employed according to some implementations.

[0009] FIG. 4 illustrates an example process for generating data on a vehicle according to some implementations.

[0010] FIG. 5 illustrates an example process for adding data blocks and attribute blocks to a 3D blockchain data structure according to some implementations.

[0011] FIG. 6 illustrates an example of determining the hashes to use in the header for a new block according to some implementations.

[0012] FIG. 7 illustrates an example process for calculating the Merkle root for the block header for a new block according to some implementations.

[0013] FIG. 8 illustrates an example attribute block according to some implementations.

[0014] FIG. 9 is a flow diagram illustrating an example process for gaining consensus for a new block according to some implementations.

[0015] FIG. 10 is a flow diagram illustrating an example process for extracting data from the 3D blockchain according to some implementations. [0016] FIG. 11 illustrates select components of one or more example entity computing devices that may be used to implement some functionality of the services described herein, such as performing data management and blockchain operations as discussed in the examples herein.

DESCRIPTION OF THE EMBODIMENTS

[0017] Some implementations herein include techniques and arrangements for a three- dimensional (3D) blockchain data structure that enables storage of large amounts of data received from one or more data sources. In some cases, the 3D blockchain data structure may include attribute blocks that enable retrieval of desired data from individual blocks without having to traverse an entire blockchain to locate the desired data. For instance, the attribute blocks may enable fast information extraction from one or more specific blocks in the blockchain without having to search through a large number of the data blocks in the blockchain. The 3D blockchain data structure enables processing and storage of data received from a plurality of data sources within a shorter processing time than would be possible with a conventional blockchain and without compromising data integrity and security. Accordingly, the 3D blockchain data structure herein overcomes the problems with conventional blockchains discussed above and provides a technical improvement in computer technology that reduces data storage time for storage of large amounts of data to a blockchain, while also improving the ability to retrieve desired data from the blockchain without having to traverse the blockchain to locate the desired data.

[0018] In some examples, the architecture, operation, and effectiveness of the 3D blockchain data structure is explained with respect to an example use case of connected vehicles. Connected vehicles may include vehicles able to communicate over a wireless network with network computing devices, such as cloud servers, private servers, etc., and/or communicate directly with other vehicles or other types of computing devices. Connected vehicles typically include a plurality of sensors and electronic control units (ECUs) onboard the connected vehicles. A portion of the sensor data as well as other information about the vehicle may be sent over the network(s) to other devices, such as to a service computing device that maintains the 3D blockchain data structure discussed herein.

[0019] Furthermore, the requirements for secure, seamless, and robust information exchange among individuals, vehicles, and operational centers are evolving. For example, the increasing prevalence of connected vehicles enables collection of enormous amounts of data from vehicles for various applications. Ensuring security of data provided by and provided to connected vehicles can prevent malicious actors from creating chaos on the roads and/or from putting vehicles and their occupants in danger. Accordingly, the 3D blockchain data structure herein may be used in the area of connected vehicles to provide significant improvements in data security, data traceability, and efficient data exchange.

[0020] For discussion purposes, some example implementations are described in the environment of storing and retrieving data related to connected vehicles, such as autonomous vehicles, semi- autonomous vehicles, or other vehicles able to communicate vehicle information over a network. However, implementations herein are not limited to the particular examples provided, and may be extended to other types of vehicles, other types of use cases, other types of industries, other types of computing platforms and architectures, and so forth, as will be apparent to those of skill in the art in light of the disclosure herein. For example, the 3D blockchain data structure may be applied in the areas of digital manufacturing, supply chain monitoring, component tracking and monitoring, finance (e.g., digital payments), smart city management, electric vehicle grid integration, and so forth. Thus, implementations herein are not limited to the discussed examples.

[0021] FIG. 1 illustrates an example 3D blockchain data structure 100 according to some implementations. The 3D blockchain data structure includes a plurality of layers 102 such as a first layer 102(1), a second layer 102(2), a third layer 102(3), and so forth. Each layer 102 may include one or more data blockchains 104 and one or more attribute blockchains 106. As discussed additionally below, the attribute blockchains 106 may be employed to locate desired data in one or more of the data blockchains 104. The 3D blockchain data structure 100 further includes a layers axis 108 that indicates a direction of growth for the addition of more layers 102 to the 3D blockchain data structure 100. In addition, each layer 102 may include a time axis 110 that indicates a direction of growth of the respective data blockchains 104 and the attribute blockchains 106 over time. As discussed additionally below, in some cases, the generation of new blocks for the data blockchains 104 and the attribute blockchains 106 may be synchronized according to a specified time interval so that respective blocks in the same column may generally correspond to a contemporaneous time stamp.

[0022] Each layer 102 of the 3D blockchain data structure 100 may further include a data sources axis 112 that indicates a direction of growth of the respective layer 102 as new data blockchains 104 are added to the respective layer 102. Further, each layer 102 may include an attributes axis 114 that indicates a direction of growth of the respective layer 102 as additional attribute blockchains 106 are added to the respective layer 102. As discussed additionally below, as blocks are added to respective ones of the data blockchains 104 and the attribute blockchains 106, the new blocks may be linked (e.g., by added hash value) not only to the immediately preceding block in that blockchain, but may also be linked to blocks in adjacent blockchains in the same layer, as well as at least one block from a layer above or below the current layer.

[0023] In some examples, each data blockchain 104 may correspond to a respective data source and may be used to store data from the corresponding data source. Because data from respective different data sources is stored to different respective data blockchains 104, the 3D blockchain data structure 100 enables processing of a large amount of data from a large number of sources within a shorter processing time than conventional blockchains and without compromising data integrity and security. In addition, the attribute blockchains 106 enable fast information extraction from the data blockchains 104 without traversing through the data blocks in the respective data blockchains 104. Accordingly, the 3D blockchain data structure may provide significant benefits for data security, traceability, and efficient data exchange in various data storage and retrieval applications. For instance, traditional blockchain structures are not able to handle large amounts of data blocks in a short time while maintaining a desired level of security. In addition, traditional blockchains are not able to be used for extracting specified data efficiently from the blockchain, which is a desirable feature for many applications, such as Internet of Things (IoT), connected vehicles, supply chain management, and the like.

[0024] The 3D blockchain data structure 100 herein may serve as a distributed ledger to allow receipt and storage of data by a plurality of participants in a network, without the need for a trusted third party or central trusted medium. For instance, as one example, each separate layer 102 may correspond to a separate participant in the 3D blockchain data structure. The 3D blockchain data structure may store the blocks of each data blockchain 104 and each attribute blockchain 106 in chronological order, and the 3D blockchain data structure 100 may provide a distributed open ledger shared and maintained by all nodes of all participating peers in a decentralized system. The data blockchains 104 and attribute blockchains 106 may continually grow when new blocks are appended, respectively. Furthermore, the 3D blockchain data structure may be provided in a peer- to-peer network without requiring support or management by any third party.

[0025] The 3D blockchain data structure 100 herein is highly scalable, which overcomes a major deficiency of traditional blockchain technology. For instance, the 3D blockchain data structure 100 may grow indefinitely along the data sources axes 112 as new data sources are added. On the other hand, a traditional blockchain in which blocks are appended one by one is not able to handle a massive amount of data shared from a large number of data sources in a very short interval while maintaining a high degree of security.

[0026] In addition, for applications such as IoT or connected vehicles, the traditional blockchain structure may be problematic when a user wants to search and extract certain data from the blockchain. Since all the blocks that contain different data are chained together, the conventional technique for locating and extracting the data of interest is to traverse all the blocks one by one until the data of interest is located. As a result, traditional blockchain technology is not able to handle a situation in which a blockchain includes a large number of blocks and many users desire to search and extract different information from the blockchain. The 3D blockchain data structure 100 herein provides a solution to this problem as well.

[0027] FIG. 2 illustrates an example 3D blockchain data structure 200 including an enlarged view of an example layer according to some implementations. In this example, the 3D blockchain data structure 200 may correspond to the 3D blockchain data structure 100 discussed above with respect to FIG. 1. In this example, the 3D blockchain data structure 200 is configured for receiving and storing data for a plurality of connected vehicles (not shown in FIG. 2), such as sensor data, which may include failures or other problems sensed by sensors onboard the respective connected vehicles. For instance, with the rapid growth of connected vehicles, large amounts of data is being captured to improve traffic safety and efficiency. Examples of this data may include road traffic data, sensor data, driving habit data, car-to-car experience sharing, e-commerce transaction data, and so forth. This data explosion has raised challenges for storing and sharing the data.

[0028] Currently, most vehicle networks rely on centralized servers to store and share the connected vehicle data, which is faced with several disadvantages, such as low data security and privacy, poor interoperability and compatibility among different computing devices and entities, and high storage costs and transaction costs. To overcome these disadvantages, the 3D blockchain data structure 200 may be employed for connected vehicle applications where a large number of data blocks need to be added in the blockchain in a short time while also providing an efficient process for extracting data from the blocks.

[0029] To illustrate how the 3D blockchain data structure 200 works in a connected vehicle use case, suppose that there are three participants involved in a blockchain network, namely an original equipment manufacturer (OEM), a components supplier, and a fleet management company that manages a fleet of the connected vehicles.

[0030] Each layer of the 3D blockchain data structure 200 may correspond to a separate participant in the 3D blockchain network. As illustrated, suppose that the first layer is a fleet layer LI that corresponds to data received from the connected vehicles managed by the vehicle fleet management company. Furthermore, suppose that the second layer is a supplier layer L2 that corresponds to data received by a supplier of vehicle components included in the connected vehicles managed by the fleet management company. Additionally, suppose that the third layer is an OEM layer L3 that corresponds to data received by a manufacturer of the vehicles included in the fleet of connected vehicles.

[0031] Each participant may store many data blocks generated from its own data sources, and which may be added into the 3D blockchain data structure 200. Instead of connecting all the data blocks from all the participants in series, such as in a single conventional blockchain, the 3D blockchain data structure 200 provides each participant with its own layer to hold one or more data blockchains and one or more associated attribute blockchains. The 3D blockchain data structure 200 addresses the data sharing and tracing problems in connected vehicles applications due to its inherent properties of persistence, anonymity, and auditability. When used in the environment of connected vehicles, the 3D blockchain data structure 200 allows for confidentiality and transparency among all the participants in the blockchain network, including individuals, vehicles, and operational centers etc., such as by tracking and recording in the 3D blockchain data structure 200 all received data related to the connected vehicles.

[0032] In the enlarged view of the fleet layer LI, a plurality of data blockchains 104 and a plurality of attribute blockchains 106 are illustrated. Each block has its own block identifier (ID) in the 3D blockchain data structure 200 based on layer ID, blockchain ID, and block position number in the respective blockchain. For instance, three data blockchains are illustrated, each corresponding data stored for a different vehicle of the connected vehicles. Thus, a first vehicle data blockchain (BC) LI -VI stores data received from a first vehicle of the connected vehicles. The first vehicle data blockchain LI- VI currently includes four blocks, namely Ll-Vl-1 through Ll-Vl-4. Similarly, a second vehicle data blockchain L1-V2 may store data received from a second vehicle of the connected vehicles. The second vehicle data blockchain L1-V2 includes four blocks, namely L1-V2- 1 through L1-V2-4. In addition, a third vehicle data blockchain L1-V3 may store data received from a third vehicle of the connected vehicles. The third vehicle data blockchain L1-V3 includes four blocks, namely L1-V3-1 through L1-V3-4. Further, while three vehicle data blockchains are illustrated in this example, a large number of additional vehicle data blockchains may be included in other examples, depending on the number of connected vehicles in the fleet managed by the fleet management company.

[0033] The individual blocks of the attribute blockchains 106 may be individually identified using a similar identification system. In this example, a first attribute blockchain Ll-Al may store data location information for data related to a particular attribute of data received from the connected vehicles. Examples of attribute data may include camera data, suspension data, radar data, lidar data, operational data, and the like received from one or more of the connected vehicles.

The first attribute blockchain Ll-Al includes three blocks, namely Ll-Al-1 through Ll-Al-3. Similarly, a second attribute blockchain L1-A2 may store data location information for data related to a second attribute included in the data received from one or more of the connected vehicles. The second attribute blockchain L1-A2 includes four blocks, namely L1-A2-1 through L1-A2-4.

[0034] In addition, each column 202(l)-202(4) of the fleet layer LI may correspond to a different time interval. For example, the blocks (L1-A2-1, Ll-Al-1, Ll-Vl-1, L1-V2-1, and Ll- V3-1) in column 202(1) may correspond to data received at a time Tl, the blocks in column 202(2) may correspond to data received at time T2, the blocks in column 202(3) may correspond to data received at time T3, the blocks in column 202(4) may correspond to data received at time T4, and so forth. As discussed below, the attribute information stored in the respective attribute blocks of the respective attribute blockchains 106 may come from multiple data blocks from the same column as the respective attribute block, e.g., based on corresponding to the same time interval. For example, suppose that the first attribute blockchain Ll-Al stores camera error information, and further suppose that at time T3, data received from both vehicle VI and vehicle V3 included camera error information. Accordingly the attribute block Ll-Al-3 may include information related to the camera error information contained in both block Ll-Vl-1 and block Ll-Vl-3. [0035] The 3D blockchain data structure 200 not only solves the problem of processing multiple data blocks in a short period of time, but also enables fast data extraction from the data blocks through utilization of the attribute blocks. In addition, the number of vehicles and types of attributes may be expanded or contracted dynamically. New vehicles or new attribute types can be added to the corresponding layer LI at any time. For example, a new attribute blockchain (not shown in FIG. 2) for the fleet layer LI may be added along the axis 114. Additional details of the content of each block, as well as data authentication and verification techniques are discussed below.

[0036] The individual data blocks and attribute blocks in the other layers, i.e., the OEM layer

L3 and the supplier layer L2 may be identified using a labeling technique similar to that discussed and illustrated above with respect to the fleet layer LI. For instance, each of the OEM layer L3 and the supplier layer L2 includes its own data blocks and attribute blocks. In a use case of vehicle sensor predictive maintenance with traceable sensor data, suppose that the OEM layer has data blockchains for different vehicle models containing vehicle identification, sensor configurations,

ECU types, previous maintenance records etc. For the supplier layer L2, suppose that this layer has data blocks for various sensors used for the connected vehicles, and may include manufacturing information (time, place, components information, production line etc.), quality testing results, sensor capabilities, and the like. All these data blocks may have one or more corresponding attribute blocks in each layer. The traceable and reliable information added to the 3D blockchain data structure 200 by the supplier, the OEM, and the fleet management company provides a comprehensive database that would be able to provide a third party or other user a full history of a particular sensor and can thereby provide more accurate information for predictive maintenance, sensor evaluation, and so forth.

[0037] FIG. 3 illustrates an example architecture of a system 300 in which the 3D blockchain data structure 200 may be employed according to some implementations. As more and more sensors are installed in vehicles, the reliability of each sensor and the compatibility of the sensors with the vehicle ECUs and other sensors can have an effect on vehicle safety. During the vehicle’s life span, a variety of sensor errors might be produced which may contain information regarding sensor performance and reliability under different operating environments and different vehicle systems. Although many sensor errors or error codes can be access via onboard diagnostic (OBD) ports via aftermarket devices or through vehicle dealership devices, this may still not provide insight as to the root cause of these sensor problems, such as due to the lack of traceable sensor data and vehicle operational data that may correspond to the error. As a result, it may be difficult for vehicle owners, fleet management companies, vehicle dealers, or third party service providers to perform sensor predictive maintenance to avoid sensor failures or other sensor errors.

[0038] In the example of FIG. 3, vehicle sensor predictive maintenance provided as a use-case example to illustrate how the 3D blockchain data structure 200 herein with attribute blocks can be implemented to receive, store, and retrieve data in an efficient manner that provides a technological improvement over conventional blockchain technology. The system architecture 300 includes a plurality of entity service computing devices corresponding to a plurality of separate entities, respectively. For instance, one or more first entity service computing devices 302(1) may correspond to the fleet management company discussed above; one or more second entity service computing devices 302(2) may correspond to the supplier discussed above; and one or more third entity computing devices 302(3) may correspond to the OEM discussed above. [0039] At least the first entity service computing device(s) 302(1) may be able to communicate with a plurality of vehicles 304 over one or more networks 306. In the illustrated example, the plurality of vehicles include a first vehicle 304(1) and a second vehicle 304(2). In actual operation, however, there may be a large number of vehicles such as dozens, hundreds, thousands, etc. In addition, one or more of the entity service computing devices 302 may be able to communicate over the one or more networks 306 with one or more third party computing devices 308. As one example, a third party 310 associated with the third party computing device(s) 308 may be an entity that desires to access the 3D blockchain data structure 200 such as to obtain a portion of the data contained therein.

[0040] The one or more networks 306 may include any suitable communication technology, including a wide area network, such as the Internet; a local area network, such as an intranet; a wireless network, such as a cellular network; a local wireless network, such as Wi-Fi; short-range wireless communications, such as BLUETOOTH®; a wired network including Fibre Channel, fiber optics, Ethernet, or any other such network, a direct wired connection, or any combination thereof. Thus, the network(s) 306 may include wired and/or wireless communication technologies. The protocols used to communicate over such networks are well known in the art and will not be discussed in detail in this disclosure.

[0041] The entity service computing devices 302(1), 302(2), and 302(3) may each include a respective management program 312(1), 312(2), and 312(3), a respective blockchain program 314(1), 314(2), and 314(3), and at least one 3D blockchain data structure (DS) 200(1), 200(2), and 200(3), respectively, which may correspond to the 3D blockchain data structure 200 and 100 discussed above. In some examples, at least one entity service computing device 302 associated with each separate entity may include at least one entity service computing device 302 that executes the blockchain program 314 to operate as a blockchain node. For example, the entity service computing devices 302(1), 302(2), and 302(3) may be able to communicate with each other through a blockchain network 320 for exchanging blockchain communications 322, such as for synchronizing blocks to the 3D blockchain data structure 200 through a consensus mechanism or the like, as is known in the art.

[0042] The blockchain programs 314(1), 314(2), and 314(3) on the respective entity service computing devices 302(1), 302(2), and 302(3) may be configured to manage the respective 3D blockchain data structures 200(1), 200(2), and 200(3), which may be separately maintained versions of the same 3D blockchain data structure 200 in this example. For instance, the blockchain program 314(1) may maintain and add to the 3D blockchain data structure 200(1), the blockchain program 314(2) may maintain and add to the 3D blockchain data structure 200(2), and the blockchain program 314(3) may maintain and add to the 3D blockchain data structure 200(3). Accordingly, the respective entity service computing devices 302(1), 302(2), and 302(3) may include blockchain nodes that participate in the blockchain network 320.

[0043] In some examples, the blockchain network 320 included in the system 300 may be a scalable, decentralized peer-to-peer system able to generate and maintain the 3D blockchain data structure 200 and/or other blockchains (not shown in FIG. 3). The integrity of the data maintained in the 3D blockchain data structure 200 may be based on a consensus mechanism rather than, e.g., a mere trust-based infrastructure. In examples herein, “consensus” may refer to a collective decision-making process or agreement as to what is true or false. For instance, blockchain network 320 in the system 300 provides a distributed consensus network made up of the participating entity service computing devices 302(1), 302(2), and 302(3), which may serve as consensus nodes. The various different consensus nodes participating in the blockchain network 320 in the system 300 may exchange a series of blockchain communications 322 to come to a consensus, such as based on a proposal by one entity service computing device 302 and an endorsement of the proposal by one or more other ones of the other entity service computing devices 302 of the other entities. [0044] The blockchain network 320 in the system 300 is configured to record data as successive blocks in the 3D blockchain data structure 200, which serves as a distributed data structure for the data. As a result, the data is securely and immutably recorded in the 3D blockchain data structure 200 and is practically unalterable. In some examples, the entity service computing devices 302 of each entity participating in the system 300 may execute the same blockchain program 314. When a consensus is reached for a particular block, the entity service computing devices 302 may record that block to their respective 3D blockchain data structures 200(1), 200(2), and 200(3). Accordingly, in some cases, each of the entities may maintain a complete copy of the 3D blockchain data structure 200.

[0045] In some examples, the decentralized peer-to-peer nature of the blockchain network 320 may help prevent any single user, group of users, or other entity from controlling the underlying infrastructure or undermining the integrity of the blockchain network 320. For instance, the entities may be individuals, groups, corporations, state actors, organizations, and so forth, or a combination of any of these entities. In the illustrated example, there are three entities illustrated as participating in the blockchain network 320, but the number of entities may vary for various different applications. In some examples, the management program 312 and/or the blockchain program 314 may communicate with each other and/or with the programs 312 and/or 314 of the other entities directly and/or through one or more application programming interfaces (APIs). Accordingly, implementations herein are not limited to any protocol or other technique for communication between the various programs. Furthermore, while the programs 312 and 314 are illustrated for convenience of discussion, it will be apparent to those of skill in the art that more or fewer programs may be executed in the examples herein for performing the functions described herein. In some examples, the blockchain network 320 may communicate over the one or more networks 306, while in other examples, the blockchain network 329 may be separate from the networks 306 such as in the case of a private network or the like. Numerous other variations will be apparent to those of skill in the art having the benefit of the disclosure herein. [0046] In addition, the third-party computing device 308 may execute the third party program 324. For example, the third party program may be any suitable type of program application or the like able to communicate with at least one of the entities participating in the blockchain network. For example, the third party program may be able to request and receive data from the 3D blockchain data structure 200 from at least one of the entities participating in the blockchain network. Additional details of retrieving data from the 3D blockchain data structure 200 are discussed below, e.g., with respect to FIG. 10.

[0047] In this example, the vehicles 304 are configured to send vehicle data 330 to the first entity service computing device(s) 302(1), such as on a periodic basis, or in response to the detection of a sensor error, or in response to any other desired trigger. The first entity computing device 302 is configured to receive the vehicle data 330, and store the received data to the 3D blockchain data structure 200. Furthermore, the vehicles 304 are not necessarily identical and may include different components, sensors, capabilities, and the like. Accordingly, each vehicle 304 may share data with different content in it, for example, the vehicle data 330(1) sent by the first vehicle 304(1) may include camera sensor information, radar sensor information, and/or suspension sensor information. On the other hand, the vehicle data 330 sent by the second of vehicle 304 might include suspension sensor information, but may not include camera or radar sensor information.

[0048] Each vehicle 304 may include one or more ECUs (electronic control units) 332 or any of various other types of computing devices that may be configured to communicate with the first entity service computing device 302(1). “ECU” is a generic term for any embedded processing system that controls one or more of the systems, subsystems, or components in a vehicle. Software, such as a communication program (not shown in FIG. 3) may be executed by one or more ECUs 332 and may be stored in a computer-readable medium (e.g., RAM, ROM, EEPROM, flash memory or other memory technology, or any other medium that can be used to store the desired information and that can be accessed by a computing device) (not shown in FIG. 3) associated with the respective ECU to enable the ECU to operate as an embedded system and perform the functions described herein. ECUs may typically communicate with each other and other vehicle components including sensors and sensor ECUs over a vehicle bus, such as a controller area network (CAN) bus, according to a vehicle bus protocol.

[0049] The vehicles 304 may further include one or more communication interfaces (not shown in FIG. 3), which may include one or more software and/or hardware components for enabling communication over one or more network(s) 106. For example, the communication interfaces may enable communication through one or more cellular networks, wireless networks (e.g., Wi-Fi), BLUETOOTH®, any other types of radio communications, wireless communications, and the like. Further, some examples, the vehicles 304 may be configured for wired communications as well such as during a recharging period, a period of nonuse, or the like. [0050] In some implementations, the ECUs 332 may be configured to encrypt the vehicle data 330 before sending the vehicle data 330 to the first entity service computing device(s) 302(1). There are typically three components to any encryption system: the data, the encryption engine and the key management. Unencrypted data is known as plaintext, and encrypted data is called ciphertext. The formulas used to encode and decode messages are called encryption algorithms. For encryption algorithms, there are mainly three techniques: symmetric encryption, asymmetric encryption, and hash function (keyless). Symmetric encryption uses one single key to encrypt and decrypt data. And this key has to be shared with the recipient, which is a disadvantage. On the other hand, asymmetric encryption uses two different, but logically linked, keys, namely public key and private key. One key for encryption and the other key will be used for decryption. Since the private key is only kept in the local computing device, the private key may be used to identify the sender identity. Combined with hash function, asymmetric encryption is used in some examples herein in connection with the 3D blockchain data structure 200 for data encryption, digital signatures, and authentication. However, implementations herein are not limited to any particular encryption techniques.

[0051] In the example of FIG. 3 the first vehicle 304(1) includes a camera 334, a radar 336, and a suspension sensor 338 as well as other sensors. The second vehicle 304(2) includes the suspension sensor 338 but might not include the camera 334 or the radar 336. The ECUs 332 may send vehicle data 330 to the first entity service computing device for recordation in the 3D blockchain data structure 200 as discussed above. In this example, the vehicle data 330(1) sent by the first vehicle 304(1) includes a timestamp, vibration information, temperature, humidity, operational data such as GPS location information, speed, vibration information, operating temperature, and the like. In addition, the vehicle data 330(1) may include a vehicle ID, and a vehicle signature, as discussed additionally below. Furthermore, the vehicle data 330(1) may include sensor error information which in this example includes camera sensor error information and suspension sensor error information. The camera sensor error information may include a camera ID, an error code, and a camera signature. Furthermore, the suspension sensor error information includes a suspension ID, an error code, and a suspension signature.

[0052] Similarly, the vehicle data 330(2) sent by the second of vehicle 304(2) includes a timestamp, vibration information, temperature, humidity, operational data such as GPS location information, speed, vibration, operating temperature and the like. In addition, the vehicle data 330(2) may include a vehicle ID and a vehicle signature. Furthermore, the vehicle data 330(2) may include suspension sensor error information, which in this example includes a suspension ID, an error code, and a suspension signature.

[0053] FIGS. 4, 5, 7, 9, and 10 include flow diagrams illustrating example processes according to some implementations. The processes are illustrated as collections of blocks in logical flow diagrams, which represent a sequence of operations, some or all of which can be implemented in hardware, software or a combination thereof. In the context of software, the blocks may represent computer-executable instructions stored on one or more computer-readable media that, when executed by one or more processors, program the processors to perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures and the like that perform particular functions or implement particular data types. The order in which the blocks are described should not be construed as a limitation. Any number of the described blocks can be combined in any order and/or in parallel to implement the process, or alternative processes, and not all of the blocks need be executed. For discussion purposes, the processes are described with reference to the environments, systems, and devices described in the examples herein, although the processes may be implemented in a wide variety of other environments, systems, and devices.

[0054] FIG. 4 illustrates an example process 400 for generating data on a vehicle according to some implementations. In this example, suppose that the vehicle represented by FIG. 4 includes a camera and camera ECU 402 in addition to a main ECU 404 that may control the communications to computing devices external to the vehicle. As mentioned above, the vehicle may have multiple sensors and may further include sensor ECUs for at least some of the sensors. In the example of FIG. 3, discussed above, the sensors and sensor ECU may be received from a supplier that may be one of the entities participating in the blockchain network 320 discussed above. One or more of the sensor ECUs, such as the camera and camera ECU 402, may include key generation program 406 to generate a private key for this ECU, and to generate a corresponding public key that can subsequently be used by another computing device for performing data authentication.

[0055] When an error code is generated by the camera, original camera data 412 related to the error may include a camera ID, such as a camera serial number, and may further include the camera error code. At 414, the camera ECU may hash the original camera data and may encrypt the hash with the private key 408 to generate a camera signature 416. For example, a selected hash algorithm may be used to hash the original camera data 412 (e.g., camera ID and error code). The camera signature 416 may be obtained by encrypting the hash using the private key 408. Next, the plaintext of the original camera data 412 and the camera signature 416 may be sent to the main ECU for data aggregation. As indicated at 418, the public key 410 may also be provided to the main ECU 404 to be provided to the blockchain computing device (e.g., the first entity service computing device(s) 302(1) discussed above with respect to FIG. 3) to be used for verification of the camera signature following receipt of the vehicle data 330(1).

[0056] As indicated at 420, original data and signatures from other sensors and ECUs (e.g., a suspension sensor and ECU- not shown in FIG. 4) may also be provided for aggregation with the vehicle data 330(1) when the other sensors or control modules generate an error code. The signatures for the other sensors may be generated in a manner similar to that discussed above for the Cameron camera ECU 402.

[0057] The main ECU 404 may combine all the aggregated sensor information and signatures, together with other sensor data 422 such as temperature 424, humidity 426, vibration 428, GPS information 430, vehicle speed 432, and other operational data. The main ECU 404 may also include a key generation program 436 that may be used to generate a private key 438 and public key 440. The main ECU may hash the other sensor data and aggregated senor information and signatures and may encrypt the hash using the private key 438 to generate a vehicle signature 442. The original other sensor data may be included in the vehicle data 330(1) along with the vehicle signature 442.

[0058] As indicated at 444, the vehicle data 330(1) may be sent to the blockchain computing device (e.g., the fleet management company service computing device). As one example, the vehicle data 330(1) may be transmitted using MQTT (Message Queuing Telemetry Transport) protocol. For instance, MQTT is a lightweight network protocol that transports messages between devices, typically over TCP/IP. Alternatively, any other desired communication protocol may be employed. Furthermore, all the corresponding public keys may be shared to the blockchain computing device as well to enable data verification. In addition, in some cases, the vehicle data 330(1) may be encrypted prior to sending to the blockchain computing device.

[0059] For performing data verification, when the blockchain computing device (e.g., the first entity service computing device(s) 302(1)) receives the vehicle data 330(1) and the public keys, the blockchain computing device may first decrypt the received data if the data was encrypted by the vehicle ECU. Next, the blockchain computing device may perform data verification (authentication) by calculating a hash of the original data using the same hash function as that used by the vehicle ECUs. In addition, the blockchain computing device may decrypt the vehicle signature to obtain the hash. The blockchain computing device may compare the two hashes. If the two hashes are identical, the data is authenticated; otherwise, the data may have been tampered with and may be discarded.

[0060] FIG. 5 illustrates an example process 500 for adding data blocks and attribute blocks to a 3D blockchain data structure according to some implementations. In some examples, the process 500 may be executed by the management program 312 and the blockchain program 314 executing on a computing device, such as the first entity computing device(s) 302(1) or other suitable computing device.

[0061] At 502, the computing device may receive vehicle data. For example, as discussed above, the connected vehicles may send vehicle data to the first entity computing device 302(1) for adding the data to the 3D blockchain data structure 200. In this example, suppose that the received vehicle data is the vehicle data 330(1) sent by the first vehicle 304(1), e.g., as discussed above with respect to FIGS. 3 and 4.

[0062] At 504, the computing device may decrypt and verify the authenticity of the vehicle data. For example, as discussed above, the computing device may decrypt the received data. The computing device may then use the public key associated with each digital signature included in the vehicle data to verify the associated data, such as by comparing a hash value calculated from the received data with the hash value associated with the digital signature.

[0063] At 506, following authentication of the received data, the computing device may provide the vehicle data to a waiting pool such as a buffer or other memory or storage location. For instance, the received data may be stored in memory temporarily while the computing device determines in which layer of the 3D blockchain data structure the received data belongs and the location of the data block.

[0064] At 508, the computing device may determine the layer, row, and column in the 3D blockchain data structure based on the vehicle data. For instance, the layer may be determined based on determining that the data is received from one of the vehicles in the fleet managed by the fleet management company. Furthermore, the role may be determined based on the vehicle ID included in the vehicle data. In addition the column may be determined based on a timestamp associated with the received vehicle data and/or based on determining a number of blocks already included in the identified row. In the example fleet layer LI illustrated in FIG. 5, suppose that the vehicle data is received from the first vehicle VI, and that the new data block for storing the received data will be located in the fourth column. Accordingly, the identifier of the new data block will be “Ll-Vl-4”.

[0065] At 510 for the new data block, the computing device may determine a header for the new block by including multiple previous hashes and the block ID of the previous hashes and a Merkel root. To utilize the traditional blockchain concept without decreasing the security, four previous hashes may be used, e.g., three hashes from prior adjacent blocks in the same layer and one hash from a prior adjacent block in the next adjacent layer. Additional details of determining the previous hashes and the Merkel root are discussed additionally below e.g. with respect to FIGS. 6 and 7.

[0066] At 512, the computing device may calculate a nonce for the header for the new block based on a defined format for calculating the nonce. For instance, after the header is constructed, a “mining” process (which is a trial-and-error process) may be performed by adjusting the nonce number in the header, such that the hashing output of the header will generate a targeted hash. The calculated nonce is included in the block header.

[0067] At 514, the computing device adds the new data block to the 3D blockchain data structure at the indicated location.

[0068] At 516, the computing device synchronizes the added data block with the other blockchain nodes participating in the blockchain network, e.g., as discussed above with respect to FIG. 3.

[0069] At 518, in parallel with performing operations 510-516 (or before or after performing these operations), the computing device also may initiate generation of one or more attribute blocks based on the received data by extracting one or more attributes from the received vehicle data. For the example 3D blockchain data structure 200 discussed above, examples of attributes may include sensor errors, such as camera sensor errors and suspension sensor errors, e.g., as shown at Ll-Al and L1-A2, respectively.

[0070] At 520, the computing device may determine attribute block ID for the extracted attribute. For example, the received vehicle data may include a suspension error that may be extracted from the vehicle data. Based on identifying the suspension error, the computing device may determine that a new block should be added to row L1-A2 of the fleet layer LI, and that the next block should be added in the fourth column. Accordingly, the block identifier for the new attribute block may be determined to be L1-A2-4.

[0071] At 522, the computing device may determine a data block ID for inclusion in the attribute block. For example, the attribute block may include a listing of data blocks in the same column as the attribute block that include data related to the identified attribute. This enables the attribute block to be used to identify a location of the corresponding data block that includes data related to that attribute, i.e., in this example, a suspension sensor error.

[0072] At 524, the computing device may perform blocks 526 through 532 for each attribute block to be added to the 3D blockchain data structure 200. [0073] At 526, the computing device may determine a header for the attribute block that may include multiple previous hashes and block IDs of the previous hashes. An example of determining the hashes to include in the header is discussed below e.g. with respect to FIG. 6.

[0074] At 528, the computing device may calculate a nonce for the header based on a defined format. As mentioned above, the calculation of the nonce may be performed as a trial-and-error process by adjusting the nonce number in the header, such that the hashing output of the header will generate a targeted hash. The calculated nonce is included in the block header.

[0075] At 530, the computing device may add the new attribute block to the 3D blockchain data structure at the indicated location.

[0076] At 532, the computing device may synchronize the added attribute block with the other blockchain nodes participating in the blockchain network, e.g., as discussed above with respect to FIG. 3.

[0077] FIG. 6 illustrates an example 600 of determining the hashes to use in the header for a new block according to some implementations. Since the first entity computing device(s) 302(1) (e.g., fleet management company server) may act as a mining node the process of adding a new block may be performed by the first entity computing device(s) 302(1). When adding a block to the 3D blockchain data structure 200, as discussed above with respect to FIG. 5, a block header is constructed for the new block. The header may be constructed to include a plurality of hashes of previous blocks in the 3D blockchain, the block IDs of these blocks, a Merkle root, and a nonce. To utilize the traditional blockchain concept without decreasing security of the 3D blockchain data structure 200, four previous hashes are used in some examples herein. For instance, three hashes may be taken from prior blocks located adjacent to the new block in the same layer (i.e., layer LI in this example) and one hash from an adjacent prior block in an adjacent layer (i.e., layer L2-not shown in FIG. 6).

[0078] In the illustrated example, suppose that a new data block having block ID L1-V2-5 is being added in the fifth column 202(5) of the layer LI, and corresponding to a time interval T5. Accordingly, the hashes added to the header of the new block may include a hash 602 from block Ll-Vl-4, a hash 604 from block L1-V2-4, a hash 606 from block L1-V3-4, and a hash 608 from block L2-V2-4 in the second layer L2. Furthermore, while four hashes of prior blocks are used for the header for the new block in this example, in other examples, more or fewer hashes of prior blocks may be used for the header of the new block, so long as a consistent technique is employed for each layer.

[0079] FIG. 7 illustrates an example process 700 for calculating the Merkle root for the block header for a new block according to some implementations. To calculate the Merkle root, in this example suppose that the data is divided into four portions at a data level 702, e.g., data 1, data 2, data 3, and data 4. At the next level, i.e., a leaf-level 704, four data hashes are calculated from the data portions, i.e., hash 1 calculated from data 1, hash 2 calculated from data 2, hash 3 calculated from data 3, and hash 4 calculated from data 4. At the level- 1 706, one level above the leaf-level 704, there may be two data hashes, e.g., hash 12 calculated from hash 1 and hash 2, and hash 34 calculated from hash 3 and hash 4 in the leaf level 704. At the top, level-2 708 the Merkle root 710 may be calculated as a hash of the two hashes at level- 1, i.e., hash 12 and hash 34. Essentially, the Merkle tree and Merkle root mechanism significantly reduce the levels of hashing to be performed, enabling faster verification for data integrity.

[0080] The hash function may be used multiple times in blockchain technology when adding new blocks into the 3D blockchain data structure 200. Examples include transaction verification, Merkel root calculations, and block hash calculations. Generally, hashing involves processing the input data through a mathematical function, which results in an output of a fixed length, i.e. hashing all the contents in a block header may generate a fixed-length output.

[0081] Two mechanisms that help to make the blockchain system tamper resistant include cryptographic fingerprints, e.g., a hash that is unique to each block, and a consensus protocol. For the hash of each block, the hash may employ substantial computing time to generate the block. However, to verify whether the block hash is correct is easy. Once a node has determined the hash of a block and another node has verified the hash, the node may update its copies of the 3D blockchain data structure with the new block. This is the consensus protocol. An additional security feature is that each of the blocks may also be used as the content of a next block in the blockchain. Thus, any change in a previous block requires a recalculation of all the subsequent blocks, so any blocks added would conflict with existing ones, and the other blockchain nodes will automatically reject the alterations. This helps make the blockchain data structure generally “immutable.”

[0082] FIG. 8 illustrates an example attribute block 800 according to some implementations. To solve the traditional blockchain’ s data extraction problem, in the 3D blockchain data structures herein, the attribute block 800 may be used to store a list of block IDs 802 that contain the specific attribute data to which the particular attribute block 800 relates. For instance, in this example, suppose that the attribute block ID is F1-A2-3, corresponding to the suspension sensor. Further, suppose that the data block ID of the new data block is Fl-Vl-3, which includes the data 804, that includes a suspension error code and other suspension sensor data. Accordingly, after the data block ID for the new data block Fl-Vl-3 is determined, any attributes in the data 804 contained in the data block Fl-Vl-3 may be detected and extracted. [0083] Based on the extracted attributes, a list of IDs for each of the new attribute blocks to be added in the same column may be determined (e.g., at least Ll-Al-3 and L1-A2-3 since the data 804 includes sensor error codes for the camera and the suspension sensors). For each of the determined attribute blocks, the new data block ID Ll-Vl-3 may be added to the list of data blocks having data including the attribute. Furthermore, if data for other vehicles is received in the same time interval and also includes a suspension sensor error, the block IDs for these data blocks may also be added to the list 802 in the attribute block L1-A2-3.

[0084] When the data block IDs of the relevant data blocks for the current time interval have been added to the list 802, construction of the header 806 may begin for the new attribute block L1-A2-3. As mentioned above, the header 806 may include the previous blocks hashes 808, e.g., three from the same level LI and one from the adjacent level L2. The block IDs 810 for the previous blocks and the Merkle root 812 may also be included in the header 806.

[0085] In addition, the nonce 814 may be calculated and adjusted for the target hash so that the hash 816 for the new block has a specified form, such as a specified number of leading zeros. The nonce 814 is included in the header of the new attribute block and the new attribute block is then sent to the other blockchain nodes in the blockchain network for verification.

[0086] The header 806 for the new vehicle data block Ll-Vl-3 may be similarly determined. In this example, since the vehicle data block is in the first data row, there are no data blocks to one side of the first data row. Accordingly, rather than using three previous blocks from the same layer for the header 806 of the new vehicle data block Ll-Vl-3, hashes from only two previous blocks (i.e., Ll-Vl-2 and L1-V2-2) from the same layer LI are added to the header 806, and hashes from two previous blocks (L2-V1-2 and L2-V2-2) from the adjacent layer L2 are added to the header 806 of the new data block Ll-Vl-3. Alternatively, genesis blocks can be used as the first blocks of each row in each layer.

[0087] When the received vehicle data is from a new vehicle, a new row may be created in the layer for adding the new vehicle ID and one or more new blocks containing data received from the new vehicle may be added to the new row, such as started in the column corresponding to the current time interval. Similarly, when a new data attribute is detected from received vehicle data, a new attribute row may be created in the layer for adding data block ID(s) of data blocks having data related to the new attribute. The new attribute block may be added starting at the column corresponding to the current time interval.

[0088] FIG. 9 is a flow diagram illustrating an example process 900 for gaining consensus for a new block according to some implementations. As one example, the process 900 may be executed by the entity computing device(s) 302, such as by execution of the blockchain program 314. As discussed above, after the targeted hash is obtained during nonce calculation, the new block (attribute block or data block) is ready for verification by the other blockchain nodes in the blockchain network.

[0089] At 902, the first entity computing device may determine the nonce and send the new block for confirmation to the second entity computing device and the third entity computing device.

[0090] At 904, both the second entity computing device and the third entity computing device may perform the same verification process to determine whether to confirm or reject the new block.

[0091] At 906, the computing device performing the confirmation may access header content in the received new block.

[0092] At 908, the computing device may calculate a hash based on the content of the header of the new block and compare the result with the hash included with the new block.

[0093] At 910, the computing device determines if the calculated hash matches the hash included with the new block. If so, the process goes to 912. If not, the process goes to 922. For example, if the two hashes are different from each other, the block is rejected without adding to the blockchain.

[0094] At 912, the computing device determines if the previous block hashes included in the header match those in the blocks in the 3D blockchain data structure. If so, the process goes to 914. If not, the process goes to 922. For example, the previous hashes in the header may be compared with original hashes which can be obtained based on the block ID information in the header. If one or more hashes are different, the block will be rejected.

[0095] At 914, the computing device may verify the Merkle root included in the header. If the Merkle root is correct, the process goes to 916. If not, the process goes to 922.

[0096] At 916, if the new block is a data block, the computing device may verify the authenticity of the vehicle data included in the data block. For example, since the public keys from the vehicle as well as all the other sensor components are publicly available, the data’ s authenticity can be quickly verified using the corresponding signature and data based on the process discussed above, e.g., with respect to FIG. 4.

[0097] At 918, the computing device may send an indication of confirmation of the new block to the other entity computing devices of the other entities participating in the blockchain network. [0098] At 920, the computing device may add the new block to its own 3D blockchain data structure 200. [0099] At 922, if the new block fails to pass one of the confirmation tests at 910, 912, 914, or 916, the new block is rejected and a notification of the rejection is sent to the other entity computing devices.

[00100] FIG. 10 is a flow diagram illustrating an example process 1000 for extracting data from the 3D blockchain according to some implementations. The process 1000 may be executed by the management program 312 executing on one of the entity computing devices 302, or other suitable computing device. As mentioned above, the 3D blockchain with attribute blocks not only enables fast processing and storage of large amounts of data, but also provides an efficient data extraction mechanism. As an example, suppose that a third party entity (e.g., an entity not participating in the blockchain network) is interested in gathering data for determining sensor predictive maintenance for the camera sensor and desires to obtain sensor error data related to the camera sensor for in the 3D blockchain for a certain time range.

[00101] At 1002, the computing device may receive, from the third party computing device, a request for data: “Camera Sensor Errors in Time Range T2-T3”.

[00102] At 1004, the computing device may check the attributes listed in layer LI of the 3D blockchain DS to locate a matching sensor attribute A1 (i.e., camera).

[00103] At 1006, the computing device may access the attribute blocks (i.e., attribute blocks Ll-Al-2 and LI -A 1-3) for the specified time range 1005 to extract data block information included in those attribute blocks: “Ll-Vl-3” and “L1-V2-2”.

[00104] At 1008, the computing device may access the identified data blocks (Ll-Vl-3 and L1-V2-2) to extract the data stored in these blocks.

[00105] At 1010, the computing device may send the data retrieved from the identified data blocks to the requesting third party computing device.

[00106] The computing device may apply a similar search and data retrieval technique to the other layers in the 3D blockchain data structure, such as the OEM layer L3 and the supplier layer

L2 to gather all the related information related to the specific sensor error code. The third party entity is then able to utilize the full scope of data ranging from the start of sensor manufacturing, installation on vehicles and vehicle environment, to actual operational data on the vehicle, and can therefore determine predictive maintenance for the sensor of interest with higher accuracy.

[00107] The example processes described herein are only examples of processes provided for discussion purposes. Numerous other variations will be apparent to those of skill in the art in light of the disclosure herein. Further, while the disclosure herein sets forth several examples of suitable frameworks, architectures and environments for executing the processes, the implementations herein are not limited to the particular examples shown and discussed. Furthermore, this disclosure provides various example implementations, as described and as illustrated in the drawings. However, this disclosure is not limited to the implementations described and illustrated herein, but can extend to other implementations, as would be known or as would become known to those skilled in the art.

[00108] FIG. 11 illustrates select components of one or more example entity computing devices 302 that may be used to implement some functionality of the services described herein, such as performing data management and blockchain operations as discussed in the examples herein. The computing device(s) 302 may include one or more servers or other types of computing devices that may be embodied in any number of ways. For instance, in the case of a server, the programs, other functional components, and data may be implemented on a single server, a cluster of servers, a server farm or data center, a cloud-hosted computing device, a virtual machine hosting computing device, and so forth, although other computer architectures may additionally or alternatively be used.

[00109] Further, while the figures illustrate the functional components and data of the computing device(s) 302 as being present in a single location, these components and data may alternatively be distributed across different computing devices and different locations in any manner. Consequently, the functions may be implemented by one or more computing devices 302, with the various functionality described above distributed in various ways across the different computing devices. Multiple computing devices 302 may be located together or separately, and organized, for example, as virtual servers, server banks, and/or server farms. The described functionality may be provided by the servers of a single entity or enterprise, or may be provided by the servers and/or services of multiple different entities or enterprises.

[00110] In the illustrated example, each computing device 302 may include one or more processors 1102, one or more computer-readable media 1104, one or more communication interfaces 1106, and one or more input/output (I/O) devices 1108. Each processor 1102 may be a single processing unit or a number of processing units, and may include single or multiple computing units or multiple processing cores. The processor(s) 1102 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. For instance, the processor(s) 1102 may be one or more hardware processors and/or logic circuits of any suitable type specifically programmed or configured to execute the algorithms and processes described herein. The processor(s) 1102 can be configured to fetch and execute computer-readable instructions stored in the computer-readable media 1104, which can program the processor(s) 1102 to perform the functions described herein. [00111] The computer-readable media 1104 may include volatile and nonvolatile memory and/or removable and non-removable media implemented in any type of technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. Such computer-readable media 1104 may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, optical storage, solid state storage, magnetic tape, magnetic disk storage, RAID storage systems, storage arrays, network attached storage, storage area networks, cloud storage, or any other medium that can be used to store the desired information and that can be accessed by a computing device. Depending on the configuration of the computing device 302, the computer-readable media 1104 may be a type of computer-readable storage media and/or may be a tangible non-transitory media to the extent that when mentioned herein, non-transitory computer-readable media exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.

[00112] The computer-readable media 1104 may be used to store any number of functional components that are executable by the processors 1102. In many implementations, these functional components comprise instructions or programs that are executable by the processors 1102 and that, when executed, specifically configure the one or more processors 1102 to perform the actions attributed above to the computing device 302. Functional components stored in the computer-readable media 1104 may include the management program 312 and the blockchain program 314. Additional functional components stored in the computer-readable media 1104 may include an operating system 1110 for controlling and managing various functions of the computing device 302.

[00113] In addition, the computer-readable media 1104 may store data used for performing the operations described herein. Thus, the computer-readable media 1104 may store the 3D blockchain data structure(s) 100 and/or 200. In addition, the computer-readable media 1104 may store or otherwise maintain other functional components and data not specifically shown in FIG. 11, such as other programs and data 1112, which may include programs, drivers, etc., and the data used or generated by the functional components. Further, the computing device 302 may include many other logical, programmatic, and physical components, of which those described above are merely examples that are related to the discussion herein.

[00114] The communication interface(s) 1106 may include one or more interfaces and hardware components for enabling communication with various other devices, such as over the network(s) 130. For example, communication interface(s) 1106 may enable communication through one or more of the Internet, cable networks, cellular networks, wireless networks (e.g., Wi-Fi) and wired networks (e.g., fiber optic and Ethernet), as well as close-range communications, such as BLUETOOTH®, and the like, as additionally enumerated elsewhere herein.

[00115] The computing device(s) 302 may further be equipped with various input/output (I/O) devices 1108. Such I/O devices 1108 may include a display, various user interface controls (e.g., buttons, joystick, keyboard, mouse, touch screen, etc.), audio speakers, connection ports and so forth.

[00116] Various instructions, processes, and techniques described herein may be considered in the general context of computer-executable instructions, such as computer programs and applications stored on computer-readable media, and executed by the processor(s) herein. Generally, the terms program and application may be used interchangeably, and may include instructions, routines, modules, objects, components, data structures, executable code, etc., for performing particular tasks or implementing particular data types. These programs, applications, and the like, may be executed as native code or may be downloaded and executed, such as in a virtual machine or other just-in-time compilation execution environment. Typically, the functionality of the programs and applications may be combined or distributed as desired in various implementations. An implementation of these programs, applications, and techniques may be stored on computer storage media or transmitted across some form of communication media. [00117] Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claims.

Claims

1. A system comprising: a first computing device able to communicate with one or more second computing devices, the first computing device including one or more processors configured by executable instructions to perform operations comprising: receiving, by the first computing device, data from a data source of a plurality of data sources; determining, based at least on information about the data source, a layer, row, and column in a three-dimensional (3D) blockchain data structure, the 3D blockchain data structure including a plurality of layers, each layer including a plurality of rows of data blocks; generating a data block to add to the 3D blockchain data structure based on the determined layer, row, and column, the generated data block including the received data; and sending the generated data block to the one or more second computing devices for confirmation for adding to the 3D blockchain data structure.

2. The system as recited in claim 1, one or more layers of the plurality of layers including one or more rows of attribute blocks, wherein a respective attribute block includes a block identifier (ID) of a corresponding data block that includes data related to an attribute associated with the respective attribute block.

3. The system as recited in claim 2, the operations further comprising: receiving, by one of the first computing device or the one or more second computing devices, a request for data from the 3D blockchain data structure, the requested data corresponding to the attribute associated with the respective attribute block; and accessing the respective attribute block to determine at least one block identifier of at least one data block containing data related to the attribute.

4. The system as recited in claim 2, the operations further comprising: determining that the received data includes data related to a first row of the one or more rows of attribute blocks; and generating a new attribute block to add to the first row, the new attribute block including a data block identifier to identify the generated data block.

5. The system as recited in claim 2, wherein the new attribute block includes data block identifiers for a plurality of different data blocks, each different data block corresponding to a different data source of the plurality of data sources.

6. The system as recited in claim 1, the operation of generating the data block further comprising generating a header for the generated data block, the header including at least one hash from at least one data block located in a layer different from the layer determined for the generated data block.

7. The system as recited in claim 6, wherein the operation of generating the header comprises including in the header a hash from a previous data block in a same row as the generated data block and a hash from a previous data block in a row adjacent to the row determined for the generated data block.

8. The system as recited in claim 1, wherein generating the header comprises including in the header block identifiers of a plurality of blocks whose hashes are also included in the header.

9. The system as recited in claim 1, wherein individual columns of the 3D blockchain data structure correspond to different respective time intervals.

10. The system as recited in claim 1, wherein the plurality of data sources are a plurality of vehicles, respectively, in communication with the first computing device, wherein individual rows in the plurality of rows of data blocks in at least one layer each correspond to a separate vehicle of the plurality of vehicles.

11. The system as recited in claim 1, wherein the received data includes an encrypted hash of at least a portion of the received data, the operations further comprising decrypting the encrypted hash and comparing the decrypted hash with a hash calculated from the received data to verify an authenticity of the received data.

12. A method comprising: receiving, by a first computing device able to communicate with one or more second computing devices, data from a vehicle of a plurality of vehicles able to communicate with the first computing device; determining, based at least on information about the vehicle, a layer, row, and column in a three-dimensional (3D) blockchain data structure, the 3D blockchain data structure including a plurality of layers, each layer including a plurality of rows of data blocks; and generating a data block to add to the 3D blockchain data structure based on the determined layer, row, and column, the generated data block including the received data; and sending the generated data block to the one or more second computing devices to obtain a consensus for adding the generated block to the 3D blockchain data structure.

13. The method as recited in claim 12, wherein one or more layers of the plurality of layers include one or more rows of attribute blocks, wherein a respective attribute block includes a block identifier of a corresponding data block that includes data related to an attribute associated with the respective attribute block, the method further comprising: receiving, by one of the first computing device or the one or more second computing devices, a request for data from the 3D blockchain data structure, the requested data corresponding to the attribute associated with the respective attribute block; and accessing the respective attribute block to determine at least one block identifier of at least one data block containing data related to the attribute.

14. One or more computer-readable media storing instructions executable by one or more processors to configure the one or more processors to perform operations comprising: receiving, by a first computing device able to communicate with one or more second computing devices, data from a data source of a plurality of data sources; determining, based at least on information about the data source, a layer and row in a three- dimensional (3D) blockchain data structure, the 3D blockchain data structure including a plurality of layers, each layer including a plurality of rows of data blocks, wherein the plurality of rows in at least one layer correspond to the plurality of data sources, respectively; generating a data block to add to the 3D blockchain data structure based on the determined layer and row, the generated data block including the received data; and sending the generated data block to the one or more second computing devices for confirmation for adding the generated data block to the 3D blockchain data structure.

15. The one or more computer-readable media as recited in claim 14, wherein one or more layers of the plurality of layers include one or more rows of attribute blocks, wherein a respective attribute block includes a block identifier of a corresponding data block that includes data related to an attribute associated with the respective attribute block, the operations further comprising: receiving, by one of the first computing device or the one or more second computing devices, a request for data from the 3D blockchain data structure, the requested data corresponding to the attribute associated with the respective attribute block; and accessing the respective attribute block to determine at least one block identifier of at least one data block containing data related to the attribute.