Ethereum-2.0-Staking auf Raspberry Pi

[satoshi21]

vor 1 Stunde schrieb skunk:

Bei mir steht dort eine 0x01. Damit bin ich dann erstmal raus

Kannst du doch beliebig oft im Testnet ausprobieren oder nicht?

Das stimmt! Pro Testnet Validator 1x 😉

[Cookies statt Coins^^]

Am 10.2.2023 um 08:15 schrieb satoshi21:

Ein anderes Thema treibt mich gerade um. Mein Validator hat (leider) eine BLS 0x00 Withdraw Adresse, d.h. ich muss, um nach dem Exit an meinen Stake(+Gewinne) zu kommen auf eine 0x01 Adresse wechseln.

Vielen Dank für den Hinweis, das hatte ich noch gar nicht im Blick. Auch ich habe noch eine 0x00 Adresse ._.

Das ist sehr ärgerlich, dass wir da eine solche sehr riskante Migration durchführen müssen. Die in deinem Link verlinkte Anleitung finde ich ja mehr als kompliziert beschrieben. Aber ich bin zuversichtlich, dass da noch eine neue Anleitung kommt. Beim Durchsuchen des Prysm-Discord-Kanals wird eine solche Anleitung in Aussicht gestellt ( https://discord.com/channels/476244492043812875/476588476393848832/1064439606898069504 ). Aktuell kann man diese Änderung sowieso noch gar nicht durchführen, wir müssen erst noch bis März auf das Shanghai/Capella-Upgrade warten...

[Muesli2k]

Annos Basin (v1.11.0) Latest

 

This is a major release, containing over 300 PRs. Our original intention was to release 1.11 with path-based storage, but eventually we decided it was time to make the release without waiting for PBSS to be merged, so we can get back to a steady release schedule.

We hope to soon follow up the 1.11 release with 1.12, including PBSS.

Shanghai Upgrade Support

Most of the code for the Shanghai fork is merged into 1.11, but activation of the fork is not configured. The Shanghai protocol upgrade will contain the ability to make withdrawals from the consensus-layer (beacon chain). Withdrawals are specified in EIP-4895: Beacon chain push withdrawals as operations.

Other features included are EIP-3855: PUSH0 instruction, EIP-3860: Limit and meter initcode and EIP-3651: Warm COINBASE.

A New Database Backend

Pebble was added as a database backend to replace good old LevelDB.

LevelDB has served us very well over the years, alas, it is a one-person project where the maintainer has signaled that the project is not a priority. We have been forced to consider three options:

1. Stick with goleveldb as long as we can, don't worry about it,
2. Fork goleveldb (or some other database), and maintain it ourselves.
3. Pick a different database, actively maintained by a dedicated team.

Since option one is not really a long-term solution, the choice was between two and three. Maintaining a database is a huge effort, and is not a burden we want to carry. Hence, we have been aiming for option 3, and eventually settled on Pebble.

Pebble is actively maintained by a dedicated team, and is used by other projects. We hope that this is a good long-term bet. It has performed well in our benchmark tests, we are very interested in getting feedback from actual production systems. In order to use pebble,

• You need to be on a 64-bit system,
• You also need to resync from scratch (with or without ancients) -- there is no migration functionality,
• And you need to specify --db.engine=pebble initially. For subsequent runs, geth should discover pebble automatically.

Removed Features

We have removed support for the ropsten and kiln test networks. We have also removed libraries for mobile development and the puppeth tool.

The personal RPC namespace is now deprecated. In order to interact with personal APIs, you need to specifically allow it via the --rpc.enabledeprecatedpersonal command-line flag.

Support for certain legacy files configuration files was dropped. geth now will ignore these datadir files:

• static-nodes.json
• trusted-nodes.json

If any these are found, an error will be printed to the log. Setups using such files should use to the TOML configuration-file instead.

Backwards-Incompatible Changes

When using geth for mining or as a clique sealer, the --miner.etherbase flag now has to be be set explicitly. Previously, Geth would use the 'first' local account as etherbase automatically, but this possibility has been removed in Geth 1.11.

This change does not affect proof-of-stake networks because the fee recipient address is provided by the consenus-layer and not configured in Geth anymore.

Geth's JSON-RPC server has become more strict; the JSON-RPC spec requires the version field to be exactly "jsonrpc": "2.0". This is now verified by the server -- a change which is not backwards-compatible with non-conforming client implementations.

If you are building from source, go-ethereum now requires Go version 1.18 or later (#26160).

New Features

#26149 added an option to direct log output to a file. This feature has been requested a lot. It's sometimes useful to have this available when running geth in an environment that doesn't easily allow redirecting the output.

We have added a method debug_setTrieFlushInterval to make it possible to set the trie flush interval via RPC (#24785). Essentially, this makes it possible to configure the node to be more or less "archive:ish", and without restarting the node while reconfiguring it.

Geth can now set custom HTTP headers, in particular for two scenarios:

• geth attach
• geth commands which can use --remotedb, e.g geth db inspect

The ability to use custom headers is typically useful for connecting to cloud-apis, e.g. providing an infura- or alchemy key, or for that matter access-keys for environments behind cloudflare.

Tracing

For tracing, it is sometimes desirable to capture logs triggered by a trace, when using the callTracer. For example: call USDT.transfer will trigger a Transfer(from, to, value) event. By specifying {"withLog": true}, these events will be collected. Some bugs related to tracing and gasUsed was fixed.

For prestateTracer, the result will from now on omit empty fields instead of including a zero value (e.g. no more balance: '0x'). The prestateTracer now takes an option diffMode: bool. In this mode the tracer will output the pre state and post data for the modified parts of state.

#26241 should make it easier to sign EIP-712 typed data via the accounts.Wallet API, by using the mimetype for typed data.

It is now possible to get the result for multiple tracers in one go via the muxTracer.

Filter System

Via the filter subscriptions to newPendingTransactions, one can now subscribe to the full pending transactions, as opposed to just being notified about hashes.

The keywords safe and finalized can now also be used as block range specifiers when requesting logs.

All Changes

Larger changes

• Added pebble as a new database backend. (#26517, #26650)
• Make use of golang generics (#26290 #26194, #26162, #26159)
• Prepare for upcoming Shanghai hardfork (#26645, #26624, #26554, #26548,#26232, #26591, #26565, #26563, #26555, #26549, #26484, #26474, #26475, #23847, #26458)
• Remove Ropsten support (#26644)
• Prepare for path-based-storage (#26637, #26603, #26324, #25532, #25896)
• Remove mobile packages (#26599)
• Deprecate personal namespace (#26390)
• internal/debug: add --log.file option (#26149)
• eth/tracers: add multiplexing tracer (#26086)
• eth/tracers: add diffMode to prestateTracer (#25422)

Minor changes and features

• rpc: remove DecimalOrHex type (#26629)
• Make abi codec more strict (#26568)
• core/vm: improve EVM instance reusability (#26341)
• core: improve ambiguous block validation message (#26582)
• log: better sanitation (#26556, #26630)
• p2p/discover: add more packet information in logs (#26307)
• common/mclock: add Alarm (#26333)
• core/rawdb: implement resettable freezer (#26324)
• signer: enable typed data signing from signer rpc (#26241)
• rpc: support injecting HTTP headers through context (#26023)
• improve reading Go runtime metrics (#25886)
• Changes for Cancun hardfork
  • Implement EIP-1153: Transient Storage (...

 

https://github.com/ethereum/go-ethereum/releases

[skunk]

@satoshi21Ab Minute 41 werden die Schritte gezeigt die du machen müsstest. Sofern der Private Key nicht kompromittiert wurde, würde ich an deiner Stelle einfach abwarten. Mit der Zeit wird der Prozess vermutlich einfacher.

Bearbeitet 16. Februar 2023 von skunk

[skunk]

Ich habe mal die letzten Wochen bei Ebay Kleinanzeigen die 8 TB SSDs im Auge behalten. Es gibt praktisch dauerhaft 2 Angebote mit guten NVMe SSDs. Neupreis dieser SSDs wäre über 1000€. Die gebrauchten SSDs haben nur wenige TB an Verschleiß hinter sich und werden für 650€ angeboten. Das Problem ist nur, dass der Verkäufer keine Top Bewertung hat und maximal PayPal mit Käuferschutz anbietet. Ich bin mir nicht sicher wie umfangreich der Käuferschutz von PayPal ist verglichen mit der normalen Zahlungsabwicklung von Ebay Kleinanzeigen. Daher lasse ich von diesen Angeboten bisher noch die Finger.

Es gibt aber noch eine interessante Alternative. Im Server Bereich kommen üblicherweise SSDs mit u.2 Anschluss zum Einsatz. In einem Standard PC kann man eine u.2 SSD entweder per Adapter an den NVMe Slot anschließen oder per PCIe Karte. Neupreis einer 8 TB SSD liegt hier bei 700€. Gebraucht sind sie für um die 500€ teilweise inklusive beider Adapter Varianten.

[Muesli2k]

vor 5 Stunden schrieb skunk:

Ich habe mal die letzten Wochen bei Ebay Kleinanzeigen die 8 TB SSDs im Auge behalten. Es gibt praktisch dauerhaft 2 Angebote mit guten NVMe SSDs. Neupreis dieser SSDs wäre über 1000€. Die gebrauchten SSDs haben nur wenige TB an Verschleiß hinter sich und werden für 650€ angeboten. Das Problem ist nur, dass der Verkäufer keine Top Bewertung hat und maximal PayPal mit Käuferschutz anbietet. Ich bin mir nicht sicher wie umfangreich der Käuferschutz von PayPal ist verglichen mit der normalen Zahlungsabwicklung von Ebay Kleinanzeigen. Daher lasse ich von diesen Angeboten bisher noch die Finger.

Es gibt aber noch eine interessante Alternative. Im Server Bereich kommen üblicherweise SSDs mit u.2 Anschluss zum Einsatz. In einem Standard PC kann man eine u.2 SSD entweder per Adapter an den NVMe Slot anschließen oder per PCIe Karte. Neupreis einer 8 TB SSD liegt hier bei 700€. Gebraucht sind sie für um die 500€ teilweise inklusive beider Adapter Varianten.

8TB halte ich nach meinen momentanen Berechnungen in den nächsten 2-3 Jahren für absolut nicht notwenig..

Meine letzten Aufzeichnungen zeigen das der Validator im Schnitt ~3TB am Tag an Speicher belegt, in meinem Fall sind 725GB frei, 200GB ziehe ich als Puffer ab, bleiben

525/3 ~ 175 Tage ein knappes halbes Jahr.. dann werde ich prunen.. und denke das als Ergebnis mind. nochmal 3-6 Monate Zeit rausspringen in der ich weiter die 2 TB nutzen kann... bevor ich auf 4TB umsteige... da lass mal 1800GB zusätzlich frei sein, 1800/3 = 600 Tage oder 1,64 Jahre wo man sich freie Zeit erkauft...

Wozu also jetzt überteuert eine 8TB nvme SSD beschaffen?

 

	m2 freier Speicher	TB read	TB written
14.01.23	846
23.01.23	822	927	835
30.01.23	799	929	837
07.02.23	782	930	838
10.02.23	770	931	839
12.02.23	768	931	839
14.02.23	762	931	840
18.02.23	751	932	841
20.02.23	746	933	841
22.02.23	741	933	841
27.02.23	725	934	842

Bearbeitet 27. Februar 2023 von Muesli2k

[skunk]

vor 21 Minuten schrieb Muesli2k:

Wozu also jetzt überteuert eine 8TB nvme SSD beschaffen?

Weil ich davon ausgehe, dass die Blockchain nicht linear wächst sondern leicht exponentiell. Wie schnell die Blockchain nach Einführung von Sharing wächst, können wir nicht mal erahnen. Da habe ich dann lieber etwas mehr Speicher als zu wenig.

[Cookies statt Coins^^]

Konnte mittlerweile mittels Pruning meine Geth-Blockchain von 1,1 TB auf 665 GB fast halbieren. Habe mich dabei an folgender Anleitung orientiert: https://geth.ethereum.org/docs/fundamentals/pruning

Der Vorgang verlief relativ unkompliziert. Trotzdem hier ein paar wichtige Tipps noch:

• Nutzt am Besten zu Beginn den tmux-Befehl, damit auch bei kurzen Verbindungsabbrüchen des Terminalfensters das Pruning nicht abgebrochen wird und die Session im Hintergrund weiterläuft
• Man darf erst mit dem Pruning beginnen, wenn Geth keinerlei Zugriff mehr auf die Dateien im Filesystem hat. Obwohl der Geth-Service beendet war, war auf der Festplatte zunächst noch eine Aktivität festzustellen (für ca 2 bis 3 Minuten). Also entweder zur Sicherheit etwas warten, oder mit dem iostat-Befehl prüfen, ob das Filesystem mit den Geth-Daten noch in Verwendung ist.
• Das Pruning verläuft in drei Phasen ("Iterating state snapshot" -> "Prune state data" -> "Compacting database"). Bei einer Größe von 1,1 TB sollte der gesamte Vorgang eigentlich in 5 Stunden durch sein (habe ich im Geth-Discord-Kanal gelesen). Nur auf meinem Raspberry Pi hat es aufgrund des langsamen USB-Festplattenanschlusses insgesamt 16 Stunden gedauert. Da es dann in der Nacht fertig wurde und ich im Anschluss auch noch eine Sicherung des Geth-Ordners machte, war mein Validator somit mal wieder für 24 Stunden offline. Das sind die ärgerlichen Nachteile bei einem langsamen Raspberry Pi^^
• Hier meine eingetippten Shell-Befehle mit entsprechenden Kommentaren zur Erläuterung:

# 1.) TMUX starten (analog zu Screen)
# tmux enables pruning to keep running even if you disconnect
#
# Neue Session beginnen:
tmux new -s GethPruneSession
#
# Session später ggfs wiederherstellen:
#tmux attach -t GethPruneSession 

# 2.) Prozess beenden:
sudo systemctl stop Geth.service

# 3.) Warten, bis keine Zugriff mehr auf Festplatte besteht (ca. 2-3 Minuten nach Beenden von Geth)
iostat -d -x -m 10 -p sda

# 4.) Prune:
# Dauer auf meinem Raspi: 16 Stunden; Größe: 1,1 GB -> Eigentlich sollte es bei 1,1 GB nur 5h dauern
#   1. Iterating state snapshot: 3h
#   2. Prune state data: 5h 
#   3. Compacting database: 6h
# 
geth --datadir /mnt/ssd/EthMerge/.ExecutionClientGeth snapshot prune-state 

# 5.) Backup vom Geth-Ordner erstellen:
# scp -r <quelle> <ziel>  
#
scp -r /mnt/ssd/EthMerge/.ExecutionClientGeth /mnt/ssd/EthMerge/Backup/.ExecutionClientGeth_Backup

# 5.) Logdatei ins Archiv verschieben (+ umbenennen)

# 6.) Prozess starten:
sudo systemctl start Geth.service

PS:
Jetzt, knapp 2 Wochen nach dem Pruning ist das Geth-Verzeichnis schon wieder um 85 GB stark angewachsen (+6,5 GB pro Tag). Das nächste Pruning steht somit wieder in 2 bis 3 Monaten an....

Bearbeitet 27. Februar 2023 von Cookies statt Coins^^

[Muesli2k]

vor 4 Stunden schrieb skunk:

Weil ich davon ausgehe, dass die Blockchain nicht linear wächst sondern leicht exponentiell. Wie schnell die Blockchain nach Einführung von Sharing wächst, können wir nicht mal erahnen. Da habe ich dann lieber etwas mehr Speicher als zu wenig.

Also wenn ichs richtig verstanden habe, haben wir auf den Validatoren eine FullNode und wenn man diese prunt, schrumpft diese immer wieder auf 650GB zusammen.

https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node

Im Gegensatz zu einer Archive Node welche die komplette Blockchain enthält (12TB) ist die die FullNode nur ein Snapshot eines Teils der Blockckain...

https://geth.ethereum.org/docs/fundamentals/pruning

 

 

Spricht somit immer mehr gegen deine 8TB Theorie 

 

 

Bearbeitet 27. Februar 2023 von Muesli2k

[skunk]

vor 53 Minuten schrieb Muesli2k:

Also wenn ichs richtig verstanden habe, haben wir auf den Validatoren eine FullNode und wenn man diese prunt, schrumpft diese immer wieder auf 650GB zusammen.

Nein. Das was du prunst sind nur ältere Kontenbewegungen. Die Blockchain selbst und auch alle aktuellen Kontoständen können nicht entfernt werden. Die speicherst du dauerhaft. Jeder neue Smart Contract auf der Blockchain wird auch auf deiner SSD verewigt. Es wird nicht bei dauerhaft 650 GB bleiben.

[skunk]

Auf Ebay Kleinanzeigen gibt es aktuell 8 TB SSDs für um die 700€. Damit sollte ich für die nächsten Jahre genug freien Speicherplatz haben.

Edit: Ist am Ende eine normale m2 NVMe SSD geworden. Eine u2 SSD wäre zwar kostengünstiger aber ich will mir die Option offen halten später auf ein Odroid oder vergleichbares zu wechseln. Mit einer m2 SSD bleibe ich flexibel.

Bearbeitet 5. April 2023 von skunk

[..::. o.Z.o.n.e .::..]

Am 5.4.2023 um 13:14 schrieb skunk:

Auf Ebay Kleinanzeigen gibt es aktuell 8 TB SSDs für um die 700€. Damit sollte ich für die nächsten Jahre genug freien Speicherplatz haben.

Edit: Ist am Ende eine normale m2 NVMe SSD geworden. Eine u2 SSD wäre zwar kostengünstiger aber ich will mir die Option offen halten später auf ein Odroid oder vergleichbares zu wechseln. Mit einer m2 SSD bleibe ich flexibel.

Es gibt heutzutage preiswerte USB-Adapter die mehrere M.2 als Raid 0 / 1 / 5 oder eben als JBOD unterstützen. Ich habe mir einen für zwei M.2 bestellt. ( link ) Es gibt aber andere, für vier ( link ) oder sogar noch mehr. ;o))

[Cricktor]

Der erste Link ist kaputt, aber du meinst natürlich das hier: https://amzn.eu/d/gwYDnyZ

An einem Raspi 4B wird so ein Adapter auf jeden Fall das 5V-Netzteil benötigen, das hoffentlich mit dabei ist. Einen Anschluß habe ich in den Produktbildern zumindest gesehen.

[skunk]

vor 37 Minuten schrieb Cricktor:

Der erste Link ist kaputt, aber du meinst natürlich das hier: https://amzn.eu/d/gwYDnyZ

An einem Raspi 4B wird so ein Adapter auf jeden Fall das 5V-Netzteil benötigen, das hoffentlich mit dabei ist. Einen Anschluß habe ich in den Produktbildern zumindest gesehen.

Bedenke, dass so ein Raspi 4B locker um den Faktor 10 langsamer ist als eine NVMe SSD. So ein Adapter würde ich nur an einem Thunderbolt 3 Anschluss anstöpseln sonst wird das künstlich soweit runtergebremst, dass ich auch gleich eine 8 TB SATA SSD hätte kaufen können. Wozu den Aufpreis für eine NVMe SSD zahlen wenn man die deutlich bessere Performance künstlich drosselt?

[Muesli2k]

vor 17 Minuten schrieb skunk:

Bedenke, dass so ein Raspi 4B locker um den Faktor 10 langsamer ist als eine NVMe SSD. So ein Adapter würde ich nur an einem Thunderbolt 3 Anschluss anstöpseln sonst wird das künstlich soweit runtergebremst, dass ich auch gleich eine 8 TB SATA SSD hätte kaufen können. Wozu den Aufpreis für eine NVMe SSD zahlen wenn man die deutlich bessere Performance künstlich drosselt?

Abgesehen davon werden m.2 Nvme von diesem Adapter garnicht supportet! Hier muss man höllisch aufpassen, da passen lediglich SATA m2 rein.. 

[skunk]

Software Raid ist unter Linux auch recht einfach möglich. Wäre vermutlich kostengünstiger braucht aber auch mehr USB Anschlüsse.

[skunk]

Noch etwas mehr als einen Tag bis zur Party: https://wenmerge.com/

Neue SSD ist eingebaut. Ich bin eigentlich etwas spät dran will jetzt aber mal so eine Auszahlung im Testnet ausprobieren. Mal sehen wie gut das so läuft.

[Muesli2k]

Werd mich dann wohl auch mal so langsam damit beschäftigen müssen....  🙈

https://launchpad.ethereum.org/de/withdrawals

Zum Glück gibts nun mittlerweile eine Anleitung.... 😃

https://someresat.medium.com/guide-to-configuring-withdrawal-credentials-on-ethereum-812dce3193a

Werde aber max. die Rewards mal runterholen, der Validator bleibt selbstverständlich weiter bestehen... 

[Muesli2k]

Gebt euch das, beobachte das gerade des öfteren... liegts an der Auslastung vom Netzwerk?

Aber 1,72ETH als Reward sind schon brutal.... 😲

https://beaconcha.in/validator/537562

 

[skunk]

Ich habe eine schöne Übersicht über alle ETH1 und ETH2 Clients gefunden bezüglich Speicherplatz Verbrauch, Zuwachsrate und CPU Verbrauch. Leider nur aus dem Webarchiv mit Stand Sommer 2022. Ist also nicht ganz aktuell sollte aber dennoch einen guten Überblick bieten. https://web.archive.org/web/20221026204307/https://eth-docker.net/docs/Usage/ResourceUsage/

Bearbeitet 27. April 2023 von skunk

[Muesli2k]

Mal wieder ein kleiner Zwischenbericht von mir, hab jetzt mal versucht den Verlauf freier Speicher, TBW u. TBR eine weile zu tracken... s.u.

Da sich meine 2TB SSD nun auch der 80% Kapazitätsgrenze annähert, hab ich heute aufgeräumt "geprunt"..

Das Ergebnis ist etwas ernüchternd, ich hätte ehrlich gesagt danach mit mehr freiem Speicher gerechnet...

Von 502GB freiem Speicher ging es zurück auf 891GB! Der Prune hat in Summe ca ~6 Stunden in Anspruch genommen...

	m2 freier Speicher	TB read	TB written
14.01.23	846
23.01.23	822	927	835
30.01.23	799	929	837
07.02.23	782	930	838
10.02.23	770	931	839
12.02.23	768	931	839
14.02.23	762	931	840
18.02.23	751	932	841
20.02.23	746	933	841
22.02.23	741	933	841
27.02.23	724	934	842
06.03.23	706	935	844
13.03.23	685	937	845
20.03.23	668	938	847
29.03.23	646	940	849
03.04.23	632	941	850
10.04.23	614	942	852
17.04.23	593	944	854
19.04.23	592	944	854
25.04.23	582	946	855
07.05.23	551	948	858
09.05.23	546	949	859
15.05.23	539	950	860
22.05.23	526	951	862
29.05.23	510	952	864
01.06.23	502 GB frei (75,5% belegt)	953	864
Prune	6 Stunden
01.06.23	891 GB frei (56,5% belegt)	954	865

 

Bearbeitet 1. Juni 2023 von Muesli2k

[skunk]

Es gibt einen neuen Stern am Himmel.

Aktuell auf meiner Watchlist stehen Rock 5b und Odroid H3 bzw H3+. Beide haben eine PCIe3.0x4 Anbindung für die SSD. Die beiden Geräte unterscheiden sich etwas in Rechenleistung, Stromverbrauch und maximal möglichen RAM. Für den geringst möglichen Stromverbrauch wäre der Rock 5b vorteilhaft jedoch ist man dann auf 16 GB RAM beschränkt. Das sollte für einen Validator locker reichen. Beim Odroid H3 und H3+ wären bis zu 64 GB möglich. Da ist man schon am überlegen den leicht höheren Stromverbrauch der verbauten Intel CPU in Kauf zu nehmen.

In Kürze kommt der Orange Pi 5 Plus mit 32 GB RAM raus. Der klingt perfekt für mich. Mehr RAM als der Rock 5b bei sonst gleichen Leistungsdaten und Stromverbrauch. Es sollte genug RAM sein um neben einem Validator noch diverse andere Programme laufen zu lassen.

[blaualge]

vor 3 Stunden schrieb skunk:

Es gibt einen neuen Stern am Himmel.

Aktuell auf meiner Watchlist stehen Rock 5b und Odroid H3 bzw H3+. Beide haben eine PCIe3.0x4 Anbindung für die SSD. Die beiden Geräte unterscheiden sich etwas in Rechenleistung, Stromverbrauch und maximal möglichen RAM. Für den geringst möglichen Stromverbrauch wäre der Rock 5b vorteilhaft jedoch ist man dann auf 16 GB RAM beschränkt. Das sollte für einen Validator locker reichen. Beim Odroid H3 und H3+ wären bis zu 64 GB möglich. Da ist man schon am überlegen den leicht höheren Stromverbrauch der verbauten Intel CPU in Kauf zu nehmen.

In Kürze kommt der Orange Pi 5 Plus mit 32 GB RAM raus. Der klingt perfekt für mich. Mehr RAM als der Rock 5b bei sonst gleichen Leistungsdaten und Stromverbrauch. Es sollte genug RAM sein um neben einem Validator noch diverse andere Programme laufen zu lassen.

guck dir zusätzlich den Ende des Monats kommenden Raspi 5 an. 

Die anderen könnten aber tatsächlich etwas mehr Leistung bringen

[Cookies statt Coins^^]

vor 3 Stunden schrieb skunk:

In Kürze kommt der Orange Pi 5 Plus mit 32 GB RAM raus.

Gute Hinweis 👍

vor 3 Minuten schrieb blaualge:

guck dir zusätzlich den Ende des Monats kommenden Raspi 5 an

Ja, der neue Raspberry Pi 5 soll ja nun auch M.2-SSD unterstützen, jedoch hat er weiterhin nur 8 GB RAM, d.h. die SSD wird zusätzlich mit Swapping beschäftigt sein.

Aktuell bin ich noch auf meinen beiden Raspi Pi 4 unterwegs, wobei das eher schlecht als Recht läuft, habe viele Ausfälle (vermutlich aufgrund langsamer USB-3.0 Festplatte mit zusätzlich einige GB Swapping). Hatte aber immer noch keine Zeit, mich weiter damit zu beschäftigen. Erst müsste ich noch meine Auszahladresse hinterlegen, erst wenn das funktioniert, dann kaufe ich mir mit dem Erlös neue Hardware 😄

[skunk]

vor 10 Minuten schrieb blaualge:

guck dir zusätzlich den Ende des Monats kommenden Raspi 5 an. 

Leider unbrauchbar weil nur PCIe 2.0x1. Nicht falsch verstehen. Ist ein tolles Gerät für alle möglichen Anwendungen nur eben nicht für ETH wo SSD Performance gefragt ist.