Ingegneria del percorso infelice: Comprendere l'architettura di BitVM2 Parte Tre: Lo stato canonico richiede il contesto della Chain Una prova di peg-out di BitVM2 è valida solo quanto lo stato che sta dimostrando. Se un operatore può scegliere gli input pubblici durante una disputa, può generare una prova valida su una storia L2 errata/diversa e tentare comunque di uscire. La crittografia è corretta; il contesto è sbagliato. La soluzione di GOAT Network è ancorare quale storia L2 è canonica impegnando il set di sequencer attivo su Bitcoin. Come funziona (concettualmente): • L'L2 esegue una rete di sequencer decentralizzata, e le chiavi pubbliche dei sequencer (o un impegno su di esse) sono ancorate su Bitcoin. • Gli aggiornamenti del set di sequencer vengono eseguiti tramite un flusso di transazioni pre-firmate dove un aggiornamento è valido solo se approvato da una soglia sufficiente (ad es. 2/3) del set attuale. • Il flusso di aggiornamento impegna l'hash del set di sequencer della prossima tornata su Bitcoin (incluso un impegno OP_RETURN per una verifica più semplice). Poi, durante la verifica del peg-out, il sistema non "si fida dell'ultimo stato dell'operatore". Costringe l'operatore a dimostrare che: • le transazioni di aggiornamento del set di sequencer rilevanti sono confermate sulla catena Bitcoin valida più lunga (contesto della chain), e • lo stato L2 a cui si fa riferimento è derivato dall'ultimo set di sequencer impegnato (canonicalità), e • la distruzione dell'asset è inclusa in quello stato L2 canonico. I 'Watchtowers' esistono specificamente per fornire e attestare il contesto della chain di Bitcoin utilizzato nelle sfide (header/evidenze della catena più lunga), in modo che le dispute possano legare il "più recente" alla realtà di Bitcoin, piuttosto che alla scelta dell'operatore. L'effetto netto: un operatore non può uscire in sicurezza utilizzando una prova su un fork privato, perché la prova deve essere coerente con la storia del set di sequencer ancorata su Bitcoin. Prossimamente: prelievi arbitrari degli utenti - separare il flusso di "ritira x BTC" dell'utente dal flusso di prova di rimborso dell'operatore.