Engineering den unglücklichen Pfad: Verständnis der BitVM2-Architektur Teil Eins: Sicherheit lebt im Streitpfad Ein Bitcoin L2 lebt oder stirbt an seinem unglücklichen Pfad. Auf Bitcoin bekommst du nicht "den Verifier on-chain ausführen und weitermachen". Du bekommst eine eingeschränkte Ausführungsumgebung, vorab signierte Transaktionsgraphen und Zeitbeschränkungen, die genau definieren, wann jede Partei handeln kann. BitVM2 ist ein optimistisches Durchsetzungsmodell für Bitcoin: off-chain ausführen, dann die Korrektheit über ein on-chain Streitprotokoll durch vorab signierte Transaktionen durchsetzbar machen. Das führt zu einer einfachen Ingenieureregel: Wenn Streitigkeiten teuer sind oder durch Gebühren gestoppt werden können, funktioniert das Sicherheitsmodell einfach nicht. BitVM-basierte Systeme funktionieren, indem sie den Betreibern erlauben, off-chain auszuführen, und dann jedem die Möglichkeit geben, on-chain herauszufordern und das Protokoll unter einer 1-von-n Ehrlichkeitsannahme auf einen Streitpfad zu zwingen (mindestens ein ehrlicher Herausforderer für die Gültigkeit; mindestens ein ehrlicher Betreiber für die Lebensfähigkeit). Dieser Streitpfad ist der Mechanismus. Vorab signierte Transaktionen und Einmal-Signaturen (Herausforderungsfenster, Antwortfristen, Finalisierung) sind die "Laufzeit" der Brücke und ihrer Ausgänge. Wenn wir also über den Aufbau auf BitVM2 sprechen, ist der Nordstern nicht Marketingbegriffe wie "vertrauenslos". Der Nordstern ist: • Streitigkeiten, die günstig genug sind, um ausgeführt zu werden, • Kettenkontext, der objektiv genug ist, um "den falschen Zustand beweisen" Ausgänge zu verhindern • Transaktionsflüsse, die unter realen Gebührenbedingungen weiter vorankommen. Diese Serie zerlegt, wie wir diese Einschränkungen im GOAT BitVM2-Design Stück für Stück angegangen sind. In Teil Zwei: die praktischen Blockaden für die Bereitstellung eines produktionsbereiten zkRollup auf Bitcoin.