Desarrolladores de Zcash proponen bloques de 20 segundos para acelerar las confirmaciones

Zcash propone reducir el intervalo entre bloques de 25 a 20 segundos para acelerar confirmaciones sin alterar la emisión diaria ni el throughput shielded.
Tabla de Contenidos

Puntos clave de la noticia:

  • Los desarrolladores de Zcash proponen reducir el intervalo objetivo entre bloques de 25 a 20 segundos para acelerar primeras confirmaciones y llevar el cambio a NU7.1.
  • Las pruebas mostraron tasas de bloques huérfanos de 1,9% con Zakura y 3,3% en una red mixta Zakura/Zebra-Andele, dentro de los umbrales técnicos previos.
  • El diseño mantendría intactos la emisión diaria y el throughput shielded, ajustando recompensas, límites de acciones y parámetros temporales proporcionalmente.

Los desarrolladores de Zcash propusieron reducir el intervalo entre bloques de 25 a 20 segundos tras NU7. En una propuesta del foro comunitario, ValarDragon y Evan Forbes plantearon llevar el cambio a la votación y programarlo para NU7.1. La propuesta busca acelerar las confirmaciones sin aumentar la capacidad diaria de transacciones shielded de Zcash. El ajuste continuaría la evolución de Zcash tras el salto de bloques de 75 a 25 segundos.

Los desarrolladores buscan reducir la latencia sin aumentar el throughput diario

Los desarrolladores presentan el objetivo de 20 segundos como continuación de ZIP 218, la propuesta que impulsó la reducción de block time en NU7. Argumentan que las transacciones esperan su inclusión cuando los bloques tienen capacidad disponible, generando fricción para pagos en comercios, depósitos en exchanges y swaps cross-chain. Recortar otros cinco segundos reduciría el tiempo hasta la primera confirmación y mejoraría la latencia de pagos consecutivos. El plan llega tras la activación de NU7 en mainnet, que redujo el intervalo objetivo de 75 a 25 segundos.

Los desarrolladores de Zcash proponen reducir el intervalo objetivo entre bloques de 25 a 20 segundos

Las pruebas de estrés utilizaron una red de 80 miners distribuida en 12 regiones con bloques de 2 MB. Una red solo con Zakura registró una tasa de bloques huérfanos de 1,9%, mientras una configuración 50-50 de Zakura y Zebra-Andele alcanzó 3,3%. Ambos resultados cumplen o mejoran el umbral utilizado previamente para los bloques de 25 segundos, cuyas pruebas mostraron una tasa empírica de 4,68% y una estimación teórica de 3,26%. Los desarrolladores atribuyen la mejora al trabajo en Zakura y Zebra-Andele, tras las mejoras de seguridad y rendimiento de Zebra.

La propuesta reduciría en una quinta parte los límites de acciones shielded para evitar que bloques más rápidos eleven la capacidad diaria. Las acciones Orchard e Ironwood por bloque bajarían de 330 a 264, mientras inputs y outputs de Sapling pasarían de 300 a 240. Mantener los máximos sin cambios busca evitar un aumento del 25% en la carga de sincronización de las light wallets. El límite seguiría en 2 MB. La emisión por bloque caería proporcionalmente y el intervalo de halving aumentaría de 5,04 millones a 6,3 millones de bloques. Se ajustarían el expiry de transacciones, el promedio de dificultad y parámetros de reorganización. El objetivo es preservar la emisión diaria y el comportamiento temporal sin pedir menos confirmaciones a los servicios, continuando el impulso comunitario por transacciones más rápidas.

RELATED POSTS

Ads

Síguenos en Redes

Cripto Tutoriales

Cripto Reviews