Skip to content

core,params: add fork readiness indicator in logs #31340

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

Merged

Conversation

lightclient
Copy link
Member

closes #31310

This has been requested a few times in the past and I think it is a nice quality-of-life improvement for users. At a predetermined interval, there will now be a "Fork ready" log when a future fork is scheduled, but not yet active.

It can only possibly print after block import, which kinda avoids the scenario where the client isn't progressing or is syncing and the user thinks it's "ready" because it sees a ready log.

New output:

INFO [03-08|21:32:57.472] Imported new potential chain segment     number=7 hash=aa24ee..f09e62 blocks=1 txs=0 mgas=0.000 elapsed="874.916µs" mgasps=0.000 snapdiffs=973.00B triediffs=7.05KiB triedirty=0.00B
INFO [03-08|21:32:57.473] Ready for fork activation                fork=Prague date="18 Mar 25 19:29 CET" remaining=237h57m0s timestamp=1,742,322,597
INFO [03-08|21:32:57.475] Chain head was updated                   number=7 hash=aa24ee..f09e62 root=19b0de..8d32f2 elapsed="129.125µs"

Easiest way to verify this behavior is to apply this patch and run geth --dev --dev.period=12

diff --git a/params/config.go b/params/config.go
index 9c7719d901..030c4f80e7 100644
--- a/params/config.go
+++ b/params/config.go
@@ -174,7 +174,7 @@ var (
                ShanghaiTime:            newUint64(0),
                CancunTime:              newUint64(0),
                TerminalTotalDifficulty: big.NewInt(0),
-               PragueTime:              newUint64(0),
+               PragueTime:              newUint64(uint64(time.Now().Add(time.Hour * 300).Unix())),
                BlobScheduleConfig: &BlobScheduleConfig{
                        Cancun: DefaultCancunBlobConfig,
                        Prague: DefaultPragueBlobConfig,

@lightclient lightclient force-pushed the core-fork-readiness-alert branch from b9ad44d to 62eda99 Compare March 8, 2025 20:58
Comment on lines +2469 to +2485
// logForkReadiness will write a log when a future fork is scheduled, but not
// active. This is useful so operators know their client is ready for the fork.
func (bc *BlockChain) logForkReadiness(block *types.Block) {
c := bc.Config()
current, last := c.LatestFork(block.Time()), c.LatestFork(math.MaxUint64)
t := c.Timestamp(last)
if t == nil {
return
}
at := time.Unix(int64(*t), 0)
if current < last && time.Now().After(bc.lastForkReadyAlert.Add(forkReadyInterval)) {
log.Info("Ready for fork activation", "fork", last, "date", at.Format(time.RFC822),
"remaining", time.Until(at).Round(time.Second), "timestamp", at.Unix())
bc.lastForkReadyAlert = time.Now()
}
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not check if we should log out before we compute the ready activation?

Suggested change
// logForkReadiness will write a log when a future fork is scheduled, but not
// active. This is useful so operators know their client is ready for the fork.
func (bc *BlockChain) logForkReadiness(block *types.Block) {
c := bc.Config()
current, last := c.LatestFork(block.Time()), c.LatestFork(math.MaxUint64)
t := c.Timestamp(last)
if t == nil {
return
}
at := time.Unix(int64(*t), 0)
if current < last && time.Now().After(bc.lastForkReadyAlert.Add(forkReadyInterval)) {
log.Info("Ready for fork activation", "fork", last, "date", at.Format(time.RFC822),
"remaining", time.Until(at).Round(time.Second), "timestamp", at.Unix())
bc.lastForkReadyAlert = time.Now()
}
}
// logForkReadiness will write a log when a future fork is scheduled, but not
// active. This is useful so operators know their client is ready for the fork.
func (bc *BlockChain) logForkReadiness(block *types.Block) {
if time.Since(bc.lastForkReadyAlert) > forkReadyInterval {
c := bc.Config()
current, last := c.LatestFork(block.Time()), c.LatestFork(math.MaxUint64)
t := c.Timestamp(last)
if t == nil {
return
}
at := time.Unix(int64(*t), 0)
if current < last {
log.Info("Ready for fork activation", "fork", last, "date", at.Format(time.RFC822),
"remaining", time.Until(at).Round(time.Second), "timestamp", at.Unix())
bc.lastForkReadyAlert = time.Now()
}
}
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah nvm, we're never updating bc.lastForkReadyAlert this way

@fjl fjl modified the milestones: 1.15.8, 1.15.9 Apr 11, 2025
Copy link
Member

@MariusVanDerWijden MariusVanDerWijden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM, I tested this extensively so it works. I don't really like that we do it on every block, but I guess its not too much work that we're adding per block

@MariusVanDerWijden MariusVanDerWijden merged commit 13b157a into ethereum:master Apr 17, 2025
4 checks passed
sivaratrisrinivas pushed a commit to sivaratrisrinivas/go-ethereum that referenced this pull request Apr 21, 2025
closes ethereum#31310 

This has been requested a few times in the past and I think it is a nice
quality-of-life improvement for users. At a predetermined interval,
there will now be a "Fork ready" log when a future fork is scheduled,
but not yet active.

It can only possibly print after block import, which kinda avoids the
scenario where the client isn't progressing or is syncing and the user
thinks it's "ready" because it sees a ready log.

New output:

```console
INFO [03-08|21:32:57.472] Imported new potential chain segment     number=7 hash=aa24ee..f09e62 blocks=1 txs=0 mgas=0.000 elapsed="874.916µs" mgasps=0.000 snapdiffs=973.00B triediffs=7.05KiB triedirty=0.00B
INFO [03-08|21:32:57.473] Ready for fork activation                fork=Prague date="18 Mar 25 19:29 CET" remaining=237h57m0s timestamp=1,742,322,597
INFO [03-08|21:32:57.475] Chain head was updated                   number=7 hash=aa24ee..f09e62 root=19b0de..8d32f2 elapsed="129.125µs"
```

Easiest way to verify this behavior is to apply this patch and run `geth
--dev --dev.period=12`

```patch
diff --git a/params/config.go b/params/config.go
index 9c7719d..030c4f80e7 100644
--- a/params/config.go
+++ b/params/config.go
@@ -174,7 +174,7 @@ var (
                ShanghaiTime:            newUint64(0),
                CancunTime:              newUint64(0),
                TerminalTotalDifficulty: big.NewInt(0),
-               PragueTime:              newUint64(0),
+               PragueTime:              newUint64(uint64(time.Now().Add(time.Hour * 300).Unix())),
                BlobScheduleConfig: &BlobScheduleConfig{
                        Cancun: DefaultCancunBlobConfig,
                        Prague: DefaultPragueBlobConfig,
```
0g-wh pushed a commit to 0glabs/0g-geth that referenced this pull request Apr 22, 2025
closes ethereum#31310 

This has been requested a few times in the past and I think it is a nice
quality-of-life improvement for users. At a predetermined interval,
there will now be a "Fork ready" log when a future fork is scheduled,
but not yet active.

It can only possibly print after block import, which kinda avoids the
scenario where the client isn't progressing or is syncing and the user
thinks it's "ready" because it sees a ready log.

New output:

```console
INFO [03-08|21:32:57.472] Imported new potential chain segment     number=7 hash=aa24ee..f09e62 blocks=1 txs=0 mgas=0.000 elapsed="874.916µs" mgasps=0.000 snapdiffs=973.00B triediffs=7.05KiB triedirty=0.00B
INFO [03-08|21:32:57.473] Ready for fork activation                fork=Prague date="18 Mar 25 19:29 CET" remaining=237h57m0s timestamp=1,742,322,597
INFO [03-08|21:32:57.475] Chain head was updated                   number=7 hash=aa24ee..f09e62 root=19b0de..8d32f2 elapsed="129.125µs"
```

Easiest way to verify this behavior is to apply this patch and run `geth
--dev --dev.period=12`

```patch
diff --git a/params/config.go b/params/config.go
index 9c7719d..030c4f80e7 100644
--- a/params/config.go
+++ b/params/config.go
@@ -174,7 +174,7 @@ var (
                ShanghaiTime:            newUint64(0),
                CancunTime:              newUint64(0),
                TerminalTotalDifficulty: big.NewInt(0),
-               PragueTime:              newUint64(0),
+               PragueTime:              newUint64(uint64(time.Now().Add(time.Hour * 300).Unix())),
                BlobScheduleConfig: &BlobScheduleConfig{
                        Cancun: DefaultCancunBlobConfig,
                        Prague: DefaultPragueBlobConfig,
```
0g-wh pushed a commit to 0g-wh/0g-geth that referenced this pull request May 8, 2025
closes ethereum#31310 

This has been requested a few times in the past and I think it is a nice
quality-of-life improvement for users. At a predetermined interval,
there will now be a "Fork ready" log when a future fork is scheduled,
but not yet active.

It can only possibly print after block import, which kinda avoids the
scenario where the client isn't progressing or is syncing and the user
thinks it's "ready" because it sees a ready log.

New output:

```console
INFO [03-08|21:32:57.472] Imported new potential chain segment     number=7 hash=aa24ee..f09e62 blocks=1 txs=0 mgas=0.000 elapsed="874.916µs" mgasps=0.000 snapdiffs=973.00B triediffs=7.05KiB triedirty=0.00B
INFO [03-08|21:32:57.473] Ready for fork activation                fork=Prague date="18 Mar 25 19:29 CET" remaining=237h57m0s timestamp=1,742,322,597
INFO [03-08|21:32:57.475] Chain head was updated                   number=7 hash=aa24ee..f09e62 root=19b0de..8d32f2 elapsed="129.125µs"
```

Easiest way to verify this behavior is to apply this patch and run `geth
--dev --dev.period=12`

```patch
diff --git a/params/config.go b/params/config.go
index 9c7719d..030c4f80e7 100644
--- a/params/config.go
+++ b/params/config.go
@@ -174,7 +174,7 @@ var (
                ShanghaiTime:            newUint64(0),
                CancunTime:              newUint64(0),
                TerminalTotalDifficulty: big.NewInt(0),
-               PragueTime:              newUint64(0),
+               PragueTime:              newUint64(uint64(time.Now().Add(time.Hour * 300).Unix())),
                BlobScheduleConfig: &BlobScheduleConfig{
                        Cancun: DefaultCancunBlobConfig,
                        Prague: DefaultPragueBlobConfig,
```
Rampex1 pushed a commit to streamingfast/go-ethereum that referenced this pull request May 15, 2025
closes ethereum#31310 

This has been requested a few times in the past and I think it is a nice
quality-of-life improvement for users. At a predetermined interval,
there will now be a "Fork ready" log when a future fork is scheduled,
but not yet active.

It can only possibly print after block import, which kinda avoids the
scenario where the client isn't progressing or is syncing and the user
thinks it's "ready" because it sees a ready log.

New output:

```console
INFO [03-08|21:32:57.472] Imported new potential chain segment     number=7 hash=aa24ee..f09e62 blocks=1 txs=0 mgas=0.000 elapsed="874.916µs" mgasps=0.000 snapdiffs=973.00B triediffs=7.05KiB triedirty=0.00B
INFO [03-08|21:32:57.473] Ready for fork activation                fork=Prague date="18 Mar 25 19:29 CET" remaining=237h57m0s timestamp=1,742,322,597
INFO [03-08|21:32:57.475] Chain head was updated                   number=7 hash=aa24ee..f09e62 root=19b0de..8d32f2 elapsed="129.125µs"
```

Easiest way to verify this behavior is to apply this patch and run `geth
--dev --dev.period=12`

```patch
diff --git a/params/config.go b/params/config.go
index 9c7719d..030c4f80e7 100644
--- a/params/config.go
+++ b/params/config.go
@@ -174,7 +174,7 @@ var (
                ShanghaiTime:            newUint64(0),
                CancunTime:              newUint64(0),
                TerminalTotalDifficulty: big.NewInt(0),
-               PragueTime:              newUint64(0),
+               PragueTime:              newUint64(uint64(time.Now().Add(time.Hour * 300).Unix())),
                BlobScheduleConfig: &BlobScheduleConfig{
                        Cancun: DefaultCancunBlobConfig,
                        Prague: DefaultPragueBlobConfig,
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add fork readiness indicator to logs
3 participants