'Ethereum Needs Polygon's Aggregation Layer to Scale' - Brendan Farmer & Sandeep Nailwal. Ep. 552

Transcript

if we3 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 ethereum and facing ethereum's ability to scale is fragmentation of altitudes because right now we have this proliferation of l2s but uh liquidity is not shared between those l2s state is not easily shared between those l2s like users have a difficult time moving between those l2s what polygon is building is basically a guarantee of safety for a shared Bridge which allows different l2s to have asset fungibility uh between their chains l2s are submitting blocks to the AG and the agair is proving to ethereum that all of

these properties hold welcome to epicenter the show which talks about the Technologies projects and people driving decentralization and the blockchain revolution I'm freder an and today I'm speaking with Brandon farmer and sandip Nal who are the co-founders of polyon before we talk with Brandon and cep let me tell you about our sponsors this week this episode is brought to you by nosis nosis builds decentralized infrastructure for the ethereum ecosystem with a rich history dating back to 2015 and products like safe cow swap or nosis chain nosis combines needs driven development with deep technical expertise this year marks the launch of

nosis pay the world's first desent centralized payment network with agnosis card you can spend self- custody crypto at any Visa accepting Merchant around the world if you're an individual looking to live more onchain or a business looking to wh label the stack visit nois pay.com there are lots of ways you can join the nosis journey drop in the nosis Dow governance form become a nois validator with a single gno token and lowcost Hardware or deploy your product on the evm compatible and highly decentralized nosis chain get started today at nosis doio cars 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 stti with corus 1 including institutions like bitgo and Ledger sticking with corus 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 cors one's public note from your wallet set up a white label note or use the recently launched product Opus to stake up to 8,000 e 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 star sake today at chorus. one sandip and Brandon thank you so much for coming on sandip you have been on multiple times before um so let's start with brandan today Brandon you are a co-founder of polygon by way of having founded my protocol which was then acquired by polygon um tell us about my uh yes so Mir was a uh it was an L1 that was trying to use ZK for privacy and skill ability and so we started mirror in 2019 and by 2021 uh really realized that we did not want to build

an L1 and wanted to build in the ethereum ecosystem and sandip and Maho and the polygon Founders were you know gracious enough to uh to offer us a platform to do that yeah super nice so sandip 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 ISS but I think there were there were um a couple of other ones as well right uh yeah like there was like Hermes and uh you know the like May protocol and then other was not an acquisition more of a aquire like was the Facebook's

Winterfell project uh which is like you know which became polygon mid even now uh you know we we recently finished the acquisition of topos Weare who is also uh one of the um you know one of the leading uh companies who are working on this aggregation thesis and uh you know we have been working very closely on our code base uh and the fun part is like now polygon ZK is like so deep into the into the whole ecosystem whether it's like uh suxing sp1 building on plony 3 or uh like you know different different protocols using either directly using

the open source code or uh get you know their architectures fully you know inspired by that so we are already doing a lot of stuff so topos faere was also like one of the teams was working on our code base and thinking about like a more of an aggregated uh 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 one PR uh that we have and things like that so yeah that has been uh like a long journey because we are absolutely clear that you know if web3 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 uh those were very

good beds to place you're kind of bringing a lot of the research you have done over the years together um in this um thing called aggregation layer that you launched earlier this year can you set the stage here so what aggregation layer what problems are you looking to solve with it yeah sure I can I can take that um so the way that we see the world is the that the biggest problem facing ethereum and facing eum's ability to scale is fragmentation of l2s because right now we have this proliferation of l2s but uh liquidity is not shared between those l2s state is not easily shared between those l2s like users have a difficult time moving between those l

and so we are scaling ethereum by adding additional block space but we aren't scaling ethereum in the sense that we're not uh scaling access to liquidity in to Shared State um like if you think about uh like you know the the value that's bridged to arbitrum that doesn't help uh optimism it doesn't help other l2s 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 their sort of liquidity and and Bridge value and defi activity um but we're not able to contribute to ethereum's network effects globally and and to contribute to uh to like the overall way that that uh ethereum

functions for users and developers and so the AG layer is an attempt to to fix fragmentation on ethereum it's an attempt to make it really easy for users to uh to move State and value and liquidity between L2 chains uh so that we can have like a hor onally scalable ecosystem for an execution layer for 3 but one in which we're able to scale access to uh to liquidity into shared State basically like a multi-chain ecosystem that feels like you're still using a single chain where we have composability and and all these size properties that we like on L1 okay so basically um 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 um the way that I kind of get from base to arbitrum despite the fact that they are both layer twos on this shared security layer of ethereum is by kind of exiting to ethereum um at the cost of kind of doing a transaction on mayet which is notoriously expensive and then kind of um moving into the other L2 um and there's no way for me to kind of laterally move from base to arbitrum and that's what we're fix fixing is that correct yeah yeah exactly so so exactly like you said like like suppose that I have some Ethan 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 uh withdraw my eth uh through the native bridge on base and then uh submit an1 transaction and deposit into arbitrum um obviously the problem is that Bas is an optimistic rollup and uh it takes 7 days for me to withdraw of the Native Bridge um and then I have to wait for that transaction to be finalized I have to wait for my deposit to arbitrum to be finalized and the L1 transaction is expensive um 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 their native eth onm L2 and

instantly Bridge it over to uh to arbitrum and get native eth um and be able to do things on that chain uh the second option that users can do is they they can uh withdraw via a third-party Bridge so there are thirdparty bridges that connect different L2 chains um but the problem here is like the trust assumption for using a third-party bridge is much much different and there's uh a requirement for users to rely on liquidity providers and market makers to basically swap from the rep synthetic version of a token so let's say I use Wormhole to bridge from base to arbitrum I get wormhole wde on arbitrum and I have to pay some amount of money to swap that into arbitrum

native eth so that I can reclaim my attchment and so what we can think about the AG 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 uh like ethereum block time or ethereum finality okay I I understand uh the goal here um how how do you make it work sure so this is a good question and and stop me if I'm getting two in the weeds but um what polygon is building is basically a guarantee of safety for a shared

Bridge which allows different l2s to have asset fungibility uh between their chains um so so this is what allows us to avoid making an L1 transaction when we move funds we can just take uh L1 native eth and move it between chains and we never have to touch the L1 um and the second thing is it allows us to provide this cryptographic guarantee of safety so that chains that are interoperating uh at lower latency than like even in ethereum Block time but certainly the time that it takes to finalize an ethereum block um are to risk of some sort of mil Behavior like a chain can't equivocate or a shared sequencer can't um you know lie about

the messages that are sent between chains um and so the EG 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 emerging 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 and uh these mechanisms benefit from the shared bridge and the safety guarantees the agair provides so like the like like one case would be for a shared sequencer um uh 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 uh a user could submit a transaction on on one L2 um to move funds and and claim a mint on another chain and then swap back to the original chain um or uh you know access some key store that's located on a third chain and the Builder could do all of this simultaneously and the Ager would guarantee that for all of these chains um the Builder can't misbehave and asset fundability is guaranteed and so that's sort of like the way that we can think about this working 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 um if if I want to start transaction on base um that kind of bridges to uh arbitrum and then back in one uh in one transaction um the the the Builder has to support both right yeah so so so this is I think that that we should emphasize that there there are different roles that that exist in this model that that maybe don't exist in the same way for L1 and so in the shared sequencer case where we want we have synchronous composability and you know this isn't required for all

chains chains could operate asynchronously too um but in in the synchronous case which is sort of the Holy Grail of composability uh a builder would uh 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 we're our Hardware requirements are going to blow up um but we have to distinguish between the actors that are building blocks that uh are super sophisticated they might be running uh in data centers and and have access to a large amount of hardware and the validators on L1 that that can be fully uh you know have very minimal trust requirement or very minimal Hardware

requirements and can fully validate everything that happen L2 um 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 um 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 uh in the extent to which they can extract rent um and so I I I think we're sort of moving to this world where where uh block building is just uh a role and a function that might not be accessible to everyone who's running a note on their laptop or a Raspberry Pi

um but I wonder to what extent it's like a necessary step to deliver uh very very good ux at least for synchronous composability yeah I also want to add uh one thing on that R like the question you asked from a very simple users point of view that if I am uh let's say or in fact a chain point of view right let's say there is a transaction where uh you know there is a cross-chain transaction between three different chains uh 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 a you know 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 AG layer is more focused on uh and then on top of that people can build shared sequencing kind of uh mechanisms is the asynchronous composability where you know if you want to do do if your user let's say I come to a user which is let's say uh connected to a chain chain a and I do a

transaction but that transaction interacts with chain B and chain C in a asyn agay 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 uh but it will go asynchronously you cannot guarantee Ager doesn't guarantee you that this the entire series of transaction will go through uh with the same set of conditions that the user initially started with uh 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 uh you know a DEX transaction or something something changes the user transaction might or might not fail but if the

conditions are correct the chains will honor that transaction in asynchronous with whereas uh you know if you needed uh 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 Ager 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 Ager 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 thousand chains and each application eventually spinning up their own chains meaning

like tens of thousands of chains and what how we see is that there will be like n like a large number of that uh those those chains connected to the Ager will be individual sequence chains so you can do uh 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 some particular consortiums consortiums and all that is fully dependent on the use cases AG is pretty pretty agnostic to that okay 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 you're you're distinguishing two cases here so one where kind of um the transactions happen one after the other so kind of say for instance I Bridge from change a to chain B there I swap token X for token y then I bridge to um chain C buy an nft against token y that I really wanted and then Bridge back to to chain a um and then there's the other case where kind of everything where kind of all the transaction all the transactions happen um at once or they don't happen right kind of what what I would call kind of an atomic um transaction right so basically you bundle everything together

so for instance if I want to do uh if I want to AR something that's kind of how how I would want to do it in order to kind of minimize my own risk right um and you're saying that the subsequent transactions that is possible today with with um a layer whereas kind of the atomic transactions um that is something that would require shared sequencing which is kind of um very much in uh which is optional for chains to kind of opt into and you kind of see specialized cases is coming up where that will be uh that where that will be done is that more or less correct yeah that was very well summarized to yeah I would say like the we're still working on both the ASN

and the and the Syrus and atomic case um but yeah I I I I think that's exactly the way to frame it um yeah I just not not to get off topic but but I I think this is sort of interesting like the orb case um that you describe I I think is like a really good example of of when atomicity is is really important um 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 train in the world will be uh using the same shared sequencer and the same shared Builder um but you could imagine like if we're trying to scale defi to like internet scale or to like global scale what that looks like it it it could be um 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 uh for people trying to Arbitrage to be able to do atomic uh 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 uh like either both legs of an arm go through or neither um and so I think like I I wonder if most of the world um composes asynchronously with these sort of like defi hubs which are like synchronously connected via a shared

sequencer um or whether sort of uh 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 um under the C this is kind of an aside here um I I want to get back to uh to the asynchronous case because that's kind of what works um today um 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 um possible to have a composite model where where you say every other block is kind of um executed by synchronous um sequences and um every other block is

done by regular people because obviously um or at least my concern would be that um the hardware requirements and kind of the dev Ops capabilities needed to kind of run um the hardware behind a shared sequencing setup um 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 um 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 um atomically you wait for that slot and every other block is built by uh independent Builders yeah so I I I I think that's definitely one approach um another approach would just be to like I I I think implicit in the shared sequencing construction is sort of a natural fallback where uh if a block Builder goes offline or misbehaves or or attempts to rent seek um 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 um 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 produc enough block producing nodes to provide sensorship 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 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 aglar ecosystem are locked in the same contracts so all l2s that uh that opt into the agair have this shared deposit contract that saves us from or saves them from uh having to submit an L1 transaction every time we do uh asset movement or asset transfer across chance um and so the the interesting thing with the with the ASN case is like like we so so we have asset fundability and we also really want low latency interrupt so uh right now like uh if you want to we were talking about this earlier but if you

want to uh move assets between l2s even if you have a shared Bridge um there's still this uh like heavy latency penalty because let's say that I'm on uh rollup a and I want to move my eth to rollup b um in order for rollup B to accept accept the message that's that transfers assets uh from rollup a to rollup B it has to have a guarantee that rollup a state is finalized otherwise rollup a could equivocate it could create two blocks one of which has a transfer to rollup B one of which doesn't and it could submit the the block with the transfer to rollup B to rollup B and it could submit the block without the

transfer toilla B to ethereum to be settled uh on ethereum in the case in which uh in which we have to wait for finality on ethereum 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 finalist so instead what we can do in the AG is rollup B can declare that it has this dependency on some state of rollup Bay so I can say okay I I've received this state of roll Bay that includes a message telling me to Mint uh a bunch of be and give it to this user but uh like I'm going to Via the AG guarantee that my rollup rollup B can only be settled to ethereum if this

state of rollup a is settled and so if rollup a equivocates uh rollup B would just have delayed settlement until it reorgs the transaction from rollup aay out of uh out of its history and so um so there's this potential for like like we we're basically prioritizing safety over livess and so there's this potential where if uh the operator of change misbehaves or acts maliciously um settlement of Ro B could be delayed uh but fundamentally this is a necessary tra off for us to provide super low latency interrup okay 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 a layer so kind of where does it check in or does it have collateral somewhere or how does it all this yeah so it proves it cryptographically with a zero knowledge proof so so like what's happening is uh l2s are submitting blocks to the AG and the AG is proving to ethereum that all of these properties hold so the shared bridge is protected and safe um and uh 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 these 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 uh submitting two ethereum on every block but it's accepting uh blocks or batches from each Rollo and so it's not like the the cost of of aggregating proofs or of proving this is like actually very very minimal relative to like your typical cost for a zkm so like like proving a zkm transaction which which we do routinely is is actually a lot more expensive than the the types of proofs that uh that the aers created okay but then kind of in between the

checkins or the ad layer into ethereum what security guarantees do you have in that interval yeah so so uh like obviously you are running the risk of um of some other change misbehaving or of the AG misbehaving um but I think fundamentally like there's a very small window where this can happen and the Ager can never uh like settle a malicious action or malicious behavior to ethereum and so the way that I look at it is uh like it's it's very similar to how rollups work now so so most people use rollups and and rely on like the pre-confirmation guarantee that's

provided by the sequencer so the sequencer basically says like okay 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 they sort of have enough trust that the sequencer is not going to misbehave and they're fine with operating on that guarantee it could be the case that certain users are um are transacting in in large enough amounts or or like need a further guarantee and so they wait until their transaction is post posted to ethereum or until a proof is posted to ethereum and so like if you're like selling a house and accepting cryptocurrency or like selling a Lamborghini you you just

have like a different requirement for settlement um versus if you're like buying a a low value nft or something and so similarly if you are using a chain that's on the egg 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 guarant that's provided by the agir if you need an additional uh uh guarantee and finally you have uh the guarantee of of settlement on ethereum and so once uh everything is settled on ethereum it's final like that we know that it's valid uh it can never be reverted and so I think it's up to to users to sort of figure out which uh which assumption

which guarantee sort of fits their use case okay so I understand that the agaya can't um settle false transactions to ethereum but can it send the transactions um yeah so so there there will be a mechanism to force transactions like to force settlement uh without explicit cooperation of the AG um the AG will be decentralized so there will be like a censorship resistance um component but like fundamentally the the goal is to is is for for chains to be able to use the IG with no additional trust assumptions so so they they should be able to to guarantee that uh like the aglar can't censor uh can't censor

settlement of chains for uh for a long period and um you know there are no additional trust or security assumptions from from the chains perspective okay so who builds who kind of who makes the proofs for the egg layer and is it currently centralized yeah so so the the initial version is centralized Ju Just Like You Know ZK rollups are are centralized just because uh you know we're trying to do like a bunch of different things and um I like building the system uh sort of takes precedence over decentralizing it um but in the future it will just be uh decentralized Stak nodes that are that are producing proofs and um but but again like the these proofs are are are

relatively lightweight uh certainly relative to uh to a zbm and so um like you know we we use laptops to test uh per generation and and that will be an option for um for users that are that are producing these proofs okay and so so in in your time when kind of the a layers is uh decentralized who will be able to generate these proofs so who who will run the AGA yeah so so uh stick note so so uh we'll just have a a leader that that occurs on every agare slot and that leader will be uh in charge of producing uh

apprach okay who's already using the ACA currently uh there is uh there are four chains connected to it uh 405 and uh which includes uh uh the polygon ZK VM okx is X layer is connected to it AAR is connected to it and uh as we recently announced that we have the pessimistic proof uh you know stage one is getting uh you know built and it comes very shortly I think in 4 to 8 weeks then I think many other uh stack based chains will be uh able to connect into the ha so um you know previously near protocol

like as a layer one has also declared that they'll be connecting into the agay once they have the ZK uh ZK wasm proofs so similarly like you know we expect many other uh 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 uh one of the biggest names in the space uh connecting into the AAR so yeah what's the the pessimistic proof the pessimistic proof so so this is uh it's an interesting idea um so like part of the vision for the agare is that uh were not opinionated about anything so

chain should be able to use their own sequencers their own tokens their own governance mechanism uh they should also be able to use their own execution environment so you should have chains that are able to run uh a ZK VM type 1 and type two uh the svm uh miden um you know a move VM like a custom rust VM like basically whatever they want the problem with this is that if we're using a shared bridge then for every VM and every prover that we include in the AG the probability that one of these provs is unsound and can be used to generate uh a proof that that's valid but but contains an invalid transaction uh goes up and so this would

be really catastrophic because it would allow some chain to construct uh you know a proof that that verifies but maybe like the block that that proof uh is validating includes a transaction that allows someone to withdraw like a million e 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 that chains have the same security using the a layer uh as not using the AER and so what we do is we basically say okay from the a layer's perspective we assume that every proof is unsound that that every Prov has some soundest bug that that's sort of like hidden deep with in the

code um and so instead we have this special proof that's very very simple and it checks uh 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 aov 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 errror um everywhere in in every prover and we still want to guard uh against that

possibility so yes so that allows us to provide the same security for chains um as uh as if they were deployed on on separate Bridges so if you're on polygon ckvm uh 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 EG layer does this also work for optimistic rollups so I think kind of we've kind of touched upon different ZK bro ups but is optimistic fundamentally different yeah so so because there's such a long fraud prooof challenge period um we can't offer the

same guarantee because there's no like Fast finality that's that's uh that's guaranteed by uh by the chain and so so the chains that can connect to the agare are obviously ZK rollups and they're also side chains that have uh that have finality and so so so so you could say like okay um I'm not going to to generate validity proofs for my chain maybe your users don't care 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 AG's perspective we already have the pessimistic proof and so for the AG like we actually already assume that your your validity proof uh is not

valid or there's some issue with it and so we can accept uh like a proof of consensus that verifies the security of the side chain the problem is like we can't have optimistic rollups because there's no way to offer this short interop uh Peri period where where like like we we can't uh we can't guarantee that like the state of the optimistic rollup won't Fork if say the validators uh say that a particular state is final and then a fraud proof is submitted later um like the agler has to be sort of fork free after um after like fin finality is reached um so that's that's sort of the the the big issue with

optimistic rups okay I see you very recently introduced something called a type one pro so for everyone like me not well vered in uh ZK evm provs what does type one mode mean yeah so so metallic came up with this classification framework for for ZK VMS and it ranges from type one to I think type four and it basically refers to like how similar an environment is to the evm so so a zkm is is like a special type of computer that's running inside a Zer knowledge proof that allows us to verify execution of evm transactions and

so um a type four is basically like okay this computer is it's different from the evm in in in like concrete ways but maybe we have a compiler or something that allows us to take uh existing solidity code and compile it to this new Target um and maybe you know it's like 90% similar or like there are like you know there's some parts that Cod you have to change you have to re audit but but otherwise it's it's similar and functional equivalent um type two is type two and three are uh are basically like you have an environment you have a zkv m that presents a functionally identical uh uh environment to um to

users and developers and so you can take your solidity code you can use it as is users can transact with the the chain with basically no difference from from ethereum um but we can't use that zkv M to prove existing evm chains and so that's where type one comes in it allows us to take any existing evm chain whether it's like an optimistic rollup like the polygon POS chain and we can upgrade it to being a ZK rollup so so seamlessly we we can just immediately start generating proofs um and we can convert it into uh a chain that's secured by fly proofs okay okay I see and how does this kind of fit into kind of the the agay

integration uh yeah so so it allows us to take existing like optimistic rollups that already exist and upgrade them to ZK rollups so they can join the a okay so basically this is a way for kind of fixing optimistic rollup such that kind of they are compatible with um the EG lay architecture then yeah exactly uh so if the uh type one proof is a way of kind of making an optimistic uh chain integrable into the app layer are there any drawbacks for that I don't like I don't think that there are any uh drawbacks I would just say that when an optimistic chain uses a

type one pro 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 7 days to 7 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 uh using the typon prover I am thinking of them upgrading into a ZK uh rather than like you know going along with both of these mechanisms okay so H how exactly does the type one pro um how does it generate proofs for for these optimistic

chains yeah so so it it uh you know it can uh take in what we call witness data from uh from Full nodes and use it to like generate a proof that every transaction in the block is uh is applied correctly to the existing state of the chain um and so it we can just prove that that a block is valid given a previous state yeah and fr I think your real question is like how does the typ one prover kind of like you know work with the optimistic or generate the proof for optimistic chain actually you have to understand what is a what is an optimistic chain like there is a simple

mostly like I'm talking about evm chain there is a simple uh 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 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 or the smart contracts that they have on the ethereum blockchain all that the ZK proves are just creating a proof for a get chain get based chain or any uh uh you know ethereum or evm client based chain and

uh you what you do is as a optimistic chain is like you just simply strip out the optimistic part of the chain and just use replace it with the ZK proofs and upgrade it into a ZK chain so basically what you do is kind of you um 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 successes state of that is that correct absolutely absolutely oh okay cool what are the challenges in building these because it it sounds like uh sounds too good to be true so what what are the challenges in

kind of building a type one pro or does it only apply to certain kinds of chains yeah so so I think the challenges are um there are a few so so um like a lot of The cryptographic Primitives that are used in the evm specifically Kack some of the pairings they're they're actually not very friendly to um to being proven and as Z knowledge proof and so um there's like a lot of engineering and and research work that has gone into uh making those more efficient um so specifically yeah like ketra and uh and pars and so um beyond that uh things like uh the MPT and orlp

encoding they they're just not very ZK friendly um but what we discovered was uh that a lot of the work that we've been doing in R&D in polygon so uh developing py 2 and py 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 for at at very very low cost and so we've been uh generating basically a proof for every single ethereum block from I think the beginning of high or something and what we've seen is that for these um for these proofs the or these transactions the average proving cost is between 1 and 2/10 of a cent um and so this is already like a very very

competitive uh cost in relation to uh transaction fees that users are already paying um and we think that uh that the the proving cost will will continue to to decrease because uh our type 1 zbm is is built on py 2 and when we move to py 3 that will be like a a huge huge uh unlock and speed up um and so I I think like it's fair to say that we're already there in terms of pring cost we're just trying to push the frontier of applications where it becomes economically feasible and practical to generate proofs so so right now like everything that you currently do out now to I think is uh is feasible and

practical 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 a fee component uh we need to further reduce proving costs to to to make those sort of practical as well okay so kind of the the only reason why kind of type one proofers are feasible is kind of because the um cost of generating proofs um 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 Advan advances in cryptography so you are you you you were talking about plony 2 and plony 3 and the fact aside that all of

these Prov systems seem to have really wacky names um 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 SNS and ZK stocks um and then kind of these uh these come with inherent limitations and challenges that were then kind of counteracted by kind of like polinomial commitments and recursion and so on can you can you dip in uh can 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 uh actually very good names no

she she that she that's a reason why we don't put mathematicians in the marketing departments yeah yeah I I I I do think the plony naming might be like some of the worst branding that's that's ever uh 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 I think if we rewind to 2019 um so Daniel uh lubero who is my co-founder of Mir uh he and I raised money for Mir in 2019 and it was like a very very nerve-wracking time because The Primitives that uh were available for for for ZK Tech uh were 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 uh to improving ZK Tech and our approach was um like in the academic Community uh there's a lot of focus on like um Asm efficiency so like how many field operations um approver requires to to generate appr proof and this is like a proxy for computational cost and and latency and improving efficiency but our Insight was uh that not all field operations are created equal and we should have this notion of like hardware and software and Theory codesign so we

should look at uh like which operations can be uh 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 uh like fry which is the polinomial 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 uh that depend on or that require um very large Fields so at least 256bit Fields with 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 uh 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 heish from from our team proposed uh the Goldilocks field which which is this field that has like a very very specific structure that makes it really really efficient on Modern CPUs um and so from there the there were a ton of optimizations and a ton of work that went into uh py 2 which was this uh like this vision of of starks that operate on on these small like very carefully

chosen fields and that yielded like a 50 to 100x speed up over what was currently available on ethereum and so so so that's been sort of like the route that we've taken with with py 2 and and now with py 3 where we have picked another even smaller field that had like it was really really nice on CPUs but it had this like theoretical drawback where you couldn't it didn't have the nice property that we needed for Starks and so oric from our team uh working alongside some researchers at starkware uh basically figured out a way to like uh change the protocol a little bit so that we could use this um this really really nice uh field with with uh with really nice structure um and so that's

kind of been the progression is like uh going from an academic mindset where um we're really really far from like the concrete efficiency on Hardware to more of like a hardware software code design where we have um we have Engineers that are working alongside researchers and people on the theory side um to to collaboratively build faster protocols okay so I think I'm missing like a little bit in between here so so um I totally understand kind of how you set your constraints right so you said okay this is kind of the GPU or this is kind of the number of um CPUs with um certain specs that are that should 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 side size chosen initially so how was it decided that kind of you would need a 250 uh 65 bit field in the first place um if kind of like half the size would have easily been enough yeah because for elliptic curves you need uh you're working over a group that that is defined by an elliptic curve and so in order for that uh to be secure in order for the discrete light problem to be hard enough it needs to have a certain minimum field size you you you can Define elliptic curve over an extension

field so you could pick a small field and and use some higher order extension but this still like like that that's not what people were doing and and it's uh you're still stuck um doing a bunch of arithmetic in at least a 256bit sized field um and so with fry there's no dependence on an elliptic curve and so so we don't have this minimum uh size requirement okay and so now the difference between plony 2 and py 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 uh so I I I think it might be minimal gains from making the field size

smaller so so the the nice thing about py 3 is that it um it has a a small field that also has this really nice structure it's a uh it's a ren Prime which means that it's of the form 2 the N minus one um and I think the further um 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 uh polinomial commitment schemes um using poal commitment schemes with a more efficient verifier for better recursion efficiency I think that these will kind of be the routes uh for for future improvements not so much

improvements on just just from reducing us what about specialized Hardware so I mean this is run on on regular multicore CPUs I assume right yep so if you were to build like specialized chip sets would that make it much simpler or much more efficient yeah so so it would um and and there are a bunch of different projects that are currently developing uh uh chips that that support you know goldilux field arithmetic or or other operations that are that are used in improving um the the tricky thing is that some of these uh some like fpgas and gpus might be like Hardware or might

be memory or or bandwidth limited and so um you might be able to really accelerate certain parts of the pro but end to end it might be it might still be the case that you know things have cheaper on a CPU um but I think that we're seeing a lot of uh efforts toward Hardware Improvement and uh I think that a lot of these are going to are going to yield very significant speed UPS uh in the near future okay so do you remember when zcash 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 um who really understanded to the course

very small and kind of um 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 um 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 um introduced vulnerabilities but if something like plony 3 where to kind of be faulty on some level what would that mean for the system yeah yeah so so I I I I think this is like 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 rollups 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 to uh 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 um and I think it's important to you know we're we're also doing Audits and and like we we're very much like in bug bounties and taking like an approach that that we really want these systems

to be scrutinized and and to be secured um 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 uh in kind of a training wheels mode where if there is a soundness issue it can be detected and it can be uh remedied by you know an emergency Security Council or something like that and so I I I think that that's the best strategy because you know we we need like to provide a sufficient incentive or or like sufficient level of exposure to systems to harden them uh but at the 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 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 can take the ZK VM rollup for example so um so like like uh I think like every ZK rollup that currently exists uh only a single designated party can provide proofs to this rollup um so so we are the only I I I believe that this is the case for starkware and for ZK sync uh and for scroll um there's only one party that can provide proofs so that if there is a soundness issue uh it cannot be exploited um by by an attacker um the

second uh training wheel is an emergency Security Council um where uh if there is an issue that's detected like we we we basically run every transaction uh twice we we run it wants to prove but but we also run it to to basically check that execution is correct and that the proof um is consistent with with what we're executing in the client um and if those two were to differ or if someone were to submit a transaction that could potentially cause an issue we we have the ability to Halt the system and to rely on a security Council that's uh the majority is from outside polygon to address that uh that issue and so so I I think that this is the same strategy as as for the AG where um you know users

are still getting a much higher level of security because like we cannot steal user funds because we would have to uh like exploit a soundness issue or or or you know prove something that's invalid um but if a stus issue is detected uh like we have the ability to um to address it okay so maybe this is a question for s now um so sandip you guys have put together this very ambitious um 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 bowl and uh I had a crystal ball and I could look into the future and in 5 years um it doesn't work anything like that um what do you think the issue will have been so if this fails why would it fail I would say that 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 bow no I mean uh seriously I think that uh you know we as a unit have been uh 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 uh web3 you know infrastructure right our blockchain Network infinitely growing blockchain you know if somebody tells me like okay this system works for 50,000 DPS this system works for 100,000 DPS not interested we want to build an infinitely growing Network so which can take like even like who knows 1 million 2 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 uh you know this infinite scalability while like you know also solving from this fragmented liquidity and uh you know user experience and all that and if let's say that doesn't happen agier is not that I would say somebody else would be there but their architecture will be very similar to AGA like something like this will win whether it's polygon's Ager or somebody else is AG that nobody can tell but somebody like this will win

something like this will win I think those are are fantastic parting words so sandep and Brandon if people want to learn more about this it kind of dive into the docs and so on because obviously this was we we've barely scratched the surface here um where do they go um how can they start building on this yeah so so the AG docks are uh I believe on on the polygon website I I believe that we we will be spinning up a separate website uh that's Ager focused um that will have the uh the docs there um but yeah they're welcome to to go there they they're welcome to reach out to me um directly and or anyone from our our engineer team and um yeah go from

there and I also want to as a parting way just want to say that you know with this a layer that polygon like kind of extends Beyond uh a layer two Network like you know we I like with a layer once the a layer comes in fully you can't really like layer is not a layer one or Layer Two it's a it's kind of a meta layer which allows layer twos and many of them will be simple uh connected chains who are not even using the layer to validity proofs but they still can exist in this multi- chain environment um 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 uh this infinite uh 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 ag 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 uh having you guys on in six months time and see what you built then yeah thanks forri thanks rri always nice talking to you thank you bye-bye