Offchain Labs co-founders Steven Goldfeder and Ed Felten shared the concept origin, working principle and progress plan of Arbitrum.
Sorting out: Bihu walking
In the past year when DeFi has flourished, the performance bottleneck of the Ethereum network has become increasingly prominent. Ethereum 2.0 is nowhere in sight, and a batch of second-tier expansion plans are already on the line, which has become a track that the market has been paying attention to since the beginning of the year. Arbitrum, a star expansion program launched by the Offchain Labs team, is one of them.
On March 16, SNZ Director of Investment Management Kai and Offchain Labs co-founders Steven Goldfeder and Ed Felten had a wonderful dialogue, sharing with you the concept origin, working principle and progress plan of Arbitrum.
Kai (hereinafter referred to as the host): Today we invited the two founding partners of Arbitrum Rollup. One is Ed Felten, the founder of Arbitrum Rollup and the former Secretary of Science and Technology of the United States. One is Steven, currently the CEO of the project.
Arbitrum is an important project in Layer 2 mentioned by Vitalik. They will be online in the near future, and we are very honored to be able to invite two of them. This is also the first appearance of the Arbitrum Rollup team in China.
The first question: Please introduce yourself to the two guests and share how you entered the blockchain field?
Ed Felten: I spent most of my time as a professor of computer science in Princeton. I officially entered the blockchain industry in 2013, mainly doing research at the time. In 2014, some of my colleagues started to teach blockchain courses, and some of my students also started to do blockchain research projects. I will do it with them. The first version of Arbitrum was launched in 2014, and it was purely a research project at the time.
In 2015, I was invited by the President of the United States to temporarily leave Princeton University and enter the White House as a senior adviser to President Obama. One of the tasks in the service of the US government is the research on cryptocurrency and blockchain. In 2017, he returned to academia. There happened to be two graduate students, one was Steven who participated in the live broadcast today, and the other was Harry, the co-founder of Arbitrum. The two of them asked me “Do you still remember the research done on the Arbitrum project? The timing is right, maybe we can pick up this research again.”
At that time we decided to build a more complete system for this project. In 2018, an academic paper was published describing the entire Arbitrum system. At that time, the three of us realized that Ethereum would definitely face scalability issues. For us, this is also a good opportunity to bring Arbitrum into business practice.
Steven: I also entered the blockchain industry in 2013. At that time, I happened to be a Ph.D. student in Princeton, and my main focus was cryptocurrency, cryptography, and various blockchain protocols. Together with Ed and other colleagues, I wrote a textbook on blockchain, cryptography, and cryptocurrency. This book is now used by more than 200 universities around the world. The book has been translated into five languages, including Chinese. Chinese students who have studied these fields are already familiar with this textbook.
Then Ed just said that after he left the White House and returned to Princeton, another co-founder and I went to him and started this conversation in his office. Before the paper was published in 2018, we realized that there is a business opportunity for Arbitrum Rollup. So we established the company soon after the paper was published. The first round of financing began in 2019.
There is also an interesting story in the entrepreneurial process. When we were working on the project, the term “Rollup” did not yet exist. When we introduce the project and what we are doing to others, others will ask us whether we are doing a state channel or a Plasma, but it is not. We started doing it when the word “Rollup” didn’t exist yet.
Everyone knows what happened later. In 2020 and 2021, the concept of Rollup has become very popular. We are the first solution in this field that can support the Ethereum EVM.
Moderator: Second question, two guests, please introduce the Arbitrum Rollup project and the stories and ideas behind the creation of this project.
Ed Felten: I still want to go back to the origin of the Arbitrum concept. When we were doing blockchain research, the question that lingered in my mind was: where exactly is the purpose of blockchain? For example, Bitcoin was very popular back then. But what interests me most as a computer scientist is smart contracts. I think smart contracts are very powerful, but I clearly realized early on that smart contracts are facing the challenge of expansion.
For example, imagine Ethereum as a globally shared computer. Allow all users to run their smart contracts on this computer. Obviously, it is very expensive, the calculation speed is very slow, and the performance is limited. So I started thinking about scalability issues very early. Even before Ethereum appeared, I was thinking about how to solve its scalability if a system similar to Ethereum appeared. All this is the origin of the Arbitrum project.
We hope to solve the problem of scalability with an off-chain solution without sacrificing security. In the beginning, I did some projects with some undergraduates, but actually tried to solve the problem of scalability and set up a department. But that system is only useful in some functions, not a very complete system. So in 2017 Steven and Harry and I worked together to make this system more complete. As for the establishment of the company, our more effort is to hope that Arbitrum can be compatible with Ethereum.
Steven: Part of the story I want to tell overlaps with Ed. I entered the blockchain field relatively late to Ed. I remember that Ed taught blockchain-related courses in 14 or 15 years. But I had not yet entered Princeton. After Ed arrived at the White House, I have been waiting for Ed’s return. Harry and I had realized at the time that Ethereum has huge potential on the one hand, and its wide application potential will be used by the mainstream world; but on the other hand, Ethereum’s scalability must also be problematic. So we have been waiting for Ed’s return. When Ed returns from the White House, we will start the Arbitrum project together.
During my PhD, I also did a little bit for other encryption projects. So I absolutely believe that the potential in this field is huge. But I also realized early on that scalability is a huge problem, which requires appropriate technology to solve it.
After doing Arbitrum for two and a half years, it proved that we were right. The timing is just right now. The market is now aware that on the one hand, Ethereum has huge potential, but its scalability needs to be solved urgently. Solving the problem of scalability also has great potential for the blockchain industry.
In our earliest financing, we also spent a lot of energy to convince the market. When I first started financing, some investors would ask me, “Why do you believe so much that we need this solution in the future?” I said: “I’m pretty sure that one day Ethereum will get large-scale mainstream applications, but at the same time it will also face scalability issues.” Now this assertion has also become a reality.
Moderator: Just now the two also mentioned scalability, a problem that Ethereum needs to solve urgently. Scalability is also the core problem of Arbitrum’s off-chain solution.
The third question, two guests, please explain the operating principle and main features of the Arbitrum solution?
Ed Felten: Let me first introduce the design principles of Arbitrum. There are three main points: the first is to be compatible with Ethereum; the second is to allow as many activities as possible to be carried out under the Ethereum chain. Because the gas resource of Ethereum is the most precious and expensive; the third principle is that there is no need to trust. Anyone can force this chain to do the right thing. Just like on Ethereum.
So how does Arbitrum implement these three principles? For example, if someone submits a transaction data, the transaction data will be stored on the Ethereum chain, so that everyone can view the transaction, and the transaction content is completely public. However, the calculation and storage involved in the transaction are placed in Arbitrum, that is, under the Ethereum chain. In this way, the capacity can be expanded and the load on the Ethereum chain can be reduced.
In addition, Arbitrum will send a “checkpoint” to Ethereum on a regular basis, such as every five minutes or 10 minutes, which is a hash that contains the complete state of all activities that occur on Arbitrum. This hash is sent as a Record on the chain. In this way, a large-scale cost reduction can be achieved while achieving scalability.
But everyone can ask again. When we send information to the Ethereum chain, what if we guarantee that the thing itself is correct? This is the key to the Arbitrum protocol. The agreement includes the participation of validators. If the validator needs to record on the chain, it needs to send a claim to Ethereum. At the same time, the validator needs to deposit a deposit. If the verifier’s claim is false, then the verification node’s deposit will be lost.
When the validator sends the claim to the chain, there will be a period of time anyone can raise their own questions. If you disagree, there will be disputes. The dispute resolution mechanism is the core and key to the scalability of Arbitrum.
The dispute resolution mechanism we designed is such that if both parties disagree on something, the effective resolution mechanism is to split from the largest to the smallest. For example, a transaction involving 1 billion steps is controversial. Our approach is to split 1 billion steps into 100 smaller propositions, each of which contains 10 million steps. In this way, one billion disputes have been reduced to tens of millions of disputes. The party who disagrees picks out the one he disagrees with from the 10 million, and then further changes from the larger to the smaller until the most critical and controversial step is found. After finding the critical step, use the Ethereum contract to determine whether this step is right or wrong. In this way, efficient dispute resolution can be achieved.
Our overall thinking is as above. When a node sends a claim, the claim is correct and there is no problem, then a hash is sent every 10 minutes. After hashing to the Ethereum chain, there is no dispute, and the system can run smoothly. If there is a dispute, you can reduce the dispute from large to small by the efficient method just described, and finally get a good arbitration. This is where the system is efficient.
For ordinary users, you may worry whether such a mechanism is too complicated? There is no need to worry about this. Because this mechanism does not have much to do with ordinary users, the dispute settlement mechanism will have a dedicated node responsible for resolving disputes. Of course, if ordinary people want to make more money, they can also choose to be a verification node. But it doesn’t matter if you don’t want it.
Moderator: Layer 2 is also a hot topic that everyone discussed before. In addition to Arbitrum, there are state channels, ZK Rollup and other different solutions.
Fourth question: I would like to ask the two guests, what are the advantages and disadvantages of Arbitrum compared to other solutions? Especially compared to ZK Rollup.
Steven: The first thing that needs to be clarified is that there is no best solution yet. This is a process of collaboration. The more people who work hard in it, the better the result will be. So we will maintain a respectful attitude towards other teams, even if we are to compare them.
I will first compare the difference with Plasma, the difference with the status channel, and then with ZK Rollup.
Plasma wants to achieve more things. In addition to the availability of execution, it also hopes to achieve the availability of data. The definition of availability refers to putting execution and data down the chain. For Rollup, the data is still on the chain, but execution is off-chain. The same is true for Arbitrum, the transaction data is on the Ethereum chain. Just put the calculation and storage under the chain.
Plasma wants to do more things, so it faces more problems. At least for now, no team has a relatively complete implementation of Plasma, and many teams have encountered many problems in the implementation of Plasma. For Rollup, because it wants to achieve fewer things, it is a relatively more feasible solution, and its potential for solving scalability problems seems to be greater. This is why more and more people are now interested in Rollup, at least the difficulty will be relatively small.
Then introduce the difference with the status channel. The state channel is even more fixed by the counterparty of the contract transaction, such as me and a certain person, we both open a transaction, or play a game. But we can imagine that in an open world, you don’t know who your counterparty is. It may be random, or you may not be able to trust it. Therefore, the status channel has great limitations.
But now for the state channel team, they seem to have found a very interesting application, which is to combine the state channel with Rollup and turn the state channel into a cross-chain between Rollup and Rollup, or between Rollup and Ethereum. bridge. Through such a combination, the ecosystem can be supplemented to be more complete, forming a more complete, interesting and more suitable ecosystem for everyone.
For ZK Rollup, it needs to be proved immediately, so the cost is very expensive. In addition, ZK’s editor has to turn high-level languages ​​into low-level languages, which is very inefficient.
I think ZK Rollup may be a good solution in the future, but the problems with Ethereum exist right now. Arbitrum can be very good and solve the current problems of Ethereum now.
By the way, I also announced for the first time: this summer, a ZK Rollup researcher will join the Arbitrum team. Why would we hire a researcher from the ZK team to join the team? As far as technology is concerned, there is no best definition of technology, and technological development and evolution are endless. The best technology today is not necessarily the best in the future. We need to always keep updated. If we cannot update and revolutionize ourselves, we will be challenged and replaced by others in the future.
Take the field of my own research as an example. The papers I wrote, one published in 13 years, one published in 15 years, one published in 18 years, and one published in 20 years, all have the same content, and they are used to study threshold signatures in the blockchain field. From the examples I studied, we can see that technology is constantly evolving and updating. As far as ZK is concerned, there is no doubt that if Ethereum is to be widely used in the future and achieve EVM compatibility, it is possible to adopt ZK. It’s just that this time span will stretch to several years or even longer.
For Arbitrum, we hire ZK researchers and hope that through self-innovation, we can ensure that Arbitrum is the best solution currently. If there are better solutions in the future, whether it is integration with ZK or integration with other solutions, we can also continue to research, always grasp the latest technology, and keep ourselves innovated.
The advantage of ZK Rollup is the fast finality. Therefore, the transfer and withdrawal can be quickly confirmed. But for Arbitrum, due to the challenge period, you need to wait until the challenge period is over before you can withdraw coins. The speed and timeliness is not as good as ZK. But this is not a flaw. The state channel and HOP protocol has also proposed some feasible solutions. Allows to quickly realize currency transfer and withdrawal at the application layer. The matter of fast withdrawal will no longer be so important in the future (at the level of the Rollup system).
Whether it is ZK or other solutions, Arbitrum is currently the best solution. And over time, we will continue to update and upgrade, whether it is ZK or other, as long as we have good technology, we don’t mind learning and borrowing. We always hire the top scientists, including researchers from ZK, to ensure that Arbitrum is always technologically ahead.
Moderator: Steven just shared a key password. Even Arbitrum will have ZK aspects in the future.
Question 5: What is the current state of the Arbitrum testnet? How to launch the mainnet? What do you expect from the Arbitrum mainnet?
Steven: Actually, I know that everyone is most concerned about the news of the mainnet launch now. Arbitrum’s testnet has been running for five months, and it is performing relatively well now. The testnet will help us test the performance of the network, existing problems, and also do stress tests.
Our current processing throughput (TPS) is very large, reaching millions of levels. During peak periods, it can receive 14,000 requests per minute. As far as the specific progress is concerned, everyone can look forward to it. We will release the “Release Candidate Version” soon this week, which will be tested on the testnet first, and then deployed to the mainnet.
After the test network and then to the main network, this also represents our attitude in doing everything. Our code has undergone 33 security audits. We understand that users entrust the funds to Arbitrum, so we will attach great importance to the safety of users’ funds.
As far as the “release candidate version” is concerned, we will invite everyone to participate and help us with stress testing. I believe that everyone will not be disappointed after the mainnet is launched soon.
The difference between Arbitrum and other projects is that the first day our mainnet goes live, everything about the project will be made public, and everyone can be invited to participate in the mainnet.
Moderator: Thank you Steven for introducing us to the follow-up development process of Arbitrum.
The sixth question: We are also very concerned about the challenges and overall planning of Arbitrum after its mainnet launch.
Ed Felten: At present, our focus is on the mainnet online, to ensure that the mainnet transition process is as smooth and safe as possible. In the future, the first thing I will focus on is scalability.
Scalability
Although we have done a good job in terms of expansion and cost, I hope to be able to get further improvements in performance, mainly through innovative engineering methods. For example, how to develop the virtual machine EVM system and how to set up nodes to further improve performance. It is expected that in the future, when the traffic on Ethereum further increases and the throughput demand further increases, we can meet the demand without the bottleneck problem that many projects are currently facing.
Programmable effort
We hope to allow everyone to write smart contracts in different ways. For example, now we have a project that allows you to compile the smart contract you write. You can write smart contracts in languages ​​other than the Solidity language, and it can also run on Arbitrum. At the same time, it can interact with a virtual machine written in Solidity language. This is an advancement in programmability. Using this method can allow outside developers who are not familiar with blockchain programming to enter.
In summary, the focus is on scalability and programmability, as well as better development tools.
Interactive Q&A
Question: A very long waiting period is required for assets on the second floor to reach the first floor. What do you think of the guests during this waiting period? How does Arbitrum or its ecological project solve this problem?
If the assets are transferred from the first floor to the second floor, or the things on the first floor need to be used on the second floor. This time is determined by the time on the first floor. But on the contrary, if you want to transfer assets from the second layer to the first layer, or call the second layer things from the first layer, if the Optimisitic Rollup protocol is used on the second layer, the waiting time of the protocol layer will indeed be longer. It needs to be emphasized that this is indeed an agreement problem, mainly because the solution will have a challenge period. You have to wait for a period of time and wait for someone to raise an objection or no objection before making a final decision.
This is why you may have to wait for a few days at the protocol layer to withdraw. But now there are projects running in the Arbitrum ecosystem trying to solve such problems, including those running on the Arbitrum testnet. Allow users to do it right away. Although there are huge differences in the technical implementation methods, the essence is the same. Either exchange or swap assets between the first and second floors, or someone else will lend you assets so that you can obtain assets in advance. Over time, users will forget the need to wait. And exchanges will soon use such a solution, so that there is basically no waiting period for deposits and withdrawals. For users, the issue of waiting period will become less and less important in the future.
Question: Recently, private transactions and preventing “scientists” from running away are relatively big problems. I would like to ask the next guest how to solve this aspect on Layer 2?
Steven: Regarding solving the problem of placing orders in advance and grabbing orders. This issue is indeed a conscious concern of Arbitrum. I co-wrote a paper with others at Cornell before, and I studied the issue of robbing orders (scientists rushing away). I started thinking about this issue a long time ago. Arbitrum has a good solution. Currently, the aggregator collects and sorts the transactions. What’s more, we use the sorting by the miners of the first layer, so that we can ensure that the sorting sequence is at least as good as the first layer and not worse than the first layer. This is the current status quo.
In the future, we will optimize this program even more. In the future, we will introduce another party, the “sequence party” mainly provides delays below one level. After a transaction is issued, the speed of receiving the transaction and responding even before the one layer includes your transaction.
It is more difficult to do this. Because sorting is equivalent to a considerable right. If you take advantage of this right, MEV runaway problems will arise. We do not want to give this sorting right to users or any party.
It happened that I had another paper published last year at Cornell University, and proposed a solution “Fair Sorting Byzantine Fault Tolerance Mechanism.” The order of fair sorting is that the transaction is brought up, and the order of entering the sequence is the order of final discharge. The sequencer or sequence node is responsible for sorting. This solves the MEV problem.
MEV exists because the party in charge of sorting now has huge rights to adjust the order. But after the introduction of the “fair ordering” mechanism, there is no possibility of adjusting the order.
To sum up, the MEV problem on Arbitrum is no worse than one level. And over time, with the introduction of sequencer and fair sorting mechanism, the situation will get better and better. For users, there is no need to worry about malicious nodes harming their interests by rushing away. This is indeed a big problem for Ethereum and blockchain applications. For me, the current Arbitrum solution is the best.
In terms of privacy, it can be divided into user privacy and contract privacy. Regarding user-level privacy issues, the second layer has been able to achieve neither improvement nor worse than Ethereum. For example, on Ethereum, you can create a new address and create a private key. In the beginning, these were not made public, they were all personal privacy. But since every transaction is public, someone who is interested can track more of your transactions and finally link the account to the individual one by one. In terms of user privacy, the second-tier technology has neither improved nor deteriorated compared to Ethereum.
As far as contract layer privacy is concerned, contract privacy means that the internal state of the contract is not public, or the transaction executed through the contract is not public. In the first version of Arbitrum, because it is a trustless mechanism, if you want to make the contract trustless, it means that the contract must be public and can be viewed by everyone. If the parties to the contract are limited, there are some technical means to realize the privacy of the contract.
On the one hand, side chains can be used, such as the side chains that have been planned in the Arbitrum roadmap and will be launched after the mainnet. There are also some other technologies, which are also explained on the roadmap. In time, you will see that many privacy technologies will be introduced on Arbitrum to ensure that contracts with limited parties can achieve privacy at the contract level.
