Ingénierie du chemin malheureux : Comprendre l'architecture de BitVM2 Partie Un : La sécurité réside dans le chemin de litige Un Bitcoin L2 vit ou meurt sur son chemin malheureux. Sur Bitcoin, vous n'obtenez pas "exécutez le vérificateur sur la chaîne et passez à autre chose". Vous obtenez un environnement d'exécution contraint, des graphes de transactions pré-signées et des délais qui définissent exactement quand chaque partie peut agir. BitVM2 est un modèle d'application optimiste pour Bitcoin : exécutez hors chaîne, puis rendez la correction exécutable via un protocole de litige sur chaîne construit à partir de transactions pré-signées. Cela conduit à une règle d'ingénierie simple : si les litiges sont coûteux ou peuvent être retardés par des frais, le modèle de sécurité ne fonctionne tout simplement pas. Les systèmes basés sur BitVM fonctionnent en permettant aux opérateurs d'exécuter hors chaîne, puis en donnant à quiconque la possibilité de contester sur chaîne et de forcer le protocole sur un chemin de litige sous une hypothèse d'honnêteté 1-sur-n (au moins un challenger honnête pour la validité ; au moins un opérateur honnête pour la vivacité). Ce chemin de litige est le mécanisme. Les transactions pré-signées et les signatures à usage unique (fenêtres de contestation, délais de réponse, finalisation) sont le "runtime" du pont et de ses sorties. Donc, quand nous parlons de construire sur BitVM2, l'étoile du nord n'est pas des termes marketing comme "sans confiance". L'étoile du nord est : • des litiges suffisamment peu coûteux à exécuter, • un contexte de chaîne suffisamment objectif pour empêcher les sorties "prouver le mauvais état" • des flux de transactions qui continuent de progresser sous de réelles conditions de frais. Cette série décompose comment nous avons abordé ces contraintes dans la conception GOAT de BitVM2, un morceau à la fois. À venir dans la Partie Deux : les obstacles pratiques au déploiement d'un zkRollup prêt pour la production sur Bitcoin.