Herausforderung
Eine Blockchain-Plattform von Grund auf zu bauen bedeutet, sehr viele Bausteine gleichzeitig zu verstehen und ehrlich mit ihrem Reifegrad umzugehen: Netzwerkschicht, Konsens, Kryptografie, Speicherung, Beobachtbarkeit, Betrieb. In jeder dieser Ebenen ist es einfach, „grüne” Testläufe zu haben und trotzdem weit von einem produktionsreifen Zustand entfernt zu sein.
Für Quantix war die eigentliche Herausforderung deshalb nicht das schnelle Aufsetzen einer neuen Chain, sondern der ehrliche Umgang mit dem, was wirklich funktioniert. Bis zum internen Audit vom 29.08.2026 lagen im Repository über dreihundert Reports mit Titeln wie „Production Ready” oder „95/100” — Aussagen, die ein unabhängiger Blick auf den Code nicht bestätigte. Der Auftrag war daher: alle diese Berichte in ein Archiv zu verschieben, den tatsächlichen Zustand in einem einzigen Status-Abschnitt zu bündeln und offene Stopp-Punkte klar zu benennen.
Ansatz
Fünf Prinzipien:
- Echte Bibliotheken statt Attrappen — libp2p für das P2P-Netzwerk und Cloudflare CIRCL für Dilithium, nicht selbstgeschriebene Ersatzstücke.
- Ein einziger, gültiger Statusabschnitt — alle älteren „Fertig”-Reports gehen ins Archiv (
docs/archive/2026-02/); nur der aktuelle Statusabschnitt beschreibt den Ist-Zustand. - Nachprüfbare Aussagen — jede Aussage im Statusabschnitt kommt mit einem Kommando (
go build ./... && go vet ./... && go test ./...) oder einer Modul-Referenz, die man selbst prüfen kann. - Offene Stopp-Punkte — was gegen einen Produktivbetrieb spricht, wird namentlich genannt, statt es hinter Meilenstein-Sprache zu verstecken.
- Getrennte Vertrauenskontexte — Sicherheitsentscheidungen (JWT, Emission, Signaturprüfung) werden im Repository ausformuliert, damit die nächsten Änderungen sie nicht wieder aufweichen.
Was wir gebaut haben
Blockchain-Knoten in Go (apps/backend/quantix-blockchain/, cmd/, internal/)
Ein Go-Knoten mit Mempool, Blockproduktion und Synchronisationsschleife (init_sync.go, sync_loop.go). Das Wurzelmodul github.com/quantix/core baut und vett ohne Fehler; Tests des Wurzelmoduls sind in neun Paketen grün (apps/backend, .../quantix-datacenter-integration, .../quantix-payment-gateway, .../quantix-security-access, internal/security, src/apps/backend/api-gateway, tests/integration, tests/load, tests/mempool). Aktueller Testzähler laut Audit: 156 von 171 grün.
Reales P2P-Netzwerk (p2p_*.go)
Kein Mock: github.com/libp2p/go-libp2p v0.43.0 plus go-libp2p-kad-dht v0.35.1 und go-libp2p-pubsub v0.15.0 bilden die Netzwerkschicht. Kad-DHT liefert Peer-Discovery, PubSub trägt Blöcke und Transaktionen als Gossip.
Post-Quanten-Signaturen (shared/security/post-quantum/, internal/security/)
CRYSTALS-Dilithium in den Modi 2, 3 und 5 über github.com/cloudflare/circl (sign/dilithium/mode2|3|5). Genutzt in pqc_manager_dilithium.go und internal/security/manager.go. Kyber und SPHINCS+ liegen im selben Verzeichnis, sind aktuell aber Attrappen — im Statusabschnitt offen als solche benannt.
Backend-Dienste (services/, apps/, microservices/)
Mehrere Go-Dienste hinter einem gemeinsamen API-Gateway (src/apps/backend/api-gateway/): Datacenter-Integration, Payment Gateway, Security Access. Jeder Dienst hat eigene Tests und ein eigenes Deployment-Rezept.
Datenschicht und Betrieb (postgres-*, migrations/, patroni/, pgbouncer/)
PostgreSQL als Kern-Datenbank mit Migrations- und Backup-Werkzeugen (postgres-backup-encrypted/, postgres-backup-verification/). Patroni und PgBouncer decken den HA-Pfad ab. prometheus/, monitoring/ und nginx/ liefern Beobachtbarkeit und Reverse-Proxy.
Web-Konsole und Desktop-Verpackung (frontend-explorer/, packages/, apps/)
Web-Konsole und Block-Explorer in React/TypeScript. Für Desktop-Auslieferung existiert eine Tauri-Verpackung (siehe DESKTOP_CLIENT_INTEGRATION_PLAN.md).
Aufgeräumte Dokumentation
Alle historischen „Production Ready”-Berichte sind in docs/archive/2026-02/ verschoben. Der aktuelle Statusabschnitt im README ist die einzige gültige Quelle. docs/SECURITY-ROTATION.md beschreibt die Reihenfolge für die Rotation der offengelegten Secrets.
Architektur
Quantix folgt einer klassischen Zweiteilung: Kette und Umgebung. Die Kette selbst besteht aus einem Go-Knoten mit Mempool, Blockproduktion, Zustandsspeicherung und Netzwerkschicht. Um sie herum liegt eine Umgebung aus Backend-Diensten, Web-Konsole und Betriebs-Werkzeugen, die nichts an der Kettenlogik ändern, aber ihren Zugriff kontrollieren.
Die Netzwerkschicht basiert auf libp2p: Kad-DHT übernimmt Peer-Discovery, PubSub verteilt Blöcke und Transaktionen. Die Wahl echter, gepflegter Bibliotheken war eine der bewussten Entscheidungen des Audits — kein Eigenbau, kein Mock im Produktivpfad.
Die Kryptografie setzt auf CRYSTALS-Dilithium (via Cloudflare CIRCL) für post-quantum-fähige Signaturen. Weitere Post-Quanten-Verfahren (Kyber, SPHINCS+) sind vorbereitet, aber im aktuellen Statusabschnitt offen als Attrappen markiert.
Das API-Gateway (src/apps/backend/api-gateway/) bündelt Anfragen an mehrere Backend-Dienste. Beobachtbarkeit erfolgt über Prometheus und Grafana; PostgreSQL bildet die Kern-Datenbank, ergänzt durch Patroni und PgBouncer.
Der Statusabschnitt im README ist der wichtigste architektonische Bestandteil dieser Fallstudie. Er nennt sieben offene Stopp-Punkte namentlich — u. a. fehlende Autorisierung auf dem HTTP-API des Knotens, freie Emission über einen Sonderaccount, unvollständige Konsens-Mechanismen (PBFT scheitert in allen 8 Tests; PoS und DPoS sammeln keine Stimmen), einen einzelnen JWT-Secret über zwei Vertrauenskontexte, und in der Git-Historie verbliebene Secrets, deren Rotation im docs/SECURITY-ROTATION.md beschrieben ist.
Zahlen & Fakten
| Metrik | Wert |
|---|---|
| Kettensprache | Go 1.24 (Wurzelmodul github.com/quantix/core) |
| P2P-Netzwerk | libp2p v0.43.0 · Kad-DHT v0.35.1 · PubSub v0.15.0 |
| Signaturen | CRYSTALS-Dilithium (Modi 2/3/5) via Cloudflare CIRCL |
| Datenschicht | PostgreSQL · Patroni · PgBouncer · Redis · NATS |
| Beobachtbarkeit | Prometheus · Grafana · nginx |
| Web / Desktop | React + TypeScript · Tauri-Verpackung |
| Tests | 156 von 171 grün laut Audit vom 29.08.2026 |
| Reifegrad | Experimentell — sieben offene Stopp-Punkte im README benannt |
Was wir gelernt haben
Ehrliche Statusaussagen brechen Tempo, gewinnen aber Vertrauen. Ein einziger, gültiger Statusabschnitt ist wertvoller als dreihundert „Fertig”-Berichte. Neue Mitwirkende und externe Prüfer:innen wissen sofort, worauf sie sich verlassen dürfen — und worauf nicht.
Attrappen im Sicherheitscode sind eine Zeitbombe. Kyber und SPHINCS+ als Stubs im selben Verzeichnis wie ein echter Dilithium-Manager sind gefährlich, wenn nicht klar markiert. Der Statusabschnitt nennt beide beim Namen, damit niemand sie versehentlich in einen Produktivpfad hebt.
Secret-Rotation folgt einer eigenen Reihenfolge. Werte, die einmal in einer Git-Historie standen, sind für immer in jedem Klon. docs/SECURITY-ROTATION.md beschreibt die notwendigen Schritte: zwei getrennte JWT-Secrets für Auth-Dienst und Knoten, Rotation aller kompromittierten Werte, Neuschreiben der Historie durch die Eigentümer.
Konsens ist ein eigenes Projekt. PBFT-Tests durchgängig zu scheitern und PoS/DPoS ohne Stimmensammlung stehen zu haben, zeigt: Konsens gehört nicht als Nebeneffekt in ein „Blockchain-Framework”. Er braucht eigene Iterationen mit eigener Testpyramide.
Nächste Schritte
- Konsens-Mechanismen (PBFT, PoS, DPoS) als eigenständige Iteration angehen, beginnend mit einem reproduzierbaren Testaufbau.
- HTTP-API des Knotens hinter Autorisierung stellen und den geteilten
JWT_SECRETinAUTH_JWT_SECRETundNODE_JWT_SECRETtrennen. - Freie Emission über den Sonderaccount abschaffen; Signaturprüfung ohne Substring-Umgehung.
- Kyber und SPHINCS+ entweder durch echte Implementierungen ersetzen oder ausbauen und das Verzeichnis entsprechend markieren.
Verwandt
- Kontext: Über Alpine Ascent — Quantix ist Ausdruck unserer Offenheit für experimentelle Plattformen mit ehrlicher Statusdokumentation.