Siento una fuerte sensación de continuidad al usar DUSK para el gas en ambos lados de la arquitectura de Dusk Network.
El Dusk L1 en vivo y el DuskEVM en la red de pruebas siguen siendo entornos de ejecución separados. DuskEVM envía transacciones a un secuenciador, publica lotes y compromisos de estado en DuskDS, y depende de un puente para mover DUSK y mensajes entre ambos.
Un solo activo no significa un solo estado.
Esa distinción es fácil de pasar por alto en una wallet. Un saldo puede salir de la L1, aparecer dentro de DuskEVM, pagar por un contrato Solidity y más tarde volver. Para el usuario, todo parece DUSK en todo momento. Debajo, cada transición depende de una etapa y un estado distintos.
Esto importa más allá del movimiento de tokens. Dusk quiere que las aplicaciones de EVM se conecten con activos de L1 y flujos de trabajo orientados a la privacidad. Si una aplicación trata una presentación al puente como una liquidación L1 completada, puede actuar sobre el valor antes de que el proceso entre capas haya alcanzado el estado que el usuario asume.
La misma ambigüedad puede afectar a los mensajes. Una llamada de contrato en un lado puede depender de un estado que el otro lado aún no ha reconocido.
No busco una temporización idéntica en ambos entornos. Busco un estado explícito.
La wallet debería indicar si los fondos están en la L1, aceptados por el puente, representados en DuskEVM o disponibles para devolverse. Las aplicaciones deberían consumir el estado del protocolo en lugar de adivinar a partir del tiempo transcurrido. Las transferencias fallidas y retrasadas necesitan una única ruta de recuperación que no cree una segunda transacción por accidente.
La mejor evidencia serían depósitos y retiros repetidos bajo carga, con distribuciones públicas de latencia y sin saldos ambiguos después de interrupciones.
Dusk puede hacer que el mismo token sea útil en toda su pila. La tarea difícil es lograr que cada usuario sepa qué sistema controla actualmente ese token y qué debe ocurrir antes de que el control cambie de nuevo.
@Dusk_Foundation $DUSK #dusk
$ACE $BTW
El Dusk L1 en vivo y el DuskEVM en la red de pruebas siguen siendo entornos de ejecución separados. DuskEVM envía transacciones a un secuenciador, publica lotes y compromisos de estado en DuskDS, y depende de un puente para mover DUSK y mensajes entre ambos.
Un solo activo no significa un solo estado.
Esa distinción es fácil de pasar por alto en una wallet. Un saldo puede salir de la L1, aparecer dentro de DuskEVM, pagar por un contrato Solidity y más tarde volver. Para el usuario, todo parece DUSK en todo momento. Debajo, cada transición depende de una etapa y un estado distintos.
Esto importa más allá del movimiento de tokens. Dusk quiere que las aplicaciones de EVM se conecten con activos de L1 y flujos de trabajo orientados a la privacidad. Si una aplicación trata una presentación al puente como una liquidación L1 completada, puede actuar sobre el valor antes de que el proceso entre capas haya alcanzado el estado que el usuario asume.
La misma ambigüedad puede afectar a los mensajes. Una llamada de contrato en un lado puede depender de un estado que el otro lado aún no ha reconocido.
No busco una temporización idéntica en ambos entornos. Busco un estado explícito.
La wallet debería indicar si los fondos están en la L1, aceptados por el puente, representados en DuskEVM o disponibles para devolverse. Las aplicaciones deberían consumir el estado del protocolo en lugar de adivinar a partir del tiempo transcurrido. Las transferencias fallidas y retrasadas necesitan una única ruta de recuperación que no cree una segunda transacción por accidente.
La mejor evidencia serían depósitos y retiros repetidos bajo carga, con distribuciones públicas de latencia y sin saldos ambiguos después de interrupciones.
Dusk puede hacer que el mismo token sea útil en toda su pila. La tarea difícil es lograr que cada usuario sepa qué sistema controla actualmente ese token y qué debe ocurrir antes de que el control cambie de nuevo.
@Dusk_Foundation $DUSK #dusk
$ACE $BTW