Weekly Rollup #21

👋 Welcome to Modular Media! We cover news, updates, educational content, and more within the modular blockchain ecosystem.

Subscribe to get posts sent directly to your email every week, and follow us on Twitter for modular-related updates!

This week’s issue covers:

  • Introducing the ZK Stack

  • Polygon Unveils 2.0 Architecture

  • Froopyland: Dymension’s First Incentivized Testnet

  • More News & Announcements

  • Will rollups outsource ZK proving?

  • Do optimistic sovereign rollups make sense?

  • More Discourse & Education


Modular Cloud is reimagining developer tools and cloud services for the modular blockchain stack. Get in touch to learn more about Modular Cloud's product offering today, including the world's first block explorer for modular blockchains.


📣 News & Announcements

Introducing the ZK Stack

Last week, zkSync announced its ZK Stack, a modular framework that developers can use to build “custom ZK-powered L2s and L3s (referred to as Hyperchains), based on the code of zkSync Era”. In other words, the ZK Stack provides teams with the tools and infrastructure they need to build their own zkSync-like network, but for their own specific use case.

This year, we have seen the top Ethereum L2s announce their own modular framework to expand their own ecosystem’s network of rollups. There’s Arbitrum Orbit, Optimism’s OP Stack, Polygon 2.0, and now the ZK-Stack.

Customizable Components

Using the ZK Stack, developers will be able to customize several different components within their own rollup, including:

  • Data Availability (DA): whether you want to have a full-scale zk-rollup and have your data posted on Ethereum, or whether you prefer a validium solution that posts its data on a separate network, such as Celestia, Eigen DA, or zkSync’s own zkPorter.

  • Sequencer: teams will have the option to either have a centralized or decentralized sequencer solution for their specific rollup. Don’t want to share a sequencer with other apps? Use a centralized solution. Want to provide maximum decentralization? Use zkSync’s soon to launch (on public testnet) decentralized sequencer solution.

  • Tokenomics: use your own token for gas on your rollup, to stake for your centralized sequencer, etc.

& more.

Sovereignty, Seamless Composability & Account Abstraction

Aside from these customizable components, there are a couple of features each rollup will get to benefit from right out-of-the-box, including network sovereignty, seamless connection to the rest of the Hyperchain ecosystem, and native account abstraction to improve the end-user experience.

Put simply, being a fully sovereign Hyperchain means your network is not defined by whatever zkSync says - networks have independent control and can push network upgrades or respond to hacks without waiting on approval from anyone. Also, it means you can take your Hyperchain and leave to a different ecosystem if you ever disagree with zkSync’s direction.

zkSync envisions a large network of Hyperchains, and if this is going to be the case, then connectivity between each Hyperchain is essential. As a user, you shouldn’t have to go through several different steps in order to go from one appchain to another. Connectivity should resemble the internet; you just click a link and you’re wherever you want to go. Within the zkSync ecosystem, every Hyperchain will have seamless composability with one another. So as a user, you won't have to bridge to a different network, utilize extra capital, or make any additional trust assumptions in order to perform a cross-chain transaction. This is all done within a single transaction from a user’s perspective.

Aside from seamless composability, teams, and end users will be able to take advantage of zkSync’s native account abstraction. As a reminder, account abstraction allows developers to adjust their payment structure, thereby improving the user experience. For example, you could increase the end-user’s security by allowing him/her to sign for transactions using biometrics (faceID, etc.), remove gas fees altogether for end-users by subsidizing them using some of your earned revenue, and much more.

So who will Hyperchains be for?

While it doesn’t make sense for every single app to have its own dedicated rollup, it may be useful in certain scenarios, including:

  • when you need to add your own unique chain customizations

  • apps that don’t want to share a sequencer with others: fast & efficient sequencing

  • high-frequency defi apps like DYDX

  • enterprises that want chain privacy while still being connected to the broader ecosystem

What’s Next

The zkSync team will publish deep dives over the following weeks to give the community a further understanding of the ZK Stack. You can find several links down below to learn more about ZK Stack if you’re interested!

Polygon Unveils 2.0 Architecture

This past week, the Polygon team unveiled their proposed architecture for Polygon 2.0, which is “designed to provide unlimited scalability and unified liquidity, and realize the vision of Polygon as the Value Layer of the Internet”.

The Scaling Problem:

Polygon 2.0 intends to address the current challenges faced by web3, where the addition of new chains leads to liquidity fragmentation, as well as a subpar user experience. For example, it aims to resolve the trade-off dilemma faced by users who must currently choose between different liquidity pools on various platforms - “Do I want to LP on Polygon PoS, or on Polygon zkEVM?”. This architecture consists of four protocol layers, each serving a distinct purpose, enabling seamless coordination and facilitating future upgrades. This modular approach allows for continuous enhancement and optimization of individual layers to keep pace with emerging innovations.

These four protocol layers in Polygon 2.0 include the Staking Layer, Interop Layer, Execution Layer, and Proving Layer.

Staking Layer

The staking layer is a PoS based protocol, that “leverages Polygon’s native token to provide decentralization to participating Polygon chains”.

Polygon sees a future in which many networks will be running under the Polygon ecosystem (appchains everywhere), and this is where “restaking” comes in. Rather than having each of these networks take the time to grow a decentralized validator network, they will be able to leverage Polygon’s existing set. In return for the validator's services, they are rewarded with different Polygon tokens, as well as having the potential to earn extra revenue through transaction fees and token rewards from the chains they validate. According to a recent Twitter Space, users like you and I will be able to stake our MATIC to take part in some of the components mentioned below, including the aggregator and prover.

Interop Layer

If Polygon intends to have all these chains across its network, then they’re going to need a way to seamlessly communicate with one another, and that is where the interop layer comes in. According to the team, users will be able to access any Polygon app from whatever Polygon chain they are on. This interop layer will enable (1) a shared bridge with Ethereum, meaning no more tons of variations of a single token, and (2) seamless composability, which means “near-instant and atomic cross-chain transactions”. It will all “feel like a single chain”.

This interop layer will be enabled by the use of zk-proofs, which will be handled by Polygon’s newly proposed “aggregator” component. This aggregator will be responsible for accepting zk-proofs and messages, as well as aggregating all these zk-proofs into a single proof to be posted on Ethereum (reducing to 1 single proof lowers fees of course).

Execution Layer

“The Execution Layer enables any Polygon chain to produce sequenced batches of transactions, aka blocks”. This is where the Polygon validators and nodes interact with one another in order to exchange messages, reach a consensus on a single chain of blocks to follow, and more.

Proving Layer

Finally, we have the proving layer, which consists of a single, common prover that generates the proofs for all transactions on every Polygon chain. Whether a developer wants to use the zkEVM, MidenVM, or construct their own state machine, Polygon 2.0 intends to support all three.

What’s Next

Over the following weeks, the Polygon team will be sharing further details about each of these layers with the community. You can follow them along on Twitter if you’re interested.


Froopyland: Dymension’s First Incentivized Testnet

Last week, the Dymension team published their first details about “Froopyland”, their first incentivized public testnet which is intended to launch soon.

Frooopyland Details

$DYM, which is Dymension’s own native token, will have a total supply of 1 billion. Throughout this Froopyland testnet, 1% of that (10M DYM) will be distributed to rollup deployers, validators, users, and the top 10 performing Dymension rollups, as follows:

  • Rollup Deployers (4M DYM): deploy a rollup, and win rewards proportional to that rollup’s uptime. You must hold the “RollApp fam” role on their Discord server to be able to launch a rollup during this testnet.

  • Validators (4M DYM): Those of you who help keep the network running by managing a Dymension Hub validator, will earn rewards “proportional to the uptime of the validator and the RollApp your team deploys”. Yeah, you’ll have to deploy a rollup.

  • Users (1M DYM): End-users like you and I can visit the Dymension portal, take a look at the different rollups launched on the Dymension Hub, and start interacting with these to earn DYM rewards. That said, this is exclusive for those with the “Rollapes” Discord roll.

  • Best 10 Rollups (1M DYM): The 10 best performing rollups, in terms of uptime and user activity I would assume, will earn from this reward pool. Of these top 10, the more active your rollup is, the more DYM you get.

35-C

As a reminder, today Dymension is running a non-incentivized testnet, 35-C, which launched back in February. 35-C introduced the genesis launch of the Dymension Hub (the ecosystem’s own settlement layer), along with two rollups, RollApp X, and EVM RollApp. Although as users we were able to interact and stake with these two rollapps, developers were not able to launch their own (permissioned rollup deployment). So, we’re excited to see the different rollapps developers launch on Froopyland.

Here are some of the numbers 35-C was able to achieve across the two rollapps:

What’s Next

Make sure to follow Dymension on Twitter to find out when Froopyland launches. Also, incase you haven’t noticed, it looks like it pays to join the team's Discord.


More News & Announcements


📚 Discourse & Education

Will rollups outsource ZK proving?

Hasu from Flashbots asks validity rollup teams how they think about internal vs. external prover networks. To be clear, he is not referring to whether or not a rollup prover network is permissioned vs. permissionless. A permissionless prover network would fall into Hasu’s “internal” category. An example of an external prover network would be a third-party marketplace, where neither the rollup core team nor community has to run any provers.

It’s likely that established rollups with large user bases will operate their own internal prover networks, both to keep control of early-stage ZK technology and for greater token utility / value capture. It’s of course possible that this changes as ZK technology and external proof markets mature and specialized vendors emerge.

To gain more familiarity with the emerging ZK proving space, we highly recommend this new post by Trace from Figment Capital.


Do optimistic sovereign rollups make sense?

Eric Wall claims that optimistic sovereign rollups make no sense since light nodes have to wait 7 days to reach finality.

While it’s true that in practice optimistic rollups have 7-day challenge periods, they are not technically required to do so. It’s worth understanding why this decision is so often made - to learn more about the 7-day justification we recommend this post by Kelvin from OP Labs.

The next thing to note is that the sensibility of optimistic sovereign rollups does not depend on the usefulness of their light nodes. For all rollups - sovereign, settled, optimistic or ZK - finality is reached when the transaction data finalizes on L1. This is because anyone can run a rollup full node and compute state transitions using the finalized input data. The real bottleneck for optimistic sovereign rollup finality is the data throughput of the underlying L1, which could be optimized down to minutes or even seconds.

There are also other approaches being considered, such as signaling fault across the p2p layer. This will be very interesting if it works for L2s and L1s alike, but it could be hard.


More Discourse & Education


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

If you found this issue useful, please share this tweet so more people can see it.

Subscribe to Modular Media
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.