From model to running network — the DataVeritas testnet

The simulator on this site works through the model behind DataVeritas: how many copies a shard needs, how fast a network heals after a node dies, how storage load spreads across a thousand participants. It's honestly labelled as a model — every number is computed, none of them measured.

As of today there's a next step: dvnode, a real reference node written in Go that spins up as a small testnet in Docker. No more model — real HTTP nodes sealing real blocks, distributing real records, and answering real verification requests.

What the testnet shows

Three authorities seal blocks in round-robin order under Proof of Authority — one every 2.4 seconds. Thin nodes take on a share of the shards via rendezvous hashing; light nodes hold only headers and verify via Merkle path and signature. If a node dies, the others automatically re-replicate the orphaned shards.

That's not a claim — we measured it. The automated smoke test (testnet/smoke.sh) brings up a network of 3 authorities, 1 full node, 6 thin nodes and 2 light nodes and runs it through a complete failure-and-heal cycle:

• 200 records submitted, all 200 sealed with a valid signature and confirmed via /verify with a matching hash, Merkle path, header signature and sealer authorization.
• 2 of 6 thin nodes killed (≈30%) — afterwards every shard still had at least one holder, and a sample of 50 records still verified completely.
• Scaled up to 12 thin nodes — shard coverage was fully restored within 15 seconds.
• A record was tampered with everywhere it was replicated (14 copies). Verification on a light node — which doesn't hold the record itself and has to fetch it from a peer — correctly failed: hash_matches: false, every other check still true. The tampering was pinpointed precisely, not just flagged as "something's wrong."

The whole run takes under three minutes.

What it isn't, yet

The testnet is a test entwurf, not a production system, and its own documentation says so plainly: no TLS between nodes, no peer authentication, no automatic sealer failover if an authority goes down (all three authorities stay up throughout the test). The three authority keys in the repository are deliberately public dev keys, clearly marked as such — a production deployment needs its own, secret keys.

Try it yourself

cd testnet
./dv.sh up
./dv.sh status
./dv.sh smoke

All commands, the architecture, and the three OS walkthroughs (Windows, macOS, Linux) are on the testnet page. If you like, connect the simulator's live mode to a locally running testnet and watch the real chain height instead of the modelled one.