Engenharia do Caminho Infeliz: Compreendendo a Arquitetura do BitVM2 Parte Dois: Bloqueios Práticos do BitVM2 O BitVM2 é uma forte estrutura de ponte, mas "funciona na teoria" não é o padrão no Bitcoin. O padrão é se o caminho infeliz é barato, inequívoco e compatível com incentivos. Em uma implementação do BitVM2 estilo zkRollup, três bloqueios práticos aparecem rapidamente: 1. Provar o estado errado Durante um peg-out contestado, o operador pode tentar usar uma prova válida sobre uma história L2 incorreta/ramificada. Se o "estado mais recente" não for determinado objetivamente, a prova pode ser internamente correta, mas economicamente fraudulenta. 2. Os usuários não podem retirar quantias arbitrárias Os peg-outs clássicos do BitVM2 estão ligados a quantias fixas de peg-in L1 e fluxos de estilo operador. Não se pode esperar que os usuários finais executem um fluxo de operador apenas para retirar "x BTC". 3. Os incentivos não pagam de forma confiável o ator honesto Se os desafiadores não forem pagos consistentemente, eles param de vigiar. Um modo específico de falha: a entidade que financia/inicia um desafio não é necessariamente a entidade que realiza o passo final de refutação, então as recompensas podem ser capturadas por outros. O design GOAT do BitVM2 visa esses problemas diretamente com três movimentos arquitetônicos: • Comprometer o conjunto de sequenciadores no Bitcoin para que o "estado L2 canônico" esteja ancorado externamente. • Mover a garantia do operador/desafiador para L2 + usar um fluxo de retirada de troca atômica para que os usuários retirem quantias arbitrárias de forma limpa, enquanto os operadores se reembolsam através de provas L2. • Reduzir a sobrecarga de disputas com circuitos embaralhados + DV-SNARK para que o caminho de desafio seja operacionalmente viável. Próximo na Parte Três: o que significa ancorar a visão L2 canônica no Bitcoin comprometendo o conjunto de sequenciadores, e por que isso fecha a saída "provar o estado errado".