Solving Scaling Without Compromise

EDCON 2021 · 29 Aug 2021 · 12:43

Edward Felten of Offchain Labs explains Arbitrum's optimistic-rollup architecture ahead of its public mainnet opening in 2021. He traces transaction inputs, state claims and interactive disputes, showing how a large execution disagreement can be narrowed to a single step for Ethereum contracts to adjudicate while preserving compatibility with existing tools.

Speakers

Topics

From EDCON 2021, hosted by EDCON.

Transcript

hi everyone i'm ed felton chief scientist and co-founder at off chain labs and i'm here to talk to you about arbitrary arbitrary offers the advantages of ethereum but without the disadvantages arbitram offers very cheap transactions because we move computation and storage off the main ethereum chain at the same time arbitram is fully trustless we offer permissionless validation and our security is firmly rooted in the security of ethereum it's also drop-in compatible with ethereum uh we support we fully support the ethereum virtual machine there's one click porting you don't even need to recompile your code and it works with all existing languages and tooling so it's like ethereum compatible with ethereum only

better we arbitrary 1 is our is is our main net we released our mainnet beta in may of 2021 and our main net is opening fully to the public on august 31st we're very excited that that's coming up so soon arbitrary comes with the big ecosystem we we have many infrastructure providers you see here many of the largest most important infrastructure providers have announced that they'll be working with us in supporting arbitram wallets integrated with uh with arbitrage and many of the biggest and most important dapps also supported and integrated with arbitrary these are the providers and the dapps that have

publicly announced so far that they'll be working with us but there are many more there are about 400 teams in our developer program let me talk a bit about how it works because i know this is a a community of developers so the big picture of how arbitrary works is very simple the chain has an inbox where users can submit transactions there's a chain state which is updated over time as the chain consumes those incoming transactions from the inbox and then it produces a bunch of outputs like payments or uh or events so from this picture to get to a complete system design there are several types of questions that we have to be

able to answer who keeps track of the inbox and the chain state how do we ensure the chain state and the outputs are correct how do users interact with the system and how are eth and tokens transferred in and out of the arbitrary chain i'll spend most of the rest of my time answering these questions and giving you a picture of how arbitrarily works the first thing to talk about is roll up arbitrary is a rollup type technology that means that users transaction data is posted on the main ethereum chain in a compressed form but but ultimately posted on the ethereum chain but execution and storage are moved off chain into arbitrary nodes

arbitrary operates by proving the correctness of the computation that happens on the l2 arbitrary chain is proven to the l1 chain using optimistic rollup technology basically some validator makes a claim about what the correct outcome is and then there's a fraud proof mechanism that allows us to resolve any disagreements among validators and all of this is secured by the layer 1 blockchain secured by smart contracts running directly on ethereum that are the record keepers and referees in the arbor trim protocol to give a picture of how the roll-up protocol works here we see a series of roll-up blocks that encode things that have happened on the arbitrary chain and

all the blocks up through block number 92 have been fully confirmed and recorded on the l1 chain then alice made a claim claimed blocked roll up block number 93 and bob ultimately disagreed with that by staking on rollup block 95. now there's going to be a dispute resolution protocol between alice and bob where alice defends the correctness of her claimed block 93 and bob challenges it so how is fraud proven how does bob prove that alice is wrong well all of the inputs to transactions as i've already said are posted directly on ethereum and now validators like alice

and bob make bonded claims about what's the correct result of executing those uh those transactions that arrived as inputs invalid claims if they're made can be challenged by anyone as bob has challenged alice's claim in our example there's then if there is a disagreement a dispute there's an interactive challenge to narrow down the dispute from a dispute about a large amount of computation to dispute about a smaller amount of computation smaller and smaller until ultimately there's a disagreement about a single step of execution and then a one-step proof procedure is used to declare the winner it looks kind of like this we start up

at the top with alice having made a claim and her claim is that if if assuming that the system starts with the hash of its state equal to h of s0 is shown on the upper left alice claims that the chain can execute n steps of execution and after that the result will be h of sn and she also claims that the chain will emit certain outputs it'll make some payments and emit some messages bob says no that's wrong now alice then is is required to divide her n step claim into two claims that are half as large

two consecutive claims of size n over two and then bob is required to identify one of alice's n over two size claims as incorrect in this example bob has challenged the second and a size n over two claim of alice alice then has to bisect again taking that challenged and over two-step uh claim divided into two claims of size n over four bob chooses one of those and so on at each round of this bisection protocol we cut the size of alice's assertion in half so after about log n steps alice has made a claim about one step of execution which bob disagrees with

now alice might then be challenged to prove something like well that alice has to prove the correctness of that so alice might prove try to prove that that's an ad instruction that the not values being added are 3 and 5 and the result of 8 is the correct sum so that's an easy thing to prove so we take a very large dispute over n steps narrow it down to a very small and simple dispute and on we go now the beauty of this interactive proving scheme is that it's first of all it's very efficient in the optimistic case if alice's claim is correct then she's just posted that simple claim before hash after hash number of steps and hash of the outputs

if that's correct that's all she has to do alice will do that every say 10 or 15 minutes on mainnet and everything is good super efficient even if there's a dispute um the cost to the l1 contracts is minimal l1 contracts running on ethereum act as the referee in this dispute protocol but the referee's job is very simple just to make sure that alice has made two half-size claims without thinking about whether those are correct or incorrect that's bob's job make sure that alice has broken her claim in half make sure that bob has designated the first or second half and so on very easy for the referee to do you never need to run the full

transaction on l1 you never need to take the full code of the contract and move it to l1 so it's very efficient that means we can have much higher gas limits and much larger contract size limits than l1 ethereum we're simply not bound by ethereum's limits because we never have to execute an entire transaction or store an entire contract at l1 this also gives us a ton of flexibility in how we implement the system and how we do the fraud proofs and that flexibility pays off in performance and it pays off in compatibility so we think interactive fraud proving which is the thing that's special about arbitrum

is a huge improvement over over what other systems do so if you're a user you can take the l2 view of arbitron that is you simply view this as a chain like ethereum if you're a user you can make rpcs to an arbitrary node and that arbitrary node will then talk to rbos and rbos is a component we wrote that runs at l2 and emulates evm contracts the user experience here is very standard arbitrary nodes provide a standard json rpc endpoint compatible with what ethereum nodes offer so it's compatible out of the box with metamask hard hat and other standard tooling if your tooling knows how to talk to

an ethereum node then it can talk to and work with an arbitrary node nodes always know the correct state they don't need to trust individual validators and users can deploy contracts because of the standard json rpc api users can deploy contracts using standard developer tools like solidity or viper as i said before you don't even need to recompile now the secret sauce that makes all of this work is rbos rbos is the l2 operating system of arbitrim it's a mini operating system that runs at layer 2 it runs on top of the roll-up chain because it runs at layer two it gets the advantage of very cheap execution and very cheap storage that

lowers the total cost of operation of the system by a lot instead of having a lot of complexity and cost in l1 contracts to enforce the rules of our roll up we push as much as possible of that work up to l2 and put it in rbos that gives us speed it gives us low cost and it gives us a lot of flexibility which pays off for users in many ways so rbos provides generalized safe l1 to l2 transactions l1 can call l2 l2 can call l1 it offers safe token bridging you can move ethan tokens back and forth smoothly it offers efficiency features like batching of transactions to amortize the l1 costs bls signatures

to lower the cost of signatures and make transactions even smaller it offers evm compatibility at the bytecode level to sub to deploy a contract you send literally the same bits that you would send to ethereum and it's easily extensible with new transaction types and features this again is a unique feature of arbitrary that we think is really important in providing the value that so many developers are seeing in arbitrary so putting it all together putting all those features together you get back to this simple model of an inbox where users put in transactions an execution engine which is operated by validators but which users can simply trust or if you want to run a validator yourself to

execute trustlessly and produces outputs that are compatible with ethereum here's a picture of all of the pieces in our stack arbitrary nodes rbos and then some contracts we call the ethbridge that run on ethereum all of this is open source and available uh for you to look at and it's been it's been running on testnet since november and running on mainnet since may so the next steps well come and hang out on our discord visit and click join our community you can view our developer documentation at developer.opchainlabs.com and most importantly deploy your dapps and use arbitrary mainnet because it

opens on august 31st thanks for your time please come to our discord or reach out to me if you have any questions we're really excited about the launch that's coming out and we can't wait to have the broader community see what we've done and most importantly what our amazing community of developers and providers have done and are doing