Per the community call regarding this proposal, it seems that we have reached consensus around a 12 hour delay given the complexity / SRE constraints around the force inclusion mechanism. The upside of @shotaro 's push towards a shorter window is that it increases interoperability between chains in a “multi-rollup world.” At the same time, @hkalodner makes a key point when he suggests that it’s possible for these features to emerge from a different portion of the “design space.” Given the bandwidth limitations / Offchain’s constraints in knowledge transfer, we probably want to err on the side of caution at the start.
Two relevant directions to extend the conversation from here:
Focus less on the diversity of user personas and more on fault tolerance / low-lift maintenance of the infrastructure
Develop a comprehensive methodology for ecosystem parameters
To the point of (2) at present, we could imagine a curve where the x-axis is censorship delay window and the y-axis is probability of a [substantive] block re-org. It’s tough to map this directly to a data science problem (without some grossly simplifying assumptions) since this deals with counterfactuals and you can’t just average things out with brownian motion. However, if we treat that model more as a heuristic, what becomes clear is that we should be willing to tolerate some non-zero probability of re-org risk (ε > 0), but based on community preferences, we should adjust the censorship window accordingly.
First of all, I would like to greatly thank all of participants of the community call. For me as a delegate it was a blast, I learned a lot and I think we had a great nuanced discussion.
This proposals benefits a relatively small user group of dapp developers
Most delegates don’t understand the implications
Almost no one is qualified or has time to conduct thorough risk analysis
Decreasing the censorship period to 12 hours instead of 24 hours is possible, but there is anxiety or nerves about changing any protocol parameter
There are alternative protocol changes being researched for future arbitrum upgrades which could circumvent the need for this kind of proposal (sequencer censorship oracle by bridging the block header of L1 → L2 delayed inbox messages)
I think it’s fair to consider this proposal status as now inactive considering there isn’t enough support and there are possible alternatives which would require protocol upgrades in the future.