#dusk $DUSK al traducir el documento de arquitectura de @Dusk , encontré una elección de diseño que es fácil de pasar por alto con una sola frase: DuskDS se encarga de la liquidación y la disponibilidad de datos, mientras que DuskEVM se encarga de la ejecución. La liquidación y la ejecución se separan, y no es un simple capricho: detrás hay toda una serie de compromisos sobre "rapidez" y "seguridad".
Poner este diseño en el contexto de OP Stack lo deja claro. DuskEVM es el entorno de ejecución; los contratos Solidity se ejecutan en el lado EVM, y el consumo de Gas por la interacción del usuario, así como los cambios de estado, ocurren en esa capa. Pero DuskDS es la capa real de liquidación: las salidas del lado EVM necesitan enviarse a L1; allí, tras la verificación, la espera de la madurez del proof y la ventana del dispute-game, es cuando finalmente se obtiene la finalidad a nivel de protocolo. La ejecución rápida se asigna a EVM, y la seguridad final a L1.
El costo de esta arquitectura también es bastante directo: las operaciones entre capas requieren espera. Para retirar fondos hay que pasar por tres pasos: propuesta de salida, envío de la prueba y finalize; cada paso tiene una ventana de tiempo, no es algo de un solo clic. Además, por ahora esta arquitectura aún se está ejecutando en la red de pruebas y usa tokens de prueba sin valor real. Que el flujo de pruebas funcione solo demuestra que la ruta del protocolo es viable, pero no permite deducir una fecha de lanzamiento en la red principal ni demostrar la estabilidad del envío de la propuesta de salida y del finalize bajo alta carga.
Por eso mantengo cauteloso el etiquetado de "compatibilidad con EVM". Lo que de verdad merece verificarse no es si Solidity puede ejecutarse, sino el tiempo real que tarda la salida entre capas, la ruta de recuperación tras un fallo, y el desempeño de esta arquitectura separada cuando se revelen los parámetros de la red principal y se enfrente a alta carga. Separar la capa de ejecución y la de liquidación, decir que es modular, está bien, pero en la experiencia del usuario la cuenta final la tiene que pagar el producto. #dusk @Dusk
Poner este diseño en el contexto de OP Stack lo deja claro. DuskEVM es el entorno de ejecución; los contratos Solidity se ejecutan en el lado EVM, y el consumo de Gas por la interacción del usuario, así como los cambios de estado, ocurren en esa capa. Pero DuskDS es la capa real de liquidación: las salidas del lado EVM necesitan enviarse a L1; allí, tras la verificación, la espera de la madurez del proof y la ventana del dispute-game, es cuando finalmente se obtiene la finalidad a nivel de protocolo. La ejecución rápida se asigna a EVM, y la seguridad final a L1.
El costo de esta arquitectura también es bastante directo: las operaciones entre capas requieren espera. Para retirar fondos hay que pasar por tres pasos: propuesta de salida, envío de la prueba y finalize; cada paso tiene una ventana de tiempo, no es algo de un solo clic. Además, por ahora esta arquitectura aún se está ejecutando en la red de pruebas y usa tokens de prueba sin valor real. Que el flujo de pruebas funcione solo demuestra que la ruta del protocolo es viable, pero no permite deducir una fecha de lanzamiento en la red principal ni demostrar la estabilidad del envío de la propuesta de salida y del finalize bajo alta carga.
Por eso mantengo cauteloso el etiquetado de "compatibilidad con EVM". Lo que de verdad merece verificarse no es si Solidity puede ejecutarse, sino el tiempo real que tarda la salida entre capas, la ruta de recuperación tras un fallo, y el desempeño de esta arquitectura separada cuando se revelen los parámetros de la red principal y se enfrente a alta carga. Separar la capa de ejecución y la de liquidación, decir que es modular, está bien, pero en la experiencia del usuario la cuenta final la tiene que pagar el producto. #dusk @Dusk
分层架构是优势还是负担
DuskDS和EVM分家合理吗?
跨层退出体验如何
3 hora(s) restante(s)