 Then thanks for coming. So this talk will be about the Perun framework, which is, you can see as a toolkit for blockchain scalability, for increasing the transaction throughput and for enabling also transactions across blockchains, for example, regarding cross-chain swaps. Perun is a Hyperledger Labs project currently. It is maintained by Bosch, the German company, and the startup Polycrypt. So I'm a software architect at Polycrypt. The project itself started as a research project at the University of Darmstadt in Germany, and we founded a small startup company from that and also have some other projects, but this will focus on Perun. So what are we addressing? I already briefly touched upon it. We are addressing scalability and interoperability. So as you know, a blockchain gives us a trustless transaction layer for exchanging value for doing payments, but also especially when we look at public blockchain networks such as Ethereum or Bitcoin. These have a lot of nodes and there are inherent transaction throughput limits with these public blockchains. So we see, for example, in the case of Ethereum or Bitcoin, we can do globally between 10 and 20 transactions per second, and this is something that we wanted to address with the research initially. It turns out that the same technology is also capable of solving a different problem that arised more recently, so we see more and more different blockchain networks coming up. The assets are fragmented, the user are fragmented across the networks, and there is, as you know, a need for interoperability solutions so that assets, for example, from different networks can be exchanged against each other. So how does the protocol work? So this, as I said, stems from a research project and this slide should give you a very rough idea how it works on a protocol level. The basic idea is that we try to push as many of the transactions off the chain so that there is no on-chain transaction costs and no on-chain limitations. And only in the case of an off-chain dispute, so if we run into a dispute with other parties that we are interacting with, then we use a smart contract to resolve the disputes. And the crucial point is that we don't really want to sacrifice any security guarantees that we typically have, so we still want to do that in a trustless way where we don't need to rely on a trusted intermediary. So here you can see the typical transaction scheme when working with a blockchain and for us it looks a little bit like this. So we have this off-chain protocol. For entering the off-chain system we do maybe a few on-chain transactions for exiting the system or for disputing. But as long as we're in an optimistic execution, we can do transactions across the parties in the off-chain system without any on-chain interaction. But there's a guarantee that any transaction that we do off-chain will eventually be possible to settle against a layer one. And Perun, as I mentioned, is an instance of such a protocol. There are other protocols as well. Perun is based on state channel technology that's the technical term and is one instance of such a scaling protocol. So today I want to tell you a little bit more about the history of the project, how it evolved from a research project into a start-up company and a hyperledger labs project. Then give you an overview of the framework, its component, the protocols. Maybe if we have time also tell you a bit about the technical details like how the architecture looks like, how the API looks like. And finally tell you about applications that we're currently working on or that we see as potential useful applications of the technology. So yeah, as I mentioned, we started, I think the research started actually back in 2016 or something like that. And then it always takes time to formulate the ideas, to write it down and finally the papers got published in the middle of 2018, beginning of 2019 I think, at well-renowned computer security conferences, Eurogroup, ACM, CCS, IEEE, S&P and that was focusing on building state channel networks. So we cannot just have one state channel that has a fixed set of parties, but we can actually build state channels on top of state channels in order to build, for example, a payment network where the creation of new state channels doesn't require on-chain interactions and that's also what these papers focus on. And on top of that you can actually run smart contracts inside such a state channel and yeah, all the protocols are in these papers. Then we wanted to build out the protocols into a library and in the middle of 2018 we got some funding from the Ethereum Foundation which basically kick-started this endeavor of making some software product out of it. Also early on we got interest from company Bosch, unfortunately a colleague from Bosch couldn't be here today due to visa reasons, but they engage with us already, I think also in the middle of 2018 and in the beginning of 2019 we had the first proof-of-concept implementation which was not an open source library now as today, but still something that we could already show. Then also something that was very helpful for us in Germany, there is funding from the government for transitioning a research project to a startup company and received some funding from that so that helped us really work individually without too much investor pressure or something like that on the project. We also then in the end of 2019 released the first version of the library and since then it's publicly available on GitHub. I will point to the repositories at the end. We continue to develop new features basically we just started with simple payment channels in the beginning and by today we can do payment channel networks, we can also do arbitrary execution logic in the payment channel in a state channel. We have cross-chain functionality by now so we continue to add new features but on an organization level at some point it was suggested by Bosch that we join the Hyperledger Foundation as a labs project because it gives us a common neutral ground to work together without having the problem of who owns what, it's just open source and there's no, we don't have to decide if the repository lies at the Bosch org or the Pudding Group org which is the company name and so on. And as I already hinted the company until that point it was still located at the university and then at the end of 2020 we founded the company called Pudding Group which is still tightly located related to the university group of Professor Sebastian Faust. We still have offices in the university so that's also quite nice. Then we got another round of funding for basically transitioning further into a self-sustainable company and we received also quite some interest from other blockchain foundations so from Polkadot specifically from DFINITY and basically integrated or are still working on integrating the Perum protocols for their blockchains so that potential application users can also work with these different blockchains. This year a focus was really on the application side so we are kind of a technology provider but of course in the end technology is only useful if you have good applications for it and one instance of that came through a connection with the Polkadot space so IUNA is a startup company which also receives some funding from Polkadot and they're focusing on providing gaming-based blockchain applications and making it easy for game developers to use blockchain but they hit a limitation in terms of how far they could scale their applications so they wanted real-time interaction in their games but they couldn't do it with other scaling technology and that's how they get interested into Perun and I will talk a little bit more later about how that works. Recently we also published an integration for Hyperledger Fabric and are also now developing an integration for Cardano which is a different type of blockchain. It's UTXO-based so quite a different model but it looks like our abstractions and our protocols also work for UTXO-based blockchains with some smart contract functionality. With that we have the history part done and I would like to give you as first a bit of an overview of how the protocols work but then also what are the components and maybe also how the architecture of the implementation looks like. So the prerequisite for using Perun is independent of how we implement it. When you want to use it you have to deploy a smart contract on a chosen blockchain so we are compatible with different types of blockchains but independent of which blockchain it is you have to deploy Perun's smart contract with a certain functionality for dispute resolution. By the way is this sound alright or should I? Yeah alright. I have a small echo but it's fine. So and then the next thing is okay we have an off-chain agreement protocol for two parties to agree that they want to engage in an off-chain interaction. So once they have that off-chain agreement basically by signing the channel parameters they can then open the channel by funding into this globally unique channel ID making a fund transaction into the smart contract and now these funds these assets will be reserved for that particular channel where only these two parties have access to. So maybe when the channel is open in a very simple case it would say Alice has five tokens and Bob has also five tokens in the channel. So now the channel is open and the funds are locked and we can now do transactions off-chain basically Alice can say I want to make a payment transfer to Bob of five tokens so Bob has balance 10 afterwards and Alice has balance zero. They both signed the new state and since they both signed it the smart contract can later realize okay now this is the state with the highest version number which has signatures from all parties in the channel so I will accept it later. So we can basically do this thousand times per second because it only requires a little bit of network interaction and signatures. It doesn't involve any on-chain fees and you get an instant confirmation and the protocols that we have guarantee that anything that you agree on off-chain you can eventually settle on-chain. So there's a protocol guarantee that you can eventually do that. So in the optimistic case you will actually say you will finalize the off-chain interactions by setting a boolean flag in the channel state but of course it could also happen that you cannot finalize the channel off-chain and one party for example goes offline. So in that case we run into a dispute and now we have to decide which is the most recent state that was agreed upon and basically this is a challenge response protocol with some time on logic and the smart contract supports this and as long as the parties are online that's a necessary requirement they will basically be able to register the most recent state that everybody has agreed on and the channel will then be settled. So as I said we also have different features that we can now enable in such a Peruvian channel. We can do swaps inside a channel, we can do other transaction logic so that one transaction depends on the next transaction and in case one party maybe signs one the first transaction but not the second one we have a mechanism that if these are dependent on each other we can enforce the transaction on the smart contract. So there's a mechanism basically for transaction enforcement in case of a dispute and that also allows us to program game logic into a channel where we can basically maybe play the game to the end even if one party already left the game. Another thing that we can do, we can also have Alice on the left put assets from a different blockchain into the channel than Bob so maybe Alice wants to trade Ether against Metaigon from Bob on Polygon and this method also works if you have two blockchains with two smart contracts and the basic idea is that as long as you keep these two things synchronized with each other similar a little bit to how a hash time lock works you can basically fund the channel with assets from different blockchains. Most of that I should say is written in the papers, we have some new protocols especially the papers we're focusing on more on a single blockchain, we now have some new protocols with multi-chain functionality but most of the protocols are formally analyzed peer-reviewed and as I mentioned we now also have cross-chain support. So from an implementation perspective how does the framework look like? So at the core we have the GoProon library and you can see that as an SDK for using that technology so it has an implementation of the protocols at its core and then the implementation is written against a set of abstract interfaces so we have a blockchain abstraction and you can basically plug in your favorite blockchain module if you implement it and then the protocol will run against this blockchain. Currently we have different features enabled we have plugins for Ethereum, Cosmos, Polkadot and Fabric, we are working on one for Cardano and on one for the DFINITY Internet Computer and a similar approach we took also for the peer-to-peer communication for the persistence so in order to store the state and restore clients we can also have a modularized approach so that you can plug in your favorite database your favorite network message broker and so on. So we really tried to have a modular approach so that these protocols and this technology can be used within any application environment and there are also some ideas now especially from that conference to use Firefly which has a similar approach in making these different components available to a blockchain application and maybe the idea could be to reuse some components of Firefly and plug them in here or something like that and then we have different ways of interacting with this core SDK if you have a full client that has a high online capability so who is online for extended periods of time and then you can use the SDK directly otherwise if you have a light client or an embedded device client which is something that Bosch especially is interested in you can use Perunote which provides some additional services and a simplified user interface for light clients and you can find all these repositories when you go to Hyperledger Labs, search for Perun but as I said I will also link to them later. Alright so a little bit more detail I think, I should have time to show this so this is the architecture of the library of the core library and here you can see exactly what I just explained so we have the core client protocols and they work against a certain set of interfaces this is the blockchain abstraction which has an abstraction for wallets, accounts this is the channel package is the abstraction for interacting basically a blockchain middleware layer where we can basically if the client wants to make an on-chain transaction it will tell that to the channel package and the channel package will translate that by corresponding chain specific implementation into an on-chain call and this also includes event subscriptions and similar for the wire package we have some abstraction for inter-client messaging for persistence as I just mentioned and you can basically then plug in your favorite implementation of that and to give you a little bit of a better idea how that actually looks like in terms of so the library is written in Go and this is a simplified version of the Go interfaces but this is roughly how it looks like so the wallet is a type that can give an address, can unlock an account an account is something that can generate a signature for a certain byte array then we need some functionality for marshalling and un-marshalling for sending it over the network and of course we also need the capability of verifying signatures so that's the account abstraction and the ledger abstraction is on the right hand side so for opening the channel we use the funder abstraction which basically must make sure so an implementation must ensure that when you call fund you specify the channel parameters that has been agreed upon in the opening protocol, the initial state and then the funding transaction should make sure that the funding is done into the on-chain contract then we have the attrudicator which is basically the dispute resolution mechanism and also has the settlement of the withdrawal capability so we have a method for registering a dispute so we provide the parameters which is fixed we provide the most recent state and we provide signatures from all participants on the most recent state and then the implementation should make sure that this dispute is registered and we have a specification basically how the smart contract implementation should look like and then for withdrawal once we have registered a channel we can also re-register in case somebody re-registered in all states so this is a function that could potentially be called multiple times but the client will know from the protocol at which point we are able to conclude the dispute and then we can finally withdraw the funds from the channel back into the account and of course for all of that it is often useful and necessary for the client logic to understand to consume events from the blockchain and for that we have the event subscription logic so when we call subscribe on the attrudicator we get an attrudicator subscription which basically allows us to consume blockchain events and then some helper functions is very crucial that from the parameters we can derive a unique ID for a channel it must be globally unique because in that this is basically a hash of the participants and determines who can in a way who can access the channel and if you have a duplicate ID you would actually by mistake fund potentially distribute your funds to the wrong persons so it is very crucial that this is implemented in a way that you get a globally unique ID for each channel and in practice this works by hashing all the fixed parameters into the channel like the participant especially the addresses but also by choosing a shared random nonce so that you are guaranteed to get a unique value out of that that could not be predicted by others and then of course we need some functionality for signing a state and for verifying a state and that includes serialization of a state so we need some functionality of serialization so that the blockchain can basically deserialize the state read it and also the blockchain must be able with this blockchain specific cryptographic signature scheme to verify the states on chain so these things are also chain specific because different chains have different serialization mechanisms and different cryptographic algorithms and these are some of the basic components that we need on chain to make this work so and finally some example of how the API actually looks like so this is again a bit simplified but some of it is actually real code so here you can see for opening a channel we first need to create a new client object and here we specify a bunch of parameters so we specify the identity the messaging bus, the type of funder, the type of adjudicator which wallet is being used and the watcher which is basically the service for consuming on chain events it can also be an external service that is why we moved it out of the adjudicator at some point then we need to start some handlers so that we can receive requests from other clients and consume blockchain events and then for creating, setting up a new channel we propose we created a ledger channel proposal which is a channel that sits directly on layer one we can also create virtual channels which sit on top of other channels but the most simple type is the ledger channel we specify the parameters like the initial balances which asset types and so on and then we run the channel proposal protocol including the funding and so on by calling proposed channel and if that doesn't error we have a new channel that we can work with and once we have a channel object we can now define an update logic so that works as follows we have a function that gets its input appointed to a channel state and then we can call on the channel object we call update by with the parameter of that function and once the function returns update by returns we are insured that this off-chain update has been enforced it has been agreed by all parties if we get an error so for example if one party doesn't reply then we have a dispute case and settle is the final operation from a user perspective from a developer perspective that will use our library and settle will make sure that either in the dispute case we run the dispute protocol or in the optimistic case we will just conclude the channel and withdraw the funds and yeah as I said especially regarding the initialization there is quite a bunch of work to do it's also blockchain specific how you set up the individual components but the other parts are actually more or less what you would actually write when you write an application with Perun okay and yeah which applications could you think of so what would be potential use cases one potential use case that Bosch is particularly looking at is building this technology in embedded devices for example to enable machine-to-machine payments so here the example is shown for making payments to an electric charging station maybe the user would have a cell phone that provides so maybe the car itself the embedded device doesn't have a blockchain connection but the user would have a cell phone which communicates with the embedded device and thereby enables blockchain connectivity while still enabling the car to do micropayments maybe for each kilowatt hour or something like that you can do an individual payment without any delays and then once the charging process is finished you settle at some point later against the blockchain when there's connectivity or basically when the blockchain so as long as you have the off-chain guarantee you can do the settlement anytime you like basically so maybe you could even already leave the charging station and the charging station would take care of the settlement or something like that then I mentioned the collaboration with Ayuna who is a gaming platform provider it's also a start-up so they are also in the early phases but their vision is that they have a gaming developer platform which is integrated with Unity or Unreal Engine I think currently they focus on Unity and they want to make it easy for game developers to write an application that uses blockchain without the complexity and they were running into the problem so they basically already had a scaling solution based on a trusted execution environment but they couldn't go below latency of 500 milliseconds or something like that and since Perun stationers appear to peer you have almost no noticeable latency it's like running a normal game and I don't know if I have time probably not but we also have a demo we will publish it soon where there's a simple tic-tac-toe game played in a state channel you can really see there's basically no noticeable latency so this basically here Perun sits on top of their existing scaling technology and additional and enabling like really low latency applications then we have the cross-chain use cases so since we have integrated different blockchains we can also enable and the protocols are capable that we can enable cross-chain swaps so for example if you think I hinted at this use case earlier if you think one client has Ether and he wants to swap it against apocadol tokens he can connect with a liquidity provider and do a trustless token swap so there's no trust involved, there's no trusted intermediary necessary you can swap tokens against each other and either the swap happens or not and you can even do it thousands of times so maybe if you think of two big banks that want to do a lot of swaps between each other before they settle that could be a viable application here at the moment I should note we only support swaps between two networks that are of the same type so it could be two Ethereum based networks this specific use case Ethereum to apocadol is something that requires the same cryptographic mechanisms to be available on both bitchains, the same serialization to be available and that just requires more work on the implementation side so that's something currently we focus on EVM to EVM or fabric to fabric or same types of networks on both sides another nice use case that is in the realm of decentralized identities so here we look at an example where there's an authority maybe a notary who provides a certificate service and wants to expect some payment and now maybe there's not enough trust that the authority wants to provide the certificate before the payment but the user also doesn't want to provide the payment before the certificate but we can basically use a swap mechanism we could maybe do it with a hash time lock but we can also program it into a Perun channel so that you can do a lot of swaps in short succession again potentially maybe between two big companies that sell or exchange certificates against payments so there's no risk involved in that because it's now an atomic transaction that we can program into the channel but it's still very efficient so we can do thousands of transactions of that type between two entities and the middle term goal is that we actually want to we have a proof of concept for that ready and we're looking at integrating that with the Hyperledger areas protocols so I think we're pretty much at time so yeah Perun, the Perun framework is a toolkit for enabling scalability and interoperability among blockchains is based on state channel technology it enables low latency high throughput is modular and is based on peer reviewed research you can find more about the Perun project at Github when you go to Hyperledger Labs you find the repositories there when you search for Perun we also have a bit of developer documentation where you can go through tutorials, play with it and yeah if you are interested, reach out to us, we're happy to get interest, contributions, maintainers whatever happy to talk to you, we have a Discord channel at the Hyperledger Discord but you can also find us via these links and with that thanks for your attention and happy to take any questions he was the first it's a good question so we have exploring a concept where it's customizable but the library as it's published so as it's on the main publishing branch you always have to pre-fund because only that way you don't need to trust the other parties but it's not that hard to customize it so I did a proof of concept where we only partially fund the channel so for example if you have some trust involved you could say maybe you reference a funding pool and if there's not enough funding for the final settlement then the funding from one party will be taken from an authorized funding pool which has the risk that the pool may run dry at some point but you can actually start transacting without any on-chain interaction if you trust in that so that enables off-chain payments for example where you can still track whose balances are what so you have some verifiability of which transactions have been done but you get kind of offline payment functionality so if you are interested we have a medium block post about this which also references to the code so any party can trigger it so in the optimistic case one party proposes to close the channel and then the settlement will be just one on-chain transaction and usually we split the settlement from the withdrawal so at some point the on-chain state will be concluded and there's no change possible but individual parties can withdraw it to their accounts whenever they like if you have a dispute so you couldn't settle the channel off-chain you couldn't finalize the state off-chain then the dispute period until you have to wait that the settlement can be done is configurable and that's I guess depending on the blockchain that you use depending on the application it can be minutes or seconds minutes or days maybe even so that's a parameter that you specify when you open the channel it also goes into the unique channel ID so you can specify it whenever you open yeah okay yeah I'm good that you point me to fast fabric because I'm not aware of that but I'm aware of like in general the space of rollups and so on that's something that we are aware of in terms of throughput what we benchmarked on our normal computers is about two to three thousand transactions per second but I think if you tune it a little bit maybe you can even go faster really what you just need to do is in case of a two-party channel, two signatures and the network communication so from a computational perspective it should be like anything like it depends probably on your round trip time on the network so in the realm of thousands of transactions yeah that's a good question yeah so basically we have an injection point in our so let's say we are on Ethereum and then we have our Ethereum smart contract and we have an injection point where you can in the dispute protocol inject arbitrary transaction logic so when you open a channel you specify this is a channel with custom transaction logic and then when the dispute protocol runs there's an additional phase that checks does the channel have customized transaction logic and then it will call a separate contract so like you deploy your tic-tac-toe contract separately and it has a value transition function so basically how the tic-tac-toe contract must look like you specify what is a value transition from one game state to the next one and so what our Perule smart contract will then do it will check, it will call the tic-tac-toe contract with the current state and the proposed next state and the signature from one party there must be at least one party that let me just recall if I understood exactly whatever exactly exactly exactly and we can call out to the layer one and the layer one uses that state machine to see whether this is exactly, we call it force move because now we have a method of enforcing logic that was predefined in comparison to just having to rely on a full consensus of chain yeah exactly yeah exactly exactly I don't know, I saw your hand raised that's also an interesting point yeah we don't guarantee like if both parties are cheating you don't have a reliable outcome like you couldn't rely as a third party that they played everything correct that would involve maybe an unrelated third party in the channel alright but if you think about swaps or some like chess game or something like that then you want to make sure that you're not betrayed but of course if they just tell okay this person won and it didn't even play the game then there's nothing you can do about it yeah that's not so much yeah we have mostly done put two party tests but not so much like the network aspects that would be also interesting to see I saw this, there's one in the back as well between the two parties in the channel you have the guarantee that whatever you agree on you can settle at any point in time so it's up to you basically I mean you can do it for like I think the typical point in time would be you want to use the funds that are locked into the channel in a different use case so you want to transfer the funds do a payment outside of the Perun channel then you want to close the channel and settle it but there's no need to settle the channel because maybe you fear of losing your funds as long as the channel is open and you still remember what the most recent state was this is also persistence is important yeah but for example maybe you want to do checkpoints for persistence reasons that could be a good point so yeah it seems at first that this is kind of contrary and sometimes we were also pitching the technology as a private channel because as you say you only see the result the settled result on the blockchain but you don't necessarily see the individual transaction but what you could do for example you could maybe, so there is an arbitrary data field that you can fill in the channel state so maybe you could populate that with the transaction history or something like that and make it so you could maybe even do some additional proof logic program it into the channel logic and basically enforce the correct transaction history I don't have a thought through answer for this but the basic thing that you just track an addition of the balances you track the individual transaction that's something that you can surely do I don't know if it's like how verifiable that is in the end against the third party auditor for example but that's exactly yeah as I said these are the blockchain so this is live this is live this is live with different feature sets so virtual channels for example so channels on top of channels we currently only have here channels with customised transaction logic we have in Polkadot now Cardano and DFINITY are in development right I think we have to we can discuss offline because we know each other