Antes veía @Dusk hablando a la vez de Moonlight y Phoenix y pensaba que era como si hicieran dos sistemas: “transferencia normal” y “transferencia privada”, con funciones duplicadas. Pero al leer juntos la documentación del modelo de transacciones y las instrucciones de integración del exchange, descubrí que no era para presumir con dos modelos, sino una aceptación activa dentro de la misma capa de liquidación: algunos flujos de fondos deben ser públicos y otros no deberían exponer a todos ni el importe ni la relación.
Moonlight es un modelo de cuentas públicas: el saldo, el remitente, el destinatario y el importe se ven. Se adapta mejor a recargas del exchange, a tesorerías y a escenarios en los que es necesario realizar conciliaciones que deben ser públicas. Phoenix, en cambio, coloca los fondos en un note cifrado: mediante pruebas de conocimiento cero confirma que no hay doble gasto y que el saldo es suficiente, sin divulgar al espectador el importe concreto ni el note correspondiente; cuando se requiere auditoría, se puede revelar de forma selectiva mediante una viewing key.
Aquí está la confusión principal: “como hay privacidad, el navegador no puede ver nada”. El navegador oficial aún puede ver metadatos públicos como el bloque, el tipo de transacción, la comisión y el gas; el alcance exacto depende del modelo de transacciones y del contrato. Al revés, el exchange tampoco puede tratar Phoenix como Moonlight para hacer un barrido directo: la documentación oficial de integración sugiere explícitamente que la recarga se realice usando Moonlight; los saldos privados deben convertirse primero en cuentas públicas. La lógica de custodia y de barrido es completamente distinta.
Por eso, el verdadero reto de $DUSK no es demostrar que la privacidad se puede hacer, sino lograr que el usuario, al alternar entre lo público y lo privado, no tome el camino equivocado. Si #dusk va a entrar en flujos de fondos regulados, deben cumplirse simultáneamente: privacidad por defecto, divulgación bajo demanda y custodia predecible. ¿Qué os preocupa más: que la transparencia total filtre posiciones, o que los dos modelos eleven demasiado la complejidad del producto?
Moonlight es un modelo de cuentas públicas: el saldo, el remitente, el destinatario y el importe se ven. Se adapta mejor a recargas del exchange, a tesorerías y a escenarios en los que es necesario realizar conciliaciones que deben ser públicas. Phoenix, en cambio, coloca los fondos en un note cifrado: mediante pruebas de conocimiento cero confirma que no hay doble gasto y que el saldo es suficiente, sin divulgar al espectador el importe concreto ni el note correspondiente; cuando se requiere auditoría, se puede revelar de forma selectiva mediante una viewing key.
Aquí está la confusión principal: “como hay privacidad, el navegador no puede ver nada”. El navegador oficial aún puede ver metadatos públicos como el bloque, el tipo de transacción, la comisión y el gas; el alcance exacto depende del modelo de transacciones y del contrato. Al revés, el exchange tampoco puede tratar Phoenix como Moonlight para hacer un barrido directo: la documentación oficial de integración sugiere explícitamente que la recarga se realice usando Moonlight; los saldos privados deben convertirse primero en cuentas públicas. La lógica de custodia y de barrido es completamente distinta.
Por eso, el verdadero reto de $DUSK no es demostrar que la privacidad se puede hacer, sino lograr que el usuario, al alternar entre lo público y lo privado, no tome el camino equivocado. Si #dusk va a entrar en flujos de fondos regulados, deben cumplirse simultáneamente: privacidad por defecto, divulgación bajo demanda y custodia predecible. ¿Qué os preocupa más: que la transparencia total filtre posiciones, o que los dos modelos eleven demasiado la complejidad del producto?
