So richtest du einen Solana-Validator ein

Terminologie: Was ist ein Solana-Validator?

Die Solana-CLI-Tools enthalten das Binary solana-validator. Es kann:

• Eine Verbindung zu einem Solana-Cluster herstellen und den aktuellen Cluster-Zustand synchronisieren
• Snapshots und andere Cluster-Daten erstellen, empfangen und teilen, um auf dem aktuellen Stand zu bleiben
• Im Rahmen des Cluster-Konsens über die Verifizierung neuer Blöcke abstimmen
• Eingehende Transaktionen verarbeiten und neue Blöcke erzeugen
• RPC und ereignisgesteuerte APIs bereitstellen, über die Cluster-Daten abgefragt und neue Transaktionen übermittelt werden können

Ein Solana-Validator kann auch als Client bezeichnet werden, da er sich mit dem Validator-Netzwerk verbindet und Daten anfordert, als Server, da er Anfragen anderer Validatoren verarbeitet und ihnen Daten bereitstellt, oder als Node.

Eine RPC-Node ist ein Solana-Validator ohne Stake und Stimmrecht, der alle Informationen des Netzwerks erfasst. Sie beantwortet lediglich Datenanfragen und nimmt nicht am Konsens teil.

Der Begriff „Solana-Validator“ kann auch eine Entität im Solana-Ökosystem bezeichnen, die einen Solana-Validator mit Stake und Stimmrecht betreibt und am Konsens teilnimmt.

Weitere Informationen zu den Unterschieden zwischen RPCs, RPC-Anbietern und Validatoren findest du hier.

Erste Schritte: Server-Hardware beschaffen

Du benötigst einen leistungsstarken Computer, der ausschließlich für den Validator vorgesehen ist. Wenn du Validatoren sowohl im Testnet als auch im Mainnet betreiben möchtest, brauchst du einen zweiten. Aktuell werden mindestens 12 Kerne/24 Threads, 256 GB RAM, 2 SSDs mit je 1 TB (idealerweise mit RAID0) und eine Internetverbindung mit 10 Gbit/s empfohlen. Ausführliche Hardwareanforderungen findest du hier.

Falls du Kosten sparen und nur im Mainnet arbeiten möchtest, beachte: Du musst einen Testnet-Validator betreiben, um dich für das Solana Foundation Delegation Program (SFDP) zu qualifizieren.

Du kannst die Hardware selbst kaufen und betreiben oder bei einem Rechenzentrumsanbieter mieten. Wir empfehlen TeraSwitch. Du kannst auch Hardware bei einem Cloud-Computing-Anbieter mieten. Davon raten wir jedoch ab, da dies oft zu teuer und anfälliger für Leistungsprobleme ist. Das Solana Foundation Server Program soll Validator-Betreibern das Mieten von Hardware bei Rechenzentrumsbetreibern erleichtern. Hier erfährst du mehr.

Um das Netzwerk zu dezentralisieren, solltest du ASNs und Städte in Betracht ziehen, in denen es noch nicht viele Solana-Nodes oder viel Stake gibt. Einige Staking-Pools und das SFDP belohnen dich anhand der Dezentralisierung nach ASN und Stadt.

Die derzeit führenden Rechenzentren findest du hier.

Solana CLI lokal installieren

Eine lokale Installation der Tools wird dringend empfohlen. So kannst du alle erforderlichen Schlüssel lokal erzeugen und den Auszahlungsschlüssel vom Validator-Server fernhalten. Eine Anleitung zum lokalen Einrichten der Solana CLI findest du hier.

Sobald die Tools lokal in deiner Befehlszeile verfügbar sind, konfigurierst du das Testnet als Standardziel:

$ solana config set --url https://api.testnet.solana.com

Für das Mainnet kannst du hier den Standard-Endpunkt festlegen:

$ solana config set --url https://api.mainnet-beta.solana.com

Die öffentlichen Mainnet-Endpunkte sind oft mit Anfragen überlastet. Falls du mit der Leistung nicht zufrieden bist, kannst du dich bei Helius registrieren und deinen Helius-Endpunkt wie folgt verwenden:

$ solana config set --url https://mainnet.helius-rpc.com/?api-key=<YOUR-HELIUS-API-KEY>

Zum Einrichten und Bootstrapping des Validators musst du Transaktionen ausführen. Daher benötigst du eine eingerichtete Wallet mit etwas SOL. Falls du gerade erst mit dem Testnet beginnst, kannst du mit den folgenden Befehlen eine Standard-Wallet erstellen und dir per Airdrop etwas SOL senden:

$ mkdir -p ~/.config/solana
$ solana-keygen new --outfile ~/.config/solana/id.json
$ solana airdrop 1 ~/.config/solana/id.json

Es wird dringend empfohlen, für Testnet und Mainnet unterschiedliche Wallets zu verwenden. Da das Schlüsselformat identisch ist, kannst du dieselben Schlüssel für beide verwenden. Widerstehe dieser Versuchung jedoch. Wenn du für finanzierte Wallets im Testnet und Mainnet dieselben Schlüssel nutzt, kannst du leicht versehentlich Befehle im Mainnet ausführen, die für das Testnet bestimmt waren.

Hier erfährst du mehr über das Erzeugen von Schlüsseln und sicherere Methoden zur Schlüsselerzeugung.

Vote-Account einrichten

Das Vote-Account deines Validators erstellst du mit dem Befehl solana create-vote-account und drei Schlüsselpaaren:

1. Identitäts-Schlüsselpaar — Der Validator verwendet dieses Schlüsselpaar, um sich gegenüber dem Netzwerk zu identifizieren und Transaktionen wie Votes zu übermitteln. Der private Schlüssel muss auf dem Server liegen. Für maximale Sicherheit solltest du daher nicht mehr SOL darin halten, als für Vote-Transaktionen erforderlich ist, also ungefähr 1 SOL pro Tag.
2. Vote-Account-Schlüsselpaar — Dieses Schlüsselpaar verweist auf das Vote-Account selbst. Damit kannst du das Vote-Account abfragen und Stake daran delegieren. Der Befehl create-vote-account benötigt den privaten Schlüssel nur als Nachweis, dass dir der erforderliche Schlüssel gehört. Nach dem Erstellen des Vote-Accounts wird nur noch der öffentliche Schlüssel benötigt. Er kann nicht geändert werden.
3. Auszahlungs-Schlüsselpaar — Dieses Schlüsselpaar dient als Hauptschlüssel für das Vote-Account. Du verwendest es, um Rewards auszuzahlen, die Identität oder den Auszahlungsschlüssel zu ändern und weitere Account-Vorgänge auszuführen. Dieser Schlüssel ist mit Abstand der sensibelste der drei. Er sollte weder auf deinem Server erzeugt noch dorthin kopiert werden. Erwäge für diesen Mainnet-Schlüssel eine Paper-Wallet, eine Hardware-Wallet oder eine Multi-Sig.

Schlüsselpaare erstellen

Erstelle die Schlüsselpaare für das Testnet wie folgt:

$ solana-keygen new -o identity.json
$ solana-keygen new -o vote.json
$ solana-keygen new -o withdraw.json

Optional: Paper-Wallet für den Auszahlungsschlüssel verwenden

Eine Paper-Wallet besteht aus einer Phrase mit 12 oder 24 Wörtern, die du auf ein Blatt Papier schreibst. Du gibst sie über die Tastatur ein, wenn der Schlüssel zum Signieren benötigt wird. Falls du keine Multi-Sig einrichten möchtest, bietet dies angemessene zusätzliche Sicherheit für den Mainnet-Auszahlungsschlüssel, da dieser Root-Zugriff auf dein Vote-Account gewährt. Führe diesen Befehl aus:

$ solana-keygen new --no-outfile

Schreibe die angezeigte Phrase auf ein Blatt Papier. Du solltest außerdem den Pubkey, den exakten Befehl zum Erstellen des Schlüssels und den solana-keygen --version notieren. Beachte, dass es verschiedene Verfahren gibt, um die Passphrase in einen privaten Schlüssel umzuwandeln. Bevor du das Blatt sicher verwahrst, prüfe, ob du damit auf den Schlüssel zugreifen kannst:

$ solana-keygen verify <PUBKEY> ASK

Verliere auf keinen Fall das Blatt mit dem notierten Schlüssel. Es gibt keine andere Möglichkeit, ihn wiederherzustellen. Vergiss nicht, die Schlüsselphrase aus deinem Terminalpuffer zu löschen.

Optional: Vanity-Key für das Vote-Account erzeugen

Einige Validatoren verwenden Vanity-Pubkeys für ihre Identität oder ihr Vote-Account. Der Helius-Validator verwendet beispielsweise HEL1USMZKAL2odpNBj2oCjffnFGaYwmbGmyewGv1e2TU als Identitätsschlüssel und he1iusunGwqrNtafDtLdhsUQDFvo13z9sUa36PauBtk für sein Vote-Account. Du erzeugst solche Schlüssel mit dem Unterbefehl grind wie folgt:

$ solana-keygen grind --starts-with PREF1X:1

Dieser Unterbefehl erzeugt einen Schlüssel, dessen Pubkey mit PREF1X beginnt. Du kannst dafür jede gültige base58-Zeichenfolge angeben. Der Befehl erzeugt so lange Schlüssel, bis einer die Kriterien erfüllt. Der Zeitaufwand wächst daher exponentiell mit der Länge des gewünschten Präfixes.

Der Schlüssel des Vote-Accounts kann nicht geändert werden. Das gilt insbesondere dann, wenn du ihn veröffentlicht hast und andere bereits Stake daran delegieren. Falls du einen Vanity-Key möchtest, solltest du ihn jetzt erzeugen.

Vote-Account aus den Schlüsselpaaren erstellen

Sobald die Schlüsselpaare bereit sind, erstellst du das Vote-Account wie folgt:

$ solana create-vote-account --fee-payer ~/.config/solana/id.json vote_account.json identity.json withdrawal.json

Dabei ist vote_account.json das Schlüsselpaar des Vote-Accounts, identity.json das Identitäts-Schlüsselpaar des Validators, withdrawal.json das Schlüsselpaar der Auszahlungs-Autorität und ~/.config/solana/id.json eine Wallet mit SOL, die für das Erstellen des Vote-Accounts bezahlt.

Falls du eine Paper-Wallet für das Auszahlungs-Schlüsselpaar verwendest, könnte dein Befehl so aussehen:

$ solana create-vote-account --fee-payer ~/.config/solana/id.json vote_account.json identity.json ASK

Mit diesem Befehl kannst du das Vote-Account oder jedes andere Vote-Account prüfen:

$ solana vote-account <PUBKEY>

Ab diesem Punkt wird das Identitäts-Schlüsselpaar zum Betreiben des Validator-Servers benötigt. Das Auszahlungs-Schlüsselpaar musst du geheim halten und ausschließlich für Auszahlungen und Änderungen am Vote-Account verwenden. Das Schlüsselpaar des Vote-Accounts wird nicht mehr benötigt. Vergiss jedoch den Pubkey nicht.

Weitere Informationen zu Vote-Accounts findest du hier.

Optional: Provision festlegen

create-vote-account akzeptiert die Provision als optionalen Parameter. Standardmäßig beträgt sie jedoch 100 %, wodurch dein Validator privat ist. Falls du externen Stake für deinen Mainnet-Validator gewinnen möchtest, musst du wahrscheinlich eine niedrigere Provision wählen.

Angenommen, der Pubkey unseres Vote-Accounts lautet <VOTE_ACCT_PUBKEY>, wir möchten die Änderung über unsere finanzierte Wallet id.json bezahlen, verwenden eine Paper-Wallet als Auszahlungsschlüssel und möchten die Provision auf 8 % setzen. Dann könnten wir dies wie folgt tun:

$ solana vote-update-commission --fee-payer ~/.config/solana/id.json <VOTE_ACCT_PUBKEY> 8 ASK

Optional: Multi-Sig hinzufügen

Eine Multi-Sig ist eine besondere Wallet, für deren Transaktionen die Signaturen einer oder mehrerer anderer Wallets erforderlich sind. Damit können mehrere Personen das Vote-Account gemeinsam verwahren. Auch wenn du den Validator allein verwaltest, solltest du eine Multi-Sig in Betracht ziehen. So kannst du später problemlos weitere Personen zum Vote-Account hinzufügen.

Squads ist ein Multi-Sig-Tool für Solana mit speziellen Funktionen zur gemeinsamen Verwaltung von Validatoren. So richtest du den Validator in Squads ein:

1. Richte deinen Browser mit einem unterstützten Solana-Wallet-Plugin wie Backpack ein
2. Öffne die Squads-dApp
3. Konfiguriere eine Squad mit den gewünschten Personen und Parametern für deinen Validator
4. Öffne „Developers > Validators“ und durchlaufe den Ablauf zum Hinzufügen des Validators
5. Du wirst aufgefordert, den privaten Auszahlungsschlüssel einzufügen. Damit wird der vorhandene Auszahlungsschlüssel durch den gemeinsamen Auszahlungsschlüssel der Squad ersetzt
6. Überprüfe den aktualisierten Auszahlungs-Pubkey mit solana vote-account

Weitere Informationen zur gemeinsamen Validator-Verwaltung mit Squads findest du hier.

Rechner als Validator-Server konfigurieren

Die genauen Schritte hängen vom Ausgangszustand deines Rechners ab. Am Ende solltest du Folgendes haben:

• Die neueste LTS-Version von Ubuntu, installiert und aktuell
  • Andere Linux-Distributionen, etwa Debian-basierte, können ebenfalls funktionieren. Alle Beispiele hier setzen jedoch Ubuntu voraus. Je stärker deine Distribution von Ubuntu abweicht, desto mehr Befehle musst du anpassen
• Konfigurierter SSH-Zugriff auf Benutzerebene
• Eingerichteter Dienstbenutzer sol
• Optimiertes System und eingerichtete Festplatten

System und Benutzer einrichten

Vergewissere dich, dass dein System aktuell ist, und erstelle den Dienstbenutzer sol:

$ sudo apt update
$ sudo apt upgrade
$ sudo adduser sol

Du kannst sudo außerdem Zugriff gewähren. Das ist bequemer, verringert aber die Sicherheit:

$ sudo adduser sol sudo

System optimieren

Füge die von Solana Labs empfohlenen Einstellungen zu sysctl und systemd hinzu. Damit erhöhst du die Grenzwerte für Dateideskriptoren, speicherabgebildete Dateien und mehr. Wenn dein Validator der aktuelle oder nächste Block-Leader ist, versucht das gesamte Netzwerk, Verbindungen zu ihm herzustellen und Transaktionen zu senden. Deshalb ist insbesondere das Limit für Dateideskriptoren wichtig.

Die aktuellen, von Solana Labs empfohlenen Einstellungen zur Systemoptimierung findest du hier.

Festplatten konfigurieren

Solana Labs empfiehlt derzeit zwei physische SSDs mit jeweils mindestens 1 TB: eine für Account-Daten und eine für Ledger-Daten. Das Betriebssystem kann ebenfalls auf dieser Festplatte liegen. Aufgrund der hohen IOPS wird davon abgeraten, Account- und Ledger-Daten auf derselben Festplatte zu speichern.

Hier findest du die Anleitung zum Einrichten der beiden Laufwerke.

Alternativ kannst du mehrere Laufwerke zu einem einzigen RAID0-Volume kombinieren, um die verfügbaren IOPS zu erhöhen. Der RAID-Controller optimiert dann, welche Stripes auf welchem Laufwerk gespeichert werden, und maximiert so die IOPS-Kapazität beider Laufwerke. Bei Bedarf kannst du dem RAID außerdem weitere Laufwerke hinzufügen, um die IOPS weiter zu erhöhen. Beim Betrieb eines Validators mit dieser Konfiguration sind bei uns bislang keine Leistungsprobleme aufgetreten.

Falls du ein einzelnes RAID0-Volume verwendest, musst du lediglich die Datenverzeichnisse des Validators auf deinem Volume einrichten. Das kannst du direkt im Home-Verzeichnis des Benutzers sol tun:

$ sudo su sol
$ mkdir -p /home/sol/accounts
$ mkdir -p /home/sol/ledger
$ mkdir -p /home/sol/snapshots
$ mkdir -p /home/sol/logs

Solana CLI auf dem Validator-Server installieren

Wiederhole die obigen Schritte, um die Solana CLI dieses Mal als Benutzer sol auf dem Validator-Server zu installieren. Für die Installation auf dem Validator-Server wird dringend empfohlen, aus dem Quellcode zu kompilieren.

Falls du das Solana-Installationstool verwendest, kannst du mit dem Befehl solana-install künftig auf neue Versionen aktualisieren. Diese Updates sind erforderlich, damit du weiter am Cluster teilnehmen kannst.

Optional: Jito Validator Client installieren

Jito Labs hat den Solana-Validator geforkt und eine eigene Version mit Maximal Extractable Value (MEV) veröffentlicht. MEV bezeichnet das Hinzufügen oder Neuanordnen von Transaktionen innerhalb eines von dir erzeugten Blocks, um Gewinn zu erzielen. Jito hat einen Markt für Personen geschaffen, die dafür einen Aufpreis zahlen möchten, sogenannte „Searcher“. Wenn du den Jito-Validator betreibst, sendet Jito deinem Validator MEV-Transaktions-Bundles. Dein Validator nimmt sie gegen ein zusätzliches Trinkgeld in seine Blöcke auf.

Der Jito-Validator erhöht die Komplexität und Latenz deines Validator-Betriebs, erschließt mit MEV-Trinkgeldern aber eine zusätzliche Einnahmequelle. Die Konfiguration ist weitgehend identisch. Du musst dich jedoch zusätzlich mit Folgendem befassen:

• MEV-Trinkgelder einziehen und verwalten
• Latenz der Jito Block Engine
• Eventuell einen Jito-Relayer betreiben

Eine Anleitung zur Installation des Validator-Clients von Jito findest du hier.

Ausführungsskripte für den Validator erstellen

Shell-Skript validator.sh erstellen

Kopiere zunächst das Identitäts-Schlüsselpaar deines Validators auf den Remote-Server:

$ scp identity.json remoteuser@your.validator.host:/home/sol

Üblicherweise verwaltest du die Konfiguration deines Validators über ein Shell-Skript. Erstelle ein Ausgangsskript und mache es ausführbar:

$ sudo su sol
$ cat >/home/sol/validator.sh <<EOF
#!/bin/bash
PATH=/home/sol/.local/share/solana/install/active_release/bin:$PATH
exec solana-validator \
    --identity /home/sol/identity.json \
    --vote-account <VOTE_ACCOUNT_PUBKEY> \
    --known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on \
    --known-validator 7XSY3MrYnK8vq693Rju17bbPkCN3Z7KvvfvJx4kdrsSY \
    --known-validator Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN \
    --known-validator 9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv \
    --only-known-rpc \
    --log /home/sol/logs/solana-validator.log \
    --accounts /home/sol/accounts \
    --snapshots /home/sol/snapshots \
    --ledger /home/sol/ledger \
    --rpc-port 8899 \
    --dynamic-port-range 8000-8020 \
    --entrypoint entrypoint.testnet.solana.com:8001 \
    --entrypoint entrypoint2.testnet.solana.com:8001 \
    --entrypoint entrypoint3.testnet.solana.com:8001 \
    --expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY \
    --wal-recovery-mode skip_any_corrupted_record \
    --limit-ledger-size
EOF
$ chmod +x /home/sol/validator.sh

Mit diesen Einstellungen kannst du den Validator schnell und sicher im Testnet starten. Sobald alles eingerichtet ist, musst du zu diesem Skript zurückkehren, solana-validator --help ausführen, die vollständige Liste der Konfigurationsoptionen ansehen und es anpassen.

Versuche, den Validator mit dem Skript zu starten:

$ ./validator.sh

Beim ersten Start muss er den aktuellen Zustand des Clusters synchronisieren.

Prüfen, ob der Validator korrekt läuft

Mit dem folgenden Befehl kannst du den extern sichtbaren Fortschritt deines oder jedes anderen Validators von überall im Cluster verfolgen:

$ solana catchup <IDENTITY_PUBKEY>

Als Benutzer sol kannst du seinen internen Fortschritt in einer Sitzung mit folgendem Befehl ansehen:

$ solana-validator --ledger /home/sol/ledger monitor

Weitere Informationen dazu, wie du die korrekte Verbindung deines Validators mit dem Cluster prüfst, findest du hier.

Validator als Daemon-Prozess einrichten

Erstelle eine Datei systemd unit, um den Validator als Daemon zu verwalten:

$ sudo cat >/etc/systemd/system/sol.service <<EOF
[Unit]
Description=Solana Validator
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=1
User=sol
LimitNOFILE=1000000
LogRateLimitIntervalSec=0
ExecStart=/home/sol/validator.sh

[Install]
WantedBy=multi-user.target
EOF

Vergewissere dich, dass dein zuvor gestarteter ./validator.sh-Aufruf nicht mehr läuft. Starte den Validator dann als Daemon:

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now sol

Monitoring und Sicherheit einrichten

Passwortbasierte Authentifizierung deaktivieren

In deiner Datei /etc/ssh/sshd_config kannst du festlegen, dass der SSH-Daemon weder Passwörter noch Challenge-Response-Verfahren zur Anmeldung akzeptiert:

...
PasswordAuthentication no
ChallengeResponseAuthentication no
...

Vergiss nicht, den Daemon sshd mit der neuen Konfiguration neu zu laden:

$ sudo systemctl reload sshd

fail2ban und ufw hinzufügen

fail2ban funktioniert sofort und sperrt Verbindungen, deren Authentifizierung mehrmals fehlschlägt:

$ sudo apt install fail2ban

ufw ist eine im System enthaltene Firewall. Du kannst sie mit wenigen Befehlen einrichten. Dabei gehen wir davon aus, dass deine endgültige Validator-Konfiguration die Standardports und -portbereiche verwendet und SSH auf Port 22 bereitstellt:

$ sudo ufw allow 22/tcp
$ sudo ufw allow 8000:10000/tcp
$ sudo ufw allow 8000:10000/udp
$ sudo ufw enable

Identitäts-Schlüsselpaar des Validators

In der Praxis speichern die meisten Validator-Betreiber ihren Identitätsschlüssel auf dem Validator-Server. So kann das Validator-Skript ohne menschliches Eingreifen ausgeführt und neu gestartet werden. Es ist jedoch möglich, den Identitätsschlüssel mit ASK oder prompt:// an den Validator zu übergeben. Dann muss er nicht im Dateisystem des Validator-Servers gespeichert werden. Das erhöht deinen Betriebsaufwand und dein Risiko, da ein Mensch nun die Rolle von systemd übernehmen und den Daemon-Prozess manuell verwalten muss. Es ist aber möglich.

Die beste Strategie zum Schutz deines Identitäts-Schlüsselpaars besteht darin, es nur mit der Mindestmenge an SOL zu finanzieren, die für einige Tage Vote-Kosten erforderlich ist.

Shinobi Systems hat Tools zur Verwaltung von Vote-Accounts veröffentlicht. Dazu gehören automatische Überweisungen des Guthabens aus dem Vote-Account, ohne jedes Mal den Auszahlungsschlüssel zu verwenden.

Weitere Tipps findest du auf der Seite von Solana Labs zur Validator-Sicherheit.

Monitoring mit Watchtower einrichten

solana-watchtower ist im Solana-CLI-Toolkit enthalten und kann dich über Probleme mit deinem Validator und dem gesamten Cluster informieren. Du kannst es ähnlich wie den Validator selbst konfigurieren und ausführen, indem du ein Skript watchtower.sh erstellst.

Dieses Beispiel verwendet PagerDuty für Warnmeldungen und schreibt die Logs nach watchtower.log:

$ cat >watchtower.sh <<EOF
#!/bin/bash
PATH=/home/solana/.local/share/solana/install/active_release/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

exec &gt;>watchtower.log \\
  env PAGERDUTY_INTEGRATION_KEY=<PAGERDUTY_KEY> \\
solana-watchtower \\
  --validator-identity <IDENTITY_PUBKEY> \\
  --monitor-active-stake \\
  --interval 20 \\
  --minimum-validator-identity-balance 3 \\
  --url https://api.testnet.solana.com
EOF

Solana Labs zeigt außerdem an einem Beispiel, wie du Telegram für Warnmeldungen einrichtest.

Es wird nicht empfohlen, Watchtower auf demselben Rechner wie deinen Validator einzurichten. Wenn der gesamte Rechner ausfällt, erhältst du sonst keine Benachrichtigungen. Falls du mehrere Monitoring-Systeme verwendest und solche Fälle separat überwachen kannst, ist dies unter Umständen dennoch vertretbar.

Anders als der Validator benötigt Watchtower nur wenige Ressourcen. Du kannst es in einer Cloud- oder Serverless-Computing-Umgebung ausführen, etwa bei AWS oder GCP.

Optional: Community-basiertes Monitoring

Viele Personen in der Solana-Community überwachen den Cluster ebenfalls und bieten Warnmeldungen für ähnliche Bedingungen wie Watchtower an.

Stakewiz bietet Telegram-basiertes Monitoring für Solana-Validatoren. Falls du beispielsweise Warnmeldungen für den Helius-Validator einrichten möchtest, kannst du seine Seite öffnen und dann auf „+ Warnmeldung erstellen“ klicken.

Beachte, dass Community-basiertes Monitoring dafür gedacht ist, Personen über Probleme mit Validatoren zu informieren, bei denen sie Stake hinterlegt haben. Als Validator-Betreiber solltest du dich bei der Überwachung deiner Dienste nicht ausschließlich auf andere verlassen.

Optional: Eigenes Monitoring über die RPC-Methode getHealth

Wenn du den Status deines Validators direkt an der Quelle abrufen möchtest, bietet die JSON-RPC-Schnittstelle deines Validators die Methode getHealth. Du kannst sie regelmäßig abfragen, um zu prüfen, ob dein Validator fehlerfrei läuft, und Informationen zu möglichen Problemen zu erhalten.

Optional: Monitoring-Lösungen von Drittanbietern

Sobald dein Validator skaliert ist und du eine Einnahmequelle schützen musst, solltest du kommerzielle SaaS-Monitoring-Lösungen wie Datadog oder Splunk in Betracht ziehen. Solche Lösungen funktionieren üblicherweise auf eine von zwei Arten: Entweder läuft ein Daemon-Prozess auf deinem Server, der Logs und Metriken lokal überwacht und an den Anbieter exportiert. Oder du stellst getHealth beziehungsweise einen ähnlichen Status-Endpunkt bereit, den der Anbieter remote von deinem Validator abfragt.

Stake zum Validator hinzufügen

Das Solana-Netzwerk erzielt Konsens durch ein Proof-of-Stake-Abstimmungsverfahren (PoS). Das Stimmgewicht eines Validators ist proportional zur Menge des an ihn delegierten SOL-Stakes. Wenn du gestaktes SOL als Aktien betrachtest, ähnelt dies einer Aktiengesellschaft. Neben dem Stimmgewicht ist auch die Häufigkeit, mit der dein Validator zum Block-Leader wird, proportional zur Menge des an ihn gestakten SOL.

Viele Wallets, dApps und andere Tools vereinfachen das Staken deines SOL bei bestehenden Validatoren. Mit diesen Schritten kannst du es manuell über die CLI durchführen:

1. Erstelle 3 Schlüsselpaare mit solana-keygen new
2. Erstelle aus den Schlüsselpaaren mit solana create-stake-account ein Stake-Account
3. Übertrage etwas SOL auf das Stake-Account. Im Testnet kannst du dafür solana aidrop verwenden
4. Delegiere den eingezahlten Stake mit solana delegate-stake an einen Validator
5. Warte bis zur nächsten Epoche, damit der Stake aktiviert wird, und prüfe ihn mit solana stake-account

Schlüsselpaare und Stake-Account erstellen

Das Erstellen der Schlüsselpaare und des Stake-Accounts ähnelt dem Erstellen des Vote-Accounts. Du benötigst folgende drei Schlüsselpaare:

1. Schlüsselpaar der Stake-Autorität - ermöglicht operative Aufgaben am Stake-Account, darunter Delegieren, Aufheben von Delegationen, Aufteilen und Zusammenführen
2. Schlüsselpaar des Stake-Accounts - der öffentliche Schlüssel, der das Stake-Account selbst identifiziert. Der private Schlüssel wird nach dem Erstellen des Stake-Accounts nicht mehr benötigt
3. Auszahlungs-Schlüsselpaar - das Hauptschlüsselpaar für das Auszahlen von Stake und Zurücksetzen der Autoritäts-Schlüsselpaare des Stake-Accounts. Behandle es mit Vorsicht und erwäge eine Hardware-Wallet, Paper-Wallet oder Multi-Sig

Aus denselben Gründen wie beim Vote-Account wird dringend empfohlen, für Testnet und Mainnet unterschiedliche Schlüssel zu verwenden. Innerhalb desselben Clusters kannst du jedoch ein einziges Schlüsselpaar für die Stake-Autorität und ein einziges für die Auszahlungs-Autorität bei mehreren Stake-Accounts verwenden. Identische Schlüssel für Stake-Accounts sind eine Voraussetzung, um diese zusammenzuführen.

Dieses Beispiel erstellt im Testnet ein Stake-Account mit 1 SOL. Für die Schlüsselpaare werden dateibasierte Wallets verwendet. Das Account wird über deine Wallet id.json finanziert und der Stake an deinen neuen Validator delegiert:

$ solana-keygen new -o stake_auth.json
$ solana-keygen new -o stake_acct_1.json
$ solana-keygen new -o stake_withdrawal_auth.json
$ solana airdrop 1 ~/.config/solana/id.json
$ solana create-stake-account --from ~/.config/solana/id.json stake_acct_1.json 1 --stake-authority stake_auth.json --withdraw-authority stake_withdraw_auth.json --fee-payer ~/.config/solana/id.json
$ solana delegate-stake --stake-authority stake_auth.json <STAKE_ACCT_1_PUBKEY> <VOTE_ACCT_PUBKEY> --fee-payer ~/.config/solana/id.json

Jetzt kannst du prüfen, ob der Stake aktiviert wird und ab welcher Epoche er aktiv ist:

$ solana stake-account <STAKE_ACCT_1_PUBKEY>

Sobald die nächste Epoche beginnt und der Stake aktiv ist, werden die Votes deines Validators gezählt. Die letzten Votes kannst du als Teil des Befehls solana vote-account ansehen. Falls du wie im Beispiel nur wenige SOL hinzugefügt hast, wird dein Validator voraussichtlich nicht zum Block-Leader.

Votes kosten etwa 1–2 SOL pro Tag. Zum Zeitpunkt der Erstellung dieses Beitrags kostet allein das Abstimmen im Mainnet deinen Validator damit ungefähr 200–300 US-Dollar pro Tag.

(Weitere Informationen zur Stake-Delegation und zur Verwaltung von Stake-Accounts).

Informationen des Validators veröffentlichen

Wenn du gängige Solana-Validator-Verzeichnisse wie validators.app durchsuchst, siehst du, dass alle Validatoren einen Namen, eine Beschreibung, ein Logo und weitere Metadaten haben. Diese Daten werden für alle registrierten Validatoren jedes Clusters On-Chain veröffentlicht. Du kannst sie mit solana validator-info get ansehen.

Sobald dein Validator läuft, kannst du seine Informationen veröffentlichen. Das ist besonders sinnvoll, wenn du im Mainnet arbeitest und Stake gewinnen möchtest.

Hier ist ein einfaches Beispiel für das Veröffentlichen deiner Metadaten:

$ solana validator-info publish "My Awesome Validator" \
--website "https://awesome-validator.xyz/" \
--icon-url "https://awesome-validator.xyz/icon360x360.png" \
--keypair validator_identity.json \
--details "The best validator in the world!"

Beim Erstellen erhält der Metadateneintrag einen eigenen Schlüssel. Du kannst ihn später mit dem Argument --info-pubkey aktualisieren. Beachte, dass die URL des Symbols höchstens 80 Zeichen lang sein darf. Weitere Informationen zum Veröffentlichen von Validator-Informationen und Metadaten findest du hier.

Fazit

Glückwunsch! Wenn du alle Schritte ausgeführt hast und bis hierher gekommen bist, sollte dein eigener Solana-Validator jetzt laufen. Willkommen in der Solana-Validator-Community!

Weitere Ressourcen

• Übersicht über Solana-Validatoren
• Dokumentation für Solana-Validatoren
• Solana Foundation Delegation Program
• Solana Foundation – Stake-Pools