Anoche volví a consultar la documentación de Dusk, centrándome en comprender el papel real $DUSK que desempeña dentro del protocolo—su función técnica más que la historia impulsada por el mercado.
Lo primero que tuve que desentrañar fueron los dos modelos de transacción de DuskDS. Moonlight es la ruta conocida: cuentas públicas, saldos visibles, remitente, destinatario, cantidad. Phoenix funciona con “notas” cifradas. Para gastar una, el usuario proporciona una prueba de conocimiento cero que demuestra que las reglas de propiedad y saldo se cumplen. Piensa en entregarle a un cajero un sobre sellado cuya firma demuestra que se marcaron todas las casillas necesarias, sin revelar el contenido. Luego, un nullifier permite que la red rechace un segundo gasto sin identificar qué nota del árbol público se utilizó. Leí esa parte dos veces—después una notificación me apartó—porque privacidad no significa “que no se verifica nada”. Significa que la red verifica una prueba en lugar de los detalles ocultos de la transacción. Las claves de visualización pueden revelar información de forma selectiva.
El consenso tuvo otra pasada. Dusk lo llama Attestation concisa: los stakers, o provisioners, bloquean DUSK; la selección determinista ponderada por el stake elige un proponente de bloque, luego un comité valida y otro ratifica. Las firmas agregadas se convierten en una atestación de que un quórum estuvo de acuerdo. Así que $DUSK es tanto el gas como la participación respaldada por el stake.
La parte que examinaría después es la concentración. La selección es sin permiso, pero ¿qué tan distribuidos están en la práctica los créditos efectivos del comité? En las páginas que leí, no pude encontrar una explicación clara de quién cambia los parámetros globales. quizá se me escapó.
¿Qué evidencia mostraría que el poder del comité está genuinamente distribuido? ¿Cómo se gobiernan las claves de visualización en despliegues reales? ¿Quién puede cambiar los parámetros del protocolo y a través de qué proceso?
#dusk $DUSK @Dusk
Lo primero que tuve que desentrañar fueron los dos modelos de transacción de DuskDS. Moonlight es la ruta conocida: cuentas públicas, saldos visibles, remitente, destinatario, cantidad. Phoenix funciona con “notas” cifradas. Para gastar una, el usuario proporciona una prueba de conocimiento cero que demuestra que las reglas de propiedad y saldo se cumplen. Piensa en entregarle a un cajero un sobre sellado cuya firma demuestra que se marcaron todas las casillas necesarias, sin revelar el contenido. Luego, un nullifier permite que la red rechace un segundo gasto sin identificar qué nota del árbol público se utilizó. Leí esa parte dos veces—después una notificación me apartó—porque privacidad no significa “que no se verifica nada”. Significa que la red verifica una prueba en lugar de los detalles ocultos de la transacción. Las claves de visualización pueden revelar información de forma selectiva.
El consenso tuvo otra pasada. Dusk lo llama Attestation concisa: los stakers, o provisioners, bloquean DUSK; la selección determinista ponderada por el stake elige un proponente de bloque, luego un comité valida y otro ratifica. Las firmas agregadas se convierten en una atestación de que un quórum estuvo de acuerdo. Así que $DUSK es tanto el gas como la participación respaldada por el stake.
La parte que examinaría después es la concentración. La selección es sin permiso, pero ¿qué tan distribuidos están en la práctica los créditos efectivos del comité? En las páginas que leí, no pude encontrar una explicación clara de quién cambia los parámetros globales. quizá se me escapó.
¿Qué evidencia mostraría que el poder del comité está genuinamente distribuido? ¿Cómo se gobiernan las claves de visualización en despliegues reales? ¿Quién puede cambiar los parámetros del protocolo y a través de qué proceso?
#dusk $DUSK @Dusk
