I’m an Offchain Labs protocol person, who was involved in the original decision to set this parameter to 24 hours. Here’s my opinion on the tradeoffs.
First, thanks to Shotaro and Bartek who have both been valuable participants in community discussion around Arbitrum over time.
You have collectively identified the main tradeoff here, which is that a shorter censorship delay value increases the risk of a reorg in the transaction sequence; but a longer censorship delay value provides a weaker guarantee if the sequencer does engage in censorship.
Here’s the sequence reorg scenario: The sequencer has published some transactions in its feed but those have not yet been posted to the on-chain inbox. In this state the sequencer goes offline (and redundancy measures such as failover to a hot spare somehow don’t succeed). The sequencer stays offline for longer than the delay interval. Someone then force-includes a message into the sequence. This reorgs the sequencer’s feed, because the messages that were in the feed but not yet inbox-posted will need to be included in the sequence after the force-included transaction, once the sequencer recovers.
By design, Arbitrum makes transaction sequence reorgs very rare, and many applications rely on that fact by assuming that a sequence reorg won’t happen. (Protocol designers have consistently warned that sequence reorgs are not impossible.). Those applications could suffer negative consequences if a sequence reorg does happen.
So the key technical question here is: how much would shortening the delay to 4 hours increase the risk of a sequence reorg? Our engineering team is analyzing that question, at the request of the Foundation, and we’ll report to the community once we have a clearer answer.