Office Hours AMA - Etan

Transcript

uh this time with so thank you so much everyone for joining but especially it's great to have you here and um yeah so after a brief pause last week we have a proper uh core developer mentor uh here today Ethan working in what used to be status uh and now layer they also started execution layer client they work on SS across both players. They work on many cool proposals that I believe are making Ethereum more um secure and resilient and um maybe uh uh champion some of the fact

he's been also mentoring them for ETF for a couple past years. So I think that uh he has also interesting insight into how the men how the fellows have been doing and uh what was them. Uh we had we had you actually for the inerson uh sort of uh panel in can but never online. So finally a proper like AMA just dedicated to Ethan. So yeah, thanks again for being here and maybe just to uh get started uh to give people some context please uh uh tell us a bit yourself about uh maybe what you did before Ethereum uh how did you get into the ecosystem like something uh uh something about yourself?

>> Sure. Sure. Hi everyone. Um just double checking again. Audio is okay, right? Okay. Um so how did I get into Ethereum? Um I'm in Ethereum now for 5 years. Um I started right uh around the launch of the beacon chain. Um before that I was working in embedded like smarthome. um like we made an SDK that you can put into small accessories like uh light bulbs or door locks, cameras and these kind of things so that you can connect to them from the iPhone. Um like there is a standard from Apple for that. Um and after that because over the time it

gets kind of repetitive like you are just adding more profiles but it's still the same tech. Um, I was still interested in small devices. So, I figured now that I have time, um, let me try to run my own note because staking is kind of expensive if you use one of the custodians. They charge like 10 10 or 15% of the rewards. So, I set up a Raspberry Pi with Rocketpool and uh, I was surprised how simple it is and how stable it was. like you just log in like once in a month, install a software update and it works on the Raspberry Pi.

And I was running Nimbus and G. So I was like wondering how these softwares work and nimosai started contributing open source [clears throat] I'm just on GitHub was very welcoming like a different background from before like smarthome is mostly proprietary like closed source crazy compilers crazy platforms and so on and now it's like with Nimbos it's like an entire tech stack like we have the compiler We have the standard libraries async await um HTTP sockets everything is under our control and it's the reason why it's so

tiny right um so same background small devices but now with um distributed um systems like without trust right you cannot just trust the controller to tell you what's right yeah that's how I got into Yeah, it's very very cool to people see people exactly from like this ecosystem from like thinking about actual like hands on hardware um and uh you know the realities of optimizations and software like coming to I think it

produces a bunch of great stuff uh Maybe just to continue like further like what uh sorts of projects you have uh now in Nimbus or what excites you uh what sorts of uh new features or uh some maybe longterm efforts you had uh within the team. So for me um like it's a bit different than many others like on the big road map you have like scaling and like cheaper gas fees and faster blocks and so on. For me, the important things like the priorities are like how can we make Ethereum accessible to developers and to users. And that's why you see me listing

all of these projects that try to improve that. Like the one I'm focusing on personally this year is the decentralized checkpoint sync. Today if you start a new node, the first thing you have to do is you point it to some weird URL to download like the initial beacon state from and I don't like this central server that you put in there and then you just trust it and oh now it works right I don't think that this is appropriate to like have on a credible neutral network right so um I will try to make this decent centralized. So far, I have um also been reached out to by

two of the current DPF or even three depending on who sticks around. And that's great, right? The other stuff um that is listed is this pure um bucket that we also started last year. Um Tamagna is also here. He was an EPF fellow last year and he made a lot of progress there. So there um this year we are trying to um integrate his learnings from last year and try to make it more real. Right? The idea there is um that we want the wallet um when it fetches data from Infura or from Alchemy or

whatever back end we want to give the wallet the ability to verify that everything that it gets is correct and also complete. So um and also for historical data. So today is like you ask in Fura what are my historical transactions and maybe they are like hey today we have a bug and we don't tell you like about onethird of them right I mean all of this stuff happens. We also had the RS kelp incident which um was a similar issue where they minted some tokens uh without them actually having been minted. They just someone told them they were minted, right? And then they had like these tokens that they can just spend on a right. Um yeah, light clients

and just verifying in a decentralized way. No trust, maximum decentralization. That's like what I try to um maintain or improve here. Um it's like the scaling is is great to have but um scaling is already kind of solved right like we have blockchains that have scaling but Ethereum is unique in decentralization and I think with every step that we take we should at least make sure that we don't give that up or even improve it like if it's possible.

Um, Yeah, I mean for the

that's just a necessity from proof of stake because with proof of stake um we have the problem that validators who were active in the past they can leave like they can exit their validators and after that they are no longer slashable. So if you start your node with a state from five years ago and those validators have exited that old state like they can just make up a separate history and you cannot really decide which one is trusted. That's like called the weak subjectivity period. It's in every proof ofstake system. You have to start from a somewhat recent state. And about the other question from Sakar, how is it

decentralized if we are using these RPC providers? Um, it's like different phrasings of decentralized, right? Like either we say it has to be something like the old portal effort where everything is decentralized on a P2P style network like on a DHT. Um that one is quite tricky because it's difficult to spread out the data in a way that is still low latency to access. Um then this RPC infrastructure um it can still be somewhat decentralized by having public RPCs and you can just pick like between 20 of them. So you trust them

for data availability. But the key is that you need to be able to verify that all the data is correct. Otherwise, you can only rely on those with high reputation who have something to lose. But if if you have the ability to verify, then you can start um asking any RPC because they can no longer lie to you. [snorts] Um yeah, and then we had a hands up from Blessing Web 3 Creed, I think. So I guess >> Yeah. Um yeah, I don't know if you can hear me.

Can you hear me? >> Yes. >> Okay. Okay. Um so I when you were actually speaking I think you mentioned about you're working on decentralized um checkpoint sync. So uh I'm just curious right because I've been making research uh on checkpoint sync in general right. So, I'm looking at So, are you going to handle the nonfal checkpoint sync? I'm just kind of curious in that area. The non finalized checkpoint sync. >> The nonfal checkpoint thing. Um, >> yeah.

>> Is there just like the thing where like you download a checkpoint and you don't check whether it's analyzed and started or what is it about? >> Yeah. Yeah. Exactly. Yeah. Exactly. You're correct. >> The standard today like you download a checkpoint and you assume it's finalized. There is nothing really that enables you to check whether it's actually finalized because like finality information comes later like you download that first state and then you download blocks and the block finalized is just a that tells it hey do not reorg deeper than this one block and it's it's just a

>> okay [clears throat] Okay. And also uh so so concerning the decentralized checkpoint sync right? Um so are you looking at the checkpoint sync uh safety in general the safety concerning it? Yeah, I mean today if you don't start with anything like if you don't put the URL you start from Genesis and like you just have to trust that whatever blocks are given to you are the canonical ones and with the decentralized checkpoint sync we can at least start with a later state but we still have this initial thing where you start with the light client from a somewhat what

old trusted block route I mean it doesn't have to be that old but like maybe half a year or so so that it's not controversial anymore you start from there you use the live client protocol to you go to the present and then you know the latest block header you know the latest finalized and you can download the checkpoint from there somewhere around that recent region but in the end I mean it's still not perfect because like the sync committee those messages are not slashable and also even if we make them slashable.

It's very tricky how to how do you punish it because like the sync committee is like a very small part of the validator set and if you can hack that one node that controls like a super high TVL bridge and like you have like billions in damages it doesn't really matter if you can like after the fact slash like a couple hundred or thousand right so security is very tricky to do there. My goal there is to provide a reasonable default um for the majority of users. And I mean it's probably more decentralized in a way when we can get rid of the URL

because with the URL you don't really have security either. You just trust that that central Panda observer gives you the correct data. Um obviously you can always just verify that you are synced to the same chain as like beacon chain or ether scan and these kind of browsers. >> Okay. Okay. And also I don't know if you can have um like a drafts article like so I can actually just check it up like just read about it. I don't know if that's possible. I will like on on I can I'm still working on text there. Um I should have something

and uh I can share it on I don't know what the best channel is but >> I think Discord I think Discord. >> All right. Thank you. >> Your base idea will be to use light client sync to the present and then use a state that's somewhat recent. split it up into chunks that are smaller than a few megabytes and then just fetch it together with proofs that they are correct. >> All right, thank you so much.

All right. What is 830? with any IP or report request or >> yeah it's basically this trust logs indexing yeah mostly with the state I

mostly mean like historical one because with the recent one it will be in the system smart contract so yeah maybe that clarifies things a bit >> yeah for the decentralized log index I mean there have been many different designs over the years. Um, so it's still a bit open which one of them will be the winning one. Um, who is storing it will be an open question. I guess [snorts] there's also the old one I think uh 7 745.

Um, like that was the the older one with the filter maps. Um, that one was a bit challenging to implement because they wanted to do everything in the E. But I think if we just move like one megabyte of data into the CL there um, into the beacon state that's already like a 100 megabyte, you put like an extra megabyte in there that has like checkpoints, it would also work. Um, yeah, it's an open question. I cannot answer that one yet. Um but it is still being discussed. Tomagna is al also commenting in the chat but uh yeah where to make it available.

[snorts] Yeah. the same like the same idea like the idea is um how can we get the ETH get logs response verifiable and verifiable means I want to be sure that no extra logs are included but I also want to be sure that no logs were um omitted from the response so it's complete and correct

um yeah I mean the RPC providers they already have the data for is get log. So maybe they can store it together with the proof that it's correct. Um but I I don't have a good answer there. >> Yeah. I mean it's like the purist is like the umbrella term for everything that tries to make Ethereum verifiable like trust minimized and so on. It has many different aspects. So

one [clears throat] of the chunks is like this the logging like just Egget logs that's like one big area then another big area is how do we change the EL data structures so that they are proof of proof friendly because today with RLP we have like these linear hashes. So like if you want to prove that a transaction happened, you have to send the entire transaction with all the call data and everything in there. And also sometimes you have to send the entire receipt with all the logs and the logs plume and everything. It's a lot of data just so that you can prove that

like that thing has the correct hash and it's part of the Merkel Patricia try. Right? So if we can change that to three hashes that enables us an efficient form where you can like say I only want to know who sent the transaction how much it is the destination and maybe the first 32 bytes of call data so that you know like the function that's being called right um with a tree hash you can do that and that's like this 7807 seven umbrella like the sub part of cury. So we have the logs, we have the SSSC data

structures, then we have the decentralized checkpoint sync. That's like a third one that's like a CL effort. And then we also have um just general on the library side an API um how can we make generic proofs because today we have beacon APIs that are like for every single thing like give me a balance of a validator give me the current activation state of a validator. It's like a new API every time. usually they don't have any proofs and we would like to have a generic ESG proofs um equivalent for the CL that works on all the data structures and last year we

had June um from EPF working on that like it's like SSC query language but like just doubling down on that evolving that that's like another part of it um but uh yeah I think how do you get into this pury stuff is like you pick one of these areas um and you just try to reach out to the people involved there. It's quite like it's different people who work on different aspects there and but like I would recommend the ETH R&D discord.

There is like an SSC channel. There is also the light clients channel. It's a bit of a mess or just e magicians comment on the EIP directly. I don't know like what's the best [snorts] chaos Um client data backfield is quite

important because without that um like you start your note and it starts with today's state and it will only have the data from today going forward. [snorts] all the data that's back here is not on the node. That means that if someone else wants to sync from you and they start from like a block route that's in the past that you didn't know yet when you started your node, they cannot get that data from you. So if you want to reliably enable someone to sync from let's say 3 months in the past let's say we start there we need all the data of

those three months widely available and that means we need to enable nodes that have started syncing later to backfill what's missing. That's not possible today with the current protocol. it only supports forward syncing and forward data collection and so on. Um but if you want to get historical states that's like an extra protocol on top. The good thing is that it will not require consensus changes like it's something that's like a layer on top. It's like a newly P2P gossip topic or request response I think probably request response um where you can get like the

historical data and not every client has to support it so we can ship it quite Uh so my question is that uh so the

light client only backfills to the uh weak subjectivity points right like about three months not back to genesis. Right. >> I mean right now it doesn't backfill at all because it can't, right? Um but uh we will have like a period how far we want to backfill. Then we need the back fill protocol as well. And then we also need to like the checkpoint into the clients so that they know this is like a trusted non-controversial checkpoint that we can start the and from this point that's in the client the data has to be available on the network.

But yeah, >> only like two weeks and they are um like it's it's a bit of a mess because we have long validator entry cues. Like if you want to set up a new validator, you have to wait like one and a half months to activate it. And if we want to make that faster, it means the week's objectivity period goes lower because like validators can exit and enter more quickly. Um, but yeah, [clears throat] it's it's always a bit of a different number there. Right now, I think it's about two weeks.

>> I see. >> Thanks. No worries. No worries. Can't.

Yeah. Um, that's like just for context, that's like this straw map.org. This is like the EF's current take on the future of Ethereum. Um what excites me about it is like the postquantum stuff like quantum like we need postquantum algorithms like the current ECDSA BLS and KZG they will not be secure anymore about five years from now.

>> [snorts] >> There is still like a period where despite them not being secure, we can kind of cheat by just rotating the keys more quickly than they get hacked. Like we can just every time we sign a transaction change the key and then the next transaction needs a different key and so on. But that's obviously not very future proof. I mean it works, right? Because like the quantum computer can only get back the private key from the public key, but an address is a hash of a public key and the quantum computer cannot reverse the hash. So it's safe, right? But um yeah, this postquantum stuff is super

nice. Um the challenge there is to get a good scheme that works really well. like BLS is a re really cool primitive that we have. It allows us to create something like the beacon chain where we have a million validators that all sign the same message. I mean it's not a million. It's like 30,000 per slot, right? I guess. Yeah. 30,000. Is that right? That was Yeah. Yeah.

30,000 per slot assign the same message and with BLS we can aggregate it into like one tiny aggregated signature that's still the same size with uh postquantum signatures they are either very large or they are very time expensive to compute it's like a big mess right aggregation is not solved yet there are some approaches that are stateful so like every time you sign a message you have to write something to disk to track, hey, I signed this message. The next time I I'm not allowed to use this anymore somewhat. These approaches are also kind of bad because on desktop systems like F-Sync, this system call it it doesn't work reliably.

Like if the power is gone and like you restart it, maybe the data is still not synced. Or like if your little hardware wallet breaks down, how do you tell it? Like how far did you sign, right? Like it's like these big problems. Um if you go stateless it's it's different kind of problems right? Um, then what doesn't excite me about it is like this idea of like a heterogenous network where like we have this $100,000 machine that we rely on for the proving. Like we have this one mega server that is priced in a region that only allows it to be possessed by

wealthy individuals and organizations primarily focused in the west and I would like to retain the geographic distribution that we have with Ethereum. Like I would really like to see someone find out a way how we can distribute the proving. Maybe like the Raspberry Pi is at home. They can like each proof like 10 mega gas and then we can aggregate those proofs. Maybe it goes a bit slower. But I think it's still worth it to explore these kind of approaches that keep the decentralization of Ethereum. Otherwise, it's just like another one of these high

performance blockchains that has a couple mega servers in in some data centers. Um, also I dislike this mixing of concerns like postquantum and zero knowledge and issuance. It's all fused together in this one road map without anyone really asking why does it have to be together. So those are like the things that that worry me a little bit here like also who is making these decisions like who is making the straw map is it the same entity that funds all the teams is it the same entity that um operates like a lot of these validators

and so on. So yeah um decentralized proving with aggregate yes exactly these kind of proposals I like them a lot um I'm not like an expert in proving or zero knowledge but if you remove the mega prover keep it decentralized find a way on accessing the data like that's another thing like if if we put the execution payload into blobs and you don't really know which blob contains the data for your own wallet and you have to run a super node to get

all the blobs and then filter through them. It's a problem like like we lose something that we already have today, right? That's the risk that I see. But yeah, I mean lots of questions still on that road map like the short-term stuff is relatively clean like the fossil we already agreed on as client developers will be the next big thing that will help with um um censorship protection because like the validators can force include certain transactions like that the builder has to include or the block becomes invalid.

Um but yeah um just we have to make sure that everything stays decentralized and like no compromises There. [snorts] Hey, can you hear me? Cool. Um, yeah.

So, I I actually totally agree with what you said about like you cannot just simply let proving and executing be centralized. I mean that is such an enormously terrible thing to do. Like letting a testing be more decentralized is more important. Yes. But this idea that we can just have like arbitrarily centralized proposers and executors is like almost equally as terrible for like a number of different reasons. But um like that's why I was talking about like an execution tree as you said you split the role into across multiple um actually weighted by stake um and and then you aggregate. you don't just let like one like entity do it all. Um so that was my proposal there. I actually

wrote about two days ago um for lean execution is like doing exactly this um you know parallelizing aggregating recursively. Um and then uh yeah um there was something else um actually I probably won't I was going to talk about the history thing as well. I know Mario you mentioned that but um that's a completely different thing but um yeah I guess what do you think you mentioned um oh yeah Mario mentioned um like meas L1 or gigas L1 teragas L2 I disagree with that notion just simply out of like um the fact that conceptually scaling L2s is actually execution sharding like to a certain

extent when you when you do it in this way so my argument has always been okay if we can get L2s to scale in way with like ZK roll-ups and then we use synchronous composability actually implementing that on mainet so that we don't rely on say like centralized sequencers centralized builders for for L L2s is a far better thing than trying to like paradmatically split it into like L1 L2 so I guess what do you think about that like an L1 centric um scaling road map I [snorts] guess >> I mean I'm not designing the road map so I cannot perspective as a user. I mean as a user dealing with the L2 is always like of delays like if you want to

bridge something in that's usually like the 30 minute thing but if you take it out it's which is I mean it's and there are like services like cow that work across channel one but in the end someone has to wait that week right um what I find a bit sketchy though is that Ethereum as a platform for developers like we had a lot of effort towards L2 architecture that was like hey we want to now we have L2s and now if we just tell them hey we promised you this platform and now we

completely reapply it that's a risk on the application side like why would someone build on top of Ethereum if the core rules keep changing so that's the reason um personally I definitely see the advantages of native rollups um but also yeah I mean if it if we can make it work with like L2s that's also fine I guess I mean like if someone wants to use like a gas free chain like that works differently specific chain or whatever.

That's fine. I'm not sure how well that would come out like right now. It's big problem like gasies are super super low and blobs are free like any free on that extract all the money for themselves they don't pay a feel

worthwhile to run out at home like a little more than just [laughter] like originally with the proof of work they was like when people really liked Ethereum at home because they could like get like a fancy GPU and feel like they are part of it. And with every step that we like the decentraliz Sorry, I think you cut out a little bit there. I'm not sure if that was the same for everyone, but um >> Yeah. No, I mean I agree. I mean roll up No, I heard it also. Yeah.

[laughter] >> Is it still the case or Yeah, a little bit. Is it? >> Is it better on this audio? Maybe. Maybe it's the headphones.

Okay. So, yeah, like my point was just like like I I'm not sure what part did you understand and where did I cut off and can you maybe explain me that? Well, I um I heard like like a little bit about like the um like you mentioned native rollups and you were talking about like the user experience. Um I think the nice thing about execution sharding natively is that you can manage the basically the load balancing on shards or like quote unquote shards or roll-ups automatically

or dynamically which is an advantage because you can just basically make it as uh easy as possible to coordinate with users. So they're not like stuck in these very rigid like spaces like oh I'm on arbitrum so I have to only interact with people on arbitum or something you know um but also I think um if you like ropes will always be good for like custom logic um but if you take something like like a native roll-ups are kind of a weird limbo to me like if you take native roll-ups and you say then native roll-ups based sequencing but let's delegate the proving and the computation natively as well like to the validator set And then you have some mechanism that lets these native ropes be established and coordinated like the the creation of them be coordinated

natively. Then you basically have like dynamic execution charting which I think is a more advantageous way of both improving the user experience and scaling than any other rollup mechanism. >> Yeah. But like the the concern there is that it's just not what um application developers were promised, right? Like >> like we cannot just keep changing like the promise like either we have to be upfront and say hey this is a temporary thing or we have to tell them hey this is how it will be for at least this period and then they can work on top of that like Ethereum has to mature

to a level where it's a reliable platform but yeah I mean there's always better ways right >> I do I agree in principle. I think it's just like the the very nature of things is like very like there there's a lot of like this idea that like the current road map is like set in stone is like not I just don't believe that like everything is constantly changing. I think we have to be willing to accept that things can change and learn to live with that even as application developers. Like I I don't like the idea that we're just going to say okay no this is what we're going to promise um in terms of like L1 and then we're just going to keep it that way. I feel like we have to be ready to hit up.

>> I agree. Um I just want to minimize changes that are like avoidable. Like if we already know that it's a temporary architecture, we should say that up front. Also like one of the VIPs that I just landed in Glamsterdam. [clears throat] That one is actually interesting for staking pools like Lido Rocket Pool. Um we had this thing in the beacon trail where the data structures like if we add more features then randomly the memory layout would change sometimes when there is a new fork and then even when nothing changed for these staking pools they still need to update

their smart contracts for these new memory locations right so they have to go like through security audit the security council has to approve the smart contract updates and so on. So now with Glomstrom, we give them forward compatibility so that as long as we are still in shot 256 and as long as the features that they care about don't change that they don't have to change smart contracts anymore, right? So if we can give guarantees on some level that like a you can like rely on this working like this for a while, I think that's fine. But if we tell them hey this is we are L2 centric and then like it's like oh now we we don't want

L2s anymore maybe like you can uh distinguish yourself with different kind of funding or whatever. Um it's yeah I don't know but [snorts] I mean it's also like a topic that's completely above my level right like I I cannot change road maps or anything. I I do think there are ways to kind of modulize modularize in a way where it's forward compatible. Like for example, EIP like 4844 or even like um like what is it 8025 like native roll-ups. Both of them deploy this paradigm of like we're going to do something really simple now and then it's going to be forward compatible with like whatever we do. So

like 4844 was compatible with Perdas um in a way that like it was one UX change just to implement data sharding for for like the entire future. um native roll-ups like 8025 is supposed to do the same thing or um what is it the the the um optional proofs again like I I do think there is a way to kind of do things in a way where it's like okay we're going to make one big change now we're not really going to implement most of what we want to but um when we implement it in the future nobody will need to change anything which is one way >> it's not 100% correct like 4844 already was immediately deprecated and now we have like columns. So the way how you access the blobs has changed and

maybe there will be cells so that changes as well and like the lip P2P stuff keeps changing. Um maybe where like the the the aspect you're right is like the transaction itself that one didn't change but like the way how the data is stored how you have to access it that definitely changed. >> Yeah that's that's fair. That's fair. Thank you. >> Like it it was also a bit of a like like for example Aztec they wanted to use these blobs and then like FU came out with data columns and then it was like oh now you have to be a super node even if you just care about a single blob right because like you have to get more

than half of the columns to reconstruct a single row right so they >> originally they wanted homestakers and then they had like to choose a different DA. It's like yeah it has to become better like with like uh communication at least like to to tell them the plan hey we know that you are here right now this is your understanding this is where you want to be and like guide them through the process give them enough heads up >> yeah all right makes sense thank you I think there's another question 7792 was a very early draft that I made

with Gajinder based on just the idea of storing logs. Um we initially just like because like we had this question before who is storing the logs right the historical logs and in the initial prototype with Ginger we just put it into the state as well like we had like a special contract and we just shoved everything in there and it's just way too expensive like to put it into a big try like that because [clears throat] like even if you change a tiny thing you have to rehash everything that's above it and it's just too expensive that way.

Um especially if it's a free thing, right, that just happens by the system in the background as a service. So I think the newer designs like the log filters and like the 7745 or the 8 I I forgot the number, but 8304 like those are better better designs than the 7792. um

like the lifeline bootstrap like initially you only have a block route that's all you start from only a single block route you don't have a sync committee you don't have a state you don't have a block even you just a single route and the light client bootstrap gives you the initial sync committee for that route and once you have that sync committee that allows you to process light client update messages and those allow you to sync to the present.

So the bootstrap is just the initial message to turn the block route into the block header and the sync committee. I hope that's clear. Otherwise, just ping me on Discord. like it's it's a component I know very Uh I think uh an important aspect is

like embracing like failure in a way like sometimes you have to try different approaches and then you get stuck and then you have to work through why did I get stuck? But like it doesn't mean that you made a mistake. It could also be like that you just need to contribute back to the specs. Um maybe like the other people who gave you a task didn't think everything through. So I I think the most successful people there were really like people who did not like who had like flexible minds in a way like

instead of just having a linear this is their plan and I just follow it and like oh now I'm stuck and then I bang my hand against the wall for like three months [snorts] um just contribute back ask questions ask each other right um especially with the research heavy topics that are not yet ready to be integrated into a spec. Yeah thanks