1. Interesse bekunden
Schreiben Sie über den bestehenden ERA-Kontaktweg an info@eraprojects.io und bitten Sie um das aktuell geprüfte Aufnahme- und Qualifikationsverfahren.
Qualifikation unabhängiger Betreiber
ERA-Validator werden
ERA betreibt derzeit vier von Gründern kontrollierte Validatoren. Externe Zulassung erfordert eine geprüfte Qualifikation; technische Eignung oder eine Bindung allein verschafft keinen aktiven Platz.
Sieben Schritte vom Interesse zum Betrieb
2. Betrieb beschreiben
Nennen Sie Erfahrung, Kontaktdaten, geplanten Hosting-Standort, Infrastruktur, Wartung, Überwachung und Vorfallmanagement. Senden Sie keine Zugangsdaten oder Kontogeheimnisse.
3. Anforderungen vor dem Staking prüfen
Prüfen Sie mit ERA die aktuelle Mindest-Eigenbindung von 10,000 ETKN, höchstens 20% Provision, Gebühren, Wahlregeln und unabhängige Qualifikation, bevor Sie Stake erwerben oder signieren.
4. Getrennten Full Node aufbauen
Verwenden Sie den kanonischen Quellcode erablockchains/era-blockchain, festgelegte Build-Anleitungen und den geprüften Betreiberleitfaden. Prüfen Sie Prüfsummen, unveränderte Raw-Chain-Spec und Genesis. Synchronisieren Sie einen eigenen Nicht-Validator-Knoten ohne Autoritätsschlüssel.
5. Zuverlässige Synchronisierung belegen
Bestätigen Sie ERA-Genesis, Peers, aktuelle Runtime und fortschreitende Finalisierung. Bewahren Sie Verfügbarkeits-, Ressourcen- und Vorfallnachweise auf. Die Erreichbarkeit öffentlicher Sentries von einem neuen unabhängigen Host ist noch zu qualifizieren.
6. Eigene Schlüssel und Absicht vorbereiten
Erzeugen Sie erst nach Prüfung Sitzungsschlüssel lokal auf Ihrem eigenen System. Folgen Sie dem geprüften Ablauf für Eigenbindung, Schlüsselregistrierung und Validatorabsicht mit aktuellen Gebühren und Zustandsprüfungen. Übermitteln Sie nie private Schlüssel oder Wiederherstellungsphrasen.
7. Wahl prüfen und überwachen
Eine Kandidatur muss noch gewählt oder zugelassen werden. Prüfen Sie aktiven Satz, Sitzungswechsel und Finalität, bevor Sie Aktivierung behaupten. Überwachen Sie Peers, Speicher, Schlüssel, Belohnungen und Vorfälle laufend.
Knoten- und Staking-Rollen
Validator
Gewählte Autorität mit eigenen Sitzungsschlüsseln, die an Blockproduktion und Finalisierung teilnimmt.
Full Node
Synchronisierter Knoten ohne Validatorabsicht oder Autoritätsschlüssel; empfohlener erster Betriebsschritt.
RPC-Knoten
Knoten für Client-Anfragen mit geprüften Zugriffsgrenzen. Ein Wallet-WSS-Endpunkt ist kein Bootnode-Peer.
Nominator
Konto, das Validatoren bei Staking-Wahlen unterstützt. Nominierte Mittel ersetzen nicht die 10,000 ETKN Eigenbindung des Validators.
Technische Prüfungen und Betriebsempfehlungen
Technische Prüfungen: kanonischen Quellcode/Tag, Build-Prüfsumme, unveränderte Raw-Chain-Spec, Genesis 0x0abc2c3d8db5815541050b73da4d81267ebf14d90dbee8d7258155b667ea112e, Peers und wachsende Finalität prüfen. Den geprüften Leitfaden verwenden; unabhängiges Onboarding ist noch nicht vollständig qualifiziert. (BUILD.md, OPERATORS.md, PROVENANCE.md)
Empfehlung: dedizierter zuverlässiger Rechner mit SSD, angemessener CPU/RAM, Überwachung freier Bytes und Inodes, stabilem Netz, Prozessaufsicht und dauerhafter Verfügbarkeit. ERA veröffentlicht weder universelle Hardware-Mindestwerte noch eine Verfügbarkeitsgarantie für externe Betreiber.
Wallets nutzen wss://eraprojects.org/ für Client-RPC. Knoten verbinden sich über das Peer-Protokoll mit geprüften Peer-/Bootnode-Adressen. Lokales administratives RPC nicht öffnen und keine Produktions-Validator-Datenbank kopieren.
Eigene Sitzungsschlüssel selbst verwahren, verschlüsselte Offline-Sicherungen anlegen und Wiederherstellung testen. Geprüfte Updates mit bestätigter Prüfsumme verwenden, Daten und Schlüssel erhalten und Vorfälle ERA zeitnah melden.
Hardware und Verfügbarkeit
Befund zur aktuellen Last: Die vier akzeptierten Validatoren meldeten jeweils einen Intel i5-13500 der 13. Generation mit 14 Kernen und 64.081 MB Speicher. Aufbewahrte Dienstprotokolle zeigen Speicherspitzen von 2,9–4,7 GB. Nach einem Netto-Rückgang von 1,8–3,0 GiB über etwa acht Tage waren rund 377–384 GiB Dateisystemplatz frei. Darin sind alle Schreib- und Löschvorgänge des Hosts enthalten; es ist weder eine Messung des Wachstums der Chain-Datenbank noch ein Nachweis einer Mindestgröße.
Startempfehlung für Validatoren bei der aktuellen ERA-Last: ein dedizierter moderner x86-64-Rechner in der Leistungsklasse der derzeitigen Hosts (etwa 12–16 leistungsfähige CPU-Kerne), 64 GiB RAM und mindestens 1 TiB zuverlässiger NVMe-SSD-Speicher. Halten Sie als Planungspuffer mindestens 250 GiB frei und passen Sie die Kapazität anhand gemessenen Datenbank- und Dateisystemwachstums an. Das ist eine vorsichtige Empfehlung, keine Zulassungsregel oder allgemeingültige Untergrenze.
Separater Full Node ohne Validatorfunktion: Planen Sie vorläufig eine moderne 8-Kern-CPU, 32 GiB RAM und mindestens 1 TiB SSD ein. Er prüft und hält den Chain-Zustand vor, besitzt aber keine Autoritätsschlüssel und signiert nicht. Eine unabhängige Ende-zu-Ende-Prüfung von Synchronisierung und Peer-Verbindung steht noch aus; diese Zahlen sind keine bewiesene Untergrenze.
Archive Node: Zusätzlich aufbewahrter historischer Zustand oder aufwendige Indexierung benötigen deutlich mehr Speicher, anhaltende E/A-Leistung und einen Aufbewahrungsplan. Es gibt keine authentifizierte ERA-Wachstumsreihe oder unabhängig qualifizierte Archiveinrichtung als Grundlage für eine feste Mindestzahl. Dimensionieren Sie mehrere Terabyte SSD nach einem gemessenen Aufbewahrungstest; ein beschnittener Full Node ist kein Archiv.
Nutzen Sie zuverlässige Verbindungen mit niedriger Latenz und geprüfte Peer-/Sentry-Routen, möglichst redundante Anbindung, unterbrechungsfreie Stromversorgung sowie Überwachung von CPU, RAM, freiem SSD-Platz und Inodes, Peer-Zahl, Synchronisationsrückstand, finalisiertem Head, Neustarts und Schlüssel-/Sitzungsstatus. Planen Sie Upgrades und Backups mit Wiederherstellungstests und melden Sie Vorfälle zügig. Wallet-WSS ist keine Node-Peer-Verbindung; Verwaltungs-RPC darf nicht öffentlich sein.
Vorgeschlagenes Verfügbarkeitsziel zur Prüfung durch den Eigentümer
Vorgeschlagen werden 99,9 % monatliche Verfügbarkeit des Validator-Dienstes zur Prüfung durch den Eigentümer (höchstens 0,1 % Ausfallzeit, etwa 43,2 Minuten in 30 Tagen). Messen Sie in einminütigen UTC-Intervallen durch unabhängige Überwachung. Ein Intervall gilt als ausgefallen, wenn der Validator-/Konsensprozess steht, geprüfte Peer-Verbindungen verloren gehen oder der finalisierte Head einer fortschreitenden Referenzkette länger als zwei Minuten nicht folgt. Geplante Wartung und Verbindungsverlust zählen als Ausfall; netzweite Vorfälle werden getrennt erfasst. Dies ist nur ein vorgeschlagenes Betreiberziel, keine bestehende Zulassungsregel, kein On-Chain-Slashing-Schwellenwert und keine ERA-Verfügbarkeitsgarantie.
Belohnungen, Provision und Sanktionen
Die bereitgestellte spec15-Runtime erzwingt mindestens 10,000 ETKN Eigenbindung und höchstens 20% Provision. Weder Bindung noch Provisionssatz garantieren Auswahl oder Einnahmen.
Leistung und Berechtigung fließen in den eigenen SecurityBudget-Belohnungsweg. Die reguläre Staking-Era-Auszahlung ist in dieser Runtime null. Lesende Berechtigung wurde geprüft, die erste rechtmäßige Produktionszahlung jedoch noch nicht. Eine angezeigte Schätzung beweist keinen auszahlbaren Anspruch.
Die genehmigte Sanktionsrichtlinie ist implementiert; ihre Produktionsaktivierung steht nach der Zahlungsprüfung noch aus. Prüfen Sie aktuellen Stand und Vorfallverfahren vor einer Kandidatur.
Kopierbare Interessensvorlage
Markieren und kopieren Sie diesen Text in Ihre eigene E-Mail an info@eraprojects.io. Lassen Sie private Schlüssel, Wiederherstellungsphrasen, Passwörter und Serverzugänge weg.
Betreff: Interesse als ERA-Validator Betreiber / Organisation: Kontaktperson und Antwortadresse: Erfahrung mit Validatoren und Knoten: Geplanter Hosting-Ort und Anbieter: CPU, RAM, SSD-Kapazität und Netzwerkplan: Überwachung, Wartung und Vorfallbereitschaft: Schlüsselverwahrung, Sicherung und Wiederherstellung (ohne Geheimnisse): Geplanter Zeitrahmen und Fragen: