zkAcademy #3: How To Think About zk Technology with zkSync, presented by Union Build

3 Nov 2023 · 1:00:24

Coogan Brennan joins The Rollup for a zkAcademy session on how to think about zkSync and the technology underlying zkRollups. The conversation breaks down zk proofs, how the transaction and prover system works, and the economics of scaling Ethereum through zero-knowledge rollups.

Speakers

Topics

Transcript

[Music] [Music] [Applause] all right hello everyone how is it going my my name is cougan Brandon you are on the rollup course courses um I'm going to be presenting on uh a topic uh this is my topic today is what is a universal mental model for l2s and we're going to get into all what

that means uh we're going to start with a little intros going to talk about why mental models why mental models are are are um important particularly for uh uh crypto and l2s and uh ZK avms uh we're going to talk we're going to go through this Universal mental model for l2s uh then we're going to do three important questions kind of easy intuitive questions that you can use to analyze l2s and then uh do some questions afterwards just before we get started I know that this uh course is particularly focused on zks so this is going to be one click above zks but I hope uh you know I feel like there there's a really important reason for that and I'll get into it it's also applicable to to to ZK

stuff so uh let's Dive Right In so my name is kouan Brennan I have been in crypto since 2011 which is so long so so it's it's like you know it's dog years right for crypto so that's you know I've been in practically 70 years um uh before uh being at matter Labs ZK sync I uh ran consensus Academy at consensus consensus is a software uh company that uh uh builds and runs metamask as well as inura so as head of a education for uh Rand consensus Academy which is the education arm of of consensus I am now doing head of Education uh at zky sync and the goal is my goal is to uh

essentially do what we did for a blockchain development uh for consensus and with metamask and with that initial um rise of crypto uh we'd like to do that now uh sort of that uh knowledge mapping for Els and ZK VMS and and zkps as well so um yeah you can get connected with me here on LinkedIn uh also on uh Twitter uh quick word on matter Labs we are the uh team that is uh helping to launch uh ZK sync it's a little bit of a a confusing um dichotomy another another good dichotomy would be offchain labs and and arbitrum so we're the team right now that is that is launching ZK sync

ultimately it will be part of this community run effort decentralized government governance that sort of thing but for now we are uh a little over 100 folks who are um located all over the world um and it's an amazing company people from uh all incredible walks of life just the most powerful strong team I've been on in quite some time we are hiring so I'm going to put a link for for for jobs if folks are interested you should check those out all different skills doesn't have to be technical um in matter Labs uh we uh have launched a evm compatible rollup ZK rollup called ZK sync uh the full name is ZK sync era uh we ran a test net for a number of years um called ZK syn light

and that was also a ZK evm rollup quite Limited in its scope um and uh yeah but we were the first ZK evm roll up to launch uh on ethereum it was pretty extraordinary this happened uh back in um April March March or April I believe this year and it's been awesome it's been a very very cool uh ride so far um I assume that a lot of folks are familiar already with uh the scalability challenges of ethereum and why we use l2s but essentially we are moving transaction execution offchain and using uh ethereum for data availability we'll get into what that means later with the

ultimate goal of reducing transaction fees and R and transaction times while uh still maintaining the security of ethereum and and again we'll get into all this in just a second um we do this through this process of cryptography called zero knowledge proofs which can be used for a number of different uh um use cases we use it for uh data compression but it's also used for privacy and networks like Aztec and ultimately ethereum is the settlement layer which acts as the custodian funds are always withdrawn uh from the L1 so uh this is where we get into our terminology of l2s l2s always have a um an anchor in an L1 typically ethereum if we're talking about it today so that's a

quick intro into myself and matter labs and ZK sync um and uh I'm just GNA speak really quickly on mental models as I mentioned I've been in the crypto uh world for quite a while and I've been teaching um uh blockchain development and crypto development for um at least five years in a professional way I've taught all over the world and one of the things that is so so important for emerging Technologies and this uh applies to blockchain but also applies to AI um any other sort of emerging field it is so critical to have a mental model which we're defining as a

lattice work on which you can hang knowledge and the reason why it's so important is because um if we have a framework for understanding the world um that is uh flexible and resilient then it not only means that we're able to understand the system uh that we're looking at in this case blockchain or l2s but we're also able to receive new information about that system and it doesn't break our our understanding right we have a flexible uh and uh antifragile uh model of the world and as we have been um uh as I've been teaching uh uh for uh

blockchain I've found this is incredibly incredibly helpful and um it it's it's useful on a on a broad scale as well um there was a a study that was done a couple years ago at Stanford around multitasking so are seeing like who you know who's good at multitasking and anyone who's read the book Thinking Fast thinking slow uh knows uh this story but essentially they were studying multitaskers and they looked at the best multitaskers and they wanted to sort of gauge their attention and what they found out is that people who are multitasking are actually quite poor have a quite poor attention span and the reason why is that they're worse at what you call mental filing keeping information in the right conceptual boxes and being able to retrieve it

quickly this is from the study in other words their minds were more disorganized um so what we're going to do today is going to be sort of giving you a a a a mental model an organization system with which to uh understand the L2 in ZK EVMS so when you hear about folding schemes or when you hear about sequencers or when you hear about smart contract security or when you hear about bridges you understand where that information goes I think that's really critical as a base layer knowledge which then allows you to have a very productive and extremely beneficial u career uh and just way of navigating and and comparing these systems uh in

crypto um and so this is an example of one of those mental models that uh we build at consensus for blockchain development more generally you can take a look here and essentially kind of as people were learning the process they would just be able to slot in okay I'm learning about ethereum clients that goes here I'm learning about Dows and defi that goes here I'm learning about JavaScript tooling that goes here so we're going to build the same sort of system here for you all around l2s and and ZK EVMS um and uh I think that's all we want to say about that yeah um oh this is just another sort of example of uh another sort of framework you know a road map is another way to

think about it uh being able to understand the different kind of paths that one can take to specialize or to to to better understand a field um this is a really successful uh or really popular defi developer road map um from uh GitHub repo um which you can you can find pretty easily by Google in there um alrighty so on to the the topic of today which is the universal mental model for for l2s so as the L2 and zkm space continues to grow in popularity and uh technical Innovation it's really critical that we have these mental models for all the reasons that we spoke about as well as um being able to compare and analyze these systems so there's a lot of

different networks and a lot of different projects that are coming out and ultimately I would say you know 97% of the population has to just trust what they read on crypto Twitter or what they read on uh blogs or what they read on repos about uh technology rather than being able to understand it for themselves and uh the promise of crypto is something very different right the promise of crypto is you don't have to trust you can always just verify and so um it's so critical to be able to trust and kick the tires to to not trust to kick the tires and to verify um these different uh L2 projects as they get launched uh and they promise air drops or or you know whatever the whatever the case may be it's really really important that you as someone who's a developer or

someone who's trying to understand the system the uh the the ecosystem better is able to very quickly and efficiently and um comprehensively gauge uh is a network good what are the trains of this network and what are some um trap doors or what are some sort of things that I should look out for uh uh when analyzing networks so uh we're going to dive into this model here that we have now um this uh is both simple and complicated but we're going to go through uh uh these sort of critical uh components um Each of which in our mind represents a group of uh components and elements that Define essential aspects of any layer 2

network uh and this includes zky ERA this includes arbitrum optimism uh z uh starkware uh lanaa um any sort of uh um project that launches you can use this um this mental model this diagram to uh analyze uh these points so the critical points that we're going to be touching on are the things where you can really profound sort of say okay here's the sequencer commitment to main net of uh data um how are we going to uh understand that hold on one second uh

wonderful um so uh yeah so these are sort of like the the the the sort of the the almost like the choke points or the points where you can like really discreetly see okay these are the points of difference of networks L2 networks so let me use that to compare um how these networks are different or the same that sort of thing um the uh the diagram is very simple uh there's this phrase uh from the statistician George box that goes all models are wrong but some models are useful so uh we are abstracting away a lot of complex information in the hopes of providing this broader understanding and tool for analysis um but uh you know

there's you can fall down a number of different wormholes and sort of side quests as you're going through this material um if something sort of strikes you as as compelling or interesting you can go deep into that area um any one of these areas uh there's a lot of simplification that happens so um so yeah so let's let's go let's let's start let's start up with our first one so the first uh uh part of a of of an L2 network is the onboarding of the user um and this one is from the user's perspective it's fairly um straightforward you usually just Bridge your assets but uh it's really important as uh the user you're able to understand the bridge which is the way in which um

those funds are the way in which you migrate funds from L1 to L2 so the um onboarding is an interaction with a smart contract which is a bridge and the bridge is responsible for safely securing or locking up assets on ethereum mainnet and it's crucial because it's the Lynch pin of security for those assets um as we mentioned before the sort of the promise of l2s is that you can uh dispute issues that happen on the L2 on the L1 and that predominantly happens either in or with the bridge contract so the bridge contract is going to be really critical you're going to want to make sure that's very well audited you want to make sure you understand the process and that um uh and and and the the different methods

of dispute which we'll get into a little bit later um when the assets are locked up in this in this in this bridge contract uh the bridge creates a counterpart on the the L2 side within the rollup so um the L2 tokens are the sort of inherent they they carry the same inherent value and utility of the L1 token in this case um eth and The Ether token um but they have the added benefits of the layer two which is typically trans faster transaction times and lower fees other networks add on different um capabilities as well so for example ZK Sync has native account abstraction um and so you're able to kind of supercharge your L1 Assets in

this case uh eth by introducing uh account abstraction on top of it with still maintaining the security features of of ethereum so uh onboarding pretty straightforward transactions again this is a pretty simple one so we won't spend a whole lot of time on it um but essentially you know the transactions look exactly the same to the user right um the only sort of like that's actually sort of this like big part of it is that let's say you're using metamask like it's going to look exactly the same of a transaction life cycle um maybe the confirmation happens a little bit quicker um but the transactions look to the user exactly the same as they do on L1 and maybe a

little faster and hopefully a lot cheaper and that's sort of the goal right you shouldn't be able to tell that you're on an L2 except for being able to check on the on the metamask network uh uh model button and seeing okay I'm on this other network now so it's really really important uh that that's sort of invisible to the user in some ways um but the really critical part of those transactions is that you know it gets submitted to a mempool which is similar to ethereum but rather than being collected by miners it's collected by an actor called a sequencer and this is a really really critical part of the um uh of the process the sequencer is the um is is is

a really important actor within the L2 it collects these transactions it orders these transactions um and we'll get into that in just a second but just know that the sequencer is kind of the the main collector of all the transactions um within an L2 Network and um yeah it's a really critical part of the um of the whole L2 system so we've covered onboarding the user here we've covered transaction submitting transactions and now we're going to go over um what we're calling computation and aggregation so after the transaction that we just saw is signed and submitted by the user the next stage involves the sequencer Computing the updated state of the L2 uh blockchain

Network assuming that these transactions go through so it's very very similar um in terms of the outcome of the evm but the ethereum virtual machine and the way that it happens on layer one but the way in which that computation happens is really really different and this is the first big big important difference on l2s um that we'll get into so the um essentially the there there are two broad forms of uh computation and aggregation process on layer 2 again just to sort of reiterate the point when we say computation and aggregation that means the sequencer is collecting those transactions that we just saw from the

user it is Computing those transactions making sure that they're valid making sure that you know properly signed all the stuff that you would also do on an L1 and then it's making sure that it's showing the reflected uh L2 State you know this is the new state assuming that all these transactions this transaction goes through um okay and so it's you know we signing you know a balance from the um you know the rollup Twitter account uh ethereum address to kugan ethereum address you know changing those balances that sort of thing um that's what's happening sort of in effect now how we get there is is is different there are two broad ways in which l2s Aggregate computate and aggregate transactions um

and they're symbolized here by the op which is the optimistic process of aggregating and processing transactions and then um our logo but representing uh the ZK which stands for zero knowledge um way of uh Computing and aggregating um uh transactions so this is a more detailed uh breakdown of that and so we're just going to address uh the optimistic computation aggregation then we're going to go into the ZK process as well so the optimistic uh sequencers collect transactions and they collect them all into a block and then they assume that the transactions are valid they naive it's called like naively or optimistically process um the state change of those transactions as though

they are valid so so they don't actually have to do they don't actually sort of check to make sure that that that that that there's no fraud happening um or there no issues um they just sort of blindly assume that that's what's happening so you know if there was if that was sort of the end of it then that's a huge trust assumption which could be easily exploited but optimistic rollups use a mechanism known as a a fraud proof it's also called a fault proof now um but the sort of the the common term is a fraud proof which is uh the main protection against this uh against any fraud happening so the fraud proof is essentially a security aspect that is a challenge window uh during

which users are financially incentivized to check the validity of the transactions and we'll get into that in just a second um but it's uh just really important to know that that that is the sort of the main mechanism that's that's guaranteeing the security of these networks is that staking mechanism from uh a sort of a a sort of a watcher a community of Watchers that are that are watching the the the network um you know computation and aggregation on these networks on the optimistic networks are not actually dramatically different from ethereum Main net uh in fact I think a number of uh of optimistic uh networks just use a fork of gath um as their client their ethereum client which is

the main uh uh the main ethereum client that use on mainnet and so um that's just sort of important to note that there's not actually a whole lot of change in terms of the computation aggregation now on so that's on the right hand side uh I believe is the optimistic uh process on the left-and side you see the uh the ZK uh method of computation aggregation this word get very interesting and obviously the basis of of of this course and why we're here so uh the sequencers for the ZK rollup also batch the transactions into a block but rather than relying on the this fraud proof ecosystem the ZK rollups use a form of cryptography known as zero

knowledge proofs to generate a single mathematically irrefutable proof to validate the execution trace of those transactions and what that means is um it's essentially with a single sort of digital signature let's think of it um we are able to with that single digital signature that so how about this I've heard that um a good analysis a good sort of comparison of the ZK um cryptography like actually explaining the cryptography is a digital signature which in ethereum It ultimately sort of shows that um that a certain someone actually has signed a transaction right that's what a

digital signature shows um someone who's holding a private key has has signed the transaction without revealing anything about the private key zero knowledge proofs the proof itself is like a digital signature but for that entire lock of transactions so rather than just that single action of saying this person has signed the um the uh this transaction the ZK proof is is is is is vouching for the entire block of transactions which is huge it's an enormous amount of execution um which captures a lot of information very succinctly um it would be really expensive to do on l1's right now so we pull it off and we do it on our own network on L2 use but it creates

this enormous amount of compression and this is the kind of the real magic of uh of of zks and the reason why it's really uh so critical and the reason why um even optimistic networks at this point even optimism Network says we eventually will have to use ZK proofs for for this reason which I'm about to describe to you which is that ZK proofs provide recursive they provide non how do I say this they provide nonlinear scaling so with optimism optimistic networks you can only scale as many as as many sort of people you have on the network because it's the same thing as just running a single validator you can't scale that in the same way like the amount of effort uh um is is is Rises with the number of people that you add

to the network for ZK proofs because there's this compression that's happening you get this exponential growth of um of scale that you can do on networks so suddenly you can really really compress a lot of transactions into small proofs now right now those proofs are very expensive to um to compute so it's not you know you're doing Rec recursive proofs is is challenging at this point but the technology is there and we are doing that work to be able to discover it and and it's just you know vitalica said this is the way of the future optimistic Ro up say this is the way of the future so if you take one thing from this talk take that that the ZK method uh is the way of the future moving forward just

plain and simple um and uh yeah so that's sort of our our overview of those two um of those two uh systems those do different ways of computating and and aggregating uh data on L2 networks going back to uh uh you know what they have in common both uh regardless of optimistic or ZK uh processing both create this unverified L2 block and this is known this is then you can see this little line here that's going down and it's going to this L2 State contract which is uh also our Bridge the way that we used it to come onto the network um but it also enshrines the L2 State on the L1 um this is called the soft commit and

this is not very well understood I think generally speaking um but you know that proof that we just talked about the ZK proof and the fraud proof um mechanism comes as a secondary separate mechanism it's not included with this soft commit that the sequencer passes uh to the L2 Network those are two different functions that get called um at least with arbitrum and with ZK sync era but I'm almost positive with with other l2s as well regardless of optimistic or or or ZK um and essentially that's why even though it might take a lot of time like a week for fraud proofs or you know a number of hours for um the proof on CK sync if you do a transaction on metamask

it doesn't take a number of hours or it doesn't take a week to confirm it confirms in a matter of seconds because the wallet and the uh the nodes are watching the sequence they doing that soft commit um and we're assuming that that's going to be the case so that soft commit is actually quite important for transaction ordering for user experience all that sort of stuff but it's actually separate from the um the from the staking or the sort of security mechanism now ZK proofs are not doing naive opt naive computation so you know there's that difference there but that's how we're able to sort of confirm quote unquote confirm transactions quickly on on metamask even though um that we might not be able to withdraw the funds from

those transactions uh in a matter of hours for ZK rollups but a matter of uh a week or you know at least seven days seven to 10 days for optimistic rollups so um so we've just gone over uh you know onboarding transactions aggregation and computation and now we're going to talk about this uh um this kind of interesting element of the um the process which is the the the commitment phase so we talked about just now you know kind of why there's this this final confirmation and uh you know this sort of this L2 block that goes to the network that updates it but um there's a real critical part of this process so

every Layer Two has to update the L2 State Route that's on the L1 smart contract that we saw in this earlier slide right here this little uh bar down here it says L2 State contract but the way in which it does it like because we're going to be discussing this dispute mechanism in a while in a second because of the way it does that there needs to be extra data that is also um that is also provided along with updating that State Route because not only do you have to sort of update the state route for the smart contract but you also need to um provide uh information about lead like what led you to update the state to look exactly like that um and you need to do it in a

way that's compressed because otherwise you're just doing the same thing you're just sort of burdening the the ethereum main net layer with the same computation that we're trying to pull off of it so this is again after that sort of the computation and aggregation where we separated between optimistic and ZK this is another really critical bottleneck a really critical decision uh sort of design trade-off space of how a network decides to do this so not only sort of you know uh not only sort of how they're comp Computing and aggregating it but then like how they are providing that information to the L2 to update their state route that helps us better understand that the

network and and and and a way to do that so one way in which that's done um and uh here we go let me show you here again we have this sort of Distinction a little bit too because uh certain networks optimistic networks need a certain amount of data and ZK need a certain amount of data but again it's just uh even within the ZK space there's a there's a difference in that so um the optimistic manets you want to make sure you can properly challenge uh the uh the L2 transactions um because of the optimistic assumption the commit then challenge mechanism so all the transaction data has to be readily available on layer one because if there's a dispute on the layer 2 Network

and we want to pull that fraud proof you have have to be able to reference L2 transaction data on L1 so in optimistic rollups you have to publish the entire set of committed transaction data even if it's in a compressed form um and it has to be published on chain meaning as part of a transaction to your L1 and then during your challenge period this week-long uh area during uh when you're doing your fraud proofs uh or allowing for people to see if there's fraud on the optimistic Network um you must be able to sort of uh you know call up that data to reference fraud that happens similarly or you know alongside that uh

the person that is that is going to attest to the um attest to the to the validity of the state transition on optimistic rollup has to also create a bond sort of a stake on the L2 block that they submit they say we're going to say this is the state transition that happens if someone is able to to challenge that during the L to uh during the challenge period I'm going to Forfeit this Bond so again that's part of that sort of Game Theory mechanism that that we spoke about earlier that's securing the optimistic rollups um and just to explain this before we jump into the ZK this is a just an example of a layer to collecting transactions at the very top batching it up into a single transaction and then committing that to

layer one and then if you can see here there's a Merkel tree here and apparently we get into Merkel trees a lot in in great depth later on in this series um but this is essentially sort of illustrating that there's a Merkel tree that gets updated on on on L1 um that represents the state on L2 um and that's part of that dispute mechanism so the um other flip side though is uh how zks uh make that commitment to um to to the state changes on L1 so Layer Two transactions that are are validated by ZK proofs um are mathematically guaranteed

to be correct therefore we don't have to worry so much about transaction disputes there are certain sort of edge cases where you still need to figure that out um but really no corrupt transactions can be uh proven mathematically proven um on the L1 chain so literally like if there's frond on the L2 chain it just won't compute on that State Route that's on the L1 chain so if there's that issue you know so if we don't to worry about that so what do we actually worry about then well the ZK rollup then we need to be concerned about uh what they call uh censorship uh transaction censorship and um censorship resistance is the other term and it's a little bit confusing because we talk a lot about sort of

censorship in the case of social media but this is a little bit different essentially as we talked about uh in the diagram let me see here so you can see we got the sequencer here that's processing all these transactions and putting them onto uh you know in that block which then goes on on to uh the L1 uh let's say that sequencer goes down or let's say that sequencer is corrupt or you know corrupted meaning that it it can't process any more transactions the ZK rollup to preserve that sort of quote unquote L1 security needs to allow the users to um uh bring their sort of disputes directly to the L1 uh without going around the sequencer

so um that's a big part of the the the concern when we're sort of publishing data so um the way that ZK sync does it is that our rollup L2 blocks we don't have to include all the full transaction data along with the ZK proof because we're not doing that sort of uh transaction dispute but what we are doing is we want to sort of commit a like a sort of a a uh we commit what it's called like the state diffs essentially sort of the the account differences before and after this L2 L2 block uh is being Comm committed and that way theoretically you can go back and as a user I can show listen my account changed uh like this like this like this like this like this um right

up to this moment where the sequencer died and so I want to pull out that remaining balance and we can all agree on that on the L1 that that's my balance I don't have to dispute the transactions I can just immediately pull that out and so this is a really really critical part about that is um understanding how a ZK rollup such as scroll such as ZK sync uh such as starkware allows for that um uh censorship resistance to be built into its its protocol it's really really important to to understand that again because we don't have to worry so much about transaction fraud because the the transactions are mathematically guaranteed what we have to worry about is a censorship uh resistant part of it um so uh this is just a quick diagram

just sort of talking about the proof and sort of going over like what is that actually um uh you know what we just sort of talked about the L2 block um you know what goes into that proof what is a part of that process the other thing that we want to highlight that I've talked about that I talked about earlier was we're essentially dividing up the sequencer and the prover actions in the L2 rollup so it helps sort of logistically and sort of as a mental model to separate those two um because there's they they're different as we can see here they different roles one is about State transition then one is about sort of guarantee of that state rout commitment and then being able to contest or um be able to save or you know uh recover

those funds in the case of some sort of sequence or corruption alrighty so um that is uh we talked about computation aggregation the uh submission and and the commitment aspects and uh call data the the data essentially that's requireed ired to to go to main net now we're going to talk about something called Data availability this is another sort of weird sort of buzzword that that that that isn't necessarily the most intuitive uh process so we're going to get into that a little bit and uh this diagram here is is talking about uh just is just going to be a representation of that data availability so again we have the smart contract that's on layer one so here

it's ethereum and it maintains the L2 state route that smart contract and that's that smart contract is getting these uh periodic updates from our L2 uh it's getting the sequencer information then it's getting the approver or the uh the sort of the fraud the um the validator from an optimistic gr up getting that assertion uh from the validator um but all the L2 uh block data like all the stuff that's getting copi and I'm gonna I'm actually going to put a link here let me see if it'll let me put a link in here um all the L2 block data that's being consumed by the contract is by default posted in something known as the the call data field of an L1 ethereum main net transaction so I'm going to put uh one

of our uh sequencer updates let me see actually I might have to put it in later um no here we go I got it so if you go on ether scan and you look at this transaction this is from R from actually the ZK sync your node going to the the the L2 State rout um on layer one and this is the actual if if you go to on ether scen you go to more details then input data and then decode input data um you you see this field here and so you can see all this really interesting this almost looks like a block header right on an L1 network but this is actually an L1 transaction right but it represents all these compressed transactions that are

happening on the ZK sync Network um and uh there's all these different um Fields uh block number block hash uh number of L1 transactions these are that sort of censorship resistant or bridging uh transactions that are happening we have our commitment here and then we have the new block data so all this stuff gets consumed by the the the L2 contract that's the the state rot contract on L1 and is able to to process it but this input data is super super important because um it captures all the like this is the reason why layer twos can claim layer one as the base security layer um

because we are by by including all this information in an ethereum transaction we're also committing that to uh uh to the ethereum state and so if we do need to uh have some sort of um dispute um and again this is similar for optimistic rups as well uh if there's some sort of dispute we're going to be pulling this data that you're looking at right here this call data to do that kind of processing and where's that going to be stored that's going to be stored in uh ethereum clients um and uh you know ethereum client data storages is it it could be its own you know book uh that we could write about but essentially it is um a really um uh it's just sort of a canonical way like we can

assume that this is this is this is data that's going to be around for forever um and it's really critical and so when people talk about data availability the real question is kind of like where does this data this call data where is this captured in a way that can be uh pulled up and if it's on an L1 then we call the L2 and L2 um there are other options uh for that um which I'll get into in just a second but um I want to just sort of underline one more thing which is that L2 is using ethereum for data availability is so important that the next big ethereum core the next big ethereum hard Fork the network upgrade um is going to develop

an entirely new transaction type to accommodate the data updates like this from l2s because quite frankly this is very expensive to do on L1 and so it's it's still L2 transactions are very expensive because you're um Distributing the cost of committing this data to the l1s to anybody who's uh has their transaction in that L2 batch um but you know the same sort of upgrade system that brought us uh the merge uh you know that layer that level of protocol change is happening for data availability it's called EIP 4844 and it increases the amount of space available from about 500 to 100 kilog kilobytes per block to uh uh one megabyte per block um it also creates a

separate market for the uh data and a sort of a new data type for transactions and this will allow l2s to dramatically lower cost because the data availability the the commitment uh costs for uh uh pushing this data onto L1 will become much uh more affordable um yeah um and just to sort of spin your head just a little bit more uh if you turn data availability in sort of a different direction like if you if you if you pull uh like if you commit that data that onchain data that that transaction data to something that's not an L1 um then we get into this

discussion around L3 systems layer three systems um so this is again kind of out of the scope for this talk but uh to follow down this rabbit hole if You' like to um you can uh you commit that data to maybe another network uh maybe an offchain server something like that we're not going to dive into it that much but here's a sort of a slide deck and there are multiple sort of you know rabbit holes you could fall down just by Googling anything on this on this uh on this slide right now uh so again when you hear the terms l3s or you hear the term data availability just remember that it's um All About sort of where is the data stored that allows you to um recreate State for the L2 contract okay so we're coming up on time

um and that is sort of like we are sort of we have covered the kind of overall components of a system that everyday users will interact with um in their um in in in the like typical user flow um there's also the as you can see here the sort of aspect of force transactions that are here uh which we weren't able to get to um but are really important and then um Network upgrades and maintenance is another aspect of it but I think we're going to stop there and um uh yeah I think we're gonna stop there just because it's a lot of material and uh I just want to make sure that and folks don't get uh get get overwhelmed with with with information so yeah all right that's all that's all

for for me amazing thank you kugan yeah that was that was a great overview I think uh we both stayed high level and dove into some of these rabbit holes that are seemingly endless uh but did a great job of uh unpacking them and explaining the relationship between these components um so with that being said I'd like to start at the high level because sure we talk about mental models like relatively frequently on this yeah Channel but this is the first time where we kind of heard like an analysis of mental models without without applying that to something so I I think I can control

these slides here I'm gonna go back to slide that you had on the organizational pattern of sure mental models because that was that was fascinating so yeah I I find myself thinking in blockchain sometimes and what I mean by that is like I'm like sometimes I think to myself like okay you know this thought is a transaction that is like going through the blockchain of my mind and like where do I settle that transactions well sometimes I post that call data to my memory and I'm like still kind of like abstractly thinking about these ideas and how to use

blockchain as like an organizational pattern for organizing my thoughts so I'm curious if you've like tinkered with this a little bit have you like had some of like some similar like realizations of how to structure our our mental processes for the most efficiency and security of our of our ideas yeah yeah that's a um yeah it's a good talk it's like thinking about thinking which is my favorite kind of thinking um uh and um yeah so I I love that you think about your life in terms of blockchain data structures because I don't think they're the necessarily the most efficient data structures you know like they're they're exciting for like trustless interactions

and settlement stuff but um uh so I love that I've never heard that before and and I think that's excellent but yeah I do think that um yeah two things one is that I'm gonna include this is like a little bit off off topic but but I think it's really important just because you bring it up the there's this great blog called farum Street uh you all might be familiar with it if you're familiar with with mental models um but it's essentially sort of talking about you know I'm using the term mental models quite generally to to to sort of be like essentially this kind of structure um you know almost like its own data structure um that you can slot things into um but there's another understanding of mental models which is you know uh different people have different mental models of understanding

things so the the mental model of like relativity or the mental model of second order thinking um uh it's this really really helpful way of uh uh being able to process information um and it's really really critical as particularly for folks who I think will be watching this because typically folks and myself included in crypto or blockchain are self-taught and there's just a a fire hose of of information coming at you all the time you know uh as soon as you feel like you've got everything uh uh you know you got everything up to speed you have to go to sleep and then you wake up in crypto Twitter something else has happened uh in another part of the world so it's it's it's so so important like

you could just try to consume everything as humanly possible which you know you can do for a while I think for you know if if you don't have to sleep but eventually you do and eventually other things will come in and so I just think it's incredibly important to have these models because it allows you to um just think better and be able to have that sort of anti fragile quality to to to your information processing and your digesting which is the fun part about crypto but also the exhausting part but mainly the fun part which is that you're always learning something you're waking up and um you know one of the reasons why I I I'm excited to be at matter Labs is that I didn't really understand zero knowledge proofs I didn't understand

hardcore cryptography despite having been in crypto for a long time and so I I get to learn something new about that and I get to come sort of share it and find good ways to sort of explain it to folks so um yeah I don't sure if this answered your question but but I do just think that for crypto and particular having these these models and these ways of of of like you said relating it to everyday life if that's a helpful way um but being able to just sort of have some sort of um framework in place will will save you a lot of grief a lot of mental effort um and uh yeah I I could talk about this for for a really long time but but I won't but yeah I I'm glad I'm glad you guys talk about it a lot and

it's it's really really important and um yeah I'll um yeah that's all more of a more of a of a abstract kind of meta personal growth and kind of overall ability to live a successful happy life right right important it's like what what what we're all trying to do here of course yeah absolutely yeah absolutely more so on the uh on the tech side I was going to pull one up oh here uh actually specifically on this one that unfortunately you were uh you you didn't finish whether was this one or the other one the the the primary Tech question that I had which is way different than where Rob was at yeah pleas Sports

transactions how does that happen and what does that really actually mean when when when a sequencer forces transactions to uh the L2 State and then back to L1 is there a difference between like forcing those and then just like doing like a normal batch to L1 or yeah yeah yeah so it's a really good question so um uh you know the question is around this particular sort of this this quadrant of of force transactions that we weren't able to to dive into uh uh um that we weren't able to dive into and uh and if I'm understanding your question correctly it's you know where you know how is a force transaction different from a sort of a sequencer uh traditional like the L2 blocks uh that we talked about um and

I'll answer you question by actually going to I love that we're like running around the slide deck uh this is great I didn't think we would use it this much but um okay so this is the block that's submitted right by the by the sequencer uh by the ZK sync sequencer and if you look at um uh there's a there's a field here that I mentioned called L1 transactions I can't find it where is it uh here you go number of layer one transactions do you see that it's like fourth from the top top do you see that there yeah can you see that there okay so this is uh typically this is bridged funds right so an L1 transaction is typically someone bridging funds on L1 I'm putting funds

onto onto onto ZK sync L2 um or any other any other L2 but there's another kind of L1 transaction that can happen which are these forced transactions now they wouldn't show up as anything different they would still look like a layer one transaction here on this thing right it would be like rather than nine it would be 10 if we included our Force transaction here but there's this kind of special way in which um so so there's a special way in which those transactions are processed it's almost like a sort of like a like a side Channel or like an emergency uh exit before before actually putting all this slides together I thought it was something that you direct the user directly submitted to the state to the L1 State contract but it's actually something that goes to the

sequencer which is why it's really important to have decentralized sequencers um because because you know it seems problematic like how could you force a transaction if the sequencer which for all L2 networks right now the sequencers are centralized or all you know all eth L2 networks it's centralized so how are we can do this Force transaction which I think is sort of part of your your question and the answer is is that we want to we have a decentralized sequencer now you know like a sense of like you could download the repo and run it we're going to sort of unveil that at devc connect uh in in November um but essentially the the smart contract expects data in a certain format and so it's going to grab those compress

transactions which are the sort of the quote unquote traditional L2 blocks but it's also going to pull in these sort of L1 transactions which kind of creates a new if it's Bridge uh funds it creates a new account essentially and sort of adds that to the Merkel tree the the state route that's there um or if it's a forest transaction then it kind of follows that other path of saying okay we just got to do a quick release of these funds to that user that's on L1 but kind of confusingly all of it goes through the sequencer um and uh the reason why that sort of censorship resistance is that you know the sequencer also has to be open- sourced so that you know Andy if you wanted to include this but the sequencer was down or zyn said you know what we're actually

not running valid blocks anymore we're forking the network we're doing something else kind like ethereum classic or whatever and you're like no no no I I I want to sort of pull it out on the network at the last valid block you would then spin up a sequencer you would generate a valid block and you could quote unquote submit that to the L1 contract um in the same transaction like this ether scan one that I put in the in the in the chat there does that make sense yeah no I think it for sure does this it's the key differential is the uh is the different types of like effectively inputs or the transactions right as you said there's those know like L1 ones and then there's like the original L2 ones Bridge funds um you know this is probably a different

segment but you know there's there's different types of tokens on different uh you know Bridges and different chains um and I guess the my followup would be that um is the is is this something that users have to pay more for or is there often an a reason for the Expediting of of this oh uh for a force transaction yeah like is it something that that I can control and like pay more to accomplish just kind of happens yeah you can you know you're um that's a good question it does cost more because it's a not compress you know part of what makes L2 transactions cheaper or that they're cluster you know they're they're

compressed so it's going to be more expensive um it also be processed at um on the L1 level uh if we can if we can sort of imag if that makes sense and then um uh I know on arbitrum it's called like the inbox and then on Linea they have like a a mailbox almost like it's also used sometimes as like a messaging service as well so again it's it's more um in terms of the mental model maybe like that sort of inbox might be a better one it's sort of like like like like an inbox in that contract uh where the transactions are more expensive but maybe there's a reason why you want to be sending uh transactions like that on your network um just from L1 to to to

and and and bypass ing the traditional compression maybe there's some sort of aspect there so again this is one of these sort of simplified models where this Force transaction path uh and and it and and it like like I think you're pointing out doesn't always have to be kind of aggressive or uh you know this kind of um it doesn't always have to be like the sequencer is down or the sequencer is corrupt it also can be some other sort of reason but the main sort of takeaway is that this exists this sort of this this sort of like separate slot of transactions exist different networks use them in different ways and how a network implements that is the sort of the design tradeoff and that sort of trade space uh that you would understand it in different ways so it's like uh that thing is there and then it

like a um like a like a like a um sort of there's a whole spectrum of what's possible within that design does that make sense yeah that's uh that's that that covers the entire scope of what why I was curious had not heard of that all before yeah yeah yeah it's an interesting kind of weird little uh yeah yeah but but but different networks do different things with it which is which is kind of cool I think Rob's gonna probably wrap us up here unless he's got another question I want to be respectful of your time KGAN thank you so much for coming on Rob do you uh do you have another one or yeah I think maybe just one more um

yeah on another so a lower level question here sure on on a on a similar note to to the flow of what ends up on L1 um I noticed in this diagram that the proof is not published to the layer one is that unique to ZK sync or no so sorry there should be a line there yeah so sorry that that's just like a the diagram is missing a line which is absolutely chaotic that I would do that and bring it there's a version there's a version maybe like we could if you could mark up the yeah that is uh that that should be uh that should be a line there okay no worries just making making that

clarification I appreciate that proofs are published to the L1 maybe are published to yeah yeah yeah absolutely so uh um uh imagine user imagine viewer that there is a line there between the proof and the uh the L2 State contract but essentially like we said um the sequencer is submitting these these blocks of transactions to the network but but the way in which and okay and those that block of L2 transactions and those L1 transactions that we mentioned uh there's a state transition that happens right so there's a state before that block and there's a state after that block and there's a certain kind of assertion that needs to be made about uh that state transition um from the ZK

side we make a mathematical assertion we submit a proof that says here's a proof that shows that mathematically this state trend ition occurs similar to digital signature like we said for optimistics the and they don't call it a proof um but again if we're you know we're trying to sort of simplify things but for optimistic rollups they use what are called assertions so uh there's an assertion of state so the validator again it's a separate it's a separate sort of function the validator says I'm asserting that this is a stake and I'm that this is the new state and I'm going to put it I'm going to stake you know eth I'm going to stake money on it that this is assertion is true and if someone else is able to come in and say hold on I don't think actually that that that

that that that's the correct State then um then that that what trigger the whole fault proof uh fraud proof mechanism and that starts the whole challenge uh process so that's the so that's the the the they don't call it a proof and optimistic uh networks but um but you know it's an assertion but that's essentially the kind of the validation so if you can think about the state transition and then the validation of that transition as two separate entities the transition is that sequencer block getting submitted and then the validation is that proof um or assertion from uh depending on whether it's a an optimistic or a ZK um Network got it that that makes sense yep and again

apologies for that just like absolute Madness just you know some men just want to watch the world burn that's like why would I why would I do that um uh okay just really quick before I go I do want to cover these because I think there's a lot of data that we just sort of covered on that diagram but I think that there are like three easy questions or like kind of simple questions that can distill a lot of these different sort of points that that that we've been going over this past time the first one is um around the computation aggregation and commitment of the network state is it optimistic or is it ZK that's the first easy question um and again it's going to touch on those design points and there's this implications that we've gone over

on the network itself the second one how do users rescue funds and this is actually sort of what data is included in the L1 State rout updates and whether it's dispute mechanisms or as as Andy pointed out what are the ways in which L1 transactions can kind of find their way to the L2 State contract so by understanding how a user can rescue their funds um or perhaps just sort of directly speak to the L2 State contract that will illustrate to you that design decisions and the trade-offs that the network made around um the data uh availability and its dispute mechanisms the last uh section is where is the data stored um and you can sort of add add add add a sort of a and what

kind you know what kind of data is stored so optimistic uh uh optimistic networks have to include all the transaction data it could be compressed in some form optim or ZK rollups have to uh can can can provide a much more compressed version of that data um so we want to know what is that data and then where is it stored what's the data availability layer um and that will go back to the dispute mechanism that'll also go back to computation and aggregation again it's a very simple question which sort of captures and touches on a number of different elements within that diagram that sort of L2 mental model the universal L2 mental model so easy questions that I always really appreciate having that so

if someone's giving me a talk or you know they're they're pitching there Network I can have in my mind these questions which rep you know which can tie back to this mental model which allow me to very quickly kind of get my orientation within that Network itself and that's extremely valuable for for the reasons that we talked about earlier so uh yeah with that Robbie Andy I'm offici I'm done I promise I'm done I'm done for sure um if folks want to follow me on you can follow me on LinkedIn or or on Twitter um there or send me an email if you have any other questions