Getting started with Arbitrum with Offchain Labs

all right so I'm not gonna do PowerPoint cuz like that we can't change what we talk about we can't like respond to what you say PowerPoint so I'm gonna go old school and off chain labs this is the place yep right okay so we are off train Labs is a company that got started really in earnest in January and so we're relatively new this is the first event that we have sponsored and we are we think a couple weeks away from our first alpha release of of our product so we have a bunch of folks here some of you been down down to our down to our table but William one of our developers is here here in the room okay so basically the value proposition is in Arbitron is the value proposition is scalability privacy security and Inter operation with the with the theorem so that probably sounds like a bunch of things you've heard before right well let me talk a little bit about sort of what this looks like from a product point of view in particular I sort of want to run through what you would do to take an existing gap that you have and get it to run on Arbitron and in doing that we'll sort of talk about what are the parts of the system and and sort of how they work the first step of porting your dap is you're going to write the thing and you write it in solidity with say let's say a web three front end right so familiar technologies basically for developing them and you can you can take an existing gap that's already developed to run on aetherium and and and run it and deploy it on arbitrament so the next step is to compile so we provide a compiler and it's integrated with truffles so if you want to use truffle you just say you just say truffle migrate - - Network Arbitron and and the rest just just happens so what this does underneath is your you're going to take your solidity code which you've developed and it's going to get compiled into an arbiter mexic you table and the way that works internally is essentially we use the standard compiler to compile into a theory and virtual machine code and then we translate that and into and link link it together to make a single arbiter mexic you table which encompasses a bunch of contracts right so adapt that you write consists of a bunch of contracts you compile all those together into one arbiter mexic you table so this produces an arbiter of executable file as its output okay and the only as I said the only change if you if you're using truffle to manage to manage this process the only change is a different command-line a switch to two truffle to make it happen okay now if you're going to deploy on Arbitron the the arbiter model runs your contracts offline off chain and it uses a and your contracts are managed or monitored by a set of validator so you choose the validators for your contract so this is actually an important aspect of the design there's not a single set of validators that everybody uses you get to choose your own validators when you deploy a an arbiter of executable when you start it up you choose your validators so you choose your validators so the and we provide we provide reference code to do this which runs as a as a docker container so you can read our code you can satisfy yourself that the implementation of validators that we provide is secure and so on but once you're happy with that the your build process will just make a docker image which you can then using our deploy script just launched and the validators will run okay because it uses docker it's it's going to be relatively easy to to to manage that and launch it from wherever you you you you are validators run off train and we provide what we call the any trust guarantee which means that as long as at least one of your validators is honest then your contract will execute correctly one honest validator implies correct execution right so this is what allows you to have a strong degree of trust in the execution of your contract while while almost everything happens off chain so one of the questions we often get is how do you choose your validators the and the answer is you can do whatever you want based on this guarantee but let me give you some examples so if you have a contract that has a small sort of fixed set of participants then you could just name all of those participants as validators so if you and I are playing a game of chess on as a as a contract we would just name the two of us as the validators right now each of us know is that at least one validator is honest and will stick up for our own interests right I know that there's an honest validator because I am a validator and same with you right so it's for a two-person contract or a three-person contract something like that or even any small number of participants just making each participant a validator is perfectly good and each validator each participant can then enforce correct execution of the contract in order to protect their own interests if you have a larger more open type of contract with a lot of participants then you need to choose a set of validators which is large enough and diverse enough so that all of your users will trust at least one of them and so you can pick and and this is going to be context dependent but because of the antitrust guarantee if you have say a couple dozen validators who are chosen in a thoughtful way from the community then then your users ought to be able to trust that at least one of them that those validators will not all collude in order to corrupt the contract all right so that's the security guarantee and you have to choose your validators when you launch but the design of Arbitron the protocol and so on guaranteed gives you this any trust guarantee okay so you've written your contract in solidity you've compiled it you've chosen your validators you're going to then deploy your your DAP so what does that amount to that amounts to starting up your validators if they're not already running and then doing a doing a call on the etherium chain to to launch your your contract as a running arbiter and virtual machine so your validators get started and there's a deploy script you can just run one command line to launch all of your validators if you're testing it just starts up an appropriate set of docker containers and make sure they can find each other and so on and then it gives the code the initial state of your contract to those validators and those validators will then execute your contract going forward okay so the validators will run your your will run your dapped once you do the deploy once the thing is deployed and running you then can launch the front-end or front ends in in a browser you can use unmodified web three front ends for this and we provide a provider which which is the glue to connect that front end to your to the arbitrament restrictions is that when your front end wants to do an RPC to call to the contract that RPC gets directed to the to the arbitral infrastructure which sees that it's delivered in the appropriate way to the running contract that to the correct running contract on the arbitral platform what you then get back what will come back to your front end is a statements signed mutually by the validators that that gives the result of that execution so it looks like a call in the same way as a call to two in aetherium contract that the front end are pcs to as far as it knows it our pcs to the contract and gets back a result which is cryptographically signed by the validators okay that is basically the process there's only one more piece of the technology that i haven't mentioned yet i've mentioned two of the major components of Arbitron I've measured I've mentioned the compiler and I've mentioned the validators the third piece is what we call the eath bridge and this is as low as I'm going to go on the whiteboard the eath bridge is the third major is the third major component and what this is is it's an aetherium contract or set of contracts it's an etherium gap that runs on chain and it is as the name would suggest is the bridge between aetherium land and Arbitron land so what does that what so what does it do it it manages the it manages the deployment or launching of contracts on Arbitron it passes calls and back and forth between Arbitron land and aetherium land and it allows you to transfer funds so that is either ether or any other ERC 20 or 721 token from aetherium land to an arbitrary act and then the arbitrament RAC to make payments that will go back to parties that are on the etherium blockchain the other thing that the eath bridge does is it referee's any disputes that happen among the validators so it makes sure that anything that anytime the validators want to write something to the main chain which they don't do all that often but they do do sometimes it makes sure that those are valid and if there's a dispute among among the validators it will referee that so you had a question now this is fine actually I'm basically done with the here's the parts and how it works so let's go to QA yeah what's I mean it's not a minor in the sense that it's not doing the operation of mining a validator is not part the validator doesn't work for the arbitrament for a particular contract or DAP right so and there are two ways that validators are motivated some validators are motivated because they are participants in a contract and they have an intrinsic motivation to want it to happen if you and I are playing chess for for money or for like a you know a gold star token that we have enough incentive ourselves to be to act as validators but sometimes validators are paid and there's a mechanism for doing that that you can arrange to launch a contract in such a way that the validators get a guarantee that they will be paid a certain amount per block time for doing the work of validation right so those are the two models either intrinsic motivation or else payment one thing about the protocol is that when a validator misbehaves that will be provable to other parties later so even if and so what that means is that validators do have a reputation to worry about as well that's part of the mix but we believe that they'll be motivated either by because they're participants or or by payment okay so let me talk a little bit about how it works to make this possible that and what happens on chain and what happens off chain right so the state of the state of a contract is is managed and sort of it's managed and tracked by validators when they run so that's this erasers terrible okay so each validator of a contract has a copy of that contracts code and state you can think of it the cui referred to the contracts that are running as VMs virtual machines because that's fundamentally what it is right and so each of the validators has a full copy of the VM State and when things are going as they should normally the validators each validator has a replica at the VM state and those replicas will be in sync so when the validators agree unanimously on what the VM will do next then they all jointly sign a statement that says what the VM has done that it's received certain messages that its state has changed and that's and that and that it has taken certain actions meaning emitting events or making payments and if the validator is all unanimous of an of a VM all unanimously sign a statement like that then that statement is accepted by the system so remember the antitrust guarantee right you need at least one honest validator and if all the validators agree then the honest one must have been part of the agreement right so that's that's consistent and you could have a series of these that operate sort of state channel style off chain and then only at the end of the sequence of these do you do you go to chain once and what goes to chain at the end is a very small cryptographic hash the state of the of the VM the entire state of the VM is arranged in a kind of Merkel tree and so that there's a single cryptographic hash that summarizes the complete state of the VM along with information about the messages that it received and the and the actions that it took which is emitting events and and and payments as well as the results of any calls that were made to it all right so that's kind of the normal mode and that's what validators are incentivized to do you can operate off chain for in in tightly sort of state channel style in that setting but the thing that mostly differentiates come on in hey no worries the thing that mostly differentiates arbitrament from from some similar products is the way we deal with the situations where a validator is unavailable or where the validators disagree about what about what a VM will do and and that's where most of them that's where a lot of the novelty in our design is so let me talk a little bit about how that works right so sort of classic basic state channel technology is able to do unanimous progress as I described just sort of a minute ago but where it breaks down is where you don't have everyone on all of the all of the participants or what we call validators online and in operating and so there's two situations that can happen situation number one is one of the validators goes offline or becomes unavailable then you no longer have unanimity right and the way that this the way that we operate in that case is that any one of the validators can make what we call a disputable assertion about what the VM will do that's a statement that they make on chain with a state behind it the claiming that the VM will will do a certain thing any other then there's a time window in which any other validator can dispute that if nobody disputes it within the time window then the system accepts it and you move on right so if the problem is just that some validators off line then you can make progress via these disputable assertions and that means that you have to have a small assertion on chain every time the vm is going to make progress but it's just a cryptographic hash of the new state of the VM plus any actions that it takes right so that's how you deal with unavailability but then of course the other case is what if a validator is a malicious or makes an error and and makes a false claim about what's going to happen so the scenario there is you have you haven't reached unanimous agreement with full participation so you have one of these disputable assertions that's put on chained by one validator then some other validator challenges it within the time window right now you have to have dispute resolution and this is a place again where where we have an approach that we think is superior to what other people do this is the case which is the hardest to handle in a scalable and performant way all right so here's the way this works the dispute resolution the way you could think about it is it's a kind of game between two parties one party is an asura who's made a claim about what a VM will do the other party is a challenger who says that claim is wrong and the this dispute a game is refereed by the eath bridge which is an on chain contract so the first thing and and the dispute resolution happens in two phases the first phase is a bisection phase and if you're familiar with true--but there's a lot of similarities to one aspect of true bits design here so some some validators made a claim that says that if you start with this state hash h0 that you can execute n steps of execution and the result is is state hash h1 this is the claim somebody else says that's wrong so now the assert the original assert er is has to break their assertion in half so they make one assertion that says that in n over two steps you go to H sub 1/2 and then in an additional and over two steps you go from H sub 1/2 to H sub one right and so the assert breaks their assertion in half and the on chain eighth bridge just needs to verify that do these two things if you stick them together are equivalent to this that the steps add up that the end hash of this first sub assertion is the same as the beginning hash of the second one and in addition that the all the actions that were taken here are divided into two pieces right so that's pretty easy to verify now the Challenger has to pick one of these two halves to challenge and once you've done that that's one round of bisection and you've cut the size of the dispute in half right you keep doing that on a logarithmic number of times and it's not really bisection it's like five-way section or something it's the it's it's a more efficient way but fundamentally it's this recursive subdivision right and you keep doing this until you have a disagreement about one step of execution so you have a hash here and you have a hash some other hash later and there's a single step of execution and the dispute is about that now at this point the assert er needs to put right on chain a one-step proof that is a proof that if you are in a machine state that hashes to this you can execute one instruction to get to a machine state that hashes to that and this is where the other really significant set of innovations in our Bertram comes in in that we have we've designed our virtual machine architecture in a way that allows this this proof to be very small and very fast to check so no matter how big your virtual machine is no matter how big the code is or how much data you have these proofs are a couple hundred bytes and they're checkable in order of a hundred thousand gas on aetherium yes yes it's a proof that if if you start in a virtual machine state that hashes to this that you can execute one step of execution one one opcode of execution and the result will be a state that hashes to that right so this is the assertion and also there's optionally a single action that might have been taken you might have emitted an event or you might have made you might have sent a message in here and so that would also be part of the assertion right and so the proof is information sufficient to allow the eath bridge to verify that this assertion is in fact true and so it's not obvious that it's possible to do this but you know we figured out how to make this proof extremely small and fast to check so the combination of this bisection which narrows down the dispute efficiently and this very efficient one-step proof and verification allows us to resolve disputes very efficiently so at the end of the dispute either the assert or Challenger has won the the contest and someone else has lost the loser will forfeit their stake half of their stake goes to the winner and the other half gets burned and that gives that gives the participants a strong disincentive to either make false assertions or to make false challenges it gives people a strong incentive to fight this game and win if they're right because they'll get half the other party stake and by burning half the stake we make sure that the assert our and Challenger are not in cahoots to cook up a fake fake dispute because they'll collectively lose half a stake by doing that and so that's the incentive structure that disincentivizes disputes but even if there are disputes we can resolve them fairly efficiently and move on it would either be malice or it would be a bug those are the only scenarios in which this can happen the execution this again we this gets into the weeds a little bit but the execution of that arbitrary certian czar let's see the execution of a code within a particular assertion is deterministic and so there is one correct answer about what the state would be after n steps given information that's in this that's put in the assertion and that gets into the weeds a little bit we can talk offline about how we ensure that but there is one right answer and so if there's a dispute someone is wrong and they're either maliciously wrong or they have a bug in their code sorry if both people are wrong someone will so strictly speaking this protocol identifies one liar and that liar is punished if both people are lying if you're lying and the other person is also lying you might get lucky and actually win the game but you know you're deterred from doing that right and it's negative some for the players that's right that's we don't try to identify everyone who is lying that would be much more expensive yes thank you yeah yes that's right the storage is on the validators now in addition to validators there is another status that we call observers observers get to see what's happening inside the inside the VM but they don't participate in ensuring correctness so other parties can be observers and so they will know what's inside the what the VMS storage and memory are they will so they'll have a full copy of it so it's replicated across all of the validators and the observers yeah yeah so a hash of the full hash of the VM state is stored is committed to by the validators and so the validators have committed to what the state is and you could have an out-of-band protocol with them to challenge them to say show me prove to me that memory location number such-and-such has this value and they could present a Merkel Merkel proof that that builds off this route to show you that or they can just tell you the full state of the VM including all the storage and the code and everything and then you can Merkel Merkel hash it yourself and verify so they can prove to you and you can demand that but there's nothing within the protocol that forces them to give you that proof when you ask the the observers right so really be the idea of the reason you would be an observer is you want to be able to look into the state efficiently in principle right you could always just ask a validator and a friendly validator would answer any question you had about the internal state of the VM but it might be more efficient for you to be an observer so for example you can make non mutating calls if you're an observer you can execute non mutating calls on the on a honest solidity VM because that doesn't need to go to chain we're gonna lose the room right now I would be happy to just like answer questions out here for as long as you guys want but we are being kicked out because we've reached the end of our time so thanks thanks for your attention just point you to off chain Labs calm and and invite you to follow us and to watch for our alpha release which we think is a couple weeks away thanks I'm sorry so the Alpha will be designed for testing on a local to on a local net local test net that's the next thing yeah yeah yeah so you know we're going to go through the usual steps first an alpha that you test that you can run in a local test net then a beta that you can run on the etherium test net and then then a release that that runs on the real runs out in the real world Thanks