Talk to an Offchain Labs engineer. How does Arbitrum solve the problems faced by Rollup in ModuLar Oriented?

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

Original article by Vision, Metastone Group   

Before the "Rollup Meetup" event held by Metastone Group, we invited Jason, an engineer from Offchain Labs, to talk about the cutting-edge technology topics in Rollup, including DAC and Anytrust. Especially the current more hot. Ip-4844 and what might erupt in the next narrative. RaaS, in addition, decentralized Sequencer  The Metatsone Group researchers are also concerned about the new orientation of ModuLar Oriented.

Topic one: Arbitrum development history

Vision: At present, the discussion about Arbitrum on the whole network is also very hot. Could Jason briefly introduce the development course of Arbitrum from its founding to today?

Jason:Well, I express my views on the entire process for Arbitrum, first of all, we are in 21 years in May on the line of our test network, after May on, the test network is not open to the public, just invited some project parties, came to our deployment, Get a taste of some of our web experiences above, but also a few improvements. Finally, we launched our first mainnet on August 31, 2000, which is a technology stack we now call cLassic. Although it is relatively early, the stack has implemented interactive fraud proof, and Optimistic Rollups has all of its related features deployed on it. It was already fully EVM-compatible, Optimistic Rollups, and as a result we saw very high on-chain activity after release.

Jason:At the same time, of course, after we went online, we may have encountered some problems in capacity expansion because this technology stack was relatively early generation. For example, during the Odyssey in June, 2002, gas increased a lot due to insufficient throughput. We have also noticed these problems. Therefore, in the same year, on August 31, 22, we launched our second generation technology -Arbitrum Nitro, the second generation technology stack we are directly in the first generation of the main network upgrade, after nitro's main network online, our throughput is about seven times more than before. For example, currently based on nitro, our fastest output time per second is about 0.25 seconds per block, and the maximum Limit per block is 32 million gas, which is basically an order of magnitude larger than the current EVM can achieve.

Jason:In fact, the best example of this was last month when we made this token cLaim. At that time, the throughput TPS of our EVM had already reached three digits, and our main network did not experience any network downtime. It's just that our sequencer is still working out. At that time, many users were unable to connect mainly due to the problem of third-party RPCS not being able to connect. But this sequencer of ours is actually running very smoothly and constantly sending this batch to L1.

Topic 2: About state expansion

Vision: At present, the whole blockchain needs to host a relatively large number of such users. In addition to solving the throughput problem of transaction execution, there is also a problem that everyone is concerned about: state expansion. If hundreds of millions of users want to hold various types of such assets and application status on the chain in the future, The problem of state explosions may also arise. I would like to ask what is Jason's opinion on state expansion?

Jason:First of all, Ethereum itself is also doing state expiration to solve this problem, and actually including Layer2, I first explain a mechanism of L2, in fact, we put the transaction DA above L1, and the DA is actually including the transaction input and transaction order. Because we know that EVM is now a single threaded execution environment, and since it is a single threaded execution environment, we know that if the input and the order of the input are known, then the output can only be unique, which is why L2 can put DA in L1, And then at the same time you can read DA directly to synchronize the L2 network, which is that if the state sum on Layer2 is large enough, you can actually introduce these state expiration, and after the state expiration, if you want to query later, you can query in some other host, Or you can just run a node, read L1 and then re-execute the DA, and you can get the state back.

Jason:In this case, unlike the other side chains, if you lose the block information of the side chain, or the block head, block body, and there is no way to synchronize from other places, then the state will be completely lost. But since we put the state in L1, and if L1 is Ethereum, since Ethereum nodes are large enough and there are many infrastructure providers, there is no need to worry about Layer1 not being able to get this data, so L2 in the future state pruning, It's going to be more advantageous than these side chains.

Topic 3: Centralization of DAC

Vision: The next problem is that Celestia, which is currently focused on doing only DA, which is data feasibility, uses DAS, which is a sampling of data, and then in addition to the Rollup expansion solution, there's an off-chain Validium, It relies on the third-party committee for data availability, and then I learned that Arbitrum Nova also adopts this DAC method. I want to ask the logic of Jason's design for Arbitrum at the beginning. Another question is whether there will be a problem of centralization due to the small number of committees in the community.

Jason:A technology stack of Nova is based on our Anytrust, which technology is actually the same code base as Arbitrum Nitro based on our Arbitrum One, but the mode of starting is different between them. Different patterns under the same code base. Then, for data availability, Nitro directly uploaded this DA to L1, while Anytrust would upload this DA to DAC. After receiving this, DAC would sign this data, issue a certificate, and then send it back to sequencer. sequencer then uploads this certificate to L1. This is a basic implementation logic of Anytrust.

Jason:To return to the previous question, will DAC introduce a serious problem of centralization? First of all, for DAC, we have been constantly expanding the data of our DAC, that is, the size of a node. We can see that there are a lot of current DAC, not only Web3, but also some big Web2 manufacturers, which are running our DAC nodes. In addition to the DAC committee, we actually have a Mirror mechanism, which means that if you are not a DAC but want to participate in the network, you can also run a common mirror, in which case you can synchronize some stored data of other Dacs. Then others can get data not only from the DAC, but also from here in the mirror.

Jason:In fact, this is a double insurance to prevent DAC from failing to obtain a DA in case of data loss. In addition, the DAC submitting the certificate to Rollup has the advantage that it greatly reduces the cost of the DA uploaded by sequencer to L1. Because what we upload now only needs a certificate, which is actually very small relative to the size of DA, it can also greatly reduce the network gas charging under the anytrust mechanism. At the same time, if you actually pay attention to the test network of Ethereum GoerLi two days ago, you will know that Ethereum GoerLi before, it was due to some network activities, so the gas fee of goerLi would be very high. At that time, In fact, at that time, the ETH on GoerLi already had a price, because of the bridge in Layer0.

Jason:If you compare Anytrust's gas overhead at the time, you can see that Anytrust's gas overhead is even lower than that of an Ethernet test network at the time. Therefore, this is a great advantage of Nova, that is to say, the cost of our Anytrust gas is very, very low. You can even reach a price of less than 1 cent if it is an ordinary eth transfer. This is the current some other networks are unable to achieve this price.

Jason:Also for Anytrust, if DAC does evil, because we have a mechanism that falls back to Rollups, we can urgently roll back to Rollup, After we found that the number of DAC signatures in any trust fell below our hypothetical threshold, the network would stop putting DA into DAC and instead put it into L1 using the same mechanism as nitro.

Jason:In contrast to the side chain, if the side chain they do the side chain that validator falls below a safety mechanism of 66% or 51%, it is actually exposed to a dangerous environment, but in our words, it is possible to go right back to the Rollups and then continue to push the state of the web correctly, and the combination of the two, It not only reduces one gas overhead of the chain, but also enhances one security aspect of the chain.

Topic four: The future of RaaS

Vision: The other optimism that I've read so far is the optimism with which op put out Layer 2 Rollup as a Service based on op stack. In fact, the design logic is similar to Starkex customizing a DApp Chain-type service for other applications like games or sociaLfi projects, At the beginning of its design, Arbitrum separated Arbitrum one and Abitrum Nova from each other. One was responsible for the derivative services on the chain like defi and others, while Nova was focused on gaming or sociaLfi. I would like to ask, for example, did we also consider such a direction of RaaS when designing this logic? And what about rolling up as a service in the future, or specifically formulating the direction of such an ecological application chain?

Jason:In fact, regarding this problem, we have changed the authorization mechanism of our Arbitrum last month, that is, in March, which means that after that, you can deploy the new Layer3 network on Arbitrum without permission. You can choose Nitro to deploy the L3 network, or Anytrust to deploy the L3 network. In these cases, you can directly deploy the L3 network without our permission. However, if you want to directly deploy on Layer1, that is to say, deploy a new Layer2, you need to apply to the DAo of our Arbitrum, and then need to be approved by DAo to run.

Jason:This way, you can deploy your AppLication Rollups on top of us and have your AppLication Rollups capture the ecological value of Arbitrum and Ethereum.

Topic five: Arbitrum Nova and Arbitrum One

Vision: Considering the whole Arbitrum, at present, all projects in the ecosystem are mainly defi projects, including the well-known projects GMX and RDNT, so the whole chain activities are mainly concentrated in Arbitrum One. I want to ask is that compared with one, Are there any good projects that I can experience on nova? Currently, the user retention of gamefi and sociaLfi is not particularly high. Would you like to ask Jason's opinion on Nova's user retention of gamefi and sociaLfi?

Jason:OK, because I did technology here, so I may not be so professional in ecology, so I can answer from a technical point of view. Nova, as I mentioned earlier, is a leading implementation environment with a low gas price, which fits the needs of Gamefi for some of its more expensive metrics. Because some DApps in Nova need high throughput, because each transaction needs to pay gas, so the lower the price of gas is the better, so it also fits their needs well.

Jason: At the same time, such as you said just now that some of these above the Nova ecology, can actually the portaL to our (https://portaL.arbitrum.io/nova) to the query above, Our portaL records some of the most popular Nova eco-apps right now, and then some gamefi, so I suggest you check it out on our portaL.

Topic six: Decentralization Sequencer and anti-censorship issues

Vision: Recently we learned that the main network of zkSync era went online around March 24, but their Matter Labs said that the whole sequencer of zk-Layer2 was still not decentralized enough. Then add a developer who also got to know Starkware some time ago, and he used substrate on Poca's side to create a decentralized Starknet sequencer. Would like to ask Arbitrum what kind of point of view is arbitrum in sorting too centralized at present? And then what are the ways to solve this problem?

Jason:First of all, this sort centralization is actually not the same problem as some other node centralization. The collator doesn't have the power to do any evil, because the collator simply packages up the transaction and uploads it to L1, you have no way to sign the state, or guarantee the state, it simply aggregates the transaction, Then the transactions are sorted and the sorted transactions are synchronized to other nodes in the network and uploaded to L1.

Jason:That is to say, the transaction sequencer broadcast did not broadcast the final state of this transaction, it did not elaborate any subjective opinion, but simply sorted this transaction. Then many people might say, if there is any examination of this transaction during the sorting, Or deliberately refuse to do some transactions above, of course, we have to solve this problem.

Jason:We also opened a deLay inbox on L1, and added a function to deLay's inbox, that is, you can send a transaction in L2 directly in deLay's inbox. When you find that the sequencer is reviewing your transaction, Or in the case of intentional rejection or MEV of your trade, you can package your trade into L2 in that way, so that you can avoid the mechanism of sequencer to carry out some potential evil. So it can be seen here that if sequencer does evil, at most it makes this transaction be examined, but there is a mechanism to carry out this review and avoid it.

Jason:So the centralization of sequence is not to say that the centralization of other networks may harm the security of the network. It does not, but it has these solutions. Of course, we will also explore the decentralized sequencer to some extent. In fact, in addition to this, we will also promote the security of this verifier. Compared with sequencer, the security hazard of the centralization of the verifier may be greater, because the verifier will make a pledge guarantee on the state, and this state is actually the state on L2 recorded on L1, which can be directly read by the bridge contract. This is then used for an asset step out from L2 to L1. That's why we're also pushing for decentralization of validators.

Topic 7: The future of Web2 development increments

Vision: The last question is whether Arbitrum will have any more technologically worthy plans for the next year after completing an ecological incentive. You can elaborate on the technological Roadmap in detail.

Jason:Well, not until 2024, but by the end of this year we will be launching styLus, which we will implement with WASM in this virtual machine. And with WASM, you can deploy your contracts in WASM mode, that is, you can deploy your contracts in C++ or Rust, and then at the same time you deploy the contracts in those languages, which share the same state tree as the EVM contracts. If the contract is deployed through WASM, it can be 10 times more efficient. If you are using EVM and currently use some Library or other components, you can also discard the existing component and deploy the new component via WASM in a way that makes a re-call within the contract.

Jason:This is also one of the strategies we have been talking about for EVM Plus, which means that in the future, we will not only be able to be perfectly compatible with EVM, but also support some of the features outside of EVM, which will make us more scalable and better user experience. And then at the same time before launch, which is very soon, we will also deploy a new Devnet, the developer network, and then give developers a taste of it.

Jason:In order for blockchain to access the next order of users, it must support the next order of developers to enter your ecosystem. And now a lot of Web3 inviting Web2, some of the developers that are coming into the current Web3 are not comfortable with Solidity, but by using WASM you can write this contract in a language that they are already familiar with, so we can host more developers, It is also compatible with current Web3 developers.

Vision: OK, thanks Jason. Today, I not only answered some questions for Arbitrum, but also answered some important questions in this direction of blockchain Medura Oriented.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia