#dusk $DUSK Aquí hay algo que se suele pasar por alto en la mayoría de los explicadores de DUSK: esto no es una cadena con un único modelo de privacidad añadido. Es una cadena que ejecuta simultáneamente dos modelos distintos de transacciones, porque un pago y una seguridad no son el mismo tipo de objeto y no fallan de la misma manera.
Phoenix es el modelo tipo UTxO para transferencias ofuscadas de uso diario: los saldos y los contraparte ocultos, las notas rastreadas en un árbol de Merkle y los nullifiers evitando gastos dobles sin revelar qué nota se gastó. Está diseñado para alto rendimiento y confidencialidad en la transferencia ordinaria de valor.
Zedger es diferente a propósito. Está modelado específicamente para valores tokenizados, donde el objetivo no es solo ocultar un saldo: es demostrar que los eventos del ciclo de vida (emisión, restricciones de transferencia, acciones corporativas, redención) ocurrieron correctamente bajo un marco regulatorio, sin filtrar la tabla de cap a la cadena pública. Un token de seguridad tiene obligaciones que Phoenix nunca fue diseñado para llevar: restricciones de transferencia vinculadas al estatus del inversor, la capacidad de que un emisor congela o recupere bajo condiciones legales específicas, y requisitos de auditoría que sobreviven incluso cuando los saldos permanecen sellados.
Llevar ambos en una sola capa de liquidación es la apuesta real de ingeniería. Dusk no está eligiendo entre "cadena de pagos privados" y "cadena de valores conforme": está defendiendo que necesitas ambos primitivos disponibles en el mismo entorno de ejecución, porque un mercado regulado toca ambos tipos de transacción en el mismo día de negociación. El contrato de transferencia gestiona ambos flujos mediante el mismo modelo de integridad basado en árbol de Merkle, lo cual es una arquitectura más limpia que enlazar dos cadenas con dos garantías de privacidad distintas.
La pregunta abierta es si esa complejidad de doble modelo se convierte en una carga de mantenimiento a medida que ambas especificaciones evolucionan de forma independiente, o si es realmente más robusta que una capa de privacidad única para todo.
¿Alguien sabe de otra L1 que esté enviando dos modelos de transacciones de producción que estén deliberadamente separados por clase de activo, en lugar de un único primitivo genérico de privacidad estirado sobre todo?
@Dusk_Foundation $NVDAB
Phoenix es el modelo tipo UTxO para transferencias ofuscadas de uso diario: los saldos y los contraparte ocultos, las notas rastreadas en un árbol de Merkle y los nullifiers evitando gastos dobles sin revelar qué nota se gastó. Está diseñado para alto rendimiento y confidencialidad en la transferencia ordinaria de valor.
Zedger es diferente a propósito. Está modelado específicamente para valores tokenizados, donde el objetivo no es solo ocultar un saldo: es demostrar que los eventos del ciclo de vida (emisión, restricciones de transferencia, acciones corporativas, redención) ocurrieron correctamente bajo un marco regulatorio, sin filtrar la tabla de cap a la cadena pública. Un token de seguridad tiene obligaciones que Phoenix nunca fue diseñado para llevar: restricciones de transferencia vinculadas al estatus del inversor, la capacidad de que un emisor congela o recupere bajo condiciones legales específicas, y requisitos de auditoría que sobreviven incluso cuando los saldos permanecen sellados.
Llevar ambos en una sola capa de liquidación es la apuesta real de ingeniería. Dusk no está eligiendo entre "cadena de pagos privados" y "cadena de valores conforme": está defendiendo que necesitas ambos primitivos disponibles en el mismo entorno de ejecución, porque un mercado regulado toca ambos tipos de transacción en el mismo día de negociación. El contrato de transferencia gestiona ambos flujos mediante el mismo modelo de integridad basado en árbol de Merkle, lo cual es una arquitectura más limpia que enlazar dos cadenas con dos garantías de privacidad distintas.
La pregunta abierta es si esa complejidad de doble modelo se convierte en una carga de mantenimiento a medida que ambas especificaciones evolucionan de forma independiente, o si es realmente más robusta que una capa de privacidad única para todo.
¿Alguien sabe de otra L1 que esté enviando dos modelos de transacciones de producción que estén deliberadamente separados por clase de activo, en lugar de un único primitivo genérico de privacidad estirado sobre todo?
@Dusk_Foundation $NVDAB