# Source code analysis of zkSync

###### tags: `thread`

These two days I took apart the code of zksync and read it carefully (matter-labs/zksync), as one of the mainstream zk-rollup projects on the market (and [StarkWareLtd](https://twitter.com/StarkWareLtd), [loopringorg](https://twitter.com/loopringorg) and [Scroll_ZKP](https://twitter.com/Scroll_ZKP), etc.), zksync is considered one of the most open source, code The most complete project, so it can be a good study as zk-rollup quality learning materials.

## Early rollup

The founder of zksync is [@gluk64](https://twitter.com/gluk64), he is a Ukrainian developer, I can see his figure frequently in many early rollup projects/forums.

For example, in barry whitehat's roll_up (which can be considered the earliest rollup implementation) gitter forum, the first people to discover the project and come in to discuss it were [@PhABCD](https://twitter.com/PhABCD), [@gakonst](https://twitter.com/gakonst) (paradigm CTO) and [@gluk64](https://twitter.com/gluk64).




And because I was curious about the historical evolution of rollup, I went to the ethereum research forum and searched for the people who first proposed rollup (before 2019).

At that time, only PhABCD, barry whitehat and gluk64 mentioned rollup in their replies to vitalik, and all three posts were well worth reading.

I also found that research (https://ethresear.ch) is where many good ideas are first formed and discussed. vitalik has been on research almost every day for the past four years posting/reading new ideas and talking to community developers.

So if you have a good idea/project, you might want to post it on research, and if you want to discover the earliest quality projects (which might still be just an idea), you might also want to hang out there more often.

## Open source code of zkSync

zksync currently open source code is the v1 version, their v0.1 (minimal implement) was completed on 8.20.2019, after which the main network went live in June 2020, but the v1.0.0 version was not completely finished until July 2021 (two years of development, it's hard to see it all in a week).

The team's focus is now put on zksync v2, the zkEVM everyone is waiting for, which is currently live on testnet but not yet open source, and is expected to be open source once all the work is done.

So the v1 we see is a very stable version, no major feature updates will be made except for some security and stability maintenance . 👇

### zk-Rollup Architecture

Most of zk-rollup basically consists of two major parts, one is the contract deployed on L1, this smart contract will communicate with the rollup network, receive the results returned by the rollup, and after verifying the correct operation under the chain to store the data on the chain (usually stored merkel root).

A rollup network on L2 is used to execute a large number of transactions and pack them into a block in bulk, and then generate proof to verify the validity of the results.



### zkSync Architecture

zksync mainly consists of three modules, the first module is the contract deployed on L1, the role is also communication/verification/storage, and the user's assets from L1 to L2 (deposit), or the assets of L2 back to L1 (withdraw).

In addition, zksync implements a priority queue where all L1 user-initiated deposit and withdraw (full exit) can be completed independently of L2 transactions (not yet tested for additional fees).


I also found two very interesting details that are worth studying separately.

**Ethereum address system**

The first one is that L2 does not need to generate new addresses, it is exactly the same account system as L1 (L1 EdDSA signature -> L2 private key), so for the user, it is only necessary to switch the network to which the Ethernet address is connected to enter the layer2 world.

If the 1 billion crypto users hosted by layer2 continue to use Ethereum account system in the future, then the current on-chain identity/on-chain data (ENS) will become a very important infrastructure, now this kind of protocol is very niche, at most only tens of thousands of people use it, in the future it may exceed millions/millions.

**Forced Withdrawals and Security**

The second is that all rollups need to achieve data available, assuming the worst case of a complete collapse of the rollup network of layer2, users can still roll back the latest block and state according to the data stored on the chain (involving consensus) and retrieve their assets from the rollup safely.

So observe whether rollup is safe enough to perform the above limit test (the final data stored on the chain is the safest), and later we can combine the idea of zksync to look at DA schemes such as zkPorter/Validium/Volition/avail/celestia/danksharding.

**Prover and Sequencer**

The other two modules of zksync are prover and server (both are implemented by trust, so it is not hard to guess that the network of zksync v2 is probably also implemented by trust).

Prover is an on-demand worker, used to generate proof for blocks. Generating proof is a very computationally intensive task, so there are many zk-hardware projects that outsource the work of generating proof to miners or other third parties.

The logic of zksync rollup is implemented in the server, the core service in /zksync_core, which receives all the valid transactions in the mempool and commits them to a new block (blockchain).

After the new block is committed, the sever will request to add a proof to the block, then the witness generator of the server module and the prover mentioned above will cooperate to generate the proof and add it to the block, after that the Ethereum Sender service will communicate with L1 and post the After that, Ethereum Sender service will communicate with L1 to publish this block to the chain for verification/storage.

In summary, this is the process below (image source Google). zksync gets all L1 (via Eth Watcher) and L2 transactions and adds them to the mempool (L1 transactions take precedence over L2).


After that, core service will check periodically and pack the transactions in mempool that meet the requirements into a new block, after that it will request proof from prover, add to the block and send (via Eth Sender) the L1 contract to verify/store.

This project is quite large and I haven't read the source code completely, I post some of the [reading notes](https://github.com/LuozhuZhang/sourceCode-zkSync-rollupContract).

Reading the source code and trying to implement it is a very enjoyable process, if there are partners who are very interested in zk-rollup/layer2 welcome to DM me, I look forward to finding more interesting people to read the source code and try to implement the new project together.

## Conclusions

zksync is a very interesting project, it is the pioneer of layer2, but will not be the end game of layer2, there are still a lot of problems waiting for us in L2 that need to be solved.

For example, how to achieve seamless composability between general zk-EVM, cross-rollup and rollup?

And the future emergence of application-specific rollup, even after L3, will not derive some convenient development and deployment of L3-rollup SDK/Protocol it, these directions are very worth exploring.

[Thread](https://twitter.com/LuozhuZhang/status/1521124870385405953?s=20&t=LEAtT7YABXdv2vw89_MJSQ)