 I'll pass you over to Robin Skirch, who will begin his presentation. Thank you, Robin. Thank you, Maurice, for inviting us this evening. Thank you all for turning out on a rather miserable day. I'd like to talk about the same and come to our work for, particularly an interesting project we've been working on. So what I would like to talk about is just a quick introduction. We're going to see a video about a pilot project that we did for Porsche. Then I'm going to tell you a little bit about the technology that we do at today, particularly about our consensus mechanism, and then I'll explain how that technology has been used in the Porsche project. So we'll hopefully have the video now. Thank you, and thank you to Jesse for managing to balance the laptop on the microphone and get the sound working. It's fantastic. So to talk a little bit about our origins. My origins, five years ago, I was a developer working on financial software in the city of London. I had some interest in blockchain. I managed to mine about half a bitcoin. But I didn't know very much about cars. I didn't own a car. I then decided when Ethereum came out, I got very excited about this, very interested in the potential that Ethereum had. I moved to Oxford and was studying at Oxford University. By chance, I met Leif Lundbach, who is the founder of Zane, a CEO. He was doing some research looking at consensus mechanisms, particularly the mathematics behind optimizing these, depending on various conditions. I was very lucky when he decided to open his office in Berlin here that he asked me to join and head up the blockchain team. Thanks. Thank you. So that was February 2017. We incorporated here. A lot of the people who started Zane had a background in the automotive industry. So it was easy for us to work with companies like Daimler. And then what this talk is mainly about was the results of a competition that happened last summer. So Porsche decided to hold a competition to start a pilot project for companies who had started a project on the blockchain forum. I'm glad to say that out of over 120 applicants, we won that competition to start a project. And these were the broad aims that they had for what they wanted from that project. So you'll have seen in the video a lot of the functionality that they wanted. Locking and unlocking the car, allowing other people to access the car, allowing somebody to deliver packages to the boot, but also recording traffic data, which is going to be very important for automotive company to see how the cars are being driven. But as always with blockchain applications, but particularly when you're talking about a luxury item like a Porsche, you want to have a great focus on safety. And you want to be sure that you understand who is driving your car at any time. This presented some challenges, of course. So we only had three months in which to do the project, which is a very short time for any type of project. We had to really build a lot of the hardware or use custom hardware in different ways. None of this had been done before. We were trying to interface to the car system, so this is very low-level systems work, which we had to understand how to do this from scratch. And we were trying to control the vehicle from a smartwatch or a mobile phone using Bluetooth and Bluetooth Low Energy. The version we used wasn't encrypted. The messages were not being encrypted, so we had to develop our own encryption layer on top of that. And also, there are limits on the volume of data that you can transfer. So that was another challenge. And finally, a general challenge to all blockchain systems I think is going to be the question of privacy and compliance with GDPR. So we wanted to record data about the people driving the car, but we had to be very careful about whether that data could be seen as personal or not and how we were going to store that and how we were going to comply with these regulations. So, given that those were the challenges and the aims of our project, how did we use the technology that we had to overcome those challenges? So I'll tell you a little bit now about the technology today and about our consensus mechanism. So you had a good introduction there about consensus mechanisms and particularly proof of work. So we have a two-stage mechanism. So we start with this. This is talking about a private network, actually. So we may be moving to a public network, but we're talking about work on a private network here. And we have a number of nodes that are white-listed. So these are ones that are allowed to participate in the mining process. From that white-listed set of nodes, we produce a committee. And we do this via a process called cryptographic sortition. And the committee, the size of that set on the committee is much smaller than their set of all of the nodes. And that committee then runs proof of work to choose a leader who is then allowed to mine a block. Now, because the size of the committee is quite small, we can have a very low difficulty. We end up doing a lot less computation than we would if you were doing just a pure proof of work system. How we do this, how we select the committee is very interesting, and we use some ideas from Algorand for this. And it's basically relying on two aspects. So we have some data that is public and some that is private. The public data is a seed that is in every block and we have a function that creates a new seed from the seed in the previous block. So that is public. Everybody can see that. Then we mix in with that some private data. So that is the private key of the nodes participating in the network. And the way we do this is we have a verified random function based on the seed. This is all public still. And then we put that along with the private key of a node into a sortition function. The output of that function is a decision whether that node is accepted to be on the committee for that block. So if you look at the first block here, block number four, we've taken the seed, we've worked out our VRF, put that into a sortition function, and two of the nodes on the left have been chosen to be part of the network. Now, they know they're going to... Sorry, part of the committee. They know they will be part of the committee, but no other nodes would know that. The third node there is not part of the committee. The benefit of this is that if you're attacking the system and you would like to take over the committee, you will not know which nodes will be chosen for that committee at any particular block. So if you want to take over the committee, you would have to attack all of the nodes that are part of the white list. Okay. Mathematically, this is a simplified version, but the seed is chosen based on the seed in the previous block. So R here is the block height, and we're just taking a signature of the previous block to produce the next seed. So that's quite simple. The sortition function itself is a little more complex. I'll just go through it very quickly. The part on the right-hand side, this is a ratio. So the value n there is the target size of the committee that we want, and the number underneath, that is the size of the total number of nodes in the network that are white listed. So we're using that ratio to then decide which nodes will be chosen. We do that by the left-hand side. So far, we've had all public information. On the left-hand side, we take, again, some more public information, the block height, the seed. We do something private now. So we take the signature of that information based on the signature of a private key for a particular node. So then that is the private information. That gets put into a hash and put into a decimal. So there comes a number between zero and one. If that number is less than the ratio, then you'll be chosen for the committee. Otherwise, you're not in the committee. So quite a simple computation, not computationally expensive. Okay. So in order to do all this, we decided we would take a fork of the Go Ethereum client. We did this after the Byzantium hard fork. And to the vanilla client, we added some extra features. So we added our consensus mechanism. We also could reduce the size of the dataset that is used for the proof-of-work hash. We reduced that down to 64 megabytes from a gigabyte. So this is then much easier to use on devices that are constrained in terms of resources. We also had to do something because we were primarily working on private networks here. And that is that there's a problem that if you have a private network, there is less incentive to act honestly. And it's possible that if there was a miner who had been removed from the whitelisted set of nodes, he might try to impersonate one of the approved set of nodes. So he might send out a block pretending that that block came from a miner that had been whitelisted. So to prevent that, we make sure that the miners sign the block when they are produced and then this can be checked by all the nodes that accept that block. If you are familiar with setting up a private network on Ethereum and starting a Genesis block, you will perhaps recognize the conflict file for that, so I'm sorry it's probably hard to see at the back there. But basically just the part I wanted to show is that we added some extra contracts into the Genesis block and these are there providing our access control layer. So these contracts are then available for every client and they are used then to whitelist nodes, remove nodes if they haven't been misbehaving. Now to talk about the project itself, we collaborated with a couple of teams as well as Porsche themselves. We worked with the Porsche Digital Lab in Berlin and SpinLab from Leipzig and Accelerator. I should say at this point that although I was involved doing some of the architecture and setting up some of the infrastructure for this project, most of the hard work was done by my colleagues and I should credit them for that. Some of them are here this evening, so I'd like to thank them for that. The system architecture itself, so basically we have some, this could be a mobile device or maybe a smartwatch that has a Bluetooth module that then can connect to the device that we have in the car. We can also connect via Web3 to our Zane network. So here you have some full clients that are on AWS, for example. We also have that then connected to myPFS nodes because we're going to collect data and store that on IPFS. And initially we would also have some extra processor clients, some extra mining because until the vehicle network has reached a critical size, we want to make sure we have sufficient hash power. In the vehicle itself, and I'm sorry this hasn't come out very well on this thing, but we have a Bluetooth module that is accepting transactions from our mobile client. This is talking to a node running in the vehicle that is then talking to the rest of our Zane network. We also have a module that is running whisper, so we're going to send the data that we're collecting via the whisper protocol back to our blockchain and get that stored in IPFS. And then these are connected to a canvas module, so this is the module that connects to the canvas in the car and this is how we interact with the in-car systems. So this acts in two ways, both to record data from the car and also to allow us to perform actions, so to allow the door to be unlocked or the boot to be opened. So for this next slide, I won't go into a huge amount of detail because there are a lot of keys on there. This was just to show you a little bit about how we're approaching the permissioning. So it really is very straightforward. It's very typical of the ideas you're usually using cryptography. We have probably private key pairs generated on our mobile devices and in the vehicle, and this allows them to verify the identity of each other and we use announcers to make sure that we don't get any replay attacks. We also have some symmetric keys in the vehicle that are then used to sign data that will then go into IPFS. So this is the driving data that we're collecting. And then we have some smart contracts and these are holding, for example, a key from the mobile device that is then associated with an Ethereum address. So this is how we keep track of an address associated with a mobile device. Since we did that, we also have another way now that we're thinking of using to simplify key management and that is proxy re-encryption. So I'll just mention this technology briefly, but it is very useful. So the idea behind this is that we have Alice and Bob who you met one half of the partnership in the previous talk. Alice here is going to sign some text and so say this is some data that she has perhaps relating to the driving behaviour or perhaps relating to her ownership of the car and how it has been serviced. She signs this, encrypts it with her public key and so it becomes ciphertext. So at this point, she can decrypt this data, which is fine for her. She knows it's safe, she has control over it, but obviously it's not very useful. She wants to be able to give access to that data to other people. In particular here, she wants to give access to this to Bob. And so the way we do this with proxy re-encryption is that she creates a re-encryption key. To do this, she uses her private key and the public key of Bob. And with this, she can then sign the already encrypted text with this proxy re-encryption key, so that gets re-encrypted into the state that you see on the right. So at no point here does she have to reveal her private key or does she have to reveal the clear text that she had initially. So once she's re-encrypted it with this key that is specific to Bob, then he can decrypt that final data with his private key. So this is the means by which Alice can allow Bob to see, to decrypt this data, to see the data in clear text. And the proxy part there is used that you can set up proxy nodes so that Alice does not have to be online to do all of this. She can grant access to the keys via the proxy. And Bob can go to the proxy to get the keys. Okay. Just look at the hardware. This photo hasn't come out great, but we also used a Raspberry Pi here. We customized heavily. Anyway, we're doing the project initially. So we used the top-of-the-range Pi at the time. A very standard thing. So it's had one gig of RAM. So you can run standard Ethereum node on this without too much trouble. Now we're moving to getting our systems onto much smaller devices and devices that are far more constrained. We did have the problem that we were customizing this by adding what's called HATs to the Pi, the Pi HATs. We had a problem that we didn't have enough pins for this so we had to be careful how we juggled the pin allocation. And then on the software side, on Ethereum, we developed a number of smart contracts and libraries. The contracts would hold the car state so whether the car was unlocked or not and the permissions that the car was using who would be allowed to access it at what time, for example. We have a contract that allows users to register on the system and register their key and then get an Ethereum address from that. And also we have the user history so that shows what that user has been doing who has been accessing their car, for example. Porsche wanted to record certain pieces of data. This is just a small set of what they would ideally like. And this is, I guess, fairly standard. It was the sort of thing you would expect. So location, speed, fuel level, mileage, also outside temperature. And obviously you need to know what the weather is, whether the driving conditions are going to need to change because of that. So this is the data that we took and would then be passed on to IPFS. And we have a nice little front end to show this data and again sadly it hasn't come out very well. The top part had a map that showed the route that the car was taking as it was driving that we collected from the data we had collected. The bottom graph is a chart showing the speed of the car versus the fuel level in the tank. So that was the basic project that we had but of course that was just the basic thing and since we have completed that project obviously we can then expand and build on that. So now we are looking along with our AI team at Distribution Machine Learning for autonomous driving. So if you are looking at autonomous driving this is often trained in very constrained environments so you do this in Silicon Valley or in a city where the roads are well defined and you have very nice road signs. But that is not the whole picture and if you want to then take your car to somewhere, say a rural setting or somewhere that has very badly bad roads your car will perhaps not perform so well. So our idea is that we will get the cars to train in whatever setting they are in and then because they are connected via a blockchain they can securely pass that training data around to each other and each car can then benefit from the experience of every other car in the network and that is what is happening on the data that every other car has gained. The second thing that we can build upon is integrating with third party systems so as you saw in the video we could collect packages from say DHL and have them delivered to your car but also we could work with insurance providers so they could be giving you a better insurance rate because they can see the driving data that has been collected for you except that you are a safer driver. So in summary I would just like to say this is a very exciting and interesting project of course initially because it is great fun hacking something like this beautiful car. Also I was very privileged to work with some very talented people so I am very grateful to all of those, this is some of our team. That is it, thank you for your attention if you would like to contact us we would love to hear from you in what you have heard about this project or you would like to talk to us generally about what we have been doing you can contact us as these addresses but also we have a couple of developers here in the audience you can come talk to me, I can talk to Jesse, our marketing manager at the end and finally thank you for your attention I have time for a couple of questions what is it? I think he was just asking for the limits that we were using on the private network so I think we just use the standard one from the Ethereum of the time so the 6 meg gas whatever. Thanks for the talk I was wondering do you need the cars to be online for the consensus to work? Okay so a very important point that I completely forgot to mention was the offline mode so of course this is going to be important for you if you go on vacation you go somewhere remote and you get out of your car you don't want your car to then be locked and unable to be accessed because you are no longer connected to the internet so we have an offline mode as well so the idea is the connection to the car from your device via Bluetooth which you will always be able to do and then the permissions that your car will use if possible it will go to the internet and download and get the latest permissions into the contract but if it can't connect to the internet it will just use the permissions that it had and then also we have a timeout so that if after a certain time it cannot connect and cannot get more permissions it will then not allow access to say third party people but it will always allow access to the owner so yeah there is definitely an offline mode so for the consensus itself that is part of the way the committee works it is probabilistic so we give a target size for the committee and then obviously if some of those are missing they won't be able to do proof of work but if you have a perception of large target size then that will be fine I think you were first why would you need proof of work at all because you have a predetermined list of white listed nodes in the network and so can you just set the difficulty to zero okay so the question is why do we need proof of work at all yeah so a couple reasons first why we need proof of work is very well understood mathematically you can reason about it it's a very good system from that point of view if we just use say the sortition and just worked out the committee we would still have to find one leader from that and so trying to get the committee size of one each time would be virtually impossible what you're saying perhaps that I think is would we do something more like proof of authority where we just white listed some nodes around robbing amongst those well we're not although we do have these white listed nodes we do not necessarily trust them it is possible there could be malicious behavior so we still want the option to be able to remove minus from that white list so it's possible there will be minus that will be removed from the list and we'll no longer be able to partake because there's been malicious behavior even though it's a private network we can still get the possibility of attacks from internal attacks so we still want to take account of that and this is already solved by the white list of nodes so it's really just to get a leader out of our committee that we do then the proof of work and then we can do it in a fair enough random fashion I think this goes next my question was really related to IPFS and I was wondering why decided to use that rather than a more traditional centralized database like for example if you had IPFS nodes running on the cars and also what challenges that poses once you want to query that data compared to other okay so yeah so why are we using IPFS we wanted a decentralized system and it's the IPFS and Ethereum pattern is one that is quite well established I think and quite like so we wanted to use that and the nodes on the cars well yeah so there we're still passing it back to IPFS nodes in the cloud at this point because we can have a large amount of data the problems that we have with that are probably around privacy so we have to be careful that we anonymize the data sufficiently and we have it sufficiently encrypted so other people cannot read this data two more questions yeah yeah one of these two whichever for the data privacy law requirements how do you work around the new right to forget data okay so this is obviously a big problem for blockchains where data is meant to be immutable so why we do that so if we're dealing with encryption and IPFS we can effectively decide to remove data from IPFS by allowing it to be garbage collected and then making sure it hasn't been pinned on any node but then because we have it encrypted and we can hold keys if we're using the key management that I was the re-encryption key management because we hold those keys we can also burn those keys so not only have we decided that the data has gone but we can also remove the encryption key for that data that's the best way we thought of yeah I think okay I think this guy was next no well I was wondering why you didn't choose to use an existing business portfolio of consensus mechanism like PBFT for example yeah so this really came out of the research that Life had done our founder had done originally so he had been looking at various PBFT systems and found that they just were not secure enough so he wanted the security of something like proof of work but then something that was much more energy efficient so that's why we took the combination of the two and he found that he could easily hack into into this and do malicious things and overcome them I mean yeah okay so thank you very much