Layr-Labs / Layr-Labs/d-inference
[feature] Verifiable transparency log for blessed cdhashes and model manifests
- 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
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