Loading...
En la encuesta a poseedores de monedas de NU7 que cerró el 14 de septiembre de 2026, unos 2.397.669 ZEC votaron a favor de ZIP 218 y 141,6 ZEC votaron en contra, un resultado del 99,9 %. La mayoría de la cobertura lo resumió como «los bloques de Zcash se vuelven más rápidos». Eso es cierto, pero omite gran parte de lo que hace la propuesta y de lo que deliberadamente mantiene igual.
Esta página explica ZIP 218 a partir de su propio texto: qué cambia, qué no cambia y cuál es su coste.
| Hoy | Después de ZIP 218 | |
|---|---|---|
| Espaciado objetivo entre bloques | 75 segundos | 25 segundos |
| Bloques por día | 1.152 | 3.456 |
| Subsidio por bloque (era actual de halvings) | 1,5625 ZEC | 0,52083333 ZEC |
| Nuevos ZEC por día | sin cambios | sin cambios |
| Intervalo de halving | 1.680.000 bloques | 5.040.000 bloques |
| Límites de acciones blindadas por bloque | ninguno (solo el límite de tamaño de 2 MB) | 330 en total, con límites por pool |
| Rendimiento de Orchard (transacciones de 2 acciones) | unas 2,9 por segundo | unas 6,6 por segundo |
Tres veces más bloques, cada uno pagando un tercio. El calendario de suministro se mantiene donde estaba.
El objetivo principal es un menor tiempo de espera. Hoy un pago espera 75 segundos de media para su primera confirmación, independientemente de la carga de la red. Con 25 segundos, esto baja a 25 segundos de media. El ZIP menciona los pagos en puntos de venta, depósitos en exchanges y bridges entre cadenas como los usos que más lo notan.
Conviene tener presentes dos puntos del ZIP:
El ZIP también señala que se podría haber conseguido un mayor rendimiento únicamente con un bloque de mayor tamaño. La latencia es la razón para elegir bloques más cortos en su lugar.
Triplicar el número de bloques triplicaría la emisión diaria si no cambiara nada más. ZIP 218 lo evita dividiendo el subsidio por bloque por un factor adicional de tres una vez que NU7 esté activo.
En la era actual de halving, esto reduce el subsidio por bloque de 1,5625 ZEC a 0,52083333 ZEC (52.083.333 zatoshi). Como 156.250.000 zatoshi no se divide exactamente entre tres, cada bloque redondea hacia abajo en un tercio de zatoshi. A lo largo de un intervalo completo de halving de 5.040.000 bloques, esto equivale a unos 0,0168 ZEC en total.
El subsidio es el total de nuevos ZEC creados por bloque. La parte existente destinada a financiación del desarrollo sigue tomándose de él, por lo que los mineros reciben menos que la cifra total, exactamente igual que hoy.
Una nota sobre la cifra de 0,26041666 ZEC. La nota explicativa del borrador de ZIP imprime el subsidio posterior a NU7 como floor(156250000 / 6) = 0,26041666 ZEC, y algunas noticias la han repetido. Esa nota se equivoca por un factor de dos: 156.250.000 zatoshi ya es el subsidio posterior a Blossom, así que dividirlo entre seis aplica por segunda vez el factor de dos de Blossom además del factor de tres de NU7. La fórmula normativa da floor(1,250,000,000 / (2 · 3 · 4)) = 52.083.333 zatoshi con el índice de halving actual. El issue de implementación de Zebra para este cambio (#11463) registra que la nota cuenta dos veces el factor de Blossom, indica a los implementadores que «implementen la fórmula, no la nota» y afirma que se ha presentado una corrección para el ZIP. La cifra correcta en la activación es 0,52083333 ZEC.
El intervalo de halving se triplica de 1.680.000 bloques a 5.040.000 bloques. Como los bloques llegan tres veces más a menudo, los halvings siguen produciéndose aproximadamente en el mismo momento que lo habrían hecho sin el cambio. El límite total de suministro no se ve afectado.
Esto es independiente de la otra cuestión sobre emisión de la encuesta de NU7, en la que los poseedores de monedas votaron por conservar los halvings en lugar de sustituirlos por una curva suavizada. ZIP 218 funciona con el modelo de halving existente y no lo cambia.
ZIP 218 añade límites a la cantidad de actividad blindada que puede contener un único bloque:
| Límite | Máximo por bloque |
|---|---|
| Todos los pools blindados combinados | 330 (cada JoinSplit de Sprout cuenta como 2) |
| Acciones de Orchard | 330 |
| Entradas más salidas de Sapling | 300 |
| JoinSplits de Sprout | 25 |
Las partes transparentes de las transacciones no se ven afectadas, y el límite de tamaño de bloque de 2 MB sigue aplicándose.
Los límites existen porque, de otro modo, más bloques implicarían más trabajo para wallets y nodos. Con los límites establecidos, el peor caso en realidad mejora respecto a hoy, incluso con tres veces más bloques:
Los límites de Sapling y Sprout son ajustados deliberadamente. En mayo de 2026, Orchard albergaba el 87,9 % de ZEC blindados, Sapling el 11,6 % y Sprout el 0,5 %, de modo que los pools más pequeños tienen espacio suficiente para su uso real, al tiempo que un atacante tiene menos que explotar. Como las comisiones de ZIP 317 cobran lo mismo por acción lógica en cada pool, un atacante no obtiene nada spameando un pool en lugar de otro.
Con 330 acciones de Orchard por bloque, una transacción estándar de Orchard de 2 acciones cabe ⌊330 / 2⌋ = 165 veces por bloque. Con un bloque cada 25 segundos, esto equivale a unas 6,6 transacciones por segundo, frente a unas 2,9 hoy; el ZIP lo califica como un aumento de 2,3× en el rendimiento normal de Orchard. Sapling resulta en unas 3,0 por segundo, aún por encima de lo que Orchard logra hoy.
El algoritmo de dificultad calcula el promedio sobre una ventana de bloques recientes. ZIP 218 aumenta esa ventana de 17 bloques a 102, por lo que sigue cubriendo unos 2.550 segundos de tiempo real, el mismo período que cubría cuando Zcash se lanzó con bloques de 150 segundos. El ZIP da dos razones: evitar que los ataques de manipulación de dificultad sean más fáciles (cita el incidente de MWEB de Litecoin en abril de 2026) y suavizar la variación a corto plazo de los tiempos de bloque.
Justo después de la activación, los tiempos de bloque tardarán un tiempo en estabilizarse en el nuevo objetivo. Esto es previsible y refleja lo sucedido en Blossom, cuando Zcash pasó de 150 a 75 segundos.
Estas son recomendaciones para implementaciones, no reglas de consenso:
Los bloques más rápidos no son gratuitos. Un bloque obsoleto es un bloque válido que pierde la carrera por incluirse en la cadena porque otro bloque llegó primero a la red. Cuanto menor sea el intervalo entre bloques, más a menudo ocurre esto, y el ZIP relaciona la tasa de bloques obsoletos con la propagación de bloques, el tiempo de verificación y el riesgo de centralización de la minería.
También hay dos costes menores. Las wallets ligeras descargan unos 200 KB más al día de cabeceras de bloques compactas. Y, dado que hay tres veces más bloques, un nodo completo que ha estado desconectado tiene más bloques que procesar al ponerse al día, aunque cada bloque sea más barato de verificar. El ZIP acepta ambos.