Engenharia do Caminho Infeliz: Entendendo a Arquitetura BitVM2 Parte Três: Estado Canônico Requer Contexto de Cadeia Uma prova de peg-out no BitVM2 só é tão boa quanto o estado que ela está provando. Se um operador puder escolher as entradas públicas durante uma disputa, ele pode gerar uma prova válida sobre um histórico L2 incorreto/bifurcado e ainda tentar sair. A criptografia está confirmada; O contexto está errado. A solução da GOAT Network é ancorar qual histórico L2 é canônico, comprometendo o conjunto de sequenciadores ativos no Bitcoin. Como funciona (conceitualmente): • O L2 opera uma rede de sequenciadores descentralizada, e as chaves públicas dos sequenciadores (ou um compromisso com elas) são ancoradas no Bitcoin. • Atualizações do conjunto de sequenciadores são executadas via um fluxo de transações pré-assinado, onde uma atualização só é válida se aprovada por um limiar suficiente (por exemplo, 2/3) do conjunto atual. • O fluxo de atualização compromete o hash do conjunto sequenciador da próxima rodada no Bitcoin (incluindo um compromisso OP_RETURN para facilitar a verificação). Então, durante a verificação por peg-out, o sistema não "confia no estado mais recente do operador". Ele força o operador a provar que: • as transações relevantes de atualização do conjunto de sequenciadores são confirmadas na cadeia Bitcoin válida mais longa (contexto da cadeia), e • o estado L2 referenciado é derivado daquele conjunto de sequenciadores mais recente (canonicidade), e • a queima de ativos está incluída nesse estado L2 canônico. As 'torres de vigia' existem especificamente para fornecer e atestar o contexto da cadeia Bitcoin usado em desafios (cabeçalhos/evidências da cadeia mais longa), então disputas podem vincular a "mais recente" à realidade do Bitcoin, e não à escolha do operador. O efeito líquido: um operador não pode sair com segurança usando uma prova em um fork privado, porque a prova deve ser consistente com o histórico do conjunto de sequenciadores ancorado no Bitcoin. A seguir: saques arbitrários de usuários - separando o fluxo "saque x BTC" do usuário do fluxo de comprovação de reembolso do operador.