- Two competing models for “Stage 2” rollups were contrasted: a “Traditional Stage 2” (admins + exit windows + a gas token bridge) vs. an “Unstoppable Stage 2” (immutable L1 contracts, non-disablable forced inclusion, no training wheels proof system, and no gas token bridge).
- Benefits and drawbacks of each approach were discussed, with the main trade-off being between a “thicker” protocol that provides more functionality to users and a “thinner” protocol that prioritizes non-interference (“unstoppability”).
- The mechanics and challenges of forking / upgrading an unstoppable rollup while carrying forward state were also discussed.
Presentation: What is an Unstoppable Stage 2 Rollup?
Context & Stakes
- Tom Lehman referenced Vitalik's recent tweet about prioritizing fast withdrawals over Stage 2, arguing this is an incorrect position.
- Features like fast withdrawals (<1 hour) depend on Stage 2 guarantees. If a chain can be shut down without notice, no withdrawal is possible—so the “Stage 2” baseline matters.
- What is Stage 2? Lehman argued that at a high level Stage 2 means "code runs the chain, not people." But there are multiple ways to achieve this
Two definitions of a rollup (terminology detour)
- Rules‑based: the rollup is a set of rules that derive L2 state from L1; you can prove the derived state back to L1.
- Smart‑contract‑centric: the rollup is the L1 contract maintaining/accepting state roots under defined rules.
- Tom’s aim: keep arguments compatible with either view, even though he personally leans rules‑based.
Two Types of Stage 2
- Traditional Stage 2: Has 30-day exit windows, can resolve proof conflicts with no notice, maintains upgradeable contracts
- Unstoppable Stage 2: Absolutely no admins, completely immutable contracts, infinite exit window (can never be shut down)
Core Components of Unstoppable Design
A Stage 2 rollup (of any kind) must have three components:
- Guaranteeing transaction inclusion
- Having a proof system
- Managing chain “upgrades” (forks? new chains?)
An Unstoppable Stage 2 rollup implements them like this:
Unstoppable Sequencing:
- Forced inclusion must go through either EOA addresses or non-upgradeable smart contracts
- EOA pros: Backwards compatible across forks, stable address
- EOA cons: Can't revert invalid transactions, requires retry mechanisms
Unstoppable Proof Systems:
- No "training wheels" (guardian interventions)
- Records facts about what happened (x root is canonical), not interpretations (x root should be relied on)
- Applications implement their own safety mechanisms
- Bridges decide individually whether to trust proofs
Exit Windows & Canonical Bridges:
- Traditional view: Exit windows protect ability to withdraw canonically-bridged assets, not just use L2 state.
- Tom's argument: "Canonical bridge" really means "gas token bridge"
- Gas token bridges create security vulnerabilities (admins can mint unlimited gas tokens)
- 70% of rollup assets aren't canonically bridged and yet still exposed to risk.
- Solution: Use native gas tokens instead of bridged ETH
Trade-offs Presented
What you get with Unstoppable Stage 2 (thin protocol):
- Protocol that can't be shut down or tampered with
- Neutral computation platform
- Greater protections for stablecoins and native assets
What you don't get (thick):
- Protocol-level bridge security guarantees
- Guardian/admin protections
- ETH-based gas system
The Unstoppable approach leaves more complexity to users and applications, but in return promises user-app relationships will be free from protocol interference.
Ethereum L1 is a “thin” admin‑free protocol. Question: to what extent should L2s emulate this design?
Q&A
Timothy Clancy's Challenges:
- Definition disagreement: Argued that rollups must use the "smart contract centric" definition since that's how Facet Bluebird was evaluated by L2Beat
- Canonicity critique: "You can't have your cake and eat it too" - Facet was evaluated as having a canonical bridge, can't now claim it doesn't
- Fork concerns: Warned about "Pulse Chain style" forking where carrying forward state enables double-spending of L2 native assets
- Example: "Let's say I create Timcoin on Bluebird... I have that same token in both versions" creating double-spend opportunities
- Core position: Every rollup IS a bridge - "there's no such thing as canonical or non-canonical, there just is"
Luca Donno's Perspective:
- Agreement on mechanism: Thinks immutable rollups with bridge redeployments are “viable" and "cool"
- Marketing advice: Facet should "put money where your mouth is" and actively promote using their Stage 2 bridge
- Practical concerns: Forking with carried state creates complexities - example of personal time tokens that could be double-redeemed
- Suggested framing: Market as "immutable rollup that upgrades through bridge redeployments."
- Positive observation: Noted that Facet's design allows anyone to build new proof systems if the original team disappears
Tom Lehman's Responses:
- On double-spending: Recognized it as a genuine problem that needs addressing, suggested users must understand which fork they're using
- Bridge hesitancy explained: Historical context - users didn't like withdrawal delays when they tried the Optimism-style bridge at Facet’s initial launch.
- Definition flexibility: Willing to work with either rules-based or contract-centric definitions of rollups
Participants
Present and Speaking:
- Tom Lehman - Presenter, representing Facet/Unstoppable Rollups initiative
- Timothy Clancy - Critical questioner, focused on technical definitions and fork risks
- Luca Donno - L2Beat representative, provided balanced technical critique
- Michael Hirsch - Facet team member