SystemContract: support millisecond block generation #1174
+52
−9
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## Walkthrough
The changes update the block timestamp calculation logic in the consensus system contract to use millisecond precision, adjusting both the timestamp computation and deadline logic in the mining worker. Logging is added for mining events, and documentation is updated to clarify the unit of block period. The patch version is incremented. Additionally, the method fetching the signer address from L1 is simplified to return a fixed address.
## Changes
| File(s) | Change Summary |
|----------------------------------------------------|---------------------------------------------------------------------------------------------------------------------|
| consensus/system_contract/consensus.go | Refined `CalcTimestamp` to compute timestamps using millisecond periods, considering block index within a second. |
| miner/scroll_worker.go | Updated mining deadline calculation for millisecond precision; added logging for mining events and transaction state.|
| params/config.go | Updated comment for `SystemContractConfig.Period` to specify milliseconds instead of seconds. |
| params/version.go | Incremented `VersionPatch` from 40 to 41. |
| consensus/system_contract/system_contract.go | Modified `fetchAddressFromL1` to return a fixed Ethereum address instead of fetching dynamically from L1 storage. |
## Sequence Diagram(s)
```mermaid
sequenceDiagram
participant Worker
participant Consensus
participant SystemTime
Worker->>Consensus: Request CalcTimestamp(parentHeader)
Consensus->>Consensus: Compute blocksPerSecond = 1000 / period
Consensus->>Consensus: Determine blockIndex = parent.Number % blocksPerSecond
Consensus->>Consensus: If last block in second, increment timestamp by 1s
Consensus->>SystemTime: Get current Unix time
Consensus->>Consensus: If RelaxedPeriod or computed < now, set timestamp = now
Consensus-->>Worker: Return timestamp
Worker->>Worker: Calculate mining deadline with nanosecond precision
Worker->>Worker: Log deadlineReached and tx countPossibly related PRs
Suggested labels
Suggested reviewers
Poem
|
![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
colinlyguo
reviewed
Apr 28, 2025
Comment on lines
+251
to
+253
| 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.
colinlyguo
reviewed
Apr 28, 2025
Comment on lines
+562
to
+565
| 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.
Thegaram
requested changes
Apr 29, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Bug Fixes
Documentation
Chores