 1700, we're in Switzerland, so I'll try to start on time. It's already getting dark outside. I hope you still spared a little of your attention span for our presentation here, because of course we're going to tell you something exciting. What we want to show you here is an approach how to give IoT devices identities on the hyperledger fabric, and in particular, do enable lightweight IoT devices to do that too. So not just Raspberry Pi's, although that still is going to be our prototyping platform, but Arduino type lightweight devices are the goal here. Now, why is that a relevant problem? A blockchain like fabric is, or the hyperledger projects, are a very nice and useful platform for business process automation, and increasingly, IoT devices play a role in these business processes. So they are delivering inputs that determine the next step in a process. So the people who own those processes would rather use IoT devices whose readings they trust, whose input they have reason to be confident in. An example is what you see here. Let's say we have on that hyperledger platform on the right-hand side from where you're looking, we have an application that implements a supply chain management process. And part of the supply chain management problem is monitoring a cold chain. So say there's a threshold of 10 degrees centigrade that should not be crossed during the transport time of goods in a container. And the container that sits on a truck here is equipped with a IoT-enabled temperature sensor. And so these are not three trucks. Let's say there's this one truck that goes from here to here to here. And over the course of the time, the external temperature changes, so we want reliable temperature readings. Now, typically, a temperature sensor is a very simple thing. You don't need a full computer to support that, but something like an Arduino. So you would like to have something on that temperature sensor that identifies it towards the blockchain and that ideally enables the device to sign its own transactions. So that nobody on the way from the truck to the blockchain can modify it. And even one of the other peers on the other end of on some other end of the blockchain platform, those with the question marks there, can still verify that the temperature reading has been signed by an individual device that they can maybe look up in some database that it has been calibrated by an authority of some sort. So what we are proposing is to use a generic SDK that people use to develop applications for fabric and carve out of that the part that does the signing. So the absolute minimum that needs to run on the device to implement what I just described. And farm out the rest of the processing and the communication with the blockchain to what we call a fabric proxy. So the device signs its own readings, sends the signed readings to the proxy, and the proxy organizes the communication with the endorsers, collects the endorsements back, then lets the endorsed final transaction again sign by the device, but then again sends the results to the orders. So that's the idea. This is what that looks like in a bit more detail. The transactions we have is the transaction proposal goes from the SDK stuff that runs on the device to the SDK backend that runs on some cloud service, say. And they are connected by an MQTT broker. MQTT is a protocol that is very lightweight and that is very commonly used to connect IoT devices with the internet. So it's more lightweight than the restful interfacing. So using that protocol, a transaction proposal that's already been signed by the device is being sent to the backend, passed on to endorsers, endorsements collected on the way back, sent back to the device. All the device has to do is sign them and form the final transaction. The final transaction again is being sent to the SDK back and that is then fed to the orders in a network. And we've implemented that. In fact, we have it on a Raspberry Pi here. Like I said, that's only the first prototyping platform. So the IoT device represented by a Raspberry Pi with the sense hat that provides us with some environment readings. The MQTT broker we're using is running on the IBM Watson IoT platform. The proxy for now is running on that laptop there, but in future we would offer that as a cloud service, I guess, and we have a freight forwarding application running on the fabric. I'll show some very preliminary results here in this table. In fact, I want to mention that the SDK we're using is the Hyperledger Fabric SDK GO that has the company's secure key attached to it. And these results are rather preliminary. They concern only individual transaction, a single endorsing note. So take them with quite a bit of salt, but here it goes. So the CPU time we see from the full SDK compared to the client SDK that is running on the IoT device drops from 130 milliseconds to 80 milliseconds. So that's quite a significant saving in processing power. And always keep in mind that anything we save on an IoT device also saves power, typically. Then data sent to the network drops from 14 to 11. It's not so impressive, but it is something and the data received from the network drops from 90 kilobytes to 70 kilobytes. And with an IoT device, all of this is precious, right? The data bandwidth is precious. You have to pay for that. And the power issue I already mentioned. And finally, another nice aspect of this approach is that the client SDK is, since it's only a small part of the full SDK, when we want to port this to a microcontroller platform like an Arduino that doesn't have the same environment like a full Linux box, we now have much less software to port than if we would have to port the entire SDK. And with that, I hand it to Jens, who will show you, who will demonstrate that we've actually implemented something. Let's see. Okay, I may have to do a little window tweaking because resolution doesn't fit. Okay, so we have seen this picture now before. So what you see here is this IoT device, which is our Arduino, which is just running and communicating via wireless communication will be shown in these green windows. There should be a second one. Let me bring this up as well. So the top one just shows you the temperature humidity readings that we are reading out of the Raspberry Pi. On the right-hand side, this window is our proxy, which I will start now, which is running on my local machine. So this proxy now connects to the MQTT program on the one side and to a blockchain implementation that's sitting in our cloud environment at the lab. So it's a running blockchain environment. And that's what I'm going to show you next if I can get back to this window, which is this one. So this is an application we developed last year, which is a pharma tracking application. And I'm only showing here all the assets that we are tracking, and we have just picked this stretch where pharma products are shipped from a manufacturer to a receiver. And so the shipper has accepted the procession of the product. And if you look, for instance, at this asset, we can see now, looking at the history, that this company has assigned to freight forwarder the goods for shipping, and the shipper has accepted procession. So now this thing is being transported, and what we are doing now is we are acting on behalf of this freight forwarder and USIS device, which is part of the network of the freight forwarder to transmit actually those signed data into the blockchain. And if you go back and I start now the Raspberry Pi, so now it starts communicating, and you can see, I mean, we can show you later in detail what it is. It's kind of this force and back communication between the Raspberry Pi and the proxy, and then the proxy takes that information and ships it into the blockchain. So this is just repeated every so and so many seconds. Going back now to our application and just reloading the history, you should see now, indeed, that we are seeing humidity and temperature data, which is signed with a current timestamp that we have. It's one hour off because it's London time. And if you start looking here, okay, so the scale is not very large, it's between the 34 degrees, 0.4 and 0.6. So if you now go and change the temperature, you should also go and see the change in the temperature readings. And this is now actually read out of this blockchain. And so you can see this is data that's put onto the blockchain with the credentials of the device that was provided by the blockchain. So there's no way to alter this data on the way to the system. With this, I hand it over back to Gero. I actually want to hand it to you if there are any questions. Is that out more? Oh, yeah. Right, so the question is who will operate the middleware layer, so basically the proxy, right? That is the main thing. And I should have pointed that out more. The point is that we don't have to trust whoever operates the proxy anymore because the signature is in the device. And therefore, nobody can modify the data on the way from the device into the blockchain no matter who operates it, right? At least they cannot modify it without the signature not matching anymore. So that's the whole point of what we're trying to achieve to keep the trust in the device itself. So it could be run anywhere? Yeah. Yes? Just to understand. Right. OK, go ahead. So there is a reading of a sensor value. And we considered a transaction in the sense of an inspect event throughout the transportation process of a good. So it's an inspect event that's recorded associated with the asset. So some transport operator is in possession of a product. He has to report certain things. And one of those is inspecting. And now the device can report on behalf of this transport operator temperature, location, whatever. And this is considered a transaction. So it's really put into the blockchain under this asset ID and under the credentials of this transport operator. Right. And you can imagine that this data that is then trusted, presumably, could cause certain actions in the smart contract, right? Going one branch or another. If the threshold is violated, then some insurance claim could be started or something along these lines. Or at least the shipping will be marked as bad. I mean, this goes way beyond what we are showing here. This is really applications back end. So we will be at the boost also later if you are interested, we can talk. Yes. Very relevant question, whether the infrastructure we are proposing makes it, well, first of all, harms decentralization and secondly, makes it a single point of failure. There's no reason why you couldn't introduce multiple failover MQTT brokers and multiple proxies. In fact, the way we've implemented this is that the proxy is pretty stateless, except for the configuration information towards the blockchain. But this configuration of the blockchain connection could be shared between multiple proxies and then you could have failover switching between them because there's no state between transactions through the cap in the proxy. So that should work. And the decentralization aspect, I think that's more fundamental than the framework we are proposing here. That's a question of how many temperature sensors you have. As long as you have only one temperature sensor, this will not be decentralized. You could, of course, connect multiple temperature sensors maybe by different operators to the same blockchain, have them all report their data into the blockchain and then you would be implicitly decentralized to the degree of how many temperature sensors you want to deploy, right? Sure. Yes, sir. You mean, is this a question of what our throughput is or something like that? Yeah, so that's an interesting question. Repeated. OK, so the question is if you have a large number of sensor readings or whatever, if you want to put it into the blockchain, if you can aggregate it somewhere. I mean, if you do it here and if you really have a small-scale device, you may do some averaging or things. Otherwise, the intention, of course, is to submit this data unaltered into the blockchain. But you could imagine if this is not the key issue here, if you have a trusted gateway or something, you could also go there, aggregate the data at the gateway, and use the gateway then to sign the transactions. It would be a bit of a different model. So we intentionally here went all the way to the source of the data. If you need to do aggregation and want to keep this kind of signature scheme, then you have to do it at the gateway. So the question is, are there application scenarios in medical and health care? Oh, yeah, yeah, absolutely. So the question is, how broadly applicable is this? So the temperature sensors, we only put in there as an example to make it more tangible. But the implementation we have is completely generic. You could connect any device that runs MQTT and has an implementation of or slimmed down SDK. There could be any device that talks to it. So up to you to make up new interesting use cases for this. OK, I think we were still going to leave a few minutes for SecureKey, I guess, who are up next. So thanks a lot. And like Jens said, we'll be around. We'll be happy to answer further questions offline. Thanks a lot.