Ingeniería El camino infeliz: Entendiendo la arquitectura BitVM2 Parte Tres: El estado canónico requiere contexto de cadena Una prueba de pinjación en BitVM2 solo es tan buena como el estado que está demostrando. Si un operador puede elegir las entradas públicas durante una disputa, puede generar una prueba válida sobre un historial L2 incorrecto o bifurcado y aun así intentar salir. La criptografía es correcta; El contexto es incorrecto. La solución de GOAT Network es anclar qué historial L2 es canónico comprometiendo el conjunto de secuenciador activo en Bitcoin. Cómo funciona (conceptualmente): • El L2 ejecuta una red descentralizada de secuenciadores, 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 mediante un flujo de transacciones pre-firmado donde una actualización solo es válida si se aproba un umbral suficiente (por ejemplo, 2/3) del conjunto actual. • El flujo de actualización confirma el hash del conjunto de secuenciadores de la siguiente ronda en Bitcoin (incluyendo un compromiso de OP_RETURN para facilitar la verificación). Luego, durante la verificación por peg-out, el sistema no "confía en el estado más reciente del operador". Obliga al operador a demostrar que: • las transacciones relevantes de actualización del conjunto de secuenciadores se confirman en la cadena Bitcoin válida más larga (contexto de cadena), y • el estado L2 al que se refiere se deriva de ese conjunto de secuenciadores comprometidos más reciente (canonicidad), y • el consumo de activos está incluido en ese estado canónico L2. Las 'torres de vigilancia' existen específicamente para suministrar y dar fe del contexto de la cadena Bitcoin usado en los desafíos (cabeceras/evidencias de la cadena más larga), por lo que las disputas pueden vincular la "última actualización" a la realidad de Bitcoin, en lugar de la elección del operador. El efecto neto: un operador no puede salir de forma segura usando una prueba a través de un fork privado, porque la demostración debe ser consistente con el historial de conjuntos de secuenciadores anclados en Bitcoin. A continuación: retiradas arbitrarias de usuarios, separando el flujo de "retiro x BTC" del usuario del flujo de prueba de reembolso del operador.