-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(protocol): Longer term predictability of block parameters (for fast tx confirmation) #14793
Comments
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.
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. |
This issue is stale because it has been open for 30 days with no activity. |
This issue was closed because it has been inactive for a week since being marked as stale. |
#17679) BEGIN_COMMIT_OVERRIDE feat(protocol): allow contract proposers to use calldata as well feat(protocol): add preconfirmation support based on Brecht's PR (with some renaming) to implement #14793 feat(protocol): add proposeBlock2 in TaikoL1.sol and approve2 in GuardianProver.sol to be used post a fork refactor(protocol): avoid writing livenessBond to storage to remove unnecessary SSTORE and SLOAD. refactor(protocol): enable AddressManager to cache address(0) without reading from storage END_COMMIT_OVERRIDE
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:
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
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.
The text was updated successfully, but these errors were encountered: