AIP: ArbOS 31 “Bianca” - Activation of Arbitrum Stylus, RIP-7212 Support, & Nova Fee Router Proposal

Proposals Finalized AIPs
1

UPDATE -

This Constitutional AIP is now live on Tally - voting starts on Thursday, August 1st, at 13:46 UTC.

There has been an error in 2 URLs on the text of the Onchain AIP on Tally, and the correct URLs are listed below.

To clarify, the payload and custom upgrade actions in the AIP are still correct - the only errors were in the description of the proposal.

Wrong Addresses:

Correct Addresses:

This update has also been highlighted at the very top of the first post. We apologize for this error, and are happy to answer any questions that delegates and the DAO might have.

Type: Constitutional

Abstract

This AIP proposes the activation of ArbOS 31 on Arbitrum One and Arbitrum Nova. This ArbOS upgrade brings a number of improvements, including:

  • Activating Arbitrum Stylus to enable developers to build the next generation of Rust or C++ applications on the EVM.
  • New precompile for verifying the secp256r1 elliptical curve (as part of RIP-7212)
  • Change to fee collection on Arbitrum Nova, making it easier for ArbitrumDAO to manage and access the funds.

This AIP combines the following three temperature checks:

A new ArbOS 31 “Bianca” was released between the time of the temperature check votes and submitting this proposal. ArbOS 31 release builds upon ArbOS 30 and includes new optimizations that were discovered during rigorous testing and feedback from Stylus teams. The ArbOS upgrade is shipped as a new Nitro node release alongside new upgrades to the rollup contracts for Arbitrum One and Arbitrum Nova.

Note: ArbOS 31 “Bianca” will be the canonical ArbOS version for the “Bianca” family of releases.

Since the DAO has already signaled support for the adoption of all three changes in all three temperature checks, this proposal will proceed to an on-chain AIP on Tally next.

Changes included

1. Activation of Arbitrum Stylus: a new WebAssembly-based (WASM) VM to support smart contracts written in Rust and C++

Stylus is an upgrade to the node software that powers all Arbitrum chains. This upgrade introduces a new WASM-based Virtual Machine (VM) that runs alongside the EVM. This enables developers to write smart contracts in new programming languages, like Rust, that are more efficient than Solidity smart contracts.

Stylus is a first-of-its-kind technology resulting from breakthrough engineering efforts in the Arbitrum ecosystem. Unlike other alternative VMs, the Stylus VM is not a replacement for the EVM & is instead purely additive to the EVM. This means that Stylus contracts and EVM contracts are fully interoperable. The two VMs work together to facilitate state transitions, each playing their part in executing their respective bytecode. Support for more memory efficient and safer languages will unlock a new generation of applications that were previously impossible to build on the EVM.

The Stylus VM and fraud prover were originally developed as a fork of the Nitro codebase before. The Stylus codebase has since been audited (Trail of Bits audit report) and merged back into the Nitro codebase:

Stylus contracts can be written using the Stylus SDK, which employs Solidity-equivalent ABIs and storage patterns to ensure cross-language interoperability. For example, existing Solidity DEXs can list Rust tokens without modification. New SDKs for additional programming languages can be added over time. Current SDK repositories:

If you would like to better understand the lifecycle of a Stylus contract, head over to A Gentle Introduction: Stylus. For teams who are curious to learn more about how Stylus is expected to interact with their project’s existing infrastructure, we encourage folks to check out this Stylus launch ecosystem one-pager.

Note: Support for Stylus contract verification is currently under development by major block explorers. We expect that contract verification will be fully supported before ArbOS 31 Bianca gets activated on Arbitrum One and Arbitrum Nova, pending the DAO’s decision to adopt this proposal.

2. Addition of a new pre-compile, to Arbitrum Nitro, that reduces the costs of verifying the secp256r1 elliptic curve as part of RIP-7212

Passkeys offer a solution that removes the need for a web3 user to personally store a private key for their wallet. Passkeys accomplish this by leveraging WebAuthn, a global standard for passwordless authentication used by Google, Facebook, Microsoft, and all major web browsers. The private key generated when creating a passkey can be encrypted and can only be decrypted using a specialized hardware module called the Secure Enclave. The Secure Enclave ensures a user’s private key can never leave the device, transforming any compatible device into a hardware wallet. Users can authorize transactions with biometric features like Touch ID or Face ID when using passkey-based wallets for key management. These qualities add flexibility and significantly improve UX while maintaining high security.

Adding support for RIP-7212 decreases the costs of verifying the secp256r1 curve on-chain by 99% when compared to current implementations, making them more feasible for everyday use and enabling dApp developers and protocols to offer their users improved UX on Arbitrum One and Arbitrum Nova. Without a precompile, verifying this signature on-chain is extremely expensive. Passkey-based wallets offer a better level of security than a typical EOA and seamless cross-device support. Many wallets, and notably, apps using embedded wallets, have been requesting this feature for over a year.

The specifications of RIP-7212, including test cases, can be found in the RIP repository. If approved, Arbitrum One and Arbitrum Nova will use this specification as the reference for implementation. The Ethereum Magicians Forum discusses design decisions, iterations, and the transformation of the proposal from an EIP (Ethereum Improvement Proposal) to a RIP.

This pre-compile is part of Nitro 3.1.0 and was added to our fork of Go Ethereum in Add Precompile for secp256r1 conditionally based on ArbOS version by anodar · Pull Request #303 · OffchainLabs/go-ethereum · GitHub and has been upstreamed into Nitro 3.1.0. Nitro 3.1.0 is the minimum supported version of Nitro for ArbOS 31 “Bianca”.

3. Update all Nova fund distributors to use a series of “fee routers” instead, while keeping the final destination as the ArbitrumDAO Treasury

Today, the ArbitrumDAO’s portion of the transaction fees from Arbitrum Nova are sent to the Core Governance L1 Timelock address, which is accessible via the core governance system. This setup is disadvantageous because any time the ArbitrumDAO wishes to spend/move the funds, a roundtrip, constitutional proposal must be passed before the DAO.

This proposal updates the setup such that all Arbitrum Nova transaction fees, that are currently sent to the Core Governance L1 Timelock Address, are instead sent to a system of “fee routers” that automatically send all funds to the ArbitrumDAO treasury. Benefits of this new setup include:

  • Lower quorum requirements for moving these funds (3% vs. the current 5%)
  • No ~2 week delay to spend funds (since a constitutional vote would not be needed, as per the Lifecycle and anatomy of an AIP)
  • Simpler accounting and bookkeeping, since all the funds would be in the ArbitrumDAO treasury.

This new, proposed system of “fee routers” results in a fee collection lifecycle as follows:

  1. A distributeRewards function call is made on the RewardDistributor contract, sending funds to a ChildtoParentRouter contract
  2. Either upon receiving funds or via a call to routeFunds, the ChildToParentRouter creates an L2-to-L1 message which sends the contract’s full Ether balance.
  3. The L2-to-L1 message is executed, transferring the Ether to a ParentToChildRouter contract on L1.
  4. routeFunds is called on ParentToChildRouter, creating a retryable ticket which transfers its full Ether balance to the DAO Treasury on Arbitrum One.

Note that the addresses deployed during the Snapshot vote for the ParentToChildRewardRouter and ChildToParentRewardRouter have been re-deployed at [0x40Cd7D713D7ae463f95cE5d342Ea6E7F5cF7C999](https://nova.arbiscan.io/address/0x40Cd7D713D7ae463f95cE5d342Ea6E7F5cF7C999) and [0x36D0170D92F66e8949eB276C3AC4FEA64f83704d](https://nova.arbiscan.io/address/0x36D0170D92F66e8949eB276C3AC4FEA64f83704d), respectively.

Implementation

All of the above changes were independently audited. The list below contains all relevant audit reports:

The canonical version of ArbOS 31 “Bianca” this proposal aims to adopt is implemented in the Arbitrum Nitro git commit hash 7d1d84c75db7fd26d27d24ffb75f8b1c93d4f980 and can be viewed in: Merge pull request #2485 from OffchainLabs/fix-disable-p2p · OffchainLabs/nitro@7d1d84c · GitHub.

The current full code diff can be viewed via this link: Comparing consensus-v20...consensus-v31 · OffchainLabs/nitro · GitHub.

ArbOS 31 “Bianca” will be shipped as part of a future release of Nitro. Node operators may see a small increase in latency for Stylus eth_call queries, if ArbOS 31 is approved for activation on mainnet by the ArbitrumDAO.

Upgrade Action smart contracts

The Action smart contracts used to execute the on-chain upgrade can be viewed in Arbos 31 actions by godzillaba · Pull Request #296 · ArbitrumFoundation/governance · GitHub.

Action contract deployments for ArbOS 31 and Stylus:

$ cast storage 0x51dEDBD2f190E0696AFbEE5E60bFdE96d86464ec 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103 --rpc-url=https://arb1.arbitrum.io/rpc

0x000000000000000000000000db216562328215e010f819b5abe947bad4ca961e (Arb One Proxy Admin)

$ cast storage 0x20586F83bF11a7cee0A550C53B9DC9A5887de1b7 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103 --rpc-url=https://nova.arbitrum.io/rpc

0x000000000000000000000000f58ea15b20983116c21b05c876cc8e6cdae5c2b9 (Nova Proxy Admin)

Action contracts, deployments, and Fee Router contracts for the Fee Router AIP:

The Fee Router contracts can be found here: fund-distribution-contracts/src/FeeRouter at v1.0.1 · OffchainLabs/fund-distribution-contracts · GitHub

Nova ArbChildToParentRewardRouter: ArbChildToParentRewardRouter | Address 0x36D0170D92F66e8949eB276C3AC4FEA64f83704d | Arbitrum Nova

Verifying the ArbOS code differences

To verify the ArbOS code differences, this notion page contains steps to build the WASM module root on that git tag, which produces the WASM module root 0x8b104a2e80ac6165dc58b9048de12f301d70b02a0ab51396c22b4b4b802a16a4, which is what the rollup contract’s wasmModuleRoot() method returns for both Arbitrum One and Arbitrum Nova.

These steps will be included on the onchain AIP on Tally in entirety to ensure consistency with previous ArbOS proposals.

4 Likes
2

Tell me, were audits conducted for the new contracts
I see that 43 files were changed.
I understand that most of them are replacements

// SPDX-License-Identifier: UNLICENSED
// SPDX-License-Identifier: MIT

But I would like to have an audit report.

3

OpenZeppelin, on behalf of the ARDC, is reviewing the upcoming ArbOS 31 upgrade proposal details. This includes the proposal calldata submitted as PR298, the contents of the forum post above, and verifying that the action contracts in the proposal have been audited.

We are awaiting additional details to be published by the Offchain Labs team that should help us address concerns raised by @cp0x. We’ll also confirm the Tally proposal submitted on-chain matches what has been previously claimed.

1 Like
4

UPDATE -

This Constitutional AIP is now live on Tally - voting starts on Thursday, August 1st, at 13:46 UTC.

There has been an error in 2 URLs on the text of the Onchain AIP on Tally, and the correct URLs are listed below.

To clarify, the payload and custom upgrade actions in the AIP are still correct - the only errors were in the description of the proposal.

Wrong Addresses:

Correct Addresses:

This update has also been highlighted at the very top of the first post. We apologize for this error, and are happy to answer any questions that delegates and the DAO might have.

1 Like
5

Proposal Review

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 were not fully covered by the audit scope and with some files receiving some optimization changes since the final audit commit. We recommend getting a confirmation on whether the latest version of these files were covered in the audit.

You may read our full review here:

1 Like
6

Before voting for this update, I would like to receive a response to OpenZeppelin’s comment

2 Likes
7

Blockworks Research will be voting FOR this proposal on Tally when live.

These upgrades are very important for the network moving forward. EIP/RIP-7212 will allow for much better gas optimization for smart wallet accounts using more traditional secp cryptographic curves which enables biometric signatures or other methods for wallet management, and Stylus will enable better and more diverse applications moving forward. This seems like a ‘no brainer’ for the DAO to support. Polygon, Optimism, and Base have already implemented RIP-7212, and it may be implemented as an EIP going forward so it’s best to get ahead of the curve and join the others.

8

Thank you for your review @openzeppelin .

The RewardDistributor contract has already been audited and is currently in use already: Nova: L2 Base Fee | Address 0x9fCB6F75D99029f28F6F4a1d277bae49c5CAC79f | Arbiscan.

Here is an example of one used in production - its code is the exact same. The ArbOS 31 proposal is NOT proposing the deployment of a new rewardDistributor contract - instead we’re just updating the recipients on the existing ones.

This comment has also been posted on the AIP: ArbOS 31 Proposal Review thread.

1 Like
9

Should be this here

2 Likes
10

I voted yes, as Bianca is giving new tools like allowing Rust to be used as a programming language.

11

Voted for this - three important upgrades in a single proposal. Enabling the precompile is a competitive necessity for account abstraction and wallet management in general, and Stylus opens the door to a richer future of possibilities for developers building on Arbitrum.

12

Here is our rationale for onchain voting:

AIP: Activate Stylus and Enable Next-Gen WebAssembly Smart Contracts

Stylus significantly improves Arbitrum by supporting Rust, C, and C++, expanding the developer community, enhancing performance, reducing costs, and improving security, all while maintaining EVM compatibility. This fosters innovation without disruption, ensuring Arbitrum’s success. So we will vote FOR this proposal.

AIP: Support RIP-7212 for Account Abstraction Wallets

We will vote in favor of the proposal. There is no reason for us to vote against as this standard will enhance user experience, security, and functionality by integrating account abstraction wallets into ArbOS 3.0, promoting innovation and more sophisticated wallet solutions within the Arbitrum ecosystem.

AIP: Nova Fee Router Proposal

We decided to vote in favor of this , as This will reduce the DAO’s administrative burden and streamline handling Nova fees. With clear benefits.

13

The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.

Having supported each individual upgrade included in ArbOS 31, we’ll be voting FOR this proposal during the onchain vote.

OpenZeppelin, in their capacity as the security member of the ARDC, conducted a review of the proposal’s executable and confirmed that the upgrade will only perform the actions described in the proposal. We also individually checked the contents of the proposal’s executable to confirm that they’ll only do what they describe. Both reviews found no issues, and therefore, we’re comfortable voting in favor.

1 Like
14

Will post my complete rational later. But voting FOR in this proposal.

15

I voted FOR this proposal on Tally, as I did for each of the three component temp checks.

I’m pleased with the level of technical rigor behind the onchain proposal. I appreciate the audits of each part, the ability the independently verify changes, and the review from OpenZeppelin as part of the ARDC.

16

I am voting in favor of this proposal on Tally. My voting rationale is aligned with the reasons that I previously mentioned on Snapshot for the individual components concerning ArbOS 31. You can read them here:

I really appreciate the quality of this proposal and the efforts that were made to make it coherent and solid.

17

We vote FOR the proposal on Tally.

We maintain our rationales below for each individual update and support a package of those updates to be deployed as “Bianca”. We appreciate the proper audits on each implementation and OpenZeppelin’s reviews as a part of ARDC works.

We are particularly excited to see Stylus finally going live!

18

In line with my previous comments at the Snapshot phase of these votes, voting “For” on Tally.

19

I voted FOR this proposal because it’s like giving Arbitrum a superhero upgrade:

Arbitrum Stylus: Now developers can whip up smart contracts in Rust and C++—faster, stronger, and definitely cooler.

New Precompile for secp256r1 Verification: Cuts verification costs by 99%, making passkey-based wallets cheaper, safer, and less of a headache for everyone.

Nova Fee Collection Update: It’s like giving the ArbitrumDAO a direct line to its piggy bank, making fund management smoother and less bureaucratic.

These upgrades aren’t just cool features; they’re going to supercharge Arbitrum’s scalability, security, and governance. Plus, with solid community backing and thorough audits, it’s clear that Arbitrum is leveling up in the best way possible.

20

At Castle Capital, we’re always enthusiastic about initiatives that push the boundaries of what’s possible in DeFi, and this upgrade proposal is no exception. We believe it holds great promise for enhancing the ecosystem, and we’re keen to see its potential benefits unfold.

That said, regarding the technical and security nuances, we believe it’s best to lean on the expertise within our DAO community. We trust those with specialized knowledge will provide the necessary analysis to ensure this proposal meets the highest standards of safety and efficacy.

We will be voting For this upgrade.