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.