 to have Joseph Poon, a co-founder of the Lightning Network, to present today on state channels, systemic security considerations and solutions. Do you have a clicker? Hi, everyone. Today, I'm going to talk about how to construct state channels in a secure way, as a lot of the channel type constructions are going to become more popular in the coming months and years ahead. State channels, perhaps, have some greater complexity when it comes to certain aspects of the design. But the general promise is fairly interesting in so far as, perhaps, I have five channels with some end participants. And I could potentially do contracts with potentially everyone in the room off-chain, but ultimately enforceable on-chain, by having the payments flow through. And the contract states flow through between multiple participants. The clicker doesn't work, though. This one? Got it. All right, cool. So on the blockchain, economic considerations are at our, I mean, on the blockchain, adversarial economic considerations are functionally security considerations. The primary issue is related to off-chain contract consensus. Because this is sort of off-chain, you don't have the blockchain itself to resolve the double-spend problem, so you resolve that through economic incentives and structures. And that requires penalties to be structured when you are not operating correctly. And that requires a great deal of presupposition when it comes to the design. And there's a lot of structure that you have to consider when it comes to the cost of the enforcement itself, much like how you can write 1,000-page contract, but your legal costs will probably add up when you ultimately require enforcement within the court system, which in this case is the blockchain. Now, consensus faults between channel participants are not that interesting when one person is acting faulty and it's not enforceable on-chain. But there are possibilities where you can enforce multiple states on-chain if you design the contract incorrectly. And this is a huge problem if this actually happens, because let's say you have some option contract and it can be resolved at $5 or $10. And one person preferentially wants to have it resolve at $10, you're going to want to enforce that contract on the blockchain as soon as possible, because you make a lot more money. So certainly there's a lot of information costs associated to that due to the uncertainty, but these are also explicit costs. You will outright pay the minor or validator set a higher amount purely because you're going to make more money. So the solution is to only allow one participant to enforce a set of states within some larger set of the contract. There may be alternate solutions, but this is a good rule of thumb for now. You could do other constructions using different types of cascading bonding structures, but that could end up being fairly complex. Additionally, penalties need to be predefined. You could have some type of adjudicator, third party, end participants, but usually if it's a two-party contract, you need to predefined everything using fidelity bonds. And what you're functionally doing is you're creating the incentives for the participants to be staying off-chain. If you have the incentive structure aligned correctly, then we can attest to the state. We both agree on the current state, and we both know if we deviate that we will not win. Systemic risks are also something to seriously consider, mass spam risks, et cetera, et cetera. There are different solutions for these types of things, like time stop constructions. This is a current area of research, but this is not specific to channels. Anything with fidelity bonds are going to have this issue, and it's a fairly interesting thing to resolve. And the most clean way to resolve a lot of this is to be using relative timestamps. When you're using a relative timestamp in your contract, generally the cost of enforcement is going to be relatively persistent, provided that the size of the enforcement of the attestation is smaller functionally. So if you're making a large attestation and you're making an incorrect attestation, the enforcement of that is probably going to be smaller, but it's good to make sure that it is. That way the cost, the blockchain costs are commensurate. Additionally, it's really important to keep it simple. A contract can be easily split into many smaller contracts, and when you do that, that allows for a great deal of isolation. Sorry. Modularity in this case is more of like a UTXO model, and that's fairly... The UTXO model is interesting insofar as you have predefined inputs, have some set of predefined outputs, and you have a potential network of contracts that can build some kind of circuit path. And... Oh, sorry. There you go. So ultimately, you always do want to be able to enforce things on chain, and you cannot ignore that aspect. And when you compute across a network of participants, the cost multiply. Now, a lot of this sounds really, really scary, and this is about risks and solutions. And I think when you look at these types of constructions, what you have are you have multiple participants that want to be able to transact with anyone else in the network, right? So let's say I'm Alice, I want to have some type of financial contract, let's say it's some options contract of some kind or some futures contract, whatever it may be, and it's a conditional payment with some terms, HTLC referring to, you have some contract term and some expiry that can be refunded and cancellation of that contract. So ideally, you want to be constructing this off chain, so if I'm Alice, I don't have any communication on chain with Dave. So I have some on chain record, some contract with Bob, and ultimately the funds will eventually propagate through to Dave. I have the option of enforcing this on chain, but I elect to do it off chain because it's cheaper, et cetera, et cetera. If at any time, either party can prove the attestations on chain, so let's say if Bob and Carol's disconnected, they can go talk to the blockchain, but Alice and Dave still remain off chain and it's fairly efficient. However, the problem from this is that when you attest on chain, the cost can be higher. A lot of the benefits of this technology is that you can resolve a lot of incentive structures on the blockchain. So an example would be like I was talking, like Zuko was talking to me about the sort of free option problem, right? Last night we were talking about that and the free option problem is functionally that one person can start a contract and the other person can, they have a free option of whether to accept it or not. And even if you resolve, like with the Catholics talk, even if you resolve certain aspects with sharding and efficiencies related to that, what a lot of the channel technology gives you is the ability to atomize a lot of the contracts themselves so that you can make the individual contract terms incredibly small and do a tit for tat increase of the actual contract. So let's say I wanted to enter into an options contract with someone or some futures contract. I can make, I can design a contract for 10 cents and the free option problem starts becoming negligible to the point where it doesn't even matter. And you can do that 10,000 times to create something with real value and ultimately have it enforceable on chain. However, with complex contracts, there is some issues when it comes to requiring the participants to enforce a lot of these things. But instead of computing the network contract on chain, you should be a testing to the results. And earlier in the day, there was a talk about Trubit. So let's talk about doing a Trubit type construction on channels and especially a network of channels. Instead, in this case, when you're a testing on chain, both participants end up funding with Carol doing like she just selects where the funds come from. In this case, it's her own funds. And Carol is functionally saying, okay, here is the contract, here are the inputs to that contract. I'm saying, and Carol is saying, here are also the end computed results of this contract. So Carol actually isn't asking the blockchain to compute anything beyond this attestation because this individual contract, let's say, is incredibly complex in some manner. But she's saying the blockchain, hey, I'm putting up, let's say the contract is $100 equivalent and she puts up another $100 equivalent and says, I am saying that I get $100. I'm also bonding $100 with some time component before I get refunded. So let's say she has to wait another day. So perhaps three or four, however long it is, before she can get her money back. So what she's saying is, if I'm wrong, we can do the full computation on chain, but we don't need to right now. I'm saying this is the result. I'm telling you this is the result. You don't, every single node on the blockchain does not need to compute this. So she puts up the bond and after some end period of time, let's say, over these four days, she gets her payment, Alice and Bob normally computes it off blockchain because, like they're computing, they're communicating normally. In this case, Bob and Carol are not communicating normally, so they need to go to the blockchain. And that's kind of a good situation. If you're Carol, you put up some bond, you get your bond back, you also get the payment from Bob, and then you can deliver the payment to Dave. Remember in this case, Bob and Carol are sort of like intermediary actors who you don't really trust. In this situation, Alice is paying Dave, but Alice doesn't have an on-blockchain construction with Dave, so Alice has the contract, flow through Bob, and then to Carol, then to Dave. But let's say Carol is a malicious actor and wants to deceive the blockchain. What happens in this case, right? In this case, Bob enforces this and tells the blockchain, hey, Carol is lying, you should compute this. And Bob can similarly put up a separate bond to discourage Bob from overly requiring the blockchain to compute too much. Let's say Bob is correct, everyone, all the nodes compute this, and they say, oh yeah, Carol made an incorrect attestation. Carol should lose her bond, and she loses her bond to Bob. And this construction allows for a minimization of the amount of computation that you need to do on the blockchain entirely. And this is using a construction on top of this type of construction allows for you to do this in a network of channels. Additionally, if a concern would be, well, if I'm Carol, I don't have enough money, I wanna put up this bond, what do I do? If you're a third party, it's not an issue because, well, you know the inputs, you know the outputs, you can compute it, you know this bond is good, Bob can't dispute it, so you can put up really any amount of money provided that you're computing correctly. The bond is an interesting structure because what it gives you is the ability to account for the cost of high computation. So what happens is, if the contract is a very costly contract to compute, you can attach a similarly expensive bond, but the benefit of this type of construction is you get your money back. So it's sort of like paying for computation, but because you don't have to actually pay for it, because you attested to the correct state, you get refunded. Whereas if you attest to an incorrect state, you actually have to pay for the computation itself. So what we're really doing here is we're reducing and eliminating the need to do full on-chain computation and I can have a channel with end participants and be able to do complex contracts with anyone on the network. Thanks.