AIP: Batch Poster Manager and Sequencer Inbox Finality Fix

Proposals Finalized AIPs
1

Constitutional

Abstract

This Constitutional AIP proposes two improvements to batch posting for Arbitrum One and Arbitrum Nova:

  • Batch Poster Manager: Introduce a “batch poster manager” role with the ability to grant/revoke batch-posting affordances.
  • Increase MaxTimeVariation: Change the max-time-variation “future blocks” and “future seconds” values to 64 and 768, respectively, in line with Ethereum’s proof of stake finality guarantees.

These changes will allow the system to be more resilient, and don’t represent a change to the system’s current trust model.

Motivation

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:

  • In both the current and the new proposed system, the Sequencer is entrusted with managing the batch posting affordance; in the current system, for example, the entity behind Sequencer could technically grant batch posting to an additional entity by simply sharing it’s keys.
  • In the new system, the DAO would still have the same ability to revoke the Sequencer role; i.e., the DAO could update the batch poster manager (along with any batch posters).

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.

Implementation

Batch Poster Manager:

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:

Audit: publications/reviews/2024-01-offchainarbitrum-securityreview.pdf at master · trailofbits/publications · GitHub

7 Likes
2

Would dare to say that like most (but not all) in this forum I can probably understand about 0.1% of what is written here. And an ELI5 would be beneficial for everybody, so if someone wants to chim in please do, also understanding that this can be simplified up to a certain point.

Beside this, good that there are not critical findings in the audit. And, above all, I trust our offchain overlords to deliver on this so voting yes.

1 Like
3

When you submit a transaction on Arbitrum, the Arbitrum sequencer collects it and orders it along with other transactions. This allows you to receive a fast notification from Metamask.

The sequencer blocks are then typically aggregated together before being posted to Ethereum. That’s why it is mentioned that the sequencer posts batches frequently. This enables the chain to keep growing/processing transactions.

The sequencer is the same entity as the batch poster and is controlled by a single address on a hot wallet. This means that if the keys of this address are lost or compromised, we could end up in a position where the entity that enables the chain to keep growing is not available anymore.

The DAO would have to take action because on Arbitrum, the ‘escape hatch’ (force inclusion mechanism) not only enables escape but also allows the DAO to elect a new sequencer. The goal of this proposal is to avoid the need to reach that point by having another entity called the batch poster manager. This manager can say, ‘Hey, this batch poster address is compromised, so now this is the new address responsible for posting batches on Ethereum.’ You can think of it as a protocol add-on that is useful/would intervene only in case of an issue.

Hope that helps.

7 Likes
4

this actually helps a truckload thanks <3 <3 <3

1 Like
5

ELI5 for batch poster manager:
Instead of the sequencer only posting batches from a single address, it has a hot wallet and a cold wallet; it posts batches from the hot wallet and can swap out the hot wallet address with a new one using the cold wallet.

6

Penn Blockchain/FranklinDAO supports this proposal - the extra permissions of will allow for update of Batch Poster address without need for a DAO vote which would take longer in cases of compromise. Also the extended MaxTimeVariation could help prevent invalid batches due to re-orgs, which we think is important and should have been updated earlier.

1 Like
7

I have a technical questions.
The current contract says that we have following values:

futureBlocks : 12
futureSeconds : 3600

But now you suggest replacing the value by 6 times.

  1. Why exactly this value and why such a significant increase?
  2. Now futureSeconds is 3600 and doesn’t depends on futureBlocks * 12. Why we need to decrease futureSeconds when we increase futureBlocks?
1 Like
8
  1. Why exactly this value and why such a significant increase?

The old value of 12 blocks was set while Ethereum still used proof of work, where finality is probabilistic and essentially subjective. With POS, 64 blocks is two epochs / gives absolute finality, so that value is used as the cutoff point. To be sure: this just means that if there is an L1 reorg of less than 64 blocks after a batch transaction is signed, the tx will not revert.

  1. Now futureSeconds is 3600 and doesn’t depends on futureBlocks * 12. Why we need to decrease futureSeconds when we increase futureBlocks?

You’re right that the current value of futureSeconds is higher than the equivalent for future blocks. In practice, this doesn’t really matter since the contract’s conditional is conjunctive (both need to pass for the tx to succeed), so the “lower” time value is the one that actually takes effect. Still, for this upgrade, the futureSeconds value is set to correspond to the new futureBlocks value, for clarity and simplicity.

4 Likes
9

Treasure’s Arbitrum Representative Council voted “For” this proposal.

We have full confidence in the Offchain Labs team’s ability to continually enhance the Arbitrum ecosystem through their technical expertise. We rely on other more technical focused delegates and community members to flag any concerns if they arise, but there seems no challenge to the value of the improvements proposed here.

10

I voted for this temp check on Snapshot. I appreciate the security-minded improvement from Offchain Labs!

11

The Princeton Blockchain Club is voting in favor of these batch posting improvements on Snapshot, as they both increase Arbitrum’s resiliency.

The batch poster manager role is nice to have in case of key compromise, and the new values for futureBlocks and futureSeconds are in line with our understanding of ETH PoS checkpointing / Casper FFG.

Kudos to @sam.ng and @dzack23 for the TL;DRs and further explanations for the changes! Should be helpful for all delegates.

Hope to see good audit results, as usual.

1 Like
12

There will be a Walkthrough & AMA call (which has been added to the Governance Calendar) to answer any questions and discuss the details of this technical AIP on Tuesday, February 13!

Walkthrough & AMA for Live Technical AIPs
Tuesday, February 13 · 2:00 – 2:45pm UTC
Video call link: https://meet.google.com/bhs-owyn-chs

1 Like
13

Our team voted FOR this proposal.
A detailed explanation of the essence of this proposal and competent answers to our questions and comments make it clear that this is a thoughtful and proven update for the Arbitrum network.

1 Like
14

The below response 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.

We’ll be voting in favour of the proposal as the proposed fixes make sense from a security perspective. We’ll make sure to check the proposed code before the on-chain vote to ensure it only does what it’s supposed to.

1 Like
15

I support this proposal based on the information provided. I specifically appreciate the focus on improving security and resilience without compromising the trust model.

Also, thanks a lot for the ELI5s! Those should be part of every technical thread.

16

Thank you for the explanation, I will echo @JoJo that I think having some type of explanation like this tied to technical proposals would be very helpful for the delegates!

As I’ve said with other votes of this nature, I will be voting “For” this as I trust the knowledge and expertise of teams involved with these types of updates. As well as other more technical delegates to flag any oversights. I do believe based on the explanations I’ve seen in this thread that as a broad concept this will be a great added security feature and think it should be implemented.

2 Likes
17

I have voted in favor of this proposal as it presents a necessary improvement and streamlines the process of altering the batch poster keys.

18

After reviewing the proposal, we will vote in support of this proposal. The introduction of a batch poster to assist and the possibility of changing addresses for the rollup are positive steps toward enhancing the network’s security. This proposal appears to have beneficial impacts with minimal risks. Upon examining the smart contract aspect, we found that it pertains to managing permissions, which presents no concerns. Furthermore, it has undergone an audit by Trail of Bits, a reputable firm in the web3 audit space, assuring us of its integrity and security.

19

The Savvy DeFi DAO’s Arbitrum Council has decisively voted FOR this proposal.

Despite its technical complexity, the Batch Poster Manager and Sequencer Inbox Finality Fix brings security benefits to the ecosystem with minimal risks. The DAO would still have the same ability to revoke the Sequencer role; i.e., the DAO could update the batch poster manager (along with any batch posters).

We commend @sam.ng and @dzack23 for providing clear explanations that helped us better understand the proposal.

Additionally, having Trail of Bits, a reputable firm, validate the proposal ensures integrity and security in its execution.

We will closely follow the development of the report before making our final decision when the proposal is ready to go on chain, ensuring that it only performs as intended.

1 Like