Deploy Uniswap V3 to zkSync

Proposal Discussion
1

[Governance Proposal]

Deploy Uniswap V3 on zkSync

FranklinDAO (Prev. Penn Blockchain) is creating this proposal in partnership with Matter Labs to Deploy Uniswap V3 on zkSync.

Matter Labs: @zkSync

Proposal History

The consensus check passed with 24M (~100%) YES votes. The temperature check passed with 15M (~100%) YES votes.

The onchain vote can be found here: Uniswap Interface

Summary

To support Uniswap’s multichain mission and expand cross-chain experiences, we propose the deployment of Uniswap V3 to zkSync 2.0 on behalf of the community.

  • zkSync ecosystem has over 100 projects committed to launching on mainnet, including top DeFi protocols, infrastructure, on/off ramps, etc.
  • Deploying on zkSync will onboard new users & increase user activity on Uniswap by decreasing costs compared to Ethereum without security degradation
  • zkSync shares Ethereum’s ethos as a free open-source project with a commitment to personal sovereignty, decentralization and community ownership

We welcome feedback from the community on the proposal, including suggestions on how it can be improved.

About zkSync

zkSync 2.0 is a ZK rollup that supports generalized EVM compatibility for the Ethereum blockchain. The primary benefit of zkSync 2.0 is that developers who have created EVM dApps can port to zkSync 2.0 effortlessly and realize significantly lower gas fees and more transactions per second without compromising on security.

zkSync 2.0 is a significant leap forward in Layer 2 technologies with long awaited improvements and benefits for Ethereum developers:

  • EVM Compatible - supporting generalized EVM smart contracts on a ZK rollup making it easy to deploy existing dApps
  • ToolChain Compatible - able to port smart contracts with existing tools
  • Ethos Compatible - aligned with the ethos of decentralization and open-source
  • Certainty - using zero knowledge proofs offering certainty of security not probability
  • Future Proof - ecosystem partners that adopt zkSync 2.0 now will enjoy all future improvements without the need to change their code

There is broad consensus that ZK rollups are the endgame for scaling Ethereum. zkSync’s EVM compatibility, ease of use, and composability will accelerate developer and retail adoption. Top researchers including Vitalik Buterin recognize ZK rollups as the long term scaling solution.

Security & Bridges

ZK rollups are the most secure scalability solution available today as they rely purely on math to fully inherit the security of Ethereum. There is a general L1<>L2 communication bridge which will support arbitrary message passing and secured by validity proof and Ethereum consensus.

Bridge validators can’t pass an incorrect message or change the content, the worst case would be to censor everyone. Importantly, we’ll be building out additional safety functionality and monitoring off & on-chain activity.

Security is top of mind for zkSync. We are currently working with tier-1 auditors for zkSync 2.0 and specifically in the review process for the bridge code. Audits will be conducted before each major upgrade. Besides audits, we offer a substantial bug bounty program.

Proposal

There’s significant value in Uniswap being available on an EVM compatible ZK rollup. Deploying early on zkSync helps solidify Uniswap’s place as the number one DEX and a thought leader.

Importantly, it will help grow a large list of projects that can be built on Uniswap V3. Established projects like Argent, Curve, and Yearn have committed to launch along with over 100 more projects and big infrastructure players like Chainlink, The Graph, Gnosis are supporting the ecosystem. Growing the public smart contract libraries interfacing and using Uniswap v3 codebase will solidify Uniswap’s influence in the Ethereum ecosystem which is moving on to ZK rollups.

While the zkSync ecosystem is already experiencing very fast growth, the team is planning programs to attract and fund innovative projects and research partners to accelerate the network’s adoption and in turn, Uniswap’s usage.

License Exemption

We are requesting an exemption via an Additional Use Grant (license change enacted via the ENS domain uniswap.eth) that would allow Matter Labs to use the Licensed Work to deploy it on zkSync provided that the deployment is subject to Ethereum layer 1 Uniswap Protocol governance and control. Uniswap V3 will be deployed on zkSync by Matter Labs through the “Deploy Uniswap V3 Script” albeit we may need to modify the compilation step with approval from the Uniswap Labs team.

Timeline

Following the Governance Proposal we will be ready to move forward with the Uniswap V3 deployment on zkSync.

zkSync has been on testnet since February 2022 and plans to launch mainnet in October. A timely assessment of the deployment of Uniswap v3 code to zkSync is important: while deploying on zkSync is fast and easy because it’s fully EVM compatible, we estimate the full effort will take 4-6 weeks given Uniswap’s relevance. This allows for proper testing, communication to the community and engagement with the broader zkSync ecosystem.

18 Likes
2

Thanks for this write up!

A few clarifying questions on the bridge:

  • There are two default trustless bridges, one for ETH and one for ERC20 tokens. Do both of these bridges support arbitrary message passing? Which would be used for governance?
  • Can you include the proposed language for the License Exemption? And, could the License Exemption include stating bridge which would be approved in the proposal?
  • To restate your bridge security summary in other terms, the zkSync bridge inherits Ethereum’s base layer security, confirmed?

And for the sake of beginning to standardize cross-chain deployment proposals, would you mind answering the questions posed in this template here? At minimum for the bridge questions would be appreciated.

Thank you!

1 Like
3

GFX Labs is generally in favor of deploying Uniswap v3 to additional chains. The main question we have is regarding cross-chain governance. All deployments of Uniswap v3 are owned and controlled by UNI token holders on Ethereum. What do you have in mind for allowing Uniswap governance proposals on Ethereum to directly influence what occurs on the zkSync deployment of Uniswap v3? Will it follow the typical messaging framework as past Uniswap v3 deployments or something new?

1 Like
4

In huge support of this. zkSync will have a ton of activity on it, of course, and things like Argent w/ account abstraction will bring in new users that havent been exposed to crypto before. Uniswap should be the liquidity back end for this.

3 Likes
5

Thanks for your question. Our implementation would be consistent with approaches taken elsewhere (Polygon, Optimism) and would allow UNI token holders on Ethereum to control and push changes to the Uniswap deployment on zkSync.

4 Likes
6

This would be super interesting to see Uniswap on Zksync.

1 Like
7

Sounds good we’ll include those for the consensus check. To answer your questions:

  1. To clarify, there is a general L1<>L2 communication bridge which will support arbitrary message passing and will be used for governance. The ETH and ERC20 bridges provide an interface for depositing/withdrawing funds, not used for governance.

  2. We can include the “Deploy Uniswap V3 Script” for the License Exemption albeit we may need to modify the compilation step with approval from the Uniswap Labs team.

  3. Mostly true. Bridge validators can’t pass an incorrect message or change the content of the message, the worst case would be to censor everyone. Importantly, we’ll have these bridges audited by Tier 1 external auditors and have multiple points of security, including monitoring off and on-chain activity, generous bug bounty programs, etc.

8

Update: Moving on to the Consensus Check. Forum post above has been slightly updated to address a few points made above in the comments and reflect the next step.

1 Like
9

Glad to see that zkSync is active in clarifying the plans for deploying Uniswap V3 onto their platform. We are in favor of deploying Uniswap onto zkSync as it offers a faster and more cost efficient means of swapping cryptocurrencies. Also, the proposal will offer much more exposure to Uniswap V3 as a whole through offering the protocol on another secure network. If Uniswap V3 were to upgrade their protocol to V4, what would the transitional maintenance process look like and who would oversee it?

4 Likes
10

非常喜欢zksync 希望投票能顺利通过

11

Update: Moving on to the On Chain vote! Forum post above has been slightly updated to address a few points and update the timeline so far.

Please take the chance to check out the vote: Uniswap Interface

2 Likes
12

i really use ZKsync, and think this network is useful and very interesting. My up vote is for this proposal!

1 Like
13

Per our proposal we would communicate to the Uniswap community our modifications of the Uniswap-v3 contract which was audited by ABDK.

Uniswap V3 zkSync Era contracts changes

  1. v3-periphery/contracts/libraries/PoolAddress.sol:POOL_INIT_CODE_HASH. Hardcoded constant POOL_INIT_CODE_HASH was changed due to the different bytecode of compiled contracts on zkSync Era. It was also adapted for the 1.1.1 and 1.3.0 versions
  2. v3-periphery/contracts/libraries/PoolAddress.sol:computeAddress. The function was changed from the calculation of EVM address derivation to the zkEVM address derivation. It was also adapted for the 1.1.1 and 1.3.0 versions
  3. swap-router-contracts/contracts/libraries/UniswapV2Library.sol:pairFor. The function was changed from the calculation of EVM address derivation to the zkEVM address derivation. It should not affect anything, as V2 is unsupported on zksync.
  4. universal-router/contracts/modules/uniswap/v2/UniswapV2Library.sol:pairForPreSorted. The function was changed from the calculation of EVM address derivation to the zkEVM address derivation. It should not affect anything, as V2 is unsupported on zksync.
  5. universal-router/contracts/modules/uniswap/v3/V3SwapRouter.sol:computePoolAddress. The function was changed from the calculation of EVM address derivation to the zkEVM address derivation.
  6. Some import paths in permit2 contracts were changed due to the transition from Foundry to Hardhat. It will not affect the bytecode.

Uniswap V3 zkSync Era deploy script changes

  1. All the contracts repositories were forked, the build process was changed for zkSync Era, and some contracts were changed due to different address derivation.
  2. zkSync Era doesn’t support runtime library linkage yet, so the script was migrated to the hardhat. To the DEPLOY_NFT_POSITION_DESCRIPTOR_V1_3_0 step was added compilation to link NFTDescriptor library.
  3. Added factory dependencies to the deployment process. The script checks that for contracts any factory dependencies were not missed, for libraries, factory dependencies should always be empty.
  4. index.ts file logic was wrapped in the function, because now hardhat is the entry point and it calls this function.
  5. Types from the ethers were replaced with the types from the zksync-web3.

Tests

The repositories were migrated to the zksync hardhat plugins and the tests were adapted to work on zkSync Era. In order to run them, you should use the era-test-node.

3 Likes
14

Update on the above: we fixed #6 (meaning no actual change here anymore). Also to clarify for permit2/src/libraries/Permit2Lib.sol:PERMIT2. The permit2 address was changed due to different address derivation.

2 Likes
15

We would love to see Uni on zkSync, it’s time!