The Star Layer 2 Solution Arbitrum is about to launch, and the team behind it, Offchain Labs, discusses the project mechanism and planning

This article was published in the CoinHu community, organized by: CoinHu Walking.

In the past year of booming DeFi, the performance bottleneck of the Ethereum network has become increasingly prominent. Ethereum 2.0 is still a long way off, while a number of Layer 2 scaling solutions are preparing to go live, becoming a highly watched track in the market since the beginning of the year. One of the star scaling solutions launched by the Offchain Labs team is Arbitrum.

On March 16, SNZ Investment Management Director Kai had an engaging dialogue with Offchain Labs co-founders Steven Goldfeder and Ed Felten, sharing the concept origin, working principles, and progress plans of Arbitrum.

Kai (hereinafter referred to as the host): Today, we have the two founding partners of Arbitrum Rollup with us. One is Ed Felten, the founder of Arbitrum Rollup and former Chief Technology Officer of the United States. The other is Steven, who is currently the CEO of the project.

Arbitrum is an important project in the Layer 2 space that Vitalik mentioned earlier. They will be launching soon, and we are very honored to have both of them here. This is also the first appearance of the Arbitrum Rollup team in China.

First question: Could you please introduce yourselves and share how you entered the blockchain field?

Ed Felten: I spent most of my time as a computer science professor at Princeton. I officially entered the blockchain industry in 2013, primarily focusing on research. In 2014, some of my colleagues started teaching blockchain courses, and some of my students began working on blockchain research projects, which I collaborated on. The first version of Arbitrum was launched in 2014, and it was purely a research project at that time.

In 2015, I was invited by the President of the United States to temporarily leave Princeton and join the White House as a senior advisor to President Obama. One of my tasks during my service to the U.S. government was to research cryptocurrencies and blockchain. I returned to academia in 2017. At that time, I had two graduate students, one of whom is Steven, who is participating in this live broadcast today, and the other is Harry, who is also a co-founder of Arbitrum. They both asked me, "Do you remember the research we did on the Arbitrum project? The timing is right; maybe we can pick up this research again."

We decided to build a more complete system for this project. In 2018, we published an academic paper describing the entire Arbitrum system. At that time, the three of us realized that Ethereum would definitely face scalability issues. For us, this was also a great opportunity to bring Arbitrum into commercial practice.

Steven: I also entered the blockchain industry in 2013. At that time, I was studying for my Ph.D. at Princeton, focusing on cryptocurrencies, cryptography, and various blockchain protocols. I co-authored a textbook on blockchain, cryptography, and cryptocurrencies with Ed and other colleagues, which is now used in over 200 universities worldwide. The book has been translated into five languages, including Chinese, and students studying these fields in China are already familiar with this textbook.

As Ed mentioned, after he returned to Princeton from the White House, I and another co-founder approached him to start this conversation in his office. Before the paper was published in 2018, we realized that there was a commercial opportunity for Arbitrum Rollup. So shortly after the paper was published, we established the company. We began our first round of financing in 2019.

There’s an interesting story during our entrepreneurial journey. When we were working on the project, the term "Rollup" didn’t exist yet. When we introduced the project and what we were doing, people would ask if we were working on state channels or Plasma, but it was neither. We started working on it before the term "Rollup" even existed.

As everyone knows, the concept of Rollup became very popular in 2020 and 2021. We were one of the first solutions in this field to support the Ethereum EVM.

Host: The second question: Could you please introduce the Arbitrum Rollup project and share the story and ideas behind its creation?

Ed Felten: I want to return to the origin of the Arbitrum concept. When we were doing blockchain research, the question that lingered in my mind was: what is the actual use of blockchain? For example, Bitcoin was very popular at that time. But as a computer scientist, what interested me most was smart contracts. I found smart contracts to be very powerful, but I realized early on that they faced scalability challenges.

For instance, imagine Ethereum as a globally shared computer that allows all users to run their smart contracts on it. It’s clear that it’s very expensive, the computation speed is slow, and the performance is limited. Therefore, I started thinking about scalability issues early on. Even before Ethereum appeared, I was contemplating how a system similar to Ethereum would solve its scalability issues. This was the origin of the Arbitrum project.

We wanted to solve the scalability problem with an off-chain solution that doesn’t sacrifice security. Initially, I worked on some projects with undergraduate students, trying to address scalability issues and built a system. However, that system was only useful for certain functions and wasn’t a complete system. So in 2017, the project that Steven, Harry, and I worked on made this system more complete. After establishing the company, our efforts were focused on ensuring that Arbitrum could be compatible with Ethereum.

Steven: My story overlaps with Ed’s to some extent. I entered the blockchain field relatively later than Ed. I remember Ed teaching blockchain-related courses in 2014 and 2015, but I hadn’t yet entered Princeton. After Ed went to the White House, I was waiting for his return. Harry and I had already recognized that Ethereum had enormous potential, and its widespread application potential would be adopted by the mainstream world; but on the other hand, Ethereum definitely faced scalability issues. So we were waiting for Ed’s return. Once Ed came back from the White House, we started working on the Arbitrum project together.

During my Ph.D. studies, I also worked on some other crypto projects. So I firmly believe that this field has enormous potential. But I also realized early on that scalability was a huge problem that needed the right technology to solve.

After two and a half years of working on Arbitrum, we proved that our ideas were correct. The timing is just right now. The market has recognized that, on one hand, Ethereum has great potential, but on the other hand, scalability urgently needs to be addressed. Solving the scalability problem also holds great potential for the blockchain industry.

During our early financing, we spent a lot of effort convincing the market. When I first started raising funds, some investors would ask me, "Why are you so confident that we will need this solution in the future?" I said, "I am very sure that one day Ethereum will achieve large-scale mainstream applications, but it will also face scalability issues." Now this assertion has become a reality.

Host: The two of you just mentioned scalability, which is currently an urgent issue for Ethereum to solve. Scalability is also a core problem that the Arbitrum off-chain solution aims to address.

Third question: Could you please explain the operating principles and main features of the Arbitrum solution?

Ed Felten: Let me first introduce the design principles of Arbitrum, which are mainly three points: First, it must be compatible with Ethereum; second, as many activities as possible should occur off-chain; because Ethereum's gas resources are the most precious and expensive; the third principle is trustlessness. Anyone can force this chain to behave correctly, just like on Ethereum.

So how does Arbitrum achieve these three principles? For example, when someone submits a transaction data, the transaction data is stored on the Ethereum chain, so everyone can view this transaction, and the transaction content is completely public. However, the computation and storage involved in the transaction are done on Arbitrum, that is, off the Ethereum chain. This way, scalability can be achieved, reducing the load on the Ethereum chain.

Additionally, Arbitrum will periodically, for example, every five or ten minutes, send "checkpoints" to Ethereum, which is a hash that contains the complete state of all activities that occurred on Arbitrum, sending this hash as a record on-chain. This allows for a significant reduction in fees while achieving scalability.

But you might ask, when we send information to the Ethereum chain, how do we ensure that this information is correct? This is the key point of the Arbitrum protocol. The protocol includes the participation of validators, who need to record on-chain and send a claim to Ethereum. At the same time, validators need to hold a deposit. If a validator's claim is false, the validator's deposit will be forfeited.

When a validator sends a claim to the chain, there will be a period during which anyone can raise their objections. If you disagree, there will be a dispute, and the dispute resolution mechanism is the core and key to how Arbitrum can achieve scalability.

The dispute resolution mechanism we designed works like this: if both parties disagree on something, an effective resolution mechanism is to break it down from large to small. For example, if a transaction involves a billion steps that have generated a dispute, our approach is to break the billion steps into 100 smaller claims, each containing 10 million steps. This reduces the scale of the dispute from a billion to tens of millions. The disagreeing party can then pick out the steps they disagree with from these 10 million, further breaking it down until the most critical disputed step is found. Once the critical step is identified, we can use Ethereum's contracts to determine whether this step is correct or incorrect. This way, efficient dispute resolution can be achieved.

Our overall thinking is as follows: when a node sends a claim that is correct and has no issues, a hash is sent every 10 minutes. If there are no disputes after the hash is sent to the Ethereum chain, the system can continue to operate smoothly. If there is a dispute, it can be resolved efficiently through the method just described, ultimately leading to a good arbitration. This is where the system's efficiency lies.

For ordinary users, you might worry that such a mechanism is too complex. But there’s no need to worry about this. Because this mechanism doesn’t significantly relate to ordinary users; the dispute resolution mechanism will be handled by specialized nodes. Of course, if ordinary people want to earn more money, they can choose to become validators. But if they don’t want to, that’s fine too.

Host: Layer 2 has also been a hot topic of discussion. In addition to Arbitrum, there are also state channels, ZK Rollup, and other different solutions.

Fourth question: Could you please discuss the advantages and disadvantages of Arbitrum compared to other solutions, especially in comparison to ZK Rollup?

Steven: First, it’s important to clarify that there is currently no best solution; this is a collaborative process. The more people work on it, the better the outcome will be. So we maintain a respectful attitude towards other teams, even while making comparisons.

I will first compare it with Plasma and state channels, and then with ZK Rollup.

Plasma aims to achieve more; in addition to execution availability, it also hopes to achieve data availability. The definition of availability refers to putting both execution and data off-chain. For Rollup, the data is still on-chain, but the execution is off-chain. This is also true for Arbitrum; the transaction data is on the Ethereum chain, but the computation and storage are placed off-chain.

Since Plasma aims to do more, it faces more issues. At least for now, no team has a complete implementation of Plasma, and many teams have encountered numerous problems while trying to implement Plasma. On the other hand, Rollup aims to achieve less, making it a more feasible solution with seemingly greater potential for solving scalability issues. This is why more and more people are focusing their interest on Rollup; at least the difficulty is lower.

Now let’s discuss the differences with state channels. State channels are more fixed in terms of counterparties for contract transactions. For example, if I always trade with a specific person, we open a trade or play a game together. But we can imagine an open world where you don’t know who your trading counterpart is; it could be random or someone you cannot trust. Therefore, state channels have significant limitations.

However, it seems that the teams working on state channels have found an interesting application: combining state channels with Rollup to create a cross-chain bridge between Rollup and Rollup or between Rollup and Ethereum. This combination can complement the ecosystem more completely, forming a more comprehensive, interesting, and suitable ecosystem for everyone.

As for ZK Rollup, it requires immediate proof, so the costs are very high. Additionally, the ZK compiler must convert high-level languages into low-level languages, which is also very inefficient.

I believe ZK Rollup may be a great solution in the future, but the issues with Ethereum exist right now. Arbitrum can effectively solve the current problems of Ethereum.

By the way, I would like to announce for the first time: this summer, a researcher from a ZK Rollup team will join the Arbitrum team. Why are we hiring a researcher from a ZK team? Technically speaking, there is no best definition of technology; the development and evolution of technology are endless. The best technology today may not be the best in the future. We need to keep updating ourselves; if we don’t innovate and evolve, we will be challenged and replaced by others.

For example, in my own research field, I published a paper in 2013, another in 2015, one in 2018, and one in 2020, all on the same topic: researching threshold signatures in the blockchain field. My research examples show that technology must continuously evolve and update. Regarding ZK, there’s no doubt that if Ethereum is to achieve widespread applications and EVM compatibility in the future, it may adopt ZK. However, this time span will extend to several years or even longer.

For Arbitrum, we hire ZK researchers to ensure that Arbitrum remains the best solution available. If better solutions emerge in the future, whether through integration with ZK or other solutions, we can continue to research and keep up with the latest technology, ensuring we remain innovative.

The advantage of ZK Rollup is its fast finality. Therefore, transfers and withdrawals can be quickly confirmed. However, for Arbitrum, due to the challenge period, you need to wait until the challenge period ends before you can withdraw funds. In terms of speed and timeliness, it does not match ZK. But this is not a fatal flaw. State channels and the HOP protocol have already proposed some feasible solutions that allow for quick transfers and withdrawals at the application layer. In the future, the issue of quick withdrawals will become less significant (at the Rollup system level).

Whether it’s ZK or other solutions, Arbitrum is currently the best solution available. Moreover, given time, we will continue to update and upgrade, whether it’s ZK or others; we are open to learning and drawing from good technologies. We always hire top scientists, including ZK researchers, to ensure that Arbitrum remains technically advanced.

Host: Steven just shared a key insight, which is that Arbitrum will also incorporate ZK aspects in the future.

Fifth question: What is the current status of the Arbitrum testnet? How will the mainnet launch? What are your expectations for the Arbitrum mainnet?

Steven: I know that everyone is currently most concerned about the news of the mainnet launch. The Arbitrum testnet has been running for five months now, and its performance is quite good. The testnet helps us test the network's performance, identify existing issues, and conduct stress tests.

Currently, we are handling a very high throughput (TPS), reaching millions. At peak times, we can receive 14,000 requests per minute. Regarding the specific progress, everyone can look forward to it. This week, we will soon release the "release candidate version," which will first be tested on the testnet before being deployed to the mainnet.

Transitioning from the testnet to the mainnet represents our attitude towards everything we do. Our code has undergone 33 security audits. We understand that users entrust their funds to Arbitrum, so we take user fund security very seriously.

Regarding the "release candidate version," we will invite everyone to participate and help us conduct stress tests. I believe that after the mainnet launch, everyone will not be disappointed.

What sets Arbitrum apart from other projects is that on the very first day of our mainnet launch, we will make everything about the project public and invite everyone to participate in the mainnet.

Host: Thank you, Steven, for introducing the subsequent development process of Arbitrum.

Sixth question: We are also very concerned about the challenges Arbitrum will face after the mainnet launch and the overall planning.

Ed Felten: Currently, our focus is on the mainnet launch, ensuring that the transition to the mainnet is as smooth and secure as possible. In the future, the most important thing I am concerned about is scalability.

Scalability

Although we have done well in terms of scalability and fees, I hope to achieve further improvements in performance, mainly through innovative engineering methods. For example, by developing the virtual machine EVM system and optimizing node settings, we can further enhance performance. It is expected that as traffic on Ethereum increases and throughput demands rise, we can meet those needs without encountering the bottleneck issues that many projects currently face.

Efforts in Programmability

We hope to allow everyone to write smart contracts in different ways. For example, we currently have a project that allows you to compile your written smart contracts, enabling you to use languages other than Solidity to write smart contracts that can also run on Arbitrum. At the same time, it can interact with virtual machines written in Solidity. This is a step forward in programmability. By using this approach, we can allow developers outside the blockchain programming realm to enter.

In summary, the focus is on scalability and programmability, as well as better development tools.

Interactive Q&A

Q: Transferring Layer 2 assets to Layer 1 requires a very long waiting period. What do the guests think about this waiting period? How does Arbitrum or its ecosystem projects solve this problem?

When transferring assets from Layer 1 to Layer 2, or when calling something from Layer 1 on Layer 2, the time is determined by Layer 1. However, conversely, if you want to transfer assets from Layer 2 to Layer 1, or call something from Layer 1 on Layer 2, if you use the Optimistic Rollup protocol on Layer 2, the waiting time at the protocol layer will indeed be longer. It’s important to emphasize that this is indeed a protocol issue, mainly because solutions will have a challenge period set; you must wait for a period of time for someone to raise an objection or for there to be no objections before a final determination can be made.

This is why you may need to wait several days to withdraw at the protocol layer. However, there are projects running in the Arbitrum ecosystem that are attempting to solve this issue, including those running on the Arbitrum testnet. They allow users to realize immediate transfers. Although the technical implementation methods may vary widely, the essence is the same: either exchanging or swapping assets between Layer 1 and Layer 2, or having someone lend you assets so you can access them in advance. Given time, users will forget about the need to wait. Moreover, exchanges will soon adopt such solutions, making deposits and withdrawals essentially not require a waiting period. For users, the issue of waiting periods will become less significant in the future.

Q: Recently, privacy trading and preventing "scientists" from front-running have become significant issues. How do the guests address these aspects on Layer 2?

Steven: Regarding the issue of preventing front-running and order-sniping, this is indeed something that Arbitrum is consciously paying attention to. Previously, I co-authored a paper at Cornell with others that studied the front-running (scientist front-running) problem. I started thinking about this issue a long time ago. Arbitrum has a good solution. Currently, transactions are collected and sorted by aggregators. Moreover, we use Layer 1 miners for sorting, ensuring that this sorting sequence is at least as good as Layer 1 and not worse. This is the current situation.

In the future, we will further optimize this solution. We will introduce another party, the "sequencer," which will provide lower latency than Layer 1. When a transaction is sent, the speed at which it is received and responded to must be even faster than Layer 1's inclusion of your transaction.

Achieving this is quite challenging because sorting represents a significant power. If you exploit this power, it will lead to MEV front-running issues. We do not wish to give this sorting power to users or any party.

Coincidentally, I have another paper published last year at Cornell proposing a solution called "Fair Ordering Byzantine Fault Tolerance." The order of fair sorting is that the order in which transactions are raised and enter the sequence is the final order that comes out. The one responsible for sorting is the sequencer or sequencer node. This resolves the MEV issue.

The existence of MEV is due to the fact that the party responsible for sorting has significant power to adjust the order. However, once the "fair ordering" mechanism is introduced, the possibility of adjusting the order will no longer exist.

To summarize, the MEV issue on the current Arbitrum will not be worse than on Layer 1. Moreover, given time, with the introduction of sequencers and the fair ordering mechanism, the situation will improve. Users will no longer need to worry about malicious nodes harming their interests through front-running. This is indeed a significant issue for Ethereum and blockchain applications. For me, the current solution from Arbitrum is the best.

Regarding privacy, we can discuss user privacy and contract privacy separately. For user-level privacy issues, Layer 2 has not improved or worsened compared to Ethereum. For example, on Ethereum, you can create a new address and generate a private key. Initially, these are not public and are personal privacy. However, since every transaction is public, those with intent can track your transactions and ultimately link your account to your identity. In terms of user privacy, Layer 2 technology has neither improved nor worsened compared to Ethereum.

As for contract-level privacy, contract privacy refers to the internal state of the contract not being public, or the transactions executed through the contract being non-public. In the very first version of Arbitrum, because it was a trustless mechanism, if you want the contract to be trustless, it means the contract must be public and accessible to everyone. However, if the participants in the contract are limited, there are some technical means to achieve contract privacy.

On one hand, this can be done through sidechains; for example, Arbitrum's roadmap includes plans for sidechains that will be developed after the mainnet launch. Additionally, there are other technologies mentioned in the roadmap. Given time, you will see that Arbitrum will introduce many privacy technologies to ensure that contracts with limited participants can achieve privacy at the contract level.