[Music] [Music] Hello, hello. GM. Hello, Hawks, and welcome to this zkSync Era CodeHawks kickoff. My name is Karen Iingirl, and I am a software engineer and instructor here at Cypher. And today, we are going to be running through the zkSync Era

competitive audit that is currently live on CodeHawks. Before we hand over to our wonderful guests, I'm just going to go through a few quick housekeeping highlights that I want to mention. Um, so, of course, this contest is currently live and will be running until the 2nd of

December at noon UTC. The number of Solidity lines of code is 15,740, so this is a pretty big boy. Um, and you'll be competing for a prize pool with a grand total of $500,000, which is split into $475,000 for mediums and highs, and

25,000 for lows. I also just want to give a very quick overview of the project. Of course, we'll be going into more detail shortly, but zkSync Era is an EVM-compatible layer 2 rollup that uses zk proofs to

scale Ethereum without compromising security or decentralization. And all the information about this project, so like the actors involved, the scope, the compatibilities, etc., are detailed in the README on the GitHub linked on the CodeHawks competitive, um, competition page. And as always, if you have any questions during

this stream, then feel free to drop them in the chats in the comment section. And if you have any questions afterwards and you're like, 'Oh, I wish I'd asked that during,' then just post them in the Cypher Discord or also the, um, zkSync Discord.

if you would like and now I'm going to pass over to our guests to explain to you a little bit more about the project so we have Stas and Vlad from Meta Labs hello Stas and Vlad the floor is now yours feel free to introduce yourself

and share your screen afterwards and explain a little bit more about how this works let me just change the orientation so we can see everyone hello hi everyone uh I'm Stas I'm protocol engineer at Meta Labs and and Vlad yeah hi everyone I'm Vlad security

engineer at Meta Labs we work in with Stas for more than four years already I guess on the contracts and stuff for think um okay so I'll give you an introduction to our Era contracts repository which contains most of the logic about our system let me just share

my screen okay so once you open our repository probably the first thing which which you should do is to go to ER contracts docs read me and there you will find the entire documentation for our new version so the audit is done not for the current version that is on

mainnet or even on testnet this version is in works so it it's been audited before the release here uh in read me there is documentation about the parts I will probably not go into deep detail about each part since each each documentation explains it perfectly but

I will mainly focus on how things stick together and where to find the files in general okay uh firstly there is also a potential reading order which you can take you can choose so for instance there is a path which can be used by someone who would rather use our bridging

Maybe for what would RL2 developers use in case of this particular contest, probably the best approach is to actually go read through all the docs one by one in this linear line. And even if you see that some parts are intertwined, some parts require next

steps, just don't worry, continue reading and at the end you will have a holistic picture of everything. And then you can, when you take a look at a specific contract or you're interested in specific functionality, you can go back to the original documentation and get the detail that you

need. So our, uh, in our repo there are multiple folders with contracts. Firstly, let's start with L1 contracts folder. The name is a little bit historical so it does not only contain contracts which are deployed to layer one, but usually files from there were only

deployed on layer one. But in this specific release, due to some unification of logic, which I'll talk a little bit about later, uh, now it has files which are deployed both on L1 and on L2. So we go to L1 contracts to contract folder

and the first thing which you can go in is state transition. There we explain the code and logic which is responsible for a single ZK chain. Zync era is an example of such ZK chain, but there are more and more and more partners get added to our

ecosystem so it grows and each partner gets themselves a chain which is represented, each chain itself is a single Diamond proxy and it points to the following faces. So this holds the logic. Also, this folder also contains files which are needed during initialization of the chain. So this is Diamond Init which

is used during initialization and also there is also a Genesis upgrade which is called during the Genesis of a chain. You can read more about it in the corresponding documentation. Uh, these old chains, they well they have all separate state, they have all separate admins, but we

do not allow them to have any upgrade which they want because it could allow them to break the ecosystem in various ways. That's why we have a chain type manager. If someone has reviewed the Casing codebase before, it was called State Transition Manager. Now it has been renamed for clarity, and this contract serves as two

things. First is a Factory for contracts and B it is the main point through which it is controlled that all chains are up to date and also all new protocol upgrades are passed through this contract. And that's pretty much it. There are also verifiers which are responsible for just verification of zero proof. There

is a validator time lock which is just a time lock mechanism to ensure that there is some distance between when a watch is proposed on layer one and when it is executed in case there is a bug. But all these contracts can be found in the docs, uh, settlement contracts and NZK

chain Basics. Also our chains, they accept uh transactions from L1, so users, if they have, if they want to call a layer two contract from layer one, they can do so. And more logic on how it's done can be read in the priority queue part. So firstly it's

firstly which is worth is processing of L1 to L2 operations. But in this particular release, we also introduced a new way how the transactions which come from L1 are and this new way can is explained in a different file, so don't worry, you don't have to remember the

Files, all of them are linked in the order to read in the README file and just saying that they exist, okay. So after we've figured out where we can find contracts for individual chains and the manager of chains, there is also the topic of bridging. There is this Bridge Hub contract which

is the main point where all the ecosystem comes together. So it contains mapping from chain ID to chain type manager which it belongs to. It also has a mapping from chain ID to their address. All new chains are created through this file. So I said that chain type manager

is a factor, but the actual creation starts here. Someone posted a message. Oh, okay. Uh, then okay. And it is the main entry point for doing transactions on the L2. So when when users want to start a transaction on on a ZK chain, they go to

Bridge Hub, tell which chain they want to call their transaction to and uh, that's it. And it will route to the responding ZK chain. This thing, it this functionality is pretty much the same as in the previous versions if you know how the the pre-versions worked, but it's not

needed for the audit, but just in case. Um, and I think from the basic Bridge Hub perspective, that's it. Then now here comes the big changes which came compared to the previous version. It's how we do bridging. So before, basically whenever you want to

bridge a token, you would have to use our default layer one shared bridge and it would only allow you bridging only tokens which are like standard ERC20, that is no special functionality like WBTC wasn't possible. So just plain bridging of some very plain

ec20 assets was possible and in in case someone wants to have some mve functionality they would have to develop their own Bridge, however, the problem here is that typically these user-built Bridges they would share a lot in common, like for example logic in case the deposit fails

and allow users to recover funds, there is a lot of repeated logic between different Bridges and generally it makes so what was decided is that instead of having a bridge which is responsible for tokens what we will do is that we will have two types of contracts: one is asset routers

which are trusted centralized contracts that are uh, B centralized. It means that it's we have only one asset router per chain like or one asset router on layer one, one, and on each individual chain there will be deployed exactly one l tool asset router, and whenever there is

a bridging that is done uh, the communication is only done between those between these asset routers, however, the exact token handling has been delegated from this asset router to a separate type of contract which is called asset Handler and users can now implement only their own asset

handlers if they want to have any custom functionality, and here in our Bridge you can see that we have L1 asset router which is deployed on layer one, L2 asset router which is deployed on all ZK chains like one, this contract is deployed on all the keychains and all

Bridge communication is done between these two contracts and as an example of an asset Handler which could be developed is native token W, so this native token W it represents totally same functionality as we had before for 20 tokens that is just a simple rc20 is escrow on chain one and then it's

copy is deployed on chain two, this is R version is deployed on chain two, and yeah, so it just simplifies the interface for for the users, in case they want to have any sort of custom token functionality. You can read more about it again in the

readme in the bridging topic here, the description about AET router and Bridge Hub. I think uh, with regards to bridging, that's about it now. Uh, another thing which was added compared to the previous release is support of custom data availability. So before, you chains had only two

choices, either data is roll up or either chain is a rollup or chain is a validium. And validium means that data is just not sent like, and there was no option to easily add some custom D validation, like Celesia or or some other D

validator. And uh, but the uh, for to allow add didn't C de validation, or maybe allow even some custom compression for contracts, we added a pair of contracts uh, for each L2 chain, and one is deployed on L2 and one is deployed on L1. And the contract on L2

would be responsible for compressing the data and the contract on L1 would be responsible for verifying that the data is correct. And our contracts which are deployed on layer one, there is are in the DA contracts folder, and the contracts for data availability that are deployed on layer

two side of things, they are in L2 contracts folder in data availability. You can read more about how exactly this DA scheme works in documentation, there will be settlement contracts, data availability, and yeah, and read in the order which is provided in the readme. That's one thing, and uh, the other

A feature that was added is the ability to have another L2 as a settlement layer. So typically rollups, they settle on L1. They send their batches and then send their proofs on L1, but if uh but it has certain limitations. It means that for instance, 

such settlements cannot happen often otherwise the cost for running the rollup or generally cost for users would increase too much. And for the future, we would want to allow to have smaller batches and just to allow quicker exchange of information between different rollups. And for that, chains 

can use a new settlement layer called Gateway. Gateway is just a normal ZK chain, just it's totally normal but it just has to be used as a settlement layer. Uh, but all the contracts which are which I mentioned before in state transition, these are all 

totally applied to it as well. But uh now an admin of a chain, if it wants to stop settling on L1 and start settling on Gateway, it will have to call the it would have to bridge its chain on top of uh Gateway. And the logic for this can be seen in 

like in the Gateway part of the readme. And here you can read just how generally it would work. But overall, like chain migration would work the following way that the admin calls Bridge Hub and then via standard process where only one asset router and two asset routers can 

communicate, the chain would be deployed. So you can imagine that a chain is sort of an NFT. So obviously it's not an NFT, but like when the migration is done, very similar logic is used to it and it allows to have reuses, all to reuse a lot of 

logic which is common for bridging and for migration, for instance, if migration fails then a very similar method can be used for recovering the chain, okay? And that's uh pretty much it on the side of the main functionality. There are also added some new contracts like

for instance, L1 nullifier, it will be a nullifier for whatever messages are sent from Layer One to from Layer Two to Layer One. Uh it's the new contract which has which the old sh brid has been upgraded to, but about all this other minor contracts you can read in the

documentation, I think it will be fine. Uh another thing which was added is we amended the chain admin contract. It was amended to have a more modular architecture, so before we had chain admin as basically an, you know, able contract, and then there's also a separate role

for calling talking multiplier, it's it's helpful for chains which have ERC20 tokens to update the ratio between the price and their token price, and so that users could pay the right price for transactions which come from Layer One. And uh we thought how we could make it

more generic and generally allow any sort of restriction which can be put on top of chain admin, maybe at some point some chain would decide that, okay, we want our chain admin to never be able to set any transaction filter, for instance, we want our chain to always be

permissionless at any like in the in Peru, and our new CH admin infrastructure allows it, so chain admin contains a list of restrictions and uh before each transaction each each restriction would be checked. You can read more about it in our chain management and admin role file, but this new chain

Admin structure is a little bit unstable because there were some issues found with it, so we may not eventually use or recommend to use it for our new partners. But it depends on the eventual decision, so we'll see how it goes. That's it from L1 contracts, uh and

why I said that L1 contracts can compile both for F1 and F2 is because since we allow new settlement layers, it means that our chain when it moves to a new settlement layer, it will have to use new contracts on top of it. And these new

contracts are compiled, they're compiled for the Ethereum VM environment, and that's why for L1 contracts we made sure that they're compilable both in the EVM and the RM environment. And DA contracts are those which are only on layer one because there's some feature which is available

only on layer one, and it is blobs. So, rollup verification which uses blobs is only available for the EVM environment, and that's why we couldn't put it together with the rest of the system. Okay, that that's how contracts on L1 or look like, and bridging contracts

look like, and also DA contracts look like. But our system, each layer two also has a set of predeployment of contracts or check that, um, only byte codes which are known can be used for new contracts, etc. And all this logic is located in the system contracts

folder, so you can generally assume that all the contracts which are present here, uh, the ones which are only deployed on L2, and they're typically all predeployment constants can be seen here. So, we can see the addresses to where these are predeployed. Some fundamental differences from any

other indication okay so in system contracts we have two fold two folders boot loader this is the main entry point of our ZKM so our proof it actually does not check some transactions per se it checks that execution of boot loader was correct how it translates into our

blockchain which we can see from the user perspective it can be all right in the L2 system contracts folder from the docs and here are the contracts themselves I don't think I can add much about them each of these have some system functionality and they're all

predeployment you can read documentation for each individual contract also last final note which is uh how did we manage the upgrade for Gateway so Gateway introduced a lot of new things like New Wave bridging also the fact that chains now have rather complex pre-deployed contracts

such as Bridge Hub and Messenger these are all this will be predeployment so that the admins they cannot violate the will of the decentralized governance we had to create a multiple step upgrade process and it is mentioned here so here you can read generally

which functionality was added compared to the previous upgrade that's one thing but with regards to upgrade process it is itself here so it would be very good sorry oh yeah so it would be very good if um those who they should also take into account files which are included

here and generally the the process itself we have tested it locally but maybe something was missed or maybe like there are some ways into way how could exploit this upgrade process and uh yeah that that's it so if you are auditing don't only look at the

contracts once they are deployed but also ensure that the upgrade process itself is safe and I think that's about it uh with regards to our big repo uh it in this does have a lot of code but we hope that documentation covers all of it also here we mentioned

some of the tricky places where there could be issues obviously since we listed them here they're probably there we have already thought about these places but maybe we forgot something and yeah that's it from the side of era contract people lot I think I will give you

the floor uh yeah sorry I had had a problem with my internet or something so I was disconnected but now I'm here there are two more topics that I want to talk about it's not about only era contract changes that we had but also we had the excitement a huge upgrade on the

governance part and we switch from the multi upgrades to the decentralized governance that is a process with the S different bodies that will lead the upgrades and also the token and the upgradeability we are working so let me um share the

screen in a second cool uh can you see my screen I guess yes cool so uh beside your contracts we also include the key governance contract that is a separate repo and you can find read me for the ZK governance uh in the folder of the

key governance there's not much info but you can find how to compile and test contracts and more importantly if you would want to go to the documentation you could go to ZK nation.com and find the documentation about the governance process itself that contains the token implementation

all the economics information as well, but also the process for the governance upgrades. So it includes different parts, starting from the era contracts that are currently deployed and the voting on Layer Two and Layer One parts for the upgrades. Let's take a look into

code. So from Layer Two contracts we have in scope the Governor contracts. There are three different Governor contracts: one is the ZK Protocol Governor. This is the most important protocol governor and this is the contract that is, um, a zkOps-based Governor contract. So the way it will work is that

anyone with enough tokens, or enough delegated tokens, can vote on the proposal and create any proposal that will be executed from Layer Two to the ZK Protocol Governor. All the parameters are enshrined in the configuration of the contract. And then after seven days, the

proposal will be created, it will start the voting process. The voting process will also take another seven days and after that there will be execution of the proposal. So this is the protocol governor. The same way we have the ZK Token Governor and the ZK Ops Governor. They

have pretty similar configuration parts, but a different meaning for the system. So for the ZK Ops Governor, it's a governor that will control the non-enforced proposals. Basically anything that the L team, uh, or the ZK Association should do, but not enforce it on the protocol

level on the contract side. Anything that should not be upgraded, but more like an off-chain proposal that should be executed. The kind of proposal that we would like to go through the ZK Ops process is a proposal to give some tokens to some entity, or to force a metal

labs to act in some specific way, including some changes to the front end and etc. While the Key Protocol Governor is much more powerful, it will actually lead to changes in the infrastructure, in the contract side, in the upgradability parts, and the token Governor is needed only

to mint new tokens or to distribute already minted tokens. While the process for the voting is very similar, and you could find all the parameters for the governors in the ZK Nation documentation right, as well as you can find the Key token, there's two different

versions of the KE token. It's upgradable contract, it's all deployed on Layer 2, uh, more specifically, it's deployed on ZK-EVM Kira, and it's already live, so we can check the deployed version as well and see the differences between current and previous

upgrade on the implementation part of the Key token. You could find your ERC20 token with a very, I would say, standard implementation with some, some extensions for minting, burning, and so that the r that can add new tokens to the system, burn already existing tokens, and we have the management for

the tokenomics that we have, so only specific addresses with the minter roles, in our case, it will be ZK token Governor, it will be able to mint new tokens as well as we added one method for delegation, uh, via EIP-1271 signatures.

But this is, uh, more specific to the EOA account abstraction, uh, support. So you would want to support account abstraction with delegation instead of just having standard EOA that supports that, right? And so for all the voting and all the token transferring is happening on the King here, but the

Contracts are governed from the layer one, and in order to change something on layer one, we need to pass data from layer two to layer one somehow. On layer one, we need to accept these upgrades. Because of this, we not only include layer two contracts, but layer

one contracts that will actually read the data from layer two of what voting was done and what was executed on L2 about any decision from the government and then execute the upgrade. So we can find the folder for layer one contracts, and this is a couple of

contracts. This is really important; this is probably the most dangerous part of the system because it controls the upgradability. If a bug is found here, then anyone who would be able to exploit it can make a malicious upgrade and steal funds from the system or override

anything. And what we currently have is the main contract protocol upgrade handler. I would start from that. You can find the doc comments here on the contract, so it explains what exactly is happening in the system. So token holders on L2 propose the upgrade, send the

message to L1, and then there's a process for accepting the upgrade, starting from the approval from different bodies, then to execution. And um, so for the contract, you can see the configuration parameter; it's immutable; it's constant on the system, so we can assess on these parameters as

well and look into the actual state transition machine that this upgradability will work for. So the first function will be start upgrade. The way how it works, it accepts all the meta parameters on which each layer two batch number what proposal was created, and etc. for proof of the message

that was sent from layer 2 to layer 1 and it verifies that proof was sent, indeed it was correctly executed, and the governance on layer 2 voters delegate they voted on something and executed their governance on layer 2 from the protocol governor on layer 2. Then we check that it successfully

was proven on layer 2 and we start the upgrade. The upgrade started with a 3-day veto period when guardians can extend the veto period for another four days, so seven days in total. But in case it's not extended, the veto period will pass and then we go to

another stage of the upgrade. On the other stage of the upgrade, we have two different parties that can vote on the upgrade: the Security Council and Guardians, to for approving upgrades from the Security Council and Guardians. And it's basically accept the ID of the upgrade, so the hash of the

proposal and then checking the state of the upgrade and then approve it. So we go to the next stage of the upgradability. We can find guardians. Soul and Security Council is a contract that is responsible for this multi-sig, so specific parties that can

approve the upgrade and move the upgrade to the next stage. And after all the approvals that will happen on the system, this execute function, where anyone or the specific party that was specified in the proposal of the upgrade on the very very beginning of the upgrade, can execute

it. After the execution, we market is executed and then basically execute the calls from the governor. This contract protocol GD Handler will hold all the permissions to layer 1 and layer 2 chains. So in case of layer 1, it will be able to execute the upgrade on the

proxy, it will be able to change the system parameters and you can find the connection for the layer one contracts in Era contracts. So, to put an example here on layer one contracts, we'll jump to Bridge Hub and Bridge Hub is a contract that is deployed in a transparent upgradable

proxy and the owner of this transparent upgradeable proxy will be a protocol upgrade handler from Z Key government. The similar way it works for all the contracts for the bridge Hub, native token Vault, etc., and this way we can execute upgrades on L one contracts for Layer Two

contracts. We also keep the upgradability from protocol upgrade handler, but in this case, we will need to use layer one to layer two communication and send the transaction to Layer Two, wait for the execution, and then the protocol upgrade handlers that is deployed on L one can do the changes on L two

parts as well, right? And then also very important to say is that besides the token voting process with the token holders and Security Council or Guardians that can approve the upgrade, we have an emergency upgrade process as well. For the emergency upgrade process, it will require three different parties to

zkSync Era | Layer 2 Rollup with Zero-Knowledge Proofs | Live Competition Kick-off

Book a smart contract audit here 👇
https://www.cyfrin.io/


Cyfrin Audits

Introduction to zkSync Era CodeHawks Kickoff and Contest Overview

Introduction of Karen Iingirl and the zkSync Era competitive audit.

Contest duration until December 2nd at noon UTC.

Overview of zkSync Era as an EVM-compatible layer 2 rollup using zk proofs.

Project details available in the GitHub README.

Instructions for asking questions during and after the stream.

Explanation of zkSync Era Contracts Repository by Stas and Vlad from Meta Labs

Introduction to the Era contracts repository and its documentation.

Audit conducted on a version under development, not the mainnet version.

Suggested reading order for the documentation.

Overview of L1 contracts folder and its contents, including state transition and chain initialization.

Explanation of Chain Type Manager and its functions.

Description of Bridge Hub contract and its role in bridging and chain creation.

Explanation of changes in bridging mechanism, introducing asset routers and asset handlers.

Discussion of custom data availability and its implementation.

Explanation of using another L2 as a settlement layer (Gateway).

Discussion of L1 nullifier and other minor contracts.

Explanation of changes to the chain admin contract for modularity.

Explanation of why L1 contracts are compilable for both EVM and RM environments.

Overview of system contracts folder and its contents.

Explanation of bootloader and its role in proof verification.

Discussion of the shift to decentralized governance.

Introduction to the key governance contract and its documentation.

Explanation of the different Governor contracts (ZK Protocol Governor, ZK Token Governor, ZK Ops Governor).

Description of the Key token and its implementation.

Explanation of Layer 1 contracts for accepting upgrades from Layer 2.

Detailed explanation of the protocol upgrade handler contract and its functions.

Discussion of the emergency upgrade process and its requirements.

Explanation of Guardians contract and its multi-sig implementation.

Discussion of the feasibility functions (soft freeze and hard freeze).

Concluding Remarks and Recommendations for the Audit

Recommendation to compare results with previous audits and external audit companies.

Advice to pay attention to specific areas of the code, such as bootloader and Gateway.

Reminder of information availability on GitHub and Discord.