18 de agosto, la SEC de EE. UU. presentó nuevas reglas de criptoactivos, con la intención de establecer una vía de emisión dirigida para ciertos contratos de inversión relacionados con criptoactivos. Una de las excepciones tiene un tope de hasta 75 millones de dólares en 12 meses, pero esto sigue siendo una propuesta, no una ley ya vigente.
Este tema me hace pensar en una pregunta que a menudo se pasa por alto: si un valor realmente tiene que ponerse en la cadena, ¿la contabilidad debe ser totalmente pública o totalmente oculta? La respuesta que da Dusk no es elegir entre una u otra opción, sino conservar tanto Moonlight como Phoenix.
Primero, usemos dos analogías conocidas. Moonlight se parece más a una cuenta bancaria: es un modelo transparente basado en cuentas (account-based), donde la cuenta se identifica mediante una clave pública. El saldo, el nonce y también el remitente, el destinatario y el importe de las transferencias son visibles, lo que encaja con procesos que requieren conciliación, informes o comprobaciones públicas.
Phoenix, en cambio, se parece a un conjunto de pagarés con contraseñas: los activos existen en forma de notas cifradas (encrypted notes), pertenecientes a un modelo basado en UTXO; las transacciones pueden explicar mediante pruebas de conocimiento cero que “tengo derecho a gastar, el saldo alcanza y no hay gasto duplicado”, pero sin necesidad de revelar el importe, las notas concretas ni el remitente.
Pero Phoenix no es “completamente anónimo”. La documentación oficial es explícita: la información del remitente es visible para el destinatario, y además los usuarios pueden usar una viewing key para revelar selectivamente, cuando sea necesario, ante requerimientos regulatorios o de auditoría. Esto es crucial: la protección de la privacidad consiste en evitar la exposición innecesaria a toda la red, no en borrar todas las responsabilidades.
Ambos modelos, al final, están coordinados por el Transfer Contract de DuskDS. Recibe transacciones con distintos formatos, las enruta hacia la lógica de verificación correspondiente y gestiona de manera unificada las comisiones, el estado global y los problemas de doble gasto. Por su naturaleza, todas las transacciones deben cumplir con la propiedad, el saldo y las comisiones, la prevención del doble gasto y la protección contra la manipulación; la diferencia es que Moonlight verifica directamente el estado público, mientras que Phoenix se centra sobre todo en verificar la prueba ZK.
@Dusk $DUSK #dusk
En resumen, sí: el verdadero dilema de Dusk no es “transparencia es mejor o privacidad es mejor”, sino permitir que el mismo sistema financiero elija el significado del libro mayor según el escenario. Cuando se necesite verificación pública, usar Moonlight; cuando se busque reducir la exposición, usar Phoenix.
Este tema me hace pensar en una pregunta que a menudo se pasa por alto: si un valor realmente tiene que ponerse en la cadena, ¿la contabilidad debe ser totalmente pública o totalmente oculta? La respuesta que da Dusk no es elegir entre una u otra opción, sino conservar tanto Moonlight como Phoenix.
Primero, usemos dos analogías conocidas. Moonlight se parece más a una cuenta bancaria: es un modelo transparente basado en cuentas (account-based), donde la cuenta se identifica mediante una clave pública. El saldo, el nonce y también el remitente, el destinatario y el importe de las transferencias son visibles, lo que encaja con procesos que requieren conciliación, informes o comprobaciones públicas.
Phoenix, en cambio, se parece a un conjunto de pagarés con contraseñas: los activos existen en forma de notas cifradas (encrypted notes), pertenecientes a un modelo basado en UTXO; las transacciones pueden explicar mediante pruebas de conocimiento cero que “tengo derecho a gastar, el saldo alcanza y no hay gasto duplicado”, pero sin necesidad de revelar el importe, las notas concretas ni el remitente.
Pero Phoenix no es “completamente anónimo”. La documentación oficial es explícita: la información del remitente es visible para el destinatario, y además los usuarios pueden usar una viewing key para revelar selectivamente, cuando sea necesario, ante requerimientos regulatorios o de auditoría. Esto es crucial: la protección de la privacidad consiste en evitar la exposición innecesaria a toda la red, no en borrar todas las responsabilidades.
Ambos modelos, al final, están coordinados por el Transfer Contract de DuskDS. Recibe transacciones con distintos formatos, las enruta hacia la lógica de verificación correspondiente y gestiona de manera unificada las comisiones, el estado global y los problemas de doble gasto. Por su naturaleza, todas las transacciones deben cumplir con la propiedad, el saldo y las comisiones, la prevención del doble gasto y la protección contra la manipulación; la diferencia es que Moonlight verifica directamente el estado público, mientras que Phoenix se centra sobre todo en verificar la prueba ZK.
@Dusk $DUSK #dusk
En resumen, sí: el verdadero dilema de Dusk no es “transparencia es mejor o privacidad es mejor”, sino permitir que el mismo sistema financiero elija el significado del libro mayor según el escenario. Cuando se necesite verificación pública, usar Moonlight; cuando se busque reducir la exposición, usar Phoenix.