[ndr-ds]

⚠️ BREAKING STORAGE-FORMAT CHANGE — do not backport to a branch with live data without a migration. See "Release Plan".

Motivation

LogView::read(range) fetches a contiguous range of entries as one point read per entry. On the validator side this is what serves received_log pages, and it is the per-entry cost behind the PM restart storms: a 20,000-entry page becomes 20,000 keys, chunked by the ScyllaDB backend into ~203 CQL IN statements of 99 keys each (MAX_MULTI_KEYS, scylla_db.rs:63).

The reason it cannot do better today is the key encoding. derive_tag_key serializes the index with BCS, and BCS writes integers little-endian:

index	key bytes
0	00000000
1	01000000
256	00010000
65536	00000100

Those sort as 0, 65536, 256, 1, … — so a contiguous range of indices is scattered across the whole key space. The 99 keys in each IN statement land on ~99 different pages of a multi-GB partition instead of 1–2 adjacent ones, and k >= start AND k < end cannot express the range at all.

This is not a new idea in the codebase: CustomSerialize exists precisely for this (common.rs, doc: "Sometimes we need a serialization that is different from the usual one and for example preserves order"), and BlockHeight already uses to_be_bytes(). LogView simply never used it.

Measured context on testnet_conway: one PM chain's received_log holds 4,466,673 entries, with one validator's sync tracker 3,871,738 entries behind. Walking that on restart drives validator statement-class IOPS from ~100/s to ~5,500/s and read p99 from 6 ms to 4.3 s for 20–60 minutes.

Proposal

Append the index big-endian, so key order matches index order and the entries of a range are adjacent in any store that keeps keys sorted.

fn append_index(mut key: Vec<u8>, index: u32) -> Vec<u8> {
    key.extend_from_slice(&index.to_be_bytes());
    key
}

Applied at the three sites that derive an entry key: pre_save, get, read_context.

Deliberately not included here: changing read_context to issue a range scan. The store trait exposes only prefix scans (find_keys_by_prefix / find_key_values_by_prefix), so a range read needs a new store API across every backend. That is a separate PR — and most of the win is already in the locality: adjacent keys mean each IN chunk reads ~1 storage chunk rather than ~99.

What this does not change

• No hash changes. LogView::hash is computed over read(..) values (hasher.update_with_bcs_bytes(&elements)), never over keys. State hashes and consensus are unaffected.
• key_value_store_view.rs has its own unrelated KeyTag::Index; it is untouched.
• No API change: append_index is private and the public surface is identical.

Test Plan

Two unit tests in log_view.rs:

• index_keys_sort_like_indices — sorting keys for [0, 1, 2, 255, 256, 257, 20_000, 65_536, u32::MAX] yields the indices in ascending order.
• a_range_of_indices_is_a_contiguous_range_of_keys — every key in 1000..1100 lies between the range's first and last key, and the neighbours immediately outside sort outside it. This is the property that makes a page adjacent in storage, not merely ordered.

Verified the tests actually catch the bug rather than merely passing: flipping to_be_bytes back to to_le_bytes (today's behaviour) makes both fail; restoring it makes both pass.

$ cargo test -p linera-views --lib views::log_view
test result: ok. 2 passed; 0 failed

Not yet done, and worth doing before this is more than a draft: an end-to-end measurement of a large read(range) against a real ScyllaDB backend, to put a number on the improvement rather than an argument.

Release Plan

• Backporting is not possible but we may want to deploy a new devnet and release a new SDK soon.

Every existing LogView becomes unreadable — entries written with LE keys are not found by BE lookups, and stored_count still claims they exist, so read fails with MissingEntries. This affects received_log, confirmed_log and every other LogView in chain state. There is no storage-format version constant in the repo to gate this on (checked: no STORAGE_VERSION / FORMAT_VERSION in linera-views or linera-storage).

For testnet_conway this needs either a migration pass that rewrites log keys, or acceptance that the data is re-synced — that decision is deliberately not part of this PR.

Links

• reviewer checklist
• Complementary, not a substitute: Periodically re-run the background received-certificate sync to keep trackers fresh #6632 keeps the sync tracker fresh so a restart only walks a small delta. This PR makes any walk — including the cold-takeover case Periodically re-run the background received-certificate sync to keep trackers fresh #6632 cannot help, where a reassigned chain starts from tracker 0 — cheap per entry.