New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Eth 2.0 Light Clients: How Light is Light? by Cayman Nava

DevconFri, Oct 9, 2020, 12:00 AM

Speaker

Cayman Nava

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more. https://archive.devcon.org/archive/watch/5/eth-20-light-clients-how-light-is-light Ethereum 2.0 has been designed from the ground up to be friendly for "light clients" - blockchain clients requiring vastly reduced computational resources that can easily be run in the browser, in embedded devices, and even inside other blockchains! We discuss how light clients work in Eth2.0, why light clients are lighter than full nodes, and get to the bottom of just how "light" these clients can be. Speaker(s): Greg Markou, Cayman Nava Skill level: intermediate Track: Consensus layer Keywords: technical Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum Learn more about devcon: https://www.devcon.org/ Learn more about ethereum: https://ethereum.org/ Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. Devcon 5 was held in Osaka, Japan on Oct 8 - 11, 2019. Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

Transcript

[Applause] any details when are you presenting even a cat lead solty how that goes good they're not know that was a thing until this conference so my clients giving to my clients how light is light they're really integral to the dream too we're going to see why they're integral what a life client is and we're trying to give you something like the thinking behind how I like fireworks and how to think about the light client Universal so brief introduction about their into developer at chain state systems a Twitter github might interact with me online and these are right profile links right now working on a project called lodestar we're building a type script during to ecosystem started with the beacon chain we're also building on a light client and we're going to be involved with helping with the developer tooling as well so trying to onboard a 31 developers to ecosystem we eat chat on this Court so anyone wants to talk to us were available there and also further allowing other relevant places and chain safe this is where I work it's a great group of guys and gals everyone's based out of Toronto mostly and we all work on a protocol level blockchain development they are all online so kind of up there labels really very people so this is already covering we're gonna start off with just what a light client is why we need my clients why we need them appearing to get like a sense of what that even like what is it like what is it what is the full note what does the light climb where does the light note it it's uh it's not it's probably pretty obvious but in theory the ones you haven't really been using that we we use a bureau we use meta mask uses and Bureau use either scan we're not really used to interacting with lifeline and said there's been a lot of research into making it more usable making it more like a default experience but we're going to need to start there too because of some reasons that I'll get into will go into some background about they don't know will kind of want to cover before we get into kind of meat of things is the actual light plan and how we are going to be sinking Ava so just some motivation what is the light client my client is software which is securely consumed blockchain data and it has requirements of scale logarithmically to the total watch-chain state so logarithmically you kind of think of like this kind of curve as like the blockchain grows and grows and grows the amount of data that you need to actually process as a like light you want that to not really change very much at all one way to think of it is like as like the total size grows exponentially then the total size that you need to verify things only into the doubles so let's say the the chain went from 1,000 pounds actions a day to a million transactions a day that would only require a doubling of where life I'm looking to process so why don't we need my clients for their area to there they're going to be first best citizens I think I like the new very vivid area so we think about some certain cases were we going to need them a resource constrained environment so I'm sure everyone here has a smartphone on them but who here has the has the chain sync telephone no one okay I mean it's probably why do you have that mask by your phone but minimum ask is all using in fear and here's a great service but not trying to diss it but you're kind of losing out on some of the guarantees that you gain when you're relying entirely on in the bureau one really interesting case for light clients especially in like this very burgeoning ecosystem of walk chance is to be able to have other block chains as light clients to your watching so when we all have varium - it would be really cool if the authority of one block chain was able to in some way validate the data of etherium - you can think of that as a no light client into a very dirty engine and so if we make things easy enough if we make things like small it up it becomes more practical to do that in more places another thing to consider is in etherion one it's really easy for everyone to get the whole state of the world and appearing to be are moving to the shard in architecture aware it's not actually going to be feasible for everyone to store all the data like even if you wanted to unless maybe you just ran out a bunch of servers on AWS like practically speaking most people aren't gonna store anything and even like even within just the protocol itself like validators are going to be required to be syncing shards at different points they're gonna be required to be proposing new blocks for different cards so they're gonna have to sync up at that point we're gonna the attesting to different parts of the recent chart state with through cross-links and so during these cases they're going to need to be like quickly downloading parts of shards that they don't have and so they're going to need to do that in a way that like you can verify it so you know they're not going to be using an inferior like system to be doing that they're going to need to actually like have proof that what they're getting is legitimate so with that said let's just cover some things that some of you probably know but I just want to cover because it'll only help out like you're thinking in my understanding of one of my pilots so mirtha proofs are basically the key to the castle for for Lance and sure to let you know this a lot of you might know this but kind of cover it all briefly some rebel proofs are waiting to verify some piece of data within a larger sweep of data where you only need to verify a logarithmic about a data table to get to to validate that something is authentic so usually what we are wanting some kind of data we're assuming as part of a workable tree and a miracle tree is just a hash of successive hashes of successive hashes and you end up with this kind of root hash which is kind of says something about all the data underneath of it and very importantly when we're kind of thinking about merkel proofs we have this root that we trust and so this e would like verifying data only works we have this root of you trust so these the roots are often like what's stored in the blockchain so actually when you're verifying this miracle trip usually the only thing you know is the route and everything else is kind of just unknown to you and that that's why you're requesting approval the first place try to get some information that you don't already have so when we give it a trip of a note we have to what we're doing with the proof is we're linking it from this bottom piece all the way up to this route that we already know and so we're wanting to be able to recreate this route which we do trust so what we what we need with a proof what the proof actually is is it's one intermediate node per level in the treatment starting from the bottom so we're able to kind of build up to the very top of the tree to the root and at that point you can compare this recreated route against your previously computed or previously trusted root and if they match then you kind of like have proven this entire chain all the way to the bottom and so what's really cool about this is that you only need one note per level tree and that grows very very slowly with like the total amount of data so that's why it's so important for these light clients because it's only a small amount of work that you need to do to prove even if there's a giant amount of data into one kind of a psych engine multi proofs that's kind of just an extension of the verbal proof idea and a Merkle multi proof we are proving data about multiple pieces in this trader multiple leaves in the tree and so very similar to a Morgul proof you're wanting to build back up the tree to the root but what makes them creep a little bit different is that you can you could share these intermediate nodes between between all your paths and so you're able to be able to be a little bit more efficient than just having one proof for one branch one proof for another branch we're going to be under picking advantage of this verb aetherium to my plants another thing to think about is just being proof of work improvement stake light clients so improvements work light clients it's really it's kind of easy because everything is everything that you need is within the protocol you can download all the headers and you verify everything based on protocol rules so these this kind of like headers you download all the headers you everything is available to you just from those headers you hatch the headers you verify the proof of work you verify that the header points back to the previous header and then that's that that's all you need to do once you read like the final header the local roots are right there and then you can request the proofs so this tabs usually go sync up and now you have not you know then you can just put Wes first improve of stake is a little bit different because the headers alone are sufficient to verify it proofs you have to also keep track of the state of validators because in this proof of stake world were governed by some supermajority state so we after the sure were on the chain was the most state the only way you can do that is by keeping track of validators and their balances and how they voted so this is it's a different piece than proof of work but it's an opportunity to do differently and maybe do things a little more efficiently I want to think another little detour to think about simple sterilized because the speck that we have for a theorem to and it's a way to consistently and easily Merkel eyes our data structures so to kind of go through do my example so what it does is we can create a consistent way of creating these merkel routes or any kind of data structures have so for exactly a checkpoint a checkpoint is an epoch in a route so if we wanted to make a vertical tree out of this we would just put each of these elements into chunks and then create a 1/2 from this we didn't get a little more complicated everything called a cross link then we can still create a vertical tree from that we just pad it with some sub-zero data and then we can kind of put them even you can kind of compose these data structures so here's another example of an attestation data which uses a checkpoint and uses a cross link and so you can because fingers are built out systematically it makes it very easy to if you want to think about the proofs that we kind of went over earlier it makes it very easy to be able to traverse the tree and create approved for any sub element of the data structure and things good things can get really see structures and we have really really nested in the etherium tool so we you know we have we put merkel roots within a lot of these data structures so we can leave eaten blocks to our beacon state we can leave our beacon state to beacon blocks trust certain trusted be new blocks we can link our chard blocks to ethan blocks and so you can imagine like sitting like the data route within this prospect here that data route is actually of some other NATO which you can then you can imagine there being a tree below that and then so you can you can end up navigating down this tree further and further maybe the past or into a shard or back into the b2 in shape so we've like designed this in a way where it's we try to make it as friendly as possible to be able to create these proofs that can take you where you need to go where wherever you need to go to some place in the chain so with that we can kind of you can start finally finally get to the into light light itself so let's start with syncing so you kind of looked at the proof-of-work model of syncing which is download all the headers and then process header is one by one so what we need to do here is we can think how can we get these trusted merkel routes in our proven state system and can we do this simply so smaller a small runnin data to our steps that's better for our life ideas but what is trusted well trust it is our roots that are attested by a certain amount of stake two-thirds roughly I mean but the state's the stake two votes give way today so we need to make sure that the roots that we're getting are roots that means something so you can kind of think of two key insights that kind of change how we can progress and in Sinking so one is instead of sinking headers by half by hashing one one by one and progressing just one at a time we can use state to vote we can use the snake to skip ahead to the current trust header without having to verify every single header one by one so instead instead of using kind of the cryptographic trust of each header being of each previous header being included in the next header we can instead if we if we already know who's validating we can use the trust we can we can use if we count all the votes we can jump ahead to place much further than we don't have to go with one by one so if you imagine like a blockchain where the validator has never changed and the balance has never changed yeah we do everything we did we would be able to skip immediately to the very head of the chain if if we saw that everyone was voting for that head the the the kind of the trick with theorem two is that the validators are always changing and so we need to keep keeping track of that and that makes it a little more complicated so they knew this was another key insight which is instead of tracking all of the validator balances and all of the votes if we can find a place where we don't have to do that you find a place where you only need to track a few of the validators then that will really like lower our requirements for for keeping track of the mistake so where where to eat to validate validate well they validate across the committees is one place it's very fast these companies committees changed every pub and they saw the attest to research our data they attest to the beacon block route which is great but that they actually we have to count all the votes across committees and we're in that case so that isn't helping and they have tested recent check points also as a whole validator set so about the prospect committees are really a great place to like keep track for my clients because we really need the whole validator set and so they're not helping us out so the other place that we can look these in the shark committees and so these are the committees that are proposing new blocks with the charts at least the currents game and these only change every 27 hours so this is actually a lot better of a place for my clients because if we wanted to keep track of the boats will kind of keep track with alligators those these things only really update very infrequently and so because they updated more infrequently that's less work that we need to do as a life plan so that brings us to the st. protocol so what we end up doing is we track we sink to a certain shard oh well my time is up I tweeted out my slides and they cover the rest of all this if you want fun magnifique and I'll put it in the packet deep for this [Music] yeah that also [Applause]

Automatic transcript — names and jargon may be misspelled.