#dusk $DUSK Anoche, a las dos, estaba encajonado frente al escritorio de un alquiler, hojeando el “Libro Blanco” @Dusk . En la esquina de la mesa se abrió un rato la lata de Coca-Cola con hielo; el gas se fue y se acabó. Las gotitas de agua que se condensaban por la pared del vaso cayeron sobre la alfombrilla del ratón, extendiéndose en un pequeño círculo de mancha oscura.
Dusk se centra en el escenario financiero con su capa de privacidad Layer1. Su mecanismo de consenso de “Succinct Attestation” (dicho de forma simple) está hecho para frenar esos viejos problemas que ya he pisado infinitas veces en cadenas PoS grandes: que los grandes dominan la producción de bloques, que la fuente de aleatoriedad es fácil de manipular, que la confirmación de bloques es lenta… y, en general, el lío de siempre. Prometen “finalidad determinista en 3 segundos”, resisten un ataque del 51% y, lo más importante, no permitirían que unos pocos grandes con muchas monedas se queden con el poder de decidir quién produce bloques.
Suena impecable.
Descentralización, seguridad y alto rendimiento: son los tres puntos que la industria lleva años discutiendo. ¿Y resulta que dicen que lo cumplen todo? Cuando pasé a la sección sobre la generación de semillas para el sorteo, el Libro Blanco lo describe de forma especialmente vaga. Suelta una frase: “Generada mediante agregación del hash del bloque anterior”. Yo moví el ratón a un lado y me quedé mirando la pantalla dos segundos, sin hacer nada. Si el rendimiento de la aleatoriedad del sorteo de nodos productores de bloques se puede predecir antes por parte de unos pocos nodos grandes, o incluso se pueden confabular para manipularla, entonces eso de “aleatoriedad justa para seleccionar validadores” es puro humo. La cualidad más esencial de una cadena de privacidad —la descentralización de sus nodos— queda recortada a la mitad. La pregunta de si esa “semilla aleatoria” se puede alterar mediante un complot, la entiende cualquiera que trabaje en consenso distribuido, mucho más difícil que solo acelerar la velocidad de producción de bloques. Si el diseño de la fuente de aleatoriedad tiene una debilidad, lo de “alto rendimiento” y “resistencia a ataques” se vuelven consignas que nunca terminan de aterrizar. @Dusk
Aquí hay un conflicto central. Un protocolo que dice estar hecho para servir a la liquidación de activos a nivel institucional: si la lógica verificable del sorteo aleatorio no se explica del todo, la credibilidad del consenso SA en realidad todavía depende de los datos de ejecución a largo plazo en la red principal para validarse, no de las afirmaciones en el texto del Libro Blanco.
El valor a largo plazo de $DUSK , en cierto sentido, queda amarrado a si este mecanismo de consenso puede funcionar realmente en la práctica.
Cuando investigas un proyecto, ¿qué parte del Libro Blanco te preocupa más que esté escrita de forma ambigua? Hablemos en la sección de comentarios.
Dusk se centra en el escenario financiero con su capa de privacidad Layer1. Su mecanismo de consenso de “Succinct Attestation” (dicho de forma simple) está hecho para frenar esos viejos problemas que ya he pisado infinitas veces en cadenas PoS grandes: que los grandes dominan la producción de bloques, que la fuente de aleatoriedad es fácil de manipular, que la confirmación de bloques es lenta… y, en general, el lío de siempre. Prometen “finalidad determinista en 3 segundos”, resisten un ataque del 51% y, lo más importante, no permitirían que unos pocos grandes con muchas monedas se queden con el poder de decidir quién produce bloques.
Suena impecable.
Descentralización, seguridad y alto rendimiento: son los tres puntos que la industria lleva años discutiendo. ¿Y resulta que dicen que lo cumplen todo? Cuando pasé a la sección sobre la generación de semillas para el sorteo, el Libro Blanco lo describe de forma especialmente vaga. Suelta una frase: “Generada mediante agregación del hash del bloque anterior”. Yo moví el ratón a un lado y me quedé mirando la pantalla dos segundos, sin hacer nada. Si el rendimiento de la aleatoriedad del sorteo de nodos productores de bloques se puede predecir antes por parte de unos pocos nodos grandes, o incluso se pueden confabular para manipularla, entonces eso de “aleatoriedad justa para seleccionar validadores” es puro humo. La cualidad más esencial de una cadena de privacidad —la descentralización de sus nodos— queda recortada a la mitad. La pregunta de si esa “semilla aleatoria” se puede alterar mediante un complot, la entiende cualquiera que trabaje en consenso distribuido, mucho más difícil que solo acelerar la velocidad de producción de bloques. Si el diseño de la fuente de aleatoriedad tiene una debilidad, lo de “alto rendimiento” y “resistencia a ataques” se vuelven consignas que nunca terminan de aterrizar. @Dusk
Aquí hay un conflicto central. Un protocolo que dice estar hecho para servir a la liquidación de activos a nivel institucional: si la lógica verificable del sorteo aleatorio no se explica del todo, la credibilidad del consenso SA en realidad todavía depende de los datos de ejecución a largo plazo en la red principal para validarse, no de las afirmaciones en el texto del Libro Blanco.
El valor a largo plazo de $DUSK , en cierto sentido, queda amarrado a si este mecanismo de consenso puede funcionar realmente en la práctica.
Cuando investigas un proyecto, ¿qué parte del Libro Blanco te preocupa más que esté escrita de forma ambigua? Hablemos en la sección de comentarios.