Ethereum Sequencing and Preconfirmations Call #4

Transcript

welcome everyone to the uh sequencing and pre- confirmations call uh number four uh today we have a special guest uh Brandon uh from polygon who will be talking about uh topics which are extremely complimentary in my opinion uh to to shed sequencing and base uh base sequencing namely uh the topic of uh cross rollup bundle safety so if you have a a super transaction which involves multiple simple transactions on different uh sequencing environments uh how do you make sure that they can all execute as a bundle how do you make sure that you have safety without having to trust uh the the the sequencers or the sequencer

in the case of uh of one single shared sequenc ER and I think Brendan will also talk about uh gas optimizations which are very much relevant as well in the context of synchronous composability uh namely the idea of sharing deposits so having one uh deposit contract for more than one rollup this is also something that ZK Sync has been thinking a lot about and this other kind of maybe more obvious optimization which is the idea of Shar proofs so if you have multiple roll apps that share the same proof system well you can aggregate proofs and you can also save gas uh there now um before we have Brandon on I want to give a quick update on the um on the the

based ecosystem so as I see it we now have uh multiple rollups that have either like committed to become a base rollup or are excited about it um so uh we all know Tao of course uh one which is very new and I've added to the slides just now is coinbase is building a this this minimal key Value Store uh as a base rollup this is one of the ideas from vitalic and maybe we could have a presentation dedicated to that in the future uh we also had a sequencing day in London uh which was very well attended and I think we've made lots of progress in particular we made a little mini breakthrough so Ben Fish came up with this really clever idea um to basically

encrypt blobs to make sure that when a blob goes on chain it cannot be associated with any given rollup uh and actually that kind of really helps uh chains like Aztec uh that are sensitive to to censorship and so Aztec is now considering becoming a base rollup and actually next week we're going to have Aztec talk about uh base rollups and sensorship resistance we also have rise as I mentioned last time which is a small uh rollup planning to become a a base rollup then we have this this mystery like uh one of the top rollups in production today that is also looking into it and then finally while I was in London um I had chats with uh one of the ens developers and uh he was saying that

they want to move to an L2 but they can't pick an ecosystem like arbitrum or optimism and the reason is that you know they can't be in all the the ecosystems at the same time they have to pick one for the root of trust and if they pick one then they'll piss off everyone else and so they have this this very high demand for credible neutrality uh which is why uh base sequencing is is very uh attractive to them now in addition to these uh rollups uh we have various builders that are building infrastructure and like I think some of these Builders behind the scenes have been having calls with with uh some of you uh like you're you're really stepping up your game in terms of building infrastructure around uh you

know shared sequencing base sequencing pre-confirmation all of that good stuff um and then like one of the other ecosystem players that I added is is is today for the slides is is actually AG layer because again this is infrastructure which in my opinion is very complimentary uh to to to this whole shed shed sequencing and base sequencing uh Vision so without further Ado I will uh give the floor to Brendan uh we have a whole 55 minutes uh so feel free to is that okay if Brandon if we interrupt to with questions uh yeah yeah please actually interrupt with questions so both both so the the presentation should be like I don't know 20 to 40

minutes um it's a big air air bar but uh yeah interrupt me while it's going and then I I've built in time to discuss after as well perfect and I think Brendon will uh try and make the presentation like more technical uh so we can like dive in pretty deep and then after the hour we have the usual half an hour kind of off the Record uh conversation so uh with that um Brandon go ahead all right uh sh my screen

uh sorry guys I I just have to rejoin so my zoom permissions could be updated but you're right back sorry okay perfect I guess while we're waiting um there's going to be more sequencing days organized so uh at ECC uh someone is organizing a sequencing day I believe and I think there will also be a sequencing day at Zub Berlin um so sequencing becoming a Hot Topic I'm actually not organizing either of these topics I think Chris uh do you want to give the one minute pitch sure um so some of you might know suu um which was organized by some people around metallic and where we brought

together different ecosystems for kind of a co- living experience in Montenegro and then we had other spiners of that Su con Istanbul and so after Berlin blockchain week in Berlin we'll have a two-e residency where we bring together blockchain researchers but also AI people Neuroscience people and kind of people just at The Cutting Edge of Technology um and so it will be in June from June 8th till 22nd um roughly 100 people living here in Berlin the possibility is to stay there for a week or for two and we'll have dedicated days for specific research topics around mechanism design sequencing um and yeah they were aligning with Justin Drake with Barnaby a few other researchers to um

organize one day which will be on these topics as well and yeah super lin. city is the website feel free to pre sign up there um and yeah would love to see many of you there thank you Chris and we'll also have a sequencing day with a different organizer at ECC uh Brandon the floor is yours okay uh can everyone see that yes cool so yeah so I I'd just like to go uh a bit into the aggregation layer um so there will be two parts the first part is high level and not very technical and then the second part is maybe a little bit technical um all right

so the background I guess some brief history of the AG layer um it arose from this problem that we had uh in polygon that was very much a strategic one we were working on like a multi-train ecosystem and uh we were wondering like how do we actually share Network effects across many chains so we had like the POS chain and it had uh like you know flourishing defi ecosystem and it had liquidity um and we wanted to launch a zkm rollup and there was no real obvious way to actually share liquidity um and for the zkm rollup to benefit from what already existed on the POS train uh we needed to um think about like

bootstrapping liquidity and and doing liquidity mining incentives air drops and and uh kind of the same games that every L2 uh does when they start uh in order to like actually bootstrap an ecosystem on ckvm and we realized that this was actually like a broader problem and like a more structural problem for ethereum where uh like it's actually very difficult for ethereum to acrw network effects from l2s I think that the like Network effects tend to developer on specific l2s so um um Justin brought up this nice uh term that vitalic used for this um like the idea of mini Empires um that sort of like

develop around individual ecosystems rather than around um ethereum itself um and so I think that this is not like this is something that's very familiar to the people on this call um but I think fragmentation is a problem in in three senses so uh for users it means increased complexity um because you have to navigate uh like moving between chains and and like accessing applications that are on uh maybe different chains from from where your funds are um there's also a lack of safety involved here uh so like often this requires uh thirdparty bridging which doesn't offer the trust minimized

uh guarantees that native bridging does um for rollups um for Builders there's this issue where uh like if you are um like let's say that you're building something that's that's really interesting and and great it could be like a new def5 primitive or um like an nft collection or a game and you're really really good at building whatever it is that that you know you're passionate about and and you're setting out to build um but the problem is is in order for you to be successful and and launch your app chain or your L2 like you know you not only need to succeed in building this thing that you have a comparative advantage building but you also need to succeed in like bootstrapping your train so you need to

uh like for your nft collection build a Marketplace and and like bootstrap liquidity for that Marketplace and um uh like actually develop a chain ecosystem uh not just sort of your uh individual application or or this thing that you uh can actually have a comparative advantage in building um and finally for ethereum this isn't great because uh Network effects aren't shared so like the success of of an L2 ecosystem is like additive in some sense for ethereum but it's not like maximally additive um like sort of we we we we don't have this uh this like collaborative environment where um like token incentives for one L2 benefit like all l2s and benefit the

entire ethereum ecosystem um and so I think it's like not an ideal uh like structural configuration for etherum so again this is uh I think very familiar for everyone on this call but the goal is to unify ethereum l2s um so by that I mean two things so we need to enable low latency composability both asynchronous and synchronous um I think Justin is much better at at terminology than I am and and he he uh called this like super intense so basically intense that span multiple chains um in a single bundle uh and moreover you need uh to provide asset fungibility across chains so so if you're on 1 L2 um you should be

able to in a very low latency way like take your native eth that's represented on that L2 and bring that to another L2 and get native eth uh without necessarily going through the L1 and and uh paying the latency penalty so uh like in my mind the technical barrier to this unification is uh like the Reliance on going through uh ethereum in order to um use the native bridge between two rollups so if we have like rollup a and rollup B and let's say that they're both CK rollups um like there are a number of latency components

that lead to a bad ux for um for for Native briding between these two trains so uh if you think about what's required for me to take uh like my eth on polygon ZK VM and move it to ZK sync or to Stark net um I need to submit a withdrawal transaction on chain a uh I need to wait for proof generation for the block that contains my withdrawal transaction so this could take like two to three minutes and in like a very fast uh and performant ZK rollup it could take longer for others um I need to wait for like that batch to be submitted on L1 so right now I believe that the like the lowest uh latency for batch submission

is about 30 minutes just to amortize the uh the cost of proof verification on ethereum um I need to wait until the batch that or the block that verifies my proof is finalized on on ethereum and so that takes like between 12 and 19 minutes I then need to submit a deposit transaction to rollup B it takes another 12 to 19 minutes for that block to finalize and so Finally I receive tokens onb and all in this ends up being like a more than 25 minute uh latency penalty for a crossr transaction via the native Bridge um obviously this is like the best case in an optimistic Ro up if you're using the native Bridge it's uh

obviously much worse so the agay is designed to solve this problem in conjunction with a coordination infrastructure like shared sequencing um I think it's important to emphasize what the a is not uh so it's not an L2 um it's not a shared sequencer uh it's not just a proof aggregation service um so I think we we'll talk about this later in the presentation but um I think there's this misconception that uh you know all that we're doing is aggregating validity proofs and uh and that aggregating validity proofs gives uh the safety guarantee that we am to provide and and that's not true so when we talk about aggregation we're actually talking

about aggregating chains so so the a layer as I would describe it is neutral public infrastructure that provides safety for asynchronous and synchronous cross-chain interoperability and a shared Bridge so again aiming to satisfy these two criteria for uh for unification so uh uh cross-chain composability at lower latency than ethereum finality um and asset fundability via shared bridge and as Justin mentioned earlier uh we're also able to massively reduce G costs so the Ager works by accepting blocks from l2s before they're settled on ethereum and it proves like three things

I guess so it proves first that uh cross chain or cross L2 transactions are safe so they're consistent um that super intents and bundles are are satisfied and are consistently included across chains um that interchain accounting is valid and we'll talk about what this means exactly later um and finally it it does aggregate validity proofs but again it's really important to emphasize that this is primarily a gas optimization so rather than uh needing to verify every single validity proof uh for every single L2 on L1 we can amortize the cost of uh proof verification across manyal TOS so the agair vision is an ecosystem

of independent Sovereign chains um the agair does not uh there's no element of rent seeking or extracting sequence or fees or profit uh it does not require a specific VM or an execution environment uh it doesn't require it doesn't place any limitations on the tokens the chains use um it doesn't require that they uh submit to Common governance uh or that they use like a specific or prescribed shared sequencer uh or even a shared sequencer at all though again like the AG doesn't function without some sort of coordination mechanism between trends so like the way that we think about it is that the a layer is like this very very minimal layer that provides the

safety guarantees that we discussed earlier and it works in conjunction with like a chain coordination layer so that could be again a shared sequencer a relay Builders and and so they're they're sort of like separate uh ecosystems that mutually depend on one another um so shared sequencers depend on the a layer for safety and then the a layer depends on uh shared sequencer and this coordination what we call like emergent coordination infrastructure um to actually navigate like producing cross-chain bundles and uh like performing the coordination between chains so uh in the like Universal again this is just to like sort of develop a

very high level intuition about how it works um in the Universal synchronous composability case uh l2s would opt into using a shared sequencer that's the only way that we know know how to to provide synchronous composability across chains um users submit Atomic bundles to a proposal or a pro proposer and a builder would then execute and build blocks across many chains um and so then this is where it gets a little bit different like the chains would uh basically build their proofs in a certain way that allows the AG layer to check that the Builder and shared sequencer uh built

blocks in a valid way and that the shared Bridge was uh uh basically yeah use safely or or or like the the bridge and variant was respected across all these transactions and so the Ager submits these three proofs um oh sorry Yuri got a question yeah could you explain a bit more the user submit Atomic bundles to proposer so far so good proposer user bundles make sense and the Builder executes builds block across many chains like I have like the chain is broken somewhere between the proposer and the Builder here could you unpack it um yeah so so I I I might be using the wrong terminology here um

but my understanding is that the idea is that after a bundle has been submitted uh to a proposer that the like some Builder would then create uh the blocks across many different chains and so so uh this is required for synchronous composability right because you need basically like all of those full notes to be collocated so you don't have to take locks uh that persist for a long time across many chains um and so that's just what I mean that uh like the Builder is actually producing those individual blocks um for each chain uh and then so we're kind of like glazing over proposer Builder whatever I don't really care about that

user give a bundle of like you know um um actions across different chains or whatever and then you know it comes somewhere between the proposer and the Builder somebody creates a block of the proposer could create something along these lines right yeah exactly like like like user uh sends off uh a bundle and and somehow we get uh like all the the individual blocks created by Chain um cool and so the agay then proves uh basically three things it proves that uh these cross L2 transactions are handled in a valid way so that uh like like in the synchronous composability case that uh there's no unbundling that for every transaction

like like if a bundle is included by one chain then for every chain that is included in that bundle the transaction on that chain executes successfully um it then it proves that the like the bridge inv variant is respected basically that no chain can withdraw more funds from uh or yeah just withdraw more funds than are deposit on that chain um and then it provides an aggregated validity proof to L1 um and so again like this is just sort of like a very high level kind of like metaphorical view of of the AG it's like uh like that very thin layer that's providing safety upon which all of this like interesting and and sort of Rich

coordin coordination infrastructure can be built so like shared sequencing base sequencing relays for asynchronous composability like but but the agay is like is not providing chain coordination it's just providing a safety guarantee so that uh users and chains don't need to trust this coordination infrastructure uh to behave in a valid way all right so feel like we've run through the non-technical Section and we can get like a little bit more technical so um so what do we mean when we talk about safety guarantees for cross L2 transactions uh by safety we mean that

if two or more chains are interoperating at lower latency than ethereum finality then uh the chain like oh sorry Yuri go ahead so just on summarizing the high level the idea is that if I am a user and I want a few actions happening across multiple chains some of them are cross chain I create the bundle saying oh here are the action that I want to take and I actually submit this to the different or actually the shared sequencer of the different chains right so it's kind of and this lands on all of them that's the high level okay yeah yeah yeah which I think is consistent with go ahead just sorry one thing that

really helped me is that if I have a super transaction which cross two rollups like rollup a and rollup B I'm actually signing three messages I'm signing transaction on rollup a transaction on rollup B and I'm also signing this super intent which basically describes how I want the relationship between transactions A and B to work and not only that transactions A and B shouldn't be like replayable individually and so they need basically needs to be a transaction type with metadata that points back to the intent and then what AGA does is that it verifies the consistency of these transactions these simple transactions with metadata plus the signed super

intent yeah exactly and I think that that's not not to detour too far but um I was actually speaking with with Ben about this the other day um I think specifying that transaction type and exactly how it works is something that's still like an open item for um for this group um yeah um all right so uh uh so the safety guarantee basically says that um like if if I have a a block from a chain that block can be finalized on a theum uh assuming that there's some cross chain interaction that that affects that block it can be finalized on ethereum if and only if uh the other chains that are or its view of the other chains um that are

involved in that cross chain interaction is consistent with what is actually finalized on ethereum for those those uh CH so I think that we have the so so like like in the async composability case so um so let's say that we have like roll up a and rollup b um and rollup a is sending a message to rollup B um and uh and so obviously we we don't want to wait for uh for this message to be routed through L1 and for uh like the state of Ro Bay to be finalized on on ethereum uh because that would take too long um and so so let's say that we want roll up B to accept this message from a uh before the state of roll up a is

finalized on ethereum it it could even be before a proof for a is uh is generated so so we want super super low latency cross interaction maybe on the order of like a second or under a second um but this can fail in a really bad way like without the agare um so so let's say that like rollup a creates a block and it it like let's say that it's valid it could be invalid but but let's say it's valid um and the message that's derived from this rollup block lowercase a is sent to B and then B creates a block that depends on the message that it received from like block lowercase say um but let's assume that at the same time that roll up a is trying to like

double spend or or equivocate and it sends uh a prime to ethereum and at the same time B chain b or roll B sends uh this Block B that depends on the state lowercase a to ethereum and so B has built a block that depends on a state that was never finalized a state of a that was never finalized to ethereum um and so this is really bad like B is rugged like you can cause really bad things to happen on B the the bridge could become under collateralized or there could be some like other kind of catastrophic issue that that could occur um and so in the asynchronous

composability case the question is like how do we provide safety in this case uh even as we're operating at lower than ethereum latency so the really simple mechanism that we use um to provide safety in the ASN case is uh let's say that chain B receives a message from a that depends on block lowercase a and then bu and B builds uh block lowercase b so in the proof for for uh Block B um we include a commitment uh to the received state of block a as a public input and the idea is basically like B is is valid if and

only if uh block a is also valid if there there basically exists a valid proof for a um and if block a is finalized to ethereum and so we can think about like the role of the AG as basically receiving all of these uh new blocks and checking for consistency um between basically like the claimed States about or the like claims about other chains and like what states are actually produced by those chains themselves um so in the case like stepping back in the case that this happens like a equivocates um and submits lower case a to be and then uh

submits a prime to to ethereum uh B would not be finalized on ethereum so there there's a safety guarantee that like whatever invalid transactions be built uh that depend on a state of a that was never finalized um those will actually never be settled on ethereum so the downside which we'll talk about later is that there there's a liveness issue for B because it built this block maybe it built like a bunch of different blocks um that all depend on this state that was never valid or that never happened uh and B will need to resolve that but fundamentally we are preserving the safety guarantee that um if uh like the claimed state of a is never valid or

or is never finalized on ethereum uh that b will be safe from final like from settling an invalid state ethereum so we can see in this slightly nicer diagram like um we have block B1 that depends on uh this other block A1 and so the aglar is checking that uh for all of these sort of claims that um that A1 is consistent with uh the block A1 that was actually received so the more interesting case um I think for this group is like the you have a question from M oh yeah yeah yeah um so if you go back to the previous slide so in that b Prime uh block that

doesn't get finalized are we saying that there's a bunch of transactions that are basically invalid now yeah so so they they need to be reor so so the the transactions that depend on uh on an invalid or equivocated state of a would need to be reor uh and we'll get we'll get to like why this is like sort of an unavoidable property of of or an unavoidable trade-off in in operating it lower than ethereum latency but um yeah so so B would need to navigate uh like A's misbehavior um if you have two conflicting sets where you know a a and b Prime and then B Prime and a basically

neither will happen even though both were committed to so so if a does not depend on a state that's invalid then then a would be finalized to ethereum um but B would not be but if there's a second kind of transaction request where you know the inverse is basically requested for uh neither will happen is is kind of what we're pointing at here yeah yeah I mean a a would never really do that because a knows that it's equivocating and that and that it's going to delay uh finalization of B of chain B um but but yeah in the example that you're giving that would happen and would would that be determined by like a first come first serve like a wouldn't

do that because his thing is before the other one yeah so so so if you're saying that like a is a equivocating at A1 and then B is producing a block and then like equivocating back um then a knows that the block that depends on this equivocated block will never be finalized um so um all right hey I just want to make sure I fully understand the concept maybe we can walk through an example uh swap just to ground it in like a real example uh yeah yeah or or like a burn mint so so like um a uh uh decides to like you know wants to uh transfer some

funds and so they're uh burned on on chain a um and then uh like a corresponding mint operation is is triggered on chain B and so so let's say that like a there's some transaction that burns a thousand eth on a um and so B says okay I've received this message I can mint a th um and the problem is is that if a now equivocates and finalizes a block to ethereum that doesn't include this burn operation then uh the like bridge for B becomes under collateralized in the case that there's no agay and that this this can happen um does that make sense yeah that was very helpful okay

cool um Noah yeah also one thing I kind of want to point out with this is and I think it's the next diagram is when B if B1 is to B1 is dependent on A1 and then there's a C1 that depends on B1 then you effectively have a tree of them all going up where if A1 equivocates then B1 would equivocate and then C1 would equivocate there as well so I think it's interesting to see but I think that may be able to be mitigated depending on how it's set up but the whole equating on the entire block makes it interesting because I think most of the examples in the past have been on individual bum bundles equivocating not necessarily

entire blocks equivocating yeah lot standards still need be defined defined there yeah yeah I I I agree I I think that's a good thing to point out and I I I would just say like um this sounds like really bad like we could have like reorgs liveness issues like cascading reorgs uh depending on like the dependency graph of uh like interactions between chains um but we'll see that this is basically like like first of all it's not as bad as it seems or like it's not all that bad if you consider like what causes uh these issues and it's like an inescapable tradeoff uh at operating at lower than ethereum latency basically

you you can choose between um having safety guaranteed uh or like trusting coordination mechanism like trusting a shared sequencer um but the problem is is like uh if you just decide to trust the shared sequencer then you have like no safety recourse if something like this happens but um Yuri I I think you had your hand I'll say it this way does it make sense to think of it kind of like a merge between ZK rollups and optimistic rollups because you kind of like take the Z that like take from ZK like take the the proof from that but you kind of build on it in an optimistic way so it's a bit sort of it's not a

roll up but technically it's a bit of a merge between the two let's get the proofs from both of them and kind of like work based on that but we're optimistically working on that is that the right mental model yeah I think um like we we hesitate to use the terminology optimistic because it I I I think it implies that there's like proof uh mechanism so so there will be like some challenge period and that doesn't exist but I I think that you're right in the sense that like uh things are sort of like there's this window of uncertainty before uh yeah maybe maybe not optimistic but kind of like um um unfinalized but basically we're kind of using the ZK proof Etc and working on that even though they're not finalized

yeah so it's optimistic not with proofs and everything but optimistic in terms of we work on it despite not being finalized yeah I I I think unfinalized is really good is like a really good descriptor for it um y thanks um all right any I'll just continue um so the synchronous composability uh uh Cas is is I think a little bit more interesting so um you can have a bundle that maybe uh includes like a delta neutral neutral Arbitrage between uh two pools on different chains and so like the uh the user wants to remain delta neutral and so um like each leg of

the trade uh should execute if and only if uh the other does um and so we create this bundle that has two transactions it could have n transactions um but it has two transactions that uh execute across Two Chains um and the uh the desired property is that um like transaction the transaction that executes on on rollup a uh is included if and only if uh the transaction that is included on rup B executes successfully and so we have this like All or Nothing guarantee that that gives us adity um and so the failure would be uh that the shared sequencer in this case

or the Builder proposer again we're sort of like blackboxing that um misbehaves and includes the transaction from the bundle on a um even though maybe the transaction uh that executes on B fails or the the shared sequence doesn't include that transaction at all um but basically like we have this unbundling so we're no longer guaranteed this property that that both transactions execute successfully um instead we uh we only get like a like part of the bundle that's included on on chains um and so this might not be so good if you're doing like a big uh a big trade or a big

Arbitrage in large size um you could be exploited um by a malicious sh sequencer and so in the past um the proposal has been uh we're going to collateralize shared sequencers and then if they do this we can slash them so there's like an economic penalty for for doing this um but you could imagine a case in which it's actually um like profitable for a shared sequencer to unbundle transactions because uh there's so much size or they can like unbundle so many transactions or so many bundles um that they're actually able to profit even though they're they're being slashed and penalized economically um and so the the idea with

the aglar at a very high level is uh let's provide a proof that uh all of these bundles or super intense were respected so so so we can prove with the AG that for every bundle uh we can look at every transaction that's included in that bundle and every chain that that uh executes these transactions and we can ensure that the bundle is included on all of these chains and so if we assume that the chain validity proofs are sound uh we enforce with the validity proof that if a chain uh commits to a bundle as a public input then uh the transactions that execute on that chain must execute successfully and so if the bundle is included or committed to by Every Chain um then we

have a guarantee that all of the transactions in that bundle executed successfully and so this is what the Ager proves is that these super intents or bundles um are respected and there's no POS way like we have a cryptographic guarantee um that they cannot be unbundled so yeah this is like a slightly nicer diagram but Brendon maybe just just maybe on the walk back to the last slide and it might be just helpful to explain how I mean uh because this is solving case where it's so it's easy to to make make two transactions not be able to be picked apart just using signatures but the failure case that you

described without the a layer is that some other transaction could be included on one rollup before that causes one of the transactions Within These bundles to fail right so signatures allow for the bundle to not be picked apart but it doesn't prevent it doesn't guarantee that one transact that both trans actions will succeed right it could be the case that both transactions are executed but one of them fails and the other one doesn't so can you maybe explain how the AG layer just so it's Crystal Clear how the AG layer would prevent that how the proofs are are attestations over State not just inclusion yeah exactly so so like like Ben said the like shared sequencers give you a guarantee that uh the transactions are included um but not that they

execute successfully um because there's no like Claim about validity or or or um or state and so uh in this case um Every Chain uh that that include like the the AG checks that for each bundle that all chains that are involved in that bundle actually commit to that bundle as a public input and then the validity proof for each chain uh guarantees that if uh a chain is committing to to a bundle as a public input that all transactions that execute on that chain as well as like the well yeah all transactions that execute on that chain um must execute successfully so we actually have this

guarantee uh that the uh like the state of um of a particular or the yeah that we we we we have a guarantee about like the outcome of a transaction not just its inclusion does that is that like a little clear about yeah okay I think maybe going to walk through the the actual details of the how the proof works that could make it even more clear yeah so so like for the like the agare proof or for the like the ZK yeah like what is what exactly is the proof that's happening uh from each chain and what would cause this proof to

be invalid for all the chains if one of the transactions in the bundle failed yeah sure so so so the like the Ager proof is uh is basically just checking that uh it looks at like it iterates over every bundle and then it builds a list of chains that are included in that bundle and it checks that each of those chains validity proof includes that bundle as a public input and so we know that like in some sense the bundle is included across all of those chains and then we have a guarantee from the individual chain validity proof that if the bundle is included as a public input it looks at the chains or sorry the

transactions that are included in that bundle that are executed on that specific chain and it guarantees that those transactions are executed validly so this is like a modification of the standard zkm proof to accept a new type of public input um and it enforces that if there's a value in this public input that uh like this specific property holds which is that uh a transaction like a transaction that's included in the bundle must execute successfully on that chain and so if you think about like uh the result after we've iterated through every bundle and every transaction um we have a guaranteed that uh like the bundle cannot be unbundled um because we have a guarantee that uh

all transactions in the bundle executed successfully um does that make sense yeah and specifically the the transaction only succeeds on one of these rollups if the proof ultimately is valid and that can happen if all the other transactions also succeeded on the other yeah yeah yeah so so so the AG will like reject an unbundled uh yeah transaction uh all right so a couple so I think Justin yeah yeah I mean going back to to Ben's question in my mind the distinction is not between inclusion and and execution guarantees like a a shared sequencer can provide promises on I whatever they want

the real distinction is on cryptoeconomic guarantees versus cryptographic guarantees so if you don't have the egg layer the best you can do is have the shell sequencer be collateralized and if they don't honor their promise the intent of the user then they get slashed whereas here it's a stronger cryptographic guarantee where the bundle can't get unbundled yeah I think it is from a from a user's perspective a difference between um so execution atomicity and inclusion atomicity so the from the shared from the shared sequencers perspective it can certainly guarantee any Atomic outcome that it wants uh over the two State over the over the states

of the chains and then it can make a promise uh on that but but Brendan is handling the case that you don't a user is submitting a bundle a user doesn't trust the shared sequencer uh no matter how collateralized it is so it doesn't want a promise from the shared sequencer it simply wants a guarantee that the bundle will not be unbundled and that and that's something that uh that a additionally enables I think we're saying the same thing okay gotcha um sure uh okay uh George

uh I think George just disappeared from my screen uh so sorry I was muted I I was muted sorry you said that you said that um transaction uh so essentially the proof is guaranteeing not only transaction inclusion but also the transaction outcome which is like portion of the talk that we just had uh what's the way that uh transaction outcome is specified like how do you specify like spec the specific outcome when it can pretty much be dynamic well so so you're you're specifying the outcome that you're specifying is that the transaction executes successfully that's like the only guarantee that we care about for

atomicity um we don't care that executes in a spe like that it uh has a specific result um I think it's really difficult to like gu like I think that there are cases where you can guarantee that like you could create an intent uh that a transaction has a specific result or like Falls within some like slippage range but but in general I think it's difficult to um like construct that arbitrarily if you have a single share sequencer it's it's pretty possible because they yeah they control the preate uh whether this is graphically provable beforehand is I guess another matter yeah so so I'm thinking I thought you

meant from like the users perspective like a user's ability to like specify an output State I think is difficult in general it's you can do it in certain cases but um yeah um and yep uh just a quick clarification so when U uh uh a agrees uh to have uh block small a uh as a part of public input are they providing any economic guarantee if they equivocate and submit a prime or that guarantee is provided by AG so yeah so so I I think this is a good question like whether so uh like whether a uh a change should be

collateralized in some way so that if they equivocate then they could be slashed or um I think there are Arguments for for both like like you there there are ways to like seriously penalize uh chains for equivocation getting even if they um if they're not collateralized so you could like remove them from the agare and and chain could opt not to to accept uh messages or or bundles that involve them um but uh yeah I think that's like sort of out of scope and and still uh the the we're sort of like punting that decision to the chain level so so I think chains get to navigate um like the trade-offs that they're willing to make in terms of

uh using shared sequencers and like using relays like accepting asynchronous messages from chains that um where they may not have a proof or um and so yeah so so I I I think it's a good question it's a little bit out of scope for for this particular discussion but thank you um and muhamad uh yeah I have a question about how what's your mental model or what's the right mental model to about to think about aggregation layer here so is it correct to think about aggregation layer as just one extra proof that checks the consistency of like like different proofs of this like roll up a and roll up B and like what you're describing

here is just the the way that consistency check or consistency proof is structured and that's it like or like it it has additional components to it yeah so so it it has additional components that that we'll get to but um but from the perspective of ensuring safety for cross-chain interaction it's yeah I mean it's it's producing a proof that gives a cryptographic guarantee that uh the chains are behaving in a valid way and that like the total state of of all TRS is consistent yeah I have a follow-up question like uh and it's more about like developer experience like from the perspective of developers uh

so for instance I can I can if if I have synchronous composability I can imagine like one transaction on roll up a making a smart contract call on roll up B uh like with some new upod like say ex call or cross call or something and but uh and that would that like second call can like happen or not happen depending on summ State on R up eight MH would something like this be still possible here or does is it going to have like too much overhead if one leg you know fails or something like that like well so so the the only way that that can fail right is if the chain or the

operator of the chain is actually misbehaving like the like whoever's in charge of attesting to that a particular block or state is canonical is actually lying in a equating um and so yeah so so I I think that what you're describing is sort of the use case for for developers you like we we call it bridge and call in in polygon so it's the ability to uh like Bridge funds and then like call some function on the destination train um and so I think that that's like that's the intent for uh for this design is to be able to do that safely at lower latency then e um Anil did you have a followup

question no question I just raised hand I need to lower it thank you okay okay thanks um all right so I'll continue um so the second component to get uh more directly to muhammed's question is um like we need a shared Bridge uh to enable asset fungibility for L1 and L native assets so um we we need to avoid the requirement that when we're bridging uh assets between um between chains we either get a wrapped synthetic on the destination chain which is not not ideal for for uh because we need to swap out of it and we need liquidity for for the

native token um or we need to go through L1 and so what a a shared Bridge or a shared deposit contract allows us to do is we can take um uh like eth like the L1 native representation of eth um and uh we can Bridge it to a different chain in the secr system and we get eth like the native Bridge representation of eth um and the way that we do that is by having a shed bridge and shed deposit contract um but but there's a problem here because we also want to enable permissionless uh heterogeneous execution environments so anyone should be able to deploy like you know a type

one or type 2 Z kbm or for us like polygon miden or like the salon VM or the move VM like there shouldn't be any restriction or sort of governance process for you to deploy an execution environment for your chain um but the problem here is like when we're just using a single VM we have a reasonable guarantee that uh you know that that Prov is sound so so we might have uh done a bunch of audits and uh we might have formal verification and um and and this like pretty high degree of confidence that there are no sound issues with that prover um but as we add more provs uh to this ecosystem and more

provs that are that are plugging into the shared bridge then the probability that there is some soundness issue across all of those provs uh goes up pretty dramatically and that's uh that's not great right because if we have a shared bridge now if there's aover with a soundness issue anywhere in the ecosystem um then that approver could create a trans transaction that like say mints like a million e and drains the entire Bridge of all funds deposited into the ecosystem um and so this is like obviously a very bad catastrophic outcome um and it's something that we need to avoid so the solution is like the second uh

cryptographic guarantee that the Ager provides is that it tracks uh aggregate token balances uh for each chain so so it says okay on zkm there's uh maybe 10,000 eth or something that's deposited in the chain um and some amount of usdc and and and so all these tokens are are tracked in aggregate for each chain and uh when a chain submits a block or a batch to the AG layer we look at uh what we call like the local exit tree of messages so these are all the asset transfers that are coming out of that chain and we parse all of them and we ensure that the withdrawals uh do not

cause the chain to go negative and then we are able to uh it's next slide but we we basically like recursively build the cumulative deposits that flow into each chain um and and we use that to update uh this uh data structure that had that holds the um the aggregate token balances for breach chain and we call this the uh the interchain or chain level accounting proof or the invariant proof um and this allows us to to give a guarantee that uh like even if um even

if a particular prover is unsound um it can't withdraw uh more funds than are currently locked in that chin and so we're able to mirror basically the the same guarantees that that would exist if if that chain were just uh like directly posting proofs to L1 uh like if you have an unsound prover for any ZK rollup then it can drain uh the funds that are deposited directly to that chain but it can't drain the funds that are deposited to any ZK rollup on ethereum and so we we are mirroring that guarantee um by uh by ensuring that that a chain cannot um uh cannot withdraw

more funds than than it currently has um and so so this is different you can think about this as like a proof that lives alongside the validity proof for a chain and unlike the validity proof which is uh basically arbitrary um it it can be sort of like any execution environment and it might be sound or might be unsound um the interchain accounting proof uh is uh something that we specify and it's a a uniform circuit that's applied to every single train and so the a layer does depend on this to be sound but it's a much much simpler proof and it's uh compatible with like any arbitrary uh execution

environment so what are the sort of failure modes here here um from the perspective of the agair uh like we actually just are effectively assuming that uh that validity proofs aren't necessarily sound um if that makes sense uh but from the perspective of the users of these chains um obviously the sound of ability proofs matters uh a lot because if you're on a chain with an unsound prover uh your funds can be rugged by an attacker or a malicious operator creating an invalid proof that uh mins a bunch of to tokens and then withdrawing all those tokens um there's also a second issue where uh users can still be uh ber rugged or or have their

funds uh stolen if uh an attacker compromises an unsound CH or sorry if uh their holding assets that are that are L2 native assets that are issued by a chain that has unsound approver so the attacker could um could create a transaction like may maybe you have an erc20 with like a fixed Supply and and the attacker could create an invalid transaction that mints a bunch of that erc20 um and uh and uses that to basically um uh like reduce the value of the of the tokens that you hold um and so from the perspective of the AG the AG is still safe with respect to unsound proofers in aggregate um but the

soundness of validity proofs matters uh quite a bit for users yeah go ahead then oh yeah just so you are this whole like discussion here is because you want to be able to support uh participation in Ager from zvm that have different proof systems am I understanding correctly uh so so so not it doesn't even have to be different proof systems but different uh like different provs so so so you could you could imagine like um then then I don't understand what you mean by an unsound proof uh just like a zkm that allows uh that's that's not sound with respect to like the ability for uh an attacker to

generate a proof that verifies for an invalid transaction so if they're sharing the same proof system why would the different circuit for example the c a bug yeah so so so like I see yeah yeah yeah like like you you could have like a bunch of like Hy 3 Z kvms and one of them uh has a bug and um would allow you to the bug the bug would be in like the circuit the circuit is incorrect for representing the uh the the um transaction validity I see yeah exactly exactly yeah maybe that maybe the terminology is not quite right but but like like an an incorrect implementation of um of the approver for an execution

envirment but Brendan one of the top voted questions in the chat is like do you report multiple proof systems and I think the answer is a resting yes the whole point is that anyone can come permissionless register their verifier circuit with an arbitrary proof system like arbitrary um you know SN circuit and if they get rugged well all the deposits get rugged but not the deposits of other chains because of this interchain accounting yeah exactly and sorry I I I know that there are a ton of I'm not sure how to see oh okay I can read the chat uh I don't think it's worth it there's way too much in there for continue your yeah okay okay uh all

right so uh hopefully that makes sense so so basically like the two I think like material and interesting cryptographic guarantees are around cross chain consistency and then this interchain accounting um okay someone uh cman had a question hey hey so I was wondering if you saw the last conf calls two weeks ago we also presented a very similar idea uh basically I think it's essential the same idea the difference was we were focused on doing this on layer one and this would allow interoperability between different ecosystems as I understand this idea is only it only works if you're using the

ACT layer so if you're in the polygon ecosystem shouldn't we do this on a wider ethereum level yeah so so you can definitely I I think it's obvious that you can do it at L1 but like yeah I mean we we we yeah came up with this uh a long time ago but um the the goal is like uh you should be able to interoperate between chains without touching L1 at all like that that's how we can how we can scale and and how we can um uh like reduce uh gas cost and and latency uh significantly because otherwise if we're r things through L1 then we not only pay gas cost penalty

but we're also paying latency penalty yeah but if you settle the proofs on layer one of what you call interchain accounting what I last time called asset verifiers then you similarly wouldn't have to go through layer one uh yeah so but I'm not clear like if you're if you're going to uh to go between ecosystems you're you're just saying like do all of the the accounting on L one I think that would be really expensive um to no okay I'm saying that you are proposing the shared Bridge which holds all the funds and is secured by this asset verifier basically so why have this on what is an a polygon a

layer Layer Two why not have it on a layer one uh because that would be incredibly expensive I think Comm is asking a different function a different question sorry so I think calman what cman presented and what you presented for Shell deposits is actually like basically the same idea where you have one contract where everyone makes deposits and you know one of the things that you gain is this gas optimization because you don't have to go through the L1 I think what cman is asking is is this a polygon EG layer or is this an ethereum EG layer and I think the the answer this is an ethereum egg layer where anyone even beyond the bounds of the polygon ecosystem can optain yeah yeah yeah yeah um yeah exactly so so the

like this is not supposed to be like specific to the polygon ecosystem but you have to use the polygon a layer to opt into your interchain accounting failure interch accounting so I was wondering why not so so so we don't we don't call it like the polygon agare we just call it the egare because like there there are a lot of like so so yes you have to use this thing that we are currently engaged in building um but it's meant it's not meant to be like a polygon specific piece of infr okay but you know other ecosystems might also have a proof aggregation like s or as the the shared Pro so I'm wondering why not put this interoperability solution that solves fragmentation on layer one

instead of on this maybe I'm just being like super dense but I I don't really see how that would uh okay let's discuss this later maybe yeah um okay so uh Jonas yeah uh I just want I want to Echo a chat thanks for the talk by the way I want to I want to Echo a question in the chat uh from Cooper like who's running the AG layer and and kind of are the rups that opt into this uh uh relying on liveness for these these people that are running this or or how does it yeah how does it work basically yeah so so run by a decentralized uh uh network of of um

of uh nodes that are generating proofs and uh providing this guarantee um the liveness and censorship uh uh mechanism is not discussed in this presentation but there are ways that I think you can very straightforwardly force uh inclusion or or know have some mechanism on L1 that uh would allow you to um to avoid using the a itself can I tag one to JIS what are the what are the actors that are running agly or being paid like how are they recorded for their yeah so so there would need to be some mechanism where they would be uh compensated for the cost of generating

proofs but these proofs are like very very very light relative to say like a validity proof for zkm so this is like a very very ninal fee are these actors separate from the1 proposers um I think that they I I I haven't thought about that I I think that they would uh I'm not sure if if they could be the same they they could certainly be like using you know E3 stickers or or something like that but is there any requirement for timeliness or censorship resistance on the people that are doing the aggregation generation and then submission into uh into the various

throwups and I guess the one yes definitely so uh they need to generate these proofs in like in order for batches to be finalized on ethereum and so there is like a time yeah Ellie um yeah sorry maybe I missed this but with this entertain accounting would this require that the nodes and agay like are able to execute across all of the different VMS uh no because the the only information that they need is uh in the uh like the uh list of asset transfers that's included with every patch and so

so it's not like random stuff could like crazy stuff could be happening inside each VM uh but those actions produce a result that's uniform across TRS okay I see that makes sense thank you sure um Ben I I think you still have your hand up but that might be an error oh yeah that's definitely an error sorry okay um and I I realized I've gone like way over time uh but I think we're basically so it's it's maybe worth discussing like the AG failure modes um so I think it's really important to to emphasize that like if uh if chain are using a shared sequencer they uh we can have these like nasty liveness issues um

where uh like the shared sequencer like um uh well yeah maybe maybe it's better in the Asing case like like like if we have like messages and there's like a provocation or there's some issue that present that prevents finalization of one chain um it's really important to emphasize that uh this like if we didn't have the ACT we wouldn't have these liveness issues but we also wouldn't have safety and so the impact would just be that uh like the sh sequencer or some like misbehaving chain could steal funds from another train and so like we are adding a safety guarantee we're not like

introducing the possibility of uh liveness issues or faults um that makes sense um yeah so this basically requires ZK because uh if you're using an Optimus scrollup and and the uh the latency of your uh finality for your native bridge is super long then the dependency graph of and and like possibility for Liv faults and reworks like increases dramatically um but uh yeah I I I think we can pause there and uh if there are any lingering questions or discussion or or we can just transition to the off the Record

discussion as well perfect thank you Brandon we're going to uh end the call here and then start the off the Record uh discussion now thanks again Brandon yeah of course