Att konstruera den olyckliga vägen: Förstå BitVM2-arkitekturen Del ett: Säkerheten lever på tviststigen En Bitcoin L2 lever eller dör på sin olyckliga väg. På Bitcoin får du inte "kör verifieraren on-chain och gå vidare". Du får en begränsad exekveringsmiljö, försignerade transaktionsgrafer och tidslås som exakt definierar när varje part kan agera. BitVM2 är ett optimistiskt efterlevnadsmönster för Bitcoin: kör off-chain, gör sedan korrekthet verkställbar via ett on-chain-tvistprotokoll byggt på försignerade transaktioner. Det leder till en enkel ingenjörsregel: Om tvister är dyra eller kan fördröjas genom avgifter fungerar säkerhetsmodellen helt enkelt inte. BitVM-baserade system fungerar genom att låta operatörer köra off-chain, och sedan ge vem som helst möjlighet att utmana on-chain och tvinga protokollet in på en tvistväg under en 1-av-n ärlighetsantagande (minst en ärlig utmanare för giltighet; minst en ärlig operatör för liveness). Denna tvistväg är mekanismen. Försignerade transaktioner och engångssignaturer (utmaningsfönster, svarsdeadlines, slutförande) är "runtime" för bryggan och dess utgångar. Så när vi pratar om att bygga på BitVM2 är ledstjärnan inte marknadsföringstermer som "förtroendelös". Polstjärnan är: • tvister som är tillräckligt billiga att genomföra, • kedjakontext som är tillräckligt objektiv för att förhindra "bevisa fel tillstånd"-utgångar • transaktionsflöden som fortsätter att fortskrida under reala avgiftsvillkor. Den här serien går igenom hur vi närmade oss dessa begränsningar i GOAT BitVM2-designen, en del i taget. Kommer i del två: de praktiska hindrarna för att implementera en produktionsklar zkRollup på Bitcoin.