Hyperledger Foundation Hyperledger India Chapter, 29 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Getting hands on Perun State Channels (Hyperledger Lab)

Description

A recording of a virtual meetup hosted by the Hyperledger India Chapter on May 29, 2021 about the Perun lab.

Perun framework is a layer 2 scaling solution for blockchain. It is jointly developed as a Hyperledger Labs project by the “Economy of Things” strategic advance engineering project at Bosch Research and by PolyCrypt GmbH. Designed to be blockchain agnostic, it can be used on top of any blockchain platform to accelerate decentralized applications and lower transaction fees. It specifically targets high-frequency and low-value transactions.

In this talk, the speakers will present a brief overview of the Perun framework focusing on how it enables the use of blockchain in IoT devices with limited resources and network constraints. It also includes a demo followed by a hands-on tutorial describing how you can try out the framework and integrate it into your projects. In the end, there will also be an AMA.

More about the Perun lab is at: https://github.com/hyperledger-labs/go-perun

----
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

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 #HyperledgerMeetups #Blockchain

A

Yeah so meeting is in recording, so uh in today's webinar we have the pattern. Labs parent is a hyperlapse project and uh is contributed by the boss and uh there is a another german company.

A

So let me holy crap.

A

This is this: is the agenda so in this webinar you will have getting hands on the pyramid state channels, which is a hyperledger left project, and we have matches yes, software architect for the polycrypt and the manual software engine at bosch, and so this is the kind of contribution to the hyper layer left and in this session we will cover the uh basic about the current state channels and uh getting hands-on and how the iot could be integrated with the discipline stretchiness so yeah over to you, medicine.

B

B

Hello all uh uh good morning, good afternoon, uh so I'll just uh share my screen. You can save it once it's visible.

B

Is my screen visible now yeah, it looks good, okay, yeah! Welcome you all to this uh talk uh in this talk uh myself, I'm mano ranjit.

B

I work at bosch as software engineer, and I have my colleague here mathias who works at polycrypt gmbh in germany, so we will together be presenting uh you on our approach towards scaling problem in blockchain, uh which is which we call it perron, and the background of our premise of this work is uh 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 or- and it takes quite a long amount of time in order of minutes or five minutes or so and costs are also uh too high, you're 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 uh cryptos.

B

Then it's not possible because the transaction costs and confirmation times are not suitable. For that. Also, you can see uh the graph on the right, uh which shows the gas price over time for ethereum.

B

So gas prices like how you how you pay for your costs on ethereum blockchain, and this is also fluctuating, which means uh the cost of transaction, is also not stable, so this actually makes uh blockchain insufficient for uh many use cases. uh For example, uh you want to assist for daily trading if you want to buy something and then pay for it with cryptos it's uh difficult or if you want to do say micro payments, uh so you want to do a large number of small payments over small amount of time.

B

Then also this is not possible or uh same goes for high frequency trading. So uh so we thought we will come up with some solution to address this problem. Also, one of the more uh particular and special premise that we want to focus on is uh industrial iot use cases.

B

So in industrial iot we actually have a range of devices uh such as a car car took uh car charger uh transactions or you're using any tool that is very expensive and you're, like you're, renting the tool for usage and then using it and paying for it or within us, like a factory where many people share a shared shop floor where there are uh machines from different companies, if you want to make transaction between these two messages, so these are certain use case that we are looking at and in this kind of use case, if you see there are three properties, one, the transaction, value and frequency.

B

So the transaction value is a very small uh because you want to ensure that you are taking little risk so, for example, if you're charging for one hour, maybe you will not pay upfront for one hour, but you will pay for uh every minute for the energy that you consume, and so you have a low value transaction and these transactions need to be done at high frequency.

B

uh Second, is the connectivity aspect. So when you talk about internet of things, we have a range of devices. Some like that are always connected to the cloud like highly connected devices. uh 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.

B

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 someone access. For example, you can think of your smart watch. Most smart watches, don't have internet access, but they do get data from internet through mobile phone. So we have a range of connectivity options that we should support and the third is the resource constraints.

B

So in most cases, iot devices are tailored towards certain use cases and their computing power and memory are mostly confined only to that use case. So we do not have the option to have a large court code footprint, so we also need our solution to have a very minimal code print on the device side.

B

So this is a background on which we uh base our work on uh I'll hand over to mathias. Who will explain how the parent protocol is, what it is and how it works and how it addresses these constraints that I've described.

C

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 parent framework looks like in terms of implemented components and how you can use it and mana will then go even more into detail and show you a demo.

C

So how does the technology work at a high level? The goal is because transactions on the layer 1 on the blockchain itself, which is the upper part, are costly. We want to shift as much of the transactions to the layer 2, which is an off chain part, and this is a direct communication between two potential clients.

C

So now, when they, uh 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 transacting on the blockchain. But now they can do it.

C

Peer-To-Peer with the peru 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 of chain, basically this just involves two signatures by both parties.

C

Then 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.

C

So this is the 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 uh certain level of privacy for your transaction, because the blockchain will not see how many transactions you did and what amount was there.

C

They will on the blockchain, will only see the end result and furthermore, this allows us to do some interesting.

C

Other um yeah apply to some interesting other use cases where maybe client one so l is here, for example, on the left side and bob is the client two on the other side and they may actually sit on different blockchains, so alice may may be on a ethereum, blockchain and bob may be on a hyper, lateral block chain on a hyperledger fabric and they can still open the channel with this technology, though this is a pretty cool side effect of this technology.

C

Yeah with that, I think then, um of course, our cha one of our challenges, the project, especially uh in the use case that bosch is addressing, is that we want to port it to the iot use case that amano was was explaining was describing, and this means now, our clients are not human users, but they may be machines such as a car and a charger.

C

So the car wants to pay the charger in small amounts, depending on how much it charges and the car might not be directed directly connected to the blockchain, but it may be connected to a node which acts on behalf of it and has the blockchain connection. So these are some abstractions that we need to implement in order to make this technology work for this iot use case.

C

um So concretely, what does the framework consist of at the moment? So here we want to give you an overview at the core. We have this.

C

Includes the the core protocol logic, then we have an implementation of a ethereum smart contracts for running those protocols on the ethereum blockchain and clients can either. If they are have a lot of resources, they can run directly using uh the state channel, sdk, the goparu library or if they are light clients, they can use the peru node, which was developed particularly by bosch, to make light clients work and make the burden.

C

Basically, they connected connect, remove some of the connectivity requirements from the clients and also take some low additional load from the clients to connect um to the blockchains, and this is what the what the parent node achieves.

C

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 designed the components of io library, which is a blockchain interface, that assistance interface, a network 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.

C

But it only depends on this very abstract interface, and this allows us to either plug in a theorem blockchain, but also you could plug in a hyperledger 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, a socket dialer or you can plug in a live p2p dialer, which gives you an additional connectivity options.

C

So this is a core feature of our framework. How we designed it- and I.

A

C

This is it from my part, and now mano will go a bit more into detail what they have been implementing for the bosch use case.

B

Yeah, as uh mathias explained before uh the node of the implements, the core state channel logic like the parent sdk implements the co station logic and node on top of that, provides some user facing functionalities, for example, if you need to, uh if there are two people alice and bob, and they need to talk to each other, uh they should know who they are. Their identity should be confirmed, so you need some mechanism to get how to contact them of chain and what is their engineers? And things like that.

B

So for that we have a component called option: identity provider, so uh this component uh provides the identity of whom you're interacting with and it can source from different places. For example, currently we use a simple file where you put all the details in a file and then provide it to the node, but this can also be an external service, say uh some identity service, or even some identity based blockchains, like hyperledger indie, which provides an in si based networks.

B

uh Second, is key handling uh so for creating signatures on these states uh that are created by the sdk. We need to uh use some kind of wallet uh that can be like a local ethereum, a wallet, a keystore wallet or an external service again, so those kind 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 the user need not maintain any state.

B

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 uh one step uh deeper. uh What we do is that uh in the user session, uh we still uh keep the channels as generic state channels, so you can implement any kind of logic.

B

If you want game channels, uh then you can implement uh 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 in 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 uh what the generic state is to that application specific state and when any change is made to that state, it tries to validate the application specific logic and we have a remote interface.

B

So if you have the option to use the pair 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, app specific api or you can just run the pero node uh in as a like, a daemon software and then interact it with a remote interface.

B

So in the demo, I will be showing uh both these ways how to use paranoid in both of these ways and also point you to resources where you can write out on your local setups.

C

Yeah one addition here, which which I forgot to mention, is that you cannot just send payments as amano hinted. You can also impose arbitrary transaction logic, so you can also play a game or, depending on the on the outcome of the game that is played off chain uh payments will be done so there's arbitrary uh transaction logic possible on the option there as well. Yeah. Sorry.

B

Yeah sure yeah, and that is something we currently support, so I will also show you later after the demo uh through the when the during the code interview how you can actually uh plug in your logic, without modifying any kind of peron or blockchain specific code.

B

So in the demo uh 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 pair on node on the other side. So now I'll present my a demo screen.

B

So, as I said, we will start a parent node here in this screen and then we will start a blockchain node here. So I am using cli node adjust the demo.

B

B

So yeah, so we have the ganache cla node here so once we start the node, I think we should deploy the contract once so. This deployment is done at once, only once so, if you're. uh So, if you're using a public blockchain, then the contract will already be 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 paro node.

B

So this actually interacts with it only through a remote interface and now I'm connecting to the node from both these clients.

B

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.

B

Yeah, so if you look at the screen uh on the top, we have the address on chain address of the user, and uh then we also have the on chain balance. So it's currently 99.94 ethers because we sum it as for you was used for uh uh sending the contracts and then we have the time so this time we will use it as reference uh later.

B

So in the command box you can type whatever command, for example, uh as actually the supported commands are provided as placeholder text in the command box. So first we can open a channel uh 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.

B

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 the other is for funding of bob. So once the channels are funded, uh they move to the transact phase and the balance of these parties are shown here. We 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.

B

So once the channel is actually we have two two channels in the transact phase, so to send payments we can use, uh send api so send on channel number. One say one is two ethers and we can also request instead of sending like uh getting money from the other user, so request on channel number two uh three ethers, so then I can accept or reject. So I will accept one of the requests and I will reject the other one.

B

So you saw that once I accept the transaction or 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 uh you can see that the latest state reminds the older state itself and the version is zero.

B

The other thing is that if you I you can also like not just choose not to respond. For example, I'm sending on channel one to bob uh say point to ethers and you can see that there's a timeout uh in the second field, which says 14 26 11., so we will wait until the time out expires.

B

So then uh you can see that it will also be said that peer is rejected. So this timeout is flexible. We can set any timeout like from seconds to minutes to hours, depending on the use case, and if the other user is not responding within the timeout which happens in this case, then uh the channel will the party who sent will recognize that the peer has rejected because he has chosen not to respond.

B

So this way you can actually make a large number of transactions. I think, since we are using a 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 payroll node and make these transactions, then you can like make thousands of transactions per second.

B

So once we have made the transactions- uh and you want to close the channel- we can say I want to close channel number one. So once I issue the close command, uh the other party, this is special update, so I will just accept the update and then explain you what's happening.

B

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 closer chosen to close the channel and he has asked alice to agree if that channel can be closed on the blockchain at the final state. The advantage is that if we, if I 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 uh closed.

B

If you see in the first slide, we have four faces, 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.

B

So when I reject you can see that it's waiting for a timeout to expire. So the idea of this timeout is that uh once we want to close a channel and one party, both parties have not agreed what is the final state of the channel? Any one party can directly post the latest state to the blockchain, and the blockchain will provide a timeout 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.

B

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 uh settled with a newer state 2f, but the first channel was settled with the actual state which is zero.

B

So I think uh this is the end of the demo, so this uh tool we have published in our code repository. We also have a readme, so you can check out our project and try it on your systems as well.

B

Now, moving to the demo part.

B

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.

B

As I explained you before, we have a co session uh which handles uh 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.

B

B

So uh 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 uh generic data which the uh session api expects and then uh sends the request. So it is a very simple logic and a very lightweight layer.

B

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.

B

So you can see this app is very lightweight and a very simple logic one. So this way you can actually implement uh things, and you also have a example that we have described so you can find it as payment underscore test.

B

So in this uh 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 system as well. For example, I will run it now so here we will start a ganache cli node. I will just close this one.

B

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 uh open a session for both alice and bob, and then it will uh open a channel between them and transact on the transact on the channel and then close the channel yeah. So these two transactions are corresponding to the deployment of contracts.

B

Now it is the setup phase.

B

Now we have alice session is.

B

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 uh to the blockchain and closed. So you can. If you want to develop any app, then you can just uh copy the payment tab to uh in the app folder and then modify the logic and then try the test and system and then integrate it with other systems that you want to use yeah.

B

So the second abstraction is the uh 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, uh for example, we will again see the open uh 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.

B

Just 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 according to the grpc interface.

B

So, uh by having these two lightweight layers, it allows us to implement a large number of arbitrary, app logics uh on a very uh abstract code framework that we have designed. So this way it is very extensible for a large number of use cases.

B

uh So, coming back to the slide, uh we are at the end of the presentation.

B

uh To sum it up, I think uh we showed how the mod the sdk and the node are designed in modular ways and some of the features that we are planning to come up with our additional blockchain back-ends support for some other blockchains. A second is ability to do cross-chain transactions. This is 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 uh be in a remote area.

B

For example, if uh the charger will be a stationary thing and it might always have connectivity to the cloud, so it can uh 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 fees, which is using only the transaction phase and put it into the car and then the remaining piece, the for the funding or for the uh registering phase put it in the cloud.

B

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, and this is one of the interesting uh approaches. If we look at enterprise use cases, for example, fleet management, etc, because if you're having a fleet of thousand cars, then there is no need to put money store money in every car's wallet.

B

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.

B

So that brings us to the end of presentation and in general uh this is an open source project that we have hosted under hyperledger labs.

B

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 a question answers now.

A

Yeah, okay, thank you.

A

Okay, so uh I I have some some questions, so I think this project being using so many any boss applications in the maybe manufacturing process in iot with iot or is just the kind of kind of poc kind of uh open source project.

B

What is the status? Actually yes, so this project itself is completely independent. It is not relating to any internal bosch component, but we are using it in uh some of the uh it is our research showcases. So there is a project. uh A research project in germany called arena 2013.

B

So the idea of this project is that you have a very advanced shared shop floor where different companies will have their machines, and uh this machines are designed to not produce a single product, but they can be configured to produce a 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 parent node to handle the contracting and transaction transacting capabilities.

B

This will work along with other things. For example, each mission will have its own identity on an ssi network, say uh ssi, selps or an identity, so this will work in constellation with uh the si networks and agent framework, so the each mission can have also have software agents which will make decisions on behalf of it. So this will plug into that the whole ecosystem, and in that research, showcase, okay, okay and.

A

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 uh this parent challenge is a blockchain agnostic right. So it's only support the ethereum or it supports any hyperledger of any other projects too.

B

No in design it is uh completely blockchain agnostic, as matthias explained, the core logic is written in a way that this does not depend on 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 uh right now. We have started working on another blockchain backend and soon you can see support for the second back end as well, which is non-ethereum uh back-end. It's not. uh You will soon see support so.

C

We are currently working on yeah, applying for grant for uh implementing a polka, dot, backend and also yeah potential. Other backends are planned, but it depends a bit if we get funding for this and what are our priorities, so nothing determined yet, but polkadot is one of the interesting candidates and hyperledger 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 and have the development supported. So this influences our decision.

B

So one other aspect is that it depends on community interest. If there is somebody who is interested in using a particular blockchain backend with peru, then we can also consider implementing.

A

D

uh Hi, uh it was a nice.

A

Presentation thank.

D

You and uh I wanted to know how is the reconciliation happening? Is it part of the uh p run framework, or is it the underlying uh blockchain uh reconciliation itself will work uh reconciliation.

A

D

The sense like, if, if there is a uh any uh transaction before accepting it, the other party disconnects or whatever the network disconnects or something like that.

B

Yeah, so what happens? Is that uh for initial phase? So when the both the 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.

B

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 send a transaction to another 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 tell them to come on back, come back online and then respond to this transaction.

B

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 timeout.

B

So this timeout provides a window for the other party to come and check the online check, the blockchain, uh whether older state or other malicious state.

B

For example, they have transacted three states and if alice is posting a second state which is actually a malicious behavior, then bob can, uh during the waiting period, come online check that an older state was posted and then post the latest ugly 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 uh what is the latest state and then settle that state.

B

So this uh dispute handling happens on the blockchain.

D

Oh, it is not the pre-run framework, it is basically the underlying blockchain itself will handle it.

B

No, that is happens in the parent contracts on the blockchain framework, so a blockchain framework has two parts: one is the sdk that is running, uh 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, when I say I am talking to blockchain, it means I am talking to these parent smart contracts.

B

C

Yeah, I'm sorry yeah, basically yeah, so the the last resort is is going to the blockchain. So when you're not able to resolve and the framework is, try is helping you in the first approach would be you resolve the uh the current state of chain. That means you send the state and you get a assigned update and the state is agreed. But if the other party is not responding off-chain, then you would tell the framework.

C

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 out, train and.

D

So you are adding an extra logic on the framework itself to do to resolve. The initial conflict is what you're trying to tell.

C

Yes, it's pretty simple, I mean in yeah.

D

Yeah thank you proposal.

C

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 the decision. Do you want to basically dispute that now? Yes, or do you maybe try to update again, that's that's up to you yeah and the dispute.

D

C

Will be will be done for by the framework, for you so register the state, and then uh the framework will wait for a bit and then you can uh okay.

D

So what is the uh condition on which the framework will transfer the dispute to the underneath blockchain.

D

B

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.

B

So in the demo I showed that we can transact for number of times, but once we decide we want to close, we just send a close command which actually instructs the framework that uh you have to close the channel and the first thing the framework will try is to send a closing update to other party, which you saw with the f symbol, which has it 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.

B

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 with register and then waiting out for the time period and then closing okay. That is one part.

B

So the second part is that, on the other party's uh side, also one core requirement uh for the parent protocol to work is that the parties apparel node should be running at all times, because if you are not watching the blockchain at all times, then you're at risk, because when this dispute resolution is happening, your blockchain, your payroll node, should be watching.

B

So your node keeps watching on the back end and when it is watches that the wrong state is registered, it is not intimating the user. It will just go and dispute the wrong state, because there is nothing the user should tell. The parent framework already knows that.

D

It's interesting, 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 in other case, if the framework is not able to uh why? Why not give the uh condition to only the underneath blockchain to resolve it and then bring it back to framework? Why are you doing double checking?

D

B

D

B

Yeah sure that is a very good question, so the reason why we are trying to finalize the state of chain and uh then registering on blockchain is that uh that is to save uh both uh cost and time. So when you are so, if you see the actual dispute resolution logic, we register, we assume we are not agreeing any op 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.

B

Second, we have to wait for 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 the second blockchain call. So here we have two blockchain calls and one large time window. But if we agree to the final state on the blockchain on the off chain, then uh we can do away with this.

B

We can directly settle the channel because both the parties have a great 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,.

D

Thank you. Thank you yeah. Thank you. Thank you. That was a very good question. Thank you.

A

A

B

Yeah, I think uh we have one hands up from manjari kumar. Sorry.

A

A

There is a question from bank: where will this recording be available? Okay, that will be available on the hyperledger uh youtube channel.

A

Hello, can you hear me yeah, yeah, okay, yeah, sorry, so uh I have like four questions, so let me start so. The first question is about the motivation you have so um can you explain me the performance you you got after implementing this protocol.

B

Okay, so we haven't deployed it to our actual use case, but uh if, if you just run the tests on your system, you can see that your transactions are like out of thousands or maybe 10 000 per second also, it really depends. Only the only restricting factor is how fast you can communicate other party and how fast you can make signatures only that is the time constraint.

B

There is no other.

A

B

A

Involved, uh I mean, can, can you did you do something like uh how many offline transactions per minute is possible for the people not to handle something like that? Did you do something yeah.

B

I think we have some tests, uh but not in the real scenario, maybe uh internet scenario. I think uh we had uh thousands to thousands of transactions per second.

C

Yeah, so we let's see so actually I don't have specific performance tests on a large scale system, but we have uh performance tests on a raspberry pi and even there you get over 50 transactions per second.

C

So 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. We should actually verify that once again- and maybe some of my colleagues have done that- and I'm not aware of that.

A

C

Is a number that we've seen in 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 uh communication. Roundup.

A

C

The underlying.

A

Signature scheme you're using is.

C

A

Or it's something.

C

B

Yeah, it's easy! Yes, for this demos,.

A

B

Are using ethereum signatures itself for off chain uh signs.

A

Okay, okay, so ecdsa! Basically, yes, okay, are you considering using some other signature schemes in the future.

B

Yeah, it depends so one thing one advantage with using icdsa is that when we want to verify the signature, so when we post the states go to blockchain for register or open phase, then that needs to be done. Signature verification also happens so like verifying ethereum compliance. Signatures is much easier on chain in terms of both cost and implementation.

B

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.

A

Okay and uh as peru is working offline, so how does the transaction validation happens? Offline.

B

Yeah, so the peron app so the parent node, as I showed you in the uh previous uh thing, that we have a core state channel uh logic that in 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 in this app.

A

B

A

Node itself is not doing anything about the validation you mean no.

B

In the parent node, there are different components. One component is where so in the parent node, the app component is responsible for doing all this validation. Okay,.

A

And it can be uh modified, you mean yes, so you can.

B

See it can be modified, we can make any kind of absence.

A

Okay, okay, okay and okay. The second question is: uh how does the light clients press to the pedal node, basically.

B

Yes, that that's a very good question, so the light clients uh are not usable in all use cases. So if you look at the previous use case that I was talking about, for example, of late management or platforming, uh these are very industry. Specific or industrial iot uh issued use cases where a company has a large number of devices or assets under its control, and it wants each of the set to have its own transaction capability with other devices, and in this scenario you can see that.

A

There is always no reason.

B

For the devices to trust its company's uh designated person, so we can use some identity, logic, say self order, certificates to designate whom it should trust, and then we can establish that trust environment.

B

So that is how we actually see that the light nodes can trust the funding and the watching notes which interact with the blockchain in actual.

C

Because yeah yeah in a further step, we're currently looking into the scenario where the light client doesn't trust the node, and this would be something like a web browser which doesn't trust the server to.

C

Basically, you want to keep the keys with the client in the in the browser wallet and there you would need a basically. You can still do that. But then you, the note, should do a callback, a signature callback to the client. So whenever the note will need the signature, it will not have the keys for that, but it will ask the client to sign this once transaction.

C

So basically, this then releases or removes this trust assumption on on the note, yeah yeah.

A

Okay and then the important question for the last is um you explained in the first, the second slide saying that uh 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- 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 uh implementing this scaling uh solution as a paroon.

A

So um do you already have that use case in mind or is it already developed? I I don't know the status right now.

B

Yeah sure, uh with regarding uh to your question, I think one of the use cases that we are uh very focusedly working on is a shared shop floor use case, uh so that is actually a huge. uh So it's a multi-company project. It's called I blockchain project, uh so yeah. I also presented a talk before uh 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.

B

What we try to do is that there are different companies, for example: bosch is there daimler is there then uh 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 uh when some order comes in.

B

That is a very customized order, so this machines 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, uh then uh this transaction layer so making this contract and agreeing to what is the state and everything is implemented on this layer and then the actual production begins.

B

So once all the production is done and the payment happens again, the payment layer is invoked and the payments all happen and it's resolved. So that is one use case. I think we are working on so you can uh refer to that resource. If you are like more interested in the details of that use case,.

A

Yeah yeah, thank you. Yeah.

B

Also, you can contact us through email. uh We can get in touch for further discussions too.

A

Okay yeah, so I mean I was uh considering the existing ethereum and there are light clients. So we need this pattern in between, like a peru node to to make the system work for high volumes of transactions right. So that's the the motive. I was also looking for, like iot devices, sensor data and how the underlying blockchain could handle.

A

I don't know thousands more than thousand requests per second or per minute, so yeah.

B

Because light client.

A

Light client is completely dependent on the full, node and full node suppose the full node has like only 50 percent 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 the request coming from the light clients. So that was the basic issue. Yeah.

B

You refer to the ethereum light line or yeah ethereum.

A

B

A

B

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 uh run the parent node. Also like you can just import this go package and then directly run the pyro node. So you don't have a node to interact with. You can just use the parent package.

B

So, but if you're having a very constricted device, say your smart watch, which is very less capable, then you can run the node on your smartphone and then your very transacting client on your smart watch and then you can make them interact via bluetooth for like funding and resolving, or something like that you can. It supports all of those fancy constellations. So that is the thing we are looking at when we are designing this framework.

A

Okay, yeah yeah, I mean, sounds good and uh looks like there is a lot of things that could be possible to do in the scenarios. Yeah yeah.

B

Yeah, thank you.

A

Thank you. Thank you. So much.

B

It was very good. Thank you. Thank you.

A

So any other question from anyone.

A

Else: okay, I think no.

A

uh Just a question you haven't shared the link of the project you mentioned uh at last.

B

Yeah sure, uh can you please yeah? Thank you can share it on the uh chat and we can also push uh like post it back in the meetup uh page as well. The links, yeah, sure, uh project and other resources that I was referring to. I can post all back into the meetup page yeah. Thank you, yeah sure.

A

Yeah, okay! Yes then I think, then we can wrap up right yeah. So thank you, ranjit and uh and thank you for the presentation, so uh this recording will be uploaded to the hyperledger uh youtube channel and say I will save the link on the intercepted page and even to the community.

C

Okay, okay, thank you.

B

Very much for for hosting us yeah. Thank you very much. It was uh really uh uh interesting discussions and.

C

Yeah, thanks for the question, that's right.

C

And yeah contact us if you wanna more details or wanna work with us or work with the product. If you have questions about uh the framework yeah.

B

C

B

C

B

Link is on the screen, but we also share it as like text links in the meetup.

B