# XAIN's energy-efficient consensus mechanism PoKW implemented in a Porsche Panamera - Laurence Kirk - Speakers: [Laurence Kirk](https://streameth.org/speakers/laurence-kirk) - Channel: [Devcon](https://streameth.org/devcon) - Date: 2018-10-07 - Duration: 30:58 - Watch: https://streameth.org/watch/yt-Q432aALiIH8 - YouTube: https://www.youtube.com/watch?v=Q432aALiIH8 ## Description Recording by Livepeer.tv ## Transcript that's your bar to Romans we're beginning this presentation okay Thank You Horace for inviting us this evening thank you all for turning out on a rather miserable day I'd like to talk about saying I can now work for and particularly an interesting project we've been working on so what I would like to talk about is this a quick introduction we're going to see a video about it's a pilot project that we did for Porsche then I'm going to tell you a little bit about the technology that we do it's a 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 [Applause] [Music] [Applause] [Music] [Applause] [Applause] [Music] [Applause] okay thank you can't hear to Jessie her managing to policy laptop on the microphone and get the sound working okay okay so to talk a little bit about our origins so my origins are five years ago I was a developer i working on financial software and the City of London I had some interesting 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 when a theorem came out I got very excited about this very interested in the potential and etherium heard I moved to Oxford and was studying at Oxford University and by chance I met a life limp back who is the founder of saying CEO and he was doing some research looking at consensus mechanisms and particularly the mathematics behind optimizing these depending on various conditions and I was very lucky that when he decided to open his office in Berlin here that he asked me to join and head up the blockchain team thank you okay so that was February 2017 we incorporated here a lot of the people who started saying had a background in the automotive industry so it was easy for us to work with companies like Daimler and then in what's this talk is Graeme 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 would I start a project on the blockchain for them I'm glad to say that I have over a hundred and twenty applicants we run that competition to start a project and these were the broad aims that they had of 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 also that's going to be very important for an automotive company to see how the cars are being driven but those always with blocking 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 and one of this was hadn't 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 work out how to do this from scratch and we were trying to trend we were trying to control the vehicle from a SmartWatch or a mobile phone using bluetooth and Bluetooth Low Energy and the version we used wasn't encrypted the messages were not being encrypted so he has to we had to develop her own encryption layer on top of that and also there are limits on the volume of data that you can transfer so there 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 GD P R so we wanted to record data about the people driving the car we had to be very careful about the weather that data was could be seen as personal or not and how we were going to store that and how we're going to comply with these regulations so given that those with 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 at Seine and that's our consensus mechanism so you had a good introduction there about consent some mechanisms and particular proof of work so we have a two-stage mechanism so now we start with this this is talking about a a private network actually so we may be moving to a public network where this is we're talking about you work on a private network here and we have a number of nodes that are whitelisted so these are ones that are allowed to participate in the mining process from that one listed set of nodes we produce a committee and we do this via a process called cryptographic sortition and the committee the size of the that set of Almaty is much smaller than their set of all the nodes and that committee then runs proof of work to choose a leader who is then allowed to mine a block now because that 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 our grant for this and it's basically relying on two aspects so we have some data that is public and some what is private the public data is a seed that is in every block and is we have a function that creates a new seed from the seed in the previous block and I just said 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 saw tition function the outputs of that function is a decision whether that node he's accepted to be on the committee for that block so if we look at the first block here block number four we've taken the seed we've worked out our vrf put that into a sought ition function and two of the nodes on the left have been chosen to be part of the network now they know they're going part of the committee they know they will be part of the committee 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 this 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 whitelist 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 pot on the right hand side this is a ratio so the value and 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 now that's a whitelisted so we're using that ratio to then decide which nodes will be chosen well we do that by the left-hand side so 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 the we do something private now so we take this signature of that's information based on these the signature of a private key for a particular node so then that elisa private information that gets put into a hash and put into a decimal so there comes a number between 0 & 1 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 ok so in order to do all this we decided we would have to we would take a fork of the go aetherium client we did this after the Byzantium hard fork and to be to the vanilla client we added some extra features so we added our consensus mechanism we also could reduce the size of the the data set that is used for the proof-of-work hash we reduce around 64 megabytes from a gigabyte so this is much 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 in a private network there is less incentive to act honestly and it's possible that if there was a miner who was 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 wide listed so to prevent that we make sure that the miners signed the block when they are produced and then this can be checked by all the nodes that accept that look ok if you are familiar with setting up a a private network on ethereum and starting on Genesis block you will perhaps recognize the config file for that so I'm sorry is pretty 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 they're providing our access control layer so these contracts are then available for every client and they are used then to whitelist know to remove nodes if they haven't been misbehaving now to talk about the the project itself we collaborated with a couple of teams as well as Porsche themselves we worked with the portrait digital lab in Berlin and spin lab from Leipzig an 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 so there's some of them are here this evening so it's like the thing for that okay the system architecture itself so basically we have some divide this could be a mobile device or maybe a SmartWatch that has a Bluetooth module that can connect to the device that we have in the car you can also connect via web three to our Zain network so here you have some four clients that are when I'm AWS for example we also have not that connected so my PFS knows because we're going to collect data and store that in ipfs and additionally we will also have some extra processor clients and extra mining because we are until their vehicle not to work has reached a critical size we want to make sure we have sufficient hash power in the vehicle itself that 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 same network we also have a module that is running whisperer so we're going to send the data that we're collecting via the whisperer protocol back to our blockchain and get that stored in I appear first and then these are connected to a canvas module so this is the module that connects the canvas in the car and this is how we interact with the in-car systems so this sucks 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 boots 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 the how we are approaching the permissioning and so it really is very very straightforward it's very typical of the ideas usually using cryptography we have public/private key pairs that are generated on mobile devices and in the vehicle and this allows them to verify the identity of each other and we use in answers to make sure that we don't use any replay attacks we also have some symmetric trees in the vehicle that are then used to sign data that it will then go into ipfs so this is the driving data and 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 aetherium address so this is how we keep track of an address associated with a mobile device but since we did that we also have another way now that we are thinking of using for to simplify key management and that is proxy re encryption so I just mentioned this this technology briefly but it is very useful so the idea behind this is that we have niacin Bob for you where you measure one half of the partnership ur in the previous talk now this here is going to sign some text and she 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 sighs this encrypts it with a public key and so it becomes ciphertext so that this point every she can decrypt this data which is fine for her she knows is 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 and in particular here which is wants to give access to this to Bob and so the way we do this with proxy encryption is that she creates a rien Krypton 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 encryption key so that gets rien to the this later you see on the right so 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 rien crypted with this key that is specific to Bob then he can decrypt that final data with his private key so here's the means by which Alice can allow Bob to see to decrypt this data and 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 and go to the proxy to get the keys okay just look at the hardware this isn't what hasn't come out great but we also used a Raspberry Pi here manage your customized heavily now anyway didn't take the project initially so we used a the top-of-the-range pi at the time very standard things so it had one gig of ram so you can run standard aetherium 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 adding what's called hats to the pie the pie hats and we had a problem that we didn't have enough pens for this so we had to be careful how he juggled that's the pin allocation and then only on the software side on a theorem we've 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 their car was using who will be allowed to access it at what time example allow we have a contract that allows users to register on the system and register their key and then get an ethereal dress 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 the what they would do ideally like and this s fairly standard it was the sort of thing you would expect so location speed fuel level mileage also outside temperature and obviously they do need to know what their personal weather is whether the driving conditions are going to need to change because of that so this is the data that we took 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 shows had a map that showed the route that the car was taking as it was driving then we collected from the data we've collected the bottom graph is a chart showing the speed of the car versus the fuel level in the tank okay so that was the 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're looking along with our AI team that's distribution machine learning for autonomous driving so if you're looking at something almost driving these are generally this is often trained in very constrained environments so you'd 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 those it's a rural setting or somewhere that has very badly bad roads you'll know Carlin profs 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 blockchain they can securely pass that training data around to each other and the each car can lend benefit from the experience of every other car in a network by retraining on the data that every other car has has gained the second thing that we can develop 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 and we'll be happy to accept that you're a safer driver okay so in summary I just like to say this is a very exciting and interesting project of course initially because it's great fun hacking something like this beautiful car also I was very privileged to work with some very talented people so I'm very grateful to all of those this is some of our team that's it I'm thank you for your attention if you would like to contact us we'd love to hear from you if you are interested in what you've which you heard about this project or you'd like to talk to us generally and avoid what we've been doing you can contact us as these addresses but also we have a couple developers here in the audience you can come talk to me I could talk to Jesse our marketing manager at the end and finally yeah thank you for your attention I prep time for a couple of questions yep what I think it was justice yes there's nothing for the the limits that we were using on a private network so I think we just use a standard one from the theorem at the time yeah so they six six might guess whatever you like the thing thanks for going I was wondering do you need to cast me on live 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 you've gone for keishon 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're no longer connect to the internet so we have an offline mode as well so the idea is the connection to the car from your device is by a 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 get the latest permissions into the contract but if it can't connect to the internet you 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's definitely not line mode yeah so for the Consensus itself that as part of the way the committee works this is probabilistic so we get 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 Pacific enlarge target size then that would be fine I think you were first so what would you need to work because you have a predetermined list of white listed nodes in the network and so can you just difficulty to zero okay so question is why do we need proof a book at all yeah so um a couple reasons first of all me proof of work and is very well understood mathematically you can reason about it is a very good regular system from that point of view and if we just use say the sortition and just to 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 and what you're saying perhaps that I think is it would reduce something more like proof of authority where we just wireless or some nodes and we did around robbing amongst those well no we not although we do have these white list of nodes we do not necessarily cross them it is possible there could be malicious behavior so we still want the option to be able to remove - from that white list so it's possible that there will be - that will be removed from the list and will no longer be able to partake and because of there's been malicious behavior even there's a private network on the moon we can still get the possibility of attacks from internal internal attacks so we still want to take account of that this is already soft but white mr. gross right so just to get a leader act of our committee that as we do we do then the proof of work and that we can do is you know fair enough a random fashion god thanks guys next my question was related to IGFs and i was wondering why he decided to use that rather than a more like traditional centralized database like for example if you had like a TFS nodes running on the ties and also what challenges that poses once you want to query the data okay so yeah so while we're using my PFS we want to do this centralized system and it's the ipfs and etherium pattern is one that is quite well established I think and quite quite like so we wanted to use that then the nodes on the cars well yeah so very 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 that we have it sufficiently encrypted so it's other people cannot gonna read this data two more questions yeah yeah privacy law requirements how do you work around the the new right to forget data okay so this is obviously a big problem for blockchains where data is meant to be immutable so we do that so if we're dealing with encryption and ipfs we can effectively decide to remove data from ipfs by allowance of 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 really manage meant because we hold those keys we can also burn those keys so not only have we decided the data is gone we can also remember the encryption key for their data that's the best way we thought off now I think okay I think this guy was next existing consensus mechanism or something yeah so this really came out of the research that life had done my founder had done originally and 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 with then something that was much more energy efficient so that's why we took that the combination of the two he found that he could easily hack into the into this and do malicious things overcome them I mean okay [Applause]