Vom Modell zum laufenden Netz — das DataVeritas-Testnetz
Der Simulator zeigt das Modell. Das neue Testnetz zeigt es in echt — als Docker-Container, mit echtem Proof-of-Authority-Konsens, echtem Sharding und einem Smoke-Test, der Knoten sterben lässt und wieder heilt.
Der Simulator auf dieser Seite rechnet das Modell hinter DataVeritas durch: wie viele Kopien ein Shard braucht, wie schnell ein Netz nach einem Knotenausfall wieder heilt, wie sich die Speicherlast auf tausend Teilnehmer verteilt. Er ist ehrlich als Modell gekennzeichnet — jede Zahl ist berechnet, keine ist gemessen.
Seit heute gibt es den nächsten Schritt: dvnode, einen echten Referenzknoten in Go, der sich als kleines Testnetz in Docker starten lässt. Kein Modell mehr — echte HTTP-Knoten, die echte Blöcke versiegeln, echte Datensätze verteilen und echte Prüfungen beantworten.
Was das Testnetz zeigt
Drei Autoritäten versiegeln reihum Blöcke im Proof-of-Authority-Verfahren — alle 2.4 Sekunden einer. Thin Nodes übernehmen per Rendezvous-Hashing einen Anteil der Shards; Light Nodes halten nur Header und prüfen über Merkle-Pfad und Signatur. Stirbt ein Knoten, verteilen die übrigen die verwaisten Shards automatisch neu.
Das ist keine Behauptung — wir haben es gemessen. Der automatisierte Smoke-Test (testnet/smoke.sh) fährt ein Netz aus 3 Autoritäten, 1 Full Node, 6 Thin Nodes und 2 Light Nodes hoch und lässt es durch einen vollständigen Ausfall- und Heilungszyklus laufen:
- 200 Datensätze eingereicht, alle 200 signiert versiegelt und über
/verifymit gültigem Hash, Merkle-Pfad, Header-Signatur und Sealer-Berechtigung bestätigt. - 2 von 6 Thin Nodes getötet (≈ 30 %) — danach hatte jeder Shard weiterhin mindestens einen Halter, eine Stichprobe von 50 Datensätzen liess sich weiterhin vollständig verifizieren.
- Hochskaliert auf 12 Thin Nodes — die Shard-Abdeckung war innerhalb von 15 Sekunden wiederhergestellt.
- Ein Datensatz wurde überall, wo er repliziert lag, manipuliert (14 Kopien). Die Prüfung auf einem Light Node — der den Datensatz selbst nicht hält, ihn also von einem Peer holen muss — schlug korrekt fehl:
hash_matches: false, alle anderen Prüfungen weiterhintrue. Der Manipulationsversuch war präzise lokalisiert, nicht bloss „irgendetwas stimmt nicht".
Der ganze Lauf dauert unter drei Minuten.
Was es noch nicht ist
Das Testnetz ist ein Test-Entwurf, kein Produktionssystem, und das steht auch so in seiner eigenen Dokumentation: kein TLS zwischen den Knoten, keine Peer-Authentifizierung, kein automatisches Sealer-Failover, wenn eine Autorität ausfällt (die drei Autoritäten laufen im Test immer durch). Die drei Autoritäten-Schlüssel im Repository sind bewusst öffentliche Dev-Schlüssel, klar als solche markiert — für einen produktiven Einsatz braucht es eigene, geheim gehaltene Schlüssel.
Selbst ausprobieren
cd testnet
./dv.sh up
./dv.sh status
./dv.sh smokeAlle Befehle, Architektur und die drei Betriebssystem-Anleitungen (Windows, macOS, Linux) stehen auf der Testnetz-Seite. Wer will, verbindet den Simulator im Live-Modus direkt mit einem laufenden lokalen Testnetz und sieht die echte Kettenhöhe statt der Modellrechnung.