Zum Inhalt springen

Ethereum-2.0-Staking auf Raspberry Pi


Cookies statt Coins^^

Empfohlene Beiträge

Hallo zusammen,

in diesem Thread beschreibe ich meine Erfahrungen, die ich beim Staking des aktuell noch in der Testphase befindliche ETH 2.0 auf einem Raspberry Pi gemacht habe. Denn vielleicht lässt sich dadurch der eine oder andere Mitleser davon inspirieren, dies ebenfalls zu versuchen.

Zwei wichtige Infos vorweg:
1.) Ich selbst stehe in keinem Verhältnis zur Ethereum-Foundation, d.h. ich beschreibe hier nur meine Erfahrungen, die ich selbst als Privatperson gemacht habe, indem ich mich über das Internet über das Projekt informiert hatte und mich am Testnetz beteiligt hatte. Daher sind auch alle Angaben ohne Gewähr, d.h. es könnte sein, dass sich noch der eine oder andere Fehler in diesen Text eingeschlichen hat.
2.) Aktuell gibt es ETH-2.0 nur im Testnet! Sobald es irgendwann mal produktiv geht (ursprünglich war Januar 2020 geplant, aktuell gibt es aber scheinbar noch keinen neuen Termin), werde ich diesen Text hier noch mal überarbeiten und aktualisieren.

 

I. Allgemeinen Funktionsweise des ETH-2.0-Staking:
Als Staking bezeichnet man den Prozess, mittels hinterlegtem Guthaben für die Korrektheit der Blöcke in einer Proof-of-Stake-(PoS)-Blockchain zu stimmen.
Grob beschrieben wird das Staking von Ethereum so funktionieren:
Man betreibt bei sich lokal zum Einen einen ETH-2.0-Node (="Beacon Node": https://docs.prylabs.network/docs/how-prysm-works/beacon-node) auf dem die Ethereum-2.0-Blockchain läuft.
Zusätzlich benötigt man einen Validator, welcher sich über den Beacon Node mit der Blockchain verbindet (https://docs.prylabs.network/docs/how-prysm-works/prysm-validator-client/). Beide Programme könnnen auf demselben PC laufen.
Des Weiteren werden 32 ETH benötigt, mit welchen das Staking durchgeführt werden soll. D.h. über einen SmartContract zahlt man diese 32 ETH an eine fest vorgegebene Deposit-Adresse ein, um dadurch seinen Validator zu aktivieren. Auf der Testumgebung sind das natürlich nur Test-Coins, die man zu Beginn geschenkt bekommt. Der somit nun aktivierte Validator hat zwei Hauptaufgaben:
- Entweder wird der Validator selbst einen neuen Block für die Blockchain erzeugen (= propose/ proposed blocks).
- Oder der Validator bestätigt einen Block, der von einem anderen Validator neu erzeugt wurde (= vote/ attestations).
Zu beiden Aktionen wird der eigene Validator jeweils abwechselnd zufällig ausgewählt. Mein Test-Validator durfte ca. alle 5-10 Minuten Blöcke bestätgen, aber nur ca alle 2-3 Tage neue Blöcke erzeugen, wobei das Erzeugen neuer Blöcke deutlich mehr Ethereum einbringt als das Bestätigen.

Wenn nun der Validator ausgewählt wurde, um Blöcke zu bestätigen, aber er kommt dieser Aufgabe nicht nach, da z.B. das Programm oder der PC abgestürzt ist, dann gibt es jedes Mal einen entsprechenden Abzug an Ethereum. Wenn der Validator also zu lange offline ist, verliert man schnell sein zuvor angespartes bzw eingezahltes Ethereum. Aktuell ist es wohl so, dass man grob im selben Zeitraum so viel Ethereumn verliert, die man ansonsten dazu gewinnen würde.
z.B. einmal lief mein Beacon-Node für 14 Stunden nicht, so dass sich der Validator nicht mit der Blockchain verbinden konnte, und in dieser Zeit verlor ich insgesamt 0,0061 ETH. In den darauffolgenden 14 Stunden konnte ich 0,0051 ETH zurück gewinnen. Vor einem Jahr hatte ich schon mal bei den ersten Anfängen der Validator mitgemacht, und damals habe ich in der Offline-Zeit ca. 3x so viel verloren als ich in der Online-Zeit Gewinn gemacht hatte. Dieses Verhältnis hat sich also glücklicherweise deutlich verbessert.
Mittlerweile habe ich mir auch ein Skript geschrieben, welches automatisch im 5-Minuten-Intervall überprüft, ob Validator und Node noch laufen, um diese jeweils bei Bedarf automatisch nachzustarten.

 

II. Einrichtung auf einem Raspberry-Pi:
Nachdem nun die Grundlagen des Stakings bekannt sind, folgen hier noch ein paar technische Details, wie ich diese alles im Ethereum-Testnetz ("Goerli test network") auf einem Raspberry-Pi-Minicomputer eingerichtet habe:
Mein Ziel ist es, mit möglichst wenig Ressourcenverbrauch (vor allem wenig Stromverbrauch) einen eigenen ETH-Validator bei mir zuhause zu betreiben. Die Entscheidung fiel daher auf einen Raspberry Pi 4 mit 4 GB RAM, welcher noch vor einem Monat das stärkste Modell war. Seit Kurzem gib es nun den Rapberry Pi 4 mit 8 GB RAM. Für alle, die neu einsteigen, sollen sich am besten das neue Modell mit den 8 GB kaufen, denn ich befürchte dass die 4GB nicht auf Dauer ausreichen. Die 4 GB RAM sind die Mindestvoraussetzungen für das Staking und 8 GB RAM werden empfohlen (https://docs.prylabs.network/docs/install/arm/).


1. Vorbereitung des Raspberry Pi:
Die ETH-2.0-Software gibt es aktuell nur in der 64-Bit-Variante, und so wie es scheint wird es in absehbarer Zeit auch keine 32-Bit-Variante geben.
Daher muss der Raspberry Pi auch mit einem 64-Bit-Betriebssystem installiert werden. Somit kann hier nicht auf das Standard-Raspbian Betriebssystem zurückgegriffen werden, da Raspbian aktuell (Stand Juni 2020) nur in der 32-Bit Variante verfügbar ist (was sich aber hoffentlich auch bald ändern wird). Ich habe mir daher die aktuellste 64-Bit-Variante von Ubuntu heruntergeladen, welche es hier in einer eigenen Distribution für den Raspberry Pi zum Download gibt: https://ubuntu.com/download/raspberry-pi
Zusätzlich habe ich mir noch eine Desktop-Oberfläche installiert, was aber nicht zwingend notwendig ist. Ich hatte mich spontan für Gnome entschieden, KDE soll aber etwas weniger Ressourcen verbrauchen, wie ich nun gelesen habe. Evtl deinstalliere ich die Desktop-Oberfläche aber auch wieder komplett, wenn es dadurch zu instabil läuft und lasse alles dann nur in der Shell laufen.
Außerdem habe ich dem Raspberry Pi über die Router-Konfiguration eine feste IP-Adresse zugewiesen und VNC für den Remotezugriff eingerichtet.
Und spätestens, wenn ETH-2.0 produktiv geht, sollte man sich eine SSD-Festplatte zulegen (vermutlich mind. 500GB) und diese an den Raspberry anschließen. Hingegen für die Testnetz-Konfiguration reicht noch z.B. eine 32GB Micro-SD-Karte, da die Testblockchain deutlich kleiner ist als die der Produktion.


2. Installation des Validators und des ETH-Nodes:
Wenn der Raspberry Pi grundlegend eingerichtet ist, dann kann nun die benötigte Ethereum-Software installiert werden. Eine allgemeine Anleitung gibt es hier: https://prylabs.net/participate
Im Schritt#1 wird dabei beschrieben, wie die Software (Eth-Beacon-Node + Validator) installiert wird. Eine ausführlichere Anleitung speziell für den ARM-Prozessor des Raspberry Pi gibt es hier: https://docs.prylabs.network/docs/install/arm/
In den weiteren Schritten#2 bis #6 wird beschrieben, wie der Validator und die ETH-Beacon-Node ("BeaconChain") zu aktivieren sind, wie man sich die 32 Test-ETH holen kann, und wie diese auf den Deposit-Contract einbezahlt werden können um den Validator zu aktivieren.
So sieht nun das fertige System aus:
Desktop-Oberfläche des Raspberry Pi mit aktiven Beacon-Node und Validator
Links oben läuft der ETH-Beacon-Node und rechts der Validator.


3. Optimierungen in eigener Sache:
Seit fast drei Wochen läuft nun dieses Setup auf meinem Raspberry Pi. Da es jedoch vereinzelte Probleme gab und in dem Zeitraum mehrmals das Skript zum ETH-Beacon-Node abgestürzt war, habe ich folgendes gemacht:
Ein Cronjob führt nun alle 5 Minuten ein Skript aus, welches prüft, ob in der Prozessliste der Validator und der ETH-Beacon-Nodes noch laufen und startet diese bei Bedarf.
Zusätzlich laufen beide Skripte in einer eigenen Screen-Session. Dies hat u.a. den Vorteil, dass das Skript unabhängig von der aktuell geöffneten Shell läuft, so dass man die jeweilige Shell schließen und wieder neu öffnen kann und das Skript läuft weiter.
So sieht mein Restart-Skript aus, welches alle 5 Minuten vom Cronjob ausgeführt wird:

#!/bin/sh
# Inspiration für Skript: https://www.linuxforen.de/forums/showthread.php?223970-Prozess-%FCberwachen-bei-Bedarf-neu-starten
# Erstellt am: 31.05.2020

logfile=/home/ubuntu/prysm/Restartlog.txt

# Stellt sicher, dass die Beacon-Chain durchgängig läuft:
if [ $(ps -A | grep -c beacon-chain) = 0 ];
then
    echo "$(date) Beacon-Chain wiederbeleben" >> $logfile
    screen -S BeaconChain -X stuff "cd /home/ubuntu/prysm\n"
    screen -S BeaconChain -X stuff "./prysm.sh beacon-chain\n"
fi

# Stellt sicher, dass der Validator durchgängig läuft:
if [ $(ps -A | grep -c validator) = 0 ];
then
    echo "$(date) Validator wiederbeleben" >> $logfile
    screen -S Validator -X stuff "cd /home/ubuntu/prysm\n"
    screen -S Validator -X stuff "./prysm.sh validator --password XXXzensiertXXX\n"
fi

Ich konnte bisher nicht herausfinden, warum das Skript vereinzelt abstürzt. Ich vermute, dass das Programm mit der Zeit immer mehr Speicher belegt und deswegen abstürzt. Aber das ist aktuell nur eine Vermutung. Daher protokolliere ich nun alle 30 Sekunden die relevanten Systemdaten und schreibe diese in eine Logdatei.


3. Monitoring
Hier nun eine Zusammenfassung meiner Beobachtungen:

  - Monitorung des Validators:
Mittlerweile gibt es eine Weboberfläche mit den wichtigsten Infos zum eigenen Validator.
Das hier ist z.B. die Übersichtsseite meines Validators:
https://beaconcha.in/validator/b7b209025b2c2b6efc237186f31f58e91eb0cf55cee1d68e64d4766a5d6a986490d551701ee0ff05b81f480a21cc2d85

Screenshot zu obigen Link:
Übersichtsdaten meines Validators

Hier sieht man auf einen Blick das durchs Staking bereits erwirtschaftete Etherum. Wenn das System kontinuierlich ohne Störung durchläuft, dann erhält man hier aktuell im Testnet ca. 0,0050 ETH pro Tag (Tendenz täglich leicht sinkend). Hochgerechnet aufs Jahr wären das dann ohne Ausfallzeiten ca. 1,8 ETH. Allerdings vermute ich stark, dass man diesen Wert hier aus dem Testnet nicht 1zu1 auf die spätere Produktionsumgebung überragen kann, denn u.U. soll sich auch die Gesamtzahl der am Staking beteiligen Validatoren auf das Einkommen jedes einzelnen auswirken. D.h. je mehr Validatoren es gibt, die sich am Staking beteiligen, desto weniger bleibt für jeden einzelnen übrig. Somit kann man meiner Meinung nach zum heutigen Stand noch keine konkrete Aussagen zum zukünftigen Staking-Ertrag eines einzelnen Validators machen.

Weiter unten bei der "Balance History" sieht man den Verlauf des erwirtschafteten Ethereums. Ganz unten bei der "Proposal History"sind die Blöcke zu sehen, die der Validator erfolgreich generiert hat.
Vor einigen Tagen gab es ein Update dieser Monitoring-Website, daher geht die Historie aktuell nur bis zum 30. Mai zurück.
Ich hatte aber vorsorglich schon mal einen Screenshot der früheren Historie gemacht, welche einen etwas markanteren Verlauf zeigt (Die farbigen Kommentare wurden nachträglich von mir eingefügt):
Zeitlicher Verlauf meines Validators
Hier sieht man schön, dass die selbst erzeugten Blöcke (Proposals) eine deutliche Steigerung bringen im Vergleich zu den Votes.
Und man sieht auch, wie das Einkommen wieder gleichmäßig nach unten sinkt, wenn das System für einige Stunden nicht läuft, denn dieser Screenshot stammt noch aus der Zeit, bevor ich das Neustartskript erstellt hatte.

  - Netzwerk-Traffic:
Mittels Nload kontrolliere ich den Netzwerkverkehr. Da auf dem Raspberry abgesehen von der SSH-Verbindung keine weiteren Prozesse laufen, welche viel Netzwerk-Traffic verursachen würden, gehe ich dabvon aus, dass die gemessenen Werte hauptsächliche auf den Validator und auf den ETH-Beacon-Node zurückzuführen sind.
Hierzu ein Screenshot aus Nload:
Durchsschnitts Traffic
Im Durchschnitt verbrauchen der Upload- und Download-Stream ca. 250 kBit/s mit einem maximalen Peak von 4 mBit/s. Das ist unerwartet wenig.

Wenn der Validator gerade dabei ist, für einen neuen Block zu stimmen (AttestationsStatus=Scheduled), dann steigt der Netzwerk-Traffic an, d.h ca 500 kBit/s bis 2,5 mBit/s im Upload.
Aber man muss auch berücksichtigen, dass es sich hier aktuell nur um ein Test-Netz handelt, so dass auf der Blockchain deutlich weniger Daten enthalten sind als in der produktiven Blockchain. Soweit ich gelesen habe, sind im aktuellen Teststadium nur die Verkehrs-Daten für das Staken von Ethereum enthalten. Somit wird hier das Datenvolumen bei den Echtdaten mit echtem Traffic im Mainnet vermutlich deutlich höher sein. Genaue Zahlen hierzu habe ich allerdings nicht..
Aktuell kann ich problemlos HD-Filme über Amazon und Netflix streamen, während parallel über denselben Anschluss (Download: 50 MBit/s & Upload: 10 MBit/s) das Staking im Testnetz läuft. Ich gehe stark davon aus, dass das dann auch im ETH-2.0-Mainnet so bleiben wird, ohne dass ich ein größeres Internetpaket abschließen muss.
Falls ich hierzu was Neues herausfinde, werde ich diesen Absatz entsprechend aktualisieren.

  - Systemauslastung:
Die CPU-Auslastung liegt im normalen Betrieb bei 20% bis 30% Auslastung, wie die Protokollierung alle 30 Sekunden mittels vmstat zeigt:
vmstat 30 --timestamp >> statistic.txt
Wie eingangs berichtet stürzt der ETH-Beacon-Node nach einigen Tagen Laufzeit ab, das macht sich auch dadurch bemerkbar, dass 30 Minuten vor dem Absturz die CPU-Auslastung kontinuierlich bis fast 100% ansteigt.
Der Arbeitsspeicher bei 4 GB Raspberry Pi ist im Normalbetrieb zu dreiviertel belegt. Ebenfalls kurz vor dem Absturz sinkt der freie Arbeitsspeicher dramatisch auf wenige MB ab.
Anbei ein Auszug aus dem erstellten vmstat-Log vor und nach dem Absturz des ETH-Beacon-Node-Prozesses:
Logdatei zur Systemauslastung während eines Absturzes des Beacon-Nodes

Zwischen 15:38:10 Uhr und 15:38:40 Uhr ist der Dienst abgestürzt, was sich durch verschieden Werte bereits bis zu 40 Minuten im Vorfeld angedeutet hatte: Free-Memory und Idle-CPU sind immer weiter gesunken, stattdessen sind die wartenden Prozesse (2.Spalte) immer weiter gestiegen.
Um 15:40:01 wurde der Dienst neugestartet (ersichtlich aus der hier nicht enthaltenem Restart-Log) und hat dann nach kurzer Initialisierung wieder mit der Synchronisierung der Blockchain begonnen, da zwischen 15:41:10 Uhr und 15:44:10 Uhr wieder stetig der Arbeitsspeicher belegt wurde.
Die letzten drei Zeilen hier im Screenshot entsprechen eher den typischen Werten im Normalbetrieb, wenn kein Fehler Auftritt und die Synchronisation der Blockchain wieder läuft.

  - Stromverbrauch:
Zu guter Letzt messe ich auch den Stromverbrauch, den der Raspberry Pi während des Stakings benötigt.
Dazu verwende ich eine Smart-Steckdose, die mir am Handy den aktuellen Verbrauch anzeigt.
Im Leerlauf verbraucht mein Raspberry ca 3 Watt.
Während des Stakings schwankt der Verbrauch zwischen 3 und 5 Watt. Summiert ergibt das laut meiner App einen durchschnittlichen Tagesverbrauch von 0,07 bis 0,08 kWh.
Stromverbrauch

Bei einem Strompreis von 30 Cent pro kWh ergibt das aufs Jahr hochgerechnet 7,50€. Das ist deutlich günstiger als erwartet.
Jedoch muss man hier Berücksichtigen, dass noch keine Externe USB-Festplatte angeschlossen ist, was den Stromverbrauch weiter erhöhen wird.
Auch betreibe ich den Raspberry Pi aktuell noch ohne Kühlung, was sich ebenfalls auf den Stromverbrauch auswirken könnte (evtl weniger Stromverbrauch durch niedrigere Temperatur bzw höherer Stromverbrauch bei aktiver Kühlung).


4. Ausblick in die Zukunft
Soviel zum aktuelle Ist-Stand. Es gibt noch einige offene Themen, die angegangen werden müssen:
- Raspberry Pi durch neuen 8 GB Raspberry Pi ersetzen
- Anschluss und Umstieg auf SSD-Festplatte
- Kühlung einbauen (passiv oder auch aktiv)
- Abstürze des ETH-Beacon-Nodes minimieren (löst sich entweder durch 8-GB-Raspberry-Pi oder durch ETH-Software-Update)


Fazit:
Ich hoffe, ich konnte euch hiermit einen Einblick in mein Raspberry-ETH-Staking-Projekt geben.
Es läuft noch nicht alles 100%ig rund, aber im Großen und Ganzen sieht es meiner Meinung nach sehr vielversprechend aus. Daher würde ich wohl auch nach aktuellem Stand den Wechsel vom Testnet auf das Mainnet mitmachen (Termin steht aber ja noch nicht fest). Und kann das auch allen nur empfehlen, dies ebenfalls mal auszuprobieren, wenn ihr selbst mit minimalen Ressourceneinsatz euren eigenen Etherem-Staking-Node betreiben wollt  😉

 

Bearbeitet von Cookies statt Coins^^
  • Love it 1
  • Thanks 20
  • Like 8
Link zu diesem Kommentar
Auf anderen Seiten teilen

Danke, sehr aufschlussreich !

Es gäbe für mich aber ein KO-Kriterium:

"Du hinterlegst 32 ETH in dem dafür vorgesehenen Smart Contract auf Ethereum 1.0. Damit werden die ETH dann zu Validator Guthaben auf der Ethereum 2.0 Beacon Chain. Dieser Vorgang ist unumkehrbar, das bedeutet, dass du in Phase 0 die ETH nicht mehr transferieren kannst. Dies ist erst wieder ab Phase 2 (2022) möglich. Außerdem musst du als Validator Blöcke validieren und organisieren, da ansonsten Strafen anstehen könnten. Ohne ins Detail zu gehen, eignet sich diese Variante eher für fortgeschrittene Nutzer."

https://bitcoin-2go.de/ethereum-2-0-staking/

 

Wie sieht es denn mit dem Beenden des Stakings und Auflösung des Initial-Smart-Contracts aus?

  • Love it 1
  • Thanks 2
Link zu diesem Kommentar
Auf anderen Seiten teilen

Sehr genialer Thread! Danke!

Ich wollte mich auch schonmal intensiver damit befassen - auch mit einem Raspi.

Zur Kühlung hätte ich noch Tipps, falls nötig: Ich habe meinen Raspi4 mit aktiver Kühlung versehen und den Lüfter in Abhängigkeit von der Temperatur laufen. Ansonsten ist der Lüfter nervig laut.

Bei Bedarf such ich raus wie ich das gemacht habe zum Nachbauen.

 

Bearbeitet von Jokin
  • Love it 2
  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 49 Minuten schrieb TomsArt:

Wie sieht es denn mit dem Beenden des Stakings und Auflösung des Initial-Smart-Contracts aus?

Wie man vom Staking wieder aussteigt, das weiß ich nicht genau. Diese Möglichkeit habe ich bisher im Testnet nicht gefunden. In der Doku ist beschrieben, dass man nach mindestens 9 Tagen Staking einen Exit durchführen kann: https://docs.prylabs.network/docs/how-prysm-works/validator-lifecycle/
Wie das genau ablaufen wird, wird sich noch zeigen.

Und da ich Langzeit-Hodler bin, ist es für mich nicht so wichtig, ob ich die Coins erst 2022 oder erst noch später wiederbekommen kann.
Aber ja, da man Strafe zahlen muss, wenn man inaktiv/ offline ist, sollte man sich auch fürs Mainnet überlegen, ein Backup-System aufzubauen um den Validator-Client schnell wieder zum Laufen zu bringen, da man ja sein Coins nicht kurzfristig wieder vom Staken entfernen kann. Weiß nicht, wie lang man inaktiv sein muss und so lange ETH-Abzug bekommt, bevor man dann evtl. automatisch aus dem Staking-Pool geworfen wird.

 

vor 55 Minuten schrieb Jokin:

Zur Kühlung hätte ich noch Tipps, falls nötig: Ich habe meinen Raspi4 mit aktiver Kühlung versehen und den Lüfter in Abhängigkeit von der Temperatur laufen. Ansonsten ist der Lüfter nervig laut.

Ich hatte mir überlegt, so ein komplettes Passives-Kühlung-Gehäuse zu kaufen, z.B. sowas hier: https://www.conrad.de/de/p/joy-it-armor-case-block-sbc-gehaeuse-passend-fuer-raspberry-pi-inkl-passiven-kuehler-2140237.html

Aber ja, wenn du ne gute Idee für die aktive Kühlung hast, dann kannst du die hier ja auch mal rein schreiben 😉

  • Thanks 2
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 2 Stunden schrieb Cookies statt Coins^^:

Mittlerweile habe ich mir auch ein Skript geschrieben, welches automatisch im 5-Minuten-Intervall überprüft, ob Validator und Node noch laufen, um diese jeweils bei Bedarf automatisch nachzustarten.

Uptime robot! Ein Überwachungscript auf dem betroffenen Gerät wird im Zweifel ebenfalls versagen. Die Überwachung muss extern laufen und man braucht dann eigentlich sogar noch eine Überwachung für die Überwachung. Oder man nutzt einen fertigen Dienst wie update robot.

 

vor 2 Stunden schrieb Cookies statt Coins^^:

Ich habe mir daher die aktuellste 64-Bit-Variante von Ubuntu heruntergeladen

Für den Desktop Betrieb ja aber für den Server Betrieb und nicht anderes machst du hier ja, würde ich eher Debian wählen. Ubuntu hat den Vorteil, dass du diverse Pakete in neueren Versionen bekommst. Für den Desktop Betrieb ist das klasse. Man will ja den neuesten Media Player mit all seinen Funktionen. Nachteil ist aber Stabilität. Da punktet dann Debian. Das übernimmt die Pakete erst wenn sie stabil genug sind um im Dauerbetrieb keine Probleme zu machen.

Wenn du dir die Konfiguration ohne UI nicht zutraust dann vielleicht OpenMediaVault. Das ist dann ein Debian was du über den Webbrowser konfigurieren kannst.

vor 2 Stunden schrieb Cookies statt Coins^^:

Ein Cronjob führt nun alle 5 Minuten ein Skript aus, welches prüft, ob in der Prozessliste der Validator und der ETH-Beacon-Nodes noch laufen und startet diese bei Bedarf.

Mach das bitte als Service. Ich habe auch Anfangs mit Watchdog Skripten und Cronjob gearbeitet. Es ist aber sehr einfach die gewünschte Anwendung gleich als Service laufen zu lassen sodass sie im Fehlerfall sofort neu gestartet wird und nicht erst nach 5 Minuten.

Können wir sonst gern zusammen machen.

vor 2 Stunden schrieb Cookies statt Coins^^:

  - Monitorung des Validators:
Mittlerweile gibt es eine Weboberfläche mit den wichtigsten Infos zum eigenen Validator.

Was ist das für eine Seite? Das sieht mir nicht nach einen lokalen Übersicht aus. Senden die Programme ungefragt Daten an einen zentralen Server oder ist das nur eine Aufbereitung der Daten die auf der Blockchain zu finden sind? (Ich bin einfach Vorsichtig was das angeht)

Ich habe mich mit dem Thema selber noch nicht weiter beschäftigt. Was mich noch interessieren würde ist ob man mit 64 ETH doppelt so oft zum Zuge kommt oder ob man zwei Nodes aufsetzen muss um den entsprechenden Reward zu bekommen. Weißt du dazu näheres oder wollen wir das zusammen einfach mal ausprobieren?

Außerdem will ich die beiden Programme gern als Docker Container laufen lassen. Das hat einige Vorteile wie automatische Updates, Ordnung auf dem System, einfache Migration auf ein Backup Maschine falls es mal zu einem Ausfall kommt.

  • Love it 1
  • Thanks 1
  • Like 2
Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich lese gerade Docker ist möglich. Hast du Lust auf eine Bonus Runde mit Docker auf deinem Pi? Optional gleich noch Netdata und Portainer installieren einfach um es mal gesehen zu haben. Die beiden kommen in solchen Umgebungen häufiger zum Einsatz. Wenn es dir nicht gefällt, kannst du die entsprechenden Docker Container einfach wieder löschen.

  • Thanks 1
  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Super Beitrag. Evtl nutze ich meine Krisen bedingte Freizeit um mich damit auseinanderzusetzen 😅

Bearbeitet von Gast
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 19 Minuten schrieb dandy:

Ich empfehle den:

https://www.amazon.de/gp/product/B07VD5L1VY/ref=ppx_od_dt_b_asin_title_s01?ie=UTF8&psc=1

Ist ohne Lüfter, aber da überhitzt nichts, auch nicht bei Last. 

Nur für Raspberry 4

Edit:

Das ist Gehäuse und Kühler in einem. 

Bearbeitet von fjvbit
  • Love it 1
  • Thanks 2
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 44 Minuten schrieb fjvbit:

Ich empfehle den:

https://www.amazon.de/gp/product/B07VD5L1VY/ref=ppx_od_dt_b_asin_title_s01?ie=UTF8&psc=1

Ist ohne Lüfter, aber da überhitzt nichts, auch nicht bei Last. 

Nur für Raspberry 4

Edit:

Das ist Gehäuse und Kühler in einem. 

So einen hat Cookie doch schon oben von Conrad für €15,49 erwähnt. — Auch ohne Ref-link ... ;o))

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 25 Minuten schrieb ..::. o.Z.o.n.e .::..:

So einen hat Cookie doch schon oben von Conrad für €15,49 erwähnt. — Auch ohne Ref-link ... ;o))

Ich habe keine Ref Link gemacht... 

Conrad hat den gleichen? 

Bearbeitet von fjvbit
Link zu diesem Kommentar
Auf anderen Seiten teilen

Am 6.6.2020 um 17:34 schrieb skunk:
Am 6.6.2020 um 15:00 schrieb Cookies statt Coins^^:

Mittlerweile habe ich mir auch ein Skript geschrieben, welches automatisch im 5-Minuten-Intervall überprüft, ob Validator und Node noch laufen, um diese jeweils bei Bedarf automatisch nachzustarten.

Uptime robot! Ein Überwachungscript auf dem betroffenen Gerät wird im Zweifel ebenfalls versagen. Die Überwachung muss extern laufen und man braucht dann eigentlich sogar noch eine Überwachung für die Überwachung. Oder man nutzt einen fertigen Dienst wie update robot.

Zum Thema "Update Robot" finde ich nur "Robot Operating System (ROS)". Aber vermutlich meinst du hier was anderes?
Grundsätzlich wäre es kein Problem, die Überwachung des Dienstes extern zu betreiben, da ich noch zwei andere Raspberry Pi im selben Netzwerk habe, auf denen ich zwei andere Nicht-Crypto-Projekte laufen lassen. Die langweilen sich und hätten noch Kapazität frei 😉

 

Am 6.6.2020 um 17:34 schrieb skunk:
Am 6.6.2020 um 15:00 schrieb Cookies statt Coins^^:

Ich habe mir daher die aktuellste 64-Bit-Variante von Ubuntu heruntergeladen

Für den Desktop Betrieb ja aber für den Server Betrieb und nicht anderes machst du hier ja, würde ich eher Debian wählen. Ubuntu hat den Vorteil, dass du diverse Pakete in neueren Versionen bekommst. Für den Desktop Betrieb ist das klasse. Man will ja den neuesten Media Player mit all seinen Funktionen. Nachteil ist aber Stabilität. Da punktet dann Debian. Das übernimmt die Pakete erst wenn sie stabil genug sind um im Dauerbetrieb keine Probleme zu machen.

Wenn du dir die Konfiguration ohne UI nicht zutraust dann vielleicht OpenMediaVault. Das ist dann ein Debian was du über den Webbrowser konfigurieren kannst.

Ich befürchte, Debian läuft nicht auf einem Raspberry Pi 4. Ich habe es nicht ausprobiert, aber dieser Hinweis hier ist nicht vielversprechend: https://wiki.debian.org/RaspberryPi#Raspberry_Pi_4
Aber Ubuntu hatte ich eigentlich nur als Übergangslösung vorgesehen. (Wobei meistens die Übergangslösungen dann ewig im Einsatz bleiben^^)
Ich würde am liebsten das Raspbian-Betriebssystem installieren, sobald es davon eine 64-Bit-Version gibt. Da es ja nun die 8 GB Raspberry Pi gibt, sollte es nur noch eine Frage der Zeit sein, bis es auch ein passendes offizielles Betriebssystem dazu gibt. Die 32-Bit-Systeme können ja nur maximal 4 GB RAM ansprechen, daher muss mit dem neuen Raspberry Pi früher oder später auch ein neues 64-Bit-Betriebssystem kommen.

Eine GUI brauche ich nicht unbedingt. Ursprünglich wollte ich den Raspberry Pi auch zum Streamen von HD-Videos über den Browser nutzen, aber das Ergebnis war nicht zufriedenstellen, daher habe die GUI drauf gelassen und betreibe nun nur das Ethereum-Staking.

 

Am 6.6.2020 um 17:34 schrieb skunk:
Am 6.6.2020 um 15:00 schrieb Cookies statt Coins^^:

Ein Cronjob führt nun alle 5 Minuten ein Skript aus, welches prüft, ob in der Prozessliste der Validator und der ETH-Beacon-Nodes noch laufen und startet diese bei Bedarf.

Mach das bitte als Service. Ich habe auch Anfangs mit Watchdog Skripten und Cronjob gearbeitet. Es ist aber sehr einfach die gewünschte Anwendung gleich als Service laufen zu lassen sodass sie im Fehlerfall sofort neu gestartet wird und nicht erst nach 5 Minuten.

Können wir sonst gern zusammen machen.

OK, danke für die Infos. Dass  man so einfach einen Service machen kann war mir neu, aber ich bin auch kein Linux-Experte 😄. Aber folgende Seite mit einer Anleitung dazu gefunden: https://medium.com/@benmorel/creating-a-linux-service-with-systemd-611b5c8b91d6
Das werde ich bei Gelegenheit ausprobieren.

 

Am 6.6.2020 um 17:34 schrieb skunk:
Am 6.6.2020 um 15:00 schrieb Cookies statt Coins^^:

Mittlerweile gibt es eine Weboberfläche mit den wichtigsten Infos zum eigenen Validator.

Was ist das für eine Seite? Das sieht mir nicht nach einen lokalen Übersicht aus. Senden die Programme ungefragt Daten an einen zentralen Server oder ist das nur eine Aufbereitung der Daten die auf der Blockchain zu finden sind? (Ich bin einfach Vorsichtig was das angeht)

Auf der Startseite (https://beaconcha.in/) nennt sich dieses Tool "Open Source Ethereum 2.0 Beacon Chain Explorer". Ganz unten in der Fußzeile ist ein Link zu GitHub (https://github.com/gobitfly/eth2-beaconchain-explorer). Also scheinbar werden hier die Daten direkt aus der Blockchain aufbereitet dargestellt. Für weitere Details müsste man sich den Quellcode in GitHub anschauen..

 

Am 6.6.2020 um 17:34 schrieb skunk:

Ich habe mich mit dem Thema selber noch nicht weiter beschäftigt. Was mich noch interessieren würde ist ob man mit 64 ETH doppelt so oft zum Zuge kommt oder ob man zwei Nodes aufsetzen muss um den entsprechenden Reward zu bekommen. Weißt du dazu näheres oder wollen wir das zusammen einfach mal ausprobieren?

Wenn man 64 ETH staken will, dann braucht man zwei Validatoren (die alle mit dem selben Eth-Beacon-Node verbunden sein können). Habe ich irgendwo gelesen, aber finde die Quelle dazu nun nicht mehr.

 

Am 6.6.2020 um 17:40 schrieb skunk:

Ich lese gerade Docker ist möglich. Hast du Lust auf eine Bonus Runde mit Docker auf deinem Pi? Optional gleich noch Netdata und Portainer installieren einfach um es mal gesehen zu haben. Die beiden kommen in solchen Umgebungen häufiger zum Einsatz. Wenn es dir nicht gefällt, kannst du die entsprechenden Docker Container einfach wieder löschen.

Die Installation mit Docker ist für die "normale" Linux-Installation oder auch bei Windows und OS möglich. Aber für den Raspberry Pi braucht man die "ARM"-Installation (https://docs.prylabs.network/docs/install/arm/). Bin kein Hardware-Experte, aber scheinbar musste hier einiges anders gemacht werden, damit es auf einem solchen Prozessor lauffähig ist. Ganz am Anfang wurde dieser Prozessor bzw der Raspberry Pi daher noch gar nicht unterstützt im ETH-Testnet.

 

vor 14 Stunden schrieb Longbrearh:

Super Beitrag. Evtl nutze ich meine Kreisen bedingte Freizeit um mich damit auseinanderzusetzen 😅

Na klar, einfach mal ausprobieren. Je mehr sich daran beteiligen und ihre Erfahrungen hier posten, desto besser 👍. Leider habe ich gerade nicht so viel Freizeit um komme erst immer nachts dazu zu antworten 😄 .

 

Am 6.6.2020 um 20:59 schrieb bjew:
Am 6.6.2020 um 17:03 schrieb Cookies statt Coins^^:

Aber ja, wenn du ne gute Idee für die aktive Kühlung hast, dann kannst du die hier ja auch mal rein schreiben 😉

als Vorabversion wäre         cpulimit -l 85 -- <program> ....

möglich, d.h. i. obigen Beispiel würde ab 85 % CPU-Last der Prozeß heruntergebremst, was sich natürlich auch auf die Temperatur auswirkt.

https://wiki.ubuntuusers.de/cpulimit/

Dei Temperatur ist auch auslesbar, damit lönnte der Lüfter eingeschaltet werden

Hmm, die Idee ist gut. Aber ich denke, dass die Temperatur aktuell nicht das Problem ist. Wenn die CPU zu heiß wird, dann senkt der Raspberry automatisch die CPU-Leistung und er wird eben langsamer. Da möchte ich nicht schon im Vorfeld mein Hauptprogramm drosseln.

Und je nach Betriebssystem und Hardware sind scheinbar andere Befehle nötigt. Bei einem Raspberry Pi mit Ubuntu braucht man diesen Befehl: cat /sys/class/thermal/thermal_zone0/temp
Zur Sicherheit habe ich nun ein Skript erstellt, welches die aktuelle CPU-Temperatur incl Timestamp in eine Logdatei schreibt:
(date "+%Y-%m-%d %H:%M:%S -> " | tr -d '\n' && cat /sys/class/thermal/thermal_zone0/temp) >> /home/ubuntu/prysm/TemperaturLog.txt
Mittels Cronjob wird das Skript nun minütlich ausgeführt und protokolliert somit die aktuelle Temperatur.

Die Temperatur schwankt aktuell zwischen 58°  und 65°. Ich denke, das ist OK ohne Kühlung. Spannend wird es aber, wie hoch dann die Temperatur beim nächsten Absturz steigt, wenn die CPU-Auslastung auf 100% geht.

 

vor 11 Stunden schrieb fjvbit:

Ich empfehle den:

https://www.amazon.de/gp/product/B07VD5L1VY/ref=ppx_od_dt_b_asin_title_s01?ie=UTF8&psc=1

Ist ohne Lüfter, aber da überhitzt nichts, auch nicht bei Last. 

Ja genau, so eine passive Kühlung schwebt mir auch vor. Wenn man den Raspberry Pi nicht übertaktet und nicht ständig bei 100% CPU laufen lässt, sollte das eigentlich ausreichend sein. Müsste man mal ausprobieren..

Bearbeitet von Cookies statt Coins^^
Fehler im Temperaturmessungsskript korrigiert
  • Thanks 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 6 Minuten schrieb Cookies statt Coins^^:

Zum Thema "Update Robot" finde ich nur "Robot Operating System (ROS)". Aber vermutlich meinst du hier was anderes?

https://uptimerobot.com/

vor 10 Minuten schrieb Cookies statt Coins^^:

Die Installation mit Docker ist für die "normale" Linux-Installation oder auch bei Windows und OS möglich. Aber für den Raspberry Pi braucht man die "ARM"-Installation (https://docs.prylabs.network/docs/install/arm/). Bin kein Hardware-Experte, aber scheinbar musste hier einiges anders gemacht werden, damit es auf einem solchen Prozessor lauffähig ist. Ganz am Anfang wurde dieser Prozessor bzw der Raspberry Pi daher noch gar nicht unterstützt im ETH-Testnet.

Docker läuft auch auf einem Pi. Von daher sollte die Docker Installation durchaus funktionieren. Wie gesagt das können wir sonst auch gern zusammen ausprobieren.

vor 6 Minuten schrieb Cookies statt Coins^^:

Wenn man 64 ETH staken will, dann braucht man zwei Validatoren (die alle mit dem selben Eth-Beacon-Node verbunden sein können). Habe ich irgendwo gelesen, aber finde die Quelle dazu nun nicht mehr.

Wenn ich das richtig verstanden habe, dann kann ein Validator mehrere Keys managen. Ich arbeite daran das zu testen. Meine Beacon Node läuft bereits.

  • Love it 1
  • Thanks 2
Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich habe meinen Validator jetzt auch am Laufen. Ich habe mir den Spaß gegönnt und die Einzahlung über mein Trezor Wallet gemacht einfach um zu sehen ob ich damit später irgendwelche Probleme bekommen würde. Das hat ohne Probleme funktioniert.

Ich habe einen zweiten Key angelegt und es sieht so aus als könnte der Validator beide Verwalten. Ich würde gern in den nächsten Tagen deine und meine Rewards vergleichen um zu sehen ob das wie gewünscht funktioniert.

Meine Docker Container sind alle auf automatischen Restart im Fehlerfall eingestellt. Watchtower übernimmt die automatischen Updates. Uptime Robot überwacht das ganze.

Zwei Punkte stören mich noch. Die gRPC Verbindung zwischen Validator und Beacon-Node ist nicht abgesichert. Da muss ich nochmal ein wenig an der Konfig spielen. Außerdem habe ich etwas von einem zentralen ETH Testnet Server gelesen. Da stellt sich mir die Frage ob ich nicht besser eine lokale Parity Node aufsetzten sollte. Was passiert wenn der zentrale Server mal nicht erreichbar ist?

Bearbeitet von skunk
  • Love it 1
  • Thanks 1
  • Like 2
Link zu diesem Kommentar
Auf anderen Seiten teilen

Auf dem Dashboard sieht es mir so aus als würden zwei Validatoren nicht zwangsläufig auch den doppelten Reward bekommen. Das macht auch sinn weil zum Schutz vor einem 51% Angriff unterschieden werden muss auf welchem Blech die beiden laufen. Ich kann mir ja schlecht meinen eigenen Block bestätigen. Solche Kombinationen müssen ausgeschlossen sein. Bei 2 Validatoren sieht man diesen Effekt noch nicht aber es gut zu wissen, dass das Dashboard das so schön transparent darstellt.

Über Nacht hat Watchtower auch ein Update der Beacon Node durchgeführt. Der Validator fand das nicht so lustig, dass sein Gesprächspartner plötzlich weg war und hat mit einem Absturz reagiert. Also im Grunde gewünschtes verhalten. Docker startet nach dem Absturz die Validator Node sofort neu. Uptime Robot hat die kurze Downtime nicht registiert. So könnte ich die automatischen Update eigentlich laufen lassen allerdings muss ich noch von Kommandozeilen Parameter auf Konfig Datei umstellen. Mal angenommen einer der Parameter wird bei einem Update entfernt. Dann würde der Container immer wieder abstürzen bis ich den Parameter aus dem Aufruf entferne. Die Konfig Datei ist üblicherweise toleranter was das angeht. 

  • Love it 1
  • Thanks 2
Link zu diesem Kommentar
Auf anderen Seiten teilen

Am 7.6.2020 um 23:54 schrieb skunk:

Docker läuft auch auf einem Pi. Von daher sollte die Docker Installation durchaus funktionieren. Wie gesagt das können wir sonst auch gern zusammen ausprobieren.

Ja, Docker läuft auf dem Raspberry Pi, aber wenn ich das Skript für den Beacon-Node oder den Validator starten möchte, dann erscheint nur folgende Fehlermeldung:
standard_init_linux.go:211: exec user process caused "exec format error"

Das Docker-Image scheint nicht für den Prozessor des Raspberry-Pi ausgelegt zu sein.

 

Am 8.6.2020 um 02:05 schrieb skunk:

Zwei Punkte stören mich noch. Die gRPC Verbindung zwischen Validator und Beacon-Node ist nicht abgesichert. Da muss ich nochmal ein wenig an der Konfig spielen.

Ja das stimmt, die Meldung, dass diese Verbindung nicht sicher sei, bekomme ich auch immer beim Start. Aber da beides auf demselben PC läuft und wir aktuelle noch im Testnet sind, hat mich das bisher nicht gestört. Aber evtl findest du ja hier eine Lösung 😉

 

Am 8.6.2020 um 02:05 schrieb skunk:

Außerdem habe ich etwas von einem zentralen ETH Testnet Server gelesen. Da stellt sich mir die Frage ob ich nicht besser eine lokale Parity Node aufsetzten sollte. Was passiert wenn der zentrale Server mal nicht erreichbar ist?

Ja, das öffentliche Testnet wird noch irgendwo zentral gesteuert, denn nach einigen Wochen Laufzeit wird es wieder zurückgesetzt, vor allem wenn es eine größere Anpassung an der Software gibt. Wie das alles genau zusammen hängt, vor allem da man ja eine Blockchain im Normalfall nicht zurücksetzen kann, habe ich noch nicht herausgefunden.
Und so wie ich das verstanden habe, könnte man auch lokal seine eigene Blockchain unabhängig vom öffentlichen Testnet betreiben, also das wäre dann vermutlich die lokale Parity Node, von der du sprichst? Habe mich damit aber nicht weiter beschäftigt.

Und zufällig habe ich vorhin ein Info von der Discord-Gruppe für dieses Projekt bekommen, wonach das aktuelle öffentliche Testnet "Topaz" in den nächsten Tagen erneut zurückgesetzt wird: https://discord.com/channels/476244492043812875/580039899097595943
Auszug aus obigem Link:

Zitat

@everyone we are planning on launching a new testnet targeting the v0.12.1 version of the eth2.0 specification (the 'final' specification before mainnet) over the coming days. Topaz has had an incredible run and we appreciate all the engagement we've had. We believe this new testnet will fare a lot better and are looking forward to your involvement. Keep in mind Topaz will be shutting down over the coming days. We will update everyone with an official announcement of a new deposit contract and a blog post explaining the new testnet.

 

Am 8.6.2020 um 02:05 schrieb skunk:

Ich habe einen zweiten Key angelegt und es sieht so aus als könnte der Validator beide Verwalten. Ich würde gern in den nächsten Tagen deine und meine Rewards vergleichen um zu sehen ob das wie gewünscht funktioniert.

Okay, gute Idee. Wenn alles ohne Störung läuft, dann konnte mein Validator in den letzten Tagen ca. 0,0050 ETH erwirtschaften. Nur heute lief mein System mal wieder sehr instabil: die CPU-Auslastung und die Prozessor-Wartezeiten waren für einige Stunden sehr hoch. Vermutlich konnte  in der Zeit die Beacon-Node nicht synchronisieren und somit konnte mein Validator keine Blöcke validieren und musste stattdessen Strafe bezahlen. Der Beacon-Node  ist aber nicht abgestürzt, nach einiger Zeit hat sich das Problem von selbst gelöst und nun läuft es wieder ohne Störungen. Ich hoffe mal, dass es dann mit der neuen Version v0.12.1 auch auf dem Raspberry  Pi etwas stabiler läuft...

Bearbeitet von Cookies statt Coins^^
  • Thanks 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 9 Stunden schrieb Cookies statt Coins^^:

Ja, Docker läuft auf dem Raspberry Pi, aber wenn ich das Skript für den Beacon-Node oder den Validator starten möchte, dann erscheint nur folgende Fehlermeldung

Häng dich mal hier mit rein: https://github.com/prysmaticlabs/prysm/issues/5769

Selbst wenn du am Ende nicht mit Docker arbeiten möchtest, so könntest du der Allgemeinheit helfen und das Thema voran bringen :)

vor 10 Stunden schrieb Cookies statt Coins^^:

Ja das stimmt, die Meldung, dass diese Verbindung nicht sicher sei, bekomme ich auch immer beim Start. Aber da beides auf demselben PC läuft und wir aktuelle noch im Testnet sind, hat mich das bisher nicht gestört. Aber evtl findest du ja hier eine Lösung 😉

Laut Github müsste man die Verbindung über TLS absichern. Das ist ein Thema für einen anderen Tag.

vor 10 Stunden schrieb Cookies statt Coins^^:

Ja, das öffentliche Testnet wird noch irgendwo zentral gesteuert

Hier steht auch wie man diese Abhängigkeit auflösen kann: https://docs.prylabs.network/docs/prysm-usage/setup-eth1/

Ich habe jetzt eine geth node am Laufen aber noch nicht angebunden. Setup ist recht einfach.

vor 10 Stunden schrieb Cookies statt Coins^^:

Okay, gute Idee. Wenn alles ohne Störung läuft, dann konnte mein Validator in den letzten Tagen ca. 0,0050 ETH erwirtschaften.

Ja das passt. Meine zwei Nodes schaffen zusammen tatsächlich etwa das Doppelte.

vor 10 Stunden schrieb Cookies statt Coins^^:

Nur heute lief mein System mal wieder sehr instabil: die CPU-Auslastung und die Prozessor-Wartezeiten waren für einige Stunden sehr hoch. Vermutlich konnte  in der Zeit die Beacon-Node nicht synchronisieren und somit konnte mein Validator keine Blöcke validieren und musste stattdessen Strafe bezahlen.

Das scheint nicht an deinem System zu liegen. Meine Nodes musste ebenfalls Strafe zahlen und mein System war nicht sonderlich ausgelastet. Ich vermute mal da gibt es noch ein paar Bugs. Ich will erstmal mein Setup zum Laufen bekommen und dann mal sehen ob ich in meinen Logs eine Ursache ausmachen kann.

  • Love it 1
  • Thanks 2
Link zu diesem Kommentar
Auf anderen Seiten teilen

Nochmal kurz zur Raspi-Kühlung: https://www.instructables.com/id/PWM-Regulated-Fan-Based-on-CPU-Temperature-for-Ras/

... so hab ich das laufen - bei Conrad den Kram besorgt, zusammengelötet und nun läuft das absolut fehlerfrei von Anfang an. Der Lüfter ist nun weit zurückhaltender weil er langsamer dreht. 

Netter Nebeneffekt: Wenn sich mein Raspi extrem anstrengt, dann höre ich das und kann mich mal draufloggen und nachschauen was da los ist.

 

  • Love it 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Gibt es für so ein Pi auch die Möglichkeit ein 12er oder 14er Lüfter zu verbauen? Ich bin inzwischen dazu über gegangen einfach lautlose Lüfter zu verbauen. In meinem Gehäuse habe ich Noiseblocker NB-eLoop B14-1 verbaut. Die gibt es auch als 12er Variante. Hier mal die Lautstärke des Lüfters in einem Test: 

 

Man hört kaum einen Unterschied zwischen statischem Hintergrund rauschen und dem Lüfter auf voller Drehzahl. Ich musste mir zum Vergleich ein paar andere Tests anhören um sicher zu gehen, dass es nicht am Test Setup liegt. Bei andere Lüftern kann man die volle Drehzahl hören.

Runter regeln würde ich diese Lüfter nicht mehr. Die lasse ich bei mir immer auf voller Geschwindigkeit laufen weil man den Unterschied ohnehin nicht hört.

Für den Pi4 dann vielleicht sowas hier "kostenlos" aus dem 3D Drucker: https://www.thingiverse.com/thing:3780466

  • Love it 2
  • Thanks 1
  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Seit Mittwoch gibt es nun das neue Testnet "Onyx", vgl Nachricht aus dem Discord-Channel:

Zitat

Hello @everyone! Earlier today we announced the Onyx Testnet and we are pleased to announce v1.0.0-alpha.10 for Onyx! We want to thank all of the Topaz participants for an incredible few months of testing. Your feedback, support, and encouragement has enabled us to build towards the latest mainnet scale, multi-client compatible, and "final" eth2 spec implementation for phase 0. Over the next few months, we'll be testing in Onyx as we work towards promoting Prysm from alpha to beta in preparation for a live mainnet launch later this year. Now is the perfect time to test your mainnet hardware and set your expectations before there is any real value at stake. At this time, Prysmatic Labs will start turning down its Topaz validators and beacon nodes (35% of the network). We now encourage participants to send new ETH2 deposits to the Onyx contract using the latest alpha.10 binaries. If you sent a deposit already with alpha.9, that deposit will not be considered valid in Onyx. Once the Onyx deposit contract has reached the minimum validator threshold of 16384, the genesis date will be set for midnight UTC of the next full day (24 to 48 hours later). Release: https://github.com/prysmaticlabs/prysm/releases/tag/v1.0.0-alpha.10 Announcement: https://medium.com/prysmatic-labs/introducing-the-onyx-testnet-6dadbd95d873

Und wie ich aus dieser Nachricht heraus lese, ist das wohl nun die letzte Test-Runde, bis dann zum Ende des Jahres die hier getestete Phase 0 produktiv gehen soll!
-> Zur Info: Phase 0 beinhaltet die neue ETH-2-Beacon-Chain incl der Validatoren, was in dieser Phase noch parallel zur bestehenden ETH-1-Chain betrieben wird (https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/#phase-0-beacon-chain)

Aufgrund des neuen Testnet musste ich mir wieder 32 Test-ETH holen und diese auf einen neue Deposit-Adresse einbezahlen. Bei der Gelegenheit habe ich gleich die Empfehlungen von @skunk umgesetzt und lasse die Skripte nun als Dienste auf dem Raspberry Pi laufen. Das funktioniert nun sehr zuverlässig. (Werde dazu bei Gelegenheit meinen ersten Betrag aktualisieren)

Aktuell befindet sich das neuen Onyx-Testnet noch in der Initialisierungsphase und wird erst gestartet, wenn sich eine Mindestanzahl von Validatoren gefunden haben. Aktuell sind es erst 13175 von benötigten 16384 GenesisValidatoren. Aber ich vermute, dass bis morgen diese Zahl erreicht sein sollte, wenn dann die meisten vom alten Testnet auf das neue gewechselt haben.

 

 

Am 9.6.2020 um 12:38 schrieb skunk:
Am 9.6.2020 um 02:09 schrieb Cookies statt Coins^^:

Ja, Docker läuft auf dem Raspberry Pi, aber wenn ich das Skript für den Beacon-Node oder den Validator starten möchte, dann erscheint nur folgende Fehlermeldung

Häng dich mal hier mit rein: https://github.com/prysmaticlabs/prysm/issues/5769

Selbst wenn du am Ende nicht mit Docker arbeiten möchtest, so könntest du der Allgemeinheit helfen und das Thema voran bringen

Aber in dem Link von dir steht auch der Satz: "There is no current plan to support ARM64 based docker images". Somit mache ich mir da aktuell wenig Hoffnungen. Vieles läuft auf dem Raspberry Pi nicht bzw nicht so einfach habe ich festgestellt... ._.

 

 

Am 9.6.2020 um 12:38 schrieb skunk:

Hier steht auch wie man diese Abhängigkeit auflösen kann: https://docs.prylabs.network/docs/prysm-usage/setup-eth1/

Ich habe jetzt eine geth node am Laufen aber noch nicht angebunden. Setup ist recht einfach.

Ich hatte gestern Abend auch noch auf die Schnelle versucht, einen ETH1-Node aufzusetzen, aber es scheiterte daran, dass die Software nicht auf dem Raspberry Pi lauffähig war oder ich habe was falsch gemacht. Werde es in den nächsten Tagen nochmal versuchen..

 

 

Am 9.6.2020 um 12:57 schrieb Jokin:

Nochmal kurz zur Raspi-Kühlung: https://www.instructables.com/id/PWM-Regulated-Fan-Based-on-CPU-Temperature-for-Ras/

[...]

Netter Nebeneffekt: Wenn sich mein Raspi extrem anstrengt, dann höre ich das und kann mich mal draufloggen und nachschauen was da los ist.

Sehr gute und nachvollziehbare Anleitung 👍.

Am 9.6.2020 um 13:26 schrieb skunk:

Ich bin inzwischen dazu über gegangen einfach lautlose Lüfter zu verbauen. In meinem Gehäuse habe ich Noiseblocker NB-eLoop B14-1 verbaut. Die gibt es auch als 12er Variante.

[...]

Runter regeln würde ich diese Lüfter nicht mehr. Die lasse ich bei mir immer auf voller Geschwindigkeit laufen weil man den Unterschied ohnehin nicht hört.

Auch eine gute Idee 👍

Ich lasse mittlerweile nun immer minütlich die Temperatur mit protokollieren, und aktuell komme ich auch ohne Kühlung noch sehr gut klar. Muss das weiter beobachten und mich dann entscheiden, was ich mache, es gibt ja nun einige gute Vorschläge zur Auswahl 😉

  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor einer Stunde schrieb Cookies statt Coins^^:

Seit Mittwoch gibt es nun das neue Testnet "Onyx", vgl Nachricht aus dem Discord-Channel:

Und wie ich aus dieser Nachricht heraus lese, ist das wohl nun die letzte Test-Runde, bis dann zum Ende des Jahres die hier getestete Phase 0 produktiv gehen soll!
-> Zur Info: Phase 0 beinhaltet die neue ETH-2-Beacon-Chain incl der Validatoren, was in dieser Phase noch parallel zur bestehenden ETH-1-Chain betrieben wird (https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/#phase-0-beacon-chain)

Aufgrund des neuen Testnet musste ich mir wieder 32 Test-ETH holen und diese auf einen neue Deposit-Adresse einbezahlen. Bei der Gelegenheit habe ich gleich die Empfehlungen von @skunk umgesetzt und lasse die Skripte nun als Dienste auf dem Raspberry Pi laufen. Das funktioniert nun sehr zuverlässig. (Werde dazu bei Gelegenheit meinen ersten Betrag aktualisieren)

Aktuell befindet sich das neuen Onyx-Testnet noch in der Initialisierungsphase und wird erst gestartet, wenn sich eine Mindestanzahl von Validatoren gefunden haben. Aktuell sind es erst 13175 von benötigten 16384 GenesisValidatoren. Aber ich vermute, dass bis morgen diese Zahl erreicht sein sollte, wenn dann die meisten vom alten Testnet auf das neue gewechselt haben.

Das ist komplett an mir vorbei gegangen. Da werde ich mich Heute Abend nochmal ran setzten. Danke dir für die Info.

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.

Das Setup um einen Slasher zu ergänzen steht noch auf meiner ToDo List. Auch will ich dieses mal die Deposit Transaktionen selber machen anstelle auf eine zentrale Webseite angewiesen zu sein. Mir ist auch aufgefallen, dass ich einen Withdraw key habe aber noch keinen Plan wie das am Ende eigentlich funktioniert. Hast du dazu eine Anleitung gesehen?

vor einer Stunde schrieb Cookies statt Coins^^:

Aber in dem Link von dir steht auch der Satz: "There is no current plan to support ARM64 based docker images". Somit mache ich mir da aktuell wenig Hoffnungen. Vieles läuft auf dem Raspberry Pi nicht bzw nicht so einfach habe ich festgestellt... ._.

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^^

  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Dieses mal habe ich die Deposit Transaktionen selber erstellt um auch die letzten Abhängigkeiten los zu werden. Es ist erstaunlich einfach. Ich habe es über MyCrypto gemacht. Als erstes natürlich mit meiner Geth Node Verbunden. Ich will ja Transaktionen erstellen selbst wenn alle anderen Dienste offline sind. In MyCrypto habe ich eine normale ETH Transaktion gewählt. Ziel ist der Contract, 32 ETH und bei den zusätzlichen Transaktions Daten das was mir der Validator ausgegeben hat.

Wichtig ist es müssen genau 32 ETH sein. 32.1 ist ungültig und die Transaktion wird auf einen Fehler laufen. Außerdem kostet die Transaktion recht viel Gas. Man muss da schon mit um die 400K Gas an den Start gehen.

  • Thanks 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...

Wichtige Information

Wir haben Cookies auf Deinem Gerät platziert. Das hilft uns diese Webseite zu verbessern. Du kannst die Cookie-Einstellungen anpassen, andernfalls gehen wir davon aus, dass Du damit einverstanden bist, weiterzumachen.