feat(protocol): Longer term predictability of block parameters (for fast tx confirmation)

[Brechtpd]

Describe the feature request

Currently the window a proposer knows how a block will execute is limited to 12 seconds, because the L2 block directly depends on some L1 values that are only known during the span that L1 block is being created. Most notably:

• The timestamp
• The L1 block height
• The L1 block hash

If we want to make the L2 block building window deterministic for a longer time, that means it needs to be possible for the parameters used for a block to be known for a longer period somehow.

The easiest way to achieve this is to allow the block proposer some flexibility on which values will be used for these block parameters. Because the previous L1 block hash that is immediately available to the L1 smart contract is limited to only the last 256 blocks, this seems to put a pretty reasonable hard limit on how long we'd want this window to be without introducing any extra caching mechanisms.

And so the proposer could decide on what L1 block to base the L2 block upon, as long as

• The L1 block is equal or newer than the L1 block used in the previous L2 block
• The L1 block is not older than 256 blocks

This could however open up L2 block building to more manipulation because it gives more flexibility to the proposer. However, I don't think this will be problematic.

Describe alternatives you've considered

Description of the alternatives you've considered here.

Additional context

Additional context here.

[dantaik]

Brecht, do you think 12 second is too short, what use cases demand "the L2 block building window deterministic for a longer time"?

[dantaik]

I thought the change above may work, but it doesn't -- it's still the same 12 second window.

[Brechtpd]

Brecht, do you think 12 second is too short, what use cases demand "the L2 block building window deterministic for a longer time"?

Mostly fast soft confirmations with an L1 validator that can propose the L1 block in one of the future slots. Could also be helpful maybe to have blocks with an immediate proof attached.

I thought the change above may work, but it doesn't -- it's still the same 12 second window.

Something like that I think would work for the case above because the exact moment the L2 block will be inserted in the L1 block is known. For cases where that may not be the case, some more flexibility would be required.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for a week since being marked as stale.