#dusk Reordené de nuevo los documentos de arquitectura de @Dusk y lo primero que me bloqueó no fue la prueba de conocimiento cero, sino el hecho de que, por qué una misma red necesita conservar al mismo tiempo dos rutas de transferencias: una pública y otra privada. Muchos proyectos tratan la privacidad como un interruptor: si se activa, ya no se ve; si se desactiva, todo queda totalmente transparente. Pero cuando entras en escenarios financieros reales, esa opción binaria se queda corta: el pagador quiere proteger su saldo, el emisor quizá necesite verificar credenciales y el auditor tiene que obtener evidencia dentro de un alcance específico.
En la capa base, Dusk implementa Moonlight como un modelo de cuenta pública y Phoenix como un modelo UTXO de tipo privado. Ambos pueden transferir $DUSK , pagar Gas y funcionar como puntos de entrada para la ejecución de contratos. Por encima, se separan DuskVM, para ejecutar contratos Rust/WASM directamente, y DuskEVM, orientado al toolchain de Solidity. Lo verdaderamente interesante de esta combinación no es la frase “cadena de privacidad”, sino que permite que el cierre público, las transferencias privadas y la compatibilidad con aplicaciones asuman tareas distintas.
Pero que la separación por capas sea clara no significa que los límites para el usuario lo sean de forma natural. Cuándo el dinero pasa de un saldo público a un saldo privado, quién tiene el derecho de divulgación selectiva, si una aplicación usa DuskVM o DuskEVM, si los estados entre capas pueden ser verificados por una persona común: todo eso incrementa la carga de comprensión. Especialmente con activos sujetos a regulación, la privacidad no es negarse a divulgar, sino limitar a quién se divulga, qué contenido y en qué momento; cualquier diseño de permisos ambiguo al final podría convertirse en otra clase de caja negra.
Así que, al mirar Dusk ahora, no solo pregunto si puede ocultar una transferencia. Me importa más: cuando se requiere lo público, si puede aportar evidencia suficiente; cuando se requiere confidencialidad, si puede filtrar la menor información no relacionada posible; y si después de cambiar entre ambos caminos se mantiene la claridad. La dirección de la arquitectura es válida; lo realmente difícil es hacer que la complejidad permanezca en el protocolo, en vez de trasladársela al usuario.
$SNXXB $BTC
En la capa base, Dusk implementa Moonlight como un modelo de cuenta pública y Phoenix como un modelo UTXO de tipo privado. Ambos pueden transferir $DUSK , pagar Gas y funcionar como puntos de entrada para la ejecución de contratos. Por encima, se separan DuskVM, para ejecutar contratos Rust/WASM directamente, y DuskEVM, orientado al toolchain de Solidity. Lo verdaderamente interesante de esta combinación no es la frase “cadena de privacidad”, sino que permite que el cierre público, las transferencias privadas y la compatibilidad con aplicaciones asuman tareas distintas.
Pero que la separación por capas sea clara no significa que los límites para el usuario lo sean de forma natural. Cuándo el dinero pasa de un saldo público a un saldo privado, quién tiene el derecho de divulgación selectiva, si una aplicación usa DuskVM o DuskEVM, si los estados entre capas pueden ser verificados por una persona común: todo eso incrementa la carga de comprensión. Especialmente con activos sujetos a regulación, la privacidad no es negarse a divulgar, sino limitar a quién se divulga, qué contenido y en qué momento; cualquier diseño de permisos ambiguo al final podría convertirse en otra clase de caja negra.
Así que, al mirar Dusk ahora, no solo pregunto si puede ocultar una transferencia. Me importa más: cuando se requiere lo público, si puede aportar evidencia suficiente; cuando se requiere confidencialidad, si puede filtrar la menor información no relacionada posible; y si después de cambiar entre ambos caminos se mantiene la claridad. La dirección de la arquitectura es válida; lo realmente difícil es hacer que la complejidad permanezca en el protocolo, en vez de trasladársela al usuario.
$SNXXB $BTC
