And as in past episodes, we are recording this live.
So if you have any questions, please tweet at us and we will do our best to include them.
Now, in the last episode,
we are going to talk about how things are going to talk about how things are going to talk about how things are going with the surge and generally where Ethereum and L2s are going next.
Welcome, Vitalik, thank you so much.
And we're going to talk about how we talk, but how we're going to talk about how we're going to talk about how everybody lives.
And so Kobi and I are just really excited to dive into this post.
And maybe to start, you know, in your post, you talk about the different trade-offs that L2s can make,
trading off security for lower transaction fees.
And, you know, you start by talking about why this might be useful.
And so maybe just to set the stage a little bit, can you share a little bit more about this?
Sure. So I think we're seeing a lot of projects of different kinds,
either building different kinds of things that they call L2s on top of Ethereum for various purposes,
or in some cases, either independent L1s like Celo or sometimes even completely centralized projects
seeking to become L2s or seeking to get some kind of like deeper technical integration into the Ethereum world of some form.
And I think when people do this, they have two kinds of motivations.
So one of those motivations is just to try to kind of be more aligned with the Ethereum ecosystem in a kind of some spiritual sense,
kind of be on the same team as, you know, team Ethereum,
while at the same time still having your own autonomy and being your own thing.
But then at the same time, there's also this technical goal of basically trying to get more security
and create a thing that people can trust if they're living inside of your thing
without having to, like, convince people that your own tiny bespoke validator set
or your own server or whatever actually is trustworthy, right?
And there's a lot, I mean, it's important to remember that those two objectives are separate to some extent,
though they're definitely also aligned to some extent as well, right?
Because it's, you know, if you're going to be on team Ethereum,
then there's even more value in making it easy and safe for people who currently live in the Ethereum
versus to also go and do things in your own ecosystem as well and vice versa.
But, you know, there's also a bit of a difference between those two goals, too.
And then within the space of, like, trying to gain security by creating some kind of tie to Ethereum,
there's a lot of different strategies that you can take.
And a lot of those strategies really depend on, like, what exact trade-off between security and scale
and functionality you're looking for, right?
So the kind of most pure one that we're the most familiar with is roll-ups, right?
And a roll-up base has computation happening off-chain but attested to on-chain using either ZK-SNARKs
or a fraud-proof system like Optimism and Arbitrum and FuelDoom.
And it also has data on-chain, right?
And so enough data gets published on-chain that it's possible to reconstruct the state
so that if every other participant in a roll-up disappears,
other participants can come right back in and extend it
or at the very least have enough information to start withdrawing all of their assets.
So roll-ups are really the gold standard.
They're basically Ethereum-equivalent security,
with the exception that there's thousands of extra lines of code
that you have to trust and not to have bugs.
Which, like, to be fair, is, you know, like, that's a very big if
and there's a lot of these separate discussions going on
on, like, security councils and multi-provers
and different ways to try to, like, minimize that security gap.
But, like, that security gap is something that exists in all of these systems, right?
So I think if we're going to compare different types of layer twos,
it's worth sort of putting that aside as a separate problem.
So we have roll-ups, but then we also have various kinds of options
that take compromises of different types.
So Validiums are probably one of the most famous ones.
Validium is a system that uses ZKStarks to prove validity of Merkle roots,
like, state roots that are being published to Chain.
And where state roots are being regularly published to Chain,
but data is kept off-chain.
And a Validium has the property that if an attacker decides to be, like, maximally evil,
then that attacker can cause people's funds to get stuck forever,
but they cannot steal funds, right?
As a plasma operator, because you're constrained by a ZKStark system,
you can disappear, but you cannot cheat.
And the benefit of Validiums is that because you don't have to pay for on-chain data,
the data costs are much lower.
You still have to pay for costs of ZKStarking, right?
But the data is definitely significantly, well, mostly gone, basically.
You only have to pay an O of one data cost, like a fixed amount per period,
to publish the roots and the proofs.
And then there's other interesting ones.
So one of these hybrids that I think people don't talk about as much,
but it's important to explicitly recognize as a category,
is pre-confirmations, right?
So if a lot of these roll-ups, they want to kind of really appeal to end users,
and a lot of them have this kind of explicit consciousness of, like,
Ethereum is the thing that tries to be a neutral and safe platform,
but we are the, like, really opinionated thing.
We do business development.
We try hard to be user-friendly.
And one thing that that requires is that requires faster block times.
And the problem is you cannot do roll-ups or Validiums
with a faster block rate than the Ethereum chain itself,
just because, like, getting the roll-up or Validium level of security
requires having something publish the chain.
And so what they are at least planning to do, right,
what they currently do in practice is there's just, like,
a signature that gets trusted by some central operator,
but what they're planning to do is have signatures that get published
by, like, some set of consensus nodes specific to that layer two.
And then there's a fraud-proof system where, like,
if they say they're going to publish one thing,
but then they later end up actually publishing something
completely incompatible, they get penalized.
So there's, like, an economic security level, right?
And that's a kind of trade-off of security in exchange
for the functionality of having much faster block times.
Then there are systems like Plasma,
which have Validium-level costs, but roll-up-level security.
But the trade-off is, of course, that Plasma is kind of much more limited
to specific sets of applications.
And, I mean, I think there's an interesting argument to be made
that we've kind of swung toward Plasma-style constructions
actually being underrated now,
and there's an opportunity to resurrect them a bit.
But, like, even if we do,
they're inherently much more application-specific
than roll-up server Validiums.
So that's, like, another security trade-off, right?
So there's this, like, broad space
of different security trade-offs.
And the way that you think about, like,
what is the thing that they're trading off
if you have an asset on the layer two,
then, like, what level of guarantee do you have
that you can actually convert that into an asset
on the underlying layer one, right?
And the answer in the case of a roll-up is, well, always.
The answer in the case of a Validium is, well,
your asset could disappear if the operator is evil,
Your answer in the case of a Plasma is, well,
it can if you're only using one of these kind of
fairly simple limited classes of applications.
Your answer in a pre-confirmation system is, well,
you have a lower economic guarantee
if you're willing to only wait one second,
but if you're willing to wait, like, let's say,
one minute or one hour, you have a much stronger guarantee, right?
So different choices have different answers.
And then separately, there is this other interesting question
of, like, what is your chain's level of ability
So what all of these, like, roll-up Validium Plasma gains,
they're all about withdrawing, right?
If you have an asset on your Layer 2, then, like,
how do you convert that into an asset on Ethereum?
Reading Ethereum is something you need to do
to be able to deposit things onto Layer 2 in the first place.
And in that case, there's basically, like,
There is the kind of ideal answer,
which is basically every block in the top chain,
like, in your Layer 2 points to a block in Ethereum.
And if Ethereum reverts, then your chain reverts as well, right?
So, like, you have to have a fork choice
that, like, really is dependent on the Ethereum fork choice.
And, like, this is something that's not too hard to do
from a fork choice perspective.
Like, I have 50-line Python POCs that are about five years old,
but it does require your Layer 2 to, like,
which is something that you totally can do
if you're forking, you know,
Geth or some other Ethereum clients,
but, like, it's an extra challenge.
And then the other approach is
you only make your chain aware of finalized Ethereum blocks,
in which case it's, like,
You generally don't have to revert.
And there are, like, exceptional cases
where, like, what happens if Ethereum gets 51% attacked?
But, like, you could just say,
we're not going to try to write code for that.
We're just going to admit that
if that happens, we're going to hard fork.
your main weakness is basically that, like,
if Ethereum enters an inactivity leak,
then you don't have, like,
deposit functionality anymore.
And so there's some interesting edge cases
And then there's the interesting question of, like,
if what you are today is a separate chain
and you want to convert yourself
into being an Ethereum volitium,
what are the specific changes
And, I mean, I remember a few months ago
there was this big discussion about, like,
is the concept of roll-up or volitium
Is it all basically just bridges?
one of the kind of conclusions
converting a separate chain
is definitely easier than it seems.
massively re-executing a lot of things.
It basically does just require
But those bridges needs to have, like,
some very specific properties.
you need, at the very least,
need to have a validating bridge,
like a bridge on Ethereum
your chain's entire execution.
So, being able to interpret
security council is, like,
then, like, it's not a vote.
proof system does, right?
give users enough time to
contradicting itself, and
snark system has a bug in
Because the output can't be
you know, trustless proof
security council can also
Or, on the flip side, if,
let's say, nobody submits
that might, that would be
direction, and that, like,
two, the security council
your security council or,
figure things out if they
percent of the trust you're
needs to really basically
move from zero percent to
And when it needs to move
maturity of the individual
So there is a dashboard by
So, you know, Polygon ZK-EVM
case of sequencer failure,
but that's something that
I'm sure they're going to
I mean, my understanding of
basically made a decision
to just go full speed ahead
and they're exploring with
that, the two things that
version 1, and then there
And both of those are not
you know, they are running
with basically kind of the
So, you know, that's roughly
Yeah, really interesting.
certainly, like, an amazing
take a look at what these
L2s are actually offering.
show two episodes ago, and
definitely check out that
And I guess, you know, it's
been a while now since you
wrote that post and came up
with those stages and those
And, you know, I'm just kind
of curious if your thinking
talking about decentralized
Does it fit the framework, or
is there anything else that
that's kind of bubbled to the
top as something that maybe
might, you know, be worth
Yeah, I think probably the
big, one of the big staking
points that's kind of in the
way of the Security Council
becoming kind of effective is
Security Council members are
Because, and the arguments in
favor of making public, making
them public is obviously if
they're not made public, then
like, how do you know the
Security Council isn't just
Like, who cares if it's six
out of eight, if the eight
keys are all controlled by the
But then the reason why people
are hesitant against making
the Security Council public is
individual members are afraid
of personal safety risk, they're
afraid of legal risk, and that
there's other risks that they're
afraid of, and so that is just
something that's proven hard to
I mean, Arbitrum has, I believe,
been willing to actually make
their Security Council public, but
a lot of other projects are not.
So that is one of those things
that is a bit of a staking point.
The, I think, realistically, there's
basically going to be, yeah, like
two good ways out of that, right?
I mean, one of that, one of those
ways is possibly for there to start
being more specialized organizations
that are willing to be Security
Council members for multiple
projects and that kind of have a
good security setup and a good
And then the other approach
would be to basically, yeah,
well, just full speed ahead to
stage two to the point where the
Security Council has no power
except in those cases where
there's a software bug and
basically have more security by
relying more on the code rather
And then there's also this
interesting third route that I
hinted at at the end of my post
from a month before, which is
basically this enshrined ZKVM
Basically this path where the
Ethereum protocol gets a native
functionality for verifying
And then if it's like native
functionality, then if there is a
bug, then that bug just has to be
responded to by like at the level
of fixing the and potentially forking
And so that's kind of a gold
standard of security, right?
So this is something that is still
kind of very early stage and it's
still controversial in certain
And of course, that would benefit
EVM projects, but it would not
benefit non-EVM projects.
interesting considerations in that
And like, even if that does get
adopted, it's realistically a much
Yeah, I completely agree that the
whole topics of security councils
and entrant rollups is going to be
extremely important to figure out
correctly in order to not lose the
And yeah, maybe talking a bit about
a different topic, you've also
written about L3s and how they
relate to L2s and what are their
And one thing that you mentioned is
that L3s has this nice ability to
bridge assets between them without
But there is this aspect that you can
also achieve something similar when
you aggregate multiple L2
proofs and then sharing the
Wondering if you can talk about that
And so the L3 thing is interesting,
right, because like L3s are a
software architecture classification
much more than they are a security
classification or rather they're
classification at all, right?
Like, so like, for example, the
StarkNet ecosystem is good at having
a lot of these L3s, but there are
some L3s in the StarkNet ecosystem
that are rollups, but then there are
some L2s that are Validiums.
And so it just kind of gets
bungled a bit that way, right?
But the reason why you would want to
do an L3, I think one of them just is
that you want to make it easier for
people to deploy new Layer 2s and
and have regular proofs of Layer 2s
being committed into Layer 1 at
So one of the big expenses of a Layer 2
is basically you have to like regularly
publish these routes and proofs to
And if you're just submitting a route,
then the cost is a bit lower, right?
It's like about 40,000 gas to send
the transaction to just like update
the storage slot, replaces X with like
hash of X and Y or whatever.
But if you're adding a ZK-SNARK, then
a ZK-SNARK has a proving cost of like
Or if you're StarkNet, then it's like
And that's, it's like a big, a much
And so if you imagine having 10 of
those systems on Ethereum at the same
time, then like you just get this
really annoying trade-off between each,
either each of those systems having to
commit their proofs to Ethereum much
And so deposits and secure withdrawals
having a higher latency or basically
just having to pay some, some pretty
And so what would be ideal is having
functionality to somehow share like that
root publication function to Ethereum.
And basically, instead of having like 10
different ZK-SNARKs, have one recursive
SNARK that represents those 10 different
And one of the properties of the StarkNet
ecosystem is that basically it just does
that as part of what it is, right?
Because if you have 10 different L3s that
are all roll-ups, then they, they, when
they publish the chain, they publish the
chain as part of the Layer 2.
And then the Layer 2 could, can just
aggregate the proofs and the proof
verification can get done inside of the
Layer 2 instead of being done inside of
And that just really lowers gas costs for
But that's only one way to do it.
So if you go back to my post on Layer 3s
on my blog, if you just, it's called
What Kind of Layer 3s Makes Sense.
It's actually for about a year and a month
And you scroll all the way down to the, like,
to the diagram at the bottom.
Like, I basically show that there is a design
where you can have this kind of, like,
proof batching system where you, it just
accepts aggregate and aggregate proof for
roll-ups that essentially presents their
state management and their verification keys
And so you could get the benefits of proof
batching without actually having to, like,
have a full EVM layer in the middle.
And that just, like, reduces security bug
So, yeah, I think there's a lot of different
And I think there's also a lot of complicated
trade-offs between doing it one way,
doing it the other way, potentially just a
lot of different projects giving up on making
their own Layer 2 at all and instead creating
some kind of sub-ecosystem inside of another
Another consideration that's, I think, worth
also bringing up and throwing into this is
Because, like, so far we've been talking a
lot about layers that provide scalability,
but there's also a big need for layers that
And we have Aztec, we have Nocturne, we have
Railway, there's just going to be a growing
And it would be, like, it's important to just,
like, think about the need of these things as
well, right, because if you have a bunch of
different privacy layers, then realistically
those privacy layers are going to have to live
inside of some kind of scaling layer, just
because Aztec starts on Layer 1 are way too
And so that's another place where you're also
going to have to have something that, like, from
an architecture perspective, looks like a Layer 3.
So that's also going to be interesting to see.
You know, you've been writing about this over a
year ago, and yet these topics just keep coming
And, you know, I think they become more and more, I
think, timely now as more and more L3s are
launching and more folks are talking about sharing
Well, we're getting close to time, so I thought
maybe we could end with kind of more of a topical
You know, Celestia launched this week, and, you
know, it's obviously more of a Cosmos project, but, you
know, kind of curious what you think of the impact that
it might have generally on the Ethereum community.
Yeah, so what Celestia is is it's basically a data layer, right?
So it's a chain that is optimized for storing large
amounts of data, which is something that is usable by a
I think the really important thing to keep in mind with data
layers is that the level of security that you get from data
layers really depends on, like, which assets you're doing
So, like, for example, the thing, like, the thing that is less
secure is having assets whose home is in one ecosystem and then
having data whose data availability come from another ecosystem.
So, like, if you try to make a system whose data is on Celestia
where that system's, like, the assets that that system is managing are
assets that come from Ethereum, then, like, your security is basically
only kind of as good as the security of Celestia, right?
Like, if Celestia gets 51% attacked, then they can either steal all of
your assets if you're, like, if you're based on fraud proofs or you
basically just become a Volidium if you're using ZK-SNARKs, right?
So, if you have something that is using, like, that is managing assets that
are homed on Ethereum but is using Celestia for data availability, then
you're basically a Volidium, right?
Whereas, you know, if you use Ethereum native data availability, which is
going to come from, like, 4844 and then other things, then, like, you
could actually be a roll-up.
And roll-ups have unconditional security, like, even if Ethereum gets
51% attacked, you are safe because an Ethereum chain where any data is
unavailable is, by definition, a non-canonical Ethereum chain.
So, but at the same time, if you are managing assets whose home is not
So, like, for example, if you are one of these, you know, like, a video game
company that wants to put its assets somewhere else or if you're focusing on
stablecoins that have an issuer or if you're focusing on assets where, let's
say, you know, you're managing your, like, people tokenizing their own stocks or
just, like, releasing their own NFTs.
So, and then if all of those things are homed inside of your chain and then you
just, and then your chain just is a thing that is based on Celestia, then, like, you
do, you do have that kind of full unconditional level of security, right?
So, yeah, I think it basically, the big thing to remember is just, like, the level of
security depends on what your application is.
And then additionally to that, what level of security is okay for you also depends on
what your application is.
So, I think it's all application-specific.
Well, I think that's all the time we have.
Vitalik, thank you so much.
Yeah, as always, that was, you know, just incredibly insightful.
I really appreciate your time.
Yeah, thank you guys, too.
Well, once again, this was L2 Unplugged.
If you enjoyed this episode, I hope to see you at the next one.