Zcash estudia reducir su tiempo de bloque de 25 a 20 segundos. La propuesta se publicó el 8 de noviembre en el foro de Zcash Community y pide incluir el cambio en NU7.1, la actualización menor posterior a NU7. El texto no está activo ni tiene fecha: es un borrador abierto en el repositorio del proyecto, pendiente de votación comunitaria y de revisión técnica. Si se aprobara tal como está escrito, la red pasaría de 3.456 a 4.320 bloques al día y su capacidad teórica de datos subiría de 80 a 100 kilobytes por segundo.
Ese es el resumen que busca quien pregunta qué se está discutiendo en Zcash esta semana. Lo que sigue es la mecánica exacta del borrador, la aritmética que el hilo no escribe, lo que el cambio no toca y el calendario real de filtros que separan una propuesta de una actualización activada.
Qué cambia exactamente: de 25 a 20 segundos
El autor del hilo, el desarrollador conocido como ValarDragon, define la propuesta en una frase: «We propose a follow-on to ZIP 218 that lowers the block target spacing from 25s to 20s.» Es un cambio de latencia, no de reglas monetarias. La diferencia con ZIP 218, el ZIP que llevó los bloques de 75 a 25 segundos, está en el alcance: aquí no se toca el tamaño del bloque ni el calendario de emisión.
El borrador técnico está en el repositorio del proyecto. El pull request 1437, abierto el 5 de noviembre y marcado como draft, propone «a separate network upgrade after NU7 that reduces block target spacing from 25 to 20 seconds». El texto conserva el límite de bloque en 2 MB, actualiza los límites de acciones para mantener la carga de sincronización shielded y sube la ventana de promedio del ajuste de dificultad de 102 a 128 bloques para conservar aproximadamente la misma duración temporal.
| Parámetro | Hoy, tras NU7 | Con el borrador |
|---|---|---|
| Tiempo de bloque objetivo | 25 segundos | 20 segundos |
| Bloques por día | 3.456 | 4.320 (+864, +25%) |
| Límite de bloque serializado | 2 MB | 2 MB (sin cambios) |
| Capacidad teórica de datos | 80 KB/s | 100 KB/s (+25%) |
| Ventana de promedio del DAA | 102 bloques | 128 bloques |
| Estado | Activo desde NU7 | Borrador abierto, sin fecha |
La cuenta de bloques es directa: 86.400 segundos de un día divididos entre 25 dan 3.456 bloques, y entre 20 dan 4.320. Son 864 bloques más, un 25% adicional de oportunidades de inclusión. Para un usuario, eso significa menos espera entre el envío y la primera confirmación; para un minero, más trabajo de propagación por unidad de tiempo.
Por qué el autor sostiene que el riesgo es bajo
El argumento de seguridad no descansa en la cifra sino en la comparación. ValarDragon escribe que «the only risk is orphan rates» y añade que las mediciones más recientes de bloques de 20 segundos en stress-net son mejores que las esperadas, hasta el punto de que el cambio «already meets the pre-existing safety bar established for 25s on today’s node software».
El segundo día de discusión puso el número en su escala real. «The chain today processes at peak 80KB/s. This change would make it 100KB/s, which is still tiny quantities that dialups could still handle», escribió el autor. La frase importa porque desactiva la objeción de ancho de banda: 100 kilobytes por segundo es una fracción de lo que soporta cualquier conexión doméstica actual, y el límite real de Zcash no está en la red de nodos sino en la demanda de espacio en bloque.
El hilo también deja claro que la reducción anterior ya ocurrió. «We have just hit the great milestone of reducing blocktime from 75s to 25s in NU7!», resume el autor en el texto inicial. Ese dato cambia la naturaleza del debate: no se discute si Zcash puede operar con bloques cortos, sino si puede bajarlos un paso más sin degradar la tasa de huérfanos.
El segundo borrador: de 2 MB a 3 MB
La propuesta de tiempo de bloque no viene sola. El pull request 1448, abierto el 6 de noviembre, aumenta el límite serializado de bloque de 2.000.000 a 3.000.000 de bytes «in a network upgrade after NU7», conserva los límites de acciones shielded y de operaciones de firma, y llega con una medición sobre 80 nodos Zakura más una lista explícita de tareas pendientes: propagación peer-to-peer, cargas de trabajo emparejadas, resultados de un cliente independiente y vectores de activación.
Son dos ZIP separados y esa separación es deliberada: el de 20 segundos conserva el límite de 2 MB y el de 3 MB se activaría en una actualización posterior. Ahí está el cálculo que ninguno de los dos documentos hace y que conviene tener a mano. Si ambos avanzaran y se activaran juntos, la capacidad teórica pasaría de 80 KB/s (2 MB cada 25 segundos) a 150 KB/s (3 MB cada 20 segundos). Es un 87,5% más, no el 25% que sugiere el cambio de tiempo de bloque por separado.
La cifra es un techo aritmético, no una promesa de rendimiento. El propio ZIP de 3 MB incluye limitaciones de medición y tareas abiertas, y el rendimiento real depende de cuánta demanda haya de espacio en bloque: hoy la cadena opera muy por debajo de su límite, así que el efecto inmediato para un usuario sería de latencia, no de capacidad.
Lo que el cambio no toca
Un bloque más corto no imprime más ZEC. La emisión sigue su calendario, el suministro máximo sigue en 21 millones y la recompensa por bloque se ajusta según las reglas existentes, no según la frecuencia. Tampoco cambia la finalidad económica de una transacción: la reducción de latencia mejora el tiempo hasta la primera confirmación, que es un problema distinto del de la confirmación definitiva.
El borrador lo dice a su manera cuando habla de «latency-only change». Lo que sí toca es la relación entre tiempo y dificultad: por eso la ventana de promedio del ajuste de dificultad sube de 102 a 128 bloques. Sin ese ajuste, un bloque más corto habría comprimido la ventana temporal y hecho la dificultad más sensible a la variación del hash rate.
El calendario real: encuesta, revisión y nodos
La propuesta, publicada en el hilo del foro de Zcash Community, no tiene fecha porque depende de tres filtros que aún no se han cerrado. El primero es la votación: el texto pide que el cambio entre «in the next poll and slated for inclusion in NU7.1», es decir, en la siguiente encuesta de la comunidad y en una actualización menor que todavía no está calendarizada. El segundo es la revisión del ZIP, que sigue abierto y sin número asignado. El tercero es la implementación en los equipos de nodos que sostienen la red.
El hilo tampoco es un consenso. El 9 de noviembre, el usuario zeckzodel respondió con la objeción de gobernanza: cada cambio de consenso tiene un coste de coordinación y ese coste se paga una vez por propuesta, no por milisegundo ahorrado. Su pregunta textual fue «is 20 the optimum answer based on everything we (or AI) can extract from the data that we already have». Otro participante, Milton, llevó la discusión al algoritmo de consenso y recordó que un cambio de esa naturaleza exigiría un fork.
El precio mientras tanto
Zcash cotizaba a 1.051,65 dólares a las 23:27 UTC del 10 de noviembre, un 11,01% menos que 24 horas antes, con un rango intradía de 196,47 dólares entre 999,57 y 1.196,04, según la captura de CoinGecko usada en este artículo. La capitalización era de 17.916 millones y el volumen de 1.234 millones, un 6,9% del valor de mercado negociado en un día.
La caída se produjo en un mercado que también cayó: bitcoin perdió 1,98%, ether 3,87% y solana 4,22% en la misma ventana. Las fuentes consultadas no identifican ningún evento de Zcash que explique el movimiento, y la secuencia temporal no permite afirmar que los borradores hayan contribuido en ninguna dirección. La coincidencia está documentada; el mecanismo causal, no.
El contexto de doce meses ordena mejor la lectura que el movimiento de un día. Zcash sube 86,05% en un año frente a una caída de 30,29% de bitcoin y de 42,34% de ether, pero sigue un 67,1% por debajo de su máximo histórico de 3.191,93 dólares, registrado el 28 de octubre de 2016. Para volver a ese nivel necesitaría subir 203,5%; bitcoin necesita 71,4% y ether 141,7%. El activo que mejor rinde a doce meses es también el que más ha caído en las últimas 24 horas, y esa tensión es la que el precio no resuelve.
La propuesta tampoco cambia la demanda de ZEC por sí sola. Un cambio de latencia mejora la experiencia de uso de la cadena, y la experiencia de uso es una condición para que la narrativa de «efectivo cifrado» tenga usuarios, no una garantía de que los tenga. Quien siga el caso tiene tres señales verificables: el resultado de la encuesta, la tasa de huérfanos publicada por los equipos de nodos y el avance de las tareas pendientes del ZIP de tamaño de bloque.
Para el lector que quiera el contexto de la actualización anterior, este medio documentó en octubre la activación de NU7 en testnet con bloques de 25 segundos y, antes, el calendario que fijó el objetivo de mainnet para el 5 de noviembre. Las dos piezas explican de dónde viene el 25 actual.
Preguntas frecuentes
¿Cuánto tarda un bloque de Zcash hoy?
25 segundos de objetivo desde NU7, frente a los 75 segundos anteriores. El borrador propuesto el 8 de noviembre pide bajarlo a 20 segundos, pero ese cambio no está activo.
¿Cuándo se activaría el cambio a 20 segundos?
No hay fecha. El texto pide incluir el cambio en la siguiente encuesta de la comunidad y en NU7.1, una actualización menor que aún no está calendarizada. Después hacen falta la revisión del ZIP y la implementación en los equipos de nodos.
¿El cambio de 20 segundos incluye bloques más grandes?
No. Son dos borradores separados. El de 20 segundos conserva el límite de 2 MB; el de 3 MB es otro ZIP que se activaría en una actualización posterior a NU7. Solo si ambos avanzan se suman sus efectos sobre la capacidad.
¿Bajar el tiempo de bloque aumenta la emisión de ZEC?
No. La emisión sigue su calendario y el suministro máximo sigue en 21 millones. El cambio es de latencia: afecta al tiempo hasta la primera confirmación, no a la cantidad de monedas creadas.
¿Qué riesgo señala el propio autor de la propuesta?
La tasa de huérfanos, es decir, bloques válidos que se descartan porque otro llegó antes. El autor sostiene que las mediciones de 20 segundos en stress-net son mejores que las esperadas y que el cambio cumple el listón de seguridad que ya se aplicó a los 25 segundos.
¿Dónde se sigue el estado de la propuesta?
En el hilo del foro de Zcash Community abierto el 8 de noviembre y en los pull requests 1437 y 1448 del repositorio zcash/zips. Los dos ZIP están abiertos y marcados como borradores.
Este artículo es informativo y no constituye asesoramiento de inversión. Los precios corresponden a la captura de CoinGecko de las 23:27 UTC del 10 de noviembre de 2026. Las propuestas descritas son borradores abiertos en revisión, no cambios activados en la red.
Sobre el autor
Redactor freelance apasionado por las criptomonedas, ofrece contenido perspicaz y preciso sobre blockchain y fintech. Con gran habilidad para traducir conceptos complejos en contenido accesible, Eric produce artículos bien documentados, posts de blog y piezas de liderazgo de pensamiento que cubren las últimas tendencias y novedades del espacio de las finanzas digitales. Su escritura está orientada a educar e involucrar tanto a principiantes como a expertos del sector, ofreciendo perspectivas frescas sobre el mundo de las criptomonedas, las finanzas descentralizadas (DeFi) y las innovaciones en blockchain. La dedicación de Eric a la calidad y la precisión lo convierte en una voz de confianza en las comunidades fintech y cripto.
