Pasé demasiado tiempo anoche buceando en la documentación de arquitectura de Dusk. No voy a mentir, mi cerebro se enganchaba con una sola cosa.
Tienen Zedger (estilo UTXO, privacidad primero para valores) y DuskEVM (EVM de OP Stack para desarrolladores de Solidity). En el papel, está todo limpio: la lógica de liquidación se mantiene separada de la lógica de la aplicación.
Pero Zedger tiene esta función concreta, bastante genial: el destinatario tiene que aprobar explícitamente una transferencia antes de que en realidad se finalize. Esto es enorme para activos regulados. Tu token de seguridad no debería poder ser arrastrado automáticamente a una billetera aleatoria.
Ahora imagina que envuelves ese activo y lo llevas al lado de la EVM. La EVM no tiene ese estado de "aprobación pendiente" de forma nativa: simplemente tiene transiciones de estado estándar.
Entonces, ¿quién hace cumplir la regla cuando está al otro lado?
La documentación pública no detalla realmente aquí los mecanismos del puente. Tal vez lleven ese contexto de cumplimiento, pero sinceramente, eso suena a que estarías reconstruyendo la lógica de Zedger dentro de Solidity de todos modos. Entonces, ¿por qué mantenerlos separados?
Probablemente por eso DuskVM (la capa de privacidad en WASM) se está extrayendo como algo propio: para mantener lo realmente regulado aislado del lejano oeste de la EVM.
Tres entornos de ejecución. Dos puentes. Es ambicioso, pero yo aquí sentado me pregunto si esas uniones son realmente herméticas. Da la sensación de que podría haber algunas inconsistencias raras de estado cuando un activo salta de capa.
No intento sembrar dudas (FUD): en realidad me gusta el enfoque. Solo que me da curiosidad genuina si alguien sabe cómo planean mantener sincronizado de forma sólida el estado entre capas en la práctica.
@Dusk #dusk #DUSK $DUSK
Tienen Zedger (estilo UTXO, privacidad primero para valores) y DuskEVM (EVM de OP Stack para desarrolladores de Solidity). En el papel, está todo limpio: la lógica de liquidación se mantiene separada de la lógica de la aplicación.
Pero Zedger tiene esta función concreta, bastante genial: el destinatario tiene que aprobar explícitamente una transferencia antes de que en realidad se finalize. Esto es enorme para activos regulados. Tu token de seguridad no debería poder ser arrastrado automáticamente a una billetera aleatoria.
Ahora imagina que envuelves ese activo y lo llevas al lado de la EVM. La EVM no tiene ese estado de "aprobación pendiente" de forma nativa: simplemente tiene transiciones de estado estándar.
Entonces, ¿quién hace cumplir la regla cuando está al otro lado?
La documentación pública no detalla realmente aquí los mecanismos del puente. Tal vez lleven ese contexto de cumplimiento, pero sinceramente, eso suena a que estarías reconstruyendo la lógica de Zedger dentro de Solidity de todos modos. Entonces, ¿por qué mantenerlos separados?
Probablemente por eso DuskVM (la capa de privacidad en WASM) se está extrayendo como algo propio: para mantener lo realmente regulado aislado del lejano oeste de la EVM.
Tres entornos de ejecución. Dos puentes. Es ambicioso, pero yo aquí sentado me pregunto si esas uniones son realmente herméticas. Da la sensación de que podría haber algunas inconsistencias raras de estado cuando un activo salta de capa.
No intento sembrar dudas (FUD): en realidad me gusta el enfoque. Solo que me da curiosidad genuina si alguien sabe cómo planean mantener sincronizado de forma sólida el estado entre capas en la práctica.
@Dusk #dusk #DUSK $DUSK
