IBM MTN Project

Transcript

[Music] all right uh thanks a lot for coming thanks a lot to Devcon for having me um first things first this is my understanding it's not the official IBM line and I'll be talking about the exploration project MTN it's not a product it's a research project and this is basically how it mostly

looks so the team MTM is uh sponsored by MC Divine who's the vice president for cloud Innovation at IBM and it's run by Egan Ford a distinguished engineer who's uh working 24/7 in the moment um pushing this and also pushing this within IBM that's that's the important part to understand there and uh with r lme um driving the bus and 12 Engineers that are working on this project I'm Henning d uh I'm a senior programmer at the blockchain group at IBM and I have prior experience for example in distributed databases which come in quite handy sometimes in this

particular field but also with high velocity and scalability as these problems are of course nothing new in the world of distributed databases so MTN is an acronym for multiplying things needlessly and uh this was a pun a little bit of how blockchain works and maybe it's not quite that needless right uh and it's really about Aon processing communication and coordination between the edge and the cloud so where we're at we saw this diagram before today even I think uh we're at at a historic explosion of calculation power of processing power

and this is of course driving the internet of things because more and more small devices are becoming more and more intelligent iot as a phomen is actually already here um there are huge success stories in the industry for example jet engines the way that they are checked every second and uh traced and tracked and uh the way that uh a new business model basically has evolved from the way that they are constantly online that is something that is a reality now there are also disappointments where for example in the consumer sector things didn't pick up the way that they might have been expected for example you would uh still not see too many uh TVs that actually

are used to uh use the internet with the motivation for MDM is that as more and more devices around us become more and more intelligent um the digital experience is going to be changing and more and more of these devices will be connected directly to each other peer-to-peer uh instead of to centralized Cloud just because they can so what's emerging there is uh has been called a devis democracy in the best case where the power in the internet of of things will actually shift from the center to the edge and while that

happens what can happen there is that a liquid Market can emerge where devices are dealing directly with each other and this will hopefully lead to products that we can't even imagine right now obviously to make that happen the blockchain can be a really strong component and uh the needs that we identify for this new world of device democracy are um to large degree exactly what what a blockchain can offer so if we look at the actual requirements and needs of the Internet of Things realm today we see a couple of roadblocks one of them is that the

architecture that we have today that's highly centralized won't necessarily scale over the next couple years we now have an internet of things that is uh having a certain topology and we will at any rate uh want to find a new way of connecting devices then these connections have to be maintained they have to be uphold and this is going to be creating some expense and somehow that has to be justified and it's not quite clear that the business business models that we have today are actually doing that what we also are going to realize is that um the internet of trust that we had some

decades ago without spamming everything is not a reality anymore we can be certain that any um system that we're deploying today is going to be attacked and his vulnerabilities are going to be exploited so security has a very high um priority right now we also won't have be seeing people accepting their toast or spying at them so that's another dimension of security where people will want to have some control over what the devices are doing and the way that for example the smartphone is completely owned by the um producer of the smartphone today is probably not how it's going to be continued now coming back to the toaster

people expect 20 years or more as a LIF span for a toaster if you have a centralist model with a toaster that's somehow useful because it's connected um then you have to maintain that for 20 years is that even viable or are people going to be very very frustrated with um producers going out of business which is kind of likely within 20 years not every company gets to 100 like IBM and then fin the business models that we're seeing today uh sorry uh the business models that we're seeing today are very much focus on information for advertisement and that is probably not

going to scale because there's only so much data that you can actually get out of a household and as more and more devices compete to collect the same data then probably the value of the data is going to go down so the motivation here is that when we see um uh the possibilities that we have here today can we have a userdefined algorithm can we have a customized experience that is not based on what we have in the moment and the iot today where we have uh new possibilities that are going to be used either for mischievous stuff if security is not high enough or for

exciting new stuff that we might not even imagine right now when we see at the bottom line though uh it's important to always remember that in the end it's about making the experience better it's not maybe worthwhile to have the toaster printing advertisement on your toast but you will want to have something that really makes sense and the whole on the whole what we are having today is the cloud as a centralized very powerful control mechanism so to say of devices that's less centralized than we had before but it's also not probably how it's going to stay when we going to more and more peer and peer

architectures that this kind of development is uh happening no matter whether you are Imagining the blockchain here or some other peer-to-peer mechanism that's that is pretty clear so if you look at this requirements what emerges as um basic foundation so to say has a very large overlap with what blockchain can offer and uh in this regard except for identity all three of the first all three bullet points over that are exactly what a blockchain can offer you you will have um a very interested interesting uh convergence here where you can see that ethereum for example is

uh implementing whisper now um there are efforts to uh create swarm that is going to add exactly um what is needed to have file transfer and messaging where uh fascinatingly in earlier Explorations that were done at IBM um Tash and bitter rent were used um that are now um or at least part of them part of uh whisper and swarm so the internet of things as it stands now is at probably 9 billion devices and what we thinking about and talking about is when it goes to 100 billion devices which is the future nobody might say exactly when it is maybe it's 2020 or 20 25 but it's going

to go there that's pretty clear and the mission that we put ourselves for MTN is analytics at the edge analytics at the edge means if you have a sensor that is picking up data then you might not be able to ship it fast enough to the cloud and have it analyzed with um high capacity computers but it's possible that this data has to be selected before it can even be shipped and it seems to be that in the moment 60% of all the data that is collected at the edge loses its value within milliseconds and so 90% of the data that is collected is never actually used and

this is what we wanted to address with the exploration MTN and what we used for that um and what we looked at here is how we can use um technical um behaviors that we see now that how we have real time processing at the edge and how we in the end um can have security containers in a hostile environment and how we have a bottom line that gives us better quality of experience hopefully so this is how it looks like this is a um software defined radio and it has 5 megabits a seconds of data that it

collects and that volume is enough that you cannot actually ship it from our experimental Raspberry Pi setup to uh a central Cloud to have it analyzed so what has to happen is um create an infrastructure so that we can use these little devices where we have raspberry pies that end points that are our sensors in this um exploration and these software um radio devices uh attached to them and then use um the plethora of data that's out there terabytes actually that you have access to this is the United States frequency allocation and zoom in into some frequency where we can find interesting data for example um we

have Smart Meters at some point we also have other stuff like aircraft radio navigation where you can track aircraft of course mobile and FM is taking up big swaths of this but um we are focusing on something simple and that is just the water and power meter output and this is how it actually looks if you read that out um interestingly in America there seems to be no protection at all you can read all the meters of all your neighbors in the moment um maybe that's not going to stay like that but uh for experimental purposes that uh may be quite interesting um you can also track flight data um that is is another possibility this is how this looks if you read it out of the uh radio frequencies so for our um experimental

setup we have a couple of personas here um we have the device itself that's the Raspberry Pi we have the device contract that is um the contracts that are actually that ethereum contracts that are actually entered in between the devices and a central token Bank contract we have the device registry that basically knows everything about all the devices in the system for our setup and then we have glansen which is a producer of Docker containers that are actually shipped out to the devices that those devices employ deploy and that are then having basically the entire logic that is needed to ship to make to enter into negotiations and to ship the data home to a consumer this is how um the

infrastructure looks um up on the top you have the uh raspberry pies um down here in the middle you have the um Contracting server that is the consumer of the data that actually is willing to pay for the data and wants the data to be to um to have the data delivered from the raspberry pies oops sorry oh sorry it's out of power for good somebody can help me I have one it's fine there's one on the ground ready plug in oh not okay

so the main aspect um what ethereum is actually used for and that's that's the important thing here because I I've often encountered the question why do you need blockchain for iot and the main aspect is really the negotiation to negotiate between devices and endpoints in an untrusted environment that is what we're using ethereum for and that is the whole mechanism of the devices offering their data the central consumer of the data accepting that offer um creating an escra where the uh the future payment is put uh for the devices then to ship the data um which is out of Bend uh and then and in the end to pay out of the ES

when the data has been shipped so and that is basically the main um point of the whole experiment to see whether that in a fashion that scales sufficiently um can actually be done using ethereum and at this point I would say um it is a success so this is how a proof of concept uh looked like it's actually emulated uh simulated we didn't have quite as many points there but we zeroed in on some that that were actually running then you could see what data um was actually there to and what connections were endpoints were actually there to be consumed you could have a device registration where a device can be

registered um so that it can be in take part in the marketplace we then have uh the view here of the blockchain how it looks when these devices actually starting to communicate with each other and and starting to enter contracts with each other and this is how um the actual flow within the different players in the system worked I I won't go through it step by step in the moment here but um it's just I you you're getting the idea it's it's quite straightforward actually and in the end this is the this was the bootstrapping flow actually to enter into the um to get a container to a device so the whole system can start

and this is the flow um when the container actually runs where you're um making a proposal and uh in the end the execution when it's done is wound down so there are a couple of risk and opportunities um that that are obvious I mean uh that we haven't looked into one is the question about a spot Market how can that look um what is not clear to us in the moment is how do you actually control access to the whole Market how to control access to the sensors it's basically out of the scope of the experimentation that we did but it's not

something um that we consider unsolvable um there's also the question how would actual vendors how would actually participants in such a Marketplace like to uh access and process and analyze and filter this kind of data and um what kind of arbitrary code can you allow in this this kind of environment um the next steps for us and it's it's still ongoing um what is what is happening there and again this is an internal experimentation so to say where that we use also um to convince people that this is uh the way to forward and we are looking uh where we're just hoping that

A Thin Client is going to be in the cards very soon to have a good um road towards scalability for this model where as far as I can see we are going to have not too many validators but a lot of thin cines and that would be a good answer to how this can scale um there should be some kind of an exchange and directory that we will uh look at how this could look where um the entire Marketplace can can be driven through um and then we're going to have a push uh internally to try to uh find 20,000 people um that are interested to sign up for this have raspberry ties connecting into the system and making a large scale real test testing the whole

ethereum installation um uh how fast it can really how how big it can really scale uh a big Thanks goes to the go team at this point and I've been asked specifically but even forward to extend that um Jeff Felix goph Victor uh you really helped us a lot I hope we also were able to contribute because we actually did ran some large scale tests with hundreds of devices or at least 100 devices uh running through containers running unusual devices like arms um raspberry pies who are slower and might have different kinds of race conditions as a result and uh we ran into a bug here and there and it was just amazing how this week uh we've been able to work together and and fix the stuff the IBM

guys were very tired and overworked so they were grumpy and brief sometimes um but it was great support that came from here and big thanks for that so thank you [Applause]