Trading hours for stream management

[PaulRBerg]

A funny idea suggested by @razgraf yesterday during our whiteboarding session:

What if we implement trading hours (9 to 5pm) for stream management? That is, the VM will process stream-related transactions only during these hours, and nothing during all other times. Note that by 'stream-related', I mean any action that would trigger a subgraph update, which includes one-time transfers of streamable NTs.

This limitation would provide us with an official window for optimizing the state, preparing the subgraphs, and implementing such optimization techniques as linear interpolation.

The idea sounded like a joke initially, but after giving it some thought, it seems quite plausible now.

For a long time, the decentralized nature of blockchains has been associated with 24/7 uptime. But maybe that's just a correlation and not a causation? Perhaps a blockchain can have trading hours and still remain decentralized? This is definitely an intriguing hypothesis. There's a sense in which the 7-day withdrawal windows in rollups (see L2Beat) corroborates this hypothesis.

CC @sablier-labs/sabvm

[razgraf]

This idea, in a more granular fashion, also relates to having longer block times.

At the extreme, imagine there's an 1h window between blocks. This provides ample time for nodes to prepare transaction bundles, optimize existing state or for verifiers to run checks on the latest state mutations etc.

[PaulRBerg]

This is a valid way to look at it, although there's some nuance with 'blocks'.

With rollups, there's a difference between L1 and L2 blocks.

No matter what we do, we should absolutely NOT have long block times for L2 Blocks. Frontends use block receipts as confirmations that their users' txs have been confirmed.

However, we can be more lax with L1 block times. Posting them once every hour, or even less frequently, should be OK. IIRC, there are ZK rollups that post only once per 24 hours.

The billion-dollar question is this:

Can we ensure fast L2 block times?

Only benchmarking can answer this ...

[razgraf]

Great way to frame it!

[IaroslavMazur]

So, having a limited window for processing the stream-related txs would mean only processing the token transfers between the users who have no outgoing Streams (both the token sender and recipient) outside that window.

In any case, I don't think that this idea would be well-received by the crypto people: no matter whether the overall system is centralized or decentralized, it's no fun to only be able to send your crypto to a friend from "9 to 5".

Besides, this would also be somewhat contradictory to the whole idea of streaming. Like, what's the point of being able to stream tokens to someone every minute if that someone is only allowed to use them in a certain time window? 🤔

[PaulRBerg]

Thanks for your comments, agree with what you said except the last part. Streaming would still make sense - the settlement would continue to occur by the second despite you not being able to close it. Bad UX, but logically and technically sound.

In any case, this discussion has been superseded by the Nuts and Potatoes mental model.