#dusk $DUSK @Dusk
Hermanos, Ma quiere hablar esta vez de algo sobre cómo los nodos de Dusk se dividen en tres roles. En la capa de privacidad, ¿quién se encarga de calcular las pruebas de conocimiento cero? Esto podría determinar en silencio qué tan descentralizada está realmente esta cadena.
Los nodos de Dusk se dividen en tres tipos: los Provisioner, que participan en el consenso; los Archive, que almacenan un historial de datos más completo; y además hay un rol encargado específicamente de generar pruebas de conocimiento cero. Los dos primeros roles, Ma cree más o menos que entiende en qué umbrales se basan: para participar en el consenso hay que hacer staking, y para guardar el historial se necesita espacio en disco. En ambos casos, el costo suele ser relativamente lineal.
Lo de generar pruebas de conocimiento cero es diferente. La carga computacional de las pruebas ZK suele ser mucho mayor que la de validar una transacción normal. Especialmente en el modelo de transacciones de privacidad de Phoenix: detrás de cada transacción que debe mantenerse en secreto, hay que calcular una prueba. Esa intensidad de cómputo no aguanta fácilmente con cualquier computadora de casa.
Esto nos lleva a una pregunta: si la generación de pruebas requiere hardware más especializado o más potencia de cómputo para completarse de manera eficiente, ¿podría hacer que, en la práctica, los participantes dispuestos a hacer este trabajo se concentren en unos pocos equipos con recursos? ¿Podrían los usuarios comunes participar de forma justa? Son órdenes de magnitud completamente distintos. El modelo de cuentas de Moonlight, que es transparente, en teoría lo puede verificar cualquiera porque la lógica es simple; pero en el modelo de Phoenix, que es privado, si el umbral para generar las pruebas es alto, la disponibilidad de la función de privacidad y el nivel de descentralización podrían resultar, paradójicamente, peores que en la parte transparente.
Por ahora, Ma no ha encontrado información oficial sobre cuánta potencia de cómputo se necesita específicamente para generar una prueba de Phoenix, ni si los usuarios normales pueden ejecutarla en casa de forma fluida. Este vacío de datos es bastante clave, porque determina directamente si el argumento de venta de las transacciones privadas es una función base que cualquiera puede usar, o si en realidad depende indirectamente de unos pocos nodos profesionales que sostienen todo desde atrás.
Si de verdad existe esta diferencia de umbral, entonces indica que la descentralización de los distintos módulos de una misma cadena no es necesariamente igual. No se puede decir en general qué tan descentralizada es una cadena; hay que desglosar cada función y analizarla por separado.
Hermanos, ¿alguno ha ejecutado realmente transacciones de Phoenix? ¿Cuánto tarda aproximadamente generar la prueba en local? ¿Hay algún bloqueo o lag notable? Comentemos en la sección de comentarios.
Hermanos, Ma quiere hablar esta vez de algo sobre cómo los nodos de Dusk se dividen en tres roles. En la capa de privacidad, ¿quién se encarga de calcular las pruebas de conocimiento cero? Esto podría determinar en silencio qué tan descentralizada está realmente esta cadena.
Los nodos de Dusk se dividen en tres tipos: los Provisioner, que participan en el consenso; los Archive, que almacenan un historial de datos más completo; y además hay un rol encargado específicamente de generar pruebas de conocimiento cero. Los dos primeros roles, Ma cree más o menos que entiende en qué umbrales se basan: para participar en el consenso hay que hacer staking, y para guardar el historial se necesita espacio en disco. En ambos casos, el costo suele ser relativamente lineal.
Lo de generar pruebas de conocimiento cero es diferente. La carga computacional de las pruebas ZK suele ser mucho mayor que la de validar una transacción normal. Especialmente en el modelo de transacciones de privacidad de Phoenix: detrás de cada transacción que debe mantenerse en secreto, hay que calcular una prueba. Esa intensidad de cómputo no aguanta fácilmente con cualquier computadora de casa.
Esto nos lleva a una pregunta: si la generación de pruebas requiere hardware más especializado o más potencia de cómputo para completarse de manera eficiente, ¿podría hacer que, en la práctica, los participantes dispuestos a hacer este trabajo se concentren en unos pocos equipos con recursos? ¿Podrían los usuarios comunes participar de forma justa? Son órdenes de magnitud completamente distintos. El modelo de cuentas de Moonlight, que es transparente, en teoría lo puede verificar cualquiera porque la lógica es simple; pero en el modelo de Phoenix, que es privado, si el umbral para generar las pruebas es alto, la disponibilidad de la función de privacidad y el nivel de descentralización podrían resultar, paradójicamente, peores que en la parte transparente.
Por ahora, Ma no ha encontrado información oficial sobre cuánta potencia de cómputo se necesita específicamente para generar una prueba de Phoenix, ni si los usuarios normales pueden ejecutarla en casa de forma fluida. Este vacío de datos es bastante clave, porque determina directamente si el argumento de venta de las transacciones privadas es una función base que cualquiera puede usar, o si en realidad depende indirectamente de unos pocos nodos profesionales que sostienen todo desde atrás.
Si de verdad existe esta diferencia de umbral, entonces indica que la descentralización de los distintos módulos de una misma cadena no es necesariamente igual. No se puede decir en general qué tan descentralizada es una cadena; hay que desglosar cada función y analizarla por separado.
Hermanos, ¿alguno ha ejecutado realmente transacciones de Phoenix? ¿Cuánto tarda aproximadamente generar la prueba en local? ¿Hay algún bloqueo o lag notable? Comentemos en la sección de comentarios.