Hyperledger Foundation Hyperledger Member Webinars, 19 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Hyperledger In-depth with Bosch: Enabling micro transactions between IoT devices using the Perun

Description

In an attempt to find an effective solution for enabling IoT devices to do micro transactions, we, the Perun team, have developed a framework based on formally verified, second layer protocols for direct peer-to-peer, off-chain transactions. Potential use cases by Bosch, Hyperledger member company, are: a machine selling its data generated by its sensors to another machine or an electric car purchasing electric power at a charging station or machines on a shared industry shop floor wanting to work together. In each of these contexts, machines may want an infrastructure to make low value transactions at high frequency with instant confirmation. Additionally, the machines could also have constraints on compute, storage and network connectivity. In this talk, we take a deep dive into understanding the problem and then present our solution for it using the Perun state channel framework. We will also be presenting a live demonstration.

Our Hyperledger In-depth series features live demos, tutorials, and stories from the battlefield! Members share learnings from their projects, and field all the hard questions about the pains and triumphs of working with DLTs. This is a great opportunity for you to get involved, come prepared with questions and voice your opinions.
Join us in building a stronger community!

----
Hyperledger – Open Source Blockchain Technologies

Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use

Discord: https://discord.gg/rVCn4j7UFd
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory

Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter

Follow-us on Twitter @Hyperledger

Learn about Hyperledger Membership: https://www.hyperledger.org/about/join

#Hyperledger #Blockchain
License
Creative Commons Attribution license (reuse allowed)

A

Oh right, everyone uh we're going to get started um again. Thank you for coming to the hyper Ledger Foundation webinar um and in depth with Bosch today, enabling micro transactions between iot devices using the parents, State Channel framework, and today we have mono AP joining us from Bosch. He is the blockchain and abundance systems. Engineer uh and he's 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 uh promoting and creating the safe environment.

A

um So please follow the code of conduct that we have when interacting with each other today and throughout uh in the code of conduct, can be found either on the wiki or on our web page, and today's webinar um and all hyperledger webinars um are under the antitrust policy, which can be found either on the wiki or on our events. Page um in this session will be recorded So.

A

If you want to go back to review uh today's discussion, um you can do that as well as it is a live stream uh coming from either Zoom or our YouTube page and um to follow the webinar. Today um we will be sending you um sending you the webinar as well, so next um we encourage these webinars to be as interactive as possible. So please help and cultivating um cultivating this interactive session. By raising your hand, asking questions uh and in the zoom box, when you raise your hand, I will unmute you.

A

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 um and without further Ado. We can get started.

A

And mono uh I'm going to stop sharing my screen and let you take over here.

B

A

B

A

B

Are yeah okay, perfect, so I will share my screen. Foreign.

B

A

B

Yeah so hello and welcome to everyone um who are joining from different time zones good morning, good afternoon or good evening, depending on where you are um today, I'll be talking about one of the interesting things we have been working on, which is enabling microtransactions through uh between iot devices and and um this we have been developing as a pattern open source project. It's a joint collaboration between Bosch and polycrypt gmbh and um yeah. So to begin with, I will start with a very um familiar context. I think you'd have come across this context.

B

If you're um hearing um talks on 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 um charger wants to give the car some power. Electricity, electric energy and and Carr wants to pay for it and using this scenario of a machine trying to um interact with another machine, I would like to take you through the Journey of how we started around with their own.

B

Like what was the problem statement, we started with what were the nuances we were looking at and um what was the solution we are thinking about, and how did we go about achieving the solution and what does it State now and how are we looking forward? So that's the whole gist of the presentation for the next 60 minutes.

B

um So to begin with, um let's compare these two scenarios when um humans are involved in economic transaction and machines are involved in an 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, um they arrive with their car at the charging station, then they make an informal agreement. uh This can be as simple as saying to the charging station operator.

B

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. Um This can also be two ways like either prepaid before charging or postpaid after charging, whichever is okay, both are fine and finally, the human status station, and that's the end of the scenario.

B

Now what if we were to remove the human um 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 and future. Also just remember.

B

This is just the example use case that I picked 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.

B

So it's very um simple agreement, but if you look closer to it, um it's it's very hard for Missions 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 with missions, because missions don't understand, um pressed the same way as humans do so. How do we make agreements and how do we handle disputes?

B

So these were the two major questions that we startled 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 uh scalable systems, we talk about internet scale, I'm, saying everybody.

B

Everybody is connected on internet, maybe 80, 90 or even much lesser, but that's fine, some very good percentage of populations, character, internet and we want to account for every person on 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.

B

So iot scale is going to be much larger than the internet scale, so we needed some uh mechanism that would work at really that scale like not even scales of today but much orders of magnitude. More than that and fourth one is um how to deal with iot Device constraints, so the iot device could have several constraints that it's it's having limited um energy, a limited power consumption because it's running on battery or it is not able to always have very good uh network connectivity or it is having compute ornamental limitations. Something like that.

B

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 uh steal money from it, so I would always try to keep it safe.

B

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 Missions 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 so how do we tackle that? So these were the problem um context which we started out with and um before I move on further.

B

If you have any questions, um I would like to take that and then go forward.

B

Yeah, 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? uh What are the technical requirements? um 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.

B

Let's use algorithmic dispute Solutions, and um each of this we 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 file to scale. As I said, the infractions can be at very high scale. Then then, what is possible today? So we thought if we are going to design for that scale, then most of the interactions should be uh peer-to-peer. If not all, then the third point is deciding to run on constrained devices.

B

So in this case we need to consider the limitations on compute memory, Network and power consumption. This would should be an important factor in designing a solution and the fourth one is limit or eliminate the need for Missions to hold money. So here we said we can use some form of pre-authorization.

B

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 or some form of reauthorization, so that even if the card is stolen, the um the authorization hold and hold which the car holds is not is very less likely to be misuse because it can be spent or used only in a very specific context.

B

So we thought, could we think about something like that and um 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: is this like it? It makes possible one to write, um 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.

B

But now we work with a lot more blockchains, but uh 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 a 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 pair one and uh in the next slide? I will explain you how parent protocol works yeah. So this brings us to the um second part of the webinar, which is the solution um so before we move forward.

B

If there are any questions we could take and then go forward.

B

Okay, perfect I'll go forward, so um the thing with parent State channels is that um say you have a charger and you have a car. So these are not on the blockchain they're like blockchain layer, and then there is blockchain, say ethereum, which is the top layer, the blue one, and we deploy the parent smart contract on the ethereum blockchain, and what happens is that the car goes and meets the charger in in the charging station, and then it interacts with the charger saying.

B

um Okay, um this is the um 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 gonna get and once they make this agreement, they go to blockchain um and say to the parent smart contract. Here's the agreement.

B

We made you please fund this um agreement on this smart contract. So what happens is if the car is willing to pay 10 euros for 10 units of electricity? Then um it sends the 10 euros to the parent 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.

B

Then the channel is funded and now uh the uh car and the charger can enter the transact phase, which means uh the car is now allowed to spend 10 euros with the charger according to the rules which they agreed. So then it can say: okay, I will 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.

B

So that way um they can pay each other, and but all of this is happening, direct peer-to-peer, it's not involving any Central server or blockchain, um and once that is done, what happens is that they again go to blockchain and say here is a transaction. It's complete.

B

um 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 transfer 10 units to the charger. So now the contract will uh take the 10 euros that was blocked in the contract and give it all to the charger, um and if for this, it would consider the proof which the charger and the car send, and so this ensures that everything is happening according to the game like like, according to the rules which they agreed upon yeah.

B

So this was the parent 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 uh most of the transactions direct peer-to-peer so that we succeeded, but the other problem is that um the car and the Charger needs to talk directly to the blockchain and when they are transacting of 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?

B

The charger will have the latest of chain state which both of them agreed to which it can post to the blockchain and say hey. This is the latest date: I have the charge. Car is not responding anymore, so settle um the uh dispute and it will verify that smart contact verify that that state is correct and then it will give a grace period, say uh 10 seconds or 10 minutes or whatever you can configure for the other person to challenge.

B

um If this is a fake transaction, then the other person can challenge with his own proof, and then um 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 Xperia expired. So um this is what I'm going to resolve.

B

So in this uh scenario, it is important that um all the participants are continuously connected to blockchain, which means they should have continuous, very good network connectivity and and um yeah. They should have good power consumption as well, because otherwise they cannot be always connected to Internet. So these two limitations were there, and that is what we try to work on in our next Improvement of their own State channels, which is spread on iot state channels.

B

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 device. So we said we will take advantage of this um 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?

B

The car is no more talking directly to the blockchain, but it says to the owner: hey I went to the station. I I made this 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.

B

Here's what you need to do the transactions and everything, and then the user gives the card the authorization and now the car can make transactions as it did before. But the interesting thing is that it just needs to send um periodically like every one second or two second, or maybe every 10 minutes which you can configure. It needs to send periodically the latest state, which was a great option to the user, so that in case any dispute arises, the user will send the latest say to the parent, smart contract and resolve it.

B

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 of the iot device to be always connected to the blockchain, and uh this solved most of our requirements.

B

So if I go back to the slide of requirements, we solve most of it, the first one we used ethereum already. So then we got enforceable digital agreements and algorithmic dispute resolution. Second, one uh we made um the transactions mostly peer-to-peer um that way this could scale even if at an iot scale.

B

Third thing is that uh in the iot state channels, we move 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 power consumption requirements.

B

This solution can still work and finally pre-authorizations um so 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 or create or doing the option transactions, which is only like pre-authorization Keys.

B

Even if these keys are lost, there's nothing lost, because um 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 uh four of the requirements that we had, and next part is the demo before.

A

uh I'm I just want to jump in really quickly. We did have a question on the YouTube channel um regarding the transactions and the negotiation there and uh the question of what. If there is some sort of technical uh issue that you run into in terms of payment, is that refunded and how does that? How does that work.

B

um Yeah, that's a good question.

B

um So if, if you look at the protocol itself, it takes care of every part that, if some or, if at some point in time like if, when you're setting up the channel or when you are making option transactions, if some point in time, if there is um loss of network connectivity or some other devices down, then you already have all the information um to to safeguard your interests.

B

For example, you block the money, say: 10 euros, you blocked and uh zero Euros, the other person blocked and your agreement is that your cell you're buying one unit of electric energy for one Euro every in every micro transaction and now after buying four units of electrical energy say the charger is down. It's it's completely out of network or something. Then you have the proof that um the for you have paid for the four things and you can send this proof to the blockchain and the blockchain will wait for some time.

B

As I said the challenge period to check if the charge is coming online or if it is trying to challenge your your decision. If not, then the state is resolved. According to the proof that you gave to the blockchain so that way um at any point in time, if there's a technical glitch, you could still recover what has happened until that point.

A

Great thank you Mano uh and thank you for asking the question. If anyone else has any questions, um I did allow everyone. um You can just submute yourself and speak directly to mano, to ask questions or feel free to write questions in the chat either on our Zoom. Live stream or YouTube live stream. Thanks.

C

B

um Yeah hi Ramesh.

C

Hey: what's the difference between the option, data and on chain data.

B

Yeah so um on chain. uh So can you be more specific about the question.

C

uh Can you go to the previous architecture which you have shown yeah.

B

C

um This one, uh no not this one, one by one more.

B

Yeah, so this one.

C

uh Yes, exactly uh layer, one and Layer Two.

B

C

Go ahead, so what exactly the difference between the you know uh layers? Actually, what exactly it will do? What kind of data it will store the layers actually.

B

Yeah sure so layer one is the blockchain, so this is like um any other, like the normal case when you're deploying smart contracts and blockchain and you're sending transactions and everything this is stored permanently on the blockchain, but um because this is like a very non-trusted layer. It's also expensive, like you have to pay some gas fees and everything for every transaction, but Layer Two is like based on the um open State. Like you open this Peron State Channel using the parent smart contract, then you can directly make create new States.

B

So, for example, the car can say uh the initial balance was 10, comma zero. Now um you gave me one unit of electricity, it can add the proof and it can say the new balance is nine comma 1, 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.

B

So this way they can create n number of chain states by the direct peer, prepare instruction interactions and there are defined rules for how these states are created and what states are valid and what's not valid and everything and those rules are what we call as Parent Channel and uh whatever state is created. According to this rules that can be later used for resolving the dispute on or even like resolving it collaboratively on the blockchain.

B

So that is what happens between layer, 1 and layer. 2.

C

But if I query my balance, will it hit layer, 2 or layer 1.

B

um So whatever you're doing on Layer Two, it does not affect your own chain balance unless you settle.

B

A

B

Just that you're maintaining a local uh 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 uh um channel is can is, is possible to be resolved uh on the blockchain at later point in time.

B

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 you can, without any problems, uh uh update this option. Balance on the blockchain.

C

B

Yeah, thank you. I will also show you this one in this, 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 of chain balance and how the changes in each step.

C

Yeah, that would be great thanks.

B

Yeah I will come to that in the demo part.

A

Thanks from bash and uh Mano, we have a few other questions here, one from Joey on magalu. uh He is asking: how can the user of an iot device manage their payments or enable scheduled activities? How are triggers for the microtransactions set up.

B

Yeah I think I will I will I will show you this part and demo as well, how how this interactions work, but in short it can be anyways. For example, you can have a mobile app to which you receive every notification when you, when a device wants um 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 this rules, then you can do it's it's. There are white possibilities.

B

It's not fixed yeah, but I will show you one possibility in the demo section.

A

Okay, great and then James comp asked, does Perrin enable asynchronous operations like JavaScript promise.

B

uh Can you be more specific about the question because I'm not able to fully understand it.

A

Let's see here, James I, don't know if you are.

D

Able to continue I'm wondering, for example, can um can parent? Can you do an asynchron on a 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 parents to do that. For example, did you have an outstanding JavaScript promise to monitor the cost of electricity and um and then it would trigger when it gets below a certain cost, and then the car could charge at that point.

B

Yeah, you could do that so so the interesting thing is that it's it's um the parent channel is is: has it's a very um it's a state Channel, which means you can write any arbitrary logic um in it and then make the transactions. According to that logic, so you can say that um okay, I'm hooking up my car with this charger, but then uh it's not charging immediately I'm buying 10 hours of time or something and I will consume charge.

B

Only when um certain criteria is met and then you can configure the title to be whatever it is. So all those fancy things are possible. Okay,.

D

B

Yeah, but whether it makes economically viable or that's a different issue but I think technically it's it's possible.

B

A

Thank you. Thank you. Mana yeah.

B

Do we have more questions, or should we move forward not.

A

Yet so I think we're okay to move forward.

B

Yeah perfect, okay, then I will move to the demo section.

B

Yeah in the demo, I will show you a screen with four splits. um Each split having a terminal and the um top right split is the blockchain terminal. uh Here you can see just some text scrolling.

B

um The purpose that I showed 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 um in the top left split. um That will be the user's portal. So this is the portal of the own iot device owner, which is basically the car owner, and here um I have set it in such a way that it's just Auto approving every request. But you will see the data like.

B

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 site that you can watch the bottom put splits the left side. I will have the uh put a 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.

B

I will start the error note for the car and the charger here and now, if you look at it here, so this is the car owner's parent dashboard, and this is the car terminal, and this is the charger terminal, and this is the blockchain, so here I hit connect.

B

um So all of this are not running on a local machine. Everything that is representing the car is running on a Raspberry Pi. Everything that is representing a charger is running on another Raspberry Pi. um This blockchain is running on this computer and the car owner's parent dashboard is also running on this computer. So it's like a really network setup. It's not a local setup.

B

C

Wait to the same network.

B

um Yeah, all of this are connected in the same uh VLAN.

B

But I think, since we use IP addresses, if you're able to um make your device visible through internet, then you can also connect across the internet. It should be fine yeah. So if you look at um the uh 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 100 eat and then here we have the time- and um here we have some Channel data. I will show you uh when I open channels. What is coming up here.

B

Similarly for the charger. Also, we have some balance so I think it's having some 99.99 ether balance. So now, let's say the car goes to the charger and it wants to open a 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 uh three and zero. So it says I want a Channel with a balance 3 either for me and 0 for the car for the charger, and then it gets a request which it can accept.

B

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 point, something which means three Euros has been. A three ethers has been blocked in the smart contract.

B

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 three and zero eat, and then it was automatically approving the request. So funding was successful. Second I was telling you about the fact that the iot devices should continuously watch for the blockchain.

B

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 the charger is started, and that is also shown here so now the channel is in pansex face uh here in the car. It says the pier is the charger. Similarly, if you look in the car charger just dashboard, it says it's also in the ransack face with the peer being the car and the balance is here, and the version is here so now.

B

Let's say on the charger sent one unit of electricity to the car and it wants to pay for it say so. I send on channel number one one ether like this, and then it gets a request. It can accept it.

B

So now what happens? Is it's accepted now you see, the balance has changed. If you look down change 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.

B

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, um the cost balance is one and um 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.

B

So now um the transaction is complete because um shakas balance is zero and charges balance is zero in the meanwhile, if you have noted in this case, the car is sending every state um that it creates of chain to the uh um to the car owners, because then, if there is any dispute on the blockchain, you can always use that latest state for a dispute resolution.

B

But if you are I'm 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 uh um at least one transaction, for example um 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.

B

So this is the transact phase where the transactions are completely over and then this transact phase you see that there is no transactions in the blockchain, so all of this is happening of chain and even the on-chain balances is not affected. So now, let's say we want to settle this channel.

B

So in this case, I think the person who's uh most interested in setting 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 ghost register phase and it uh sends a request to the user which the user can accept. So once the user accepts it, it marks the new status version four and because both parties are agreeing to close the state.

B

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 said 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 statement that we want to close, and if you look um in the car owners dashboard, you saw that um Channel finalized off chain.

B

So this is what I said, as both parties agreed to what was the last of the channel and after that um the withdraw request was made on behalf of the car and then the channel was concluded on the blockchain and the withdraw 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 balanced did not increase it's like 96.9 and again. But if you look at the charger, it is like 102.99. So this is how the transactions work.

B

uh Maybe if you have some questions, um we can take it and then I will show you one more scenario which is more interesting.

A

And mono we do have a few questions on the YouTube channel again from Muhammad Abu Jabara um he's asking: where do you maintain the pricing table and how many power, uh how many power units are sold uh in tally.

B

A

B

um Sorry, can you repeat the question.

A

Sure so the first question is: where do you maintain the pricing table.

D

A

And then, uh and then the second is how many power units are sold initially and Muhammad. If I am not asking, this question um thoroughly feel free to.

B

So I think um this particular use case itself. Is it's not the real use case, like um just use cases chosen for illustration purposes, so I mean we don't care much about what is electricity price or something in fact, there's no electricity being exchanged between the devices so on. It's just for illustration that I use this 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.

B

That is quite possible if you're thinking about implementing this use case in real life, and uh we are the states that um how much power stores exchanged and everything is probably stored locally between these two parties, because the car knows how much power it receives, so you can keep track of it, and maybe there is some proof exchanged between the car and the charger on that part. So so that is very specific to the use case here. It's just used for illustration purposes, so there is no um exchange of electricity or anything.

B

No I hope that answer the question.

A

It looks like it thanks. Mono.

B

Yeah sure um so um now I come to 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 um just having one transaction and I accept this channel and then um I send uh one um 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's not it's!

B

It wants to drive away because it does not want to make this one either payment um reflected on the blockchain. So it 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 from channel two, and um so it's going to register face 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.

B

So then what happens is that uh both persons will wait until the time out. So the timeout you can see here was 42 seconds which has passed and after the timeout, the challenge. Duration starts. So, irrespective 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 register transaction and after that, the challenge duration is rated like in this case. It's 10 seconds.

B

I have set it to 10 seconds for easier demo purposes and after the 10 seconds um still both parties withdraw the 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 starting, malicious, the channel can still be settled.

B

The protocol safeguards your interests, but just that it is, it involves little more money because you need money for this better solution or and little more time, yeah. That's that's the end of the demo.

A

And Mano uh Ramesh has another question here: he's asking how many transactions are created in the blockchain.

B

um Yeah, so in the blockchain, when you open the channel, uh one transaction is created for funding the channel and when you um close, the channel um two print sessions are created, one is for registering and the others will be throwing the money. So totally three.

C

And for each transaction gas fee is required.

B

C

Okay and one more thing right now, we have shown it on the option data, but uh uh do we have any local setup of ethereum blockchain or is it pointing to the any test Network.

B

No, so the one I showed you here is is a local ethereum net node. It's not.

C

B

Yeah, it is ganache yeah.

C

And this solution is uh specific to to leave the public blockchains or the will. It support private, also.

B

uh No I will come to that, so I think the parent um uh blockchain it's the parent protocol itself is blockchain agnostic and in the next section I will be um I'm talking about what is under the hood and in there I will explain you um 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,.

C

uh Okay? Why? Because you know I'm working in the Apple Ledger fabric, which is a permission and private blockchain, so I'm just interested to see to get that. You know it.

B

Works for it works with fabric as well. So so I will explain that um to you in the next section of the presentation.

C

Okay, yeah and that's a great presentation.

B

Do we have more questions.

B

Okay, if there are no more questions, then uh we could go to the next uh part of the um presentation, uh which is uh let's look under the hood. uh So we were I was talking about their own State channels and then iot State channels, and then I was saying um it's possible that um I delegate um every transaction of device to the user or the owner of their device.

B

So uh in this section, I would like to show what is making that work, because such a delegation should ensure that um what are the rules in which the the device should share the state with the owner and um in all cases uh there should not be any loss of money or funds, because these are all economic transactions. So I think uh what makes iot State channels work. The first part is that we split the on chain and off chain components of the parent protocol, which means uh initially, we were having this.

B

um So this was the first one which we are having that um there was. There is a device, one which is talking to the smart contract and uh inside um the device too. There is a node which is running locally and then this is talking to the smart contract. So in this case uh both the on chain and on of 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.

B

Two style 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.

B

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 of chain transactions so that a split of of of responsibilities and functions. We we. That is what the first thing we conceived, and then we try to implement that and and I think. All of the work that we do um is is open source, so this is also from the repository of called proposals, uh which is also open source.

B

So you can also um go here if you want, 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 uh the device has now very less requirements, um yeah, so yeah and, and the second component is uh designing a protocol for externalizing The Watcher service um yeah. So what happened here is that okay, we uh we um externalize the watching component here.

B

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 data state.

B

So it's very simple, but with watching component, it's not the same because the uh device is continuously creating new of chain States and it needs to send this off chain State um 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.

B

So then we said: okay, here's, the main component or the car, then there's the watching component or the users dashboard and then there's a blockchain, and then we modeled in each phase what are interactions involved and what are the rules and what is the time frame um in which they have to exchange States and if they don't what happens and so on. So then we implemented this uh protocol, which we described here. So this is what enabled us to externalize the watching component. So this was the second key aspect of uh What uh made.

B

uh The iot state channels, work and uh third is- is using a very standard scheme for encoding option messages. Initially, we were using a custom encoding protocol for sending option messages between two participants, but then later we switched from the custom protocol to protobuf, which means even if we are doing incrementations in multiple languages.

B

For example, uh if we do a implementation, current implementation is in golang, but if we do a implementation in CSC 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 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.

B

Yeah so I think um that um gave you a good insight into what were the um thoughts designs and protocols which made the um components work, and this brings us to the final part of the presentation putting things together. So what exactly is? uh Is this the parent framework and what? What is concrete about it?

B

um So the first part is the Peron go perone, which is the core SDK, which consists of very Central piece of software, which is parent protocols. uh Here we Implement all of the funding watching of chain. Every protocol is implemented in this component and this is pluggable. So what is pluggable in this param protocol core is that first is the uh chain, so whatever blockchain you want to use along with parent protocol, that is pluggable, um so I will show you what chains are possible and then the second packable component is networking and serialization.

B

So parent protocol does not specify even how the off chain transactions should be carried out like what network you should be used. How should be hosted to be serialized? All of this is not defined in the protocol.

B

It just defines the rules on how the state should be created, but how the networking acceleration happen is still left open as a plug-in, 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 purchase it 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.

B

Currently we support four different chains: ethereum Cosmos, polka, dot and internet computer I. Think as of today, we also have a fabric backend, so there's also fifth, one that is supported right now and all of this you can find Details in our hypology 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 from any devices and for serialization, as I said. Initially, we are using parent format, which is very custom, home-baked format for encoding.

B

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 purchased 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 parent protocols and and build your own custom use case, but for most users, I think um there is a second component which is called pero node.

B

What pero node does is that first, it takes the parent, go parent framework and configures it. So that's the bottom part it just configures one possible option for each of the applicable component, and it makes it ready to use on top of that. It creates a session so where you can manage channels.

B

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 ID is appear so, for example, if you're going to talk going to a charger and talking to it, how do you know that's the charger so so those kind of option IDs are also maintained by this session and then on top of that it provides some use case. Specific apis, for example, in this I, showed you payment use case.

B

So the payment specific API, because I I said parent 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- or maybe you want to make it very specific to a use case that case you can just build it on top of 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.

B

So this is where everything comes together and the pero node was what I was showing you in the demo that a charger was running its own parrow, node user was running his own paranode and the car was running its own pero node and the front end was just connecting to the para node via grpc remote interface. If for API and different parent nodes were running in different configurations, for example, the users better node was only running funding and watching service, but the cars and charges was running everything.

B

So so that brings us to the end of the presentation and in 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 like running bare, metal or or running real-time operating systems, which I would like see or rusts kind of implementation.

B

And finally, we are looking for contributions if you find the concept relevant feel free to get in touch with us. If you like to evaluate check out our tutorials demos online videos that we have done before um and even reach out to us, if you don't find what you would like and last, if you're interested in joining a 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.

A

And mono, we do have two questions from the YouTube channel. um Let's see here so uh really quickly and we just have a few minutes left um from Mike V. He says: can you speak to the cyber security aspect of this? How is this protected from attacks such as those seen previously on ethereum with the 51 attack Factor.

B

Yeah I think um the parent protocol itself um is not having such things, because um obviously the blockchain with which parent protocol is working with they have they still have the same uh 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 um um to uh sign both States.

B

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 strike nature from the charger and the Charger signs. Then only the state is valid, so actually both the persons involved are signing on the state, so I think um it. This scenario is bit different.

B

um 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 in all participants are coming. We accept that that is a later State and then we go to next state, and you know order to identify which is the latest State.

B

You saw that we are also using version numbers, so whenever you create a new state, you increment, your version number so raise a state with higher version is, is later is later than the state with the lower version number, and uh this every party should 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.

B

So this is what we call as the parent of chain protocol like these rules, According to which the new states are created.

A

Great thank you mono, and we have one other question here um from UV on the YouTube channel and uh I'll. Ask the second one. First, um what are the benefits uh of use for micro transactions in between users.

B

Yeah, um that's a very good question, um so so one advantage of microtransaction is that um it reduces the risk, for example, if if the car is extinct to the same use case, if the car is is trying to purchase 10 units of electricity and if it is saying that um you give me um 10 units of electricity and I will pay the money for it. It can either prepare a postpaid, but neither case if it's prepaid, then the car is already paying the money for it.

B

And if the charger is not giving the desired um quality of service, then there's a problem um and then you 10 euros is like a huge money. So it needs to resolve the dispute and then make things uh fair. So then it needs some mechanism for disputal solution and everything which is making it Liberty cumbersome.

B

On the other hand, if you go for postpaid payment, then um 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 or 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.

A

Right, thank you so much and thank you Evie for asking that question. Unfortunately, we are uh out of time here. I want to thank mono very much uh for his time and participating in the hyper-ledger foundation, Foundation webinar series and, if um I'm going to share my screen here and.

C

A

If you can stop sharing your screen.

B

Yeah yeah I just thank.

A

You so much thank you all right and.

A

I I want to encourage everyone to go to our Discord Channel um and you can continue. This conversation ask more questions as well as get more involved in the hyper Ledger foundation, and we do have another webinar coming up on November 10th uh build your identity solution using hyper Ledger Aries I encourage everyone to join that as well. If it interests you- and thank you so much for your time today and thank you, mono.

B

Yeah. Thank you all bye.