@Dusk #dusk
$DUSK Componentes principales
La red Dusk utiliza una arquitectura modular diseñada para las finanzas reguladas: privacidad cuando es necesaria, transparencia cuando es útil y liquidación determinista cuando los flujos del mercado la requieren. A alto nivel:
Componente :
1. DuskDS
Rol :
Base de asentamiento y disponibilidad de datos: consenso, finalidad y modelos de transacciones de Dusk
A dónde ir a continuación :
Dusk tiene una arquitectura de dos capas:
DuskDS – la capa de liquidación y datos (consenso, disponibilidad de datos, modelos de transacciones)
DuskEVM – la capa de ejecución de EVM donde se ejecutan los smart contracts y donde vive Hedger
Esta página describe los modelos de transacciones en DuskDS. Es el contexto para quienes quieren entender cómo funcionan la liquidación y la privacidad por debajo del capó. Si estás construyendo dApps en DuskEVM, en su mayor parte interactuarás con Hedger y con contratos EVM en lugar de esto.
Phoenix vs Moonlight (en DuskDS)En DuskDS, el valor puede moverse de dos maneras nativas:
Moonlight – transferencias públicas, basadas en cuentas
Phoenix – transferencias protegidas, basadas en notas, usando pruebas de conocimiento cero
Ambas, en última instancia, se liquidan en la misma cadena, pero exponen información diferente a quienes observan.
Para los detalles completos de la implementación, puedes consultar el Whitepaper.
Moonlight – saldos públicos
Moonlight es el modelo de transacciones transparente:
Las cuentas tienen saldos visibles.
Las transferencias muestran el remitente, el destinatario y el monto.
Es adecuado para flujos que deben ser observables (por ejemplo, algunos escenarios de tesorería o reportes).
Conceptualmente se comporta como un modelo de cuenta estándar.
Para la mayoría de los usuarios, esta es “la forma transparente de mover DUSK” a nivel de protocolo.
Phoenix – saldos protegidos
Phoenix es el modelo que preserva la privacidad:
Los fondos viven como “notas” cifradas en lugar de saldos explícitos.
Las transacciones prueban la corrección (sin dobles gastos, suficientes fondos) con pruebas de conocimiento cero sin revelar: cuánto se mueve, quién envió la nota, salvo al receptor, entre qué notas específicas.
Los usuarios pueden revelar información selectivamente mediante claves de visualización cuando la regulación o la auditoría lo requieren.
$DUSK Componentes principales
La red Dusk utiliza una arquitectura modular diseñada para las finanzas reguladas: privacidad cuando es necesaria, transparencia cuando es útil y liquidación determinista cuando los flujos del mercado la requieren. A alto nivel:
Componente :
1. DuskDS
Rol :
Base de asentamiento y disponibilidad de datos: consenso, finalidad y modelos de transacciones de Dusk
A dónde ir a continuación :
Dusk tiene una arquitectura de dos capas:
DuskDS – la capa de liquidación y datos (consenso, disponibilidad de datos, modelos de transacciones)
DuskEVM – la capa de ejecución de EVM donde se ejecutan los smart contracts y donde vive Hedger
Esta página describe los modelos de transacciones en DuskDS. Es el contexto para quienes quieren entender cómo funcionan la liquidación y la privacidad por debajo del capó. Si estás construyendo dApps en DuskEVM, en su mayor parte interactuarás con Hedger y con contratos EVM en lugar de esto.
Phoenix vs Moonlight (en DuskDS)En DuskDS, el valor puede moverse de dos maneras nativas:
Moonlight – transferencias públicas, basadas en cuentas
Phoenix – transferencias protegidas, basadas en notas, usando pruebas de conocimiento cero
Ambas, en última instancia, se liquidan en la misma cadena, pero exponen información diferente a quienes observan.
Para los detalles completos de la implementación, puedes consultar el Whitepaper.
Moonlight – saldos públicos
Moonlight es el modelo de transacciones transparente:
Las cuentas tienen saldos visibles.
Las transferencias muestran el remitente, el destinatario y el monto.
Es adecuado para flujos que deben ser observables (por ejemplo, algunos escenarios de tesorería o reportes).
Conceptualmente se comporta como un modelo de cuenta estándar.
Para la mayoría de los usuarios, esta es “la forma transparente de mover DUSK” a nivel de protocolo.
Phoenix – saldos protegidos
Phoenix es el modelo que preserva la privacidad:
Los fondos viven como “notas” cifradas en lugar de saldos explícitos.
Las transacciones prueban la corrección (sin dobles gastos, suficientes fondos) con pruebas de conocimiento cero sin revelar: cuánto se mueve, quién envió la nota, salvo al receptor, entre qué notas específicas.
Los usuarios pueden revelar información selectivamente mediante claves de visualización cuando la regulación o la auditoría lo requieren.
