Hoy revisé el documento de arquitectura técnica de Dusk y los cambios de actualización de Phoenix 2.0 son la optimización que considero que mejor se ajusta a necesidades reales.
La versión anterior de Phoenix tenía una debilidad bastante evidente en su mecanismo de privacidad: la protección de privacidad llevada al extremo generaba un “punto ciego” de la información. Después de que un usuario realiza una transferencia, el destinatario no puede identificar el origen de la misma; y si surge la necesidad de reembolsar o verificar el origen de los fondos, básicamente no hay soluciones viables.
Para los pequeños inversores esto no suele afectar demasiado, pero para las instituciones que quieren entrar al mercado, esta es una carencia fatal. Sin un canal de conciliación no se puede completar una auditoría de cumplimiento, y si aparecen problemas con los fondos tampoco se pueden rastrear. Esto no cumple en absoluto los requisitos de control de riesgos de las instituciones. Phoenix 2.0 solucionó este dolor de forma dirigida. Tras la actualización, los datos centrales de la transacción se mantienen cifrados, garantizando la privacidad de los activos del usuario, pero se añaden datos de identificación: el destinatario puede reconocer correctamente la dirección de la transferencia.
El punto más práctico es que el destinatario puede devolver los activos directamente por la misma ruta; todo el proceso no rompe la privacidad de la transacción.
A primera vista parece una mejora pequeña, pero en realidad equilibra dos puntos más difíciles de conciliar en la industria: la protección de privacidad en la cadena y la auditabilidad conforme a normativa.
Las instituciones no necesitan una anonimidad absoluta en la que nunca se pueda rastrear, sino una privacidad controlada y suficientemente transparente. En los escenarios donde se necesita verificar el origen, se puede comprobar de forma normal; y en las transacciones donde se requiere confidencialidad, los detalles se mantienen cifrados y ocultos en todo momento. @Dusk
El diseño de visibilidad selectiva de Phoenix 2.0 es mucho más pragmático que proyectos que simplemente apilan tecnologías de pruebas de conocimiento cero, y se ajusta perfectamente a las necesidades de implementación de las finanzas tradicionales.
Sin embargo, considero que, aunque el diseño teórico sea perfecto, no significa que la operación real esté libre de problemas. Es necesario verificar con el tiempo y con datos reales en la cadena si este mecanismo puede soportar transacciones frecuentes y a gran escala, y cuál es su estabilidad a largo plazo. #dusk $DUSK
La versión anterior de Phoenix tenía una debilidad bastante evidente en su mecanismo de privacidad: la protección de privacidad llevada al extremo generaba un “punto ciego” de la información. Después de que un usuario realiza una transferencia, el destinatario no puede identificar el origen de la misma; y si surge la necesidad de reembolsar o verificar el origen de los fondos, básicamente no hay soluciones viables.
Para los pequeños inversores esto no suele afectar demasiado, pero para las instituciones que quieren entrar al mercado, esta es una carencia fatal. Sin un canal de conciliación no se puede completar una auditoría de cumplimiento, y si aparecen problemas con los fondos tampoco se pueden rastrear. Esto no cumple en absoluto los requisitos de control de riesgos de las instituciones. Phoenix 2.0 solucionó este dolor de forma dirigida. Tras la actualización, los datos centrales de la transacción se mantienen cifrados, garantizando la privacidad de los activos del usuario, pero se añaden datos de identificación: el destinatario puede reconocer correctamente la dirección de la transferencia.
El punto más práctico es que el destinatario puede devolver los activos directamente por la misma ruta; todo el proceso no rompe la privacidad de la transacción.
A primera vista parece una mejora pequeña, pero en realidad equilibra dos puntos más difíciles de conciliar en la industria: la protección de privacidad en la cadena y la auditabilidad conforme a normativa.
Las instituciones no necesitan una anonimidad absoluta en la que nunca se pueda rastrear, sino una privacidad controlada y suficientemente transparente. En los escenarios donde se necesita verificar el origen, se puede comprobar de forma normal; y en las transacciones donde se requiere confidencialidad, los detalles se mantienen cifrados y ocultos en todo momento. @Dusk
El diseño de visibilidad selectiva de Phoenix 2.0 es mucho más pragmático que proyectos que simplemente apilan tecnologías de pruebas de conocimiento cero, y se ajusta perfectamente a las necesidades de implementación de las finanzas tradicionales.
Sin embargo, considero que, aunque el diseño teórico sea perfecto, no significa que la operación real esté libre de problemas. Es necesario verificar con el tiempo y con datos reales en la cadena si este mecanismo puede soportar transacciones frecuentes y a gran escala, y cuál es su estabilidad a largo plazo. #dusk $DUSK
