L2 Planet Issue #31
In this issue of L2 Planet, we focus on the latest developments in the Aevo, Starknet, Scroll, Orbiter, and Arbitrum ecosystems.
Aevo Migrates to Celestia
Aevo, an exchange focused on options and perpetuals, has decided to transition its data availability layer to Celestia.
Previously, Aevo utilized Ethereum for data availability, incurring costs of 50-100 ETH per month to post all rollup data. As is widely recognized, using Ethereum for data availability is significantly more expensive than using Celestia. By migrating to Celestia, Aevo is expected to reduce its costs by nearly 100 times, making its services more affordable for users. Additionally, this change is projected to enhance the profitability of Aevo's Exchange/Sequencer operations by over 90%.
As a result of this migration, Aevo should now be classified as an 'optimum rollup' rather than an 'optimistic rollup'.
Starknet 🤝 Celestia
StarkNet and Celestia have partnered to utilize Celestia's blobstream on StarkNet L3s.
With this partnership, StarkNet appchains will have the option to send their data to either Celestia or StarkNet. For example, consider the ZKX protocol, which aims to be an appchain on StarkNet. When ZKX opts for Celestia over StarkNet for data availability, transaction fees could experience a dramatic reduction.
Blobstream allows L3 developers in the Starknet ecosystem to integrate Celestia, expected to be the first data availability layer in production with data availability sampling (DAS). The principle of operation is clearly visible in the image above. An appchain produces a proof with the SHARP prover and sends it to the L3 contract on StarkNet for verification. On the other hand, transaction data is sent to Celestia for Data Availability (DA). The Merkle root of the available data signed by Celestia validators is sent to the blobstream contract on StarkNet. The L3 contract on StarkNet both verifies the proofs and checks the DA through the blobstream contract.
Scroll’s Multi-Prover Implementation
Scroll is currently a zkRollup solution running zkEVM, as we all know. According to the latest blog post, Scroll is exploring the implementation of the multi-prover approach, which Vitalik has also previously mentioned. What is the multi-prover approach and why its matter?
In the current state, all Layer-2 solutions have a single prover, which is either a fraud proof or a validity proof. In fact, some projects do not have any active proof mechanism at all, but that's not our focus here. Having a single proof system can lead to certain problems. Just like Ethereum's multi-client approach, increasing diversity in the proof system can positively impact security. In the image below, you can see how different proof combinations affect finality and security.
For instance, Scroll is a zkEVM solution which runs single zk proof system, and its zkEVM architecture and circuits comprise thousands of lines of code. Such lengthy and complex zkEVM codes could potentially contain a bug, which might lead to critical consequences. How can we mitigate this risk? Through a multi-prover approach! In the multi-prover approach, 2 or more provers are used. The options we have are fraud-proof, zk-proof, Trusted Execution Engine (TEE), and governance. We can combine these options to enhance the security or finality of the network.
The Scroll team conducted research on what the second prover should be and decided on a TEE, such as SGX. TEEs allow you to run software in a secure area of a processor where data and memory are inaccessible to other components in the system. The TEE prover operates within this protected environment, executing transactions and generating proofs. Why wasn't a fraud-proof chosen? Because fraud proofs have a long finality time, for example, 7 days, which would affect Scroll's current finality time.
Does TEE carry no risks? To mitigate concerns about relying on TEE implementations and hardware manufacturers, Scroll is exploring a protocol that aggregates TEE proofs from multiple TEE verifiers with different hardware and client applications. This approach aims to diversify trust and enhance the overall security of the system. In the image below, you can see the planned system architecture.
The Scroll team is closely working with Automata to integrate an SGX prover. In fact, a prototype SGX verifier currently operating on the Scroll Sepolia testnet is validating all state transitions in the network. It seems like we will be hearing more about multi-prover systems soon.
Orbiter Rollup
Orbiter Finance, a bridge application between Layer 2 networks, will launch its own zkRollup.
According to the announcement, Orbiter commands an impressive 57% market share of transactions. In 2023 alone, it successfully processed over 12 million transactions, totaling a remarkable 7.8 billion dollars. Considering the transaction count of over 12 million, it's clear why Orbiter wants to create its own Rollup. From a user perspective, it's likely that there will be a reduction in transaction fees. Additionally, it is reported that with zk-SPV technology, certain input information can be concealed, allowing DApps to execute private transactions based on this.
There is no information yet on what stage the transition is at or when it will be completed. You will hear about Orbiter's rollup architecture from us first as soon as it is clear, so stay tuned :)
Arbitrum Chain-Cluster
We know there are different stacks in the Layer 2 ecosystem. Arbitrum also has its own stack, Arbitrum Orbit. Using Arbitrum Orbit, it's possible to create a chain with Rollup or AnyTrust technology in a permissionless manner. But what if Orbit chains could communicate with each other cross-chain? Ed Felten addressed this topic from Arbitrum's perspective in the Arbitrum forum.
Let's consider a scenario where Arbitrum Orbit chains form a cluster. For example, Chain A and Chain B are in the same cluster. The party operating the A node also operates a B node and vice versa. Consequently, the A node can provide information about events on Chain A, and the B node can trust this information because both nodes are operated by the same party. In this scenario, any cross-chain message within the cluster that is sent by one chain at time T must be visible on its destination chain by no later than time T+Delta, where Delta is less than the settlement time of the sending chain. Additionally, Chain A and Chain B need to organize the proving process as a joint effort. If the proving is done via zk-proofs, a single proof encompassing both A and B is required. If the proving is conducted through optimistic proving, there should be a single assertion and dispute protocol. In principle, it's also possible for A and B to use different proof systems.
This unlocks two use cases:
a single chain can take a sharding approach, expanding into a set of clustered chains that have identical code and configuration, and are governed as the original single chain was; or
a set of separately governed chains can agree to connect their chains into a cluster, accepting a level of interdependence in their security in exchange for much faster cross-chain interaction.
For now, these are the known details about the Arbitrum chain-cluster. The team has conveyed that they will share more information on this in the future.
Spectating Corner
Reading Corner
What builders can learn from RetroPGF 3: separating the signal from the noise, Carl Cervone
Introducing Blobstream: streaming modular DA to Ethereum, Celestia
That’s all from L2 Planet for now, hope to see you in 15 days :)