YT YouTube2Text

YouTube2Text → Transcripts → Maximize ETH Staking Returns: Latency Optimization in the $100B Validator Market

Maximize ETH Staking Returns: Latency Optimization in the $100B Validator Market — Transcript

by Optimum · 3,531 words · 578 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:06Welcome everyone. Today, we're
0:08discussing how network latency affects
0:10Ethereum validator revenue.
0:12And specifically, what a 100 millisecond
0:14improvement can mean at scale. I'm
0:16joined by Moritz, research engineer at
0:18Optimism, and Sajida, chief product
0:21officer. Uh they are two of the
0:22co-authors of a research piece Optimism
0:25published recently, along with Slobodan,
0:27our chief economist, and CEO Muriel.
0:30Optimizing a hundred-billion-dollar
0:32market, effects of latency reduction on
0:35ETH staking revenue. Let's start with
0:37the big picture. Why should validators
0:39care about network latency? Isn't it
0:40mostly about good hardware and reliable
0:42uptime? Maybe Moritz, you can uh kick us
0:45off.
0:46>> Yeah, I can. That's actually an
0:47excellent question, right? In a sense,
0:49uh hardware optimization is really
0:51important for uh staking revenue.
0:53However, we're uh hardware and uptime
0:55are basically table stakes. So, most
0:58validator operators have already figured
1:00that part out. Um latency is a different
1:03problem, right? Because when a validator
1:06proposes a block, for example, it has to
1:09uh traverse the Ethereum P2P layer
1:11before other validators can attest to
1:13it. So, how fast that happens
1:16um basically determines and constrains
1:19how much time a validator can use inside
1:21the inside the slot.
1:23And it's outside of the control of this
1:25respective validator, basically. Now,
1:28propose too early, for example, you
1:29leave something on the table. Propose
1:31too late, and your block arrives too
1:32late at other at at other validators to
1:35attest to it. Latency is the constraint
1:37that determines the the outcome in that
1:40sense.
1:41And we wanted to basically find out how
1:43that constraint translates into
1:45different APRs for different validator
1:47operators.
1:48>> Awesome. Awesome. Right, so so I guess
1:51for the audience's sake, it's important
1:52to give some context that as a
1:54validator, most of the time you are
1:57attesting to others proposal and so 99%
2:01of the time you're a tester and then
2:03sometimes you're selected as the
2:05proposer or sometimes people call it
2:07leader of that particular block or slot
2:09and you're proposing.
2:10All right, so so at any point in time
2:12you're playing one of the two roles. So
2:14what I heard you said Moritz is that
2:17this constraints, that is latency,
2:19really exist at the network level is
2:21outside of what any individual validator
2:25can solve. Right? So so Sajida,
2:28is that where Optimum comes in?
2:29>> Right. So yeah, this is not something
2:32that operators can directly configure.
2:35Right? You can choose your Ethereum
2:36client, you can select which relay to
2:39connect to, you can try to optimize on
2:41the infra provider selection, all that
2:43to achieve better performance uh because
2:46that's in your control. But as a
2:48validator, you cannot do anything about
2:50how fast a block propagates through the
2:52Ethereum peer-to-peer layer. It's a
2:54shared infrastructure and that's where
2:56Optimum comes in. With Mempool P2P
2:58protocol, validators just have to run a
3:00simple sidecar that we call a gateway
3:03attached to their beacon node. That
3:05allow them to tap into the Mempool P2P
3:07propagation boost and basically you have
3:10the Optimum network running in parallel
3:12of the existing peer-to-peer network.
3:14Doesn't need to replace it, it
3:15complements it. Operators that we have
3:18testing Optimum on Hoodie right now gets
3:20their block faster via Mempool P2P than
3:22Libp2p over 80% of the time, which is a
3:26significant edge. In the pilot, we're
3:28providing real-time propagation metric
3:30for both the Gossip Sub baseline and the
3:33Mempool P2P. So operators can measure
3:36the advantage directly.
3:38Obviously,
3:39getting the performance results, uh you
3:41know, was an interesting milestone to
3:43unlock, but it also brings up another
3:45interesting question which is what this
3:47research is about. If you improve
3:49propagation latency on Ethereum, what
3:52does that actually mean for validator
3:54APR? So, that's what we're here to
3:56discuss.
3:57>> All right. That's some interesting
3:59observation there, Sreeram. So, let's
4:02talk about scale, right? So, the
4:04research that you have put out really
4:05put this in the context of a hundred
4:08billion dollar staking market for
4:10Ethereum. So, maybe you can give us a
4:12sense of the the landscape, right? What
4:15what are the validators actually
4:17optimizing for here?
4:18>> Yeah, okay. Let's jump into it. Maybe we
4:21can share a quick diagram that will help
4:23us illustrate. What is important to
4:25understand is that validator APR has two
4:28components. On one side, you have the
4:29consensus layer rewards from
4:31attestation, block proposals, and on the
4:34other end, you have the execution layer
4:36rewards that come from fees, builder's
4:38payment. Both are sensitive to
4:40propagation latency, but through
4:42different mechanism. So, on the
4:44consensus side, as we said, faster block
4:47arrival means more accurate and timely
4:50attestation. So, you're able to capture
4:53the rewards that you are supposed to
4:55have as part of your validator operation
4:58because you increase your performance
5:00and because of the latency reduction.
5:02And then, on the execution side, it's a
5:04slightly different mechanism where you
5:07are able to leverage extra slot time to
5:09access better bids and better visibility
5:11into the MEV market.
5:13>> So, it sounds like whether you are a
5:16proposer or attester, there are
5:19different mechanisms for you to, you
5:21know, make extra staking yield. And the
5:24staking yield, as as we know, don't just
5:26come from vacuum, right? They actually
5:27come from these very solid underlying
5:30mechanisms that are kind of built in to
5:34the protocol, and some of it are out of
5:37protocol strictly by definition, but no
5:40matter which one it comes from, the key
5:42thing to remember is that speed matters,
5:46right? So, so, so, how how how we're
5:49we're seeing it is really like there's
5:51really that one thing that speed is
5:53money. So, Moritz, what does that
5:55actually mean in practice for an
5:58operator's bottom line as we look at
6:01translating speed into money?
6:04>> Yes. So, this is the
6:06this is the golden question, right? The
6:08the research that we've done suggests
6:10that
6:11very small improvements in latency,
6:13meaning very very small improvements in
6:15latency, basically already translate
6:17into measurable outcomes or into
6:19significant outcomes, like
6:2150 to 150 milliseconds of extra slot
6:24time by being 50 or 150 milliseconds
6:28faster when proposing or receiving a
6:30block, translate already roughly into 1
6:33to 2% higher revenue for validator
6:37operators. Now,
6:39that is
6:40based on like an historical analysis
6:42that we did across
6:44uh the biggest
6:46validator operators um out there,
6:49which represent approximately 1/3 of the
6:51total stake.
6:53And from the analysis that we did, that
6:55the the relationship is approximately
6:57linear, right? So, we have 50
7:00milliseconds translating into roughly
7:03half the improvement that 100
7:05milliseconds would do.
7:07And
7:0850 milliseconds translate approximately
7:11into 0.75%
7:13more revenue for the
7:16operator, which is already
7:17re-significant, right?
7:18>> Very interesting. Very interesting. So,
7:20so, long story short, right? Every 50
7:23millisecond,
7:24uh that's that's almost 1% improvement
7:27in revenue. So, if we can translate, um
7:30you know, if we can deliver a 100
7:32millisecond improvement, uh that's, you
7:34know, almost doubling that, you know, 2%
7:36revenue. As you mentioned, the
7:38relationship is is is roughly linear,
7:40linear, right? So, um
7:42this is this is a very interesting
7:44observation and I think most people may
7:46not be familiar with that. Right, so
7:48maybe you can walk us through the
7:50methodology or as you said where does
7:52this data actually come from?
7:54>> Yeah, maybe we can mention the the main
7:56sources that we used here. So we have
7:58three main external sources. Zatoo which
8:01is the telemetry database that the
8:03EthPanda upstream has put in place with
8:06many contributors from the ecosystem.
8:08That was very useful. That gave us time
8:11stamped time stamped data on when blocks
8:14are first seen by nodes across that
8:16network. And then we use the Rated API
8:19to track the API for validator operator.
8:23That gave us the economic signal to
8:24correlate it against. And the third data
8:27sample we used was the beat traces we
8:29collected from major relays PBS relays
8:32over a week.
8:33And with all of that, knowing the mum
8:36P2P advantage that I explained earlier
8:38we were measuring with our partners,
8:40that translate basically into the extra
8:43usable slot time that Optimum provides.
8:47Then we're just able to see what's the
8:49correlation between that delta of
8:52improvement and the economic side.
8:55So the way we get that delta is for each
8:57gateway we have a dual path measurement.
9:00We record for each node the gossip sub
9:04and the mum P2P arrival timestamps. So
9:06we have the baseline to compare against
9:08under the same condition and we're able
9:10to do an apple to apple comparison. So
9:13yeah, that's the sort of data landscape
9:15that we were operating within. Maybe
9:18Maurice can add to that.
9:19>> Very interesting. Very interesting. So
9:22effectively we're seeing a parallel
9:25example of a two path measurement
9:29and they happen under the same
9:30condition. Right, so it's really apple
9:32to apple comparison and we also look at
9:36three different independent data sources
9:39that are all talking about the same
9:41question.
9:42And
9:43that would actually bring another
9:45interesting question to me, right? Like
9:46how how do you go from latency data to
9:50an APR estimate now that we can compare
9:54and see the gap in latency. How does
9:57that translate into how much more money
9:59we can help people make?
10:01Uh maybe Morris, you can help us share
10:03some thoughts.
10:04>> So the proxy we took sort of the the
10:06invariant in the network is the P80
10:08latency. So
10:10um this means how long does it take for
10:13a block to reach 80% of the network.
10:15With this being our main metric, we can
10:17say if we improve the P80 latency by 50,
10:22100, or 150 milliseconds, a proposal has
10:26the equivalent budget in time to
10:30additional an additional time to propose
10:32a block, like additional usable slot
10:34time, which according to the
10:37relationship we described earlier,
10:38historically speaking, translates into
10:41additional revenue for the validator
10:43operator.
10:43>> So that's very interesting sharing on
10:46the translation of speed into money.
10:50Again, um I think that's probably the
10:52most important part here. So let's let's
10:53really dive in, right? So so with Mon
10:56Peter Pan delivering two to three x
10:58faster block propagation on the Ethereum
11:01Goerli testnet currently live on
11:03production, let's let's let's unpack
11:05that and think about what actually
11:08propagation in Ethereum means and what
11:10do people do and what happens behind the
11:13scenes when when Ethereum is really kind
11:15of running. All right, so so so behind
11:17the scenes, right? There are um all
11:20these blocks that are moving when the
11:22proposer has to actually propose the
11:25block
11:26uh and and before that it gets it gets
11:27selected,
11:29right? Every uh, every couple uh, ahead.
11:32So, and a proposer gets selected
11:34depending on how much stake Ethereum
11:36stake it has.
11:37And then they propose that vote that
11:40block will need to travel through the
11:41network all over the world to reach
11:43other validators.
11:46They will need to receive it in time and
11:49vote on it depending on whether it's a
11:51good block or a bad block. So, they will
11:54vote yes on the good block and vote no
11:55on a bad block. Um, you know, long story
11:58short. And that vote would again travel,
12:00you know, throughout the world uh, to
12:02reach the vote aggregators. So, so on
12:04and so forth. There are so there are so
12:05many rounds of like these um, you know,
12:08um, blocks that are traveling, votes are
12:10traveling. And it makes the whole
12:13network extremely latency sensitive. So,
12:16knowing that as a context, right? It it
12:19it it it then can kind of helps people
12:21explain why uh, Ethereum itself has
12:24established voting accuracy and you have
12:27to vote on time on target to be able to
12:30help you earn rewards as a validator.
12:32So, that's what people generally call
12:34the consensus layer reward. And so,
12:37Moritz,
12:38as we look into the research,
12:42how does that break down in practice in
12:44how Optimum helps improve the consensus
12:47layer layer reward uh, for validators?
12:50>> This is this is very important now. So,
12:52the um, consensus layer rewards are
12:55actually uh, specifically the vote
12:57rewards that you that you just shared.
13:00They are composed of two aspects. It's
13:02like one, does a validator itself get
13:05the vote right? And two, do other
13:07validators get the vote right? So, in a
13:09sense, if only I get my
13:13uh, vote on the right block, but
13:14everyone else votes on another block,
13:16that doesn't um, translate into higher
13:19revenue for me, but it's like a net it's
13:21a network wide um, it's a network wide
13:23effect. And a an improved network
13:25performance also helps um, an individual
13:28validator in that sense. Now,
13:31the most fragile vote out of these votes
13:36is the so-called head vote, meaning the
13:38vote on the last block,
13:39and it currently sits
13:42at around 99 98.6%.
13:46Now,
13:47we have seen that across the network
13:50with
13:51100 to 150 ms latency improvement, we
13:55can
13:56already roughly half the gap between the
14:0099.6%
14:02and a theoretical upper bound of 99 of
14:0498.6% to a theoretical upper bound of
14:0699.4%.
14:09The 99.4% is due to the missed slots in
14:13the protocol, which
14:15make the vote on the last block
14:16redundant. Now, this is the effect that
14:20an additional 100 to 150 ms improvement
14:22can have on the consensus layer votes,
14:25and this eventually, across the network,
14:27translates into thousands 1,000 to 2,000
14:30ETH more network revenue.
14:33>> Very interesting. So, around 2,000 extra
14:37ETH revenue, right? For all the
14:40validators to share, and eventually can
14:43be shared back with the stakers that
14:45stake with them. So, these are
14:47significant money that are left on the
14:49table, basically not captured by anybody
14:53just because the network is slow these
14:55days.
14:56So, that's really fantastic fantastic on
14:59the on the consensus layer side. So, as
15:02we kind of explored before, when we look
15:05at the charts, the the APR is broken
15:08down into the consensus layer side and
15:11the execution layer side. So, let's now
15:13talk about the execution layer side. It
15:16happens only when the block
15:19only when the validator is proposing,
15:21and all the execution layer reward goes
15:24to the proposer, which is one party, for
15:27that particular block.
15:29Right? So, so Gina, maybe you can help
15:31us
15:32understand
15:34as Optimum provides these
15:36speed benefit, how does that translate
15:39into value for this particular proposer
15:43for that particular block? And, you
15:44know, kind of how this works
15:46as the proposer rotates from block to
15:49block. And then you know, effectively
15:52how this translate into APR improvement
15:54for all the validators that are using
15:55Optimum.
15:56>> Right.
15:57So,
15:58on the execution layer side, things are
16:01a bit different. That's where MEV comes
16:03in. So, the way it works under the PBS
16:06model is that as a validator you're
16:09running a sidecar, you're getting bids
16:12from builders through the relays. You're
16:14selecting the one that is the most
16:16advantageous and once you commit to it,
16:19the relay are going to package the
16:21payload and then the broadcast happens
16:24and the block gets published and then
16:25the race begins that the blocks get sent
16:27by a good share of the network before
16:30the 4-second deadlines that you're not
16:32getting reorged. So, the tension here is
16:35that you need to select your bid and
16:38ultimately trigger the the publication
16:41of the block in time so that you don't
16:43miss that 4-second deadline. If you do
16:45it too early, you might be selecting, as
16:48we can see here in the diagram, each dot
16:50here is a bit might be selecting a bit
16:52of a lower value. Though, it would be
16:55safer for your deadline. If you do it
16:58too late, you might be accessing a bit
17:00of a higher value, but will you make the
17:02deadline in time?
17:04So, that's the sort of dilemma that a
17:06proposer face.
17:08Why is this interesting? In the sample
17:11that we collected, we were able to see
17:13that the uplift can go
17:16as high as 30% to 16%, which is quite
17:20meaningful. And even though being a
17:22proposer is a rarer, you know, event and
17:26duty compared to the attester, over a
17:29fleet of validators that most of the big
17:32operators operate, it gets statistically
17:35meaningful. And even more interesting,
17:38due to due to the volatility of MEV,
17:41some slots can see up to 20 times higher
17:46bid. If you're able to leverage that
17:48extra slot time to select a more
17:51efficient bid. So, there is a very
17:54significant portion of the pie here that
17:57could be made accessible to the
18:00operators and, you know, to all of the
18:02stakers and and, you know, people
18:05working with them.
18:06>> Right, right. So, what I'm hearing is
18:08that, you know, there's a bidding system
18:09that's going through life, uh and, you
18:12know, some of the audience might have
18:13heard of
18:14the the the term PBS, which stands for
18:16proposer builder separation. Um so,
18:19there are, you know, these builders that
18:21are building the blocks
18:23um that gets pushed to the to these
18:25proposers that are basically um
18:28receiving the bids from the builders,
18:29right? And and and assessing and
18:31checking which bid they will commit to.
18:33And indeed it's this extra time
18:36uh that we give them as advantage
18:38because they can afford to now select a
18:41bid
18:42a little bit later. So, they can select
18:45the more profitable bid on average
18:48compared to before. And and that is
18:50really the the key unlock here. Uh and I
18:53I really like that explanation. It's
18:55it's um it really brings out this nuance
18:57really well, so which which is on the
18:59execution layer side. Um and and this
19:01bid uh
19:03it translate into into extra APR, and
19:07people may may may may know of this from
19:09other terms, for example, MEV is really
19:12what we're talking about here. Like the
19:13bid like a bid value and the MEV is
19:16really interconnected. All right, so the
19:17more time that you have basically allows
19:20you to also
19:22achieve a higher MEV from here that
19:25eventually you can you know distribute
19:28with your stakers.
19:30>> Yeah, and I think what's important here
19:32also is that
19:33you're allowed to optimize for your bid
19:36selection while maintaining the safety
19:38like within the constraints of the
19:40protocol. So it's not about adding more
19:43risk. It's really about unlocking for
19:46the operators extra usable slot time
19:49that was not accessible before allowing
19:51them to make you know better more
19:53optimized decision.
19:56>> Right. So expanding the opportunity you
19:59know space for them to win
20:03So let's let's wrap up.
20:07We'll have to hear one takeaway from
20:09from each of you.
20:10During the the research, is there what
20:13was the most unexpected finding? So
20:15Moritz, maybe you can go first.
20:17>> Yeah, that's uh
20:18Um the the that's that's a good
20:21question. Um
20:22For me at least the the most interesting
20:25finding was we going in we expected
20:28there to be
20:29um a lot of potential on the execution
20:31layer side
20:33due to the mechanism described by
20:35Sashida.
20:37What what surprised me the most was how
20:41much there is to gain on the consensus
20:43layer side, right? We talk about
20:46the vote accuracy already being at 98.6%
20:50already on average, you wouldn't expect
20:53there to be 1,000 to 2,000 ETH gain
20:56potential in the whole network. And this
21:00sheer fact was was one of the one of the
21:02most surprising things to me.
21:04>> Interesting. So this extra 2,000 ETH,
21:08you know, additional for for annual
21:11network revenue,
21:12it's really a major unlock. Sajida,
21:15what's your what's what's what surprised
21:17you?
21:18>> First of all, I think it was easier to
21:20reason about the execution layer side,
21:23right? Because you have all those big
21:24traces, so you can always say what would
21:27have happened
21:28if I had, you know, an extra 50 100
21:31millisecond. So, that was very
21:33interesting from an analysis standpoint,
21:35and then what we saw is how heavy the
21:38tail was on the MEV side, which is often
21:41something that is considered a downside
21:44because of the volatility. But, another
21:46way to see it is how much of upside
21:49there is to unlock here. As I mentioned,
21:51some, you know, the the most optimal
21:54beat that, you know, might have been 50
21:56millisecond later could be up to 20 time
21:59the beat that was selected. So, I think
22:01this is non-negligible and really speak
22:03directly to the core
22:06you know,
22:07business priority to a lot of the
22:08operators. I think over the sample that
22:11we collected, roughly $400,000
22:16due to beat uplift could be unlocked for
22:19all of the proposer within that time
22:21frame. So, yeah, pretty interesting
22:23results.
22:24>> Great. So, it's a really fantastic
22:27discussion. Again, the the full blog
22:29post that many of the results were
22:32presented and the ETH research paper
22:35can be both found in the description.
22:38So, thank you both, Moritz. Thank you,
22:40Sajida. Feel free to like, comment, and
22:43subscribe to this episode,
22:45and we'll see you in the next one.

About this transcript

This page contains the full transcript of Maximize ETH Staking Returns: Latency Optimization in the $100B Validator Market by Optimum, generated from the public captions YouTube serves with the video. The transcript has 3,531 words across 578 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.