Por Canuto  

Desarrolladores de Zcash proponen reducir de 25 a 20 segundos el intervalo objetivo entre bloques, pocos días después de NU7. Las pruebas iniciales registraron entre 1,9% y 3,3% de bloques huérfanos, pero la iniciativa aún debe pasar por la discusión y aprobación comunitarias.
***

  • La propuesta de ValarDragon y Evan Forbes busca incluir el cambio en una próxima encuesta y considerarlo para la actualización NU7.1.
  • Una prueba con 80 mineros en 12 regiones registró tasas de bloques huérfanos de 1,9% y 3,3%, según el software utilizado.
  • El borrador plantea límites y ajustes para acelerar las confirmaciones sin aumentar de forma significativa la carga diaria de nodos y wallets.


Zcash evalúa bloques de 20 segundos tras activar la actualización NU7

La red Zcash podría reducir nuevamente el tiempo objetivo entre bloques: un borrador presentado por sus desarrolladores propone pasar de 25 a 20 segundos, pocos días después de que la actualización NU7 comenzara a operar en la mainnet. La iniciativa apunta a acelerar la primera confirmación de las transacciones, aunque todavía no cuenta con aprobación y deberá someterse a la discusión de la comunidad.

ValarDragon y Evan Forbes compartieron el domingo el borrador de una Propuesta de Mejora de Zcash, o ZIP, en el foro comunitario. Según informó CoinGape, sus autores buscan llevar la idea a una próxima encuesta y evaluar su inclusión en NU7.1, por lo que el cambio no debe interpretarse como una modificación ya decidida ni como una fecha confirmada para su despliegue.

Una nueva reducción después de NU7

NU7 entró en funcionamiento en la mainnet el viernes y redujo el intervalo objetivo de bloque de Zcash de 75 a 25 segundos. La nueva iniciativa plantea recortar esos cinco segundos adicionales, con el argumento de que una producción más frecuente de bloques puede acortar la espera inicial para que una transacción aparezca confirmada en la cadena.

El borrador vincula esa posible mejora con usos cotidianos de la red, entre ellos pagos, depósitos en exchanges y operaciones entre cadenas. Los autores sostienen que el intervalo más breve podría acelerar esos procesos sin imponer demandas significativamente mayores a la infraestructura, pero esa expectativa depende de los parámetros técnicos que acompañarían el cambio y de su comportamiento fuera de las pruebas.

La propuesta es distinta de ZIP 218, que se desplegó junto con NU7 y formó parte de la actualización que llevó el objetivo de bloque a 25 segundos. En esta ocasión, los desarrolladores plantean un ajuste más acotado, enfocado en reducir retrasos y adaptar otros límites para evitar que la frecuencia adicional de bloques incremente en la misma proporción el trabajo diario de nodos y wallets.

Ese equilibrio es importante porque acortar el intervalo no significa simplemente pedir a la red que produzca bloques más seguido. Si los límites que controlan los datos y las transacciones permanecieran sin cambios, las wallets ligeras podrían tener que descargar y procesar más información cada día; el borrador calcula que su carga podría aumentar 25% en ese escenario.

Los límites que acompañarían el cambio

Para contener ese posible incremento, los desarrolladores proponen límites específicos para las transacciones blindadas, conocidas también como shielded. La intención es impedir que las wallets ligeras deban manejar una cantidad diaria mayor de datos solo porque los bloques llegan con más frecuencia, un aspecto que el borrador presenta como parte del diseño y no como un detalle secundario de la reducción del intervalo.

La propuesta mantendría sin cambios el límite de tamaño de bloque de Zcash, establecido en 2 MB, mientras ajustaría otras configuraciones para preservar la temporización existente de la red. Entre los parámetros señalados figuran la emisión de bloques, la tasa de reemisión del Mecanismo de Sostenibilidad de Red, el promedio de dificultad y el plazo de caducidad predeterminado de las transacciones.

En conjunto, esos cambios buscan que la nueva frecuencia no altere de forma desproporcionada el volumen de trabajo de los participantes. La fuente no presenta el ajuste de cada parámetro como una decisión ya aprobada: se trata de elementos incluidos en un borrador que todavía debe evaluarse, junto con la conveniencia de reducir el intervalo y las implicaciones para el funcionamiento de la red.

La propuesta también distingue entre acelerar la llegada del primer bloque y modificar los criterios que usan terceros para considerar definitiva una operación. Los exchanges podrían conservar sus requisitos actuales de confirmaciones, de modo que un tiempo de bloque menor no obligaría automáticamente a reducir la cantidad de bloques que esperan antes de acreditar depósitos.

Pruebas de bloques huérfanos y límites de los resultados

Al reducir el intervalo de 25 a 20 segundos, los mineros tendrían menos tiempo para recibir y verificar cada nuevo bloque antes de que aparezca el siguiente. Esa ventana más estrecha puede elevar la posibilidad de que se generen bloques competidores; cuando la cadena termina aceptando uno y rechaza otro, el bloque descartado queda huérfano.

Para medir ese riesgo, los desarrolladores probaron una red de 80 mineros distribuidos en 12 regiones. Cuando todos utilizaron la misma implementación de software, Zakura, la tasa de bloques huérfanos fue de 1,9%; al combinar Zakura con Zebra-Andele, el registro llegó a 3,3%.

Los autores compararon esos datos con las pruebas asociadas a NU7 y al intervalo de 25 segundos, que registraron 4,68% en un experimento y 3,26% en un modelo teórico. Las cifras permiten observar resultados de distintos escenarios, pero no equivalen a una garantía de que la red producirá las mismas tasas cuando opere con bloques de 20 segundos en condiciones reales.

Los ensayos ocurrieron en un entorno controlado, una limitación que los propios desarrolladores reconocen al valorar el posible cambio. Las condiciones efectivas de la mainnet podrían arrojar resultados diferentes, por lo que las tasas iniciales respaldan una evaluación técnica, pero no eliminan la incertidumbre que acompaña a cualquier ajuste de tiempos y propagación de bloques.

Una propuesta todavía pendiente de decisión

La iniciativa busca que las confirmaciones iniciales lleguen más rápido sin que el cambio se traduzca en mayores exigencias para la red o en una reducción automática de los estándares de seguridad de los exchanges. Mantener los requisitos de confirmación existentes es una opción explícita del borrador, aunque cada plataforma conservaría sus propias reglas para depósitos y acreditaciones.

La discusión comunitaria y la posible encuesta serán pasos relevantes antes de que el borrador avance hacia una consideración para NU7.1. Por ahora, la propuesta no equivale a una aprobación ni establece por sí misma que la próxima actualización vaya a incorporar bloques de 20 segundos; esa decisión dependerá del proceso de evaluación y consenso que plantea la iniciativa.

Al momento de la publicación citada por CoinGape, ZEC cotizaba aproximadamente a USD $1.217, con una caída de 3,14% en las 24 horas previas. Ese dato describe el mercado en el momento referido por la fuente y no demuestra que el precio responda a la propuesta, que todavía no ha sido aprobada.

El objetivo inmediato de los desarrolladores es abrir el debate sobre cuánto puede acelerarse la confirmación sin elevar de manera innecesaria los costos operativos ni perjudicar la fiabilidad. Los resultados de las pruebas aportan una primera referencia, pero la decisión de pasar de 25 a 20 segundos seguirá pendiente hasta que la comunidad examine el borrador y sus consecuencias.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín