Ingeniería del Camino Desafortunado: Entendiendo la Arquitectura de BitVM2 Parte Tres: El Estado Canónico Requiere Contexto de Chain Una prueba de peg-out de BitVM2 es tan buena como el estado que está probando. Si un operador puede elegir las entradas públicas durante una disputa, puede generar una prueba válida sobre una historia L2 incorrecta/forjada y aún intentar salir. La criptografía es correcta; el contexto es erróneo. La solución de GOAT Network es anclar cuál historia L2 es canónica comprometiendo el conjunto de secuenciadores activos en Bitcoin. Cómo funciona (conceptualmente): • El L2 ejecuta una red de secuenciadores descentralizada, y las claves públicas de los secuenciadores (o un compromiso con ellas) están ancladas en Bitcoin. • Las actualizaciones del conjunto de secuenciadores se ejecutan a través de un flujo de transacciones pre-firmadas donde una actualización solo es válida si es aprobada por un umbral suficiente (por ejemplo, 2/3) del conjunto actual. • El flujo de actualización compromete el hash del conjunto de secuenciadores de la siguiente ronda en Bitcoin (incluyendo un compromiso OP_RETURN para una verificación más fácil). Luego, durante la verificación de peg-out, el sistema no "confía en el último estado del operador". Obliga al operador a probar que: • las transacciones de actualización del conjunto de secuenciadores relevantes están confirmadas en la cadena de Bitcoin más larga y válida (contexto de chain), y • el estado L2 al que se hace referencia se deriva de ese conjunto de secuenciadores comprometido más reciente (canonicidad), y • la quema de activos está incluida en ese estado L2 canónico. Los 'Watchtowers' existen específicamente para suministrar y atestiguar el contexto de la cadena de Bitcoin utilizado en los desafíos (encabezados/evidencias de la cadena más larga), para que las disputas puedan vincular lo "último" a la realidad de Bitcoin, en lugar de a la elección del operador. El efecto neto: un operador no puede salir de manera segura utilizando una prueba sobre un fork privado, porque la prueba debe ser consistente con la historia del conjunto de secuenciadores anclada en Bitcoin. Próximamente: retiros arbitrarios de usuarios - separando el flujo de "retirar x BTC" del flujo de prueba de reembolso del operador.