Jump to content
Cookies statt Coins^^

Ethereum-2.0-Staking auf Raspberry Pi

Empfohlene Beiträge

Wird Raspberry Pi mit Steckernetzteil geliefert? Im Conrad Schweiz ausverkauft, unglaublich.. muss warten..

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 4 Minuten schrieb dandy:

Wird Raspberry Pi mit Steckernetzteil geliefert? Im Conrad Schweiz ausverkauft, unglaublich.. muss warten..

Nein.

Kannste für'n Zehner bei Amazon kaufen (USB-C + 3 Ampere)

  • Thanks 1
  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Nach dem Neustart des Testnetz läuft mein Setup bisher super. Ich würde aktuell 0,0144 ETH pro Node pro Tag bekommen. Mit zunehmender Anzahl an Nodes dürfte der Reward langsam sinken.

@Cookies statt Coins^^ wie läuft es bei dir? Hast du bereits einen dieser kurzen Aussetzer beobachten können?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Am 11.6.2020 um 16:34 schrieb skunk:

Ich habe inzwischen geth, beacon-node und validator auf Konfig Dateien umgestellt um der Problematik mit dem Updates aus dem Weg zu gehen. Zusätzlich habe ich alle 3 Prozesse in einen eigenes Docker Netzwerk geschoben womit auch die Problematik mit der unsicheren gRPC Verbindung erschlagen wäre. Ich kann sehr genau definieren welche Ports von Außen in dieses Netzwerk geleitet werden. Als kleinen Bonus funktioniert jetzt auch Docker Stats. Das zeigt mir an wie viel Ressourcen überhaupt verbrauchen. Mit den Daten werde ich da vielleicht noch das eine oder andere optimieren.

Sehr interessant 👍.
Wie hast du das mit der Konfigurationsdatei gemacht? Ich rufe die Skripte mittlerweile auch zusätzlich mit ein paar Optionen auf (--log-file und --datadir), da wäre es in einer Konfig-Datei übersichtlicher.
Wie viel Bandbreite Upload und Download zeigt dir Docker Stats an?

 

Am 11.6.2020 um 16:34 schrieb skunk:

Das Setup um einen Slasher zu ergänzen steht noch auf meiner ToDo List.

Einen Slasher lasse ich nun  auch mitlaufen. Ist ja nur ein zusätzlicher Aufruf habe ich festgestellt. Bisher hat mein Slasher aber noch keine Unregelmäßigkeiten festgestellt. Wird vermutlich eher selten auftreten.

 

Am 11.6.2020 um 16:34 schrieb skunk:

Richtig es gibt von Seiten der Entwickler keine Pläne aber von Seiten der Community kann einfach jemand einen Pull Request eröffnen und dann wäre das ARM64 Image plötzlich doch vorhanden. Die notwendige Code Änderung sollte in etwa so aussehen: https://github.com/storj/storj/pull/2814/files#diff-b67911656ef5d18c4ae36cb6741b7965R175-R177

Wenn jemand einen Pull Request eröffnet, wird der sicherlich nicht abgelehnt werden. Ich selber bin mit meinem Docker Wissen noch nicht an diesem Punkt angelangt und ich habe auch keine Hardware um das Docker Image am Ende zu testen. Ich bräuchte also zumindest einen Freiwilligen dafür^^

Also für den Test würde ich meinen Raspberry Pi gerne zur Verfügung stellen, aber das mit dem Pull Request ist mir zu viel. So viel Zeit habe ich leider nicht, um mich damit intensiv zu beschäftigen und um das voranzutreiben ohne aktuell selbst viel Ahnung davon zu haben.

 

Am 12.6.2020 um 03:45 schrieb skunk:

Dieses mal habe ich die Deposit Transaktionen selber erstellt um auch die letzten Abhängigkeiten los zu werden. Es ist erstaunlich einfach. [...]

Gut zu wissen 👍. Das muss ich nun auch mal probieren. Aber erst muss ich den Geth Node auf dem Raspberry Pi zum laufen bringen..

 

Am 15.6.2020 um 11:49 schrieb skunk:

Nach dem Neustart des Testnetz läuft mein Setup bisher super. Ich würde aktuell 0,0144 ETH pro Node pro Tag bekommen. Mit zunehmender Anzahl an Nodes dürfte der Reward langsam sinken.

@Cookies statt Coins^^ wie läuft es bei dir? Hast du bereits einen dieser kurzen Aussetzer beobachten können?

Mein Setup läuft nach dem Neustart des Testnets nun auch sehr stabil. Seit dem Start vor zweieinhalb Tagen gab es keinen Absturz. Beacon-Node und Validator (und nun auch Slasher) laufen fehlerfrei und stabil auf dem Raspberry Pi. Vermutlich liegt das auch an der neuesten Version (Version: v1.0.0-alpha.11). Die CPU-Auslastung liegt nun bei ca 10%.
Und auch ohne Docker wird bei jedem Start der Shell-Skripte automatisch geprüft,  ob es eine neuere Version gibt und diese wird dann automatisch heruntergeladen und gestartet.

Das hier ist nun der neue Link zu meinem neuen Validator: https://beaconcha.in/validator/8015
Es geht hier nun kontinuierlich aufwärts. Ähnlich wie deine Validatoren hat mein Validator in den letzten 24 Stunden 0,0146 ETH eingebracht. (In diesen Zeitraum fielen aber auch zwei proposed-Blöcke, die etwas mehr einbringen.) Somit habe ich nun 3x soviel eingenommen als zuletzt am Ende des vorherigen Testzeitraums. Das bestätigt auch eindrucksvoll meine Vermutung, dass zu Beginn des Stakings die Erträge noch am höchsten sind, da es weniger Validatoren gibt auf welche die Erträge verteilt werden. Aktuell sind es ca. 17.400 aktive Validatoren im Testnet. (Mal abwarten, wie viele es am Ende sind und wie dann die Erträge ausfallen.)

Es gibt aber auch vereinzelte Aussetzer (Attestations=Missed), bei denen der Validator vermutlich nicht rechtzeitig den Block bestätigt hatte oder irgendwas anderes schief lief.
Ich habe soeben eine Auswertung meiner Validator-Logdatei gemacht: Aktuell hat mein Validator 60x ein Strafe bekommen aufgrund eines ungültigen Votes. Dem gegenüber stehen 496 Gutschriften aufgrund eines korrekten Votes. Macht eine Fehlerquote von 9%. Hast du eine ähnlich hohe Fehlerquote?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Eigentlich wollte ich nun meinen ersten Beitrag hier in diesem Thread editieren, damit alle wichtigen Infos zentral an einer Stelle zu finden sind. Aber ich habe festgestellt, dass ich diesen Beitrag nun nachträglich nicht mehr bearbeiten kann. Das ist schade, denn jetzt muss man sich die wichtigsten Infos hier aus dem Verlauf sammeln und einige Infos aus dem ersten Beitrag sind schon veraltet. Aber zum Schluss, wenn alles stabil läuft, kann ich evtl. nochmal eine Zusammenfassung posten.

Hier ein Zusammenfassung der Änderungen im Vergleich zum ersten Beitrag vom 6. Juni:

- Neues Testnet:
Das öffentliche ETH2-Testnet wurde neugestartet. Passend dazu gabs ein Softwareupdate (Version: v1.0.0-alpha.11). Diese neue Version bekommt man automatisch, wenn man sich an die ursprüngliche Anleitung haltet: https://prylabs.net/participate
 

- Slasher in Betrieb genommen:
Ich betreibe nun auch zusätzlich zum Validator einen Slasher. (Zur Info: Ein Slasher soll erkennen, wenn z.B. ein anderer Validator unerlaubte Aktionen begeht, vgl: https://docs.prylabs.network/docs/prysm-usage/slasher/; Wenn ein Slasher eine solche unerlaubte Aktion meldet, dann gibt es ein zusätzliches Einkommen; Bisher hat mein Slasher  im Testnet aber noch keine Auffälligkeit gefunden)
 

- Externe Festplatte an Raspberry  Pi angeschlossen:
Ursprünglich wollte ich eine 1TB SSD-Festplatte an den Raspberry Pi anschließen. Aber ich habe noch zuhause ein 500 GB HDD Festplatte gefunden und diese vorübergehend angeschlossen.
Das Anschließend der Festplatte an den Raspberry PI ist in folgender Anleitung ab dem Kapitel "Mount the SSD" ausführlich beschrieben: https://kauri.io/running-an-ethereum-full-node-on-a-raspberrypi-4-m/9695fcca217f46feb355245275835fc0/a (Auf diese Anleitung komme ich später aufgrund eines anderen wichtigen Punkts nochmal zurück 😉 ).
--> D.h. die Festplatte wird gemountet, partitionieren und so eingerichtet, dass sie bei jedem Start automatisch wieder mit eingebunden wird.

Seit Montag habe ich nun die Festplatte angeschlossen und seitdem hat sich auch der tägliche Stromverbrauch des Raspberry Pi von 0,07 kWh auf 0,13 kWh fast verdoppelt. Somit komme ich aktuell auf folgende jährliche Stromkosten: 0,13 kWh * 365 * 0,30 €/kWh = 14€. Das finde ich auch noch günstig.

Diese Festplatte ist aber nur eine Übergangslösung, bis ich mir eine SSD-Festplatte zulege.
 

- ETH-Blockchain-Daten auf Externe Festplatte ausgelagert:
Die Daten der ETH-2.0-Beacon-Blockchain verschiebe ich nun von der Micro-SD-Karte des Raspberry Pi auf die Externe Festplatte..
Danach müssen ab sofort die Skripte (Beacon-Node, Validator, Slasher) zusätzlich immer mit folgendem Übergabeparameter aufgerufen werden, um den Standard-Pfad für die Blockchain-Daten auf die Externe Festplatte umzubiegen:
    --datadir /mnt/ssd/ethereum/.eth2 

Zusätzlich für den Validator braucht man noch folgenden Parameter:
    --keystore-path /mnt/ssd/ethereum/.eth2validators

Falls man die bisherigen Ordner nicht verschiebt, beginnt man praktisch erneut von Null an und der ETH-2.0-Beacon-Node müsste sich zunächst neu synchronisieren und für den Validator müsste dann vermutlich auch nochmal ein neues Schlüsselpaar und dazugehöriges Deposit hinterlegt werden. (Nur eine Vermutung, habe es nicht ausprobiert)
 

- 8 GB Swap-Bereich  auf Externer Festplatte eingerichtet:
Mein Raspberry Pi hat nur 4 GB Arbeitsspeicher, was gerade so die Mindest-Hardware-Anforderungen für den Betrieb eines ETH-2.0-Beacon-Nodes und Validators abdeckt. Da scheinbar standardmäßig in der Ubuntu-Distribution für den Raspberry Pi gar kein Swap-Bereich (für zusätzlichen ausgelagerten Arbeitsspeicher auf der Festplatte) vorgesehen ist, musste ich zunächst nach folgender Anleitung eine 8 GB Swap-Datei auf der Externen Festplatte einrichten: https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-18-04
--> D.h. ein 8 GB große Swap-Datei wird auf der Festplatte erzeugt, mit den Befehlen "mkswap" und "swapon" wird dem System nahe gelegt diesen Swap-Bereich zukünftig zu nutzen, durch einen Eintrag in "fstab" wird sichergestellt dass diese Konfiguration nach dem Neustart erhalten bleibt, und zum Schluss werden noch ein paar Parameter verändert damit das System nicht zu oft auf diesen (deutlich langsameren) Speicher zurückgreift.

Zu Beginn wurde der neue Swap-Bereich nur sehr zögerlich angenommen. Aber seit ich nun seit heute auch mittels Geth die ETH-1.0-Blockchain im Testnetz synchronisiere (siehe Aufzählungspunkt ganz unten) war es schon zwingend notwendig, den Speicher im Vorfeld entsprechend zu erweitern, wie folgender Auszug der Systemauslastung zeigt (1,5 GB des Swap-Speichers sind nun bereits  belegt):
top.png.60fbcf35fc05d51edcd601c212bb5665.png
 

- Skripte laufen nun als Prozesse (und nicht mehr in Screen-Session mit Cronjob-Überwachung)
In meinem ersten Beitrag vom 6. Juni hatte ich geschrieben, dass ich die Skripte in einer Screen-Session laufen lasse und ein Cronjob hatte alle 5 Minuten geprüft, ob noch alles läuft. Durch den Hinweis von @skunk habe ich die Skripte so umgestellt, dass diese nun als Prozesse laufen. Dies hat den Vorteil, dass diese beim Systemstart und bei einem Absturz sofort automatisch (nach)gestartet werden.

So sieht nun beispielhaft der Prozess zum Starten der ETH-2.0-Beacon-Node aus:

[Unit]
Description=Prysm Testnet BeaconChain Service 
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=1
User=ubuntu
ExecStart=/home/ubuntu/prysm/prysm.sh beacon-chain  --log-file /home/ubuntu/prysm/LogBeaconChain.txt  --datadir /mnt/ssd/ethereum/.eth2

[Install]
WantedBy=multi-user.target

Diese Datei muss dann unter "/etc/systemd/system/" abgelegt werden und mittels "systemctl"-Befehl einmalig initialisiert werden. Details zur Erstellung und Konfiguration eines solchen Services gibt es hier: https://medium.com/@benmorel/creating-a-linux-service-with-systemd-611b5c8b91d6

Insgesamt habe ich so nun fünf Prozesse am erstellt:
- Prozess für ETH-2.0-BeaconChain-Node
- Prozess für Validator
- Prozess für Slasher
- Prozess zum Logging der Systemauslastung
- Prozess zum Logging der CPU-Temperatur (da ich immer noch keine Kühlung habe^^)
 

- Installation von Geth zum Betrieb eines ETH-1.0-Nodes
Dieser hier beschriebene Schritt ist zwar nicht zwingend nötig für das Staken, es fördert aber die Dezentralisierung von Ethereum und evtl. verspreche ich mir dadurch auch einige Verbesserungen (dass z.B. die Validatoren eine höherer Trefferquote beim Attestieren der Blöcke bekommen; aber ohne Garantie, dass das tatsächlich Auswirkungen haben wird).
Ziel ist es hier, mittels Geht einen ETH-1.0-Node zu betreiben, mit dem sich dann mein ETH-2.0-Beacon-Node verbinden soll.

Hintergrund:
In Phase 0 werden die ETH-1.0- und und ETH-2.0-Blockchain parallel betrieben. Man könnte sich für das Staken daher entweder mit einem öffentlichen ETH-1.0-Node verbinden, oder man betreibt seinen eigenen.
Die Kommunikation läuft scheinbar über diesen Weg: Validator <-> ETH-2.0-BeaconNode <-> ETH-1.0-Node
z.B. über den ETH-1.0-Node müssen die Einzahlungen der 32 ETH zum Aktivieren der Validatoren eingehen, da man ja nicht Ethereum direkt von ETH-1.0 nach ETH-2.0 senden kann. (vgl: https://docs.prylabs.network/docs/prysm-usage/setup-eth1).
Aber wie das alles genau im Detail zusammen hängt und funktioniert, habe ich auch noch nicht ganz verstanden.🙈

Nun zur Installation von Geth:
Zu Beginn hatte ich Probleme, die korrekte Installationsdateien für den Raspberry Pi zu finden. Aber auf folgender Seite ist es sehr ausführlich beschrieben, wie man Geth auf einem Raspberry Pi installieren und den ETH-1.0-Node starten kann: https://kauri.io/running-an-ethereum-full-node-on-a-raspberrypi-4-m/9695fcca217f46feb355245275835fc0/a
Zu Beginn wird in dieser Anleitung sehr ausführlich auf den Raspberry Pi eingegangen. Erst im letzten Drittel (ab Kapitel "Install and configure Geth") kommt der hier relevante Teil.
-> d.h. die Installationsdateien von Github herunterladen, mittels "make" die Sourcen von "Geth" auf dem Raspberry Pi selbst kompelieren, und zum Schluss "Geth" starten.
Diese verlinkte Anleitung bezieht sich auf das Mainnet. Da ich Geth jedoch nur im Testnet (ETH-1.0-Testnet = "Goerli") betreiben möchte (und da ich auch die Ausgabe in eine Logdatei umleiten möchte), starte ich Geth auf folgende Weise:
    geth --goerli --datadir="/mnt/ssd/ethereum/.eth1Goerli" 2>> /home/ubuntu/prysm/LogEth1Goerli.txt

Aktuell, während ich diesen Beitrag hier schreibe, läuft gerade die Synchronisation, d.h. Geth lädt gerade die ETH-1.0-Testnet-Blockchain herunter. Das wird noch einige Stunden so gehen, weil ständig die Verbindung zu den Peers abbricht. Aber spätestens morgen Abend sollte es fertig sein, dann kann ich mit dem entsprechenden Parameter meinen ETH-2.0-Beacon-Node mit diesem ETH-1.0-Node verbinden. Vermutlich muss ich dazu den ETH-2.0-Beacon-Node nur zusätzlich mit dem Parameter "--http-web3provider=$HOME/Goerli/geth.ipc" starten, und dann sollte es eigentlich schon funktionieren. Steht zumindest hier in der Anleitung: https://docs.prylabs.network/docs/prysm-usage/setup-eth1

Sollte dies im Testnet dann stabil laufen, dann würde ich auch mal versuchsweise auf meinem Raspberry Pi die echte Ethereum-Blockchain aus dem Mainnet herunterladen. Nur um zu sehen, ob mein Raspberry Pi mit diesen zusätzliche Volumen klar kommt. Aber höchstwahrscheinlich wird das ohne SSD-Festplatte nicht zuverlässig laufen, könnte ich mir vorstellen.. Es bleibt also spannend... 😄

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Erst einmal ein herzliches Danke für diese tolle Anleitung.

Ich habe es ebenfalls versucht mit einem Raspberry Pi 4 ETH zu staken, laufe aber leider in folgenden Fehler, wenn ich "./prysm.sh beacon-chain" ausführe:

[2020-06-29 15:14:01] INFO initial-sync: Waiting for enough suitable peers before syncing required=3 suitable=0

Hat jemand von euch eine Idee, woran das liegen kann?

Vielen Dank schon mal!

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Geschrieben (bearbeitet)
vor 15 Stunden schrieb mlange:

2020-06-29 15:14:01] INFO initial-sync: Waiting for enough suitable peers before syncing required=3 suitable=0

Hi, vor einigen Tagen trat der Fehler bei mir auch durchgängig auf, da musste ich dann das Beacon-Skript neustarten und danach hat es seltsamerweise ohne weitere Änderung plötzlich wieder geklappt. Aber einen Neustart hast du vermutlich schon versucht?
Oder evtl. sind von der Firewall/ Router noch wichtige Ports gesperrt, welche das Skript für die Verbindung mit den Peers benötigt? (Nur relevant, wenn es zuvor noch nie geklappt hat, denn eigentlich musste ich hier nichts besonderes konfigurieren)

Update:
Seite heute morgen um kurz nach 6 Uhr tritt dieser Fehler bei mir auch wieder auf. Aktuell hilft auch kein Neustart. Vermutlich liegt dies am Testnet, welches schon seit einige Tagen nach meinem Gefühl sehr instabil läuft...

bearbeitet von Cookies statt Coins^^

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo,

ich habe schon mehrere Neustarts versucht, ohne Erfolg. Leider weiß ich auch nicht ob ich die Portöffnung korrekt gemacht habe. 13000 und 12000, wie genau das aber aussehen soll habe ich noch nicht ganz herausgefunden. Weiß jemand vielleicht ob es überhaupt mit dsl lite möglich ist ( IPv6 ), oder kann mir jemand ein Screenshot von den Portöffnungen posten? Ich habe eine Connection Box von Unitymedia und finde es da sehr kompliziert aufgebaut. 
 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Geschrieben (bearbeitet)
vor 5 Stunden schrieb mlange:

Leider weiß ich auch nicht ob ich die Portöffnung korrekt gemacht habe. 13000 und 12000, wie genau das aber aussehen soll habe ich noch nicht ganz herausgefunden. Weiß jemand vielleicht ob es überhaupt mit dsl lite möglich ist ( IPv6 ), oder kann mir jemand ein Screenshot von den Portöffnungen posten? Ich habe eine Connection Box von Unitymedia und finde es da sehr kompliziert aufgebaut. 

Ich habe nochmal die Anleitung durchgelesen und hier steht, man soll im Router die Port-Weiterleitung für TCP#13.000 und für UDP#12.000 aktivieren: https://docs.prylabs.network/docs/prysm-usage/p2p-host-ip/#port-forwarding

Das hatte ich bis heute auch falsch konfiguriert, bin erst durch deinen Beitrag darauf gekommen das erneut zu prüfen. So sollte es nun richtig sein:PortForwarding.thumb.png.416ef5e600ba8677b1ff4772a3ae07ff.png

Zur Erklärung:

  • Der erste Eintrag in der Liste (TCP/UDP#30303) ist für dich nicht relevant. Das habe eingetragen weil es in der Anleitung für den Betrieb eines ETH-1.0-Nodes empfohlen wurde, für die Beacon-Chain hier ist das aber erst mal nicht nötig.
  • Der zweite und dritte Eintrag sollte hier bei deinem Router ähnlich aussehen. Nur bei "Computer" musst du eben die private IP-Adresse deines Raspberry Pi eintragen. Und du hattest etwas von "IPv6" geschrieben. Tatsächlich bezieht sich das alles auf IPv4, evtl hast du da einen Fehler. Für IPv6 habe ich nichts konfiguriert.

 

Wenn ich nun einen dieser drei Einträge editiere, dann sieht das so aus (am Beispiel des zweiten Eintrags, d.h. für TCP#13.000):

PortForwarding_TCP13000.thumb.png.e943e710b27187c68fca33b5a59942ba.png

 

Bei der von dir verwendeten Unitymedia  Connection Box sieht es vermutlich so aus: https://wiki.instar.de/Fernzugriff/Port_Weiterleitung/Unitymedia_Connectbox/
Die Konfiguration sollte hier genauso erfolgen.

----------------------------------

Und zusätzlich habe ich auf derselben Seite (https://docs.prylabs.network/docs/prysm-usage/p2p-host-ip/#setting-the---p2p-host-ip-flag) nun gelesen, dass man die Beacon-Chain mit folgendem Parameter aufrufen soll:
prysm.sh beacon-chain --p2p-host-ip=$(curl -s v4.ident.me)

Das hatte ich bisher auch nicht in meinem Skript und habe es vorhin noch hinzugefügt, in der Hoffnung, dass es mit diesen Änderungen etwas stabiler läuft.

 

 

bearbeitet von Cookies statt Coins^^

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.


×
×
  • Neu erstellen...

Wichtige Information

Wir speichern Cookies auf Ihrem Gerät, um diese Seite besser zu machen. Sie können Ihre Cookie-Einstellungen anpassen, ansonsten gehen wir davon aus, dass Sie damit einverstanden sind. In unseren Datenschutzerklärungen finden sie weitere Informationen.