Strong Cryptoeconomic Security for Arbitrary Validation Tasks

[00:00:10]uh good afternoon everybody thank you so much Ari for the kind introduction um I'm going to talk today about uh uh cryptoeconomic security for orbitary tasks I'll start with motivating this talk with some of the work we are doing at igen layer so you if you think about the evolution of blockchain uh our thesis on blockchain is it's a mechanism to create more permissionless Innovation or open Innovation and if you look at the various uh uh various layers of a blockchain you see basically uh there is a security layer at the base and then there is it could be staking or mining on top of which there's a consensus layer nodes come together and you know arrive at consensus on top which there is an execution layer like an execution environment like Bitcoin script or evm or whatever then applications then build on top Bitcoin was an application specific blockchain designed for storing sending Bitcoins so you had all these four layers and they were all tightly coupled and integrated and ethereum was the first modular blockchain modular in the sense that anybody can build new applications on top of a common substrate of security consensus and execution so this led to a whole growth of daps anybody building coming and building new kinds of smart contracts on top of a common trust platform and then you go to the next framework I think you you look at uh rollups rollups basically anybody can come and build new execution environments on top of a common consensus layer you know uh each rollup runs its own offchain execution and makes proofs that it did the execution correctly and so now you can have Innovation at the level of execution environments you can build many execution environments on top of a common consensus and security layer and what we did with I lay you know we are you know I keep I used to run the University of Washington blockchain research lab where we worked a lot on consensus protocols I also have a a bunch of papers with Ari on you know far ordering and consensus protocols let's say you want to go build or deploy any one of them uh you don't have root access to go change it on ethereum so this is really why we built igen lay we built igen layer to modularize security it just does Security on top of which anybody can build new consensus layers on top of which other people can build execution layers application and so on so it is the deepest level of open Innovation so now you can basically build anything so just imagine an abstraction it it just covers decentralized trust or security Now anybody can come and build new kinds of networks protocols which require you to reprogram how the n network works okay so we call these consensus layers built on top of I layer so I layer is the name of the protocol that we built and it's a system for shat security a common security layer for any decentralized network to be built on top these networks we call them AVS actively validated Services actively validated means somebody's actually running notes to keep these things going Services rather than chains because we think of servers as the right unit of operation you know you may be sitting on ethereum and you want to make a call to a AI engine and you get a return which is the uh executed output of this AI inference that's a service it's not necessarily a chain okay so that's the setup now you ask how do we provide crypto how do you provide security and in this talk I'm not going to talk much about the sharing part which is how do you extend security to multiple different systems but I'm going to focus on what is the right framework for providing security so you know the the core idea in igir is cryptoeconomic security what is cryptoeconomic security you have a bunch of nodes which come at stake they all come at some stake stake is just a take a bunch of digital assets eat or something else and then lock them up into a contract and once you lock them up into a contract now you you promise to run various Services various avss okay so that's what's happening and the main question is when you have anybody when you have permissionless validation anybody can come and run validators how can you make sure that these validators are doing the right thing and the core idea of cryptoeconomic security is if nodes fail to perform the task in the way they promise to do it then they'll lose their stake so that's the check and balance for how cryptoeconomic security works okay so you know what you know once you look at this you can ask the question do we need cryptoeconomic security are there other ways of doing security and should we use the best possible one and so to do this we came up with a taxonomy of what kind of properties you want from systems and how we can use different mechanisms to achieve these security properties so you know a group of ndes come in and they're running some task and what you want to do you know I said in crypto econom security if they did the thing wrongly so which means they committed a fault they should be punished so what kinds of Falls are we talking about the first category of Falls is objective Falls objective Falls means you are violating some objective condition I think of it like a mathematical or a cryptographic or like a deterministic code execution so the the first category sub type of objective Falls is we call it proactively attributable what does proactively attributable mean I run a p piece of code and then I I can attach a proof that I've actually run this piece of code correctly so as soon as I give you an output I can give you a certificate that I've done that output correctly and when you're running an execution so you can use something like zero knowledge proofs which is basically you know what we call in our space but really uh verifiable Computing which is you can create short proofs of correct execution um you can use either zero knowledge proes or or you can use uh cryptoeconomic security C stands for cryptoeconomic security uh for this but you know ZK is probably better and a lot of people think maybe ZK is all you need you don't need anything else all you need is cryptographic integrity to do all these tasks I'm going to argue it's absolutely not the case so the next category of Falls is what we call retroactively attributable they're still objective but only retroactively attributable what do I mean by that imagine I sign to the protocol says you should you know validators should sign off on only one block for block number 30 but a validator goes around and signs two certificates for block number 30 this is a violation of a core Covenant of the protocol but I cannot give you a certificate that I have never signed another block with block number 30 because this is not a pro error of commission this is an error of omission I've given this other certificate to a another counterparty and trying to fool everybody so but retroactively after I did this somebody can you know get both the certificates and prove objectively by showing me two certificates that sham signed on block number 30 is hch but block number 30 is G they're not the same so he should get slashed so it's objectively attributable but only retroactively you cannot do ZK for this there is no cryptographic proof of Integrity for this except in Quantum Computing you can use the no cloning theorem to do this but we'll skip that for here um so this is we call them reorgs or double signing or whatever and these Falls you need you need cryptoeconomic security I have a bunch of stake I promise that I will not do this error of permission like that I will not sign two blocks at the same block number and if I do you can catch me and slash my Stak okay so first first argument for why ZK is not the end game ZK is not the end game for building blockchains we need much more more interesting more important fundamental perimeters or equally important fundamental perimeters to actually make these systems work okay what else do we have we have a category of Falls we call inter subjective Falls okay fancy name what is it mean inter subjective subjective means like I have my own opinion inter subjective means we can can all socially agree another way of thinking about it is these are Falls for which there is offchain agreement but not necessarily onchain agreement okay so I'll give you an example of a fault you say who is the president of the United States who won the silver medal in swimming in the Olympics examples of questions for which we have offchain social inter subjective agreement but onchain I don't know there's no Locust to bring the right sense of Truth on chain so these we call them inter subjective fals so when you think about inter subjective Falls uh we still categorize them into two types retroactive and an example of this is you know an oracle price feed let's say I come in and say one BTC is equal to one USD one Bitcoin is $1 Us doll it's absolutely not true we all know but on chain somebody said it now what are you going to do how do you know it's wrong we don't know onchain it's wrong but we know offchain from the outside frame of reference that it's wrong so this is an example of inter subjective fault and it's retroactively attributable depending on the scale of the error it's retroactively attributable I can come back in 3 weeks and if I said one BTC is one USD today you would still know that I said the wrong thing three weeks back so inter subjective retroactive okay so the next category of Falls we call inter subjective concurrent concurrently attributable concurrent basically means you had to be there at that time to know that it was a fault one fault that we think about a lot is data publishing or data availability I have a network of nodes which storing which are storing the data and they're promising that we will allow anybody to download the data if they ask for it it's called Data availability is a AVS that we are building called Igan da okay so in IG da these nodes promis that they're going to serve the data to any body who asks for it but how do you know that they all didn't collude and never serve any honest node ever even if they served one honest node that node has the data they can go and stand up a website and let anybody else distribute the data but what if they never served even one honest note this fault is not observable on chain but it's observable offchain anybody who's quering the rpcs anybody who is running a full node anybody who's connecting to the peer-to-peer Network all have a Locus to know whether data was published or not this is an inter subjective fault offchain observable but concurrent I need to be there at that time to know I can't come back one week later and know whether the data was published this week or not because I may have witheld the data this week and publish it two weeks later after whatever fraud prooof window or other important time Horizon lapses so it's a concurrently attributable inter subjective fault so this is the Topography of the various kinds of FS there are also non-attributable fults they're neither onchain attributable nor offchain attributable with high social concordance an example would be you take a data item and then spread it into secret shares like Shamir secret sharing many of us would have read so you take the data and then split it into secret shares and send it to a network now if a majority of the nodes met to gather in a private boardroom and reveal the data to somebody there's no way for us as a society as outside observers to get Social concordance on whether that happened or not so this is not even inter subjectively attributable so these are the various Topography of faults that we came up with and the question became how do we uh create cryptoeconomic penalties for inter subjective faults to go into this I want to um specify a meta framework for coordination whenever you're thinking about who is enforcing this conditions of coordination so think of this like the fact that you don't want certain kinds of faults think of this as basically like a condition of coordination I'm a validator I've opted in I've promised that I will not make these false now who is enforcing this type of coordination you think of like broadly at like a macro scale four types of coordination you can have an authority that enforces a condition of coordination you can have a committee that enforces the condition of coordination you can have a majority of some group of nodes that enforce a condition of coordination and then and each of them are more robust than the previous one and then finally I think you have the gold standard of coordination I call Self enforcing coordination mechanisms a self- enforcing coordination mechanism is executes itself irrespective of what anybody says neither an authority nor a committee nor a majority can come and corrupt the condition of coordination so that's what we call self- enforcing coordination so so I'll illustrate this with an example in blockchains you know a lot of the theory that we do as academics in blockchains usually stop with majoritarian coordination we assume a majority of nodes are honest what properties can you brew about a consensus protocol and so on but the really powerful thing in blockchains is you can go even beyond that to self- enforcing coordination systems imagine like you're running a blockchain protocol and a majority of validators are malicious and they sign an inval valid block they sign a block the state transition function is not computed correctly they sign off on a block okay so this is a majority malicious behavior and you know in in a protocol like ethereum or Bitcoin the condition is that if the block is invalid it doesn't matter even if a majority signs off on it you don't accept it you don't accept a block which is invalid which means you Fork around it so you Fork around it means somebody else will include the CER certificate claiming that a majority were malicious and then they can continue only the remaining nodes are now eligible to participate in consensus they come to consensus and then they can actually proceed forward based on this uh system so this is a self enforcing coordination for validation for uh execution validity in a blockchain you don't need to trust a majority if a majority does the wrong thing signs off on an invalid Block they'll get slashed they'll get removed from consensus later very very powerful system so blockchains are not correct based on a majority of the nodes they are self enforcing okay so this I'm specifically talking about for um execution validity so we have to take each fault that a blockchain can perform and make sure we can uh recover from that even when there is a majority fault okay I'll skip ahead and start the U question okay so this is true for execution validity right go back here if the execution was wrong then yes you will Fork around it but what if inside this ethereum block there was an oracle price feed or an Igan da feed or some other AVS brought in a wrong data we can't Fork ethereum ethereum has no we don't have any license to fork ethereum for things that happen on the application layer or on the IG layer or any AVS layer okay so what do we do this became the B big open question for us in resolving how do we solve Falls which are socially inter subjectively offchain attributable but we want to enforce this not based on not based on an authority not based on a committee not based on a majority because they all suffer from the tyranny of majority you know a majority of the committee could lie a majority of like stakers could lie so we don't want to trust any of them we want to enforce it only to truth not to power okay how do you do this so you know the methods people have are majority voting like you have a majority of stakers vote on something you can have a committee vote on something but you know you have to ask the question what types of coordination mechanisms are we building how do we make them very robust and both of these are vulnerable to the tney of majority so the only system that's really robust to the teral majority that we know about is forking okay but as I said the problem is so what's happening in forking is if there were two forks of Bitcoin or ethereum people figure out what is the Right Fork because they know what the what the execution conditions are it is self-evident what the Right Fork is and say so people automatically gravitate towards the Right Fork okay so you can think of forking as like a social consens Sensers on an unsized and unbounded group like you don't know who these people are anybody who's coming behind you is going to decide what the right forus so this is the only system that is robust to the tyranny of majority so we call these self- enforcing so the question is how do we extend cryptoeconomics to any inter subjective fault without forking the chain because I is built on ethereum we have no license to Fork ethereum what are we going to do okay so that's the main main problem so I'm going to illustrate a couple of key ideas and then put together the solution for you the first idea is when we're talking about forking a lot of people have this idea of social consensus as ad hoc post facto capricious we meet on Twitter and then say Oh that guy is bad I'm going to Fork him that's not a good system it's a kangaroo court you want to have a system where it's preset there is a setup phase which presets what the conditions of folking are and then an execution phase where you just follow the pre pre-agreed conditions you Fork on pre-agreed events that are self-evident towards pre-agreed self-evident so you only for on pre-agreed events that are self-evident okay uh one thing that gives us a good match here is when we're talking about self-evident inter subjective Falls are self-evident because they're offchain observable so that that's a good match of what framework we're trying talking about and this core idea the second core idea is as I said we're building on ethereum we have no right to Fork ethereum what are we going to do we create a new idea we call token forking okay so here is a meta point I said The Faults Are inter subjective which means socially off chain it's observable whether it's a fault or not there's another thing which is inter subjective which is the value of a token is inter subjective we all look at a system and say suppose I take Bitcoin and Fork it and create another chain are you going to say that that's worth $1 trillion no you'll say the original one is worth $1 trillion this new one is worth is BS that's what you're going to say value is inter subjective truth so social truth is inter subjective you merge these Concepts so that's the basic idea okay how do we do this um the core idea is instead of forking the chain which we have no license to do Fork the token what do you mean by Fork the token so you know you're chugging along you've St the igen token on igen layer and the systems chugging along and then a majority of Ian stakers turn malicious and report that 1 BTC is equal to 1 USD okay now they've created an error event now what do we do we need to punish them they need to lose their iGun that's the right punishment for them how do we do this anybody can create a new Fork of ion the token they create a new Fork of the IG token and now in this new Fork they say oh we're doing this because of that pre-agreed condition that I stakers shall not give a wrong Oracle report so now those stakers who give the wrong Oracle report one BDC equal to 1 USD then their stake is removed from the second igen token the new igen token is created so now looking outside from the looking from inside ethereum ethereum doesn't know whether ion one is correct or Ion 2 is correct both look the same to ethereum it's just another erc20 token but looking from the outside we know the pre-agreement on what is the I token is the one that says the truth okay so people Converge on igen 2 as the token that is valuable when people are trading it they're going to trade I 2 when people are staking it new Services come in they would want igen 2 to be sted not IG one so this is the core idea the fact of whether IG one is right or I 2 is right is not transparent onchain but it's transparent offchain and we want to bring that Intelligence on chain to to turn around the crypto economics you want to enforce the correct uh punishment and rewards okay on the ion users point to the right one so this is the core idea I'm going to there is um there's more to it you know this doesn't overload ethereum's social consensus because ethereum doesn't need to know what is going on only anybody who's interested in the igen token is needs to do this this this is not our the idea that tokens Can Be foged is not our or orig idea you know vitalic wrote about this back in 2014 there was a paper even earlier called Truth coin and you know a bunch of blog posts here the main system that worked off this idea is called augur which you know used this idea of token forking but it had a bunch of shortcomings I'm not going to get into it but I'll explain what how we saw those shortcomings so the first property that we have for igen is it's Universal Universal what do I mean by Universal it is not an application specific forking token augur was an application specific folking token built for prediction markets Ian is a universal folking token so what that means is you can start building new tasks on top of the igen token and create folking conditions for all of them and if the IG stakers opted into those conditions they'll be bound by it okay so universality is one me major Concept in the igen token the second one which actually makes this insanely hard is what we call a property called isolation isolation is if a token is forking willy-nilly that same token is listed on exchanges the same token is being lent and borrowed there's Financial applications on all these tokens it induces a downstream Cascade of you know events that you don't want so the way we solve it we create two kinds of igen token one called a solid representation a solid representation is one which is honored one is to one on every igen Fork if you hold a solid representation it's honored one is to one on every I fork but if you hold a not solid representation which is um forking representation then you know you are stuck with that fork but you need a forking representation to STI so what we do is we decouple the utility of the igen token on Fork staking and financial utility with two different tokens and then finally our the third point is metering metering is forking induces social cost you know somebody comes in and says hey there are two two igen tokens you know they can be forked now this is a problem you know because now everybody needs to adjudicate whether ion one is correct or Ion 2 is correct and users a mass massive social cost you don't want that what are we going to do about that we meter the cost of social consensus let's say we know oh this is going to induce x amount of pain on all the users what you do is you say then you Fork the token you have whoever is claiming to Fork the token they have to burn a bunch of the first token the original token and they will be minted the same amount or more in the second token so they are actually measurably giving up opportunity cost if the first token turned out to be right they're burning their uh fingers this is a kind of a blood letting in making sure that they are actually like do not create denial of service but also if they were wrong the value of the other users igen token increases compensating them for their attention Okay so that's metering and then finally we found a major problem in cryptoeconomic security which is cryptoeconomic security models usually Val adversary Centric which means they think about whether an adversary um whether you know they think about like what is the profit that an adversary can make from attacking the system and what is the cost incurred on the adversary it's called cost of corruption and profit from corruption for an adversary but the problem with these things is there are always extrinsic incentives that you can't model somebody may have a shot position somebody may be bribed somebody may have some other thing going on you can't model all of the stuff so we created a new framework we call strong cryptoeconomic security strong cryptoeconomic security is adversary neutral you don't need to think about the adversary you think about yourself as a user the way you do it is if you're transacting certain value on the system you buy insurance directly from the system called compensation and when the uh stakers are slash for their misbehavior you can take that stake and compensate back the people who hold the insurance so if I'm using an Oracle in a D5 protocol and I I have risk worth 1 billion if I hold Insurance worth 1 billion from the protocol then I'm crypto economically secure irrespective of what the adversaries do so this is a brand new concept of crypto Economic Security that we invented called strong cryptoeconomic security the igon token satisfies all these properties solving this fundamental problem of how to do strong cpto Economic Security for arbitrary inter subjective Falls thank you so much [Applause] much okay we have time for maybe one question um just trying to understand from the eum classic Fork perspective like the only proposal here is you would have to burn a bunch of token before you can mint ien 2 tokens or is there something else there is all the four differences that I laid out the first one is it e was ethereum classic the problem was the setup condition of ethereum was Cod is law Cod is Law and then like what we had to do was to negotiate that you know Cod is law except their major bugs so this was a massive social renegotiation very hard second one is ethereum is does not fork for arbitrary events and to fork for arbitrary events you need a mechanism to solicit and monitor the cost of forking and the total amount at risk for all these different events so that that goes to the first point of universality the second one on isolation which is also a very important thing which is how do you make sure that there is a single representation that uh is honored one is to one on all these different Forks there's a whole bunch of details on this I'll I'll let you take a look at that and then finally slashing and redistribution is a New Concept for how you honor people who are actually using the system without letting them make random assumptions on adversaries so those are all the differences thank you so much thanks for your [Applause]