 OK, so thanks a lot for the introduction. So this talk, well, as one just said, it's about virtual multi-party state channels. Actually, so most of the credit should belong to Christina. She was supposed to give the talk, but unfortunately she got sick. So some large part of the slides are from her also. So let me start with a short introduction. What are blockchains? Because this is a blockchain session. So blockchains are essentially a decentralized data structure for storing transaction, as you probably all know. So they are like kind of miners that maintain the blockchain. They process the transactions. And they integrate new transaction into blocks. So there are different types of transactions that have been proposed or that are used in the literature. So one famous example is Bitcoin. Bitcoin uses transactions for payments. So for example, if I want to send some money to Ivan over there, then I can do this via Bitcoin, sending Bitcoin payment transaction. But transactions can also be used for many other things, for much more complicated applications. And one prominent example is the cryptocurrency Ethereum. And there are also many other cryptocurrencies that support transactions for something more complicated than just payments, namely for smart contracts. So smart contracts are essentially programmable money. So we have some kind of program that is deployed on the ledger. For example, it could be some chess game, could be some other program that you can think of. The parties deploy this contract code on the ledger. They also deploy some or send some coins to the contract. So these coins are shown here with this one. And then once they have deployed this contract, maybe some chess contract in this case, then they can interact with this contract by sending transactions to the contract. And this initiates some kind of execution of the contract. For example, this could be a function call making the next move in the contract. And this can be many executions of the program. And at the end, at some point, maybe Alice wins the game. So she finalized the contract and she gets back the money that she won. So why do we need a blockchain for a smart contract? Essentially, what the blockchain guarantees is that we are guaranteed that the contract is executed in a fair way and also we have guaranteed termination. So what does it mean termination? Essentially, there's no way, like in this situation, for example, Bob may be inclined to stop the execution such that Alice cannot win the money, but he cannot do this because of the guarantees of the blockchain. As you probably all know, there are many challenges in blockchain technology, but one important one from a technical point of view is scalability. So if more and more people want to use the blockchain, so they send more transactions to the ledger to run some decentralized complicated application, the blockchain gets congestion. For example, in Ethereum, blocks are created all 10 seconds. Every 10 seconds, the new blocks are created. This results in a relatively slow execution. So for a chess game, maybe it's still fine 10 seconds because you probably anyway need longer to think about what is your next move, but for other contracts, 10 seconds could be way too slow. Another problem is also that there can only be a limited number of transactions be processed in such a block. And since many people compete for integrating transactions into a block, this results into high fees. The one solution to address these problems are so-called off-chain protocols, which is also the topic of this talk. In this off-chain protocols, we kind of like we want to limit the amount of usage of the blockchain. The blockchain is somehow this trusted component. It's slow and expensive, and we want to use it as little as possible. So the users essentially carry out the contract execution directly between each other, and only in case there's some dispute, some disagreement, then they go to the blockchain and resolve this. So this is called usually dispute process, and the blockchain is kind of takes the role of a judge. So this has been quite, the off-chain protocols have been quite hot topic in particular in the cryptocurrency community, because it's one of the main technical challenges improving the scalability. So there are many different proposals. For this talk, most important are the channels, so payment channels, state channels, channel networks, and so on. I will explain some of them in a moment. Initiated this channels or payment channels were initiated by the work of Decker and Wattenhofer, and there were some important extensions by Poon and Dreyer, who proposed this lightning network. Probably some of you have thought about it, which is a payment channel network over Bitcoin. And there are many more informal publications and also many academic publications. For us, most important is the peer-run protocols, which are essentially state channel networks. And in these works, they introduce essentially two types of channels, so-called ledger state channels and virtual state channels, which I want to take a look in a moment now. So the ledger state channels are essentially executed between two parties, Alice and Bob. They have three phases. In the first phase, we create the contract on the ledger. So Alice and Bob, they send some kind of transaction to the blockchain to deploy the contract code, the channel contract. They also lock some money in this contract, like one coin and one coin. And this results into this blue arrow here, which represents then the off-chain channel. Now, once they have created this channel, they can now execute contracts in this channel. So this is now taking care of chain, so without interaction with the blockchain. So that means it can go very fast and it's very cheap. And at technical level, this kind of exchange here is done by what we call signed versions of the state. So the party locally computes the next state of the contract, signs it, sends it to the other party. The other party verifies it, signs it, and sends it back. And you can repeat this many times. The version number here represents a state counter. At some point, maybe Alice wins, and then she can go to the blockchain and close it. So at that point, again, we have to go interact with the blockchain, which is expensive and slow. And there's another important process here, which is called a dispute. So at some point, when parties disagree, then they can go to the blockchain and resolve their dispute. So that is also the case why this has to be on chain. So the main contribution of this work of DFH-18 was the introduction of virtual state channels. So what are virtual state channels? So imagine we have the following situation, Alice Ingrid Bob. They are connected by ledger state channels, each of them. And now Alice decides to play with Bob. So what she can do, of course, is use this technique that we just talked about. So create a new ledger state channel. That is, of course, costly, because you need to deploy this channel contract on the blockchain. And also for closing, it will be costly. So alternatively, we can use these two underlying ledger state channels as a two-party blockchain. We can run any contract here and any contract here. So the parties can deploy what is called a virtual channel contract in these two ledger state channels. And then create this virtual state channel. The good thing is that this is creation closing can be done off-chain without any communication with the ledger. So this is then fast and cheap. So in this work, they also extended this to allow longer state channels, those called state channel networks. So if, for example, party 1 wants to communicate with party n, then they can recursively create these virtual state channels until party 1 has reached party n. So this is where our work starts. So there are several limitations of this work. The first one is that if there is a conflict in this channel, so these two parties here and these channels disagree, then they have to go to the blockchain, they have to run this dispute, and this takes time off n. And it's linear in the number of parties that are intermediaries. This is something what we don't want usually. The second limitation, which is probably the more important limitation, is that in the original work, there were only support for two-party contracts. So if you want to run a poker game with more than two parties off chain, then you cannot use this construction. So we resolve these problems. So we construct a new channel protocol that has a dispute time of o of 1 by using what is called direct disputes. Then we also introduce, and this is probably a main contribution, multi-party state channels so that allowed to run multiple parties, multiple contracts with multiple parties off chain. Then we have an extensive universal composability modeling of all these primitives. So in this talk, we mainly focus on these two parts and give very high-level overview. The protocols are very technical, so I would recommend to you to look into the paper for more details. So what are direct disputes? So let's take first a look how the disputes are handled in the virtual state channels of the FH-18. So we have these two parties, Alice and Bob. They have this contract here as executed, and then at some point it turns out that Bob is not responding to the requests of Alice. So now this could be just before the last move. So how can Alice now resolve her conflict? In the original construction, it was done like this. She contacts the intermediary, so goes to an intermediary ingrid, tries to resolve the conflict with ingrid. So she sends some messages to her. Then she, of course, doesn't know what is the current state off-chain in the channels, so she contacts Bob. If Bob also is not responding, then also this contract goes here into dispute, so this channel contract that was deployed in the underlying ledger state channel. And then she will go to the blockchain because this is distrusted, as I mentioned in the beginning, distrusted last resort on which we can always rely for termination, for execution. So there she can finally execute it, and then resolve the conflict in this channel here. So like now this was for just one intermediary. Now, of course, we can have several other intermediaries, and it turns out that this kind of process grows linear with the number of intermediaries. So what we do instead is, well, kind of simple. Essentially, when Bob is not responding, then we will use what is called a direct or like a dispute board contract. So the party will, instead of talking to the intermediary, they will directly go to the blockchain, send the latest state, this signed version number state to this dispute contract. The dispute contract goes in a waiting state to give also Bob some time to react. Bob can then send his latest state, and then the contract will decide what is the latest state, and settle the dispute. And from then on, Alice can continue executing on-chain. So as you can see now, in this case, you don't need to talk always all these intermediaries. We can directly go to the blockchain, and we can resolve conflicts in a time of one. Of course, there's several technicalities that you need to solve. Now, like for example, Ingrid is not aware what was happening in the dispute, so she needs to kind of, when there's the closing of this channel, she needs to take the latest state from here to have it reflected in her underlying ledger state channels. But this can be taken care of with our protocol. So now we go to the main contribution, well, the main contribution of our work, which are the construction of virtual multi-party state channels. So the goal essentially is now we have a scan in network topology, Alice is connected to Ingrid, Ingrid is connected to Bob, they're connected by these two ledger state channels. And now they wanna, for example, play three player poker over this kind of network. So what can they do? Well, first I can ignore, of course, these channels and open a ledger multi-party, so ledger MP state channel, by deploying a contract directly on the ledger. So this was proposed in the work of Andrew Miller and some other people, it's called Sprites Network, and it's actually used, I think, in Ethereum for the RAID network. So what they do is say, yeah, so the problem of this approach, of course, is that creation and closing is slow because we need to interact with the ledger. So what we introduce in this work are so-called virtual MP state channels, which use these existing underlying ledger state channels to build the virtual multi-party state channels. So at a technical level, it works like this, that essentially the parties here deploy a virtual multi-party channel contract in this ledger state channel here and another one in this channel here, and this contract will take care in case of disputes to resolve conflicts. The good thing with this is that creation and closing is again fast because we don't need to go to the blockchain, at least in the optimistic case, we just talk to the parties, just talk to each other without interacting with the blockchain. But so let me now have a closer look at how this is actually done. So we take a look at the poker game where each of these parties, so there are three parties, one to play maybe poker against each other. So again, similar to what's happening for ledger state channels or also virtual state channels, we have three phases. In the first phase, we create this virtual MP state channel over these two ledger state channels by deploying these contracts in these ledger state channels. So this happens completely off-chain. Once the channel is established, this happens like they execute some signatures and so on and do some communication. Once this happens, then they can load a contract into this channel. They can also lock some coins in this channel, like in this case, each party locks one coin into the poker contract and then they can execute this. So they can run this for multiple rounds. At some point, maybe Alice will win. So she wins all the coins here, other parties lost. And then in the last step, when they don't want to use anymore this channel, then they can close it. And the closing is essentially reflected in the underlying channels. So now we have to somehow make sure that Alice, since Alice won the three coins in this multi-party state channels and Ingrid lost coins here and Bob lost also coins here. This has to be reflected in the underlying ledger state channels. So how does this happen? Essentially, the contract here, this will take care of during the closing procedure that Alice wins two coins here. So in this channel, she gains two coins because originally she deposited one coin and two coins she wins by winning the game. Then of course, because of the fact that you cannot create money out of thin air, so we need to like have that Ingrid loses two coins on that side. Now the problem is of course that Ingrid now lost more money here than what she was supposed to lose in this contract because originally she only lost one coin. And how do we do this then? We do this that essentially here she is compensated. So here she gets one coin plus and Bob has to compensate in Ingrid for this. So this is how the ideal functionality kind of like what it guarantees. And then guaranteeing this is of course complicated because they are like, this is like the simple case just with three parties but it's extended to multiple parties as well. So in the end, as you can see overall Ingrid and Bob each lose one coin even though of course Ingrid is here more in the negative than here she is in the plus. As I said, this can be extended to more complex networks. So for example, consider the situation when Alice, Bob, Dave and Emma want to open a virtual multi-party state channel. What they can do in this case is and Ingrid doesn't want to participate so she is not interested, then they can cut out Ingrid by opening a virtual two-party state channel over Ingrid so they open this two-party virtual state channel over her by deploying these contracts. And once now all parties are again directly connected by two-party channels, they can open a virtual multi-party state channel by deploying these virtual multi-party contracts or virtual multi-party channel contracts in the underlying channels. So there are many challenges. One particular challenge in designing this protocol is concurrent execution. So we want that everything can happen at the same time and there's no restriction on the ordering of messages. So what can happen, for example, in such a case is that all parties want to, because they're independent participants, they all start to execute the protocol at the same time. So maybe they all make a move in a game at this exactly in the same time. And now we somehow have to take care about the ordering of this execution. This is similar to what happens in Bitcoin where also like in any blockchain system where the miners take care of the ordering of the transactions. So by processing one transaction first, they also take care of this ordering. So what we can do is, a naive approach is to give each of these parties a slot, separate slot for execution when it's her turn for execution. And if it's not her slot for execution, she is not allowed to do this execution. So if she tries to execute, we just reject. But this results for large channels in a round complexity of ON. So we have a more clever protocol, which is a four-round protocol in the optimistic case, and it uses in the pessimistic case, the ledger. So if there's some disagreement, then we go again to the ledger, but in the optimistic case, we can be very fast. So there are many more challenges that we have to address to make this whole protocol work, in particular because we want to support full concurrency not only of one contract, but in the virtual state channels, we can run like an arbitrary number of contracts in parallel. So we also support arbitrary network topology. So any kind of topology you can build over multi-party state channels and so on. With the UC modeling, we allow that you can combine multi-party channels with two-party channels and two-party channels can have direct dispute or indirect dispute, so you can combine these kind of channels in an arbitrary way to have some arbitrary complex network topology. And we have to deal with some UC technicalities, in particular with the fact that the joint state, that ideal functionalities have some joint state. So let me summarize our contribution. We introduced the technique of direct disputes for visual state channels. We also introduced the first construction of multi-party, virtual multi-party state channels for any network topology. All protocols have round complexity of all of one in the optimistic case, of course. There's interaction sometimes with the blockchain needed, but in the optimistic case, there's no interaction with the blockchain. One main open question that remains is that the virtual multi-party channels that we considered, they have this direct dispute that we built and it would be interesting to have them also with indirect dispute where you go layer by layer and contacting your intermediary first to resolve the conflicts, which has the advantage that in a dispute, you don't need to directly go to the ledger. You first have some kind of layer of defense which can help you to resolve conflicts before you actually go to a ledger to resolve the conflict. So thanks a lot for your intention. Also, we are hiring at the Peru network. We are implementing this protocols. So if you're interested in working on this kind of topic, please let me and Stefan know for implementation questions or anything. Thanks. Any questions for Sebastian? Thank you for your nice presentation. I just had one question about security of this lightning network. As recently, they have been shown that they are privacy attacks on this lightning network because of using fixed, let's say R as a, I mean key between each other. Just I wanted to say that, okay, your system is also secure again, it or it is, you are using the fixed R between all parties. Okay, so we don't use any fixed, so this what you are referencing to is called like the test time log transactions. So where you essentially have a pre-image, you have to reveal to make the transfer happening. In our case, we have some kind of privacy for free because, to some extent at least, because like in this virtual state channels, if you look into this situation, well, I'm here. So, yeah, you see here, like once this virtual state channel is established, this interaction is happening without the intermediary involved. So she does not really know, for example, that these two parties now deploy a chess contract, okay? Or they do some payments. So this is kind of oblivious. So there's not like in the lightning network, it's like this, I send something to you, you send it to him and he send it to blah and so on. So in this case, you will have the situation that of course intermediaries can try to learn something. Here, like the routing is happening directly. So we once build it and then we send everything over this. So what happens exactly in this channel, the intermediaries don't know, of course, unless there's a dispute between us, but in this case, one of us is corrupt and then there's no privacy anymore. What's the guarantee that one of these active channels will not be closed before the other ones? I mean, you have several active channels between nodes. Well, it is what the protocol takes care of. I mean, the protocol has carefully designed to make sure that it's not happening, that this channel is essentially closing before this channel is expired. Essentially what we do it, each of these channels, how we do it is each of these channels has an expiry date, okay, so it's called like validity and the validity time here is lower than the validity time for the underlying channels. So you can make sure. So we have to almost move on. I guess one short question is that, so you say like this is all kind of you say, as you example using Ethereum, like do you think you may take more advantage of like the Turing completeness or the expressiveness of Ethereum or the fact that it has a sort of more stateful model or like what would, could you deploy this in a currency like Ethereum or a model like Bitcoin? For sure, I like it. Or a transactional model, yeah? Well, I think you could potentially also deploy it in transactional, like in Bitcoin like currencies, but not, I mean, not in Bitcoin directly because you need like, for example, kind of the state what you describe, which is not really there in Bitcoin with this version number. So all of this works, like not with this hash time lock transactions, but works with this signed version number. So like you compute something, you put like a count, like a version number there. Next time when you compute something, you put a higher version number there, you sign it, send it to the other party. And this is essentially how this works. And for this, you need somehow that you can like, in a contract can have some kind of state. So I send something there, the contract figures out, okay, maybe this version number seven, the other party sends something there. And then, so it has to remember that the state was seven. If Bitcoin supports something like this, then I think we can also integrate this into Bitcoin. But currently it's not possible. But it really needs like very limited, like scripting functionality, not like some kind of heavy stuff. Of course, if you talk about state channels, then the underlying currency has to be sufficient to anyway deploy contracts, otherwise it's not possible. All right, let's, thanks for watching again.