Lo que más se suele ignorar en los puentes entre cadenas es la asimetría de direcciones: los depósitos pueden ser rápidos, pero los retiros requieren pasar por comprobaciones y desafíos. DuskEVM, basado en OP Stack, detalla que el ciclo de vida de un retiro en @Dusk oficial es: iniciar, salida disponible, preparar la prueba, entrar en el período de desafío, preparar el finalize y completar finalmente. Es decir, no es “toca y vuelve”.
En el modelo OP estándar, el clásico período de desafío de Optimism es de 7 días, pensado para que los retadores demuestren que alguna raíz de salida o compromiso de estado es incorrecto. $DUSK Dado que el ancla de liquidación está en DuskDS, en la promoción se afirma que este intervalo puede eliminarse o acortarse considerablemente; sin embargo, la información pública no proporciona un número de período de desafío fijo y verificable por todos, como hace Optimism. En su lugar, exige que los usuarios sigan el estado de la wallet y no usen “hace cuánto” para determinar si ya está listo. Este diseño de “basarse en el estado” quizá sea más preciso para el protocolo; pero para usuarios e instituciones es más difícil construir expectativas.
Lo que de verdad me hace desconfiar es la suposición de confianza. Si el contrato del puente tiene una vulnerabilidad, o alguien envía una prueba incorrecta, ¿quién asume la pérdida? El material no explica con claridad los detalles sobre un fondo de seguros, la propiedad del puente y los permisos de actualización. La seguridad de un puente estilo OP depende del supuesto de que “alguien puede desafiar dentro de la ventana”; si nadie está atento, el error podría confirmarse. #dusk Además, históricamente ha habido riesgos operativos relacionados con puentes, lo que recalca que la operación del puente y la gestión de permisos en sí mismas son puntos de riesgo.
Por eso, los desarrolladores deben separar el “llegó el dinero” en DuskEVM del “verdadero asentamiento” en Dusk L1. Al transferir activos entre cadenas, sobre todo hay que confirmar si el puente de Dusk ofrece un período de desafío claramente definido, o si solo se puede “según el caso”. Si la respuesta es lo segundo, entonces ese puente todavía no es infraestructura básica para usar con los ojos cerrados.
En el modelo OP estándar, el clásico período de desafío de Optimism es de 7 días, pensado para que los retadores demuestren que alguna raíz de salida o compromiso de estado es incorrecto. $DUSK Dado que el ancla de liquidación está en DuskDS, en la promoción se afirma que este intervalo puede eliminarse o acortarse considerablemente; sin embargo, la información pública no proporciona un número de período de desafío fijo y verificable por todos, como hace Optimism. En su lugar, exige que los usuarios sigan el estado de la wallet y no usen “hace cuánto” para determinar si ya está listo. Este diseño de “basarse en el estado” quizá sea más preciso para el protocolo; pero para usuarios e instituciones es más difícil construir expectativas.
Lo que de verdad me hace desconfiar es la suposición de confianza. Si el contrato del puente tiene una vulnerabilidad, o alguien envía una prueba incorrecta, ¿quién asume la pérdida? El material no explica con claridad los detalles sobre un fondo de seguros, la propiedad del puente y los permisos de actualización. La seguridad de un puente estilo OP depende del supuesto de que “alguien puede desafiar dentro de la ventana”; si nadie está atento, el error podría confirmarse. #dusk Además, históricamente ha habido riesgos operativos relacionados con puentes, lo que recalca que la operación del puente y la gestión de permisos en sí mismas son puntos de riesgo.
Por eso, los desarrolladores deben separar el “llegó el dinero” en DuskEVM del “verdadero asentamiento” en Dusk L1. Al transferir activos entre cadenas, sobre todo hay que confirmar si el puente de Dusk ofrece un período de desafío claramente definido, o si solo se puede “según el caso”. Si la respuesta es lo segundo, entonces ese puente todavía no es infraestructura básica para usar con los ojos cerrados.
