Evaluation Story

MALT's evaluation should show that the system changes the structure-maintenance cost model for evolving graph-normalized data. The current prototype stores immutable payloads in CAS, so the benchmark accounting still reports CAS payload and metadata costs explicitly.

MALT makes relation maintenance explicit. Nested authenticated Roots still require affected ancestor updates, and complete comparisons must count that work alongside payload, ArcTable, index and commitment costs. Lower costs are an experimental question, not an assumption of the design.

The active runner is malt-eval-next; see the executable evaluation boundary. The dimensions below describe intended research comparisons, not a completed campaign or publication-ready results.

Read Latency

Read latency measures root-relative path/query resolution and large-file range reads.

The core read shape is:

Authenticate(root, label steps, resolve) -> destination + traversal evidence
Authenticate(root, label steps, index range) -> count + metadata CID + element bindings
Fetch and bind segment bytes -> requested byte interval

The current typed range operation authenticates element-index bounds, count, an optional metadata CID and ordered element CIDs. The UnixFS reader verifies the referenced application JSON, translates byte intervals into index ranges, verifies those ranges against its selected Root, and hashes and slices chunks. Proof and payload checks are separate measured work; the removed list_range proof format and VerifyRangeBody helper are not current runtime APIs.

Metrics should include:

• end-to-end latency
• CAS GET count and bytes fetched
• ArcTable lookup count for MALT
• retrieval depth
• sequential network rounds
• proof or evidence bytes
• prove latency
• verify latency

Merkle-DAG evidence is the fetched DAG blocks needed for verifier-side hash reconstruction. MALT evidence is ProofList. HAMT evidence is traversal blocks or proofs for directory lookup.

Write Amplification

Write amplification measures cumulative authenticated storage occupation under source-domain mutations.

The main comparison should count all authenticated bytes, not only payload bytes:

• CAS payload blocks
• CAS metadata blocks
• ArcTable records or deltas
• commitment metadata
• root or publication metadata
• objects or records changed

This matters because MALT intentionally moves work into explicit structure maintenance. ArcTable and commitment costs are part of the main comparison, not hidden in a later breakdown.

Cost Breakdown

Cost breakdown explains the end-to-end results.

For reads, useful components include server/runtime dispatch, ArcTable lookup, commitment prove, CAS fetch, and client verification.

For writes, useful components include layout translation, typed candidate generation, ArcTable update, commitment update, CAS writes, and root/publication metadata.

This is attribution, not a separate claim that some components can be ignored.

Sensitivity Studies

Sensitivity studies should vary the design choices that affect the cost model:

• overwrite versus versioned ArcTable
• commitment backend choice
• chunk size
• directory fanout
• file size
• path depth
• version depth
• controlled CAS latency

Proof-off or in-process runs can be useful lower bounds, but they should be labeled as lower bounds rather than main results.

Deferred Semantic Reachability Demo

MALT can express relations that are awkward for embedded-reference DAGs, such as reverse relations, cross-object relations, and multiple views over the same payloads.

Those demonstrations are useful, but they are secondary to the main quantitative evaluation. The primary paper story should focus on read latency, write amplification, and cost attribution.

HAMT is a directory/map-relation baseline. It is not the large-file content layout baseline. Large-file range experiments compare Merkle/UnixFS chunk structure with MALT Positional chunk structure; HAMT affects only directory lookup when the path traverses a HAMT-sharded directory.