 Yeah, okay, I can sort of start there. Okay, so guys, my name is Patrick McCory. I'm assistant professor at King's Collies London. What I'm going to present to you today is some work that actually originated from DevCon last year. So last year, me and Lev Teres were having, you know, Pina Coladas and Cancun. Then he was telling me about in writing how they're trying to solve the monitor problem. So when I went back to England, I got talking to some people from UIUC, like Siri Bakshi and Andrew Miller. And then we sort of started to come up with a little solution. So first we did it for payment channels. And then I thought, well, actually, why don't we go a step further and try to solve it for state channels as well? So that's sort of where we got to. And I think there's literally that one slide that isn't going to load, but that's fine. I'll do it at the very end. And I also want to thank several people. So I think there's two people in the audience, Chris Bucklin and Sarah Mikkeljohn. They're both my co-authors, alongside Andrew Miller and Siri Bakshi. And Edo Bentoff as well. So I'm just going to move on. So everyone in this room pretty much is aware of what a state channel is about. You've had five presentations of how state channels work. So I just want to give you a very, very brief overview of how I think about them. So basically with a state channel, the idea is that parties lock coins into your contract and then they can run an application off chain locally amongst themselves. So it was poker, for example, if Alice plays her hand, then everyone in the state channel must agree that Alice has played her hand. And what the blockchain gives you is two properties. So first, there's safety. Every party should always get the coins they deserve. And it should also guarantee liveness. And we've had several people talk about that already. So if one person doesn't cooperate, then you could simply redeploy the app on the blockchain and finish it there. So the applications should always progress. So what I'm going to focus on is the bad case. You know, what if one person doesn't actually cooperate? So you're going to imagine Alice is playing poker. She reveals this royal flush. She gets really lucky. And she's about to win the poker game. Bob says, well, I'm not going to agree to this, Alice. If I agree to this state update, then you know what? You're going to win the bet. You're going to take all of my money, and then I've lost. So how does Alice ensure that she can actually self-enforce the correct execution of the poker game? We use the dispute process. And several talks have already outlined how dispute process works. And I'm just going to go over briefly as well. So when we harvest something called Kitsun channels and this sort of came out recently, and some people have already adopted it, which is awesome because it really helps with PISA, but it's really straightforward. We have a dedicated contract just for the state channel and just for the dispute process. So all this single channel cares about is signatures from every party. The hash of the state, so not the actual bytes for the state itself, does a commitment to it, and a state version. And during the dispute process, whatever state has the largest counter will be considered the most recent and final off-chain agreed state. So how does this work in practice? So what Alice will do is that Alice will create a transaction, broadcast it to the network, and initiate a dispute. Now the smart contract will say, okay, there is now a fixed time period for everyone to respond with their latest off-chain state that they are aware of. So of course, Alice is going to broadcast the state of the game where she's just about the win. And because this is the most recent state of the game, this should have the hash counter. After the fixed time period, anyone can send a transaction to the smart contract to settle the dispute. So what the smart contract will do is basically say, what was the state I received with the largest counter? That is the final state that people agreed off-chain. And that's all our dispute process cares about in this state channel. So what's really nice then is that Alice can deploy the poker game. So you can then deploy the full game state as well. And then the app will look at the state channel, grab the hash, compare them and say, yep, that was indeed the game state that we agreed. So that's pretty much how Kassun would work. And that's a really good way to think about dispute processes. So the problem of state channels is that we now have this always online assumption that several talks have alluded to. For this to work, both parties have to remain online and fully synchronized with the network. They have the WhatsApp for disputes that may occur. So what could happen is that Alice wins the poker game. You know, she's really wealthy now, maybe she can go buy a Lambo. And then she just goes to sleep. You know, she's gonna sleep and maybe play more poker tomorrow with Bob and the rest of the gang. So while Alice is asleep, Bob and the remaining people in the state channel, because there could be end parties, there could be five people in this state channel, they all collude. They say, well, Alice has beat us a poker and Alice has taken most of our money. Why don't we get that back? Why don't we trigger a dispute, broadcast an earlier state of the game, when in fact the game hasn't even started yet, resolve the dispute and then get our coins out? So that's what they could do. So Bob could trigger the dispute, send the older game state, and then the block just ticks away and ticks away. And of course, if Bob is successful, he could then deploy the poker game and simply withdraw his coins from the channel. Now for Alice to defend herself, she has to come online and go, oh no, Bob's trying to cheat me, and then broadcast the latest state of the game, where she in fact had won the poker game. And that's really important because the problem here is that there could be an execution fork. So whatever the parties agreed off Chien, while it's final, if they're online, that execution could get reversed if one party goes offline, because the blockchain trumps everything. So this isn't great. I mean, we have these payment networks, state channel networks, but now it relies on everyone being online and fully synchronized with the network. And of most people who actually, when was the last time anyone here fully synchronized Gith? Who managed to fully synchronize Gith here? I got like one, two, three hands. So that's what you're all up against. If you're going to use state channels, you can't even synchronize Gith to protect yourself. So really the question is, can we help alleviate this new security requirement a bit? I mean, we can't get rid of it, but we can alleviate it. So this is where Pisa comes in. And I know the Pisa is like a leaning tower and it's leaning the wrong direction, but it's going to go to the moon. You know, that's the joke I'm trying to make with it anyway. That's why it's a leaning tower. But yeah, the motivation behind Pisa is that we want to hire an accountable third party to watch the channel on our behalf. So it has some different properties. So first we get state privacy. So if I hire this third party, this third party doesn't actually understand my state. All they receive is a hash. The second aspect is fair exchange. So what I really want is publicly verifiable evidence that I've hired the third party. And at the same time, the third party always wants to get paid when they agree to resolve disputes on my behalf. So it needs to be a fair exchange protocol there. The third part is actually order one storage. So what's really beautiful about this protocol is that as a customer, if I hire this third party and I give them 1,000 jobs, they only have to store the latest job they receive from me. They don't need to store all 1,000 jobs. So for like 10,000 customers, we're actually looking at a couple of megabytes worth of storage for the Pisa Tower. And finally, recourse as a financial deterrent. So if Pisa does cheat and this third party cheats and colludes with the rest of the channel, you should hopefully be able to do something about that and financially penalize the tower for cheating. It's just the idea behind Pisa. So let's go into it step by step. So first we have two components. We have the state channel contract that as I mentioned already, it only cares about hashes, signatures, and a state version or the number. And it's actually a bit like a honey badger. It's compatible with most applications you can think about for state channels. Then the second contract is the Pisa contract itself. And this really only does two things conceptually. One, it stores a large security deposit from the third party. And then two, it simply just waits around for evidence that the third party has cheated. If someone could present evidence, it will effectively freeze the deposit and punish the third party. So that's the basis behind Pisa. So how do you set up Pisa? So we have this third party and he has a little smiley face because he's gonna do this to make some money. And what all he has to do is leave a small or leave a deposit with the Pisa contract. So my 1990 animation is floating across and now he's signed up. He's left this deposit and everybody can see that this third party now wants to run a Pisa service. So the next question is, how do we achieve state privacy? As I mentioned before, because of the way the state channel is designed, all the customer has to send is signatures for every party in the channel, the blindest state hash, and the incremental counter. And they just send that to the tower and that's basically what a job looks like. So actually all this job, all the Pisa, all this third party does is relay messages on behalf of Alice or the customer. They're just a relayer effectively. Now the question is, how do we get the fair exchange of this signed receipt and payment? So obviously this is layer two. So we want to pay the tower or the third party off chain. So the third party could be paid via writing or lightning. And what you could also have, which is really nice actually, is a one-way payment channel with the third party. Because one-way payment channels have the property where the sender can go offline and never lose their coins. They're protected against that fact, but that only works for one-way payment channels. Other assumptions we'll make for the presentation is that the tower, the third party, they're already aware of the state channel address on the blockchain. They know where the state channel exists. And the second assumption we'll make is that the payment information is pre-agreed, i.e. we know how much we're gonna pay the tower. And the second point is basically how long is this third party gonna watch your channel for? Have you hired them for one hour, three hours, forever? We'll assume that's pre-agreed for now. So how does this work? First, the customer will send the appointment to the third party. The third party will do some sanity checking. They'll get the message they received. They'll look at the customer state channel contract on the blockchain and they'll say, yep, if there was a dispute, I could actually relay this message and the contract would accept it. Then what the third party does is that they create a new signed receipt. This contains the appointment information, but it also includes this new hash that we call the receipt hash. So what the third party will do is generate a random number, they'll hash it, and they'll include the hash as part of the signed receipt. Now the customer gets this. The customer does some sanity checking as well. The customer says, yep, the tower has agreed to watch the job that I asked them to do. And now the customer will send a conditional transfer to the third party. Now what is a conditional transfer? In this case, the transfer will say the following. Third party, if you reveal the pre-image of the receipt hash before time t, you can get this payment. And that's basically what the conditional transfer will say. So then the third party can simply reveal the pre-amis s that it computed before. He reveals s to the customer and now the customer has his signed receipt and also this pre-image s. So they can prove to anyone that the third party agreed to watch the channel on their behalf. And the pre-amis proves that this third party was also paid. So they've actually been paid for doing this job as well. So that's why we call it a signed and ratified receipt. Of course, what if the customer doesn't cooperate now? What the third party could do is get this conditional transfer and simply broadcast it to the network and then redeem the payment via the blockchain. So the third party can always get the payment as long as they're willing to reveal the pre-amis s. So that's how we get our fair exchange. Now the next question is, you know, what happens if Bob and Pisa collude the cheered Alice? So you know, again, Alice goes offline, sees asleep dreaming about being a Lambo bro and then Bob triggers a dispute while Alice is offline. He sends the state update, which is an older state that would give him more coins than he deserves. Now Pisa should step in and Pisa could relay the message to settle this dispute. But Pisa doesn't. You know, Pisa is colluding with Bob, oh my God, it's happening, it's losing, boom, Bob wins. He resolves the dispute, he gets his coins from the channel and Alice is lost out. You know, Alice wakes up and sees really angry. You know, she's like, wow, Pisa cheated me. I thought it was accountable. I thought Pisa would never cheat me. So is it too late for Alice? I mean, is there anything Alice can do about this? Well, there is. I mean, this is the accountability part that's quite important. Alice has the signed receipt from the tower or from the third party that they agreed to watch the channel on her behalf. Alice also has that pre-amis s to prove the third party has been paired to do this job as well. And what she also has is a dispute record on the blockchain. So there's a record of the dispute on the blockchain that, you know, that what the tower could have responded to resolve. So what does Alice do? Alice gets the signed and ratified receipt and simply sends it to the Pisa contract. The Pisa contract can request all of the disputes from the state channel contract and then the state channel contract will return the list of disputes. The Pisa contract then says, okay, that's the good of the disputes. Well, that's the good of the receipt. Was there a dispute that the third party could have resolved? Yes, there was. Then what happens is that, you know, the third party's crying because his deposit has been frozen. I know Alice gets a little bit revenge. You know, so he penalized the third party for cheating. Now there is an alternative scheme where Alice could be compensated as well. So instead of simply burning the deposit, you could compensate Alice, but that comes with some caveats as well. So I can answer that during the FAQ if anyone's interested. But that's basically the summary of Pisa in a nutshell. That's state privacy. There's this fair exchange protocol. There's order one storage. And we have recourse as a financial deterrent. I'm not sort of what you'd want out of this third party service. Now, in terms of related work, what I should mention is that Pisa is in the very first solution. There was an initial YouTube video by Taj at Scaling Bitcoin a few years ago for Monitor. And then you have the Watchtower protocol as well that was presented at BPIS earlier this year. I think it was earlier this year, maybe around February time. Now they're both for Bitcoin. And what they mostly focus on is state privacy. I'm a customer, I get some encrypted blob, and then I give it off to the tower. They never focus on accountability. So if I hire the tower or the monitor, I have no evidence that I've ever hired this tower. So if they cheat, I have no evidence of hiring them, I have no way to either damage their reputation or financially penalize them. So what's beautiful about Pisa is that that's what, I guess that's our main contribution. That's what we mostly focused on. And because it's designed for Ethereum is deployable today. And actually our protocol is somewhat compatible with Watchtower. So we also improved the Bitcoin protocol as well. And I actually think this is a really good way for at least academic researchers to design protocols. If you design it for Ethereum, you mostly only have to focus on the concept. And actually when you design a smart contract, given the concept, it's really easy to write as a trusted third party that is a smart contract. Where normally when you focus on Bitcoin, you know, you're sort of trying to punch Bitcoin in the submission, they get it to do something it really doesn't want to do. So I mostly focus on doing stuff for Ethereum now and then retrospectively see if this will also work on Bitcoin. A lot of the time it's not really worth the while either because they won't update it. But anyway, that's my rant over. So two years later, you know, state channels have been an idea as I mentioned from Jeff's blog. Actually that was 2015, that's three years later. I believe we're on the verge of practical and deployable state channels. As we've seen today, we've had lots of people building state channels. Last night I attended an event and three out of eight presentations said they want to use state channels as part of their product. There's still quite a bit of research to do but I believe state channels are, for a big part of it, mostly an engineering challenge to go build it and see how well they work, what parameters should be set, et cetera, et cetera. So basically, magic unicorns need not apply. We no longer need magic unicorns for state channels that work. So that's pretty much the summary of my talk. What I went over today was PISA which is the one in the middle, which is an accountable third party. In the past with Andrew Miller, I worked on sprites which was one of the first state channel constructions or actually was multi-command focused. During that dispute process, you issue a command and you self enforce a state transition that way. So the goal there was to ensure the state channel never closes. You just submit commands and that's how you do your state transitions. And then more recently I did a case study where pretty much we built this two player battleship game and we really wanted to empirically evaluate how well state channels work. And we got some lessons from that as well. But what came out of that was Kitsun was that application diagnostic state channel where the state channel really doesn't care what the application is. Basically, you design the application as normal for the blockchain. You add this locking and unlocking mechanism then you can lock yourself into the state channel and then unlock yourself. And what you really learn is that state channels are mostly an optimistic way to scale. If everyone cooperates, we can optimistically run off chain. If one person doesn't cooperate, then we just default to the tortoise, you know, the lower layer. That's slow and expensive, but we can always default back to that. So I'd like to thank my co-offers. Of course, I put their photos up there. And I also want to thank the Ethereum Foundation, the Ethereum Community Fund and the Research Institute for helping sponsor this research because with our sponsorship, it's very difficult to get any research done. So I guess that's the end of my talk. So thank you guys for listening. Awesome, I have two minutes apparently. Hi, thank you for an interesting talk, first of all. Maybe a stupid question here, but okay. So the parties in the channel submit the latest version of the state, the state hash and signatures of all the parties to PISA. But if one of the parties is trying to act maliciously, okay, do they submit their signatures for each updated version of the state? Because why wouldn't they? They can't do, so if you think about the receipt, the receipt will basically say, I will relay this message according to this version number. So what the PISA, what the third party must do first is that given a job, the third party must validate itself that this actually works. So they look at the state channel and they can just simulate it and say, yep, if there was a dispute, this will always be accepted by the state channel contract. I think that's what you're alluding to. Yeah, well, I was kind of wondering if somebody, if a party in the channel withheld their signature. Oh yeah, so for example, the poker game instance. So Alice plays her hand and Bob doesn't respond. What Alice would have to do is send the previous state that everyone agreed upon. If you're missing a signature, then it won't be accepted into the state channel. Okay, thank you. Awesome. I think I've got 19 seconds, so I don't mind ending it here. Oh, there's one question here if there's time. Yeah, there's, yeah. I think we actually have a bit of time. Awesome. So I was wondering if Alice has a lot of money at stake and they collude to get it out. Don't you require the validator, the watcher to have more money at stake? You do, yeah. So there's different ways to think about this. So obviously for the third party, if their collateral is less than they're gonna win, then they're always gonna cheat if there's a positive payoff. So that's why I normally say a large security deposit, they might have to have $10,000 locked up. And there's two ways you could do it. I mean, you could do this, you know, simple punishment, and that way there's always this constant financial deterrent. One issue with, you could do compensation. So what the tower could do, they could lock up collateral. So if they have $10,000, $1,000 could be directly allocated for Alice. So if Alice does, I mean, if they do cheat, Alice always gets refunded the $1,000. The issue with that is that that actually strictly weakens the financial deterrent. And this is like a generic issue of any protocol that has a central deposit. And why do I say that? So if $1,000 is locked up for Alice, the tower could also lock up $9,000 for its Siebel, and then it'll always get those $9,000 back. So that way it'll have to be fully collateralized to make sure Alice can never lose any money. Yeah. So actually you have to have the sum of what everybody has at stake plus something that they lose. If there'd be trustless, it would have to be fully collateralized. But actually, I think it worked quite well on risk as well. So in the appendix of the paper, we actually consider the case of risk where what if it's over-collateralized? It's actually somewhat a fractional reserve. It's actually still quite difficult for the Tower of the Wind because you have to assume that everyone's offline. Well, actually maybe only two parties are offline. Everyone else is online. When you're burning the collateral, you're actually giving money to everybody who has stake in each. So there's two instances, there's burn which is strictly burns it and no one gets any coins. Or you could do the compensation where you reward the loser, whoever lost their money. So you could do both. Yeah. I always find the financial, the burning much easier to think about because it's a constant cost. Okay. Okay, I guess that's it. Awesome. Thanks, Patrick.