Pasé una hora intentando entender por qué @Dusk necesita dos sistemas de cuentas diferentes.
La mayoría de las cadenas eligen un modelo. Público por defecto con funciones de privacidad opcionales. O privado por defecto con claves de visualización para la transparencia. Supuse que Dusk seguiría el mismo patrón. Un solo tipo de cuenta. Un solo modo de transacción. Un interruptor en la billetera que cambia entre visible y oculto.
Resultó ser otra cosa totalmente...
Dusk ejecuta ambos de forma nativa. Moonlight es la capa de cuenta pública. Direcciones estándar, saldos visibles, transacciones auditable. Phoenix es la capa protegida. Cantidades ocultas, emisor y destinatario cifrados, pruebas de conocimiento cero que verifican la validez sin exponer datos. No son conmutadores de la misma cuenta. Son sistemas paralelos que operan en la misma cadena, cada uno con su propio formato de dirección y su caso de uso.
Esto cambia cómo pienso sobre el cumplimiento en blockchain. Yo asumí que la privacidad era algo que agregas cuando la necesitas. En Dusk, la privacidad y la transparencia son carriles de infraestructura separados. Una institución puede mantener reservas públicas en Moonlight para informes regulatorios, mientras mueve los fondos de los clientes a través de Phoenix para la confidencialidad. La misma entidad usa ambos sin hacer puente entre cadenas ni envolver activos en estándares de privacidad distintos.
Pero la tensión es real. Dos sistemas de cuentas significan el doble de complejidad. El software de la billetera tiene que gestionar ambos. Los usuarios tienen que saber qué tipo de dirección usar para cada transacción. Un error no solo significa que falle una transferencia. Significa enviar una transacción confidencial a una dirección pública o exponer una liquidación que estaba destinada a permanecer oculta.
Todavía estoy determinando si los mercados financieros quieren una cadena que refleje su separación existente entre libros públicos y libros privados, o si quieren un sistema más simple que obligue todo a encajar en un solo modelo.
¿La arquitectura de dos cuentas es flexibilidad o fragmentación?
#dusk
$DUSK
@Dusk_Foundation
La mayoría de las cadenas eligen un modelo. Público por defecto con funciones de privacidad opcionales. O privado por defecto con claves de visualización para la transparencia. Supuse que Dusk seguiría el mismo patrón. Un solo tipo de cuenta. Un solo modo de transacción. Un interruptor en la billetera que cambia entre visible y oculto.
Resultó ser otra cosa totalmente...
Dusk ejecuta ambos de forma nativa. Moonlight es la capa de cuenta pública. Direcciones estándar, saldos visibles, transacciones auditable. Phoenix es la capa protegida. Cantidades ocultas, emisor y destinatario cifrados, pruebas de conocimiento cero que verifican la validez sin exponer datos. No son conmutadores de la misma cuenta. Son sistemas paralelos que operan en la misma cadena, cada uno con su propio formato de dirección y su caso de uso.
Esto cambia cómo pienso sobre el cumplimiento en blockchain. Yo asumí que la privacidad era algo que agregas cuando la necesitas. En Dusk, la privacidad y la transparencia son carriles de infraestructura separados. Una institución puede mantener reservas públicas en Moonlight para informes regulatorios, mientras mueve los fondos de los clientes a través de Phoenix para la confidencialidad. La misma entidad usa ambos sin hacer puente entre cadenas ni envolver activos en estándares de privacidad distintos.
Pero la tensión es real. Dos sistemas de cuentas significan el doble de complejidad. El software de la billetera tiene que gestionar ambos. Los usuarios tienen que saber qué tipo de dirección usar para cada transacción. Un error no solo significa que falle una transferencia. Significa enviar una transacción confidencial a una dirección pública o exponer una liquidación que estaba destinada a permanecer oculta.
Todavía estoy determinando si los mercados financieros quieren una cadena que refleje su separación existente entre libros públicos y libros privados, o si quieren un sistema más simple que obligue todo a encajar en un solo modelo.
¿La arquitectura de dos cuentas es flexibilidad o fragmentación?
#dusk
$DUSK
@Dusk_Foundation