Ethereum L1 R&D Panel | ETHTaipei 2024

so welcome to the e s Le one and the panel so um my name shwe I work at the S Foundation con r& D team and these are my favorite panelist today so um so we have three um client representative and two from research side and so like we actually all work together remotely uh around the world to deliver the sensing the is protocol upgrad so um today um I think the goal of this panel is to um to bridge the small gap between research and development and also like we want to um share the message that we think they are important um also like exchange the ideas here yeah okay so um our first question to the panel is list is um could you give a short introduce of yourself and also share like what is the certain L1 feature excites you the most um I mean the future feature like we start with uh V I have what sorry oh okay so sorry so my name is uh vitalic I'm you know the famous Dogecoin Enthusiast uh but uh I mean I guess for favorite fe uh feature I I'll focus on one that's uh that sometimes gets less attention than than the others which is The Purge um so what the purge is is basically it's a set of changes the goal of which is to try to simplify the ethereum protocol reduce requirements for users and for clients um and um basically make both the specification and client implementations um simpler over time and um also help make the network more decentralized by reducing requirements and making it easier for people to participate and I think this is super important because we there's constant pressure to keep adding new things and to keep increasing the power and the functionality of the platform but we do also do not want if am to be a platform where requirements and complexity keep going up up up there sometimes needs to be down as well um and so um to that end I think one of the most underrated features of the of Denon was the self-destruct removal right so now as a about a week ago the self-destruct op code only works in this if you destroy a contract in the same transaction when it was created and I personally hope that in a couple of years we can uh go further and remove it entirely and the reason why even the first step is valuable is that it adds a new um invariant which is BAS which is that uh there is now a hard limit on the total number of changes to the state that can happen within a particular block um and it's proportional to the gas limit but at least there is an upper Bound in the past this was not true and the reason this was not true is because you could have a super big contract and that super big contract could get self-destructed and then recreated and then like you could read and write State on top of state that was destroyed and this actually creates a whole bunch of complexity for clients uh that were trying to keep the state H cached uh to try to deal with and that's like basically hundreds of lines of code that could get deleted now um so excited about that I'm excited about uh gu recently removing a whole bunch of code um that had to do with the uh basically pre-merge proof of work handling and hope more things like that continue thank you and mariio uh I'm Marius and I like BLS why do you like BLS no um to to your point about the to your point about the um B about removing stuff um that is it's so great that we can finally remove some of the code from the from the different clients and um in the future if we have uh if we have history expiry and we don't have this the requirement for um for clients to be able to sync the chain from Genesis anymore um or at least for some of the clients uh we can have uh we can have really nice new implementations of the uh current ethereum protocol um instead of requiring everyone to uh also implement the the rules from like 10 years ago and um because like and and yeah implement the bugs that there were 10 years ago because they are enshrined now and uh everyone has to um has to kind of implement these weird behaviors before this blog and then after this blog it's a different behavior and so yeah I'm also very excited about getting rid of stuff but uh I actually wanted to really talk about BLS um so um uh we are looking into adding BLS pre-compiled um into the evm and um that is really exciting because uh right now well the consensus layer has been using BLS uh for for a very long time um but BLS just wasn't available um um on the execution layer at all and um putting BLS into the evm um gives us a bunch of really cool things like if you're depositing you can actually verify that uh um that your your keys are correct and stuff that you you can verify the signature on um on on on your deposit um you can do a bunch of uh cool things that you can do with BLS like um aggregating signatures um and I think a bunch of Protocols are really waiting for BLS to hit um and um hopefully we will be able to ship it in the next hard for thank you hi I'm Matthew Keel I'm part of the loadstar team and as a JS developer because loadstar is a a typescript implementation uh I come from from a ux background and I think some of the most important uh features in the in the Horizon of ethereum are simplifying the uh interactions um and also uh reducing the settlement time and this is why I'm a big advocate of both uh account abstraction and um and single slot finality which uh maxb is a big piece of um and I think one of the biggest things while I I appreciate a lot of the technical prowess and and the uh difficult problems that we're solving every day bringing the next billion into the ecosystem I think is an incredibly important piece of the future of ethereum and uh making it uh compatible with the thoughts of like my mom and grandma um is a is a big uh step forward uh for how the ecosystem will evolve thank you Matt and next G uh yeah I'm I'm G also work for uh for the guest team um I uh I like uh adding more codes so that Marius can delete it later I uh I work currently on veral trees so that's that's my favorite Topic at the moment uh but I'm also excited about ZK VM U I think I think it unlocks a lot of cool features for for ethereum for increased usability increased Freedom as well um yep thank you so our panelist U mentioned various types of the features um so I want to talk more about the verticle so who would have so first to to actually to balic that so people love to investigate your um road map diagram to found if there are like actually like the gold um in this and and uh wonder that I mean I think it really helps to um understand what is the timal goal or from the small features that were uh work in the one year and what you will grow in maybe five 10 years yeah could you like elaborate about uh what is the timate goal of ver Verge sure um so there's a multi-step road map here of which I think veral trees are a very important First Step um but you know there's also a second step and a third step and the ultimate goal of all this is to make it easier to run noes right so you know we uh talked you know yesterday and today about the difficulties of being a solar Staker and being a solar Saker requires having a node and being a solar Saker becomes much easier if be running your own node uh becomes much easier and it becomes something that has the overhead of like regular software Damons of which your computer already has like 50 that you've never heard of as opposed to something that takes up three qus of your hard drive um so that's um the first step there is veral trees which I know we'll talk about and we have talked about but you know the main goal is to reduce the hard drive space required to uh have a node that together with you know EIP 4444 which would require nodes to no longer store all of the history but then there are also longer term steps um in particular the big longer term step is ZK inarching all of ethereum right but basically wants to get to the point where the block Builder would be the one that's actually generating a proof that the entire block the state route everything is computed correctly and any other node in the network only needs to verify approv which is an extremely fast operation can be done in know ones or tens of milliseconds to verify that that block is correct and so once we get to that point then like run running a verifying node actually will be something that has comparable storage and compute difficulty to the hundreds of other Damons your laptop runs without you ever learning about it um but to get to that points I you know we do need to still get quite um quite a bit of work done but know fortunately know we've seen amazing progress on virgal trees and we've also seen massive progress on zkm implementation so I'm very excited anyone want to he said it [Laughter] all yes I actually I actually think um one of the advantages that uh verle it gives us not like sure light clients is cool and all but I think the biggest Advantage is it it makes us able to prove things about the state um in a very efficient manner and um this can be used for all kinds of things I think you uh you talked about um L2 Bridges um and uh I think there are a lot of a lot of uh use cases a lot of protocols that are underexplored that can make use of uh these State proofs um we we we we have this this idea about the the light the light client diversity where one of the clients is producing proofs um and all of the other clients so you not only run one client you run five clients on your machine um you run one main client and that is producing a proof for all of the other clients and these other clients verify the proof and then you know um at least in the EV within the evm um all of those clients agree and um so we have a way easier way of um of uh of making sure that no bad block makes it to the network because we um uh or if a bad block makes it to the network it doesn't turn into a chain split um because you will only a test to the bad block to the block if all of your light clients agree to it and um I think there are probably hundreds of use cases um where you actually want to um prove something about the state but you cannot really do it right now because the state is so large and creating proofs for it is so large it's it's um that um yeah it's it's not really possible and I hope with the with verle we can we can move move move there I'm actually really excited about that as well uh so loadstar has a project called the approver um and it gives us the ability to actually do full client side proofs of um uh individual contract state or uh transactions and uh in order to do that today we are actually still communicating with the uh the elel side and pulling a lot of these pieces as you're talking about and uh so verl is going to actually uh pair a lot of those proofs with the transactions which uh is going to actually increase the efficiency of our prover um this is something that is actually really exciting to us um so we're uh something that chains saafe is doing is we're in discussions with um metam mask at a very high level to explore feasibility of including our light client and our approver in metam mask and what does that do is it it reduces the need to depend on um uh external providers like uh infura or ether scan in order to do verification of of what do I actually have and uh so being able to reduce the amount of transmission and and uh and uh CPU on the client side especially in resource constrained uh locations like the browser uh it really increases uh uh the usability of that feature yeah and like right now if you're sending a transaction via VIA metamask or we are any most of the wallets you're kind of trusting the wallet to do the right thing for you and uh you're trusting the the RPC provider to send you the correct State and um there are projects out there already that that um that combine the this with proofs in the current mer Patricia tree um but it's just not very scalable and it puts a lot of um uh resource constraint on these on these uh bandwidth constraints on these uh on these uh proof providers um so if we can move to smaller proofs um you can you can do things like whenever I sign a transaction um I I I want to know that the balance that I currently have is actually the balance that is on the blockchain for example and so just getting your balance is is something where you right now you're trusting the provider to get you the correct balance and it would be nice if you could uh in in addition to getting your balance you get actually get a state proof to it that it matches the current well um the current state routes so you know and actually one of the things we've gone even further to do is uh we can pre uh uh pre-run transactions in the browser fully client side uh but again it requires pulling sections of the state and sections of the smart contract code and then running it in an evm on uh on the client side uh but having these proofs that are provided by vericle will actually reduce a lot of that overhead uh so it actually makes it feasible in order to to basically pre-run a transaction using live State uh on mainnet uh before you ever actually have to send that transaction it's actually a very cool feature sorry uh just uh just to add uh what you said that yeah I also think like the the biggest advantage of veral is that is going to improve trust uh by an order of magnitude you're going to be able to prove a lot more that currently you're just trusting people to be honest um you were talking about resource constraints so the browser is one thing but clearly what what at least I'm targeting is uh the Raspberry Pi uh all those devices when it comes to computing power they're they're okay they they have a lot of ram they have a lot of computing power IO is the uh is the thing that really uh fail on and this is going to offer I mean ideally we would be uh validating on phones we're we're not going to be right there right off the bat but this is this is a goal and I I think over time it's it's achievable thank you sorry another thing um apologies we we love verle yeah let's let's make it a bad verle okay let's um there's a test net right uh I I mean you can try veral right now you can experiment and I invite you to do this because we want to get some feedback we want to build cool applications so uh the sooner people get on that test net the the better we we make it happen indeed so um about um so think the umal upgrade uh just happened last um 13 so something and last week so and just one week within one week and also in the past months that the cting are very um hardworking at how what will be in the next har so it's like hard and half and they sometimes like over left in some ways in I mean the features are working in pedol so um let's talk about the next half which is the Petra according to te beo it's called Petra and so yesterday just a couple hours ago that uh we made some progress of the two eips so the first first one is the EIP 7251 the max EV now that is that basically it allows validators to have a larger um effective balance so um before that uh the the max effective uh B and is actually just 32 and we want to increase that one so that um so that um the signature um on the network will be should be reduced as well and to uh decrease the overhead of clients and the second feature is the inclusion list uh that was mentioned in Mar's talk previously so um I think I don't have to talk much but it's help the um censorship resilience so I wonder that um what do you think about this eips open discussion yes what what do you think about Maxi B why why do we need Maxi B Matthew you're probably the best one to talk about I mean to be fair I love the fact that it's just going to reduce the bandwidth to to for the same reasons um you know it's easy enough with uh BLS in order to aggregate signatures it's a relatively uh uh CPU in intensive process uh but just being able to collect all of the attestations in order to and to propagate them across the network on a global scale um is really the challenge and maxb is is a great step forward in order to promote single slot finality do do you think that um the the big validators will start to consolidate no no honestly no yeah and yeah uh I I actually had a question about Maxi because I only uh had a very quick look over it uh is it going to be possible to merge like do we have to exit if you have more than one validator do you have to exit and then push everything back and would it be hard to actually merge validators without exiting that that would require way more lines of code yeah but I'm fine with that in code I'm not right especially on the on the consensus layer yeah right so well any inclusion list oh yes right what do you think about it um yeah I'm going to be the I'm going to rain on the parade here uh I mean no no I think it's important overall uh I think it's a bit early to include them now uh I mean every every feature uh has to be delivered yesterday but uh I would say we have a censorship problem somewhat but it's not really pressing as much as other uh like Max CB because we we do have uh we do have some timing issues that would be solved with that I would say I clearly veral because of the the dis size and some features uh for me I think it would benefit from more um maybe thinking through uh I think it's going to delay Prague and therefore it's going to delay uh veral and I know I sound like extremely obsessive which which I am uh but uh at the same time this is this is uh this is a fork that needs to be taken very seriously it's it's on par with the merge on par with 4844 um so it's nice to have I would like to keep prag as small as possible with a lot of usability features uh but I I'd say it's time to get to work uh on on the big thing as well um I you I'll give some uh I guess I'll be the grumpy uncle and give some somewhat unsexy eips that I would still love to see um so EIP 7623 which puts the floor on the cost of call data of know either 48 or 68 there's uh there's two versions and that actually it leaves the G because it's not a gas cost increase it's a floor it leaves about 99% of use cases unchanged but it reduces the bound on the Block size from about 1.87 meab to um like basically one3 of that so about 600 kiloby which makes it safer to do things like increasing gas limits or um increasing blob counts um another one is to start thinking about increasing gas costs of operations that are uniquely expensive from AAR perspective um so uh espe this I think especially includes the hash functions um I mean like I think the worst offender is the hashing that's inherent in the uh the marry but you know we're getting rid of that anyway but aside from that know things shot 256 know Kat and the various other hashes because uh for the ZK evm L1 use cases again you know we need to have very good bounds on how long it takes to prove a block a lot of things like a lot of for a lot of things the safety is decided not by the average case but by the worst case and people really love putting the average case numbers in their headline but like right now a lot of the zkm implementations they're doing really ugly stuff because of the the worst case stuff like they have ugly things like basically like having to do more centralized sequencing because he wants to have an extra layer to prevent people putting in blocks that do lots of hashing and like clearly the correct solution to this is to just make hashing 10 times more expensive right but we need to actually do it um so that's another um a uh a third is uh um you know doing um doing the same to logs um and know possibly know simplifying the hashing um in the logs know removing Bloom filters um because at this point nobody uses them and they're expensive reducing gas cost of logs potentially replacing Rec compiles that are currently almost never used with equivalent evm code implementations which will definitely increase their gas cost by a lot but uh know like it's like my favorite way of deprecating things because at least it doesn't like fully break any application but like there definitely are lots of promiles that we excitedly edit in because yeah the features and then five years later like pretty much nobody uses them and they're like half our source of annoyance for consensus bugs in some cases um so start look moving moving toward expiring those um so you know just a bunch of purging and a bunch of you know limiting do do you think it's it would be like do you think it's realistic that this happens in the ne next hard Fork um for the next hard Fork I think uh realistically if we want to add things we need to add the the subset of that which is like on liners um so I think uh ap6 7623 can uh because lots of people are already raising the alarm that three blobs is not enough and I think the only way to like the only realistic and way to add more blobs that doesn't depend on Amazing new technology is to improve on other guarantees um so that's one um if I wanted to start the whole train of replacing pre- compiles with evm implementations the one I would start with is identity because the implementation that replaces it is like literally less than 10 lines of code but like that's I mean if it starts later that's fine right but basically definitely like definitely do oneline things like I would definitely not um advocate for anything bigger than you know like one or two line changes um just because the main stuff is so important actually actually we had a we had a buck in the one line that is the identity precompile and getting a bug fix for that it was a consensus bug it was a couple years back and getting a bug fix into a on line pre compile is kind of uh it's not easy this is true I mean I guess the argument would be this is deleting a pre compile which is easy but still point taken so like why are we mhm yeah so afraid of like adding free compile yeah I mean I think you know the reason why we're afraid of adding pre compiles and you know the reason why even something is you know seem as common sense as uh like making um you know BLS accessible from the evm when we already use it for like a bunch of other things that take so long is basically you know we do have these kind of horror stories of like you know yay let's have this new thing let he these amazing use cases and then like four years later there's no use cases and then there's like hundreds of lines of spec code right so like the complete listing is basically ripe MD um so that one was a hash function that was added in in order to enable ethereum Bitcoin compatibility applications nobody uses it um then Blake same thing but for ethereum zcash interoperability nobody uses it mod exp um and intended to enable RSA cryptography based application including plasma Prime including a whole bu of Stu possi vdf Stu um the result is nobody uses it and it's it's a big source of consensus bugs um then I mean identity but like that one was useful but now we have M Copy as an OP code then I feel like the aside from [Music] those I think I think the other stuff basically actually is like the the elliptic curve pairing stuff which we actually do use quite a bit which is great but it would become obsolete with uh with BLS presumably all yes so with well so with BLS the I guess uh the BN 128 focused promiles they would become obsolete in the sense that there are better things but like there's lots of existing applications that would keep using them that but I mean the the time when they all become obsolete is when like quantum computers blow everything up and then you know there's no point do you think we're we're making the same mistake right now with adding nine pre-compiled for the BLS Let's uh yeah it's a it's a good question I mean I think I you know there's there's a value in being pragmatic you know they I mean I feel like sometimes the distinction between you know like adding a few PR imp piles and adding more pre compiles is like actually not large because they're like basically pointing to this like different place is in the same code base but I me on the other hand like there's times when if you add more promiles it ends up exposing more things that makes things harder to change later on um so one very subtle example of this that I can give is uh when we did the pre the pairing pre compiles for BN 128 the original tic curve we designed the pairing precompile specifically in such a way that it doesn't output the GT element which is like the answer of appearing it instead like you have to put in a Ser of elliptic curve pairs of elliptic curve points and it computes all the pairings of them and then multiplies the pairings together and then checks if the result equals one um and this is um like one of the important things that this means is that it basically means that clients have a choice of which elliptic curve pairing implementation they build right because there's like actually like hundreds of ways to do like there's like a a okay fine at least three ways probably more ways to do a pairing and then there's hundreds of ways to represent Fields And so there's like lots of different ways to represent pairings internally and if you had to like make the match up on the answer internally like that would really constrain the uh like the implementation it will that actually open up a lot more attack service for bugs and actually it would have also prevented a whole bunch of um optimizations because there's actually some optimizations you can do to pairing checking when you can guarantee that lots of pairing computations are being done at the same time um so yeah lots of uh like lot lots of these kind of subtle things where you can end up dodging a lot of bullets if you open up less functionality at the start and uh like so like this is just like one of the things that's uh really valuable to be careful about so to to I I would also like to like to answer the question about why why we don't like pre compiles or why we don't like pre-compiled as much as maybe the L2 people like pre-compiled they they really love them so um uh you're you're already kind of mentioned it the so we have the modex pre-compile which does X to the power of Y mod P and um within this precompile I think almost every client actually had a bug at some point I know that we within gu had three bucks at least one was um one was in the uh GH standard Library where you put in some certain input and it would just Panic with the with the error message impossible turns out it wasn't impossible to hit this so uh we had to fix the standard Library um the other uh the other one was um if you put in a really really big modulus that was even um then it would uh it would just it would just take extremely long to to process the block and we were like like okay sure what's happening turns out in the go standard Library they have this this nice little switch if the modulus is even they use this one algorithm if the the modulus is odd they use this other algorithm no one ever uses mod x with an even modulus like why is this even possible because everyone uses modex only for like cryptography and for cryptography you always have a a prime modulus at least an an odd modulus um so no one ever ever did any benchmarks with even modu modu li and um so uh yeah we again had to go into the gold standard library and create a new algorithm for for even uh modulus um for for modex and um and the other thing is like that that that is one bug that I think I found at least in at least like three or four clients um because it's like the fuzer usually finds this pretty quickly and no one really thinks about it um with a mod x pre-compile you you you basically you have six Fields you have U uh uh base um exponent uh modulus and then you have the base length the exponent length and the modulus length if you specify the zero uh zero modulus um then um the result will be zero because anything modul zero is zero um but what happens is uh you can you can specify like really really really big numbers and the computer will crunch them and then in the end apply the modulus and it will be zero and and so the the answer will be zero and it's it's just like there are a bunch of times where where clients just uh ran out of uh um uh ran out of uh time because of because of this it's and it's been in like most of the implementations yeah so as the author of The Mod X breaking pile I [Laughter] apologize I like how marus reveals CRI critical vulnerability in the public setting like that so we have like some different um prefer um preference of what eips what features we like but in reality that there are some other considerations like for example like thaine and what are the uses like and um how would you describe your preference uh based on your considerations like what are the factors that you would prioritize so for me I think security is the most important one by far um it it should be uh it should like we should try not to create too many foot guns for people so that they don't shoot themselves in the their own foot um and um for example the the self-destruct create two thing um that was kind of a foot gun where you could um everyone is under the assumption that the code um that a contract has cannot change but now we have this parad where you can change the code of a of a contract and um so it's very important if we valuate new eips um to think about does this change the mental model that people have and um or does it introduce some new denial of service stuff like these technical considerations but we also have to take into account some some of these more I would say soft considerations about like what are people thinking about it about it that's a really good point and um yeah you you mentioned your grandmother right exactly or or even something like iil uh this is a feature that is relatively at least from our uh CL side easy to implement uh but what are the human implications and the user implications of of bringing is into into effect like is it just going to wacka style open up a new market for uh for ILS and uh and and just create a new version of me boost um and I think that's not really a technical challenge I think that's more of a of a usability challenge that requires more study um just from seeing how the market is going to uptake this this new uh EIP um yeah I mean usability is definitely a big factor I would say um there's also how you don't don't take the whole house by removing a brick or adding a new brick uh so we we have I mean unlike uh many other blockchains that have project that have a lot a higher delivery speed we have to we have already a lot of value loged we already have a huge user base and we unfortunately cannot move as fast and it's a pain but it's also extremely important because there's a lot of people depending on us so yeah that would be another criteria so yeah no just um I yeah it's like a a very big product management with and we have to balance between like decentralization and also the technical uh consideration yes and I think like sometimes for us on the stage that we prioritize security um I think we all yeah cherish that um the most important for the nwork we have to be bive to the users yeah and I mean it's like yeah it can be a challenge because um sometimes you have these proposals that are very shortsighted that are made by some some company that um I don't know developed some product and they really really really need this one feature and um it's just kind of like we will be stuck maintaining this feature forever forever and um that that that is a big problem and this company might might be out of business in like a year or two and we like we have the same we have the same thing with a we have the same problem with gu um uh a lot where like people show up propose some feature maybe even write the code for the feature and uh and and then um we merge it in and three years later we want to like refactor something or something doesn't really work and then um we cannot do it we cannot um go with our new ideas um because we have this one feature that like three people in the world depend on and uh we cannot get rid of it so it's um it's it's always yeah we need to evaluate the proposals very carefully how many guest folks like you can um daily talk to uh I think it's roughly 9k or something 9,000 folks on the on GitHub um uh most of them are not like other l1s um I think so the big uh uh guess Forks that are actively maintained probably like 105 um but um I don't know so it's like a much more um energy um and laboration of the you have to talk to L and for the maintenance it wors you're tying yeah it's sometimes it's sometimes sad that there's uh there's too little collaboration there are sometimes you you go to to conference like this and you talk to someone um who knows exactly what you're doing EXA like they they know they know like what everyone in the team what their role is they they know exactly what is what is happening what we're working on H and and yeah there there there some sometimes know the features better than you know them um even though you're working on it and um and there's a lot of knowledge about especially about gu uh in the community um but unfortunately it's very rarely that this really helps us and that this comes back um so we would love like it's it's great from my point of view it's great that guest has been fed so so often and that so many people know how it works internally um but it would be really really nice if some of that knowledge came back to us so if you are working on a GU for if you are maintaining a GU for um and you find something you find an issue in uh in gu that we didn't see uh reported to us uh send it to the buck Bounty program um uh get in contact with us um if you have if you have some if you found some cool new optimization that you did in in in your fork Upstream it um we very heavily depend on uh on the community to um to uh help us with new ideas power collaboration in the open source Community yes can yeah I think that's also uh that's a really good point and um I I as a newer cordev um I'd like to say thank you to all you guys who have laid the the road uh ahead of me um and I now get to carry that flag forward um but I think this is a a great opportunity to to ask the community uh you know because we say thank you to you guys all the time and I I think it's really important that we say thank you again um but like you're saying there is uh this fractioning of the space um often for sometimes for not the not within that web three ethos um that uh I think it's a great opportunity for us to say please come back and and uh give us feedback and uh we not only uh are always there on Discord we're always there uh um in our U you know at the community uh events uh we love to hear from you and it's really important for us to get that feedback because the usability of the system is really key um and we're building it for you and uh you know so understanding your use cases and your challenges and and what other opportunities are out there I think not only helps us to to build a better ecosystem but um to really uh build the best product that's possible good so um as a wrap up wrap up uh could each of you share like One Vision that keep you motivated uh to continue your current work [Laughter] just [Laughter] one um yeah I mean I would say um you know it's uh it's easy to get depressed when you look at all the all the bad news in the world um I think we we have a truly unique chance of building something that going to last forever um there's uh there's uh this talk um by Danny Ryan at bota 2 years ago now where he say ethereum is the intellectual gravity well of the of the entire space uh there's a lot of things happening I would not be able to pick a single feature uh they're all awesome most of them will never happen there's so many ideas that fly by and uh uh and come back and disappear and so on um I'm going to say ZK everything ZK related is uh is awesome if we if we could just improve the the security the the Privacy the censorship resistance uh I think it's going to have a huge social impact um but yeah I wouldn't be able to to pick a single one um I'm going to fall back on uh account abstraction um and lowering the the burden of uh of uptake by the next billion people I think uh in order to lever this technology for everybody I think is a huge opportunity um in order to really to grow uh not only the appeal but the usefulness of of this amazing thing that we've built um I think to be in this to be in the space and especially in the C of community you have to be extremely self motivated like it's way easier to make 10 times as much money doing def or doing me or um or doing some doing some Ico or whatever and um yeah I think the division of the future is what kind of keeps us um Keeps Us in this space and keeps us building and keeps us building for something good like I don't want to be I don't want to be associated with um business models that extract the value from the users I want to I want to work on stuff that actually brings value to to people um I want to work on stuff that um I think for the the longest time companies have have extracted a lot of the value from from from normal people and I think uh ethereum and and blockchains are way to give back some of the power to the people and um and I really like that and um the other thing that I that I really like is that we did the merch and we are not as uh energy hungry as some other orange people in the space anymore so uh uh yeah that that was um it was a passion project and uh I think all of the people who who worked on it worked worked day and night it because they uh saw this vision of the future and um the vision isn't there yet um you have you have a you have a great quote about um the the the internet of money shouldn't cost 50 cents per transactions or something um and I and like people the orage people left at that one for five years yeah and and and and people clown on it and I think it's this like this this is it this is like this is the vision like MH no it shouldn't and we're not there yet um and we need to keep building until we are there until we can provide um uh cheap transactions forever um and not like burn out within like 5 years or something because no one is able to verify it anymore and uh we have to have you have to have this huge servers to to compute anything um no we have to build a sustainable future where everyone can transact um and everyone has the right and the freedom to transact however they want and that's uh I think that's that's what keeps me motivations that was an awesome answer thank you yeah I mean I think um in addition to the U you know the money and finance aspects that get um highlighted all the time I mean I see you know etherum as being like one of the standard bearers of you know the open source movement and that's something that I have highly valued since long before I was a part of know the cryptocurrency space you know I know I can still you know run Linux on this laptop it's you know my laptop's been my laptops have been running Linux for about at least 15 years now um going know continue using various open- Source tools and I'm always know still keep you know my music at MP3 files like you know always appreciate things that are actually hackable that actually you know work with standards that don't try to keep you know locking you into all kinds of proprietary ecosystems and I view blockchains as being one of the extensions of that whole Space of values to software that requires collaboration um and uh it's a software where know it's not it fundamentally is not just a thing that you can do on your computer but where it has to involve some kind of persistent interaction between a very large number of users right and uh if you don't do that with chains then you know the only practical way to do that with servers and I you know we see what happens when our basic infrastructure and our basic ability to interact with each other depends on servers um so I look forward to you know building a future that is not just that thank you so much for coming to easte and um thank you for the panel and okay that's it thank you yeah thank you thank you all right