 Alright everyone, we're going to get started. Again, thank you for coming to the Hyperledger Foundation webinar in depth with Bosch today, enabling micro transactions between IoT devices using the parent state channel framework. And today we have Mano AP joining us from Bosch. He is the blockchain and embedded systems engineer and he is joining us live from Germany. Before we start today's session, we have a few housekeeping rules. We'll go over. Everyone here is welcome at Hyperledger Foundation and we're committed to promoting and creating the safe environment. So please follow the code of conduct that we have when interacting with each other today and throughout. And the code of contact can be found either on the Wiki or on our web page. And today's webinar and all Hyperledger webinars are under the antitrust policy, which can be found either on the Wiki or on our events page. And this session will be recorded. So if you want to go back to review today's discussion, you can do that as well as it is a live stream coming from either Zoom or our YouTube page. And to follow the webinar today, we will be sending you the webinar as well. Next, we encourage these webinars to be as interactive as possible. So please help in cultivating this interactive session by raising your hand, asking questions. And in the Zoom box, when you raise your hand, I will unmute you so you can ask those questions as well as any questions that are not addressed today that you still have. Feel free to email me or our ecosystem team or Mono or you can go to our Discord as well to continue the conversation there. And without further ado, we can get started. And Mono, I'm going to stop sharing my screen and let you take over here. Yeah, sure. All right. Am I audible? Yes, you are. Yeah, okay, perfect. So I will share my screen. So is my screen visible? Yes, thank you. Yeah, so hello and welcome to everyone who are joining from different time zones. Good morning, good afternoon or good evening, depending on where you are. Today, I'll be talking about one of the interesting things we have been working on, which is enabling microtransactions through between IoT devices. And this we have been developing as a pattern open source project as a joint collaboration between Bosch and Polycrypt GMBH. And yeah, so to begin with, I will start with a very familiar context. I think you'd have come across this context if you're hearing box from the blockchain space for quite some time. It is that there is an electric car which wants to charge at a charging station. And here, the charger wants to give the car some power, electricity, electric energy, and car wants to pay for it. And using this scenario of a mission trying to interact with another mission, I would like to take you through the journey of how we started around with Perron, like what was the problem statement we started with, what were the new ancestors we were looking at, and what was the solution we were thinking about, and how did we go about achieving the solution, and what is its state now, and how are we looking forward. So that's the whole gist of the presentation for the next 60 minutes. So to begin with, let's compare these two scenarios when humans are involved in economic transaction and missions are involved in the economic transaction. And the economic transaction, as I said, is a car trying to get some electrical energy from a charging station. So when humans are involved, they arrive with their car at the charging station, then they make an informal agreement. This can be as simple as saying to the charging station operator, Hey, I want to charge my car for one hour or 30 minutes. And this is the rate I would like to pay. Is it okay? And then they make an agreement, like by word of mouth. And then they charge the car. And once the car is charged, the payment is made. This can also be two ways like either prepaid before charging or postpaid after charging, whichever is okay, both are fine. And finally, the humans leave the station. And that's the end of the scenario. Now, what if we were to remove the human personality personas from the scenario, like the owner of the car is not there. And the charging station is also not there. It's an automated charging station. And the car is probably having some intelligence to just go there and charge itself, because autonomous cars are not like very far away in the future. Also, just remember, this is just an example use case that I pick up to walk you through with a tangible example. But this can be extendable to many use cases that are like really happening even today, not necessarily futuristic. So the machines, the first trick is that how to make agreements. Because we take it for granted that we go to some shop and say I want this and I will pay you this. So the other person gives you the good and then you pay. So it's a very simple agreement. But if you look closer to it, it's very hard for machines to do that because this involves an aspect called trust, that if you give him the group, he will give you the money back. If not, then you can make some fight or some case and resolve it. But that is not possible in machines because machines don't understand trust the same way as humans do. So how do we make agreements and how do we handle disputes? So these were the two major questions that we started with. But as we kept pondering upon the scenario, we started coming up with a few more questions, which also became critical. Third one being how to design for IoT scale. By IoT scale, what I mean is that currently when we talk about most scalable systems, we talk about internet scale. I'm saying everybody is connected on the internet, maybe 80, 90% or even much lesser. But that's fine. Some very good percentage of populations connected to internet. And we want to account for every person on the internet. That is what we think about scale. But if we look about IoT scenarios, IoT devices are most likely owned by people or by companies. And one person or one company can own any number of devices. So IoT scale is going to be much larger than the internet scale. So we needed some mechanism that would work at really that scale, like not even scales today, but much orders of magnitude more than that. And fourth one is how to deal with IoT device constraints. So the IoT device could have several constraints that it's having limited energy, limited power consumption, because it's running on battery, or it is not able to always have very good network connectivity, or it is having compute or memory limitation, something like that. So how do we deal with such IoT device constraints? That was the fourth nuance that we came up with. Fifth was the last one, but also very tricky one is machines holding money safe. So if I'm going to some shop to buy something, then I would either have some cash or credit card, which I can spend. And if this cash or credit card is lost, it's a problem because somebody could steal money from it. So I would always try to keep it safe. But if I lose it, then it's my problem because I have been careless. But now if we think about giving the ability for machines to make economic transactions, is machines holding money safe? For example, if the car or some other device is stolen, then the money associated with it is also gone, and that is a problem. So how do we tackle that? So these were the problem context, which we started out with. And before I move on further, if you have any questions, I would like to take that and then go forward. Since there's no questions, I will move forward. So the next step is, okay, we have looked at what the problem context is. Now how do we, what are the technical requirements? This context gives this. So the first thing is enable machines to make agreements and handle disputes. Here we said, okay, let's use some form of enforceable digital agreements, which machines can understand. And for dispute resolutions, let's use algorithmic dispute solutions. And each of this, I'll be coming into detail in the later parts of this talk on how we go about with them. Here it's about just identifying what the requirements we are working at. Second is designing for IoT scale. As I said, the interactions can be at very high scale than what is possible today. So we thought if we are going to decide for that scale, then most of the interactions should be peer-to-peer, if not all. Then the third point is designing to run on constrained devices. So in this case, we need to consider the limitations on compute, memory, network, and power consumption. This should be an important factor in designing a solution. And the fourth one is limit or eliminate the need for machines to hold money. So here we said we can use some form of peer authorization. For example, I can say the car, hey, I give you permission to spend so much amount of money only with this person, only in this context. So some form of pre-authorization, so that even if the car is stolen, the authorization hold which the car holds is very less likely to be misused because it can be spent or used only in a very specific context. So we thought, could we think about something like that? And having all of this in mind, I think the first one, if you're in the blockchain space for quite some time, you understand one of the big benefits blockchain brings is this, it makes possible one to write enforceable digital agreements. And it also has algorithmic dispute resolution. So we said we will pick one of the common blockchains, say Ethereum. And this is just the one we started with. But now we work with a lot more blockchains. But for a solid context, let's say we already use Ethereum for this. So we don't work much on the first part of the requirement because it's already solved. But then how do we go about solving the other three parts? And that's where we started working on Perron. And in the next slides, I will explain you how Perron protocol works. Yeah, so this brings us to the second part of the webinar, which is the solution. So before we move forward, if there are any questions we could take and then go forward. Okay, perfect. I will go forward. So the thing with Perron state channels is that say you have a charger and you have a car. So these are not on the blockchain. They are like blockchain layer. And then there is blockchain, say Ethereum, which is the top layer, the blue one. And we deploy the Perron smart contract on the Ethereum blockchain. And what happens is that the car goes and meets the charger in the charging station. And then it interacts with the charger saying, okay, this is the agreement that I want to make with you that I want to purchase so much of electrical energy. And this much I'm willing to pay. So all those interactions happen, direct peer to peer between these two participants. And they come to an agreement, okay, this is what I'm going to sell you energy for and this is how much you're going to get. And once they make this agreement, they go to blockchain and say to the Perron smart contract, here's the agreement we made. You please fund this agreement on the smart contract. So what happens is if the car is willing to pay 10 euros for 10 units of electricity, then it sends the 10 euros to the Perron smart contract, which is getting blocked in the smart contract. It is not yet sent to the charger. And it also tells the smart contract what the rules of the game are. Then the channel is funded. And now the car and the charger can enter the transact phase, which means the car is now allowed to spend 10 euros with the charger according to the rules which they agreed. So then we can say, okay, I will get one unit of electrical energy and then pay one euro, one more unit of electrical energy and pay one more euro and so on. So that way they can pay each other. But all of this is happening direct peer to peer. It's not involving any central server or blockchain. And once that is done, what happens is that they again go to blockchain and say here is a transaction that's complete. We would like to settle our new balances on the blockchain. In this case, it would be that the car got 10 units of electrical energy and transferred 10 units to the charger. So now the contract will take the 10 euros that was blocked in the contract and give it all to the charger. And if for this, it would consider the proof which the charger and the car sent. And so this ensures that everything is happening according to the game, like according to the rules which they agreed upon. So this was the Peruvian state channels, the first part of a solution, but it was not all. So what we achieved here was that we were able to make most of the transactions direct peer to peer so that we succeeded. But the other problem is that the car and the charger needs to go directly to the blockchain and when they're transacting off-chain, so when they're sending off-chain payments, if somebody is missing, what happens? So if the car is just driving away from the station, what happens? The charger will have the latest off-chain state, which both of them agreed to, which it can post to the blockchain and say, hey, this is the latest state I have. The car is not responding anymore. So settle the dispute and it will verify, the smart contract verify that that state is correct. And then it will give a grace period, say 10 seconds or 10 minutes or whatever you can configure for the other person to challenge. If this is a fake transaction, then other person can challenge with his own proof and then the smart contract will try to check both the proofs and resolve it according to which is the correct one. But if nobody is responding in that time period, the challenge duration, then the smart contract will say, I got this, the challenge period expired. So this is what I'm going to resolve. So in this scenario, it is important that all the participants are continuously connected to blockchain, which means they should have continuous, very good network connectivity. And yeah, they should have good power consumption as well, because otherwise, they cannot be always connected to the internet. So these two limitations were there. And that is what we try to work on in our next improvement of Perron State Channels, which is Perron IoT State Channels. Here, what we did was that we took an advantage of a key characteristic of IoT devices. That key characteristic is that every IoT device is either owned by someone or it is administrated by someone. If the device belongs to a company, then there is an administrator for every IoT device. So we said we will take advantage of this phenomenon. And then we will try to delegate all of on-chain interactions of the IoT device to this administrator or owner. So now what happens? The car is no more talking directly to the blockchain. But it says to the owner, hey, I went to the station. I made these interactions with the charger. And this is the way I want to open the channel. This is what he says to the owner. And the owner will then fund the channel on behalf of the car. And he will also set up everything and then say, I've set up everything. Here's what you need to do the transactions and everything. And then the user gives the car the authorization. And now the car can make transactions as it did before. But the interesting thing is that it just needs to send periodically like every one second or two seconds or maybe every 10 minutes, which you can configure, it needs to send periodically the latest state, which was a grid off-chain to the user so that in case any dispute arises, the user will send the latest state to the parent smart contract and resolve it. So in this case, the car is no more required to interact with blockchain or be always connected to blockchain. It just needs to talk to the user. And to the user also, it need not be always connected. It needs to be connected only when it needs to talk or at least once in that periodic interval. So this way, we eliminated the need for the IoT device to be always connected to the blockchain. And this solved most of our requirements. So if I go back to the slide of requirements, we solved most of it. The first one, we used Ethereum already. So then we got enforceable digital agreements and algorithmic digital solution. Second one, we made the transactions mostly peer-to-peer. That way, this could scale even at an IoT scale. Third thing is that in the IoT state channels, we moved all of the blockchain interactions and network connectivity requirements away from the IoT device to the owner or administrator of the device, which means even with limited compute memory or network or power consumption requirements, this solution can still work. And finally, preauthorizations. So what happened was that when the car says that it wants to spend so much and everything, the user actually has the keys for the funds which are on the blockchain. Whereas the car has only the funds for signing or doing the off-chain transactions, which is only like preauthorization keys. Even if these keys are lost, there is nothing lost because with that keys, the only thing possible is to act within the limited context of that contract with that particular person with whom it was set up in that particular time period. So this way, we solved all the four of the requirements that we had. And next part is the demo before. And Manu, I just want to jump in really quickly. We did have a question on the YouTube channel regarding the transactions and the negotiation there and the question of what if there is some sort of technical issue that you run into in terms of payment? Is that refunded and how does that work? Yeah, that's a good question. So if you look at the protocol itself, it takes care of every part that if at some point in time, like when you're setting up the channel or when you are making off-chain transactions, if some point in time, if there is loss of network connectivity or some other devices down, then you already have all the information to safeguard your interest. For example, you block the money, say 10 euros you blocked and 0 euros the other person blocked and your agreement is that you're buying one unit of electrical energy for one euro in every microtransaction. And now after buying four units of electrical energy, say the charger is down, it's completely out of network or something, then you have the proof that you have paid for the four things and you can send this proof to the blockchain and the blockchain will wait for some time, as I said, the challenge period to check if the charger is coming online or if it is trying to challenge your decision. If not, then the state is resolved according to the proof that you gave to the blockchain. So that way, at any point in time, if there's a technical glitch, you could still recover what has happened until that point. Great. Thank you, Manu. And thank you for asking the question. If anyone else has any questions, I did allow everyone, you can just unmute yourself and speak directly to Manu to ask questions or feel free to write questions in the chat either on our Zoom live stream or YouTube live stream. Thanks. Yeah, hi Ramesh. Hey, what is the difference between the off-chain data and on-chain data? Yeah, so on-chain, can you be more specific about the question? Can you go to the previous architecture which you have shown? Yeah, sure. This one? No, not this one. One more. Yeah, so this one? Yes, exactly. Layer one and layer two. Yeah, please go ahead. So what exactly the difference between the layers actually, what exactly it will do? What kind of data it will store on the layers actually? Yeah, sure. So layer one is the blockchain. So this is like the normal case when you're deploying smart contracts on blockchain and you're sending transactions and everything, this is stored permanently on the blockchain. But because this is a very non-trusted layer, it's also expensive. You have to pay some gas fees and everything for every transaction. But layer two is like based on the open state, like you open this parent state channel using the parent smart contract, then you can directly make, create new states. So for example, the car can say the initial balance was 10 comma zero. Now you gave me one unit of electricity. It can add the proof and it can say the new balance is 9 comma one, which means the car is paying one to the charger. So the car can create this data in locally and then sign it and then send it to the charger. The charger will then sign it, which means it is now a new off-chain state. So this way they can create n number of off-chain states by direct peer-to-peer interactions. And there are defined rules for how these states are created and what states are valid and what states are not valid and everything. And those rules are what we call as parent channel. And whatever state is created according to these rules that can be later used for resolving the dispute or even like resolving it collaboratively on the blockchain. So that is what happens between layer one and layer two. But if I query my balance, will it hit layer two or layer one? So whatever you're doing on layer two, it does not affect your on-chain balance unless you settle. So it's just that you're maintaining a local bookkeeping between you two people because you are the two people involved and you know that every state that is created in this off-chain channel is possible to be resolved on the blockchain at later point in time. So this is just a local copy. This will not affect the on-chain balance, but it gives you the guarantee that at later point in time, you can without any problems update this off-chain balance on the blockchain. Okay, thanks, sir. I will also show you this one. So this particular part, I will show you how it works in the demo part. Like I will show you both the on-chain balance and off-chain balance and how that changes in each step. Yeah, that would be great. Thanks. Yeah, I will come to that in the demo part. Thanks, Ramesh. And Manu, we have a few other questions here, one from Joey on Mugalu. He's asking, how can the user of an IoT device manage their payments or enable scheduled activities? How are triggers for the microtransactions set up? Yeah, I think I will show you this part in demo as well, how this interactions work. But in short, it can be any ways. For example, you can have a mobile app to which you receive every notification when a device wants to ask for some authorization and then you can manually approve it. But if you're having a larger system, like if you're a company, then you can also have an automated system which says, if it meets these rules, then you can do it. There are white possibilities. It's not fixed. Yeah, but I will show you one possibility in the demo section. Okay, great. And then James comp asks, does parent enable asynchronous operations like JavaScript promise? Can you be more specific about the question? Because I'm not able to fully understand it. Let's see here. James, I don't know if you are able to perfect. So I'm wondering, for example, can parent, can you do an asynchronous, on the blockchain, it's not possible to do asynchronous operations because it would lock up all the nodes. I'm wondering if it's possible on parent to do that. For example, could you have an outstanding JavaScript promise to monitor the cost of electricity and then it would trigger when it gets below a certain cost and then the car could charge at that point? Yeah, you could do that. So the interesting thing is that the parent channel is a state channel, which means you can write any arbitrary logic in it and make the transactions according to that logic. So you can say that, okay, I'm hooking up my car with this charger, but then it's not charging immediately. I'm buying 10 hours of time or something and I will consume charge only when a certain party has met and then you can configure the factor to be whatever it is. So all those fancy things are possible. Okay, thank you. Yeah, but whether it makes economically viable or that's a different issue, but I think technically it's possible. Yeah. Thanks, James. Thank you, Manu. Yeah, do we have more questions or should we move forward? Not yet. So I think we're okay to move forward. Yeah, perfect. Okay, then I will move to the demo section. Yeah, in the demo, I will show you a screen with four splits, each split having a terminal, and the top right split is the blockchain terminal. Here, you can see just some text crawling. The purpose that I show this split is that whenever some blockchain transaction is happening, you can see some bulk of data. So that's the only thing I don't expect that the text is readable in this split. In the top left split, that will be the user's portal. So this is the portal of the IoT device owner, which is basically the car owner. And here, I have set it in such a way that it's just auto approving every request. But you will see the data, like whenever a request comes, you can see that the request is coming. And then it is getting automatically approved. And what's happening on his side that you can watch the bottom two splits. The left side, I will have the small UI for the car. So in this UI, we will try to open a channel with the charger and everything and do some transactions. And on the bottom right, you will see a small UI for the charger. Yeah. So I will move to my demo screen. So this is what you see. One moment, I will start the note for the car and the charger here. And now if you look at it here, so this is the car owner's dashboard. And this is the car terminal. And this is the charger terminal. And this is the blockchain. So here I hit connect. So all of this are not running on a local mission. Everything that is representing the car is running on a Raspberry Pi. Everything that is representing a charger is running on another Raspberry Pi. This blockchain is running on this computer. And the car owner's dashboard is also running on this computer. So it's like a really network setup. It's not a local setup. So let's wait until this gets connected to the same network. Yeah. All of this are connected in the same VLAN. WLAN. Okay. Thanks. Yeah. So local network. But I think since we use IP addresses, if you're able to make your device visible through Internet, then you can also connect across the Internet. It should be fine. Yeah. So if you look at the terminal, I will show you in the top, there is the address, the on-chain address of the car. And then there is the balance, which is 108. And then here we have the time. And here we have some channel data. I will show you when I open channels what is coming up here. Similarly for the charger, also we have some balance. So I think it's having some 99.998er balance. So now let's say the car goes to the charger and it wants to open the channel. So it says open. So I'm typing in the text box here if you can follow. So it goes here and says open with a charger, 3 and 0. So it says I want a channel with balance 3 either for me and 0 for the car, for the charger. And then it gets a request, which it can accept. So once it accepts, you can see that we have a few transactions on the blockchain, which is basically the funding transaction. So the money gets blocked. So now you see that the balance here is 96. something, which means three Ethers has been blocked in the smart contract. Here the balance has not changed because this was not blocking any money in the channel. And if you see in the car owners dashboard, it got a funding request saying the channel is between the car and the charger with a balance of 3 and 0 ETH. And then it was automatically approving the request. So funding was successful. Second, I was telling you about the fact that the idol devices should continuously watch for the blockchain for some events. And in this case, the car will not be watching, but the user will be watching on behalf of the car. So the watching request for the channel with a charger is started. And that is also shown here. So now the channel is in Pansec face here in the car, it says the peer is the charger. Similarly, if you look in the car chargers dashboard, it says it's also in the Pansec face with the peer being the car. And the balance is here and the version is here. So now let's say the charger sent one unit of electricity to the car and it wants to pay for it. So I send on channel number one, one ether, like this, and then it gets a request. It can accept it. So now what happens is it's accepted. Now you see the balance has changed. If you look the on chain balance remains the same. It is 96.99 for the car and 99.99 for the charger. So that's not affected. But the off chain balance has changed. So it is two and one. And the version also has been updated. It's like version one. And it's not that always the car needs to initiate the payment. For example, if you want in your use case to be otherwise that you want to request payments, that's also quite possible. You can say request on channel number one, one ether. And then he gets a request for approval, which he does accept. And then the balance is again change. Now if you look the cost balance is one and charges balances two and the version is two. So similarly, we can try to make one more payment, send on one, one and then accept on one. So now the transaction is complete because car's balance is zero and charges balance is zero. In the meanwhile, if you have noted, in this case, the car is sending every state that it creates off chain to the car owners because then if there is any dispute on the blockchain, you can always use that latest state for dispute resolution. But if you're thinking about high frequency transactions in some use cases where you want to make large number of small transactions, then it is not necessary that you send every transaction. It is sufficient if you are sending periodically at least one transaction. For example, the latest transaction every minute or the latest transaction every five minutes, or it can be any period that you can configure depending upon your use case. So this is the transact phase where the transactions are completely over. And in this transact phase, you see that there is no transactions in the blockchain. So all of this is happening off chain. And even the on chain balances is not affected. So now let's say we want to settle this channel. So in this case, I think the person who's most interested in settling the channel is a charger because he is the one getting the money. So he can say close on channel number one. And then it says goes register phase and it sends a request to the user which the user can accept. So once the user accepts, it marks the new state as version four. And because both parties are agreeing to close the state, it says that is the final state. And when you try to resolve a final state, the balance is settled immediately. So we saw that as soon as we set close, there was no challenge duration or something. The balance was getting settled very fast on the blockchain. That was because both parties agreed that this was the final state and this was the state but that we want to close. And if you look in the car owners dashboard, you saw that channel finalized off chain. So this is what I said as both parties agreed to what was the last channel. And after that, the withdrawal request was made on behalf of the car. And then the channel was concluded on the blockchain and the withdrawal was successful. Now if you look at the on chain balance since all the three ethers which the car blocked was spent on the channel, it's balance did not increase. It's like 96.99 again. But if you look at the charger, it is like 102.99. So this is how the transactions work. Maybe if you have some questions, we can take it and then I will show you one more scenario which is more interesting. And Manu, we do have a few questions on the YouTube channel again from Mohammed Abu Jabara. He's asking, where do you maintain the pricing table and how many power, how many power units are sold in Tali initially? Excuse me. Sorry, can you repeat the question? Sure. So the first question is, where do you maintain the pricing table? Okay. And then the second is, how many power units are sold initially? And Mohammed, if I am not asking this question thoroughly, feel free to. So I think this particular use case itself is not the real use case. Like this use case is chosen for illustration purposes. So I mean, we don't care much about what is electricity price or something. In fact, there is no electricity being exchanged between the devices or so on. It's just for illustration that I use as example. But if you want, then you can just have some software that is running in your car which is talking to an external service like an external API which is providing you with pricing information and so on. That is quite possible if you're thinking about implementing this use case in real life. And we had these states that how many power is exchanged and everything is probably stored locally between these two parties because the car knows how much power it receives. So it can keep track of it. And maybe there is some proof exchanged between the car and the charger on that part. So that is very specific to the use case. Here it's just used for illustration purposes. So there is no exchange of electricity or anything. I hope that answered the question. It looks like it. Thanks, Mano. Yeah, sure. So now I come to an even more interesting use case that so that I will open one more channel with this charger, open with charger one and zero. So it's just having one transaction. And I accept this channel. And then I send one on this channel, okay, 0.5 on this channel, one. Send on channel two, one ether. And then it accepts. Now what if the car is not responding? Like it wants to drive away because it does not want to make this one either payment reflected on the blockchain. So what if it's just running away and it's not responding? Even in that case, I think our interest is safeguarded. So we can try doing it like close on channel two. And so it's going to the register phase and it's asking the car to approve it, the closing, but the car is saying I will not respond. I don't care about it. So then what happens is that both persons will wait until the time out. So the time out you can see here was 42 seconds, which has passed. And after the time out, the challenge duration starts. So irrespective of whether the car responds or not, the channel is always registered on the blockchain. So here you can see that. And you also see that there was some transaction here, which was the registered transaction. And after that, the challenge duration is weighted. Like in this case, it's 10 seconds. I've set it to 10 seconds for easier demo purposes. And after the 10 seconds, still both parties with product balance. So the only difference is that if both persons collaborate, cooperate, then the cost, like the economic cost, money cost and time cost of settling the channel on the blockchain is much cheaper. But if one person is not collaborating or one person is acting malicious, the channel can still be settled. The protocol safeguards your interests. But just that it involves a little more money because you need money for the solution or a little more time. That's the end of the demo. And Manu Ramesh has another question here. He's asking how many transactions are created in the blockchain? So in the blockchain, when you open the channel, one transaction is created for funding the channel. And when you close the channel, two transactions are created. One is for registering and the other is for withdrawing the money. So totally three. And for each transaction, gas fee is required? Yes. Okay. And one more thing. Right now, we have shown it on the offshore data. But do we have any local setup of Ethereum blockchain or is it pointing to the any test network? No. So the one I showed you here is a local Ethereum network. It's not. Yeah, it is Ganesh. Yeah. And this solution is specific to only the public blockchains or the lead support private also? No, I will come to that. So I think the Peron blockchain, the Peron protocol itself is blockchain agnostic. And in the next section, I will be talking about what is under the hood. And in there, I will explain you that it works on most blockchains. And what are the blockchains it currently works on? It actually works on more than just Ethereum even now. Okay. Why? Because I'm working in the hyperledger fabric, which is a permission and private blockchain. So I'm just interested to see if you get that into the hyperledger. Yeah, it works with fabric as well. So I will explain that to you in the next section of the presentation. Okay. Yeah, that's a great presentation. Yeah. Okay. So do we have more questions? Okay. If there are no more questions, then we could go to the next part of the presentation, which is let's look under the hood. So I was talking about Peron state channels and then IOP state channels. And then I was saying, it's possible that I delegate every transaction of the device to the user or the owner of the device. So in this section, I would like to show what is making that work because such a delegation should ensure that what are the rules in which the device should share the state with the owner. And in all cases, there should not be any loss of money or funds because these are all economic transactions. So I think what makes IOP state channels work? The first part is that we split the on-chain and off-chain components of the Peron protocol, which means initially we were having this. So this was the first one which we were having, that there is that is device one, which is talking to the smart contract. And inside the device two, there is a node which is running locally. And then this is talking to the smart contract. So in this case, both the on-chain and off-chain parts are coupled into a single piece of software. So what we did was that we went from this architecture to here, where we said, okay, we will allow this one. So entity two stale thing is still here, that is also possible. But what is also possible is that we will take the funding component and the watching component and make it a separate services. And then we will use a gateway through which the device can talk to these funding and watching components. So this is what you saw in the demo that the user was having whenever there was a funding request or need to watch the channel or withdraw funds that was done by the user, whereas the device is doing only off-chain transactions. So that split of responsibilities and functions, that is what the first thing we conceived. And then we try to implement that. And I think all of the work that we do is open source. So this is also from the repository called Proposals, which is also open source. So you can also go here if you are interested in diving much deeper into this and want to know more. So this is the first part, separating the funding and watching components away from the main component software and being able to run it separately, which means the device has now very less requirements. And the second component is designing a protocol for externalizing the watcher service. Yeah, so what happened here is that, okay, we externalize the watching component here. But what does this mean? Because with funding, it's very simple. I want to say to the funding component, please fund this channel, then it is funding it and then giving the response. It's very simple request response thing. And if you want to settle a channel, I will say here's the latest state, settle it, and then it settles it and then gives you the latest state. So it's very simple. But with watching component, it's not the same, because the device is continuously creating new off chain states. And it needs to send this off chain state periodically to this watching component. Because if it is not sending, then when there's a dispute, the watching component does not have the necessary information to resolve the dispute. So we needed to work with some protocols, work out some protocols to see how that works. So then we said, okay, here's the main component or the car, then there's the watching component or the user's dashboard, and then there's a blockchain. And then we modeled in each phase what are the interactions involved and what are the rules, and what is the timeframe in which they have to exchange states. And if they don't, what happens and so on. So then we implemented this protocol which we described here. So this is what enabled us to externalize the watching component. So this was the second key aspect of what made the IoT state channels work. And third is using a very standard scheme for encoding off chain messages. Initially, we were using a custom encoding protocol for sending off chain messages between two participants. But then later we switched from the custom protocol to protocol buff, which means even if we are doing implementations in multiple languages, for example, if we do a current implementation is in Golang. But if we do an implementation and say see or rest in later point in time, then also we can just not rewrite every encoding schemes, but we can just use protocol specification and generate steps for it. And finally, the fourth part is use the external funding watching component in a practical way. And that is what I showed you in the demo. This one is not yet released, but we plan to release it in the coming weeks. Yeah, so I think that gave you a good insight into what were the thoughts, designs and protocols which made the components work. And this brings us to the final part of the presentation, putting things together. So what exactly is the parent framework and what is concrete about it? So the first part is the parent go parent, which is the core SDK, which consists of a very central piece of software, which is parent protocols. Here we implement all of the funding, watching off chain, every protocol is implemented in this component. And this is pluggable. So what is pluggable in this parent protocol core is that first is the chain. So whatever blockchain you want to use along with parent protocol, that is pluggable. So I will show you what chains are possible. And then the second pluggable component is networking and serialization. So parent protocol does not specify even how the off chain transactions should be carried out, like what networking should be used, how should be serialized. All of this is not defined in the protocol, it just defines the rules on how the state should be created, but how the networking and serialization happen is still left open as a plugin. And the third part is persistence. So on the off chain, when you're creating new states, whether you want to persist it using some database or just flat file, or you don't want to persist at all, it's everything up to your choice. And that is also left open. So now for each of this, we have multiple options. So for chain, I think currently we support four different chains, Ethereum, Cosmos, Polkadot and Internet computer. I think as of today, we also have a fabric backend. So there's also 51 that is supported right now. And all of this, you can find details in our Hyperlogel Labs projects. And with regards to networking, I think currently we use TCP networking for P2P, but I think we will start using more other protocols for the need arises. And for serialization, as I said, initially we were using Perron format, which is very custom home-baked format for encoding. But then later, since we wanted to do implementations in multiple languages, we moved to protocol buffers. And finally, for persistence, we use level DB. So we just persist every state using a level DB database. And this is the core part, which is having a central piece and many pluggable components. This is the component that you would look into if you really want to play with the Perron protocols and build your own custom use case. But for most users, I think there is a second component, which is called Perron node. What Perron node does is that first it takes the Perron go Perron framework and configures it. So that's the bottom part. It just configures one possible option for each of the pluggable component and it makes it ready to use. On top of that, it creates a session so where you can manage channels. So if you're having 10 channels, then it collects all the 10 channels of yours together. And then if it manages your keys, wallets and option IDs appear. So for example, if you're going to talk to going to a charger and talking to it, how do you know that's the charger? So those kind of option IDs are also maintained by the session. And then on top of that, it provides some use case specific APIs. For example, in this, I showed your payment use case. So the payment specific API, because I said Perron state channels itself has any arbitrary possible logic. So the API is very generic. But if you want easy to use APIs, then you maybe maybe want to make it very specific to a use case. That case, you can just build it onto a session. And then there are remote API interfaces, and then also the remote funding and watching services. These are optional. So any of these components you can enable or disable or even modify according to requirements and then use it. So this is where everything comes together. And the Perron node was what I was showing you in the demo, that charger was running its own Perron node, user was running his own Perron node and the car was running its own Perron node. And the front end was just connecting to the Perron node via gRPC remote interface for API. And different Perron nodes were running in different configurations. For example, the user's Perron node was only running funding and watching service, but the cars and charges was running everything. So that brings us to the end of the presentation. And in the near future, we plan to focus on implementing a light plane for deep embedded devices. So what I showed now was software running on Raspberry Pi, which is also still a very capable computer, but we are looking forward to develop a very light client which can run on devices which are running bare metal or running real-time operating systems which are like C or Rust kind of implementation. And finally, we are looking for contributions. If you find the concept relevant, feel free to get in touch with us. If you'd like to evaluate, check out our tutorials, demos, online videos that we have done before. And even reach out to us if you don't find what you would like. And last, if you're interested in joining our development efforts, always welcome. Just get in touch with us and we can see what we can do together. Thank you. And it's open for discussion. And Manu, we do have two questions from the YouTube channel. Yeah, sure. Let's see here. So really quickly, and we just have a few minutes left from Mike V. He says, can you speak to the cybersecurity aspect of this? How is this protected from attacks such as those seen previously on Ethereum with the 51% attack factor? Yeah, I think the parent protocol itself is not having such things because obviously the blockchain with which parent protocol is working with, they have, they still have the same scenario, whatever is existing before parent protocol is still existing even when parent protocol is working or not. But within the parent protocol, you're actually creating a space for two participants to sign both states. For example, when the car is sending a payment to the charger, car is creating this new state, it is signing its own, and then it is asking for the signature from the charger and the charges signs, then only the state is valid. So actually, both the persons involved are signing on the state. So I think the scenario is a bit different. The same arguments of on-chain does not apply here because here we are creating consensus by getting approval from all the involved participants. And only after the approval from all involved participants are coming, we accept that that is the latest state, and then we go to next state. And in order to identify which is the latest state, you saw that we are also using version numbers. So whenever you create a new state, you increment your version number. So always state with higher version is later than the state with the lower version number. And this, every party should ensure check when they are signing. So when you're signing, you should see that this version number is greater than any other older version number. So that's just your due diligence in the software. So this, all these rules are implemented in the software. So this is what we call as the Perun off-chain protocol, like these rules according to which the new states are created. Great. Thank you, Manu. And we have one other question here from UV on the YouTube channel. And I'll ask the second one first. What are the benefits of use for microtransactions in between users? Yeah, that's a very good question. So one advantage of microtransaction is that it reduces the risk. For example, if the car is sticking to the same use case, if the car is trying to purchase 10 units of electricity, and if it is saying that you give me 10 units of electricity and I will pay the money for it, it can either be prepaid or postpaid, but in either case if it's prepaid, then the car is already paying the money for it. And if the charger is not giving the desired quality of service, then there's a problem. And 10 euros is like a huge money. So it needs to resolve the dispute and make things fair. So then it needs some mechanism for dispute resolution and everything, which is making it a little cumbersome. On the other hand, if you go for postpaid payment, then the charger is giving all the electricity to the car. But then when it wants to pay, if it is not paying as per the agreement, then also it's a problem for the charger. But when you break this one big transaction into 10 small transactions, your risk becomes less because you're purchasing one unit of electricity. If you're satisfied with it, you pay for it. If you're not, then you walk away right away. So by making the transaction smaller, there is a lesser counterparty risk. Great. Thank you so much. And thank you, UV, for asking that question. Unfortunately, we are out of time here. I want to thank Mano very much for his time and participating in the Hyperledger Foundation webinar series. And if I'm going to share my screen here, and Mano, if you can stop sharing your screen, that would be great. Thank you so much. Thank you. All right. And I want to encourage everyone to go to our Discord channel and you can continue this conversation, ask more questions, as well as get more involved in the Hyperledger Foundation. And we do have another webinar coming up on November 10th. Build your identity solution using Hyperledger Aries. I encourage everyone to join that, as well, if it interests you. And thank you so much for your time today. Thank you, Mano. Yeah, thank you all. Bye.