The Porsche-XAIN Vehicle Blockchain Network: A Technical Overview
Ever wonder which cars would be the first to implement Blockchain technology? Spoiler alert, it’s Porsche. But don’t worry, the excitement is far from over. In fact, it’s only beginning.
1. General Setup and History
Speaking of exciting beginnings, it all started five years ago at the University of Oxford and Imperial College in London, where a group of researchers, machine-learning engineers, mathematicians and cryptographers, including Leif-Nissen Lundbæk, Felix Hahmann, Daniel Janes Beutel, Professor Michael Huth and Laurence Kirk, decided to join forces. The result was XAIN — a research project focused on strengthening the Blockchain through reinforcement learning and a novel two-fold consensus mechanism — called Practical Proof of Kernel — for massive energy reductions and network democratization that directly includes mobile low-power devices, like ECUs in machines or connected cars.
It was that last bit that caught the attention of Porsche, the perennially forward-thinking car manufacturer. This is where things got interesting. In mid-2017 XAIN won the 1st Porsche Innovation Contest against 120 international startups. As a result, a partnership with Porsche was formed. This new partnership, next to already existing ones with NVIDIA and Daimler, gave XAIN a boost of confidence that fueled even more innovation and creativity inside the company. After a successful test in December 2017, Porsche and XAIN intensified their cooperation to further develop and test XAIN’s Blockchain-powered hybrid vehicle client. Currently, the goal for the coming years is to test a potential serialized production, as well as to expand the application areas, potentially also involving further third parties.
“Once autonomous driving is broadly adopted, the collaboration possibilities are practically endless.”
Alright, but what does all this technobabble mean for regular drivers today? What’s so exciting about the same old Blockchain-meets-car storyline? Glad you asked. If you are lucky enough to become a future owner of a brand-new Porsche, here’s what you’ll be able to do with it using just your smartphone:
● Record traffic data over the Blockchain, in direct communication with other vehicles.
● Lock/unlock your car, way faster and much more secure, thanks to a Blockchain-powered direct offline connection (no server connection involved)
● Grant somebody else temporary access to your Porsche, even if you’re nowhere near.
● Receive real-time notifications about who/when/where accessed your Porsche.
● Get your mail packages securely delivered directly inside the trunk of your parked car.
● Enjoy the unhackable safety of a fully decentralized Blockchain implementation.
Additionally, Porsche itself gains direct benefits on the basis of data access, including:
● An increased trust in vehicle data, entirely audited and usable for reports, certificates and especially the access of local data for predictive maintenance and autonomous driving.
● An increased security for vehicle software, sued for flexible access transactions and secure update opportunities.
● The XAIN Blockchain as a distributed, lightweight and trusted “app store” for fast integrations of third party software, such as from DHL.
● An increased customer trust, while meeting GDPR compliance requirements for data usage.
● The potential training of distributed machine learning to achieve better local models for autonomous driving as a knowledge transfer platform with efficiency and privacy gains, compared to sending large amounts of data.
We need to emphasize this safety and security a being key consideration here. Unlocking your Porsche car happens via an online transaction that is mined by the vehicle network, a public permissioned Blockchain with hybrid nodes inside the car. Each node mines with Practical Proof of Kernel Work (PPoKW), developed as an energy-optimized consensus algorithm that works in ECUs of the cars. The network is stabilized through reinforcement learning. The pilot described below is just a taste of what we have in store for future Porsche-XAIN collaborations. Once autonomous driving is broadly adopted, the collaboration possibilities are practically endless. For now, we are content with pushing Blockchain innovation in the automotive sector as far as it can go.
We are genuinely excited about publishing below a more detailed technical explanation of how we integrated our clients inside of cars, and how the cryptographic mechanisms solve the above mentioned features:
2. Overview of XAIN Blockchain
We begin with introducing the core features of the eXpandable AI Network (XAIN), as the main technology behind the vehicle network. XAIN consists of three main technology stacks:
- Three different types of clients,
- Practical Proof of Kernel Work, a novel and patented consensus mechanism, and
- The integration of an EVM module for smart contracts on the basis of Solidity.
Starting with the clients, we differentiate between logging-only clients (XAIN Dataloggers) that store the entire Merkle tree of the Blockchain, including the history of all transactions. Further, we integrate Initiators, clients that are comparable to light clients in Ethereum in that they look at neighboring logging-only clients for actual data, but also have the ability to put new transactions into the network. Furthermore, we built Processors, as hybrid nodes, that mine new transactions and store the newest stack of transactions.
These clients, however, do not yet store the entire Merkle tree, for reasons of scalability and storage efficiency; they only store transactions in a recursive pyramid structure. This means that, over time, the density of storage decreases, so that a Processor stores merely block headers for older blocks. We sometimes refer to these processors also as ‘miners’.
“These benefits therefore also lead, depending on the use case, to more consensus networks in which the consensus is a more democratic process.”
Next to the new data and client structure, one of the main the technological features of XAIN is its consensus mechanism PPoKW. We refer to the Yellow Paper for an in-depth discussion of this mechanism and we only sketch the main idea here. First of all, a block is enriched with a seed Q, initialized with high entropy and recomputed for each new block as a deterministic digital signature of the seed from the previous block, signed by the leader of the next block. This seed is then used in a technique called Cryptographic Sortition — first proposed in the work around Algorand — which selects from the set of all nodes that are eligible to mine a random set of nodes with specified expected size, such that only these nodes will know that they are selection and where an attacker has no ability to compromise these nodes to influence their mining behavior — other than just trying to attack random nodes in the entire network. This means that resiliency to network attacks stays invariant even if the expected size of the committee is small, e.g. 20.
Moreover, this process of selecting committee members is integrated with a whitelist and other access-control mechanisms, without compromising the aforementioned invariance under scale. This approach, therefore, combines the advantages of scale invariance with those of energy-efficient mining, as nodes that are not selected into the committee for the next block can easily determine this and thus not waste energy on Proof of Work for the next block. These benefits therefore also lead, depending on the use case, to more consensus networks in which the consensus is a more democratic process.
Our pilot client is further enable by XAIN technology through its integration of the Ethereum Virtual Machine (EVM) and Solidity smart contracts with simple plug-ins for enterprise systems.
3. System Architecture: Vehicle Network and System Components
The pilot system comprises a variety of different network and system components that refer to the architecture diagram below. Inside the car, we run a single-board computer (SBC), which includes a XAIN Processor with the ability to process data (mining) and to store the most important information. Further, the SBC stores the car wallet with the encrypted private keys for signing transactions and for encrypting all communication via BLE, a BLE module as an implementation of the transaction protocol for communication with the smartphone, a Whisper module as a message protocol for secure transmission of encrypted vehicle data, an LTE module for communication between the Processor with the Blockchain network, and a CAN bus module as the interface between the SBC and the vehicle itself.
Subsequently, we implemented a smartphone app, which includes а digital wallet (HD Wallet) as an Initiator Client that comprises the encrypted private keys, necessary for signing transactions, for the encryption of the communication via BLE and for the encryption of the symmetric key of the vehicle data. This allows for all keys to be recovered via a mnemonic seed, thus if one loses the seed, all data is lost, which is a security and privacy requirement, especially considering GDPR. Moreover, the app comprises a BLE module for communicating with the car, plus a Web3 module for the communication between the app and the different XAIN clients (Processors or Dataloggers) and for requesting smart contract data or for sending signed transactions.
Last but not least, we implemented a network of multiple nodes on AWS with three different categories. Firstly, IPFS nodes, which store the encrypted vehicle data, transferred via Whisper. Secondly, Dataloggers that each contain the complete Merkle tree of the Blockchain as a security instance. These nodes are also used as so-called bootnodes for the hybrid nodes in the car. Thirdly, we also implemented a network of Processors (miners) on AWS that perform the mining process (PPoKW) and store less information over time (recursive pyramid data structure). The Processors can be removed at a later stage from AWS, once enough cars have running Processors installed and the network becomes large enough.
4. Smart Contract Architecture
The architecture of the pilot system is based on three main smart contracts (among others): UserRegister, UserHistory and VehicleState.
- UserRegister is just what the name says; it provides an overview of all users of the system. It allows queries as to whether an address represents a user and the possibility to exclude users from the system (ban from the whitelist). It also allows querying the address of a user’s UserHistory contract.
- UserHistory contains the hash values of the driver’s history (driving history). The actual records are encrypted on the distributed file system IPFS.The contract contains the addresses of the vehicles that are allowed to add entries in the driver’s history of the user. These vehicles are the “authorized cars” for this user. It is also possible to deposit access permissions that allow outside parties’ access to specific records.
- VehicleState represents the state of a vehicle. Mainly, this means an assignment to an owner, as well as a mapping of addresses to permissions. These permissions determine which specific users have rights to the vehicle. For example, when opening the doors, the trunk or starting the engine. These authorizations are not fixed but are represented by an identifier that is interpreted by the above-described application scenarios. Authorizations are always provided with an expiration date but can also be manually withdrawn at any time.
5. Access Control and Key Management
The figure below shows a different view of the system architecture, focusing on the management of access control and cryptographic keys. Essentially, access is granted when an appropriate and verifiable cryptographic credential is being presented that matches the request to the sought access, e.g. a specific action performed by the vehicle.
We follow best security practice by using different private/public key pairs for different intents of the same user (a smartphone, the SBC or other system agents). In particular, keys for symmetric encryption of payload data, such as the data generated by driving behavior, is encrypted with a private key dedicated for communicating such symmetric keys. Whereas the signature of transactions or messages is performed by another private key.
Certificates are generated by digital signatures that involve the use of standard hash functions, in this case SHA-3. Overall, the XAIN network and this pilot system is using established, tried and tested, cryptographic primitives — and in standard usage modes. We stay well clear from ‘rolling our own crypto’ to make our systems as secure as is possible by the state of the art in cryptography.
Our security protocols for key and message exchange, detailed in a subsequent section, adapt common protocol primitives and steps to the particular tasks at hand. For example, we reply on the generation of nonces (which is security-sensitive code that needs to guarantee that nonces never get regenerated, in particular that the state of that generator does not ‘flow over’ to an initial counting state).
Cryptographic credentials such as pubic keys are stored in smart contracts, this a register that functions as a secure public-key infrastructure that is resilient to adversarial manipulation to the same extent that smart contracts are resilient to unauthorized modifications.
The private keys for the wallet in a smartphone, that is the private keys that belong to a human agent who wishes to interact with the vehicle, are all determined by a mnemonic seed — giving us a good balance of security and usability, and also a sole and simple source whose destruction also ‘destroys’ (knowledge of) these private keys.
Join us next week, as we discover five more innovations made possible with the partnership of Porsche and XAIN!
Leif-Nissen Lundbæk is the Co-founder and CEO at XAIN AG and leads their cryptographic developments. For more information on the company XAIN and their eXpandable AI Network, you can find them on Twitter or at xain.io.