3.5 KiB
Netzzugang, lokale Node-Konfiguration und Mining-Identitäten
Aktueller Architekturentscheid: ADR 0008 (25.10.2026). Noch keine funktionierende Implementierung. Das ältere NETWORK_SERVICES_UND_ONBOARDING.md beschreibt eine verworfene verpflichtende zentrale Registrierung und ist nur noch als historischer Entwurf enthalten.
1. Netzwerk beitreten: Ohne zentralen Benutzeraccount
Hub-Installation / lokale Konfiguration enthält: Chain-ID, authentischen Genesis-Hash bzw. vertrauenswürdige Genesis-Datei, Seed-/Persistent-Peer-Adressen, eigene P2P-/Node-Schlüssel, lokale Daten- und Portpfade, optional separaten Operator-Fingerprint/Mining-ID. Alle Peers/Ports und Genesis werden gegen die Vertrauensanker geprüft. Die Node verbindet sich P2P und synchronisiert selbst, unabhängig vom Network Admin.
Technische Rollen: Validator (CometBFT-Konsens, eigener State), Hub (Full Node mit WebGUI und browserseitiger Wallet, optional Miner), Worker (Hub-gebundener Miner ohne Chain-State/Spend-Key), Betreiber (operator_id, mehrere Hub-/Worker-IDs). Eine Wallet ist keine Node-Identität; der Hub/Worker darf keinen Wallet-Spend-Key empfangen. Ein Fingerprint allein beweist keine Kontrolle über den Schlüssel.
2. Mining-Zulassung: Getrennt von P2P
Für die erste private Version legt die betreibende Person eine überprüfte Betreiber-/Mining-Identität mit zugehörigen öffentlichen Schlüsseln fest. Anträge können anfänglich manuell als signierte Datensätze/CLI-Datei übermittelt werden, keine verpflichtende Registrierungs-Website. Geschütztes Admin-Werkzeug erstellt erst nach Prüfung die autorisierte On-chain-Freigabe; Validatoren prüfen sie deterministisch, danach gilt sie als bestätigt. Die Admin-GUI zeigt Registrierung/Freigabe/Sperre und Audit. Ein Statusfeld in lokaler Konfiguration oder optionaler Monitoring-DB verleiht keinerlei Mining-Recht.
Freigaben und Sperren sind schreibende Ausnahmen: Sie dürfen erst aktiviert werden, wenn Admin-Schlüsselformat, Rechte und Audit mit Negativtests vorliegen. Bis dahin read-only Cockpit und inaktive Schaltflächen mit verständlicher Begründung. Keine Server-Wallet-Keys.
3. Netzwerküberblick und Zählbarkeit
Die Registry kennt zugelassene Identitäten, nicht automatisch laufende Rechner. Peers einer Node sind eine Teilmenge der Netzverbindungen. Ein optionaler, geschützter Monitoring-Receiver kann nur mit Zustimmung signierte Heartbeats erfassen und Zeitreihen speichern, beispielsweise in SQLite. Anzeigen daher getrennt: registriert / P2P gesehen / signiert zuletzt online / PoP aktiv mit Zeitpunkt und Datenabdeckung. Keine vollständige Live-Hostzahl ohne flächendeckend verifizierte Meldungen behaupten.
4. Ausfallverhalten / Sicherheit
Validatoren und bereits synchronisierte Hubs bleiben bei Admin-Ausfall funktionsfähig. Seed-Fallback über mindestens zwei unabhängige Einträge im späteren Testnet. Keine ungeschützten externen RPC-/Admin-/ABCI-Ports; Entwicklung auf localhost plus SSH-Forward. API-/Pairing-Authentifizierung unabhängig von fremden Wallet-Spend-Keys. Keine zentrale Benutzerpasswortdatenbank.
5. Entwicklungsreihenfolge
M1: Chain-ID/Genesis-Verifikation, Betreiber-/Mining-/Admin-Keys und Registry-Aktionen spezifizieren. M2: erster Validator, Hub+Wallet und getrenntes Network-Admin-Read-only auf echter Datenquelle. M3: Multi-Peer-/Validator-Betrieb. M4: signierte Freigabe/Sperre, Worker-Pairing, PoP und Fonds; M5/M6 optional Monitoring-Historie und geschützter separater Admin-LXC.