perf(consensus): grow BLS QC verification LRU cache from 256 to 2048 entries

[simonzg]

Why

ValidateQC is called on every incoming vote and block proposal during HotStuff consensus. It attempts to verify the quorum certificate against up to 5 different BLS committee configurations in sequence — each attempt is a full BLS aggregate signature verification, which involves elliptic-curve pairing operations and is one of the most expensive per-call operations in the node.

The validQCs LRU cache short-circuits all of this on a cache hit, returning immediately. However, at 256 entries the cache is far too small for real workloads:

• A 100-validator committee producing blocks every 2 seconds generates ~30 unique QCs per minute.
• During a view change or catch-up, the same QCs are re-presented from multiple peers.
• At 256 entries, QCs from earlier in the current epoch get evicted and must be re-verified when seen again — paying the full BLS pairing cost each time.

What Changed

lru.New(256) → lru.New(2048)

The LRU stores only a string key per entry (no large values). 2048 entries adds negligible memory overhead (< 1 MB) while covering a full epoch's worth of unique QCs without eviction under normal operation.

All existing cache population paths (validQCs.Add) and the cache-hit fast-path (validQCs.Contains) are unchanged — this fix simply makes the cache large enough to be effective.

Expected Impact

• QCs from the current and recent epochs are served from cache on repeat verification, making those calls essentially free (O(1) hash lookup vs. milliseconds of BLS pairing work).
• Reduced CPU spikes during view changes and block catch-up when the same QCs arrive from multiple peers.
• Lower and more consistent block confirmation latency.