Ethereum-2.0-Staking auf Raspberry Pi

[skunk]

vor 14 Stunden schrieb Muesli2k:

tendiere aber dazu die m2 irgendwie unter Windows zu Clonen oder ein Image zu erstellen.... und auf die größere zu übertragen...

Wie wäre es mit einer m2 copy station? Das ist so eine Art HDD Dock wo man zwei Festplatten reinstecken kann und auf Knopfdruck wird der Inhalt der einen Festplatte auf die andere Kopiert ohne dafür einen PC zu benötigen. Gibt es auch mit m2 Anschluss.

Zum Beispiel sowas hier: https://www.delock.de/produkt/63331/merkmale.html

Du musst nur schauen ob du B oder M Key SSDs hast und ob es dir den Preis Wert ist.

Bearbeitet 8. August 2022 von skunk

[Muesli2k]

Werd es jetzt doch erstmal mit CloneZilla versuchen, Image vom Validator erstellen und auf die größere SSD recovern... Downtime lässt sich nicht umgehen, 4-5 Stunden..

Da es 2 Clients sind, kann ich nach dem sichern, den Validator weiter laufen lassen, recovere das Image auf die 2 TB SSD und bevor diese online geht, nehm ich den alten offline..

Werde berichten wie es ausgegangen ist 🙂

Wenn die 2TB SSD erfolgreich läuft, dann und erst dann mach ich mich an die ganzen Änderungen die es jetzt für Merge ready noch braucht...

 

Bearbeitet 13. August 2022 von Muesli2k

[Cricktor]

Macht das keine Probleme, wenn du dann den weitergelaufenen Validator offline nimmst und dann den Validator mit der älteren Image-Kopie auf der 2TB-SSD wieder online nimmst? (Ich verstehe schon, daß zu keiner Zeit zwei weitgehend identische Validatoren online gehen. Aber der auf der 2TB-SSD kopierte Validator-Zustand ist zumindest einige Stunden älter, als der Validator auf dem anderen Client zuletzt online war.)

[Muesli2k]

vor 9 Stunden schrieb Cricktor:

Macht das keine Probleme, wenn du dann den weitergelaufenen Validator offline nimmst und dann den Validator mit der älteren Image-Kopie auf der 2TB-SSD wieder online nimmst? (Ich verstehe schon, daß zu keiner Zeit zwei weitgehend identische Validatoren online gehen. Aber der auf der 2TB-SSD kopierte Validator-Zustand ist zumindest einige Stunden älter, als der Validator auf dem anderen Client zuletzt online war.)

Nein war kein Problem, habs jetzt soweit das das recoverte 1TB Image auf der 2TB SSD läuft 🙂

Der hat kurz am Anfang gemeckert das die BeaconNode nicht aktuell und sync ist, das war aber nach 2-3 Minuten weg, und er läuft nun seit heute Nacht anstandslos...

Mit Gparted noch die Partition groß gezogen und nun endlich wieder einiges an free DiskSpace..

Ich meine auch das es ihm egal ist, bevor er mit dem attestieren beginnen kann, lädt er ja immer das Ende der Kette und klinkt sich erst ein wenn er sync ist, und attestiert immer den zu diesem Zeitpunkt aktuellen Block.. wenn du zwischendrin einen Ausfall hast, musst ja auch immer nachladen, bevor er wieder starten kann..

 

 

 

 

 

 

 

[kryptokenner]

Zahlt man als Validator nach dem Merge weiterhin in den gleichen Contract ein oder gibt es einen zweiten Contract? Die Staked ETH bleiben ja bis zum Post Merge Upgrade im Contract gesperrt, sodass ich mich frage, ob nach dem Merge die gelockten Ether flexibler benutzt werden können als im Zeitraum 2020 bis zum Merge.

[skunk]

vor 1 Stunde schrieb kryptokenner:

Zahlt man als Validator nach dem Merge weiterhin in den gleichen Contract ein oder gibt es einen zweiten Contract? Die Staked ETH bleiben ja bis zum Post Merge Upgrade im Contract gesperrt, sodass ich mich frage, ob nach dem Merge die gelockten Ether flexibler benutzt werden können als im Zeitraum 2020 bis zum Merge.

Mir ist nicht bekannt, dass da irgendwas am Contract verändert werden soll. Auch nach dem Merge wird das Guthaben weiterhin gesperrt bleiben bis irgendwann mal ein Withdrawal implementiert wird. Das einzige was sich durch den Merge ändert ist, dass die Validatoren dann auch die Priority Fee bekommen und diese kann sofort bewegt und verkauft werden.

[kryptokenner]

1 hour ago, skunk said:

Mir ist nicht bekannt, dass da irgendwas am Contract verändert werden soll. Auch nach dem Merge wird das Guthaben weiterhin gesperrt bleiben bis irgendwann mal ein Withdrawal implementiert wird. Das einzige was sich durch den Merge ändert ist, dass die Validatoren dann auch die Priority Fee bekommen und diese kann sofort bewegt und verkauft werden.

Wenn das so ist, dann wird ja nochmals mehr ETH-Angebot dem Netzwerk entzogen, jedenfalls bis zu diesem Upgrade. Wahrscheinlich sogar besser dann die ETH2 liquide zu behalten  

[Muesli2k]

vor 52 Minuten schrieb kryptokenner:

Wenn das so ist, dann wird ja nochmals mehr ETH-Angebot dem Netzwerk entzogen, jedenfalls bis zu diesem Upgrade. Wahrscheinlich sogar besser dann die ETH2 liquide zu behalten  

Der Smart Contract liegt auf der Beacon Chain, für diesen hat es damals die 500tsd ETH gebraucht um die Chain überhaupt zu starten.. jeder zukünftige Validator zahlt auf diesen ein…

Wie @skunkauch schon schrieb wird man vorerst nur die jetzt entstehenden Fees ausbezahlt bekommen.. Als nächstes kommt dann so weit ich weis die Funktion vom Validator überschüssiges Guthaben, also alles was größer >32ETH verfügbar ist abzuheben..

Von der Logik her macht es auch keinen Sinn mehr abzuheben, weil die 32 Mindesteinlage müssen bestehen bleiben. Wer mehr abheben möchte muss dann den Validator auflösen, das geht auch heute schon, kostet aber Unsummen..

es wird meiner Meinung nach auch keinen run zum abheben geben, weil die meisten werden ihre Einlage ja mit mind. 32ETH weiter laufen lassen…

Last but not least, der Merge kommt einem Triple halving bei Bitcoin gleich, die täglich ausgegebenen neuen ETH gehen von 13.000 auf 1500 runter, und somit die jährliche Inflationsrate auf 0,4%

 

 

 

 

 

 

 

[skunk]

@Cookies statt Coins^^Wie sieht es bei dir aus? Hast du die notwendigen Umstellungen schon gemacht oder verfolgst du eher den Plan mit dem Merge Offline zu gehen? Letzte Chance  

Edit: Ich hab dir mal noch eine PM geschickt. Die sollte hoffentlich eine Email Benachrichtigung auslösen.

Bearbeitet 27. August 2022 von skunk

[Muesli2k]

@skunk

..es ist diesmal gar nicht verkehrt gewesen etwas länger zu warten, ich mach die Updates in der Regel auch immer erst 5-7 Tagen nach Release.

In der für den Merge finalen Geth Version 1.10.22 war diesmal ein richtig fießer Bug, so das es die Chain zerblasen hat, und wer gleich auf die neuste Version aktualisiert hat, der musste unter Umständen einen re-org der kompletten DB laufen lassen...

https://coingape.com/breaking-bugs-found-in-ethereum-clients-mainnet-merge-releases/

 

 

 

 

 

 

[skunk]

vor 21 Minuten schrieb Muesli2k:

In der für den Merge finalen Geth Version 1.10.22 war diesmal ein richtig fießer Bug, so das es die Chain zerblasen hat, und wer gleich auf die neuste Version aktualisiert hat, der musste unter Umständen einen re-org der kompletten DB laufen lassen...

Die Problematik mit der Geth Dominanz hast du schon aufgeschnappt? Ich habe auf Erigon umgstellt um dieses Risiko zu minimieren. Vorteil: Online Pruning und weniger belastend für mein System. Nachteil: Braucht locker eine Woche für den ersten Sync und ist noch Alpha.

Besu soll recht schnell mit dem Sync sein. Vielleicht probiere ich das bei Gelegenheit noch aus.

[Muesli2k]

vor 12 Minuten schrieb skunk:

Die Problematik mit der Geth Dominanz hast du schon aufgeschnappt? Ich habe auf Erigon umgstellt um dieses Risiko zu minimieren. Vorteil: Online Pruning und weniger belastend für mein System. Nachteil: Braucht locker eine Woche für den ersten Sync und ist noch Alpha.

Besu soll recht schnell mit dem Sync sein. Vielleicht probiere ich das bei Gelegenheit noch aus.

Ja so am Rande mitbekommen, aber bevor ich da jetzt anfange mit irgendwelchen unausgereiften Alpha Geschichten, bleib ich lieber beim Marktführer

[Cookies statt Coins^^]

vor 8 Stunden schrieb skunk:

@Cookies statt Coins^^Wie sieht es bei dir aus? Hast du die notwendigen Umstellungen schon gemacht oder verfolgst du eher den Plan mit dem Merge Offline zu gehen? Letzte Chance  

Hi, danke für deine Erinnerung. Ich habe es schon mitbekommen, dass bald der Merge bevorsteht, aber habe es immer weiter verdrängt. Habe privat sehr viel um die Ohren und habe mich daher schon lange nicht mehr damit beschäftigt. Ich muss nun dringen anfangen, mich da einzulesen..
Vermutlich muss ich neue Hardware kaufen, denn das wird wohl auf meinem alten Raspberry Pi nicht laufen.
Ich hatte ja bisher Infura genutzt, da ich damals Geth auf dem Raspberry Pi nicht zum laufen gebracht hatte. Ich überlege mir mal einen Schlachtplan und melde mich dann die Tage wieder.
Ihr seid dann wohl alle schon bereit für den Merge?

[Muesli2k]

Aus ein paar Fehlern werde ich nicht schlau, scheint noch zu syncen oder??

 

Aug 28 15:05:41 ETH-NUC8i5BEK lighthouse[4258]: Aug 28 13:05:41.013 WARN Not ready for merge                     info: The execution endpoint is connected and configured, however it is not yet synced, service: slot_notifier
Aug 28 15:05:47 ETH-NUC8i5BEK lighthouse[4258]: Aug 28 13:05:47.678 INFO New block received                      root: 0x23f0995432340e6693e8d588578131507f97e7978c1c3aacf07c13b06bdc328f, slot: 4572327
Aug 28 15:05:53 ETH-NUC8i5BEK lighthouse[4258]: Aug 28 13:05:53.001 INFO Synced                                  slot: 4572327, block: 0x23f0…328f, epoch: 142885, finalized_epoch: 142883, finalized_root: 0x4048…5424, exec_hash: n/a, peers: 69, service: slot_notifier
Aug 28 15:05:53 ETH-NUC8i5BEK lighthouse[4258]: Aug 28 13:05:53.039 WARN Not ready for merge                     info: The execution endpoint is connected and configured, however it is not yet synced, service: slot_notifier
Aug 28 15:05:59 ETH-NUC8i5BEK lighthouse[4258]: Aug 28 13:05:59.842 INFO New block received                      root: 0xc84c9ab5f7eb94bede4c8494e7fbdf3766c4c89121260d796c6261af6c9f2b56, slot: 4572328
Aug 28 15:06:05 ETH-NUC8i5BEK lighthouse[4258]: Aug 28 13:06:05.001 INFO Synced                                  slot: 4572328, block: 0xc84c…2b56, epoch: 142885, finalized_epoch: 142883, finalized_root: 0x4048…5424, exec_hash: n/a, peers: 70, service: slot_notifier
Aug 28 15:06:05 ETH-NUC8i5BEK lighthouse[4258]: Aug 28 13:06:05.029 WARN Not ready for merge                     info: The execution endpoint is connected and configured, however it is not yet synced, service: slot_notifier
Aug 28 15:06:08 ETH-NUC8i5BEK lighthouse[4258]: Aug 28 13:06:08.278 WARN Execution endpoint is not synced        action: trying fallback, last_seen_block_unix_timestamp: 0, endpoint: http://127.0.0.1:8551/, auth=true, service: deposit_contract_rpc
Aug 28 15:06:08 ETH-NUC8i5BEK lighthouse[4258]: Aug 28 13:06:08.278 ERRO No synced execution endpoint            advice: ensure you have an execution node configured via --execution-endpoint or if pre-merge, --eth1-endpoints, service: deposit_contract_rpc
Aug 28 15:06:08 ETH-NUC8i5BEK lighthouse[4258]: Aug 28 13:06:08.278 ERRO Error updating deposit contract cache   error: "All fallbacks errored: http://127.0.0.1:8551/, auth=true => EndpointError(FarBehind)", retry_millis: 60000, service: deposit_contract_rpc

[skunk]

vor 17 Minuten schrieb Muesli2k:

however it is not yet synced

Klingt danach als wäre deine Geth node noch mit dem Sync beschäftigt. Schau da sonst auch mal in die Logs.

[Muesli2k]

vor 14 Minuten schrieb skunk:

Klingt danach als wäre deine Geth node noch mit dem Sync beschäftigt. Schau da sonst auch mal in die Logs.

ja die scheint sich neu zu syncen, kann man geth versehentlich 2x installieren? ich hatte das Problem das sich die Version nicht über den Paketmanager aktualisieren ließ, und habs dann manuell geladen...

Zudem haben sich die Pfade wohl mit der Zeit geändert, und aus dem goeth wurde mit der zeit ein geth... jetzt befürchte ich das ich es doppelt installiert habe...

Bearbeitet 28. August 2022 von Muesli2k

[Muesli2k]

Ich habs irgendwie geschafft 1.10.21 und 1.10.23 parallel zu installieren

das doofe ist, da die Anleitungen sich alle unterscheiden, 1.10.21 ist gesynced und in der alten Anleitung hieß es /goethereum User goeth

in der neuen 1.10.21 sind die Pfade anders und läuft wohl als User Geth und liegt unter /geth ab....

muesli2k@ETH-NUC8i5BEK:~$ sudo apt show geth
Package: geth
Version: 1.10.21+build27994+focal
Status: install ok installed
Priority: extra
Section: science
Source: ethereum
Maintainer: Go Ethereum Linux Builder <geth-ci@ethereum.org>
Installed-Size: 31,5 MB
Depends: libc6 (>= 2.17)
Homepage: https://ethereum.org
Download-Size: unbekannt
APT-Manual-Installed: yes
APT-Sources: /var/lib/dpkg/status
Description: Ethereum CLI client.
 Ethereum CLI client.

muesli2k@ETH-NUC8i5BEK:~$ geth version
Geth
Version: 1.10.23-stable
Git Commit: d901d85377c2c2f05f09f423c7d739c0feecd90a
Git Commit Date: 20220824
Architecture: amd64
Go Version: go1.18.5
Operating System: linux
GOPATH=
GOROOT=go
 

Bearbeitet 28. August 2022 von Muesli2k

[skunk]

vor 23 Minuten schrieb Muesli2k:

in der neuen 1.10.21 sind die Pfade anders und läuft wohl als User Geth und liegt unter /geth ab....

Das kannst du ja relativ einfach beheben. Mach mal in beiden Ordnern ein `ls -al`. Achte dann auf die Zeile die in etwa so aussieht: `drwxr-xr-x 9 eth  eth  4096 28. Aug 15:06 .` Der Punkt am Ende besagt, dass die Zeile das aktuelle Verzeichnis repräsentiert. In meinem Fall besagt die Zeile, dass der Ordner dem User eth gehört. Wenn du das in beiden Ordnern machst, kannst du erstmal prüfen ob sie dem gleichen User gehören.

Ein `du -sh` gibt die Größe des Verzeichnis aus. Das größere Verzeichnis von beiden ist das was du behalten möchtest. In dem anderen Verzeichnis setzt du ein `rm -r *` ab. Das löscht alles aus dem Verzeichnis raus. Achte daher darauf, dass du das nicht versehentlich in einem falschen Verzeichnis ausführst.

Als letztes noch mit `mv` das Verzeichnis verschieben und mit `chown -R eth:eth .` die Zugrissrechte richtig setzen. In meinem Fall user eth. Du trägst dort das ein was `ls -al` ganz am Anfang ausgegeben hatte.

Nochmal die Kurzfassung:
Aufschreiben welcher User die neue Version nutzt mit `ls -al`
Altes Verzeichnis in das neue Verzeichnis verschieben.
Mit chown die Zugriffsrechte korrigieren.

Bearbeitet 28. August 2022 von skunk

[Muesli2k]

Vielen Dank @skunk 

Das sieht doch gleich viel besser aus 👍🙂

Aug 28 17:10:17 ETH-NUC8i5BEK lighthouse[1567]: Aug 28 15:10:17.011 INFO Ready for the merge                     current_difficulty: 57408881820840934276518, terminal_total_difficulty: 58750000000000000>

Ich hab den Ordner /var/lib/geth gekillt und geth.service noch die /var/lib/goethereum angegeben, dort liegt die geladenen Blockchain, und gehört dem User goeth

falls mal einer das selbe Problem haben sollte... nach der alten Installationsanleitung muss das so aussehen;

[Unit]
Description=Geth Execution Client (Mainnet)
After=network.target
Wants=network.target

[Service]
User=goeth #anstelle geth
Group=goeth #anstelle geth
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/geth \
  --mainnet \
  --datadir /var/lib/goethereum \  #anstelle /var/lib/geth
  --authrpc.jwtsecret /var/lib/jwtsecret/jwt.hex

[Install]
WantedBy=default.target

 

Bearbeitet 28. August 2022 von Muesli2k

[Muesli2k]

sieht ja noch nicht so Prall aus... 😬

Merge ready sind erst 44,4% aller Nodes...

https://ethernodes.org/merge

[Cookies statt Coins^^]

vor 18 Stunden schrieb Muesli2k:

Merge ready sind erst 44,4% aller Nodes...

Und bei dieser Übersicht ist mein System noch gar nicht mit dabei, da ich meinen Validator bislang nur über Infura betrieben habe, was hier gar nicht auftaucht..

 

Ich habe mich noch ziemlich eingelesen in die Materie. Grundsätzlich ist es gar nicht so kompliziert:
Zusätzlich zum bereits bestehenden Beacon-Node und zum Validator braucht man nur noch einen Execution-Client. Dazu gibt es ja mehrere zur Auswahl.
Danach kommen noch ein paar kleinere Konfigurationen, was ja alles sehr ausführlich auf diversen Seiten beschrieben ist, z.B. https://github.com/remyroy/ethstaker/blob/main/prepare-for-the-merge.md

Was mir jedoch noch Sorgen macht ist die Installation des Execution-Clients auf meinem Raspberry Pi.
Ich habe mich aktuell für Geth entschieden, da dieser auf dem Rasperry Pi am besten laufen sollte: "Ethereum on ARM supports 4 Eth1 clients: Geth, Nethermind, Openethereum and Besu [...]. We recommend running Geth as default as it is the most reliable and tested client for ARM devices." [ https://ethereum-on-arm-documentation.readthedocs.io/en/latest/quick-guide/running-ethereum.html ]

Das große Risiko bei einem globalen Ausfall von Geth ist mir bewusst und damit lebe ich zunächst. Viel wichtiger ist es mir, die benötigte Konfiguration schnellstmöglichst zum Laufen zu bekommen.
Ich habe vor zwei Tagen Geth auf meinem Testsystem im Testnet "Goerli" installiert und es startet auch ohne Fehler. Jedoch startet hier die Synchronisation nicht, da der Client seit Tagen keine passenden Peers für die Synchronisation findet. Die Anzahl der verbundenen Peers schwankt zwischen 0 und 2, mehr werden es aber nie.
Habe es mit den Synchronisierungs-Optionen "Full" und "Snapshot" versucht, beides ohne Erfolg. Vielleicht würde es im Mainnet besser klappen, weil es mehr Clients gibt, aber was hilft mir das auf Dauer, wenn ich dann keine passende Testumgebung habe. Werde dies aber trotzdem als nächstes mal versuchen, ob es im Mainnet besser laufen würde.
Werde mir aber noch einen anderen Client heraussuchen. Welchen könnt ihr hier empfehlen, der sich schnell und einfach installieren lässt und der mit möglichst wenig Ressourcenverbrauch auch auf einer ARM-CPU läuft?

Für den Mainnet-Raspberry-Pi brauche ich eine zusätzliche Festplatte, denn die aktuelle hat nur 1 TB Speicher, empfohlen werden aber nun 2 TB mit dem Execution-Client (z.B bei Geth).
Die bisherige 1-TB-SSD würde ich am Raspberry-Pi für die Beacon-Chain und Validator belassen und stattdessen zusätzlich an den zweiten USB-3-Steckplatz eine zweite Festplatte anschließen und beide parallel laufen lassen (ich hoffe, das überlastet nicht den USB-Controller). Dieses mal werde ich mir eine M.2-SSD zulegen. Kenne mich mit Hardware nicht gut aus, aber würde folgendes kaufen:

Festplatte:
https://www.amazon.de/Crucial-CT2000P2SSD8-Internes-2400-NAND/dp/B08GVDNTGJ/
- Kosten: 139€
- Kapazitäten: bis zu 2TB mit sequentiellen Lese/Schreibvorgängen bis zu 2.400/1.900 MB/s
- unterstützt NVMe

Dazu sollte folgender USB-M.2(NVME)-Adapter passen:
https://www.amazon.de/Adapter-basierter-Festplattenkonverter-tragbare-Unterstützung/dp/B09H6K3TTQ
- max Speed: 10 Gbit/s mit USB 3.1

Die ausgesuchte M2-SSD ist zwar relativ langsam im Vergleich zur Konkurrenz (Geschwindigkeit von bis zu 5.000 MB/s möglich), jedoch unterstützt USB 3.0 eh nur eine maximale Geschwindigkeit von 5Gbit/s (625MB/s).
Somit sollte die ausgewählte Festplatte für den Raspberry Pi genau richtig sein. Wenn sich jemand besser dazu auskennt, dann bitte melden, werde die mir morgen kaufen.

[Muesli2k]

vor einer Stunde schrieb Cookies statt Coins^^:

Somit sollte die ausgewählte Festplatte für den Raspberry Pi genau richtig sein. Wenn sich jemand besser dazu auskennt, dann bitte melden, werde die mir morgen kaufen.

Die Crucial ist ok, wie du sagst ist USB hier sowieso der limitierende Faktor,

aber willst nicht mal den Rasperry durch etwas leistungsstärkere Hardware ersetzen ? 

Ich finde die Teile sind ja ganz süß um bissl damit zu basteln, aber für einen Mainnet Validator sind/waren die mir schon immer zu schwach...
Einen Intel Nuc 4Kerner aus der 8000er Serie bekommt man zu wirklich erschwinglichen Preisen, bei der M2 habe ich mich z.B. für das Modell von Transcend entschieden, die hatte ich auch beim Chia Mining im Einsatz, und die haben einen sehr hohen TBW (TerraBytesWritten), was denke ich durch die vielen Zugriffe hier sicher von Vorteil sein wird.. 

https://amzn.eu/d/gL9qkUh

 

 

Bearbeitet 30. August 2022 von Muesli2k

[Cricktor]

Ich bezweifele, daß du dauerhaft stabil zwei SSDs an den zwei USB3-Ports vom Raspi 4B betreiben kannst, da der Raspi maximal 1,2A für alle USB-Ports zusammen liefern kann. Wenn die USB3-SSD-Adapter keine eigene Stromversorgung haben, dann reizt meist eine SSD schon das Energie-Budget nahezu aus (die Sandisk Plus SSDs sind wohl am genügsamsten mit 0,7A Spitzenstrom; Samsung Evos, Samsung QVO, Crucial kratzen alle an der 1A Marke und soweit ich das wahrgenommen habe, sind M.2 NVMe SSDs meist noch stromdurstiger.

[Muesli2k]

Bekomme in Geth ständig diese Meldung, habt ihr eine Idee was das bedeutet ? und was man dagegen unternehmen kann?

Der Vali läuft weiter ohne Einschränkung und sagt auch weiter Merge ready, leider hab ich bisher nichts finden können was diese Meldung zu bedeuten hat ?

Sep 03 10:49:58 ETH-NUC8i5BEK geth[844]: WARN [09-03|10:49:58.315] Failed to decode block body              block=13,100,309 error=EOF
Sep 03 10:49:58 ETH-NUC8i5BEK geth[844]: WARN [09-03|10:49:58.315] Failed to decode block body              block=13,100,308 error=EOF
 

[skunk]

vor 1 Stunde schrieb Muesli2k:

Bekomme in Geth ständig diese Meldung, habt ihr eine Idee was das bedeutet ? und was man dagegen unternehmen kann?

Der Vali läuft weiter ohne Einschränkung und sagt auch weiter Merge ready, leider hab ich bisher nichts finden können was diese Meldung zu bedeuten hat ?

Sep 03 10:49:58 ETH-NUC8i5BEK geth[844]: WARN [09-03|10:49:58.315] Failed to decode block body              block=13,100,309 error=EOF
Sep 03 10:49:58 ETH-NUC8i5BEK geth[844]: WARN [09-03|10:49:58.315] Failed to decode block body              block=13,100,308 error=EOF
 

https://github.com/ethereum/go-ethereum/issues/24158#issuecomment-1017311444