salt: plain_value_and_slot accessor + drop hashbrown/serde feature

[deepld]

Summary

Two independent changes to the salt crate:

1. PlainStateProvider::plain_value_and_slot — give callers that need the slot, or the encoded record itself, a way to skip plain_value's Vec<u8> copy.
2. Drop the hashbrown/serde feature — hand-write Serialize/Deserialize for SaltProof::levels so we no longer pull serde_core ≥ 1.0.221 through hashbrown, which was breaking downstream alloy-tx-macros 1.0.23.

Commit history

This PR is intentionally kept as three commits (not squashed) to preserve the perf investigation:

1. 05cf399 — initial change: plain_value_and_slot + #[repr(align(8))] on SaltValue.
2. 14f9430 — revert just the repr(align(8)) part after the perf-pr benchmark flagged it.
3. 279e687 — drop hashbrown/serde feature flag; hand-roll levels (de)serialization.

---

Part 1 — plain_value_and_slot (commits 1 & 2)

Changes that stay (commit 1)

salt/src/state/state.rs

• Add pub fn plain_value_and_slot(plain_key, hint) -> Result<Option<(SlotId, SaltValue)>, S::Error>.
• Refactor plain_value to delegate to it (no behavior change for existing callers).
• New test test_plain_state_provider_plain_value_and_slot covering: happy path with slot cross-check (verifies the returned SlotId matches where the entry actually lives by reading store.value((bucket_id, slot).into())); wrong-hint short-circuit; missing-key.

Why

Some callers only need (SlotId, SaltValue) — for example follow-up slot-addressed operations, or reading the encoded record without copying it onto the heap. The existing plain_value always allocated a Vec<u8>. The new method exposes the underlying shi_search result directly without that allocation.

What got reverted (commit 2)

The first commit also added #[repr(align(8))] to SaltValue on the theory that aligned u64 loads would speed up PartialEq/Clone. perf-pr ran update 10000 KVs on it and showed the opposite:

Threads	Baseline (Kelem/s)	With align(8)	Δ
1	49.10	43.08	−12.27%
2	88.82	81.17	−8.61%
4	159.12	150.06	−5.69%
8	276.22	265.00	−4.06%
16	405.55	392.11	−3.31%

Linear convergence from −12% (1T) toward −3% (16T) is the textbook signature of a memory-bound regression: per-core working set blows past L1, multi-thread parallelism then hides part of the latency.

Root cause: Option layout, not SaltValue itself

SaltValue is already 8-aligned in most containers (Vec, Box, BTreeMap<SaltKey, SaltValue>) because the surrounding alignment naturally puts it on an 8-byte boundary. So repr(align(8)) is a no-op for mem_store's BTreeMap<SaltKey, SaltValue> — which is the bulk-storage case.

The one place where repr(align(8)) actually changes layout is inside Option<SaltValue>. [u8; 94] has no niche (every bit-pattern is a valid SaltValue), so the Option discriminant must be stored as a real byte. With align=1 it sits at offset 0 and SaltValue follows immediately at offset 1; with align=8, SaltValue must start at offset 8, so the compiler inserts 7 bytes of padding after the discriminant — plus 2 bytes of trailing padding inside SaltValue itself to make its size a multiple of 8. Net growth: +9 bytes per Option<SaltValue>:

align=1 (95 B):
[disc:1][data:94]

align=8 (104 B):
[disc:1][padding:7][data:94][tail-pad:2]
        ↑                    ↑
        forced 7 B           SaltValue size rounded up to align

And the hot-path containers all carry Option<SaltValue>, not raw SaltValue:

• EphemeralSaltState::cache: HashMap<SaltKey, Option<SaltValue>> — entry size grew 104 → 112 B (+7.7%)
• StateUpdates::data: BTreeMap<SaltKey, (Option<SaltValue>, Option<SaltValue>)> — entry value grew 190 → 208 B (+9.5%)

For update 10000 KVs that's roughly +260 KB of working set, enough to push single-threaded execution past per-core L1 (32–64 KB).

The "aligned u64 load" benefit was also overstated: unaligned MOVQ is zero-cost on x86 since Sandy Bridge, and a 94-byte struct unavoidably spans cache lines either way. Net: paid ~10% memory locality for no real ALU win.

The cosmetic SaltValue::new rewrite that was bundled in the first commit (constructing Self first vs. building a local array) is also reverted, since it was added together with the alignment change for the same speculative-perf reason.

---

Part 2 — drop hashbrown/serde feature (commit 3)

Why

salt and ipa-multipoint were enabling hashbrown/serde purely so SaltProof::levels: FxHashMap<BucketId, u8> could derive Serialize/Deserialize. That feature transitively bumps serde_core to ≥ 1.0.221, which in turn breaks downstream alloy-tx-macros 1.0.23 (it doesn't compile against the newer serde_core). Dropping the feature unblocks downstream consumers without forcing them onto a different alloy version.

Changes

• salt/Cargo.toml, ipa-multipoint/Cargo.toml: drop the hashbrown/serde feature.
• Cargo.lock: regenerate (loses the serde_core 1.0.221+ line).
• salt/src/proof/prover.rs: hand-write Serialize/Deserialize for the levels field via a #[serde(with = "fx_hashmap_serde")] module. Implementation:
  • Serialize: collect entries into a Vec, sort by BucketId ascending, emit as a serde map. Sort is required so the encoded proof bytes are deterministic across provers — FxHashMap iteration order is not stable.
  • Deserialize: drive a Visitor over the map, building an FxHashMap with the size hint. No order assumption on input.

This is the only FxHashMap in the crate that crossed the serde boundary, so a single hand-rolled module covers it.

---

Test plan

• cargo build -p salt --all-targets clean
• cargo test -p salt --lib state::state::tests::test_plain_state_provider_plain_value_and_slot passes
• cargo test -p salt proof:: passes (covers SaltProof round-trip serde)
• full cargo test -p salt (CI)
• perf-pr update 10000 KVs back within noise band after the revert (CI)
• downstream alloy-tx-macros 1.0.23 consumer builds against this branch (CI / manual)

[github-actions]

Performance Benchmark Comparison

Compared 5 benchmark(s) against the latest main baseline.

Detailed Comparison

Benchmark	Baseline Throughput (Kelem/s)	New Throughput (Kelem/s)	Change
update 10000 KVs/1 threads	49.10	42.41	-13.62%
update 10000 KVs/2 threads	88.82	79.73	-10.24%
update 10000 KVs/4 threads	159.12	147.59	-7.25%
update 10000 KVs/8 threads	276.22	260.90	-5.55%
update 10000 KVs/16 threads	405.55	387.58	-4.43%

[flyq]

LGTM