 Hi everyone, welcome to our Protocol Labs research seminar. Today we are joined by Miguel Pinchera who is currently a postdoc researcher at the Open IoT Research Unit of the Brunner Kessler Foundation. Miguel received his PhD from the University of Trento in Italy, has previously worked as a lecturer and robotics group tutor at the University of Biobio in Chile and is currently interested in researching the integrations of the Internet of Things with other technologies. Today Miguel will be talking about blockchain-based IoT system architectures and their practical implementation in agriculture. So Miguel, I will let you take it from here. Thank you, Amy. So yeah, as Amy kind of introduced me, my name is Miguel Pinchera and here I'm here today to talk about our research. I work at the Open IoT Unit Research Unit and particularly I want to talk about blockchain-based IoT system. So we are a base IoT unit and we are exploring blockchain as a research topic and today in particular I want to talk about practical implementation of this, this combination of IoT and blockchain for agricultural use cases. So the session today I split it in four parts. First I will start with an introduction of Internet of Things, a brief state of the art, what is leading us to our research, then our approach to using blockchain IoT systems and a proposed architecture for this integration of blockchain into IoT systems. Then I will present a few highlights that I found interesting from use cases, real use cases, where we have uses architecture that integrates blockchain and IoT into agricultural domain, in particular a water management system and another use case that is agriculture traceability and then we wrap it up with completion and let's say future work that we are in vision. So first of all to put us in context I want to define what is the Internet of Things and for that I like to use this analogy that current statistics show that over four billion of people are currently connected to the Internet. So considering that we are more or less eight billions of inhabitants for the planet this means that half of the population is connected to the Internet. In parallel to that this is that also show that there are more than 23 billion of devices also connected to the Internet. That means three times the population of the more less three times the population of the entire world of devices that are connected to the Internet. So the term Internet of Things referred of these devices that are connected to the Internet but with a particular task that is collecting data and creating or or creating recollecting data to create application that will help people in daily activities. So all the network the system the software that connect this device for this data interchange is what we can define the Internet of Things in a more general way. Typically the Internet of Things systems so how these devices are grouped are ordered into systems that are relatively complex because there are several pieces that need to interact and to make this system more easily they are divided into layers which typically talk about layer architecture of this software system software and hardware systems. All the devices have different capabilities and for that have also different constraints in terms of computing power and requirements and this layer architecture is typically used to to organize the systems. At the base layer there's called the device layer or the sensing layer where the most smaller devices typically the sensor are located. These devices tend to favor size smaller size and power consumption less power consumption over processing capabilities or communication capabilities. So to overcome this limitation that the small size devices have we have another layer that is typically called the edge layer where more powerful device provide the missing capabilities to the sensors. This could be a more network connectivity, more computing power, more storage capabilities. And on the top of this layer of the devices and the edge we found the cloud layer where we store and process all the information that is collected by the smaller devices. Typically on this cloud layer there are the the applications reside so are the more the end layer of the system. In this context the current IoT system favor a closed cloud-based centralized architecture meaning that the top layer the cloud layer is typically on the cloud and where a trusted intermediary the service provided provide different services for both the users of this application and the devices. For instance that the management authentication that kind of service are provided at this layer. This centralized architecture are easy or help to develop more easily this system and organize it more easily. But they introduce an intermediary that can introduce several potential issues to the ecosystem related to security related to a centralized point of failure for an entire architecture and many of the typical that if you're working with web free and blockchain you know which one we want to move away from centralized systems. So in this case the IoT is a really good candidate of a centralized infrastructure where we can rely on this centralized application. That is why in the latest in the recent year there has been increasing interest in blocking technology for enabling decentralized IoT architectures. These architectures tend to replace this cloud layer or even a smaller layer for this decentralized blockchain based application or systems. And however despite this growing interesting because it's really been growing from the last five four or five years there's still some research gap as we can say there are still points that need to be addressed. Particularly if we are looking from a practical point of view my unit has really applied a practical approach to this topic so we are really focusing on the practical issues that are still missing from the research. And one of the main issues the first issue is that the current literature the current research that you can find favor a smaller device with or consider that the sensors are devices more powerful than they are really are. So what we are using is sensors that are more related to edge devices that are proper sensors something really small with really low power requirements which could be useful for some use case but in the agriculture environment on the agriculture domain when we use favor size and energy consumption it's a really no no to go. On the other hand when you actually or the research consider small sensors this typically needs to rely on another component there is an intermediary in this case is inside the system itself but still an intermediary which can also create a security issue. For instance if you rely on the gateway and you get compromised the gateway you get compromised a lot of sensors too. And finally one other research cap or one point that we find we could exploit a little bit more is the fact that the smart contracts are really underused if you look at from a software perspective point of view. So the key element of our research is to rely on blockchain to enable decentralized IoT architectures where we use constraints devices so real sensor really small sensors. So the key elements are that the constraint devices are direct actors on the blockchain system they are not intermediaries the sensor itself should be part of the blockchain system. So they have a unique identity in this case for us the identity is just the capabilities to manage the private or public keys for the cryptographic functionalities that you need to do to be able to interact with a blockchain. And also the fact that the device is managing its own key give it give it let's say a root of crash for the sensor data and the sensor data is the key of the entire IoT system. Another key element that we actually focus also in our research is to use permissionless blockchains or public blockchains in order to integrate the application itself the agricultural application to many actors that you may not know so really entrusted actors. And the last point of the last point of our approach is to actually rely on a smart contract as software platform. So when we are developing this blockchain based application for agriculture many of the business logic we try to if not the entire business logic we try to implement it on the blockchain itself so using smart contract. This translates in our proposed architecture that we are going to talk a little bit more here each device is a direct actor of the blockchain system with a unique identity as well as any user of the blockchain has its unique identity in the sense of public public and private keys that is managed by the cell the device itself is managing a pair of private keys that give him a unique identity. For us at this stage of the research managing the keys is enough to prove their entity even though we know that blockchain could be enabled to to elaborate or to provide more complex identity scheme decentralized identity scheme so for us for now I'm managing the key and the device is good enough to start. Also our approach to rely on the smart contract as software components we use the approach similar to the digital twin this contract of information that is has a lot of fast words that is related to it we use a similar concept in the sense that each device is represented by the blockchain by a smart contract that is a twin of this device on the blockchain. Where this smart twin is not maintained or the information not feed by the user but directly by the sensor and finally we have another component that is a smart twin app so another type of contract that relies on this smart twin on the blockchain to to create the blockchain application itself for the iot system that we want to develop. So this architecture we conceptualize a software framework so we divide in software components divided in three layers that try to match typically three layers that we saw before for current iot systems. First of all the framework is blockchain diagnostic so we are not thinking about any particular blockchain just in it the smart contract capability and that's all and then we divide in these two three models the first model the key model let's say of the architectures is device model that provide the blockchain identity or the blockchain connectivity for the iot device. In our architecture the gateway what is on the edge acts as a transparent gateway so nothing nothing here is done everything's going through the device through to the next layer that is the blockchain layer where all the smart contract providing the application logic. So a really straightforward application where the gateway that can be used for other communications let's say tasks in this case it's not related to the data that is gathered by the sensor it's just a transparent gateway providing a communication related. So one of the key of this software framework that we propose is the device model that we want to see because that is what we convert a normal iot sensor a really constrained device in terms of computing power memory and this space into a blockchain actor direct blockchain actor which is actually a term that now you can find in also a trustworthy oracle an oracle for the blockchain system this device that has a unique event is one step closer to be more or to be trustworthy than any other device that doesn't have the blockchain identity. So this device is the key of the architecture and when we try to evaluate and explode and see if it was actually something to actually work with and the device is divided in three main tasks the device itself performed six steps that are related to all the blockchain operations sensing and coding hashing but also all the communication are related to the system itself. So to make it more easy we divide this task of the device model into three main categories sensing that is also just what the sensor normally does the blockchain part that we try to to insert in these devices and then the communication which is actually the typically communication for any iot devices so at the end the device model what we try to prove what we want to evaluate and we research on is to how we add this blockchain part inside the sensor with this proposed framework and this software framework conceptualization we try to evaluate it in different use cases and today I'm going to talk about two that are related to agriculture domain the first one is related to water management in fact there's a reference for the for the entire research paper if you're interested and it's it's talk about cost effective iot devices in a blockchain based water management system so the motivation for the use case comes from the fact that more than 85 percent of fresh water is currently used for agricultural practice so we know there's a water scarcity now and it has been for the last year so knowing that 85 percent is used for agricultural practices means that we need to do something there in that context there's we are working a research project that is called SAPI and that is a collaborative research project between a water management company a winery what a wine producer and a farming cooperative here in Italy the goal is to foster sustainable behaviors by reducing water consumption while preserving the quality and quantity of the crops yield so still producing the same quality of quantity but with less water consumption and the idea behind this project is to use low cost battery power iot devices as we talked before that water measure the water usage on the fields but also that report that to a blockchain system and a blockchain infrastructure and here in the blockchain infrastructure we use smart contracts to provide a trusted platform where it can include more additional actors that maybe we don't know about yet that can provide incentives to to foster these water savings so we took our architecture and we elaborated into this use case i'm going to briefly explain here so we have the constrained devices we have the twin contract that will represent the device on the blockchain and we have the contract that will provide the functionalities of the use case in this case everything related to to water management so first let's say a customer or a farmer has a water sensor that is measuring the water consumption on his farm he's on her farm and this device is directly represented in the blockchain by a bulk contract a twin contract of this bulk that is storing the information about the water consumption and it's directly maintained by the sensor the farmer doesn't have access or the control to to tamper the information the sensor reports information this can be replicated to to to many other many other farmers and then what we do is we create another contract for instance to reward this water saving and the contract itself is managed by any actor that wants to foster this water saving so we have the information about the water savings or water consumption and then we can open this information in a blockchain in a public blockchain so open to anybody that can create a contract to foster these savings whatever it means like for instance by token by money itself or whatever you want to use there and the idea is that this contract is twin up contract indirectly with the bulk however the the more interesting part of the the architecture itself of the use case itself is that we can replicate this to many other farmers for instance many other farmers give the information and their work can be extended to many other this part but also include the functionalities of the water management system for instance the billing where a service provider can use the same information that we store on the bulk to do the the payment of the water consumption and also some kind of foundation that can give certification saying that your product the farmer product produce let's is produced with less less water than the I don't know another single product and all of these get automatically interact inside the blockchain and take advantage of this audible and transparent record of information so that is our use case and that we wanted to implement so we took our software framework the one I presented before and on this let's say first version we tailored it to the Ethereum blockchain the software the framework itself is blockchain agnostic but we choose Ethereum for being one of the most let's say common platform in current literature and also at the time that we were doing this research and we tailored our software framework to that the device model that we talked that is the key element of the architecture we implemented as a cross-platform software library using C and agrinoide agrin is a platform for typically do it yourself sensor so it's really open and can be used in many many different type of devices and considering that we also select six different platforms that are really low-cost sensors that we see on this table furthermore we use a water flow sensor that we implemented and we connected to the sensor and we use a shield for the communication here I want to make a highlight the shield says that it's using lora one network lora one network is a type of protocol communication that we typically use on every cultural or also smart city that allows you to to have great coverage with very low energy consumption and a large amount of coverage for digital signal for communication but with a limitation of slow speed and slow payload so you cannot send too much data not too often so there's a limitation that typically is well done or suitable for normal IoT application but could be a problem if we're using blockchain when we are adding more information that we want to share in any case going back to the devices we have this table of devices when we use different type of devices arduino uno which is a really common and typically board that you can buy in any store that is really easy to start to do in your own sensors or even more complex electronic products but we also move it to more complex architecture that is still very low cost and even more we use a type of farm hardware family that is the the MIPS architecture that is a type of device or a type of architecture that you can still find on some kind of devices the idea of choosing everything all this kind of variation is also to reflect that as i told before iot system is typically composed of several type of devices that can be of any type of plan so with this experiment what we try to do is try to ship as many as use case possible and one of the key elements here is that we focus on really constrained devices you can see we have clock or processing power of the devices ranging from 16 hertz megahertz sorry to 18 hertz and memory ranging ranging from 32 kilobyte to only 50 and 512 kilobyte all of them with a price lower than 25 euros at the price of the of the evaluation and well using this using architect tool we want to see how this behave are these devices capable of being a blockchain actor so send the information directly the blockchain is what we evaluate in this water management case and what we measure first was the footprint so how much do we have to consume on this device to include this blockchain functionality in the sensor itself and our statistics our studies show that actually even in the most constrained device you are able to run the blockchain part however as we can see there in the flashing part including the communication is too much for a really constrained device as an Arduino that only has 32 kilobyte of memory however in the same implementation we can see on the other boards for instance the m4l there is a lot of space to include more functionalities as well as the communication as we did so it's possible to include blockchain but depending on the communication that we want to use we may need to use another board that is a little bit more but still really really constrained devices in the same spirit of benchmarking this this this blockchain addition we also measure the time consumption because as we are going to see later the the processing times will help us to measure the energy consumption and here we can see that actually creating the digital signature which is one of the main tasks in the blockchain part so to create a blockchain transaction at least for the Ethereum use case the time range that this is the more time consuming task and in the Arduino the most constrained board is for four seconds to generate the transaction however a similar constrained board but only with 32 kil 32 bits processing power it's already less than one second and we can see in the rest of the board really short times moreover if we compare to them to the rest of the operation we can see the transmission so the communication part still the highest time needed for all the other use cases also we evaluate the compression we had to add for doing the use case using this lora 1 technology that has limited payload for transmission we have to reduce the transaction into a simple compression that on the one hand is able to fit on these constrained devices but on the hand provides enough compression to make the transaction fit into this payload that we have available for the lora 1 network and actually a simple dictionary compression that is really easy to implement on the device can provide almost 45 percent of compression of the transaction then one of the critical points for any other decision if the energy consumption so we measure with a tool that is called the OT device that provides a really precise power consumption measurement at five volts which was the typical use case and we consider a needle time so arrest time of the board as eight and eight seconds as reference without any low power consumption method so the board without any low power mode just the board in sleep mode and then working what we wanted to do and as the table shows the results in in joules while the the graph provided the current consumption in milliampers and we can see here that actually you can barely see any difference for any of the stage of the process so no difference between sensing or creating the blockchain transaction however the communication is the highest peak of energy for our device and taking this power consumption measurement we estimate the energy budget of the of the device meaning that how much is going to to use during the normal operation this means how much energy is used in evil mode so just waiting for anything to happen plus the sensing time and the transmitting time plus the blockchain that is what we are adding to this evaluation for this we consider a reference irrigation schedule since it's a water management system that varies from farmer to farmer but in average we can consider aggregation schedule of two hours twice a day and we evaluate two different monitoring cases continuous monitoring when we are measuring measuring every 15 minutes during this time this wind of two hours of irrigation or a reactive monitoring where we are measuring when you open the vault and when you close the vault so just a lapse of time and lots of elapsed water consumption during that two key points and with this energy bias of this scenario scenario of two hours twice a day the results show that both monitoring cases so continuous and reactive the blockchain part is barely noticeable as we can see the most time consuming is ill so just waiting for something to happen although we didn't implement low power in those mode but still just after the ill the sensing is the more consuming so adding the blockchain part as we can see is really marginal to what we are consuming which is a really good point to see that we can implement all of this on the blockchain sensor so this is an ongoing project that is given a really interesting result we still need to to to get the more concrete results about the the savings and everything but so far it's providing really interesting information about this use case so we assess this architecture in insane device in the virtual behavior we are focused on evaluating the impact of blockchain on the devices and our results show that actually really limited the sources so less than 35 euros with really limited memory space and power consumption can work as direct source data sources for blocking system with minimal energy overhead what is also really interesting at this constraint sensor scan directly feed a smart contract that created this new type of publication in fact using the public blockchain provides allow us to develop this kind of application where anybody can join to foster this virtual behavior of what we're saving and so that is really interesting for what we have learned from using a public blockchain whereas there's still some constraint regarding the time processing and for instance cost that we can talk in another time which leads us to our next use case more or less the same principle we want to test this architecture that we propose but in this case we want to really benchmark it and make a comparison between two different blockchain implementations and in this case we take we take a paper that we we work our first approach to blockchain iot system which was for crossability application so the motivation in this use case is a little bit different that in every culture this has been a really interesting blockchain for crossability for the transparency that blockchain can provide this is also lived by consumers and authorities are demanding more information about the food products that they consume so what they want is a transparent history of the entire process of the product from the farm so wherever it was produced to the final consumer and actually the table where you are consuming the fourth part of the of the use case to study this we have a first we did a first research paper in 2018 when we simplified every food process into six steps and we also highlighted where the sensors can produce information in this process across the entire six steps simplification sorry and also that the smart contract can create new information during this process but in that first version we only evaluate at the gateway labor so our first approach that was the main approach on the risk on the current literature at that time so no sensor involved the sensor was acting as usual and the blockchain part was added at a gateway labor so when we have a little bit of more computing power and at that time we compare Ethereum and sold to us to other alternatives but then we made a release version last year when we took the same use case but we went with more details and a more detailed also proof of concept implementation we use our architecture the same we use for the water management and we apply it to this crossability scenario here we also lower the price of the boards we said okay this is more even more demanding for what we want to do there are more steps so we lower the cost and we set a baseline of 20 euros less than 20 euro for the board we wanted to carry and once again we focus on the device so how we do this the use case let's we take all of the step of the six steps of the crossability process which is time on the farm and finish on the consumer getting the food on the store and we implemented on the blockchain to make it more simple here we only focus on the transportation so for instance when the farmer is sending the raw materials the food raw material to the processor where it's going to be processed and here we consider that the the transportation has let's say as a couple of sensors inside the the transportation station for instance it has a GPS there's monitoring waypoints of the directory from the farmer to the processor but it also has an environmental sensor that the measuring for instance temperature and humidity of the container where the food is transported and for that the the processor the one that is receiving has that can create a delivery contract that is going to be for instance paying automatically on receivable and this receivable is going to be estimated or or calculated in the based on the waypoints that the GPS is reporting but also considering that for instance no anomaly on the temperature was registered by the temperature sensor so for instance the delivery can set automatically set that if the temperature passes some threshold let's say 30 degrees while transporting the payment is not going to be made automatically following the same reasoning we open the architecture for other actors to create other type of contract that automatically interact with the sensors on the transport for instance to transfer the ownership to different farmer or different actors in the system or to get a certification for the retailer that the food is well perceived during the entire process for instance so once again we focus on evaluating this but this time we extended the library from Ethereum to Sotut so another blockchain platform that is mostly used for private implementation but the idea is to to compare see if the our results that work for Ethereum can work also in other implementations um we include for instance another board that is this p32 that's appear in the recent year that is really common to see for doing yourself right that you have really low cost but the thing is that this board provides a lot of more research on the same cost on the same power consumption still boards that are less than 20 euros of price actually the more expensive still the you know which is 18 euros but you can find replacement that are not official let's say Arduino made but similar architecture were way less than 10 euros for for the board and here we did another evaluation also the footprints of this including these blockchain operations on sensor but comparing the two blockchain implementation so Ethereum one hand and Soto on the other one regarding disk space so how much program we need to put inside we can see that the avid board can fit a zero implementation but Soto is more demanding it cannot fit in a normal board with only just 32 kilobyte of memory similarly the the 32 bits require more space and and also it's not feasible however as we can see for the sixth board only two were not able to fit the the proposed architecture in terms of disk space regarding memory this more or less the same happened we we started noticing that the Soto implementation or at least our porting of the library to to be able to interact with Soto also has higher memory requirements however really constrained device in this case only for Soto only five or six boards were able to handle the entire implementation however for Ethereum as we saw before we have no problems for even a really low constrained device one comment here we didn't focus on any communication technology as we did before for the water management when we use Lora one here we open it to many other energy available communication technologies so we just opt for a serial communication and simulations and just to get a base reference and then we can eventually try for instance Wi-Fi Bluetooth or whatever we have available but we're still focusing more on the blockchain part and as we can see here we have a lot of space to continue working what is interesting here is that the processing time for Soto was almost twice the time for the Ethereum time and this is related to the protocol if you've ever seen how that blockchain section is made for Soto what the main difference is that requires two digital signatures and obviously that doubles the time as we saw in the first use case is the main time consuming task for creating blockchain inside the device blockchain transaction server and also that reflects on the transaction size for Ethereum the average size was 132 34 bytes where for Soto this almost 925 bytes so a larger transaction and this high demanding resources also translates into energy which is finding the main key for IoT here we have an average graph of the energy consumption for Ethereum on top and Soto to estimate we use the same machine we use the same energy budget so it'll just do anything sensing and creating the blockchain information and transmitting once again we didn't implement no low power mode so there is no low power when it's in little mode and that shows that the device is currently the highest energy consumption in the entire process what was interesting here is that despite that Ethereum sorry Soto requires more energy for creating a bigger transaction and also for transmitting a bigger transaction when we put in the context of a daily energy usage for IoT sensor it's still very very low it's less actually it's less than 1% of additional energy so which also encourages us to say okay we can soon use this constrained device to be part of a blockchain based system for at least for our use case that we were evaluating which will open the door to use this smart contract that are really relying on this sensor as trustworthy oracles that also enables to develop this blockchain based application using the smart contracts or relaying also entirely on the blockchain network summarizing we assess the blockchain based traceability application in this case with an event based traceability case study here I want to make an observation typically when you work with IoT you talk about collecting a lot of data so to to don't over over saturate on over consume information on the blockchain we just create some event based monitoring for instance when we do in water management we talk about measuring irrigation and a certain time interval that was quite long let's say 50 minutes or event when you open or close the water valve and here the same we were measuring certain events for instance when we're doing the transportation certain gps white points only registered not the entire path and also when we have some anomalies on the temperature on the humidity not the entire information on the blockchain itself this can still be sent to the typically normal IoT system and one second our show show that this constrained device can work also in this scenario comparing even two different blockchain implementations underlying it a theorem and so to what we show is clear that small variation in the protocol as it told before the sort of protocols used to do two different signatures two different state of signatures for the data which create a lot of more resource in the demand on the sensory itself despite this the constraint sensors can still be used with both implementation with minimal impact on the resources whereas the present time the memory and the most important the energy value that is one of the key elements for IoT devices particularly in agricultural environments let's wrap it up what we have what I have presented today so our research focus on integrating blockchain technology into the Internet of Things to develop new type of decentralized IoT applications and for that we propose an architecture that concerns constraints sensor devices really small IoT devices that open a lot of use case particularly in agriculture and the other key element of our architecture is to use a smart contract to implement the application logic the application platform and we have valued this architecture in two different use case one for water management and one for possibility and in both cases the constraints sensors constrained in the terms of memory space this space costs and energy requirements can work with a really common platform as a theorem and also on private implementation as sorted and what is really also really important to highlight the smart contract we're able to provide the software platform to develop the logic of every use case in this use case that we show as future work on this recent what we continue or want to do is to to port this library since we started in Ethereum we want to sort it we also would like to try different implementations for instance hybrid fabric that has been really used in current literature for blockchain experiment and for that also see made in more accurate energy consumption and using other communication technologies we evaluate the most constrained that was Laura one but we could also start using 3G 4G or even the new 5G generation and also one is and I'm going to research is related to the smart contract for more security analysis so we can say how much secure how this blockchain based application and also infrastructure cost that actually is ongoing really active and to estimate how much is going to cost for instance when we are using public or what we have to pay if we want to create our own private infrastructure and also another interesting topic is to try to implement or migrate or adapt this architecture to later to architecture so this is secure channel of between when we are using public that is what is we are envisioning in our research so that's all thank you so much for this invitation for any time to talk about what we do here in the open IT unit could be here now or later there is my content information so please free to contact at any time thank you so much Miguel for taking the time to talk with us I really appreciate it