Arbitrum: Off-Chain Contracts with On-Chain Security with Ed Felten

hey everybody um thanks for coming I want to talk about arbitral and the tag line here is off chain contracts with on chain security let me start by talking about what we mean when we say that when we say off chain contracts what we mean is that arbitrament a solidity contract or other EVM contract and move the storage and computation of your contract contract off chain that stuff never goes to chain and by doing that we can make the execution of your contract faster and cheaper we can improve scalability by a substantial factor and we can eliminate the gas limit there's now no limit on how much storage or computation your contract can have beyond the limits of the of the nodes that are that are running at his native code so that's off chain contracts everybody likes to have this stuff but usually you have to make sacrifices in order to get this we also provide at the same time on chain security and what we mean by that is that execution is trustless that if you're a participant in a contract you acting by yourself can ensure that that contract will execute correctly no matter what anybody else does and the security of all of this is anchored by an Unchained contract that runs on aetherium that provides a sort of trust anchor for the whole arbitrament I'm going to talk a little bit more in a bunch more detail about about how we do that and about what it what the implications are for developers but this is the basic value proposition you sort of get the best of both worlds of being off chain and on chain okay so this leads to a technology stack the Arbitron stack which is unusually flexible as layer two systems go and we have three different use cases or modes of use for what is a single underlying technology we call these our Bertram channels orbitrim side chains and arbitral rollup and I'll talk about what these are and how they are related so you can think of them as separate products but we actually tend to think of them just as three different ways of using what is the single technology okay so I want to start by talking about closed world contracts so what I mean by that is you imagine you have a contract that has a fixed set of parties maybe not to largest set a fixed relatively small set of parties who are the only people who will ever care about that contract and its correctness maybe they're playing a game maybe it's some kind of financial contract with the small fixed number of parties I want to talk first about this type of contract and then I'll come back later and talk about open world contracts okay so for closed world contracts one of the standard approaches is state channels and state channels have a bunch of advantages but also some disadvantages that I'll talk about in a minute so state channels are the standard way of doing this you have a fixed set of end participants if those end participants can unanimously agree about what the contract should do then you're good to go anything that they all unanimously agree on the system might as well accept is correct and you only need to go on chain to resort to any kind of an on chain activity if there's some kind of a disagreement or dispute or if one of those parties becomes unavailable this is standard state channel technology that has been out there for a while okay now if there's a dispute the typical thing to do in a state channel system is to say that there's an on chain contract which got in which gets initialized with the most recent state that was unanimously agreed by all of the parties off chain so off chain they you can imagine they evolve the contract up to some point now they can't agree anymore now you tell this on chain contract where you were and the on chain contract is going to be is going to continue going from there either the either the on chain contract will wrap up the execution of this contract and pay out any assets that it held sort of shut down the contract early if you will or the on chain contract needs to be able to run that logical contract to completion on chain right this is all again standard state channel stuff so there's a bunch of limitations of that model it's good when it works but there are four main limitations one is it's fragile if one party goes offline I'm not even talking about malice if a party just becomes unavailable then fast progress halts and you have to move on chain because state channels in the standard configuration can't distinguish between a node being unavailable and being malicious it has to treat those as the same the second limitation is they're computationally limited because you always need to be able to fall back on chain execution you can't put anything into a state channel that you couldn't do on chain if you needed to and that means if you want to do a computation that will use more than the global gas limit or if you want to have a contract that has a lot of storage more storage than you're willing to pay for on chain then you can't run that contract in a state channel because if you have to go to chain you'll be out of luck okay limitation number three of standard state channels is there's no guaranteed privacy although you can have privacy while you're executing off chain because only the participants need to know what the contract is doing if you're going to move on chain the whole state of the contract all of its code all of its data all of its execution from then on has to be public and so although you start out in a private state you can't guarantee privacy any and if anything goes wrong your privacy is blown completely and then finally number four is most state channel systems forced you to develop your your app in or your adapt in a contract in a non-standard programming model you have to code for this state transition paradigm which is not really natural and it's not the way most people either have or want to develop their apps so those are all limitations of standard state channel models so they're great when they work when in the optimistic case if you never have to fall back to on chain but they have some pretty significant limitations so are Bertram channels which is the first mode of using our arbitrary solves all four of those issues first that use we still make progress even when all of the parties are not available in unanimous we can resolve disputes between the parties about what a contract will do without having to move everything in the world on chain we have a special fast dispute resolution protocol so the computation and storage don't have to move on chain and therefore are never subject to the global gas limit we guarantee privacy even in the presence of a dispute so again because we don't need to move everything on chain if there's a dispute you still get privacy and there's no need to it's illicitly defined state transitions you compile your existing solidity contracts to run directly on arbitral so no change in programming model okay so how does it work let me sketch briefly how how this part works and basically one way of thinking about how this works is that in the optimistic case in the case where all of the parties are agreeing and cooperating and available this works just like state channels all of the participants in the contract will get together they will agree on what the contract will do they will jointly sign the statement of what the contract will do when the system will accept it and you're good to go the only thing that ever gets written to chain is a cryptographic hash of the state of your contract along with any actions it takes like payments that it makes so that's the easy case but otherwise if if for some reason a node becomes malicious or participant becomes unavailable instead of falling back to on chain we fall back to our Bertram roll-up mode which is another mode of execution much more efficient than fully on chain which I'm going to talk about later so the the keys that make this work and be efficient and much better than state channels are first of all this arbitral up mode and I'll ask you to wait for a few minutes until I talk about that and second the ability to switch back and forth if somebody becomes unavailable your contract will seamlessly switch into the roll-up mode execute and roll-up mode for a while and then once the unavailability is gone the contract will seamlessly switch back into off chain unanimous mode so it's the ability to switch back and forth between a fully unanimous a fully off chain mode and a mostly off chain roll-up mode and to be able to do that in a way that's seamless and that the programmer developer doesn't need to worry about that is another part of the secret sauce here you never need to move your storage or computation to chain okay let me move on and talk about open world contracts now so instead of having a fixed set of participants who are the only people in the universe who care about the contract now a contract is open anybody can come along and join and participate interact with it anyone in the world might in principle care of what this contract is going to do okay so one of the ways of doing this is one of the ways of handling this it traditionally is using a side chain and there's a bunch of different approaches to this you can use permissionless consensus system like a proof of work or proof of stake based side chain you can have permission consensus based on something like a B ft Byzantine fault tolerant consensus protocol but all of these introduced new significant security risks for example if you're using a PFT based sidechain then have to assume that more than two-thirds of the validators of your sidechain are honest and that's not the sort of level of trust that you would like to have in a blockchain application okay so but if you like you can actually use state channels as a consensus mechanism right in an in a sidechain there's a set of validators who are the validators of the sidechain and those are the people who are jointly responsible for keeping track of and advancing the state of the sidechain you could have those people interact via a state channel if you did that with the traditional state channel that wouldn't be ideal but let's stick with it for a minute the idea is the validators participate in a state channel and they rely on all of the other validators to execute correctly to advance on that state channel now if you use a traditional state channel to do this you're not going to do very well because you will eventually have to fall back to on chain execution and all of the problems that come from that but if you're using an arbitral instead as the coordination means for the validators of a of a channel of a sidechain I'm sorry then you get all of the benefits of arbitral zin particularly you get what we call the NE trust model and what this means is your sidechain has a set of validators and as long as even one of those validators is honest and available we will guarantee that your sidechain will execute correctly that every contract on it will execute correctly you don't need to assume that it's majority honest or 2/3 honest it's anyone honest if have 50 validators and 49 or malicious and one is honest these chain will still execute correctly so that's a very strong guarantee it's the strongest guarantee you could ask for yes so right now when I'm talking about side chains this is permissioned yes so you have a permission set of validators and they're going to they're going to monitor a chain or a contract right and so what this Arbitron channels what this arbitrament echnology lets you do is run a permission sidechain like that with this any trust trust model and to be able to do it efficiently while keeping stuff off chain and basically the way you do this is you take that previous arbitral Cannell's technology I talked about and you have the validators of your side chain just use that it's literally the same code okay so if you if you were to use standard state channels they would not be so great they would break if you went offline disputes with ha stop halt halt fast progress and all that but if you use our Bertram channels as I said this these problems go away and you get and you get this any trust model and never have to go on train I want to talk now about so this is arbitrary size chains right so the arbiter of state channels as a consensus mechanism and you get this any trust guarantee okay so but now what about trust Lass's this sort of relates to to your question right that arbitrament east one validator to be trusted in orders so that means for example that the validators can't all be anonymous as an example because it's hard to trust people who you know if you don't know who they are so some applications require trust lessness and they also require the ability of participants or even validators to remain anonymous logger being an example so for that model we have yet the third model of execution that we call arbiter roll-up so this is like a side chain except it is not permissioned that is anybody can act as a validator and so this means that if you are a participant or even a person who cares about a particular contract you can make sure all by yourself that it will execute correctly so basically right it's like a side chain that anybody can validate and so it's trustless assuming that the people who care actually step up and do validation or if you like if you prefer not to be a validator yourself you can always pay someone to do it for you so execution and storage are off chain and as in other roll-up models the call data that that goes along with calls to a contract is posted as call data on shape so the downsides of this compared to the other models are you give up the privacy guarantee because these contracts are big and open if anybody can validate then anybody needs to be able to see what's in the contract and you give up instant finality which is a property that the other models can give you when they're operating in the anonymous mode but the result is that any contract can get better scaling than you can get with with other models okay so how does this work the key idea in arbitral roll-up is what we call a disputable assertion and so the idea is something like this so imagine that one validator makes a claim so on chain we have recorded the cryptographic hash of the state of a particular contract and this validator claims that starting in the current state that the contract can execute and instructions and the result will be this state hash and that along the way the contract will make some payments and will send certain messages when this is posted on chain it goes into a pending state and a time window is open during which other validators really in this open mode anybody can step up and challenge that and say that it's wrong the person who makes this assertion has to put down a deposit which they risk losing if they're wrong okay if nobody issues a challenge during the challenge period then this assertion will be confirmed and the state of the contract will be advanced and so this will now be the new state hash of the contract and cryptographic hashes of the state are all that it's recorded on on chain if on the other hand there is a is a challenge if now this is this assertion is put on chain and somebody challenges it old say Alice puts it on chain and Bob challenges it he says no that's wrong now there is an on chain dispute resolution protocol which is able to determine whether alice is wrong or Bob is wrong efficiently and this goes in two steps the first step is logically a sort of bisection protocol where Alice is responsible for taking her initial end step assertion and breaking it into two and over two-step assertions which together add up to form the initial one so if Alice was wrong in her big assertion then at least one of these two needs to be wrong and Bob's now on the hook to say which one he thinks is wrong so Bob chooses in this example to to to point to the second one is wrong so notice the on chain component just needed to make sure that these sub assertions where each half is large and that the end state of the first one was the same as the beginning state of the second one and then also that Bob actually issued a challenge in a timely way so that's very cheap to verify on chain now we've cut the size of the dispute in half and you know you can probably guess what happens next they keep doing it Alice bisects again Bob challenges again and so on until you get down to Alice making an assertion about one step of execution which bob has challenged so this one step of execution might be like a single add instruction so very easy and small now Alice the assert has to offer on chain a one step proof that is basically just enough information that allows us the simple on chain contract to verify that's starting in this state hash if you execute one instruction you get to that state hash so this a one step proof is a because of the way we design our system just a few hundred bytes in size and it can be verified on chain with about 90,000 aetherium gasps so very cheap Arbitron one-step proofs are constant size independent of contract complexity independent of the amount of storage in your contract they don't require fancy cryptography there's no zero knowledge proof going on here this is just hashes and signatures okay so we have this slide that sort of summarizes the use cases they have their different pros and cons depending on what you want you'll want to be in one or another of these use cases but it's a single technology that covers them all okay how does this work it's built on top of etherium we have a compiler that takes your solidity code or EVM code and compiles it to run on our ABM architecture we offer plug-ins for your front-end development for web 3 ethers and go aetherium you use if you use those plugins it's just in the case of web 3 and ethers a single line of initialization code that you need to add to your to your JavaScript front-end and you're good to go these virtual machines that are running on arbitrary and send and receive ether or any ER C 20 or 721 token with regular etherium users or regular etherion contracts and our code is available here oh and we have a $1500 API prize here at eddie 'the waterloo ok so that's a quick summary happy to take questions in the remaining time yeah so here's one way of thinking about it many other systems are designed to rely on getting to consensus meaning agreement so that's kind of like a form of voting right so with voting voting you need to have something like a majority or plurality or 2/3 or supermajority requirement whereas with our Bertram we're not trying to figure out which answer is most popular we're trying to figure out which one is right so if there's any dispute there is this trusted on chain component which is going to figure out not who got more votes but who is actually right and because the on chain component determines truth rather than popularity if even one person raises their hand in favor of the truth they will be able to win any disputes against everybody else and they'll be able to make that correct that correct outcome be the one that gets accepted so if all of them if there is no honest node then you are in trouble if there's no honest validator so in the roll-up mode anybody can be a validator so you can be a validator right it is true that we give you if all of all of the parties participating in a contract are dishonest then we are not going to be able to guarantee what that contract will do in the channels mode that kind of doesn't matter right if Alice and Bob are playing chess and they decide that they mutually want to agree Bob to MIT allow Bob to make an illegal chess move you know the rest of the world doesn't really care in the roll-up mode anyone is able to stand up for their own rights so it's only in that sort of in-between mode the sidechain mode where there's a fixed set of validators where if every single one of them is dishonest and they're all colluding they can do what they want but again you know in any kind of a sidechain based model you had this issue that there's a fixed set of validators in other models if a third of them are dishonest or if half of them are dishonest you're in trouble in arbiter it's only if every single one is dishonest so that's and that's we think the strongest guarantee you can get in a sidechain based model yes in that case when you're in that so of these three use cases when you're in the sidechain mode there's a fixed set of validator so that is permissioned and so you have to rely on at least one of those validators to be honest but in the other modes either channel where everyone who's participating in the contract is a validator or roll-up where anybody can participate in the protocol in both of those cases it's trustless because if you're a participant in the protocol then you by yourself can force correct execution right that's what trustless means how can we provide right so here participants only right the participants need to know what's in what the contract is doing but the rest of the world doesn't in the case of a sidechain all the validators need to know and in roll-up it's it's an inherently public model if anybody can act as a validator then anybody needs to be able to know everything about what's going on so we don't think it's possible to provide privacy in this kind of roll-up model okay great any other questions right we have a channel on the conference discord we have a table like we've seen many of your faces there but for those of you haven't come by come on by and we're happy to talk more if you want to look at our code it is right here it's on github at the URL that you might guess off to a lab slash arbitrary Thanks [Applause]