Zum Inhalt springen

Ethereum-2.0-Staking auf Raspberry Pi


Cookies statt Coins^^

Empfohlene Beiträge

  • 4 Wochen später...

Hallo zusammen,

mittlerweile sind wieder einige Wochen vergangen und es ist viel passiert. Daher erfolgt hier nun ein kurzes Update von mir..
 

I. "Genesis time has been set to Dec 1, 2020, 12pm UTC":

Die wichtigste Neuigkeit haben hoffentlich schon alle mitbekommen:
Am 1. Dezember erfolgt nun endlich Phase #0, d.h. das bislang hier getestete Zusammenspiel zwischen Beacon-Chain+Validator usw. wird ins Mainnet überführt, vgl: https://discord.com/channels/476244492043812875/580039899097595943/773574992046194718

Seit einigen Tagen kann man sich nun über das offizielle ETH2.0-Launchpad einen Validator für das Mainnet registrieren. Ich habe gestern mit der Registrierung begonnen, diese aber noch nicht abgeschlossen d.h. beim Überweisen der 32 ETH habe ich abgebrochen, da ich noch etwas warten möchte.
Hier kommt nun eine Zusammenfassung für alle, die wissen möchte, wie die Registrierung abläuft (Spoiler: eigentlich sehr ähnlich wie im Testnet^^).

Die Website zum ETH2.0-Launchpad ( https://launchpad.ethereum.org/overview ) ist in mehrere Abschnitte aufgeteilt:

  1. "Overview": Zu Beginn muss man verschieden wichtigen Infos zum Staking-Prozess bestätigen, die man sich ausführlich durchlesen und auch verstehen sollte.
  2. "Select Client": Hier muss man sich nun die Konfiguration seines Setups zusammen klicken. Da es verschieden Anbieter der ETH2.0-Staking-Software gibt, sollte man sich diese Konfiguration auswählen, die man bereits erfolgreich im Testnet betrieben hat. (Die ausgewählte Software muss man sich natürlich selbst installieren, das erfolgt nicht über diese Website^^)
  3. "Generate Keys": Nun muss man sich für seinen zukünftigen Validator einen "Deposit Key" erzeugen. Die Erzeugung erfolgt auf der eigenen Hardware und nicht auf der Website. Für den Raspberry-Pi muss man sich mal wieder die Sourcen erst selbst kompilieren (vgl Anleitung auf Website), da es noch keine ARM-Setup-Dateien gibt.
    Bei diesem Schritt erhält man drei wichtige Elemente, die man sehr sorgfältig sichern muss:
    - Validator-Key: Diesen Schlüssel braucht man später, um damit seinen Validator zu aktivieren. Es müsste sich hierbei also um den Private-Key handeln.
    - Passwort für Validator-Key: Dieses Passwort braucht man später, um seinen Validator mit dem dazugehörigen Validator-Key zu aktivieren
    - Mnemonic-Seed-Phrase: Aus diesen Wörtern wurde der Validator-Key generiert. Man braucht diese Mnemonic unbedingt, um später bei einer Auszahlung bzw bei einem Exit auf seine hinterlegten 32 ETH zugreifen zu können. ("Validator keys are derived from a unique mnemonic (or seed). Your seed is the ONLY WAY to withdraw your funds. Above all, keep it safe!")
    Anbei ein geschwärzter Screenshot, auf dem die Generierung zu sehen ist:
    Contract1.thumb.png.921b9d2cb80c7a66a02eb24ad359629c.png
  4. "Upload Validator": Im vorherigen Schritt wurde zusätzlich zum Validator-Key das sogenannte "Deposit Date File" erzeugt, welches den Public-Key zum Validator enthält. Diese Datei muss zur Verifizierung nun hochgeladen werden, da diese Daten scheinbar dafür benötigt werden, damit im späteren Schritt die Einzahl der 32 ETH dem eigenem Validator gutgeschrieben werden können.
  5. "Connect Wallet": Hier hat man nun die Möglichkeit, eines der folgende Wallets zu verwenden, um dann im nächsten Schritt die 32 ETH über den SmartContract einzubezahlen. Es gibt folgende drei Wallets zur Auswahl:
    - Metamask
    - Portis
    - Fortmatic
    Ich entscheide mich für Metamask, denn darüber habe ich auch mein Hardware-Wallet angeschlossen, auf dem die 32 ETH liegen.
  6. "Summary": Hier noch mal eine letzte Zusammenfassung, bei der man nochmal explizit erklären muss, dass man sich hierbei gewisse Risiken aussetzt und im Fehlerfall sein 32 ETH verlieren kann:
    Contract2.thumb.png.859146aa20cf96d82bc51bfb3de4c62c.png
  7. "Transactions":
    An dieser Stelle habe ich erst mal abgebrochen. Nun würden man über sein angebundenes Wallet über eine von der Website erzeugten vorgefertigte Transaktion die 32 ETH dem SmartContract übergeben und auf folgender Adresse einbezahlen:
    https://etherscan.io/address/0x00000000219ab540356cBB839Cbe05303d7705Fa
    Stand heute befinden sich hier bereits 1.436 Transaktionen, d.h. so viele Validatoren sind bereits registriert und mit einem Deposit hinterlegt. Insgesamt wird ein Minimum von 16.384 Validatoren benötigt, bevor die Phase #0 aktiviert wird. Wenn also bis zum anvisierten Datum (7 Tage vor dem 1. Dez.) noch nicht genügend Validatoren zusammen gekommen sind, wird so lange gewartet bis die Mindestanzahl erreicht ist: https://en.ethereumworldnews.com/ethereum-is-set-to-launch-eth2-0-phase-0-on-december-1st/

Diese Zusammenfassung hier habe ich auch für mich selbst zur Bestätigung geschrieben, ob ich alles richtig verstanden haben. Wenn hier jemand Fehler feststellt, dann bitte melden.

Und worauf warte ich nun noch?
Aktuell hat die Prysm-Software noch einen Fehler, d.h. man kann für den Prysm-Validator noch keine Mainnet-Wallet erstellen:
"Our latest release of Prysm, beta.1, is not mainnet compatible. Please do not run Prysm yet until we announce it in our Discord channel, our releases page, our official mailing list or in this documentation portal."  ( https://docs.prylabs.network/docs/wallet/nondeterministic )

Bevor ich also die Überweisung der 32 ETH durchführe, möchte ich den Prysm-Validator mit dem hier erzeugen Validator-Key auf meinem Raspberry Pi aktivieren. D.h. erst wenn mein Validator mit dem Mainnet-Wallet und meinem erzeugtem Valdiator-Key und ausgewähltem Passwort grundsätzlich läuft, erst dann werde ich die Überweisung durchführen.

 

II. Hinweis zu möglichen Risiken:

Und noch drei wichtige Punkte, die man im ersten Schritt des obigen ETH2.0-Launchpad bestätigt hat:

- "Transfers between validators are disabled until at least phase 1. Validators will have to wait until phase 2 (around two years) to be able to withdraw to a specific shard."
Man kann die einbezahlten 32 ETH erst wieder ausbezahlen, sobald die Phase #2 implementiert sein wird. Dies kann scheinbar noch ca. zwei Jahre dauern.
Eine Übersicht über die verschiedenen Phasen findet man in der Roadmap: https://ethereum.org/en/eth2/#roadmap
Zusammengefasst kann man folgendes lesen: In der nun kommenden Phase #0 wird parallel zur ETH1.0-Chain die Beacon-Chain mit den Validatoren eingeführt. Streng genommen hat diese Phase #0 noch keine wirklichen praktischen Nutzen für die Ethereum-Chain, man betreibt hier lediglich einen Validator auf der Beacon-Chain, aber man kann (noch) keinerlei eigene Transaktionen durchführen. Diese Beacon-Cain wird aber das Rückgrat für alle weiteren zukünftigen Implementierungen sein. Denn später in der Phase #1 wird es die sogenannten Shard-Chains geben. Soweit ich das verstanden haben, sind das mehrere unterschiedliche Chains, die alle über die Beacon-Chain verbunden sind, so dass man die Ethereum-Blockchain scheinbar beliebig hochskalieren kann. Die aktuellen Validatoren aus Phase #0 werden dann wohl auch die Blöcke dieser Shard-Chains erstellen und validieren. Ein Shard-Chain-übergreifender Austausch von Informationen (ETH) wird es in dieser Phase wohl noch nicht geben. In Phase #1.5 wird dann die aktuelle ETH1.0-Chain zu einer eigenständige ETH2.0-Shard-Chain migriert. Ab diesem Zeitpunkt wird es dann kein Mining mehr geben für Ethereum. Und erst mit Phase #2 sollen auch die unterschiedlichen Shard-Chains miteinander kommunizieren können. D.h. die heute für Phase #0 einbezahlten 32 ETH sitzen so lange in der Beacon-Chain fest, bis dann in Phase #2 eine Chain-übergreifender Austausch möglich sein wird ("cross-shard communication").

- "Validators are participating in the initial launch of a novel network. As with any new piece of software, there is the potential for software bugs. While unlikely, potential bugs may result in slashing."
Die Gefahr eines Softwarefehlers besteht natürlich auch immer, wie es im Testnet mehrmals der Fall war. Im Mainnet sollte zwar alles angeblich stabiler laufen, aber es kann nicht schaden, wenn man für sich selbst ein Notfallszenario zur Hand hat. z.B. ein Backup-System mit identischer Software oder eben mit einem System eines der anderen Validator-Anbieter. Oder man weiß im Fehlerfall schnell, wie man einen Exit ausführt und seinen Validator absichtlich abmeldet (obwohl man dann auch noch zwei Jahre bis Phase #2 warten muss, aber zumindest hat man dann seine Einlagen vor noch mehr Verlust gesichert).

- "Only validators that actively participate in consensus, receive rewards. Those that are offline are penalized. The penalties for being offline are equal to the rewards for actively participating."
Wie bereits vor einem Monat geschrieben, werden für den aktiven Staking-Zeitraum ungefähr genausoviel Ethereum erwirtschaftet, wie man im selben Zeitraum durch Inaktivität verlieren würde, vgl auch: https://www.attestant.io/posts/understanding-validator-effective-balance/
Wenn man also zu lange inaktiv ist (Hardware-/ Software-Fehler, Internetrechnung nicht bezahlt, usw.) macht man Minus und kann auch unter die ursprünglichen 32 ETH fallen. Wenn man nur noch 15 ETH auf dem Staking-Konto hat, dann wird der Validator aus dem Netzwerk geworfen ("Involuntary Exit"). Mit seinem Seed/ Mnemonic sollte man sich dann aber ab Phase #2 seine übrig gebliebenen ETH wieder auszahlen lassen können.
Allerdings gibt es auch Situationen, in denen man deutlich mehr ETH verliert:

  -- Slashing-Bestrafung für Fehlverhalten:
Wenn sich der Validator nicht an die Staking-Regeln hält und wenn dieses Fehlverhalten durch einen Slasher bemerkt wird, dann bekommt der Validator eine Slashing-Bestrafung, bei der man 1 ETH oder mehr verlieren kann. Hierzu müsste man aber entweder seinen eigene Validator-Software schreiben. Oder es könnte auch die verwendete Software einen Fehler haben, so dass der eigene Validator unbeabsichtigt ein Fehlverhalten ausführt und somit eine Slashing-Bestrafung erhält.

  -- Inaktiv während "non-finality"-Modus:
Das Netzwerk braucht die korrekten Stimmen von mindestens zweidrittel aller aktivierten Validatoren, um die Blöcke korrekt zu finalisieren. In den letzten Wochen waren im Testnet viele der aktivierten Validatoren offline (=aktiviert aber inaktiv) und konnten somit nicht an der Konsensfindung teilnehmen. Das Testnet befand sich daher im "non-finality"-Modus ( https://gist.github.com/yorickdowne/ea9b18ac2b51a508080c9a810d978522 ). Dieser Modus tritt ein, wenn vier aufeinander folgenden Epochen (1 Epoche beinhaltete 32 Blöcke) nicht abgeschlossen werden können (da ja die korrekte Abstimmung von mindestens 2/3 aller aktivierten Validatoren nicht vorliegt).
Und im "non-finality"-Modus werden inaktive Validatoren besonders hart bestraft, um vermutlich diese inaktiven Validatoren möglichst schnell aus dem Netzwerk zu drängen um dann wieder ein ausreichendes Verhältnis an aktiven aktivierten Validatoren zu haben. Während mein Validator im Testnet einige Tage zwar aktiviert aber inaktiv war, da ich an meinem Setup herumexperimentiert hatte, habe ich nun in 10 Tagen Inaktivität ganze 7 ETH verloren. Im Mainnet sollte angeblich dieser "non-finality"-Modus nicht mehrere Tage vorliegen, da ja jeder Staking-Partner kein Interesse daran hat, sein Guthaben zu verlieren. Daher wird sich wohl im Mainnet jeder einzelne viel stärker dafür einsetzten, dass der eigene aktivierte Validator entweder dauerhaft aktiv ist, oder dass er dann eben einen Exit ausführt und das Staking-Netzwerk verlässt.

 

III. Meine bisherigen Erfahrungen auf dem Raspberry Pi:

Und hier noch ein Update zu meiner Installation auf dem Raspberry Pi. Zur Erinnerung mein letzter Stand:
Mit Ubuntu hatte der Prysm-Validator und Beacon-Chain wunderbar funktioniert.
Nur die Anbindung an einen eigenen ETH1.0-Node mittels Geth hatte nicht geklappt, da die Chain auf meinem Raspberry Pi niemals das Ende der Synchronisation erreichen konnte. Jokin hat es auf seinem Raspberry Pi geschafft es einzurichten, d.h. grundsätzlich sollte es funktionieren, nur bei mir läuft es eben nicht:

Am 14.10.2020 um 21:09 schrieb Jokin:

Mein ETH 1.0-Node ist nun synchronisiert und er bleibt mit der Blockchain synchron.

Eine 10-MBit/s-Leitung reicht locker aus.

Als Workaround verwendete ich daher einen kostenlosen ETH1.0-Node von infura.io und allem Anschein nach werde ich diesen Workaround auch ab Dezember im Mainnet verwenden.

Ich habe weiter verschiedene Dinge ausprobiert, aber alles ohne Erfolg:

- Raspbian statt Ubuntu:
Vor Kurzem hatte ich auf einer neuen SD-Karte nochmal komplett von vorne neu begonnen:
Dieses Mal wählte ich als Betriebssystem "Raspberry-Pi-OS" (ehemals "Raspbian") statt Ubuntu.
Dann habe ich erneut den Prysm-Validator und die Beacon-Chain eingerichtet, beides läuft auch grundsätzlich ganz OK (abgesehen von den üblichen Problemchen im Testnet).
Zum Schluss habe ich Geth installiert um die ETH1.0-Chain (Mainnet) zu synchronisieren, was aber wieder nicht geklappt hat. Es trat dasselbe Problem wie unter Ubuntu auf. Es liegt also nicht am Betriebssystem.

- SSD-Festplatte schnell genug:

Am 30.9.2020 um 00:41 schrieb bjew:

hast du schon mal geprüft, wie schnell deine SSD ist?

könnte sein, dass in deiner cmdline.txt (boot-Partition) so etwas vorstellen musst:

usb-storage.quirks=125f:a88a:u   - natürlich passend zu deinder ssd

 

Die SSD ist mit 230 MB/s eigentlich schnell genug. Habe trotzdem mal diese Einstellung ausprobiert, hat aber nichts geändert.

- Parity statt Geth:
Ich habe "OpenEthereum" (ehemals "Parity") installiert und versuchte damit erneut die ETH1.0-Mainnet-Chain zu synchronisieren. Aber auch hier kommt die Synchronisation der Blockchain nicht hinterher: Die Erzeugung neuer Blöcke im Mainnet läuft schneller als die Synchronisation auf meinem Raspberry Pi.

- Passive Kühlung für Raspberry Pi:

Am 29.9.2020 um 08:15 schrieb bjew:

Bin die Tage gerade dabei, mir nun auch einen solchen Kühlturm zu bauen: https://progpi.de/raspi4-passiv-gekuehlt/
Grundsätzlich reicht für die Sparvariante (d.h. auch ohne Gehäuse usw) nur ein Kupferzylinder (Durchmesser: 2cm; Länge: 5 cm; Preis: 7 €), den man auf die CPU stellt und auf den man dann optional auch noch einen LED-Kühlkörper (4 €) drauf legt, und schon fällt die Temperatur auch im Dauereinsatz von 70°C auf 50°C.
Bei Gelegenheit werde ich dann auch mal ein Foto hier posten, wenn alles fertig zusammen gebaut ist.
Aber trotz der niedrigeren Temperaturen konnte ich mein eigentliches Ziel nicht erreichen: Die ETH1.0-Blockchain synchronisiert weiterhin zu langsam.

- Raspberry Pi mit 8 GB statt 4 GB RAM:
Als letzte Lösung hatte ich mir einen Raspberry Pi mit 8 GB gekauft. Einfach das alte System heruntergefahren und die SD-Karte und SSD-Festplatte an den neuen Raspi angeschlossen und die Synchronisation erneut gestartet.... und allem Anschein nach hat das auch nichts gebracht. Habe abwechselnd nur Geth und nur Parity laufen lassen, aber Geth kommt nicht mit der Synchronisation hinterher. Parity ist nun etwas schneller, ich muss noch ein paar Tage abwarten wie hier die Zeiten werden.


Fazit:
Voraussichtlich werde ich mit folgendem Setup ab Dezember im Mainnet teilnehmen:
- Raspberry Pi 4 mit 8 GB RAM
- Betriebssystem = Raspbian
- ETH1.0-Client = infura.io
- ETH2.0-Client = Prysm
- Passive Kühlung durch selbstgebauten Kupfer-Kühlturm
- Notfallplan:
   -- Backup-System = Raspberry Pi 4 mit 4 GB RAM
   -- alternativ mit Ubuntu-Betriebssystem und eingerichtetem Prysm-Client
   -- für den Prysm-Client habe ich aktuell noch kein Backup -> im Falle eines dauerhaften gravierenden Software-Fehlers würde ich versuchen einen Voluntary Exit auszuführen.

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

Vielen Dank @Cookies statt Coins^^, @Jokin und @skunk für all eure Mühe ETH2 Beaconchain + Validator auf einem Raspberry Pi zum laufen zu kriegen. Als ich zum ersten mal vom ETH2 Staken gehört habe, dachte ich noch an eine EC2 Instanz in der AWS Cloud - umso erfreulicher das dies auch von daheim aus mit einem Raspberry PI möglich sein kann. Ich melde mich in den Tagen wieder, wenn ich mich ebenfalls an das Setup setzen werde (vielleicht sogar noch bis vor dem Startschuss).

@Cookies statt Coins^^ musst du ausser dem Port-Forwarding in deinem Router noch etwas anderes einstellen?

@Jokinbist du mit deinem Raspberry Pi Setup welches du auf der vorherigen Seite gepostet hast, voll zufrieden? Frag mich noch ob das von dir erwähnte Raspberry Pi Kit mit Gehäuse und Lüfter auch das Geld wert ist.

Bearbeitet von Carrot
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor einer Stunde schrieb Carrot:

@Cookies statt Coins^^ musst du ausser dem Port-Forwarding in deinem Router noch etwas anderes einstellen?

Ich habe nur das Port-Forwarding eingestellt für die hier zuvor erwähnten Ports. Mehr wird hier auch nicht erwähnt: https://docs.prylabs.network/docs/prysm-usage/p2p-host-ip#incoming-p2p-connection-prerequisites

(Und in den ersten Tagen hatte ich es auch ohne diese Port-Forwarding am Laufen und so weit ich mich noch dran erinnern kannte, hatte es so auch funktioniert. Das ist also scheinbar nur eine Verbesserung, damit es noch stabiler läuft, aber keine Pflicht)

Dann viel Erfolg mit dem Setup. Bei Fragen oder Problemen einfach melden 😉

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

vor 10 Stunden schrieb Cookies statt Coins^^:

Daher wird sich wohl im Mainnet jeder einzelne viel stärker dafür einsetzten, dass der eigene aktivierte Validator entweder dauerhaft aktiv ist, oder dass er dann eben einen Exit ausführt und das Staking-Netzwerk verlässt.

Das Problem im Testnet war ja nicht, dass Validatoren einfach offline waren. Meine Validatoren liefen durchgängig aber die Software ist einfach nicht stabil. Beta 0 und Beta 1 hatten da eine Reihe von unschönen Fehlern.

In der letzten Woche sieht es jetzt etwas besser aus. Ich bin aber noch vorsichtig und warte lieber ein paar weitere Versionen ab.

vor 10 Stunden schrieb Cookies statt Coins^^:

Die SSD ist mit 230 MB/s eigentlich schnell genug.

IOPS sind der Knackpunkt. Ich bin noch am überlegen ob ich eine handelsübliche m2 SSD nehme oder gleich eine Intel P4500.

Ich muss mich mal die Tage noch damit beschäftigen wie die ETH Rewards zu versteuern wären.

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

Wow das ging ja flott. Heute Abend eine neue Linux dist aufgesetzt und innerhalb von 2 Std. den Validator eingerichtet und die Görli-ETHs transferiert (bis auf das synchronisieren der Blockchain, das wird wohl noch bis morgen dauern).

@Cookies statt Coins^^ dein Notfall-Backup sieht ja vor, einen weiteren Pi mit 4GB einzusetzen falls der 8GB PI mal ausfällt. Ich würde mir noch Gedanken machen, wie ein Notfallplan ausssehen könnte während ich im Urlaub bin und nicht innerhalb weniger Stunden eingegriffen werden kann. Da erscheint es mir auch sinnvoll, einen weiteres Backup über AWS oder andere Cloud Computing Plattformen einzurichten um im Zweifelsfall von überall aus einen neuen Validator starten zu können. 

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

  • 2 Wochen später...

Hallo zusammen,

ich würde mich hier gerne einklinken... seit ein paar Tagen schon bin ich auf der Suche nach Anleitungen und Erfahrungsberichten was das Staken von Ethereum angeht.

Momentan versuche ich noch durch das sammeln von Informationen einen Plan zu erarbeiten welcher letztendlich umgesetzt werden soll... AWS habe ich von einem User gelesen wäre auch eine Überlegung, hat das denn schon mal einer versucht, und wenn ja mit welchen Parametern welchem Image etc. würdet ihr das umsetzen? mit welchen Kosten muss man rechnen? Gibt es überhaupt schon Erfahrungen damit?

Andererseits könnte ich mir das mir dem RaspberryPi auch gut vorstellen, ist hier schon jemand auf dem MainNet? die Anleitung auf Seite 1 bezieht sich wenn ich das richtig gelesen habe, bisher nur auf das Testnetz? 

Wenn man so allgemein liest das bisher erst 20% der erforderlichen Eth validiert sind, Frage ich mich, ist das Staken für die Masse vielleicht doch zu kompliziert?

Ich habe zum Glück jetzt dieses Forum und diesen Thread gefunden, und bin auch nicht ganz unerfahren, was das aufsetzen von z.b. Servern unter Linux anbelangt, aber ich finde dennoch, das das Thema doch recht kompliziert und komplex ist... Was sich daher vermutlich im geringen Interesse am Staken widerspiegelt? wie seht ihr das? ...wird sich die große Mehrheit der Ethereum Besitzer doch für den einfachen weg über die Börsen entscheiden? so denn dies in Absehbarer Zeit angeboten werden sollte? Habe gelesen BitcoinSuisse und Binance sind dran, das Staken über ihre Plattformen anzubieten, wahrscheinlich kostet das ordentlich Gebüren, daher wäre es auch super interessant einen Vergleich anzustellen eigenes Hosting vs Börse, welche Kosten/Nutzenvorteile hat das eigene betreiben des Servers/ welche Nachteile muss man in kauf nehmen....Strafen, HW Anschaffung, Erhaltung, Stromkosten etc. 

VG

 

 

 

 

 

 

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor einer Stunde schrieb Muesli2k:

AWS habe ich von einem User gelesen wäre auch eine Überlegung, hat das denn schon mal einer versucht, und wenn ja mit welchen Parametern welchem Image etc. würdet ihr das umsetzen? mit welchen Kosten muss man rechnen? Gibt es überhaupt schon Erfahrungen damit?

Blos nicht. Schau dir mal an was die großen Player dir für den Traffic in Rechnung stellen. Das dürfte teuer werden. Dann lieber Hetzner.

vor einer Stunde schrieb Muesli2k:

Andererseits könnte ich mir das mir dem RaspberryPi auch gut vorstellen, ist hier schon jemand auf dem MainNet? die Anleitung auf Seite 1 bezieht sich wenn ich das richtig gelesen habe, bisher nur auf das Testnetz?

Ich habe so meine Zweifel ob ein RaspberryPi genug Leistung hat. Davon unabhängig ist ETH2.0 derzeit noch zu instabil um damit ins Mainnet zu gehen. Ich hatte erst letzte Woche mit Prysm wieder einen wunderbaren Fehler, der im Mainnet so nicht passieren darf! Ich würde behaupten vom Mainnet sind wir noch einige Monate entfernt. Solange bleibe ich weiter im Testnet.

vor einer Stunde schrieb Muesli2k:

Wenn man so allgemein liest das bisher erst 20% der erforderlichen Eth validiert sind, Frage ich mich, ist das Staken für die Masse vielleicht doch zu kompliziert?

Kompliziert ist es überhaupt nicht. Die Bedienung des Launchpads ist eines meiner persönlichen Highlights. Damit werden sich noch einige Generationen an Software messen müssen. Benutzerfreundlicher geht es fast nicht mehr.

Das eigentliche Problem ist das fehlen eines geeigneter Software. Man hat einfach ein Datum fest gesetzt ohne mal die Entwickler oder die Anwender zu fragen. Es wurden ja nicht mal alle Features implementiert. Sicherheitsreleavante Funktionen wie Slashing sind nicht in allen Clients vorhanden. Solange das so ist werde ich wie gesagt noch ein paar Monate warten. Ich will als erstes ein stabiles release im Testnet sehen, dass alle wichtigen Features enthält und dann lassen wir das Teil mal 1 Monat laufen. Wenn es in der Zeit zu keinem Aussetzer kommt, dann bin ich bereit über Mainnet nach zu denken.

vor einer Stunde schrieb Muesli2k:

Ich habe zum Glück jetzt dieses Forum und diesen Thread gefunden, und bin auch nicht ganz unerfahren, was das aufsetzen von z.b. Servern unter Linux anbelangt, aber ich finde dennoch, das das Thema doch recht kompliziert und komplex ist...

Wie wäre es mit Docker Compose? Damit solltest du deine Testnet Node in kurzer Zeit an den Start bringen können. Ja das ist jetzt nicht unbedingt die einfachste Möglichkeit aber wenn man mit Docker umgehen kann, ist es die schnellste inklusive automatischem Start und automatische Updates.

vor einer Stunde schrieb Muesli2k:

daher wäre es auch super interessant einen Vergleich anzustellen eigenes Hosting vs Börse, welche Kosten/Nutzenvorteile hat das eigene betreiben des Servers/ welche Nachteile muss man in kauf nehmen....Strafen, HW Anschaffung, Erhaltung, Stromkosten etc. 

Da können wir aktuell nur Mutmaßen. Ich kann dir aber zum Vergleich einfach mal meine Kosten nennen.

Ich habe hier ein Ryzen mit 32GB RAM in einem schallgedämmten Gehäuse verbaut. Ursprünglich mit dem Ziel meine alten Festplatten an Storj zu vermieten. Das Teil hat komplett inklusive der kürzlich hinzugefügten 2 TB SSD um die 800€ gekostet. Diese Kosten kann ich bereits mit den Storj Nodes decken die ETH2.0 Node hatte ich zu diesem Zeitpunkt noch nicht eingeplant. Davon unabhängig ist die Rechnung aber recht einfach. 800€ auf 3 Jahre + 5€ Strom pro Monat (laut Messgerät) + 5€ Internet (Upgrade vom Standard Tarif den ich vorher ohnehin hatte). Ich muss somit 35€ pro Monat einnehmen. Halten die Festplatten für Storj länger als 3 Jahre, würde das meine Gewinn sogar weiter steigern. Das schwächste Glied in der Kette wäre vermutlich die SSD für die ETH2.0 Node. Glücklicherweise scheint ein Full Sync eine Frage von wenigen Tagen zu sein sodass ich es im Zweifel einfach darauf ankommen lassen kann. Steigt der Preis von ETH zu sehr, könnte ich mir aber auch eine zweite SSD im Raid 1 vorstellen. Das würde das Setup um weitere 240€ (40€ extra wegen mangelnder SSD Steckplätze -> Asus Hyper.

Damit hast du mal eine Hausnummer was sowas in etwa kostet. Ein RaspberryPi wäre zwar billiger aber wie gesagt habe ich da so meine Bedenken ob die Leistung ausreicht.

Edit: Bei Interesse kann ich mal aufschreiben welche Hardware ich hier genau verbaut habe. Vielleicht hilft das ja anderen ein vergleichbares System für ihre Zwecke zusammen zu stellen.

Bearbeitet von skunk
  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Danke skunk für die schnelle und sehr Ausführliche Antwort, das Thema: Docker Compose muss ich mir mal reinziehen, danke für den Hinweis.

Auch habe ich mich mit dem Launchpad bisher überhaupt noch nicht auseinander gesetzt, meine bisher mit Ethereum gesammelte Erfahrung beläuft sich aufkaufen, hoddln, kaufen kaufen kaufen... Ab und zu Trade ich andere Coins, aber verliebt habe ich mich in ETH. So das ich jetzt beschlossen habe, ich möchte tiefer in die Materie einsteigen...

Das Minen von Coins habe ich bisher auch nie in die Tiefe verfolgt, vielleicht wars ein Fehler.. aber da ich zu 95% bei Ethereum engagiert bin, auch die 32 ETH locker zusammen habe, muss ich jetzt halt mal schauen wie ichs konkret anstellen möchte, neben kaufen und halten, dem Netzwerk auch vielleicht mal etwas zurück zu geben :) 

Das mit dem Raspberry habe ich schon fast vermutet, es wäre zu schön gewesen wenn das so einfach geklappt hätte.. Ich muss aber auch sagen, ich habe hier ganz gute Voraussetzungen für größeres, nur was ich nicht wollte ist ein PC im haus stehen der 24x7 läuft.. Aber wozu hat mein ein 19" Rack, das sich bisher mit einem 48Port switch ziemlich einsam und unnütz vorkommt, im Keller stehen... 

Ich werd mir mal Gedanken machen, theoretisch müsste es ein ausrangierter ProLiant Server mit einem 4 oder 8 Kern Xeon doch auch tun, der hat wahrscheinlich die 20fache Leistung von so einem RB4..... Nur die SSDs, das ist echt ein Thema, die Server SSDs sind unbezahlbar, aber auch da findet sich auf SATA Basis sicher die ein oder andere günstige Alternative... Auch Strom (den erzeuge ich selbst) und Internet 500Mbit sollten passen :D

 

 

 

 

 

 

 

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 1 Stunde schrieb Muesli2k:

Nur die SSDs, das ist echt ein Thema, die Server SSDs sind unbezahlbar, aber auch da findet sich auf SATA Basis sicher die ein oder andere günstige Alternative...

SATA SSD dürfte zu wenig IOPS haben oder bei gleicher Leistung einfach teurer als m2 SSDs. Wenn du kein m2 Steckplatz frei hast, würde auch ein PCIe Slot funktionieren.

Ich habe jetzt eine Sabrent Rocket Q4 2TB bei ebay ersteigert. Die sollte mindestens so schnell sein wie meine alte Samsung EVO in meinem Desktop PC. Ich würde mal sagen alles ab Samsung EVO sollte locker reichen.

Bezüglich der Langlebigkeit wollte ich eher auf ein Raid 1 gehen und dann eventuell defekte SSDs einfach austauschen. Alternativ würde auch eine Intel P4500 SSD funktionieren. Gibt es bei ebay direkt aus China ebenfalls kostengünstig. Das sind dann Server SSDs mit einem u2 Anschluss. Adapterkarte auf PCIe gibt es für 15€. Verglichen mit den m2 SSDs ist die Intel nicht ganz so schnell dafür aber langlebiger.

So mal als kleiner Überblick.

  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 23 Minuten schrieb Muesli2k:

 

@skunkdu sagst mit ner SATA SSDs wirds zu langsam, mit wie vielen IOPS rechnest du ??

Ich bin auf dem Gebiet kein Experte. Ich weiß nur aus eigener Erfahrung, dass eine Samsung EVO ausreichend schnell ist und einige andere SATA SSDs nicht. Beim Vergleich SATA und m2 SSDs fällt auf, dass SATA bei gleicher Leistung teurer ist. Daher würde ich in jedem Fall zu einer m2 SSD raten auch wenn ich nicht sagen kann ob es auch mit einer SSD unterhalb einer Samsung EVO klappen würde.

vor 23 Minuten schrieb Muesli2k:

und wie groß soll die sein ??

Meine Geth node ist aktuell 300 GB groß. Ich habe noch nicht die Konfig optimiert aber ich glaube viel kleiner als 300 GB bekomme ich die am Ende nicht. Ich weiß nicht wie schnell die Blockchain aktuell wächst. Ich vermute mal eine 500 GB SSD wird in kurzer Zeit an ihre Grenzen stoßen. Eine 1 TB SSD sollte es schon sein. Neben Geth will ich aber auch noch Beacon, Validator und Slasher laufen lassen. Die dürften ebenfalls nicht wenig Platz verbrauchen. Außerdem gibt es bei größeren Festplatten auch gleich mehr Performance. Daher habe ich zur 2 TB SSD für 230€ gegriffen. Schau mal bei Ebay rein mit Lieferung aus Großbritannien. Da hatte ich meine günstig bekommen. Laut SMART Werte ist meine SSD neu und unbenutzt so wie das auch versprochen wurde.

@JokinIm Mainnet ist meine Geth Node aktuell mit sehr viel Traffic dabei. Ich denke aber das kann ich mit einer guten Konfig unterbinden.

Edit: Kommando Zurück Jokin. Ich hatte kurzzeitig volle Auslastung. Gemäß Docker stats hält sich die Summe weiterhin im Rahmen. Ich werde trotzdem mal mit den Einstellungen spielen und schauen was da noch so raus zu kitzeln ist.

Bearbeitet von skunk
Link zu diesem Kommentar
Auf anderen Seiten teilen

Kann man hier irgendwie einen Screenshot posten? Ich würde euch einfach gern mal mein Netdata Dashboard zeigen. Die Geth Node ist konstant bei 20-40% CPU und das bei 6 physischen bzw 12 logischen Kernen. Oben drauf soll dann noch Beacon, Validator und Slasher laufen. Das wird schon eine ordentliche Belastung werden. 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Nach 5 Stunden habe ich das hier an Traffic:

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT   MEM %               NET I/O             BLOCK I/O           PIDS
5d15e92ed547        eth_geth_1          8.26%               5.519GiB / 47GiB    11.74%              2.06GB / 5.37GB     58.7GB / 271MB      29

CPU hat sich etwas normalisiert und ist jetzt eher konstant bei 20% mit kurzen Ausschlägen jedesmal wenn ein Block kommt.

Zum Vergleich jetzt die gleiche Aktion mit optimierten Einstellungen:

      - --light.ingress=1
      - --light.egress=1
      - --light.maxpeers=0
      - --txpool.accountslots=1
      - --txpool.globalslots=1
      - --txpool.globalqueue=1

Damit bin ich nur noch bei 10% CPU Auslastung. Nach 3 Stunden habe ich das hier an Traffic:
 

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT   MEM %               NET I/O             BLOCK I/O           PIDS
4b79b35bc4d1        eth_geth_1          9.73%               3.937GiB / 47GiB    8.38%               703MB / 980MB       8.38GB / 3.17GB     28

Damit kann ich denke ich leben.

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

Am 22.11.2020 um 10:11 schrieb nixahnung:

Gibt es irgendwelche Risiken? 

Gibt es Risiken beim Staking in ETH 2.0?

Ja. Es gibt zwei verschiedene Arten von Strafen. Verringerung der Staking Rewards und Teilverlust der Einlage (Slashing). Während die Verringerung der Belohnung auch schon bei geringen Problemen ein Thema ist, etwa wenn der Validator offline ist, ist Slashing für den normalen Nutzer eigentlich kein Thema, da es grobes Fehlverhalten voraussetzt.

Wenn jedoch fehlerhafte Blöcke vorgeschlagen werden oder Transaktionen doppelt vorkommen ist die Einlage von 32 ETH in Gefahr.

Das größte Risiko wird in der Anfangszeit die Ungewissheit sein, ob Ethereum 2.0 stabil läuft, keine Bugs oder Hackingattacken möglich sind.

Auch der Umstand, dass man zwar von Ethereum 1.0 zu 2.0 wechseln kann, aber nicht umgekehrt birgt ein Risiko.

Der Markt wird das Risiko einschätzen, denn je höher das Risiko umso weniger Staker und um so höher die Rendite.

 

Quelle: https://www.blockchaincenter.net/ethereum/staking/

 

Bearbeitet von Amsi
Schriftgröße verkleinert
  • Love it 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 2 Wochen später...

Heute um 13:00 Uhr war der Startschuss der Beacon-Chain für das Mainnet!

Mein Raspberry Pi war live dabei:

MainnetLaunch.thumb.png.8dd8f15e178a72f224daece9f404cef4.png

 

Kurzer Zwischenstand nach einer Stunde Laufzeit:

Es läuft aktuell alles noch sehr stabil und ruhig.
Die CPU-Auslastung auf dem Raspberry Pi ist sehr gering, liegt nur bei 30% (und das obwohl 20% schon für den Parity-/OpenEthereum-Node verwendet werden, der im Hintergrund noch das ETH1.0-Mainnet synchronisiert). Teilweise mit Lastspitzen auf ca. 50% CPU-Auslastung.
Ich werde den Ressourcen-Verbrauch die nächsten Stunden und Tage verstärkt beobachten und dann nochmals ein Update posten.

Um ein wenig die Anonymität zu wahren, poste ich hier nun nicht mehr den Link zu meinem eigenen Validator. Aber man kann sich auf folgender Liste einen beliebigen aktiven Validator heraussuchen und den Verlauf der Staking-Erträge ansehen: https://beaconcha.in/validators
Dieser Link zeigt auch, dass aktuell 18.792 Validatoren aktiv sind und 2.271 sind inaktiv. Mal abwarten, wie sich die Zahlen in den nächsten Tagen noch ändern. Ich hoffe mal, mein Validator bleibt bei den aktiven Validatoren und wechselt nicht die Seite zu den Inaktiven^^.

Und mittlerweile hat mein Validator schon 10 Blöcke korrekt bestätigt ("Attestations = Attested") und noch keinen Block falsch oder zu spät bestätigt ("Attestations = Missed", was im Testnet bei zu hoher CPU-Auslastung geschah). Somit hat mein Validator in der ersten Stunden knapp über 0,0006 ETH eingenommen (ca. 0,30 €). Dieser Wert wird aber mit der Zeit immer weiter sinken, je mehr Validatoren sich am Staking beteiligen werden.

Ich werde morgen oder in den nächsten Tagen noch ein neues Update posten...

 

----------

Hier noch meine Antworten auf die vorherigen Posts:

Am 8.11.2020 um 22:09 schrieb Carrot:

 

@Cookies statt Coins^^ dein Notfall-Backup sieht ja vor, einen weiteren Pi mit 4GB einzusetzen falls der 8GB PI mal ausfällt. Ich würde mir noch Gedanken machen, wie ein Notfallplan ausssehen könnte während ich im Urlaub bin und nicht innerhalb weniger Stunden eingegriffen werden kann. Da erscheint es mir auch sinnvoll, einen weiteres Backup über AWS oder andere Cloud Computing Plattformen einzurichten um im Zweifelsfall von überall aus einen neuen Validator starten zu können. 

Ja, ich denke ein Backup auf einem Cloud-Anbieter könnte ne gute Alternative sein 👍.
Da kenne ich mich aber leider zu wenig aus. Wenn du einen guten und günstigen Anbieter hast, kannst du ja deine Erfahrungen hier teilen.
 

  

Am 19.11.2020 um 23:14 schrieb Muesli2k:

Andererseits könnte ich mir das mir dem RaspberryPi auch gut vorstellen, ist hier schon jemand auf dem MainNet? die Anleitung auf Seite 1 bezieht sich wenn ich das richtig gelesen habe, bisher nur auf das Testnetz? 

Ja genau, die Anleitung auf der ersten Seite bezog sich ursprünglich auf das Testnet. Aber dies ist ähnlich auf das Mainnet zu übertragen. Ich wollte mal eine Zusammenfassung schreiben, wenn dann alles im Mainnet stabil läuft. @Jokin hatte auch mal mit einer Zusammenfassung begonnen..

 

  

Am 20.11.2020 um 00:13 schrieb skunk:

Ich habe so meine Zweifel ob ein RaspberryPi genug Leistung hat.

Ich hatte zu Beginn auch meine Zweifel, aber mal abwarten, was die nächste Tage im Mainnet bringen... 😉

 

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

vor 6 Stunden schrieb Cookies statt Coins^^:

Somit hat mein Validator in der ersten Stunden knapp über 0,0006 ETH eingenommen (ca. 0,30 €).

Grob hochgerechnet dürftest du auf ca 5 ETH Gewinn pro Jahr kommen. Vermutlich etwas weniger je mehr Validatoren es gibt.

Hast du dir schon Gedanken darüber gemacht wie du die ETH in der Steuererklärung angeben willst?

vor 6 Stunden schrieb Cookies statt Coins^^:

Ich hatte zu Beginn auch meine Zweifel, aber mal abwarten, was die nächste Tage im Mainnet bringen... 😉

Der Spaß kommt ja erst noch wenn dann Epochen mangels ausreichender Teilnahme nicht mehr finalisiert werden. Was man so ließt soll Lighthouse der stabilste Client sein. Das wollte ich bei Gelegenheit nochmal im Testnet ausprobieren.

Was hast du an Alerts? Für Prysm gibt es ja einige sehr gute Alerts via grafana. Durch den Wechsel auf Lighthouse düfte das aber nicht mehr funktionieren.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Am 1.12.2020 um 14:23 schrieb Cookies statt Coins^^:

Ich werde morgen oder in den nächsten Tagen noch ein neues Update posten...

Echt stark, danke das du deine Erfahrungen mit uns teilst, finde ich wirklich sehr lehrreich...

 

Am 1.12.2020 um 14:23 schrieb Cookies statt Coins^^:

Ja genau, die Anleitung auf der ersten Seite bezog sich ursprünglich auf das Testnet. Aber dies ist ähnlich auf das Mainnet zu übertragen. Ich wollte mal eine Zusammenfassung schreiben, wenn dann alles im Mainnet stabil läuft.

Bitte unbedingt, ich bin gerade dabei mir Hardware zusammen zustellen und kann jeden Tipp, jede Anleitung dringend gebrauchen 🙂

Link zu diesem Kommentar
Auf anderen Seiten teilen

Am 1.12.2020 um 20:33 schrieb skunk:

Grob hochgerechnet dürftest du auf ca 5 ETH Gewinn pro Jahr kommen. Vermutlich etwas weniger je mehr Validatoren es gibt.

Kurzer Zwischenstand: Nach 3,5 Tagen hat mein Validator nun 0,057 ETH eingenommen. Ich gehe aber weiterhin davon aus, dass dieser Wert immer langsamer steigen wird, da immer mehr Validatoren einsteigen.

Im letzten Beitrag schrieb ich, dass in der ersten Stunde 18.792 Validatoren aktiv waren. Nun sind bereits 23.813 Validatoren aktiv, das ist ein Zuwachs von 25% in dreieinhalb Tagen. Und 7.782 sind aktuell noch in der Warteschlange ("Pending") und warten darauf, nach Ablauf einer vorgegebenen Wartezeit auch aktiviert zu werden. 
Zusätzlich waren damals zur ersten Stunde genau 2.271 Validatoren offline. Nun sind nur noch 210 aktivierte Validatoren inaktiv/ offline. Die meisten konnten daher ihre Startschwierigkeiten beheben.
Alle diese Zahlen stammen hier von dieser Seite: https://beaconcha.in/validators

Und 12 Validatoren mussten einen Exit ausführen, da diese eine Slashing-Bestrafung erhalten hatten. Im Prysm Discord-Channel wird vermutet, dass diese Slashing-Events dadurch entstanden sind, da (versehentlich) mit demselben Validator-Key zwei Validatoren parallel betrieben wurden. Evtl ist es daher keine gute Idee, ein Backup-System online laufen zu lassen, auf dem die Validator-Keys bereits vorkonfiguriert sind. Wenn dann versehentlich der Backup-Validator auch startet und der eigentliche Validator läuft auch noch mit demselben Validator-Key, dann erfolgt ein Slashing für diesen Validator.
Wenn ein Validator mit einem Slashing bestraft wurde, kann dieser nicht mehr am Staking teilnehmen und muss spätestens innerhalb der nächsten 36 Tage die Beacon Chain verlassen. Dazu verliert er zusätzlich noch kontinuierlich sein Guthaben, bis er schließlich die Blockchain verlassen hat (vgl. Kapitel "What happens after a slashing": https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50 ). Ich hoffe mal, dass ich nicht versehentlich für meinen Client ein solches Slashing-Event produziere, das wäre dann sehr ärgerlich. Die übrig gebliebenen Coins sind dann aber nicht verloren, man kann sie Mithilfe seines Seeds wieder abholen, sobald ETH2.0 vollumfänglich implementiert sein wird (also in ca. 2 Jahren).

 

Am 1.12.2020 um 20:33 schrieb skunk:

Hast du dir schon Gedanken darüber gemacht wie du die ETH in der Steuererklärung angeben willst?

Das mit den Steuern und dem Staking ist ja noch gar nicht geklärt, soweit ich weiß.
Ich müsste ja für jeden Staking-Ertrag, der ja alle paar Minuten erscheint, den aktuellen ETH-Kurs notieren um somit jeweils den Gewinn zum Erstellungszeitpunkt auszurechnen. Das ist aber manuell nicht machbar. Und ne Software, die das kann, ist mir auch nicht bekannt. Daher werde ich es einfach schätzen und die Staking-Erträge mit einem monatlichen Durchschnittlichen Kurswert von z.B. 500€ berechnen (abhängig davon, wie stark der Kurs noch steigt und fällt, wir sind ja erst am Monatsanfang). So würde ich dann auf ca. 250€ Staking-Gewinn für den Dezember kommen.
Diesen Gewinn würde ich dann, genauso wie die übrigen Krypto-Gewinne, in Anlage "SO" unter "Private Veräußerungen" eintragen. Da ich dieses Jahr fast keine Kryptowährungen verkauft habe, werde ich somit unterhalb des Steuerfreibetrags von 600€ bleiben. Ich glaube zwar, dass die Stelle "Private Veräußerungen" hier nicht ganz richtig ist, aber da es sich hier noch um einen kleinen Betrag handelt, finde ich, dass das für meine Steuererklärung noch OK ist. Dann im nächsten Jahr muss ich mir dann bessere Gedanken darum machen, da es sich dann um einen vierstelligen Betrag handeln dürfte, da muss es dann schon genauer und korrekter sein.

Fazit für 2020: Die Staking-Erträge sind noch sehr gering und die Steuerfrage ist eh noch nicht geklärt, daher lebe ich mit dem Risiko, dass ich das evtl. an der falschen Stelle eintrage. Besser an der falschen Stelle als gar nicht. Aber das ist meine persönliche Meinung. Wer mit größeren Summen handelt, sollte sich mehr Gedanken dazu machen. Das ist zumindest mein aktueller Plan für 2020. Wenn jemand ne bessere Idee hat, dann einfach melden. Und für 2021 gibt es dann hoffentlich genauere steuerliche Vorgaben..

 

Am 1.12.2020 um 20:33 schrieb skunk:

Der Spaß kommt ja erst noch wenn dann Epochen mangels ausreichender Teilnahme nicht mehr finalisiert werden.

Ja genau, die Gefahr besteht. Und wenn dann mein Client auch davon betroffen ist und keine Blöcke mehr attestiert, dann wird das sehr schnell sehr teuer, ich hab das im Testnet mitbekommen. Für den Fall bleibt dann als letzte Lösung nur noch ein Exit. Ich hoffe, dass dies in absehbarer Zeit nicht auftritt, so dass ich mir noch ein gutes Polster aufbauen kann, um im Fehlerfall gelassener reagieren zu können..

 

Am 1.12.2020 um 20:33 schrieb skunk:

Was hast du an Alerts? Für Prysm gibt es ja einige sehr gute Alerts via grafana.

Ich habe mir das Dashboard im Testnet angesehen, aber ich konnte damit nichts anfangen. Evtl. sollte ich mich nochmal damit beschäftigen.
Aber ich habe für mich eine eigene Lösung gebaut, welche aktuell noch sehr provisorisch ist und noch in den nächsten Wochen weiter ausgebaut werden muss:
Mein Alert sieht so aus:
- Auf einem zweiten Raspberry Pi läuft ein Python-Skript, welches im 5-Minuten-Intervall die Website https://beaconcha.in/validators zu meinem Validator ausliest.
- Sobald auf der Website der Hinweis erscheint, dass der Validator inaktiv ist, verschickt dieses Python-Skript eine E-Mail an mich.
- Ich muss mich dann zuhause vor den Laptop setzen und den Fehler analysieren und beheben, was aber bisher im Mainnet glücklicherweise noch nicht vorgefallen ist.
Der Plan ist, dieses Skript kontinuierlich zu erweitern, so dass ich auf diese Warn-Mails mit bestimmten Begriffen antworten kann, um mir z.B. die letzten Zeilen der Logdateien zuzusenden oder um einen Neustart des Dienstes (Validator, Beachon-Chain) oder einen Neustart des kompletten Raspberry Pi durchzuführen...

 

Am 2.12.2020 um 23:43 schrieb Muesli2k:

Bitte unbedingt, ich bin gerade dabei mir Hardware zusammen zustellen und kann jeden Tipp, jede Anleitung dringend gebrauchen 🙂

Bezüglich der Hardware reicht dieser Einkaufskorb, den @Jokin hier auf Seite 3 zusammengestellt hatte, ich habe fast dasselbe (abgesehen vom Gehäuse):

Jedoch empfiehlt @skunk eine M2 SSD-Festplatte. Würde ich mir nun auch kaufen, wenn ich nochmal von vorne beginnen müsste, aber hab dies noch nicht mit einem Raspberry Pi ausprobiert.

Und seit dieser Woche habe ich eine weitere Empfehlung:
Man sollte sich die ganze Hardware doppelt zulegen. Dann mein Raspberry Pi läuft nun im Mainnet, somit habe ich kein Testnet mehr.
Ich werde daher meinen alten Raspberry Pi, den ich eigentlich als Backup fürs Mainnet vorgesehen hatte, nun als Testumgebung verwenden. Bei Bedarf sollte es mit wenigen Eingriffen möglich sein, aus dem Testnet wieder einen aktiven Validator fürs Mainnet zu machen. Besonders muss ich aber dabei aufpassen, dass niemals mein Validator-Key zeitgleich auf zwei Raspberry Pi aktiv ist, sonst werde ich geslashed und darf dann für die nächste zwei Jahre nur noch von der Seitenlinie aus zuschauen...

Eine Testumgebung zusätzlich zum Mainnet-Raspberry-Pi finde ich besonders wichtig:
- Zum Einen wird es früher oder später wieder ein Testnet für die weiteren ETH2.0-Phasen geben. Auch die möchte man sich ja dann ausführlich anschauen, um Erfahrungen zu sammeln.
- Und außerdem hatte ich vor einigen Wochen/ Monaten im Testnet tatsächlich den Fehler, dass die von Prysm bereitgestellten Skripte kurzzeitig nicht mehr für den ARM-Prozessor des Raspberry Pi lauffähig waren. Daher möchte ich zukünftig jedes Update erstmal im Testnet auf den Test-Raspberry-Pi ausführen, bevor ich den Validator und die BeaconChain auf dem Mainnet-Raspberry-Pi aktualisiere.

 

Und bezüglich eines Updates bin ich noch auf der Suche nach dem besten Vorgehen:
Kurz nach dem Mainnet-Launch gab es ein erstes Update der Prysm-Software. Da ich noch keine Testumgebung aufgebaut hatte, habe ich zuerst den Slasher neugestartet, um nach dem Neustart automatisch das Update zu erhalten. Wenn es hier bereits zu Problemen gekommen wäre, hätte ich dann nicht weiter gemacht.
Anschließend mussten noch Beacon Chain und Valdiator neugestartet werden, damit diese nach dem Start ebenfalls die neue Software herunterladen und ausführen. Zusätzlich musste sich die Beacon Chain nach dem Neustart erst noch aktualisieren. Während des ganzen Vorgangs wird mein Validator als "offline" gewertet und kann keine Attestations ausführen.
Ich habe daher extra so lange gewartet, bis mein Validator gerade eine Attestation erfolgreich abgegeben hatte (erkennbar im Status "Attested" auf beaconcha.in), und habe dann beides fast zeitgleich neugestartet. Nach dem Neustart wurden automatisch die neuen Skripte herunterladen und beide gestartet. Da die Beacon-Chain noch sehr kurz war, war die anschließende Synchronisation in weniger als 30 Sekunden durch. Mein Valdidator war daher nur ca. 1,5 Minuten offline. Trotzdem hatte ich dann die nächste Attestation verpasst aufgrund dieses Updates. Eine verlorene Attestation ist noch vertretbar, trotzdem bin ich noch auf der Suche nach dem optimalen Vorgehen, um beim nächsten Update möglichst gar keine Attestation mehr zu verpassen. Vermutlich wird es  aber hierfür keine Lösung geben, da man den Zeitpunkt der Attestations nicht vorhersagen kann..

 

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

vor 10 Stunden schrieb Cookies statt Coins^^:

Das ist aber manuell nicht machbar. Und ne Software, die das kann, ist mir auch nicht bekannt.

Eine Software gibt es schon allerdings müsste man dafür trotzdem noch ein wenig scripten: https://beaconcha.in/api/v1/docs/index.html

Ich würde die Gewinne pro Tag aufsummieren da die Lizenz für das Steuerjahr in der Regel von der Anzahl an Transaktionen abhängig ist. Durch das aufsummieren sollte die Steuererklärung immer noch genau genug sein ohne dabei gleich Unsummen für die Berechnung der Steuerklärung auszugeben.

vor 11 Stunden schrieb Cookies statt Coins^^:

Diesen Gewinn würde ich dann, genauso wie die übrigen Krypto-Gewinne, in Anlage "SO" unter "Private Veräußerungen" eintragen.

Meines Wissens "Sonstige Einkünfte im Sinne des § 22 Nr. 3 EStG - einzutragen in Anlage SO - Zeile 8 -"

Eventuelle Kursschwankungen sind steuerfrei weil du die ETH selbst erzeugt und nicht angeschafft hast. Gilt soweit ich weiß allerdings auch für Verluste. Selbst wenn du die ETH verkaufen könntest, droht damit eine Steuerfalle. Da du sie nicht verkaufen kannst, droht die Falle erst Recht. Bei 4 stelligen Beträgen nächstes Jahr dürfte das noch nicht ins Gewicht fallen.

Sollte der ETH x10 hinlegen, sollten wir nochmal darüber reden welche Möglichkeiten wir haben das finanzielle Risiko inklusive der zu zahlenden Steuern zu minimieren. Ich kann nur aus Erfahrung sagen sei da ja Vorsichtig! Im Extremfall versaust du dir dein ganzes Leben! Ich entnehme deinen Ausführungen, dass du diesen Teil durchaus bedacht hast. In dem Sinne schreibe ich diese Zeilen eher für alle anderen Mitleser.

vor 10 Stunden schrieb Cookies statt Coins^^:

Im Prysm Discord-Channel wird vermutet, dass diese Slashing-Events dadurch entstanden sind, da (versehentlich) mit demselben Validator-Key zwei Validatoren parallel betrieben wurden.

Dafür gibt es eine Lösung. Man kann durchaus mehrere Validatoren parallel laufen lassen muss aber vor dem veröffentlichen eines neuen Blocks immer den eigenen Slasher um Erlaubnis fragen. Schmiert ein Validator ab, würde der zweite Validator automatisch übernehmen. Ausprobieren würde ich das allerdings noch nicht. Ich vertraue dem Lighthouse und dem Prysm Slasher nur so weit wie ich sie werfen kann.

Ich habe jetzt auf Lighthouse umgestellt und werde damit noch ein wenig im Testnet rumspielen.

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

Steuern auf Staking-Erträge:

Das mit den Steuern ist ein wichtiges Thema, über das ich mir bisher nur sehr grob Gedanken gemacht hatte und mir Details dazu erst nächstes Jahr machen wollte, wenn es für mich relevant wird. Denn zum Einen gibt es Stand heute noch keine genauen gesetzlichen Regeln dazu, und zum Zweiten könnte es immer noch passieren, dass mein Validator ausfällt und ich das Staking bald wieder beende, somit wären dann auch alle Gedanken über die Besteuerung überflüssig.

Aber für den Fall, dass ich meinen Validator die nächsten Jahre erfolgreich weiter betreibe und auch für den Fall, dass der ETH-Wert sich in den nächsten Jahren vervielfacht, ist es vorteilhaft, alle relevanten Infos jetzt schon im Vorfeld zu sammeln.

Hier im Forum gibt es bereits die Staking-Steuer-Thread aus dem Jahr 2019:

Meine letzte Aussage war somit falsch.
Für die Staking-Einnahmen gibt es nur einen Grundfreibetrag  von 256€ (also kein Freibetrag vom 600€)
Wenn der ETH-Kurs bis zum Jahresende noch stark steigt, besteht die Gefahr, dass ich diesen Wert überschreite, und dann müsste ich auch bereits für dieses Jahr meine Staking-Einkünfte im Detail berechnen und korrekt angeben.

Dies kann man auch hier nachlesen: https://cryptotax.io/staking-und-die-steuer/
Nach aktueller Gesetzeslage ist es scheinbar so, dass ich die Coins nur zum Zeitpunkt des Erhalts des Staking-Rewards versteuern muss, aber nicht, wenn ich diese dann z.B. in 2 Jahren verkaufe. Der Verkauf ist dann scheinbar steuerfrei: "Da die gestakten Coins jedoch durch eigene Leistung erzeugt und somit nicht entgeltlich erworben wurden, kann kein privates Veräußerungsgeschäft i.S.d. § 23 EStG vorliegen."

Ein konkretes Beispiel mit folgenden Extremwerten:
Sehr positiv gerechnet erwirtschafte ich im Jahr 2021 genau 5 ETH durch das Staking. Der Kurs hat sich jedoch verzehnfacht, so dass ein ETH durchschnittlich 5.000€ wert sein wird. Ich hätte somit 25.000€ (=5*5000€) erwirtschaftet und müsste diese in der Steuererklärung für 2021 angeben. Ich rechne im Schlechtfall, dass ich darauf 50% Steuern bezahlen muss, also muss ich für 2021 ca 12.500€ an Steuern nachbezahlen. Jedoch kann ich für die nächsten zwei Jahre keine der erwirtschafteten ETH verkaufen, da ein Handel erst mit Phase 2 möglich sein wird (in ca. 2 Jahren, oder später??).
Ich brauche also einen Puffer, also eine ausreichenden Menge an anderen ETH, die noch auf der 1.0-Chain enthalten sind, die ich bei Bedarf verkaufen kann. (Natürlich muss ich mir diesen Puffer schon vor über einem Jahr zugelegt haben, denn sonst fallen beim Verkauf wieder zusätzliche Steuern an, die hier in diesem Beispiel nicht berücksichtigt sind.)
Aber wie viel Puffer brauche ich maximal? Wenn ich davon ausgehe, dass es noch 2 Jahre dauert bis Phase 2 kommt (oder zur Sicherheit im Schlechtfall mit 4 Jahren rechnen), und wenn ich pro Jahr maximal 5 ETH (zu maximal 50%) versteuern muss, dann bräuchte ich für die nächsten vier Jahre einen Puffer von insgesamt 10 ETH (=4Jahre * 5 ETH/Jahr *50%), um immer genügend ETH zu haben, um damit die beim Staking anfallenden Steuern zu bezahlen.
Jedoch gibt es auch noch die Gefahr der starken Kursschwankung, im vorherigen Beispiel könnte dies so aussehen:
Im Jahr 2022 fällt dann der ETH-Wert wieder zurück auf 500€ (oder auch auf Null Euro). Da ich erst im Jahr 2022 die Steuererklärung für 2021 mache, muss ich in 2022 noch 12.500€ an Steuer fürs vorherige Jahr nachzahlen. Ich habe mir zwar für dieses Steuerjahr 2,5 ETH als Puffer zurück gelegt, aber diese sind nun Null Euro wert.
Daher darf ich nicht den Fehler machen, und mit dem Verkauf der gestakten ETH bis zum Zeitpunkt der Steuererklärung warten, sondern müsste im Optimalfall monatlich die Menge meiner gestakten ETH verkaufen (welche optimalerweise bereits steuerfrei sind, da ich diese schon länger als 1 Jahr halte). Und den durch den Verkauf eingenommenen Geldwert muss ich für die Steuer in Euro zurücklegen.

Fazit:
Jenachdem, wie stark man mit der Gefahr eines starken Kurseinbruchs rechnet, sollte man monatlich einen gewissen Teil (0-50%) der gestakten ETH aus einem zuvor angelegten Puffer verkaufen und dieses Geld unangetastet auf einer Bank deponieren, um nicht in die Steuerfalle zu laufen. 
Dann, nachdem auch Phase 2 eingeführt wurde, brauche ich keinen Puffer mehr und kann monatlich bis zu 50% meiner gestakten ETH direkt verkaufen und dieses Geld für die Steuer zurücklegen. Der Verkauf dieser gestakten ETH sollte dann hoffentlich noch steuerfrei bleiben (wenn sich bis dahin das Gesetz nicht ändern sollte).

@skunk: Siehst du das genauso, oder habe ich hier noch einen gedanklichen Fehler?

 

Berechnung des Staking-Rewards (für die Steuererklärung):

Nun zur Frage, wie man den Staking-Reward für die Steuererklärung ermittelt. Dazu fallen mir aktuell zwei Möglichkeiten ein:

Bachonch.in-API:

Die API-Befehle von Beaconcha.in habe ich auch schon gesehen. Leider finde ich den Funktionsumfang (noch?) etwas gering, man muss etwas mehr Arbeit rein stecken um die gewünschten Infos zu erhalten.
Wenn ich dich richtig verstanden habe, dann möchtest du die Staking-Erträge pro Tag ermitteln und diese dann vermutlich mit dem tagesaktuellen ETH-Kurs multiplizieren.

  • Ich müsste also täglich mit folgendem Befehl die aktuelle Balance ermitteln (hier am Beispiel von Validator #00001): https://beaconcha.in/api/v1/validator/1
  • Dann berechnet ich die Differenz zum Vortag um zu erkennen, wie viel mein Validator für den aktuellen Tag eingenommen hat
  • Dann multipliziere ich diesen Wert mit dem aktuellen ETH-Kurs (evtl. kann man diesen aus Coinmarketcap abgreifen)

Nachteile dieses Vorgehen:

  • Tagesaktuelle Schwankungen am ETH-Kurs könnten das Ergebnis verfälschen. Aber wird sich dann hoffentlich über die Laufzeit ausgleichen, mal ist der Wert zu hoch und mal zu niedrig. Die Frage ist, ob das Finanzamt mit einem Tagesdurchschnittswert leben kann, oder ob besser auf die Minute genau der Staking-Gewinn mit dem aktuellen Kurs verrechnet werden soll. Dies wäre theoretisch auch möglich, dann wird das Skript einfach minütlich ausgeführt und nicht täglich
  • Wenn mein Skript mal abstürzt brauche ich die Möglichkeit, nachträglich die historischen Werte einzulesen. Dies wäre mit folgendem Befehl für die letzten 100 Epochen möglich: https://beaconcha.in/api/v1/validator/1/balancehistory
    Wenn man davon ausgeht, dass eine Epoche ca 6 Minuten dauert, dann kann ich maximal die Werte der letzten 10 Stunden nachladen. (Ich lasse auch andere kleine Skripte durchgängig laufen und habe schon mal längere Ausfallzeiten, wenn ich dies nicht immer sofort mitbekomme).

=> Somit finde ich diese Lösung über die Bachonch.in-API aktuell nicht zielführend, da ich nur eine Historie der letzten 100 Epochen habe.


Auswertung Validator-Logdatei:

In der Logdatei des Validator findet man folgende Zeile, wenn dieser eine Attestation macht:

time="2020-12-06 14:10:35" level=info msg="Previous epoch voting summary" correctlyVotedHead=true correctlyVotedSource=true correctlyVotedTarget=true epoch=1134 inclusionDistance=1 inclusionSlot=36310 newBalance=32.081088157 oldBalance=32.081019711 percentChange="0.00021%" percentChangeSinceStart="0.24731%" prefix=validator pubKey=0xXXXzennsiertXXX startBalance=32.00194481

(Zur Wahrung der Anonymität habe ich meinen PublikKey in der Logdatei zensiert)

Hier in der Logdatei findet man immer jeweils die aktuelle Balance. Wenn der Validaor immer fleißig die Logdatei mitschreibt, dann kann ich bei Bedarf auch ein komplettes Jahr zurück gehen und die Staking-Erträge nachträglich berechnen.
Das einzige, was ich hier noch brauche, ist der aktuelle ETH-Kurs. Gibt es eine Möglichkeit, diesen kostenlos im Nachhinein für einen gewünschten Zeitpunkt (auf den Tag genau oder auf die Minute genau) zu ermitteln? Falls es dies nicht gibt, dann müsste ich mir jetzt schon ein Skript schreiben, welches mir minütlich den aktuellen ETH-Kurs ermittelt und diesen in eine Datei wegschreibt.
Somit hätte ich dann alle Informationen, um die Staking-Gewinne für das Finanzamt zu ermitteln. Oder habe ich etwas vergessen?

Fazit:
ich würde mir ein Skript schreiben, welches mir nachträglich aus der Logdatei die Staking-Gewinne ermittelt. Vorausgesetzt ist, dass das Logging aktiviert ist und dass ich jeweils irgendwoher den damaligen ETH-Kurs noch habe.

 

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

vor 3 Minuten schrieb Cookies statt Coins^^:

@skunk: Siehst du das genauso, oder habe ich hier noch einen gedanklichen Fehler?

Ja genau das ist auch mein Stand.

vor 7 Minuten schrieb Cookies statt Coins^^:

Wenn ich dich richtig verstanden habe, dann möchtest du die Staking-Erträge pro Tag ermitteln und diese dann vermutlich mit dem tagesaktuellen ETH-Kurs multiplizieren.

Die Multiplikation dürfte unnötig sein. Ich muss nur die Summe an Coins ermitteln. Der Tageskurs und die Multiplikation übernimmt üblicherweise die Steuersoftware.

vor 15 Minuten schrieb Cookies statt Coins^^:

Auswertung Validator-Logdatei:

Eigentlich sollte die Beacon Node ja eine Art Full Node sein, die die komplette ETH2 Blockchain abspeichert. Fraglich ist nur ab wann die ETH2 Node mit dem Pruning anfängt. Das könnte uns ein Strich durch die Rechnung machen. Für Lighthouse würde der Spaß dann hier losgehen: https://lighthouse-book.sigmaprime.io/api.html

Prysm hat ebenfalls eine API.

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.