The Future of Light Clients by Noah Citron | Devcon SEA

[Music] [Music] I'm Noah Citron I'm an engineer at a6z crypto and today we're going to be talking about the future of light clients so before we talk about the future let's talk a little bit about how light clients are going today um and the answer is it's pretty pretty good ethereum has multiple light clients by my ethereum has no less than seven and they make a wonderfully diverse set of choices they're written in different programming languages they have different dependency Stacks some of them have different mechanisms for verifying ethereum and they even Target different use cases ranging from end user verification to bridging but we do have a problem and that problem is that users are moving TT and while this is not necessarily a problem itself l2s are awesome they're giving us cheap and punful block space uh it is a problem because we have fewer options when it comes to L2 light clients but we would like to change that so before we go into how we're going to change that we need to sort of understand what a light client is and how do they work so first what's a light client well a like client is a piece of software that gives us higher confidence in what data on ethereum is it might not give us as high confidence as say running a full node but the thing that like clients give you is they are very easy to run you can even run them on your phones in the browser or really anywhere you can imagine they're very very lightweight but now let's talk a little bit about how light clients works so I have kind of a diagram here and it describes like a typical light client not all light clients uh might break up components in this way but this is kind of a good model for us to start with so as you can see the light client splits itself into a consensus layer and an execution layer this is kind of typical in all sorts of clients whether it's a light cine or a full node and the consensus layer's job is conceptually very simple the consens layer's job is to figure out what is the block header and then send it off to the execution layer it's conceptually simple but in practice quite difficult now the executions layer's job is to actually do something useful with those block headers uh I don't think I remember a time user has ever asked hey give me the block header that's not really particularly useful information but there's a bunch of useful information that can be inferred From the Block headers so the execution layer's job or some people call it the execution prover its job is to actually infer interesting information and ask and answer questions of the user so let's go through a quick example um in this case it's me a user who wants to know my e balance so I sort of send over to the light client like hey what's my e balance what's the balance of Enron eth and it goes into execution layer and the execution layer says well I don't have Noah e balance but what it does have is the block header and what is inside a block or of the many things in a blocker there's the state rout and what the state root is is it's the Merkel root of the entire tree of All State on ethereum and what's great about these Merkel trees is that they're a sort of authenticated data structure which means that we get to be able to generate proofs about what's inside of them so the ex are going to ask some untrusted data source hey give me a proof of what nose balance is it can verify that proof and then you know it figured out it I really have one eth and it can send me back the answer and now I know exactly how much E I have it turns out you can do this sort of strategy for a bunch of things if you want to know your receipts there's a receipt route so you can prove receipt inclusion if you want to know a transaction there's a transactions route we can even sort of simulate eth calls by running a local evm and fetching State using proofs as needed but we've kind of viewed this consensus layer portion as a black box it just verifies headers but how does this work so on ethereum layer one we use the AL light client sync protocol and this uses the trust in the ethereum valers signing block headers so the way this tends to work is that ethereum has this thing called the sync committee which is a set of 52 validators that are elected for a 27-hour period to just sign blocks and and if you have if you know who the syn Committees are you can see their signature and kind of have a good understanding of what's happening on ethereum and then there's a little bit of machinary on how do you update your Sy Comm committee every 27 hours uh but we'll skip that uh but now let's go to the L2 how how will an L2 like client consensus work well the valuers can't help us l2s don't have validators they use ethereum and the ethereum validators don't necessarily have particularly good understanding of what's happening in an L2 which means we need to figure out something new and that's pretty much what we're going to be talking about today so before we kind of go into okay how do we build these L2 consensus layers or L2 light client consensus layers we need a model of l2s so in our model of l2s we're going to sort of think about blocks and a block has two kind of components it has block inputs and block outputs we can view these as like the inputs to the state transition function and then the outputs that are derived from running the state transition function and generally you know the block inputs are the transactions and the block outputs are things like the state route the receipt Roots the transactions route these are things that normally go in the block header so we think of a rollup being a thing that puts its L2 block inputs inside of ethereum blob data and ethereum blobs data's job is to sort of make sure that once it's in there it stays and it doesn't get sort of reordered and then we have our L2 block outputs which are really our block headers and we in a rollup we generally have these Bridges and the bridges job is to use some system either a snark a dispute game or something else and to derive the block outputs the block headers from the inputs so in our for our purposes we're going to make this model a little bit more generic and we're going to replace sort of ethereum with an irreversible Gadget and the snarks with oity Gadget now let's quickly Define these so an irreversi Gadget convinces a verifier about what the L2 block input data is and a validity Gadget convinces a verifier about what the lp block output data is given a given L2 block input example of an irreversible Gadget is uh the data posted to ethereum and checking it via the existing ethereum light client and an example of a validity Gadget is a snark that implements State transition function so once we have these gadgets we can actually Implement sort of a generic view of an L2 light client and in this example here we have the light client and the irreversible Gadget and the Gadget the light client starts by saying hey reversible Gadget uh convince me what the block inputs are and the IT receives the block inputs a proof it checks the proof and now it knows the inputs so next it talks to vality gadget says Hey vality Gadget convince me of what the block outputs are and it you know it sends the the V Gadget sort of figures out the block outputs generates a proof and sends it over the light client verifies it and now we know the block outputs the block headers and we've kind of done our job so to understand is security of this really the security of breaking our light client is the security or the minimum of the security of our irreversibly Gadget and our validity Gadget but let's let's now instantiate a light client so our to instantiate it we're going to use for our R Gadget the ethereum alter light client so we're to syn a light client and read data off of ethereum and now we know the block inputs for our validity Gadget we're going to use a snark it could potentially be a snark implemented by the bridge and uh yeah now when we ex to Smart we have an L2 light client but we have one big problem here and that problem is latency so roll up T to post data to L1 only every couple minutes and on top of it take some extra time to finaly and snark generation today is slow hopefully in the future it won't be um but this means that our light client runs way too far behind the tip of the chain so what are we going to do about that well we are going to invoke the light client superpower and the light client superpower is to balance security with Laden scene performance so now we need to do something we need to choose irreversibly gadgets and validity gadgets that offer lesser security guarantees but uh lower latency and higher performance and we do this it means that we can pick any reversible Gadget in any validity Gadget that we can come up with and we have an L2 light client and we can make these choices so that they are best for a given use case okay so now we're going to talk about some irreversi gadgets these gadgets are kind of hard because the l2s need to implement them themselves because you know right now the sequencers have the full right to decide what gets put on ethereum and we can't force them to do anything but the L2 twos can build mechanisms that will force them to commit to what they're going to put on ethereum earlier so we've already talked about ethereum finality as a uh irreversible Gadget but we also have three others that we're going to discuss so the first one's very simple it's a sequencer commitment what this is is we have the sequencer receives the blocks inputs it might just be generating the block inputs itself and it's going to sign them and then once it signs the block inputs it sends them off to the light client and the light client assumes that they're valid and that's it light client just trusts the sequence it's not a very good uh but it's a good start it's a good first start so our latency is very low really the only hot path we have is signing um but our security is also very low it's just as secure as trusting the sequencer what's nice about this design is that most l2s already implement this today as part of their sequence or pre-confirmation um so we kind of get it for free now I think we can do a little bit better and we can add some economics this we can Bond the sequencer to their responses so in this case it's kind of the same as before but we have the sequencer to start by bonding some assets on L1 and then they act kind of the same they sign block inputs and send it off to light clients and the light clients accept that's valid Additionally the light client might want to run an L1 light client to sort of check up on the bond and say is is the bond big enough and we add sort of an extra entity here which is the Watchers Watchers are just sort of a group masquerading as light clients and they also ask the sequencer to sign block inputs but what they're doing is they also are running full nodes and they are trying to figure out is the sequencer being honest right they're going to watch L1 and see is the sequencer actually going to post the data on L1 that they say that they're going to post and if they don't they sort of present previously signed inputs that conflict with what the sequencer put on L1 and it will slash the sequencer so this is much better the latency is still very good our hot path is just signing um and the security is better and we could scale it kind of as much as we want just by increasing the bond so let's go a little bit further and talk about one last irreversibly Gadget which is a fast finality committee now in this model we have the sequencer sending block inputs off to a committee of end nodes and what this committee's job is is to agree on what the sequence are said so it does a little bit of consensus and it generates something called a quorum certificate which is essentially a little proof that they did consensus correctly and then they send a Corum certificate off to light client the light client verifies that the fast final committee really agreed on what the sequencer said and if it did the light client accepts the the inputs as valid now what's we also have to make one change kind of to howy rollups post their data to ethereum and it's that you change kind of the validity of the r the rollup validity rules to say that some block inputs are only valid if they come with a quorum certificate that the fast finality committee saw it now for latency uh it's still pretty good uh we know how to build uh relatively fast consensus mechanisms as long as n is not too big and for uh for security it's it's reasonable right it turns out that we can we can even scale our security so right now the security is that as long as at least uh or less than one third are malicious we should be good um but we can also add sort of bonds to the system and ensure that the fast fality is staked and if they act maliciously we can submit evidence to this onto L1 and slash them and what's really cool about this is that there are sort of some traditional issues with slashing a consens or operators of a consensus mechanism when more than two-thirds are malicious but since we can do the slashing on ethereum L1 we get around that completely completely and we are able to tolerate greater than than even two-thirds malicious and still slash them even though the light client will be deceived so okay vets are irreversible gadgets so now we're we have a sort of good set of options for how do we figure out what the block inputs are at least how do we figure it out faster than just waiting for it to land on ethereum but we need a couple mechanisms to talk about how given those inputs how do we know the outputs so we've already talked about snarks but we have kind of four other ideas for what we could do and the first one is sequencer commments this is basically the same as what we talked about in the sequencer commitment version of the irreversibly gadget but in this rather the SE squencer sort of receives some block inputs it executes them and then only once it's executed it sort of it signs the input comma header tupal and then sends that signed uh signed tupal over to light client the light client checks that it is the inputs it expects and then trust the headers as valid now for latency still very good the hot path is really just signing we will probably execute eagerly so we don't actually have to wait for that um and the security though much like before is not so good what's nice about it though is like before uh sequencer pre-confirmation implemented by most l2s today give us this for free but we can do better we can do sort of the same strategy we did before let's add economics into the situation so in this we can have a bonder who Bonds on L1 and in this case the bonder doesn't need to be a sequencer it can be anyone and the light client will send over some block inputs that it had received from its irreversibly Gadget and ask the the bonder to execute it they execute it derive the block headers and then send sort of assigned input header tupal and then when the when the light client sees it they just accept it as valid now again we have watchers the Watchers are either Mas grading as light clients or maybe just receiving these tupal from the light clients themselves and they run full nodes and if they notice that the what the bond is saying the output is is different than what they see it as they will generate a snark that executes the inputs and proves that it's not the same blocker now this snark can be executed slowly we don't have to worry about doing this very quickly it can maybe take a data generate doesn't matter we just need to be able to eventually generate it and then we can present the snark as as well as the bonder or signature that shows it's different and Slash the sequencer so latency this again still very good uh we the hot path is just signing and uh the security of it is also okay because because we can scale security as high as we want by just increasing the bond you can even imagine uh asking for many bonders what their position is and now you can kind of aggregate the security through multiple people rather than just requiring only the sequencer to be able to bond but uh I think there are other some other interesting sort of parts of the design space so next we're going to talk about uh just using tees so in this case uh it's really simple the light client sends over the block inputs te EX them and then signs them but the one additional thing they do is they send uh te at to station uh te at station is a special thing that a uh te can do to kind of convince someone what kind of code is running on it and the like client sort of receives the signature checks that it's valid receives the attestation checks that the te really is running the code they say they're running they're hopefully running the code that executes the state transition function and V it accepts it as valid the latency B is very good um the security of it um we don't know uh lots of people have opinions on how secur tees are but what my belief is is that however Securities are today they're certainly going to get more secure in the future which means that this is maybe maybe a good part of the design space and we we talk about one final validity Gadget this one is actually my favorite so this is offchain dispute games so an offchain dispute game is going to function a lot like a traditional dispute game that we see optimist rollups do with the one major difference being that an optimistic rollup does its dispute game through the layer one so you have all of these players who are arguing about what you know the output is and they play their moves on an L1 smart contract and the problem with this is that you have to assume worst cased inclusion times for every move in the game which means it plays extremely slowly most dispute games take at least a week to or have a weekl Long window to be played when you're playing a through1 now what's cool about an offchain dispute game is that for our like client we can simply connect to multiple servers we have no idea how many of them are malicious even the majority can be malicious we're hoping just one is honest and we can have them send us hey what's the block header given these inputs they all send over the block header and if they all agree you say perfect uh you know life is good we're going to accept it now if one or more disagree we make them play a dispute game but we make them play a dispute game not on L1 we make them play a dispute game through the light client all the moves get played in the light client now the light client certainly does doesn't want to censor to players so we have relatively good guarantees that all of these players are able to make their moves in a timely fashion which means we can run the game very very quickly um so the latency of this is okay um if we assume the happy case that uh they all agree the latency is fast if we assume the case that a dispute is going to happen the latency is less fast even though we don't have this horrible latency that a onchain dispute game has we still have uh a little bit of latency because each of these players do need to do a lot of computations uh but modern kind of dispute game uh provs are getting better and better at doing this um and for security I think it's really fantastic because we have what's called existential honesty which means as long as you're connected to just one honest player you're guaranteed to get the correct output another thing that's good about this design is once we identify sort of the set of players we're connected to that are bad you know we we pick maybe 10 20 people to connect to hopefully some people have maybe some reputation and the second we see one has lost a dispute game well we kick him out we never ask him again so it it it it means that we can use this mechanism to keep a kind of set of very reasonable players to to ask uh to work with so now with these uh irreversible gadgets and validity gadgets done we get this really nice light client security latency trade-off Matrix for LTS so we have all of these reversible gadgets and all of these validity gadgets and you get to pick one from each and design a light client that works for your use case so to recap we have a new way of thinking about L2 light clients and to build better L2 like clients we just need better reversible gadgets and better vity gadgets so what are we doing with filos uh we want to implement all the LTS and all the gadgets so Helios now supports the op stack uh uses sequencer commitments for both irreversi and validity um and what's next we're going to add more l2s more validity gadgets and more reversa gadgets so if you want to help uh reach out to me on telegram here's my telegram here uh we'd love to help work together and build the future of light clients thank you all right thank you so much Noah we have some very sophistic questions here um I'm happy to go through them and ask you so what incentives have regular nodes for serving all these light nodes right now they are minorities so this doesn't matter but what happens when light nodes start to flating normal nodes yes that's a awesome question so there are kind of a bunch of different designs for how a light client gets data um and sort of the two popular ones are one a peer-to-peer network uh good example is the portal Network who's doing great work uh and in this case it's kind of hard right you're hoping they sort of altruistically serve data and you know maybe that works maybe that doesn't we'll have to see um but there are other options right an option that Helios uses and Helios to like C I work on is we sort of implement the RPC proxy architecture where we connect directly to a traditional RPC and we use that to fetch the data we need but we do it in a very special way we're using lots of eth underscore get proof uh calls and this means we have like like clients have like a direct business relationship with who they're getting data from uh but they don't have to trust that person they just need to make sure that person actually responds to them so we do have kind of a bit of a spectrum here and hopefully the peer-to-peer Network stuff works I really really hope that we can do it that way but we also have these RPC proxy designs okay thank you so much um then is there any small protocol changes rops could do to improve the trade-off between security and latency for rollup light clients yes great question so for validity gadgets we can just make them as we see fit you know we can spin up tees we can you know Bond but for irreversible gadu it's much harder this is because while the wild the sequencer hasn't posted the data back to L1 we have no good way of knowing what they'll post we we just have to hope they tell us the truth so L2 teams it would be awesome if they think about building these sort of fast finality committees or start bonding to what they say they're going to post and if we do that we end up in a very very nice world because we have more we can we can work with um additionally there are some changes that like L1 could do you know we heard Justin talk about the beam chain which includes fast finality and lower slot times and if we have fast finality and lower slot times we can do techniques like based sequencing and just have um the l2s poster batches every block and in this world we get you know basically the most secure possible irreversibly Gadget ethereum um with low latency which I I think is probably the end game but it's going to be a little while all right next question um oh I have different ones what would be the economic incentive for a bonder yeah it's a little weird right because once if you Bond once you sort of sign a uh a message like I can't prevent someone from forwarding that message off so it mean it's like this data market problem where it's hard to keep that signed message secure or hidden uh later so it's very hard to make it that you pay for the bond um there may be sort of these like Insurance style designs where when you get when the bond gets slash maybe half of their assets are burned but the other half can be given to the wronged parties and in that case the wrong party is like a you know one of these light clients and they could pay directly for it um and then in this case we actually have like kind of a direct relationship where the light client is paying not just for the signed message but really for the insurance when something goes wrong um and this this gives the relatively nice economic design okay and this one is nice um when we achieve stateless clients on ethereum will light clients become obsolete assuming 99.99% internet uptime in the Future No Light clients become better so there are two types of stateless clients I guess uh one is like a stateless executing client where we can just execute all of the transactions locally but you know they have witnesses to or to all the state that they touch and doing that is still going to be hard you're not going to be able to do it on a phone or on you know other potentially really lightweight Hardware so we'll still need light clients now in this like future beam world where we've snarked everything we still need light clients because you know the consensus layer is very simple the consensus layer is grab the proof and verify it which would be awesome I I hope we do that but we still need to build these execution provs we still need to have strategies for how to uh how to fetch data and sort of coordinate all those proofs so we'll absolutely still need light cents and I think you know stess clients are going to make like clients even better all right