Leader-selected rent is not replicated at restart boundaries #200

Problem

Leader and verifier can execute the same ledger with different rent parameters. During the v2.0.0-rc.1 remote test, the leader used 5080 lamports per byte while the verifier used the default 6960. Eight 128-byte account materializations funded with 1,300,480 lamports succeeded on the leader but failed on the verifier with InsufficientFundsForRent { account_index: 1 }, which required 1,781,760 lamports.

The first checkpoint mismatch was at slot 302715600: expected 16266377927445660123, observed 10480558111038198992. Both nodes had an identical published blockstore prefix. The mismatch preceded the first commit canary; account preparation exposed the rent discrepancy.

Reproduction

Run a leader with rent below Rent::default() and a verifier using the default. Materialize accounts funded at the leader's rent-exempt minimum and replay them on the verifier. This was observed on MBV v2.0.0-rc.1 with Engine 0.21.0 (fb3480d).

Expected

The leader selects rent at startup and may lower it on subsequent restarts. Followers must apply that rent at the same ledger boundary, without restarting or downloading a fresh snapshot for each change. A lagging verifier must finish earlier history with the previous configuration.

Extend the existing signed Reset with the lamports-per-byte rate (u64) and the complete active feature list (Vec<Pubkey>). Do not replicate deprecated Rent fields or introduce a new message. The feature list replaces the previous set, including deactivations; leaders use Engine's default feature list, without host configuration.

Apply each reset while execution and simulation are quiesced. Runtime rent, the Rent sysvar, active features and program environments must agree before work resumes.

Keep one persistent Runtime account mode, using existing read-only/no-sync mechanics. Rent and feature accounts must be included in authenticated account state and restored through local recovery and snapshots. Seed runtime accounts, locally supplied programs and generated sysvars only at genesis; startup must not overwrite restored state. Recover historical configuration first, then publish the leader's requested rent and current Engine defaults through a new reset.

Keep protocol version 1. There are no production deployments requiring storage-format migration or backward compatibility.

Accepted limitation: a crash after a reset becomes durable but before its account-state application can leave an unapplied reset-only ledger tail. Reset does not advance slot or transaction count, so existing recovery checks can miss it. Tracking applied-record progress is deferred; this rare crash window is accepted for this change.

Context

Inspected Engine master at 5cc03bee1d05251fc8be1b46affbf4771045b7d9 (baseline before the current uncommitted implementation):

• Reset carries only a slot.
• Keeper rent is fixed at startup; reset clears volatile state.
• Startup seeds the Rent sysvar from builder rent.
• Replication already quiesces execution before applying a reset.