 All right. Welcome everyone to the October 27th technical oversight committee call. As you are all aware, two things that we must abide by on a call calls. The first is the antitrust policy notice. And the second is the code of conduct, which is linked in the agenda. As far as announcements today, we have the standard Dev Weekly developer newsletter that goes out each Friday. If there's something that you would like to reach the hundreds of hyper hyper ledger developers, please leave a comment on the wiki page that is linked in the agenda. The second announcement that we have today is that the TOC nomination period is still open. The nominations do close on Monday, October 31st. So if you are interested in nominating yourself, please do so. And then Rai, you said you had an announcement. Well, it was an expansion on that announcement. Okay. And that is the people that have nominated themselves. The minority of those have filed an issue with their nominating statement. And I, well, it is in the interest of anyone that nominates themselves to run to add a to add a nominating statement because that will be linked from the ballot. And if you need help with that, ask in the discord. Okay. Any other announcements? Not seeing any hands or anybody coming off mute. We'll take that as no, as far as quarterly reports. The Ursa one is in draft. So last I looked, it still said it was in draft and that we shouldn't review it yet. As far as the other two fabric and cacti, I haven't seen any specific comments showing up on either of those. But does anybody have any questions that they'd like to bring up at this point? All right, I would take that as I know. As far as upcoming reports, we do have the sauteed report that is due today. So we'll look to see if that one comes in today and then we also have the areas in the in a row how reports coming due on the 10th of November. So we'll expect to see those at that point. Any other items that anybody would like to cover before we get to the presentation that we have scheduled for today. So we have no other discussion items. We do have the folks from the prune lab here. We have nano and BTS that are here and they're going to present to us the prune lab and walk us through that. So I will hand it off to to you. Yeah, thank you. Then I can share my screen now. Yes, please. Can everyone see my screen. We can see it. Yeah, okay, perfect. Hi everyone. I'm Manu Ranjit. I work as software engineer Bosch. And I have been involved with parents since the beginning days. Perron is a framework that targets two problems in the blockchain space. One is blockchain scalability. Another one is blockchain interoperability. It's it started out as an independent project and later became a hyper legit labs project and it's collaboratively being developed by Bosch and polycrypt GMB H. I would like to start with the problem statement that we try to solve. We are aware that blockchain provides an excellent mechanism for doing trustless transactions, say payments or in more general terms exchange of any value. But with time we have seen that there are quite some limitations with this. The first one being limited transaction throughput. For example, if we look at Bitcoin, it has like 10 transactions per second. That's the limit. And there are quite some new chains which have improved the layer one scalability, but there's still a limit on how much we can go far in that respect. So layer two scaling then becomes quite important. Second is a problem where which we figured out along the way as we developed Perron that the blockchain networks as new ones come up become the network is getting fragmented. And then we need mechanisms to make the networks interoperate with each other. And we realized that the technology we developed which Perron is usable in this context as well. So these are the two challenges that we target mainly coming to the agenda for the presentation. First, I would like to present you an overview of the Perron framework, then a brief history of the project, and then the interesting applications that we see. First the overview. To begin with, let's say two participants Alice and Bob, they want to make some transactions. So they come together and they talk to each other on what transactions they want to do, what the rules of the transactions are. And once they agree on these terms, they also decide what are the allowances for them. For example, in case of a payment channel, it could be that Alice wants to be able to spend 10 units of the currency. So they decide all of that and then approach the blockchain to say we want to open a channel. And these are the initial terms of the channel and these are the assets you would like to block in the channel. Then the assets are blocked in the Perron smart contract and the Perron channel is open for transaction. Now, each of them could make any number of transactions in a very direct peer-to-peer manner. Because these transactions are direct peer-to-peer, there are technically no limitations. There are limitations on how fast they can make the transactions, how fast they can create new states. And creating new states is basically about generating data and then making signatures on the data. And the second limitation is how fast is the communication channel. So these are the only two factors that limit them, which means they can easily reach thousands of transactions per second with a near zero cost for each of the transactions and the confirmation is immediate. As soon as both these parties sign, then that particular state is valid. And after they make any number of transactions in this fashion, they can go to blockchain and say here is the final state that we agreed on or that we want to settle. And then the Perron smart contract will validate that state and verify if it's really the final state. And once it confirms that it's a final state, it will settle the channel and redistribute the log assets according to the final state. So this is what happens with Perron state channels. What the protocol provides is that it's probably secure, meaning it has been proven in a formal way that if any state that is generated on the off-chain Perron channel can eventually be settled on the blockchain. It only becomes invalid when the next state is created. And second thing is cross-chain capability. So in this picture, we can see that the Perron smart contract is just one unit, which means we are using one blockchain back end. But we also figured out that we can open a Perron channel that is simultaneously using two different blockchains. For example, a Perron channel which blocks assets for Alice on one chain say Ethereum and for Bob on another chain say Cosmos or something like that. So this is an overview of how the Perron state channel works. And coming to the implementation part, all of these Perron protocols, as we call the funding protocol, the off-chain communication protocol and the settling protocol, everything, is defined, is implemented in an abstract way that is independent of any blockchain back end, of any persistence mechanism, and even independent of any networking or civilization format used for the off-chain communication. So this is a real abstract and modular core of the framework. And into this we can plug different blockchain back ends. And I think we currently have five different blockchain back ends, Ethereum, Cosmos, Polkadot, Internet Computer and Fabric. And for networking and civilization, we currently have TCP for the transport protocol. And for civilization, we are using a custom format called Perron format and recently we also implemented protocol bifurs. So which means you can just take the protocol definitions, generate the steps and easily implement the Perron client in any other language. And for persistence, we currently persist all the off-chain states that are created in a level DB. But again, this is also pluggable. You can go for any other options. So this is the core of the framework. And on top of this, we have a second component, which is Perron node. And Perron node, what it does is that in first place, it takes the Gopin framework and configures it according to your use case, picking one of the options for each of the pluggable modules and configuring them in the needed way. And on top of that, it provides an abstraction called session. So what session allows you is that it manages all the channels that a single user has and all the keys and wallets associated with all the channels of the user. And additionally, it also maintains a contact list on how to contact each of the peers that the user wants to talk to. And their off-chain information maintains all the off-chain information of those peers. And it provides an easy API for the user to open channels with any of these peers and then transit on those channels. But this is a more a generic API, which is providing all of these functionalities. But if you're looking at a specific use case, say payments, for example, then on top of this session API, we provide another API layer, which is payments API layer, which is providing like really simple APIs, allowing you to specify only the data that is required for payments. And this payment API can either be accessed as a library, like a Go library or anything. Or if you want a scenario where you want access over remote interface, then you can just implement a GRPC adapter. So this is also existing right now and so on. This is like really the extensible component of the whole parent framework where depending on your use case, you can just implement lighter API layers without modifying the protocol or the session layer. So that's the interesting way in which the core of the protocol can be extended by using plugins and the framework can be more usable or tailored to use case by writing appropriate APIs only in the upper layers. Yeah, so this is an overview of the two components of parent framework. And now we come to project history. We started in 2018 with the publication of parent search paper. This was published by Sebastian Faust and a few of his colleagues from to Darmstadt in collaboration with another university. And then Bos joined with them to collaborate on the development of the parent framework into 2019. And from there, we had several milestones before we eventually became a Hyperledge Labs project in late 2020. And from there, it has also been interesting that we developed a lot in terms of the framework functionalities and we even presented a few demos in Hyperledge in-depth series. And as I told that we have several other backends like Polkadot and Cosmos. We also collaborate with the corresponding communities as well. So this is how our collaboration looks like in time. And finally, I would like to discuss some of the applications that we find interesting and that we have experimented with so far. First of them is Perun IoT state channels. This was also one of the initial use cases which we had in mind for Bos. Like how do we enable two devices to make transactions based on blockchain? So that was one of the initial questions that we had in mind. And the Perun state channels that we developed, we extended it further. And the reason that we needed to extend it is for that the IoT devices that are here can have like real limitations on compute memory or network interactions or even power consumption. Like they can always not be connected to internet or and so on. And so it is tricky to expect that the device is able to do all the blockchain interactions by itself. So we thought about a key parameter for IoT devices, which is that each device is owned by an owner or a user. If it's by company, then it's administered by some person. So then we said, let's build some protocols to outsource all the blockchain interactions of the device to this owner or administrator. And this device is then interacting only with the other device that it wants to transact with and with the user, never with the blockchain. And these protocols we released in our recent releases and we also presented an extensive talk on the Perun IoT state channels itself in the last week. So that is the first use case that I wanted to discuss. The second one is blockchain gaming at low latency. So this is a very interesting use case. Peruna is a blockchain gaming infrastructure provider in the Polkadot ecosystem. What they're having in mind is that they wanted to build a game that works completely on blockchain, like it every move that is done is stored on the blockchain. And this means games are usually fast and then we need like real time confirmation of transactions and this is quite not possible in the layer one. So they were looking at a layer, a very low latency layer for implementing their game logic layer, which is recording these transactions and eventually recording it on blockchain. And that's where Perun was a very interesting fit. And this is like work in progress. And if you have more questions, we could also discuss about it in the discussion section. The next use case is trustless cross-chain asset swap. So here, as I said, when discussing the concept of Perun channel, let's say there's a client who has an asset on Ethereum and then there's a liquidity provider who has an asset on Polkadot. And now these two people want to exchange their assets. So what they can do is they can open a Perun channel blocking their corresponding assets on the corresponding chains. So the client will block their asset on Ethereum and the liquidity provider will block their asset on Polkadot. And then they can also give each other the addresses on the chain. For example, liquidity provider will give the address to which they want the asset to be transferred on Ethereum and vice versa. And after this channel is opened, what they can do is they can create a state which is swapping the assets. So it is swapping the asset ownership between the client and liquidity provider in a single atomic transaction. And then they can finalize the state and again settle it on the corresponding chains where the smart contract will then swap the assets for them on the corresponding chains. So this way it's very cheap and trustless token swap because you're now not relying on any intermediate party like a bridge or something. And next use case is trustless credential payment. This is similar to the trustless cross assets crossing asset swap. But then the difference is here one of the asset is a piece of data maybe a decentralized ID or something which is issued by an authority and the other asset is the payment for it. So both of them can block the corresponding assets in the Perun channel and inside of the channel they can swap it in an atomic way and then settle it again on a chain. Which means again this is atomic in nature and because it is done off-chain it can be like really thousands of transactions a second as we said. And I think we implemented a POC on this which is available on the internet which you can try out and currently we are also working to integrate this into the Hyperledger Ares framework. That brings us to the end of the presentation and to summarize I think Perun we would like to call it as a toolkit for blockchain scalability and interoperability. Using the state channel technology and the key advantages that it offers is low latency modularity and it's based on peer reviewed research and formal proofs. And as a good segue into discussion section I think one of the interesting things you would like to discuss is possible opportunities for collaboration within the Hyperledger ecosystem. And then what we saw based on interactions during the global forum was that two projects Hyperledger Cactus and Firefly might be interesting. I mean might have interesting of a new sort of collaboration but then we are looking forward for your inputs as well on how to think about this. Thanks for that. So I have an initial question to kick us off and then we will get some other questions as well. I'm curious about the roadmap for the Perun framework. You know, when we're looking at the history, it kind of, you know, peaked in my mind that you know I'm curious as to what's next. What are the plans for additional chains or additional sort of work that's going on there. In terms of roadmap, one of the things that we're currently looking at is IoT state channels. What we demonstrated in the recently is the ability to use the main framework on devices like Raspberry Pi or little more capable devices. So one of the things you want to do is develop a light client which can work on like real like low embedded devices which are like running bare metal or running an orthos kind of systems. So one of the areas that we want to go forward and maybe Matthias or Henry can highlight on some other areas that we are looking forward for. Yeah, sure. Maybe I can extend this a bit. So we are currently also working on extending the prune framework to other blockchains. So for example right now in progress is Cardano. So this demonstrates that the prune framework is also can be applied to EU ticks or star blockchains. And we're also in talks with further blockchain ecosystems for next year. Then Mano highlighted the SSI use case. So we recently in this October started a project on integrating this into the areas framework. And this is a project that we planned for the next two years. And it's also partially funded by the state grant from the German state government. And then we are also continuing on the gaming use case that Mano highlighted with the folks from IUNA network. And then of course we also intend to we are open for becoming a full hyperledger project. So for that there are a lot of things that need to be done. For example, streamlining the naming streamlining the repositories documentation create more attraction terms of marketing and also create more traction terms of the applications as they are currently in the PUC state. We are trying to also bring them into production. So this is kind of a summary. Thank you for that. Thanks. This was this is really nice project and I'm actually personally looking forward to a project like this. It's really beneficial for the community. And I have two questions probably took you can tell my first question is from the interoperability. Yeah. So, can you elaborate a bit more on that so when you talk about interoperability it's not actually providing a set transfer mechanism across blockchain. That's rather taking mechanism on the same blockchain but the parent node itself is adoptable across blockchain. Is that correct understanding? No, maybe I can go back to that area one moment. Yeah, so what happens is that you can have two different contracts. So say one contract is on Polkadot and one contract is on Ethereum. And then when you come together in opening the channel so during the initial interaction you say that liquidy provider has the asset on Polkadot and client has asset on Ethereum and they're going to block and swap it. So all of this is agreed in the first transaction and then we have to fund this channel be funded on both the chains. So on both the smart contracts we block the assets and then only the channel becomes open. And once the channel is open you do the first transaction which is also the last transaction which is swapping the assets. And once you create that state that state can be used to claim the assets by the other user on both the chains. So that way it's an asset swap not begging. So a single channel is by you're actually swapping the ownership of asset in the off chain because off chain is a single medium and it can be done in an atomic manner and then you go back and settle claim your assets back on the chain. I'll read more about it. So my second question is on the use cases so far that probably I'm a little outdated when I last saw the payroll note. All the examples that I could find work with two parties. I remember there was some kind of implementation where the multi-party aspect of it were to be supported, right? Any suggestions or any inputs on that? No I think currently it's mostly two-party framework. So currently mostly we support two-party transactions but the protocol itself is not the limitation. I think the protocol is extensible for multi-party channels but since most use cases currently we are interested in or the community is interested in involving only two parties we are going in the direction. So most of the examples are two-party examples. But the protocol itself is not having the limitation. Yeah and I can add also the implementation is written in a way that the data structures are already multi-party but we didn't write the protocol communication implementation already for multi-party. So kind of the data structures already are and depending on the protocol for example the funding protocol or the off chain transaction protocol we would have to extend these protocols to communicating with multiple parties, maybe integrating a broadcast functionality or something like that. So this part is not there but the core is written in a way that it is extensible if we decide to do that. Got it. Thanks for answering that. I don't know if I could probably hold on to this question later but the later question that I had was in terms of are you guys thinking to bring the project to hyperledger incubation and how many contributors are currently helping you maintain the project and all other aspects. So I'll hold on to that question maybe you can address that later. Yeah okay. Maybe we'll take the other questions and then come to that later on time. That's good. Peter. Thank you Tristan. Thanks for presentation. I wanted to know about the opening of the channel. Does that require a transaction on layer one to open the channel? Yes it does. And then the cost to that is that paid by Alison from the charts. Yep. And one more quick one for the exchange is that based on those contracts or HTLCs or there's some other mechanism to return funds. These are based on state channel technology. So it's comparable in a way to HTLC that you have this locking mechanism, but it's different to HTLC that it works based on signatures so you can almost think of a channel in a way as a multi sync contract. So as soon as all the participants and create on the new channel state for example transferring a token from one party to another. Then the contract recognizes this as a creed as opposed to an HTLC which depends on this secret value that you have to review. And this has also the benefit that we're not limited to one transaction, but we can do multiple updates. So you can do as many updates as you like before you settle the channel where in HTLC based swaps, you can only do one. And the source code of this contract. Is that also open source in the lab. Yes, they are all open source. Okay, then the last thing not another question just comment on one of the maintainers of cactus or cacti sorry. And I would be definitely interested in collaborating, trying to figure out how we could work together and achieve interoperability. Okay, yeah, that sounds interesting. Probably we could also talk after the docy meeting. Okay, sounds good. Thank you. Thanks, Peter. Thank you. Thank you for all the presentation. My comment is more on the side of the project is if it makes sense to have a fast track for Perun to get into cacti instead of having Perun as another hyper ledger project because it's also to have clarity of the ecosystem if now we know that there is a hyper ledger cacti that is a project that contains multiple, multiple techniques that offers multiple techniques to achieve interoperability. There is another one in this, in this direction so I, my first instinct would be to suggest this path to get Perun inside cacti directly, instead of having it as a new hyper ledger project. Thank you. Okay. Yeah, probably, we can have a look into it like what are the possibilities there. I would also see that I don't have the biggest work in that of course but I yet through the discussions at the global forum I also had the impression that cacti has like several protocols included but none of them is a state channel base so state channels could add something to cacti. And cacti which is not there yet. So I could see if it there, but maybe, yeah we would also have to look at other aspects of such an integration like how compatible are the code bases and the architectures and so on but yeah I agree with the idea that it could make sense. So it will be definitely a faster track that's that's for sure so you don't have to to find other organizations that you will have that needs to be made by maintainers of the Perun repository and so on and so forth so there is a community around cacti so why not that. And, you know, I think, I think the key here right is to have these connections so Peter is obviously worked with other, other labs, right, to bring into to hyperlider cactus to become cacti right so I think it's definitely a good place to start with those conversations. See how likely it is that it makes sense and I know Peter is definitely up for that I saw that the thumbs up that Peter gave so definitely let's let's continue those conversations and see what makes sense. Yeah, that really sounds like a very interesting avenue for for going forward. I think like Angelo mentioning you and that like, instead of having a separate project it could be maybe clubbed with cacti because like like we were in cactus where it could be has some some different way of interoperability in the blockchain protocols. Thanks so much. Other questions. Right, so I have slightly contradictory statement to Angelo and you guys are proposing right now in terms of margin it to cat type. So, so far I have been treating cat type earlier as interrupt solution when I needed that interoperability aspect. But looks like they don't does have additional capabilities which would spill over beyond interrupt scope. So, that's all just wanted to bring out that point. Yeah, thanks for bringing up this point so so I think one of the thoughts I have in mind as I hear the comments is one. Definitely there is a way like a good synchrony to work with cacti because both are addressing interoperability in one way. But I think that on itself has some other directions for example IOT state channels where it's it's it's not about interoperability but about just scalability and so on. So, I think I'm having a closer look and having more discussions with the team would provide a clear understanding of what's possible. Thanks. I look forward to outcomes of those discussions, but yeah I'm pretty much excited if collaboration does happen. Yeah, thank you. And coming back to the question that you raised on the beginning Aaron. I think in terms of becoming a main high pleasure project few things are housekeeping things which Mathias described in the beginning like bring together different repositories and and housekeeping around the code and something. But in other aspects, we see two other fronts for to achieve before we can become main project. One is to see a fit with other high pleasure projects and how do we collaborate and so on. And second is to find a use case or a third contributor I think currently it's it's mostly Bosch and polycrypt that's working on this, probably if we find a third entity that is also finding the technology interesting. Probably it could be a more stronger project when it as a main project maybe caught your thoughts on this. Yeah, so I guess the question is have we had projects that have come in with only to two organizations have had maintainers. And I'm not sure I'd have to go take a look at the original project proposals and see where they were. I do think that, you know, our incubation entry criteria probably outlines what is suggested. And then it's a matter of, you know, seeing how well those those criteria are met I think it's it's really, you know, if you read that document it really kind of highlights the expectations of things that we've seen in the past. When it when it comes to how we have approved projects into hyper ledger. So probably worth taking a look at that if you haven't already. Yeah, okay. And I'm happy to share that link directly in the in the prune chat so that you guys have access to that and can take a look at kind of where you think you stand related to that. Yeah, I mean I do find it interesting right and looking at kind of the history right when we looked at that slide that the number of kind of collaborations that you've had with other sorts of organizations or chains or, you know, there was definitely some sort of collaboration happening there and I'm curious as to whether or not any of those sorts of groups that you've worked with would, you know, be willing or able to also participate in contributing and maintaining the code. So that could be another sort of avenue or venue that you take a look at, you know, with the other sorts of groups that you've done collaboration with. Okay, yeah, that that's also one possibility. Yeah, no just to be honest with Aaron said that makes a lot of sense because if Perun main focus of Perun is layer two and performance that probably deserves a dedicated space in the in the in the greenhouse. In that case, yes, from the point of your layer to we don't have any anything that speaks directly to for layer two and given the level of integration with with blockchains that Perun has already. Yeah, that would, that would, that would qualify as a as a as a hyperlegical project with that target so layer two. Yeah. Okay, yeah. Thanks for your input. Just FYI I didn't just look at the incubation entry considerations. It says the product should have multiple maintainers. These maintainers need to be from different companies, however, having maintainers from different companies as seen as positive sign proposals with only one maintainer have been rejected by our TOCs. So I, you know, there is sort of precedence, I think, and it's just a question of, you know, what, what it looks like as far as the actual growth of the, the lab and how that's looking so, you know, like, I would say based on our considerations, it's not an immediate no, right. Okay, yeah, yeah, thanks. Thanks for the quick input on that point. Yeah, and I did, I did add the link to the prune channel so that you guys can take a look at that in depth. Other questions. Any closing thoughts from the prune team. Yeah, I think I'd like to thank the TOC for the opportunity. It was quite an insightful discussion for us in terms of how we, how the TOC sees this project from their point of view and the way forward. So thanks for your time and thanks for listening. All right, thanks. And it looks like a room maybe has a another question or comment. Right, I do have one more question so out of curiosity just because of the integration that it's for that the parent project has made but other frameworks outside of the hyperledger ecosystem. So what is the interest that is seen in other communities that you have observed in terms of adoption or the project interest itself. And this is a question out of curiosity you may choose to ignore or if you have any thoughts on that free free to share them. Maybe I can say a few words on this. So state channels where one of the early scaling technologies and they have specific use cases where they are interesting so especially when you want to go towards low latency and I think communities are all interested in layer two solutions, and that's why they funded our project as one layer two solution for their for their community for their blockchain space and at the moment, I think we are now looking at these applications. And one interesting aspect, or one interesting application was for example the collaboration or is the ongoing collaboration with you now, where we already did one current project. Regarding bringing state channels into the gaming space and enabling low latency interactions there. So, overall I would say, first of all, we are kind of an infrastructure technology provider, which is a toolkit. And now we are in all of these communities going more and more into the direction. What can we do with it and looking for collaborations in that regard. All right, any, any last questions. All right, if there's no questions then I would like to thank my own ideas and hundred for joining us today on the call. I think this has been a really interesting presentation and discussion. I am curious to see how the continued conversations might go with cacti and whether or not it makes sense to bring that into cacti or whether it makes sense to bring this into a separate top level project as we move forward so definitely keep us informed as you move forward with those conversations and let us know how it goes. And with that, I am going to close the call for today so I thank you all for attending, and we will hopefully see you next week. Thank you very much for having you all. Thank you. Thank you all. Bye.