Att konstruera den olyckliga vägen: Förstå BitVM2-arkitekturen Del tre: Kanoniskt tillstånd kräver kedjekontext Ett bevis för en BitVM2-peg-out är bara så bra som det tillstånd det bevisar. Om en operatör kan välja de publika inmatningarna under en tvist kan de generera ett giltigt bevis över en felaktig/förgrenad L2-historik och ändå försöka avsluta. Kryptografin stämmer; Sammanhanget är fel. GOAT Networks lösning är att förankra vilken L2-historik är kanonisk genom att committa den aktiva sequencern på Bitcoin. Hur det fungerar (konceptuellt): • L2 kör ett decentraliserat sequencernätverk, och sequencerarnas publika nycklar (eller ett åtagande till dem) är förankrade på Bitcoin. • Uppdateringar av sequencer-set utförs via ett försignerat transaktionsflöde där en uppdatering endast är giltig om den godkänns av en tillräcklig tröskel (t.ex. 2/3) av den aktuella mängden. • Uppdateringsflödet commiterar nästa rundas sequencer-sethash på Bitcoin (inklusive ett OP_RETURN åtagande för enklare verifiering). Sedan, under verifieringen av utlösningen, "litar inte systemet på operatörens senaste tillstånd". Den tvingar operatorn att bevisa att: • de relevanta uppdateringstransaktionerna i sequencer-setet bekräftas på den längsta giltiga Bitcoin-kedjan (kedjakontext), och • det L2-tillstånd som refereras härleds från den senaste committerade sekvensermängden (kanoniskhet), och • tillgångsbränningen ingår i det kanoniska L2-tillståndet. 'Watchtowers' finns specifikt för att tillhandahålla och intyga Bitcoin-kedjans kontext som används i utmaningar (längsta kedjans headers/bevis), så tvister kan binda "senast" till Bitcoin-verkligheten snarare än operatörens val. Nettoeffekten: en operatör kan inte säkert avsluta med ett bevis via en privat fork, eftersom beviset måste vara förenligt med sequencer-set-historiken som är förankrad på Bitcoin. Nästa punkt: godtyckliga användaruttag – att separera användarens "ta ut x BTC"-flöde från operatörens återbetalningssäkra flöde.