Vertrauen & Light-Modus
Kurz und ehrlich: Post-Quantum bezieht sich hier auf Dilithium (Mode 3) für Wallet- und Transaktionssignaturen. Der Light-Modus vertraut zusätzlich den HTTP-APIs der gewählten Nodes für Chain-Fakten — das ist kein SPV, sondern ein Trusted-API-Modell. Technische Referenz auch im StreCoin-Repository.
1. Was „Post-Quantum“ hier bedeutet
Gemeint sind digitale Signaturen mit Dilithium — abgestimmt auf das NIST-PQC-Programm. Ziel ist Schutz vor dem Szenario, dass sehr große Quantenrechner klassische Kurven-Signaturen (z. B. ECDSA/Ed25519) brechen können.
Nicht automatisch gemeint: TLS zum Dashboard, jede andere kryptografische Schicht oder die Korrektheit von API-Antworten im Light-Modus.
2. Full Node vs. Light
| Full Node | Light | |
|---|---|---|
| Chain-Validierung | Du validierst Regeln und Historie (über deine Nodes). | Nein — Remotes liefern Höhe/State. |
| Transaktionssignatur | Lokal mit deinem Schlüssel. | Ebenfalls lokal. |
| Vertrauensanker | Protokoll + Software + Peers. | Die gewählten HTTP-API-Endpunkte. |
Light startet z. B. mit --remote-node oder --discover-pv (Premium-APIs aus der On-Chain-Registry).
3. Light mit Premium-Registry (--discover-pv)
- Discovery holt aktive Einträge (z. B. über
/api/registry/peers) und leitet daraus HTTP-Basis-URLs ab. - Das Trust-Set sind die erfolgreich erreichbaren Premium-APIs — nicht willkürlich eine einzelne feste IP.
- Ist die Registry leer, gibt es keinen Fallback auf Seed-IPs als Ersatz-Wahrheit — das Modell bleibt klar.
4. Risiken und Empfehlungen
- Kompromittierte API: falsche Balance, Nonce oder Höhe → nutzlose oder irreführende Transaktionen.
- Netzwerk: DNS-Spoofing, TLS-MITM — wie bei jeder HTTPS-API; vertrauenswürdige URLs und sauberer Serverbetrieb mindern das Risiko.
- Nutzer: größere Beträge lieber mit eigenem Full Node; im Light mehrere Remotes (Failover) und bei Zweifeln nicht nur eine Quelle.
- Premium-Betreiber: TLS, Monitoring, keine Secrets in Logs, sinnvolle Rate-Limits für öffentliche Light-Endpoints.
5. Roadmap (Transparenz)
Stufe A (heute): API-trusted Light — pragmatisch und klar benannt.
Stufe B (optional später): z. B. SPV-Header, Checkpoints oder Konsistenzchecks über mehrere APIs — mehr Aufwand, stärkeres Modell ohne Full Node.