refactor(lru): switch LRU implementation to golang-lru

[brbrr]

Replaces geth LRU implementation with golang-lru library. Adds a wrapper package, which exposes only API that are currently used.

[Copilot]

Pull request overview

This PR refactors the codebase’s LRU cache usage to rely on github.com/hashicorp/golang-lru/v2 (and simplelru) instead of the previous go-ethereum LRU helpers, centralizing construction logic in utils.

Changes:

• Added utils.NewLRU and utils.NewSimpleLRU helpers to standardize LRU construction.
• Migrated RPC trace caches and pending pre-latest caching to HashiCorp LRU implementations.
• Updated aggregated bloom filter cache to use the new LRU and adjusted its constructor/tests accordingly.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
utils/lru.go	Introduces shared constructors for thread-safe and non-thread-safe LRU caches.
sync/pending_polling.go	Switches the pre-latest “seen-by-parent” cache to simplelru via utils.NewSimpleLRU.
rpc/v8/handlers.go	Updates RPC v8 handler trace cache construction to use utils.NewLRU.
rpc/v9/handlers.go	Updates RPC v9 handler trace cache construction to use utils.NewLRU.
rpc/v10/handlers.go	Updates RPC v10 handler trace cache construction to use utils.NewLRU.
blockchain/aggregated_bloom_filter_cache.go	Replaces the previous LRU cache with HashiCorp’s cache and uses utils.NewLRU; changes constructor signature.
blockchain/blockchain.go	Adjusts blockchain initialization to match the aggregated bloom cache constructor change.
blockchain/aggregated_bloom_filter_cache_test.go	Updates tests to use the new aggregated bloom cache constructor and constant size.
go.mod	Adds github.com/hashicorp/golang-lru/v2 as a direct dependency.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[codecov]

Codecov Report

❌ Patch coverage is 89.28571% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 76.28%. Comparing base (6fc5100) to head (3ad6be2).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
utils/lru.go	85.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3674      +/-   ##
==========================================
+ Coverage   76.16%   76.28%   +0.12%     
==========================================
  Files         396      397       +1     
  Lines       36585    36560      -25     
==========================================
+ Hits        27865    27890      +25     
+ Misses       6743     6692      -51     
- Partials     1977     1978       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[rodrodros]

Looks good, looking forward to see some benchmarks, and why SimpleLRU was used in someplaces. What about using 2 queues LRUs as well?

[brbrr]

@rodrodros I've assumed that geth was using golang-lru under the hood, so I thought it would be 1-1 migration. I've double checked, and they use their own impl. I'll run the tests and post it here as a comment.

[rodrodros]

I am thinking it is better to create a package inside utils/lru/lru.go so that imports are called lru by default. We would wrap whatever implementation we used from there

[brbrr]

tl;dr: golang-lru is ~20–35% slower per-op + 1 alloc per Add. Absolute deltas are ns-scale. While the implementation is slower, I think it's fine, since the callsites are not bottlenecked by the LRU performance, but rather by IO/network.

Latency (ns/op)

Workload	Key / Size	old (ethereum)	new (hashicorp)	Δ	p
Add	int / 128	78.85 ± 3%	104.35 ± 3%	+32.3%	0.000
Add	int / 8192	102.2 ± 4%	138.5 ± 4%	+35.5%	0.000
Add	bloomKey / 16	66.45 ± 3%	89.70 ± 4%	+35.0%	0.000
Add	feltKey / 128	85.81 ± 3%	110.00 ± 1%	+28.2%	0.000
GetHit	int / 128	18.04 ± 2%	24.27 ± 2%	+34.5%	0.000
GetHit	int / 8192	23.89 ± 6%	28.20 ± 1%	+18.0%	0.000
GetHit	bloomKey / 16	21.43 ± 1%	27.93 ± 4%	+30.3%	0.000
GetHit	feltKey / 128	28.80 ± 2%	32.22 ± 1%	+11.9%	0.000
GetMiss	int / 128	18.29 ± 3%	24.31 ± 2%	+32.9%	0.000
GetMiss	bloomKey / 16	17.91 ± 0%	24.86 ± 15%	+38.8%	0.000
GetMiss	feltKey / 128	21.03 ± 6%	26.07 ± 3%	+24.0%	0.000
Mixed 80/20	int / 128	52.16 ± 4%	56.95 ± 1%	+9.2%	0.001
Mixed 80/20	bloomKey / 16	48.20 ± 12%	53.02 ± 6%	+10.0%	0.022
Mixed 80/20	feltKey / 128	63.42 ± 10%	70.09 ± 8%	+10.5%	0.023
Parallel mixed	int / 128	233.0 ± 1%	289.8 ± 2%	+24.4%	0.000
Parallel mixed	bloomKey / 16	210.8 ± 8%	232.7 ± 2%	+10.4%	0.000
Parallel mixed	feltKey / 128	277.5 ± 5%	319.5 ± 5%	+15.1%	0.000
SimpleAdd (no lock)	feltKey / 10	69.34 ± 3%	89.58 ± 6%	+29.2%	0.000
SimpleGetHit (no lock)	feltKey / 10	24.06 ± 9%	24.12 ± 5%	~	0.469
SimpleMixed (no lock)	feltKey / 10	52.83 ± 10%	56.30 ± 11%	~	0.971
geomean		51.33	62.26	+21.3%

Memory (B/op, allocs/op)

Workload	Key / Size	old B/op	new B/op	old allocs	new allocs
Add	int / 128	0	80	0	1
Add	int / 8192	0	80	0	1
Add	bloomKey / 16	0	80	0	1
Add	feltKey / 128	0	96	0	1
GetHit (any)	—	0	0	0	0
GetMiss (any)	—	0	0	0	0
Mixed	int / 128	0	8	0	0
Mixed	bloomKey / 16	0	8	0	0
Mixed	feltKey / 128	0	9	0	0
Parallel	int / 128	0	8	0	0
Parallel	bloomKey / 16	0	8	0	0
Parallel	feltKey / 128	0	9	0	0
SimpleAdd	feltKey / 10	0	96	0	1
SimpleGetHit	feltKey / 10	0	0	0	0
SimpleMixed	feltKey / 10	0	9	0	0

Summary

Path	Cost change
Reads (hit/miss)	+12% to +39% latency, 0 allocs
Writes (Add)	+28% to +35% latency, +1 heap alloc / 80–96 B per Add
Mixed 80/20 R/W	+9% to +11%
Concurrent	+10% to +24% under contention
Overall (geomean)	+21.3%