describir que ejecutar dos modelos de transacción estructuralmente distintos sobre una misma capa de liquidación es una cosa en abstracto. hacer cumplir que no puedan contradecirse entre sí es un problema completamente diferente, y DuskDS lo resuelve mediante una única pieza específica de la arquitectura, el Contrato de Transferencia.
Phoenix y Moonlight no son sistemas independientes ejecutándose en paralelo y esperando mantenerse consistentes por coincidencia. cada movimiento de valor, ya sea una nota UTXO protegida bajo Phoenix o un saldo de cuenta público bajo Moonlight, en última instancia pasa por el Contrato de Transferencia, que es la autoridad real sobre el estado global en DuskDS. es el único lugar responsable de garantizar que una nota protegida que se gasta y un saldo público que se actualiza nunca puedan producir un total inconsistente, que no se pueda crear valor de la nada y que los dos modelos no se separen con el tiempo.
lo que esto significa en la práctica es que Phoenix y Moonlight no son dos libros contables separados que simplemente comparten una cadena; son dos representaciones diferentes, impuestas por una única fuente de verdad compartida. el modelo de privacidad cambia según el tipo de transacción que estés usando, pero la contabilidad subyacente no puede contradecirse a sí misma dependiendo de qué lado del sistema estés mirando.
aquí es donde el diseño debe ser impecable para que el enfoque de doble modelo de hace unos días realmente se sostenga en un uso real. si el Contrato de Transferencia tuviera alguna inconsistencia en cómo concilia los dos, eso no sería un fallo menor: sería un lugar en el que, teóricamente, podría crearse o perderse valor simplemente al pasar entre una representación protegida y una transparente del mismo activo.
así que, ¿centralizar esa conciliación en un solo contrato es un diseño más seguro porque hay exactamente un lugar para auditar y verificar la corrección, o poner tanta responsabilidad en un único contrato solo concentra el riesgo en lugar de reducirlo.
#dusk @Dusk $DUSK
Phoenix y Moonlight no son sistemas independientes ejecutándose en paralelo y esperando mantenerse consistentes por coincidencia. cada movimiento de valor, ya sea una nota UTXO protegida bajo Phoenix o un saldo de cuenta público bajo Moonlight, en última instancia pasa por el Contrato de Transferencia, que es la autoridad real sobre el estado global en DuskDS. es el único lugar responsable de garantizar que una nota protegida que se gasta y un saldo público que se actualiza nunca puedan producir un total inconsistente, que no se pueda crear valor de la nada y que los dos modelos no se separen con el tiempo.
lo que esto significa en la práctica es que Phoenix y Moonlight no son dos libros contables separados que simplemente comparten una cadena; son dos representaciones diferentes, impuestas por una única fuente de verdad compartida. el modelo de privacidad cambia según el tipo de transacción que estés usando, pero la contabilidad subyacente no puede contradecirse a sí misma dependiendo de qué lado del sistema estés mirando.
aquí es donde el diseño debe ser impecable para que el enfoque de doble modelo de hace unos días realmente se sostenga en un uso real. si el Contrato de Transferencia tuviera alguna inconsistencia en cómo concilia los dos, eso no sería un fallo menor: sería un lugar en el que, teóricamente, podría crearse o perderse valor simplemente al pasar entre una representación protegida y una transparente del mismo activo.
así que, ¿centralizar esa conciliación en un solo contrato es un diseño más seguro porque hay exactamente un lugar para auditar y verificar la corrección, o poner tanta responsabilidad en un único contrato solo concentra el riesgo en lugar de reducirlo.
#dusk @Dusk $DUSK