Trustless Scalable Smart Contracts – Edward Felten

the next person who's speaking I'm kind of a little excited and smitten by because he used to be the deputy chief technology officer for the United States so we have someone coming from politics that's my old stomping ground Edward felt in now with off chain labs he's going to talk with us as you can see about trustless scalable smart contracts take it away and it's Mike let me try this one let's see how it goes all right hey everybody so I'm ed I'm the co-founder and chief scientist at off-tune labs and I'm gonna talk about our bertram roll-off this is the first rollout product that is available on test net for general smart contracts so first of all some background what is roll-up there's different roll-up systems that have been proposed but basically I would say roll-up is characterized by three things first it's an approach where you build a scalable layer to chain that's anchored on a small layer one contract by building on top of that small layer one contract you can get the security of a layer one solution but the scalability that you get by moving a lot of stuff off into layer two in particular computation and data moves off chain the second thing about roll-up is that you post as on chain call data everything that's needed to follow and validate the correctness of the l2 chain so everyone who wants to can follow what's happening in the l2 chain reconstruct it all and figure out if it's correct and that means that you have the ability to participate in the protocol to ensure correctness at l2 so that's all transaction calls and data hashes of the contract state and of outputs and the third thing that makes roll up roll up is that you advance the l2 chain by posting a roll-up block to the l1 chain that includes the results of multiple l2 calls that you post all rolled up into a single transaction to make it cheaper the system of course needs to validate those roll up blocks somehow and that's where that's where a lot of the secret sauce is okay so let me talk about our Bertram roll up our Bertram Ralph is a roll up approach that is is our product it supports general smart contracts we compile your code from solidity so you don't need to modify your code except in the slightest way it's compatible with standard front ends so we offer plug-ins for web 3 ethers and go aetherium so that you don't need to rewrite your front-end the user can use the same browser-based front-end that they want working with meta masks or a standard wallet and you just have to change a few lines in the initialization of your front-end code in order to pull in our plugin we provide easy tooling for launching a chain for your DAP we're not a single chain we're a tool for launching many chains and we anticipate one chain per dab that gives better control and better performance for each down we provide easy tooling for launching a chain moving eath in and tokens in and out we grew out of Princeton University research and we're the first roll-up for general contracts to be available in working on test net so if you want to launch an arbitral roll-up chain for your DAP let me talk about how that works and I'm gonna do two things for the rest of for most of the rest of my time I'm gonna talk first about what is the developer experience what do you have to do as a developer to actually use this and I'll occasionally stop and we'll go under the hood and talk about how it works and why it's designed the way it is ok so you want to launch the first thing you need to do is compile your DAP so your DAP may consist of a bunch of solidity code maybe a bunch of contracts a bunch of libraries a pile of dots all files and some migrations stuff you take all of that and you feed it into the arbitrament compiler the arbitrament compiler takes those different pieces that make up your DAP and it crunches them all together into a single executable file we call an arbitral executable which might have a name like my chain do now and that is the thing that you can then launch as an arbiter in chain so you do that by using a command line like the one on the upper right truffle migrate dash dash Network Arbitron we have a we have a plug-in for truffle that makes it just that easy to compile your existing solidity DAP to run on Arbitron and that takes care of everything to make this one file that my chain do now when you do this compilation we also include into the your executable a few other things we include first of all the arbitrament oaken bridge this is a mechanism for easily moving eath and ER c20 and ER c 721 tokens in and out so a user can transfer tokens deposit tokens into your chain they can withdraw tokens from your chain and we provide the the contract and protocol support for that automatically will link it in with your contract automatically and we provide a nice front-end that I'm going to show you later for that functionality we also provide compiled into your code a bunch of bookkeeping dispatching and managing management services and the reason we do that basically is that other meant some other solutions will do a certain amount of bookkeeping & management on chain in the l1 in their master l1 contract but we found that by moving some of those functions into l2 we can operate them at the efficiency and at the low cost of l2 so we take as much as possible of the bookkeeping & management and all of that kind of stuff needed to operate a chain and we move it actually into the l2 itself and we compile back in automatically into your into your arbitrary executable so that's a single package a single file that you can launch how do you launch it while you go to this URL which you can't quite read up there but it's developer dot off chain labs.com slash tools slash deployment and you get this form so up near the top you see there is a under contract upload there's a box and you can drag and drop one of those dot IO files into that box or you just click the Box you get a file chooser it's that easy to inject your dot IO file and to get it set up to start a chain down in the bottom there's a bunch of parameters for your chain you can set we have presets here I've clicked the preset for local testing when I just clicked that preset I get parameter values that we suggest to use for local testing so having dragged my dot IO file in having clicked that preset I then click the and at the bottom create roll-up chain and and now I've made an arbitral roll-up chain this calls an on chain contract called the arbitral chain Factory and it launches your chain your chain is now up and running as an arbitral chain okay let me now stop and go under the hood and talk a little bit about what is actually happening while your arbitration is running I apologize for the flickering so down at the bottom you have the arbitral in running your l2 chain there are two theorem contracts that are involved there's the arbitral inbox contract and your chains are broil up contract the inbox contract is responsible for intake whenever a client makes a call to your chain whether it's making a transaction call to one of your contracts depositing some eath or some tokens or something like that they do that by calling the inbox contract and the inbox contract manages those incoming calls keeps a list of them and so on everything else needed to run your chain is done by your chains are Brawl up contract that keeps track of the state of your chain and it and it makes sure that everything is recorded and everything is going to execute correctly the workhorses of your of your arbiter and roll-up chain are validators validators are our pro a validator is a program that can run anywhere if you are the DAP developer you might run a validator or two you might use a validator as a service company we're talking to infrastructure providers about providing validation as a service and you should expect an interesting announcement along those lines very soon and any but anyone else who wants to function as a validator can do it they can download the source of the free source code from our website or they can download a docker image and run it just start it up and they will operate as a validator and the guarantee that we give is that as long as any one validator is honest the chain will execute correctly so more validators is only better that's just more people who would have to I'll be dishonest in order for something to go wrong so whoever starts up validators starts up those validators those volunteers are responsible for pushing the state of the chain forward and for calling each other out if some other validator is lying so the validators interact with those on chain contracts in the normal way every validator interacts with the inbox contract in order to they watch the inbox contract in order to see incoming requests and they interact with the ARB rollout protocol to do stuff that I'm going to show you in a few minutes to push the chain forward if you have a user who's operating with let's say a browser-based front-end using web 3 or ether zand our plugin the users sitting at their browser the user does a thing which cause in which your front-end wants to make a call what that what that does is that the users browser will then make a call to a transaction call message to the arbitrament box contract to deposit that transaction call into the inbox if there's a payment that goes along with it that will be recorded and everything else that you'd expect for a transaction call so the front end code and the users in the user software doesn't know that it's calling to an l2 contract and not to l1 the plug-in takes care of bridging that gap but what happens is then a TX call message gets sent to the arbitral inbox contract and it shows up in the Inbox the front end again also through the plugins which we write and provide interacts by remote procedure call with one or more validators in order to find out what's going on on the chain in order to ask for other things and to see events that happen on the chain so those are the pieces that are interacting and we provide the code for all of these things except of course the application specific parts of the front-end ok so let me talk about the inbox contract every Arbitron roll-up chain has an inbox which holds a sequence of messages from clients to the l2 contracts there are different message types a transaction call a token deposit stuff like that the messages are ordered in the inbox and they're time-stamped with the Chane block number when they arrived so that the L to contract can ask by calling an arbitral library when was this thing put in when was this thing submitted if it wants to the contents of these messages are posted on chain as call data so anyone who wants to see them such as a new validator who comes along can see them the on chain Inbox contract doesn't actually store this stuff it just maintains a hash accumulator of the inbox contents that's enough for it to validate claims that other people make later about that certain things were in the inbox and so the the work that this inbox contract has to do is quite is quite small the way that the rest of the operation of the chain or at least the link to the l1 chain is done by the ARB roll up contract of which there's one especially as separate one for each of your each of your chains so the way that the system makes progress here is through what we call assertions which other similar systems might call a roll-up block the idea is any validator can post on chain an assertion this is a claim about what the chain did or what the chain will do which is really a claim about what the contracts in the chain will do that assertion involves the the chain consuming some messages from the head of the inbox those are say the transaction calls that are going to get executed by the contracts during that assertion it says that the contracts execute some number of steps of computation in the chains virtual machine it says it updates the chains root state hash the entire state of the chain is represented as a giant Merkle tree and so there's a root hash which is a commitment to the entire state of the chain and the and that's part of the assertion what is the state hash after this computation has happened and then also some outputs that were produced by the contracts things like log items and payments that that that were made so all that stuff is asserted on chain and the arbiter protocol is going to decide whether to accept that is valid and confirm it or whether to reject it so how does that accept or reject work in order to get into that I need to talk a little bit about some of the data structures inside the operation of the chain in particular this thing we call the state tree so here we have a state in the history of an oven our Bertram roll-up chain each of these boxes represents a particular state in the history of the chain and all of this history is confirmed which means it's final it definitely happened the chain has decided it's accepted and so the chain keeps track of the latest confirmed State or actually just the hash of it now at some point a validator Alice might decide to make an assertion a claim that the next thing the chain will do is whatever when Alice makes an assertion basically that Forks the tree it Forks the the possible future histories there's one future state if that assertion is accepted and another one if it's rejected and the system is going to decide which of those boxes to move to now when Alice makes that assertion she's required to stake on the note at the top there and when when she stakes on the node she is saying that she is putting her money behind the claim that that state is correct if that state is eventually confirmed she'll get her stake back if it's rejected she'll lose her stake so she has money at stake in doing this now when Alice makes this assertion she's claiming this date will be confirmed a timer starts and this is the period in which other validators have to check the check out Alice's assertion and to challenge it if they think it's wrong okay so now Bob might come along he might also stake on that outcome he's allowed to do that he's putting his money where his mouth is he wants to make sure that Alice's assertion gets accepted now if you have a situation like this and the timer expires the deadline has passed everyone is staked on the upper branch and so the system says nobody disagrees they've had their debt they've had their time out in which to disagree and so that upper branch will be confirmed but the other thing that could happen is some malicious or or confuse validator might come along before the deadline at stake on the bottom branch now you have a dispute now Alice and the and the malicious validator get into a dispute and the arbiter of dispute resolution protocol will be triggered and the dispute resolution protocol will efficiently figure out whether Alice is lying or the malicious a validator is lying in this case alice is telling the truth so Alice will win the dispute when Alice wins the dispute the malicious guy's stake is taken half of it is given to Alice half is burned the malicious guy is kicked out and now you have a situation like this and now the system is happy to accept the top node because there's no dispute anymore so if there is a dispute the people will fight it out cage match style somebody will be left standing if you are correct you can always win these disputes and so you can force acceptance of the correct branch okay the other thing you need to know is that in order to make this fast we allow pipelining what that means is that while Alice's assertion is still under consideration Bob can come along and make a claim about what comes next building on top of Alice's node he has to stake on that of course you always have to stake on your assertion so now notice that Bob is staking on his claim but he's also implicitly staking on Alice's claim because if Alice's box is not accepted then bob's definitely won't be and he'll definitely lose his stake so bob is taking on both of those Alice might then make yet another branch like this and this is what it typically looks like actually in operation the tree typically looks like this so this pipelining allows the system to keep going so you don't have to stop the world and wait for the timeouts whenever there's the possibility whenever you need to wait to find out whether somebody will dispute something this ensures the chain can go at full speed no matter what okay so we can make progress even if the deadlines are long even if there are disputes we keep making progress the honest validators can always keep building out the correct branch dishonest validators are going to lose their stake whatever they've built will be pruned away and progress will continue now you might think all of these nodes and branching and stickers and so on are expensive to track on chain but there are tricks for reducing how much we have to store turns out the on chain contract just needs to keep track of the hash of the latest confirmed state the hash of every leaf of the tree in that previous diagram there were four of those and also for each stake or who thus taker is and the hash of the state they're staked on that's all that needs to be tracked so that's actually pretty small the rest of it can be proven or checked as necessary from those hashes when there's a dispute there's a separate contract that's spawned for that when needed we don't worry too much about the cost of that because who the malicious party is going to lose a giant stake and that is gonna pay for dealing with that contract now dispute resolution is very efficient it uses a bisection based protocol if you've seen past Arbitron talks you've probably seen stuff about that so this protocol gives you some really nice properties it gives you trustless correctness and progress trustless correctness means that if any one validator is honest the system will never will never go wrong any one honest party can stake on the correct outcome they can win every dispute kill off everybody who's wrong and take their stakes and then the correct thing will survive so any one honest validator and that can be you if you're concerned about it can ensure correctness also trustless progress malicious parties cannot stop progress they can't stop the building out of the correct chain they can't stop themselves from getting killed off in disputes and so they can't stop the confirmation of correct nodes so any one honest guy can force progress we also provide trustless finality so most of the state's updates that are made are going to be confirmed as soon as their deadline is reached if nobody's malicious that's what's going to happen we expect the deadlines in production to be measured in hours if there's a dispute the confirmation of that node has to wait for a multi round dispute protocol so the withdrawals at that point might be delayed for a day or two but the chain still makes progress and as soon as the dispute is cleared the chain will catch up you'll be able to confirm all the things that we're waiting on that just you we also provide the trustless finality guarantee which it if an honest taker is staked on some future state that future state definitely will be confirmed eventually that means that if you want to borrow against a withdrawal that you know will be confirmed eventually you can borrow from that honest taker or if you stake on a future where your withdrawal is recognized you know that withdrawal will happen and that's also really important guarantee so people can provide early guarantees of finality early payout or advancing of funds against withdrawals because they can force those withdrawals to definitely happen so the summary here the roll-up protocol moves computation and storage off chain the design is optimized for a high speed limit we provide trustless Li correctness progress and finality there's tooling for easily supporting solidity DAPs and standard front ends we have tooling for launching chains moving ethan tokens in and out and so on okay so you can try this today it's on beta it's running on test net and if you go to our developer at off chain labs comm you can see all of our documentation okay now let me show you a demo and I'm not going to do the demo live because live demos and 15 second block times do not go well together so I'm going to show you screen shots we took a few minutes ago upstairs okay so this is the arbitrament Oken bridge and so you can launch this UI for any for any arbitrary chain and you can see what it has in it it has tabs for ithi RC 20 and ER c 721 you can put in here I've put in some ER C 20 token which I want to deposit into the chain I can do the standard operations approve deposit into the into the chain I can withdraw from my account on the chain through this UI and I can when I withdraw it goes into a lockbox and I can then do another another click to riff draw from the on chain lock box so all of this is provided for every chain and because these things are put in the inbox and the inbox is guaranteed to be processed in order your withdrawal will be processed in order that's true for every chain by design okay so I can do this I can deposit into it into the into my demo chain a some eath and an e rc 20 token or two now I can launch my my my demo tap this is unit swap running on our Bertram roll-up we have it running upstairs and this is these are screenshots we took a few minutes ago so we launched this thing unit swap running on on our Bertram roll-up I previously deposited into this chain some ethan some ERC 20 and i can go through this standard unit swap front end this is this is an open-source front end that that we got online so for example I can create an eunice WAP exchange by by filling out the normal forms it gives me I put in the address of the ERC 20 token I want to use click the Create exchange button and I can go on with write so I can create that exchange and I can go on with the other steps I create the exchange I can put liquidity in I can I could put in liquidity in the form of eath and the ERC 20 I can do transfers I can buy and sell in the Yunus whap in the unit swap contract if you want to see this running live come on up to our booth upstairs off chain Labs and this is an example of the kind of DAP you can run it took one of our developers a fraction of a day to get this working it was not a huge it was not a huge porting load you can talk to the guy who did it again upstairs if you want to know how it works so this is a demo that you can run real dabs that people actually care about as an l2 chain fairly easily so that is that is Arbitron roll-up I'd be happy to take any questions if we have time and until the emcee interrupts us I will take questions yes yeah how do we prevent nefarious validators from front-running by publishing to the main chain when clients make a call to the chain that call does not go through the validators that call is made directly to an on chain aetherium contract to the inbox contract the reason the inbox contract is there is so that clients can speak directly to the etherium chain to put their requests in and that those will be are guaranteed to be executed in order so there are people who confront run you on the etherium chain and we can't stop that but the validators are not in any special position to front run anybody they have to execute those calls in the order that they were put into the inbox and so the validators don't get the ability to reorder or anything like that that's that censorship resistance is a really important property and that's why we decided to have an on chain contract to process incoming calls just to recording phone calls oh so the question is can you see what's coming so here's the thing you as an observer know everything that the validators know about the state of the machine and what's in it's inbox and so if you wanted to follow along or if you want to be a validator you can do that you can keep exactly up to date you can you can even compute ahead and say well the next five things in the Inbox here's what they are I can figure out what the chain is what the contracts are going to do so the validators have no advantage over Joe public in figuring out what's going to happen and so we don't think they're in an advantageous position to front-run yes so in the current implementation it's a per chain it is a per chain a parameter how much the stake is and all validators take the same amount there there are a bunch of ways in which you might want that to vary one way is you might want it to go up and down as they say the am number of funds deposited in the chain changes there's no fundamental reason we couldn't do that but we don't do that in the current version we also currently supports taking only in eath but we expect pretty soon two supports taking in year C 20s as well there's no fundamental reason not to do that the point of the stake is to is to deter bad behavior and as long as there is enough stuff of value that is staked and the other validators find that stuff to be a value so one of the right so people we want validators to fear losing their stake and we want validators to want to get into a dispute with the liar in order to take their stake right and so as long as it's something that the validators value then you can stake in it how big just one more question one more question so we just launched in beta earlier this week and the road to main that is addition of some features probably nothing really major but the main the main factor is security due diligence before we tell people you can trust your real money to this we need to do more security due diligence and that'll take as long as it takes it's yeah we think it's measured in months [Music] you [Music]