Craftec Docs
ZephCraft

Architecture

Identity, transport, membership, and content routing — the layers under the grid

A ZephCraft node is a single binary (zeph) whose identity is an Ed25519 keypair — the public key is the node ID is the QUIC key, so every connection is mutually authenticated by construction. There are no privileged roles: every "global" facility — content routing, relays, bootstrap, governance — is a service anyone can run.

The layer stack

   COMPUTE        one WASM runtime, capability grants
   COORDINATION   head registry (owner-signed, sharded)
   DATABASE       CraftSQL — SQLite over content-addressed pages
   STORAGE        CraftOBJ — erasure coding + health lifecycle
   ─────────────────────────────────────────────
   ROUTING        Kademlia DHT (provider/want records)
   MEMBERSHIP     partial views + a converged census
   TRANSPORT      iroh QUIC — one endpoint, many protocols
   IDENTITY       Ed25519 keypair = node ID

Transport

One iroh QUIC endpoint carries every protocol via ALPN (/craftec/ping/1, /craftec/member/1, /craftec/piece/1, /craftec/sqlpage/1, /craftec/invoke/1, /craftec/registry/1, /craftec/dht/1). NAT traversal is hole-punched where possible with relay fallback; the network runs its own relay first (relay1.zeph.craft.ec) with public relays as backup. Wire messages are compact postcard frames carrying a hybrid logical clock timestamp.

Membership — two layers

  • Partial views (HyParView-style): each node keeps a small active view (~5 peers, probed every few seconds) and a passive reserve (~30), refreshed by periodic shuffles. This bounds per-node state at any network size.
  • The converged census: a full member map (node → last-heard) that every node converges on via gossip piggybacked on the shuffles — a CRDT-style union+max merge. The census is what anything needing cluster-wide agreement runs over: registry writer elections, governance sync, health-scan liveness. This layer is why elections are consistent across nodes instead of diverging with each node's partial view.

Content routing — the DHT

Content is found through a Kademlia DHT (zeph-dht): 256-bit XOR keyspace, K=20 buckets, α=3 parallel lookups. Records are Ed25519-signed by their publisher and re-verified everywhere; per publisher, highest sequence wins, and many publishers coexist under one key (that's how a CID has many providers). Records live 48 h and republish at 22 h; dead contacts are evicted after repeated failures with a tombstone so they can't be immediately re-taught. Both records and the routing table persist across restarts, so an infrastructure node reboots with its overlay intact.

Provider records are candidate lists, never availability truth — liveness comes from membership, and durability decisions are made by the storage layer's own health scan.

No consensus, anywhere

The deepest design decision: single-writer-per-identity. Every database has exactly one writer (its owner); every registry entry is signed by its owner; "shared" state decomposes into per-identity writes plus readers that aggregate. There is no blockchain, no gas, no global agreement protocol — which is why the network scales linearly instead of paying O(N) for every byte.

On this page