Solía ver el puente Dusk como una pregunta sencilla de hacia dónde se mueve DUSK.
Luego empecé a pensar en una pregunta más importante:
¿Qué cambia en la forma en que el valor se representa, se transfiere, se liquida y se verifica a medida que atraviesa la arquitectura?
DuskEVM aporta compatibilidad con EVM y contratos inteligentes basados en Solidity al ecosistema Dusk, mientras que DuskDS proporciona la base de liquidación y disponibilidad de datos.
Esa distinción se vuelve interesante porque Dusk admite dos modelos nativos de transacciones.
Moonlight es público y basado en cuentas.
Phoenix está protegido y se basa en notas/UTXO, usando pruebas de conocimiento cero para proteger la privacidad de las transacciones.
Así que la parte interesante no es simplemente que Dusk tenga un EVM.
Lo que llamó mi atención es lo que hay debajo de esa capa de ejecución: DuskDS, donde se unen la liquidación, la disponibilidad de datos y los modelos nativos de transacciones de Dusk.
Los desarrolladores se familiarizan con las herramientas de EVM y con Solidity, mientras que Dusk mantiene su arquitectura nativa de transacciones para distintos requisitos de transparencia y privacidad.
Cuando el valor se mueve, las preguntas más profundas son:
¿Qué forma adopta ese valor? ¿Cómo se liquida la transacción? ¿Qué información permanece visible? ¿Y dónde se preserva la privacidad?
Eso es lo que hace que DuskEVM valga la pena seguir de cerca.
Para mí, esto tiene más sentido que simplemente decir “Dusk es compatible con EVM”.
Lo que considero más interesante es cómo la ejecución familiar de contratos inteligentes interactúa con la arquitectura existente de liquidación y transacciones de Dusk.
El puente puede mover el activo, pero la arquitectura determina cómo se comporta ese activo a lo largo del camino.
Y esa es la capa a la que vigilaría con más atención mientras DuskEVM se desarrolla.
$DUSK #Dusk @Dusk
Luego empecé a pensar en una pregunta más importante:
¿Qué cambia en la forma en que el valor se representa, se transfiere, se liquida y se verifica a medida que atraviesa la arquitectura?
DuskEVM aporta compatibilidad con EVM y contratos inteligentes basados en Solidity al ecosistema Dusk, mientras que DuskDS proporciona la base de liquidación y disponibilidad de datos.
Esa distinción se vuelve interesante porque Dusk admite dos modelos nativos de transacciones.
Moonlight es público y basado en cuentas.
Phoenix está protegido y se basa en notas/UTXO, usando pruebas de conocimiento cero para proteger la privacidad de las transacciones.
Así que la parte interesante no es simplemente que Dusk tenga un EVM.
Lo que llamó mi atención es lo que hay debajo de esa capa de ejecución: DuskDS, donde se unen la liquidación, la disponibilidad de datos y los modelos nativos de transacciones de Dusk.
Los desarrolladores se familiarizan con las herramientas de EVM y con Solidity, mientras que Dusk mantiene su arquitectura nativa de transacciones para distintos requisitos de transparencia y privacidad.
Cuando el valor se mueve, las preguntas más profundas son:
¿Qué forma adopta ese valor? ¿Cómo se liquida la transacción? ¿Qué información permanece visible? ¿Y dónde se preserva la privacidad?
Eso es lo que hace que DuskEVM valga la pena seguir de cerca.
Para mí, esto tiene más sentido que simplemente decir “Dusk es compatible con EVM”.
Lo que considero más interesante es cómo la ejecución familiar de contratos inteligentes interactúa con la arquitectura existente de liquidación y transacciones de Dusk.
El puente puede mover el activo, pero la arquitectura determina cómo se comporta ese activo a lo largo del camino.
Y esa es la capa a la que vigilaría con más atención mientras DuskEVM se desarrolla.
$DUSK #Dusk @Dusk
