Weekly Rollup #2

For the week ending February 17th

Welcome to Modular Media, a weekly newsletter covering news, updates, educational content, and more within the modular ecosystem.

Subscribe to get issues sent directly to your email every Tuesday, and also, make sure to follow us on Twitter for daily modular updates!

You can check out our previous newsletter issue.

News and Announcements

zkSync launches zkEVM - fair onboarding phase begins

Last week, zkSync caught everyone by surprise after officially launching the first zkEVM on mainnet.

As you may already know, ZK-rollups are thought to be the holy grail of blockchain scaling. StarkWare was the first team to deploy a general-purpose ZK-rollup, however, it’s built using their own custom, native programming language, Cairo (as opposed to Solidity). zkSync on the other hand, natively supports the EVM (EVM compatible), and Solidity enabled, which makes it easy for developers to port their existing Solidity code to zkSync.

To be specific, February 16th marked the launch of the network’s fair onboarding phase, allowing all registered teams to start deploying on the zkEVM. Mainnet will remain closed for users during this phase, allowing teams to test their projects in a closed environment. This phase is expected to last 4-6 weeks, and assuming everything goes well, the Full Onboarding phase will begin soon after.

Aside from this, zkSync also announced:

  • their now fully open sourced, allowing anyone to view, modify, and fork the code (although, it’s highly recommended to avoid forking until full onboarding phase)

  • zkSync2.0 is now zkSync Era

Some of the projects that have already announced their upcoming deployment on zkSync’s zkEVM include: Aave, Uniswap, 1inch, Curve, Chainlink, Ramp. Hop, Hashflow, and Juno.

The zkSync team will be posting their new roadmap and milestones soon, so make sure to follow them on Twitter so you don’t miss that.


35-C testnet is now live

This past week, Dymension officially launched their Dymension Hub testnet, 35-C. 

As a recap, the Dymension Hub is a Proof of Stake blockchain that acts as the settlement layer for the entire Dymension ecosystem. Builders can then launch their own dedicated RollApps, or execution environments, on top of this settlement hub. 

As of today, there is one RollApp deployed on the testnet, RollApp X, which was launched by the Dymension team shortly after the hub’s launch. Anyone interested in playing around with the testnet can go into the community discord and request tokens from their faucet, which can then be bridged into RollApp X for staking. Once the team determines the network is stable enough, they’ll deploy two more RollApps on top of the hub, an EVM RollApp, and a CosmWasm RollApp. 

You can learn more about the Dymension testnet here.


Introducing Modular Cloud

Last week, we saw the launch of a new modular project, Modular Cloud. The first product they released is Explorer, a block explorer built specifically for modular blockchains. 

As you may already know, a block explorer is a tool that allows users to dive into specific transactions, blocks, addresses, and more. The most popular example is Etherscan. However, what separates Modular Cloud’s Explorer from Etherscan and the rest is that it’s specifically made for modular chains. 

A modular blockchain separates the different components that make up a blockchain into multiple layers, rather than doing everything on the same one, as with your typical monolithic chain. 

Let’s take Dymension (mentioned above) as an example. As of today, the Dymension ecosystem consists of three different layers: RollApp X (the execution environment), the Dymension Hub (settlement layer), and Celestia (data availability layer). When a user submits a transaction on RollApp X, they’ll be able to see in which rollup block that transaction was included, which block that transaction settled on, as well as which DA block the original transaction was included in. 

As of today, the only networks that are integrated into the modular explorer are Celestia, Dymension, and Eclipse, however, they’ll soon be launching an automated integration tool so that any execution, settlement, or data availability solution can easily integrate their network within the modular explorer. For now, if any modular solution wants to integrate their network into Explorer, you cn reach out to the team.

Aside from this, the team will also be releasing “visualization of the transaction flow through all layers of the modular stack and paid cloud services in the future. 

You can learn all about this new modular block explorer here.


Caldera announces $9M funding

Last week, Caldera announced their $9M raise, in a round that was led by multiple big-name firms, including Sequoia, and Dragonfly. 

According to the team, the funds will be used to “rapidly accelerate the development timeline”, as well as to hire more team members in order to strengthen their core product, and to improve the UI.

This funding round came just a week after Caldera announced the launch of Spark, a testnet version of their no-code deployment platform that allows users to launch their own rollup in just one click. You can learn more about Spark here if you’re interested. 

As a reminder, Caldera is an EVM-based, rollup as a service provider, allowing any team to spin up their own individual, custom rollup.


More News & Updates


Discussions and Education

The first zkEVM on mainnet

The Polygon and zkSync announcements spark a series of back-and-forths between project teams. As usual, the debates implicitly center around which rollup is “the first zkEVM”. This time, the focus is on provers:

One thing left without clarity is which ZK protocol Polygon will use - Groth16 (used by zkSync) or FFLONK. We don’t need to get into this very esoteric topic, but it matters which one they pick. Groth16 requires a “trusted setup” and FFLONK does not. On the other hand, FFLONK might bring more risk.


Privacy and upgradability for ZK L1s vs. L2s

Brendan Farmer (Polygon ZK) makes a case against ZK L1s and for ZK L2s. Before Polygon, Brendan worked on a ZK L1 himself, making him a credible person to speak on the topic. His main arguments are:

  • Recursion makes the cost of verifying ZKPs on Ethereum not a practical problem

  • Upgrading ZK L1s is really hard

ZK teams from L1s like Mina Protocol / Aleo mostly disagree with his upgradability argument. They offer potential upgradability solutions which Brendan acknowledges.

There doesn’t appear to be a simple answer here - at least not yet. ZK L1 upgradability is possible, but hard. There are solutions, some more practical than others, and all with tradeoffs.


Rollups posting different types of data

DinoEggs here 👋 This question is posed by yours truly, with the goal of understanding why different rollup teams might post different data types on L1. The different types are:

  • Transaction data

  • State diff data

To be clear, this decision is unique to ZK rollups (due to the ZK part). Since they can prove state transition validity without revealing transaction data (inputs), they can get away with only posting compressed data about state changes (outputs).

At first glance the answer seems obvious - post state diffs since it’s cheaper - but my question is whether there are tradeoffs and good reasons to post transaction data. A few key advantages stuck out:

Are there mechanisms to get the best of both worlds? Alex (zkSync) says yes.


More Discussion & Education

That's all for this week! Thanks for reading 🧱🎬

Loading...
highlight
Collect this post to permanently own it.
Modular Media 🧱🎬 logo
Subscribe to Modular Media 🧱🎬 and never miss a post.
#weekly rollup
  • Loading comments...