#dusk $DUSK Hoy probé explicando la arquitectura técnica de Dusk con palabras sencillas, evitando en lo posible tecnicismos, a ver si mis amigos que no son de tecnología también logran entenderla más o menos.
Primero, la conclusión: @Dusk todo el sistema, en esencia, es una estructura de "dos pisos": un piso se encarga de la privacidad y el otro de la normativa, cada uno hace su trabajo.
$AKE
Primer piso: Phoenix, se encarga de la privacidad.
Se basa en una arquitectura UTXO (puedes entenderlo simple como "billetes independientes, una transacción a la vez", en vez de "una cuenta única total"), e integra las pruebas de conocimiento cero directamente en la capa de transacciones. Cuando transfieres, tu dirección, el monto y esos datos van cifrados en la cadena: cualquiera que escanee la cadena no ve el texto claro, pero la red aun así puede verificar que la transacción es válida (sin doble gasto, sin gastar de más). Así se resuelve el problema antiguo de "privacidad pero sin perder verificabilidad".
Segundo piso: Zedger, se encarga de la normativa.
Si Phoenix es "esconder los detalles", Zedger es "respetar las reglas". Es una capa pensada específicamente para tokens tipo valores, donde las reglas de cumplimiento se escriben directamente en la lógica de la cadena. Por ejemplo, si un token de valor establece que un solo tenedor no puede superar el 5% del total, entonces una transferencia que exceda ese límite será rechazada directamente en la cadena, sin necesidad de depender de revisiones manuales fuera de la cadena para frenarlo. Límites de tenencia, listas blancas, periodos de bloqueo: esas restricciones típicas de las finanzas tradicionales también pueden automatizarse con Zedger.
Debajo, la base: DuskDS + DuskEVM + DuskVM.
$SPCXB
DuskDS es la capa de consenso: se encarga de que el resultado sea determinista. Una vez que una transacción se registra en la cadena, queda como estado final y no se reorganiza ocasionalmente como en algunas cadenas PoW. DuskEVM es compatible con Solidity, así que los desarrolladores del ecosistema de Ethereum pueden migrar con bajo costo. DuskVM conserva la capacidad nativa de cómputo con privacidad, para escenarios que requieran mayor personalización.
Lo ingenioso de este diseño es que no trata "privacidad" y "cumplimiento" como si fueran opuestos. Las separa en capas: cada necesidad se resuelve con la forma más adecuada y luego se combinan. Por eso Dusk puede apuntar a RWA y a las finanzas reguladas: desde el inicio su stack técnico está hecho para ese escenario, no es algo forzado.
Ya con la lógica base clara, si miras su posicionamiento en el mercado y a sus socios (AFM, el grupo de exchanges como NPE), tiene sentido: toda la línea encaja, no es un rompecabezas armado a última hora.
#dusk @Dusk
Primero, la conclusión: @Dusk todo el sistema, en esencia, es una estructura de "dos pisos": un piso se encarga de la privacidad y el otro de la normativa, cada uno hace su trabajo.
$AKE
Primer piso: Phoenix, se encarga de la privacidad.
Se basa en una arquitectura UTXO (puedes entenderlo simple como "billetes independientes, una transacción a la vez", en vez de "una cuenta única total"), e integra las pruebas de conocimiento cero directamente en la capa de transacciones. Cuando transfieres, tu dirección, el monto y esos datos van cifrados en la cadena: cualquiera que escanee la cadena no ve el texto claro, pero la red aun así puede verificar que la transacción es válida (sin doble gasto, sin gastar de más). Así se resuelve el problema antiguo de "privacidad pero sin perder verificabilidad".
Segundo piso: Zedger, se encarga de la normativa.
Si Phoenix es "esconder los detalles", Zedger es "respetar las reglas". Es una capa pensada específicamente para tokens tipo valores, donde las reglas de cumplimiento se escriben directamente en la lógica de la cadena. Por ejemplo, si un token de valor establece que un solo tenedor no puede superar el 5% del total, entonces una transferencia que exceda ese límite será rechazada directamente en la cadena, sin necesidad de depender de revisiones manuales fuera de la cadena para frenarlo. Límites de tenencia, listas blancas, periodos de bloqueo: esas restricciones típicas de las finanzas tradicionales también pueden automatizarse con Zedger.
Debajo, la base: DuskDS + DuskEVM + DuskVM.
$SPCXB
DuskDS es la capa de consenso: se encarga de que el resultado sea determinista. Una vez que una transacción se registra en la cadena, queda como estado final y no se reorganiza ocasionalmente como en algunas cadenas PoW. DuskEVM es compatible con Solidity, así que los desarrolladores del ecosistema de Ethereum pueden migrar con bajo costo. DuskVM conserva la capacidad nativa de cómputo con privacidad, para escenarios que requieran mayor personalización.
Lo ingenioso de este diseño es que no trata "privacidad" y "cumplimiento" como si fueran opuestos. Las separa en capas: cada necesidad se resuelve con la forma más adecuada y luego se combinan. Por eso Dusk puede apuntar a RWA y a las finanzas reguladas: desde el inicio su stack técnico está hecho para ese escenario, no es algo forzado.
Ya con la lógica base clara, si miras su posicionamiento en el mercado y a sus socios (AFM, el grupo de exchanges como NPE), tiene sentido: toda la línea encaja, no es un rompecabezas armado a última hora.
#dusk @Dusk
ZK证明到底是什么原理
0%
UTXO和账户模型哪个好
100%
兼容EVM有多重要
0%
1 Votos • Votación cerrada