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.