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 modular-related updates!

You can check out our previous newsletter issue here.

📣 News & Announcements

Obol Labs Launches Alpha Release

Last week, the Obol Labs team announced the launch of their Alpha release, meaning that for the first time, community members will get to deploy mainnet distributed validators (DVs).

Up until now, the protocol has only been used by people within the Obol team, but this alpha release starts the teams’ process of progressively integrating the Obol protocol into actual staking applications.

To make sure everything is running smoothly, DVs will initially only be launched with trusted partners, however, this will open up to others over time, as we approach Obol’s mainnet launch.

According to the team, they look to add 25 DV clusters in two types of configurations:

Solo Clusters: one entity running all nodes within a cluster. initial solo staker partners include Anthony Sassano, Blockscape, Ankr, and more.
Multi-org Clusters: two or more entities are running nodes within the cluster. Initial Multi-Org Cluster partners include EtherFi, DSRV, Cosmostation, and more.

What is DVT?

As you may already know, anyone from around the world is able to run a validator node and stake their $ETH in order to become an Ethereum validator. The reward for doing so of course, is a combination of network fees (gas fees) and block issuance (newly minted ETH).

That said, running an Ethereum validator comes with a huge risk - your stake. In order to make sure validators are doing their job correctly, they must put their ETH at stake. If a validator node was to start acting maliciously, or if the validator node was to go offline for a certain amount of time (even if it was through no fault of the validator themselves), then they could get slashed (your ETH stake deposit goes bye bye).

Today, we’re accustomed to having every validator run by a single node, but distributed validator technology (DVT) enables a validators to be run by 2-4 different nodes (not just one).

So for example, today, you may be running an Ethereum validator on your own computer. This means that your computer has to stay online 24/7 in order to make sure you’re doing your job to help verify the network. If your computer goes offline for a long period of time, or if it experiences some sort of bug, then you run the risk of losing your initial ETH deposit (stake).

DVT works by running validators within clusters of people (a cluster can be anywhere from 2-4 people). So rather than me running my own validator, I can pool my resources with up to three others in order to form a cluster and run our own validator as a team (“squadstaking” seems to be the winning term to use). The benefit of DVT is that if the validator node you’re running were to go offline, you won’t get slashed - all you need is 3/4 of members within the cluster to be online at any one time.

How does DVT benefit me?

Over time, we should start seeing liquid staking protocols like Lido and Rocket Pool integrate DVT into their platform. So not only will you not be required to hold the entire 32 ETH, but you also won’t have to run the entire setup yourself.

That’s for those of you who wish to run your own validator node, however, there’s also a huge benefit for those of you that wish to continue just delegating your ETH to someone else. Today on Lido, for example, we delegate our ETH to someone else who runs the validator node. The risk to depositors is that if the validator you delegate your stake to was to get slashed, then that means you potentially lose your deposit as well (your deposit adds to the validator’s stake). With DVT however, the validator is split between different nodes (could all be from different places around the world), meaning depositors are ultimately putting their deposit at the hands of 2-4 individuals, rather than just one, ultimately increasing security for the end-user deposits.

There’s of course a lot more that can be said about DVT, but we’ll leave that for another time.

What’s Next

As mentioned, this initial Alpha release is intended for only a limited amount of users, as the Obol team looks to make sure everything is running smoothly before opening up their protocol to the broader community. The purpose of this Alpha release is to learn from this initial release, and add any necessary changes before their v1 launch (hopefully later this year).

You can visit the Obol website to learn more about the protocol. If you have any specific questions for the team, you can head over to the project Discord and ask away there.

Introducing Magi & OP-Erigon

Last week, the Optimism community saw the launch of two new network clients, Magi and OP-Erigon.

What are clients?

Generally speaking, clients are the actual code implementation of network rules. Let’s use Ethereum as an example.

As most of you already know, Ethereum is like one giant supercomputer.

This giant supercomputer follows a set of rules, or “specifications” (specs), which dictate how the network functions. Every node that connects to the network has to follow these specs - this is where the “clients” come in. The clients are the actual code implementations of these specs.

In regards to Ethereum, there are two types of clients, execution clients, and consensus clients. execution clients listen to incoming transactions and execute them in the EVM, while consensus clients implement the PoS algorithm (Beacon chain). This means that in order to become a node, you must run both of these clients.

There can be several variations of clients, each offering certain tradeoffs. For example, in Ethereum there are four execution clients (Geth, Nethermind, Besu, and Erigon), and five consensus clients (Lighthouse, Lodestar, Nimbus, Prysm, and Teku). Each client can vary in the programming language (is the client code written in Rust or Python for example), or in the amount of hardware power that is required.

How does Optimism fit in

“With Bedrock, the OP Stack leans heavily into the technical separation of concerns specified by Ethereum by mirroring the separation between the Ethereum execution layer and consensus layer. Bedrock introduces separation of execution client and rollup node in this same way”.

Similar to Ethereum, in order to connect to the Optimism network, you need to run two types of clients, an execution client, and a rollup client.

According to the official Optimism docs, “an execution client is the system that sequencers and other kinds of node operators run to determine the state of the canonical L2 chain. It also performs other functions such as processing inbound transactions and communicating them peer-to-peer, and handling the state of the system to process queries against it”.

While a rollup client communicates to the execution client and more specifically, “the rollup node is a stateless component responsible for deriving the state of the system by reading data and deposits on the L1. In Bedrock, a rollup node can either be used to sequence incoming transactions from users or other rollup nodes or to verify confirmed transactions posted on the L1 by singularly relying on the L1”.

Up until last week, there was only one type of client each, and both were developed by the OP Labs team (the original team behind the development of Optimism).

On the execution client side, there was only op-geth, which was a fork of Ehereum’s geth client, which is a Go (programming language) implementation of the network, however, now we also have op-erigon, which is a fork of Ethereum’s erigon client.

On the rollup client side, there was only op-node, which again, was developed by the OP Labs team, and is written in Go. However, now we also have Magi.

Magi

On April 19th, the a16z team announced Magi, a new rollup client for the Optimism community. According to the a16z team, “Magi performs the same core functionality as the reference implementation (op-node) and works alongside an execution node (such as op-geth) to sync to any OP Stack chain, including Optimism and Base”.

Up until now we only had one rollup client for Optimism, op-node, which was written in Go. Magi is written in Rust, adding a whole new developer community to the Optimism client stack. Aside from language diversity, this also removes the centralization risk from only having one client to choose from.

Considering Magi is still so young, there will be several features added over time, such as alternative data availability layer support. “Magi is very new, and likely months of development away from being a feasible alternative to op-node.”

OP-Erigon

Just one day later, the “Test in Prod” team announced op-erigon, a new execution client for the Optimism community.

Just as with Magi, op-Erigon is still very new and only deployed on Goerli tetsnet. To learn how to start integrating these clients yourself, make sure to visit the links provided above.

What are the overall benefits of having different clients?

There are several benefits to having multiple clients run the network, such as:

Security/Liveness: We don’t want 100% of nodes running the same client - what do you think will happen if this one client experiences a severe bug?
Diversity of languages: expanding the types of languages used, means different ideas and approaches that can potentially be used, as well as just an overall bigger pool of developers that can potentially join the network.

Ultimately, it’s good for the network to have a wide set of clients. Over time, we should see other Optimism clients come being developed, and we’ll make sure to let you know when that happens! In the meantime, make sure to follow Optimism on Twitter to stay up to date with the network.

More News & Announcements

The Radius team proposed a model that combines MEV Boost with their sequencing layer for rollup revenue generation.
Learn about ZK-Proof of Exploit, which enables white hat hackers to report live vulnerabilities in smart contracts while maintaining the confidentiality of the exploit. This was one of the projects that were submitted during the recent ETHDenver hackathon, and won two awards.
“Before changing withdrawal credentials or creating new validators, stakers interested in restaking on EigenLayer mainnet have a few considerations to make. Learn more in this post”.
Last week, the EigenLayer team held its first community call, where they discussed the testnet, roadmap, AVS R&D, and held a community AMA. For those that weren’t able to attend, @0xASK wrote this great summary.
The Nethermind team just deployed a new dashboard to start tracking EigenLayer testnet activity.
EigenLayer’s first security audit passed with zero network vulnerabilities.
The Fuel Labs team just published the latest edition of “Inside Fuel”, a quarterly (Q1 in this case) report that goes over the latest news and updates across the Fuel ecosystem.
Check out Mantle’s new ecosystem page, where you can view the different dapps deployed across the network. You can also check out this video recording from last week, where the team goes over their Q1 journey.
Here is the recording from Demo Day during ETHTokyo, where the Mantle team went over the project roadmap and upcoming Q2 mainnet launch.
Last month, Mantle held a hackathon event during ETHDubai. Here are the three winners from the event.
For any web3 game developers, “announcing the first Saga Multiverse Hackathon”, featuring $50K in prizes.
Taiko’s “Alpha-2” zkEVM testnet has now been deprecated (as scheduled). During its launch, the tetsnet reached 194 unique provers, 1.5M+ transactions, and 144K+ unique wallets.
Taiko just published its latest bi-weekly update thread, featuring EIP-1559 and more.
Here are the 11 winners that submitted projects for the Taiko bounty during EthTokyo Hackathon.
Caldera announces Stateful Precompiles, which “will enable developers to customize their rollups without writing a single line of Solidity, saving hours of work”.
The Wynd network team launches its first product, Grass, which enables users to “monetize their network resources with ease”, while also getting rewarded for it.
AltLayer is 1/12 projects chosen for Binance’s MVB Season 6 cohort, out of a total of over 1500 applicants.
Radius, who are building a zk-based shared sequencing layer, announce the “Alliance Partner” program. Anyone building a modular solution while leveraging Radius’ shared sequencer can apply for access to resources and support. Looks like they’re also looking to hire engineers!
Stride becomes the second team to submit a Consumer Chain draft proposal in order to join the ATOM Economic Zone and adopt replicated security from the Cosmos Hub.
Mintscan, the interchain block explorer, just dropped its v2. Check out the thread to learn about the new features that have been added.
The voting period is now open for proposal #790: “Liquid staking module: Regulated and efficient liquid staking”.
Hyperlane announces the “Hyperlane Pilot Academy”. Community members and developers who are interested in helping grow the Hyperlane ecosystem can start applying today.
Polygon announces the Dev Global Tour Hackathon, which will run from May 1 - 21st and feature $125K in prizes.
D8X is now live on Polygon zkEVM testnet. D8X is an institutional grade perpetual futures DEX. Any financial institution can fork, brand, and host their own derivatives product.
Polygon just announced a “bounty program for PIP submissions with $40K in rewards”. Submit Polygon improvement proposals on the community forum for a chance to win some fund rewards.
InsurAce & Lifi protocol announce Bridge cover. “this innovative product compensates users for their claimable loss during a specified bridge transaction”.
“StarkEx v5 for spot trading has arrived”. StarkEx is an L2 scaling engine that is home to projects like Immutable, DYDX, SoRare, and more. This new StarkEx version introduces new features like Multi Asse Trading, and ERC-1155 & ERC-20 Token Minting.
ANVU, previously known as Alpha Road, launched its “exclusive” testnet on April 19th. There were only 1K open slots at launch, with more to be added over the coming weeks. For those unaware, ANVU is a multi-tasking DeFi platform and aggregator that is building on Starknet. You can learn all about the platform through this detailed thread.
1inch, the leading DEX aggregator, is now live on zkSync Era
Maverick protocol launches on zkSync Era. Check out the thread to learn how you can win an early adopter NFT.
Spearmint, an allowlist platform that was developed by the Alchemy team, is now live on Arbitrum.
Pimplico is now live on Arbitrum. Pimlico is building an entire stack of account abstraction tools that developers are able to integrate into their dapps, such as subsidizing gas payments for users, and more.
Here are the top three teams who submitted hacks for Arbitrum bounties during LionHack 2023.
For any Optimism developers and node operators, this new “Optimism Status” Twitter page was made just for you.
The final audit from the Sherlock team found a few bugs in the Bedrock contract, pushing the Bedrock upgrade to a later date. “We plan to scope & execute the changes, announce a new consensus and feature freeze, and demonstrate two weeks of code stability before announcing the Bedrock upgrade date for OP Mainnet”.
During the recent ETHTokyo hackathon, Scroll saw 72 project submissions. Here is a thread they wrote that goes over some of their favorites.
Introducing Spark, a new central limit order book built on the Fuel network.
Attention Fuel community, the team needs your help to decide what the new documentation portal should look like, “including links, information, and structure”.

📚 Discourse & Education

Should sequencer confirmations count as finality?

Logan Jastremski from Frictionless Capital asks if users should count L2 sequencer confirmations as finality. Before going further, we’ll tweak the question from L2s —> rollups to address a larger solution space.

First off, are sequencer confirmations technically final?

No, they are not. Rollup transactions technically reach finality when a batch of them land on L1. Note that rollups do not have to wait for validity proofs to be posted to the settlement layer or for fraud challenge periods to end, but the transactions themselves must be posted and finalized on the DA / consensus layer. This is because before the transaction batch is finalized, transactions can be excluded or re-ordered, resulting in a different state transition. As I’m sure you know, this means bad things can happen. Once the batch is finalized, every transaction and its order is set in stone. If you run a rollup node, you have a deterministic way to compute the state transition, and you know it will not change.

Does this mean users should never count sequencer confirmations as final?

Practically speaking, there are scenarios where it makes sense to do so.

If there’s low user value at risk, you might be willing to roll the dice. In a coffee purchase example, the coffee seller and buyer might both be fine temporarily trusting the sequencer and risking $2. This is a common example where the speedy customer experience likely outweighs the risk.

If there’s high user value at risk, it becomes a harder argument to make. This is, of course, is a big reason why sequencers are being decentralized. With a decentralized sequencer design it’s very possible to implement some leader election mechanism. For example, a rollup might use Proof-of-Stake to increase economic guarantees and make users more comfortable accepting sequencer confirmations as final.

That said, it will depend on the user.

Are blockchain “layers” real?

Christopher Goes from Anoma challenges the idea of “layers” and claims there’s no such thing as L1s, L2s or L3s. In fact, he thinks it’s better if we invert the terminology. Alex Beckett from Celestia disagrees, arguing there is in fact an explicit hierarchy with Ethereum L2s, where the L1 smart contracts determine the canonical L2 chain. Yes, it’s quite confusing 🫠 And if the debate sounds familiar, that’s because we've seen it before.

So, who is right? How should we think about this?

As always, in crypto, there’s technical and social elements.

Christopher emphasizes the technical elements. Technically, it’s all just data posted to new types of databases called blockchains. Can you post the same data to two different databases? Yes. Can one person base their actions off of database A and another person base their actions off of database B? Of course they can. Can two communities / chains look at the same data in the same database, but compute over it in two different ways? Absolutely. This is a dramatic oversimplification, but captures the spirit of how L1-focused ecosystems like Cosmos see things.

The counter argument to Christopher’s POV is that focusing too much on the technical elements can be counterproductive. In one of his replies, Alex mentions the “root of trust” - this is the key social element that Ethereum / modular / rollup communities emphasize. Social consensus on using L1 as the root of trust makes blockchains system easier to understand and build on. For example, even though chains can technically post proofs in multiple places and change their root of trust, there are reasons that they don’t.

More Discourse & Education

@musalbas explains how he thinks about “comparing levels of security for data availability verification for light nodes” 💬
@nickwh8te summarizes the above post on security for different DA schemes 💬👆
0xResearch releases an episode discussing shared sequencers with Josh from Astria and Ben from Espresso 🎙️🔥
@nickwh8te breaks down different aspects of security (immutability vs. verifiability) using Ethereum and Celestia as examples 💬💎
Bell Curve releases an episode on “MEV in a modular world” with Robert from Flashbots and Jon Charb from DBA 🎙️🧠
@HaymanLiron explains the arguments behind posting L2 full transaction data vs. state diffs onto L1, objectively assessing both sides 💬
@likebeckett writes an article discussing “why everyone is converging on the same path to scaling blockchains” ✍️💎
0xResearch releases an episode exploring Account Abstraction and why “Crypto UX sucks, but it won’t” with Alex from zkSync and Julien from Argent 🎙️
Messari (@sunnydece) depicts the business and licensing models of several L2s / L3s 🖼️
@ProbablyNoam explains Account Abstraction in simple terms, using playful illustrations 💬😆
Espresso Systems explains several ways that shared sequencers facilitate cross-rollup bridging 💬
@jillrgunter writes an article and explains how shared sequencers deal with rollup interoperability, including helpful examples and illustrations ✍️
@musalbas breaks down how transactions flow between rollups and Celestia in a whiteboard session 🎥
Empire releases an episode exploring the bear case for L2s and why “they won’t scale Ethereum” with Kyle and Tushar from Multicoin Capital 🎙️
AltLayer releases an episode discussing the evolving blockchain landscape with Nick from Celestia 🎙️
For anyone looking to get started building with StarkWare’s Cairo1.0 programming language, @odin_free has compiled all the links and resources you need in one thread 💬
Taiko explains what makes their rollup decentralized, Type-1 and Ethereum equivalent, including a recording and slides from their recent ETHGlobal presentation 💬
@jon_charb explains how a rollups can retain final say over transaction ordering while also outsourcing block building to a shared sequencer, offering rollups shared security, fast finality and flexible sovereignty 💬💎
DSRV writes an article walking through how to run a distributed validator with Obol Network ✍️
@colludingnode explains how L2 transactions can settle as fast as L1 transactions 💬
Caldera writes an article explaining how they enable rollups to subsidize user gas fees ✍️
Eclipse writes an article explaining “Why Eclipse’s Innovative Modular Rollup Solution Beats Traditional L2s” ✍️
a16z crypto highlights metrics showing momentum in the ZK field, including daily transactions verifying ZK proofs and GitHub stars for ZK repositories 📊
Hyperlane hosts a Twitter Space discussing their collaboration with Caldera
Hyperlane writes an article discussing permissionless interoperability across modular blockchains ✍️
@evansforbes highlights possible designs for shared sequencers 💬🤔
@emo_eth explains how app-specific rollups can control the degree of permissionlessness 💬