Arbitrum: Overcoming the Limitations of State Channels by Ed Felton of Offchain Labs

okay let's start thanks everybody for coming I'm Ed Felten I'm the co-founder and chief scientist adoption labs and I'm going to talk about Arbitron which is our product now the second spin of alpha that overcomes a bunch of the limitations of state channels risk I'm going to talk about state channels just sort of a review of what they are and what the limitations of state channels are and then I'll talk about sort of how we overcome those and some about the design of our a product and at the end they'll talk just give a few pointers on what to do if you're interested in using it all right so I might start with smart contracts smart contracts have to like are awesome they have their disadvantages every minor emulate every execution step so the contract complexity is limited by the global gas limit on a theory of that gas limit is uncomfortable oh it's something like a tenth of a laptop of total computation capacity that has to be shared by everyone across the world and this gas mechanism is basically necessary because it's expensive to run contracts and also all of the contracts in code code and data is public so the total throughput is really limited by what a single miner do right so there are a bunch of responses to this to try to get scalability one of them is state channels and just a review overview what state channels are for those who need the review if you have a fixed set of end participants in a state channel who are defined at the beginning whether state channel is operating as a state channel they unanimously agree off chaining about updates in the state of the channel and as long as they unanimously agree on a sequence of updates you can stay off chain and everything is good and you only need to go on chain if there's not agreement among the participants so the optimistic case is great everything happened is off chain and you only need to sort of cash out the state channel at the very end Chane okay so if you if you want to write this as a smart contract in theory of you're right it's sort of like if you write it as a smart contract that operated in two modes state channel mode and unchain them so the contract starts out in the state channel mode and the participants then sign State updates locally and when you're in this initial state channel mode and everything is going along off chain then all of the functions of your contractor locked except for closed channel closed channel is basically what one of them which is what someone's going to do if you are no longer reaching unanimous agreement off chain then you're going to need to move on chain so you initially start here everything happens off chain except for this one opportunity to close the channel now if you don't get agreement among all the parties and that could happen either because somebody becomes unavailable or because somebody is just uncooperative or malicious if that happens then some participant can decide to close the channel actually any participant can decide to close the channel just because they feel like it but in any case once you close the channel the contract now enters the on chain mode the contract is initialized with the most recent sign state whatever is the most recent version that all of those parties agreed to off chain that's going to be the initial state of the now on chain the execution of the contract all the functions are now unlocked and the contract proceeds on chain until completion right Sonia you ride the optimistic horse as long as you can and when the optimistic mode fails then you switch to on chain execution that's the standard state channel model so why use them well they're fast they're scalable because they invested scalable because they have very little on chain footprint in the optimistic case and they're also private when you're operating in the off chain mode that is you don't need the stuff that's happening in your contract that could just be agreed upon mutually by the participants and as long as they all sign updates you don't have to post those updates to chain and you can have a long interaction between the parties and at the end you just have a simple cash out transaction that they don't think I can read so that's great when you're operating off chain but there's a set of disadvantages that state channels have a set of limitations so one limitation is that they're sort of fragile if one party not only fails but even just goes offline for a while one participant then your fast progress halts you switch into the slow on chain mode and you stay there state channels don't distinguish generally between unavailability and mouse so it doesn't require that somebody be wrong or malicious just if they have a hiccup in the availability of their computation or their network the result would be the whole thing will go on chain and stay on chain so that's the fragility the second limitation is that they're computationally limited although you can do huge amounts of stuff lots of computation have lots of storage when you're operating off chain you need to be prepared at any time to move on chain and that means whatever it is you're doing it has to be doable on chain and so even if you're in the optimistic case you you have to be able to get pessimistic and so that means you can't do more then on chaining resource limits would allow so state channels improve the transactions per second but you still face the same limitations on computation and storage as you would if you were not changing the third limitation is you don't get guaranteed privacy you have privacy of what's happening if you're operating off chain but as soon as you go on chain everything is visible again and then finally generally state channel models require specialized development that is you don't write your contract in the standard programming model or paradigm you have to write your contracts actually for a state-transition paradigm in which the contract goes through sequences of states and what gets agreed upon is the state in between and that's a different programming model than the one that you have if you're writing a normal contract in let's say solidity so the fact that you have to write in a different model and a model that some people at least I considered to be less friendly is a drawback so those are the four limitations argotron our solution for a lot chain lab solves all of these issues we were able to make and I'll explain how and why this happens in in a minute but we can make non-unanimous fast progress meaning that if somebody becomes unavailable we can still make progress fairly quickly not quite as quickly as if everyone's available even if somebody gets malicious or in error and there's a dispute we can still make progress relatively quickly we can resolve disputes between parties without having to run the full code on chain we have a very efficient on chain dispute resolution protocol which operates without taking more than a tiny bit of the state and putting it on chain and that means that because we never have to move your whole contract on chain that we're not limited by the computation and storage that we could do on chain we can do more than can't be done on on chain and sustain act and privacy is guaranteed even when there's a dispute because you don't have to move the state of your contract onto the chain in case of dispute if you want to keep the code of your contract secret or you want to keep the state of your contract secret to only the participants you can do that and there's no need to explicitly reprogram in the state transition model you can compile existing the contracts without modification using a compiler that we supply so if you have in my colleague Harry Claude nerd did a API workshop this morning where he did a sort of live porting on a simple tap from etherium into arbitrary in a few minutes it requires changing only a few lines of code sort of in the initialization okay so now there are a couple of different use cases or styles of using armitron which I sort of summarized here in this table and I'm not going to go through all of this but I just want to know that what I'm going to talk about here is what we call arbitral channels and that is a state channel like mode of operation where there's a fixed set of participants the system runs trustless Li for the participants and computation storage and messages all happen often we give instant finality for in the common case and privacy is such that only the participants need to know what's going on we also have arbitral chain mode where the participants are dynamic participation is dynamic and open to everybody in a slightly different performance characteristics because messages to that you're the the call data of your of your transactions has to be on chain but computation and storage still long so I'm going to talk about here in this session about arbitrary channels okay so basically the arbiter of design involves a very high level a combination of three things it involves some protocol design that is how is it that the parties participants interact with each other it involves some incentives we give parties incentives to come to agreement off chain and we produce strong disincentives to ever getting into a dispute and then we have there are some things we do in the virtual machine architecture that allow us to make dispute resolution very cheap and I'll go through this in a little bit more detail so let me sort of build out how this argotron channel's mode works one of the first concepts here is a validator and that's the term we use for a participant in an arbitral Channel when you make a VM a virtual machine this is our term for a contract or group of contracts that are run sort of for a running gap on the chain you give a list of validators for it those people any parties you want and those validators are responsible for keeping track of the VMS computation and its data so think of them like the participants in this station and we provide what we call the antitrust guarantee and that guarantee is that as long as at least one of your validators is honest then we guarantee that your your contract will execute correctly according to its code that means in particular if you're a validator then you can force correct correct execution all by yourself so it's trustless with respect to you and that's why we say that arbitral channels are trust us because every participant is a validator in any one validator can force honest progress validators advance the state of the running vm in in in a couple of ways the heavy sedatives to agree unanimously about what you're about what a contract will do and when they unanimously reach agreement they can repeatedly update the state without going on change this is very much like optimistic mode of the state channel you can have a whole series of executions and and if everyone is well-behaved and follows their incentives then you're basically won on change transaction to start your contract and another one at the end and cash it out if they all agree the system accepts what they agree on is correct and that's consistent with that any trust requirement so the method that we use is something we call unanimous desertion and it looks logically like this the validators all agree that if the if the machines virtual machine starts in a state certain hash and with its inbox of incoming messages having a certain hash then it can execute n steps of computation the result will be that the Machine State will be will have this hash the inbox will have that hash and along the way it will make some payments and cents of outgoing messages so if all of the validators agree on this then they can sign a series of these things and if they change together with this resulting state matching the precondition of the next one then they can just chain them together off chain so as long as it's signed jointly by all of the validators you're good to go and that's all opportunity ok and once it is confirmed and fully signed by everybody this is some technical details here but except in rare cases it's immediately final meaning that we guarantee that it will eventually reach the main chain and achieve finality there so that applications clients can trust that they have already have finality all right so so far this looks like just regular state channels want to talk now about the more interesting case which is how to make progress table unanimously and one of the first pieces of this is what we call a disputable assertion so any manager any validator can make an assertion that is the claim that looks just like one of those unanimous assertions but it's made by just one party and when they make this claim they put down a deposit which they might lose if their life the assertion is subject to challenge and if somebody challenges that claims it's wrong then they deposit funds and if there is a challenge then there's a dispute and the party that's wrong is going to lose their deposit ok so it works kind of like this somebody makes a disputable assertion and when they do that a timer is started in which everyone else an opportunity to challenge it if they don't give time passes without challenge that it's confirmed that it's accepted as correct everyone had their chance to challenge it they had an incentive to challenge it and if they didn't then they must have believed it was right alternatively you can have an assertion disputable assertion make somebody can challenge that and now you have a dispute between Ana starter who made the claim and a challenger who says it's wrong and we officially resolve the dispute in through a two-stage protocol the first stage involves bisection that is the idea that once the challenge is made the assert has to bisect their assertion into two half sizes certian that fit together to to yield the initial one and then the Challenger has to pick one or the other of these two sub assertions to challenge here they challenge the second launch something's wrong with it maybe you didn't get to this end state maybe it didn't spend exactly these coins maybe you can't even execute n over two instructions whatever it is it claims this is this is not a thing that that this machine could do so you continue this process recursively dividing into four one of those gets challenged and so on after a logarithmic number of stages of this what you have that is an assertion about just one step of execution like say an instruction and somebody has to challenge that now at this point we go to the next the second stage of dispute resolution and this is the one that uses the virtual machine architecture and that's a one step proof and so the party who mate has made the one step assertion needs to provide enough information that an on chain component can verify that their claim is correct or determine that is wrong and so the big question here is how big is this one-step proof and how costly is its created verified through a bunch of through a bunch of trickiness in the way we design the virtual in architecture we make these one-step groups of small constant size meaning a few hundred bytes and independent and that's independent of the complexity of the contract how much code or data it has in it and they don't require complicated cryptography just hashes and ordinary digital signatures so the custom VM architecture guarantees that these proofs are small and it's efficient one-step proof so this fall and they're fast to create or verify cost about 90,000 gas on etherium to verify this so this is order of ten cents or less of worth of gas to checkout to verify it one step three and they're also private they don't leak contract data because they're just dealing with hashes of things okay so one of the one of the consequences of the way this design works is that the state of a virtual machining of a running contract is revealed only to its validators they're the only ones you need to know the only thing that appears on chain is this stuff solvable hashes of the state cryptographic hashes the number and timing of steps executed when you're in non-unanimous about the fact that the vm executed some particularly number of of steps at some point in time and also the messages and money that are sent and received by the vm if the virtual machine is going to receive or make payments of E or of other tokens that's ultimately going to need to be recorded on chain and so that's going to be on chain but this is all that appears on the etherium may change so arbitrary on top of aetherium we have an ethereal contract called the eath bridge we called it bridge which manages all of this resolves disputes and so on ok so right it's built on the theory of we offer a compiler that takes your existing solidity code or takes EBM the theory of virtual machine code if you want compiles it into our architecture so you can use existing contracts we offer plugins from the front-end for web 3 ethers and go aetherium to let you use your existing JavaScript or go based front-end you just plug in our our our plugin instead of whatever one you're using so you can use their existing front-end code these virtual machines that are running can send or receive each or any PRC 20 or 721 token between the theory of land and arbitral land or to other arbitrary virtual machines this is all available on github it's open source you can go and try it out ok so we have a developer site which is here developer not off Chan Labs calm the code as I said is here in the URL you can probably guess github calm off chain Labs Arbitron there's a developer QuickStart doc and we have an API prize so $1500 here at this event and we thought would think a few minutes or any questions scalability solution you give a high-level overview of how arbitrary scale sure so where we are not only in our outfit is we we measures for scalability we measure a couple things there's several things that are relevant why does how many contracts can you run at the same time and then what performance do you get for each contract and performing for each contract we measure both in terms of transactions per second that is sort of how fast can you spin the dial and also how much computation you can do perspective within a contract right so in terms of the number of contracts per second if you can run simultaneously when you're running on sort of test net on a local machine laptops tell you you can run thousands of contracts at the same time and we can make that number frankly we we feel safe saying thousands is an honest number but we can you know we can cook the benchmark to make that as big as you want in terms of transactions per second we currently are a bit over five hundred transactions per second in each contract again you know thousands of contracts at the same time the amount of computation you can do in each contract right now each contract gets can execute instructions at a rate that's about 2.3 times the global capacity of atheria within each contract that's what we are now we expect to get substantial improvements over that continuing over time so the other thing that we think is important for application developers is finality time right you want to be able to get instant finality in the common case and you want to be able to do that with a very strong trust guarantee you know there are lots of different level tools out there and there's different trade-offs between them we think we really hit a sweet spot in terms of scalability and performance privacy yeah instant finality in the common case and a very strong security guarantee right so unlike some other chains which say you need to have PAP honest or 2/3 honest participants in order to guarantee a correct execution we have this very strong any trust guarantee so even one honest validator gives you guarantee of correctness so it's trustless with respect to those participants so that's basic thank you right yes like certain types of applications and others if you could imagine because the few powers like there might be two so if I mean it does work for everything in the sense that you can compile any solidity program and the compiler doesn't generate a slowdown compared to other dispute resolution based systems so in other words we it is general-purpose in the sense that you can run anything on it it's especially well-suited for applications that require a lot of storage or a lot of computation because the on chain footprint and the cost of proofs and so on are independent of the amount of storage and the the cost of dispute resolution depends only in a logarithmic way on the amount of computation you do and so things that require large storage buffer lots of computation and a multi-user type damps large storage may come from having a lot of users whose records all need to be kept within we also have a particular type of privacy guarantee and so if you care about that we're also we also might be well-suited for for what you have we kind of feel like we have a combination of features that is that is really unique as well so you know if all of you care about is privacy then maybe you want something if all you care about is scalability and you're willing to sacrifice some security in order to get it then maybe something else is right but we think we're at the sweet spot where we do well on all of these dimensions yes yeah the current version is open-source there will eventually be a premium model which is close to a premium version which is close source but the developer version we come out now is is BSD license it will always be open source there will always be a fully working system at at least the current performance characteristics it'll be higher performance and primary higher performance in some tools for sort of management and enterprise yeah so basically you're saying that you divide the code you can do like a binary search in the code yes I think that people are contesting so let's go back and then you need and then someone has to prove yeah so so let's walk through the example a little bit more carefully just to kind of put a finger on that right so suppose that I claim I make a claim like this right and you actually like you know the initial state of the VM you run it for n steps and you find that it ends with some other hash yeah right so you you would then just put down a challenge on my plate right so that what's you versus me and this theory of contract each bridge is refereeing my recipe right so now it's my turn I have to bisect my I have to bisect my assertion now it's pretty easy to prove that if my initial assertion was wrong then at least one of these two halves has to be wrong right and so your job once I have made this claim by section is to figure out which half is wrong what you're going to do in practice is you're going to try to replicate the first half if that's wrong you'll challenge it if it's right then the second half it must be wrong you just can't an instruction number and at that point we stopped yeah - check the house it doesn't match that's how you do that's what you did to figure out if I was right in the first place right and now I what I've I sucked essentially what I'm doing this I'm saying what was the hash of the halfway point I'm making a claim about that and you say either that you can't get from here to here in over two steps or you can't get from here to here and then over two steps right if my initial plate was wrong at least one of these two sides of mine has to be alive you just have to figure out which one it is you put your challenge on that one right so now you've got your finger on something that you know it's wrong it's smaller right you don't know what I claim happened in here but you know this is wrong right so this happens on the chain right I've made this assertion on chain and you put the challenge on chain and I brought this midpoint hash on chain and then you said well I'm challenging the second half and so on and we continue to do this or I like to put down two deposits no no you put you put you put it I put down a deposit when I made my first claim and then you put down the deposit when you make your challenge and now we're involved in this dispute and we're playing for our deposits the loser is going to lose their deposit the winner gets half the other half gets burned right and so if your challenge is a valid challenge and each stage you'll be able to identify one of the halves that's wrong and so you're basically pinning me down step by step assuming I'm lying if I'm telling you the truth then I just keep telling the truth and so get down to the end if you were right in the beginning then you're going to be right down here as well I will not be able to show that you can get from here to here in one step of execution if I was right in the beginning and I told the truth all the way down then your challenge was bogus and continued to be bogus all the way down so whoever was right at the top level is also right down level assuming that the person who was right played the game well and so then the on chain component just needs to resolve this dispute right and that is the point where I have to like actually but what my claim has here is a hash of the state I have to open up a little bit of that hash can imagine the whole state is organized as a Merkle tree and I have to open up a little bit of that Merkle tree just enough that you can figure out what the Buerkle tree after one step of execution is just enough you can figure out oh it was an add instruction and he was adding three and seven therefore the result is 10 and the rest of the big purple tree is just what it was before so we don't need to open it right and so that's kind of the spirit of how that was def proof works and that's checked by an on chain by an untamed contract cost about 90,000 guests to do that and now it knows whether I was right or you were right and whoever was wrong is going to lose their deposit right and so what that means is if whoever was whoever is right will win and so I was right in a starting that what I was doing I will win the dispute and so because this dispute gets to the truth of what the virtual machine would have done with some technical caveats then we could talk about off changing in other in other words which don't need to in correctness of the other right maybe both people are getting the point B maybe both people are idiots and the protocol is designed so if both people are idiots are lying that it doesn't take a long step so what we guarantee is that anyone honest party can prevent a wrong action by challenging it and then although I didn't talk about it in the limited time I had here we also guarantee any trust progress which means any one honest party can force progress even if everyone else is throwing up fake challenges at large expense to the and that that's how we get the any trust basically that whoever is right is able to win because they're right that's the thing you have to do in order to in order for one right person to be able to win over n minus one wrong people you have to actually get to the truth of the claim not quite so one thing you can do is you can take those two parties and send them off to the side to resolve their dispute so once the dispute starts so if if the original Lacerta wins and the assertion is accepted the system can't necessarily believe that that assertion was correct right because maybe the maybe those two parties are actually polluted they're trying to create a situation where the asserted one and so if there's a dispute you just take those two parties you send them off on the side to resolve their dispute and then the the operation of the virtual machine creatures going yeah so the worst case delay is assuming that they're n minus 1 people who are willing to lose deposits going to lose large deposits reputedly they can slow you down by a basically factor of n that's right thank you make the deposit resolution let's see so it probably depends on n right so it's logged in we don't really buy set we really do Gateway Meissen k way this case section for a larger K so and a realistic circumstances think about a dozen unchanged transactions to do so they can send them off on the side to do that there is a large they have put down large deposits and those large deposits the losers deposit half of it will be burned you could a little bit of that actually goes to compensate the the miners to pay for the gas to do all of the dissolution so there's ample funds from the losers deposit to