SystemContract: support millisecond block generation #1174
Conversation
WalkthroughThis update refines the handling of block timing and system contract address retrieval in the consensus and mining components. The calculation of block timestamps and mining deadlines now uses millisecond-level granularity, allowing for more precise scheduling based on the configured period. The logic for fetching the L1 signer address in the system contract is temporarily bypassed, with a hardcoded address returned instead of querying L1 storage. Additionally, documentation for the period configuration is updated to specify milliseconds as the unit. The patch version is incremented to reflect these changes. Changes
Sequence Diagram(s)sequenceDiagram
participant Miner
participant ConsensusEngine
participant SystemContract
Miner->>ConsensusEngine: Request next block timestamp
ConsensusEngine->>SystemContract: Get block period (ms)
ConsensusEngine->>ConsensusEngine: Calculate blocks per second
ConsensusEngine->>ConsensusEngine: Determine block index in current second
ConsensusEngine->>ConsensusEngine: Compute precise timestamp
ConsensusEngine->>Miner: Return timestamp
Miner->>Miner: Calculate mining deadline with nanosecond precision
Possibly related PRs
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (3)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
consensus/system_contract/consensus.go(1 hunks)consensus/system_contract/system_contract.go(1 hunks)miner/scroll_worker.go(1 hunks)params/config.go(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
consensus/system_contract/system_contract.go (1)
common/types.go (1)
HexToAddress(218-218)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: test
- GitHub Check: Analyze (go)
🔇 Additional comments (3)
params/config.go (1)
800-800: Documentation update aligns with implementation changesThe comment has been updated to clarify that the Period is measured in milliseconds rather than seconds, which aligns with the implementation changes in other files that now treat this value as milliseconds.
miner/scroll_worker.go (1)
561-578: Improved deadline calculation with millisecond precisionThe mining deadline calculation has been refined to use millisecond-level granularity, correctly interpreting the system contract period as milliseconds. This provides more precise scheduling of blocks within each second.
The implementation includes proper handling of edge cases like zero
blocksPerSecondand calculates timestamps with nanosecond precision, aligning with the changes in the consensus timestamp calculation.consensus/system_contract/consensus.go (1)
229-256: Enhanced timestamp calculation with millisecond precisionThe timestamp calculation has been improved to support millisecond-level block periods, calculating how many blocks fit within each second and appropriately incrementing the timestamp for the last block in each second interval.
This change allows for more flexible and precise block timing, while still maintaining compatibility with the Unix timestamp format (which uses seconds). The implementation also properly handles edge cases like when
blocksPerSecondwould be zero.
georgehao
changed the title
| nowTimestamp := uint64(time.Now().Unix()) | ||
| if s.config.RelaxedPeriod || baseTimestamp < nowTimestamp { | ||
| baseTimestamp = nowTimestamp |
There was a problem hiding this comment.
We can revert these changes to make total diff smaller.
| blocksPerSecond := uint64(1000) / periodMs | ||
| if blocksPerSecond == 0 { | ||
| blocksPerSecond = 1 | ||
| } |
There was a problem hiding this comment.
We can add this as a utility function since it's used in 2 places.
| } | ||
|
|
||
| // Calculate the actual timing based on block number within the current second | ||
| blockIndex := header.Number.Uint64() % blocksPerSecond |
There was a problem hiding this comment.
| blockIndex := header.Number.Uint64() % blocksPerSecond | |
| blockIndex := (header.Number.Uint64() + 1) % blocksPerSecond |
1. Purpose or design rationale of this PR
...
2. PR title
Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:
3. Deployment tag versioning
Has the version in
params/version.gobeen updated?4. Breaking change label
Does this PR have the
breaking-changelabel?Summary by CodeRabbit