Ingeniería El camino infeliz: Entendiendo la arquitectura BitVM2 Parte Dos: Bloqueadores Prácticos de BitVM2 BitVM2 es un framework puente fuerte, pero "funciona en teoría" no es el límite de Bitcoin. El criterio es si el camino infeliz es barato, inequívoco y compatible con los incentivos. En un despliegue al estilo zkRollup de BitVM2, aparecen rápidamente tres bloqueadores prácticos: 1. Demostrando el estado equivocado Durante un peg-out desafiado, el operador puede intentar usar una prueba válida sobre un historial L2 incorrecto o bifurcado. Si el "estado más reciente" no está determinado objetivamente, la prueba puede ser internamente correcta pero económicamente fraudulenta. 2. Los usuarios no pueden retirar cantidades arbitrarias Los peg-outs clásicos de BitVM2 están ligados a cantidades fijas de peg-in en L1 y a flujos de estilo operador. No se puede esperar que los usuarios finales ejecuten un flujo de trabajo de operador solo para retirar "x BTC". 3. Los incentivos no pagan de forma fiable al actor honesto Si los retadores no cobran de forma constante, dejan de ver. Un modo de fallo específico: la entidad que financia o inicia un desafío no es necesariamente la que cumple el paso final de refutación, por lo que las recompensas pueden ser capturadas por otros. El diseño GOAT BitVM2 apunta directamente a estos con tres movimientos arquitectónicos: • Comprometer el secuenciador en Bitcoin para que el "estado canónico L2" quede anclado externamente. • Trasladar la garantía del operador/challenger a L2 + usar el flujo de retirada de atomic swap para que los usuarios retiren cantidades arbitrarias limpiamente, mientras los operadores se reembolsan a sí mismos mediante pruebas L2. • Reducir la sobrecarga de disputas con circuitos distorsionados + DV-SNARK para que el camino de desafío sea operativamente viable. A continuación en la Parte Tres: qué significa anclar la visión canónica L2 en Bitcoin al hacer commit del conjunto secuenciador, y por qué esto cierra la salida de "probar el estado incorrecto".