AIP: ArbOS 31 Proposal Review
Summary
OpenZeppelin, the Security Member of the ARDC, reviewed the AIP: ArbOS 31 “Bianca” proposal and its execution instructions. If enacted, the proposal execution will activate Stylus, Alternate Signature Verification, and Automatic Treasury Deposits using seven on-chain governance action contracts (GACs) that alter the ecosystem in the ways described in the proposal description. The new, on-chain contracts match their audited versions with the exception of the contracts in the OffchainLabs/fund-distribution-contracts for fund distribution which we read but did not audit.
Overview
This proposal does three separate things.
Stylus
Smart contracts are computer programs. They execute the code they store and the code that Arbitrum has used until now has been Ethereum Virtual Machine (EVM) code. Different computer languages like Solidity and Vyper can be stored as EVM code but more popular languages like Rust or C++ cannot. They can, however, be stored as Web Assembly (WASM) code. This proposal will upgrade the on-chain contracts to allow not only EVM but also WASM code to be executed on Arbitrum One and Nova chains. Allowing WASM would mean that these more popular languages can be used by the developers who know them and don’t want to learn an EVM language.
Alternate Signature Verification
Ethereum and Arbitrum are secured by cryptography. Because a user’s keys are effectively impossible to figure out, they can use these keys to “sign” transactions and everyone knows that only they could be the ones that signed it. There are many different key-signature schemes including the popular secp256r1. This scheme is widely used by numerous web services and most notably by Apple and Android devices. To be able to easily use this scheme on-chain would make dApps easier to integrate into these platforms. This proposal cuts the cost of using secp256r1 signatures down drastically (up to 99%) by creating a “precompile” or special program that will perform the signature verification in the node and not in the EVM. This node software is the ArbOS referred to in the proposal.
Automatic Treasury Deposits
Arbitrum DAO collects fees for transactions on the Arbitrum networks. Currently the fees are sent to the L1 Timelock on Ethereum mainnet. The DAO’s treasury, however, sits on the Arbitrum One network. To collect the fees that come from Arbitrum Nova, a full vote must take place which requires at least two weeks to fully conduct. This proposal removes the need for these votes by creating fee routers which will transfer the funds across the networks to the DAO’s treasury automatically.
Technical Details
Scope
We reviewed the calldata as of commit 52c086 in Pull Request #298 for the proposal of ArbOS 31 “Bianca” that was recently proposed to the Arbitrum Core Governor.
Our review included determining the proposed execution, what contracts are involved, and if the contracts have demonstrated credibility.
Proposal Execution
The proposal stores a call to the ArbSys sendTxToL1 precompile which sends a transaction to L1. The cross- transaction (decoded calldata) targets the L1 Timelock’s scheduleBatch function and stores seven different calls to be executed of two calls on L1, two on Arbitrum One, and three on Arbitrum Nova.
L1 Calls
The two calls on Ethereum are to the L1 Upgrade Executor to delegatecall perform on two different governance action contracts (GACs). This follows the established protocol for upgrades in the ecosystem. The two GACs set a new challenge manager contract, initialize it with a new one-step-prover contract, and set a new WASM module root for the rollup contract. One GAC upgrades the contracts for Arbitrum One and the other upgrades the Arbitrum Nova contracts. We diffed the new contracts on-chain with the contracts found in the audited repos and found no differences. Our diff included all compilation artifacts and related contracts and not just the single contract with the matching name. We summarize this diff in the following table:
Audit Report: ArbOS 30 Nitro Upgrade
Audit Commit: de1852c
| Address | Chain | Contract Name | Contracts Checked | Diff with Audit Commit |
|---|---|---|---|---|
0x914B7b3053B35B84A24df08D7c9ceBCaEA4E2948 |
ETH | ChallengeManager | 24 | No diff |
0xa328BAF257A937b7934429a5d8458d98693C6FC7 |
ETH | OneStepProofEntry | 20 | No diff |
Note that while there are differences between the audit commit and the v2.0.0 commit, no differences exist in the contracts of interest here.
We also want to note that although there is a guide for confirming the WASM module root, it is not the most user friendly. We recommend the guide be updated for community users not as experienced with the codebase and practices.
Arbitrum One Calls
The L1 Timelock forwards two calls on to the Arb One delayed inbox, creating retryable tickets. These two calls target the Arbitrum One Upgrade Executor, again calling execute which delegatecalls to the perform function on two GACs. The first schedules the upgrade to the ArbOS version for 3 Sep 2024 @ 5pm GMT via the ArbOwner precompile. The second GAC adds the new cache manager to the ArbOS. We compared the cache manager’s implementation contract against its audited version and found no difference.
Audit Report: ArbOS 30 Nitro Upgrade
Audit Commit: de1852c
| Address | Chain | Contract Name | Contracts Checked | Diff with Audit Commit |
|---|---|---|---|---|
0x7f6dbaed9905c3b01030d3ad5aa93846ecbbfa44 |
Arb One | CacheManager | 9 | No diff |
Note that while there are differences between the audit commit and the v2.0.0 commit, no differences exist in the contracts of interest here.
Arbitrum Nova Calls
The L1 timelock forwards three calls on to the Arb Nova delayed inbox, creating retryable tickets. They all target the Arbitrum Nova Upgrade Executor, again following the familiar path of execute targeting a GAC that is delegatecalled. The first and second GAC are almost identical to the two GACs executed on Arb One described above and perform the same actions. The third sets up the new fee routing to send fees to the DAO treasury on Arb One rather than to the L1 Timelock. There are five contracts it integrates:
- an L1 surplus fee distributor
- an L2 base fee distributor
- an L2 surplus fee distributor
- a Nova to L1 Reward Router
- an L1 to One Reward Router
The first three are RewardDistributor contracts that match the code in the audit repo at the specified commit, but are actually not identified within the scope of the relevant audit report. The Arb-to-L1 fee router (ArbChildToParentRewardRouter) is also not in the audit report, but is an iteration of a file that was audited. The proposal authors have stated that the changes are optimizations. We recommend that the files and changes be described for the community in greater detail so that they can review and gain greater trust in their contents.
| Address | Chain | Contract Name | Contracts Checked | Diff with Audit Commit |
|---|---|---|---|---|
0xbb7f4871ace3bb0fffb36a9c28d0987ddab0da3a |
Arb Nova | CacheManager | 9 | No diff |
0x509386DbF5C0BE6fd68Df97A05fdB375136c32De |
Arb Nova | RewardDistributor | 4 | Not in audit report |
0x9fCB6F75D99029f28F6F4a1d277bae49c5CAC79f |
Arb Nova | RewardDistributor | 4 | Not in audit report |
0x3B68a689c929327224dBfCe31C1bf72Ffd2559Ce |
Arb Nova | RewardDistributor | 4 | Not in audit report |
0x3B68a689c929327224dBfCe31C1bf72Ffd2559Ce |
Arb Nova | ArbChildToParentRewardRouter | 4 | Not in audit report |
0x40Cd7D713D7ae463f95cE5d342Ea6E7F5cF7C999 |
ETH | ParentToChildRewardRouter | 14 | adds a safeApprove feature |
Summary of diff between audit commit and v1.0.1
| File | Lines Added | Lines Removed |
|---|---|---|
| src/FeeRouter/ArbChildToParentRewardRouter.sol | 88 | 0 |
| src/FeeRouter/ChildToParentRewardRouter.sol | 19 | 55 |
| src/FeeRouter/DistributionInterval.sol | 1 | 1 |
| src/FeeRouter/OpChildToParentRewardRouter.sol | 63 | 0 |
| src/FeeRouter/ParentToChildRewardRouter.sol | 6 | 4 |
| src/RewardDistributor.sol | 1 | 1 |
| src/Util.sol | 1 | 1 |
Conclusion
In our review of the proposal we found the payload for the L1 Timelock to be the same between the block explorer, Tally (see “Raw”), and the Arbitrum Foundation’s repo. We found that the on-chain, forum, and Tally proposal descriptions are consistent and that the descriptions accurately describe the execution of the proposal on-chain. The proposal dispatches seven different execution paths which we simulated independently and found that each executed as intended and without reverting. We expect this proposal to execute correctly should it pass.
Lastly, we found some involved contracts have been refactored and we were unable to confirm that the RewardDistributor contract was audited. We recommend that these contracts be described in detail for the community to gain trust in them.