Kicking Our Infura Addiction: A Quick-Launch Client by Jason Carver (Devcon5)

so welcome we are here to talk about in Fuhrer how we're hooked on it and what we're gonna do about it my name is Jason Carver I work at the ethereum foundation on all sorts of Python tooling as well as the Trinity Python client let's get started so why are we hooked to in fear obviously it's delicious it is an obvious thing for DAP developers to make it as easy as possible for new people to sign up and use their app and similarly plugins like meta masks ignosi and so on or have the same incentives right so in fury is a way to skip the install of the node skip the sinking of the node and get people on board fairly obvious setup why that's easier and more pleasant for a lot of users and frankly for a lot of casual users you know 80 to 90 percent of people they're always gonna minimize effort they're they're very willing to make trade-offs about trust and custodianship to to make it easy but there is a set of users that were interested in the sophisticated users whether that's hobbyists or people writing scripts to interact with the chain and they're willing to do more they're willing to put in some more effort so the problem is when they try that they go out and look for documentation they look for help in the apps and they don't find anything it's all built for that 80% user and so they just skip over it and and they often don't have any trigger or later to switch over to something different so maybe that's okay you know how how bad is that what how bigger problem is that well you know there's some obvious ones like concerns about downtime you know in fear is gonna be a single point of failure and no matter how good their systems are and they're very good perhaps the worst is that in fear makes a bad hire or someone cracks into their systems and they serve you bad data now they can't explicitly directly say send your funds from one account to another or your assets but if they can control the view of the world you have it is pretty straightforward to get you to send funds or assets to the whatever address they choose for example by resolving an ENS name to a different address than the real main that one and some other things like leaking private data everything about who you are and what you're doing is going out - - and Fuhrer and the other Absalon way and slightly more subtly the more the more people the fewer people that are running nodes the easier it is to spin up other nodes and do slight manipulations like eclipse attacks so it's here it's a problem what are we gonna do about it well there's a lot of different avenues to approach this with and there is dedicated hardware like DAP node or good plus there's people looking at the problem of how much storage it takes to to use on your computer there's people looking at peer discovery and the thing that we've found to be one of the biggest pain points is just the amount of time that it takes to sink from a fresh start you know these sophisticated users who are willing to try something out there hobbyist they like to tinker but they'll start up a node and try to sink it and two hours later have no indication about how far they are into that sink and say screw it flip it off and go do something else that's more fun to tinker with so we want to fix that problem the the reigning speed champion is guess fast sink that's the the one to beat that's about four hours according to their latest benchmarks so you know even is gonna be a problem for for these users and so we want to take a look at that and see how much better can we do and part of the reason we're asking that question is if we directly implement fast sync we're gonna do a lot worse because python is never gonna match or beat go and a head-to-head performance race so we zoom in too fast sync and we say we look at what parts are taking most of the time and the majority of that is downloading state ok there's things like downloading the headers downloading receipts but downloading the state of a recent block which includes all the things like accounts and storage for contracts that's the vast majority so what are we gonna do it's time to upgrade our sync process so this next generation of sync we're calling beam sync and the the ability it gives us is go from an empty node no data to executing a recent main net block in minutes asterisk with just in time state downloads that's the main concept behind it so asterisk I don't want to lie to you it takes longer than that right now because you have to find peers and that's unreasonably difficult right now and header imports can take a while unless you use a checkpoint which has its own interesting side tracks we will get back to those things but we're not we're considering that out of scope for beam synchrony so high level how does beam sync work roughly we combine the ideas of the way that fast sync works and the way that stateless clients work so stateless client gets all the data I mean just the data it means to run and block and it dumps it at the end of the block fast sync is about getting all of the data all up front and save it to disk so instead beam sync works by running a VM on an empty state pulling the data as it's needed but saving it and storing it for future executions so what kind of effect does that have well there are about 375 million try notes in the main that state database and there are roughly three to four thousand try nodes that are used per block so that's about one one hundred thousandth of the amount of data you need for just one block versus for everything in the state and this works out to about 250 times fewer requests on the network before the first block can run and we'll get into those numbers a little bit more later so we are approaching halfway through and obviously only great blaze raced over beam sync so I've got a talk or a post here rather on medium that goes into a bit more detail compares it to fasting and all that so I'll give people a second to grab that link and also I'm gonna be posting further beam sync updates as well as talking about how it impacts the whole network over time so feel free to follow up me there to find out more and while people are getting their last shot of that you may have noticed kind of a discrepancy in the numbers on the last slide if there's a hundred thousandth of the data then why is it only 250 times fewer requests excellent question so fast sync gets to batch together it's try node requests into 340 no 384 nodes per request so beam sync as implemented now can only request a single node per request and because the latency the actual time that the packet is round-tripping between you and your peer makes up the majority of the time you lose a factor of 384 okay so we're about to do a deep dive I'm sorry for the folks that I might lose it requires a little bit of understanding about EVM and the way that that tries work I'm not gonna have time to get back out on it so I'm sorry for everyone else I hope you have fun so what I'm gonna do here is I'm going to paint a big picture of kind of how it works but I'm gonna put it on the slide bit by bit so that we can kind of stitch it together the understanding so the idea here is we're going to jump into a VM code execution this isn't the way it really works but it it gets the point across so let's say we have a push 20 opcode we're gonna push an address onto the stack that doesn't take that didn't require any state that was just in the the byte code so even though our state database is empty we can continue on okay but the next opcode asks for the balance of that address so now the VM has to check the state database which is empty and and try to extract that balance now all we know at this point all the node knows at this point is the hash of the root of the Tri so that is we're gonna call that F here a dot and that's that's all we've got so what are we gonna do how are we gonna get the balance we're gonna find a friendly Pierre and we'll ask it hey Pierre do you know what the node is that has the hash chef this command is the exact same command that fast Inc uses right so we're picking backing on this we don't require any new network protocols to make them sync happen so we say Pierre give us can you give us F and they say sure the node F has children and B so what does that mean it means that the hashes of the children of note F are a and B you know I'm lying to a little bit here pretending this is a binary tree or other than a modified Patricia Merkle tree still gets a point across so we got a and B back and we store it in my database so here's what our local try it looks like now we've got two children we don't know what are inside them we have the root now and what happens at this point now we're looking for the balance of a particular address and we know which address we're looking for so we don't have to fill out the whole tree we can just follow the path to the address we want so let's say the path takes us down down a and so we want to know what the children they are so we ask our peer hey what's what are the children of a it says the children are D and E we save that into our database okay so now we're starting to build just a few pieces that are necessary to get at the balance of the address that we care about and so we do the same thing again where we know a particular address that we're looking for the balance for let's say it's down you're meant to follow it down the path to e and we ask our peer and they say hey e is actually a leaf node it contains the ROP of the account and which includes things like the balance that you're interested in so we save that in in the state database so now we've got three nodes in the state database that's enough to not only know the balance but prove that that balance is part of the state route from the previous block and so at this point we can read the balance out of that leaf node and push it onto the stack and continue resume going down the EBM so let's say you know the the byte code wants to know if the balance was non-empty so this is the gist of it you can see you know later on it may be a different balances asked for again you'd be asking for nodes one by one you get to skip the root node next time but you know the same concept applies similarly this is showing you know three layers the real mean that's closer to six or seven probably at this point depending on you know where the accounts so how long does that take so let's say there are 3000 nodes per block and we only get to request one node in each request and we're connected to peers but we can only ask one peer at a time so we get to ask our best peer we get the one that in this case best means we're closest to that'll round-trip fastest so let's say that our best peer is 100 milliseconds away so you work that all out you get 300 seconds of time waiting for state for a block and that kind of sounds like a problem you can imagine if it takes five minutes to download the state for a block then you're gonna lag behind than that and then as you process the next block you're gonna lag further that would not be tenable but the good news is we don't have to wait for the first block to finish before we start executing the second one so what ends up happening is you continue to run these all in parallel and and you catch up along the way but you know maybe stay perpetual in five minutes behind main that in reality it might look something more like fluctuating between fifteen minutes behind and one minute behind depending on the blocks that you're running into and your peers okay so at this point you know you're a few minute you've turned on your node you're five minutes in maybe some more minutes for a pure discovery and headers and you've got main net blocks executing on your local node this is already a way better experience than four hours or sometimes days to run fast sync but it's not good enough so how can we do better one of the things we can do is to find out from our peers which nodes which try nodes are going to be needed in a block right so we're gonna call that the block Witness metadata where the witness is all the state needed to execute the block and the metadata is just the hashes of the state that's needed to execute the block so what that allows us to do is match up the requests again into 384 nodes per request and it allows us to spread those requests across multiple Pierce so a quick look this is going to look very similar to the past one so we'll go through a little bit faster of what that might look like so push an address on to the stack ask for its balance hit the empty state database all we know is the root hash find a peer to help us out and now instead of asking for that root node what we do is we get a witness really I'd probably call it witness metadata or something and we know which block we're on of course so we can say hey Pierre can you tell us which hashes we're gonna need for block G you say sure we're gonna need FA and E from last time so you know at this point we actually can't store anything in the database we just have a bunch of keys we don't have any key value pairs and in fact we don't know how these stitch together all we really know is F so at the root but we can use it to now make the next requests so we can match them together put them in a single request we can send it to a different peer we can send it to we can split it up and send it to a bunch of different peers we have a lot of options and so we get back essentially all the data that that was requested in the previous slide so we know F has children a and B a has children D and E and E is the account ROP so we save it into the database that's enough we can look up and prove the account balance and push it onto the stack and then ask follow-up questions like is that balance zero which is you know a stateless call okay so how much does that help us well let's run some numbers so let's say again 3000 try nodes per block rough number and but this time we get to group it into 384 at a time and you know we're again assuming and this looks about right from empirical test that most of the time spent is latency we get to group it up and we get to also split it up so we get to send these requests to let's say four different peers at at once and now that we're sending it to more than our best peer you know maybe the average round-trip time actually goes up you know that we have to rely on some peers that are a little further away and so maybe each peer takes 500 milliseconds to round-trip and so all of that throw it into you know throw some arithmetic at it and you get one second of time waiting on try note requests so this is a prediction all right the other one is is known but this is a fairly straightforward extension that we're looking at that would be pretty much the whole game right if you can download all the state in one second for a block you can keep up with me and that quite easily from the beginning of launching an empty node so how close are we well v-0 is prototyped in Trinity alpha the that works on main net right now so we have executed many main networks over and over and you know generated local witnesses that kind of thing but it's not production ready you know it's this is meant for experimentation right now but there's nothing left to research there's no there's no open questions really on on d0 and how it works just more coding to do now the witness metadata surveying is in its design phase right so we have ideas about how to do that that's gonna be coming up next right after DEFCON you know follow us to see how that progresses and people sometimes ask the question well why hasn't anyone done this before and the answer is that no one had to you know we were forced to do it because python is slow so we had to ask these questions there was a chicken in the egg problem with why why we can't couldn't use witnesses right away and v-0 because there were no serve servers of those witnesses and so Trinity can't serve them until it sinks so we're gonna boot strap with v-0 in order to sync v1 so that's it we're we're doing this now we're talking to other clients to get it done for them it's a great thing about working at the foundation is we get to share all the fun toys that we make up and we're we're cranking away so follow us and see what's new it looks like we don't have time for questions but you can find me on the side or in the hall I'm happy to talk thanks for your time [Applause]