La verità trascurata: la reale motivazione dietro la rimozione delle restrizioni su OP_RETURN in Bitcoin Core v30

Chainfeeds Guida alla lettura:

La modifica della policy OP_RETURN in Bitcoin Core v30: non è una resa agli Ordinals, ma una gestione proattiva per l’ecosistema BitVM. Non si tratta di una risposta passiva alla speculazione, ma di una preparazione anticipata per l’innovazione tecnologica. Questo riflette il pensiero lungimirante degli sviluppatori Core.

Fonte dell’articolo:

Autore dell’articolo:

Aaron Zhang

Punto di vista:

Aaron Zhang: Nell’aprile 2024, Citrea ha lanciato il primo BitVM bridge completo — Clementine. È il primo zkRollup su Bitcoin, che utilizza BitVM per la verifica su L1. Poi hanno incontrato una difficoltà tecnica: era necessario pubblicare on-chain 144 byte di dati di ancoraggio. Questi 144 byte includono 128 byte: Groth16 zero-knowledge proof, e 16 byte: total accumulated work (prova del lavoro totale accumulato). Questi dati servono per dimostrare, quando il Watchtower contesta l’Operator, che essi possiedono la corretta catena Bitcoin. Il problema è che OP_RETURN permette solo 83 byte. Non basta. Qualcuno potrebbe chiedere perché non inserirli nel witness? Come fanno gli Ordinals? La differenza chiave è che le transazioni di verifica successive di Citrea devono leggere questi dati. Ma Bitcoin Script non può fare riferimento ai dati witness della transazione precedente. Quindi i dati devono essere nella posizione scriptPubKey, non è opzionale. In breve: i dati witness possono solo dimostrare la validità della transazione corrente, ma non possono essere letti dalle transazioni successive. I dati scriptPubKey possono essere referenziati dagli Script delle transazioni successive. La logica di verifica di BitVM richiede riferimenti concatenati, quindi è necessario usare scriptPubKey. 83 byte non bastano, quindi Citrea è stata costretta a utilizzare un metodo molto problematico: creare output Taproot “non spendibili”, mascherando i dati come chiavi pubbliche. Il problema di questa soluzione è che gonfia permanentemente il set UTXO. Ogni transazione WatchtowerChallenge crea due UTXO che non potranno mai essere ripuliti. Tutti i nodi completi devono conservare per sempre queste false chiavi pubbliche. Questo è esattamente lo scenario peggiore che gli sviluppatori Core hanno sempre cercato di evitare. Il ragionamento degli sviluppatori Core: la situazione attuale è che Citrea usa falsi UTXO (male), in futuro altri progetti BitVM seguiranno l’esempio o useranno multisig nude (come il protocollo Stamp). La conclusione è che è meglio allentare OP_RETURN, offrendo una via con “danni minori”. Questa è una strategia di harm reduction (riduzione del danno). Perché gli sviluppatori Core sono disposti a facilitare BitVM? Perché BitVM rappresenta una direzione importante per l’innovazione su Bitcoin L1. Adam Back, CEO di Blockstream, ha detto: “Il meccanismo di ancoraggio di BitVM è una direzione importante per L1”. Se l’ecosistema BitVM si svilupperà: vari zkRollup, cross-chain bridges e verifiche on-chain complesse avranno esigenze simili di ancoraggio.