Cookies statt Coins^^

Ohje, hat Alex in dem Video tatsächlich gesagt, dass PLC besser wäre als Ethereum!!!??? 😄 Das ist ja absolut lächerlich dieser Vergleich, aber die Leute fressen ihm aus der Hand statt mal ihr Hirn einzuschalten und selbst zu recherchieren. Wie bereits von anderen Usern hier in dem Thread dargestellt haben die sogenannten PLC-"SmartContracts" nur sehr rudimentär mit den SmartContracts zu tun, die man gewöhnlich bei anderen Blockchain-Projekten erwarten, u.a. bei Ethereum. Zum Vergleich: Die sogenannten PLC-"SmartContracts": Hier wurde wohl in die Handy-App so erweitert, dass man auf Knopfdruck für sämtliche Coins auf der Wallet einen Timelock hinerlegen kann. Für die hinterlegte Summe wird dann wohl die PLC-Company monatlich die entsprechende Minting-Überweisung tätigen. Aber ja, man kann das wohl laut Wikipedia tatsächlich als einen SmartContract bezeichnen. Allerdings ist das nur ein einziger fest vorgegebener SmartContract, den die PLC-Company mit allen Nutzern eingeht. Echte Blockchain-SmartContracts (z.B. bei Ethereum): Wenn eine Blockchain von sich behauptet, dass sie SmartContracts unterstützt, dann handelt sich hier vielmehr um ein eigenständige Entwicklungsumgebung, auf der jeder Benutzer (nicht nur die Coin-Ersteller) selbstständig eigenen SmartContracts erstellen kann und diese mit anderen Nutzern eingehen kann. Ethereum bietet ein ganzes Ökosystem in Bezug zu den SmartContracts, und das als OpenSource völlig kostenlos. PLC hingegen feiert eine einzelne Implementierung eines automatischen Vertrags in ihrer Handy-App als "SmartContract". Bildhaft gesprochen bietet Ethereum eine ganze Autofabrik, in der jeder Interessierte kostenlos beliebig viele eigene Fahrzeuge (=SmartContracts) individuell nach eigenen Wünschen selbst bauen kann, vom Lamborghini bis hin zum Monster-Truck. PLC hingegen bietet ein nach ihren Vorstellungen entworfenes und unveränderliches Auto (=PLC-"SmartContract") gegen teures Geld zum Verkauf an und präsentiert dies als Weltneuheit. ------ Leider gibt es wenig verständliche Infos zum Thema SmartContracts, die auch jemand versteht wenn er nicht gerade in der IT arbeitet. Und alle verständlichen Artikel beschreiben die SmartContracts nur sehr oberflächlich. Daher fällt es den PLC-Machern auch entsprechend leicht, ihre PLC-"SmartContracts" als Sensation zu feiern. Ich versuche das Thema "SmartContract" daher mal mit eigenen Worten zu beschreiben und beziehe mich auf nachfolgende Seminararbeit eines Studenten, die ich im Internet gefunden habe. Ab Seite 6 wird hier ein selbst geschriebener SmartContract ausführlich beschrieben: https://www.h-brs.de/files/seminararbeit_rene_mueller_final.pdf Ein SmartContract im eigentlichen Sinne ist ein kleines Programm bzw ein Stück Quellcode, welches auf der Blockchain abliegt und von einem Node ausgeführt wird. Mit den entsprechenden Tools (z.B Solidity bei Ethereum) kann jeder Nutzer so seine eigenen SmartContracts auf die Blockchain bringen. So können z.B Prüfungen/ Bedingungen u.a. in Überweisungen mit eingebaut werden. -> z.B. Neuen Token kaufen (vgl. "buyTokens" aus verlinktem PDF): Gegen Überweisung von Ethereum an einen SmartContract bekomme ich im fest vorgegebenen Verhältnis einen anderen Token zurück, solange eine Maximalanzahl an einbezahlten Ethereum noch nicht überschritten ist (bzw. so lange es noch eine ausreichende Anzahl des zu verkaufenden Tokens vorhanden ist.) -> z.B. Kontostandsabfrage (vgl. "getBalance"): Bei einem SmartContract muss es sich nicht immer um Überweisungen handeln. Der SmartContract kann auch die Funktion bieten, dass die Anzahl der insgesamt von allen Nutzern eingezahlten Ethereum angezeigt wird. Durch eine Berechtigung wird gesteuert, dass diese Abfrage nur der Ersteller dieses SmartContracts ausführen kann. Je höher die Komplexität dieses SmartContracts (z.B. Abhängig von den Anzahl der Anweisungen) desto mehr CPU wird im Node bei der Ausführung des SmartContracts benötigt. Daher kostet das Ausführen von SmartContracts eine Gebühr, z.B. "Gas" bei Ethereum, die der Node bei der Ausführung des SmartContracts als Entschädigung behalten darf. => Und jetzt versuchen sich mal alle PLC-Investierten grob ein eigenes Bild von den Möglichkeiten der SmartContracts bei Ethereum zu machen und übertragen dies dann auf die tatsächliche Implementierung bei PLC: Allem Anschein nach sind die Versprechen bezüglich der technische Bedeutung dieser sogenannten PLC-"SmartContracts" deutlichst übertrieben.

Habe mir nun auch mal das Video in Ruhe angeschaut.. Und es ist tatsächlich sehr dubios, wie aus 20€ Euro plötzlich 100€ werden können. Aber es passt tatsächlich grob zusammen, wenn man von einem Bedienungsfehler und von einer schlecht programmierten App ausgeht: Bei der ersten Eingabe, beim Aufladen der Karte, klickt er auf den Button "Deposit with PLC" und er sagt dazu: "Ich geb jetzt einfach mal 4 ähm 20 Platincoins ein". Aber in der Anzeige steht aber ein Euro-Betrag. Auch als dann die App den QR-Code mit der Adresse anzeigt, wo die PLC hin überwiesen werden sollen, steht unter dem QR-Code: "Send exactly: 4 PLC". Denn, bei der Überweisung von seinem PLC-Konto, überweist er fälschlicherweise 20 PLC an die angegebene Adresse, die ihm der QR-Code in der App anzeigt. Eigentlich hätte er nur 4 PLC überweisen müssen. Der QR-Code mit der Adresse, auf welche die 20€ (4 PLC) überwiesen werden sollen, zeigt auf diese Adresse: https://platincoin.info/#/address/P4uKvUug4Fuia8GeE4SqNycxNhHhNy5SMJRs Und dort auf dieser PLC-Adresse liegen nun die überwiesenen 20 PLC und wurden seitdem nicht mehr bewegt. Seltsam, scheinbar hodlt der Kreditkarten-Herausgeber auch seine PLC-Coins. Seltsam ist es aber auch, dass die App für diese Transaktion manchmal die händisch eingetragenen 20€ anzeigt ("PLC-Order #46 for €20"), aber tatsächlich wird die Gesamtsumme aus aus den überwiesenen 20 PLC berechnet. Später, bei der zweiten PLC-Überweisung für 400€, aktualisiert sich die Gesamtsummer damit gar nicht mehr, obwohl im Video 20 Minuten vergangen sind. Und in der App steht ja auch zu lesen, dass eine Buchung 1-3 Tage dauern würde. Tatsächlich kam diese aber schon bei der ersten Überweisung nach 6 Minuten an, wie man an der Uhrzeit im Handydisplay erkennen kann (was in dem Fall ja positiv für Platincoin zu werten wäre, falls das dann in der Realität tatsächlich so schnell gehen würde). Aber für mich sprechen all diese Auffälligkeiten eher dafür, als ob die App extra schnell für dieses Video in Form eines einfachen Vorführ-Prototyps zusammengebaut wurde um den Anschein zu erwecken, dass man damit bald schon eine Kreditkarte aufladen könne. Aber das ist nur meine Meinung dazu 😉

Ja, das ist wohl eine gute Idee 👍 Denn in den letzten Tagen kam es zu größeren Problemen im Testnet, zunächst aufgrund eines Synchronisierungsfehlers des Prysm-Clients. Daraufhin gab es eine übereilte Korrekturversion, die aber noch mehr Fehler verursacht hatte. Details dazu kann man hier nachlesen: https://medium.com/prysmatic-labs/eth2-medalla-testnet-incident-f7fbc3cc934a Hier in dem Bericht findet man im letzten Drittel (Kapitel "The risk of client dominance") auch eine Verteilung der aktuellen ETH2.0-Clients: - 78,6% sind Prysm-Clients - 8,5% sind Lighthouse Clients - 12,9% sind andere/ unbekannte Clients Und in dem Bericht wird auch empfohlen, andere Clients auszuprobieren, um im Fehlerfall schnell wechseln zu können: "However, it is good practice to try other implementations and experiment switching between them as needed". Ich werde mir daher auch mal als nächstes den Lighthouse-Client ansehen und diesen auf dem Raspberry Pi installieren. Bei Lighthouse gibt es sogar eine Installationsanleitung, die auf den Raspberry Pi mit Ubuntu zugeschnitten ist: https://lighthouse-book.sigmaprime.io/pi.html

Hi, ich habe bei mir das Filesystem Ext4. Hatte damals nicht viel über das passende Filesystem nachgedacht sondern einfach diese Anleitung hier befolgt, und dort wurde auch Ext4 empfohlen: https://kauri.io/running-an-ethereum-full-node-on-a-raspberrypi-4-m/9695fcca217f46feb355245275835fc0/a. Auch meine Root-Partition läuft unter Ext4. Das wurde auch automatisch so eingerichtet, als ich das Ubuntu-Image installiert hatte. Dem kann ich nur zustimmen: Die Testnet-Konfiguration lief auf der HDD zum Schluss sehr gut und stabil. Davor hatte ich drei Wochen lang versucht, die ETH1.0-Mainnet-Chain auf der HDD zu synchronisieren, aber es war erfolglos: Ich war immer eine Minute hinter dem aktuellen Block und habe es mit der HDD nicht geschafft diese synchron zu bekommen. Ich habe es dann aufgegeben und mir nun ein SSD gekauft. Die muss ich nun demnächst mal einbauen und dasselbe erneut versuchen. Nur zur Zeit habe ich aber leider etwas wenig Zeit dafür. Habe auch erst vor ein paar Tagen auf das neue Testnet umgestellt ("Medalla Testnet"). Nachdem mein Validator stabil lief, habe ich das alles nicht mehr so aktiv mitverfolgt. Das hier ist nun mein neuer Validator im Medalla-Testnet: https://beaconcha.in/validator/32487 Vor zwei Tagen habe ich die 32 Test-ETH einbezahlt, aber nun muss ich noch vier Tage warten, bis der Validator aktiviert wird. D.h es werden nur immer Schritt für Schritt neue Staking-Clients zugelassen.. Was ich mittlerweile mit dem neuen Testnet dazugelernt habe ist, dass es aktuell ja vier unterschiedliche Staking-Clients gibt. Die Anleitung hier in diesem Thread bezog sich bisher auf den Prysm-Client (https://medalla.launchpad.ethereum.org/prysm). Daneben könnte man für das Staking von ETH auch einen der folgenden Clients verwenden: - Lighthouse (https://medalla.launchpad.ethereum.org/lighthouse) - Nimbus (https://medalla.launchpad.ethereum.org/Nimbus) - Teku (https://medalla.launchpad.ethereum.org/Teku) Soweit ich das mitbekommen habe, ist das aktuelle Testnet hier nun ein Multiclient-Testnet, in dem alle vier Clients parallel betrieben werden. Die vorherigen Testnets in diesem Thread waren hingegen reine Prysm-Client-Testnets. Weitere Infos zum aktuellen Testnet und zu den weiteren ETH2.0-Meilensteinen gibt es hier: https://medalla.launchpad.ethereum.org/

Sehr gut, dass es bei dir nun auch klappt! 👍 Als ich vor ein paar Monaten mit meinen ersten Versuchen startete, gab es noch keine 64-Bit-Raspbian-OS, daher habe ich nun Ubuntu.. Wenn ich alles neu installieren müsste, dann würde ich nun wohl auch das 64-Bit-Raspbian-OS nehmen 😉

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: 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): 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.

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

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): - 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... 😄

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? 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. 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. Gut zu wissen 👍. Das muss ich nun auch mal probieren. Aber erst muss ich den Geth Node auf dem Raspberry Pi zum laufen bringen.. 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?

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. 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... ._. 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.. Sehr gute und nachvollziehbare Anleitung 👍. 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 😉

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. 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 😉 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: 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...

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 😉 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. 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. 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.. 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. 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. 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 😄 . 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. 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..

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. 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 😉

Hi, habe nun im Forum im Bereich "Altcoin->Mining" einen Beitrag erstellt und meine Erfahrungen aus dem ETH-2.0-Testnet zusammengeschrieben: Viel Spaß beim Lesen und Nachbauen 😉

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: 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: 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): 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: 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: 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. 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 😉

Ja, seit genauer einer Woche habe ich nun auf einem Raspberry Pi 4 im ETH-Testnetz einen Validator und einen dazugehörigen Node am Laufen. Im Vergleich zu den ersten Versuchen im letzten Jahr läuft nun alles mittlerweile deutlich stabiler. Wenn ich mal etwas mehr Zeit habe und falls Interesse besteht, kann ich mal etwas mehr dazu hier im Forum schreiben..

Danke für die Infos. Eigentlich lese ich im Prognose-Thread immer mit, aber damals hatte ich das noch nicht auf dem Schirm und somit wohl überlesen. Im Prinzip werden die Kurse bei zu starken Schwankungen und täglich um 02:00 UTC neu kalibriert. Und bei obigem Link ist auch die Historie für 2019 mit dabei. Wenn man die mit dem ETH-Kurs auf Bitcoin.de vergleicht, dann kann man folgendes erkennen: -> 17.Nov 2019: ETH = 170€ EthBull= 2.000$ -> Dez 2019: ETH = 110€ EthBull =600€ -> 3.Feb 2020 ETH = 170€ EthBull = 1.200$ Wie vermutet erreicht der Kurs bei zu starken Minus-Kursen nicht mehr den ursprünglichen Wert. Aber dafür hat man nicht das Risiko, komplett auf Null zu fallen. Ich werde es daher mal ausprobieren und eine kleine Menge investieren. Mal abwarten wo der Kurs in einem Jahr steht... (..bei meinem Glück vermutlich bei 10$^^)

Hallo zusammen, auf Binance gibt es ja seit kurzem neue Trading-Paare, nämlich die Bull-/Bear-Coins für Bitcoin und entsprechend EthBull, EosBull für ausgewählte andere Coins. Soweit ich das verstanden habe, orientiere sich diese Coins an den jeweiligen Kurs des eigentlichen Coins, jedoch ändert sich der Kurs um den Faktor 3 im Vergleich zum Originalcoin. Der Vorteil ist, dass man gehebelt Coins kaufen kann, ohne dem Risiko ausgesetzt zu sein, dass der Trade liquidiert wird, falls sich der Kurs zu weit in die andere Richtung bewegt. Aktuell steht der EthBull-Coin bei knapp 100$ und ETH bei bei 130$ . Da ich sehr an die Zukunft von ETH glaube, bin ich mir sicher, dass der Kurs langfristig wieder steigen wird, und somit überlege ich, aktuell auch mit einen kleinen Anteil in EthBull zu gehen. Allerdings habe ich noch nicht genau das Prinzip verstanden, wie stark der Kurs jeweils steigt und sinkt zum Originalkurs. Das mit dem "mal drei" kommt ja nicht genau hin: z.B: im Februar stand ETH bei knapp 300$, und EthBull bei 4.000$. Mittlerweile hat sich der Kurs von ETH halbiert. Mit einem 3er-Hebel sind das dann ja mehr als 100% Verlust. Entsprechend tief liegt EthBull nun bei 100$ ziemlich am Boden. Die Frage ist nun: Wenn ich nun für 100$ EthBull kaufe, und der ETH-Kurs steigt wieder auf die 300$, würde dann EthBull auch wieder auf die 4.000$ steigen? Ich vermute mal nicht, denn das wäre ja dann ein extremer Anstieg. Ich befürchte eher, dass wenn ich heute den EthBull kaufe, und ETH fällt nochmal um 50% und steigt anschließend wieder um 100% auf den Ausgangszustand, dass dann EthBull nicht wieder am Ausgangszustand ist, sondern weiterhin deutlich tiefer. Weiß da jemand Genaueres, wie das hier funktioniert?

Heute kam im Weltspiegel eine Reportage über Bitcoin-Mining in Paraguay. Wen es interessiert, hier der Link zur ARD-Mediathek: https://www.daserste.de/information/politik-weltgeschehen/weltspiegel/videos/paraguay-kryptowaehrung-bitcoin-video-100.html

In meiner Historie habe ich auch Einkäufe nachts um 2 Uhr und die Order wurde immer sofort zum aktuellen Zeitpunkt und -Kurs ausgeführt. Auch WE und Feiertage sind kein Problem. Evtl. war das frühers mal anders, ich bin erst seit November 2019 dort und sehr zufrieden damit.

Die Bison-App kann ich auch voll und ganz für den Einstieg in die Krypto-Welt empfehlen. Dagegen spricht lediglich der eingeschränkte Funktionsumfang, da man hier nur sofort zum aktuellen Kurs kaufen kann (d.h. man kann nicht wie auf Bitcoin.de eine eigene Order zu einem gewünschten Betrag einstellen und warten, bis der Kurs den gewünschten Betrag erreicht). Dafür spricht: Der fest angeboten Ein- und Verkaufskurs ist sehr fair (nur 1,5% Differenz zwischen Ein- und Verkaufskurs und alles ohne jegliche Gebühren), die Kaufabwicklung ist extrem einfach (nur sofortiger Direkthandel mit Bison zum aktuellen Preis, d.h man kann nicht versehentlich ein zu teures Angebot annehmen oder Ärger mit dem Handelspartner bekommen) und man kann mit minimalsten Beiträgen handeln (Einkauf ab 1€ möglich). Ich finde, da ist man als Einsteiger und Gelegenheitskäufer sehr gut aufgehoben ;-)

Genau!! Und auch wenn man daraus inhaltlich mehr machen hätte können, aber genau das verdeutlicht die Reportage meiner Meinung nach ganz gut: Egal, was jemand 'wissenschaftlich' beweisen lassen möchte, man muss nur 500.000€ an das Heartland-Institut bezahlen, dann organisieren sie dir einen Wissenschaftlicher, der dir zu jedem Thema eine 'wissenschaftliche' Arbeit nach deinen Wünschen schreibt, egal ob es nun gegen die Klimaerwärmung geht, oder dass Passivrauchen bzw Autoabgase gar nicht so schädlich sind. Davon kann man meiner Meinung nach nicht oft genug berichten, um die Menschen über solche Praktiken aufzuklären.

Heute habe ich zufällig nachfolgende Reportage gesehen, da musste ich gleich an diesen Thread hier im Forum denken, da das Heartland-Institut hier ja auch an der einen oder anderen Stelle als 'Quelle' verwendet wurde.. 😉 https://www.zdf.de/politik/frontal-21/undercover-bei-klimawandel-leugnern-100.html Inhalt des Videos:

Vlt haben sie eure Konten mit meinem Konto verwechselt. Denn wollte mein Fidor-Konto schon seit der letzten AGB-Änderung (Einführung Kontoführungsgebühren) im November kündigen, aber nichts ist passiert, stattdessen werden weiter die Gebühren abgezogen, denen ich eigentlich fristgerecht widersprochen hatte... 😄

Ich plane auch, einen ETH-Staking-Node zu betreiben und verfolge daher das Thema mit großem Interesse. Den Aufwand für Pflege und Steuer muss man dabei wohl als Hobby ansehen und mittelfristig entscheiden, ob sich der Aufwand tatsächlich auf Dauer lohnt. Ich möchte es aber auf jeden Fall mal ausprobieren. Aber zum Thema Inflation kann ich dich beruhigen: Bereits jetzt unterliegt ETH aufgrund des Minings einer jährlichen Inflation von 4,7%, wie man anhand der historischen Daten auf Coinmarketcap erkennen kann: 05.01.2019: Umlaufversorgung ETH = 104.233.441 04.01.2020: Umlaufversorgung ETH = 109.157.039 => +4,7% Und bei ca 4% sollte ja auch der Staking-Reward liegen, also würde die Inflation nahezu unverändert bleiben. Da sich aber aktuell alles noch in der Entwicklung befindet, kann man jetzt noch nicht sicher sagen, wie hoch der Staking-Reward tatsächlich ausfallen wird...