#dusk Todos los que han hecho Ethereum (#ETH ) o Arbitrum, Optimism de este tipo seguro que tienen bastante experiencia. Escribir contratos en Solidity es, bueno, conveniente, pero en cuanto entra en juego algún cálculo complejo o pruebas de conocimiento cero (ZKP), el rendimiento de la EVM (máquina virtual de Ethereum) va tan lento como un coche antiguo de antaño, y las tarifas de Gas son absurdamente caras; pero si, para buscar rendimiento, se intenta crear un lenguaje de capa base completamente nuevo, los desarrolladores y los usuarios ni de cerca quieren mudarse, y el ecosistema directamente se enfría.
Hoy estuve mirando el diseño de @Dusk ($DUSK ) y me pareció bastante interesante la forma en que aborda este problema: lo convierte directamente en unos “bloques modulares tipo LEGO”.
En pocas palabras, divide la capa base en tres partes:
La “gran contabilidad y cámara de compensación” de la capa base (DuskDS): se encarga específicamente de ejecutar el consenso de SA y realizar la liquidación de datos. Es como el servidor principal de un banco: solo se ocupa de la verificación y la seguridad definitivas de los activos a nivel más bajo, sin meterse en asuntos colaterales, garantizando una altísima disponibilidad de datos y determinismo en la liquidación.
El “motor ultrarrápido” nativo (DuskVM / Piecrust): una máquina virtual nativa que corre con Rust y WASM, diseñada especialmente para manejar pruebas de conocimiento cero y cálculos de privacidad de alta complejidad. Es como equipar el sistema con una tarjeta gráfica profesional: procesar transacciones de privacidad ZK vuela.
El “portal genérico de Ethereum para trabajar” (DuskEVM): una capa de compatibilidad preparada específicamente para desarrolladores del ecosistema de Ethereum. Los desarrolladores no tienen que aprender un lenguaje nuevo; con un “sombrero duro” (Hardhat), Metamask, pueden llevar tal cual sus aplicaciones de ETH, haciendo una sustitución tipo “plug and play”, y cobrando el Gas directamente con $DUSK .
Ese diseño que separa la capa de liquidación de la capa de ejecución se siente como “conectar sin dolor” el enorme ecosistema de Ethereum a una capa base supersólida que ya trae un acelerador de privacidad ZKP.
Pero dicho sea de paso: la idea de una arquitectura por capas es buena, aunque lo que más pone a prueba es la seguridad en la interacción entre muchas capas. Cuando los activos se transfieren entre DuskEVM y la capa nativa de privacidad, la complejidad lógica se duplica: ¿aparecerán vulnerabilidades en los contratos? ¿La latencia de la liquidación entre capas será aceptable para los usuarios? Estas son pruebas duras que hay que superar antes de que el ecosistema de la red principal realmente florezca. ¡Intercambiemos en la sección de comentarios!
Hoy estuve mirando el diseño de @Dusk ($DUSK ) y me pareció bastante interesante la forma en que aborda este problema: lo convierte directamente en unos “bloques modulares tipo LEGO”.
En pocas palabras, divide la capa base en tres partes:
La “gran contabilidad y cámara de compensación” de la capa base (DuskDS): se encarga específicamente de ejecutar el consenso de SA y realizar la liquidación de datos. Es como el servidor principal de un banco: solo se ocupa de la verificación y la seguridad definitivas de los activos a nivel más bajo, sin meterse en asuntos colaterales, garantizando una altísima disponibilidad de datos y determinismo en la liquidación.
El “motor ultrarrápido” nativo (DuskVM / Piecrust): una máquina virtual nativa que corre con Rust y WASM, diseñada especialmente para manejar pruebas de conocimiento cero y cálculos de privacidad de alta complejidad. Es como equipar el sistema con una tarjeta gráfica profesional: procesar transacciones de privacidad ZK vuela.
El “portal genérico de Ethereum para trabajar” (DuskEVM): una capa de compatibilidad preparada específicamente para desarrolladores del ecosistema de Ethereum. Los desarrolladores no tienen que aprender un lenguaje nuevo; con un “sombrero duro” (Hardhat), Metamask, pueden llevar tal cual sus aplicaciones de ETH, haciendo una sustitución tipo “plug and play”, y cobrando el Gas directamente con $DUSK .
Ese diseño que separa la capa de liquidación de la capa de ejecución se siente como “conectar sin dolor” el enorme ecosistema de Ethereum a una capa base supersólida que ya trae un acelerador de privacidad ZKP.
Pero dicho sea de paso: la idea de una arquitectura por capas es buena, aunque lo que más pone a prueba es la seguridad en la interacción entre muchas capas. Cuando los activos se transfieren entre DuskEVM y la capa nativa de privacidad, la complejidad lógica se duplica: ¿aparecerán vulnerabilidades en los contratos? ¿La latencia de la liquidación entre capas será aceptable para los usuarios? Estas son pruebas duras que hay que superar antes de que el ecosistema de la red principal realmente florezca. ¡Intercambiemos en la sección de comentarios!
