Å konstruere den ulykkelige veien: Forstå BitVM2-arkitekturen Del to: BitVM2s praktiske blokkeringer BitVM2 er et sterkt bro-rammeverk, men «fungerer i teorien» er ikke standarden for Bitcoin. Målestokken er om den ulykkelige veien er billig, entydig og insentivforenlig. I en zkRollup-stil BitVM2-implementering dukker tre praktiske blokkere raskt opp: 1. Å bevise feil tilstand Under en utfordret peg-out kan operatøren forsøke å bruke et gyldig bevis over en feil/forket L2-historikk. Hvis «siste tilstand» ikke er objektivt fastslått, kan beviset være internt korrekt, men økonomisk svindelaktig. 2. Brukere kan ikke ta ut vilkårlige beløp Klassiske BitVM2-tilkoblinger er knyttet til faste L1-tilkoblingsmengder og operatørlignende flyter. Sluttbrukere kan ikke forventes å kjøre en operatørarbeidsflyt bare for å ta ut «x BTC». 3. Insentiver betaler ikke pålitelig den ærlige aktøren Hvis utfordrerne ikke får betalt jevnlig, slutter de å se på. En spesifikk feilmodus: enheten som finansierer/initierer en utfordring er ikke nødvendigvis den som lander det siste avvisningssteget, så belønninger kan bli fanget av andre. GOAT BitVM2-designet retter seg direkte mot disse med tre arkitektoniske grep: • Committer sequenceren satt på Bitcoin slik at «kanonisk L2-tilstand» er eksternt forankret. • Flytt operatør/utfordrer-sikkerhet til L2 + bruk atomic swap-uttaksflyt slik at brukerne tar ut vilkårlige beløp rent, mens operatørene refunderer seg selv via L2-bevis. • Redusere tvistekostnader med forvrengte kretser + DV-SNARK slik at utfordringsveien er operasjonelt gjennomførbar. Neste i del tre: hva det betyr å forankre det kanoniske L2-synet på Bitcoin ved å committe sequencer-settet, og hvorfor dette lukker utgangen for å «bevise feil tilstand».