[Constitutional] AIP: Update the Upgrade Executors

Proposals
1

Constitutional AIP

Note: this proposal will be subject to an individual Snapshot vote; if it reaches a quorum of 3% of votable $ARB, it may be combined with several other maintenance-related proposals for a joint Tally vote.

Abstract

This proposal seeks approval to replace the Upgrade Executor contracts on Arbitrum One, Arbitrum Nova, and Ethereum mainnet with upgraded versions. The modernized version introduces an additional function that enables the Upgrade Executor to execute an upgrade by directly calling the target contract, rather than indirectly delegate calling an upgrade contract. As a result, future governance actions can be executed more simply and with fewer contract deployments.

Motivation

The Upgrade Executors controlled by the DAO are responsible for carrying out critical upgrades on Arbitrum One, Arbitrum Nova, and Ethereum such as protocol contract upgrades, system parameter changes, and more. Currently, the traditional Upgrade Executor contracts in place only support one function for executing an upgrade: execute(). When called by the owner of the Upgrade Executor, the execute() function delegate calls an upgrade contract, which facilitates subsequent calls to target contracts and ultimately executes the upgrade. This indirect method of calling and execution can complicate upgrades and require additional development and deployments.

The modern version of the Upgrade Executor introduces a new function, executeCall(), which allows the Upgrade Executor to directly call target contracts and execute upgrades, removing the need for delegate calls to upgrade contracts. While the existing execute() call is still supported, the new executeCall() function enables the Upgrade Executor to implement upgrades in a lighter weight fashion. In the future, upgrades that use this method may not require dedicated action contracts, simplifying the process and saving development energy.

Key Terms

  • Upgrade Executor: A smart contract responsible for executing upgrades on Arbitrum One, Arbitrum Nova, and Ethereum mainnet; owned and administered by the DAO
  • Upgrade Contract: A smart contract that contains dedicated logic for a particular upgrade; receives a call from the Upgrade Executor and subsequently calls other contracts targeted in that upgrade
  • execute(): The sole function for executing an upgrade in existing Upgrade Executor implementations; relies on indirect delegate calls to upgrade contracts
  • executeCall(): A new function for executing an upgrade in the modern Upgrade Executor implementation; allows for direct calls to target contracts

Specifications

Steps to Implement

  1. Deploy new UpgradeExecutor contracts on Arbitrum One, Arbitrum Nova, and Ethereum using the parameters specified above.
  2. Update proxy contracts on Arbitrum One, Arbitrum Nova, and Ethereum to point to the new UpgradeExecutor contracts.

If this proposal passes a Snapshot vote successfully (as defined above), it will be combined with other maintenance-related proposals for a unified Tally vote and on-chain payload. The portion of the Tally payload that covers the actions described in this proposal will be shared as soon as each individual proposal passes a Snapshot vote.

Timeline

  • Immediately: publish proposal to the forum and respond to community feedback; requisite code has already been written, tested, and audited as of 6 January 2023
  • 1-2 Weeks: initiate a Snapshot poll to gauge community sentiment
  • 3-5 Weeks: initiate joint Tally proposal and execute on-chain assuming vote is successful
4 Likes
2

After further consideration, we’ve realized that our original requirement — that a proposal must receive at least 95% FOR votes on Snapshot and reach an informal quorum of 100M votes in order to be batched with other maintenance-related proposals for a joint Tally vote — is unnecessarily stringent.

To streamline the process while still ensuring sufficient support, we’re updating the requirement - that if a proposal reaches a quorum of at least 3% of votable $ARB on Snapshot, it may be eligible to be combined with other maintenance-related proposals in a joint Tally vote.

2 Likes
3

Thank you for submitting this maintenance proposal and continuing to improve the infrastructure that underpins DAO-led upgrades.

We support the motivation behind simplifying the upgrade execution process and introducing a more lightweight alternative, especially for operational efficiency and governance overhead reduction.

We would appreciate a clarification regarding how this proposed change might affect the custom gateway upgrade process, such as the one currently up for vote for Sky, are they influenced by this upgrade?

4

Thank you for the proposal.

We have no feedback on the proposed upgrade at this time and will support it.

However, we would like to confirm whether an audit of the new UpgradeExecutor contract rollout is being conducted or is planned, considering that the linked audit was conducted in January 2023, which is over 2 years old now.

5

Please advise on this proposal:

  1. Why is a solution that was audited 2.5 years ago being applied only now?

  2. Is there a need for a new audit due to Ethereum updates during this time?

    • Shanghai
    • Dencun
    • Pectra
6

We support this proposal, as the introduction of executeCall() will help streamline upgrades and reduce unnecessary overhead for future governance actions. That said, we’d like to raise a few questions. Since this introduces a more direct method of executing upgrades, are there any guardrails or best practices planned to ensure safe usage and prevent misuse or errors? The proposal notes that the code has been audited, it would be helpful to better understand the scope of that audit and whether it covered risks specific to executeCall(). We also encourage the team to provide documentation and usage examples so DAO participants can confidently adopt the new functionality.

7

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

After reviewing the proposal with the assistance of L2BEAT’s research team, we’re supportive of it.

The only real novelty is the new executeCall() function, which allows the DAO to interact directly with a target contract instead of first delegating to a throw-away “action” contract. Cutting that hop should simplify future governance actions and reduce the need for contract deployments.

Nothing else in the permission model changes—ownership remains with the DAO, the old execute() path continues to work, and we’ve seen no alteration to the underlying trust assumptions.

We also posted an X thread that simply explains the proposal for anyone interested in learning more about it.

1 Like
8

The actual solidity-code in question, the updated UpgradeExecutor.sol, does not appear to have been covered by the audit. The phrasing of the above sentence led me to believe it had, so I think it’s important to point this out to other delegates.

None of the commits mentioned in the audit report contain the new executeCall(...) function, the audit only seems to cover the old UpgradeExecutor.sol and framework-code around it.

The direct links for readers to confirm this themselves:

https://github.com/OffchainLabs/governance/blob/cf6762d45678847cd901544f90989d852dfdd6ea/src/UpgradeExecutor.sol
https://github.com/OffchainLabs/governance/blob/6bd1a880df96b36508b55a10c8f29327711f3750/src/UpgradeExecutor.sol
https://github.com/OffchainLabs/governance/blob/e4562df1fd165042f6fc5400063dd4a23d10e855/src/UpgradeExecutor.sol

Perhaps there is a different audit that covers the updated UpgradeExecutor.sol?

In the end the suggested upgrade does not seem to introduce new ‘powers’ to the executor-role beyond what it already imbued with. If anything it provides a cleaner path to achieving what execute(...), without the potential side-effects that a bad execute(...) call might cause.

Would I personally feel comfortable with this change? Yes. Would I feel comfortable suggesting the DAO embrace the change without having at least seen it audited? No. As the proposal stands right now I would feel forced to vote “Against”.

1 Like
9

After consideration, the @SEEDgov delegation decided to vote FOR on this proposal at the Snapshot Vote.

Rationale

We have no reason to oppose this update. However, we would appreciate clarification regarding the audit status of the referenced contracts — as raised by other delegates — before the on-chain vote takes place.

10

I voted AGAINST this proposal

11

We vote in favor of this proposal.

This streamlines Arbitrum’s upgrade execution by introducing a direct-call method (executeCall()), thus reducing the complexity and potential risks associated with delegate calls and single-use upgrade contracts. Maintaining existing permission structures ensures continuity of trust assumptions while enhancing operational efficiency. Additionally, the upgrade mitigates technical overhead, benefiting both developers and the broader community through clearer and safer upgrade processes.

That said, as many other delegates pointed out, the audit status should’ve been disclosed prior to the vote, considering the importance of transparency for the DAO to effectively manage contracts in a secure manner.

12

We support this proposal as it streamlines the DAO’s upgrade process by introducing executeCall(), allowing for direct contract upgrades without deploying separate upgrade contracts. This improves efficiency, reduces complexity, and maintains backward compatibility. With the code already audited and no added governance risk, we see this as a low-risk, high-value improvement to DAO operations.