Zcash propone bloques de 20 segundos sin aumentar la emisión diaria
Publicación de la fuente: 2026-11-08 · Análisis editorial publicado: 2026-11-09
La propuesta del 8 de noviembre sigue al objetivo de 25 segundos de NU7. Reduce recompensa y límites por bloque; no hay fecha de activación.
Un paso adicional tras los 25 segundos
Los desarrolladores de Zcash Dev Ojha y Evan Forbes propusieron el 8 de noviembre reducir el objetivo entre bloques de 25 a 20 segundos. Quieren su consideración en la siguiente consulta y una posible inclusión en NU7.1. La propuesta y su borrador siguen en discusión: ni el post ni una revisión de código abierta anuncian la activación. La referencia es el objetivo de 25 segundos introducido por NU7.
Para quien mina o recibe ZEC, el atractivo es esperar menos para incluir un pago. Para operadores, la cuestión es conseguirlo sin descartar mucho más trabajo. Los autores lo presentan como un cambio de latencia: busca reducir la espera, no aumentar la capacidad diaria de transacciones protegidas ni crear más monedas nuevas cada día.
Más bloques, menos monedas nuevas por bloque
Con esos objetivos, un día contiene 3.456 bloques esperados a 25 segundos o 4.320 a 20. Son un 25% más de bloques, no un 25% más de nueva emisión ZEC. El borrador multiplica el subsidio por bloque por cuatro quintos. Multiplicar 1,25 veces los bloques por 0,8 veces el subsidio conserva la emisión esperada en el mismo tiempo.
El intervalo de reducción a la mitad también pasa de 5.040.000 a 6.300.000 bloques para conservar su duración esperada. Se mantienen el calendario de emisión y el máximo de 21 millones de monedas. Un minero no puede convertir más bloques en una previsión proporcional de ingresos: importan cuota de trabajo, comisiones, rechazos y contabilidad del pool. La aritmética del subsidio no promete una mayor recompensa diaria al mismo hashrate.
Límites protegidos menores por bloque
La propuesta reduce el presupuesto global de acciones protegidas y los límites Orchard e Ironwood de 330 a 264 por bloque. El límite conjunto de entradas y salidas Sapling pasa de 300 a 240. Son límites de componentes del trabajo de transacciones privadas, no una afirmación de que cada acción sea un pago completo. El tamaño máximo de dos megabytes se mantiene.
La razón es el trabajo de la cartera. Mantener los límites antiguos con bloques más frecuentes elevaría los datos privados máximos que una cartera ligera podría necesitar procesar. Reducirlos a cuatro quintos conserva los máximos diarios esperados. Todavía hay más cabeceras: capacidad protegida invariable no significa que todos los bytes y operaciones de red sean idénticos.
El coste de perder la carrera
Dos mineros pueden encontrar bloques competidores antes de conocer el resultado del otro. Finalmente una rama gana; el bloque fuera de la cadena aceptada suele llamarse huérfano. Su minero gastó electricidad sin recibir la recompensa normal de un bloque aceptado. Intervalos menores dejan menos tiempo para comunicar descubrimientos, por lo que este riesgo operativo merece comprobarse.
Los autores informan de pruebas exigentes con 80 mineros en 12 regiones, bloques completos de dos megabytes y objetivo de 20 segundos. Declaran un 1,9% de huérfanos con Zakura y un 3,3% con una mitad Zakura y otra Zebra-Andele. Los comparan con el 4,68% de un experimento anterior para 25 segundos. Son resultados atribuidos bajo sus condiciones, no porcentajes garantizados para un pool real ni pruebas independientes de ASIC.tools.
Confirmar antes no decide la política del receptor
Tres intervalos objetivo pasan de 75 a 60 segundos. Es tiempo esperado, no una cuenta atrás: descubrir bloques mediante prueba de trabajo es irregular. Un servicio puede exigir otro número de confirmaciones o considerar tiempo y trabajo acumulado. La propuesta no obliga a los exchanges a reducir confirmaciones; el momento en que un depósito queda utilizable depende del receptor.
La media de dificultad pasa de 102 a 128 bloques, aproximando la duración de observación: 2.550 frente a 2.560 segundos. Es aproximadamente igual, no exactamente; quedan diez segundos de diferencia. La caducidad predeterminada de transacciones pasa de 120 a 150 bloques. Reducir el objetivo exige coordinar reglas expresadas en bloques, no sustituir un único número del nodo.
Separe observaciones y estado de actualización
El foro cita observaciones alentadoras tras NU7, pero la tasa de huérfanos de un explorador es lo que vieron sus observadores, no un censo de todos los bloques perdedores. ZecBlock explica que antes del 5 de noviembre solo observaba un nodo de Helsinki; después añadió otros. Más puntos pueden detectar competidores antes invisibles, por lo que comparar porcentajes con cobertura cambiante no aísla el efecto de la actualización.
Por ahora no existe un ajuste ASIC que active bloques de 20 segundos ni una fecha fijada en la propuesta. Los operadores pueden seguir borrador, consulta e instrucciones futuras de nodos, manteniendo las reglas vigentes. ASIC.tools comprobó el post, el borrador fijado y la metodología sin ejecutar la red de prueba. Se debate una inclusión más rápida conservando emisión diaria, no una garantía de rentabilidad ni liquidación instantánea.
Otra métrica compara la hora de cabecera con la primera recepción observada. ZecBlock explica que el pool suele fijarla al emitir trabajo: la diferencia incluye resolverlo y entregarlo. No mide directamente propagación, y los relojes pueden hacerla negativa. Un operador no debe sustituir con ese gráfico sus registros de envío, rechazo y conexión al investigar trabajo obsoleto.
Fuente: Zcash developers / community proposal ↗ · Draft specification and review status ↗ · Pinned draft examined for this report ↗ · Observer methodology, not a universal orphan census ↗
Calculadora de minería ↗
