He estado mirando los documentos de Dusk durante demasiado tiempo y algo no encaja.
Los validadores comprueban pruebas, no importes de transacciones. Las matemáticas cuadran, dan el visto bueno. Pero eso significa que si el circuito ZK tiene un error, la red queda en ruinas y nadie se daría cuenta hasta que ya sea tarde. En Bitcoin, los mineros ven el absurdo. ¿Y aquí? Fe ciega total en el código. Eso... me resulta inquietante.
Lo de las claves de auditoría también me está removiendo. Son ventanas de visualización con límite de tiempo —o eso dicen—. Pero en realidad estás entregando una descarga de todo tu historial. La ventana se cierra, pero el servidor del regulador sigue teniendo tus transacciones en texto plano en su base de datos para siempre. No puedes revocar un recuerdo. No puedes des-enviar esos datos.
La estructura de comisiones cuenta su propia historia. El circuito más amigable para la normativa cuesta más, así que pagas extra para anunciarle a toda la red que eres el tipo que intenta esconderse del público pero mostrarle al gobierno. Parece ponerse una máscara, pero pagando con una tarjeta de crédito que tiene tu nombre.
Luego está la situación de varios reguladores. Puedes dar claves separadas a la SEC y al IRS. Pero si te auditan ambos, significa generar dos pruebas completamente distintas. Doble tiempo de CPU. Doble probabilidad de que algo falle. No veo que se comente en ningún sitio.
Aun así no logro entender qué pasa si pierdes el archivo de clave de cumplimiento. ¿Hay una ruta de recuperación? Si la hay, ¿no introduce eso una clave maestra que lo rompe todo? Si no la hay, entonces simplemente quedas permanentemente incapaz de demostrarlo. Culpa de un fallo de hardware.
Es una arquitectura ingeniosa, pero algunos de estos compromisos se sienten como si estuvieran maquillados. Me interesa de verdad saber si alguien ha ejecutado realmente un nodo de testnet a través del escenario de doble regulador. Apostaría a que la UX es una pesadilla.
@Dusk_Foundation #dusk #DUSK $DUSK
Los validadores comprueban pruebas, no importes de transacciones. Las matemáticas cuadran, dan el visto bueno. Pero eso significa que si el circuito ZK tiene un error, la red queda en ruinas y nadie se daría cuenta hasta que ya sea tarde. En Bitcoin, los mineros ven el absurdo. ¿Y aquí? Fe ciega total en el código. Eso... me resulta inquietante.
Lo de las claves de auditoría también me está removiendo. Son ventanas de visualización con límite de tiempo —o eso dicen—. Pero en realidad estás entregando una descarga de todo tu historial. La ventana se cierra, pero el servidor del regulador sigue teniendo tus transacciones en texto plano en su base de datos para siempre. No puedes revocar un recuerdo. No puedes des-enviar esos datos.
La estructura de comisiones cuenta su propia historia. El circuito más amigable para la normativa cuesta más, así que pagas extra para anunciarle a toda la red que eres el tipo que intenta esconderse del público pero mostrarle al gobierno. Parece ponerse una máscara, pero pagando con una tarjeta de crédito que tiene tu nombre.
Luego está la situación de varios reguladores. Puedes dar claves separadas a la SEC y al IRS. Pero si te auditan ambos, significa generar dos pruebas completamente distintas. Doble tiempo de CPU. Doble probabilidad de que algo falle. No veo que se comente en ningún sitio.
Aun así no logro entender qué pasa si pierdes el archivo de clave de cumplimiento. ¿Hay una ruta de recuperación? Si la hay, ¿no introduce eso una clave maestra que lo rompe todo? Si no la hay, entonces simplemente quedas permanentemente incapaz de demostrarlo. Culpa de un fallo de hardware.
Es una arquitectura ingeniosa, pero algunos de estos compromisos se sienten como si estuvieran maquillados. Me interesa de verdad saber si alguien ha ejecutado realmente un nodo de testnet a través del escenario de doble regulador. Apostaría a que la UX es una pesadilla.
@Dusk_Foundation #dusk #DUSK $DUSK