 Welcome, everyone. This is Hyperledger in-depth, an hour with Bosch on scaling DLTs with the Perrin lab framework. This is a discussion that will be hosted by six speakers, so I'll let them introduce themselves as they go. They all are either with Bosch or with Damselton University. So we have both researchers and industry experts today. I'll let you tell you a bit more about the in-depth Hyperledger in-depth series. First of all, like every other meeting in the Linux Foundation, it is held under the Antitrust Policy. You can read the full policy if you click in the top right corner on the QR code or scan it. In general, antitrust policy means that you shouldn't be sharing anything that isn't public knowledge or could be considered IP during meetings within the Linux Foundation. This session is being recorded and will be available on our website as well as our YouTube channel after the presentation or after the session finishes. Also, any slides that presenters are using will be available to download while in parallel to the recording. Now, as Hyperledger in-depth is not a typical Zoom presentation. It is really about being interactive. So please participate. We have discussions scheduled throughout the talk, so there will be time to participate and to engage. If you feel like everybody is speaking and you want to just jump in, you can raise your hand, which is a button that you have on your navigation bar. If your mic is not working or you're shy, ask questions in the Q&A. They will be definitely also addressed. And if you want to do some side chats or tech issues or something like that, use the Q&A box. I will allow everyone to talk so you can just unmute yourself whenever you want, but please obviously bear in mind that we want to kind of keep it polite. Okay, with that, I present you Hyperledger in-depth, an hour with Bosch on Perron Labs framework. So I'll let the presenters take over. Okay, thank you very much. I'm going to share my screen. Does it work? Can you see the presentation? Yes, we do. Okay, I will arrange it a little bit. Yep. Okay, so it looks good on my side as well. So yeah, welcome everybody again. My name is Matthias. I'm working for previously TU Darmstadt. We now founded a company called Polycrypt. And I will be presenting to you together with my colleagues also from Bosch, the Perron framework. The Perron framework in its essence is a modular framework for building scalable blockchain applications. So what was our motivation from the research side at TU Darmstadt for this work? It's the general observation that popular blockchains that we use widely don't scale very well. So when we look at the two most popular in the open space, Bitcoin and Ethereum, then we have a transaction throughput limit of about five to 15 transactions per second. We have transaction confirmation times in the order of minutes or potentially hours. And we have transactions costs that vary a lot depending on the load on the blockchain. So on the right hand side, you can see the graph of the gas price, which is the basis for the Ethereum transaction price. And even if we don't convert it to US dollars, even the inherent gas price varies a lot over time depending on the load on the Ethereum network. So this really makes these these blockchain technologies that are used for some use cases, but for other use cases they this makes them insufficient. So for example when we think of micro payments we need usually high throughput, low transaction cost, fast confirmation times the same for high frequency trading it doesn't work if we have to wait several minutes or hours for our confirmation. And any day to day shopping of goods that are not of high value isn't feasible with with these high transaction costs. So this was the main motivation from the research side and now Daniel from Bosch will tell you about the challenges from the industry side. Thanks for handing over. Hi, together. My name is Daniel Kunz and I'm working for Bosch Center Research in Germany. I would like to give you an overview about challenges we see by adopting blockchain technology in IoT space. The first point we see is regarding transaction value and frequency. Having not only a big number of running devices, we also do expect a high number of micro transactions as we want to be able to realize small asset transfer for received services or data or at least parts of them. Next please. And the IoT space consists of several kinds of entities from cloud native instances up to small embedded devices. Looking there at the different domains and constellations like manufacturing or sensors, you cannot assume that every entity has a persistent connection to the internet. On the one hand resulting from energy optimizations if it runs by battery, for example, on the other hand it can be located in a local available secured network with no direct internet connection available. Assumption is that local direct interactions are in general possible, but interactions through the internet only either by using so called gateways or at defined periodic time slots. Next please. The last constraint is coming by the device itself. As it is optimized for the dedicated use case and environment it runs in it will have limited power constraints, for example the embedded devices and also limited memory available. The constraints will have the outcome to bring only small code sizes with minimal functionality to such devices, if they have the need to execute transactions. And next, I would like to hand over to Sebastian. My name is Sebastian Stammler, I'm a PhD student at TU Darmstadt and also a co-founder of the university spin off polycrypt. I led the development of the Perun SDK which we are going to introduce to you later since 2019. At this point we would like to have a little discussion around and I want to kick it off with asking you a couple of questions. So, in particular, if you experienced any of the following scaling issues in your blockchain projects, because this is all of the problems that we actually address with this framework. As mentioned already, whether you experience too low transaction throughput in particular for microtransactions. If you experienced of course this is rather relevant for public blockchains but if you experienced a problem with transaction costs. And also, which is sometimes very important for some applications if you sometimes experience that the confirmation took too long so that the finality of a transaction, even if it is just seconds. That can still be a big problem in some applications and this is also something that we will can tackle with our solutions. So, because we basically have instant transaction confirmation, but yeah, that's something you can. Yeah, we will discuss now, hopefully. So, we will wait for everybody to give answers. Yeah, we launched the poll so please take take part in the poll and that will be the start of the discussion. Well, I'll reveal because you can't see the results I would like more people to answer but I would like to say that for now transaction cost is too high at 75% confirmation too long is 58% and throughput to low is 67%. So, I think it's quite interesting. Yeah, that's not bad. Yeah, I mean, not that I like people to have problems, but but for us it's I like that people actually really experienced those problems. And this is exactly what we are. Yeah, what we're tackling here. I wonder for those of you who voted. How, how does the whole kind of transaction costs versus throughput versus confirmation. How does it shape how you design your, your solutions. I will remind you we all are able to unmute yourself if you'd like to join the discussion. And I think that I would also be interested because you, I think you said that transaction cost too high was actually at 75. Oh yeah. 77% Wow, yeah. So, does that mean that many of you are also like running projects in a with a public blockchain. I never mentioned in the chat that paying 20 bucks on uni swap is just not fun to use. So that would seem Oliver would you like to share what what you're doing with blockchain because it seems like you are using public ledger aren't you. Hello, can you hear me. Yes. Yeah, I'm fine. Yeah, well I don't have my my my camera activated. Yeah, I'm just using it sometimes for token swaps and with MetaMask it already finds the cheapest, the cheapest platform to swap the tokens. But it's the way to expensive. Yeah, so I hope there's an easier solution which can be used as easily with with MetaMask as uni swap for example. So scaling DeFi applications like uni swap is definitely something that we are also working on right now. It's, it's, I mean, we are not going to talk about this in the presentation later but we can surely if there's other interest in from the audience we can surely also talk about scaling like current DeFi applications on Ethereum, if there's any more interest. So, Sebastian, I will ask you a question then because we've discussed the IoT problems. Is this something that you've been working on kind of parent came from working specifically on IoT and what kind of IoT solutions were you building that that came brought brought up those problems. So probably some of my colleagues can answer that better because IoT is of course just one application of the technology, but we already have proof of concepts running on IoT devices. I don't know maybe Hendrik or Daniel want to share some of their experience doing that. Because we also have in at TU Darmstadt we also have projects with students where they were exactly using the Perun framework for scaling on IoT devices. And from my side later I will also point anyway to another project where we want to include Perun for payments and this will be then also for machines and organization level. Right. Greg mentioned that while Ethereum is also part of Hyperledger and quotes part of. So it comes at the price but in his opinion Bitcoin is beyond reach for most right now, which yes it's a good point. We all wish that we were early in early adopters. Right, well, I'll let you continue. Sorry. Yeah, so should we. Yeah, if there are any more questions at this point to us. Yeah, please ask or we will just continue with the presentation otherwise. Yeah, I think we can continue. All right, so. Okay, so we we heard about the motivation of the of the project and how did we actually solve them. These challenges. One of our parent framework is something that is called state channel technology and the goal here is to offload as much of the transactions on the interaction of the chain of the plug chain onto a second layer that we call off chain layer. We achieved that by deploying a smart contract that has some asset holding logic in it, and some some other logic for allowing this functionality and how that roughly works is when you want to participate in the off chain network, you deposit some funds on the smart contract. And then you can interact without any of the on chain limitations. So once you deposited the funds on the contract and you signal with whom you want to interact off chain. You can transact with basically unlimited throughput, which is just limited by the number of signatures that your computer can generate. So that is more than 1000 transactions per second. So you have the transaction cost and you have instant confirmation so any state that you agree on off chain with your with the channel participants can be registered on chain and made a global made. Yeah, be a global state again. So this is really a direct communication. And this is also why it achieves instant confirmation times. Our protocols that we developed on the research side are probably secure. And this also has another interesting property we can even have cross chain support so we can open channels between different block chains and have clients from on different block chains, exchange funds with each other, even though they are not connected to the same network. So this is at the core of our framework. And what we are actually building the framework consists of several components at the core is the state channel SDK, which holds the channel logic. And then clients can either directly build on top of the SDK or if they are thin clients they can use the Perun node, which is in some sense a rapper around the SDK, which enables thin clients to work. And this is built by Bosch. And then in a separate repository we have the smart contracts, which realize the smart contract logic that I just talked about. In detail, how is the framework builds and what component does the framework have. So, at its core as I said there's the stage analogic, and an important property is that we build with modularity in mind so we initially planned to have a framework that is usable with many types of blockchains, not just with Ethereum, but you can build your own blockchain adapter. And through our abstract interface you can integrate it easily without changing the application code. That's, from my point of view, a main feature of our framework and the same accounts for the persistence. You can plug in your favorite database adapter you can plug in your favorite logging engine in your favorite message broker. So all of these things are not directly integrated into the framework we give some examples what we already provide but you can also provide your own adapter. And so this we think makes the framework usable. Hopefully in many application scenarios. Now, Manu from Bosch will tell you about how they use it in their application scenario. So I will be presenting on Perun node. So Perun node is a multi user node that we are building using the Perun SDK, which provides the opportunity for devices with less resources to use the Perun protocol and make state channel transactions. At the core we use the Perun SDK and initialize the different adapters required for it. So we use Ethereum adapter for blockchain and level DB for persistence and so on. And on top of that we add two other functionalities. So the first is key handling and the first thing we have implemented is like to use Ethereum key stores and second is option identity provider. So this option provider is like if you have an option network and many participants in that you need two things one is an identity of the provider which using which he will authenticate his ownership of that identity. Second is the communication address to reach him. So this is what this module does. And this complete adapters and the identity providers are all encapsulated in a session so that multiple users can use the same node. And to use the node, we have a user API. And this API is defined an abstract way that you can either use it as direct function calls or as a remote calls. So in the upcoming demo, I will show you that you've seen this API via remote call a GIPC interface. Sorry, just because Greg is having a question that I think is quite relevant to the previous slide. He was asking if why are you using and if are you using level DB rather than couch DB. Yeah, I think level DB was the first implementation we are trying for that fits of purposes. But maybe Sebastian can answer more detail. Yeah, so we use if you have a very modular approach using dependency injection by which you could use any database back end and in particular if you want to use couch to be instead of level DB. We could basically within one or two days just provide a wrapper for this because we have like an abstraction using a key value store and as far as I remember couch to be is also a key value store. So we can very quickly just integrate any key value store as as the back end. So level DB is really just one example implementation of this. But yeah, we could integrate couch to be within a matter of a few days. It's quite easy. And is it fair to say that parent blockchain is being used to just settle and archive, but the confirmation are done off confirmations are done off chain. Yes, so we set up we block a particular amount on the blockchain and within that amount we can update our balances and make any number of transactions off chain which does not require any on chain interaction. And only when we want to settle either like collaboratively or we have some dispute and we want to resolve it only then we need to go to blockchain. Yeah, there's a there's a nice parallel that you can see here so basically when you have a contract with someone like a real life contract with a person let's say you have a business relationship with with another business. You have a contract right it's a very complex contract, but of course you do the business with the other business person peer to peer right you don't go to a judge or to a court every time you just do a normal business transaction. And this is exactly the way how we use the blockchain so if you use the blockchain for every single transaction that basically means you go to the court to do every single even benign business transaction. And basically that's the that's the metaphor here that we use the that we use a blockchain only as a dispute handler as a dispute resolver. So it's a trust anchor but normal transactions if all involved parties behave honestly can then be done off chain. That's the idea. And how do you discover if parties are behaving or how do you how can you ensure that parties are behaving the right way. So the idea is in any in any kind of transaction there's at least one party who would have like a negative outcome if so if one party tries to cheat another party then that other party has disadvantage and then that other party can just go to the blockchain and dispute the state of the system. It's like this so every time you do transactions you exchange cryptographic signatures and those signatures prove that all parties agreed on some state of the system on some state of a transaction. And if then one party tries to misbehave and not act according to the rules, then any other party can go to the blockchain and use it as a kind of judge to resolve the dispute. And, and that's basically one of the core idea here. And what happens in case of kind of coordinated malicious behavior. So. So, the thing is, you only can affect the involved parties. So if three PT, let's say three people are involved, then, and all three people agree on some state then it doesn't matter because they cannot hurt anyone else outside the system, because you can simply using channels to parties, deposit into a channel and then that channel only affects those two parties. So, even if they both collude, they can only cheat themselves and not it doesn't have any other like effect on anything outside that channel so to speak so you have like a little encapsulated system. But I would also like to point out that you can actually program this resolution mechanism and what's a valid transaction on that channel. So we have an app concept on the channel level where you can program what is a valid transition for that channel. And what is an image transition so you can even impose rules on what is okay or not not okay. And now I'm just asking how is this bit resolution handled in the case of iot scenario where we have multiple micropayments submitted from various devices throughout the network. I mean it's rather general so for example when you have iot devices you probably would use a note like the note from Bosch because you would then have like one it's like an intermediate server service running and then you have thousands of iot devices and you usually have so what you usually experience in those systems is that you don't have so much malicious acting but if that happens of course then the note would jump in and then resolve the dispute. So that means the note would send a transaction to the blockchain opening a dispute and then of course the parties the particular party involved in the dispute so for example the one party that was behaving this honestly. Of course then at that point you cannot further transact but anyways I mean if a party is misbehaving then then you want to stop transacting with that party anyways. So, I don't know if that answered the question but I'm also very happy to follow up if that wasn't clear. Yeah we will also have a slide on the iot use case maybe could be clarified there I don't know. Yeah, well let's move to the demo I'm sure that this will clarify some things and bring some other questions. Yeah sure I can show one case in the demo where the other party is not willing to settle collaboratively and we can see how to settle. Yeah, so now I'll share my screen so in the demo I'll be presenting a split of the screen so the first split will be the blockchain node running I'll be running the national line node. In the second split I'll be running a parent node and in the bottom two splits I'll be running to client applications that we provide along with parent node but suggest that implementations to interact with the parent node. So now I'll present my screen. Hope my screen is visible. So in this split as I told I will start a gas line node. And here I will start the parent nodes before I start the parent node I was talking about the ID provider. So for building the parent node and generating the default configuration files you can have a look at the evening files, but I can point you to one of the configuration files that's here. So you have the parent node binary and then you can generate the configuration files here. So if you generate the Alice if you look at the Alice directly there are four components one is the database directory where the level DB database will go. The ID provider file. So if you look into the ID provider file it actually tells who Bob is like what is his option address and what is his communication address and how he can be connected like we are TCP connection or whatever. So currently we are using a local implementation where this comes from a file but in future we are looking for integration with a sign network so that we can get this information from a larger pool. So I will start the parent node here and in the bottom two splits I will start the parent node CLI. So now we have started the parent node CLI and for the first time we need to use the contracts we needed the context with deployed but in real life case I think there's only a single 10 instance of the contract deployed and hence this will not be done for like every time you want to open a contract. So now the contract is deployed and we can check the balances of both the parties. So this is Alice balance which is like 99 ethers and this is Bob's balance is like 100 ethers. So now we will connect to the node from this terminal both of these terminals node connect. And we are here and we'll open a session for Bob in the split and similarly we will connect with the node and open a session for Alice here. So this session will initialize the ID provider and key store and everything else. So now we have that we can check if you're able to get Bob's ID from this terminal. So yeah we're able to get so it tells the address. Now we can send a channel opening request to Bob so channel send opening request to Bob and we can say the initial balance should be 10 for myself and 10 for Bob. So he gets a request here so now we go there and accept the request. So if you look at the blockchain terminal we have a few transactions going on so this is where the money is deposited on the blockchain. And now if we check the on chain balances it will be decreased by 10 ethers for both of them. So this Alice balance which is like 89.9 something ethers and this is Bob's balance which is also like 89.9 something ethers. So now we are free to send any number of transactions between these two parties so I will try to send a transaction from this person. And on this channel and I will say send to ethers so he gets a notification which he can accept. So he can also like request a transaction where his money is increased and others money is decreased. So that can also be accepted. So this way you can you can either accept the transactions also reject them reject them then the channel states are not updated. So if you look at the states after the channel update you can see the update balance changes but none of this is reflected on change. So the on chain balances still remind the same. Now if either of the parties feel that they do not want to transact anymore and want to close the channels. They can send a close request. So if it is a collaborative close what happens is that a finalized state is sent to other party which he signs. And if both parties sign that state then the finalized state is submitted to blockchain then it's very fast resolution because both the parties agree. But in this case I will show you where one of the parties is rejecting the finalized update. Still the first party is able to settle the channel on blockchain. So I will say channel close and settle on chain and the channel name. So if you look at here he is getting another update which says should I accept the finalized state I will reject it here. So though he is rejecting it it will take a little more time because that we should provide some time out for the parties to wait and provide some challenges. But after the time out the channel automatically gets settled and the balance is withdrawn. So now we get an update that the channel settled so we can check the on chain balances. So now if you see the on chain balances have changed that Bob gets for it does more because of some of chain transactions. And yeah that's the end of the demo. Next, I think Daniel will present something more on the IOP use case. Okay I will share again if we have questions on a demo we can either have them now or we have another discussion slot. After the next slide. Okay, so Daniel is next. Thanks Manu for the demo. I'm coming now to the industry based showcase. I would like to point you to a public funded project located in Germany, where we are participating which is called industrial blockchain or I blockchain. The goal of I blockchain is to build an open and decentralized marketplace for the industry for the zero domain as a demonstrator especially for the so called auto controlled production use case scenario, which is described by the platform industry for the zero consortium. For example, for a better understanding you can think of ordering and customizing a bicycle, which needs then to be manufactured and assembled by different suppliers based on the chosen parameters by the customer. Therefore, the described scenario wants to connect manufacturers and customers by using different market mechanisms like negotiations or auctions and other kinds of matchmaking, depending on the marketplace type. Next please. As outcome of the marketplace interaction there will be an electronic agreement which needs then to be said to be settled between the involved parties. Next please. As part of this settlement. This is not only the manufacturing step included but also some kind of payment between the involved parties. At this step, we want to bring in Perun to be able to make economic based transactions, either between companies organizations or machines. Next please. This whole scenario will be built upon a common identity layer, which will be built which will be based on self sovereign identity or SSI. And at the end, every involved in entity in this scenario needs an SSI based account for participate participation and interaction for transactions on the other hand, a common deal to be then used. And now I would like to hand over to back to Sebastian for the next questions and discussions rounds. Yeah, thanks. So now that you have seen a little bit more how we can use this and possible applications of this. Yeah, we just wanted to ask you in general how relevant do you see this particular kind of solutions of scaling solutions for your projects, your business area. In the meantime, I'll just bring up the question that Manjiri asked, which was what is the underlying protocol used for the peer to peer communication. And I know Sebastian you answered it in Q&A but I don't think that everybody's observing it so I wanted to make sure that. So in general, the SDK doesn't make any expectations on how peer to peer messages are transported. Because again, we use dependency injection so you can insert any communication mechanism that for example already is in place. I mean, probably if you want to insert this into some existing application, you already have your communication infrastructure, right? So maybe you use lip peer to peer, or maybe you have encrypted TCP IP connections, or maybe you have some other kind of message broker system and any kind of system can be used to then just transmit our messages. So basically, of course you have to implement some interface so you basically have to provide a kind of thin wrapper around the communication system that you have. And then we can reuse your existing communication system to transport the peer to peer messages that our framework, our protocol needs. Great, thank you. I remind you all to participate in the poll. We are really curious what do you think about parent and do you think it's something that you'd be using? I still see that there are people who haven't voted. Currently, medium relevance is the one that is winning. So you get the chance to change the vote. Use your power. Someone added higher relevance, okay, so between medium and high is what we're seeing right now. So, yeah, well, what do you think then? Do you think that, are you happy with this result or would you, well, I guess you are. You'd rather have it high than not. How would it be relevant to other industries? So we talked about IoT, but how do you imagine using parent and I don't know supply chain or something else? So, so in general, so this particular technology that we present your channels are most relevant if you have recurring transactions between the same set of participants, or at least if you have, or you can also have like hub and spoke infrastructure. So basically you have, you can have like one hub in the middle and then you have thousands of other devices or people connected to that hub. So this is in general the, the kind of application usage scenario where this makes sense. So for example, in supply chain, you sometimes have the situation that of course, basically when you update the system state, for example, you use a fabric system, hyper ledger fabric and then you want to publish some system update state. Then of course it should be visible to the whole world, so to speak, right, because you use the ledger as a means of single source of truth for the whole world. And in this particular kind of applications, going off chain is, is not really helping because of course you want the changes to the system to be publicly visible to the whole world, so to speak to the whole system. Yeah, but basically anything that involves not only payments but also more complex transactions between a fixed set of participants. But you could also realize an intermediate solution like a hybrid solution where you have some off chain updates, and only at certain intermediate points you have global on chain, on chain visibility for your supply chain or something like this. Yeah, so that might be also a use case where you can study this. I would be interested from those people who rated medium or low what. Yeah, what, why, why is it a little bit relevant but could we extend the framework maybe to make it more relevant or what are their main challenges or main interests in that area. So if somebody would like to comment I would be curious to hear. Oliver you mentioned that you use kind of tokens and to transact or exchange tokens. So what do you think about about parent do you have an idea how you'd use it. I myself already worked with it but I didn't I'm not doing any kind of business with with Ethereum professionally it's just for private use so I would be on the consumer side. So I would need someone else to like create a platform that then can be integrated with that people just use. I would also like to hear from somebody else and then only because he's part of our team so. Sorry, but I would be really interested into hearing the opinion of people that I don't know already. Now man, you, you were asking about dispute resolution and yeah, IOT with micro payments is this something that you're working with. Hi, hi. Yes, I am working at this particular use cases where in require a lot of transactions amongst two devices basically hardware devices and because those are the micro payments, which is why I was looking at Perun and I have been following it since almost six to eight months but I really wanted to know the dispute logic and glad that I could get it from you. Yeah, I mean just to reiterate here so it really depends on the on the on the whole system setup you so either each device itself can run the dispute in case of a dispute, but of course in like some industrial application or it sounds like in your application. It probably makes more sense that you have like a no server running for you that is handling all the disputes so that the all the thousands of devices don't really need to handle this so they don't need to watch the blockchain and so on so basically you have like all those and devices who would be doing the transactions, micro transactions, but then you have like this note who's doing this channel watching. So I mean, yeah, so watching the blockchain is just a, it's a general necessity in all a second layer solution so anytime you go off chain so there are also other solutions like plasma like rollups, like air style which is another project that we launched for the ETH online hackathon last year and all those solutions you always have chain watching it's like a fundamental problem because of course anyone else could try to cheat you by running a dispute on an old state of the system on chain. And this is why there's like this fundamental property of off chain protocols that you always need to watch the chain. One thing, yeah, one thing which I would also like here to be addressed is when I was looking at the demo. One thing which we can also focus on is how to address the confidentiality of the data there because as far as I saw in the demo when two nodes were interacting we can see that the addresses were been issued. So if we have some encoding or encryption there to ensure that the data or whatever transactions are happening remains confidential not only to the parties, but also when they are stored finally upended to the ledger as well. So that thing can also be taken care. So you basically only see the batch of the transaction so basically the aggregated effect of all the transactions would be visible on chain right so you could run thousands of transactions off chain and this would never be visible on the blockchain, but only the final state so say you open a channel and both parties put in 100. And then I don't know at the end you have a channel where the balance is 50 and 150 and then only this final balance would be visible on chain of course because people withdraw their funds back on chain, but how you came to that final balance is not visible. So the privacy of the intermediate steps so to speak is preserved here. Okay, okay. Thank you. Thank you so much. You're welcome. Any other comments or questions. Well, I guess we can move on then. Alright, then I'll take over. So my name is Chris. And I'd like to shift the focus in this final part of today's session to the from the technology to parents journey from academic research to the current open source project. You may wonder why gosh got engaged in this parent development quite early. So in a way it was coincidence of need as you heard in our even in our early prototypes with Ethereum, we ran into those scalability issues and opportunity as state channels were evented around that time, and we had those problems. And we've been in contact with Professor Faust and his colleagues since the early stages of their research. And based on those, and if you click, we see a point in time on the timeline. Based on those results and the early walkthrough prototypes and smart contracts that are already created within the studio dumpster. Within our research project economy of things we started to implement a first version of this state channel node application. And this was always meant to be open source. And I think it may be interesting to quickly recap what are why that why we think it that is so and what the initial open source strategy was and that would be the next slide. So we're a potential user of the technology and not so technology provider per se actually, but our overall goal for Perun is that you want to have enabled scalability of blockchain payments and smart contracts and without any gatekeepers or it shouldn't be monopolizable infrastructure in the end. To enable high volume of arbitrary transactions, including scalable micropayments that support our vision of an economy of things. And go to the next thing Perun as it is as we learned as a protocol at heart, we think it needs widespread adoption to function. And so the main open source goal is to lead a standardization efforts to establish it as a major part in the payments and smart contracts ecosystem. And a second very important benefit of an open source approach as you'll know is that open source provides a framework for partner collaboration and you'll see that in a minute. And additionally for product like Perun, obviously transparency and open access to the development process. Many of you as a required part of getting trust and the resulting protocols and implementations and stuff. Next please. Oops, there's a link on the left hand side. Sorry. I just wanted to point you to an interesting article by Carl Vogel and James was sealed from Open Tech Strategists, which they published against the Mozilla, which helps to guide strategic thinking about the question how to set up such projects. And they talk about open source archetypes such as just open source project patterns until the most fitting archetype for Perun is I think multi vendor infrastructure archetype, which is exactly designed for non monopolizable infrastructure projects and you know many of the projects like Kubernetes, OpenStack or Hyperledger itself are some very non examples. Now to the next slide. We continue now that you know where you want to go. We continue our journey. So we were at the point that we had started with an initial in-house implementation and the major obstacles around that time and until the first open source release, which you already saw up here, were a lack of speeds and ensuing friction in collaboration. So you have different internal repos, different communication channels, et cetera, and you may have experienced similar things. And ultimately this led to two independent implementations being open sourced in the end of 2019. So more than a year ago, you had a state channel nodes and the first version of the Perun SDK. However, the first very positive effect of going open source or finally going open source was that it made collaboration just so much easier and it enabled contributions. And so at the beginning of 2020, our two teams had gotten together. We had regular tech calls, we had a common chat system, and we started to have some, see some contributions to either code base. And if you, I think if you continue, then we see that also we rebuilt the node on top of the SDK so it started to evolve into this modular framework represented today. And I think the next important step was to move to a neutral home to further evolve this project. And we're happy to have found that as Hyperledger Labs, and I'd like to use the opportunity here to thank or know who was our sponsor and Ryan Tracy, who has lapsed towards us to get the infrastructure going and not to forget Marta, who's our host here, we hope to get this rolling to start with. And with the founding of Polycrypt, we also see the start of a hopefully growing multi-vendor infrastructure ecosystem around this technology. So to sum up on the next slide, Perun is a modular framework for building scalable blockchain applications at its core is the SDK. And as for the next steps, plan to invest some time and documentation to ease onboarding of new developers. We also foresee additional blockchain backends. And I mean, there's many DLTs in the Hyperledger space, and maybe there's some interest in the users. And I guess which ones get implemented depends on user needs. And we would also welcome contributions, of course, if you're interested to get involved here. We're also looking forward to virtual channels of support to some of the features we haven't spoken into detail yet, but that would enable this hub and spoke architecture, I think. It could even build or enable cross-chain transactions. Matthias mentioned earlier. So you could do an off-chain transaction sending one either, and your Perun state channel here receives a different coin of equal comparable value on a fabric network, say. Anything you'd like to add, Sipas and Matthias? Sounds good. Okay, as far as the notice concerned, I mean, we're interested in this IoT use case, so we're looking to develop a light node or a library for embedded devices to use in the showcase project Daniel presented earlier. And last but not least, and at least in my view, I think the biggest challenge at this point in time this year is to grow this open source project. And so we'd love you to get in touch and start to collaborate, whether you just want to use Perun or I think you've got an interesting use case, or even better if you want to start to contribute and integrate it with other Hyperledger technologies, for example. Because today, the current implementation works with Ethereum, but as you saw, the abstractions are in place to add other DLTs. Today, we have a simple off-chain identity provider, but I think integration with SSI would also be a valuable addition. Or maybe you have other great ideas, then either waste them now or later. Mark is actually asking, or says that it would be interesting if you could discuss the pros and cons of using general purpose blockchain with Perum versus a special purpose blockchain like Iroha, Hyperledger Iroha for IoT. Yeah, I have a few words to say about this, maybe also Sebastian or you can go ahead. I think one interesting property of our framework is that it's flexible. You can create off-chain networks dynamically, you don't have to predetermine who can talk to whom, you can go off-chain, interact very efficiently and go on-chain again and create a new group. Or you can even transact between different blockchains using that channel technology and I think this is something, I'm not totally familiar with all the existing projects, honestly. But I think this is something that I haven't seen like it in the other projects. Yeah, I think it really depends on the context. So for example, if you want to set up some IoT systems that eventually transact on the public Ethereum blockchain, then of course you kind of need something like Perun or some other framework for going off-chain. But if you say, okay, I'm setting up a system, but it's a closed system. So it's like a private blockchain. And I really know that this is exactly the kind of use case. And then I don't know, if Iroha perfectly covers this use case, then I would suggest, okay, then better use the special purpose software because it's made for this particular use case. So in general, yeah, I would say if some special purpose blockchain or solution like Iroha supports like fits your bill perfectly, then I would just use it because of course using a framework on top of Ethereum adds complexity. But then on the other hand, this also opens up all those possibilities that you can interact with the Ethereum blockchain, but still be efficient off-chain. I hope that kind of answered the question. Yeah, I think that's a very good point. Manjiri also is asking if you could elaborate on the Lightnode implementation. How would it be different than existing Lightnode client implementation? Maybe Manu or someone from... Yeah, I think I can explain it here. So what the current node that we have per say the Peron node has all functionalities like can set up blockchain. It can help you to do off-chain transactions and it can settle. But if you look at IoT use cases, maybe they do not have the access to the funds because the valid needs more security and cannot be stored on the embedded devices. So they can request for the owner of the device some gateway to set up the state channel and they can have components only for making off-chain transactions. And the setting of state channel and closing can be taken care of by the gateway and for like off-chain transactions, they can completely do independent of the gateway itself. So that is one of the directions that we are looking for Lightnodes where we have a minimal possible functionality on the embedded device to do off-chain transactions. Does that help you? I hope it does. Well, okay, I think that this is all we have time for. So I would like to really thank you for joining us here today.