#dusk $DUSK Hoy estaba leyendo la documentación de la red de pruebas DuskEVM de @Dusk y, al principio, pensé que era simplemente «Dusk por fin admite Solidity»: una capa estándar compatible con EVM, donde los desarrolladores solo necesitan portar contratos de Ethereum para ejecutarlos. Pero al ver la relación entre DuskEVM y DuskDS en el diagrama de arquitectura, me di cuenta de que no es tan simple.
DuskEVM se construye sobre OP Stack, usa la interfaz JSON-RPC estándar de Ethereum, el Chain ID745, y el token de gas sigue siendo $DUSK . Los desarrolladores pueden desplegar contratos con Foundry o Hardhat, y el explorador de la red de pruebas también es Blockscout. A simple vista, esto no parece diferente de otras cadenas de OP Stack.
Pero lo crucial es que DuskEVM no se encarga por sí mismo de la liquidación ni del DA. Pone la ejecución en la capa EVM, y deja la liquidación y la disponibilidad de datos a DuskDS: es decir, la capa de consenso y finalización de Dusk L1. Esto significa que los contratos EVM se ejecutan en un entorno compatible, pero el estado final queda fijado por el consenso de Succinct Attestation de DuskDS. En lugar de confirmaciones probabilísticas, se obtiene finalización determinista.
Lo comparo así: no es como abrir en el centro una tienda con la misma especificación que todas, sino que, dentro del centro comercial, las tiendas usan un sistema de caja que todos conocen (EVM). Pero cada vez que se cierra una cuenta, al final el dinero sigue yendo a la tesorería central (DuskDS). El cliente no nota la diferencia, pero en auditoría y cumplimiento se mira el libro contable de la sede, no el caché de la caja registradora.
Aquí hay una restricción que es fácil pasar por alto: entre DuskEVM y Dusk L1 hay una conexión mediante bridge. DUSK es el mismo activo en los sistemas de cuentas de ambos lados, pero las transferencias entre capas requieren la operación de bridge. Si la liquidez del bridge es insuficiente o la latencia es demasiado alta, la experiencia DeFi en la capa EVM se resiente. Actualmente, en la fase de red de pruebas, hay pocos datos sobre el rendimiento real del bridge y su latencia. @Dusk
Así que, al ver esta etapa «EVM» de #dusk , me fijaría en el volumen real de despliegues de contratos en la red de pruebas, la distribución de la latencia del bridge y el costo de fricción al transferir activos entre DuskEVM y Dusk L1. $DUSK Tener una entrada EVM no significa que los desarrolladores vayan a venir; lo importante es si, cuando vienen, logran quedarse.