transparency-dev / transparency-dev/tessera

[Hammer] Monitor leaf integration

Open
#512 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Go
Stars
238
Forks
56
Avg merge
1d 2h
Merged PRs (30d)
35

Description

Log external APIs reference leaves at four different points:

  1. Add requests: data clients send
  2. Add responses: the index at which the leaf will eventually be integrated
  3. Leaf bundles: where leaves contain the data sent by clients
  4. L0 tiles: listing hashes of leaves included in leaf bundles

Today, the conformance tool / hammer does not check that these four match with each other. For instance:

  • A request to add data X, could return index n, and the entry later integrated at index n might not match
    data X
  • The leaf at index p, might not match with the hash included in the tile at the corresponding position

After speaking with both @roger2hk and @mhutchinson about this, I'm not 100% convinced that the hammer in its current form would allow to implements {all, any of, some of} these checks, but let's at least discuss options.
Some of these can be implemented with integration tests (like other checks the hammer runs), but implementing them with a conformance binary supporting heavy load could ensure that a log implementation doesn't go off track, and that all the https://c2sp.org/tlog-tiles conformance checks live together.

There's precedent here, as we ran into some of these issues with static-ct.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by examining the hammer conformance tool and the integration checks it already runs. Map how Add requests and responses, leaf bundles, and L0 tiles are represented, then determine which consistency checks are feasible under heavy load. Done means the agreed checks are implemented and verified without allowing these references to diverge.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
testing-qa
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.