If Web 3 needs to scale to the scale of Internet, the only way
it scales is through ZK, and we have our all our bets on ZK.
The biggest problem facing Etherium and facing Etherium's
ability to scale is fragmentation of L twos.
Because right now we have this proliferation of L twos, but
liquidity is not shared between those L twos.
State is not easily shared between those L twos.
Like users have a difficult time moving between those L twos.
What Polygon is building is basically a guarantee of safety
for a shared bridge, which allows different L twos to have
asset fungibility between their chains.
L twos are submitting blocks to the AG layer, and the Ag layer
is proving to Ethereum that all of these properties hold.
This episode is brought to you by Gnosis.
Gnosis builds decentralized infrastructure for the Ethereum
ecosystem. With a rich history dating back
to 2015 and products like Safe Cow Swap or Gnosis Chain, Gnosis
combines needs driven development with deep technical
expertise. This year marks the launch of
Gnosis Pay, the world's first decentralized payment network.
With a Gnosis card, you can spend self custody crypto at any
Visa accepting merchant around the world.
If you're an individual looking to live more on chain or
business looking to white label the stack, visit gnosispay.com.
There are lots of ways you can join the Gnosis journey.
Drop in the Gnosis Dow governance form, become a Gnosis
validator with a single GNO token and low cost hardware, or
deploy your product on the EVM compatible and highly
decentralized Gnosis chain. Get started today at gnosis dot
IO. Course One is one of the biggest
node operators globally and help you stake your tokens on 45 plus
networks like Ethereum, Cosmos, Celestia and Dydx.
More than 100,000 delegators stake with Chorus One, including
institutions like BIT, Go and Ledger.
Staking with Chorus One not only gets you the highest years, but
also the most robust security practices and infrastructure
that are usually exclusive for institutions.
You can stake directly to Chorus One's public note from your
wallet, set up a white label note, or use the recently
launched product Opus to stake up to 8000 ETH in a single
transaction. You can even offer high yield
staking to your own customers using their API.
Your assets always remain in your custody so you can have
complete Peace of Mind. Start staking today at Corus .1.
Welcome to Epicentre, the show which talks about the
technologies, projects and people driving decentralization
and the blockchain revolution. I'm Frederica Anst and today I'm
speaking with Brandon Farmer and Sandeep Nawal who are the Co
founders of Polygon. Sandeep and Brandon, thank you
so much for coming on. Sandeep, you have been on
multiple times before, so let's start with Brandon today.
Brandon, you are a Co founder of Polygon by way of having founded
Mir Protocol which was then acquired by Polygon.
Tell us about Mir. Yeah.
So Mir was a, it was an L1 that was trying to use ZK for privacy
and scalability. And so we started Mirror in 2019
and by 2021 really realized that we did not want to build an L1
and wanted to build in the Ethereum ecosystem.
And Sandeep and Mahilo and and the Polygon founders were, you
know, gracious enough to, to offer us a, a platform to do
that. Yeah, super nice.
So Sandeep, during that time frame, you guys acquired quite a
few CK teams. Maybe let's talk about that for
a while. So, so I mean the other very
well known one is a mess, but I think there were there were a
couple of other ones as well, right?
Yeah, like there was like Hermes and you know, the like male
protocol and then other was not an acquisition, more of a equi
hire like was the Facebook's Winterfell project, which is
like, you know, which became Polygon Maiden.
Even now, you know, we decently finished the acquisition of
Topos where who is also one of the, you know, one of the
leading companies who are working on this aggregation
thesis. And you know, we have been
working very closely on our code base and the fun part is like
now Polygon ZK is like so deep into the, into the whole
ecosystem, whether it's like succinct SP1 building on Plonky
3 or like, you know, different, different protocols using either
directly using the open source code or get, you know, their
architectures fully, you know, inspired by that.
So we are already doing a lot of stuff.
So Toposphere was also like one of the teams was working on our
code base and thinking about like a more of an aggregated,
you know, future the way we were thinking.
And it was like it made a total sense to, you know, bring them
in, especially related to the Type 1 prover that we have and
things like that. So yeah, that has been like a
long journey because we are absolutely clear that, you know,
if Web 3 needs to scale to the scale of Internet, the only way
it scales is through ZK and we have our all our bets on ZK.
Yeah. And I think those were very good
beds to place. You're kind of bringing a lot of
the research you have done over the years together in this thing
called aggregation layer that you launched earlier this year.
Can you set the stage here? So what what what's aggregation
layer? What problems are you looking to
solve with it? Yeah, sure I can.
I can take that. So the way that we see the world
is that that the biggest problem facing Etherium and facing
Etherium's ability to scale is fragmentation of L twos.
Because right now we have this proliferation of L twos, but
liquidity is not shared between those L twos, State is not
easily shared between those L twos.
Like users have a difficult time moving between those L twos.
And so we are scaling Etherium by adding additional block
space, but we aren't scaling Etherium in the sense that we're
not scaling access to liquidity into shared state.
Like if you think about like, you know, the, the value that's
bridged to arbitrary, that doesn't help optimism.
It doesn't help other L2's and it doesn't help the, the
Ethereum L1. And so right now we're in this
mode where everyone is basically trying to build their own like
mini copy of Ethereum where there's sort of liquidity and,
and bridge value and defy activity.
But we're not able to contribute to Etherium's network effects
globally and, and, and to contribute to, to like the
overall way that, that Etherium functions for users and
developers. And so the ag layer is an
attempt to, to fix fragmentation on Etheria.
It's an attempt to make it really easy for users to to move
state and value and liquidity between L2 chains so that we can
have like a horizontally scalable ecosystem for an
execution layer for Etherium, but one in which we're able to
scale access to to liquidity insurance.
That basically like a multi chain ecosystem that feels like
you're still using a single chin where we have composability and
and all these nice properties that we like on that one.
OK. So basically, if I kind of take
one step back, what you're saying is say I am a user on
base and I want to do something on Arbitrum.
The way that I kind of get from base to Arbitrum, despite the
fact that they're both layer twos on this shared security
layer of Etherium is by kind of exiting to Etherium at the cost
of kind of doing a transaction on mainnet, which is notoriously
expensive, and then kind of moving into the other L2.
And there's no way for me to kind of laterally move from base
to Arbitrum. And that's what we're fixing.
Is that correct? Yeah, exactly.
So, so exactly like you said, like like suppose that I have
some ETH on base and there's like an NFT mint on Arbitrum and
I want to be able to claim an NFT from that mint, There are
two things that I can do, right. So the first is I can withdraw
my ETH through the native bridge on base and then submit an L1
transaction and deposit into Arbitrum.
Obviously the problem is that base is an optimistic roll up
and it takes seven days for me to withdraw via the native
bridge and then I have to wait for that transaction to be
finalized. I have to wait for my deposit to
arbitrary to be finalized and the L1 transaction is expensive.
Some of this gets a little better with ZK roll ups because
we have a much shorter window where users can withdraw funds.
But fundamentally like it's not good enough.
Like we, we, we need a way for users to be able to take their
ETH, they're native ETH on some L2 and instantly bridge it over
to, to Arbitrum and get native ETH and be able to do things on
that chain. The second option that users can
do is that they can withdraw via third party bridge.
So there are third party bridges that connect different L2
chains. But the problem here is like the
trust assumption for using a third party bridge is much, much
different, and there's a requirement for users to rely on
liquidity providers and market makers to basically swap from
the wrapped synthetic version of a token.
So let's say I use wormhole to bridge from base to Arbitrum.
I get wormhole wrap teeth on Arbitrum and I have to pay some
amount of money to swap that into Arbitrum native ETH so that
I can claim my retainment. And So what we can think about
the Agglera is doing is providing two things.
So the first is asset fungibility.
You should be able to take your assets and move them between
chains without having to rely on a market maker or liquidity
provider. And you should be able to do
this safely at super super low latency, even lower than like
etherium block time or etherium finality.
OK, I I understand the goal in here.
How? How do you make it work?
Sure. So this is a good question and
and sad me if I'm getting two in the weeds, but what Polygon is
building is basically a guarantee of safety for a shared
bridge which allows different L twos to have asset fungibility
between their chains. So, so this is what allows us to
avoid making an L1 transaction when we move funds.
We can just take L1 native ETH and move it between chains and
we never have to touch the L1. And the second thing is it
allows us to provide this cryptographic guarantee of
safety so that chains that are interoperating at lower latency
than like even Ethereum block time.
But certainly the time that it takes to finalize an Ethereum
block aren't at risk of some sort of malicious behavior like
a chain can't equivocate or a shared sequencer can't, you
know, lie about the messages that are sent between chains.
And so the ag layer fundamentally is like this very,
very minimal guarantee of safety for the shared bridge and for
interoperability. And it provides a foundation for
what we call emergent coordination infrastructure.
So the way that chains interoperate is up to them.
They could use a shared sequencer or relay or, you know,
a builder. And these mechanisms benefit
from the shared bridge and the safety guarantees the AG layer
provides. So like that, like, like one
case would be for a shared sequencer.
If users wanted like synchronous composability between chains,
they could opt in to using the same shared sequencer.
And that shared sequencer would allow the same block builder to
simultaneously build blocks across chains.
So a user could submit a transaction on on 1L2 to move
funds and and claim the mint on another chain and then swap back
to the original chain or you know, access some key store
that's located on 1/3 chain. And the builder could do all of
this simultaneously. And the ag layer would guarantee
that for all of these chains, the builder can't misbehave and
asset fungibility is guaranteed. And so that's sort of like the
way that we can think about this work it.
But would that mean that the builder kind of any builder kind
of to to to build the next block would actually have to opt into
all of these chains? So kind of if if I want to start
transaction on base and that kind of bridges to Arbitrum and
then back in one in one transaction, the the the builder
has to support both, right? Yeah, so, so, so this is, I
think that that we should emphasize that there are, there
are different roles that that exist in this model that that
maybe don't exist in the same way for L1.
And so it in the shared sequencer case where we want, we
have synchronous composability and and you know, this isn't
required for all chains. Chains could operate
asynchronously too. But in in the synchronous case,
which is sort of the Holy Grail of composability, a builder
would be executing transactions and producing blocks for all of
these chains, which, which sounds bad, right?
It, it sounds like, oh, like this can't scale, like our
hardware requirements are going to blow up.
But we have to distinguish between the actors that are
building blocks that are super sophisticated.
They might be running in data centers and, and have access to
a large amount of hardware and the validators on L1 that that
that can be fully, you know, have, have very minimal trust
requirement or very minimal hardware requirements and can
fully validate everything that happens at L2.
I think it's up to chains, whether they're comfortable with
this model in which we have super sophisticated builders
that have that, that are able to operate a bunch of full nodes
concurrently. But they still exist in this
competitive marketplace, right? Like builders are limited in
what they can do. They're limited in how they can
misbehave, in the extent to which they can extract rent.
And so I, I, I, I think we're sort of moving to this world
where block building is just a role and a function that might
not be accessible to everyone who's running a node on their
laptop or a Raspberry Pi. But I wonder to what extent it's
like a necessary step to deliver very, very good UX, at least for
synchronous composability. Yeah, I also want to add one
thing on that, like the question you asked from a very simple
user's point of view that if I am let's say or in fact a chain
point of view, right. Let's say there is a transaction
where you know there is a cross chain transaction between three
different chains and you want to do it in one single transaction.
And you can actually break, you know, break it down into two
categories, one where you really want to have it in under one
single transaction. That means like synchronous that
we call synchronous composability across chains.
And that would require what Brendan was saying that some
level of shared sequencing or like, you know, a sequencer
marketplace where you people are the chains are selling rights
to, you know, sequence the blocks.
And then for these cross chain transactions, somebody who has
the rights to all three chains, they they create the block.
But there is another form which is a very much much simpler,
which where Aglier is more focused on.
And then on top of that, people can build shared sequencing kind
of mechanisms is the asynchronous composability where
you know, if you want to do, if your user, let's say I come to a
user, which is let's say cannot connected to a chain, chain A
and I do a transaction. But that transaction interacts
with chain B and chain C in a async add layer provides you the
mechanism or the safety guarantees that that transaction
will go through the chain B and chain C and you will and it will
come back to let's say some action comes back to your chain,
but it will go asynchronously. You cannot guarantee the aglier
doesn't guarantee you that this the entire series of transaction
will go through with the same set of conditions that the user
initially started with, but asynchronously.
There are like safety guarantees that the chains are not playing
a role in that. If the market condition, let's
say it's a, you know, a text transaction or something,
something changes things, that transaction might or might not
fail. But if the conditions are
correct, the chains will honour that transaction in a
asynchronous way. Whereas you know, if you needed
this synchronous one single transaction and you are
guaranteed that the entire sequence of the transaction will
go through for that you need some sort of shared sequencing.
And Aglayer provides an environment where people can
come and build the shared sequencing mechanism.
And, and we see the world growing into a place where you
will have we will have like Aglayer will have like hundreds
or like, you know, not even hundreds, like I would say
hundreds of thousands of chains connected in next 5 years.
Like I think the space where we are heading into by the end of
2025, only you'll probably have like 1000 chains and each
application eventually spinning up their own chains, meaning
like 10s of thousands of chains. And but how we see is that there
will be like 9, a large number of that those, those chains
connected to that layer will be individual sequence chains.
So you can do you know, asynchronous transactions across
other chains, whereas a few clusters of chains will be
shared sequence chains which have much faster and synchronous
composability across across the chains.
And that is dependent on the use case and how those chains want
to choose and join one somebody custodians, consortiums and all
that is fully dependent on the use cases.
Agglate is pretty pretty agnostic to that.
OK. So I think there's a there.
There's kind of like a lot to unpack here, but what I'm taking
away from this is basically yours is your distinguishing two
cases here. So one where kind of the
transactions happen one after the other.
So kind of say for instance, I bridge from chain A to chain B.
There I swap token X for token Y, then I bridge to chain C by
an NFT against token Y that I really want it, and then bridge
back to to chain A. And then there's the other case
where kind of everything where kind of all the transaction, all
the transactions happen at once or they don't happen, right?
Kind of what, what I would call kind of an atomic transaction,
right? So basically you, you bundle
everything together. So for instance, if I want to
do, if I want to AB something, that's kind of how, how I would
want to do it in order to kind of minimize my own risk, right?
And you're saying that the subsequent transactions that is
possible today with with AG layer where as kind of the
atomic transactions that is something that would require
shared sequencing, which is kind of very much in which is
optional for chains to kind of opt into.
And you kind of see specialized cases coming up where that will
be that where that will be done. Is that more or less correct?
Yeah, that was very well summarized to me.
I would say like the we're, we're still working on both the
async and the and the synchronous and atomic case.
But yeah, I, I, I, I think that's exactly the way to frame
it. Yeah.
I just thought that not to get off topic, but, but I, I think
this is sort of interesting. Like the ARP case that you
describe, I, I think is like a really good example of, of when
atomicity is, is really important.
I think it's interesting to like, imagine what the world
will look like. Like I, I, I, I'm not sure that
every single chain in the world will be using the same shared
sequencer and the same shared builder.
But you could imagine, like if we're trying to scale D5 to like
Internet scale or to like global scale, what that looks like it,
it, it could be a bunch of different chains that are all
providing liquidity sort of in parallel and they're all using
the same shared sequencer. Because it's really necessary
for, for people trying to arbitrage to be able to do
atomic arms between chains and, and like it's, it's very, very
important for us to be able to guarantee like within some
slippage parameters that like either both legs of an arc go
through or neither. And so I think like, I, I wonder
if most of the world composes asynchronously with these sort
of like Defy hubs, which are like synchronously connected via
shared sequencer, or whether it's sort of synchronous
composability becomes important for everyone.
I, I, I, I think it's just there are a lot of open questions as
to how the world looks with the ad clerk.
This is kind of an aside here. I I want to get back to to the
asynchronous case because that's kind of what works today.
But do you think kind of in the synchronous case where you kind
of have to have shared sequencing between different
chains. Do you think it's it's possible
to have a composite model where where you say every other block
is kind of executed by synchronous sequences and every
other block is done by regular people?
Because obviously, or at least my concern would be that the
hardware requirements and kind of the DevOps capabilities
needed to kind of run the hardware behind a shared
sequencing setup would be very difficult and not achievable for
many people. So kind of you would have a
small number of entities actually doing this shared
sequencing setup, which would result in much lower censorship
resistance then you would have with a much wider validator set.
So do you think it's conceivable to kind of have both where you
have like dedicated slots for shared sequencing and then kind
of if you want to do something atomically, you wait for that
slot and every other block is built by independent builders?
Yeah. So I, I, I, I think that's
definitely one approach. Another approach would just be
to like, I, I, I think implicit in the shared sequencing
construction is sort of a, a natural fall back where if a
block builder goes offline or, or misbehaves or, or attempts to
rent seek chains can always default to allowing anyone to
produce blocks for that chain. They, they wouldn't be a
sophisticated builder running full nodes for every chain, but
it would sort of like fall back to the asynchronous case.
But I think that like ultimately it's not for us to decide.
It's, it's up to the chains. But I I do think having like
periodic blocks that are produced that are not
synchronously composable, it is like an interesting solution to
sort of guarantee that there exists block producing enough
block producing nodes to provide censorship resistance.
Yeah, super interesting. So let's talk about the
asynchronous case. So in my head, this currently
takes the shape, as I would almost call it, like a unified
bridge. Is that kind of a fair
conception of what you're building?
Yeah. So I would, yeah.
So, so I, I, I would say that it has two components, right.
So, so there's the unified bridge, which means that all L1
and L2 native assets that are in the Agglar ecosystem are locked
in the same contracts. So all L twos that that opt into
the Agglar have this shared deposit contract that saves us
from or saves them from having to submit an L1 transaction
every time we do asset movement or asset transfer across chance.
And so the, the interesting thing would be with the async
case is like, so, so we had asset fungibility and we also
really want low latency interrupt.
So right now, like if you want to, we were talking about this
earlier, but if you want to move assets between L twos, even if
you have a shared bridge, there's still this like heavy
latency penalty. Because let's say that I'm on
roll up A and I want to move my ETH to roll up B.
In order for roll up B to accept the message that's that
transfers assets from roll up A to roll up B, it has to have a
guarantee that roll up A state is finalized.
Otherwise roll up A could equivocate.
It could create two blocks, one of which has a transfer to roll
up B1 of which doesn't and it could submit the the block with
the transfer to roll up B to roll up B and it could submit
the block without the transfer to roll up B to Ethereum to be
settled on Ethereum. In the case in which in which we
have to wait for finality on Etherium.
That's a really bad user experience, right, Because we
have this like 12 to 19 minute latency delay for for that block
to be finalized. So instead what we can do in the
AG layer is roll up B can declare that it has this
dependency on some state of roll up A.
So I can say, OK, I I've received the state of roll up A
that includes a message telling me to mint a bunch of ETH and
give it to this user. But like I'm going to via the AG
layer guarantee that my roll up roll up B can only be settled to
Ethereum if this state of roll up Bay is settled.
And so if roll up A equivocates, roll up B would just have
delayed settlement until it reorgs the transaction from roll
up A out of out of its history. And so, so there's this
potential for like, like we're we're basically prioritizing
safety over liveness. And so there's this potential
where if the operator of a chain misbehaves or acts maliciously,
settlement of roll up B could be delayed.
But fundamentally this is a necessary trade off for us to
provide super low latency interop.
OK, I, I, I think I understand the value proposition.
What kind of is missing for me in in my head is how do you
ensure the security and integrity of that AG layer?
So kind of where does it check in or does it have collateral
somewhere or how does it guarantee all this?
Yeah, So it proves it cryptographically with A0
knowledge proof. So, so like what's happening is
L twos are submitting blocks to the AG layer and the AG layer is
proving to Ethereum that all of these properties hold.
So the shared bridge is protected and safe and chains
are interoperating in a way that's consistent and no one's
behaving maliciously. And so it's aggregating all the
validity proofs from every single chain and also these
additional proofs that guarantee the safety properties.
And it's submitting all of this to Ethereum.
And so that's where where settlement happens.
For every block. That sounds very expensive.
So it's not necessarily submitting, submitting to
Ethereum on every block, but it's accepting blocks or batches
from each roll up. And so it's not like the the
cost of, of aggregating proofs or, or proving this is like it
actually very, very minimal relative to like your typical
cost for AZKVM. So like like proving AZKVM
transaction which which we do routinely is is actually a lot
more expensive than the the types of proofs that that the AG
layer is creating. OK.
But then kind of in between the check insurance or the AG layer
into Ethereum, what security guarantees do you have in that
interval? Yeah.
So, so like obviously you are running the risk of, of some
other chain misbehaving or of of the AG layer misbehaving.
But I think fundamentally like there's a very small window
where this can happen and the AG layer can never like settle a
malicious action or or malicious behavior to Ethereum.
And so the way that I look at it is like it's, it's very similar
to how roll ups work now. So, so most people use roll ups
and, and rely on like the pre confirmation guarantee that's
provided by the sequencer. So the sequencer basically says
like, OK, I'm accepting this transaction at, at very low
latency, maybe it's like 400 milliseconds.
And for most users, that's fine. They're, they're, they're, they
sort of have enough trust that the sequencer is not going to
misbehave and they're fine with operating on, on that guarantee.
It could be the case that certain users are, are
transacting in, in large enough amounts or, or like need a
further guarantee. And so they wait until their
transaction is posted to Etherium or until a proof is
posted to Etherium. And so like, if you're like
selling a house and accepting cryptocurrency, you're like
selling the Lamborghini, you you just have like a different
requirement for settlement versus if you're like buying us
a a low value NFT or something. And so similarly, if you are
using a chain that's on the AG layer, you have these different
stages of guarantees. So you have the initial
guarantee that's provided by the sequencer of your chain.
You have then the guarantee that's provided by the AG layer
if you need an additional guarantee.
And finally, you have the guarantee of of settlement on
Etherium. And so once everything is
settled on Etherium, it's final like that we know that it's
valid. It can never be reverted.
And so I think it's up to the to users to sort of figure out
which which assumption which guarantee sort of fits their
use. OK, so I understand that the AG
layer can't set the false transactions to Ethereum, but
can it sense the transactions? Yeah.
So, so there, there will be a mechanism to force transactions
like to force settlement without explicit cooperation of the AG
layer. The AG layer will be
decentralized. So there will be like a
censorship resistance component. But like fundamentally that the
goal is to is, is for for chains to be able to use the AG layer
with no additional trust assumptions.
So, so they, they should be able to, to guarantee that like the
AG layer can't censor, can't censor settlement of chains for
for a long period. And you know there are no
additional trust or security assumptions from from the chains
perspective. OK.
So who builds who kind of? Who makes the proofs for the
Aglayer and is it currently centralized?
Yeah, so, so the, the initial version is centralized just
like, you know, ZK roll ups are, are centralized just because,
you know, we're we're trying to do like a bunch of different
things. And I like building the system
sort of takes precedence over decentralizing it.
But in the future it will just be centralized.
Stake notes that are that are producing proofs.
And but, but again, like these, these proofs are, are, are
relatively lightweight, certainly relative to to AZKVM.
And so like you know, we, we use laptops to test proof generation
and and that will be an option for for users that are that are
producing these proofs. OK.
And so, so in, in your time when kind of the AG layers
decentralized, who will be able to generate these proofs?
So who who will run the AG layer?
Yeah, so, so stick notes. So, so we'll just have a leader
that that occurs on every AG layer slot and that leader will
be in charge of producing proofs.
OK, who's already using the AG layer?
Currently there is there are four chains connected to it,
four O 5 and which includes the Polygon ZKVM OK XSX layer is
connected to it, a star is connected to it.
And as we recently announced that we have the pessimistic
proof, you know stage one is getting you know built and it
comes very shortly, I think in four to eight weeks then I think
many other stack based chains will be able to connect into the
agglia. So you know, previously near
protocol like as a layer one has also declared that they'll be
connecting into that layer once they have the ZK.
The ZK was on proofs, so similarly like, you know, we
expect many other, you know, chains and not only new chains,
but the existing chains also connecting into it.
We in the next 2-3 weeks, for example, we also have another
one of the biggest names in the space connecting into BRT.
So yeah. What's the pessimistic proof?
The pessimistic proof. So, so this is it's an
interesting idea. So like part of the vision for
the Aglayer is that we're not opinionated about anything.
So chains should be able to use their own sequencers, their own
tokens, their own governance mechanism.
They should also be able to use their own execution environment.
So you should have chains that are able to run AZKVM type one
and type 2, the SVM miden, you know, a move VM like a custom
Rust VM, like basically whatever they want of this is that if
we're using a shared bridge, then for every VM and every
prover that we include in the agglare, the probability that
one of these provers is unsound, it can be used to generate a
proof that that's valid, but but contains an invalid transaction
goes up. And so this would be really
catastrophic because it would allow some chain to construct,
you know, proof that that verifies.
But maybe it like the block that that proof is validating
includes a transaction that allows someone to withdraw like
a millionaire or something. And, and they can drain the
entire shared bridge of all funds.
And so we don't want this to be possible.
And we, this is like a very, very important part of
guaranteeing the chains have the same security using the AG layer
as not using the AG layer. And So what we do is we
basically say, OK, from the AG layer's perspective, we assume
that every proof is unsound that that every prover has some
soundest bug that's sort of like hidden and deeper than the code.
And so instead we have this special proof that's very, very
simple and it checks it. It basically like takes in all
of the asset transfers from the bridge and it checks that the,
the token balances on each chain are conserved.
So no chain can withdraw more tokens than are currently
deposited to that chain. And so this guarantees that, you
know, I, I, I can't spin up some chain that, that has a prover
that I know is unsound and use it to, to drain, drain the
entire bridge. And so we call it the
pessimistic proof because we're basically assuming that there's
a soundness error everywhere in in every prover.
And we still want to guard against that possibility.
So, yeah. So that allows us to provide the
same security for chains as as if they were deployed on on
separate bridges. So if you're on Polygon CKVM,
your funds are safe even if there's some compromise chain
that exists elsewhere in the ecosystem.
Yeah, that makes a. Lot of sense.
So we were talking about different kind of chains
integrating into the Agda. Does this also work for
optimistic roll ups? So I think kind of we we've kind
of touched upon different ZK broad UPS, but is optimistic
fundamentally different? Yeah, so so.
Because there's such a long fraud proof challenge period, we
can't offer the same guarantees because there's no like fast
finality. That's that's, that's guaranteed
by by the chain. And so, so the chains that can
connect to the eye glare are obviously ZK roll ups and
they're also side chains that have that have finality.
And so, so, so, so you could say like, OK, I'm not going to to
generate validity proofs for my chain.
Maybe your users don't care or, or you think that, you know,
having side chain security is a sufficient security guarantee,
which which I think is a valid position.
And from the Agglio's perspective, we already have the
pessimistic proof. And so for the AG layer, like
we, we actually already assume that your, your validity proof
is not valid or there's some issue with it.
And so we can accept like a proof of consensus that verifies
the security of the side chain. The problem is like we can't
have optimistic roll ups because there's no way to offer this
short interop period where where it like like we we can't, we
can't guarantee that like the state of the optimistic roll up
won't fork if say the validators say that a particular state is
final and then a fraud proof is submitted later.
Like the aggler has to be sort of fork free after, after like
finality is reached. So that's, that's sort of the
the, the big issue with optimistic roll ups.
OK, I see. You very recently introduced
something called a Type 1 prover.
So for everyone like me, not well versed in ZKEVM proofers,
what does type one mode mean? Yeah, so, so Vitalik.
Came up with this classification framework for for ZKVMS and it
ranges from type 1 to I think type 4 and it basically refers
to like how similar an environment is to the EVM.
So, so AZKVM is like a special type of computer that's running
inside is your knowledge proof that allows us to verify
execution of EBM transactions. And so a type 4 is basically
like, OK, this computer is it's different from the EBM in, in,
in like concrete ways. But maybe we have a compiler or
something that allows us to take existing Solidity code and
compile it to this new target. And maybe, you know, it's like
90% similar or like they're, they're like, you know, there's
some parts that you have to change, you have to re audit,
but but otherwise it's it's similar and, and functionally
equivalent. Type 2 is type 2 and three are
are basically like you have an environment, you have a ZKVM
that presents a functionally identical environment to to
users and developers. And so you can take your
Solidity code, you can use it as is, users can transact with the
chain with basically no difference from from Etherium.
But we can't use that ZKVM to prove existing EVM chains.
And so that's where a type one comes in.
It allows us to take any existing EVM chain, whether it's
like an optimistic roll up, like the Polygon POS chain and we can
upgrade it to being AZK roll up. So it's so seamlessly we we can
just immediately start generating proofs and we can
convert it into a chain that's secured by Philip Lipres.
OK, OK, I see. And how does this kind of fit
into kind of the the Ag layer integration?
Yeah. So, so it allows us to take
existing like optimistic roll ups that already exist and
upgrade them to ZK roll ups so they can join the Agler.
OK, so basically this is a. Way for kind of fixing
optimistic roll up such that kind of they are compatible with
the egg layer architecture then yeah exactly so if the type 1
prover is a way of kind of making an optimistic chain
integrable into the app layer are there any drawbacks for that
I don't like I. Don't think that there are the
drawbacks. I would just say that when an
optimistic chain uses a Type 1 prover, then they don't need to
remain an optimistic chain. They can be a fully validity
proven, fully proven chain and don't need to have those
optimistic fraud proofs which need for seven days to seven
days challenge period as a safety mechanism and all those
things and they can settle instantly.
So you know, when I see of I think of optimistic chains using
the Type 1 prover, I am thinking of them upgrading into a ZK
rather than like you know, going along with both of these
mechanisms. OK, so how?
Exactly does the type 1 prover? How does it generate proofs for
for these optimistic chains? Yeah, so, so it.
It you know, it can take in what we call witness data from from 4
nerds and use it to like generate a proof that every
transaction in the block is is applied correctly to the
existing state of the chain. And so it we can just prove that
that a block is valid given a previous state.
Yeah. And Felipe, I think.
Your real question is like how does the type 1 prover kind of
like, you know, work with the optimistic or generate the proof
for optimistic chain? Actually you have to understand
what is it? What is an optimistic chain?
Like there is a simple mostly like I'm talking about EVM
chain. There is a simple, let's say get
node, right, which is running somewhere and the chain and the
get node doesn't know anything about optimistic proofs being
sent somewhere. It's a simple get node.
And then on the Ethereum, you have some few smart contracts
which are the optimistic part of the of the, of the, of the, of
the whole system, right? And when you create the ZK
proof, the ZK proofs are being created of the chain.
ZK proofs don't have anything to do with the optimistic proofs of
the smart contracts that they have on the Ethereum blockchain.
All the ZK proofs are just creating a proof for a get
chain, get based chain or any, you know, Ethereum or EVM client
based chain. And you what you do is as
optimistic chain is that you just simply strip out the
optimistic part of the chain and just use replace it with the ZK
proofs and upgraded into AZK chain.
So basically what you do is kind.
Of you, you go back to the last state of the chain that can't be
rolled back because kind of the challenge period has lapsed and
then kind of you prove that your current state is a valid
successor state of that. Is that correct?
Absolutely. Absolutely.
Oh, OK, good. What are the?
Challenges in. Building these because it it
sounds like sounds too good to be true.
So what what are the challenges in kind of building a type 1
prover? Or does it only apply to certain
kinds of chains? Yeah.
So so. So I think the challenges are
there are a few. So like a lot of the
cryptographic primitives that are used in the EBM,
specifically Catch Shack, some of the pairings, they're,
they're actually not very friendly to, to being proven in
Israel knowledge proof. And so there's like a lot of
engineering and, and research work that has gone into making
those more efficient. So specifically, yeah, like
Catch Act and, and parents. And so beyond that, things like
the NPT and RLP encoding, they're, they're just not very
ZK friendly. But what we discovered was that
a lot of the work that we've been doing in R&D in Polygon, so
developing Pocky 2 and Pocky 3, that has gotten us to the point
where we can actually accept this extra complexity and cost
and we're able to generate transactions at at very, very
low cost. And so we've been generating
basically a proof for every single Ethereum block from I
think the beginning of Shanghai or something.
And what we've seen is that for these, for these proofs the OR
these transactions, the average proving cost is between one and
2/10 of a cent. And so this is already like a
very, very competitive cost in relation to transaction fees
that users are already paying. And we think that, that the, the
proving costs will, will continue to, to decrease because
our type 1Z KB M is, is built on plucky 2.
And when we move to clock E3, that will be like a, a huge,
huge unlock and speed up. And so I, I, I think like, it's
fair to say that we're already there in terms of proving cost.
We're just trying to push the frontier of applications where
it becomes economically feasible and practical to generate
proofs. So it's right now like
everything that you currently do, I don't know too.
I think is is feasible and practical and, and the cost is
low enough to generate proofs for.
But if we want to do like games and social applications that
that aren't as like economically valuable and and don't have as
as high fee component, we need to further reduce proving costs
to to to make those sort of practical as well.
OK, so kind of the the. Only reason why kind of type 1
provers are feasible is kind of because the cost of generating
proofs has decreased so much that you can now kind of just
prove the state of the chain since the last uncontestable
state. So let let's talk about these
advances, advances in cryptography.
So you were you, you, you were talking about Plonke 2 and
Plonke 3. And the fact aside that all of
these prover systems seem to have really wacky names.
Can, can, can you walk us through kind of the evolution of
CKP system? So kind of like back in the day,
kind of we had, we had ZK snacks and ZK stocks and then kind of
these, these come with inherent limitations and challenges that
were then kind of counteracted by kind of like polynomial
commitments and recursion and so on.
Can you, can you dive in? Can you, can you dive into a
little bit more detail here? Yeah.
I I, I I. Think by by wacky names, you
mean like brilliant branding and very, actually very good names?
No, I I see, see that, see that's a.
Reason why we don't put mathematicians in the marketing
departments. Yeah, yeah, I, I.
I, I do think the placky naming might be like some of the worst
branding that's, that's ever been introduced to crypto, but I
don't know, like people, people know what it is and it's
recognizable. But yeah, so, so I, I think if
we rewind to 2019, so Daniel Lubrov, who's my Co founder of
Mir, he and I raised money for Mir in, in 2019 and it was like
a very, very nerve wracking time because the primitives that were
available for, for, for ZK tech, we're not fast enough to do what
we wanted to do. And we weren't sure how quickly
they would become faster. And so we put in a ton of effort
in 2020 and 2021 to, to improving ZK tech.
And our approach was like in the academic community, there's a
lot of focus on like asymptotic efficiency.
So like how many field operations approver requires to,
to generate a proof. And this is like a proxy for
computational cost and, and latency and improving
efficiency. But our insight was that not all
field operations are created equal.
And we should have this notion of like hardware and software
and theory code design. So we should look at like which
operations can be, can be optimized to, to be more
efficient on hardware and how that can feed into the theory
piece. And so one of the things that we
that we hit on was like Frye, which is the polynomial
commitment scheme used in Starks has this nice property that it
doesn't depend on elliptic curves.
And what this means is that like unlike elliptic curves that that
depend on or that require very large fields, so at least 256
bit fields, with Fry you, you basically have a lot of freedom
in selecting a field that might be much smaller.
And if you think about like modern CPUs, they operate on 64
bit word sizes. And so when you're simulating
256 bit field arithmetic, it's actually a lot less efficient
than if you had a field element that could fit in a single word.
And so we discovered, or Hamish from, from our team proposed the
Goldilocks field, which is this field that has like a very, very
specific structure that makes it really, really efficient on
modern CPUs. And so from there, there there
were a ton of optimizations and a ton of work that went into
Plucky 2, which was this like this vision of, of Starks that
operate on, on these small like very carefully chosen fields.
And that yielded like A50 to 100X speed up over what was
currently available on Etherium. And so, so, so that's been sort
of like the route that we've taken with with Pucky 2 and and
now with Pucky 3 where we have picked another even smaller
field that had like, it was really, really nice on CB us,
but it had this like theoretical drawback where you couldn't, it
didn't have the size property that we needed for Starks.
And so Ulrich from our team, working alongside some
researchers at Starkwear, basically figured out a way to
like change the protocol a little bit so that we could use
this, this really, really nice field with, with, with really
nice structure. And so that's kind of been the
progression is like going from the an academic mindset where
we're really, really far from like the concrete efficiency on
hardware to more of like a hardware software Co design
where we have we have engineers that are working alongside
researchers and people on the theory side to to
collaboratively build faster protocols.
OK, so I think. I'm missing like a little bit in
between here. So, so I totally understand kind
of how you set your constraints, right.
So you, you said, OK, this is kind of the GPU, this kind of
the number of CPUs with certain specs that are with that should
that this should somehow run on. And then you kind of you, you
determine the field size based on that.
But how was the field field size size chosen initially?
So how how was it decided that kind of you would need 200 and
5065 bit feared in the 1st place if kind of like half the size it
would have easily been enough. Yeah, because for.
Elliptic curves you need. You're working over a group that
that is defined by an elliptic curve, and so in order for that
to be secure, in order for the discrete log problem to be hard
enough, it needs to have a a certain minimum field size.
You you you can define an elliptic curve over an extension
field. So you could pick a small field
and and use some higher order extension, but there's still
like like that that's not what people were doing.
And and it's you're still stuck doing a bunch of arithmetic in
at least a 256 bit sized field. And so with Fry, there's no
dependence on an elliptic curve. And so, so we don't have this
minimum size requirement. OK, and so now the.
Difference between Plonke 2 and Plonke 3 is that you can use an
even smaller field, making it much cheaper.
So is this the limit or can you make it smaller still so I I?
I think it might be minimal gains from making the field size
smaller. So so the the nice thing about
Pocky 3 is that it it has a a small field that also has this
really nice structure. It's, it's a Mersenne prime,
which means that it's of the form 2 to the north -1 And I
think that the further, further improvements will come from like
on the theory side and on the like the zero knowledge proof
protocol side. And so like using different
polynomial commitment schemes, using polynomial commitment
schemes with a more efficient verifier for better recursion
efficiency. I think that these will kind of
be the routes for for future improvements, not so much
improvements on just just from reducing a field test.
What about specialized? Hardware.
So I mean this is run on on regular multi core CPUs I assume
right? So.
If you were. To build like specialized
chipsets, Would that make it much simpler or more much more
efficient? Yeah, so it so it would.
And, and there are a bunch of different projects that are
currently developing chips that that support, you know,
Goldilocks field arithmetic or, or other operations that are
that are used in improving the. The tricky thing is that some of
these some of like FPGA and GPUs might be like hardware or might
be memory or, or bandwidth limited.
And so you might be able to really accelerate certain parts
of the prover, but end to end it might be, it might still be the
case that you know things are cheaper on ACPU.
But I think that we're seeing a lot of efforts toward hardware
improvement and I think that a lot of these are going to are
going to yield very significant speed UPS in the near future.
OK, so do. You remember when Z Cash had the
bug in the cryptography for the shielded pools.
So kind of with all of this very advanced cryptography, the
problem is that the number of people who really understand it
to the core is very small. And kind of you always, you
always run the risk that kind of there's a vulnerability
somewhere in there that just no one's found yet, right.
So I, I hear that kind of like if if you look at kind of like
how you set up the egg layer with kind of the pessimistic
proof and so on, kind of, I mean, you, you everywhere,
you're kind of trying to contain the risk of introduced
vulnerabilities. But if something like Plunky
three were to kind of be faulty on some level, what would that
mean for the system? Yeah.
So, so I, I, I, I think this is like the very much a top of mind
concern for us. And our strategy has been to
sort of have a gradual progression of, of like
governance minimization and, and decentralization.
I think it's really important for ZK roll ups or for protocols
that use ZK technology to launch with training wheels and to give
their systems time to, to be scrutinized and, and to develop
and, and to, you know, potentially have formal
verification. And so I think that we're, we're
still like very much in the early stage of this process.
And I think it's important to, you know, we're, we're, we're
also doing audits and, and like we're, we're, we're very much
like in bug bounties and, and taking like an approach that,
that we really want these systems to be scrutinized and,
and to be secured. But I think like with a lot of
things in cryptography, it's just a, a question of time.
And we just need these systems to be in production and securing
value in kind of a training wheels mode where if there is a
soundness issue, it can be detected and it can be remedied
by, you know, an emergency Security Council or something
like that. And so I, I, I, I think that
that's the best strategy because, you know, we, we need
like to provide a sufficient incentive or, or, or like a
sufficient level of exposure to systems to harden them.
But at the same time, we can't progress too quickly and, and
really put user funds at risk. And so that's kind of the,
we're, we're like trying to balance those, those two
concerns. What shape do the?
Training wheels take here then. Yeah, so, so right now.
Like for like, like we, we can take the ZKVM roll up for
example. So, so like, like I think like
every ZK roll up that currently exists, only a single designated
party can provide proofs to this roll up.
So, so we are the only approver. I, I, I believe that this is the
case for stock Ware and, and for ZK sync and for scroll.
There's only one party that can provide proofs so that if there
is a soundness issue, it cannot be exploited by, by an attacker.
The second training wheel is an emergency Security Council where
if there is an issue that's detected like we, we, we
basically run every transaction twice.
We, we, we run it once to prove, but, but we also run it to, to
basically check that execution is correct and, and that the
proof is consistent with, with what we're executing in the
client. And if those two were ever to
differ or if someone were to submit a transaction that could
potentially cause an issue, we, we have the ability to fault the
system and to rely on the Security Council.
That's the majority is from outside Polygon to address that,
that issue. And so, so I, I think that this
is the same strategy as As for the AG layer where, you know,
users are still getting a much higher level of security because
like we cannot steal. User funds because we would have
to like exploit a soundness issue or or or or or, you know,
prove something that's invalid. But if a soundness issue is
detected like we have the ability to to address them.
OK, so. Maybe this is a question for
Sandeep now. So Sandeep, you guys have put
together this very ambitious vision of how the future of the
Internet should kind of look under the hood, right?
And it is. It's certainly super compelling.
If I were to tell you I had a crystal ball and I had a crystal
ball and I could look into the future and in five years it
doesn't work anything like that. What do you think the issue will
have been? So if this fails, why will it
fail? I would say that the your.
Crystal ball is not paying its Internet bill and it's not
showing you the correct results. So use Moses pay to pay the
Internet bills of your crystal ball.
No, I mean seriously, I think that you know, we as a unit have
been working on this problem and many times like, you know,
people come to us today that Polygon is not doing this.
And they talk about a lot of these short term things like you
know, Polygon is not doing this, Polygon is not doing that this
that they should do this, they should that.
But The thing is that for us the mission has been extremely clear
from get go and that mission is very simple that how do we
create this infinitely growing web three, you know,
infrastructure, right? Our blockchain network,
infinitely grown blockchain. You know, if somebody tells me
like, OK, this system works for 50,000 DBS, this system works
for 100,000 DBS, not interested. We want to build an infinitely
growing network. So which can take like even like
who knows, 1,000,000, two million, 2 million, even 1
billion TPS in 20 years, it should be able to take that.
So if you ask me that architecture, I don't see, I
mean, as of now, like I don't see there, there there can be an
there can be an alternate architecture which can achieve
this, you know, this infinite scalability while like, you
know, also solving from this fragmented liquidity and you
know, user experience and all that.
And if let's say that doesn't happen, Aglier is not that I
would say somebody else would be there, but their architecture
will be very similar to Aglier. Like something like this will
win, whether it's polygons, Aglier or somebody else's Aglier
that nobody can tell. But somebody like this will win
something like this will win. I think those.
Are fantastic parting words. So Sandeep and Brendan, if
people want to learn more about this, they kind of dive into the
docks and so on because obviously this was we we've
barely scratched the surface here.
Where do they go? How can they start building on
this? Yeah.
So, so the Aglayer docks are, I believe on, on the Polygon
website. I, I believe that we, we will be
spinning up a separate website that's Aglayer focused that
we'll have the, the docks there. But yeah, they're welcome to, to
go there. They, they're welcome to reach
out to me directly and, or anyone from our, our engineering
team. And yeah, go from there.
And I also want to as a. Parting way, just want to say
that you know, with this AG layer, that Polygon like kind of
extends beyond a layer two network like, you know, we I
like with AG layer, once the AG layer comes in fully, you can't
really like add layer is not a layer one or layer two.
It's a it's kind of a meta layer which allows layer tools and
many of them will be simple connected chains who are not
even using the layer two validity proofs, but they still
can exist in this multi chain environment.
And so, you know, that is that the Polygon transcends this
layer two layer one debate and then, you know, goes into a
place where it can actually support this infinite
scalability while using Ethereum as the settlement layer.
And that has been our core thesis from day zero.
And I think like now we are at a place with Aglayer where we can
take it to, you know, more closer to reality.
Cool super. Nice.
Thank you guys. As always.
It's been very elucidating. I look forward to having you
guys on in six months time and see what you've felt then.
Yeah. Thanks Rodriga.
Thanks for the weekend, always nice.
Talking to you. Thank you.
Bye. Bye.
Thank you for joining us on this week.
'S episode We release new episodes every week.
You can find and subscribe to the show on iTunes, Spotify,
YouTube, SoundCloud, or wherever you listen to podcasts.
And if you have a Google Home or Alexa device, you can tell it to
listen to the latest episode of the Epicenter podcast.
Go to epicenter.tv/subscribe for a full list of places where you
can watch and listen. And while you're there, be sure
to sign up for the newsletter so you get new episodes in your
inbox as they're released. If you want to interact with us
guests or other podcast listeners, you can follow us on
Twitter. And please leave us a review on
iTunes. It helps people find the show,
and we're always happy to read them.
But thanks so much and we look forward to being back next week.