Dominic | Diode: Making IoT more SECURE with Blockchain | 2019-03-27

Everyone here today CEO of blockchain he will introduce a blockchain based approach enables devices to solve most of the shortcomments of [Applause] Okay, great. So, what we're trying to do is we we're trying to bring blockchains um to account for IoT devices. And really when you when you hear that, what you should think when you hear this first is you should think this like why why would you bring blockchain to IoT devices? you have these very small devices and there's a lot of complexity and like connecting to a blockchain like what's the reason and we would like to differentiate ourselves a bit from the when we look at blockchain and and IoT we our background is really being an IoT company so we have deep IoT products company Xite is doing that as a business I products and so we are from IoT moving into blockchain and we have very concrete certain problem that we want to solve with blockchain and this problem is called T P T P T P T P T P T P T P T P T P T Pis public key infrastructure. It is actually what protects most of the communication when you go to a website you have HTTPS and it protects the communication between you and the server between them.

Nobody can listen to them. Now this infrastructure is actually if you if you go into detail and that's what we want to do here has a certain couple of problems and some of these are much bigger on IoT devices than just in the browser. So if we want to look into that we have to go one step back and go back to 2010. 2010 was the first time was the very first time that traffic of the internet was redirected through the BGP routing protocol into China 50%. Now security analysts at that time assumed that this is basically a test whether they can do it and didn't know what would happen at this point.

Now afterwards the time between these kind of reop have become more and more common so they have been every Now they have more and more and it's not always China sometimes it's Russia sometimes it's Iran sometimes it's just some private group that does something for example this was 2017 or write a big report about that because they had to do something about this so what happens is that there basically on the TCP level there's a network traffic trying to go from A to B so in this case trying to go from Los Angeles to Washington and it's using the BGP protocol or protocol to identify the shortest routes. Now, unfortunately, some route just because this is a very democratic protocol can announce shorter routes even though they're not physically short, they can announce routes. So, that's what's happening is some routers announcer routes and so the packets decide, oh, actually the shortest route goes through China. Unfortunately, the colors from you cannot see China. This is China.

And he is mother. No, China. Let's go on. So you have imagine this. So if you see that well then the reaction should be well my I'm using TS I'm using so my traffic is being redirected to China and then it goes back so I'm safe right like there's they cannot encrypt it but you can also like ask the question so if they cannot encrypt this ever why are they doing it regularly right so there's some assumptions here that we rely on that are unfortunately not completely true and if you rely on assumptions that are not completely true, bad things happen.

So to understand what what the issue you see at hands, we have to dive a little bit deeper to PKI. So I mean you can always do that on like on your own computer anytime you check out you go to some website you check out the little secure it icon that you have on the upper corner go to your security details is for example some fires and you dig down what are the certificate details and what you will find is that there's somewhere a hierarchy certificate hierarchy that starts at a root certificate that's installed in your machine so it's living on your computer then the next one is an intermediate certificate that's living on your computer but it's signed by this by this group on your computer. The last one is the actual website. So what's happening is that we have when you register a domain for example there's a lot of private companies they can create certificates for you for example let's not they are an intermediate so any intermediates they can create domains and signatures for any domain on the so it's not by country or by company so or tww any intermediate and sign every the problem with that is is is twofold. So first is so there's only few intermediates right no there's actually quite a lot there's right now there's independent companies because there's no way to actually find out how many intermediates are you know the only way to find out is to check all websites and check like which intermediates are luckily there's companies who actually doing this this is from census for example and you can see that there's a setup here by you can see that Europe and United States have all of these certificates up here um Japan, China is Taiwan also actually also has quite some certificates and it goes on and there it's there like a couple of issues here at hand that are immediately obvious.

So first all of these are basically root keys right so all of these can create if you talk to google.com Facebook.com your private server everybody of these can create a certificate that truly seems to be that identity there's no way for you to prevent that it can even be for one identity compain many many certificates but there can be hundreds certificates there's no uniqueness to them and what you also will see is that a lot of these countries obviously have economically speaking very different interests and sometimes also economic conflicts and also when when you ask these countries they find it like every country that's not on this list that doesn't have a region always finds it very unfair to me Why are we the only ones not having like a root certificate in our country? Right? So there's a big governance problem and I find also personally I find it hard to say why why some countries are not allowed to have those happened.

Um when Netscape started introducing that system there was only like three certificates 1995 and the first Netscape browser that had now we have 3,600 and there's really a question like who gets to own the internet who gets to own all these root accesses. Um so now if you look into into that with browsers there's kind of the good news that browsers actually watch this. So actually Google has like active programs to watch this ask is somebody misusing certificates promise on IoT devices there's no nobody sim another problem is that with different browser manufacturers you have different rules set for example this one here is a revoke certificate and it's revoked in one of two methods you can revoke a certificate so you want to revoke a certificate for two reasons basically one is have a domain, you get a certificate for the domain, you sell the domain to somebody else and that somebody else wants to ensure you don't have a certificate, right? So, you revokes it. The other case, somebody steals your certificate while they own the domain and then you re it now depending on which method you use to revoke that either Google says it's still um or does I haven't tried on Safari.

You can you can try out on Safari, but the problem is that revocation is basically system even though it's quite designed there in multiple standards it's broken and if you use a like a lot lower than your browser into operating system or Linux or IoT devices you'll basically find it's never been used against stealing in place it's not another issue on top of that so we talk about two really big issues the third really big issue is time so if you do this little experiment um you put your time your clock forward by one hour or sorry by one year. So I put my clock forward to 2020 90% of the certificates will be considered invalid because all these certificates have validation periods. So now luckily your computer knows the time right and how does your computer know the time knows it from the internet right he gets it from the network but how does your computer know that the time he's getting from the network is real time and it's not effective but he's probably using certificates either he's doing that or he's using NTP or Minecraft he doesn't know so there's a chicken egg probably right so to know whether certificates valid you need to know the time to know whether the time is valid that you need to know whether it's in IoT. This is a you don't want to look at the code how they do it. They they either assume they the time is always the same time stamp or they say like if I get an invalid certificate it must be that I'm on the validity of that certificate.

So there there's a big issue here. Um I have this slide I don't want to go through all of that but this shows like just some examples recently of reroutes. So this reroutes that happen. So you can see it's China, it's Russia, it's Iran, but it's also happening more and more um within countries for example US and you can see some of the US politics about not liking your way around us is is coming from this because they're afraid that they cannot control anymore. So stuff like this happens when within the US traffic is being rerouted and now it's being rerouted to somewhere and they can't do something with the traffic there.

How can you avoid that? And the second part here that I have is examples of fake certificates. One that I wanted to highlight because it's really original attack was recently on the Brazilian bank. So what they did is they only have the DNS server. The DNS server was then pointing to a different domain and then they the hackers used that encrypt to get a valid certificate because that encrypt was just checking whether they control the domain.

They controlled the domain because of the DNS. So they got a valid certificate um that they shouldn't have but they have had it and then they could grab money from all the customers of the bank. They could grab all their credentials, all this information showing website. This is completely embedded certificate that they should have another and the only thing they had to break was a DNS. So this is very problematic and we want to we want to work on on solving this for IoT device because for them it's even twice as problematic because you don't have a human in front who can like check this and you don't have a browser in front who can like introduce additional logic to check this with a with a human for example in front of your notebook if your time is wrong on your notebook you will figure it out because you're human you send like the rest of the world but that was not so The reason why we want to ensure this is because this is actually the field to work in IoT and industrial IoT and fortunately or unfortunately you can you can see that both ways devices will be connected because it is possible to to connect them and that includes not only like your lamp at home with smart home devices but it also includes like really important infrastructure that's out there and it's being connected with what is considered standard security technology like TLS using PKI technology and if you if you do that we want to ensure that there's no unhappy surprises like if if there's no way to avoid these things to be connected we want to show that they're connected really really safely right so this is this is our our drive our motivation we want to change that we talked um about that I just want to summarize the four detail the four of the PK so we talked about the times chicken and egg you can't really figure out what the time is we talked about the consensus actually The problem in the Brazilian bank, the bank had a totally valid certificate that nobody had stolen.

The problem is the hackers also had a valid certificate, a different certificate. And as a user, you don't know that there too often. They're both totally valid and there's no ownership of these can anymore. Revocation basically doesn't work. Like if your certificate stolen, it's really problematic.

Every piece of software really differently to that. And lastly is governance. How do you want to solve this with all these politics, all these countries involved and having a system where every root key is a complete key for everything and how do you want to say like this country is allowed, this country is not allowed. How do you want to solve that? So we think each of these problems are really hard to solve and probably in the current environment not solve.

Now if you look at them and map them now over to to blockchain, you will actually see that the blockchain world by that they're actually very very easy to solve. So the the first the first one is time and more important than time the current state. So when we check the time we want actually to know what the current state is. So with blockchain if you establish consensus we establish the current state of the network that is actually all that blockchain is blockchain establish the state. This is what we want to do.

Um consensus in the way in terms of a single identity how can we ensure I know that in all the world that for this domain or for the server this is a true identity. There's no fake identity. So if we store something in a state on the blockchain and we store an identity there and have a mapping like this domain of the server belongs to this this identity it's very easy to to count that you see there it's one to one or maybe one to two but there can be no certain force randomly created by some third party certificate revocation because again we have blockchain especially with Ethereum where we have contract account that we can update. We can actually change whether this certificate should belong to this identity or not. So revocation actually part of the protocol by itself.

You don't need an external protocol. That's only half and lastly governance. So if we imagine we do set up this around blockchain and we look at that from a smart contract perspective, we actually when we create an environment block, we don't have to give everybody access. When you create bring your own devices online, you define your own fleet. You can define your own governance.

So as there's a lot of Ethereum contracts that use multisync and have multi patterns implemented or pattern implement the same you can do as soon as you're on the blockchain you can do governance your own governance structure defined in whatever way you need. So if you're for example a working directly for the government you can implement your regulation requirements as a smart contractor. Maybe there is an authority for you that needs to be able to look into it. You can define that, but you're not in a system anymore where there's all these groups and everybody can look into this stuff. So, it's a much better environment and it's like this not nothing new, right?

This is like what Ethereum blockchain actually brings by itself already. So, there's a couple of steps here to get there. So, we want to approach it in three steps. First, we replace PKI for that. We need a we also need a light client protocol for that.

Then we want to look at what decentralized IoT could actually look like. So after we can connect to our centralized server securely there's actually also options how we could um connect the devices between each other without centralized service security and then once we have done that we think that both pretty safe and there can be no infrastructure. So let's jump to the first thing here. So we look at some code just code example to understand a bit what's happening. So let's assume this is a really small embedded device.

So this is not it's not running Java VM doesn't have GB of RAM. It's very very small. So what it does today is it first needs to find out the time. If it's a a good device it will probably use NTP server. Simpler devices use just DHCP.

So they only ask the local network. Here we assume it asks actually a time server. So first it needs to do a DNS lookup. Unfortunately DNS if you don't use DNS sec no embedded devices using DNS is is completely unsecure. So whatever you send to it will trust that this is true.

Then it does an IP lookup and now does an NTP check. NTP is also totally unencrypted. So this information is to can be totally it's really easy. Put a router into a network. It sends wrong DNS.

It sends around time. It's very easy to trigger any device. So now the next thing let's assume this is a device like a typical embedded device. It has a central server that it wants to connect to this central server called it's on control on also here does a DNS lookup also that lookup is wrong to IP address and then finally it does connection with PKI and we run into all the troubles that we just talked about. So it's fake certificate.

It's maybe embedded certificate. Maybe it's an old certificate. That's for example like there's all this digital garbage that lost. So you can imagine there's like 3,600 certificates. That's the ones that are currently valid.

But if you go like back one back two years, three years there's all these certificates that are not validated. This is the digital garbage. Now digital garbage is much less well protected than currently digital goods. If you get any digital garbage, you you get somewhere like an invalid intermediate certificate and you are able to provide the wrong time to somebody you you get into. Now let's compare that with a blockchain based approach here.

So the first piece I made that I made that very easy. So we said we assuming we have a lifeline protocol and connected that to the blockchain. If you have a lifeline proed, you can obviously get the time stamp at least the time step time from the latest draw. I just wanted to point that out in fact we don't need the latest time because much better than the latest time is the latest state and so what this example is we have here a so instead of like a control name we have like a this is like an account contract what I want to do is in this account we have stored some state some variables and these variables like variables for example We want to look up from the device. So there's a a map.

We want to check in the map the value for the server. So what we do is we fetch the data from from the server including the bubble proof and we validate proof on that. The same we do for the signature and we receive two bits here or two pieces here. The real server IP address but much more signature. The signature is a certificate fingerprint in this simple example.

And now when we connect to our server, we can use this certificate fingerprint to ensure that this is exactly the one certificate that we want it to be. It's not a third party. It's not a man in the middle that all of these problems we all just to go a bit more into the details. So this is a really simple example just to explain the concept. Um we have this fleet contract.

So that's what we just talked to about this address. It has like a a map a map has it first variable so we know where to index it from the device. The device obviously needs to fetch a certain point in the state get the val and then we have a very simple function that only the the owner should be able to call should be able to set the server signatures. Now you can see that this is just a normal smart contract and you can replace that with any governance environment on any smart contract you you want to define yourself. Now this links to the state and then down here in our account we somewhere have the actual values and based on that device check it against the state and finally state check the state of the whole blockchain that state.

Um when we have done that then we basically live in our own defined governance structure and if you compare it directly to the old system of care. So we have here 3,600 certificate uh authorities all these intermediates if one of their keys is being stolen we are blasting right or also not only stolen but also if one of them decides to misuse their key for example we're also blasting because they can now go with the method that we just described here to actually crack the smart contract and do something that we have not planned to to be happening in the smart is the same as breaking into the blockchain itself. So to get this normal blockchain guarantee of you want to break the system you have to break the 51. Now we're making a jump from that to to step two. So we have established very secure connections to our servers and this is great because it's much more secure than what we can but also take that one step further because there is in fact a lot of use cases where stream a lot of data from device to device like from one line for example in security also or like traffic watching for example there's a lot of these cameras outside there and they want to stream the traffic to some endpoint that's consuming for example video data.

So if you stream that from a video camera to a to a smartphone you can go via a sensor circle or if you have a lifeline you can actually use already establish and that's the idea that we bring that we can use once we have established lifeline and have est to save the cost of going to a server. Um so the example here is very simple the device um now I'm talking about the IoT device that you imagine a smartphone on the protocol level of course also has the same kind of like so there's no difference just the difference in the use case they connect to hopefully the nearest and then in order to make this proof of concept work what's happening is this device is setting key value pairs into the into the network so this is transactions against against the virtual machine but this is using the network to actually put a piece of information in a certain place in the network. So actually is using so it's using the same this case it's using it own device ID to identify the location key there with a where is something connected to so this server it's connected to this local IP and then the signature from itself to ensure that this piece of information is actually from the device and not from somebody else and the client can do exactly the He does the same lookup because he knows he's looking for the device and fetch the data from there and then has everything he needs to either do direct connection. So if the direct connection is possible to the local he could just do that will be the most optimal maybe then the same networking or if the direct connection is not possible use the server A. Now he knows that the machine is so ser and to be able to proxy the connection what we're doing is we introduce something called ser service tickets which are not transactions but are level two abstraction talk.

So the idea here is that we are able to incentivize actually notes that that are in the network a to respond to the light to client protocol. So that's always a question like I I run a m I run a note on this network why should I allow a million IoT devices even to connect to me and consume my resources for PKI validation or something like what's what's the benefit of of doing that and also like with the extension traffic in the same way like why should I be a proxy for for data traffic why should I do that why don't I just mine so we're setting up an incentive here to do these kind of services and potentially more services in the future start connecting and then traffic in and we do that we go back to this contracts that we established earlier. So that's actually what the device is connected to. That's what it's using to catch the real data. But we associate to that contract also some value and that is some state value in another smart smart contract we call it registry.

And now when a server gets a connection from a device. The server can do this based on the device identity. It can check whether the corresponding fee contract has the value in the registry to provide an incentive to the minor to actually serve this device. The device will emit um transmission proofs and service proofs to the miner and the miner is then able to submit these service groups to the smart contract. So this all the tot minor it proof of work.

Yeah. Um it can be proof of work can also be can also be like a future iteration on that. So whether it's proof of work or proof of state it doesn't have um much much connection here. But what is really important is that we need to ensure that the incentives that the devices stay online for connectivity of the IoT devices and that there's a connection to the light protocol. So we're actually very curious about Ethereum too because it gets some some additional um entry points that are really important to make something like this possible.

But we talk about that in a second. So let's let's make a very simple example here. We have minor. So if you there's some incentive. What you want to do is if this incentive is enough, you want to accommodate as many device traffic and as many device connection as possible up to your capacity.

So let's assume we go we go down that route. So we have these devices, they all compete for connection to the nearest server. So you could imagine there's a server all these devices connect but there's just not enough capacity for these devices. Now the server can actually evaluate the different devices based on the state that is in this contract. So here we just use eight value points are being saved by the speed contract and so that is inherited to the devices.

So these each of the service units that are being generated correspond to a ratio to proportion of that. So if there's one for example a total of four service tickets here the yellow one then this would be 7 75% 25% meaning that this device basically has provided this consume this amount of service like the whole service that has consumed and that means that this device and also the service actually has a certain value the value it has to minor exactly proportional to the value contract. So we translate that least. So this device is most valuable because it has the biggest contract or because it has the least activity has not such a big contract but has very little activity and so it activity is more valuable and then we have devices that are less valuable. So as the server becomes full right we can imagine if the server has a low capacity watermark a new device comes in that has very has very high value yeah connect to me really happy to serve you putting it at the top of the st connected and serving devices but also now this device down here that is really not a lot it's running down into it low capacity at all so space again so the minor optimize is always for the highest revenue And so we get like a um a market where devices try to connect to the nearest devices, the nearest servers for lowest latencies and servers try to find the highest paying devices.

So devices get basically for higher state for high state better latencies better and that's projection. Now because we create all these service tickets, we need to talk about like how do we turn the service tickets at the end of the day into like a limited amount of transactions in Ethereum one or Ethereum two. So this is a layer two abstraction and we convert all of these millions of tickets into less much less transactions. This um the first piece here is that these uh service tickets don't have a double spend problem, right? So they're not a currency that you're spending.

They are always that into a portion when a device is sending a service ticket to a server. The important pieces here are like the current off what we call a building cycle. So that's one. Um the device ID itself, the node, the node it's talking to, like that's the server it's talking to. And then the types of um the types of service and how much of that service for example, connectivity service traffic.

We can count traffic. Every thousand bytes we count one chunk of traffic. And now if you have a lot of these tickets as a server, you don't need to keep all the tickets for a single device. You only need to keep the highest because it's the I send you a ticket approving I sent you that you transmitted for me one kilobyte of data and then it sends you much later I prove to you allow me to send 2 kilob you only have t actually the last ticket number and all the other tickets from before you can just drop them so that's a massive reduction in addition to that because there's actually a lot of these tickets what you can also And I don't want to talk about BLS too much because I think on it but you can actually use BS signatures to reduce the total weight important is that when the goal is here to reduce the total weight of like a C single ticket that you submit to the smart contract so that we can submit as many as possible of these tickets in a smart contract. So this calculation of roughly 27 points multiply that by 86 gas per so that we can get roughly 4,000 tickets maximiz 172,000 per month that means we can reach roughly 700 700 million active devices.

So that sounds first like a lot. Then we look at the growth that is expected for IoT devices and doesn't sound like a lot anymore. And so there's um there's a second step you can take and that is when you create when you have the concept of fleets, right? So that means there's some owner of the so if it's a very large for example it's like for example then it's a very large fleet with a single owner like the company actually this you have this It's a type of relay that takes these tickets and instead of having individual signatures for each of these tickets, it creates aggregate ticket that shows accounts and has a single signature but also has none of that is um a lot of these concepts are new but like from other concepts but they're being applied here specifically to it and this use Finally, we want to go into cont. So, I'm just going to go ahead.

Um, so let's look into how this actually could look like in a more realistic scenario. We talked about the fleet contracts and we talked about the the registry and like when we think of industrial IoT there's actually more complex companies multiple roles and we talk also about governance to show a bit more governance. So we have on the right hand side we have the fleet contract we really think of the fleet contract as everything that is operational in it. So this is very very technical control which server these devices should connect to which fingerprints or certificates are being accepted and that should be connected controlled by an operator. Now obviously you have this problem now if your operator has this team to make changes to the contract you might be worried that maybe in your building like in your office maybe somebody's breaking in right maybe somebody's stealing or fishing was doing something else bad to actually get this key and then the whole like everything I want before all the security what happens to that so governance is actually is actually a good thing and having authorities is actually a good thing as long as you can control who these authorities And this is what we enable here.

So you can have like the voting contract and you can pick any of the existing voting templates or define your own voting and governance structure. You find that not only you have access to the smart contract to issue changes that for example set but they there is a on top of you maybe three out of two out of three that can sign and help you to either recover access to it or remove your access or create new new keys to this. So the governance structure now is is in your hands. Also what to show here is that there's a split between accounting defining a state that you want to stract. You put that into the direct registry and actually the control of the contract because also that you want to split because otherwise this always becomes like a very interesting target attack target if there's what money like in the same key the same protection that is also um protecting.

So we split the money from the technical control these devices. Again, this is everything you can do using smart contracts and of course you can also do the same that you go right side you can also control here it's like es what we talked about summary of all of that. So we talked about um we need an algorith to um to connect our life and we're working on that looking actively for some reviews for that. We didn't talk about but we need that works together a little bit about service awareness. So that means the miners actually need to keep those connections open and they need to be incentivized to do so to to actually serve this network.

And that's why there's some service in one as well as some changes to like the block headers itself that we need uh to enable the light protocol and then everything else that we talked about here contract service that's all layers and constructs that happen in the contract service devices protocol and virtual and devices and that's really it. Thank you so much for for listening to this and if there's any questions we have jump back any questions on this makes sense. What's the service for? Where the service at this point? uh what's for what it's for is um it's for incentivizing the minor to actually serve the network.

So like this. So if um if you just let's assume you just set up a minus stake of system and um they just mine happily for their rewards and they can do that but they don't have any incentive to have these live clients connect to them like the light clients are not in our case here the lifelines are never submitting transactions right so there's no reward for having them connect to if it's just quite a mind stop. So the tickets are actually a rewarding mechanism for these nodes to let the lifelines connect and help them fetch data from the blockchain and make all of the good stuff they wanted to do about DKI for fetch this data. So so the device wants to signing signing the service tickets and then the nodes are sending the service tickets back to the registry. The registry is aware of the theme contracts that there's a connection between the feed contract and this device sign the ticket and then is reporting back the minus actually doing all of that.

That's the idea of the service because otherwise you could just like close this protocol again. Why why why would I do that right? A peer-to-peer network that you run for profit You want to always optimize for the profit. And so if you have like an open open port on the server that is not for profit just generating cost because somebody's catching data, you know, why why would you do that? The device uh the uh the device should buy the service ticket before and uh yeah.

So it's it's not the device. So it's a contract. team devices don't do transactions. They never do transaction. So the it's a fleet contract um actually having having so also certain tickets are not transactional but they're proportional so when you generate a lot a lot of because if they would be transactional we would need to solve the transaction problems like double spending.

So they here they're proportional. So every service ticket from different devices is basically proportional to the total amount. So if you have like service tickets like this is one kilobyte and then this is each like one kilobyte. So it's the same as one one service with 3 kilobyte then you have like a weight on these but it's not you can like a device doesn't have a limited amount of traffic can generate traffic generate more traffic but basically on this on this track there's a state so if you look from epoch to epoch what you could do as a min for example and see well there's there's a sleep contract inside that has a ton say like a ton of value in it. But these devices make so much traffic like all the time by just a hammer on the network that each kilobyte of this thread is actually not worth a lot.

So even though this is the biggest contract, I still prefer serving this one because um it's doing much less activity. So the activity has model this activity doesn't record and this proportion absolute is there to avoid the need for for double yeah is this whole structure visible for really usable IoT device for example sensors yeah uh we think I mean this all hinges on the the on the on the like the light plan, right? So this is what we what we designed that for. And so the the lifeline protocol is light enough that a smart small device can relatively quickly find out what the most recent block state is. Then then this this exactly what we're working on.

So we're working on publishing this uh this paper. This is actually one of the diagrams from here. So what we what we're doing is is basically a reputation based approach where we use the proving uh the content algorithm that is in place proof of work for example where what is happening here is um we have an IoT device that has been manufactured at some point in time let's say at manufacturing time it got like some block state that wasn't part of state might be three years old three years old might be a very old state but it got that programmed in now What this device it doesn't have anything else what it can do security is it can only look securely into the password so can connect to any server assuming it doesn't know anything else can ask the server can you give me previous blocks like old blocks that that were before it can validate that all these old blocks are true based on on the hashes and what it can do is um and this is a piece that we need to add in our case to the block it can find out who actually created these identify the uh identities of the miners based on today one doesn't have that. So that's why we have that two might have that. Yeah.

So, so this some you need to put several milestone. Sorry. You need to put some milestone. No, we don't need a milestone. We don't need milestone.

This is just like just saying like there's some point that the IoT device knows about. It's the random point at the point it was created. when you create the the device in the factory. So your heart uh like the first the first item that you know is like this and then the question the important part is when this for example is three years old how can you follow from there to right now right so how can you trace from whatever that was maybe three years ago maybe five years ago maybe one month ago that right now to right now what's safe right now how can you bridge that gap so we don't usually We make it a bit simpler to demonst you don't have to check from zero in our case because uh you probably are a bit further than zero today. If you would you just manufacture compile today we we hard code like the block maybe from yesterday.

So it's a kind of security that we know that is that is probably not broken with that. But let's assume this device go ships now out goes to goes to Costco. Maybe it's a washing machine on Costco. Nobody wants to buy it. Maybe it stays there for like two years.

Then somebody buys it, brings it home. Now the device needs to find out now what's the current block, right? What's the state right now? And so what it does there is if it only knows like the hash of one it first goes backwards right so that's not not very productive first but it goes backwards in order to create an app of where actually at this point in time the consensus group no matter really the consensus group is usually something use of state but we can also define consensus group for proof of work if he actually has digital signatures of who was the guy who created these props then we can imagine there's pie chart here. We can go forward backwards and check in the pie chart how many blocks say the last 100 blocks how many blocks were created by A, how many blocks were B, how many blocks by C and so on.

So we get a pie chart of distribution. If you look at like Ethereum scanner or like Bitcoin scanner, you know these these pie charts that show you actually miners and this kind is a distribution we we can fetch here securely based on this. Now what we do is we now have this knowledge and now we go incrementally forward. So now we ask for and we check we don't know E. We have never seen E in the past.

So we don't know if his law at least we don't know him but his block might still be fine. The way we assume it now is we only work on block. The way we check whether this block is fines, we go forward and look for further um blocks that are from the consensus group that we just have established from the past. And now as soon as so for example let's say B has like 20% and A has 25% and then C has 10% of our previous group. Now we So at this point we see B now okay B is 25% so B has like a truce value of 25% not enough so we go to A that's 20 20% now we have 45 still not enough we go to F now we don't know F so we go to C or C add another 10% now it's 55% now we know under this block not under this but this block we have 55% confirmation And now we basically do the same.

We update our little ratio table here that actually shows the consensus because now we have one more member that and we keep doing that forward. So that's the base concept and there's also a concept for short that because there might be like if you want to bridge you can like but that is that's the what we have working. So yes, this is designed for very very small devices at time and um doesn't need actually a lot of like a lot of complicated computations making like contrary to several device. Yeah. And uh it is possible to trans back to this device through the the free country because the free case should be readable for everyone.

Yeah. Yeah. Yeah. So I just think that if I can just back to this device actually I know where this device and all the information for this device. Yeah.

There's actually you can actually use different seams like to connect the the devices to the feed contract right and because like there there's a difference the important thing is that um when you have device ID or when you have the service ticket you need to be able to point to the feed uh contract right now the question is can I point back from the feed contract to the device so if you use a hash in between then you cannot because it's only one way you can prove I know this device that yes it's part of It's in this it's somewhere mentioned in the state but if I only have the hash I cannot find out what this original device ID was. There's a hash there. Yeah, you you can use a hash. What you can also use for example is um you can actually use a PKI hierarchy of of your own choosing and then you don't say I want to register all the devices like this individual entries like all the devices from this uh certificate that that I code in my smart contract plus for example. So this is this is for this is a template that we work on.

So because this is all contract space what what we are doing is defining a template like a standard contract policy that we we want to establish. But once you have the infrastructure, you can actually define any contract any for the devices. Yeah, the devices should basically when they try to connect similar like today like if you connect to nodes when they try to execute this this algorithm. So there's some some part of if if a node ever provides me with strong data obviously I I don't like that anymore so I don't connect to that but what devices should aim to optimize is for low latency. So they find that I need and that but that is like an incremental so it connects to some some node.

Now the device might have been transported from A to B, right? Maybe was manufactured in one country, was connected there for some time and was shipped to a different country was connected there. And so the way it try probes multiple servers during the like client execution during the validation. Um it also needs to check the the latencies and then prefer that server the latencies. So the last step here I didn't talk about it um but the last step is basically when you have made all of these connections when you have forward proof that is the last step is you need to connect to other servers other servers that are actually from the same consortium.

So you once you finish up you like you consume everything that the guy gave you. You just know whether the guy was a good guy or a bad guy, but at least all the blocks he gave you were valid blocks. You could you could follow up using this algorithm that it was always more than 51%. There's still the chance that he didn't give you all the blocks. He might try to keep you like that in the past.

Maybe he gave you all from one year ago. So what the final step you need to do is you look again at your pie chart and you connect to a couple of these guys that run your pie chart to ensure you're actually not only talking to this one guy gives you the blockchain from one year ago but you connect to all of these guys who actually are part of the group. You should they agree that this is the most recent block and there's not much while you do that you have to connect to that and you can you also check for the latencies to find like the in the end you want to strive to like the optimal nearest load might just be that because of the incentives the nearest load might not be interested in you so freaks you out because you're not paying so this is really a market market constraint where you have If you see there's a huge fleet in one in one location, huge device fleet with like big fleet contracts, there's an incentive for miners to put very very near loads there like basically on the edge to these devices. the nearer you get if you the nearest there the device will most fail and vice versa there's an incentive for the devices if you need like very low latency you need to get so sorry I didn't get the the miners get punished if they hit the device with wrong. There's no punishment inside here.

And the the thing with punishment is that you that you require transactions for like if the device create some creating some kind of proof, right, that data, then the device still needs a way to submit that to the real blockchain, right? So in any attack scenario, for example, like the attacks, for example, have been done on connected cars where you as soon as you catch up. So something that behaves like it's a cellular antenna, but it's not actually a real cellular antenna. So the device connects to it and now you are it's internet like everything it connects to is actually just your fake box, right? In that case, you cannot um transmit like a penalty or something.

So we don't have penalties in here. What happens is just the device can deterministic say well I'm seemingly not connected to the real thing. I just stop. I don't try to connect to my server because I cannot establish true school connection which is honestly in many cases when that happens if you're connected to a closed net only like to a fake router that's the best you can do just say like issue maybe you have a light and you can issue a warning you just have to stop connecting penalties question penalties are always making the system more much more difficult so it might be that penalties might make sense for optimizing but I generally think that the system should work out of incentives. Thank you very much.

I'm happy to just go much deeper and discuss anyway. [Applause]