 And then I can kick it off. So welcome, everyone, to a virtual Hyperledger meetup. Today we are talking about blockchain scaling and interoperability with the Prune framework. I put a link to the GoProon lab in the Zoom chat if people would like to find out more. And then I'll hand it off to Matthias and Oliver. So take it away. Yeah, thanks a lot. So I will go back to the title slide, which summarizes in a slogan what GoProon is and what we will be talking about today. So we will be talking about the GoProon library, which we developed over the past two to three years. And this is a project together with the German company Bosch. It originated at the University of Darmstadt as a research project. And now we also founded a small company based on this, which partially continues to develop on this product, but also has other products, which I briefly will touch upon. So GoProon is a library for enabling fast and cheap transactions on and across blockchains. And this is the core idea of the library. We want to scale blockchain applications. And this is all based on the channel technology which were developed in a series of research papers. And the goal for today is to briefly touch on the technology, give you an overview of how it roughly works, but then also dive into the architecture of the library that we developed. And Ollie will give you a more in-depth look how you would actually use the library and develop a small application with that. So yeah, so I am myself. I'm currently leading the Perun development team. I'm Matthias. Yeah, and my role as a software architect in general at the Polycrypt company. And I'm joined by Ollie. Yeah, he will talk to you later about how to develop an application with GoProon. And he is a core developer in our team since pretty much the beginning of the project. Our company that we founded based on the project also has a few other streams. So one stream is certainly the Perun library and this is targeted at a scaling scenario where you basically already know which parties you will be interacting with. You make a pre-deposit and anything that you interact in this small group of people will be very fast and very efficient and basically at zero cost. But then there's also other scenarios where you might not know who you will be interacting with, with the assets that you have. In particular, if you look at marketplace scenarios or non-fungible tokens, these are technologies. These are asset types and settings which do not work well for the channel technologies. And these we cover in our Azure project, which is a different technology lying below this library. And I just briefly wanted to mention both. Besides that, we also do consulting. So if you have any needs in that regard, you can also contact us and we like to do research, use cases and implement software. So, but let's come back to Perun. What problems are we addressing with the Perun framework? And these are mainly two. So you might be aware of, you might have heard these issues or these challenges with blockchains already, but I will take you through that briefly here. So we know that the popular blockchains that most people use today, for example, Bitcoin, the most prominent Bitcoin in Ethereum, they have a transaction throughput limit. So we're talking about globally about five to 15 transactions per second that we can process in the network. And they are also relatively slow with respect to confirmation times. So it takes normally about five minutes on Ethereum to confirm a transaction, depending on how much confidence you want to have that the transaction is really going through. And Bitcoin is a bit slower, so it can take up to an hour or even longer for a transaction to be confirmed. The transaction costs are also something that make small amounts of transaction relatively infeasible on these popular blockchains because we see transaction costs currently of multiple dollars for the simplest transaction that you can think. So many types of transactions with only a small value where you send only a small value from one party to another will not be viable on these types of blockchains. And on top of that, the transaction price that you pay varies a lot on how much load currently there is on the network. And these are problems that we address with our Gopal Room Library and the state channel technology. The second thing that we are observing right now is that there are more and more different blockchain networks coming up. So, yeah, Bitcoin was the first popular one. Ethereum is certainly very popular, but we are seeing other networks such as Polkadot coming up. And now we have the thing that these users on the different networks can natively interact with each other. And here we can also use our channel technology to basically bridge these networks and enable transactions between users in different networks. So how does it work? How does the Perun technology work on a very high level? So I try to summarize this in this picture where we see on the top the on-chain layer, and this is anything that runs on the global blockchain network. We can deploy the Perun smart contract which will be executed in a decent, seem to address fashion in a trustless way by the whole network, but any interaction with this layer one will be costly and slow, as I just explained. So basically the goal is to enable transactions between parties without having to interact every time. So we want to put as much load off the network in a local, basically interaction between the involved parties. And this is what we refer to by the second layer. So anything that does not directly touch the blockchain, we refer to by the second layer. And our goal is to establish basically a connection between two parties that know that they want to interact with each other. And we want to do that securely, efficiently, and possibly even between different types of blockchain networks. And this is all what the Perun channel technology and the GoPro library enables you to do in a secure way. So as I said, this is based on a series of research papers. We have proofs of security that our protocols are secure. We achieve transactions between two parties, basically with unlimited throughput. We achieve over 1,000 transactions per second. And this is between any two parties that connect via a channel. So this scales pretty well, even if you have many parties. The transaction cost, once you are off chain is zero, you don't pay any fees for that. And as I said, yeah, this can even connect clients which are on different networks potentially. So how does it roughly work? The first thing that the clients need to do, they need to discover each other and they need to decide, okay, we want to open a channel. And when they do that, they can deposit some funds into the smart contract which will be reserved for this specific channel under a unique channel ID. Then we have our library that enables off chain updates of the states. So the clients will interact peer to peer and they will sign new channel states and thereby transact and send funds from one party to another, for example. We can even apply additional transaction logic here. And basically the idea is that any transactions that are done off chain, there's a guarantee or protocols guarantee that you can eventually settle these transactions on chain. So once you completed a transaction off chain, even without the blockchain interaction, you can, there's a guarantee that you can redeem this transaction on chain. So basically once the clients decide, okay, now they have interacted as much as they wanted, they can go back to the on chain smart contract and settle the most recent state that they agreed on off chain. And then the funds will be available to the global network again. This is the very rough idea. Are there any questions on that or should we do that later? So there's one question in the chat that I see. How do you prevent off chain double spend? So the idea is that we pre-fund the channel. So when we deposit, we know these are the funds that are available in the channel and only to the parties that are part of this channel. This is all defined in the initial deposit that is done on chain. And now the consensus in this local channel works by having all parties agreeing on the new state. So you can only update the off chain state if all parties in the channel agree. And this basically controls what is the outcome of the channel? If all parties agree that some funds should go from Ellis to Bob, then they will sign it and they have a consensus on the new outcome of the channel. So there's, if one party is not fine with basically agreeing to that transaction because they think it's double spending, they will not sign it so they would prevent this transaction off chain. And yeah, so you can only make a transaction if everybody agrees and usually you would not agree to double spending. So there would be one party that they will disagree with that. Okay, so there's some more. So there's one question about which blockchains do we support? So that's a good question, I will... Yeah, answer. Yeah, go ahead. So we currently support Ethereum as our main backend and develop currently a polka dot backend and the backend for the Cosmos network. And the Cosmos network backend actually got released just this week. So this is available already in the first version. And the polka dot backend should be available later this year by the end of this year. So then we support three backends, Ethereum, polka dot and Cosmos. And we also started developing a definitive backend for the internet computer, which is in early stage. Then there's another question. I think this will be the last one that I cover here because we have some more slides to cover as well. How do you fix the price cross chain? This is up to the participants of the channel. So the logic of these channels is totally free to the clients to program any logic that they want. So they can define how to fix the price. And if you build an application with Perun, you need to think about how a fair price for your swap protocol would be and Perun gives you the technology to implement that. But we don't give you just this method for implementing it. It's basically up to the user of the framework how you want to realize your logic. So there's no prefixed answer to how we swap assets against one another. This is totally free to the application designer. Okay, I think, yeah, we move on. Yeah. Sorry, Luciano here from Brazil. I have only one more question there. Nice to meet you, everyone there. I have a little question. For example, the smart contract retain Perun, deploying the Perun framework. Is it written in a specific language or no? Yeah, so basically I will also go into this a bit more into detail on the following slides. But for any, so Perun as it's, I think it will be covered on the following slides if not let me know. So you can write the contracts in different languages but depending on which blockchain you use. So Perun is kind of abstractly defined. It does not necessarily require one contract language because it has an abstract defined interface for interacting with smart contracts. But I will go into this later. I see, I see. So the purpose of Perun, the goal of Perun is similar to the goal of Hyperledger Cactus or no, it has a different approach. Yeah, so I must admit that I'm not... I'm not talking about interoperability, right? Yeah, I'm not 100% up to date about Hyperledger Cactus but I also saw that there's a talk on that. So I think that the project started independently. So we started as a research project and Hyperledger Cactus started within Hyperledger and I'm not 100% aware about the differences of this project but this general scope looks pretty similar and I think we would have to go more into detail what are actually the differences and this is probably also a task that I need to cover for myself because I didn't look at the project yet in much detail. I see, I see. Thanks for the answers, Machiz. Yeah, and we will also do a Hello Words introduction later with Oli and for now I will continue on the Hyperledger idea of the technology. So also to understand better how using our library works I will briefly take you through the steps of how you open a channel, transact on it and settle it. So when you open a channel, you first send a proposal and the goal is, so basically you need to know which participants, you need to know the addresses of the participants that you want to open a channel with and then one of the participants will send a channel proposal and the other participants will agree with that or if they agree they will sign it and if we have a signature on this channel proposal then there's a guarantee that this channel will be open, can be opened on chain and the funds will be deposited into the contract. Once this has been done, once the fund has been deposited and this initial agreement has been done, the channel is open off chain and any participant can basically propose a new update to the channel and a recruitment off chain is reached by every participant having a signal by having every participant sign the new state. This is the update procedure off chain and once the participants or if one participant wants to close the channel, there's two ways to do that. Either everybody agrees that they want to close the channel and this is the collaborative case which is the quick one also because there's no dispute occurring so they all agree with the signature this is now the final state and we can conclude it on chain. If there's a dispute of course our protocols have to cover that some of the participants may not react or they may just not counter sign and in this case we open a challenge response dispute protocol on the smart contract which guarantees that whatever was the latest state decreed off chain will be concluded on chain. So some participant registers his local state and if other participants have a newer state they can register it and basically refute the state and after some time we will have a final answer what is the most recent state and we conclude the channel and withdraw the funds from the contract. That's the rough idea and we will see that when Olli shows you how to write an application. All right, so just to pre-overview how the architecture looks like we when you write an application with Go Perun at the core of the library is the state channel logic which is an abstract representation of the Perun protocols and any interfaces to the outside world are represented in an abstract way and this means you can basically Perun allows you to plug in your favorite blockchain backend, your favorite database backend, your favorite network message broker backend and also logging is only represented in an abstract way so that you can use it within your environment that you like. And regarding implementation in particular regarding blockchain backend implementations we have the Ethereum backend which is feature complete. So all features that are in the core library are available in the Ethereum network currently. Cosmos, as so for the Cosmos network we have a backend just released this week. Here it's still in development because it was just done this week and Polkadot will be released later this year. This picture should give you an idea how the Go project is structured into packages. This basically resembles what I showed you on the last slide. So if you want to work with the library just to give you an overview what are the different packages in the Go module? We have the client package that's contains the protocols that interacts with the wire package which is the abstraction for the message communication between the clients. We have an implementation of that which is very simple based on TCP IP. Then the client of course also needs to interact with an account model which is the wallet package abstraction and the client for interacting with a smart contract basically with a smart contract logic that runs on the blockchain it interacts with a channel package. And for the channel package specifically and the wallet package we have these blockchain backend implementations which give you concrete implementations of these packages, of the interfaces in these packages I should say. And for example in Ethereum the channel package contains a contract that is written in Solidity and for the polka dot backend the channel package contains a smart contract that is written in Rust. So this abstraction basically allows us to to work with any blockchain that is smart contract enabled and potentially might even work with Bitcoin if we apply some tweaks and recent research results. But yeah, the idea is that we have an abstraction which lets the core protocols work abstractly against any kind of blockchain backend that you can make work for these defined interfaces. Yeah. Okay. That's the end of the part about the Yeah, about the overview of the architecture and now I would hand over to Oli and I think we should also do that in the interest of time and we can address more questions after that. So Oli, you can share your screen and Oli will show you in a brief example how you would write an application with GoPro. Yeah, great. So hello everyone. That's my screen share book. Yeah, I can see it. Okay, great. So Udversölyuk, also a warm welcome to Oli and Gary since, yeah, Udvers. And so I will show you how to build an application now. I will also show you the demo course. So all the tech as all the non tech savvy people can just stay in for a second and then see what we will achieve. So on this overview graph, the orange parts are what we are going to build. And what you see here is one Bob node and one Alice node and Ethereum chain. And these connections here are the communications between them. So on chain always stands for when a client communicates with the blockchain on these two sides. And off chain is the communication that happens between the two participants and stays private between them unless they have a dispute or something. But normally this is very fast because it doesn't reach the chain. And in the Ethereum chain, we have the two smart contracts as Matthias already hinted. So the adjudicator, which is used for disputes and adjudication in that case. And the asset holder, which holds the balances and yeah, manages them for later use. So I will now start all these three parts and then show you how they interact. So we first start the blockchain. This is just a local Ethereum chain. It's called Ganesh. And if you scroll up here, you can see that all the accounts start with a thousand ETH. So they are just pre-funded. But this is important to know. So you can see the result later on. Now we'll start the LS node in the right window. She deploys the two smart contracts, the asset holder and the adjudicator and then waits for connections. And now we run the pop node in the left window. And as you can see, there is a prompt now about incoming general proposal with 500-500 ETH. So we click on accept here, enter Y. And so it takes a while and then you see that the tunnel has been opened between the two. And if you now look at the on-chain balance, so with info we can see all the balances currently. We see that Alice and Bob both have 500 in the tunnel and also 500 in the blockchain currently. And Bob now queries for an integer onto how many micro transactions to do. So yeah, since more is always better, let's select 50 transactions. And as you can see, this was really fast. So it's, the printing is what takes the longest here. Yeah, just that were 50 transactions. And now we press enter and then the channel will be closed. So Bob's already done and Alice waits for the event from the chain. And after that happened, we can then again look at the on-chain balance, info and see that Alice now got the 50 that I transferred in micro transactions actually on the blockchain. Okay, great. So now I will show you actually how the build is. For that, I will go to the start state again in the unfinished version and open all the files. So, right, first of all, I will show you the structure of the project. So we have like multiple goal and files. It's a goal project. And in the goal mode, there's the dependencies which as you can see depends on go per room. So the framework that we are using and go Ethereum for Ethereum specific stuff. Yeah, and some other configuration. Okay, so now we look at the configuration for the program itself. That's all held in this conflict struct. It's the Mnemonic, you're probably familiar with that with MetaMask where you enter your Mnemonic and the chain URL of the Ethereum blockchain. And then we have some other setup like IP addresses, account addresses and the addresses of the smart contracts. Okay, yeah. I think the concrete values are not important here but just so you know that it exists. Great. So let's look at what actually happens in this program. It starts out in this main function with first the setup, then a channel opening where each site has 500 EVE and then a for loop which always sends one EVE to the other party. And this query number function is just so that the user can enter a number that makes it a bit more interactive. And then after this has been sent, it just waits for an enterprise and then it closed it in. So like a really easy example. Now let's look into the code. Right, so this is our node struct and all the members that are contained here will be explained in the setup now but this holds the complete state which we need later on. So let's look at it. The first thing that we set up is an account. This is an Ethereum account from the Mnemonic that I mentioned earlier and the wallet. And it's important to know that Goproon can handle two accounts. So one account for the on-chain communication and one for the off-chain. But in this case, we just use one account to keep it simple. The distinctions can be used for privacy reasons. So yeah, this function just sets up the account and the wallet. This will be used by Goproon for signing transactions and off-chain states. Then this transactor, it takes in the wallet but this is just Ethereum specific so it will look different for every blockchain. So yeah, this is not really important right now. Then we have the on-chain connection here. This is the, this error, the on-chain connection between Bob and the chain. Yeah, it takes in the transactor and then returns the connection. Then we have the contract setup. This gets in the chain connection and the account and it returns to a smart contract. So the adjudicator and the asset order. And the only really important thing is that it validates the addresses. Since in the config file, I added the addresses and if I mistyped them, then yeah, the user could lose money. So we verify them here. The next thing is the bus. This is important for the off-chain communication part between Bob and Alice. And it again takes the account so that Alice can verify that she's really talking with Bob and not some kind of imposter. So yeah, this bus will then be used for network communication and forwarding of the messages. Next we have the funder here. The funder is needed to deposit funds into the asset order. So Bob will then use the funder and deposit Ethereum into the asset order. And it again takes in the on-chain connection, Bob's account and asset order smart contract. Okay, and why are we even doing this? So it's all important for this function here. It's all needed for this function. Since this is actually setting up the GoPro client, I just called it parent.newyear. And yeah, so this is a nice alias to understand it. And it takes five arguments. So the first argument is the address. That would be, in this case, Bob's address. And it takes in the bus, yeah. So the address is used for letting the client know which address they actually want to use. Since we don't distinguish between on and off-chain addresses, it's, yeah, we can just take this one. Then it takes the bus to enable the communication between Alice and Bob, or a funder that we just set up, and the adjudicator smart contract, and the wallet. So the adjudicator will then be needed for the disputes and the wallet for signing and verifying. I always have this no error here, which will just assert that nothing bad happened. So yeah, it's code is keeping it simple here. And then we just store all of this in our notes truck. Okay, so then we actually have the client set up, but it's not really going to react to anything. Let's say if someone wants to open a channel with Bob, then it wouldn't react to it. In our case, we don't have this in the protocol. So we don't have this in the demo right now, but I will still explain it to you for completeness reasons. So let's start with the proposal and update handlers. There is this handle function on the client, and it takes into arguments. So it's two interfaces, once the proposal handler, and then the update handler. And conveniently, we will implement both of them on the notes. So we just put the note here twice. It's a pro call, since it is otherwise a blocking call. And so if you look here again, first was proposal handler, this then expects you to implement the handle proposal function. And this is actually, in this case, only relevant for Alice. That's why it's empty here. So it gets in the channel proposal and a responder. And Alice would then react to this proposal by either accepting or rejecting. You can look at a proposal and say, if you like it or not, and then if you accept it, you will get a channel. And the next one is the update handler. So this is down here. In this case, Bob is sending the updates. So he does not need to implement this as well. It first gets in the old state, which the channel had before the update would be applied. Then the update, which is being proposed to update. And then a responder where you have accept and reject functions on it. So you can look at the update and then accept or reject it. Okay, there's one more handler here, which is called handle adjudicator event. This is not used in the code right now, but I will still explain it here briefly. So this is for reacting to events, which happened in the adjudicator smart contract. That's important for the dispute case. Yeah, but we don't look at the dispute case in this example. So it's just empty. But there's another function for us heading this on the client that Gopelwun would then know that you have actually implemented this. Okay, so that's this for the setup. Let's look at our main function again. This is what we did now with the setup. And now the next is the channel opening with where we pass in an amount. So let's look at the open channel function. It's down here and it takes in the amount and it should return a channel. So in order to open a channel or to propose a channel in Gopelwun, we have to input some configuration to actually specify how we want to open it. And we do this by defining the initial balances of the channel. And since Gopelwun channel support multiple assets, you can even specify which assets you want to use. We only want to use one asset. So yeah, to keep it simple right now, we just used the asset that we have in the conflict. So asset address. And then we put in the balances of Alice and Bob how they should be at the beginning of the channel. So after it's opened, in this case, we have to write Bob first, since he is the proposer of the channel. And the proposer goes always as first entry. Yes, and now we have the allocation and we also define which would be part of the channel. So again, Bob goes first and now entering the addresses of both parties. So for then Gopelwun which addresses should be actually part of the channel. Then we propose the channel. This is like a two-step thing. So first we create a proposal with proposal error. And then we call this on the parent package. So new ledger channel proposal. As you can see, there's also sub channels and virtual channels. Since Gopelwun supports multiple types of channels, we will just be using the ledger channels for now. First we put in the dispute timeout. This is like not important in our case, but it's still necessary for extended configuration. And we put in the address of the person who proposes it. So in this case, it's Bob's address. Then we put in the initial balances which we just defined up there. And the participants are part of the channel. And again, is certain that there was no error. And then we can actually send this proposal. With using the client, the parent line that we set up and calling proposed channel on it. I will not be setting a context here. So just using background and then putting in the proposal. So this should then propose the channel. And if the other party accepted the channel and the handle proposal handler, then we will get the channel here. If Alice would reject this channel proposal, then we will get an error, but this case is not interesting right now. So we just don't look at it. And the last thing that we can do here is we can start a watcher, which will watch for events on chain, which happened in the adjudicator. But I will just show you how this looks like. I'm not like that yet, this interface. So we call watch on that. And this will then use this adjudicator event handler, which we had up here currently empty to maybe handle some disputes. Right. Okay, so now we got the channel here and it's being returned. Let's look back here. So we have our channel, nice and easy. And the next thing is the sending of the balance. So that's the send balance function. It's right below here. So it gets into channel and an amount and then should send this amount to Alice. And we send an amount by updating the state of the channel. So we use our channel and call update by. And this takes a context, but that's ignored right now. And then a function which modifies the state. So if we now want to exchange the balances, we first have to subtract it from box balance. And then we have to add it to Alice balance. So that the complete balance in the channel stays the same so that you like can't double spend to achieve balances. Otherwise, scope everyone would reject it and Alice would reject it as well. So using Colen's pick and API, we now subtract this from our box balance. So we are using an asset index here since we have possibly multiple assets, we just use zero asset because there's only one asset in our channel. And then we use box index which in this case will be zero. And this will then take this expression will give us box balance of the asset. And we can then subtract amount from that. So that the new balance of pop will be the subtractive amount. And then we assign it with an equal. So we've set or something to box balance. But now we need to do the same thing for Alice but with an addition. We take Alice balances, Alice balance in the channel add the value to it with just that function and then set Alice new balance here. Then transfer the balance. And yeah, this call returns an error but in this case, we assume that Alice accepts the updates so everything should work. Great. Yeah, so there's no problem with Colen with multiple times in the for loop. So yeah, that works. And then the last step would be the channel closing. This is down here. It takes a channel and it would close the channel. So what this means is you want to get the result of the funds that are currently in the channel back onto the blockchain. And what we first do is we have to finalize the state since otherwise that's what we dispute if we don't use a final state and just try to close the channel then it would actually go to the adjudicator and try to dispute the state. But by doing this, we are using the cooperative case. Okay, then we just call it settle on the channel. Let's go and with no context and the secondary rule is only for guess optimization on Ethereum. This is not important to look at right now. It's not the error here. And this settle function will then also withdraw the funds back onto your on-chain account. And then there's another function for closing the channel, which actually just freeze resources. This is not for protocol reasons. So yeah, that should be it. And if I did everything correctly, we can try it out. So let's again start with the next chain, which SP4 is giving everyone 1000 ETH. Then the Alice node, which did not change. And you put it in the contracts and now we start our modified Bob node. So there's a channel opening again with 500, 500. Alice accepts it. I can actually also show you the transactions on the chain. So there's one transaction here and another one and yeah, two funding transactions. So it's actually happening. Now we can enter an integer. I could go up to 400, 99 I think here. So the printing into the console takes the longest. Actually this takes less than a second. Yeah, much less than a second. So and now if you press enter, then yeah, the channel gets closed. This will produce more transactions on the chain right here and yeah, some more there. Great. And if you look at the on-chain balance again, then we can see that Alice now got to 499 more and Bob just has 500 one remaining. Okay, I don't know if I can answer any questions now. Otherwise I would be giving back to Matthias. Yeah, I think we have some time to, yeah, does anybody have questions on the implementation part? Now is the time to ask and learn more about how to work with the framework? Otherwise you can also like ask your questions later. We will probably be some longer into the talk after the official parts. Yeah. How do you plug in persistence interface? Yeah, a specific database. Do you want to answer that? Yeah, we have a persistence layer in copper rule that let us enable persistence function. And that's what then like allow for persisting and restoring channels. And as you can see, it takes in an interface persist the restorer and you could then implement that. If I look into the code, what does it need to know? Yeah, we designed this very thoroughly. So there's all kinds of functions here which are nicely abstracted, but it's an interface that's the important thing. So you can plug it in by that. And we also have default implementations for a level DB. And I also think for a memory representation but I'm not sure about that. Definitely level DB. Yeah, any other questions? I didn't check YouTube, do you? Should I? Yeah, I'll just do YouTube, but it's fine. How about implementation with you, me? Or can be on any other thing? Default implement. Yeah, can also, I mean, I would like to address implementation questions first because then I will wrap up the talk and then you can also ask more to another questions afterwards. Okay, okay. So I give the space for you asking the questions. Then I ask mine after that. Okay, yeah. I mean, if everything was so understandable then I'm also fine with it. Yeah. And you can also re-watch it later. So, and drop us a question either via our website, Perun.network or in GitHub. We have the GitHub repository source, of course. They can be found at Apple at your labs. And I think, yeah, if there are no more questions on the implementation, then I will wrap up and show the last slides. So can you? Yeah, here's the slide. Yeah, just to briefly wrap it up. Yeah, Goproon is a modular library for building scalable blockchain applications. So in particular for payments between a small number of parties, for micro payments in particular, this is a very suitable technology. And we have multiple supported blockchain backends. You can even implement your own blockchain backend if you like. We're also considering, for example, implementing a backend for Hyperledger Fabric. And the really nice thing about the technology is that it is potentially possible to enable channels between blockchains, between different networks. This is something that we know how it works, but we haven't implemented it yet. And we will be starting that soon. That's the plan. And hope to have this functionality at least in a basic kind of way available within the next half year. So then the library will also support transactions and opening channels between different blockchain backends. Yeah, here's all kinds of links that you can connect with us. So of course, our repository at GitHub or our project website. We also have a Twitter linked in a medium account where we post news or more information on our technology, also on our other products with our company Polycrypt. And yeah, really happy if you want to connect with us. And yeah, that's it from our side. And yeah, if any quick questions, I think we need to close in a few minutes so that people can move to the next talk which is starting at six. Just one little fast question here, Oliver. Excuse me. It's still a little bit unclear for me. Not unclear, but only to check that, only to confirm. The communication off chain between the clients, between the agents, all the agents. This is done only to guarantee, to give a warranty that you were, how can I say, you were talking with, you were talking, you were speaking with someone that has a true identity, that has a, it's a trustable agent. I don't know, only to warranty trustability between the agents, among the agents, sorry. Because for example, the assets are going to be stored on chain, right? Yes, everything that will make the transactions. And what would the off chain communications serve for? The utility for that, the goal actually for that. So it's, the goal is that you can finalize transactions without needing to go to the blockchain every time. And the identities that you use in the channel can be the same identities as you use on chain, but it can also be different identities. And they can even be different from the addresses that you use for the network communication, of course. So we have different identity abstraction layers. And if you want, you can basically use the same identity across all layers, that is for on chain transactions, for off chain transactions, and even for registering on the network layer, you could also use the same identity. But you could also reuse different cryptographic identities on all three layers. So that's up to the application. And yeah. So this transaction finalization off chain would make the transaction, not on the transaction, but all the transaction lifecycle more faster, right? Faster. Exactly, that's the goal. And after we don't change. Exactly. So the idea is going on chain for very small amounts of transactions is not feasible in some cases. So for example, when you have a pay-per-use streaming service where you regularly get updates and you should pay in small incremental intervals, this is not something that you would like to do on a blockchain, but using a payment channel, you could do that. Or if you have a game and people interact with the game on a regular basis, and then you have a group of people who regularly, depending on the outcome of the game, want to transfer some money between each other. And this is a very nice use case for payment or even for state channels, which can have arbitrary transaction logic. So after the game is over, then the people can say, okay, now we are fine with the outcome. We can basically redistribute our money depending on the game outcome on the blockchain. And if there's any inconsistencies, any disagreement between the participants, our protocol will ensure that the outcomes can still be resolved, at least, depending on the most recent state in the game that was still fine, that was not compromised. And doing that- That's what I want to do. The DLT, right? Sorry? Doing that, for example, solving any kind of eventual problem like that of double spend transactions, auditing the blockchain, right? Auditing the DLT, the larger. Auditing? Yes. Very fine. For example, you've stated, for example, a kind of, let's suppose that there is a problem between the participants or some divergence of some transaction, I don't know. And for some of those transactions were made of, not the transactions, were signed or finalized at the off-chain, right? Then for example, if there's a problem, if there's a divergence between among the participants, what I said. I think I get it. Exactly. You use the smart contract to resolve the disputes. That's the idea. So anytime you get a dispute, the smart contract kind of resolves it and you may call it auditing, I would call it, yeah, adjudicating or resolving the dispute. That's the role of the blockchain in the end. I see. Ah, that's the role of the adjudicator that smoke on it. The adjudicator represents the smart contracts. It's just like another name for the role of the smart contract. I see, I see. Okay. Thanks. I was talking with, sorry. I think I was not talking with Oliver. I'm not seeing who is talking here. You talked with Matthias. Matthias, okay. Thanks Matthias. Thanks for your questions. Yeah. And if you want to connect, you can write us an email or have more questions. Surely do that. Okay. Are there any other questions? Yeah, if not, then I don't see any. So you see the information where you get more information about our project, the websites. And yeah, I think I said it all. And yeah, thank you a lot for attending the presentation. I hope you got something out of it. And we would be happy if you try out using the Gopaloon library and experiment a bit with it and give us your feedback. Thanks a lot. And yeah, I think that's it from our side. Okay. Thanks Matthias. Thanks Oliver. Nice to meet you, everyone. Yeah. Have a nice day. Yeah, you too. Yeah, you too. Bye-bye. Thanks. Okay, goodbye. Goodbye.