Introduction to Weiroll - Nick Johnson - [Toronto Ethereum Developers Meetup]

Transcript

so uh wayroll is another side project that i've been working on uh with uh dean eigenman uh and matthew deferenti uh and the basic idea is that there are a bunch of solutions around for batching operations uh in order to turn multiple operations into a single atomic transaction and so for instance there is instadap there is a defy saver and there are a few other systems that are similar at the very basic end of things we have things like um multi-core which allow you to just batch multiple operations but don't support data dependencies between them existing systems like this tend to

have some significant weaknesses either they use oodles of gas because they rely on things like uh contract storage for passing data between operations like uh instadap does uh or they have limitations on their flexibility and that there's only certain ways you can pass stuff between things like named slots and only a single return value uh or they uh have very complex architectures like uh i i believe um defy savers does with multiple different uh types that have to be sort of multiple different storage areas that have to be taken from and so forth so wayroll is our attempt at building an extremely straightforward vm

that can execute arbitrary chains of transactions and pass data between uh between them in a transparent fashion the basic idea is that the wayroll vm has and i really wish i had a diagram here uh has uh when you call the vm you pass in two things you pass it an array of commands and each command specifies a smart contract uh function to execute and you pass in an array of state values and each state value is a bytes so it's arbitrary length and it represents an argument or a return type for that command so the command specifies the uh the function selector um a

flag that that specifies uh what sort of call you're making whether it's a delegate call or a regular call and so forth and then a series of input values which are taken from the state in a single output state slot and finally the address that you're calling so what the vm does is it simply look it assembles the input arguments from the list of of state variables that were specified in in and then it calls the target address with the function selector and the compiled data and then writes the result to the output and this is sufficient to have arbitrary chaining of

functions with with complex arguments and so forth um this is much simpler than existing solutions which rely on say having input values and output values and also return values from previous things because we put everything in the single state array so as an example if you wanted to add two numbers uh your command would be a call to the add two numbers function uh your state would be the two input numbers and then your command word would say this is the add function uh the input arguments are first state slot in the second slate slot where the two numbers to add are and your output is either of those say the first state slot to overwrite the result to and in this way you can even uh for gas efficiency reuse existing state slots

uh in order to uh to save on on gas uh so in this is very straightforward but somewhat uh awkward to program for because you have to plan slot allocations and so on and so forth so we have written a planner in javascript called wayroll.js and the way this works is it provides a really easy way that you just create a series of smart contract calls in javascript and it handles how to actually turn that into a wayroll program so we have some example code here we uh starting here you you construct a new planner uh and then for each uh function you want to execute you take

the contract object which is basically like an ethers contract only wrapped in our own library and you just call a function on it with the arguments just like you would a normal web3 contract call and you pass the result of that planner.add and it adds it to the list of commands and then if that contract function has a return value you can capture it just like you would anything else and then pass it into another contract call later and the planner will detect that you use this return value and where you used it and then automatically make sure it allocates the state slots and the inputs correctly so that all the data gets routed correctly and then once you're done adding all of your functions

function calls you simply call planner.plan i hope people can make this out my text is probably a bit on the small side uh and planner.plan returns the list of commands and the state which you simply pass into the vm to execute so the idea is that using this uh to chain a series of commands into a single transaction should be as easy as simply doing it as if you were doing it with ethers.js or web3.js only at the end it generates the plan for you when you send only that in the actual transaction and that is the high level overview uh we are um we've written the whole thing uh the overhead

uh was i believe about 6k gas per command dispatch uh which is uh on my side but still significantly better than all the competing solutions uh we're currently in the midst of rewriting everything in um yule and we've saved about 30 gas writing at a new as opposed to uh solidity and fortunately because the vm is uh reasonably straightforward that's actually a practical thing to do without it getting insanely complicated uh so that'll bring it down to possibly as low as about 4000 gas per dispatch which is still higher than i would like but uh significantly better than what anyone else has achieved i believe this also incidentally supports what we

call sub plans so if you want to do flash loads for instance you can tell it go off and call the slash loan function and you can pass in the data necessary to instantiate a nested version of the wayroll planner then does stuff inside the flashlight and this is all supported transparently so that you don't have to deal with all the plumbing of connecting the two instances together yourself the the planner javascript library just handles it for you so that is the somewhat disorganized high level overview of wayroll any questions thank you so much for the impromptu uh second presentation there nick um um are there any any questions for nick

on either ens and layer two or wayro johnny i'm not sure if uh that clears things up for you i believe you can unmute yourself i can now hi nick um hi i have um two small questions one is what's your favorite l2 um and if you if you're if you're feel comfortable saying and then also this way roll thing how it's batching these um commands together can what what effect does that have on mev as far as hiding what's going to be happening some people can't figure out what's going on in the transaction that's being executed yep so in terms of favorite l2 uh optimism is by far the one i'm most

familiar with because i dug away into its internals to construct a demo for for during back before it was called jiren um and it seems well well conceived and so on um so it's kind of a de facto favorite rather than like i've carefully examined every single one we would love to work with them and and like potentially others as well to build like general purpose gateways for for jiren so that uh they can be used for enes and for a bunch of other stuff as well um in terms of way role uh batching um the the mev implications unfortunately aren't great because uh common uh sorry because uh the more sophisticated general purpose front

running bots don't just try front running the whole transaction from their account they actually try uh front-running individual contract calls so uh depending on how you structure your wayroll invocation they might be able to just like play your entire transaction and make whatever mev you were trying to extract with your your weigh roll program or they might identify that they can like replay some subset of that and do that automatically so unfortunately uh their ability to simulate just about anything makes it very difficult to evade this cool great uh thank you um johnny has just the comments yeah like

your your array way roll explanation was super clear um impressive ad hoc presentation like i'm impressed but you got it i'm glad um i'm particularly proud of the planner too so if people want to dig into us and play with us like i really like the fact that we've managed to completely separate the vm architecture which is straightforward but unintuitive from like a really obvious like very similar to ether's uh ux uh in in the browser cool yeah um anyone else have any questions and if not then we can uh oh thank you nick um thank you for popping

by and presenting um it's in the afternoon right now for you in new zealand isn't it uh just about yeah it's 20 past 12. i thought i thought it would have been like late at night for you oh johnny asks is weirdo live uh it's uh so the solidity version works but our testing is is on the lighting so i wouldn't recommend deploying its production uh the yule version is still uh in progress and and doesn't pass all the tests for the solidity version yet uh we we definitely need to spend more effort on uh unit tests and code coverage before we can like tell anybody that they would actually be well advised and giving it a go on a real network great um and also like i just forgot as

additional comment to your last answer that there's your call to action for the developers go go play and test with uh with ray roll and also ens um yeah please tell me yeah nick thank you thank you for stopping by i appreciate it appreciate your time thank you