 Yeah, so the meeting is in recording. So in today's webinar, we have the parent labs. And is a hyperlapse project and is contributed by the boss. And there is another German company. Yeah. This is this is a render. So in this webinar, you will have getting hands on the parent stretch channels, which is a hyperlapse project. And we have Matthews, yes, software architect for the polycrypt and the monology software engineer boss. And so this is a kind of contribution to the hyperlapse and in the session, we will cover the basic about the parent stretch channels and getting hands on and how the IOT could be integrated with this parent stretch channels. So yeah, over to you. Okay. Hello all. Good morning. Good afternoon. So I'll just share my screen. You can save it once it's visible. It's my screen visible now. Yeah, looks good. Okay. Yeah, welcome you all to this talk. In this talk, myself, I'm an orange. I work at Bosch as software engineer and have my colleague here, Matthias who works at polycrypt GmbH in Germany. So we will together be presenting you on our approach towards scaling problem and blockchain. And the background or premise of this work is the observation that it is very expensive to do transactions on chain now. For example, if you look at the transaction throughput of Ethereum, it's roughly around 15 or 15 to 20 transactions per second. And it takes quite a long amount of time in our minutes of five minutes or so. And costs are also too high, too high in the sense that it does not allow many applications like you want to go to shop, buy something and pay for it with cryptos. Then it's not possible because the transaction costs and confirmation times are not suitable for that. Also, you can see the graph on the right, which shows the gas price over time for Ethereum. So gas prices like how you pay for your costs on Ethereum blockchain. And this is also fluctuating, which means the cost of transaction is also not stable. So this actually makes blockchains insufficient for many use cases. For example, you want to do, as I said, for data trading, if you want to buy something and then pay for it with cryptos, it's difficult. Or if you want to do, say, micropayments. So you want to do a large number of small payments over a small amount of time, then also this is not possible or same goes for high frequency trading. So we thought we will come up with some solution to address this problem. Also, one of the more particular and special premise that we want to focus on is industrial IoT use cases. So in industrial IoT, we actually have a range of devices, such as a car to car charger transactions, or you're using any tool that is very expensive and they're like you're renting the tool for usage and then using it and paying for it. Or within a factory where many people share a shared shop floor, where there are machines from different companies, you want to make transaction between these two machines. So these are certain use cases that we are looking at. And in these kinds of use cases, if you see, there are three properties. One, the transaction value and frequency. So the transaction value is very small because you want to ensure that you are taking little risks. For example, if you're charging for one hour, maybe you will not pay upfront for one hour, but you will pay for every minute for the energy that you consume. And so you have a low value transaction and these transactions need to be doing at high frequency. Second is the connectivity aspect. So when we talk about Internet of Things, we have a range of devices, some like that are always connected to the cloud like highly connected devices. Some are residing in some local network like a company VPN or a corporate network such that they cannot access the direct internet but have a limited accessibility. A third set of devices could be that they do not have internet access at all, but they're able to talk to some parent device and through that get some internet access. For example, you can think of your smartwatch. Most smartwatches don't have internet access, but they do get data from internet through your mobile phone. So we have a range of connectivity options that we should support. And the third is the resource constraints. So in most cases, IoT devices are tailored towards certain use cases and they are computing power and memory are mostly confined only to that use case. So we do not have the option to have a large code print code print. So we also need our solution to have a very minimal code print on the device side. So these is a background on which we base our work on. I'll hand over to Mathias who will explain how the Perun protocol is what it is and how it works and how it addresses these constraints that I've described. Yeah. Thank you. So yeah, let me try to explain a bit how the technology works at a high level and then also go into detail what we implemented and how the Perun framework looks like in terms of implemented components and how you can use it and Manu will then go even more into detail and show you a demo. So how does the technology work at a high level? The goal is because transactions on the layer one on the blockchain itself, which is the upper part, are costly. We want to shift as much of the transactions to the layer two, which is an off chain part and this is a direct communication between two potential clients. So now when they, these two clients now decide to open such an off chain channel, they have to transmit an on chain deposit and open the channel by that. So there's one on chain transaction for opening the channel. And now once the channel is open, they can transact basically with the same security guarantees as on the layer one, as if they were at a transaction on the blockchain, but now they can do it peer to peer with the Perun channel technology. And there are basically no transactions costs because you're transacting off chain. And you basically have no transaction limits in terms of throughput or confirmation times because as soon as you agree on a new state off chain basically this just involves two signatures by both parties. And the transaction is confirmed. And once you're happy with the off chain state, let's say after a few transactions, then you can decide to register your state on the blockchain. And then it will be materialized on the public blockchain again, and your funds will be available once you settle the register state. So this is a general idea so all the basic transaction or the, the valuable transactions will go to the second layer and only opening and settling the channel will be on the blockchain itself. And the important part is that our protocols guarantee that this happens with the same security guarantees as if you were transacting directly on the blockchain, almost the same security guarantees. You also get some certain certain level of privacy for your transaction because the blockchain will not see how many transactions you did and what amount was there they will own the blockchain will only see the end result. And furthermore, this allows us to do some interesting other. I applied to some interesting other use cases where maybe client one. So Alice here, for example, on the left side and Bob is the client to on the other side, and they may actually sit on different blockchain so Alice may, maybe on a Ethereum blockchain and Bob may be on a hyper ledger that blockchain on a hyper ledger fabric. And they can still open the channel with this technology load. This is a pretty cool side effect of this technology. With that, I think then, of course, our one of our challenges the project, especially the use case that Bosch is addressing is that we want to port it to the IOT use case that a man was was explaining was describing. And this now our clients are not human users, but they may be machines such as a car and a charger so the car wants to pay the charger in small amounts depending on how to charge us. And the car might not be directed directly connected to the blockchain, but it may be connected to a note which acts on behalf of it and has the blockchain connection. And these are some abstractions that we need to implement in order to make this technology work for this IOT use case. So, concretely was does the framework consists of at the moment. So here we want to give you an overview at the core we have this includes the core protocol logic. Then we have an implementation of Ethereum smart contracts for running this protocols on the Ethereum blockchain. The clients can either if they are have a lot of resources they can run directly using the state channel SDK the GoPro library, or if they are light clients they can use the Perot note which was developed particularly by Bosch to make light clients work and make the burden. Basically the connected connect really get removed some of the connectivity requirements from the clients and also take some low additional load from the clients to connect to the blockchains and this is what the what the Perot note achieves. And one, I think important aspect of our library of the core library how we decided is that we decided with modularity in mind so we have decided the components of our library which is a blockchain interface. And a logging interface in an abstract way so that the core logic of the of the framework the protocol logic does not depend on any specific implementation or any specific blockchain, but it only depends on this very abstract interface and this allows us to either plug in the Ethereum blockchain but also you could plug in a hyper ledger fabric blockchain and the same goes for the persistence the logging and the network layer so you can either plug in a simple TCP IP socket dialer, or you can plug in a lippy to P dialer which gives you additional connectivity option. So this is a core feature of our framework how we designed it. And I think this is it from my part and now Manu will go a bit more into detail what they have been implementing for the Bosch use case. Yeah, as Mathias explained before, the node offer the intimacy co state channel logic, like the Peron SDK implements the co state channel logic and node on top of that provides some user facing functionalities. For example, if you need to, if there are two people Alice and Bob and they need to talk to each other, they should know who they are their identity should be confirmed so you need some mechanism to get how to contact them off chain and what is their on chain address and things like that. So for that we have a component called option identity provider. So this component provides the identity of whom you're interacting with, and it can source anything from different so places for example currently we use simple file where you put all the details in a file and then provided to the node, but this can also be an external service, say some identity service or even some identity based blockchains like Hyperletter Indie which provides an SI based networks. Second is key handling. So for creating signatures on the states that are created by the SDK we need to use some kind of wallet that can be like a local Ethereum wallet a key store wallet or an external service again. So those kinds of functionalities are offered by the key handling module. And on top of that we provide a session so the session kind of manages all the channels belonging to the user and manages the state of it so that the user need not maintain any state he can just interact with what information he has. So on top of that we provide a user API, which kind of has an easy way to interact with the node and the clients interact with the node through the user API. If we get just one step deeper, what we do is that in the user session, we still keep the channels as generic state channel so you can implement any kind of logic if you want game channels, then you can implement the game logic or the payment channels what we will show later in the demo that also can be implemented. And on top of that the user API we have an app specific API, which actually just translates this user API does not maintain any state, but it just translates what the generic state is to that application specific state. And when any changes made to that state, it tries to validate the application specific logic. And we have a remote interface. So if you have the option to use the Perot node in two ways, one you can directly import it as a go package. It's the first implementation is in Golang. And you can use the package directly from the use a app specific API, or you can just run the Perot node in as a like a Damon software and then interact it with a remote interface. So in the demo I will be showing both these ways how to use Perot node in both of these ways and also point you to resources where you can write out on your local setups. Yeah, one addition here which which I forget to mention is that you cannot just send payments as a manual hinted. You can also impose arbitrary transaction logic so you can also play a game on depending on the on the outcome of the game that is played off chain payments will be done so there's arbitrary transaction logic possible on the afternoon there as well. Yeah, sorry. Yeah, sure. Yeah, that is something we currently support so I will also show you later after the demo through the event that during the code interview how you can actually plug in your logic without modifying any kind of Perot or blockchain specific code. So in the demo, I will present four splits of the screen. So bottom two splits will be Alice and Bob respectively, and in the top split we will have blockchain on one side and then we will have Perot node on the other side. So now I'll present my demo screen. So as I said we will start up Perot node here in the screen. And then we will start the blockchain node here so I'm using ganache CLI node, just the demo purpose. So yeah so we have the ganache CLI node here. So once we start the node I think we should deploy the contract one so this deployment is done at once only once. So if you're using a public blockchain then the contract is already deployed and this is a singleton instance. So what you will basically do is always use that contract but since we are using a local setup I used to deploy for the first time. So here's the connect screen where this client is completely independent of Perot node. So this actually interacts with only the remote interface. And now I'm connecting to the node from both these clients which will set up the key handling and the identity provider and everything for these two clients and then present us with a screen where we can do some transactions. Yeah so if you look at the screen on the top we have the address or on-chain address of the user and then we also have the on-chain balance. So it's currently 99.94 ethers because we some ethers for you was used for sending the contracts and then we have the time so this time we will use it as reference later. So in the command box you can type whatever command for example actually the auto supported commands are provided as placeholder text in the command box. So first we can open a channel with Alice with say initial balance of 10 and 20. So you can see that both of them got a notification. So here it says it's waiting for peer and here it says it's waiting for user and it's blinking. So I can accept this channel. What you can see is that once I accept there are two on-chain transactions that are created. So one each for each party. So one transaction is for funding of Alice and other is for funding of Bob. So once the channels are funded they move to the transact phase and the balance of these parties are shown here. So I will open just one more channel so that I can show demo easier way open with Alice another channel with five and six of initial balance and I will accept this channel as well. So once the channels actually we have two channels in the transact phase so to send payments we can use send API so send on channel number one, say one ethers and we can also request instead of sending like getting money from the other users or request on channel number three ethers. So then I can accept or reject so I will accept one of the request and I will reject the other one. So you saw that once I accept the transaction the status is marked as accepted for both parties and then the current is the proposed balance is made as the current balance. But when I reject that state just reminds for the user to be shown but you can see that the latest state reminds the oldest state itself and the version is zero. The other thing is that if you I you can also like not just not to respond for example I'm sending on channel one to Bob, say point to ethers. And you can see that there's a time out in the second field which says 142611 so we will wait until the time out expires. So then you can see that it will also be said that we are as rejected. So this time out is flexible we can set any time out like from seconds to minutes to hours depending on the use case. And if the other user is not responding within the time out which happens in this case, then the channel will the party who sent will recognize that the peer has rejected because he has chosen not to respond. So this way you can actually make a large number of transactions I think since we are using the GUI it is very like it is limited on how fast we can enter the transactions. But if you use a code to interact with the Perot node and make this transaction then you can make thousands of transactions per second. So once we have made the transactions and you want to close the channel we can say I want to close channel number one. So once I issue the close command the other party this is special update so I will just accept the update and then explain you what's happening. So in that special update you can see that the version is marked as 2f. So f means final. So the final update implies that the other party has chosen to close the channel and he has asked Alice to agree if that channel can be closed on the blockchain as the final state. The advantage is that if we agree to that state then the blockchain understands all the involved parties have agreed that what the final state of the channel should be and it allows the channel to be directly closed. If you see in the first slide we had four phases open transact register and settle. If we agree to the final state then the final state can directly be registered on the blockchain without waiting for a time period so it was very fast like we can see how it happens if we don't agree. I will close channel 2 and in this case I will reject the update I don't agree it. So when I reject you can see that it's waiting for a time out to expire. So the idea of this time out is that once we want to close a channel and one party both parties have not agreed what is the final state of the channel. Anyone party can directly post the latest state to the blockchain and the blockchain will provide a time out duration for both parties. It will say there is a fixed time in this case it is 10 seconds but we can make it also into days or hours. For this amount of time you can wait and if any other party has the latest state that the first party is misbehaving or posting older state then you can challenge the registered state on the blockchain and that challenge will be handled by the smart contract. So once that state expires then the channel will be settled and the balances will be withdrawn. So that is the difference you can see that the second channel was settled with a newer state to it but the first channel was settled with the actual state which is zero. So I think this is the end of the demo. So this tool we have published in our code repository we also have readme so you can check out our project and try it on your systems as well. Now moving to the demo part so in this part you saw that we had a GUI where we did this demo in which we were using a remote gRPC interface. As I explained you before we have a session which handles state channels in a very generic way and in top of that we build applications so that you can find in the app directory and so this is a payment tab that we have currently now. And for example you want to say send payment so say for example you want to open payment channel. So the only thing the what app does is that it gets the user data and then translate it into the generic data which the session API expects and then sends the request so it is a very simple logic and a very lightweight layer. So if you have any arbitrary logic that you want to implement all you want to do is that you can add a simple app here and this should be like very few lines of code and it involves only your logic nothing more than that. And rest all is handled by the core abstractions so you can see this app is very lightweight and a very simple logic one. So this way you can actually implement things and you also have an example that we have described so you can find it as payment underscore test. So in this example we have described how to use the app API directly without running a node so you can just import this package and use it. So that you can actually try it out and you can run this on your system as well for example I will run it now. So here we will start. I will just close this one. And then in this we will run the test. So what this test does is that it actually does what we just tried out in the GUI but in a scripted way. So it will open a session for both Aliz and Bob, and then it will open a channel between them and trans out and transack on the channel and then close the channel. Yeah, so these two transactions are corresponding to the deployment of contracts. Now it is the setup phase. Yeah, now we have Alice session is open. Yeah, now we have session for Bob and Alice and Bob have opened the channel. They have made one transaction so you can see the update balances here. Then they have registered to the blockchain and closed. So you can if you want to develop any app then you can just copy the payment app to in the app folder and then modify the logic and then try the testing system and then integrate it with other systems that you want to use. Yeah, so the second abstraction is the remote interface that you saw in the previous slide. So this app is just a code way and then you have an API package in which we have currently implemented the gRPC interface. And this is also a very lightweight layer. So what this does is that it, for example, we will again see the open payment channel API how it is. So what this does is that it just calls the app API as you can see here with two to three lines of code just to call the API check the error and that's all you need not do anything more. And then package it according to your remote interface. For example, here I am packaging it according to the gRPC interface. So by having these two lightweight layers, it allows us to implement a large number of arbitrary app logics on a very abstract core framework that we have designed. So this way it is very extensible for a large number of use cases. So coming back to the slide, we are at the end of the presentation. To sum it up, I think we assured how the SDK and the node are designed in modular ways. And some of the features that we are planning to come up with are additional blockchain back ends support for some other blockchains. Second is ability to do cross chain transactions. This is a work in progress. And third is the light node or library for embedded devices. So what you saw was that in the previous slide, if you looked here, the car and the charger might be in a remote area. For example, if the charger will be a stationary thing that it might always have connectivity to the cloud. So it can always listen to blockchain and everything, but the car might not be the case. So what we do is that we want to split the parent software into two pieces. One is the transacting piece, which is using only the transaction phase and put it into the car. And then the remaining phase for the funding or for the registering phase put it in the cloud. So then the car can contact the cloud for funding the channel or for watching for changes in the channel. But the transaction alone it can do directly with whichever party it wants. One of the interesting approaches if we look at enterprise use cases, for example, fleet management, etc. Because if you're having a fleet of 1000 cars, then there is no need to put money store money in every car's wallet. You can always use the funding and registering in the cloud and you can just give the car the access to transact off chain, which also is a better security. So that brings us to the end of presentation. And in general, this is an open source project that we have posted under hyper ledger labs. So you we welcome everyone who is interested to participate in the project and start contributing in terms of using the project is a great contribution in itself. And you can also start getting involved. And I think we have, we are open to question answers now. Yeah, okay. Thank you. So I have some questions. So I think this project being using so many, any boss applications in the maybe manufacturing process in IoT with IoT or just the kind of kind of music kind of open source project. What is the status actually. So this project itself is completely independent. It is not relating to any internal Bosch component. But we are using it in some of the other research showcases. So there is a project, research project in Germany called RNA 2030. So the idea of this project is that you have a very advanced shared shop floor where different companies will have their machines. And this machines are designed to not produce a single product, but they can be configured to produce variety of products. So they have to interact with each other and make a large number of transactions and do a lot of contracts. So in that context, we want to use, we are using this better note to handle the contracting and transaction, transacting capabilities. This will work along with other things. For example, each mission will have its own identity on an SSI network say SSI is self sovereign identity. So this will work in constellation with the SSI networks and agent framework. So each machine can have also have software agents which will make decisions on behalf of it. So this will plug into that whole ecosystem and in that research showcase. Okay, okay. And another question, I think there's a question like, can you please share the link for this project you just mentioned. That's okay. And another thing, so this parent channels is a blockchain agnostic, right? So it's only support the Ethereum or support the any hyper-legible any other projects too? Or is it just only Ethereum? No, in design, it is completely blockchain agnostic. As Matthew explained, the core logic is led in a way that does not depend on any blockchains. And currently it supports Ethereum, like you can try it out, whatever demo I showed was based on Ethereum blockchain. But we are also working right now, we have started working on another blockchain back in and soon you can see support for the second back end as well, which is non Ethereum back end. You will soon see support. So we are currently working on a blind foreground for implementing a polka dot back end. And also, yeah, potential other back ends are planned about it depends a bit if we get funding for this and what are our priorities so nothing determined yet polka dot is one of the interesting candidates and type alleged fabric is something that we are also considering what not sure how the funding situation there is. So as a company, we also need to basically look where we where we can get grants and have the development supported. So this influences our decision. So one other aspect is that it depends on community interest if there is somebody who is interested in using a particular blockchain back end with their own. Then we can also consider implementing that. I have a question. Yeah, yeah. Hi, it was a nice presentation. Thank you. And I wanted to know how is the reconciliation happening is it part of the beer and framework or is it the underlying blockchain reconciliation itself will work. Reconciliation in the sense like if there is a any transaction before accepting it, the other party disconnects or whatever the network disconnects something like that. Yeah, so what happens is that for initial phase so when the both parties want to open a channel they communicate with each other, and only when they respond they agree to what the initial state of the channel should be. Then they contact with the blockchain so then deposit their particular amounts what they agreed and the initial state that they agreed to the blockchain. So once this is done it's in a transact phase and the transact phase it does not matter so if you have connection you can make transaction if the other party was not responding in the demo I showed one place where the transaction expired. So you can consider that case where the connection has been lost so you sent a transaction to other party, but the connection is lost. In this case what you can do is that you can speak outside of the system to other party to say tell him to come on back come back online, and then respond to this transaction. But if that is not possible if that is not at all possible then what you can do is that you still have the latest state which is agreed the previous state. That state you can post to the blockchain without even talking to other party. So when you post that state to the blockchain what happens is that blockchain will register the state as the state that is to be settled and then wait for a time out. So this time out provides a window for the other party to come and check the online check the blockchain, whether older state or other malicious state for example they have transacted three states. And if Alice is posting a second state, which is actually malicious behavior, then Bob can during the waiting period come online check that an older state was posted and then post the latest agreed state which is three. And then blockchain will see that which is the latest state based on version numbers because version numbers are monotonically increasing. So based on that it will resolve what is the latest state and then settle that state. So this dispute handling happens on the blockchain. It is not the pre-run framework, it is basically the underlying blockchain itself will handle it. No, that just happens in the current contracts on the blockchain framework. So blockchain framework has two parts. One is the SDK that is running, providing you a way to interact with the blockchain and an SDK that is allowing you to transact with the other party. The second component is the smart contracts that reside on the blockchain. And whatever I say I'm talking to blockchain it means I'm talking to these current smart contracts. The framework is, I'm sorry, yeah. Basically, yeah, so the last resort is going to the blockchain. So when you're not able to resolve and the framework is helping you in the first approach would be you resolve the current state of chain. Once you send the state and you get a signed update and the state is agreed. But if the other party is not responding off chain, then you would tell the framework. Now you have to go on chain. And the framework does that for you. But there, you basically have to decide as a user when is the moment when you want to go on chain and So you're adding an extra logic on the framework itself to do to resolve the initial conflict is what you're trying to do. Yes. It's pretty simple. I mean, you propose an update, and either you get a response and if you don't get a response, you will notice it and then you have to decide do you want to basically dispute that now. Yes, or do you maybe try to update again. That's that's up to you. And the dispute process will be will be done for by the framework for you so we just to the state. And then the framework will wait for a bit, and then you can. Okay, so what is the condition on which the framework will transfer the dispute to the underneath blockchain. Yeah. Was I audible. Yeah, so the condition is that so when you want to close the state so all this dispute resolution and everything happens only when you want to close the state. So in the demo I showed that we can transact for a number of times. But once we decide we want to close we just send a close command which actually instructs the framework that you have to close the state. And the first thing the framework will try is to send a closing update to other party which you saw with a symbol, which actually says that the state is final. And if the party is responding in the time period then it acts with that state like it directly settles. But if the framework sees that the other party is not responding or he's missing, then it automatically goes for settling the channel on chain, like register and then waiting out for the time period and then closing. Okay, that is one part. So the second part is that on the other parties side also one core requirement for the Peron protocol to work is that the parties Peron node should be running at all times. Because if you're not watching the blockchain at all times then you're at risk because when this dispute resolution is happening your blockchain your Peron node should be watching. So your Peron node keeps watching on the back end and when it is watches that the wrong state is registered it is not intimidating the user it will just go on dispute that wrong state because there is nothing the user should tell the Peron framework already knows that if that state is not responding. Okay, I'm totally with you guys what you told me now. But why have this reconciliation on two levels, why not have only on one level because if let's say if the framework was not able to resolve, let's abandon it there and there why do you want to give another chance to the underneath blockchain or in another case if the framework is not able to why not give the condition to only the underneath blockchain to resolve it and then bring it back to framework. Why are you doing double checking is my next question. Yeah, sure. That is a very good question. So the reason why we are trying to finalize the state of chain and then registering on blockchain is that that is to save both cost and time. So when you're so if you see the actual dispute resolution logic we just assume we are not agreeing any of chain final state we just registered to the blockchain. In that case what we have to do is that first we have to register so that involves one blockchain transaction. Second we have to wait for a time period. So this window provides all other participants to see if the registered state was final and dispute if there is there is not final. So that window period is there. Third, once that window period expires we have to settle the channel. So that is second blockchain call. So here we have two blockchain calls and one large time window. So if we agree to the final state on the blockchain on the off chain, then we can do away with this we can directly set in the channel because both the parties have agreed offline and we also don't have the window because these parties have agreed so it is an optimization. We have reduced time and we have reduced cost. Okay, got you. Thank you. Thank you. Thank you. Thank you. It was a very good question. Thank you. It was a very good question. We can go ahead. Manjiri right or Yeah, I think we have one answer from Manjiri Nanda Kumar sorry. Yeah, there is a question from Bankata. Where will this recording be available. Okay, that will be available on the Hyperledger YouTube channel. Hello, can you hear me. Yeah. Sorry. So, I have like four questions. So let me start. So the first question is about the motivation you have. So, can you explain me the performance you got after implementing this platform protocol. Okay, so we haven't deployed it to our actual use case. But if you just run the tests on your system, you can see that your transactions are like the order of thousands or maybe 10,000 per second. It really depends only the only restricting factor is how fast you can communicate at the party and how fast you can make signatures only that is the time constraint. There is no other time component involved. And, I mean, can you, did you do something like how many offline transactions per minute is possible for the person not to handle something like that. Did you do something. Yeah, I think we have some tests, but not in the real scenario, maybe in that scenario I think we had thousands of transactions per second. Yeah, so we have. Let's see. So, actually, I don't have specific performance tests on a large scale system but we have performance tests on a Raspberry Pi and even there you get over 50 transactions per seconds. Okay, and I think what we have seen on larger devices with with other tests that you can do 1000 signatures or more per second. So, if you take this number and translate it to the general setup. So, definitely on a larger system than a Raspberry Pi you definitely get more and I would expect in the realm of 1000 transactions per second but it's a good point to be we should actually verify that once again and maybe some of my colleagues have done that and I'm not aware of that. So this is the number that we've seen in some scenarios where signatures were involved and where basically, yeah, which, which gives you an idea how many signatures you can generate and this is what we think is the performance bottleneck and the communication and what is the underlying signature scheme you're using is like ethereum or it's something. Yeah, exactly. For this, the most we are using ethereum signatures itself for option science. Okay. Okay, so ECDSA basically. Yes. Okay. Are you considering using some other signature schemes in the future. And so one thing one advantage with using a CDSA is that when we want to verify the signature so when we post the states go to a blockchain for register open face, then that means we done signature verification also happens. So like verifying ethereum complaint signatures is much easier on chain in terms of both cost and implementation. So we are sticking to it now but if the need arises that by using some other signature scheme we get an advantage then it's quite possible. Okay, and as Perun is working offline so how does the transaction validation happens offline. Yeah, so the Perun app so the Perun node, as I showed you in the previous thing that we have a core state channel logic that any session and on top of that we have an app. So this app is what defines your logic so how you can make the next state and everything is defined by this app. Perun node itself is not doing anything about the validation. No in the Perun node there are different components one component is where so in the Perun node the app component is responsible for doing all this validation. Okay. And it can be modified you mean. Yes, it can be modified we can make any kind of. Okay, okay, okay. And okay the second question is how does the light clients trust the Perun node basically. Yes, that's a very good question. So the light clients are not usable in all use cases so if you look at the previous use case that I was talking about for example of leak management or platonic. These are very industry specific or industrial issues use cases where a company has a large number of devices or assets under its control, and it wants each of the asset to have its own transaction capability with other devices. So in this scenario you can see that there is always no reason for the devices to trust its companies designated person. So we can use some identity logic say self or not certificates to designate whom it should trust, and then we can establish that trust environment. So that is how we actually see that the light notes can trust the funding and the watching notes which interact with the blockchain in actual the further step we're currently looking into the scenario where the light client doesn't trust the note and this would be something like a web browser which doesn't trust the server to basically you want to keep the keys with the client in the in the browser wallet. Basically, you can still do that, but then you, the note should do a call back a signature call back to the client so whenever the note will need a signature, it will not have the keys for that. But it will ask the client to sign this on central section. So basically this then releases or removes this trust assumption on on the note. Yeah. Okay. And then the important question for the last is you explained in the first the second slide saying that scaling challenges right. So how does and you are mentioning about industrial IOT also so consider there is a smart factory, or I don't know a smart city for example, and there are IOT devices installed across the city and they are sending data consider it as the data so they're sending continuous data to this blockchain network. So, I mean, implementing this scaling solution as a pattern. So, do you already have that use case in mind or is it already developed. I don't know the status right now. Yeah, sure. With regarding to your question I think one of the use case that we are very focused we working on is a shared shop floor use case. So that is actually a huge, so it's a multi company project it's called I blocks. Yeah. So I also presented a talk before you can I will present the link to this talk after this call. So in that we have explained about that use case also in detail. So there what we try to do is that there are different companies, for example, Bosch is there Daimler is there then BMW is there. And there are a lot of big companies and these big companies have big shares in that shop floor like huge missionaries and production lines. And when some order comes in that is a very customized order. So this machine will then make contracts to each other that I will finish this component and give you at this point of time for this cost and all of these things happen. And we have an agent framework a software agent for doing that. And once that is done, then this transacting layer so making this contract and agreeing to what is the state and everything is implemented on this parent layer, and then the actual big production begins. So once all the production is done and the payment happens again the parent layer is invoked and the payments all happens, and it's resolved so that is one use case I think we are working on to refer to that resource if you are like more interested in the details of that use case. Yeah, thank you. Yeah, also you can contact us through email, we can get in touch for further discussions too. Okay, yeah, so I mean I was considering the existing ethereum and there are light clients. So, we need this pattern in between, like a pattern node to to make the system work for high volumes of transactions and that's the motive I was also looking for like IoT devices and data and how the underlying blockchain could handle, I don't know, 1000s more than 1000 requests per second or per minute. So, yeah, because light client light client is completely dependent on the full node, and full node, suppose the full node has like only 50% of its capability to handle the light clients. So, that's kind of a performance issue also, you know, it can drop a light client or it can just don't serve serve the request coming from the light client so that was a basic issue. Yeah, you refer to the Ethereum light client or. Yeah, Ethereum light client. Okay, I think that is exactly the place we are looking at and that is also the reason we keep the framework in a very flexible way. For example, if you're having a more powerful device say a little more powerful than Raspberry Pi, then you can actually run the parent node also like you can just import this go package, and then directly run the parent node so you don't have a note to interact with you can just use the parent package. So, but if you're having a very constricted device say your smartwatch which is very less capable. You can run the node on your smartphone, and then your very transacting client on your smartwatch and then you can make them interact via a Bluetooth for like funding and resolving or something like that you can. It supports all of those fancy constellation so that is the thing we are looking at when we are designing this framework. Okay, yeah, yeah I mean sounds sounds good and looks like there is a lot of things that could be possible to do in this scenarios. Yeah. Thank you. Thank you so much. It was very good. Thank you. Thank you. So, any other questions from anyone else? Okay, I think no. Just a question you haven't shared the link of the project you mentioned at last. Yeah, sure. Thank you. I can chat it on the chat and we can also push like post it back in the meetup page as well. The links to the project and other resources that I was referring to. I can post all back into the meetup page. Yeah, thank you. Yeah, sure. Yeah, okay. Yes, then I think then we can wrap up right. Yeah. So, thank you. Thank you for the presentation. So, this recording will be uploaded to the hyper ledger YouTube channel and said I will set the link on the internet. Okay, thank you very much for hosting us. Yeah, thank you very much. It was really interesting discussions and yeah, thanks for the question that's right. And yeah, contact us if you want to more details or want to work with us or work with the product if you have questions about the framework. Yeah. The project link is on the screen but we also share it as like text links in the meetup page.