Skip to content

linera-core: extract the confirmed-certificate sender from ValidatorUpdater - #6624

Draft
ndr-ds wants to merge 5 commits into
testnet_conwayfrom
ndr-ds/exporter-relay-primitive
Draft

linera-core: extract the confirmed-certificate sender from ValidatorUpdater#6624
ndr-ds wants to merge 5 commits into
testnet_conwayfrom
ndr-ds/exporter-relay-primitive

Conversation

@ndr-ds

@ndr-ds ndr-ds commented Jul 25, 2026

Copy link
Copy Markdown
Contributor

Motivation

Groundwork for making validators replicate blocks to each other directly, so that every validator in the committee becomes a full node.

The plan is for the chain workers in the server binary to push each block they execute straight to the other validators: at that moment the certificate and its blobs are already in memory, so nothing has to be re-read from storage or relayed through another process. Those workers need the client's existing dependency-upload logic — uploading blobs the destination is missing, and pushing the admin chain when the destination does not yet know the committee that signed the certificate.

Today that logic is welded to ValidatorUpdater, which owns an Arc<Client<Env>>. The server binary has no client. The confirmed-certificate path, however, only ever needs storage reads plus a validator connection.

Proposal

Extract the confirmed-certificate synchronization path out of ValidatorUpdater into a reusable primitive, ConfirmedCertificateSender<S, N, L> (new linera-core/src/updater/confirmed_sender.rs), holding storage, a RemoteNode, the admin chain id, and the upload batch size — no client, wallet, or signer.

Moved: send_confirmed_certificate (the dependency-upload retry loop, preserved verbatim), the Phase-1 height sync, read_certificates_for_heights, initialize_new_chain_on_validator, update_admin_chain, send_chain_info_for_blobs. Local-node reads become direct storage reads (read_blobs_from_storageread_blobs + all-present check; cert-by-height → read_certificates_by_heights).

Chain state views must not be loaded outside the chain worker (scripts/check_chain_loads.sh: loading one elsewhere races with the worker and can corrupt data), so the two chain-level reads the path needs — the admin chain's local tip, and the block-hash fallback — go through a small LocalChainState trait instead. ValidatorUpdater implements it over its local worker (chain_info / get_block_hashes), exactly as before; the server's chain workers will supply their own implementation.

ValidatorUpdater::send_chain_information keeps its shape: Phase 1 delegates to the primitive; Phase 2 (consensus round sync) stays in ValidatorUpdater, since it genuinely needs the local worker.

Everything stays crate-internal (pub(crate)) — the consumer is in linera-core.

Intended as a pure refactor — no behavior change for the client.

Test Plan

  • cargo check -p linera-core
  • cargo clippy -p linera-core --all-targets --all-features -- -D warnings — zero warnings
  • cargo doc --no-deps -p linera-core --all-features with -D warnings — clean
  • cargo test -p linera-core --no-run — tests still compile
  • cargo +nightly fmt -p linera-core -- --check — clean
  • bash scripts/check_chain_loads.sh — no unexpected chain loads
  • cargo machete — clean

Release Plan

  • Nothing to do / These changes follow the usual release cycle.

Links

One deliberate delta worth a reviewer's eye: update_admin_chain is now Phase-1-only. It previously called send_chain_information (Phase 1 + Phase 2); the primitive has no worker, so it does the height sync only. This helper runs inside the retry loop purely to deliver the admin chain's confirmed epoch/committee events, so the admin chain's pending consensus round should have no bearing on whether the certificate is then accepted. Top-level send_chain_information calls are unchanged and still run Phase 2.

Note on read_certificates_for_heights: the block-hash-list fallback and its height-index backfill are kept. An earlier version of this branch dropped them on the assumption that the (chain_id, height) -> hash index (#5233, 2026-01-13) always covers stored certificates — but testnet_conway has been running since 2025-08-27, so its storage genuinely contains certificates written before that index existed, and dropping the fallback would have silently skipped them. The write-back is now gated behind with_height_index_backfill(): ValidatorUpdater enables it, and consumers that only borrow another component's storage get the fallback read without ever writing to it.

@ndr-ds ndr-ds changed the title linera-core: extract ConfirmedCertificateSender from ValidatorUpdater linera-core: extract the confirmed-certificate sender from ValidatorUpdater Jul 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant