Ingegneria del percorso infelice: Comprendere l'architettura di BitVM2 Parte Prima: La Sicurezza Vive nel Percorso di Contenzioso Un Bitcoin L2 vive o muore sul suo percorso infelice. Su Bitcoin, non ottieni "esegui il verificatore on-chain e vai avanti". Ottieni un ambiente di esecuzione vincolato, grafi di transazioni pre-firmate e timelock che definiscono esattamente quando ciascuna parte può agire. BitVM2 è un modello di enforcement ottimista per Bitcoin: esegui off-chain, poi rendi la correttezza applicabile tramite un protocollo di contenzioso on-chain costruito da transazioni pre-firmate. Questo porta a una semplice regola ingegneristica: se i contenziosi sono costosi o possono essere bloccati dalle commissioni, il modello di sicurezza semplicemente non funziona. I sistemi basati su BitVM funzionano consentendo agli operatori di eseguire off-chain, poi dando a chiunque la possibilità di contestare on-chain e forzare il protocollo su un percorso di contenzioso sotto un'assunzione di onestà 1 su n (almeno un contestatore onesto per la validità; almeno un operatore onesto per la vitalità). Questo percorso di contenzioso è il meccanismo. Le transazioni pre-firmate e le firme una tantum (finestre di contestazione, scadenze di risposta, finalizzazione) sono il "runtime" del ponte e delle sue uscite. Quindi, quando parliamo di costruire su BitVM2, la stella polare non sono termini di marketing come "senza fiducia". La stella polare è: • contenziosi che sono abbastanza economici da eseguire, • contesto della catena che è obiettivo abbastanza da prevenire uscite "prova lo stato sbagliato" • flussi di transazione che continuano a progredire sotto condizioni di commissione reali. Questa serie analizza come abbiamo affrontato queste limitazioni nel design del GOAT BitVM2, un pezzo alla volta. In arrivo nella Parte Due: i blocchi pratici per il dispiegamento di uno zkRollup pronto per la produzione su Bitcoin.