WAGMi Venture: 5 minutes to understand the development history and future direction of Arbitrum

Original source: WAGMi Venture

Original author: 0xMoonda

With the popularity of DeFi and NFT, Ethereum has grown rapidly in the past few years. China has developed into the main settlement layer of the encrypted economy. However, limited by the nature of the blockchain itself, the number of transactions that can be processed at a time is limited. In the case of extremely active transactions on the chain, the competition between users for the limited block space often makes the network congested. Greatly reduce user experience - high gas fees and long pending transactions. In order to solve the above problems, the Ethereum community has adopted the method of on-chain and off-chain expansion. Beginning in 2021, developers began turning their focus off-chain — creating L2 rollups on top of the Ethereum network, and Arbitrum is one such L2 rollup technology.

How does Arbitrum solve the scaling problem of Ethereum?

Arbitrum network is mainly composed of two types of nodes: batcher and validator. Both types of nodes interact with the Ethereum mainnet to maintain the status of an independent chain, which is called L2. The batcher is responsible for recording user transactions in L2 and submitting the data to L1. The validator is responsible for reading data in L1, processing transactions and updating the state of L2. Then the validator will publish the updated L2 state data to L1, so that other nodes can verify the validity of the new state. The whole process is roughly as follows:

· The user sends the L2 transaction to the batcher, often called the sequencer;

p>

After receiving enough transactions, the sequencer will package the data and send it to L1;

< /p>

· validator will read the transaction in the L1 contract and process the local copy in the L2 state;

< p>

After the processing is completed, a new L2 state will be generated locally, and the validator will send the new stateRoot to the L1 contract;

· Other validators start processing the same batch of local copies in L2 state;

· validator will L2 The result of stateRoot is compared with the original stateRoot sent to the L1 contract;

· If the stateRoot obtained by the validator is the same as that published to L1 If the stateRoot is different, the validator will initiate a challenge in L1;

The challenge requires the challenger and the validator who issued the original stateRoot to prove correct in turn What is the stateRoot of;

· No matter which party loses the challenge, its pledge will be cut. If the original stateRoot of L2 is invalid, it will be destroyed by the next validator and will not be saved in L2.

Batcher and L2 transaction data

The batcher uses two different L1 contracts to publish data, one is "delayed inbox" and the other is "sequencer inbox". Any node can send transactions to the delayed inbox, and only the sequencer can send transaction data to the sequencer inbox. The sequencer inbox extracts transaction data from the delayed inbox and mixes it with other L2 transactions submitted by the sequencer. Therefore, the sequencer inbox is the main contract for each validator to extract the latest L2 transaction data. There are three types of batcher: forwarder, aggregator, and sequencer. Users can send L2 transactions to any of the three types. The forwarder sends the L2 transaction to the specified address of another node. The aggregator address as the specified node can be either a sequencer or an aggregator.

The aggregator receives incoming L2 transactions and batches them into a single message that is sent to the delayed inbox. The sequencer also takes incoming L2 transactions and batches them into individual messages, but it sends the messages to the sequencer inbox. If the sequencer stops sending transactions to the sequencer inbox, then any node can request the sequencer inbox to include transactions from the delayed inbox through a smart contract call. This not only ensures the availability of the Arbitrum network, but also resists malicious sequencers. Currently, Arbitrum runs its own independent sequencer on the main network, and plans to decentralize the sequencer in the future.

< p>

Essentially, the task of batcher is to submit L2 transaction data to L1. Once these transactions are processed in L2 and generate a new state, the validator must also submit this state data to L1.

validator and L2 state data

The series of smart contracts that make validators submit and store L2 state data is called rollup. The essence of rollup is a chain connected by different blocks, that is to say, rollup is actually L2. It’s worth noting that the blocks that make up the chain are referred to as “nodes” in Arbitrum’s codebase. In order to prevent confusion with the validator and batcher above, the "node" of rollup will be represented by "block" in the following description.

Because a single block contains the hash value of the L2 state data, the validator can read the data and process the transaction from the sequencer inbox, and then send the updated L2 state data The hash is submitted to the rollup smart contract, and rollup will create a new block with the updated data and add it to the chain. When the validator submits the L2 state data to the rollup smart contract, the validator will also clearly state which block in the current chain is the parent block of the new block.

In order to punish validators who submit invalid state data, a pledge system is introduced in the process. In order to be able to submit new L2 state data to the rollup, validators must stake, they must deposit a certain amount of ETH (or deposit other tokens according to the requirements of the rollup). In this way, if a malicious validator submits invalid state data, other validators can challenge the block, and the malicious validator will lose its pledge.

When the validator becomes a staker, it can be pledged on different blocks. The pledge rules are as follows:

Stakers must stake in any block they create;

< /p>

· Multiple stakers can pledge on the same block;

· Stakers cannot Pledge on the block path. When a staker stakes in a new block, the new block must be a sub-block of the previously staked block (unless it is the staker's first stake);

· Staker does not need to add new collateral when staking on a new block;

· If a If a block fails in the challenge, all stakers who have pledged in the block or sub-blocks of the block will lose their pledges.

If a block meets all of the following conditions, then the block will always be received by L1 and will not be reset :

· Block creation time exceeds 7 days

· Not challenged by other blocks

· At least one staker stakes on it

· p>

If a block meets all of the following conditions, it can be destroyed:

· Its parent block has existed longer than the latest confirmed block (the latest confirmed block is on another branch)

· There is a staker staked on its brother block

· No staker here Block pledge · more than 7 days from the date of block creation

type of validator

Each validator can use different strategies to ensure network security. There are currently three types of verification strategies supported in the network: Defensive, StakeLatest, MakeBlocks (called MakeNodes in the codebase). Defensive validator is responsible for monitoring the blocks in rollup, looking for forks or conflicting blocks. Once a fork is detected, the validator switches to the StakeLatest strategy. Therefore, if there are no conflicting blocks, the Defensive validator will not have any pledge.

If the block contains valid L2 state data, the StakeLatest validator will stake on the existing block in the rollup, And will try to stake on the most correct block in the chain. The StakeLatest validator will generally not create a new block unless it identifies a block containing data in the wrong state. In this case, the validator will create a new block with the correct data and make a mandatory pledge on the new block.

MakeBlock validator will also choose to stake on the most correct block in the rollup. But even in the absence of invalid blocks, MakeBlock validators will create new blocks when staking at the end of the chain, and they are an important role responsible for advancing the development of the chain with new state data.

< p>

L1 transaction and state data storage

transaction data storage

To sum up, aggregator and sequencer receive L2 transactions and submit them to delayed inbox and sequencer of L1 In the inbox, the cost of submitting data to L1 occupies a large proportion in L2. The aggregator receives user transactions in L2, compresses calldata into byte arrays, and then combines multiple compressed calldata into a series of byte arrays (these arrays are called batch transactions). Finally, the aggregator submits the batch of transactions to the delayed inbox. The delayed inbox hashes a batch of transactions and saves the hash to the contract. The workflow of the sequencer is similar to that of the aggregator, but the sequencer inbox must also contain data about the number of messages in the delayed inbox. This data is part of the final hash that the sequencer inbox saves into the contract.

< p>

Status data storage

MakeBlock validator After reading and processing L2 transactions from the sequencer inbox, The updated L2 state data will be submitted to the rollup smart contract. The rollup smart contract then hashes the state data and saves the hash to the contract.

< p>

Retrieve transaction and state data

Even if only The transaction hash and state data are stored in the contract, and other nodes can also view the original data by retrieving the transaction calldata of the data submitted from the Ethereum full node to L1. The transaction calldata sent to the delayed inbox or the sequencer inbox contains all the L2 transaction data processed in batches by the aggregator and the sequencer. The transaction calldata sent to rollup contains all L2-related status data, and there is enough time for the validator to judge whether they are valid. To make querying transactions more convenient, the smart contract sends an event to the Ethereum log, allowing any node to retrieve L2 transaction data or state data.

Since smart contracts only need to save hashes in their storage and not full transaction or state data, this saves a lot of gas. The main cost of Rollup comes from storing this data in L1. Therefore, this storage mechanism can significantly reduce gas costs.

Technical update and progress of Arbitrum

Arbitrum Nitro< /h4>

Nitro is a major upgrade to Arbitrum with improvements in the following areas:

< /p>

· Optimize the compression method of calldata: reduce the amount of data published to L1 to reduce the transaction cost in Arbitrum;

< p>

·Isolate regular execution from error proof: improve L1 node performance and reduce gas costs;

Compatible with Ethereum L1 gas: make the pricing and accounting of EVM operations exactly the same as Ethereum;

· Increase interoperability with L1: such as more closely synchronized with L1 block numbers, support for precompiled Ethereum L1;

· Secure retryable tickets: Eliminate failure modes where retryable tickets cannot be created;

· Geth trace: support for more Extensive debugging.

Arbitrum Nova

Nova is a new chain developed based on AnyTrust technology. It is fully compatible with EVM. It greatly reduces costs by sending data to DAC (Data Availability Committee). Only when DAC fails to complete the processing will the returned data be placed in the chain. Nova adds minimal trust assumptions in the process of processing transaction data - assuming that at least two DAC members are honest. It replaces the method of batching and sending calldata to L1 by the sequencer by sharing the data with the DAC. DAC signs Data Availability Certificates (DACerts) for batch transactions, and only the certificates are sent to L1, which greatly reduces the requirement for L1 storage space. In order to ensure the availability of data, DAC is responsible for running the Data Availability Server (Data Availability Server), and the open REST API allows data batches to be obtained by hashing. Therefore, Nova is designed for games, social networking, and some applications that are sensitive to gas costs.

Arbitrum Virtual Machine (AVM)

Since Arbitrum's L2 transactions are not executed in L1, they do not have to follow the exact same rules as EVM for calculation. So the Arbitrum team built their own virtual machine, the Arbitrum Virtual Machine (AVM). AVM is very similar to EVM in order to support the compatibility of EVM compiled smart contracts, but there are also differences. The difference is that AVM must support Arbitrum's challenge. The challenge requires that the steps of transaction execution must be provable, so AVM introduces code points. As the code executes, the instructions are kept in a one-dimensional array, and the program counter points to the current instruction. The purpose of using the program counter is to find out which instruction to execute takes logarithmic time, which then reduces the time complexity to constant time. Each instruction in the array has a code point so that the AVM can immediately show which instruction is being executed at the program counter. While code points add complexity to AVM, the Arbitrum system is only used when proof of transaction execution is required. In general, the normal program counter will still be used.

ArbOS

ArbOS is Arbitrum's operating system responsible for managing and tracking smart contract resources used during code execution. ArbOS has an account table that tracks the state of each account, and also runs a funding model for validators participating in the rollup protocol. AVM's built-in instructions improve the performance of ArbOS running and its tracking resources. AVM's support for ArbOS enables ArbOS to run certain rules in L2, not necessarily in L1, because any calculation from L1 to L2 will cost a lot of gas, which can save a lot of cost.

Arbitrum Ecological Development Data

Agreement Revenue

This data measures the dollar value of total transaction fees paid by users over a period of time. Since the Nitro upgrade was completed in August, Arbitrum’s protocol revenue has doubled to $40,000. It peaked at $75,000 at the end of October. At present, due to the impact of the macro economy and the FTX incident, it has fallen back to about 30,000 US dollars, a drop of about 60%.

< p>

Independent addresses

Since the mainnet launch, the number of Arbitrum's independent addresses has increased significantly. Entering October, the average daily new address was around 6,000; after November, the daily average new address exceeded the 10,000 mark, which was about twice that of October. , and showed a continuous upward trend.

< br>

Daily active users

From September to October, Arbitrum's active users remained at Around 30,000. After entering October, there was an explosive growth. It is speculated that it is mainly related to the interaction of fighting for airdrops. In recent days, it has reached a high point of the year, and the number of daily active users exceeds 64,000.

< p>

TVL

In September, the TVL of Arbitrum has been fluctuating around 930 million US dollars. On the 8th, it reached a phased high of over US$1 billion. After the FTX incident, it fell to 890 million US dollars and is currently recovering.

< p>

On-chain applications

The top ten TVL applications in the Arbitrum ecosystem are: GMX, Stargate, Uniswap V3, Curve, Sushi, Synapse, AAVE V3, Radiant, Vesta Finance, Beefy. Notably, GMX’s TVL accounted for 48.73% of the total TVL of the top ten apps, amounting to $394 million. GMX is a DEX platform for spot and perpetual contract transactions, focusing on derivatives business, formerly known as Gambit on BSC, and later migrated to Arbitrum to support Avalanche.

< p>

Cross-chain

Currently, there are about 454,000 users using Arbitrum for cross-chain, The total cross-chain amount is 198,000 ETH (about 230 million U.S. dollars based on market price); as of November 21, the number of depositors within 7 days is 20,000, and the total amount of cross-chain within 7 days is close to 20,000 ETH. Compared with other L2 protocols Optimism, zkSync, and StarkNet, except that Optimism has 100,000 deposits within 7 days, the data of the other three dimensions are in the leading position.

< p>

Gas

In terms of gas cost, Arbitrum ranks No. 1 in transfer cost among many L2 protocols Three, the transfer cost is 93% lower than that of Ethereum L1. Swap fees are the second highest among L2 protocols, 96% lower than the cost of swapping at Ethereum L1. (Note: The fees shown in the figure below are floating, but the range of change is relatively small)

< br>

NFT

Taking Opensea as an example, the total transaction volume of the top 5 NFTs in Arbitrum within 30 days is 1025 ETH, which is 103% higher than that of Optimism, which is also an L2 expansion solution. The highest NFT floor price is 0.38 ETH, which is 38 times the highest NFT floor price in the Optimism ecosystem.

< p>

Arbitrum Future Outlook

In summary, Arbitrum is very Good has inherited the DeFi gene of Ethereum, and many DeFi OG projects have migrated to Arbitrum for continuous construction. Their existence has brought a stable user base to the ecology; Arbitrum is highly compatible with Ethereum L1 and supports any EVM language for developers It brings great convenience, and at the same time can share the huge developer community resources of the Ethereum ecosystem; the gas that is 90% lower than the Ethereum main network increases the user's acceptance of on-chain transactions. A very inclusive environment. Secondly, in order to adapt to the high-frequency interaction between games and social networks, Arbitrum has developed a new chain Nova as a solution. It is also a good attempt to isolate it from its DeFi ecology. However, compared with Polygon’s relatively mature games and social ecology, there are still some gap. From this perspective, the future development of Arbitrum at the DeFi level is even more worth looking forward to.

*The above contents of this article are opinions, not investment advice.

Original link

https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia