@Dusk estaba darse cuenta de que el fragmento modular no se trata solo de tener más componentes. $DUSK en realidad separa dónde ocurre el asentamiento de dónde ocurre la ejecución, y eso cambia la forma en que pienso sobre la cadena.

Mientras revisaba la documentación más reciente de Dusk, seguía trazando DuskDS versus DuskEVM. DuskDS se encarga del consenso, la finalidad y la disponibilidad de datos, mientras que DuskEVM es la capa de ejecución de EVM que se asienta a través de ello.

DuskVM es otro entorno de ejecución directamente sobre la L1. Lo interesante es que todos pueden apoyarse en la misma base de asentamiento en lugar de obligar a cada aplicación a encajar en un solo modelo de ejecución.

Al principio lo leí como un lenguaje estándar de arquitectura modular y casi lo pasé por alto. Luego miré con más detenimiento cómo maneja Dusk las transacciones reales: Moonlight y Phoenix se asientan a través de DuskDS, mientras que la ejecución de contratos inteligentes puede estar en otro lugar. Eso hizo que la separación se sintiera mucho más práctica que sugiere el diagrama.

Aun así, me interesa el equilibrio. Una vez que las aplicaciones empiecen a moverse entre estos entornos de ejecución, ¿la modularidad realmente reduce la complejidad para quienes construyen, o solo traslada esa complejidad a las interfaces entre ellos…

@Dusk $DUSK #dusk