linera-core: extract the confirmed-certificate sender from ValidatorUpdater - #6624
Draft
ndr-ds wants to merge 5 commits into
Draft
linera-core: extract the confirmed-certificate sender from ValidatorUpdater#6624ndr-ds wants to merge 5 commits into
ndr-ds wants to merge 5 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 anArc<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
ValidatorUpdaterinto a reusable primitive,ConfirmedCertificateSender<S, N, L>(newlinera-core/src/updater/confirmed_sender.rs), holdingstorage, aRemoteNode, 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_storage→read_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 smallLocalChainStatetrait instead.ValidatorUpdaterimplements 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_informationkeeps its shape: Phase 1 delegates to the primitive; Phase 2 (consensus round sync) stays inValidatorUpdater, since it genuinely needs the local worker.Everything stays crate-internal (
pub(crate)) — the consumer is inlinera-core.Intended as a pure refactor — no behavior change for the client.
Test Plan
cargo check -p linera-corecargo clippy -p linera-core --all-targets --all-features -- -D warnings— zero warningscargo doc --no-deps -p linera-core --all-featureswith-D warnings— cleancargo test -p linera-core --no-run— tests still compilecargo +nightly fmt -p linera-core -- --check— cleanbash scripts/check_chain_loads.sh— no unexpected chain loadscargo machete— cleanRelease Plan
Links
One deliberate delta worth a reviewer's eye:
update_admin_chainis now Phase-1-only. It previously calledsend_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-levelsend_chain_informationcalls 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) -> hashindex (#5233, 2026-01-13) always covers stored certificates — buttestnet_conwayhas 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 behindwith_height_index_backfill():ValidatorUpdaterenables it, and consumers that only borrow another component's storage get the fallback read without ever writing to it.