The development and deployment experience of the Arbitrum mainnet, see what these seven developers have to say

This article is sourced from ChainNews, interview conducted by: Pan Zhixiong, interviewed teams: DeGate, DODO, EthSign, imToken, MaiZi Wallet, MCDEX, WePiggy.

As one of the earliest EVM-compatible Rollup scaling solutions to go live, Arbitrum has opened up mainnet access to developers. It has been running for exactly one month, and many domestic and international development teams are actively trying and deploying it. Overall, there is optimism about the maturity of this network, but some components, such as the block explorer, are still in the early stages, which may affect project development.

This Layer 2 network is referred to as Arbitrum One, to distinguish it from the Arbitrum technology. Although it has been deployed on the Ethereum mainnet, the team currently refers to it as a beta version of the mainnet to ensure security, and it is limited to developers for early deployment.

Outside of Arbitrum, Optimism is a similar technical solution, but since its mainnet launch in the first quarter, which was limited and selected for collaboration with Synthetix, it has not undergone broader testing and has delayed its launch once, stating it will officially go live in July.

The other two Rollup scaling solutions based on zero-knowledge proofs may launch even later. Matter Labs has stated that zkSync 2.0 will launch in August, and its compatibility is somewhat worse than the first two, as it does not support some less commonly used EVM opcodes; StarkWare's StarkNet solution only launched its testnet this month, with the mainnet expected to be ready by the end of this year at the earliest.

To gain a more intuitive understanding of the current state of Arbitrum One, ChainNews interviewed seven teams that are integrating into the Arbitrum network, including DeFi, applications, wallets, and other upstream and downstream entities. We hope to restore a more comprehensive view of the state of Arbitrum's first mainnet through the different perspectives of these developers.

Overall, these development teams have given very positive evaluations of the maturity and completeness of Arbitrum One, with most tools and infrastructure already supporting or soon to migrate to support it (such as Chainlink and The Graph).

The main point of criticism is the current inadequacy of the block explorer, which may affect development speed. However, as the most widely used block explorer in the industry, it should not be difficult for Etherscan to add more features to the block explorer for Arbitrum One. Additionally, the differences in gas calculation methods have also been mentioned multiple times, and developers need to pay attention to these differences.

Another interesting situation is that since Arbitrum One uses a mechanism similar to fraud proofs, which is a key security feature of the network, one might expect developers to focus on various tests and drills related to the network's fraud proof. However, this has not been the case. In the early stages, the network may be maintained by official or trusted third parties, so security should not be an issue.

Finally, regarding the timeline for the official opening of the Arbitrum One mainnet to the public, evaluations vary. The most optimistic teams believe that the network is already sufficiently mature to be opened, while more cautious development teams think it may take up to six more months.

In addition to the above summaries, this interview mainly discussed the following topics:

• Is EVM compatibility really as advertised by the official, and what is the overall migration workload?

• How stable is the network? Can development tools and infrastructure be migrated seamlessly?

• What is the actual performance and cost of the Arbitrum network?

• How long do you estimate until the mainnet can be fully opened?

Question 1: When migrating to Arbitrum, did the smart contracts on the original Ethereum L1 need adjustments? What is the overall workload for this migration?

MCDEX: No adjustments were made to the smart contracts during migration. We may need to review aspects related to block and time. Since our token issuance is on L1, we have some cross-chain communication needs that require coding.

DODO: No adjustments were needed; the workload was minimal. DODO has a multi-chain strategy, so when migrating from Ethereum to BSC initially, we prepared many scripts. However, some work was needed on the frontend product, as DODO's products are relatively complex, with many caches and data middleware, which took some time to migrate.

WePiggy: The smart contracts on the original Ethereum L1 did not need adjustments when migrating to Arbitrum. We only upgraded the OpenZeppelin contracts to the latest version.

DeGate: Generally, no adjustments are needed for the smart contracts; we did not encounter any issues. If block and gas-related data are used, please refer to the differences below:

《Differences from Solidity on Ethereum》

imToken: The workload is not high because it is EVM compatible, so the process was relatively smooth. However, the workload was more in the environment and system monitoring, requiring an additional system for maintenance and monitoring.

MaiZi Wallet: We can highlight the cross-chain smart contracts for assets. Arbitrum provides a default Token Bridging mechanism, where all ERC20 and ERC721 assets on L1 have a default automapping contract on Arbitrum, eliminating the need for project parties to redeploy ERC20 or ERC721 contracts, which is very convenient. We believe this mechanism will migrate a large amount of L1 assets to Arbitrum L2.

EthSign: Apart from needing to reconfigure the Truffle network settings, we currently cannot deploy. Preliminary assessment indicates that Arbitrum's EVM is not compatible with OpenZeppelin contracts (e.g., the basic Ownable), and logic that runs normally on other networks will revert during deployment.

Question 2: Is the infrastructure on Arbitrum similar to that on Ethereum L1, such as development tools, IDE, Chainlink, The Graph? How stable is it, and have you encountered any issues?

WePiggy: We have been tracking Arbitrum's development progress since the Kovan3 version, experiencing Kovan3, Kovan4, Kovan5, and other versions in between. During our testing, we discovered some issues, such as block synchronization problems between L1 and L2 and ETH contract transfer issues on L2, and we actively provided feedback to the Arbitrum development team, which they acknowledged.

MCDEX: The development tools are completely consistent, which is a very impressive experience. Chainlink and The Graph are in the process of migrating to the Arbitrum mainnet. The only issue is that the explorer currently does not provide enough information, but this is not a major problem. Etherscan is also deploying and will improve the explorer experience.

DODO: Not yet. Development tools and IDE have completely reused L1. The Graph is a middleware, and its stability remains to be tested (as the mainnet is not yet open to a large number of users). Chainlink belongs to other project parties and is also not fully online, currently in the debugging phase.

DeGate: Due to compatibility with Solidity, development tools and IDE can be used interchangeably, but some older versions of tools may have issues, such as encountering failures when deploying contracts with Truffle. Chainlink and The Graph have not been fully deployed yet.

imToken: We use Hardhat for development tools without any issues. The IDE has no impact from the chain, as we have not used or tested Chainlink since we do not use oracles.

In terms of stability, since Arbitrum's testnet has switched, there have been some instability issues in the past, but things have improved significantly since then. Overall, we feel that the Explorer lacks sufficient information due to the absence of Etherscan support, but it is usable. Recently, both Alchemy and Infura have supported Arbitrum nodes, making it relatively convenient.

EthSign: The development tools and L1 experience are basically consistent, but stability cannot be tested due to the inability to deploy.

Question 3: From the perspective of L2 performance, have you evaluated the current performance and cost of Arbitrum?

DeGate: We believe that Arbitrum's costs will mainly come from the on-chain costs of calldata for a considerable period, and its performance bottleneck lies here. With the current Ethereum block gas limit of 15 million, where 30% is occupied by Arbitrum, the average gas cost for L2 transactions is 4500 gas (an ERC-20 transfer is about 1800 gas), estimating its throughput at 1000 transactions per L1 block, or 71 transactions/s.

MCDEX: The cost is about 1/100, depending on the specific functionality of the smart contracts. The calculation method for ArbGas differs significantly from L1, which developers need to adapt to.

DODO: There is already a lot of theoretical analysis available in the market; the actual situation will need to be assessed after a large number of users flood in.

WePiggy: Based on our testing on the test network and mainnet: Arbitrum's GasLimit is relatively high, but GasPrice is very low, making the overall costs significantly lower than on L1, and the performance is extremely fast, basically achieving second-level transactions.

imToken: Currently, we do not have this information because it requires interactive testing, but we have only tested our own deployment and have not conducted interactive tests with other projects.

Question 4: Have you observed on-chain data, and has Arbitrum's fraud proof design undergone actual drills? What were the results?

DODO: We have not observed fraud proofs on the mainnet, but we believe the Arbitrum team has conducted thorough drills.

imToken: No, this may require running a node to observe.

MCDEX: We have not tried it.

WePiggy: We do not have experience participating in actual drills in this regard.

DeGate: We have not observed the challenge process in practice.

Question 5: As a mainnet aimed solely at developers, how long do you estimate it will be until Arbitrum is fully open for actual use? What basic infrastructure do you think this ecosystem still lacks?

DODO: We believe it can be opened now, but the Arbitrum team clearly wants to prepare more thoroughly, as this is a highly anticipated launch. Taking it slow is fine, as long as it does not fail. In terms of infrastructure, we feel that we are not lacking; we just need to test stability to ensure it can handle a large volume of traffic.

WePiggy: Although we have officially deployed the WePiggy protocol contracts to the Arbitrum One network for over half a month, considering the implementation and improvement of infrastructure such as browsers, cross-chain bridges, and oracles, we estimate that the Arbitrum development team will need another month to officially open the network to ordinary users.

Currently, most Ethereum infrastructure has announced plans to enter the Arbitrum ecosystem, and we can only quietly hope they complete their development, deployment, and testing work soon; we cannot rush them. Personally, I think the infrastructure still lacking includes a more developer-friendly SDK and more backup nodes.

MCDEX: It is difficult to judge the opening time. There is no lack of infrastructure, as everything is migrating.

DeGate: I feel it will take another 3 to 6 months; we are still in the early stages of system improvement and lack more trusted third-party verification nodes to participate in governance, as not every developer can run a relatively heavy verification node.

MaiZi Wallet: Currently, there are still some basic tools in the internal testing phase, such as the Arbitrum version of Etherscan, and the official block explorer is not very user-friendly. For example, the lack of contract verification functionality may lead to some security issues. From the perspective of node operation and basic functionality, we have tested and found no major issues. MaiZi Wallet has also completed support for Arbitrum and will synchronize the release for ordinary users once fully opened.

EthSign: The most lacking aspect is actually a fast way to obtain tokens. The current bridge speed is too slow, and token transfers across the bridge take dozens of minutes. Additionally, the incompatibility with industry-standard contracts like OpenZeppelin needs to be fully resolved.

imToken:

• A more complete explorer;

• A gateway or solution for fast withdrawals;

• Currently, projects are relatively developing and deploying independently, requiring interactive testing.