Geth client well behind chain head

[astral cypress]

The issue I’m seeing is that my Geth client is always around 196 000 blocks behind the head. Prysm is fine, it’s at the head. I understand they are different chains and increment differently.but as I understand it they should be much closer than that.
My validators are active and attesting .

I have just closed a ticket with dappnode support where they suggest the issue might be solved here, suggesting it may be a problem with the checkpoint. I checked that and can’t see a problem.

The validators run but they are so far behind and as I understand it, if Geth gets too far behind for too long Prysm may fail to validate certain attestations or produce valid blocks. I may be wrong here but this is what I’m trying to understand.
I have deleted Geth volumes, restarted and no improvement. Things have been running smooth since testnet. It’s only since this upgrade I get issues. This may also explain the other issue mentioned in the other post by @exotic gulch regarding the 2% Ave effectiveness.

[steady zephyr]

<@&816220244892319754>

[toxic lion]

Hey @astral cypress,
What’s your setup? Is it a Dappnode LUKSO NUC with Geth + Prysm?
If so, could you please share all version details (including the Dappnode Core version, etc.) and your NUC hardware specs?

This would be super helpful for us and might speed things up 🙏
Based on your answers, we can try to reproduce the issue on our side / on the Dappnode side.

[steady zephyr]

@astral cypress:

It’s a Dappnode Lukso running Geth + Prysm. It’s my own 12 core NUC with 700 Gb SSD 16 Gb ram.
Geth version : Version: 0.1.5 (ethereum/[email protected], dappnode/staker-package-s)
prysm : Version: 0.1.3 (prysmaticlabs/[email protected], dappnode/staker-package-scripts)

dappnode details:

Core DAppNode Packages versions
bind.dnp.dappnode.eth: 0.2.12
core.dnp.dappnode.eth: 0.3.10
dappmanager.dnp.dappnode.eth: 0.2.112, commit: 3c45f5b0
https.dnp.dappnode.eth: 0.2.2
ipfs.dnp.dappnode.eth: 0.2.27
notifications.dnp.dappnode.eth: 0.1.7
premium.dnp.dappnode.eth: 0.1.0
wifi.dnp.dappnode.eth: 0.2.9
wireguard.dnp.dappnode.eth: 0.1.3
System info
dockerComposeVersion: 2.39.4
dockerServerVersion: 28.4.0
dockerCliVersion: 28.4.0
os: debian
versionCodename: bookworm
architecture: amd64
kernel: 6.1.0-13-amd64
Disk usage: 12%

[toxic lion]

Thanks. We're checking this with the Dappnode dev team. I'm not sure if it's related to the Dappnode issues yet: #901964192117047356 message, since our packages are supposed to work with the exact Geth and Prysm versions and it was working fine:

• Geth v1.15.11: https://github.com/dappnode/DAppNodePackage-geth-generic/blob/7b8cebf8e45ec9a7ab7ba4c05f80359f570c903c/package_variants/lukso/docker-compose.yml#L9
• Prysm v6.0.4: https://github.com/dappnode/DAppNodePackage-prysm-generic/blob/40ef4120b4fe87c5650871da63fb3dc1ec5a6fd8/package_variants/lukso/docker-compose.yml#L

[steady zephyr]

@astral cypress

[astral cypress]

My message keeps getting blocked.

[steady zephyr]

Are you referring to the one that I've shared above? Sorry for the inconvenience. 🙏🏻

[astral cypress]

Yep , sorry didn’t see the first one 😬 Thanks

[toxic lion]

I've just confirmed — it's a Dappnode manifest file issue (UI side only). Requesting the NUC for Geth and Prysm versions provides valid versions (screen). So that's not the case.

Anyway, we're currently experiencing some Consensus Explorer UI issues related to the 2% Avg effectiveness indicators. You can double-check your validator key via https://dora.explorer.mainnet.lukso.network/

We're also working on a complete fix for the issue, which will likely come with the Explorer V2 update.

[toxic lion]

Currently, there are 4,762,951 more slots than blocks since The Merge on the Ethereum Mainnet.
This difference is completely normal in a PoS network. The consensus layer operates on time-based slots (every 12 seconds), while the execution layer only produces a block when a validator successfully proposes one. As a result, slot numbers always advance faster than block numbers.

At the moment, on the LUKSO Mainnet, the latest slot on the consensus layer is 6,262,191, and the highest block on the execution layer is 6,065,299, which is consistent with the same PoS architecture.