Could it be possible to have Rollup-to-L1 communication cemented immediately?

Question

I've read the rollup documentation and various blogs that explain the enshrined aspect and permissionless aspect of Tezos SORUs, and one inconvenience inherent to the Optimistic layer hindered my imagination about what could be achieved in the future. It is the delay of 2 weeks which is set to allow anyone to challenge the current commitment and to ensure the safety of users from malicious rollups (assuming there is at least one honest node running the rollup).

But then, with this exact aspect of decentralizing the duty of ensuring safety and honesty. I like to imagine that in the future there would be some successful rollups with many users, and eventually a big community behind. Those rollups would be running on many nodes (maybe there would be some different incentives than safety, but I can't imagine what). Some of these nodes would be managed by the community.

Can I assume that the delay of 2 weeks may eventually get removed or reduced if :

• the number of nodes for a certain rollup is greater than some threshold (3 for example)
• we can measure the possiblity of having an honest node (which will ensure the safety against malicious rollups).

If, on top of this, we can add some incentives to reward the nodes, we will have this simple balance of interests :

• more nodes -> less delay
• less delay -> more possibilities , better UX -> more activity
• more activity -> more rewards for nodes

Answer 1

There is a path to have a shorter withdrawal period, it requires additional protocol where liquidity providers accept reorg risks in exchange for a premium.

The protocol could work as follows:

• User submits a withdrawal request to the rollup
• Rollup kernel emits an outbox message encapsulating the withdrawal
• Rollup node pushes the commitment including that message onto L1
• User constructs proof of inclusion for his outbox message (actually two proofs: outbox message belongs to a particular commitment + commitment belongs to a particular L1 block)
• User submits withdrawal request and the proof to the L1 contract where LP funds are locked
• L1 contract verifies the proof and sends withdrawal amount minus LP fee to the user
• After 2 weeks someone (LP or external relayer) executes outbox message that refills the contract balance

In this scheme there can be mutiple LPs with different fees and margin available, one can build an additional aggregation layer on top of them.

Note that there are still time issues as the steps are not atomic:

• User has to specify the LP in the withdrawal request at T1
• Rollup submits commitment with outbox message at T2
• User submits withdrawal & proof at T3

On the one hand, User has to be sure that the liquidity will be still available at T3, so he needs to reserve it before initiating withdrawal at T1.

On the other hand, LP does not want to be abused with false reservations (when User reserves some amount but does not submit outbox msg) so there has to be a spam-prevention mechanism, e.g. small deposit User has to place in order to make a reservation.

To avoid the additional friction one can proceed without the reservation system: use pool aggregation and enable the escape path where User can get his funds after the commitment cementation if no one provided him with early liquidity (basically fallback to the native ticket bridging mechanism).