Arbitrum L2 Time Lock Delay Proposal Security Review

Arbitrum Research & Development Committee (ARDC) Security Member
1

OpenZeppelin, the Security Member of the ARDC, reviewed the Arbitrum L2 Time Lock Delay Proposal and its specifications.

Summary

If enacted, the proposal will increase the delay of constitutional proposals from 3 days to 8 days. The change only involves a modification of an existing configuration parameter and does not introduce any new functionality.

Overview

The Arbitrum DAO has a governance process whereby the community can vote on proposals fully on-chain. Two distinct kinds of proposals can be passed: those that spend funds from the ArbitrumDAO’s ETH treasury and those that perform upgrades to the contracts governing the system. In either case, there is currently a 3-day delay between the time a proposal has passed and when it is executed. While the same delay applies for both types of proposal, the former is governed by the L2 Treasury Time Lock while the latter is governed by the L2 Core Time Lock. As such, the delays for each proposal type are independent and any changes made to one will not necessarily impact the other.

While these delays are in place, the Security Council can always step in to stop malicious proposals. However, the delay gives the Security Council the time to act in the event that a malicious proposal is indeed passed. In addition, it provides users the opportunity to withdraw their assets in the event that they are dissatisfied with the changes that would result from a proposal. The proposal would increase the delay applied to the L2 Core Time Lock from 3 days to 8 days. All proposals regarding spending funds from the ArbitrumDAO ETH treasury would still maintain a delay of 3 days. Only constitutional proposals related to smart contract upgrades would be affected.

Motivation

The primary motivation for this change is to increase the aforementioned security benefits. Namely, an increased delay will give the Security Council more time to review and stop malicious proposals (which is already a technical and lengthy process), while also providing users more time to make an informed decision. Furthermore, the proposal mentions a framework developed by L2BEAT as part of the motivation behind it. More specifically, it will change the color of Arbitrum’s ‘Exit Window’ slice on L2BEAT’s Risk Rosette from red to yellow.

By only increasing the delay on the L2 Core Time Lock, a compromise is achieved between security and speed. Since constitutional proposals are much more complex in nature, the Security Council requires more time to review these proposals than those directed towards the treasury. This timelock delay increase would provide the necessary time to review these potentially complex proposals while the traditional proposals regarding treasury spending adhere to the existing process. The downside of increasing this delay is that constitutional proposals will now take an extra 5 days to execute. No additional costs or security risks are introduced to the system as the proposed changes only modify one configuration parameter.

Technical Details

No new functionality needs to be introduced for this change. The value of the existing _minDelay parameter would be changed from 259200 to 691200 in the L2 Timelock contract. Note that the units of this parameter are in seconds, so the change is from 3 days to 8 days as explained earlier. The action contract has already been implemented and is pending an audit. It consists of a contract that has a function called perform which:

  1. Calls the L2AddressRegistry contract deployed on Arbitrum at 0x56C4E9Eb6c63aCDD19AeC2b1a00e4f0d7aBda9d3 to get the value of the coreGovTimelock state variable. Currently, the value of this variable is the address of the contract deployed at 0x34d45e99f7D8c45ed05B5cA72D54bbD1fb3F98f0.
  2. Calls the updateDelay() function of the stored coreGovTimelock contract with the new value of 86400 * 8. Note that 86400 is 24 hours in seconds, so this would effectively update the delay to 8 days as described. This function, in turn, sets the _arbMinDelay to this new value and emits an event. No other changes occur.
    • Using the same coreGovTimelock contract, the getMinDelay() function is called to ensure that the new value of _arbMinDelay reflects the proposed change.
  3. Calls the L2Registry contract once again, this time retrieving the value of the arbitrumDAOConstitution state variable. Currently, the value of this variable is the address of the contract deployed at 0x1D62fFeB72e4c360CcBbacf7c965153b00260417.
  4. Calls the setConstitutionHash function with the new value of 0x28faf2acba9b3ff80ec484e3d5646931eeef40568b1b7c38dbe52b890bfd7938. This reflects the changes made to the constitution text which are discussed further below. This function, in turn, sets the constitutionHash state variable and emits an event. No other changes occur.
    • Using the same arbitrumDAOConstitution contract, the constitutionHash() getter for this state variable is called to ensure that the new value of constitutionHash reflects this change.

The CoreGovTimelockUpdateDelayEightDayAction contract already seems to have been deployed on the Arbitrum network at 0x5B947D8bF197467be7ef381b7cAfEE0A7B35737A.

The current constitution of the Arbitrum DAO has been modified with the following changes:

- Phase 4: L2 Waiting Period (3 days): After an AIP has passed Phase 3, a 3 day waiting period occurs. This gives users who object to the AIP time to initiate withdrawal of their funds or take other action on L2.
+ Phase 4: L2 Waiting Period (3 or 8 days): After an AIP has passed Phase 3, there is a 3 day waiting period for actions related to the DAO Treasury and an 8 day waiting period for an L2-to-L1 Message. This gives users who object to the AIP time to initiate withdrawal of their funds or take other action on L2.

- Phase 5: Initiate and Finalize an L2-to-L1 Message (at least 1 challenge period of the rollup protocol): After the 3 day waiting period in Phase 4 has passed, an L2-to-L1 message is sent indicating that the AIP was passed.
+ Phase 5: Initiate and Finalize an L2-to-L1 Message (at least 1 challenge period of the rollup protocol): After the waiting period for Phase 4 has passed, an L2-to-L1 message is sent indicating that the AIP was passed.

A keccak256 hash of the full constitution text was used to generate the value mentioned above. Based on independent review from the ARDC, these changes have been verified to produce the same hash as mentioned by the team. This can be verified by following the same instructions for generating the hash as outlined by the team, with the new changes to the constitution reflected. Note that the CoreGovTimelockUpdateDelayEightDayAction contract has not been directly audited and any calls are not guaranteed to succeed. However, the functionality would only execute if the changes are successfully performed. In addition, no other changes are proposed beyond those explicitly mentioned in the proposal.

Conclusion

We found the timelock delay increase proposal to be a reasonable compromise between increased security and maintaining the existing benefits of speedy treasury proposals. This will enable Arbitrum to transition into a more mature rollup that operates independently of any centralized actors, as outlined by the L2BEAT framework. Moreover, the proposal provides added security to reduce the possibility of malicious contract upgrades being executed, while also increasing the amount of time a user has to act on a proposal. The changes described in the proposal have been verified and exactly match those that are currently pending execution on-chain.

3 Likes