Dialogue with Offchain Labs engineer: How does Arbitrum address the challenges faced by Rollup in ModuLar Oriented?

Original Title: How does Arbitrum find its ecoLogicaL niche in ModuLar Oriented?

Written by: Vision, Metastone Group

Before the "Rollup Meetup" event hosted by Metastone Group, the author invited Jason, an engineer from Offchain Labs, to discuss cutting-edge topics in Rollup, including DAC and Anytrust. In particular, the currently popular EIP-4844 and the potential explosion of RaaS in the next narrative cycle, as well as decentralized Sequencer and ModuLar Oriented, are also new directions of interest for Metastone Group researchers.

Topic 1: The Development History of Arbitrum

Vision: There has been a lot of discussion about Arbitrum lately. Jason, could you briefly introduce the entire development journey of Arbitrum from its founding to today?

Jason: Sure, I’d like to share my perspective on the entire process of Arbitrum. First, we launched our testnet in May 2021. After the launch, this testnet was not open to the public; we only invited some project teams to deploy on our platform and experience some of the network features while also making some improvements. Finally, we launched our first-generation mainnet on August 31, 2021, which is what we now refer to as the cLassic tech stack. Although that tech stack was quite primitive, it had already implemented interactive fraud proofs and all related functionalities of Optimistic Rollups. At that time, it was already a fully EVM-compatible Optimistic Rollups solution, so we saw very high on-chain activity after our launch.

Jason: Of course, after the launch, we encountered some scalability issues due to the primitive nature of the tech stack. For example, during the Odyssey in June 2022, gas prices rose significantly due to insufficient throughput, and we noticed these issues. Therefore, on August 31 of the same year, we launched our second-generation technology—Arbitrum Nitro. The second-generation tech stack was directly upgraded from the first-generation mainnet. After the launch of the Nitro mainnet, our throughput increased about sevenfold compared to before. For instance, based on Nitro, our fastest block time is currently about 0.25 seconds per block, and the maximum limit per block is 32 million gas, which is a very large magnitude achievable in the current EVM.

Jason: A great example of this was last month during our token claim event, where our EVM throughput (TPS) reached triple digits, and our mainnet did not experience any network downtime; our sequencer was still producing blocks normally. Many users had connection issues mainly due to third-party RPC connectivity problems. However, our sequencer was running very smoothly and continuously sending batches to L1.

Topic 2: State Scaling

Vision: Currently, the entire blockchain needs to support a large-scale user base. In addition to solving the throughput problem of transaction execution, there is also a widely concerned issue of state scaling. If we want to enable billions of users in the future to hold many types of assets and application states on-chain, the problem of state explosion may also arise. What is Jason's view on state scaling?

Jason: First, Ethereum itself is also working on state expiration to address this issue. Let me explain the mechanism of Layer 2 (L2). We place the data availability (DA) of transactions on L1, which includes the inputs and the order of the transactions. As we know, the EVM is a single-threaded execution environment. Since it is a single-threaded environment, we can understand that if the inputs and their order are known, the output can only be unique. This is why L2 can place DA on L1 and directly read DA to synchronize the L2 network. In other words, if the state on Layer 2 grows to a certain extent, we can actually introduce state expiration, and after this expiration, if you want to query it later, you can do so through other custodians or run a node yourself to read L1 and re-execute the DA to regain that state.

Jason: This is unlike other sidechains; if you lose the block information of a sidechain, or the block header and body, and cannot synchronize from elsewhere, then the state would be completely lost. However, because we place the state on L1, and since Ethereum's nodes are already large enough and there are many infrastructure providers, we do not need to worry about the situation where Layer 1 cannot access this data. Therefore, L2 will have more advantages in state pruning in the future compared to sidechains.

Topic 3: Centralization Issues of DAC

Vision: The next question is about Celestia, which focuses solely on data availability (DA) and uses DAS to sample and verify data. Besides Rollup scaling solutions, there is also off-chain Validium, which relies on a third-party committee for data availability. I understand that Arbitrum Nova also adopts this DAC approach. I would like to ask Jason about the logic behind Arbitrum's initial design and whether the small number of community committee members might lead to centralization issues.

Jason: The tech stack of Nova is based on our Anytrust, which actually shares the same code base as Arbitrum One, but the two have different launch modes under the same code base. For data availability, Nitro directly uploads the DA to L1, while Anytrust uploads the DA to DAC. After DAC receives this, it signs the data, issues a certificate, and sends it back to the sequencer, which then uploads this certificate to L1. This is the basic execution logic of Anytrust.

Jason: Returning to the previous question about whether DAC introduces serious centralization issues. First of all, we are continuously expanding the scale of our DAC nodes. We can see that many nodes are currently running our DAC, including large companies from both Web3 and Web2. Besides the DAC committee, we also have a Mirror mechanism, which allows those who are not part of the DAC but want to participate in the network to run a regular mirror. This way, you can synchronize with other DAC-stored data, and others can access data from both the DAC and the mirror.

Jason: This actually provides a double assurance to avoid situations where DAC cannot obtain DA in case of data loss. Additionally, the benefit of DAC submitting certificates to Rollup is that it greatly reduces the overhead of sequencer uploading DA to L1. Currently, we only need to upload a certificate, which is very small compared to the size of the DA, thus significantly reducing the gas fees under the Anytrust mechanism. If you pay attention to the situation of the Ethereum Goerli testnet a few days ago, you would know that the gas fees on Goerli were very high due to some network activity. At that time, the ETH on Goerli already had a price because of the Layer 0 bridge.

Jason: If you compare the gas costs on Anytrust, you will find that the costs on Anytrust were even lower than those on the Ethereum testnet at that time. So this is a significant advantage of Nova: our gas costs on Anytrust are very low. For a regular ETH transfer, it can even be less than 1 cent, which is a price that other networks cannot currently achieve.

Jason: Regarding Anytrust, if DAC misbehaves, we have a mechanism to fall back to Rollups. We can urgently revert to Rollup if we find that the number of DAC signatures in Anytrust falls below our assumed threshold. The network will stop placing DA into DAC and will instead place it into L1 using the same mechanism as Nitro.

Jason: In contrast to sidechains, if the validators of a sidechain fall below 66% or 51% of a security mechanism, it can expose the network to a dangerous environment. However, we can immediately revert to Rollups to continue correctly advancing the state of the network. The combination of both not only reduces the gas costs of the chain but also enhances the security of the chain.

Topic 4: The Future of RaaS

Vision: Another question I have is about the optimism mechanism. Optimism has launched a Layer 2 Rollup as a Service based on the OP stack. Its design logic is similar to Starkex, which customizes a DApp chain-type service for other application parties, such as gaming or social finance projects. When Arbitrum was initially designed, it separated the ecological attributes of Arbitrum One and Arbitrum Nova, with One responsible for DeFi and other on-chain derivative services, while Nova targets gaming and social finance. I would like to ask if we considered the RaaS direction when designing this logic, and what are our views on the future of Rollup as a Service or specifically creating ecological application chains?

Jason: Regarding this question, we actually revised our authorization mechanism for Arbitrum last month, in March. This means that in the future, everyone can deploy new Layer 3 networks on Arbitrum without permission. You can choose to deploy using Nitro or Anytrust, and these can be deployed directly without our permission. However, if you want to deploy directly on Layer 1, meaning deploying a new Layer 2, you need to apply to our Arbitrum DAO and get approval from the DAO to run it.

Jason: This way, everyone can deploy Application Rollups on our platform, which allows their Application Rollups to capture the ecological value of Arbitrum and Ethereum effectively.

Topic 5: Arbitrum Nova vs. Arbitrum One

Vision: Considering the entire Arbitrum ecosystem, the leading projects are mainly DeFi projects, including well-known projects like GMX and RDNT. Therefore, most on-chain activities are concentrated on Arbitrum One. I would like to ask if there are any good projects to experience on Nova. Currently, the user retention rate in the GameFi and social finance sectors is not particularly high. What is Jason's view on Nova's ability to retain GameFi and social finance users?

Jason: OK, since I work on the technical side here, I may not be as professional in terms of the ecosystem, but I can answer from a technical perspective. As I mentioned earlier, Nova is a leading execution environment with low gas prices, which perfectly meets the high throughput demands of some GameFi applications. In Nova, if some DApps require high throughput, they need to pay gas for each transaction, so lower gas prices are better, which aligns well with their needs.

Jason: Additionally, regarding the ecosystems on Nova that you just mentioned, you can check our portal (https://portaL.arbitrum.io/nova), where we record some of the more popular ecological applications on Nova, including some GameFi projects. So I recommend everyone to take a look at our portal.

Topic 6: Decentralized Sequencer and Anti-Censorship Issues

Vision: Recently, I learned that around March 24, the zkSync era mainnet was launched, but Matter Labs stated that the entire zk-Layer 2 sequencer is still not decentralized enough. Additionally, I learned that a developer from Starkware used Polkadot's substrate to create a decentralized Starknet sequencer. What is Arbitrum's view on the current centralization of sequencing, and what methods are there to address this issue?

Jason: First of all, the issue of sequencing centralization is different from the problems caused by centralization of other nodes. Sequencers do not have the ability to act maliciously because they simply package transactions and upload them to L1. Sequencers cannot sign states or guarantee anything about the state; they merely aggregate transactions and order them before syncing the ordered transactions to other full nodes in the network and uploading them to L1.

Jason: This means that the transactions broadcasted by the sequencer do not broadcast the final state of these transactions; they do not express any subjective opinions. They simply order the transactions, and many people may say that if the sequencer censors transactions or deliberately rejects some transactions, we do have solutions for this issue.

Jason: We have also opened a delay inbox on L1, where we added a feature that allows you to send L2 transactions directly to the delay inbox. If you find that the sequencer is censoring your transaction or deliberately rejecting it, you can use this method to package your transaction into L2, thus avoiding potential malicious mechanisms from the sequencer. So, we can see that if the sequencer acts maliciously, the worst that can happen is that the transaction gets censored, but there is a mechanism to avoid this censorship.

Jason: Therefore, the centralization issue of sequencers is not like the centralization issues of other networks that could endanger network security. There are solutions for these issues. Of course, we will also explore decentralized sequencers. In addition to this, we will also advance the security of validators. Compared to sequencers, the centralization security risks of validators may be greater because validators stake to guarantee the state, and this state is recorded on L1 as the state of L2, which can be directly read by bridge contracts for cross-asset processing from L2 to L1. This is why we are also promoting the decentralization of validators.

Topic 7: The Future of Incremental Development in Web2

Vision: The last question is whether, after completing the entire ecological incentive, Arbitrum will have any technical plans worth looking forward to in the new year. Could you elaborate on the technical roadmap?

Jason: Sure, you don't have to wait until 2024. By the end of this year, we will soon launch the styLus technology, which integrates Wasm into our virtual machine for execution. With the addition of WASM, you can deploy your contracts using C++ or Rust. Contracts deployed using these languages will share the same state tree as those deployed with EVM. If contracts are deployed using WASM, efficiency can increase up to 10 times compared to now. If you are using EVM and currently utilizing some libraries or other components, you can abandon the current components and deploy new components using WASM in this contract for re-invocation.

Jason: This is also part of our EVM Plus strategy, which means that in the future, we will not only perfectly support EVM but also support functionalities beyond EVM, enhancing our scalability and user experience. Shortly before the launch, we will also deploy a new developer network (devnet) for developers to experience.

Jason: To onboard the next level of user scale, blockchains must support the next level of developers entering your ecosystem. Many Web3 projects invite Web2 developers to join, but those developers may not be familiar with Solidity. However, with the WASM approach, they can use languages they are already familiar with to write contracts, allowing us to accommodate more developers while also being compatible with current Web3 developers.

Vision: OK, thank you, Jason. Today we have addressed some questions about Arbitrum and discussed some important issues regarding the direction of blockchain ModuLar Oriented.