Was das ist

Drei Autoritäten versiegeln reihum Blöcke (Proof of Authority, keine Rechenlast wie beim Mining).
Thin Nodes übernehmen per Rendezvous-Hashing einen Anteil der Shards; fällt einer aus, laden die übrigen automatisch nach (Heal).
Light Nodes speichern nur Header und verifizieren über Merkle-Pfad und Signatur — ohne den vollen Datensatz zu halten.
Ein Angriff auf einen einzelnen Halter fällt sofort auf: /verify prüft Hash, Merkle-Pfad, Header-Signatur und Sealer-Berechtigung.

Architektur

Wie sich die Knoten finden

Beim allerersten Start braucht jeder Knoten einen Einstieg: eine Liste von Bootstrap-Adressen (hier die drei Autoritäten). Danach hält ihn nichts mehr an diesen Adressen — das Netz findet sich selbst.

Einstieg: Jeder Container bekommt DV_BOOTSTRAP mit mehreren Adressen (http://auth1:8080, auth2, auth3). Docker löst die Namen im internen Netz auf, deshalb reicht das auf jedem Betriebssystem. Die Liste wird nur benutzt, solange ein Knoten weniger als drei lebende Peers kennt.
Austausch: Jede Sekunde tauscht ein Knoten mit ein paar zufälligen Nachbarn seine Peer-Listen aus (Push-Pull, /peers/exchange). So erfährt er von allen, ohne dass ein Zentrum nötig ist — neue Knoten verbreiten sich wie ein Gerücht.
Begrenzte Nachbarschaft: Jeder Knoten spricht mit höchstens 8 Nachbarn (3 pro Runde) und tauscht regelmässig einen davon aus. Der Verkehr pro Knoten bleibt gleich, ob das Netz 12 oder 1000 Knoten hat — vorher prüfte jeder jeden.
Lebenszeichen: Jeder Knoten zählt seinen eigenen Herzschlag hoch, und der wandert mit den Listen mit. Nur ein höherer Herzschlag zählt als «lebt noch». Ein Peer ohne neuen Herzschlag seit 8 Sekunden gilt als weg; Thin Nodes verteilen die Shards neu und laden fehlende nach (Heal).
Neustart: Die Peer-Liste liegt auf der Platte (peers.json) und wird beim Start wieder geladen. Ein Knoten findet sein Netz deshalb auch, wenn kein Bootstrap-Knoten mehr läuft.

Grenzen: Ein Knoten, der weder eine Einstiegsadresse noch gespeicherte Peers hat, findet das Netz nicht. Mehrere Rechner sind im Docker-Aufbau nicht vorgesehen (DV_ADDR und DV_BOOTSTRAP wären anzupassen — ungetestet). Die vollständige Mitgliederliste pro Knoten ist für Zuweisung der Shards nötig; bei sehr grossen Netzen (weit über 100 Knoten) müsste der Austausch grössere Ausschnitte übertragen — getestet ist das Netz mit bis zu rund 20 Knoten. Es gibt noch keine Peer-Authentifizierung: Jeder, der die Genesis-Datei kennt, kann mitmachen und Adressen streuen.

In drei Minuten starten

Docker Engine + Compose-Plugin (`docker compose version`).

cd testnet
bash dv.sh up
bash dv.sh status

Docker Desktop oder Colima (`colima start`), Apple Silicon und Intel.

cd testnet
bash dv.sh up
bash dv.sh status

Docker Desktop mit WSL 2, PowerShell 5.1 oder neuer (vorinstalliert).

cd testnet
powershell -ExecutionPolicy Bypass -File .\dv.ps1 up
powershell -ExecutionPolicy Bypass -File .\dv.ps1 status

Befehlsreferenz

dv.sh / dv.ps1	Wirkung
`up [thin=N] [light=N]`	Netz bauen und starten (Standard: 6 Thin, 2 Light)
`status`	Höhe, Peers, Shard-Abdeckung aller Knoten
`submit N`	N Testdatensätze einreichen
`verify [id]`	Datensatz prüfen: Hash, Merkle-Pfad, Signatur, Sealer
`kill N`	N zufällige Thin-Knoten stoppen (Ausfall simulieren)
`scale thin N`	Anzahl Thin-Knoten ändern
`tamper id`	lokale Kopie eines Datensatzes manipulieren (nur Test)
`smoke`	kompletter Ablauf: Kill/Heal/Scale/Tamper mit Prüfung
`down`	Netz stoppen

Quellcode

Der komplette Knoten (Go, nur Standardbibliothek) liegt im Repository unter testnet/

Nicht enthalten (bewusst — Test-Entwurf)

kein TLS zwischen Knoten, keine Peer-Authentifizierung, keine Registry-Images, kein automatisches Sealer-Failover bei Ausfall einer Autorität.

Läuft das Netz lokal (Port 8080), kann der Simulator oben im Live-Modus echte Zahlen von hier übernehmen. Simulator →

Testnetz