Dear Bankless Nation 🏴,

In this edition of the DeFi Download, we’re giving you the rundown on zkSync Era and Polygon’s zkEVM. We’re answering the following questions: How do ZKEVMs work? What are the different proving mechanisms? What is the outlook for the two earliest ZKEVMs on the market?

Afterwards we dig into the MEV-Boost hack and give you the latest project releases and Twitter takes.

This is the DeFi Download ⚡️

Contributors: BanklessDAO Writers Guild (Austin Foss, Jake and Stake)

This is the official newsletter of BanklessDAO. To unsubscribe, edit your settings.

Zero to One Knowledge: Comparing zkSync's Era and Polygon's zkEVM

Author: Jake and Stake

What are ZKEVMs?

ZKEVMs are rollups that strive to create a platform as close to the EVM as possible. They increase transaction throughput and reduce transaction costs by moving computation off-chain and using Ethereum as a data availability layer. 

Basically, transactions are executed off chain by rollup operators called “sequencers”. These sequencers generate proofs to show the transactions are correct and publish that proof to Ethereum. Publishing transactions to Ethereum is costly, but instead of publishing the entire collection of transactions, data and gas is saved by publishing a small proof.

This can be analogized to data compression. Imagine you have a library of songs you want to send to someone. Instead of copy and pasting your folder, you can compress it into a much smaller zip file and send that instead.

The compressed data submitted to Ethereum is a validity proof. This short cryptographic proof allows anyone to verify the correctness of the computation without needing all the transaction data. In fact, it’s better than our zip file analogy because proofs are the same size regardless of the number of transactions—O(1).

A ZK proving system is composed of two parts: on-chain contracts and an off-chain virtual machine.

On-chain contracts store blocks, track deposits, and monitor state updates. Particularly the verifier contract which validates zero-knowledge proofs submitted by the rollup’s sequencers. And an off-chain virtual machine that users submit transactions to. Rollup operators bundle these transactions and generate the validity proof that is submitted to the on-chain Ethereum contracts.

zkSync and Polygon have been in the news recently regarding their newly launched ZKEVMs (or at least their alpha versions). But how do they compare?

Similarities

Both are ZKEVMs in that they generate proofs of user transactions that are published to Ethereum L1. They mimic the transaction execution environment of L1 Ethereum. A ZK Rollup (ZKRU) is composed of three different parts:

• An off-chain sequencer that batches user transactions and publishes them to L1

• An on-chain contract that verifies the proof’s correctness

• An on-chain data store (usually Ethereum L1 smart contract)

Like optimistic rollups, users bridge their assets to the rollup contract by depositing their funds or using a third party bridge. Once these funds are settled in the contract, users are able to connect to the sequencer and generate transactions.

Users and developers submit transactions to the sequencer which bundles them and generates a proof that is verified by the on-chain contract for correctness. If the verifier contract doesn’t approve the proof, the state is not changed and the bundle is rejected.

Both are considered volitions. Volitions allow users to choose whether or not to publish data on Ethereum L1. zkSync has a data availability chain called zkPorter and Polygon has a data availability chain called Avail. The trade off is cost. If users want guarantees that their transaction inherits the security guarantees of Ethereum, they will volunteer to publish it to L1 at a higher cost. The aforementioned data availability layers have fewer security guarantees but cheaper costs.

A strategy that users might utilize is to publish their transactions to L1 every so often to create checkpoints, saving their transaction history in more permanent storage. This system can be analogized to general computing: committing transactions to Ethereum L1 is like “saving to disk” for long term storage and the data availability chains function as a “Memory Cache”.

Differences

Different ZKEVM schemes have different trade-offs. The more expressive and performant your computation, the more complex the required ZK system. 

ZKEVMs already exist, but are not general enough for EVM equivalence or are too slow to be used for production systems. Note that specialized hardware can increase the speed, but it also increases barriers to entry thus hurting decentralization.

Vitalik has outlined a method for categorizing ZKEVMs:

zkSync and Polygon’s zkEVM differ in two main ways:

• EVM compatibility

• How validity proofs are generated

EVM Compatibility

Starting with EVM compatibility, zkSync Era is language-level equivalent. It relies on compiling Solidity code to zkSync’s custom bytecode that is compatible with their ZKEVM using their LLVM-based compiler. This bytecode is optimized for generating ZK proofs (ZKPs) efficiently, resulting in shorter proving times and lowering barriers to become a prover.

The problem that zkSync faces is that the EVM was not designed to be ZK compatible so some things will be difficult to generate proofs for. For instance, the KECCAK256 function is not easily translated to ZKPs, so zkSync opted to replace this function with one of their own design. 

Basically, the generated bytecode is not the same as EVM bytecode. So, contracts may not have the same addresses and a lot of existing tools and infrastructure that rely on the EVM bytecode will break, limiting what can be deployed to zkSync.

However, because zkSync uses a custom VM, they can offer native account abstraction to users without the need for EIP-4337. And by leveraging the LLVM-based compiler, they can allow developers to deploy contracts in languages like C++ and Rust (coming soon ™).

The Polygon ZKEVM, on the other hand, is partially bytecode equivalent. As a result, a lot of infrastructure can be ported over and it’s fully compatible with most Ethereum applications. They’re partially bytecode equivalent because they omit operations that are hard to generate proofs for like hash functions and precompiled contract calls, but the tradeoff is that it’s fast to generate ZKPs, though not as fast as zkSync.

Polygon transforms the EVM bytecode into their own zero-knowledge Assembly language (zkASM) which is then used to generate their validity proof.

Proof Generation: SNARKs vs STARKs

zkSync uses a form of SNARKs called PLONKs to generate validity proofs with any type of circuit.

PLONKs require a universally shared secret that is generated through a trusted set up. This “common reference string” (CRS) only needs to be created once and can be reused for subsequent ZKP generation. The CRS is like a seed that creates the randomness needed to maintain security and has an O(1) security model. In other words, you only need one honest actor to ensure that the CRS is sufficiently random.

PLONKs are one of more battle-tested zk technologies (at the ripe age of 3 years old). zkSync has generated their CRS in collaboration with several prominent members of the crypto community like Vitalik.

While zkSync uses SNARKs, Polygon uses STARKS which do not require a trusted set up as they rely on hash functions, not a CRS. But STARKs are more computationally intensive, take longer to verify, and the proof is larger than SNARKS. So Polygon actually uses a combination of SNARKs and STARKs for their ZKEVM.

Polygon has their ZK Nodes generate a STARK, generates a SNARK to attest to the correctness of the STARK, and then publishes that SNARK to Ethereum. There’s quite a bit of nuance to how Polygon generates their proofs, but I’ll spare you the details of STARK recursion and Polygon “aggregators” for the sake of simplicity. Check out their documentation if you’re interested in learning more.

This mechanic reduces the cost of publishing validity proofs because STARKs are larger than SNARKs and the more data you publish to Ethereum the more costly it is. This 2-proof scheme is basically compressing transaction data into a small proof (STARK) and then compressing the proof even further (SNARK), reducing gas cost by over 90%.

Notably, zkSync doesn’t have a token yet, but Polygon has designed their ZKEVM with the $MATIC in mind.

Sequencers must pay a fee in the form of MATIC tokens for the right to propose batches of transactions, driving demand for the MATIC token. In return for their services, sequencers are rewarded with transaction fees paid by users.

Summary

zkSync Era has quickly accumulated an impressive $247MM in TVL since launch in March compared to only the $3.7MM in Polygon’s ZKEVM. This could be due to users interested in farming zkSync’s token. Because Polygon has already launched $MATIC, the incentives for using their zkEVM are not as clear.

Polygon and zkSync are both racing to put together the most EMV-compatible, production-ready ZKRU. And to be honest, the pace of innovation is staggering.

The L2 wars have begun and it’s clear that things are unclear. Arbitrum and Optimism still dwarf zkSync with $6.44B and $2.02B in TVL respectively. While some of this can be attributed to their token launch, I’d argue that there’s simply more things to do there. EVM equivalence matters and that’s why they have so much activity.

While there are clear advantages to ZKRUs, there’s no reason ORUs can’t develop their own solutions and chase down the front runners. They already have larger ecosystems and greater surface area to collect fees and drive development. The question is this: can ORU providers develop ZKRUs faster than ZKRU providers can get users?

I think it’s smart for zkSync to hold off on deploying a token. These crypto-based platforms are like campfires and a token is like a can of gasoline. Deploy a token before you have sufficient projects and users, and your fire will burn bright, then fast, then small. But waiting to get organic adoption through projects and users is like collecting wood. Your fire will burn at a steady rate until you’re ready to step on the gas and deploy your token.

Because tokens are a one-time thing. Projects that have to deploy a V2 token are usually already dead.

Action Steps

📖 Read zkEVMs: The Future of Ethereum Scalability | Galaxy Digital

⛏️ Dig into The different types of ZK-EVMs | Vitalik

🎧 Listen zkSync Era Mainnet Launch | Bankless Shows

🎧 Listen Polygon zkEVM Launch | Bankless Shows

Exploiting MEV-Boost

Author: Austin Foss

Maximal extractable value (MEV) is a ruthless game for all those who chose to play; unfortunately, it also poses a risk to users who didn't choose to play -- ruthless.

Average users understandably can have a negative view of the practice as a whole, prompting some ideas to be proposed like MEV burn that would take away much of the economic incentive from these MEV bots and their operators. Last year, The DeFi Download covered a "Karma Case Study: The Tale of 0xbad", by Elemental, where an MEV bot named after it's Ethereum address that had exploited an unknowing user for nearly 1.8M USD through an arbitrage opportunity; initially earning themselves 800 ETH. Later that day, 0xbad was hacked for more than 1100 ETH who then tried demanding their ETH be returned, to which the hacker replied "What about normal people who you have mev'ed and literally fucked them?"

In another article published by Halborn Security, the author Rob Behnke, referred to this kind of behavior from MEV bots as a "... parasitic exploitation of other blockchain users..." MEV is not well loved in no small part because of how ruthless these bots can be to average users. Participants in MEV can be equally ruthless to other participants who know full well what they're getting into as demonstrated by an exploit that happened at the start of April.

MEV on MEV Aggression

At 11:29 PM UTC, block number 16964664, a malicious proposer, a validator who's turn has come to propose a block, took advantage of a bug in the software used to run mev-boost compatible relays. MEV-boost is a protocol, and different relays can participate using different clients — analogous to the different Ethereum clients that all speak the same protocol (geth, besu, erigon, etc.).

From a post mortem published by the Flashbots team about two days after the incident the author, Bert Miller, reported that this exploit was made possible by "a vulnerability in the majority of mev-boost relays (mev-boost-relay, Dreamboat)..." What went wrong in this case was that "Crucially, regardless of whether the block was rejected by beacon nodes or not, the relay would still reveal the body to the proposer."

Between the block builders and proposers sits the relays whose role is to hide the contents of the block from the validator until the validator has committed to proposing the block. If the body is not hidden from the proposer then the builder's MEV can be stolen by the validator proposing the block.

When this malicious validator signed/proposed the relay's modified, invalid, block the relay would still reveal the block's body to the proposer who could then build a new block, selecting and reordering transactions for their own profit -- resulting in a profit of 20-25M USD for the proposer.

Recourse

Unfortunately for this kind of exploit, there is almost no form of recourse; and if there were a way, who would be the parties who suffered damages? As we saw at the start, sentiment towards MEV bots in general is not particularly favorable. In the block that was validated were several transactions sending funds to five individual MEV bots. Were they good actors taking advantage of a profitable trading strategy or blackhats that have taken funds in the manner we saw 0xbad conduct their MEV practice?

Certainly Flashbots cannot be held accountable by the MEV bots for the unintended bug in their relay software since it is published under the AGPL-3.0 license without warranty or liability. Could Flashbots go after the attacker for exploiting their software? Not likely as they would not have been the ones damaged by the exploiter nor the ones operating that particular relay.

From the same post mortem Bert explained that the relay in question that was "exploited" was the Ultra Sound Relay. Potentially the team behind UltraSound.money could have had standing to pursue damages if the exploit required the attacker to have access to the system the relay was running on, but by the description of this exploit and the patch that was implemented, having access was not required.

https://twitter.com/zenith_owl/status/1642867903874646016?s=20

So with the classification of this incident in question and no path for any legal recourse even if any of the MEV bot operators wanted to, should the validator who proposed the malicious block be punished at all? Well yes, they were in a sense. After exploiting the mev-boost-relay software for tens of millions worth of USD their validator was slashed for just 1 ETH (~1800 USD at the time). This was because the validator still had to sign an invalid block header derived from a modified block originally retrieved from the relay, fulfilling one of the conditions for which they could be slashed.

PROOF-OF-STAKE REWARDS AND PENALTIES

• By proposing and signing two different blocks for the same slot

• By attesting to a block that "surrounds" another one (effectively changing history)

• By "double voting" by attesting to two candidates for the same block

Since the exploit the Shanghai upgrade has taken place which has allowed the operator behind this malicious proposer, dubbed Sandwich the Ripper on Etherscan, to since exit the beacon chain with their remaining 31 ETH.

Implications

Given the opportunity, a malicious actor will not hesitate to act in their own interests, even in the face of the best interests of the network and a 1 ETH slashing penalty. In the end, economic incentives must continue to be relied upon to ensure it is not profitable to compromise the credible neutrality of the network.

Project Releases 🎉

Hand-picked updates to help you understand the current state of the DeFi ecosystem

OpenSea Pro is live

• OpenSea’s NFT aggregator OpenSea Pro is now live

• Geared towards OpenSea power users

• Sweep across NFT marketplaces

https://twitter.com/openseapro/status/1643314687134556160

MetaMask adds “Buy Crypto” feature

• New fiat on-ramp that allows users to buy crypto assets in the MetaMask extension

• 90+ tokens available across 8 networks

• 189 supported countries across 8 different networks, including L2s

https://twitter.com/MetaMask/status/1645446587131346946

MakerDAO approves Coinbase Custody Vault

• Move 500 million USDC from PSM to Coinbase Vault (RWA014)

• MakerDAO will earn 2.6% annually on USDC calculated monthly

• USDC will be held in cold storage

• Maker can access USDC within 24 hours of withdrawal request

https://twitter.com/MakerDAO/status/1649117864086097920

Chirping Birds

🔥 and 🧊 tweets from across the DeFi ecosystem

BANK utility (BanklessDAO token)

With over 5,000 holders, BANK is one of the most widely held social tokens in crypto. So it bears asking, where are the best places to put our BANK to use? The five protocols below will allow you to deposit BANK in a liquidity pool and earn rewards. To get going, just click on the name, connect to the app, filter by BANK, and start earning passive income.

BanklessDAO 🏴 @banklessDAO

Resident tokenomist @ffstrauf turns inward, analyzing BanklessDAO's $BANK token and showing us how a movement becomes an incentivized community of buidlers (Cov @dippudo)

medium.comTokenomics 101: BanklessDAOHow a Movement Becomes a Tokenized Start-up Incubator...

2:38 AM ∙ Apr 7, 2022

---

49Likes17Retweets

⚖️ Balancer

Balancer has two 80/20 liquidity pools, meaning that you are required to deposit 80% BANK and 20% ETH in the pool. There is one pool on Ethereum and another on Polygon. Once you’ve provided liquidity, you’ll receive LP tokens. Keep an eye out for opportunities to stake these LP tokens. There is nearly 500,000 USD in the two Balancer liquidity pools.

🍣 SushiSwap

SushiSwap has a 50/50 BANK/ETH pool. As with Balancer, you will receive LP tokens, and while you can’t stake them on SushiSwap’s Onsen Farm yet, you may be able to in the future. Liquidity providers earn a .25% fee on all trades proportional to their pool share. The SushiSwap pool has a little over 100,000 USD in liquidity.

🦄 Uniswap

The Uniswap V3 liquidity pool is 50/50 BANK/ETH, and provides a price oracle for the Rari Fuse Pool. By depositing in the Uniswap pool, you can earn fees and help enable borrowing on Rari. This pool currently has over 500,000 USD in liquidity.

🪐 Arrakis

You can also provide liquidity to the Arrakis Uniswap V3 pool. The ratio is about 2/1 BANK/ETH. This pool is new, and only has a bit more than $6,000 in liquidity. In the future, you may be able to stake your BANK/ETH LP tokens within the protocol to earn additional rewards.

Share