Work on the Rust client has begun

Implementation of a Rust client for Lakat has started. It follows a written technical specification rather than being derived directly from the earlier Python prototype, so that the wire formats and state-transition rules are pinned down before they are baked into code. The Python implementation remains the reference for concrete encodings, and the two are cross-checked against shared test vectors.

Why Rust

Layers 0–3 of a Lakat node — primitives, objects, authenticated structures and the state machine — have to be a pure, deterministic library: given the same store contents and the same inputs they must produce byte-identical objects. Object identity is the hash of the encoding, so any ambient non-determinism forks the address space. Everything non-deterministic (time, randomness, network, key material) enters through injected interfaces. Rust's type discipline makes that separation enforceable rather than aspirational, and the state machine contains no async at all, which is what keeps it testable.

What the specification covers

The specification is eighteen documents describing a node as five layers, each depending only on those below it:

  • 0 – Primitives: CIDs, deterministic CBOR, hashing, namespaces, storage keyspace, identity
  • 1 – Objects: buckets, the immutable content units
  • 2 – Authenticated structures: the Merkle trie, its transaction model and proofs
  • 3 – State machine: submits, branches, validation
  • 4 – Protocol: branch requests, Proof of Review, lignification, merge, networking
  • 5 – API: the node-external surface

Three properties distinguish Lakat from both a blockchain and from git, and the specification is organised around them. There is no global state: no single chain, no canonical head, no global consensus — every branch has its own head and its own contributor set, and two branches may disagree permanently. Content and history are separate graphs: the bucket graph and the submit graph are independent, so two branches sharing no submits may still share most of their buckets. And finality is per-branch and deferred: competing proposed heads are wrapped in short-lived branches called sprouts and resolved through lignification.

Where it stands

The workspace currently holds five crates covering layers 0 to 2 — roughly 3,900 lines of Rust with around 80 tests:

  • lakat-primitives — CID, multihash, varint, deterministic codec, length-prefixed text, namespaces, profiles
  • lakat-types — bucket, submit, submit trace, branch state, config, interaction
  • lakat-traits — the injected interfaces: content store, oracle
  • lakat-trie — the Merkle trie: nodes, views, transactions, proofs
  • lakat-store — store backends: in-memory, file, RocksDB

What comes next

The next milestone is lakat-core, the state machine: branch creation, content submits and full validation. Reaching it puts the Rust client at parity with the Python implementation, with signature verification, content-addressed storage guarantees and name-collision checks that the prototype lacks. After that come the RPC binding and CLI with an interop harness against Python, then networking (read-only participation first), then consensus — Proof of Review, and lignification under simulation before deployment. Merge comes last: it depends on ancestry queries, contributor unions and a resolution policy, and it is the least specified part of the system.

Timeline

The current estimate for the first usable client release is 15 November 2026. That target covers layers 0 to 3 plus the RPC and CLI surface — enough to create a branch, make submits and validate them against the specification. Networking, consensus and merge follow after. As with any estimate on a system still being specified as it is built, treat the date as an intention rather than a commitment.

If you would like to help, the work is public — see our GitHub repositories or write to [email protected].