This Constitutional AIP proposes two improvements to batch posting for Arbitrum One and Arbitrum Nova:
These changes will allow the system to be more resilient, and don’t represent a change to the system’s current trust model.
Batch Poster Manager:
Currently, both Arbitrum One and Arbitrum Nova, each have a single address that is granted the batch-poster role (this is currently the same as the Sequencer). The Sequencer posts batches frequently, and thus the batch-poster address must be controlled by a hot wallet. This means that if the batch poster’s keys were compromised, Sequencing could be unstable until the DAO took action.
This AIP proposes a system in which a “batch poster manager” role is granted to the operator of the Sequencer which has the ability to grant and revoke batch-posting affordances. This way, the batch poster manager could perform key rotations for the batch posters— routinely, and/or if a batch poster address is ever compromised — quickly and without the DAO needing to take coordinated action. Note that this proposal does not change the sequencer, but more so allow for easier key rotations on the batch poster.
Crucially, this would not represent a change on the current system’s trust model:
MaxTimeVariation:
The futureBlocks value in the the SequencerInbox enforces a max block height that a batch can be posted relative to the current block (likewise with futureSeconds). The current value for futureBlocks is 12, which was set prior to the Ethereum merge. A small value for future blocks means that a relatively small L1 reorg can cause an otherwise valid batch to revert. This proposal increases the value to 64, two epochs, in line with Ethereum’s finality guarantees.
Batch Poster Manager:
https://github.com/OffchainLabs/nitro-contracts/commit/c7554852a7c41ca5eaef298dab10472a7f550df7
Note that this implementation is currently under audit and is dependent on the ArbOS 20 AIP changes (AIP: ArbOS Version 20). Depending on the timeline of the audits, the result the ArbOS20 AIP acceptance, and the feedback on this proposal, these changes can be bundled into the same proposal as the ArbOS 20 changes or proposed separately.
MaxTimeVariation: