Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Improve txpool_content performance for high-frequency polling

Abierto
  • ¿Algo no está bien?
#35 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
rust
Área
api, blockchain, performance

Línea de trabajo

Comienza reproduciendo llamadas repetidas a txpool_content mediante HTTP y WS eth_call durante una sincronización de mainnet en vivo, midiendo las transacciones recuperadas por segundo y el tamaño del pool. Compara los costes del recorrido completo del pool y de la serialización JSON descritos en el issue. Se considera terminado cuando se haya implementado un enfoque concreto de mayor rendimiento o de recuperación incremental y se haya medido su rendimiento frente al límite máximo informado de ~200 tx/s.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary
When polling txpool_content via the Ethereum JSON-RPC, I’m seeing a hard ceiling of ~200 transactions per second retrieved, even when the node’s actual mempool is much larger and incoming rate is higher.

This is likely due to the heavy JSON serialization and full-pool traversal in each RPC call. The endpoint works fine for occasional inspection, but is too slow for real-time monitoring or ingestion scenarios that require higher throughput.

Reproduction
1. Run reth with default RPC settings and a live mainnet sync.
2. Call txpool_content repeatedly (HTTP or WS eth_call) as fast as possible from a single client.
3. Measure transactions retrieved per second — result is consistently ~200 tx/s even with thousands of txs pending in the pool.

Expected behavior
• Ability to retrieve higher throughput from the mempool via RPC (e.g., closer to the actual incoming tx rate), especially for local/IPC clients.
• Option to fetch incremental changes instead of the full pool every time.

Why this matters
• Full-pool polling is currently the only way to get a complete snapshot of pending and queued txs via JSON-RPC.
• Many applications (analytics, MEV research, relays, custom ordering engines) need near-real-time mempool state but can’t efficiently use txpool_content due to this throughput cap.

Potential solutions
1. Add a streaming or incremental API — e.g., a txpool_diff or subscription that streams full tx bodies for new/removed txs (similar to eth_subscribe:newPendingTransactions but with bodies, not just hashes).
2. Expose a binary/IPC interface — avoid JSON encoding overhead for local clients.
3. Allow partial fetches — parameters to limit to N txs, specific senders, or time ranges to reduce traversal cost.
4. Optimize serialization — e.g., pre-encode pool entries to JSON or use more efficient traversal for RPC dumps.

Lenguaje dominante
Rust
Estrellas
8
Forks
9
Merge medio
7 h 25 min
PR fusionados (30 d)
2

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de evstack/ev-reth

Todos los issues de evstack/ev-reth

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.