YT YouTube2Text

YouTube2Text → Transcripts → Speed is Money: Pricing Innovation Under Latency Constraints | Ft. Tarun Chitra

Speed is Money: Pricing Innovation Under Latency Constraints | Ft. Tarun Chitra — Transcript

by Optimum · 8,041 words · 1,328 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:03[music]
0:11>> Hello everyone um and welcome.
0:14In blockchain systems, millisecond is
0:17not just a millisecond in the truest
0:19sense of the word,
0:21it's the fact that speed is money.
0:24Validator or trading, few milliseconds
0:26can be the difference between capturing
0:28a reward or trade or missing it.
0:32We have recently, with my wonderful
0:34collaborators who are joining me today,
0:37uh published a paper which asks a simple
0:40but fundamental question
0:42which has massive implications. If you
0:44do faster data delivery, how does it
0:46create economic value? And also, how
0:49should that value be priced? So, that is
0:52the core idea behind the work we've done
0:54together and that we're discussing
0:56today. It's called pricing innovation
0:58under latency constraints, a mean field
1:01analysis of coded payload delivery. Can
1:04sound like a bit of a mouthful, uh but
1:06as we'll see, it's fun, intuitive, and
1:09actually very intriguing.
1:11The question's the following. If a
1:12coding scheme is improving the
1:14probability, i.e. the reliability, for
1:17useful data to arrive before a deadline,
1:20how much is that improvement worth? And
1:22this really matters because crypto
1:24already has a fin- financialized block
1:27space. It has already a financialized
1:30order flow.
1:31But what it's somewhat missing is a
1:33financialization of time, of latency, a
1:37latency marketplace. Specifically, who
1:39gets useful information before a
1:41deadline and how can people use it?
1:44That question matters. Blockchain
1:46systems are full of hard timing
1:49constraints which generally originate
1:52from the protocol themselves. So, let's
1:54look at Ethereum, for instance.
1:56Most people know Ethereum has a
1:5712-second slot. Validates need to
1:59receive, validate, attest in time.
2:03There's a large amount of work going on
2:06in this
2:08with EIP 4844.
2:10There's large data payloads which then
2:14are going to affect these delays because
2:16of congestion, other aspects. So, you
2:18know, it's a very rich type of
2:21considerations that people are looking
2:23at. And the way the data is delivered,
2:27it's not just basically, okay, and then
2:31you do the networking. There's not just
2:33a detail or just
2:36you know,
2:37appendage to what we do. It's actually
2:39core to the engineering design choice.
2:41So, that's what we're going to talk
2:42about today and I'm Mureal Matart
2:46and CEO co-founder of Optimism.
2:49And I'm joined today by my three
2:51collaborators as I mentioned before, uh
2:54three wonderful people who bring a
2:56different angle to this work which is
2:58part of why I'm so excited about this
3:00work about how rich
3:02and multifaceted it is. So, the work is
3:05timely as I mentioned because there's
3:07the convergence of Ethereum moving into
3:10more data around time-sensitive paths.
3:13The whole aspects around MEV markets
3:15which have already priced latency in an
3:18informal way.
3:20And then the more
3:22you know, maybe
3:24unexplored part which is the coded
3:26delivery part
3:28which of course is core to what we do at
3:30Optimism
3:31but also is often not explored in a way
3:35that's very accessible or very usable.
3:38So, first I'd like to introduce Tarun.
3:40Tarun Chitra is the founder and CEO of
3:43Gauntlet. Tarun maybe doesn't need any
3:45introduction but we'll introduce him
3:47anyway.
3:48And Tarun, you have spent years thinking
3:50about incentives, risks, market design,
3:52DeFi systems.
3:54uh Uh you know, your work has been
3:56highly influential and uh highly also
4:00pre- uh prescient. Uh how does this
4:02paper
4:04uh
4:05fit uh in that vision that you have uh
4:09of what's going on in crypto?
4:11>> Yeah, thanks a lot, Mireille, for the
4:13the kind words. Um I
4:16I think one kind of interesting thing
4:18about crypto markets versus traditional
4:21finance markets is
4:22you can often times use constraints
4:25enforced by cryptography or distributed
4:28systems in terms of
4:30um you know, relative ordering of
4:33transactions and sort of
4:36you know, understanding of different
4:37types of participants participants'
4:39incentives to really model how, you
4:43know, users will behave and also how you
4:46can constrain what types of things users
4:48can do.
4:49Um
4:50one place where that has not been true
4:52has generally been the
4:55uh the final latency races um that exist
4:58where, you know, the the time between
5:00when a user submits a transaction and a
5:03user's transaction is accept- accepted
5:05by, you know, a network set of
5:06validators.
5:07And that latency over time has like has
5:10evolved where, you know, in 20
5:13>> [clears throat]
5:13>> 2018,
5:14you know, in Ethereum, most of that
5:16latency was spent in how much you could
5:18spam the blockchain and send your same
5:21transaction repeatedly and how fast you
5:24got into a block was how much you could
5:25spam. Whereas today, you know, there's a
5:27very complicated set of
5:30actors who are, you know, relaying your
5:32transaction, bidding with your
5:34transaction to get it into a block. Um
5:37and one interesting thing is this
5:39evolution over the last five or six
5:41years in terms of how latency impacts
5:43transactions for end users
5:46um
5:47has changed a lot, but people have sort
5:49of only talked about it informally,
5:50right? There's there's been these huge
5:52market structure changes, but they've
5:54never been, you know, very clearly
5:56formalized.
5:58Um
5:59you know, a lot of those changes are
6:02faster relays. So, relays are sort of
6:04people conveying blocks or transactions
6:06to validators or or users who have sort
6:09of a privileged right to produce the
6:11next uh confirmed block.
6:14Co-location sort of being near these
6:16validators and being able to have lower
6:18latency. Obviously, we know that means
6:20lower latency, but what is the, you
6:22know, benefit from that?
6:25Um as well as sort of private order flow
6:26sort of arrangements between wallets and
6:28other types of strategic users um
6:31to to land transactions in.
6:33Um
6:35the hard part is formalizing the
6:36economic value of being faster or slower
6:39and and who captures it. Now, I want to
6:41make an analogy to the traditional
6:43markets where
6:45some of these types of changes have not
6:48worked out as well. You know, a common
6:51change you may have heard of um you
6:54know, around the time say the book Flash
6:56Boys uh Flash Boys came out in 2008,
7:002009 was that
7:03you know, hey, we should just add speed
7:04bumps at stock exchanges so that, you
7:07know, when I send a
7:09order, I have to wait x 100 milliseconds
7:13before my order goes through. There's no
7:15There's no sort of And the hope was
7:17that, hey, we would stop the latency
7:19races.
7:20Now, inevitably, someone would make a
7:23new exchange that didn't have that. And
7:25then, people who are arbitraging the
7:28exchange with the the latency delay and
7:30the arbit- the exchange with no latency
7:31delay were taking advantage of the users
7:34who are trading at the the place with
7:35the latency delay.
7:37And in the decentralized world, this is
7:39an even bigger
7:41you know, you have to assume that is
7:43going to happen always, right? If a
7:45certain exchange, certain decentralized
7:46exchange says, "Hey, we're going to slow
7:48down users or have some type of latency
7:50bump." Or an RPC says, "We're going to
7:52slow down users." Well,
7:55then there will be someone else who, cuz
7:57it's open source code, who copies it and
7:59removes the speed bump and it it gets
8:01launched. So, you have to think about
8:03sort of the economic consequences of
8:04these. And so,
8:06I think the interesting thing in crypto
8:08is you can use cryptography and
8:11technology to sort of enforce some of
8:13these constraints. And I think
8:15a lot of the way
8:17Muriel has been thinking about this
8:19in network coding ecosystem for years is
8:22actually a certain type of constraint
8:24that maybe you can you can kind of get
8:26the both best of both worlds in in the
8:28way traditional finance doesn't have.
8:30>> That that's great. Yeah, thank you so
8:32much for for that insight. And I think
8:34you it's it's a perfect segue into
8:36chatting with Moritz because one of the
8:38things you brought up is effectively
8:41the coding, you know, which is the
8:44algebraic manipulation of the data to
8:46make it more reliable, faster, more
8:48efficiently represented, um actually
8:51removes constraints.
8:53Um one of the difficulties, of course,
8:54is, you know, how do actually represent
8:57the removal of constraints because very
8:58often we think of coding as being, you
9:00know, um highly complex, uh often
9:03basically combinatorially scary. Um and
9:07that's one of the things that the paper
9:08really tried to address was to sort of
9:11step away from that complexity
9:14um with, you know, a fluid approximation
9:16that was uh that was meaningful. And uh
9:19with that, I I'd like to turn to Moritz
9:21and and hear, you know, your take uh on
9:24that aspect of the
9:26>> Yeah, um
9:27thanks. And no, that that's definitely
9:29very interesting part of the paper. So,
9:31usually when you think about how
9:33information flows in networks, you would
9:36have to think you would believe that it
9:38would be very complex to
9:40explicitly model like all of those
9:42different how those different kind of
9:45schemes translate into into latency.
9:48We took like a very very simple
9:50approach. I would believe that is kind
9:52of irrespective that of the specific
9:56topology and everything underneath it.
9:58And we just
10:00basically from perspective of a single
10:02node looking at the information that
10:05this node receives, how is the decoding
10:08time
10:10sort of modeled and and distributed. And
10:14I think the the interesting step now
10:15from everything that Tarun also said is
10:17kind of what is the link to the kind of
10:21intuition that we have for and how
10:23latency translates into economic
10:25utility. And finally into like what what
10:29are these participants able to price? I
10:30think that's sort of the span of this
10:32paper.
10:33Um and we
10:35are going to dive into it today.
10:38>> Yeah, no, that's great. And actually
10:39this brings me to Sreeram. So Sreeram,
10:42you know, you you you like the elegant
10:44math as much as the next researcher.
10:47Uh but you are at your core
10:49a product person. And so how do you see
10:53this not just as a wow, this is super
10:56elegant, but this is something people
10:57want to buy?
10:59>> Yes, I mean I think that's a fair
11:01question. Um you know,
11:03people will not buy a coding scheme.
11:07What they want is, you know, higher
11:08probability of reaching better outcomes.
11:11So the question becomes, you know, how
11:13as a validator am I going to get this
11:15reward for my attestation? As a
11:17searcher, how to get my bundle included
11:20in the next block? Um so it's shifting
11:24the conversation from, you know,
11:26blockchain as distributed networks where
11:29latency throughputs are performance
11:31metrics to track to something that is
11:34actually shaping the economic uh
11:36incentives and the behavior of those
11:38actors. And I think this is quite
11:40fascinating.
11:42Uh The other thing is that um Ethereum
11:44does not reward averages. It's a very
11:47like there are many binary outcomes.
11:49Like you're either on time or you're
11:50not. You either get your reward or not.
11:53You get included in that slot or not.
11:55And so um
11:57you're not slightly worse off if you're
11:59late. You might be getting nothing. And
12:01so it's actually interesting that uh
12:04latency is something so core to
12:06everything that we're doing in
12:07blockchain, but is sort of like an
12:10informal force uh that people are are
12:13are discussing. What I like about uh
12:16this effort that uh we did here in this
12:18paper is trying to link this important
12:21uh aspect, which is latency, to the
12:24actual value and outcomes for the actors
12:26that are part of this blockchain system.
12:29>> That that's a great framing. Thank you.
12:31Thank you so much, Sajida. And and I
12:33think uh you know, uh going back to uh
12:36what we said about Ethereum before, uh
12:39that cliff type of uh
12:41behavior is very clear there. You have
12:4312-second slots. Uh in each slot,
12:46validators need to observe the block,
12:47validate and broadcast your attestation.
12:50You know, it all has to get done.
12:52Uh and you don't get any prize for
12:55almost getting it done on time, you
12:56know? It's just you you get nothing. On
12:58the other hand, you don't want to get it
13:00all done ahead of time because then you
13:02might be missing a lot of opportunities.
13:04Um you know, basically this is also what
13:06we see in MEV markets. Searchers are
13:08looking for opportunities. Uh and they
13:10need to uh do that before the builder
13:12finalizes the block. So everybody's
13:14rushing around within this block with
13:16this deadline. Um and so this cliff
13:20structure, which in a way is different,
13:22I want to hark back to what Tarun said
13:24before
13:25about the some of the differences the
13:27classical markets, uh this cliff
13:30structure, what would you see it's so
13:32important uh in
13:35uh in the crypto market, Tarun?
13:37>> Yeah, I think, you know, historically,
13:40uh
13:41you know, it changes sort of the notion
13:43of of value very much like,
13:45you know, a plane ticket is valueless as
13:47soon as the plane leaves the gate. Um
13:50yet, right before it takes off, there
13:52can be a huge amount of value, right?
13:54So, this this gap where something
13:56suddenly goes to zero is is is quite a
13:58big difference in a lot of markets.
14:01Um
14:02in such a market, obviously,
14:03you have some incremental value with
14:06incremental speed, but the problem often
14:09times is that, you know, time is sort of
14:11a a continuous variable, so you can bid
14:14at any time effectively. Um yet, you
14:18have this sort of discrete
14:19uh kind of constraint of like, you need
14:22to make your transaction in before this
14:25kind of interval, which itself could be
14:26slightly random.
14:28So, this sort of means your value has
14:31this kind of discontinuity where it
14:33where it jumps to zero in the sort of a
14:34step function. Um
14:37now,
14:38one important thing to note in these
14:41types of markets is,
14:43you know,
14:44the there's sort of a question of
14:47the average latency you have. So, you
14:49know, maybe an average user who's using
14:52a MetaMask wallet might care about the
14:54average time their transaction takes.
14:56They're not necessarily trying to win
14:58every block. They're not necessarily
14:59trading every block. On the other hand,
15:02professional traders
15:04don't care about the average. They
15:05actually care about getting their trade
15:07in exactly at the time when the
15:10validators are running the slowest
15:12because there's huge demand, right?
15:13That's probably the time that the assets
15:16are going up or down the most.
15:18Uh and so, really understanding the
15:20tails of these distributions and the
15:21probability of getting in conditional on
15:24there being a lot of traffic is actually
15:26quite important.
15:28Um
15:28>> No, that's and that's that's exactly
15:31also why the coding scheme matters,
15:32right? Because
15:34uh it's it's really affecting not just
15:37the average
15:38uh but that variability as you were
15:40saying, right? It's you know, the the
15:42the tail really really matters. Um and
15:46you know, we we think a little bit about
15:48um
15:49what things are happening again just to
15:52to ground it in an example, what's
15:53happening in Ethereum. Uh blob carrying
15:56transactions, you know, the those blobs
15:58are large data payloads. Um and you
16:01know, that's moving more data into the
16:03consensus critical path. It's actually
16:05changing basically where congestion
16:07happening and changing what the effect
16:10of coding is to relieve that congestion.
16:13Um if you think of actually coding being
16:16used directly, you see this in pure DAS
16:18or in EIP-7594,
16:20which is going further, their validators
16:22are relying increasingly
16:25on just receiving enough sample of coded
16:26data in time uh to make the right
16:29decisions. So, you know, to a large
16:32extent the delivery has been getting
16:34more and more attention. It's not just
16:37oh, now send the data. It's like, well,
16:39how you're representing the data? How
16:40are you aggregating the data? How are
16:42you actually ensuring that the data gets
16:45there? Um and so, again, the data
16:48becomes
16:49data that has a really hard sell-by date
16:54um and an economically relevant cutoff.
16:57Uh maybe Sajida, do do you want to jump
16:59in again on this aspect?
17:01>> Uh yes, actually on the two points that
17:03you mentioned, uh some interesting
17:05facts. So, uh the blob market has been
17:09um actually slow to take off and
17:11surprisingly it is not uh
17:14a demand
17:15uh issue.
17:16Uh it is because
17:18rational actors,
17:20you know, builders that have to compete
17:22in those,
17:24you know, races,
17:25have found that it was less economically
17:28valuable to include those because, you
17:30know, obviously you increase the
17:31payload, it means you have more data to
17:33transmit, you get slower, also increase
17:35the simulation time. So, at some point
17:37you have to decide, is it worth it to
17:38include even if it means more reward or
17:40to just disregard them
17:43for the moment and try to build a block
17:45with other transactions that are a bit
17:46lighter and and easier to
17:48to manage. And so,
17:51this is an interesting
17:53example of how
17:55this latency that we're mentioning
17:57is impacting a market where actually
18:00people are looking to adopt blobs and
18:03some people are producing blobs, but
18:05they're just not getting included. And
18:06so, this is a reality in Ethereum right
18:08now.
18:09I pure dust is also a good one.
18:11Actually, the the core devs are looking
18:14at removing
18:15some of this data propagation from the
18:17consensus critical path because of, you
18:19know, this issue that we're mentioning.
18:21So, Ethereum roadmap upgrades after
18:23upgrades is getting into like
18:26there's more pressure coming on the
18:28propagation layer and it needs to be
18:30addressed and it needs to be addressed
18:32quickly.
18:34>> Absolutely. And and I think, you know,
18:36one of the ways we've seen that
18:39addressed, I want to hearken back to
18:41something Tarun pointed out, which is
18:43colocation. You know, to a large extent,
18:45colocation seems to
18:47go against the whole point of
18:49decentralization. I mean, if we all
18:51colocate inside a room, are we really
18:54decentralized or is it just, you know,
18:56one set of people inside a room.
18:59I'd like to hear your take on this,
19:00Tarun.
19:02>> Yeah, so I think certainly the there's a
19:04lot of centralization pressure from from
19:07colocation. This also happened in the
19:10traditional markets. I think actually
19:13around the time people were trying to do
19:15the
19:16the these speed bumps I was talking
19:17about earlier, that was around the same
19:20time people started co-locating and
19:21then, you know, all the exchanges, you
19:24know, there are exchanges across the US
19:25prior to 2006 in in every city and then
19:28they all co-located to
19:30two data centers in
19:32New Jersey and outside of Chicago by
19:352010. Um and part of it just became this
19:38pure latency race meant that you weren't
19:40competitive unless you were, you know,
19:43physically in the same place, which
19:44naturally is a centralization vector,
19:46right? There's only two data centers
19:47where where everyone's trading.
19:50Um
19:51in in the decentralized system, it
19:52becomes even harder because in a lot of
19:54ways
19:55you can't precisely measure everyone's
19:58latency at every point in time because
20:00you don't know all the participants in
20:02the system. It's a permissionless
20:03system, people will come and leave. Um
20:05you you might not be able to have a
20:07perfect map with very low um
20:10you know, low error in understanding
20:12this.
20:13Um for MEV, this is very obvious, right?
20:16Like everything there is really about
20:18being the first one to get a transaction
20:20in to extract the highest value.
20:23For validators, it's
20:24it's more subtle, but certainly very
20:26real.
20:27Um you know, as a validator, you you
20:29know, you have you're you're offering a
20:31service to your users, you have a bunch
20:32of SLAs, you want to be able to offer
20:34them low latency, you want to make sure
20:36you don't drop their transactions, you
20:38want to make sure they can get the best
20:39price thing.
20:40Um without being able to
20:43exactly quantify that for your users,
20:46uh
20:47your users have to hope that you do that
20:49and in order and and effectively pay you
20:51because they think that you'll be able
20:53to do that. So,
20:54the latency problem is not just a pure
20:57performance problem, it's it's also
20:58about market structure um and and sort
21:02of in some ways fairness for users.
21:05>> Yeah, and to add on that,
21:07it's interesting because we
21:09we've seen studies and and data around
21:12the fact that validators,
21:14you know, related markets and other
21:16actors of the PBS chain are
21:18concentrating around the
21:20Atlantic corridor. And this is not a
21:22coincidence as we just mentioned, it's a
21:24rational response, let's say. And so
21:28this this pressure that we were
21:30mentioning already has this geographic
21:33expression. And so
21:35there was some research done recently
21:37that was calculating a liveness
21:39coefficient showing that in the current
21:41state of things one region
21:44out what region outage, let's say, of
21:47the Ethereum network would cause the
21:49chain to halt. So,
21:52this is a critical problem right now.
21:55We're mentioning specific actors of the
21:57PBS supply chain, but at the scale of
21:59the protocol, the network, and the
22:01mission, it is also
22:03I would say an existential risk.
22:05>> Absolutely. Yeah, and and and again,
22:08this is where the aspects around coding,
22:11which we'll get into now a little bit
22:12more, really come in. It's around, you
22:15know, coding mechanisms have been to a
22:17large extent
22:18created exactly for the purpose of
22:21reliability and
22:24robustness
22:25under the face of failure. So, let me
22:29maybe redirect a little bit again to to
22:31the core of the paper.
22:33And one of the things that that we do
22:35here is we provide
22:38a taxonomy which I'm hoping is going to
22:40be a taxonomy that's
22:42useful not just for this paper, but in
22:44general in terms of thinking
22:46about the problem and really sort of
22:48putting a framework that's more general.
22:50And we we look at four ways, right, of
22:52delivering a payload.
22:54One is, let's say, just unchartered
22:56delivery. Basically, the payload is the
22:58message. And it's it's if you will the
23:01simplest
23:03but the problem is that it has a bad
23:05tail going back.
23:07To what Tarun mentioned about the tail,
23:10you know, sometimes because you know,
23:12you don't have a very fluid way of
23:14distributing the message, the tail can
23:16be bad.
23:18So what people have looked at of course
23:19is sharding so chopping up the message
23:23and now you get something that's more
23:25fluid
23:27but you get a problem that your
23:28completion time is governed by the
23:30slowest piece by the last piece to come
23:32in the last piece of the puzzle.
23:34And so people have looked in order to
23:38remedy this to fixed rate erasure
23:41coding. So probably the more well known
23:43one is Reed-Solomon. We mentioned in
23:46passing pure DAS.
23:48It uses Reed-Solomon as most DAS
23:52systems out there do now.
23:55And the idea is you encode a bunch of
23:58shards say K
24:00source pieces into N pieces so K and N
24:03is the sort of the customary notation
24:06for this.
24:07And then as long as I get any K out of N
24:10I'm okay. I can I can reconstruct the
24:13the data.
24:14You can also have more sophisticated
24:16approaches which are called rateless
24:18coding where you still have a fixed K
24:21but the N can be variable. So the N
24:23might be very close to K when the
24:26network is let's say in a very benign
24:28condition.
24:30It might have to be much larger than K
24:32when the network is more challenged.
24:34And in specifically what we look at here
24:37is a randomly network coding RLNC which
24:40was developed
24:41right here
24:43in in this in in this lab
24:46at MIT.
24:48But basically while you could also use
24:51RLNC
24:52as a fixed rate erasure coding such as
24:54Reed-Solomon, it has a lot more
24:56flexibility. Um and um you know, I I
25:00just mentioned RLC, but I I'd love to
25:02hear somebody explain RLC and I'm
25:04worried so I'm going to put it on you.
25:06>> Sure. Okay.
25:07Yeah, I mean, I guess the simplest way
25:09to explain RLC would be that instead of,
25:13like you said before, I'm going to
25:14collect specific pieces
25:16um might they either be fixed rate coded
25:19or um also uncoded of my original data,
25:22I'm going to collect equations and the
25:25kind of coefficients to these equations
25:27and this is kind of the one of the very
25:30very interesting fact with RLC. They can
25:32be chosen kind of randomly
25:35um without coordination between actors
25:36or anything.
25:38And with high probability, with very
25:40high probability,
25:42I can just collect K equations, like
25:45only as much as I need, and all of them
25:47will be um
25:48informative for me.
25:50Now,
25:51um
25:53this kind of um changes the completion
25:56time distribution from, okay, now
25:59if I don't code at all, I'm going to be
26:02um dependent on the slowest shard to
26:05um
26:06now I only need any K shards sort of
26:08that uh that I receive. Um so, this kind
26:12of shows the effect of um how RLC can
26:15protect against um erasures or in this
26:18case actually excessive delays if we as
26:20we've modeled them.
26:23>> No, that that's uh that's the key point
26:25um and that also goes now into the
26:29aspect which again, going back to
26:32Tarun's uh mention of, you know, the
26:34tailing, the tail of those distribution
26:36and the reliability.
26:39At high service levels, especially
26:41around the 95th percentile, RLC can
26:44reach the deadline reliability target
26:46much much faster. And this also obviates
26:48some of the issues that Sajitha
26:50mentioned around people being worried
26:53about blobs, not because there is a
26:55demand, but just because, you know, the
26:58blobs are scary. Uh they they they big,
27:00they're unwieldy, and you know, what
27:02what's going to happen there? So, you
27:03know, kind of uh be be be aware of the
27:05blob. Um and uh
27:08that service level reliability
27:13um I I'd like to hear Sajida, your
27:16product takeaway on that reliability.
27:19>> Yes. Yes. I I think this is where it
27:21gets interesting because the the first
27:24layer of understanding is more speed is
27:27better. But once we understand that um
27:31the Ethereum supply chain is basically
27:34filled with those invisible deadlines,
27:36then we can see that looking at average
27:38speed metrics would hide the risk. The
27:42risk is, you know, not that your data is
27:45arriving early or late. It's that you
27:47can never predict it. And so, because of
27:49that, you have to hedge, uh and you have
27:51to Basically, you're not able to
27:53optimize for the best outcome just
27:55because you're worried about missing
27:57that deadline.
27:59Um so,
28:00within a deadline-sensitive system, what
28:02we're looking at is actually variance.
28:05One thing that uh Erlang C, once we
28:07implemented it and tested it uh with our
28:10our partners at Optimum, what we saw is
28:13that not only do we get a speedup, but
28:15we also get uh seven times less
28:17variance. And that is where it starts
28:20becoming practical because once we
28:22reduce the variance once we increase the
28:25the stability, then um
28:27uh there is no rational reason to hedge
28:31as much as current actors do. And that
28:34can open up to new interesting
28:36economics.
28:39>> I'd love to hear Tarun's view on the
28:41economics. I know this is something
28:42you've thought about very very uh
28:45deeply.
28:46>> Yeah, so I think an interesting aspect
28:48of of colocation of like why people
28:51colocate, why do people want to be very
28:53close is, you know, the closer you are,
28:55the less uncertainty you have. Like the
28:57less variance on your average
28:59transaction, you know, kind of akin to
29:01what Sudeep just just mentioned. But
29:04also the worst
29:06catastrophic or tail events, right? Like
29:08if if I if I am in the same data center,
29:11the likelihood it will ever take me tens
29:14of seconds for a packet to be to to
29:17reach the destination are very low.
29:19>> [snorts]
29:19>> Um and and and so that's sort of this
29:21tail event. Now, um
29:24you get a very different market
29:25structure though when all market
29:27participants participants are forced
29:29into the same that same environment, and
29:31then all of a sudden there's not so much
29:33of economic rationality when bidding.
29:36People are not bidding with what they
29:37think the thing is worth. They're
29:39bidding with what they think everyone
29:41else's latency advantage or
29:42disadvantages.
29:44And so then you go from being
29:45economically rational to sort of like
29:48latency guessing. You're you're sort of
29:49trying to guess what everyone else is is
29:51bidding. And so then you start losing
29:54economic efficiency, right? People
29:55aren't bidding with what they think the
29:56true value of the item they're bidding
29:59on is, they're bidding on what they
30:00think everyone else's bet on
30:03arriving in time is. And in these
30:05repeated games like a blockchain where
30:08there's, you know, it's almost like a
30:09repeated auction that's happening
30:11regularly.
30:13Um these types of uh effects kind of
30:16start to ossify and and calcify over
30:19time where people start becoming more
30:21used to pricing things not from what
30:23they believe the value is, but from what
30:25they believe everyone else's advantage
30:27or disadvantage at arriving is.
30:30And so if you
30:32look at this paper, what it tries to say
30:34is
30:35maybe if you have the kind of guarantees
30:38you get from RLNC,
30:41and then you also know something about
30:44the delivery time distribution. That's
30:46sort of the mean field part of the
30:48title.
30:49Um you should sort of
30:51be able to say how much do people really
30:53want to pay to get their item in. How
30:55much do they really value the item
30:57versus how much are they valuing their
30:59bet on whether they arrive at a certain
31:02time.
31:03And I would say that a lot of classical
31:05economic theory on auctions sort of
31:08assumes that users are bidding some
31:10notion of their true value or that it's
31:13rational for them to bid their true
31:14value. And I think a nice aspect of this
31:17is
31:18RLNC kind of makes people bid in a way
31:21that
31:22people are used to thinking about,
31:24right? It it it sort of it it it it
31:26turns it away from a game of guessing
31:28what everyone else is doing and bidding
31:31on solely on what you think the true
31:33value is. And I think
31:34that's sort of, you know, a meaningful
31:36step towards making latency markets
31:38have a value that's dependent on true a
31:41true economic transaction versus sort of
31:44a
31:44pure speculation on other people's
31:47advantages.
31:48>> That that's that's such a Thank you
31:50that, you know, that I think that's such
31:52a core point, you know, because
31:54there's this, you know, probably you
31:56know, price times arrival rate
31:59uh just has to be less than the expected
32:02utility of this delay, right? I mean
32:05that that's basically how we're how
32:06we're putting it. So, as you said, in a
32:08way it's very very classical, right? Um
32:12um and yet, you know, this expected
32:14delay is itself not very classical. So,
32:18um so yes, it's a it's an un-
32:20unclassical way of looking at delay, but
32:23a very classical way of pricing it. And
32:25you know, that that that connection is
32:26is one of the very important interesting
32:28parts here.
32:30Um
32:31I I'd love to hear a little bit about
32:36how to use this also about any
32:41architecture
32:43which is not just
32:47only forward-thinking. So, looking at
32:49the what-if scenarios, you know, we just
32:51to just to repeat, you know,
32:53no sharding, sharding
32:56but no coding, sharding with
32:59uh a fixed-rate code or, you know,
33:02sharding with a rateless code. I mean,
33:04those are all forward-looking, but
33:06effectively we often are stuck
33:10uh with whatever
33:12you know, the the legacy system is. Um
33:15and I wanted to turn our
33:17attention to the second part of the
33:19paper, those turbo. So, you know, the
33:21the inspiration, of course, is just, you
33:22know, if you're calling a in a turbo
33:24engine, you're you're taking stuff which
33:26is already being processed in the engine
33:29and you pull it back in, you know, to to
33:31make the engine go faster
33:33uh and be more efficient uh more more
33:35powerful and also efficient. So, you
33:38know, in the turbo side, we're sort of
33:41mixing
33:43the RLNC approach, which is effectively
33:47extremely
33:48um
33:49agnostic to, you know, whether there's
33:52coding or not
33:53uh and our RLNC. And I and I wanted to
33:55turn our attention to to that part
33:59um
33:59maybe, you know, this this aspect around
34:03uh around turbo and around having a fast
34:06lane that's being added to the base
34:08lane.
34:09Uh and maybe Sagita, if if I could ask
34:11you to to give your take on that.
34:15>> Yes, I I think my my take here from a
34:17product perspective is just that it
34:19makes the path to adoption much easier.
34:23Cuz basically what you're saying is that
34:25you still keep that base lane that
34:27people are using that the whole network
34:28is currently um
34:31depending on and you add another lane
34:34that is faster, more reliable, and this
34:36can be an additive improvement. And so
34:39basically it makes the the story much
34:41more tractable
34:42from a migration perspective, from a
34:44user perspective. So this is one of the
34:46key value that I see in this turbo
34:48approach and the fact that we can do it
34:50with RLC is pretty neat.
34:54>> Uh, maybe Moritz, would you care to
34:56share how you see the mathematical
34:58intuition
34:59behind combining the lanes?
35:02>> Yeah, I mean I guess this is like one of
35:03the also kind of really magical
35:06properties of RLC that
35:09and RLC is kind of the most general code
35:11in a sense, right? We just talked about
35:12random combination sort of like any
35:14linear combination of the original
35:18shards is a valid packet which can be
35:21interpreted by RLC.
35:23And this is where this this is why RLC
35:27is actually the only code which could
35:29implement such a fast lane because
35:31basically there are two scenarios,
35:32right? One, we're talking about an
35:34un-sharded base lane payload in which
35:36case you would just have
35:38either the base lane would arrive first
35:40or the fast lane.
35:41But if you're talking about sharded base
35:43lanes,
35:44then
35:46um, RLC is the only code that can sort
35:48of take any kind of sharding sharded
35:51kind of payloads underneath
35:53and and add on top of that to to make
35:56sort of an additive um, always positive
35:59contribution to the decoding
36:01time.
36:02Now, in terms of how this translate into
36:05the translates into the pricing, now the
36:08fast lane would then have to be priced
36:10in a sense that only the incremental
36:12additional value caused by by the fast
36:15lane should be considered as um,
36:19yeah, affecting the the upper bound for
36:21for pricing. So yes.
36:24>> Yeah, yeah, and and and so really what
36:27you're talking about is more this uplift
36:30um rather than, you know, a separate
36:34pricing. And, you know, again, I'm
36:37I know I keep turning to you for these
36:39pricing questions, Tarun, but you cover
36:41them so well. I'm going to keep doing
36:42it.
36:43Uh how do you see that uplift aspect?
36:47>> Yeah, I I think one really important
36:50piece where economists sort of
36:53has historically
36:55for better or worse, I'd argue, failed
36:57at explaining real-life auctions versus
37:00theoretical auctions, you know, like
37:01there's auction theory where people, you
37:03know, you idealize how a set of people
37:05who are trying to bid over a scarce
37:06resource
37:07bid and, you know, what their incentives
37:09are.
37:10But one aspect that in practice has on
37:13the internet in particular has always
37:15kind of eluded classical auction theory
37:18is the fact that spamming is a good
37:19strategy. So, I spam, I send a lot of
37:22extra transactions, and by spamming a
37:25lot, I can crowd out other people who
37:27might bid higher than me or delay them,
37:30increase their latency, or or or put
37:32them into the tail of the distribution,
37:34and then I can win for a lower price.
37:36And that's sort of what I mean by I'm
37:37not necessarily bidding my economic
37:39value. I might actually be just trying
37:41to crowd out competitors. Now, the nice
37:44thing about thinking about the uplift is
37:46that in the base versus the premium
37:48lane,
37:49someone can spam, but it's only going to
37:52be economically rational for them to
37:54spam in the base lane versus the premium
37:56lane because they will they will
37:57actually incur such a high cost
38:00differential relative to someone with
38:01the real economic value of getting into
38:03the premium lane that it just won't be
38:06worth it. The cost of spamming is
38:08effectively uh not worth it. Now, this
38:10is an oversimplification, but this is
38:12sort of kind of the type of thing that
38:15is enabled by being able to have sort of
38:17mathematically guaranteed separation
38:19between these and sort of a way of
38:21thinking about the payments between
38:23these differently. And I think
38:25um you know
38:26fundamentally, whether the base
38:29way of sending transactions is good or
38:31bad, you know, there's someone spamming
38:32or someone kind of doing some other
38:34actions,
38:35the idea that this fast lane is gives
38:38you some guarantees, lets you
38:40you know, even at times when there's
38:42sort of poor performance,
38:44really be able to understand that you're
38:46going to get the economic value you
38:48expect.
38:49>> Yeah, and and actually I think what what
38:52you mentioned goes way beyond uh
38:54specific Ethereum, right?
38:56Uh and actually thought for anybody to
38:59may maybe get your takes um
39:01again [clears throat] Tarun, but anybody
39:03please jump in in terms of, you know,
39:06how this goes beyond Ethereum.
39:08>> Yeah, I'll just say that uh
39:11the nice thing about having a model is
39:13that once you apply it to a different
39:16environments, um granted you know the
39:19you know, the the rewards and the
39:21mechanics, then it it just applies. So,
39:24this can be this can scale to many more
39:26use cases. And I know we've discussed
39:29and brainstormed that with Tarun, maybe
39:31you want to to lead us there, but around
39:34the MEV competition and you know, we're
39:36touching on spamming and all of that.
39:40>> Yeah, for sure. So, so I think MEV over
39:42time, maybe I'll just give a brief kind
39:45of history of it because it's sort of
39:47the micro structure has evolved so much
39:49and that's sort of why you need a lot
39:50more control over latency in 2026.
39:54But in the early days of MEV, you know,
39:56there were Ethereum validators who were
39:57not really paying attention to what
39:59transactions they were validating, they
40:00just took transactions from users,
40:03placed them into a block arbitrarily,
40:05you know, used whatever the default in
40:07the client was. They weren't even like,
40:09you know, people were just not assuming
40:11users were sophisticatedly sending
40:13transactions.
40:15And then the more sophisticated users
40:16realized this thing that I was saying
40:18earlier, which
40:19is hey, it actually makes more sense to
40:22send a lot of spam transactions at very
40:24low gas, but the you know, the the
40:27the default algorithm would include
40:29enough of them that I would block out
40:31some other users who might be bidding
40:33higher than me.
40:35And so then people started realizing
40:36this actually became endemic and it was
40:3880 to 90% of the block was spent on
40:40these spam non-economic transactions.
40:44And so then people started having these
40:45auctions off-chain where people kind of
40:49bid in a fast lane to get their
40:51transactions into the chain. Now, while
40:53that was great, this effectively created
40:55a sort of centralization vector because
40:58you're bidding sort of either directly
41:00with the validator or you're bidding
41:02kind of in sort of a third-party who
41:04validators are subscribing to and that
41:06third-party effectively became the
41:08centralization vector.
41:10Um, over time as Ethereum moved to
41:12proof-of-stake,
41:14you started to have this thing where um,
41:16the validator themselves who was chosen
41:19for the next block would run their own
41:20auction as opposed to a single user.
41:23That's sort of this uh, proposer-builder
41:25separation style auction. And then what
41:28happened was people sort of got latency
41:30advantages before even there's multiple
41:33levels of latency advantages of how fast
41:35could I send my transaction to someone
41:38who was bidding in the block. And so
41:40what this ended up getting at is that
41:43you sort of had the segmentation of you
41:47know, users who are strategic, who are
41:50bidding repeatedly every block, users
41:52who are less strategic, selling the
41:54rights effectively to their transactions
41:57to strategic users, and then the
41:59strategic users repeatedly competing
42:01where maybe there's a hundred of them
42:02but only ten of them could win on every
42:04block.
42:05And so
42:06the real question is how much value are
42:08those ten people who are winning leaking
42:12to these kind of strategic bids that
42:15have nothing to do with the true value
42:17of the block.
42:18And by being able to actually precisely
42:21bid on latency, you're finally able to
42:23take out the last segment of uncertainty
42:25in those bids, right? Of of where where
42:27where people were
42:29trying to to to to bid based on how
42:31fast, you know, account for the fact
42:33that there's some error in whether their
42:35block would make it in time, whether
42:37they would meet the deadline. And so
42:39they'd have to price slightly
42:40differently, usually slightly lower or
42:43hedge somewhat, like shrink the size of
42:45their block a little bit because it
42:47would be faster to validate.
42:49Things of those lines were were things
42:51that were occurring because people were
42:53not able to precisely price latency. And
42:55I think that the idea that you're able
42:57to to do that for these types of
42:59contests that are almost like
43:00knapsack-like of I have 100 people, I'm
43:03picking 10 every time.
43:05I think that will sort of
43:07something that
43:08you know, this
43:10framework really allows us to to reason
43:12about and is sort of unique to RLNCs in
43:15a lot of ways.
43:16>> Uh no, that that's a great point. And
43:18you know, just to connect it to the
43:19paper, we have, you know, a validator
43:23with multiple deadlines, but then very
43:24connected to what you're saying, this
43:26top K MEV race.
43:28Right? Which I think is highly highly
43:30connected to to what what you were just
43:33what you were just mentioning. Uh we
43:35have been having so much fun and I
43:36realize we're we're you know, we're
43:37getting on the Oh, it's 45 minutes of of
43:41discussion and I think we could go for
43:43another hour readily without without
43:45missing a beat. Um so I'm going to try
43:47to maybe pull it all together.
43:51Um and in particularly, you know,
43:54looking forward.
43:56Um
43:58Siddhartha, you mentioned the empirical
44:00calibration, taking measurements from
44:02live networks.
44:04Um we also of course need to see the
44:07supply side, what users are willing to
44:09pay, what it costs to provide reliable
44:11delivery, etc. And then, of course, you
44:14you're going to have issues around
44:16adoption equilibrium. You brought up
44:18this this point directly and indirectly
44:21many times, Tarun, about the fact that
44:23you're basically also competing in with
44:26other people and thinking not just what
44:27does it do to me, but what it might do
44:29to other people, right? And and uh you
44:32know, explicitly or implicitly adjusting
44:34your behavior in that way.
44:36Um, so, uh I'd love to get
44:40some thoughts about, you know, the the
44:42future work, where this where this goes
44:44next. And uh
44:45Tarun, I'll start with you.
44:48>> Yeah, I I think the most important thing
44:51that
44:53in my opinion
44:54will eventually, you know, what what
44:56you're right now
44:58assume everything Optimism is super
45:00successful and you know, we go from this
45:03market which maybe is 5% to 15%
45:07inefficient and we're able to shrink
45:09that to 10 basis points or 0.1%
45:12inefficient because people are having to
45:15shave their bids less, they're having to
45:17shrink their blocks less, there's more
45:18consistency in bandwidth in the network,
45:20more consistency in latency in the
45:21network.
45:23Um, and I think
45:25what I'm sort of excited to see is how
45:29do these kind of latency marketplaces
45:31financialize on the next
45:33uh level, which is
45:35will people start selling, you know,
45:38futures on future block latency? So,
45:40like, hey, I don't really need I'm a
45:43validator who I'm going to be selected,
45:47you know, I know I'm going to be
45:47selected in the next 2 minutes in at
45:49least X blocks.
45:52Is there a way for me to
45:54hedge some of my risk or, you know, kind
45:57of
45:57ahead of time sell some of the rights to
46:00this auction early. The reason I bring
46:03this up is
46:04you know, these types of futures markets
46:08also make things a lot more efficient
46:09for for users, especially users who have
46:12very planned regular transactions. So,
46:15you know, an example of that is
46:17an oracle. So, an oracle might be a a
46:19user who's conveying a price from an
46:22off-chain
46:23um venue to an on-chain uh protocol and
46:27they're trying to have as little latency
46:29and bandwidth variance as possible. They
46:31They need to tell you the price of the
46:32S&P 500 every second
46:35uh or every minute, let's say,
46:38between 9:00 a.m. and 4:30 p.m.
46:41um
46:42but then after that they don't need to
46:43bid. So, they have a very precise sort
46:45of bidding frequency and you could
46:47imagine that they're willing to pay
46:49ahead of time to guarantee um sort of
46:52being in the top X of latency. And so, I
46:56I see a lot of this infrastructure
46:58evolving as traditional entities start
47:00moving into blockchains. Blockchains are
47:02continuous time repeated games like
47:05we've been talking about. And [snorts] a
47:07lot of the off-chain stuff, you know,
47:08traditional finance brokerages,
47:10tokenized assets, etc. don't follow
47:13that.
47:13And and the way to make those two worlds
47:15work is to just reduce the variance and
47:18and spread between them and I can see
47:19these products kind of pushing us in
47:21that direction.
47:22>> Oh, thank you. I have
47:24I love it. Love it. And
47:26Moritz, onto you. What What What do you
47:29see as the the main the main takeaway
47:31that that you like our listeners to
47:33retain?
47:35>> Yeah, sure. I I guess like from
47:36especially a coding theory research
47:40perspective, I would think that what we
47:43did here in the paper was we took a
47:44first stab at connecting as like on a on
47:47a formal way as on a formal level as
47:50well like these two different worlds and
47:52um
47:53sort of the mean field framework made
47:54that
47:55the that problem tractable also
47:58like comparing these different
48:00these different propagation
48:03paradigms. Now
48:05I think again and I I guess I said this
48:08before but the fact that we are able to
48:10do it without considering the specific
48:13topologies that we are talking about
48:15which might be very different for each
48:16of the actors involved is a
48:19is a is a very very good very good step
48:22and a very good sign that we can move
48:25forward and also derive like some
48:27interesting results with this framework
48:28going going forward.
48:30>> Thank you and I Sajida.
48:32>> Yes, so to keep it simple I think the
48:35main takeaway for our listeners would be
48:38that
48:39we move from speed is money to
48:41consistent speed is money.
48:45>> I love it. I love it. That's the message
48:47I'd like to close with. It's not just
48:49speed is money but reliable speed is
48:51money.
48:52And
48:54the paper to remind everyone is pricing
48:57innovation under latency constraints.
49:00Encourage everyone to read it. Don't
49:02forget to get at least one cup of coffee
49:04before cracking cracking open your your
49:07your laptop to take a look at this.
49:10And I really want to thank
49:13um
49:13our wonderful
49:15contributors today. Thank you Tarun.
49:17Thank you Moritz. Thank you Sajida.
49:20And I want to thank everybody for
49:22listening.
49:25>> Thank you.
49:32>> [music]

About this transcript

This page contains the full transcript of Speed is Money: Pricing Innovation Under Latency Constraints | Ft. Tarun Chitra by Optimum, generated from the public captions YouTube serves with the video. The transcript has 8,041 words across 1,328 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.