#dusk $DUSK @Dusk Todavía no he terminado de entender del todo qué es exactamente DuskEVM en Dusk, cuál es su función y su posición. Esta semana me dediqué específicamente a sacarlo del contexto y revisarlo por separado.
En pocas palabras, DuskEVM es una capa dentro del ecosistema de Dusk creada para ser compatible con el modo de desarrollo de contratos inteligentes de Ethereum. Si eres un desarrollador que ya está acostumbrado a ese lenguaje y esas herramientas de Ethereum, no tienes que aprenderte desde cero un conjunto completamente nuevo: puedes desplegar tu aplicación en Dusk. DuskEVM no mantiene por sí solo un libro contable totalmente independiente ni una lógica final de liquidación propia; los datos reales de registro de transacciones y la confirmación final los completa la capa de liquidación subyacente de Dusk. En ese sentido, DuskEVM se parece más a una capa “encima” que se encarga específicamente de la ejecución de contratos inteligentes.
Al principio, yo asumí por defecto que era una cadena independiente “en el mismo nivel”, separada de la capa de liquidación subyacente, con dos libros contables que no dependían entre sí y que corrían por separado. Luego revisé varias veces las descripciones oficiales de arquitectura y caí en cuenta de que estaba entendiendo mal: después de que la capa de ejecución procese las transacciones, al final el resultado se empaqueta y se envía a la capa de liquidación subyacente para que se realice el registro real y la confirmación. Se trata de una relación de arriba hacia abajo (proveedor y consumidor), no de dos partes paralelas. Este malentendido me tuvo bastante tiempo dando vueltas, sobre todo porque en los materiales de divulgación suelen presentar las dos capas por separado, lo que hace fácil que la gente piense que son dos cadenas independientes y que avanzan en paralelo.
Para los desarrolladores, esta relación jerárquica es bastante importante: significa que, al desplegar una aplicación en DuskEVM, el costo real de ejecución no es solo el gasto de recursos que implica ejecutar los contratos en esa capa; también hay que sumar la parte del costo que se genera al enviar los datos a la capa de liquidación subyacente. Es la suma de ambas cuentas lo que constituye el costo completo. Si solo estimas el costo de despliegue basándote en la experiencia de Ethereum, es fácil olvidarte de la parte correspondiente a la capa inferior.
Si mi entendimiento tiene algún matiz o está desviado, agradecería que me lo señalaras; yo mismo recién estos días he podido ordenar esta lógica y no estoy seguro de si falta algún detalle.
En pocas palabras, DuskEVM es una capa dentro del ecosistema de Dusk creada para ser compatible con el modo de desarrollo de contratos inteligentes de Ethereum. Si eres un desarrollador que ya está acostumbrado a ese lenguaje y esas herramientas de Ethereum, no tienes que aprenderte desde cero un conjunto completamente nuevo: puedes desplegar tu aplicación en Dusk. DuskEVM no mantiene por sí solo un libro contable totalmente independiente ni una lógica final de liquidación propia; los datos reales de registro de transacciones y la confirmación final los completa la capa de liquidación subyacente de Dusk. En ese sentido, DuskEVM se parece más a una capa “encima” que se encarga específicamente de la ejecución de contratos inteligentes.
Al principio, yo asumí por defecto que era una cadena independiente “en el mismo nivel”, separada de la capa de liquidación subyacente, con dos libros contables que no dependían entre sí y que corrían por separado. Luego revisé varias veces las descripciones oficiales de arquitectura y caí en cuenta de que estaba entendiendo mal: después de que la capa de ejecución procese las transacciones, al final el resultado se empaqueta y se envía a la capa de liquidación subyacente para que se realice el registro real y la confirmación. Se trata de una relación de arriba hacia abajo (proveedor y consumidor), no de dos partes paralelas. Este malentendido me tuvo bastante tiempo dando vueltas, sobre todo porque en los materiales de divulgación suelen presentar las dos capas por separado, lo que hace fácil que la gente piense que son dos cadenas independientes y que avanzan en paralelo.
Para los desarrolladores, esta relación jerárquica es bastante importante: significa que, al desplegar una aplicación en DuskEVM, el costo real de ejecución no es solo el gasto de recursos que implica ejecutar los contratos en esa capa; también hay que sumar la parte del costo que se genera al enviar los datos a la capa de liquidación subyacente. Es la suma de ambas cuentas lo que constituye el costo completo. Si solo estimas el costo de despliegue basándote en la experiencia de Ethereum, es fácil olvidarte de la parte correspondiente a la capa inferior.
Si mi entendimiento tiene algún matiz o está desviado, agradecería que me lo señalaras; yo mismo recién estos días he podido ordenar esta lógica y no estoy seguro de si falta algún detalle.