28 lines
3.5 KiB
Markdown
28 lines
3.5 KiB
Markdown
# 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.
|