Cronos v1.8: cómo leer una lista vacía de transacciones pendientes
El explorador ya muestra el bloque previsto para la actualización de Cronos. El mempool opcional de la aplicación cambia dónde se ven las transacciones pendientes y qué significa una respuesta vacía.
Ilustración conceptual generada con IA: una persona técnica mira un compartimento con sobres junto a otro vacío. Representa distintas vistas del pool de transacciones pendientes; no reproduce una interrupción observada ni una interfaz real de Cronos.
Puntos clave
- Chainstack registró el mantenimiento como completado el 22 de octubre a las 08:00 UTC. Cronos Explorer muestra el bloque previsto, 101.485.000, con hora 07:52:24 UTC y conectado con su sucesor.
- El mempool de la aplicación es opcional. Al activarlo, algunas consultas anteriores de transacciones pendientes quedan vacías y los métodos txpool leen la cola de la aplicación.
- La gestión de la cola, la ejecución paralela y la red experimental son cambios distintos. Superar la altura prevista no demuestra una configuración universal ni un rendimiento medido.
Cronología de los hechos
La versión aparece como Pre-release y advierte que los operadores no deben sustituir su binario inmediatamente.
El anuncio fija el 22 de octubre y distingue el mempool opcional, la ejecución paralela y libp2p experimental.
El bloque 101.485.000 lleva la hora 07:52:24 UTC; Chainstack registra el fin del mantenimiento a las 08:00 UTC. Son registros diferentes.
Se ha superado una altura; los registros significan cosas distintas
Cronos programó su actualización EVM v1.8 de mainnet para el 22 de octubre de 2026. Ahora hay algo más que una fecha: el aviso de mantenimiento de Chainstack identifica el bloque 101.485.000 y registra la finalización a las 08:00 UTC. Cronos Explorer muestra ese bloque con hora 07:52:24 UTC, y el bloque 101.485.001 apunta a su hash como padre. El historial del explorador ya ha superado la altura anunciada.[1][3][4][5]
Estas observaciones tienen límites. La hora del bloque es un registro de la cadena; las 08:00 corresponden al mantenimiento del proveedor, no a una medición del instante exacto de activación en toda la red. CoinYQ no verificó de forma independiente la versión ejecutada por los validadores. La página de versiones sigue marcando v1.8.0 como Pre-release. Ni esa etiqueta ni una marca de mantenimiento completado establecen por sí solas qué opciones activó cada operador.[3][4][5][6]
Dos ventanas a la sala de espera de un nodo
Una opción tiene una consecuencia fácil de pasar por alto al leer un flujo de transacciones. El mempool guarda las que esperan entrar en un bloque. Antes, Cronos utilizaba el pool de la capa de consenso CometBFT; v1.8 permite que el operador encargue esa tarea a la aplicación. La guía de migración lo describe como opcional y aclara que las configuraciones existentes siguen funcionando.[2]
La elección cambia la ventana desde la que se ve la cola. Según la guía, en modo app, /unconfirmed_txs y /num_unconfirmed_txs de CometBFT no muestran entradas pendientes; eth_newPendingTransactionFilter y el filtro pending tampoco devuelven resultados. En cambio, txpool_content y txpool_status leen el pool de la aplicación. En modo flood, funciona la vista de CometBFT, mientras esos métodos txpool ven un pool de aplicación vacío. Por tanto, una respuesta vacía de una interfaz no basta para concluir que el nodo no tiene transacciones esperando.[2]
Mover trabajo antes del bloque y repartirlo dentro de él
¿Por qué trasladar el pool? El anuncio de Cronos describe trabajo compartido entre la admisión y la construcción de bloques, con menos verificaciones repetidas. La revalidación posterior a un bloque puede ejecutarse en segundo plano en lugar de competir en la ruta del consenso. Cambia cómo se organiza el trabajo antes del siguiente bloque; no demuestra que una transacción enviada ya se haya incluido o finalizado.[1][2]
Block-STM aborda otra etapa: ejecutar en paralelo las transacciones de un bloque y volver a ejecutar las afectadas cuando detecta conflictos. Cronos lo recomienda en la guía, pero el valor predeterminado documentado de block-executor es sequential. La versión del software, el pool elegido y el modo de ejecución son datos separados. Activar el pool de la aplicación también exige una capacidad compatible: el valor que lo deshabilita, max-txs = -1, no puede combinarse con el modo app.[1][2]
Lo que la actualización no determina por sí sola
Otros anuncios de la versión requieren la misma atención. El comunicado del 14 de octubre describía libp2p como experimental y todavía sin activar en mainnet; que el código exista en v1.8 no establece su activación posterior. La guía también indica que el límite de gas de 16.777.216 por transacción necesita un cambio de gobernanza aparte, en vez de entrar en vigor a la altura de actualización. Aquí no hemos verificado ninguno de esos cambios posteriores.[1][2]
Para quien construye un panel o investiga una transacción en espera, la pregunta práctica es qué pool expone el endpoint. La guía propone mantener flood para los usuarios que necesitan la vista anterior, o trasladar las consultas a los métodos txpool con ese espacio de nombres habilitado. Haber superado la altura prevista da actualidad a esta distinción operativa. No convierte una lista vacía en prueba de una red sin actividad ni sustituye las mediciones de latencia de ejecución y consulta.[2][3][4]
Historias para seguir leyendo
Explora el tema a través de otros casos y contextos.
Fuentes y referencias
- [1]Fuente 1: Cronos Labs — Cronos EVM Mainnet v1.8 UpgradeCronos Labs · 2026-10-14Consultado 2026-10-22
- [2]Fuente 2: Cronos v1.8.0 — migration guide, pending-transaction views and defaultsCronosConsultado 2026-10-22
- [3]Fuente 3: Chainstack — Cronos Mainnet Upgrade maintenance recordChainstackConsultado 2026-10-22
- [4]Fuente 4: Cronos Explorer — block 101,485,000Cronos ExplorerConsultado 2026-10-22
- [5]Fuente 5: Cronos Explorer — block 101,485,001 and parent hashCronos ExplorerConsultado 2026-10-22
- [6]Fuente 6: Cronos — v1.8.0 release notesCronos · 2026-09-24Consultado 2026-10-22