Un solo número me detuvo: capacidad para más de 17 mil millones de hojas, de un árbol que solo tiene 34 niveles de profundidad.
El modelo Fénix de Dusk usa un árbol Merkle binario para almacenar la prueba de cada nota, y ahí es donde está el verdadero truco: la capacidad crece de forma exponencial mientras que la ruta de inclusión solo crece de forma lineal. Pasa de la profundidad 34 a la 35 y la capacidad se duplica, pero el camino de la prueba solo se alarga unos pocos puntos porcentuales. Esta asimetría importa mucho para una cadena enfocada en la privacidad, ya que cada transacción lleva una prueba de conocimiento cero; cuanto más pequeña se mantenga esa prueba, mejor.
Pero el tamaño del número es solo un techo teórico. Lo que realmente determina cuánto dura esa capacidad es la rapidez con la que, en la práctica, se crean nuevas notas. Con un bajo rendimiento de transacciones, el árbol podría tardar décadas en llenarse. Si la adopción se dispara, esa misma capacidad podría verse sometida a presión real en cuestión de meses.
Eso plantea la pregunta más interesante: ¿qué ocurre cuando el árbol se llena? Almacenamiento de archivo, costos de verificación, sincronización de estado: ¿escalan de manera adecuada junto con la creación de notas, o es algo lo primero que empieza a fallar? Un número enorme luce impresionante en el papel, pero la usabilidad a largo plazo depende de cómo se use ese número, no solo de qué tan grande sea.
¿Tener una capacidad matemáticamente enorme es lo mismo que seguir estando cómodo para operar durante años de uso real?
#dusk $DUSK @Dusk
El modelo Fénix de Dusk usa un árbol Merkle binario para almacenar la prueba de cada nota, y ahí es donde está el verdadero truco: la capacidad crece de forma exponencial mientras que la ruta de inclusión solo crece de forma lineal. Pasa de la profundidad 34 a la 35 y la capacidad se duplica, pero el camino de la prueba solo se alarga unos pocos puntos porcentuales. Esta asimetría importa mucho para una cadena enfocada en la privacidad, ya que cada transacción lleva una prueba de conocimiento cero; cuanto más pequeña se mantenga esa prueba, mejor.
Pero el tamaño del número es solo un techo teórico. Lo que realmente determina cuánto dura esa capacidad es la rapidez con la que, en la práctica, se crean nuevas notas. Con un bajo rendimiento de transacciones, el árbol podría tardar décadas en llenarse. Si la adopción se dispara, esa misma capacidad podría verse sometida a presión real en cuestión de meses.
Eso plantea la pregunta más interesante: ¿qué ocurre cuando el árbol se llena? Almacenamiento de archivo, costos de verificación, sincronización de estado: ¿escalan de manera adecuada junto con la creación de notas, o es algo lo primero que empieza a fallar? Un número enorme luce impresionante en el papel, pero la usabilidad a largo plazo depende de cómo se use ese número, no solo de qué tan grande sea.
¿Tener una capacidad matemáticamente enorme es lo mismo que seguir estando cómodo para operar durante años de uso real?
#dusk $DUSK @Dusk
