We continue our series of educational articles and today we’ll look at some professional tips in the auditing smart contracts on Arbitrum blockchain.
In this article we will focus only on those aspects that can be really useful for auditing Arbitrum-based projects!
Everything you see below is based on our personal experience!
And today, dear readers, it will be made available to you! We also encourage you to read our earlier article, which contains a wealth of auditors’ and developers’ useful advice:
First and foremost, we would like to express our sincere gratitude to the creators of Arbitrum and its ecosystem projects, everyone who supports it, the Authors of all the resource materials, and of course our brilliant auditors who have helped us by revealing much-needed information and lifting the curtain of secrecy!
We can confidently say that such tips can be read publicly in a few places, and our blog is one of those places. The following will be our observations — only dry facts for auditors, tricks and the best life-hacks shared by our best auditors.
Let’s get started! By the way, there are some vacant slots now so if your project needs an audit — feel free to write to us, visit our public reports page here.
Essentially speaking, Arbitrum is a Layer 2 network on top of Ethereum mainnet, with much faster and cheaper transactions. It was created by Offchain Labs. The company raised $120 million in a Series B funding round in September 2021.
Here are some statistics:
Arbitrum average block time: ~0.26s;
Ethereum average block time: ~12.1s;
Arbitrum average transaction cost: $0.2–0.3.
The Ethereum Virtual Machine (EVM) is also supported by Arbitrum, allowing Ethereum DeFi developers to integrate their decentralized applications (dapps) with Arbitrum with almost no modifications required!
Please review the following framework, which is recommended by our team, in order to better understand what we will discuss next and to more clearly differentiate L2 from L1:
Let’s analyze why Arbitrum achieves such results!
Arbitrum relies on the Optimistic Rollup technology (used to scale Ethereum). A bundle of transactions from L2 (Arbitrum) is formed into a batch and sent to L1 (Ethereum), where it is then approved by validators.
Batch sending and validation are designed so that Ethereum nodes are not executing every L2 transaction as in the case of L1, so throughput is much higher and transactions are cheaper.
Currently, both Arbitrum and Optimism operate with a single centralized Sequencer that is in charge of ordering all the transactions it receives and is assumed to work honestly in a first-come, first-serve manner. With it, there are plans to decentralize the sequencing role with whitelisted or community-voted L2 nodes:
Client software can do remote procedure calls (RPCs) to an Arbitrum node, using the standard Ethereum API, to interact with an Arbitrum chain.
Nodes will forward your transactions to the Arbitrum Sequencer, which will report transaction results just as an Ethereum node would–but much faster, typically around one second.
The volume of gas per transaction in Arbitrum consists of two components:
L1 Gas:
Paid to cover the future batches on L1. It is the majority of the commission and depends on the calldata size of the transaction and the calldata value in L1.
At the time of the transaction, you can only estimate its approximate ratio to the size of the future batches. In other words, the L1 component is meant to compensate the Sequencer for the cost of posting transactions on L1 (but no more). (See L1 Pricing.)
In addition to the three transaction types currently supported on mainnet, Arbitrum adds additional types listed below and documented in full detail here.
L2 Gas:
Works similarly to commissions in Ethereum Mainnet — it is a transaction execution fee on L2. The L2 component covers the cost of operating the L2 chain; it uses Geth for gas calculation and thus behaves nearly identically to L1 Ethereum.
One difference is that unlike on Ethereum, Arbitrum chains enforce a gas price floor, currently 0.1 gwei on Arbitrum One and 0.01 gwei on Nova (See Gas). L2 Gas price adjusts responsively to chain congestion, ala EIP 1559. See 2-D fees for more information on this topic!
Because the main obstacles that the auditor may have while auditing projects on Arbitrum are logical, the first suggestion for any firm will be in competent development, which results in solid documentation and reliable tests.
It sounds too simple to be true, but be sure it works and it only proves itself over time!
We will not go into detail in this article because we assume you, dear reader, already have a sufficient understanding of the Arbitrum ecosystem, so we strongly advise you to visit their knowledge-base and study the project documentation for a better understanding:
In the Arbitrum network, block.number will return the approximate number in L1 at the time the sequencer receives the L2 transaction. To get the L2 block number (L2 has its own block numbers), you need to use ArbSys.arbBlockNumber()
block.timestamp is similar in behavior to L1, but two different blocks in L2 can have the same block.timestamp, unlike in L1. For details, see Block Numbers and Time.
Since the PUSH0 opcode is not yet supported, when using the 0.8.20 compiler and above you need to use an EVM version lower in block than the Shanghai update. Compilers starting from 0.8.19 and below are fully supported.
Arbitrum chains include a number of special precompiles not present on Ethereum; see Common Precompiles / All Precompiles. Of particular note is the ArbAddressTable, which allows contracts to map addresses to integers, saving calldata / fees for addresses expected to be reused as parameters; see Arb Address Table tutorial for example usage.
You can deploy Solidity contracts onto Arbitrum just like you do Ethereum; there are only a few minor differences in behavior. See Solidity Support for details.
Check out: mainnet transaction receipt fields, L1 to L2 Messaging, mainnet block fields.
Arbitrum’s L2 block hashes should not be relied on as a secure source of randomness (see ‘blockhash(x);) Also check out this resource & — tend to use Chainlink!
…And a few other minor differences! We will provide even more details in subsequent articles, but for now, let’s continue with our initial evaluation.
One of the primary issues with Arbitrum is its high gas costs for users when they withdraw funds from the Arbitrum network to the Ethereum mainnet.
These gas costs are due to the fact that Arbitrum uses a rollup architecture, which requires users to pay gas fees to transfer assets between the rollup and the Ethereum mainnet:
Another challenge that Arbitrum has faced is network congestion, which has resulted in delayed transaction processing times and higher gas fees. This issue is not unique to Arbitrum, as it is a common problem for many Layer 2 scaling solutions that rely on Ethereum’s network to function.
Since Arbitrum’s system is currently run by a centralized team of developers, there have also been some worries about its centralization. Even though this isn’t necessarily a problem in and of itself, some people are worried about the possibility of censorship or other types of network control.
Despite these challenges, Arbitrum has continued to gain traction as a scaling solution for Ethereum, and its developers are actively working to address these issues and improve the network’s performance and usability!
There is no mempool on the Arbitrum (keep in mind the centralised Sequencer) so there is nothing to front-run, but in our opinion this does not negate the possibility for MEV to exist here!
We hope that this article was informative and useful for you! Thank you for reading! What instruments should we review? What would you be interested in reading about in our blog?
If you still have questions, please feel free to ask! We will be happy to answer every question you have! The best answers and questions may be included in the next blog post!