Ethereum-2.0-Staking auf Raspberry Pi

[skunk]

Huch da habe ich glatt ein paar Fragen übersehen. Ich beantworte sie mal besser spät als nie.

Am 10.9.2021 um 19:45 schrieb Muesli2k:

Fällt die Geth Geschichte nicht weg wenn auf ETH 2.0 umgestellt wird?

Das habe ich mir noch nicht so genau angeschaut. Es wird irgendwann der Tag kommen an dem die ETH2 Chain auch Transaktionen prozessieren soll. Im Moment sind es ja eher leere Blöcke. Sobald die Blöcke mit Transaktionen voll sind, haben wir doch das gleiche Problem wie vorher oder nicht? Ich vermute mal wir werden noch eine Weile ausreichend Plattenplatz bereitstellen müssen bis irgendwann die Blockchain mittels Sharding aufgeteilt wird.

Am 10.9.2021 um 19:45 schrieb Muesli2k:

ansonsten wäre tatsächlich die Überlegung ob man nicht auf eine größere Platte gehen sollte? 2TB, 4TB...?

Platte meinst du hier vermutlich umgangssprachlich und gemeint ist eine SSD. Ich habe bei mir eine 2TB SSD verbaut. Jetzt ist es natürlich so, dass die Kosten sowieso komplett vom Reward abgezogen werden. Insofern ist es nur eine Frage des Verhältnis. Wenn der Aufpreis für eine 4TB SSD nur ein Bruchteil deines Rewards ist, würde ich das einfach machen. Mein Plan ist es zum Black Friday / Cyber Monday zuzuschlagen. Als erstes beim Steuertool meiner Wahl und dann lasse ich mir ausrechen wie viel Mining Rewards ich habe. ETH2 spielt bei mir bisher keine Rolle. Warum das so ist, erkläre ich gleich noch etwas genauer.

Wenn der Gewinn nach Abzug der Kosten recht hoch ausfällt, kann ich nochmal eine Runde Hardware shoppen gehen. Natürlich nicht sinnlos. Mein Plan wäre dabei auf Ausfallsicherheit zu gehen. Ich hatte da an eine zweite SSD im RAID Verbund gedacht oder einen Pi4, der einfach passiv mitläuft und im Notfall zügig aktiviert werden kann. Wir reden hier immerhin von 6K $ Rewards im Jahr pro Validator. Bei dem Reward würde ich schon ein angemessenes Setup auffahren. Einerseits um sicher zu stellen, dass ich den Reward auch ein weiteres Jahr kassieren kann aber andererseits auch zur Weiterbildung. Am Ende bekomme ich den Reward als Belohnung dafür, dass ich mich in das Thema eingearbeitet habe. Ich hätte kein Problem damit bis zu 50% vom Reward erneut in Weiterbildung zu versenken.

Jetzt aber zu den Gründen, die mich auch weiterhin davon abhalten einen ETH2 Validator aufzusetzen. Ich hatte darüber nachgedacht und auch schon ein paar Varianten durchgerechnet. Am Ende bin ich zu der Erkenntnis gekommen, dass ich es mir aktuell nicht leisten kann bzw will. Die Haltefrist von 10 Jahren ist mir dann doch etwas zu teuer. Ich muss erstmal ein paar kurzfristige Projekte abschließen und erst danach kann ich das Restgeld auf 10 Jahre anlegen. Sofern überhaupt genug Restgeld übrig bleibt.

Eigentlicher Grund warum ich mich nochmal melde. Ich habe vor ein paar Wochen Grafana aufgesetzt mit diversen Email Alerts. Ich war ein wenig schokiert wie häufig mein Testnet Validator ausgefallen ist. Inzwischen hat sich das gebessert. Ich habe das Gefühl der ganze Spaß läuft inzwischen deutlich stabiler. Unter anderem gibt es jetzt auch zwei Docker Tags für latest und latest-unstable. Damit war es mir möglich von manuellen Updates auf automatisierte Updates (Watchtower) umzustellen und trotz der automatisierten Updates bisher keine nennenswerten Ausfälle. Für mich ist das ein weiterer Meilenstein in der Weiterentwicklung.

Auf meiner Wunschliste steht noch (reinfolge beliebig):
1. ETH2 auszahlen und auf einem Exchange verkaufen.
2. Automatisches Failover. Aktuell wäre ein Failover noch manuelle Handarbeit.

[Muesli2k]

Am 10.10.2021 um 00:28 schrieb skunk:

Platte meinst du hier vermutlich umgangssprachlich und gemeint ist eine SSD.

ja natürlich, alles andere macht keinen Sinn... bei mir sind es auch keine Sata SSDs sondern m.2 nvme Karten.

Am 10.10.2021 um 00:28 schrieb skunk:

Ich war ein wenig schokiert wie häufig mein Testnet Validator ausgefallen ist. Inzwischen hat sich das gebessert. Ich habe das Gefühl der ganze Spaß läuft inzwischen deutlich stabiler.

Ich habe Lighthouse auf Ubuntu laufen, das System ist außer das der SSD-Speicher vollgelaufen ist, seither zu 99,9% online.. Keine Abstürze keine Ausfälle, nichts...

Von daher kann ich sagen, man braucht hier keine HighEnd Hardware, ein einfacher NUC i3/i5 16GB RAM u. 1-2 TB nvme sind ausreichend.

Habe mir mittlerweile auch einen zweiten als Backup angeschafft, den ich gerade am aufsetzen bin. Meine Überlegung die ich gerade verfolge, evtl das Geth vom

Validator 1 auf die Backup Hardware auszulagern, so das der wenigstens auch was zu tun hat. Und diesen gleich von Anfang mit einer größeren SSD ausstatten.

 

[Muesli2k]

bzzgl. der zweiten Kiste, dem Backup Server...

wenn ich diesen, in der Zeit wo er als Redundanz nebenher laufen soll, als Geth Server einrichte so das sich Validator1 seine Daten von dort holt,

genügt es den lokalen Geth vom Vali 1 auf die IP des Backup Servers umzuschreiben ? 

--http Expose an HTTP endpoint (http://localhost:8545) that the Lighthouse beacon chain will connect to.  

..also quasi statt dem localhost dort die IP des Backup Servers auf dem auch Geth läuft einzutragen ???

schonmal wer probiert..?

 @skunk

[skunk]

vor 1 Minute schrieb Muesli2k:

bzzgl. der zweiten Kiste, dem Backup Server...

wenn ich diesen, in der Zeit wo er als Redundanz nebenher laufen soll, als Geth Server einrichte so das sich Validator1 seine Daten von dort holt,

genügt es den lokalen Geth vom Vali 1 auf die IP des Backup Servers umzuschreiben ? 

--http Expose an HTTP endpoint (http://localhost:8545) that the Lighthouse beacon chain will connect to.  

..also quasi statt dem localhost dort die IP des Backup Servers auf dem auch Geth läuft einzutragen ???

schonmal wer probiert..?

 @skunk

Ja das sollte reichen. Du kannst mehrere Geth Nodes und auch mehrere Beacon Nodes angeben. Ist eine nicht erreichbar wird dein Validator automatisch auf den zweiten Server ausweichen. Leider ist es im Moment nicht möglich auch mehr als einen Validator mit irgend einer Art Failover laufen zu lassen. Zumindest habe ich bisher keine einfache Möglichkeit gefunden.

[Muesli2k]

vor 2 Minuten schrieb skunk:

Ja das sollte reichen. Du kannst mehrere Geth Nodes und auch mehrere Beacon Nodes angeben. Ist eine nicht erreichbar wird dein Validator automatisch auf den zweiten Server ausweichen. Leider ist es im Moment nicht möglich auch mehr als einen Validator mit irgend einer Art Failover laufen zu lassen. Zumindest habe ich bisher keine einfache Möglichkeit gefunden.

Danke,

ja das mit dem Failover ist mir auch bekannt, größtes Problem bei der Sache ist das es nicht erlaubt ist, das 1 Validator auf 2 Systemen zur gleichen Zeit online ist, damit riskiert man ein slashing und/oder erhebliche Strafen.. wenn  dein System 1 down geht und Vali2 übernimmt während Vali 1 kurze Zeit später wieder Online geht, ohne das Vali 2 wieder Off nimmst, dann hast die kacke am Dampfen....

 

 

[Muesli2k]

@skunk hast du vielleicht noch eine Idee, wie man den Traffic verbrauch insgesamt gesenkt bekommt?

Ich habe jetzt mal die MaxPeers von Geth halbiert, weil ich gelesen hatte das könnte was bringen.. mein Validator verbrät mit  >50GB am Tag gefühlt aber doch etwas viel wie ich finde... würde das gerne weiter reduzieren..

 

 

[skunk]

Am 3.11.2021 um 12:52 schrieb Muesli2k:

@skunk hast du vielleicht noch eine Idee, wie man den Traffic verbrauch insgesamt gesenkt bekommt?

Ich habe jetzt mal die MaxPeers von Geth halbiert, weil ich gelesen hatte das könnte was bringen.. mein Validator verbrät mit  >50GB am Tag gefühlt aber doch etwas viel wie ich finde... würde das gerne weiter reduzieren..

Ich hab deine Frage komplett überlesen. Sorry für die verspätete Antwort. Versuch mal noch:
      - --light.ingress=1
      - --light.egress=1
      - --light.maxpeers=0

Warum ich eigentlich den Thread wieder hoch hole ist weil ich erneut nachfragen wollte wie eure Staking Nodes sich so machen. Meine Testnet Node läuft jetzt schon seit Monaten traumhaft gut. Ich hatte eine Zeit lang Probleme mit CPU Usage. Meine Storj Nodes haben zu viel CPU Zeit verbraucht sodass die Staking Testnet Node ihre Blöcke verpasst hat. Daraufhin habe ich das Nice Level für die Geth Node und die Staking Node so gesetzt, dass sie selbst bei 100% CPU Auslastung mit hoher Priorität ihre Operationen zwischen schieben können. Das hat das Problem komplett gelöst. Ich kann praktisch machen was ich will die Staking Node stört es nicht. Die macht einfach weiter als wäre nichts.

Außerdem ist es inzwischen möglich Keys mit einem Hardware Wallet zu generieren. Damit sind die Withdrawl Keys um einiges sicherere und ich muss sie mir nicht extra abspeichern sondern kann sie jederzeit mit meinem Hardware Wallet neu generieren. -> Ich habe meine Testnet Node neu aufgesetzt.

Und last but not least habe ich eine Failover Möglichkeit gefunden. Für den Fall, dass meine SSD das zeitliche segnet, installiere ich auf einer VPS eine neue Node. Das größte Problem ist das Slashing Risiko. Es gibt inzwischen wohl Tools, die die Slashing DB neu generieren können. Macht auch sinn. Die Beacon Node hat ja noch alle Blöcke. Einfach einmal nachschauen was in den letzten Blöcken so drin stand dann hat man die notwendigen Informationen um ohne Slashing Risiko nahtlos weiter zu machen. Dieses manuelle Failover würde im Ernstfall sicherlich einige Tage dauern. Mit etwas Übung würde man es vielleicht auch in wenigen Stunden schaffen.

Bearbeitet 8. Mai 2022 von skunk

[Cookies statt Coins^^]

Am 8.5.2022 um 02:03 schrieb skunk:

Warum ich eigentlich den Thread wieder hoch hole ist weil ich erneut nachfragen wollte wie eure Staking Nodes sich so machen.

Hi,
sehr gut, dass du diesen alten Thread wieder ins Leben rufst. Wollte mich auch schon lange wieder mit einem Update melden, aber bei mir ist privat viel passiert: Während der Corona-Zeit hat sich mein entspanntes Single-Leben zum äußerst stressigen Familien-Leben weiter entwickelt, so dass seitdem nun alles Kopf steht und ich keine Zeit mehr für irgendetwas anderes habe.. 😄

Das Positive vorweg:
Mein Beacon-Node und Validator laufen ohne irgendwelche manuellen Eingriffe relativ stabil. Ein oder zweimal habe ich ein neues Update der Prysm-Software installiert, mehr musste ich bisher nicht machen.
Ein kleines Problemchen gibt es: Hin und wieder verpasse ich eine Attestation (ca. 1x pro Tag) oder ein Proposal (seit einigen Monaten erreiche ich hier nur noch eine Quote von knapp über 50 Prozent erfolgreiche Proposals, das ist sehr schlecht). Ich vermute, dass hier entweder die Hardware des Raspberry Pi nicht ausreicht, um ausreichend schnell zu antworten. Oder es hängt damit zusammen, dass ich aufgrund eines neuen Routers das Port-Forwarding nicht mehr einstellen kann. Hatte aber bisher keine Zeit, dem näher nachzugehen. Ich bin froh, dass es ansonsten ohne Eingriff relativ stabil läuft (d.h. kein Komplettausfall, keine Fehler, kein Neustart usw).

Am 8.5.2022 um 02:03 schrieb skunk:

Und last but not least habe ich eine Failover Möglichkeit gefunden. Für den Fall, dass meine SSD das zeitliche segnet, installiere ich auf einer VPS eine neue Node. Das größte Problem ist das Slashing Risiko. [...]

Einen Failover-Mechanismus habe ich gar nicht. Zur Not muss ich alles neu installieren oder auf dem Testnet-Raspberry-Pi alles neu konfigurieren. Dabei gehen wohl einige Tage verloren, aber mit dem Risiko kann ich leben.
Aber wieso hast du ein Slashing-Risiko, wenn deine Node ausfällt und du daraufhin ein Backup aktivierst? Du aktivierst es ja nur, wenn von deinem alten System kein Lebenszeichen mehr kommt? Somit wirst du ja nie denselben Validator doppelt in Betrieb haben, oder gibt es da eine Konstellation, an die ich hier nicht gedacht habe?

 

Und natürlich bin ich für 2021 in die Steuerfall getappt:
Anders als ursprünglich geplant habe ich nicht kontinuierlich die Menge an ETH, die ich durch das Staking erwirtschaftet habe, von meinen übrigen ETH auf der Seitenlinie verkauft. Das führt aufgrund des stark eingebrochenen Kurses dazu, dass ich nun mehr ETH versteuern muss (ca. 5.000€), als wie diese nun tatsächlich noch wert sind. Außerdem gehe ich noch vom worst-case aus, denn es ist ja noch gar nicht sicher, dass ich jemals diese gestakten ETH auch in Euro umtauschen kann. Denn bis zum mehrmals verschobenen Merge kann noch viel passieren (vgl. Lunar^^) oder evtl aufgrund eines Fehler bei der Einrichtung kann ich mir den falschen Key notiert haben und hätte somit gar keinen Zugriff mehr auf die gestakten ETH. Denn eine Auszahlung konnte ich bislang noch nicht testen. Daher bin ich noch am überlegen, wie ich das in der Steuer angeben soll..

Somit war es keine schlechte Idee von dir, erst mal mit dem Staking im Mainnet zu warten. Allerdings gebe ich zu bedenken, dass du evtl. nicht zu lange warten solltest, denn soweit ich mich erinnern kann, gab es mal eine maximale Grenze an Validatoren. Anfangs hieß es, dass nur maximal 10 Mio ETH fürs Staking gebunden werden können. Mittlerweile sind aber schon über 12 Mio ETH im Staking, somit hat sich diese Grenze entweder verschoben oder wurde ganz aufgelöst: https://beaconcha.in/

[skunk]

vor 19 Minuten schrieb Cookies statt Coins^^:

Ein kleines Problemchen gibt es: Hin und wieder verpasse ich eine Attestation (ca. 1x pro Tag) oder ein Proposal (seit einigen Monaten erreiche ich hier nur noch eine Quote von knapp über 50 Prozent erfolgreiche Proposals, das ist sehr schlecht). Ich vermute, dass hier entweder die Hardware des Raspberry Pi nicht ausreicht, um ausreichend schnell zu antworten. Oder es hängt damit zusammen, dass ich aufgrund eines neuen Routers das Port-Forwarding nicht mehr einstellen kann. Hatte aber bisher keine Zeit, dem näher nachzugehen. Ich bin froh, dass es ansonsten ohne Eingriff relativ stabil läuft (d.h. kein Komplettausfall, keine Fehler, kein Neustart usw).

Am Port Forwarding kann es eigentlich nicht liegen. Auch ohne Port Forwarding läuft mein Validator traumhaft gut. Einige Monate hatte ich aber schlechtere Quoten immer dann wenn meine CPU mit anderen Prozessen beschäftig war. Ich habe daraufhin dem Validator das höchst mögliche Nice Level zugewiesen. Direkt ein Level darunter dann die Beacon Node. 10 weitere Level tiefer habe ich die Geth Node positioniert.

Versuch das bei dir auch mal. Wenn deine Beacon Node und deine Geth Node gleichzeitig einen Block bekommen, würde das Nice Level dafür sorgen, dass die Beacon Node und der Validator Vorrang bekommen. Die Geth Node muss dann kurz warten. Das sollte bei dir ebenfalls funktionieren.

vor 29 Minuten schrieb Cookies statt Coins^^:

Aber wieso hast du ein Slashing-Risiko, wenn deine Node ausfällt und du daraufhin ein Backup aktivierst? Du aktivierst es ja nur, wenn von deinem alten System kein Lebenszeichen mehr kommt? Somit wirst du ja nie denselben Validator doppelt in Betrieb haben, oder gibt es da eine Konstellation, an die ich hier nicht gedacht habe?

Das mit dem Slashing ist schon ein wenig komplexer. Würdest du 2 Validatoren parallel laufen lassen, wäre ein Slashing praktisch garantiert und nur eine Frage der Zeit. Wenn du einen Validator runterfährst und ein paar Minuten später den anderen Validator hochfährst, laufen die Validatoren nicht mehr zeitgleich können aber dennoch einen Fehler machen. Der alte Validator pflegt eine Datenbank. Bevor der Validator bei einem Block attestiert konsultiert er seine lokale Datenbank um zu prüfen ob das zulässig ist. Dem neuen Validator fehlt diese Datenbank und so kann es zum Fehler kommen. Die angesprochene Failover Variante würde diese lokale Datenbank neu generieren um dann ohne Risiko den neuen Validator in Betrieb nehmen zu können.

 

[Muesli2k]

Ich kann auch nur positives berichten... Ich habe mich damals für etwas leistungsfähigere Hardware entschieden, und statt dem PI setze ich auf einen INTEL Nuc, i5, 16GB mit 1TB M2 und habe überhaupt keine Probleme. 100% Uptime, von Stromausfall und Telekom Ausfall wegen eines durch einen Bagger abgerissenen Kabels mal abgesehen, läuft die Kiste unentwegt, ist nicht einmal abgestürzt u. hat sich auch nicht aufgehängt..

Ich setze auf Lighthouse und Geth.

Das einzige was hin und wieder vorkommt, ich muss weil die SSD vollquillt "prunen" um die DB von Geth etwas in Zaum zu halten.... hier ist die M2 mit 1TB etwas knapp bemessen.. Als Backup habe ich mir mittlerweile die identische Hardware nur mit einer 2TB SSD noch einmal zugelegt, so das falls mir was an der HW am Nuc verreckt, ich bequem auf die Backup Hardware ausweichen kann... (max 2-3 Stunden downtime, wäre verschmerzbar)..

Eigtl. wollte ich schon vor Wochen mal testen, ob ich vielleicht nur Geth auf der Backup HW laufen lasse, und dort hin verlinke, aber ich war zeitlich mit den Kindern zu beschäftigt u. hatte schlichtweg noch keine Lust das auszuprobieren... so könnte ich die zweite Maschine mit der grösseren M2 paralell laufen lassen und müsste nicht ständig "prunen"...

Bearbeitet 17. Mai 2022 von Muesli2k

[satoshi21]

vor 18 Stunden schrieb Cookies statt Coins^^:

Hi,
sehr gut, dass du diesen alten Thread wieder ins Leben rufst. Wollte mich auch schon lange wieder mit einem Update melden, aber bei mir ist privat viel passiert: Während der Corona-Zeit hat sich mein entspanntes Single-Leben zum äußerst stressigen Familien-Leben weiter entwickelt, so dass seitdem nun alles Kopf steht und ich keine Zeit mehr für irgendetwas anderes habe.. 😄

Das Positive vorweg:
Mein Beacon-Node und Validator laufen ohne irgendwelche manuellen Eingriffe relativ stabil. Ein oder zweimal habe ich ein neues Update der Prysm-Software installiert, mehr musste ich bisher nicht machen.
Ein kleines Problemchen gibt es: Hin und wieder verpasse ich eine Attestation (ca. 1x pro Tag) oder ein Proposal (seit einigen Monaten erreiche ich hier nur noch eine Quote von knapp über 50 Prozent erfolgreiche Proposals, das ist sehr schlecht). Ich vermute, dass hier entweder die Hardware des Raspberry Pi nicht ausreicht, um ausreichend schnell zu antworten. Oder es hängt damit zusammen, dass ich aufgrund eines neuen Routers das Port-Forwarding nicht mehr einstellen kann. Hatte aber bisher keine Zeit, dem näher nachzugehen. Ich bin froh, dass es ansonsten ohne Eingriff relativ stabil läuft (d.h. kein Komplettausfall, keine Fehler, kein Neustart usw).

Einen Failover-Mechanismus habe ich gar nicht. Zur Not muss ich alles neu installieren oder auf dem Testnet-Raspberry-Pi alles neu konfigurieren. Dabei gehen wohl einige Tage verloren, aber mit dem Risiko kann ich leben.
Aber wieso hast du ein Slashing-Risiko, wenn deine Node ausfällt und du daraufhin ein Backup aktivierst? Du aktivierst es ja nur, wenn von deinem alten System kein Lebenszeichen mehr kommt? Somit wirst du ja nie denselben Validator doppelt in Betrieb haben, oder gibt es da eine Konstellation, an die ich hier nicht gedacht habe?

 

Und natürlich bin ich für 2021 in die Steuerfall getappt:
Anders als ursprünglich geplant habe ich nicht kontinuierlich die Menge an ETH, die ich durch das Staking erwirtschaftet habe, von meinen übrigen ETH auf der Seitenlinie verkauft. Das führt aufgrund des stark eingebrochenen Kurses dazu, dass ich nun mehr ETH versteuern muss (ca. 5.000€), als wie diese nun tatsächlich noch wert sind. Außerdem gehe ich noch vom worst-case aus, denn es ist ja noch gar nicht sicher, dass ich jemals diese gestakten ETH auch in Euro umtauschen kann. Denn bis zum mehrmals verschobenen Merge kann noch viel passieren (vgl. Lunar^^) oder evtl aufgrund eines Fehler bei der Einrichtung kann ich mir den falschen Key notiert haben und hätte somit gar keinen Zugriff mehr auf die gestakten ETH. Denn eine Auszahlung konnte ich bislang noch nicht testen. Daher bin ich noch am überlegen, wie ich das in der Steuer angeben soll..

Somit war es keine schlechte Idee von dir, erst mal mit dem Staking im Mainnet zu warten. Allerdings gebe ich zu bedenken, dass du evtl. nicht zu lange warten solltest, denn soweit ich mich erinnern kann, gab es mal eine maximale Grenze an Validatoren. Anfangs hieß es, dass nur maximal 10 Mio ETH fürs Staking gebunden werden können. Mittlerweile sind aber schon über 12 Mio ETH im Staking, somit hat sich diese Grenze entweder verschoben oder wurde ganz aufgelöst: https://beaconcha.in/

Ich stecke in einer ähnlichen Situation. Habe auch seit Genesis prysm auf einem Raspi 4 laufen. Auf einem zweiten Raspi 4 läuft inzwischen Geth. 1-2x am Tag wird eine Attestation versäumt. Ansonsten habe ich auch schon insgesamt zwei Proposals verpasst. 

Mich treibt aktuell insbesondere das aktuelle Krypto BMF Schreiben um. Ich habe im Steuerthread dazu gerade mal meine Überlegungen dargestellt. Was sagst du dazu?

Bearbeitet 18. Mai 2022 von satoshi21

[skunk]

Der Merge steht bevor. Ich habe mich selbst damit bisher noch 0 beschäftig. Ich habe mir vorgenommen das folgende Video bei Gelegenheit anzusehen um zu erfahren was ich auf meiner Testnet Node machen muss: 

 

[Muesli2k]

vor 17 Stunden schrieb skunk:

Der Merge steht bevor. Ich habe mich selbst damit bisher noch 0 beschäftig. Ich habe mir vorgenommen das folgende Video bei Gelegenheit anzusehen um zu erfahren was ich auf meiner Testnet Node machen muss: 

 

Ich verstehe ehrlich gesagt nur ,Bahnhof‘ hab’s jetzt auch nur mal kurz überflogen, aber dachte bisher es reicht wenn man wie bei mir Geth u. Lighthouse aktuell hält… aber dem scheint wohl nicht der Fall… 

Vielleicht kannst du mal wenn du soweit bist zusammenfassen was du alles umgestellt/konfiguriert hast?

viele Grüße 

 

Bearbeitet 6. August 2022 von Muesli2k

[skunk]

vor 2 Stunden schrieb Muesli2k:

Ich verstehe ehrlich gesagt nur ,Bahnhof‘ hab’s jetzt auch nur mal kurz überflogen, aber dachte bisher es reicht wenn man wie bei mir Geth u. Lighthouse aktuell hält… aber dem scheint wohl nicht der Fall… 

Ich habe es bisher auch nur überflogen. Hier ist was ich bisher weiß:

1. Die ETH1 Node ist in kürze nicht mehr optional sondern zwingend notwendig. Bisher war es kein Problem wenn die ETH1 Node mal ein paar Stunden offline war zwecks Pruning oder Resync. Nach dem Merge geht das nicht mehr weil ohne ETH1 Node ist der Validator direkt offline.
2. Daraus resultierend ist fast schon zwingend eine 2 TB SSD oder größer notwendig. Bisher funktionierte auch eine 1 TB Node und alle paar Monate eine Runde Pruning. Das Geth Team arbeitet an einem Online Pruning ohne Downtime wird dafür aber noch schätzungsweise mindestens ein halber Jahr brauchen. Bedeutet vor dem Merge ein letztes mal Prunen und dann durchhalten. Mit einer 2 TB SSD hat man wohl 2 Jahre Zeit bis das fehlende Pruning zum Problem werden würde.
3. Geth Node ist ungünstig. Aktuell nutzen 80% der Nodes Geth. Im ungünstigsten Fall (schlimmster anzunehmender Bug) verbrennen diese 80% der Nodes all ihr Kapital und steigen dann mit 16 ETH aus. Sie können nichts dagegen machen. Den anderen 20% kann das nicht passieren. Der gleiche Bug würde bei ihnen nur billige Offline Penalty bedeuten. -> Besser auf einen der anderen ETH1 Nodes umstellen. (Ich habe mir noch nicht angeschaut welche Alternativen es gibt und was deren Vor und Nachteile sind.)
4. Zusätzliche Einnahmen durch die ETH1 Priority Fee. Wenn ein Validator einen Block baut bekommt er auch alle darin enthaltenen Priority Fees. Interessant ist dabei, dass die ETH1 Fees anders als der ETH2 Block Reward sofort bewegt und damit auch verkauft werden können. Bei den ETH2 Block Rewards müssen wir noch auf die Implementierung des Withdrawal warten. Bei den ETH1 Priority Fees nicht.
5. Damit das funktioniert ist mindestens ein neuer Parameter notwendig. Irgend einer der 3 Prozesse braucht eine zusätzliche Wallet Adresse an die die ETH1 Priority Fee gesendet wird.
6. Die Beacon Node hat wohl inzwischen auch ein Snapshot Sync bekommen. Dieses Feature wurde schon vor dem Merge eingebaut bedarf aber ebenfalls ein paar zusätzlicher Parameter. Die Idee ist, dass die Beacon Node einfach bei einer andere Node wie zum Beispiel Infura nach dem letzten Snapshot fragt und dann die Blockchain in umgekehrter Reinfolge runterlädt dabei aber bereits ab der ersten Sekunden Einsatzbereit für den Validator ist. Das ganze soll sogar sicherer sein als ohne Snapshot Sync weil es vor einem Angriff schützt. Den Angriff habe ich bei meinem Kollegen sogar einmal live mitverfolgen können. Seine Full Archive Node wurde vom rest des Netzwerks isoliert und ihm wurde eine falsche Blockchain untergejubelt. Diese falsche Blockchain ist zwar eigentlich kürzer als die Main Chain aber sie ist lang genug sodass die Node nicht mehr weit genug zurück springt um auf die eigentliche Main Chain abbiegen zu können. Mit einem Snapshot Sync soll sowas wohl nicht passieren.

Das war erstmal alles was ich auf die Schnelle mitgenommen habe. Es gibt noch einen zweiten Mitschnitt von dem Live Stream gestern: 

 

[skunk]

Die ganzen Parameter Änderungen sind anscheinend hier beschrieben: https://github.com/remyroy/ethstaker/blob/main/prepare-for-the-merge.md#using-the-new-configuration-options-for-your-ethereum-clients

Sieht so aus als müssten wir einfach nur der Anleitung folgen.

Edit: Hier auch noch ein nützlicher Link den ich gerade gefunden habe: https://www.coincashew.com/coins/overview-eth/ethereum-merge-upgrade-checklist-for-home-stakers-and-validators

@Cookies statt Coins^^

Bearbeitet 6. August 2022 von skunk

[Cricktor]

Klingt ja noch etwas nach unfertiger Baustelle, wenn ich das lese, was skunk geschrieben hat. Wenn dann noch ein paar schlimme Finger mitmischen, um unliebsame Validator-Konkurrenz ausbluten zu lassen, die bei diesem augenscheinlich etwas komplexeren Software-Gebilde jeden Fehler ausquetschen könnten, um ihre Vorteile daraus zu ziehen, dann weiß ich nicht so recht, was ich davon halten soll.

Ist jetzt vielleicht etwas übertrieben, wirkt aber ein wenig fragil in meiner Wahrnehmung. Nicht jeder Mitspieler führt Gutes im Schilde. Mal abwarten, wie robust sich das mit dem Mainnet und "Merge" gestaltet.

Ich sehe das ja etwas aus den Augen eines Zuschauers, der allerdings nicht mit allzu vielen Details vertraut ist.

[skunk]

vor 17 Minuten schrieb Cricktor:

Wenn dann noch ein paar schlimme Finger mitmischen, um unliebsame Validator-Konkurrenz ausbluten zu lassen, die bei diesem augenscheinlich etwas komplexeren Software-Gebilde jeden Fehler ausquetschen könnten, um ihre Vorteile daraus zu ziehen, dann weiß ich nicht so recht, was ich davon halten soll.

Deswegen ja auch der Aufruf nicht Geth zu nutzen. Sobald Geth auf unter 66% fällt, ist dieses Risiko komplett vom Tisch. Fairerweise muss man auch sagen, dass Geth selbst wirklich hohe Qualitätsstandards hat. Ich hatte eigentlich noch nie Probleme mit Geth.

 

[Muesli2k]

vor 13 Stunden schrieb skunk:

Ich habe es bisher auch nur überflogen. Hier ist was ich bisher weiß:

1. Die ETH1 Node ist in kürze nicht mehr optional sondern zwingend notwendig. Bisher war es kein Problem wenn die ETH1 Node mal ein paar Stunden offline war zwecks Pruning oder Resync. Nach dem Merge geht das nicht mehr weil ohne ETH1 Node ist der Validator direkt offline.
2. Daraus resultierend ist fast schon zwingend eine 2 TB SSD oder größer notwendig. Bisher funktionierte auch eine 1 TB Node und alle paar Monate eine Runde Pruning. Das Geth Team arbeitet an einem Online Pruning ohne Downtime wird dafür aber noch schätzungsweise mindestens ein halber Jahr brauchen. Bedeutet vor dem Merge ein letztes mal Prunen und dann durchhalten. Mit einer 2 TB SSD hat man wohl 2 Jahre Zeit bis das fehlende Pruning zum Problem werden würde.

 

Ich frag mich wie ich das lösen soll, ich habe Geth auf meinem NUC mit 1TB m2 SSD laufen, also so wie es eigtl sein soll Geth lokal. Aber wie du unter Punkt 2 schreibst, ich musst ständig prunen um halbwegs Speicher frei zu bekommen...

Das ganze System irgendwie auf eine größere 2 oder 4TB clonen ? oder ein zweites System mit nur Geth installieren, ob das noch geht ??? die Möglichkeit hätte ich, da ich schon vor längerer zeit mal die selbe HW als Backup gekauft habe...

[skunk]

vor einer Stunde schrieb Muesli2k:

Das ganze System irgendwie auf eine größere 2 oder 4TB clonen ? oder ein zweites System mit nur Geth installieren, ob das noch geht ??? die Möglichkeit hätte ich, da ich schon vor längerer zeit mal die selbe HW als Backup gekauft habe...

Ich würde eher eine 2TB SSD verbauen als ein zweites System aufzusetzen. Bei zwei Systemen hat man auch doppeltes Ausfallrisiko.

Um die Daten zu kopieren würde ich mit mehreren rclone Durchläufen arbeiten. Die ersten zwei während die Node noch läuft und für den letzten Durchlauf muss dann für ein paar Minuten alles ausgeschaltet werden. Zur Sicherheit vielleicht noch einen zusätzlichen Lauf am Ende der dann eigentlich 0 Dateiänderungen feststellen sollte.

Hier mal ein Beispiel Befehl für eine andere Anwendung:
runuser --login storagenode --command "nice -n 19 rclone sync /mnt/$quelle/storagenode$i /mnt/$ziel/storagenode$i --create-empty-src-dirs -P --transfers 4 --checkers 4"

Den Befehl lasse ich unter dem user storagenode laufen damit beim Kopieren gleich die Dateirechte richtig gesetzt werden. Nicelevel 19 für niedrige Priorität. Der Validator soll ja weiterhin seine CPU Zeit zugesichert bekommen. Dann rclone sync um Quell und Zielverzeichnis abzugleichen. Leere Ordner sollen ebenfalls angelegt werden.

[Cricktor]

Die Shellvariablen $quelle, $ziel, $i werden wodurch definiert?

[skunk]

vor 1 Stunde schrieb Cricktor:

Die Shellvariablen $quelle, $ziel, $i werden wodurch definiert?

Durch meine Bash Schleife.

[skunk]

@Muesli2kBezüglich der altnativen zu Geth habe ich folgendes in Erfahrung gebracht:
 

Zitat

Nethermind - can online prune, muss aber “genau so” laufen. Braucht ordentlich resources während online prune
Besu - 8 GiB/woche non-state Wachstum. Kann keinen prune
Erigon - 1 GiB/Woche Wachstum aber braucht ordentlich disk am Anfang. Auch Alpha, zwei resyncs schon geplant für 2.2 und 2.3

Langfristig würde ich Erigon bevorzugen aber solange das noch im Apha Status ist versuche ich mein Glück mit Nethermind.

Bearbeitet 7. August 2022 von skunk

[Muesli2k]

vor 17 Stunden schrieb skunk:

Ich würde eher eine 2TB SSD verbauen als ein zweites System aufzusetzen. Bei zwei Systemen hat man auch doppeltes Ausfallrisiko.

Um die Daten zu kopieren würde ich mit mehreren rclone Durchläufen arbeiten. Die ersten zwei während die Node noch läuft und für den letzten Durchlauf muss dann für ein paar Minuten alles ausgeschaltet werden. Zur Sicherheit vielleicht noch einen zusätzlichen Lauf am Ende der dann eigentlich 0 Dateiänderungen feststellen sollte.

Hier mal ein Beispiel Befehl für eine andere Anwendung:
runuser --login storagenode --command "nice -n 19 rclone sync /mnt/$quelle/storagenode$i /mnt/$ziel/storagenode$i --create-empty-src-dirs -P --transfers 4 --checkers 4"

Den Befehl lasse ich unter dem user storagenode laufen damit beim Kopieren gleich die Dateirechte richtig gesetzt werden. Nicelevel 19 für niedrige Priorität. Der Validator soll ja weiterhin seine CPU Zeit zugesichert bekommen. Dann rclone sync um Quell und Zielverzeichnis abzugleichen. Leere Ordner sollen ebenfalls angelegt werden.

Wie stelle ich das an, der Nuc hat nur einen Anschluss für eine m2 gesteckte SSD. Ich könnte versuchen in einem externen Gehäuse über USB-C die 2TB anzuschließen und Clone dann auf diese? oder ich lasse Geth auf der ext. USB m2 SSD laufen? Hast du Erfahrungen was die Datentransferraten angeht? Müsste auch gehen oder?

[skunk]

vor 30 Minuten schrieb Muesli2k:

Wie stelle ich das an, der Nuc hat nur einen Anschluss für eine m2 gesteckte SSD. Ich könnte versuchen in einem externen Gehäuse über USB-C die 2TB anzuschließen und Clone dann auf diese? oder ich lasse Geth auf der ext. USB m2 SSD laufen? Hast du Erfahrungen was die Datentransferraten angeht? Müsste auch gehen oder?

Du könntest auch ein Image der SSD auf eine externe HDD schreiben und dann die SSD austauschen und das Image zurück kopieren. Ich würde aber mit einigen Stunden wenn nicht sogar Tagen Downtime rechnen.

Was ist mit deinem Backup System? Kannst du dort die neue SSD anschließen und dann über das Netzwerk die Daten kopieren. Dabei musst du nur ganz besonders vorsichtig sein, dass du nicht versehentlich zwei Nodes gleichzeitig laufen lässt. Am besten vorher die systemd services deaktivieren aber laufen lassen. Sollte dein Backup System versehentlich hochfahren würde es die Node nicht automatisch mit starten. Du müsstest für die Zeit des Umzuges alles manuell hoch und runterfahren. Dabei dann gleich doppelt überprüfen ob auf der jeweils anderen Maschine wirklich alles gestoppt wurde.

Bearbeitet 7. August 2022 von skunk

[Muesli2k]

vor 2 Stunden schrieb skunk:

Du könntest auch ein Image der SSD auf eine externe HDD schreiben und dann die SSD austauschen und das Image zurück kopieren. Ich würde aber mit einigen Stunden wenn nicht sogar Tagen Downtime rechnen.

Was ist mit deinem Backup System? Kannst du dort die neue SSD anschließen und dann über das Netzwerk die Daten kopieren. Dabei musst du nur ganz besonders vorsichtig sein, dass du nicht versehentlich zwei Nodes gleichzeitig laufen lässt. Am besten vorher die systemd services deaktivieren aber laufen lassen. Sollte dein Backup System versehentlich hochfahren würde es die Node nicht automatisch mit starten. Du müsstest für die Zeit des Umzuges alles manuell hoch und runterfahren. Dabei dann gleich doppelt überprüfen ob auf der jeweils anderen Maschine wirklich alles gestoppt wurde.

System 1; live Validator Intel Nuc i5, 1TB m2 16GB RAM, Geth u. Lighthouse

System 2; Ersatz Hardware, Intel Nuc i3 / 16GB hier ist nur Ubuntu & Geth installiert aber mit 2 TB m2..

Da beide Systeme nur einen m2 Steckplatz haben, überlege ich was am schnellsten gehen würde, mit am wenigsten downtime.. Ggf die m2 aus System 1 ausbauen, in einen Windows PC einbauen, ein Image machen und auf die m2 aus System 2 überschreiben...

Kopieren über Netzwerk oder sonstiges ist mir zu kompliziert, dazu kenne ich mich auch bei Linux zu wenig aus, und wie du schreibst, wenn man beide gleichzeitig Online fährt, ist das Riskiko da, das ggf. der validator doppelt online ist... das will ich nicht riskieren...

Eine weitere Möglichkeit wäre den Validator auf System 1 runter zu fahren, und auf System 2 nochmal neu aufzusetzen... ist zwar der schwächere NUC (i3) aber mit der größeren m2 (2TB)....

Bin da gerade echt etwas aufgeschmissen, da meine Linux Kenntnisse nicht allzu gut sind, wie ich das am besten anstelle... tendiere aber dazu die m2 irgendwie unter Windows zu Clonen oder ein Image zu erstellen.... und auf die größere zu übertragen...

 

 

 

 

 

Bearbeitet 7. August 2022 von Muesli2k