#dusk $DUSK
Antes veía “EVM compatible” y, básicamente, no pensaba mucho.
Si con Solidity se puede escribir, con Foundry se puede ejecutar y el monedero también se puede conectar, ¿entonces no es básicamente seguir usando el mismo modelo de Ethereum?
Más recientemente leí la Reference de DuskEVM de @Dusk y me di cuenta de que, al hacer un despliegue real, aún no se puede ser tan descuidado.
Un ejemplo muy simple: DuskEVM ahora tiene su propio sequencer.
Cuando la transacción obtiene un receipt, significa que ya se ha incluido en un bloque, pero eso no es lo mismo que el settlement posterior.
También está prevrandao.
En Ethereum, algunos desarrolladores lo usan a menudo para lógica relacionada con números aleatorios de forma automática; pero la documentación oficial de Dusk advierte específicamente que, en DuskEVM, no lo trates como una fuente de aleatoriedad segura y sin sesgos.
Este tipo de cosas, si normalmente no miras la Reference, es muy fácil escribirlo directamente siguiendo los hábitos antiguos.
Así que ahora mi comprensión de la compatibilidad EVM es más realista que antes:
Puede ahorrarte muchos costos de migración, eso está bien.
Pero “la interfaz es familiar” y “el entorno subyacente es igual” no son lo mismo.
Si de verdad vas a ponerlo en producción, todavía hay que revisar de nuevo cosas como el sequencer, la finality y el estado entre capas.
De hecho, me gusta que la documentación oficial ponga estas limitaciones de forma tan directa.
Lo que más me preocupa no es que haya diferencias.
Es que creas que no las hay.
Antes veía “EVM compatible” y, básicamente, no pensaba mucho.
Si con Solidity se puede escribir, con Foundry se puede ejecutar y el monedero también se puede conectar, ¿entonces no es básicamente seguir usando el mismo modelo de Ethereum?
Más recientemente leí la Reference de DuskEVM de @Dusk y me di cuenta de que, al hacer un despliegue real, aún no se puede ser tan descuidado.
Un ejemplo muy simple: DuskEVM ahora tiene su propio sequencer.
Cuando la transacción obtiene un receipt, significa que ya se ha incluido en un bloque, pero eso no es lo mismo que el settlement posterior.
También está prevrandao.
En Ethereum, algunos desarrolladores lo usan a menudo para lógica relacionada con números aleatorios de forma automática; pero la documentación oficial de Dusk advierte específicamente que, en DuskEVM, no lo trates como una fuente de aleatoriedad segura y sin sesgos.
Este tipo de cosas, si normalmente no miras la Reference, es muy fácil escribirlo directamente siguiendo los hábitos antiguos.
Así que ahora mi comprensión de la compatibilidad EVM es más realista que antes:
Puede ahorrarte muchos costos de migración, eso está bien.
Pero “la interfaz es familiar” y “el entorno subyacente es igual” no son lo mismo.
Si de verdad vas a ponerlo en producción, todavía hay que revisar de nuevo cosas como el sequencer, la finality y el estado entre capas.
De hecho, me gusta que la documentación oficial ponga estas limitaciones de forma tan directa.
Lo que más me preocupa no es que haya diferencias.
Es que creas que no las hay.