You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
apply: admit BatchTransfers blocks, warm the block's accounts in one multi_get
The batch run proved the whole signed path — 892 transfers/s included on-chain —
and then wedged the network: the block-level internal-type guard still listed
BatchTransfers among the genesis-only/deprecated variants and hard-rejected any
block carrying one. The producer admitted batches through the (opened) mempool
gates and included them; every validator rejected the block. Admission, gossip,
value-class, validate and apply had all been opened — this fifth site had not.
BatchTransfers leaves the forbidden list; CreateAccount, BatchRewardClaims and
BatchNodeActivations stay rejected. Every remaining reference to the type across
the codebase is now accounted for.
Block-apply account warm-up goes through ONE RocksDB multi_get instead of one
point read per address. The block already collects and dedupes every affected
address (batch recipients included); only the miss path changes — resident
accounts keep the exact hit/touch semantics. Measured 240-tx blocks spent
543-851 ms in apply, consistent with hundreds of sequential cold point reads on
VPS disks; AccountStore grows load_accounts_batch with a sequential default so
non-RocksDB stores are untouched.
Ladder on the previous image, for the record: 250 TPS 13433/13433 finalized and
500 TPS 22913/22913 finalized (382 sustained), 100% success both — the loads
that previously killed the network.
Tests: 420 integration + 176 state, zero warnings.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0 commit comments