Layr-Labs / Layr-Labs/d-inference

[feature] Verifiable transparency log for blessed cdhashes and model manifests

Open
#745 2 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Go
Stars
522
Forks
113
Avg merge
17h 26m
Merged PRs (30d)
111

Description

### Component

cross-cutting / not sure

### Problem / motivation

Five files in this repo name a public transparency log as the intended fix for a residual gap, and none of them points at an implementation:

- `docs/architecture/security/attestation.md:88` — "version pinning is intended to come from reproducible builds plus a public transparency log of blessed cdhashes"
- `docs/architecture/security/attestation.md:33` — `binaryHash` "is used only for drift telemetry and transparency-log matching"
- `docs/architecture/security/identity-binding.md:100`
- `docs/architecture/decisions/apns-code-attestation.md:48`
- `docs/provider/security-model.md:41`

We built one — for an unrelated anonymous-publication protocol, where descriptor distribution had the same shape of problem. It is finished, adversarially tested, mutation-verified, and has a second implementation in another language sharing no code. If it is useful here we would rather contribute it than have two projects write the same Merkle tree.

We think it closes a second gap too. `docs/architecture/operations/model-registry.md` describes a SHA-256 chain that is complete except at its root: a provider verifies files against the manifest **the coordinator handed it**, and the coordinator verifies a provider's `WeightHash` against **its own catalog** (`coordinator/registry/registry.go:1595-1622`). Every hash is checked against the coordinator's database, so nothing lets a consumer establish that the manifest it was routed against is the one the fleet got — and a coordinator that behaved perfectly could not prove that it had. Same primitive.

**Full proposal, with the design, the testing, and what it does *not* claim:**
https://github.com/Jtensetti/nomad-darkbloom/blob/claude/nomad-transparency-log-proposal/docs/proposals/verifiable-transparency-log.md

Two things we would flag up front:

- A log does not make the log operator honest. It makes equivocation detectable and the evidence transferable; preventing it needs more than one log or cosigning witnesses.
- The freshness half is not optional. Without it the trust just moves from the database to the checkpoint.

Filed as a feature request rather than a PR because CONTRIBUTING.md says surprise PRs touching attestation are likely to bounce — that seems right, and we would rather scope it with you.

Licensing would need sorting before code moves (LICENSE §2(c) requires a CLA, and the code is currently ours). Raising it so you don't have to.

We have no prior contact with Eigen Labs, and we are not claiming our own project is production ready — its readiness registry stands at 27 partial, 2 met, 1 blocked. The transparency log is one of the finished pieces, which is why it is the one we are offering.

---
_Greetings, [jonatan@tensetti.se](mailto:jonatan@tensetti.se)_

### Proposed solution

RFC 6962 Merkle tree + Ed25519-signed checkpoints (origin-bound), inclusion and consistency proofs, a freshness window, and an absorbing split-view state that yields transferable evidence. Blessed cdhashes and model-manifest digests become log entries; the coordinator publishes signed checkpoints; providers and consumers accept a build or manifest only with an inclusion proof against a checkpoint they hold and only while it is fresh. Design, testing and limits: https://github.com/Jtensetti/nomad-darkbloom/blob/claude/nomad-transparency-log-proposal/docs/proposals/verifiable-transparency-log.md

### Alternatives considered

_No response_

### Scope notes

Touches attestation and the model registry - the two areas CONTRIBUTING.md flags. Coordinator gains a log and a checkpoint endpoint; provider-swift gains

Contributor guide

Open the contributing guide

Research direction

Read the linked transparency-log proposal first, then review the five security documentation references and coordinator/registry/registry.go:1595-1622. Scope the coordinator log and checkpoint endpoint alongside provider-swift verification, including inclusion, consistency, freshness, and split-view evidence. Done means the agreed design is implemented and its testing and licensing boundaries are resolved.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, swift
Domain
backend-api-design, cryptography, distributed-systems, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.