DuskEVM: Lo que me hace cambiar la forma de ver lo de “EVM compatible”
Antes, cada vez que veía una chain que decía “tenemos EVM”, yo solía pensar: otra vez más un fork de EVM, otra vez a aprender un montón de cosas.
Pero al poner DuskEVM junto al workflow de OP Stack que yo suelo usar, entendí que la historia era completamente distinta.
Hardhat sigue siendo lo mismo.
Foundry sigue siendo lo mismo.
JSON-RPC sigue siendo lo mismo.
Blockscout sigue siendo lo mismo.
Incluso DuskEVM usa OP Stack / op-geth, así que la sensación al implementar es que casi no hay “curva de aprendizaje” significativa.
Pero lo que de verdad me llama la atención está debajo de la capa EVM.
DuskEVM no se limita a llevar un entorno EVM a otra chain. Los datos de la transacción se envían hacia DuskDS, la capa de settlement y disponibilidad de datos de Dusk, en lugar de depender de Ethereum L1 como en los modelos OP Mainnet/Base.
Y a partir de aquí, lo que cambia no es Solidity ni las herramientas de desarrollo.
Lo que cambia es dónde se hace el settlement de la aplicación.
@Dusk mang incorpora al sistema las cosas que han construido durante años: settlement determinista, Zedger y los componentes relacionados con cumplimiento/infraestructura institucional.
Por eso empiezo a ver DuskEVM no como “otra chain EVM”, sino como una forma de llevar aplicaciones EVM existentes a una infraestructura diseñada para las finanzas reguladas.
La pregunta más interesante ahora ya no es:
“¿Los desarrolladores tienen que aprender un stack nuevo?”
Sino:
Con la fricción técnica casi en cero, ¿qué hará que los desarrolladores elijan DuskEVM en lugar de Base u OP Mainnet?
¿El ecosistema?
¿La adopción institucional?
¿El cumplimiento?
¿O la economía del gas y el settlement?
Esta es la parte que considero que vale la pena seguir en la historia #dusk . $DUSK
Antes, cada vez que veía una chain que decía “tenemos EVM”, yo solía pensar: otra vez más un fork de EVM, otra vez a aprender un montón de cosas.
Pero al poner DuskEVM junto al workflow de OP Stack que yo suelo usar, entendí que la historia era completamente distinta.
Hardhat sigue siendo lo mismo.
Foundry sigue siendo lo mismo.
JSON-RPC sigue siendo lo mismo.
Blockscout sigue siendo lo mismo.
Incluso DuskEVM usa OP Stack / op-geth, así que la sensación al implementar es que casi no hay “curva de aprendizaje” significativa.
Pero lo que de verdad me llama la atención está debajo de la capa EVM.
DuskEVM no se limita a llevar un entorno EVM a otra chain. Los datos de la transacción se envían hacia DuskDS, la capa de settlement y disponibilidad de datos de Dusk, en lugar de depender de Ethereum L1 como en los modelos OP Mainnet/Base.
Y a partir de aquí, lo que cambia no es Solidity ni las herramientas de desarrollo.
Lo que cambia es dónde se hace el settlement de la aplicación.
@Dusk mang incorpora al sistema las cosas que han construido durante años: settlement determinista, Zedger y los componentes relacionados con cumplimiento/infraestructura institucional.
Por eso empiezo a ver DuskEVM no como “otra chain EVM”, sino como una forma de llevar aplicaciones EVM existentes a una infraestructura diseñada para las finanzas reguladas.
La pregunta más interesante ahora ya no es:
“¿Los desarrolladores tienen que aprender un stack nuevo?”
Sino:
Con la fricción técnica casi en cero, ¿qué hará que los desarrolladores elijan DuskEVM en lugar de Base u OP Mainnet?
¿El ecosistema?
¿La adopción institucional?
¿El cumplimiento?
¿O la economía del gas y el settlement?
Esta es la parte que considero que vale la pena seguir en la historia #dusk . $DUSK
