in Matter Labs and he is our uh 4844 expert um so for that section we borrowed liberally from Zach's slides and um yeah so we're in in deep debt to him and uh we'll we'll we'll draw on him if needed uh just to introduce the matter of

labs so uh for certain uh projects Arbitrum is another one there is a separation between the company that actually launches the network and then the network itself and this is true of Matter Labs so Matter Labs is a company with about 115 people um based primarily

in Europe and Asia um and we launched uh zkSync there zkSync light and zkSync Era uh zkSync Era as a general purpose um zkVM EVM which we'll get to in just a second um but just briefly uh about

the company we have jobs open so check out our our jobs page um but if you wouldn't mind going to the next slide Sid um I'm sure some a lot of you are familiar with L2s uh some of you may have also heard of zkSync um but we

are what's called an EVM compatible uh zk rollup and we'll get into that a lot uh in the next couple uh in the next two weeks over these sessions but essentially what uh a rollup does it compresses transactions uh into a single

transaction that gets committed uh to an L1 and um it does so trustlessly meaning that if there's an issue or dispute or some sort of network corruption on the L2 um L2 design is required to have a a mechanism by which people can exit um

using the L1 uh smart contract and so it's considered to be um it considers to be inher it inherits the security of uh of ethereum L2s typically do we'll get into that a lot more as to why we need that and all that sorts of thing in this

in this lecture today but just to sort of from the top uh matter labs is the the company that Zach and myself worked for and Hope was there earlier um and we launched this network ZK sync um uh last May uh right after Eth Denver uh last

year and has been running for for about a year now um next slide if you don't mind so uh just a brief word about uh the workshop series and then I'll toss it over to Sid so um uh layer 2 networks are a very uh

popular discussion and very popular projects right now as our ZK VMs which are a sub a subsection of of L2s however it's it's it's sort of unclear kind of what those are to a lot of people um and so as part of our mission not only as

sort of developing a network and and you know establishing this project and bringing scalability to ethereum matter Labs also sees as a responsibility almost like a public good to be able to educate the ecosystem including um um you all and and and and people at different conferences and universities

around the world um about just sort of the having a common understanding of what an L2 is from an agnostic standpoint not just from ZK sync standpoint as well as being able to deeply understand uh what zero-knowledge proofs are and how they're applied to

create uh ZK-EVMs and the reason why we want to do this is because the the fundamental premise of blockchain is uh don't trust but verify um and that's very hard to do today with L2 because just the fundamental technical understanding is missing so we are on a

mission to be able to educate folks about uh the uh concepts and foundational stuff that's underpinning L2 systems and ZK-EVMs with the hope that it'll allow folks uh like you to be able to contribute more to uh contribute to discussions contribute to the tech itself um and

just have a better understanding of this what what I think could be an extremely pivotal um technology for for crypto as we'll see in a little bit so we're doing this workshop series today is um L1 fundamentals through the lens of L2 so I

I know a lot of you are familiar with L1 fundamentals but we are going to focus on a few very recent um innovations and uh you know see how they uh could be interpreted from the L2 perspective and then uh the session on Thursday is going

to be uh an overview of L2 systems from a universal standpoint we have this universal mental model that can be applied to any L2 network and we're going to go through that discussion as well the third series is going to be around uh designing circuits uh from a very high

level just understanding what a ZK-EVM system is and what circuits are uh and what proofs are that sort of thing and then the last is going to be sort of advanced and sort of interesting uh grab bag of what else is being what else is

happening in the ZK space such as uh ZK machine learning, decentralized identity, that sort of thing. So with that uh we really hope this is an educational uh and uh meaningful experience for y'all. Um and we're really really excited. We also have designed custom swag just for you.

all we're really excited. I had hoped to grab me a couple sweatshirts um for Zach and myself, so I hope people are able to get that and enjoy that. And um yeah I will uh uh I will hand it over to Sid. Thank you all so so much and uh thanks

for being here. All right, thank you Kugan. Um so yeah, now I'll do a brief intro on myself. So as you guys know, I'm Sid. I'm currently doing my Masters here where I focus on research on consensus protocols at the Sky Computing lab uh here at

Berkeley. So part of my research focuses on DAG-based BFT protocols. So if you guys have ever heard of Narwhal and Bullshark, they're uh more novel protocols that focus on high throughput for consensus and working on getting lower

latency there. And I also do some work on Gasper which is Ethereum's consensus protocol. And here at BAB I used to be an ex-core developer and researcher, and now I'm just giving lectures for fun. So yeah, that's a little bit about me. Now let's

talk a little bit more about BAB for those who are unfamiliar. So we're a student org uh here at Berkeley focused on education, research, development and design in the blockchain space. So we run courses on campus and online. If you guys have ever seen our EDX uh we do

Consulting projects with Fortune 500 companies and top blockchain companies, and we have research projects as well. Um, and if any of this is of interest to you, feel free to scan this QR code to learn more about us. Um, and yeah, are there any questions before we dive into...

like our overview section? All right, awesome. So let's do a brief overview on crypto. So Bitcoin and Ethereum are two of like the most well-known things in the industry, so let's talk a little bit about Bitcoin first. So Bitcoin is the first widespread cryptocurrency application that solves

the Byzantine Generals' problem. So the core innovation that Bitcoin did is uh proof of work consensus. So the Byzantine Generals' problem basically uh explains how do computer networks uh continue functioning when you can have up to F parts of the network fail, and the proof

of work consensus protocol solves this by making networks uh making the network solve computational puzzles to prove that they are not malicious or non-faulty. And if they provide a correct solution to the computational puzzle, then whatever transactions uh or blocks that they're trying to add to the

network can get added. And this is kind of what we show in this diagram here. So uh let's move this a little bit, just minimize really quick. So we say client and server in this diagram, but you can think of the client being just like any

node on the network, and then the server being being the broader network. So one of the uh nodes in the client solves the computational puzzle, they send it to the network to verify this uh and once it's verified uh they are granted the service which is essentially just like adding a

new block to the network now let's talk a little bit about Ethereum so Ethereum uh very broadly kind of just generalizes the Bitcoin concept by adding a programming or execution environment and this is very powerful because you can do a lot of uh more generalized applications

or just pretty much almost anything on this very distributed computer that a lot of people have access to um through this like programming environment so specifically the Ethereum uh blockchain uses what's called the Ethereum Virtual Machine EVM and this kind of acts as like almost every other computer that

you know so you have like a a stack memory and program counter that kind of just tells you how to execute programs you have access to some memory or state um um such as like your accounts here and then other uh EVM codes that we won't really go into and the core

difference that Ethereum has than most other computers is this notion of gas so gas is kind of just a way for you to measure how much computation your program is actually doing so the main idea is that if you have some computation you want everybody to pay

for everything that they're doing so you kind of use gas to denote how much work are you making the network do uh yep questions between all the EVMs so the Ethereum Virtual Machine doesn't really parallelize at all uh it's like very poorly designed in that

sense um essentially like everybody has like this notion of like storage slots which is like in your like computer when you have like memory kind of corresponds to that it's that everybody knows that in the virtual machine this value is stored at this slot when you're

executing some smart contracts, um, so there's no real notion of like parallelizing. Uh, other blockchains do this, um, namely like Solana has a lot of this type of optimization, but Ethereum doesn't really have that provided. Uh, people are trying to work on this type

of stuff, uh, but it hasn't really been formalized yet. So kind of like a simplified but also complicated computer. So this is all like very kind of like nuanced stuff and very new. Uh, so now the obvious question to ask is why is adoption not widespread? Uh, do we have

any takers? Any guesses? Sure. Okay. Anything else? Go for it. A lot of bad actors like in the industry, and that can cause a lot of fear entry based on the you have. Yeah, so these are all pretty good responses, and yeah, I pretty much agree with all of

them. Uh, there's a lot of growing pains around accessibility or UI. Uh, it's very expensive to use a system sometimes, um, and it's very new technology, so a lot of people don't really know how a lot of it works, which can lead to bad actors, uh,

taking advantage of this, and it can just be difficult to kind of use the systems. So this kind of leads into what's called like the blockchain trilemma, uh, where people try to balance between decentralization, scalability, and security. And typically you get to choose

two of these three. Um, so Ethereum specifically has this kind of ethos where they focus on, for blockchain to be decentralized, it's very important for a normal person to be able to run a node and be able to verify things on their own. It's this uh notion

of trust uh don't trust but verify uh and this has been very commonly quoted by Vitalik uh the co-founder of Ethereum so Ethereum has a goal of keeping the hardware requirements low for you to run a node uh and any updates to scalability should not come at the

expense of decentralization or security um and the way that Ethereum approaches this today is at a year of L2 networks on top of Ethereum also known as rollups so L2 solve this blockchain trilemma by compressing many transactions into one transaction that's submitted into the L1

and they do so in a trustless way so you can imagine that if I'm using an uh an L2 I treat it the same as transacting on Ethereum but under the hood the L2 just compresses a bunch of information on this like separate layer that's cheaper

and then submits it back to Ethereum for everyone to use uh and it does so in a trustless way says that you can dispute things and also like trustlessly exit the L2 um so yeah rollups perform transaction execution outside of the layer one and then post this data back um and Ethereum

has kind of like changed their scalability road map to focus on this rollup-centric model uh because it allows people to focus on decentralization and security of just the Ethereum layer uh while not having to worry about scalability of other things that you're using so it kind of

reduces the scope for Ethereum to work on but also allows people a lot of um design space to do other things and rollups are a lot cheaper than L1s uh mostly due to the L1 fees and we'll dive a little bit more into that but we'll just leave

at that for now uh but I do want to say like L2s are not a very novel idea so they've been around for a while and L2s have been suggested back in 2015 um as a way to do scalability so a nice analogy to think

about L2s is kind of like interstates and highways so you can consider the L1 to be the interstate that's designed as like the backbone of transportation and designed for like long distance travel and just like a lot of things and is very stable to think about it um where

as uh an L2 is like a highway that's parallel to the uh to the interstate so it can also facilitate traffic uh but probably used for like shorter distances and whatnot and you can interlink the two between an on-ramp and an off-ramp

in this case it's through a smart contract bridge and this allows both systems to interact and exchange assets securely uh and efficiently so when you have high traffic on your interstate what do you want to do you would want to take the highway as it's like easier to

get uh on off and just just faster so the same analogy applies to L1s and L2s when there's a lot of traffic on the L1s a user may decide to use an L2 for a period of time uh for cheaper and faster

transactions and then they can eventually choose to say okay I'm done with the L2 the L1 is back to normal I want to continue using the L1 um so yeah that's kind of just like a nice analogy to reason about everything so uh

provides like a critical component uh to give security to the L2 user um through two main mechanisms the first is that L2 users should be able to take whatever they have on the L2 and bring it back to the L1 without any coordination from the

L2 so this is why we have Smart contract Bridges um and without this guarantee you wouldn't have like a trustless implementation of the system um and then there's other mechanisms to make sure that your transactions were executed correctly in the first place uh on the

L2 uh that we will also dive into and yeah since they have been proposed in 2015 rollups have kind of become like the canonical way to make Ethereum more scalable by just compressing transactions in a trustless way uh and there seem so critical that Vitalik

once again the co-founder of Ethereum thought um it's like the best way forward uh previously Ethereum had like a slightly different architecture to scale but since then that's been kind of discarded and is focusing specifically on rollups and the Ethereum core developers are making changes just to

make them better suited to run L2s and this is one of the posts on the Eth Research Forum I believe that kind of discusses this um and yeah we're going to focus or we're going to start off by focusing on two main things the merge

and the separation of consensus and execution uh uh on the L1 and how this relates to L2 networks but before we dive into that are there any questions all right cool so now let's talk a little bit about the merge so the merge was Ethereum's

transition from proof of work to proof of stake so we talked about proof of work a little bit earlier where we like described it as like a way to kind of have computational puzzles to be able to prove that somebody's not like a bad actor uh what we didn't talk about is

that it's very inefficient amongst other bad properties that make it kind of like an undesirable way to run a blockchain so the merge was basically Ethereum's upgrade to the proof of stake model of consensus that we won't really worry about for now but let's just uh we just

think about it as a different way to run the network um so the existing proof of work blockchain was replaced with what's called the proof of stake Beacon blockchain uh so the pre-merge Beacon chain had not been uh processing transactions like we can see that we

started the Beacon chain somewhere here but it wasn't really doing much work it was just reaching consensus on blocks and then after the merge which is like an arbitrary point the Ethereum developer set they said okay we're going to move to this new system so with the merge came this nice

separation of concerns so previously uh the if you're in 1.0 blockchain kind of just had like one like execution layer um that just did all the work but with the Beacon chain we separate uh the execution layer from the consensus layer so as we

see here like the execution layer in like proof of work Ethereum just contained like a bunch of transactions uh and other like metadata that's important but then after the merge we have the separation where the consensus layer tells us like oh this is how we like process new transactions and order

them and then it kind of sends it off to a different layer to actually execute the transactions. We can kind of see this uh more explicitly here where an Ethereum client is made up just of like two different parts: the beacon node which is the consensus layer and the execution

engine uh which communicates with the beacon node to be able to execute transactions. So the beacon chain handles proof of state consensus and it tracks like the chain's head uh any like new blocks that are being gossiped uh and receives like validated rewards uh and

the execution layer just primarily handles like running transactions and running smart contracts and updating the state of the Ethereum blockchain. So everybody uh that runs a node essentially runs both of these two pieces together with some exceptions um and this is what's happening like under

the hood when you're interacting with the Ethereum blockchain. So the data layer in Ethereum is technically just like the beacon chain state um which is essentially you can think about like all the accounts that exist in Ethereum uh and like what balances they have um different

blockchains have different approaches to this, but on Ethereum it's kind of just like everybody just has like one like beacon state that every validator just maintains. All right um and now we're going to talk a little bit about client diversity um like we just mentioned like

Ethereum cares a lot about decentralization, security uh so there's a lot of different uh clients to do this. So on the left side of the screen we have all of the execution clients so you can see that they're written in like a variety of different languages by a

variety of different developers, uh, and on the right side we see all the consensus clients, uh, also in a variety of different languages and frameworks and developers. So the goal here is to kind of just make sure that there's very little overlap, uh, and like systemic risk

in the system. So like let's say there's a bug in one of these clients, if it goes down, then we want other clients to be able to take over without having a lot of failures. Um, and this is kind of just, uh, made a lot more explicit with the

separation between the consensus and the execution clients. So with that being said, what does this mean for L2s? Um, so the L2 transaction lifecycle kind of looks like a single transaction in mainnet, but in reality, it kind of follows like a similar process to what we just

mentioned for L1s. So this is kind of like the full picture, but we're going to make this a little simpler and not worry about forced transaction action. So let's just consider this simplified picture. So if I'm a user on the L2, I submit my

transaction to the sequencer, and the sequencer takes a bunch of transactions, puts it into an L2 block that's unverified. We can consider this to be kind of similar to the consensus clients, like just ordering different things and figuring out, okay, I have a bunch of

transactions, how do I package them together? Then the unverified block is posted onto the Ethereum layer and sent out to the prover, and the prover generates like a ZK proof that tells us, okay, these are like valid transactions, or they've been executed correctly.

generates a proof and the proof is sent to the uh L1 as well which is kind of similar to like the execution part of the regular Ethereum L1 so we kind of see like the same idea of like separation of concerns um between the

sequence or ordering and then proofs being generated which is essentially like make sure that everything works correctly or executing in a broad sense and then putting that back down into the Ethereum layer uh I know those a lot are there any questions about how this works or just like anything

specific go for it someone someone does they whatever kind of like there are mechanisms to be able to prove that some transaction was faulty like uh in optimistic rollups there's a concept of fraud proofs that you can run to say oh like look this person did this

incorrectly um and in ZK proofs is slightly different because uh if if your proof verifies in the first place that means that it follows all the rules of the VM so that kind of just like if it doesn't prove then like there's a bug in

the first place which so kind of like in theory it shouldn't be possible to construct in the first place um but I wouldn't say that they inherit security because if you're an L2 user uh the only thing that you care about is like the

L1's ability to do what you want it to do like if you send some transactions into the L2 and then that goes into the L1 you just want to make sure it makes it to the L1 and then you you also want to be able to make sure that the L1

works correctly for you to be able to take anything you have on the L2 off the L2 without interacting with the L2 so I think the better way to think about is that the L2 inherits the security of Ethereum and um it kind of requires that to be

able to function like a trustless way uh usually ends up being compressed um like for example for ZK proofs like all you need to show is that there's like a state diff like basically all you're saying is like oh this was the state of

the L2 before this block and this is what this block did that's different from that and then you proved that that like transition was correct so that's like that ends up being a lot smaller than um like proving or like listing out every single transaction itself um so it

does end up being compressed yep for the sequencer is that decided by whoever is like the users is that decided by the name that's it's decided by the rollup yeah right now there are a lot of people doing research into decentralized sequencing a lot of rollups today don't

really have like a decentralized model for you to be able to like spin up your own L2 sequencer uh but people are working on that yeah but even if the L2 did uh act maliciously you should be able to there are like mechanisms to be able to prove

that it acted maliciously um so that is kind of like makes life easier I guess like the follow question is like is there like some pseudo malicious ways that it could act where it's not technically wrong like let's say like there was some trade that both the

person posting that L wanted to make and you wanted to make could they choose to put theirs over yours sort of sequencing yeah they could do that but it's also kind of easy to tell like if there's like if the sequencer was actually doing that you're able to tell oh this account

is owned by like the sequencing company like they're just like doing this so it is easy to tell um I guess it's more of like a social thing um but yeah it is kind of hard to like fake that yeah all right let's move on to our next

section which we're going to take a break break and uh everyone can grab some pizza and wear some cool merch that we have we have some wait wait wait we have some zk and bab exclusive edition merch like you cannot find this anywhere else so please wear some

pizza it it [Music] you're all right everyone we're going to go ahead and get started again um so we're going to talk about data availability and EI 4844 uh one of our audience members num suggested or kind of alluded to this

earlier so we're going to talk about it a little more uh data availability is a fundamental concept for any L2 implementation and it refers to the assurance that any necessary L2 data um such as transaction details or the current state of the L2 uh is accessible

uh from the L1 and can be independently verified so this is kind of like a visualization of what L2s are um or what uh L1's and data availability are with respect to L2s so for understanding an L2 you kind of to know where the data for is stored

Uh, another way of kind of putting this is, uh, what is the network's data availability layer? Um, and once again, it's very crucial to maintain like the trustless nature of the system. Um, because it ensures that anybody can verify the transaction and inspect it.

The difficult part is that when you're scaling blockchains, the blocks end up getting bigger, uh, and it becomes harder for normal users to download data all the time and verify it, uh, as you kind of want to. And once again, the, um, has like core design goal of being able to do

that, uh, for any arbitrary person with low hardware requirements. So once again, the importance of data availability in L2s can't be overstated. And, um, without that, it kind of goes against the ethos of decentralization and trustless, uh, and it becomes impractical.

Um, and just makes it a lot easier for people to potentially manipulate the L2 and do fraudulent things. Um, so traditional L2s use Ethereum as the data availability layer, um, and this is why we say that L2s quote-unquote inherit the security from, uh, the Ethereum state.

zkSync ZK Workshop Series Lecture 1: L1 & L2 Fundamentals

Scripts