The "Nuts and Potatoes" mental model for block production

[PaulRBerg]

Context

@razgraf and I had another productive brainstorming session yesterday at CSX. We ideated on the trading hours for stream management proposal.

Idea

What if we had two types of L2 blocks on SabVM?

1. Nuts: the default blocks WITHOUT subgraph manipulations, which are produced very FAST (e.g. every few seconds)
2. Potatoes: blocks WITH subgraph manipulations, which are produced very SLOW (e.g. once per hour)

The interval between Potato blocks is a critical value because it provides the settlement window for streaming updates. A user might have to wait up to an hour to create, update, or delete streams.

Timestamping

We thought about two ways of timestamping streaming txs:

1. Enforce that timestamps are always equal to one of the Potato blocks' timestamps
2. Introduce a new preferred_timestamp field in streaming txs that allows users to use the timestamp of one of the Nut blocks in-between the Potatoes

We will likely go with option 1 for simplicity's sake. Option 2 introduces a new assumption that, to my knowledge, does not exist on any blockchain today.

Further Notes:

• By subgraph manipulations, we mean this.
• Regardless of types, L2 blocks are consecutive. Nut block $i$ is followed by nut block $i+1$, which is followed by potato block $i_2$.

Drawings

Not super clear, but I put it here just in case.

Feedback

RFC @sablier-labs/sabvm

[razgraf]

Regarding timestamps, would cadences (#84) work the same within the context of potato blocks?

If so, the preferred_timestamp seems necessary - it'd be a inter-block time for when the streaming would have to stop, even though settlement would be done only upon reaching the next potato window.

[PaulRBerg]

I see what you mean here - but I would phrase it differently than necessary vs unnecessary.

• The Potato block times provide the minimum settlement cadence (MSC); cadences smaller than this would be faux cadences because they would work only in BALANCEOF. Thus, we may want to consider disallowing cadences lower than the MSC.
• Alternatively, to allow smaller cadences, we can introduce the preferred_timestamp field.

More research needed on how much backwards compatibility we would lose by introducing this new transaction field.

[PaulRBerg]

Believe it or not, I found something in Optimism that resembles this Nuts and Potatoes dichotomy. See my comment here:

ethereum-optimism/developers#416 (reply in thread)

TL;DR: only some L2 blocks contain (the first in an epoch) contain L1 deposit txs.

It appears that we're on the right track.

[PaulRBerg]

More research needed on the Nuts and Potatoes would influence the Transaction Flow in a rollup:

https://docs.optimism.io/stack/protocol/rollup/transaction-flow

The only implication may be that the Potato tx would remain unprocessed for up to 1 hour.