Begin Preparation for ZkSync v2.0 Deployment

Summary

My Proposal is to deploy a testnet to zksync v2.0 testnet, and begin preparing to deploy to the zk vm at launch.

Abstract
As the L2 ecosystem of Ethereum booms, zksnarks hold a strong proposition for scaling as a secure solution that relies soley on math, with quick exit times. Uniswap V2 Based DEXes have been recently proven via UniSync and I think having Sushi on the Zksync ecosystem early would be a valuable addition.

Motivation
I really like zksnarks, they are an amazing technology, and seeing Sushi only being on Optimistic Rollup based L2s makes me sad, having it on both technologies I think would be amazing for those who want to take advantage of quick exit times, or want the piece of mind of zksnarks.

Specification
Deploy Sushiswap and Kashi to Zksync 2.0 testnet
Testing then begins on Zksync 2.0 to ensure the protocols function on the zkvm as expected
Sushi team begins working with Zksync’s team to deploy in parallel with the Zksync vm 2.0

For
So first deploy Sushiswap and Kashi onto the Zksync 2.0 testnet, and conduct testing with users to ensure everything is running smoothly and the transpiler has prevented any errors. Sushi then works with zksync to be one of the first projects to deploy to zksync 2.0 when it releases, and Sushi Token emissions then also occur on zksync as well.

Against
Nothing

This proposal is still immature, but was hoping to get some community thoughts to help flesh it out, and build it out taking into account community concerns.

Poll Options if I could make polls

  • Yes Move to Zksync 2.0 Testnet and prepare for Launch with Zksync 2.0
  • Launch on Zksync, but wait for migration until after launch of Zksync 2.0
  • Do not launch on Zksync
3 Likes

Here is the poll for above post:

  • Yes, Move to Zksync 2.0 Testnet and prepare for Launch with Zksync 2.0
  • Launch on Zksync, but wait for migration until after launch of Zksync 2.0
  • Do not launch on Zksync

0 voters

3 Likes

@ControlCplusControlV this seems to be a great next step for scalability of Sushi.

ZK rollups - particularly ZKSync - has provided value add for major protocols such as Aave, Curve, and 1inch. I am curious to see how it can benefit Sushi in terms of speeds, and as you say, allow to

Besides speeds - what is the Gas impact of ZK technology? This chart provided on ZKSync’s website notes the benefits over optimistic rollups but seems to be 2x the cost of SNARK-based rollups.

Reflecting on the Sushi UX, I am not quite sure exit times are the biggest impediment. SushiSwap attracts a diverse group of retail investors who value a turnkey product suite. How does ZKSync fit into this vision? Furthermore, what is the cost to the protocol or dev team for this technology?

As Sushi implements more products how will the dev team be impacted by this change? Will the speed of deployments be affected? If so, this may be best to delay the proposal.

I am aware of the need for ZK technology (over optimistic rollups) for quicker speeds, cheaper transactions, yet hope to understand the choice for this specific infrastructure. Would releasing on another L2 such as Optimism hope solve these problems?

UniSync: the first live zkEVM dapp! seems to be a lite version of Uniswap, with a simplified UI/UX and limited pairs (WBTC,USDC, LINK, & DAI.) Would the Sushi build have similar limitations?

Curious to hear you thoughts and to continue to build the future of Sushi together.

3 Likes

https://l2fees.info/ should give you an idea of the gas, I am not sure on SNARK based rollups as a lot of this is still new and relatively untested.

How does ZKSync fit into this vision? Furthermore, what is the cost to the protocol or dev team for this technology?

Zksync adds value in bringing many of its services like NFTs, where customers still want to use ETH, but can decrease gas costs when buying their tokens (atleast after core products are tested on zksync.) The use of other tokens as fee tokens also provides lots of flexibility to Sushi users, and I think adds a lot of value to their trading experience (can’t be stranded anymore and need to buy gas tokens to sell their current tokens)

As Sushi implements more products how will the dev team be impacted by this change? Will the speed of deployments be affected? If so, this may be best to delay the proposal.

So zksync requires a slightly different transpiler, but it still uses Solidity with some minor limitations like no unbound loops (horrible practice anyway). It requires minimal transfer time given value added, and I think it won’t add any significant delays to deployments. As the transpiler improves it may be no different at all then deploying to EVM based chains, but as of now its the same code, and if they are writing thorough tests (which they are) then they can verify the transpiled version will deploy without any further issues.

Would the Sushi build have similar limitations?

I think they’re limitations were due to developing the transpiler in parallel with their demo, limited pairs has to do with the setup of their test demo and not with the actual l2 itself. That being said this proposal seems to have community interest so I am working on fleshing that out right now, and finishing some research into Sushi deployment onto zksync

3 Likes

I think from a fee perspective ZkSync v2.0 is very transformative and we should be pushing to be at the forefront.

2 Likes

支持 :笑着: zksync 未来会是一个很厉害的L2的项目 可以布局

@ControlCplusControlV curious what your research brings, I think this presents a massive opportunity for Sushi!

[🍣 zkEVM Sushi Deployment 🍣 - HackMD](This HackMD) is where I have began formulating things. Trying finish up a lot of the reasoning and outlining what this technically means before proposing on snapshot!

2 Likes

zk enables transactions at large size for very small cost, which I find particularly interesting for institutional investors