Light Clients After the Merge by Etan Kissling | Devcon Bogotá

foreign [Music] to answer that first let's look at what you actually need for a full node at the very least it's a Raspberry Pi eight gigabytes of RAM 2 terabytes of storage one terabyte A month's internet and a live client is basically anything that doesn't support those specs like a browser wallet to the left side metamask or in the center the status mobile or on the right Hardware wallet so let's look at what those like clients can actually do let's assume that you own one of those this metamask wallet with the 4.75 eth and you are doing great work at this conference and your work is not great at your approach by investors here someone approaches you he wants to donate 0.5 East to you so sounds good 0.5 is a lot of money you give them the QR code they send the money and they send you the transaction and seems good but when you check it you see ah they accidentally sent five E's so we need to refund 4.5 of those and luckily we brought our Hardware wallet but as you know the Wi-Fi is not too great here so let's just ask we can use their laptop and they agree we connect The Ledger to their laptop and we see here the 9.

75 eth so the plus five and we signed the transaction for 4.5 the letter protects our keys so they cannot be extracted we see here the amount is correct the address is correct and we confirm and we thank them for the donation so like clients very powerful that there is a problem when you go back to the hotel you actually realize that a this transaction of the five is missing so what went wrong we confirmed that everything is correct but uh one key piece is missing there the actual balance was 4.75 East so they lied to us with the 975 this is actually the same problem with traditional banking when I create a transaction to an unknown destination they only ask me is the amount correct and the address but they don't verify that the intent why I am sending the transaction is really why yeah so where is metamask putting this data from the answer is there is a setting in there and you just put it to a server by default that's infuro but in this case the scammer just put a custom URL there that lies about the balance so how is that possible isn't that more secure actually it's just this is the call that metamask is doing is get balance your posit the address the block number and you need a response you just get the raw balance no security whatsoever just trust me bro so in this case the attacker simply added the five E's if it's our address this is the complete attack code this thing I tried with a real metamask so now the question is how can we make this more secure to understand that we need to understand we need to see what are what is actually stored in ethereum and all of these things any one of you probably interacted with at least one of them nft ownership game characters tokenized assets exchange rates or even just the plain East balance that we have seen before all of that is just data stored as part of the ethereum state and because it's data it's just a bunch of bytes and we can arrange it as we want for example here we can order it and then what we can do is we can compute the hash function on pairs of each of them so a hash function is just a one-way function it's a cryptographic checksum the idea is that if any of these change for example if someone modifies the B then the hash also changes and we can apply this to the entire data and as you can see here we now have only four of them then we do it again we only have two of them until we have a single state root hash so how is this useful if you have our balance down here the 4.75 we can see the root cache contains information about all of it so whenever someone changes that for example to 9.75 to lie to us Everything Changes up to the true test so if we know the correct routes we can know that whether something was tampered with or not so how do we actually send a proof that the 4.

75 is was used as part of this hash and for this we need to work this entire path to the top let's start with this node here to compute that we also need this one and then we go to the next node here and for that one we need the A and B and then from there we go all the way to the top what is missing is EFG and H so with just sending those three additional values we can prove that the 4.75 is part of the root hash we can cut away all of the rest so those proofs are really tiny of course in reality it's not just a binary Merkel tree it's a bit more complex but the general principle is the same so how do we obtain those proofs the answer is is get proof the interface looks surprisingly similar to the get balance but instead of just a balance in the response we also receive the Merkel proof and this marker proof can be used to verify that the balance that we get is indeed part of that root touch so now the question is how do we obtain the root test this is where the lifeline protocol comes in if we look at the Beacon chain it's a series of blocks that point to the parent block with a address that's part of the block it forms a chain and since the merge actually the root hash is just part of those blocks so the question now is how do we obtain that latest block with the correct true test and a full node does this by just following all the signatures and verifying them we have the proposer of each block and then all the attestations but to verify that it's like nearly half a million of validator keys and it takes multiple gigabytes to verify what is the latest block so that is not very practical for like clients but a year ago Altair launched and it added this notion of a sync committee the student committee has a set of just 512 validators that the like client can keep track of and they also sign each block they sign whatever is the latest block and if you know those keys you verify the signature and more than two-thirds of it agreed on the same block you can trust that is the same that is correct so how do you get these sync committees and the answer here is it's from the previous in committee every day the student committee changes and the previous student committee signs a message that passes on this power of signing the latest block to the next student committee and the previous student committee how do you get that one is from the previous previous student Committee of course but at some point you just need to agree on a trusted block route for example the merge transition block and if you start from there with the initial Zoom committee you can get that with a Merkle proof as a bootstrap object and from there you can continue and continue one day at a time to the next string committee and download those public Keys verify the message that signs the next single committee until you are at the present one and then you obtain the latest block check the signature and you know the root hash this data is really small it's just about 25 kilobytes each and to obtain the final root hash it's just about 300 bytes um one thing for certain applications that can be done if you are really offline for a long time those committee messages can be combined into a CK proof and then you can essentially jump from any point in time to the present in constant time with a very small proof those apis are available to download the data it's on rest andly P2P it's already standardized part of the official specs on the portal Network there is a PR and load star and Nimbus are currently implementing the lip p2pn rest apis so if you want to try those feel free to do so then security how secure is it there is some research that shows that with a few minor modifications to the protocol it can be made so that you can actually only stream every four months so this really opens up a lot of applications such as iot devices where you are not connected to the internet so as long as you student once every four months should be secure then let's bring it together this was where we started we had our wallet just get balance to infurum and it returned us to 4.75 eth not very secure but uh it's it's the best that could be done before the merge now we can obtain the latest root hash from the beacon API and then use the get proof endpoint to actually get the 4.75 plus a proof that it is actually part of the root hash that we obtained and this essentially means that if you think that the beacon API provider could be the same as the web3 API provider why not infuro could essentially just provide that data and you no longer have to trust them for the correctness of the data but just for the availability of the data that is quite huge if you don't want to modify metamask you can also put a proxy in between that does this translation so metamask is unmodified it still does this old get balance call but the verifying proxy it keeps track of the latest root hash using the light client data and it translates the get balance call to the get proof and verifies that the return data is correct it can alert you if it was tampered with like in our original case this verifying proxy is available today from Nimbus it's it's a part of the Nimbus E1 repo in the LC underscore proxy subfolder and yesterday someone announced on Discord is r d in the light clients Channel a product called keflar that also does this including proof verification for nft ownership and token balances so one piece is still missing for the later device how can we get it to show us the current balance of course that needs a modification to the letter software but it could be done in a way where we just dump all of this data to The Ledger and it can actually just verify that it's correct it uses the live client data to update to the latest public keys then obtains the latest true touch then verifies that the balance that we give it is correct using the Merkel proof and then it can show this it can show the balance with the timestamp and you can verify that this transaction is really something you want to do so what else can we do with this protocol for full nodes right now it's always a bit tricky where do you obtain that initial State from usually you just go to infuro and scrap States finalized and then maybe you go to Beacon chain and check that it's the correct one but with this protocol you can just hard code the merge transition block for example into the client and then use the lifeline protocol to jump to the latest State download that state and then use that as your bootstrap checkpoint without having to validate it against Beacon chain or another use case a decentralized wallet that doesn't need to talk to any server Geth has a Mode called Les currently it's sort of a thing that you have to enable but the key point is that it doesn't require a huge database so what a live client protocol gives you is access to the block headers and inside of the execution payload header there is a field called logs bloom and with that field you can filter all the incoming transactions and see whether a block contains a transaction that is interesting for your wallet so you just need like the little like client on the consensus side 25 kilobytes a day about 20 bytes per second to follow the blocks continuously and then you can pass the headers over to guess Les and it can then filter for the blocks that contain interesting transactions and just download those few blocks it's not every block for sure so if we go a bit further to the Future layer twos are getting more important and for them the problem right now is they get attacked all the time like they usually get operated by Oracle nodes that are trusted there is a multi-stick maybe 5 out of nine four out of seven but it turns out that one party owns four of those when they get compromised everything gets hacked and if you add this Lifeline protocol there um it can sort of act as an additional safety net so that the Oracle notes cannot just um send the bogus information so for example when you make a deposit into a bridge you can create a Merkel proof that you made that deposit in the ethereum state and if there is a light client deployed to that layer too you can then use this as a as an endpoint like if you if you submit a Merkel proof to that bridge it can verify using that light client that it's a valid deposit and can transfer that tokens to the layer 2. and also Internet of Things devices you can put a rental pass for bicycles in your wallet on chain like a weekly pass and you can just send this data to the bicycle lock like we have seen with the letter device before and it can actually verify that you own that rental pass and are allowed to open that lock or for example when you have like an electric car charger at home and you want your friends to be able to use it but not anyone to be able to use it just put a lag client on there it doesn't need to be connected to the internet so yeah that's uh all from my side this is the latest updates about the lifeline protocols feel free to contribute to this Discord channel from ESR and D this is where we discuss the like lines foreign we also have time for questions if anyone has a question hello uh thank you for the great talk I see a lot of deformed Bitcoin Maxes who say that it's putting too much pressure on the nodes while you're part of the sync committee um so I just wanted to ask what do the resources of the machine look like while you're part of a sync committee CPU RAM and bandwidth so as part of the same committee you are already doing extra work so doing this extra lag client work is actually not that much extra basically what you need to do is you need to Hash the state and you need to grab a bit of static data out of it because you already loaded the state and getting those hashes is basically instantaneous so this really just doesn't add that much for nimbos we collect the lifeline data by default and no one has ever complained about any CPU Spike or bandwidth Spike due to that you please elaborate on what this means for wallets like metamask or coinbase or Ledger like what does this actually what's the future opportunity of using like lines and how does that change how well it's actually operate in the future um I'm not sure if I got the question but uh metamask right now it has to use the get balance endpoint because that's just what was available before the merge with this it can actually provide a secure verified display so to say so that this so that the balance that it shows is actually correct um also for your nft balances nft ownership anything can be verified is there anything the protocol can do to be even friendlier to like clients or are we pretty much as good as it will get we are still working on the protocol for example right now getting access to the execution payload header is not that easy you need you still need to download the full block for that but we are targeting a couple improvements there for Capilla that further reduce the amount of information that needs to be exchanged to be fully synced to the latest head oh hey uh thanks for the talk I just have a question about the attack that you showed at the beginning with metamask and the solution that you uh came up with at Nimbus as how to mitigate that attack I'm just curious um introduce my excuse my ignorance here on this question but like why doesn't metamask or these like client wallet providers just build the solution um and instantiate it themselves like what does um Nimbus why does nimbus need to be brought in to mitigate this attack well the reason there is that actually those protocols just are getting standardized right now for example the rest protocol was standardized on Monday so that's when it got merged so there was just not enough time yet and we hope for sure that metamask and Ledger will integrate those security enhancements directly into their products or you could also Imagine a scenario where Apple and Google put it into the Android and iOS operating systems as a background service so you can just ask that one give me a secure balance and as long as you trust that background process that's fine but yeah the answer is just there was not enough time yet to implement those changes because the protocols are really brand new hey it's on what are the um sort of assumptions that are being made or the security implications of just trusting the data that comes into the like client headers and how do we mitigate this so all of the security Implement implications the student committee is sampled by random from the full validator set so the full Beacon chain currently operates under an honest majority assumption so as long as a majority is honest the beacon chain works so if we sample randomly 512 validators from that set that is considered to be honest maturity then the same can be assumed for the smaller set and there is also this additional safety that's why it's more than the weak subjectivity period um where because like it has to be exactly those 512 validators that are only assigned for that particular day that you need to compromise if you look at it how long does it take for validators to exit it takes about four months until enough validators are exited so that they can then sign conflicting histories to compromise this so as long as you stay within the four months and as long as we improve the protocol with those flashing methods then I think it's quite a secure way what you have to keep in mind though is that the student committee is 512 validators and each of them has 32 E's so if you combine all of these balances it's about 2 million dollars so that's about the highest cost you can get even if everyone would be fully slashed down to zero any attacker who can offer the student committee a higher amount than that can compromise this so right now for highly secure applications such as layer 2 Bridges I would recommend it as an additional safety net so in case the Oracle notes get compromised that you can still verify that they are compromised but I would not trust this solely for high security for the wallet use cases it's already an improvement compared to just trusting infuro hey so on the beginning of the thought you mentioned this Raspberry Pi 4 with a gigs and two terabytes of disk so is that still the same for like a running like client could be a bit lower to smaller devices or in Linux in constrained like a hardware resources a Lifeline doesn't need a database you just have to track those 512 validator public keys and the latest headers so you don't need eight gigabytes of RAM you don't need two terabytes of storage because there is no database and you only need 20 bytes a second over one terabyte a month so yeah awesome so please one more round of applause for Ethan [Applause]