first level title
Architecture Summary
Since Arbitrum is a L2 scalability solution for Ethereum L1, part of Arbitrum's architecture is on L1 and some is on L2.
The component of Arbitrum on L1 is EthBridge, which consists of a set of Ethereum contracts.
EthBridge is responsible for arbitrating the Arbitrum Rollup protocol and maintaining Arbitrum rollup inboxes and outboxes on the Ethereum chain.
Users, L1 contracts, and full nodes can send their transactions to the Arbitrum chain through inboxes and outboxes on the Ethereum chain and observe the results of those transactions.
Arbitrum Virtual Machine (AVM) is a function provided by EthBridge, which is a gateway between L1 and L2.
AVMs are able to read inputs and perform calculations based on those inputs to produce outputs.
ArbOS runs on AVM, ensuring smart contracts are executed on the Arbitrum chain.
image description
first level title
Arbitrum Rollup Agreement
The order of messages in the inbox determines the outcome of the transaction.
Therefore, anyone who checks their inbox can know the outcome of the transactions, as long as they execute them themselves.
The Arbitrum Rollup protocol is responsible for confirming the outcome of transactions that have occurred.
Users participating in the protocol are called validators; if a validator deposits ETH in the staking contract, they become stakers and can stake blocks on the Arbitrum chain.
Neither validators nor stakers require permission.
In terms of security, only one honest validator is needed to ensure that the Arbitrum chain executes correctly.
This makes the Arbitrum chain as trustless as the Ethereum chain.
Arbitrum assumes that at least one validator is honest.
The Arbitrum Rollup protocol acts on the Arbitrum Rollup chain. The latter is a chain of Rollup blocks, independent of the Ethereum chain.
The role of validators is to propose new blocks and add them to the Arbitrum chain.
Every proposed block is eventually confirmed or rejected by the protocol.
Each block contains several fields. Except for the block number field, the data in each field is an assertion of the block proposer, but not necessarily correct.
If any of the assertion fields are incorrect, the protocol will eventually reject the block.
All proposed blocks have a confirmation period.
pledge
pledge
In order for a Rollup block to be added to the chain, stakers must stake on that block.
Staking is permissionless and anyone can stake any block.
Once you bet on a block, you cannot get your deposit back until the block is confirmed.
Once you bet on a block, it means that you believe that this block is correct, and that every block on the chain from the latest confirmed block to the block you bet on is correct.
If the block you bet on is incorrect, or a block on the chain from the latest confirmed block to the block you bet on is incorrect, your deposit will be forfeited.
If you don't want to bet on a certain block, you can bet on the latest confirmed block.
If you bet on a block, you can extend your bet to any blocks following that block.
The amount of collateral required is dynamic.
There is a specified base pledge amount parameter on the Arbitrum chain, which will be used in most cases.
To prevent an attacker from slowing down the network at the expense of staking, the stake is multiplied by a factor that grows exponentially with the timeout (the timeout is counted from the deadline of the first pending block).
This is to increase the cost of this type of attack during the attack.
secondary title
challenge agreement
A challenge arises when two stakers stake on different blocks with no inheritance relationship between them, they diverge on a block.
Challenges mainly take place on the Arbitrum chain and are adjudicated by the L1 contract.
The challenge consists of an interactive multi-round split game on L2 and a one-step proof performed on L1.
If a staker disputes a block, the staker who proposed the block will defend his assertion as a "defendant".
The "defendant" pledger claims that starting from the previous block, after the virtual machine executes N instructions, the state of the previous block will advance to the state of the proposed block.
In the splitting game, the staker (Alice), who is the "defendant", takes the first move and divides N instructions into K segments, and the size of each segment is N/K.
Please note that the Arbgas consumption of each stage is equal, but not necessarily equal in the number of steps.
Also note that each paragraph has a start and an end (this is not important, but helps us understand the next point).
The pledger (Bob) as the "plaintiff" also divides the N instructions into K segments (the size of each segment is N/K), and corresponds them to Alice's segments one by one, and finds that one of the segments The end point is different from Alice's.
Bob is actually finding segments that he doesn't agree with.
Next, Bob will perform Alice's original operation, split the disputed segment (N/K in size) into K sub-segments, and then send the segment and the sub-segments to Alice.
Alice performs Bob's original operation and finds the subsegment with a different end point.
The splitting process continues until Alice and Bob find the one instruction they diverged from.
This instruction is sent to the L1 contract, which executes it and then decides the "winner" of the dispute.
The "loser" will lose the pledge, some of which will be destroyed (preventing attackers from hedging bets), and the rest will be rewarded to the honest "winner".
During the entire splitting process, the L1 contract as the adjudicator does not know any information about the instructions, and is only responsible for verifying whether the two parties follow the rules of the game.
During the dispute, all other validators can determine the outcome of the dispute before the dispute is finalized, which means that a soft fork occurs and the validator can continue to submit Rollup blocks on the correct chain.
The challenge period has an enforced duration, i.e. about a week per staker.
Each staker must complete their task within a one-week deadline or “lose the case.”
Like a chess timer.
Verifier
Verifier
Validators are nodes on the Arbitrum chain responsible for monitoring the activities of the Rollup protocol and advancing the state of the entire chain.
Not all nodes are validators.
Offchain Labs expects validators to adopt an active, defensive, or wait-and-see strategy; the protocol does not enforce which strategy they adopt.
"Active validators" continue to advance the state of the chain by proposing new blocks. Only one honest active validator is required on each chain; increasing the number of active validators does not improve the efficiency of the entire chain.
"Defensive validators" monitor the Arbitrum protocol and only take action when they spot dishonesty: either proposing a correct block themselves, or betting on correct blocks proposed by other validators.
Although "wait-and-see validators" also monitor the Arbitrum protocol like defensive validators, even if they find dishonesty, they will not propose or bet on the correct block, and will only issue warnings to other validators.
Offchain labs will run active validator nodes on their flagship Arbitrum chain.
Most of the time, the defensive validators and wait-and-see validators don't need to do anything, so the attacker never knows how many defensive validators there are.
full node
full node
Full nodes on the Arbitrum chain function the same as full nodes on Ethereum, responsible for tracking the state of the chain and allowing others to interact with the chain.
All nodes have a built-in AVM simulator. Therefore, from the perspective of the full node, the Arbitrum chain just calculates the output based on the input, without knowing the actual rollup protocol.
Full nodes can act as on-chain aggregators, helping users increase cost efficiency.
Arbitrum also has a facility to collect fees from users to compensate full nodes for the cost of acting as an aggregator.
Full nodes can also further reduce L1 call data costs by compressing transactions.
The full node submits the compressed transaction to the inbox, and arbOS will decompress the transaction after receiving it.
first level title
sequencer mode
When the Arbitrum chain starts, we can choose whether to enable the sequencer.
Sequencers are full nodes that have the privilege to determine the ordering of transactions in their inboxes.
This privilege allows the sequencer to instantly guarantee the outcome of the transaction.
If the sequencer is enabled for the Arbitrum chain, the inbox is split into two parts:
The first inbox will function as if the sequencer did not exist, i.e. nodes can send messages to this inbox tagged with block numbers and timestamps.
The second inbox will be controlled by the sequencer and only the sequencer can send messages to this inbox.
When sending a message to an inbox, the sequencer can specify a block number and a timestamp with which to stamp the message.
This includes the block number (of past blocks) and timestamp and delta seconds (time in the past) up to the specified delta block.
These deltas typically equate to around 10 minutes in the real world.
When arbOS checks the inbox, it will receive the message with the lowest block number. This block number is either the block number of the normal inbox or the block number of the sequencer inbox.
The number of blocks the sequencer can backtrack depends on the number of confirmed blocks needed to finalize an arbitrum block on Ethereum.
If arbitrum needs to wait for X blocks to achieve finality on Ethereum, then the sequencer needs to go back X blocks to determine which transactions will be processed immediately after its current packaged transaction
When sequencer mode is enabled on the Arbitrum chain, transactions submitted to the sequencer will be finalized x blocks earlier than without the sequencer, but transactions submitted to the normal inbox will be finalized faster than without the sequencer Situation behind x blocks finalized.
This is a positive trade-off due to the large difference between instant OK and 5 minute OK versus 5 minute OK and 10 minute OK.
However, malicious sequencers are able to exploit these privileges to some extent.
A malicious sequencer can censor a user's transactions by not putting them in the sequencer inbox, forcing the user to send the same transaction to a normal inbox after finding out that they have been censored.
Sequencers can also preempt user transactions.
The initial Arbitrum chain will enable a sequencer run by Offchain Labs.
image description
first level title
ArbGas / Fee
The principle of ArbGas is similar to Ethereum gas, which is used to measure the calculation cost on the Arbitrum chain.
However, there is no hard ArbGas cap on the Arbitrum chain, and ArbGas is consumed much faster than Ethereum gas.
A key role of ArbGas is to predict how long it will take to verify the result of a computation.
Each Rollup block contains a statement about the total amount of ArbGas consumption, which means that the difference between the statement in the current block and the statement in the previous block should be an effective indicator of the ArbGas consumption in the current block.
Therefore, when checking the validity of the block, the verifier can set this difference as the gas upper limit. If so many ArbGas are exhausted before the block is executed, it can be determined that the block is invalid and successfully challenge it .
Because the data of these transactions eventually needs to be uploaded to the chain, users need to pay fees.
If that user sends a transaction to the aggregator, part of the fee is automatically paid to the aggregator as compensation.
The remaining fees will enter the fee pool of the network to pay for the service fees that ensure the safe operation of the entire chain.
Fees include L2 transaction, L1 call data, computation and storage costs.
in conclusion
in conclusion
Arbitrum is a L2 scalability solution developed by Offchain Labs: Optimistic Rollup with a multi-round interactive challenge protocol.
The flagship Arbitrum chain was opened to developers on May 28th. Once the projects running on this chain reach the threshold, it will be opened to users.
From the user's point of view, the interactive experience of the Arbitrum chain is no different from that of Ethereum.
Next month, Tracer will deploy Perpetual Swaps on the Arbitrum mainnet. Welcome to follow Tracer's Twitter and join Discord.
Original link:
Original link:
https://tracer.finance/radar/arbitrum-in-under-10/
Translation & Proofreading: Min Min & A Jian
Translation & Proofreading: Min Min & A Jian
