Building a Trustless Cross-Chain Bridge - Beau Shinkle

hey everybody my name is bo schenkel and i'm a protocol designer for the keep network working on tbtc which is a trustless bitcoin bridge to ethereum the original plan was to give this talk live but unfortunately due to inclement weather that became pretty impractical so instead i'm going to go i'm going to be meandering through some game theory some math some philosophy and some lived experiences we're seeing a really cool community do some really honest things in a way that surprised us in a way that let us change the designs from our version one of the system to improve our version two of the system in a cool way earlier i mentioned that our bridge was trustless and i think that is a key differentiator and a really big idea so a lot of bridges end up being custodial what i mean by that is that in order to interact with the bridge you have to trust who you're interacting with so ideally you send them like your bitcoin you trust that they will issue you your token on ethereum and then when you send them your token back sometime in the future you trust that they'll send you your bitcoin uh the difference between a trustless bridge is that all of these sorts of transactions are ideally decentralized and crypto economically secured and a large part of this talk is going to be in exploring this concept of what crypto economic security is and how we can like play with that concept and sometimes relax it and the implications of doing so so what is cryptoeconomic security and what does it imply the idea is or behind cryptoeconomic security we want to make sure that all of the actors all the people who are interacting with the system are incentivized by the protocol itself to be behaving honestly in accordance with the protocol so for instance in version one of our protocol anytime anyone wants to deposit bitcoin in order to bridge it on over to ethereum three randomly selected operators that are using our system have to collateralize that deposit using their own like eth and so they over collateralize the bitcoin so for example if i want to deposit 10 bitcoin three keep operators are selected they have to come up with 10 bitcoin or 15 bitcoin worth of eth to collateralize the deposit with and so if they ever collude to steal the underlying bitcoin then they'd be losing more money worth of eth than they're stealing and so they are incentivized to be honest unfortunately what this does is create a huge capital constraint and therefore a supply cap on the total amount of bitcoin that can be bridged and that supply cap is based on how much capital the operators can come up with to secure the system so for example if we wanted to secure a billion dollars worth of bitcoin on the bridge we'd have to come up with more than a billion dollars worth of eth as collateral on the other side and that turned out to be far too much of an ask for all these operators and doing it any other way would mean that we were no longer crypto economically secure because once you give up that collateral constraint then now the operators could they are incentivized to collude and steal the underlying bitcoin um so having this crypto economic security leads to a supply constraint on the system and what we saw as tbtc was launched and became like a moderately successful product was that we were constantly supply capped by how much our operators were willing to put into the system in terms of eth so we always had demands for how much bitcoin people wanted to bridge but never had supply for eth as capital and that was a shame i think was one of the big failings of tbtc version one uh but what we also saw in the community was something that was really cool so there was this phenomenon where occasionally when people would create these deposits they would send the wrong amount to the underlying bitcoin addresses we would call that a miss fund and so for example um you might say i want to make a one bitcoin deposit and so the operators would have to collateralize that with one and a half bitcoin worth of eth and then the person making the deposit might accidentally send 10 bitcoin instead of one and on a smart contract level there's nothing to enforce that from not happening bitcoin doesn't stop you from sending the wrong amount and an ethereum side nothing stops the operators from like rejecting that deposit and so you end up with no crypto economic security in that case and it's purely the depositor's fault they sent the wrong amount and so you have this severely undercollateralized deposit so in terms of purely selfish operators why wouldn't they just take the 10 bitcoin because all they've put in up is one and a half bitcoin themselves and so modeling it from a purely selfish purely like game theoretic perspective you end up expecting that everyone would just take the money in those circumstances but after watching people use the system for years that just like wasn't happening and i thought that was beautiful instead what we saw was that the operators were going out of their way to try to return the money and the system wasn't built to even allow that and so people were trying to like find loopholes in order to refund those deposits because they didn't want to be in charge of collateralizing that much bitcoin like they were trying to make it right rather than just walking with lots of money and i thought that was beautiful so we had modeled this system as fully antagonistic we had modeled this system as expecting all of these operators to be these like selfish like crypto economically rational operators and that just wasn't the case uh and that got us thinking what if we can release this capital constraint by making what's called an honesty assumption and so the idea here is that we have these like three of three signing groups and in order to steal the underlying bitcoin you have to have all three of the underlying operators collude to steal the bitcoin and so if just one of them is honest and refuses to steal it then none of them can and so if you say i think 10 of my operator base just won't take the money then now you're able to calculate the probability that any particular wallet is immune to this sort of a problem and we call that general concept an honesty assumption and so you can sort of play around with those numbers and figure out like how how honest do we think our community is and given that parameter of honesty and given how big we want our wallets to be like whether or not it takes three or three or 10 out of 10 or 51 out of 100 or like whatever you decide what's the probability that the dishonest operators are able to take the underlying funds once you do that then you now have the ability to say what's the probability of a dishonest operator and if it is sufficiently low then you are able to rather than have each wallet be individually collateralized uh instead basically sell insurance via a look at what we call a coverage pool which is a pool that people can put money in and then they collect rewards when the wallets are honest in general and then they might pay out when the wallets are dishonest and steal the funds and this concept let us massively release the capital constraint uh and so at this point people might be wondering like whoa whoa whoa bo doesn't that mean that the the walls themselves are no longer crypto economically secure and doesn't that mean that these wallets are custodial and the answer is sort of um there is less cryptoeconomic security and i like to think of this as a gradient so rather than this binary idea of this this is either fully crypto economically secure or not crypto economically secure at all you instead can model your population as having like a gradient of honesty and so some people are like fully bribable or fully like just completely selfish and then some people are easily profitable or difficult to bribe and then some people will never install like a modified client in order to take the funds and so you can begin to like model your population and figure out where in the gradient you think your community is and make assumptions from there and that gets you an idea of how secure your protocol is as a protocol designer i find that using this honesty assumption actually tows a really thin line between using our operators honesty and exploiting that honesty and what i mean by this is that using their honesty allows us to release their this capital constraint that i described earlier and it allows us to reward operators for their honesty but one of the things that can become problematic is that if i dangle more and more like potential reward for being dishonest in front of the operators and so for example if the protocol grew very very large and so there was more and more reward for just like stealing the underlying bitcoin but the operators felt compelled to to be honest anyway and they would i would be essentially putting them as a protocol designer in this perpetual moral dilemma and i definitely don't want to do that so that's one of like the things that as protocol designers we have to be aware of i think that's one of the really cool problems is balancing this concept so what we have to do is again balance the information that our communities are honest and want to do generally the right thing and aren't just rational economic maximizers with not exploiting their honesty like for protocol maximum efficiency and i think that's like a fascinating sub problem in itself for for v2 in particular i find that like once we've seen enough growth then the wallets themselves will become more and like larger and larger which incentivizes the operators to become more and more dishonest fortunately we have upgradability which is one of the greatest tools for for the protocol designer and so we are able to upgrade our contracts subject to governance approval and tweak the system parameters to further add security or further add rewards for honesty and that brings us back down into um like giving the operators more of a carrot or providing more of a stick like which there's the punishment in case of dishonesty and that brings us back into sort of like an equilibrium which is where we want to be uh and so we have this like constant design idea where at the beginning of a system like in its in its early days we want to make sure that it's capable of of growing and becoming large but as we start to see this growth we want to make sure that it doesn't go out of control and that it doesn't become something that is causing our operators to like have these moral dilemmas or are considering like spinning up discord groups where they are sharing you know like dishonest clients or whatever it is like i don't want to create that situation and i think that these sorts of problems are absolutely fascinating i hope that everyone else does too um that is my talk and i hope that you guys enjoyed it as much as i did and i hope you guys enjoyed the rest of the panels thank you so much