State Channels Systemic Security Considerations and Solutions

you very pleased to have Joseph Boone a co-founder the Lightning Network to present today on state channels systemic security considerations and solutions you have the clicker hi everyone um 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 you know 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 insofar 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 alright cool so on the black chain economic considerations are I mean on the blockchain adversarial economic considerations are functionally security contract 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 operate went 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 know you can write you know a thousand-page contract but the your legal toss will probably add up when you ultimately require enforcement within the court system which in this case is the blockchain now consensus falls between channel participants are not that interesting when one person is acting faulty and it's not enforceable on chain but there are there are possibilities where you can enforce multiple states on chain if you design the contract incorrectly and this is a huge problem to if this actually happens because let's say you have some option contract and it can be resolved at five dollars or ten dollars and one person preferentially wants to have it resolved at ten dollars you're going to want to enforce that contract on the blockchain as soon as possible because you make a lot more money so that certainly there's a lot of information costs associated to that due to the uncertainty but these are also explicit costs right you will outright pay the minor or validate or set a higher amount purely because you're going make more money so the solution is to only allow one participant to enforce a state a set of states you know within some larger set of the contract and this an alternate there may be alternate solutions but this is the you know this is a good rule of thumb for now you could do other constructions using different types of like cascading bonding structures but that could end up being fairly complex additionally penalties need to be predefined you could have some type of you know adjudicator third party you know end participants but usually if it's a two-party contract you need to pre defined everything using fidelity bonds and what you're functionally doing is you're creating the incentives for the participants to be staying off chain right if you have the incentive structure aligned correctly then you know 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 math spam risks etc etc you know like there 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 and it's a fairly interesting thing just resolved and the most clean way to resolve a lot of this is to be using relative timestamps when you're using a relative timestamp of 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 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 costs the blockchain costs are commiserate additionally it's really important to keep it simple you know like a contract can be easily split into many smaller contracts and when you do that that allows for a great deal of isolation module is sorry okay um modularity in this case is more of like a UT Excel model and that's fairly that's the aut X model is interesting in so far as you have predefined inputs have some set of predefined outputs and that get in you have a net potential like network of contracts that can sort of like 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 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 you know this is about risks and solutions and I think when you look at these types of constructions right what you have are you have multiple participants that want to be able to transact with anyone else in the network right so I have let's say I'm Alice I want 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 hdl-c referring to you have some contract term and some expert 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 commute any communication on chain with Dave so I have 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 etc etc if at any time either party can prove the attestations on chain so you know like let's say if Bob and Carols disconnected they can go talk to the blockchain but Alice and Dave still remain on/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 the sort of like a free option problem right last night we're 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 Daleks talk even if you resolve certain aspects of sharding and efficiencies related to that what a lot of the channel technology gives you is the ability to a demise 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 contracts I can make can design a contract for 10 sets and the free age the the free option problem starts becoming negligible to the point where it doesn't even matter and you can do that you know ten thousand 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 nor contract on chain you should be attesting to the result and earlier in the day there was a talk about true bits so let's talk about doing a true bit type construction on channels and especially in network of channels instead instead in this case when you are testing on Chane both participants end up funding with Carol doing like a 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 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 let's say the contract is a hundred hundred dollar equivalent and she puts up another hundred dollar equivalent and says I am saying that I get a hundred dollars I'm also bonding a hundred dollars 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 Shane 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 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 you know like their 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 on blockchain construction with Dave so Alice has the contract flow through Bob and then to Carol 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 is asked Bob enforces this and said tells the blockchain hey Carol is lying you should compute this and Bob can similarly put up a separate bond to discourage Bob from you know 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 above 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 this type of construction allows for you to do this in a network of channels additionally if you know like a concern would be well if I'm Carol I don't have enough money I want to 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 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 if the bond 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 were reducing and eliminating the need to do full-on chain computation and I can have a channel with n participants and be able to can't do complex contracts with anyone on the net ork likes