Cuando vuelvo a mirar @Dusk , lo que realmente me hizo detenerme no fue la tecnología de privacidad, sino un problema más realista: después de tokenizar en cadena activos como los valores, ¿la calificación del inversor, las restricciones a la transferencia y la divulgación de información pueden convertirse directamente en reglas de la cadena?
El modelo Phoenix de Dusk me dio una respuesta bastante interesante. Las transacciones pueden ocultar a las partes participantes y los importes, y aun así permitir una divulgación dirigida mediante un viewing key. Para los activos financieros, esto es más útil que perseguir simplemente el objetivo de “que nadie lo vea”, porque normalmente lo que la regulación necesita no es todo el conjunto de datos, sino la verificación de datos específicos bajo condiciones concretas. Moonlight conserva el modelo de cuentas públicas, y DuskDS se encarga del asentamiento a nivel de infraestructura. Ambos enfoques pueden servir a distintas necesidades de negocio.
Pero también creo que la mayor ventaja de este diseño, al mismo tiempo, podría convertirse en un umbral para el ecosistema. DuskVM está orientada a Rust y WASM, y es adecuada para aplicaciones nativas de privacidad y de conocimiento cero. DuskEVM, en cambio, es compatible con Solidity y las herramientas existentes del EVM. Tener más opciones no necesariamente hace que el desarrollo sea más sencillo: si al final el equipo usa principalmente EVM, la diferencia técnica de Dusk podría quedar atenuada. El problema más real, sin embargo, es el coste computacional de las pruebas de conocimiento cero y los requisitos de recursos de hardware para el Prover; esos factores también acabarán convirtiéndose en retos de ingeniería que habrá que resolver para escalar aplicaciones.
En la capa de tokens, me interesa más la necesidad real de uso de $DUSK , y no solo mirar la oferta por separado. Como activo nativo de la red, DUSK se relaciona directamente con funciones de la red como las comisiones de transacción y el staking. Esto significa que cuánto valor puede terminar soportando depende, en gran medida, de si la red puede seguir incrementando actividad real. El diseño oficial de la oferta utiliza un mecanismo de liberación a largo plazo, con un tope máximo de mil millones de monedas. Para mí, estos datos por sí mismos no son lo más importante; lo realmente valioso que observar es si el uso futuro de la red podrá alinearse con las necesidades funcionales de los tokens.
Ahora que miro Dusk otra vez, me importa más si puede integrar de verdad la privacidad, la identidad y las reglas de los activos en los flujos cotidianos del negocio financiero. Las capacidades técnicas resuelven el “si se puede hacer”; la adopción real es lo que responde al “si hace falta hacerlo”. Para Dusk, lo más importante que convendría observar después quizá no sea añadir más módulos tecnológicos, sino si cada vez más activos reales están dispuestos a quedarse.#dusk
El modelo Phoenix de Dusk me dio una respuesta bastante interesante. Las transacciones pueden ocultar a las partes participantes y los importes, y aun así permitir una divulgación dirigida mediante un viewing key. Para los activos financieros, esto es más útil que perseguir simplemente el objetivo de “que nadie lo vea”, porque normalmente lo que la regulación necesita no es todo el conjunto de datos, sino la verificación de datos específicos bajo condiciones concretas. Moonlight conserva el modelo de cuentas públicas, y DuskDS se encarga del asentamiento a nivel de infraestructura. Ambos enfoques pueden servir a distintas necesidades de negocio.
Pero también creo que la mayor ventaja de este diseño, al mismo tiempo, podría convertirse en un umbral para el ecosistema. DuskVM está orientada a Rust y WASM, y es adecuada para aplicaciones nativas de privacidad y de conocimiento cero. DuskEVM, en cambio, es compatible con Solidity y las herramientas existentes del EVM. Tener más opciones no necesariamente hace que el desarrollo sea más sencillo: si al final el equipo usa principalmente EVM, la diferencia técnica de Dusk podría quedar atenuada. El problema más real, sin embargo, es el coste computacional de las pruebas de conocimiento cero y los requisitos de recursos de hardware para el Prover; esos factores también acabarán convirtiéndose en retos de ingeniería que habrá que resolver para escalar aplicaciones.
En la capa de tokens, me interesa más la necesidad real de uso de $DUSK , y no solo mirar la oferta por separado. Como activo nativo de la red, DUSK se relaciona directamente con funciones de la red como las comisiones de transacción y el staking. Esto significa que cuánto valor puede terminar soportando depende, en gran medida, de si la red puede seguir incrementando actividad real. El diseño oficial de la oferta utiliza un mecanismo de liberación a largo plazo, con un tope máximo de mil millones de monedas. Para mí, estos datos por sí mismos no son lo más importante; lo realmente valioso que observar es si el uso futuro de la red podrá alinearse con las necesidades funcionales de los tokens.
Ahora que miro Dusk otra vez, me importa más si puede integrar de verdad la privacidad, la identidad y las reglas de los activos en los flujos cotidianos del negocio financiero. Las capacidades técnicas resuelven el “si se puede hacer”; la adopción real es lo que responde al “si hace falta hacerlo”. Para Dusk, lo más importante que convendría observar después quizá no sea añadir más módulos tecnológicos, sino si cada vez más activos reales están dispuestos a quedarse.#dusk