The one advantage alt-L1s have over L2s

While I regularly sing the praises of Ethereum L2s over alt-L1s, there is one advantage L1s have over L2s, and that is the ability to fallback to social consensus, via hard forks, to fix software bugs.

An L2's security depends entirely on a smart contract deployed on L1. That smart contract in turn cannot be altered via a hard fork in the event that it malfunctions.

This owes primarily to the position held by Ethereum stakeholders at large that the underlying Ethereum protocol must never be altered to fix third party smart contracts.

The insistence against hard forking for application-layer fixes is correct in my opinion, as it ensures a credibly neutral platform, but it does impose a cost on Ethereum L2 security and thus usability.

The proposition of tens, perhaps of hundreds, of billions of dollars worth of capital moving to an L2 is daunting, as it requires that much capital being at risk of loss from a smart contract flaw. The Rollup's layer 1 contracts are also complex pieces of software with many potential places that may contain hidden flaws capable of causing catastrophic losses.

So what can be done? Well the solution would be to create enshrined Rollups which are not third party smart contracts where it would be forbidden to burden the L1 network with a hard fork to fix.

The correct operation of enshrined Rollups would be protected by layer 1 social consensus, so a malfunction would be fixed via a mainnet hard fork.

This would protect Ethereum from catastrophic layer 2 malfunctions and encourage migration to layer 2, which would massively improve Ethereum user experience and adoption.

By designating the Rollup as enshrined, the implicit promise of a Layer 1 hard fork to rectify any flaws in the Layer 2 smart contract does not compromise Layer 1's credible neutrality. This is because such intervention would not stem from arbitrary decisions by the social layer to address issues in the third-party application layer, which could imply favoritism towards specific applications, users, or developers. Instead, it relies on a structured, predetermined consensus mechanism for managing problems in critical infrastructure.