La primera vez que vi el sistema de cuentas con doble carril del @Dusk , interpreté de forma automática que era “una cuenta pública, una cuenta privada, y listo: se cambia en el monedero”. Pero lo realmente problemático de esto no está en los botones de la interfaz, sino en que, en el nivel subyacente, la estructura del libro contable no tiene nada que ver con eso. $DUSK
Moonlight utiliza un modelo de cuentas: la relación entre saldos y direcciones, y el flujo de fondos, es más fácil de auditar. Para los exchanges, los custodios y las instituciones que hacen KYC, este camino público es crucial, porque las revisiones de cumplimiento necesitan poder explicar claramente de dónde viene el dinero y a dónde va. Phoenix, en cambio, sigue otra lógica: sobre una estructura UTXO superpone pruebas de conocimiento cero PLONK para ocultar el importe y la información del contrapartido. El validador solo confirma que la transacción es válida, sin necesidad de ver los datos originales. $BTC
Por eso, pasar de Moonlight a Phoenix no es solo cambiar el modo de visualización. El saldo público primero pasa por shield, luego se regeneran compromisos de privacidad; además, en local hay que generar la prueba y, en la cadena, se valida. Es como volver a meter un asiento contable “claro” en una caja sellada: no es que al producto le falte un atajo, sino que entre el modelo de cuenta y los UTXO de privacidad debe existir una transformación criptográfica.
Esto también explica por qué las operaciones entre carriles son más pesadas. La ruta de transferencia normal de Moonlight es más corta y barata; al entrar en Phoenix, se añaden generación de pruebas, interacción con contratos y tiempos de espera para la confirmación. Para usuarios con montos pequeños, esos costos se notan mucho. Al final, lo que era solo proteger la privacidad de una transferencia se vuelve más complejo de operar y además suben las comisiones: la experiencia se resiente de forma natural.
Pero si lo llevas a escenarios RWA o de trading institucional, el diseño de doble carril de Dusk muestra su enfoque. Moonlight puede asumir las partes “que necesariamente deben verse”: cumplimiento, custodia y auditoría. Phoenix, por su parte, gestiona lo que “no conviene que todo el mercado esté mirando”, como cotizaciones, contrapartes y ajustes de posiciones. No intenta resolver únicamente las transferencias privadas, sino cómo se reparten las funciones cuando coexisten cumplimiento y privacidad. $ETH
#dusk El mayor obstáculo ahora es que, cuando el usuario mueve activos entre dos carriles, debe percibir el proceso de conversión, y también debe pagar por ello y esperar. Si en el futuro se pudieran hacer shield en lote, agregación de pruebas y abstracción del enrutamiento, comprimiendo múltiples operaciones en una experiencia más parecida a un solo settlement, entonces el uso de Phoenix tendría mucho más alcance. Hasta que eso ocurra, Moonlight seguirá siendo la puerta principal para la mayoría.
Moonlight utiliza un modelo de cuentas: la relación entre saldos y direcciones, y el flujo de fondos, es más fácil de auditar. Para los exchanges, los custodios y las instituciones que hacen KYC, este camino público es crucial, porque las revisiones de cumplimiento necesitan poder explicar claramente de dónde viene el dinero y a dónde va. Phoenix, en cambio, sigue otra lógica: sobre una estructura UTXO superpone pruebas de conocimiento cero PLONK para ocultar el importe y la información del contrapartido. El validador solo confirma que la transacción es válida, sin necesidad de ver los datos originales. $BTC
Por eso, pasar de Moonlight a Phoenix no es solo cambiar el modo de visualización. El saldo público primero pasa por shield, luego se regeneran compromisos de privacidad; además, en local hay que generar la prueba y, en la cadena, se valida. Es como volver a meter un asiento contable “claro” en una caja sellada: no es que al producto le falte un atajo, sino que entre el modelo de cuenta y los UTXO de privacidad debe existir una transformación criptográfica.
Esto también explica por qué las operaciones entre carriles son más pesadas. La ruta de transferencia normal de Moonlight es más corta y barata; al entrar en Phoenix, se añaden generación de pruebas, interacción con contratos y tiempos de espera para la confirmación. Para usuarios con montos pequeños, esos costos se notan mucho. Al final, lo que era solo proteger la privacidad de una transferencia se vuelve más complejo de operar y además suben las comisiones: la experiencia se resiente de forma natural.
Pero si lo llevas a escenarios RWA o de trading institucional, el diseño de doble carril de Dusk muestra su enfoque. Moonlight puede asumir las partes “que necesariamente deben verse”: cumplimiento, custodia y auditoría. Phoenix, por su parte, gestiona lo que “no conviene que todo el mercado esté mirando”, como cotizaciones, contrapartes y ajustes de posiciones. No intenta resolver únicamente las transferencias privadas, sino cómo se reparten las funciones cuando coexisten cumplimiento y privacidad. $ETH
#dusk El mayor obstáculo ahora es que, cuando el usuario mueve activos entre dos carriles, debe percibir el proceso de conversión, y también debe pagar por ello y esperar. Si en el futuro se pudieran hacer shield en lote, agregación de pruebas y abstracción del enrutamiento, comprimiendo múltiples operaciones en una experiencia más parecida a un solo settlement, entonces el uso de Phoenix tendría mucho más alcance. Hasta que eso ocurra, Moonlight seguirá siendo la puerta principal para la mayoría.