DappCon 2023: Anchoring things in reality: The subjectivocratic Layer 2 - Edmund Edgar

Transcript

okay thanks so um I'm uh Ed I made um reality Keys which was the first smart contract Oracle back in about 2013 um now I maintain reality. e which is a crowdsourced smart contract orle system um mainly an escalation game I'll show you later how that works um but I want to talk today about um well mainly about kind of the new thing we're building but to to explain the new thing we're building is going to take a lot of background um so I want to start with some sort of really fundamental stuff about how we secure anything in blockchains um when I say when we secure stuff what I mean is um with a blockchain or with a system on a on a blockchain um there are a bunch of rules

that the user expects to be followed um and generally the system is secure if it's actually going to apply those rules and it's insecure if some adversary can make it apply some other rules okay um so let's start with base layers your your Bitcoins your ethereum stuff like that how do how do we do that what are the mechanisms we have um there is some voting so in ethereum we have a little bit of voting just for like blockch um capacity governance the block gas limit um there's generally not very much voting in Bas layers and there's a good reason for that um it has a lot of problems um voting is Su um susceptible to bribery um in theory you can bribe people very cheaply in any kind of voting system um it's succeptible to capture um if you you know you can uh

exploit minorities quite easily um you have alignment problems in in voting um what's much more robust and it's used much more in base layers is what we can Loosely call shelling games right so famously with Bitcoin everybody is spending some money to mine a block um and then they want to put that block on the longest chain of of blocks that they see um and if i m a block and spend my money and then I put that on a shorter chain then the next guy since he's trying to put put it on the longer chain um is going to reject my block um so I'm going to be kind kind of punished for doing that um so everybody's getting rewarded for doing what everybody else is doing and getting punished for um doing what they're not doing um so that

tends to be a much more robust system than voting um but it has some problems famously the 51% attack that if you can control um 51% of the of the participants um then you can start to apply your own rules so so the famous one we've been worrying about with ethereum is um what happens if somebody starts to um sensor blocks that have ofac transactions in them um ofac sanctions transactions in them um and you know that that could happen you if you've got you know 51% of stakers a part of some organization and it's a regulated organization that could happen um and then you you know you have much uh much kind of cruder um you know 1% tax on blockchain systems um but there's

another layer of security that we have and some some of that the kind of Bitcoin tribes like to pretend this isn't real but it's not and this is what vitalic calls subje ocracy um so if we think about this case where the where the the majority of stakers might have colluded to um to censor the blockchain to do like reorgs to reorg out blocks um that shouldn't have been reared out according to the users what we could do in that case is what what we call social slashing right so um we'll make a new rule um we'll make a new chain that um deletes the stake of those 51 of those 51% of attackers um and then we can carry on with an honest chain that actually fulfills our rules um now that's also

How We Do governance in ethereum right so somebody um makes a new version of the software and if you want to run it you can run it and if you don't want to run it you don't have to run it uh generally everybody runs it um but you can have contentious cases is or you could have wholesale rejection um now this would be chaos if we did it all all the time right the whole the point of the blockchain is it's supposed to kind of automate and you know make it um make it possible usually just to leave the system running and have it you know tell tell you the right answer um without you paying attention to which Fork you should be looking at but we can do it occasionally and we do do it occasionally and it works and it's extremely robust um because there's

there's kind of no amount of stake that you can hold no amount of power that you can wield that would allow you to subvert this that right it's just the subjective choice of users that what we think is the um the chain that's following the correct rules that's the chain chain that we're going to follow okay so that was the base layers but most of us are um dapon we're mostly building applications uh we're mostly mostly building stuff on top of the the base layers and that looks a bit different um there's a lot of voting in things like Dows um in things like um you know our project governance systems there's loads and loads of token voting um there are a few system using shelling games so one is um claros which is this

kind of decentralized Justice project um they have a nice kind of kind of blinded voting system to to to create a shelling game um and there's very little subject ocracy and I I'll tell you in a minute um kind of why it's hard to do subject ocracy um on the application layer um and this puts us in a little bit of a pickle that we can't use subject Devy for our application um because it's really hard to do a lot of things um in particular it's really hard to make a secure Oracle system without resort to subject ocracy just using um token voting or shelling games and stuff like that um and this also applies to things like you know governance systems um really all all kinds of things end up with this

Economic Security bound so generally speaking if you have a well-designed system you're mostly okay if the value of your token is some multiplier of the amount that you've got to steal okay um so if I can buy up half the tokens and by doing that I can steal more than it cost me to buy up those tokens um then I could subvert the system um if the amount that's being secured is very low and the value of the token is very high then I can't do that profitably so we generally consider um that the system is secure um and this is a little bit terrifying to me in that at the moment it generally doesn't look too bad because at the

moment we're in this kind of early phase where most of the projects have token value based on the expectation of all the growth that they're going to have in the future right so so if you think about like an early stage company generally the um the value of the company is quite high in um in comparison with its revenue and it's the same with with protocols that the value of the token will tend to be very high if we're taking into account all of our future Revenue that we we're going to we're going to have as the system grows but at some point we're actually going to be be holding that Revenue so we're going to have these token values that are much more in line with the amount of Revenue that they're actually creating um so even things that right now seem

like they're they're working securely could well end up spectacularly breaking um and and I feel like this is exactly the kind of system that we don't want to be making right um if stuff's going to break we want it to break soon um we don't want to wait until everybody's using our systems um and then it turns out that uh once we have a certain amount of value stored in them people start successfully attacking them um and and I feel like it's a bit kind of ridiculous that we've got ourselves into this situation we get kind of numb to this idea that um kind of the Oracle problem is unsolvable and you know project governance is just you know kind of impossible to to do well um because you you know the blockchain

isn't real right the blockchain is something we made up it's our model of reality it's not reality um so it's kind of ridiculous that we're in the situation where at the base layer we have resort to subject bureaucracy at the base layer for ethereum or Bitcoin any base chain um we can correct a mistake and we actually have a lot of robust security but for the stuff that we're building on top just because of the way we've layered things we don't have that kind of security um so this has been bother me bothering me a lot in you know sort of 10 years working on oracles and we you know it doesn't have to be this way this is a design decision um so now earlier I said that it's really hard to use

subject biocracy at the at the level of um of applications at level of contracts um and and there is a little bit of subject oy used um one example would be for example enss the original version of ens was immutable and upgradable um and and then when somebody came out with version two they just made a new contract and said hey everybody use version two now for ens um it will fetch some data from the old version but um you know but we're just using the version two um and you could do that in theory if if your Oracle system broke or something um if you know if if chain link got subverted or if claros was was broken um but the the problem here is that um it breaks composability so

you've got a bunch of contracts that are all talking to each other um you as a as a subjective human may know that this Oracle is bad and this one is good thiss contract is bad and this one is good um but other contracts don't know that um so you know with with an oracle if you if you've got a contract that's looking up a price of something against some contract um and you've changed the contract it doesn't know that it needs to look in the new place um so if we're going to use subject decy at the level of applications we need instead of just doing it at the level of individual contracts we need if we Fork something we need to be able to Fork an entire ecosystem of stuff all at the same time right so we want to be able to Fork the

contract but also the contract that's calling that contract and the contract that's calling the contract that's calling that contract um so okay we we got to move everything um we've got to take this entire ecosystem we' built and put it on a new chain that we can Fork that may sound like a mad capap insane idea but this is basically the um minus the forking part this is basically the ethereum scaling road map right we we we start out with um one layer with a bunch of contracts on it um what we're going to do in the new ethereum it's going to be too expensive to uh to use layer one in the new ethereum we're going to have some rollups um the rollups will be on layer one each of those rollups is going to hold a a state route and then the contracts are going going to live on a

layer two um so if we want to be able to Fork stuff if we want to have subjective CTIC security we can do something similar um we're going to make a roll up initially it looks the same but if you pay it a very large amount of money you can cause it to fork and when you Fork that thing it's going to duplicate the entire universe of stuff right every single contract is going to have its own evil twin contract and people are going to use whichever chain they want um so if one of the chains is the result of a very obvious attack then nobody's going to pay attention to the to the second chain every everybody's going on the on the first chain um so let me take you through just kind of a concrete example of how that would work the so so so the ne the next

problem is um if we're doing this for every single contract we don't want to be forking this entire ecosystem all the time um so in between what we want to do is to put an escalation game um we want to only um do the forking kind of as a back stop as a very as an extreme thing um but for regular cases we don't want to have to do it um and this is where reality eth comes in this is so so this first slide here um is how reality generally works right now uh just also on layer one um let's imagine you've got like uh a contract that needs to know some information so I don't know let's say I've got a pet insurance contract um it's supposed to be insure insuring me against my goat getting sick so that I can pay the vet bills right um the way

reality e works is any anybody can put in a question anybody can answer the question when they answer the question they have to put up a bond um generally they'll answer the question question correctly so that's the final answer nobody will bother challenging it um the thing uh you have like a timeout period that the elapses and that's your answer the goat got sick um in some cases the there may be a challenge somebody may say no that didn't happen the goat didn't get sick um then they can come and change the answer but they have to double the bond um and this can carry on as long as you like doubling and doubling and doubling um we don't want to be in a situation where just the person with most money gets to decize everything um so the the final stage we

have is that if you pay enough money um to what what we call an arbitrator contract this is kind of a there's a bunch of different kinds of of contract you can use for this um then it gets uh then the arbitrator has the final opinion and that decides so so the most common arbitrator people are using now is is claros for this um this sort of uh decentralized justice project um but then the problem is okay so what happens if um I'm missing a slide here sorry um what happens if um if claros for example got hacked um in that situation we can do this whole thing again except this time instead of escalating over whether the goat got sick we escalate over whether Clos got hacked um so we'll do

the same escalation and then when we get to the final point the arbitration for this is going to be that we Fork the entire chain um and everybody uses the version they want on one of the versions We we assume that claros is broken and on the other one we assume that claros is good um so everybody is using this thing because they want good information so if claros is broken they're not going to want to pay attention to the one that says it's good and and vice versa okay um now I just say a little bit about bridging assets um since it's a layer two um we have trustless communication from the layer one to the layer two and vice versa um but if you've put some ether or something if you tried to bridge some

assets over to layer two then we've now got a problem because the the contract on layer one those ether can't be fored right the contract on layer one needs to decide which of the two rollups it's going to um which of the two ledges it's going to follow um so so one solution is don't do that don't Bridge assets use native assets um but there are a bunch of ways that you can choose uh um which bridge to follow you can do it like an out chain where everybody uses token vating and multi sigs and stuff um we can follow the most valuable assets on the fork uh the sorry the fork with the most valuable assets so um um so one thing we do here to help this process is we have like an auction process um before the fork happens so that everybody can see how much um money is

um how much people think the tokens on each of these Forks are worth um so we can do that or and you can also just not yeah not do the bridging and instead just put synthetic assets on the on the layer to um okay so what does that give us well compared to voting so if we were just doing you know a voting system you have basically no security um shelling game systems tend to give you the security of like um half the market cap or that something thereabouts um with subject bureaucracy um with this ability to Fork um assuming that we think that users are capable of choosing the right Fork when an attack happens you have basically um in infinite security uh you have no Economic Security bound um for

Native assets um for assets that you bridged we have this security bound back again but only for things that are related to the issue at dispute right so if you've just bridged some ether over and they're sitting in your wallet then it doesn't matter which Fork the bridge chooses uh you still have your ether okay so um so that's what we're um we we're building um there'll be a related talk tomorrow by Alex Herman who's working on this um he's going to be talking about stable coin designs and how you can make a better a stable coin design um that will better handle what happens if the chain that you're sitting on Forks um which could also happen to ethereum but um is is certainly

something that you know we want to make work well um and then there's a QR code there if you're interested that will give you a bunch more um a bunch more details um also so Sil on the team is here if you want to out to her um Alex should be here tomorrow um and and I'll be around uh next couple of days okay thanks any questions okay so then thank you very much Edmund for your talk