Ingegneria del percorso infelice: Comprendere l'architettura di BitVM2 Parte Due: I blocchi pratici di BitVM2 BitVM2 è un forte framework di bridge, ma "funziona in teoria" non è il parametro per Bitcoin. Il parametro è se il percorso infelice è economico, chiaro e compatibile con gli incentivi. In un'implementazione di BitVM2 in stile zkRollup, tre blocchi pratici si presentano rapidamente: 1. Provare lo stato sbagliato Durante un peg-out contestato, l'operatore può tentare di utilizzare una prova valida su una storia L2 errata/diversa. Se lo "stato più recente" non è determinato oggettivamente, la prova può essere internamente corretta ma economicamente fraudolenta. 2. Gli utenti non possono ritirare importi arbitrari I peg-out classici di BitVM2 sono legati a importi fissi di peg-in L1 e flussi di tipo operatore. Non ci si può aspettare che gli utenti finali eseguano un flusso di lavoro da operatore solo per ritirare "x BTC". 3. Gli incentivi non pagano affidabilmente l'attore onesto Se i contestatori non vengono pagati in modo coerente, smettono di osservare. Un modo specifico di fallimento: l'entità che finanzia/inizia una sfida non è necessariamente l'entità che completa il passo finale di disconferma, quindi le ricompense possono essere catturate da altri. Il design GOAT di BitVM2 affronta direttamente questi problemi con tre mosse architettoniche: • Impegnare il set di sequencer su Bitcoin in modo che lo "stato L2 canonico" sia ancorato esternamente. • Spostare il collaterale dell'operatore/contestatore su L2 + utilizzare un flusso di prelievo a scambio atomico in modo che gli utenti possano ritirare importi arbitrari in modo pulito, mentre gli operatori si rimborsano tramite prove L2. • Ridurre il sovraccarico delle dispute con circuiti confusi + DV-SNARK in modo che il percorso di sfida sia operativamente fattibile. Prossimamente nella Parte Tre: cosa significa ancorare la vista L2 canonica su Bitcoin impegnando il set di sequencer e perché questo chiude l'uscita "provare lo stato sbagliato".