Ethereum-2.0-Staking auf Raspberry Pi

[Jokin]

... wechselnde IP-Adressen sind kein Problem für den Node, oder?

[Hering]

vor 16 Stunden schrieb Jokin:

Gibt es hier stille Mitleser, die auch mitmachen wollen

Joo eigentlich schon ... Im Herbst und Winter ist da die richtige Zeit für. 

[skunk]

Am 27.9.2020 um 17:57 schrieb Jokin:

Was hältst Du denn von dem Einkaufskorb? Sollte eigentlich passen, oder?

Für Testnet ja. Für das Mainnet später ist es fraglich ob jede noch so langsame SSD ausreicht. Meiner Erfahrung nach ist eine M2 SSD notwendig sonst reicht es nicht für eine ETH Node. Ich würde ähnliche Performance Ansprüche von einem ETH2.0 Validator erwarten.

vor 16 Stunden schrieb Jokin:

Gibt es hier stille Mitleser, die auch mitmachen wollen?

Mitmachen wobei? Bei ETH2.0? Da wirst du hier auch unter den aktiven Mitlesern genug finden  

Bearbeitet 28. September 2020 von skunk

[Jokin]

vor 7 Stunden schrieb skunk:

Für Testnet ja. Für das Mainnet später ist es fraglich ob jede noch so langsame SSD ausreicht

Das hab ich gestern auch gelesen.

Wer mit einem Raspi startet und früh ins Mainnet wechselt und damit 32 ETH in den SmartContract schiebt könnte überrascht werden, dass die späteren Mainnetanforderungen mit einem Raspi nicht erfüllbar sind. Seine ETH liegen dann wohl bis zur Phase 2 fest.

Ein gewisses Risiko ist schon dabei. Zudem muss man wohl auch eine ausreichende Verfügbarkeit haben, hierbei interessiert mich am meisten die Frage: "Wie verliere ich 32 Görli-ETH am Schnellsten?" Was muss man falsch machen um sein Vermögen zu schrumpfen? 

vor 7 Stunden schrieb skunk:

Mitmachen wobei? Bei ETH2.0? Da wirst du hier auch unter den aktiven Mitlesern genug finden  

Mitmachen beim Aufbau eines eigenes Validators und herausfinden welche Probleme auftauchen könnten.

Ich bin mir sicher, dass es einige hier mit Hunderten ETH gibt, die ihre ETH zum Staken keiner Exchange anvertrauen möchten sondern selber im Besitz ihrer Keys bleiben möchten.

Gleichzeitig werden diese Leute nicht ihr gesamtes Guthaben in Phase0 oder Phase1 festsetzen. Bis Phase2 kann das noch locker ein paar Jahre dauern.

vor 6 Stunden schrieb bjew:

ich hatte kürzlich den Raspi4 mehrere Tage mit 100% Auslastung laufen, ohne Kühlkörper und Lüfter - unter 80°  - ohne Probleme, der regelt ja selbst etwas runter.

Besser und sicherer ists allerdings mit ...

Danke für die Info! Ich werde auch auf passive Kühlung gehen mit dem Conrad-Kühlkörper.

Ich stecke die nächsten Tage in einem anderen Projekt fest. Ab 6.10. rum sollte ich den Kram zu Hause haben und dann erstellen wir die Dokumentation.

 

[Jokin]

Ich hab mal von meinem anderen Raspi 4 den Lüfter abgezogen und mir die Temperatur angeschaut - scheint auch ohne zu gehen wenn die Last nicht zu groß ist.

Daher versuche ich es nun mit einem passiven Gehäuse und wenn das nicht klappt, dann gibt's halt später den Lüfter oben drauf, der den Kühlkörper runterkühlt.

[Cookies statt Coins^^]

Am 28.9.2020 um 05:54 schrieb Jokin:

Oh, Du hast nichtmal einen passiven Kühler drauf?

Hast Du mal die Temperatur geprüft? Eventuell läuft der zu heiß.

Hmm, bei genauer Betrachtung der CPU-Temperatur könnte das tatsächlich auch der Flaschenhals sein, ich habe mal folgendes ausprobiert:

Nur für den ETH_2.0-Node alleine ist nicht zwingend eine Kühlung notwendig. Zumindest wenn man nur den Beacon-Node mit Validator und Slasher betreibt, dann verbraucht mein Raspberry Pi insgesamt auch nur 10-20% CPU, d.h. 80% Leerlauf. Die CPU-Temperatur pendelt dabei ohne Kühlung zwischen 53-65°C. Der Stromverbrauch liegt bei ca. 5 Watt. Soweit ist alles gut, daher hatte ich zu Beginn das Thema "Kühlung" erst mal nach hinten verschoben.

Aber sobald man dann auch zusätzlich versucht, das Ethereum Mainnet zu synchronisieren, dann geht der Raspberry Pi in die Knie. Die CPU-Auslastung steigt auf durchgängig 80% und auch die Temperatur steigt auf 77-80°C. Teilweise mit vereinzelten Ausschlägen auf bis zu 83°C. Auch der Stromverbrauch steigt auf ca. 8,5 Watt.
Und in dem Zustand arbeitet dann auch mein Validator nicht mehr korrekt und schafft es nicht mehr sämtliche Blöcke korrekt zu validieren. Vielleicht ist es grundsätzlich keine gute Idee, beides (ETH_1.0-Node und ETH_2.0-Staking-Node) auf demselben Raspberry Pi zu betreiben. Vor allem ohne gute Kühlung.

Aber auch, wenn ich den ETH_1.0-Mainnet-Note alleine betreibe (ohne ETH_2.0-Beacon Node usw), dann pendelt die Temperatur aktuell zwischen 73-75°C und die CPU-Auslastung liegt bei ca. 60%. Das sollte eigentlich noch OK sein, trotzdem schaffe ich es nicht die Blockchain zu synchronisieren..

-> Ich werde demnächst mal einen provisorischen Ventilator aufstellen und schauen, ob das dann bei niedrigeren Temperaturen besser läuft mit der Synchronisation..

 

Am 28.9.2020 um 10:03 schrieb Jokin:

.. wechselnde IP-Adressen sind kein Problem für den Node, oder?

Ich habe keine feste IP-Adresse bei mir. Habe auch nirgends gelesen, dass eine feste IP als Voraussetzung benötigt wird.

 

Am 28.9.2020 um 22:49 schrieb skunk:

Für Testnet ja. Für das Mainnet später ist es fraglich ob jede noch so langsame SSD ausreicht. Meiner Erfahrung nach ist eine M2 SSD notwendig sonst reicht es nicht für eine ETH Node. Ich würde ähnliche Performance Ansprüche von einem ETH2.0 Validator erwarten.

Und ich dachte, meine SSD-Festplatte wäre schon sehr schnell^^. In allen Tutorials, die ich gelesen hatte, wurde immer nur eine SSD-Festplatte im allgemeinen empfohlen. Von einer M.2-SSD lese ich nun zum ersten mal. Das wäre aber auch eine gute Idee das mal auszuprobieren..

Allerdings z.B. in diesem Tutorial vom Februar 2020 wird eine Lese-/Schreibgeschwindigkeit von mindestens 50 MB/s empfohlen, welche ich mit den Standard-SSDs locker erreiche (bei mir > 200MB/s):
"Below 50MB/s (write/read), I wouldn't recommend trying to syncing a Geth node because you might never be able to reach the head and complete the sync." (vgl. Kapitel 7. "Disk performance checkpoint": https://kauri.io/running-an-ethereum-full-node-on-a-raspberrypi-4-m/9695fcca217f46feb355245275835fc0/a)

 

vor 18 Stunden schrieb Jokin:

Wer mit einem Raspi startet und früh ins Mainnet wechselt und damit 32 ETH in den SmartContract schiebt könnte überrascht werden, dass die späteren Mainnetanforderungen mit einem Raspi nicht erfüllbar sind. Seine ETH liegen dann wohl bis zur Phase 2 fest.

Ein gewisses Risiko ist schon dabei. Zudem muss man wohl auch eine ausreichende Verfügbarkeit haben, hierbei interessiert mich am meisten die Frage: "Wie verliere ich 32 Görli-ETH am Schnellsten?" Was muss man falsch machen um sein Vermögen zu schrumpfen? 

Ja das stimmt, man geht ein gewisses Risiko ein. Wenn das alles unbeobachtet laufen lässt und im Fehlerfall nicht eingreift, dann kann man im schlimmsten Fall die Hälfte seiner 32 ETH verlieren, also nach heutigem Stand 5.000€. Daher muss natürlich alles reibungslos funktionieren. Allerdings hat man aktuell auch genügend Zeit, jetzt schon seine System entsprechend einzurichten oder bei unlösbaren Problemen im Betrieb einen Exit durchzuführen.

Grundsätzlich wird es so funktionieren (vgl https://www.attestant.io/posts/understanding-validator-effective-balance/):

- Man braucht genau 32 ETH, um initial den Validator zu aktivieren und um sich somit am Staking zu beteiligen. Wenn sich der Validator aber nicht korrekt am Staking beteiligt, da er z.B. offline ist, dann bekommt er ein Guthaben abgezogen für nicht korrekt attestierte Blöcke (=penalties/ Bestrafungen). Durch zu viele Abzüge (z.B. dauerhaft inaktiv) kann man auch unter diese initialen 32 ETH fallen. Trotzdem kann man sich dann noch weiterhin am Staking beteiligen, um die verlorenen ETH wieder hereinzugewinnen.

- Wenn das Staking-Guthaben (="effective Balance") unter 32 ETH sinkt, dann sinkt mit der Zeit auch die Menge an ETH, die man durch die Bestrafungen verliert, aber auch die man durch erfolgreiches Staking wieder dazu gewinnen kann. Die Schritte für Gewinn und Verlust werden also kleiner, je weniger Guthaben ("effective Balance") man hat, so dass man dann hoffentlich nicht zu schnell ins Minus gerät. Man braucht dann aber auch entsprechend länger, um sich aus dem Minus wieder hochzuarbeiten, um die 32 ETH zu erreichen. ("attesting with a higher balance provides larger rewards and penalties than attesting with a lower balance."). Wie das Steigen und Fallen in Schritten genau funktioniert, muss man sich in obigen Link in Ruhe mal durchlesen.

- Wenn gar nichts mehr klappt und man nur noch Minus macht, dann kann der Validator jederzeit auch einen freiwilligen Exit ausführen: https://docs.prylabs.network/docs/wallet/exiting-a-validator/
Somit entgeht man z.B. einer weiteren Bestrafung für noch längere Inaktivität. Allerdings hat dieser Exit zwei Nachteil:
1.) Wenn ein Validator ausgestiegen ist, dann kann dieser nicht mehr aktiviert werden. Man müsste mit dem übrig gebliebenen Guthaben wieder einen neuen Deposit-Vertrag für einen neuen Validator eingehen.
2.) Aktuell kann man aber auf dieses ETH-Guthaben erst wieder in ca. 2Jahren zugreifen, wenn das ETH_2.0-Mainnet vollumfänglich gestartet ist. Das hat auch damit zu tun, dass die Überweisung der 32 ETH von ETH_1.0 auf die ETH_2.0-Depostit-Adresse eine Einbahnstraße ist: Man kann zwar ETH von ETH_1.0 auf ETH_2.0 übertragen, aber nicht mehr zurück. Daher kann man dann erst wieder mit ETH_2.0-Mainnet auf dieses Guthaben zugreifen um sich dann mit einem neuen Validator erneut zu beteiligen.
Man sollte hier also nicht Geld investieren, welches man kurzfristig wieder benötigen könnte. Und ehrlich gesagt befürchte ich, dass die 2 Jahre nicht eingehalten werden, denn ursprünglich wollte man schon im Januar 2020 mit Phase 0 im Mainnet beginnen... (alte Quelle vom Juni 2019: https://www.theblockcrypto.com/linked/27639/ethereum-2-0-phase-0-set-to-launch-on-3rd-january-2020)

- Bei weniger als 16 ETH im Staking-Guthaben wird ein Zwangs-Exit durchgeführt: "On the other hand, if your validator is affected by penalties and its balance drops to or below 16 ETH, it triggers what is called a forceful (or involuntary) exit." (vgl. Kapitel "The Honest Validator" https://codefi.consensys.net/blog/rewards-and-penalties-on-ethereum-20-phase-0). Man kann also maximal 16 ETH verlieren (aktuell 5.000€).

- Und zusätzlich zu den hier beschriebenen Penalties/ Bestrafungen gibt es auch noch das Slashing, wodurch man seine ETH besonders schnell verlieren kann. Während man bei den Penalties nur sehr kleine Mengen an ETH verliert, verliert man bei einem Slashing-Event mindestens 1 ETH, in Extremfällen verliert man sogar sein volles Guthaben. Eine solche Slashing-Bestrafung ist für solche Validatoren vorgesehen, die sich nicht an die Spielregeln halten (z.B. doppelte Votes) oder die versuchen, das Netzwerk anzugreifen (vgl.  https://blog.ethereum.org/2020/01/13/validated-staking-on-eth2-1-incentives/).
Wenn man also nicht gerade mit krimineller Energie seine Validator-Software selbst schreibt, mit dem Ziel die Regeln zu umgehen, dann sollte es im Normalfall nicht passieren, dass der eigenen Validator eine Slashing-Bestrafung erhält.
Allerdings ist es vor Kurzem im Testnet geschehen, dass aufgrund eines Softwarefehlers ein Großteil der Prysm-Validatoren eine Slasher-Strafe erhalten hatten. Softwarefehler sind also auch nie auszuschließen, vgl dazu meinen vor einem Monat geposteten Link zum Ausfall des Testnets: https://medium.com/prysmatic-labs/eth2-medalla-testnet-incident-f7fbc3cc934a)

 

vor 16 Stunden schrieb bjew:

hier nochmal zum Lüfter thema an @Jokin

und gerade gefunden  https://progpi.de/raspberry-pi-4-cooler-temperature/

Sehr cool, die Idee mit dem Kupferzylinder sagt mir aktuell am meisten zu, wenn das wirklich so gut funktioniert wie hier beschrieben ist..

Bearbeitet 29. September 2020 von Cookies statt Coins^^

[Jokin]

Am 28.9.2020 um 22:49 schrieb skunk:

Für Testnet ja. Für das Mainnet später ist es fraglich ob jede noch so langsame SSD ausreicht. Meiner Erfahrung nach ist eine M2 SSD notwendig sonst reicht es nicht für eine ETH Node. Ich würde ähnliche Performance Ansprüche von einem ETH2.0 Validator erwarten.

Danke!

Ich habe nun das erste Mal von "M2" gehört und nach bisschen Recherche sieht das so aus:

USB 3.0 kann 4,8 GBit/s
SATA kann 6 GBit/s

M2 kann deutlich mehr, aber wenn wir einen Raspi nutzen ist nicht SATA der Bottleneck sondern die USB-Schnittstelle.

[skunk]

vor 2 Stunden schrieb Jokin:

Danke!

Ich habe nun das erste Mal von "M2" gehört und nach bisschen Recherche sieht das so aus:

USB 3.0 kann 4,8 GBit/s
SATA kann 6 GBit/s

M2 kann deutlich mehr, aber wenn wir einen Raspi nutzen ist nicht SATA der Bottleneck sondern die USB-Schnittstelle.

IOPs sind wichtiger.

Das Problem bei einer ETH Node ist schlicht die Zeit um eine Datei zu lesen und zu schreiben. Eine HDD wäre schnell genug wenn die ETH Node große Dateien am Stück lesen und schreiben würde. Tut sie aber nicht. Eine ETH Node arbeitet mit kleinen Dateien und dann eben sehr viele davon. Genau an der Stelle versagt dann die HDD und auch nicht jede SSD ist dazu in der Lage. Vermutlich dürfte es inzwischen auch unter den SATA SSDs einige geeignete Modelle geben. Ich würde trotzdem zu m2 greifen einfach weil ich für wenig Geld die beste Leistung haben möchte.

Ich werde erstmal mit einer HDD starten und mal schauen wie gut ZFS damit zurecht kommt. Ich habe eine billige aber kleine SSD als ZFS write cache. Alle 5 Sekunden werden die Daten, die in den Write Cache geschrieben wurden auf die HDD verschoben. Der Trick dabei ist, dass das dann sequentiell passiert. Random write auf die SSD aber sequentiell kopiert auf die HDD. Das sollte sie dann mit ausreichend Performance hin bekommen. Beim Read hält ZFS einfach Daten, die häufiger angefragt werden im RAM. Anfangs sollte die ETH Node also langsam sein aber je mehr Daten ZFS im RAM hält um so näher dürfte ich der Performance einer SSD kommen. Ob das ausreichend ist, muss ich noch testen.

Falls der Plan mit ZFS so nicht auf geht, besorg ich mir eine m2 SSD und steck sie per Adapter Karte in eine PCIe Slot. So eine Adapter Karte gibt es recht kostengünstig. SATA macht bei mir keinen Sinn weil ich bereits 6 HDDs für STORJ "Mining" verbaut habe und langfristig plane jeden verfügbaren SATA Anschluss dafür zu missbrauchen.

[Jokin]

vor 3 Stunden schrieb skunk:

IOPs sind wichtiger.

Ok, also dann hier schauen: https://ssd.userbenchmark.com

Dazu "4k read" als Spalte mit aufnehmen und dabei kommt heraus, dass die SATA-SSD um die 80 MB/s schaffen und die M2-SSD über 140 MB/s schaffen.

Ok, also nun doch M2 + entsprechenden USB-Adapter besorgen?

[skunk]

vor 1 Stunde schrieb Jokin:

Ok, also nun doch M2 + entsprechenden USB-Adapter besorgen?

Wäre dann nicht so oder so der USB Adapter der Flaschenhals. Kann die SSD dann noch ihre volle Leistung entfalten? Bei meinem Setup dachte ich eher an einen PCIe Slot und selbst da müsste man dann nochmal genau hinschauen wie schnell der PCIe Slot ist, die man dafür nutzen möchte sonst bringt einem auch die schnellste SSD nichts.

[Jokin]

vor 51 Minuten schrieb bjew:

aber einen guten Adapter ......

Naja, USB3.0 ist mit 150 MB/s noch nicht überfordert.

Von daher dürfte eigentlich alles gehen.

Nun hab ich aber gesehen, dass so eine SSD gern mal 5 Watt über den USB-Anschluss zieht - hoffentlich klappt das alles am Raspi.

[dxtr]

Sehr interessantes Projekt, aber verstehe ich das richtig, dass ich nicht mitmachen kann, wenn ich nicht 32 ETH halte?

[wwurst]

vor einer Stunde schrieb dxtr:

Sehr interessantes Projekt, aber verstehe ich das richtig, dass ich nicht mitmachen kann, wenn ich nicht 32 ETH halte?

Im Moment brauchst du nur Testnet-ETH, also Spielgeld.

[Jokin]

Ich sehe gerade, dass man 50 MBit/s Internetanbindung haben muss, stimmt das?

Dann kann ich das mit dem Raspi zu Hause vergessen. 

[skunk]

vor einer Stunde schrieb Jokin:

Ich sehe gerade, dass man 50 MBit/s Internetanbindung haben muss, stimmt das?

Dann kann ich das mit dem Raspi zu Hause vergessen. 

Eher nicht. Ich kann dir dazu aber gern mal ein paar Zahlen liefern. Docker protokolliert das ja zum Glück mit.

[Jokin]

vor 5 Stunden schrieb bjew:

waaaaas? du hast noch ne Tröpfelleitung? 😭

Jupp, ich bin froh, dass wir überhaupt Internet haben  

Dafür ist‘s hier sehr schön 🙂 

Bearbeitet 2. Oktober 2020 von Jokin

[Jokin]

vor 4 Stunden schrieb skunk:

Eher nicht. Ich kann dir dazu aber gern mal ein paar Zahlen liefern. Docker protokolliert das ja zum Glück mit.

Das wäre mal cool, danke!

 

[Jokin]

Grad mal geschaut, der Bitcoin-Fullnode zieht nur 1 MBit/s und er braucht auch nicht mehr im Upstream. 

Der ETH-Node zieht mehr?

[skunk]

vor 33 Minuten schrieb Jokin:

Grad mal geschaut, der Bitcoin-Fullnode zieht nur 1 MBit/s und er braucht auch nicht mehr im Upstream. 

Der ETH-Node zieht mehr?

Bleiben sie ruhig. Ich stelle gerade mein Setup auf Docker Compose um. Ich will geth mit parity vergleich und lighthouse mit prysm. Wie üblich fehlt mir aber die Zeit. Hier mal das was ich bisher habe:

CONTAINER ID        NAME                      CPU %               MEM USAGE / LIMIT   MEM %               NET I/O             BLOCK I/O           PIDS
e08ae25703e6        eth_prysm_1               0.71%               2.141GiB / 47GiB    4.55%               12.5GB / 20.5GB     435MB / 12GB        61
dc1ad111312c        eth_geth_1                0.03%               422.7MiB / 47GiB    0.88%               521MB / 571MB       1.5GB / 989MB       20
 

30 Stunden Laufzeit.

[Jokin]

Ok, hab nu mit Crucial-SATA-SSD bestellt. 🙂

[skunk]

Hier  mal ein kurzer Zwischenstand:

# du -h -d 1
96K     ./lighthouse-validator
9,6G    ./geth
1,6M    ./prysm-wallet-v2
796K    ./prometheus
11G     ./prysm-slasher
492K    ./grafana
11G     ./parity
5,8G    ./prysm-beacon
4,0K    ./prysm-validator
7,0G    ./lighthouse-beacon
44G     .

 

NAME                         CPU %               MEM USAGE / LIMIT   MEM %               NET I/O             BLOCK I/O
eth_lighthouse-validator_1   0.00%               13.7MiB / 47GiB     0.03%               19.5MB / 9.68MB     3.06MB / 8.95MB
eth_lighthouse_1             81.73%              3.322GiB / 47GiB    7.07%               9.41GB / 5.72GB     10.2GB / 21.1GB
eth_prysm-slasher_1          0.00%               1.701GiB / 47GiB    3.62%               2.15GB / 6.11MB     877MB / 60.4GB
eth_prysm-validator_1        0.00%               40.3MiB / 47GiB     0.08%               8.75MB / 2.98MB     19.5MB / 175MB
eth_prysm_1                  200.03%             2.759GiB / 47GiB    5.87%               9.81GB / 16.3GB     5.03GB / 22.1GB
eth_prometheus_1             0.04%               43.71MiB / 47GiB    0.09%               10.4MB / 3.65MB     23.7MB / 2.7MB
eth_grafana_1                0.01%               25.77MiB / 47GiB    0.05%               11MB / 1.24MB       10.1MB / 6.1MB
eth_parity_1                 0.26%               1.308GiB / 47GiB    2.78%               2.73GB / 4.76GB     25.3GB / 8.32GB
eth_geth_1                   0.04%               276.4MiB / 47GiB    0.57%               1.28GB / 1.43GB     16.2GB / 19.2GB

Beim Vergleich Geth mit Parity würde ich sagen Geth bleibt und Parity wird entfernt. Beide Beacon Nodes richten ihre Anfragen an Geth. Parity bekommt keine Anfragen aber verbraucht trotzdem mehr Speicherplatz auf der Festplatte und auch mehr RAM. Klarer Gewinner ist also Geth.

Der Vergleich Lighthouse mit Prysm ist damit erstmal noch nicht möglich. Bei Prysm habe ich einen slasher am Laufen, den es bei Lighthouse nicht gibt. Außerdem lasse ich prysm aktuell auch alle alten Blöcke überprüfen. Das verzerrt die Ergebnisse.

Beim Setup ist mir aufgefallen, dass Prysm inzwischen ein Stable Release Tag hat. Lighthouse zwar auch aber deren Stable Release ist zu alt sodass es nicht kompatible ist mit dem aktuellen Testnet. Dort konnte ich nur das Latest Release nehmen. Bei Prysm war das Latest Release eigentlich eine Garantie auch mal ein kaputtes Build für 2 Stunden untergejubelt zu bekommen.

Dokumentation ist bei Prysm besser. Bei Lighthouse ist dagegen an einigen Stellen Try und Error angesagt. Grundsätzlich aber beides noch im Rahmen.

Was mich aktuell stört ist der Slasher. Ich ging eigentlich davon aus ich würde für derartige Aktivitäten bezahlt werden. Wenn ich einen Regelverstoß aufdecke, bekomme ich dafür einen Reward? Das scheint wohl nicht der Fall zu sein. Zumindest hat mein Slasher keinen Zugriff auf irgendwelche Wallet Dateien was dann nicht so recht zu meiner Annahme passt. Weiß das jemand mehr? Wenn es dafür keinen Reward gibt, warum sollte ich dann überhaupt einen Slasher aufsetzen? Wenn es keinen Slasher im Netzwerk gibt, ist das dann noch sicher genug?

[skunk]

vor 11 Stunden schrieb skunk:

Was mich aktuell stört ist der Slasher. Ich ging eigentlich davon aus ich würde für derartige Aktivitäten bezahlt werden. Wenn ich einen Regelverstoß aufdecke, bekomme ich dafür einen Reward? Das scheint wohl nicht der Fall zu sein. Zumindest hat mein Slasher keinen Zugriff auf irgendwelche Wallet Dateien was dann nicht so recht zu meiner Annahme passt. Weiß das jemand mehr? Wenn es dafür keinen Reward gibt, warum sollte ich dann überhaupt einen Slasher aufsetzen? Wenn es keinen Slasher im Netzwerk gibt, ist das dann noch sicher genug?

Ich denke diese Frage kann ich inzwischen selber beantworten.

Der Slasher bittet die Beacon Node um die Blöcke. Findest der Slasher in diesen Blöcken einen Regelverstoß, meldet er das zurück an die Beacon Node. Die Beacon Node würde diesen Verstoß dann an alle anderen Beacon Nodes weiterleiten. Man könnte also sagen im Mempool gibt es eine Transaktion mit einer sehr hohen Transaktionsgebühr. Der nächste Validator, der diese Transaktion in einen Block integriert, bekommt den Reward.

Um selber den Reward zu bekommen, muss ich meiner Beacon Node nur sagen, dass diese Transaktion bitte nicht an andere übermittelt wird sondern nur lokal gehalten werden soll. Dafür gibt es eine Option. Die habe ich bei mir jetzt einfach mal aktiviert.

Problem bei dieser Option ist die Frage ob die persönliche Profit Steigerung es Wert ist das Netzwerk kaputt zu machen. Nehmen wir mal an ich habe einen Regelverstoß bemerkt. Um das Netzwerk sicher zu machen, muss dieser Regelverstoß so schnell wie möglich verarbeitet. Um Profit zu machen muss ich den Regelverstoß aber geheim halten. Damit mache ich das Netzwerk angreifbar.

Jetzt kann natürlich jeder einen Slasher laufen lassen. Dann wäre das egal. Wenn jeder einen Slasher laufen lässt, hätte ich aber keinen Vorteil mehr. Wir könnten auch alle die default Einstellungen wählen und ein paar weniger Slasher laufen lassen. Auch die Validatoren ohne eigenen Slasher würden den vollen Reward bekommen. Genau das ist die Überlegung hinter der default Einstellung.

Ich lasse das erstmal laufen und schaue mal was passiert. Später wenn es ans Mainnet geht, kann ich das immer noch korrigieren.

[skunk]

Da fällt mir glatt auf, dass Lighthouse damit raus aus dem Rennen ist. Lighthouse hat aktuell noch keinen Slasher. Das ist jetzt an sich kein größeres Hindernis. Immerhin gibt es bereits einen Pull Request. Ich würde in dieser Situation aber eher den schon länger getesten Slasher von Prysm vertrauen und vielleicht später nochmal Lighthouse testen.

Was ich jetzt noch probieren möchte ist einmal die Frage ob ich die beiden Lighthouse Validatoren abmelden kann sodass sie kein Geld verlieren. Wenn diese Exit Strategie klappt, könnte man auch direkt am ETH2.0 Mainnet teil nehmen. Es verringert das Risiko.

Außerdem will ich mehrerer Setups parallel laufen lassen. Bekomme ich höhere Rewards wenn ich mich mit mehr Peers verbinde? Bekomme ich weniger Rewards wenn ich alles auf einer HDD mit ausreichend Cache verschiebe? Der einfachste Weg das zu testen sind zwei gleiche Setups bei denen ich dann die Rewards vergleichen kann.

[Jokin]

Am 27.9.2020 um 02:39 schrieb Cookies statt Coins^^:

Zum ETH_1.0-Node:
Ich wollte zusätzlich zur Beacon-Chain mittels Geth die ETH_1.0-Blockchain synchronisieren, da die ETH_2.0-Beaconchain dorthin eine Anbindung braucht. Das ETH_1.0-Göerli-Testnet hat auf dem Raspberry mit Geth ohne Probleme geklappt zu synchronisieren.  Aber wenn ich versuche, das Mainnet zu synchronisieren, dann schafft es der Raspberry Pi auch nach drei Wochen Laufzeit nicht, die Synchronisation erfolgreich zu beenden.

Der Node bleibt immer 1 bis 2 Minuten hinter dem aktuellen Stand der Blockchain und schafft es nie, diese komplett einzuholen, beispielhafter Auszug aus dem Log

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

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

Nun werde ich ins Testnet wechseln und das mit Prysm weiter probieren. Schaut bisher ganz gut aus ....

[Jokin]

So sieht das nun bei mir aus - eigentlich ok, oder?