"EVM compatible" son estas cuatro palabras que se usan hasta el cansancio en el relato de ampliación de ETH en L2, pero si de verdad abres el flujo de salida de OP Stack, verás que no estás haciendo un puente entre cadenas: estás conciliando con una máquina de estados de cuatro fases. L2 inicia → esperar a que el output proposal cubra ese estado de tu transacción → en L1 ejecutar prove_withdrawal con la prueba de Merkle → completar la ventana del dispute game de 7 días para finalizar. En Base/OP Mainnet, este balance los usuarios ya lo han regañado: entre los tres primeros pasos, el capital queda bloqueado en el contrato puente de L1; no se “pierde”, pero tampoco te pertenece. Si en cualquiera de las fases falla porque el gas en L1 no alcanza, el output root es desafiado, o el proposer se queda parado, el retiro se queda atascado en “Ready to prove” o “Waiting for finalization”.
En Arbitrum, aparentemente solo hay dos transacciones (retryable ticket en L1 + ejecución en L2), pero si el ticket se redime automáticamente falla, cae en un buffer en memoria; dentro de 7 días cualquiera puede redimirlo manualmente, y después de caducar se devuelve el escrow. Lo más turbio es la ejecución desordenada que señaló Trail of Bits: A corre antes que B, y si el protocolo no gestiona ese orden temporal, equivale a enterrar una vulnerabilidad tipo reentrancy. Esto demuestra que “menos pasos” no significa “estados fáciles de entender”; solo esconde la complejidad dentro de precompilados.
Por eso, la salida de #dusk EVM Testnet, desglosada en initiate / submit proof / finalize, no es que @Dusk esté dificultando al usuario a propósito; es que no simplificó en secreto el “periodo de desafío de 7 días + madurez de la prueba” de OP. En una testnet, usar test tokens para que funcione solo prueba que la billetera pueda reconocer estos estados: Waiting for output proposal / Ready to prove / Waiting to finalize; no prueba que en mainnet, bajo alta carga, el proposer produzca el root de forma estable, ni que el dispute game no quede continuamente desafiado hasta ahogar a los usuarios, ni que sea suficiente tanto el gas del lado EVM como el costo de las dos operaciones en L1.
Yo veo que el puente de ETH L2 nunca cuenta “qué herramientas compatibles” soporta; solo reconoce tres señales duras: si el tiempo medio de salida se desvía de la teoría de 7 días y converge hacia abajo, si cuando falla prove se puede cambiar a otro output root para seguir con vida sin reiniciar todo el flujo, y si cuando los activos se quedan bloqueados, el usuario puede leer en el contrato de Etherscan la prueba de almacenamiento de su withdrawal. Tener menos botones es solo un caramelo de UX; que los estados sean explicables es la verdadera seguridad. Antes de que estas tres condiciones se verifiquen de nuevo con datos de la mainnet, “EVM compatible” en el lado del desarrollo es comodidad, pero no es “listo” para el usuario. $DUSK , así que Base, así, y Arbitrum, también.
En Arbitrum, aparentemente solo hay dos transacciones (retryable ticket en L1 + ejecución en L2), pero si el ticket se redime automáticamente falla, cae en un buffer en memoria; dentro de 7 días cualquiera puede redimirlo manualmente, y después de caducar se devuelve el escrow. Lo más turbio es la ejecución desordenada que señaló Trail of Bits: A corre antes que B, y si el protocolo no gestiona ese orden temporal, equivale a enterrar una vulnerabilidad tipo reentrancy. Esto demuestra que “menos pasos” no significa “estados fáciles de entender”; solo esconde la complejidad dentro de precompilados.
Por eso, la salida de #dusk EVM Testnet, desglosada en initiate / submit proof / finalize, no es que @Dusk esté dificultando al usuario a propósito; es que no simplificó en secreto el “periodo de desafío de 7 días + madurez de la prueba” de OP. En una testnet, usar test tokens para que funcione solo prueba que la billetera pueda reconocer estos estados: Waiting for output proposal / Ready to prove / Waiting to finalize; no prueba que en mainnet, bajo alta carga, el proposer produzca el root de forma estable, ni que el dispute game no quede continuamente desafiado hasta ahogar a los usuarios, ni que sea suficiente tanto el gas del lado EVM como el costo de las dos operaciones en L1.
Yo veo que el puente de ETH L2 nunca cuenta “qué herramientas compatibles” soporta; solo reconoce tres señales duras: si el tiempo medio de salida se desvía de la teoría de 7 días y converge hacia abajo, si cuando falla prove se puede cambiar a otro output root para seguir con vida sin reiniciar todo el flujo, y si cuando los activos se quedan bloqueados, el usuario puede leer en el contrato de Etherscan la prueba de almacenamiento de su withdrawal. Tener menos botones es solo un caramelo de UX; que los estados sean explicables es la verdadera seguridad. Antes de que estas tres condiciones se verifiquen de nuevo con datos de la mainnet, “EVM compatible” en el lado del desarrollo es comodidad, pero no es “listo” para el usuario. $DUSK , así que Base, así, y Arbitrum, también.