An Ethereum Validator in Every Home: The Road to 1 Billion

Transcript

Hey. Um, morning. Um so question is what it what would it take to uh get ordinary homes and phones to contribute to Ethereum consensus? And this has sort of come from this this tweet from Ethereum Bull who said uh he wanted to live in a world where there was an Ethereum validator in every home. So what would it take to make this possible? um not a dedicated server, not delegated staking, but perhaps a small computer in the home, a phone or a device that spends a lot of time asleep. What happens when it gets to a billion

people? Um so this is some some research that this is based on which is uh decoupled consensus which you heard about earlier. uh execution chain proofs uh sleepy consensus from minimal participation uh and and also aggregations from um postquantum but we'll get into that. So if there were more than a billion staking in identities, 6-second slots enshrine PBS potentially postquantum signatures,

we can't make today's validator system a thousand times larger. Instead, what responsibilities can we do to remove from an individual validator while u preserving what makes participation meaningful and what cannot safely be removed? A billion registered keys is easy to imagine. A billion independently useful, economically secure participants much harder. So we would have a scaling cliff. If we took today what happens today and we scaled it up to a billion validators, 32 slots per epoch, 6second slots, then we have 31 million uh attestations

every slot, which is uh 3 GB of uh signatures every slot. So you'd have to have a 500 megabit per second connection. Well, that's just the the gossip between peers. But then why should every registered validator work in every epoch? And this has sort of been touched on in in the earlier talks. Um but then if we're also increasing that, how small could a stake be? Could we take it down to say 0 uh 01 ETH?

um 1 billion accounts at 10 10 million that would be 10 million ETH seems right. So it lowers the barrier. The minimum balance does not determine sorry we the lower balance we don't want to um determine security. It must not reward creating multiple identities. We don't want to um we don't want somebody to who would normally stake say 16 or 48 E to split it into this um and that would just create undue weight on the

network without doing things. So we want we'd want it to be useful. Um and splitting shouldn't pay you extra. It should still be stated. So we have to separate the stake from the job. Um so your your ownership is your registered stake that's persistent but the availability of who can do duties is temporary. So you you'd come onto the network you'd go off the network. So if you had a phone or a device it could be asleep some of the time. Um you'd have duty selection. So who's chosen for any particular slot to validate the blocks? That would be like

a a sampling um as mentioned earlier with the goldfish uh available chain head slots and then uh credentials who who will be able to sign that could be um changing keys uh scoped and postquantum. So you'd have a fast chain uh which is a much smaller group of sampled people um validating and then the economic finality which is again goes back to more the 2/3 accountable full slot with slashing.

Okay. So you want to pay for useful work that's contributing to security not just presence. So you can be dormant and not be available to do work in which case uh you'd be asleep. There's no duty being accept accepted to and unlike today where you'd be slashing that uh the set that is not online. Sleeping wouldn't wouldn't be a slashable offense. You would just be not available to do work.

Then you'd have uh lightweight which is uh the head votes. Um you would advertise your your duty and then you may be selected and then you would you would get paid for um voting on those those head slots. We don't want to pay for announcing you're online because that's easily gained. You just do it on a heartbeat. You want to reward useful completed work. verify exec uh an execution proof sample DA a head vote payload timeliness observation if resources allow we want to avoid griefing so a small bounded commitment costs delayed eligibility and

cooldowns um so what happens when a phone wakes up so you'd want to say after a week you use a zk K proof of execution history uh which is EIP 4 sorry 8440 uh ex execution chain proofs that makes catch up much quicker but still verifying execution isn't sufficient the device would still need a trustworthy consensus view um validator state current randomness and safe signing history signed duty records must survive when the phone crashes.

Backup restores, intermittent connectivity. Um, and we want cheap verification and cheaper recovery. They're they're related but different problems. Step five, uh, stay awake since the previous slot would then make you available for duty. Um, so after restart, you'd want to keep your your finality site state, your signing records, available chain locks, recorded confirmations, uh, rebuild the rest.

Um, and then things like losing receipt history and immediately resuming duties could produce views that are inconsistent with longunning nodes. There are obviously downsides. Um, so now it's it's not just the attacking stake, but now it's the awake state versus the sleeping state. Um, and so the attacker can have have more weight.

Suppose an attacker has 20% of the total stake, but only 20% of the honest stake is is online is awake. The attacker now has 55% of the stake awake. So that breaks the honest majority assumption used by sleepy consensus protocols like Goldfish. Goldfish uses expiring votes and view merge to to handle this changing participation. But temporary network delays can cause honest uh votes to expire. Um we have expiring locks from EIP 8453 which which helps imp prove that stability.

But we need to allow validators to sleep because it's useful. But security depends on who's awake. Fast fork choice and economic finality therefore need separate security guarantees. As was mentioned in the earlier talk about fast finality, the finality will use different security assumptions from from the available chain head votes. So the fast head is not economic finality. Um, so the the available chain um uses say 512 randomly sampled head votes per slot rather than requiring millions of

assistations. That builds on goldfish. Old votes expire. Proposes help reconcile views and temporary locks protect confirm blocks against missing votes. that makes faster slots more practical, but faster confirmation of the head is not finality. A small committee also cannot automatically inherit economic security of all staked ETH. For example, a thousand uh 10,000 validators staking 0.01 ETH represent just 100 ETH with roughly 33 ETH potentially accountable for a conflicting 2/3 vote.

So that's why we retain we would need to retain full set finality separate from this fast head voting. And the key point is we want fewer messages and faster blocks but without reducing the economic cost of attacking Ethereum. Um in this sort of new world downtime would not be misbehavior. It'd be expected. So you can be asleep accepting no duties and there's no penalty uh for that.

You could commit to doing a duty but miss it and you'd lose your reward or perhaps a small um bounded a availability bond. But obviously if you're doing something like signing conflicting messages then that that would be um that would be provable misbehavior and meaningful stake would need to be at risk of slashing but it separates fast flexible participation from economic finality and it lets us tolerate unreliable devices without weak weakening and accountability. So ordinary downtime type should cost rewards that that would potentially you'd be able to get and malicious

behavior should put your your staking capital at risk. Did I go back? Okay. Um so so let's look at an example. Um you have one side voting um 51% the other side 49. Neither side's reached two/irds. What now? So, traditionally, we'd we'd leak the inactive stake on a network partition. Um, but instead each each side penalizing the the

validators it could not see. Um, but both could eventually penalize uh sorry um finalize through the the conflicting change. One alternative is to freeze the voting weights at the last finalized checkpoint. That preserves the accountable safety but means that finality could stall indefinitely if more than one/3 stake disappears permanently. Um this is sort of a unresolved trade-off at the moment. We need to recover from mass inactivity without allowing the network partitions to create conflicting finality uh aggregation. So today we have BLS. Um tomorrow in the postquantum or post AI

world we have um proofs using PQ signatures. So BLS signatures can be combined into one small signature. Postquantum schemes like lean XMS don't support this directly. Instead we can aggregate aggregate proofs of signature verification. Loc aggregates verify signatures, committee membership, voting rates, and produce proofs. Higher level aggregators combine them recursively uh ensuring no validator is counted twice. And the final result is a compact proof representing thousands of Alex signatures while preserving um evidence needed for slashing. And the key point

is that recursive proofs can replace BLS aggregation and make even larger scale postquantum consensus practical. Um, one downside is postquantum proving is measurable. It's not free. So lean VM uh already demonstrates promising performance on a M4 Mac. It aggregates uh 1,400 postquantum signatures in 1.5 seconds producing a uh 360 kilobyte proof size verif and you can verify that in just 7.5 milliseconds. So

recursive proof merging just takes around 0.3 seconds on top. But one such proof every six seconds would mean 5 point uh 5.3 gigabytes of downloads per day which is far too much for like doing on a phone. So phone should then verify proof selectively with more capable online machines handling aggregation. So you you'd want to split out what you're doing based on the the hardware available. So if you were doing it on a phone versus a server, maybe you you give one harder work and one the other. Um there are also security challenges. Current parameters

target 128 bit classical but only 64-bit quantum security. You it it has um and stateful signatures must never reuse the same signing keys after crashes or backup restores. So we we EIP8 for 50 um explores registering postquantum keys ahead of the mig ahead of the migration. But the key point is postquant postquantum aggregation is becoming practical but bandwidth security parameters and key management still need a bit of work.

So if we scale beyond signatures, reducing voting to a few hundred participants leaves a billion staking accounts to manage. Registrations, withdrawals, rewards, key challenges, and slashing all require updates. Even one update per account per day means over 11,000 updates per second. Uh, Vitalix extremely lean chain explores removing validator accounting and proof generalization for stakers generation for stakers um so we can target millions of validators. Reaching a billion would require scaling that much further.

We'd likely either need batched updates and cryptographic proofs instead of processing every account individually. So scaling signatures isn't isn't enough. We also need to scale validator state accounting and recovery for devices that can spend weeks offline. So what would we need to solve before we could do a billion validators? Uh the three major challenges are first cheap verification. Can the phone sleep for a week, wake up, catch up securely and perform a useful duty? What does that cost in bandwidth, battery and time?

Second, safe intermittent participation. How much honest stake must be awake? How do we prevent predictable committee predictable uh committee selection and make rewards worthwhile for tiny stakers without centralized pools? And third, accountable for finality. Can we manage billions of accounts, preserve slashing evidence, and recover safely if more than onethird of committed stake disappears?

All this must work alongside EPBS, shorter slots, and post quantum signatures. So, we need to make validation accessible without making Ethereum easier to attack. So the so the wrong question is how do we run today's validator protocol a billion times. The right one would be how little work could an independent participant perform while still contributing to general genuine security of Ethereum and how can we make that work accessible without making attacks cheaper.

From this we can get to an Ethereum validator in every home. Uh a validator it shouldn't mean always online server in every home. Imagine a device that wakes up catches up securely performs useful work earns a reward and then goes back to sleep. We need to solve tiny stake economics, sampled committee safety, finality recovery, and postquantum aggregation. But advances in lightweight verification, decoupled consensus, and cryptographic proofs bring this this vision closer. The goal isn't simply a billion validators.

It's an Ethereum where ordinary people can participate independently using ordinary devices in ordinary homes. Thank you. >> All right. Come on. Let's give it up for Ben Adams, ladies and gentlemen. Wow. How can we make Ethereum more accessible for everyone while at the same time not compromising on security? A big question for our core team of developers to really work on, all of us to really participate on together. Now, we've got some great questions coming in. Once again, please submit your questions on the Devcon Passport app powered by Mircat. And also, you can even upvote.

Yeah, for the great questions that you see there. Upvote them so that we can pick them as the most popular. And you also have an emoji. Yeah, you can react with emojis as well. You'll see it come out on the screen. Okay, Ben, first question on the top. Really important question. What is the realistic minimum hardware and bandwidth requirement you envision for a home validator once all these scaling mechanisms are fully deployed? Can it genuinely run smoothly on mobile or low P? What do you think? >> Um yes. No. Um so we know proving an execution proof is like milliseconds. So you can prove the the execution if

you're if you're getting a ZK uh result also with the the lean proofs verifying the proofs >> a lot of the verification can be done done very quickly and very cheaply on a phone. >> Y >> uh the issue is catching up the bandwidth. Um and also we we'd still need large validators, large machines to do like the aggregation of all the signatures and so forth. So it's more it would be more moving to a mixed model of you would be uh assigned the duties based on the the capacity and your your ability to do them. But yes, it should still be able to run on a phone um quite

happily eventually. >> Fantastic. The future of running your Ethereum on your phone. That is an exciting future indeed. Let's go to the next most popular question. This one got quite a few up votes. Ben, what fundamental problem does scaling Ethereum to 1 billion validators solve and what benefits does it really offer beyond the current POS model? >> So, I' I'd turn this around. So, there is a trend to make everything more centralized because it it's just easier. Um, >> so now you have well is it only the builders running the uh building the blocks and the validators aren't aren't building uh now they get all the order flow that's all becoming more and more

centralized. Um if the proofs as we go to ZK proving is it just people with large GPU setups. So is if we're more centralizing can we push back against that and make it more de decentralized instead? >> Yeah I think decentralizing is always the goal right decentralizing while maintaining great security. All right let's go to the next one. This one also got quite a few up votes as well. With potentially a billion validators, how will staking rewards remain economically viable for participants holding just 0.01 ETH? It's a good question.

>> Well, if if 0.01 ETH is a lot to you, then the rewards percentagely presumably would would also be meaningful. >> Yeah. All right. Next one. Let's see. What happens when a phone client is chosen for block proposal and it goes offline? I think you were talking about this at the end of your presentation. Is it passed on and is the slot will not have a block? Right. Or could multiple small clients contribute to proposal? So I think you briefly touched on this on the last few slides. Can you expand a bit more?

>> Yeah. So that would that's the fast finality and the decoupled consensus. So the choosing the head block is separate from finality. the finality would really need the 2/3 majority to say this is the finalized chain. But in the goldfish vote, um they're they're votes that are only transitory and for that block. Um I mean, so EPBS, the builders are doing the block proposal. The phone would say, you know, I've chosen this block. So they don't necessarily have to build a local block.

Um if it goes offline, I suppose that would be the reorg. >> All right, I think we got time for one final question. The one that got the highest votes. Uh let's see this one over here. Absolutely amazing. And this is the dream, I believe. So it is indeed. Possible/realistic we get here in 5 years. What do you think? Fiveyear timeline. Is work on this already happening? Question. and does it integrate seamlessly with lean Ethereum? Take it away. >> Um, so I mean I don't know whether whether this would happen in in in the near future. However, all the pieces are being put together. So if you look at the the previous uh few talks and um

Justin's talk I think coming off after this. Yep. >> And there's a there's a couple more talks later today. All the pieces are being built. They're not necessarily being built for this, but this comes this is sort of like an emergent property you could do from from everything that's being built. So, uh yeah, it uses lean Ethereum in order to do in order for this to be achievable. >> Thank you, Ben. The pieces are being built. Everything is coming together. Let's give our speaker another big big round of applause.