Questo articolo è solo per condivisione tecnica e non costituisce alcun consiglio di investimento.
Anche BTC avrà un proprio contratto intelligente?
Nel recente ecosistema Bitcoin, Fractal BTC ha finalmente lanciato la mainnet a settembre dopo aver attraversato più testnet. Una caratteristica importante di Fractal è la possibilità di avere "contratti intelligenti" e quasi contemporaneamente al lancio della rete principale è stato lanciato un nuovo protocollo token CAT 20. Che intelligenza tecnica ha CAT 20? Cosa possiamo imparare?
Bitcoin frattale
Prima di comprendere CAT 20, dobbiamo comprendere brevemente Fractal Bitcoin. La loro relazione è proprio come ERC 20 ed ETH. Il protocollo CAT 20 è distribuito su Fractal Bitcoin.
Fractal Bitcoin, noto anche come Fractal Bitcoin, è una rete di "secondo livello" completamente compatibile con BTC. Rispetto a BTC, il tempo di conferma del blocco è più veloce, impiegando solo 1 minuto. Il suo principio di base è semplicemente, come dice il nome, ovvero quello di creare più copie della rete BTC. Ogni catena elaborerà le transazioni Più nodi saranno in grado di elaborare le transazioni, più veloce sarà naturalmente. Tuttavia, i dettagli specifici, come ad esempio il modo in cui comunicano le diverse catene, non sono ancora chiari e non esistono documenti tecnici ufficiali corrispondenti a cui fare riferimento.
Se solo una transazione a catena di secondo livello fosse più veloce, non ci sarebbe entusiasmo. Tuttavia, l'attivazione di OP_CAT in Fractal, che è stata abbandonata da BTC molto tempo fa per motivi di sicurezza, ha portato le capacità di Fractal Bitcoin a un livello superiore. Alcune persone dicono che OP_CAT può consentire a BTC di avere funzionalità di contratto intelligente modo, c'è spazio per l'immaginazione.
Ora, qualcuno ha implementato un protocollo simile a ERC 20 su Fractal Bitcoin.
Per quanto riguarda il motivo per cui OP_CAT è stato abbandonato e perché può essere utilizzato su Fractal Bitcoin, ne parleremo più avanti. Qui ci concentreremo su CAT 20.
Protocollo CAT Fare riferimento al white paper per il seguente contenuto: Introduzione |. Protocollo CAT (https://catprotocol.org/)
E repository github: GitHub - CATProtocol/cat-token-box: un monorepo per pacchetti che implementano il protocollo CAT (https://github.com/CATProtocol/cat-token-box)
Con il supporto OP_CAT sottostante sarà presto disponibile un protocollo corrispondente, il protocollo CAT. Attualmente, un protocollo attualmente in esecuzione è il protocollo CAT 20 e su Unisat è stato aggiunto un pannello corrispondente: https://explorer.unisat.io/fractal-mainnet/cat20.
Tutti dovrebbero essere in grado di reagire quando vedono il nome CAT 20. Dovrebbe essere più simile a ERC 20. Rispetto al protocollo maturo ERC 20, è molto conveniente per tutti distribuire un token. In che modo CAT 20 implementa un ciclo di vita simile a ERC 20?
Distribuire
Prima della distribuzione, gli utenti devono specificare l'indirizzo del proprio portafoglio e le informazioni di base sul token. Le informazioni di base sul token sono simili a quelle di ERC 20:
Ci saranno alcune differenze. CAT 20 può impostare limiti di pre-estrazione e quantità per ciascuna zecca. Naturalmente, l’ERC 20 può raggiungere queste capacità anche attraverso capacità contrattuali.
Durante la fase di distribuzione verranno avviate due transazioni, che possono essere considerate come due fasi: "commit" e "reveal". Citando lo schema ufficiale, le fasi di distribuzione sono le seguenti:
Nella fase di "commit", le informazioni di base del token verranno scritte nello script di output della transazione, come il nome, il simbolo, ecc. del token. L'hashId della transazione avviata nella fase di "commit" verrà utilizzato come simbolo del token per distinguere gli altri token.
Puoi vedere che l'utxo di questa transazione " bc 1 pucq...ashx " corrisponde al commit. Poi ci sono due transazioni rimanenti che puntano a " bc 1 pszp...rehc 4 ". La prima viene utilizzata per pagare la tariffa del gas per la successiva fase di "rivelazione" e l'altra è il resto.
Nella fase "reveal", puoi vedere che ci sono due input utxo, corrispondenti ai primi due output della precedente fase di commit. Questa transazione genererà innanzitutto un OP_RETURN, in cui verrà salvato l'Hash dello stato iniziale di CAT 20. Quindi verrà emesso un Minter, che svolgerà un ruolo importante nel successivo processo di Mint e verrà utilizzato per mantenere i cambiamenti di stato del processo di Mint.
Guardando indietro all'intero processo di distribuzione, "commit" e "reveal" seguono i due passaggi di invio e rivelazione comunemente utilizzati sulla blockchain. È un modo relativamente comune per distribuire i progetti. Alcuni dati del progetto sono solo in "reveal". verranno rivelate le fasi
COME
Quando guardiamo per la prima volta Mint Token, la transazione appare così.
Come puoi vedere nell'immagine sopra, il processo di Mint ha le seguenti caratteristiche.
L'input di mint è un minter, che viene inizialmente generato durante la distribuzione.
Ogni volta che Mint ha uno e un solo coniatore come input e un numero qualsiasi di coniatori come output (un po' problematico)
Ogni zecca ha un solo gettone (un po' problematico)
L'ordine di output è obbligatorio, minter deve essere seguito da token
Conoscendo il processo Mint, possiamo effettivamente scoprire alcune situazioni speciali che renderanno interessante l’intero processo Mint.
Ad esempio, minter, come risultato della transazione di conio, può essere 1, multiplo o anche 0. Se Mint viene impostato ogni volta su 1, il numero di Minter che possono essere utilizzati nell'intera rete rimarrà invariato (1), il che renderà Mint affollato e tutti dovranno prendere questo Minter per evitarlo In questo caso è necessario impostare il numero di coniatori in uscita ogni volta maggiore di 1, in modo che dopo il conio si possano utilizzare sempre più coniatori.
Tuttavia, ogni produzione aggiuntiva di Minter significa che è necessario pagare un utxo extra. Per ragioni economiche, più persone saranno disposte a impostare Minter su 0, il che porterà inevitabilmente alla deflazione del Minter, il che richiede che alcune persone vengano a fare una donazione e pagare il prezzo. Minter extra volontariamente.
Nella versione V2, l'impostazione predefinita è generare due minatori e lo stato dei due minatori sarà il più simile possibile.
Strutturazione delle transazioni
Alcuni amici potrebbero aver scoperto un problema, ovvero: perché l'utxo di Minter può essere utilizzato per costruire transazioni? Per comprendere questo problema è necessario analizzare il codice sorgente del "contratto".
1、rivela utxo
Innanzitutto, analizziamo la transazione durante il processo di rivelazione e scopriamo che utilizza come input il commit di output della transazione precedente. Perché possiamo prendere un utxo che non è il nostro indirizzo e costruire l'input della transazione?
Secondo il buon senso, una chiave privata corrisponde a una chiave pubblica e la chiave pubblica deriva l'indirizzo. Quando si verifica se un input utxo è valido, di solito viene determinato confrontando se la firma è coerente con la transazione originale dopo essere stata decrittografata con la chiave pubblica. Questa parte della logica è scritta nello script Bitcoin. Quindi possiamo riscrivere abilmente la logica dello script. Le coppie di chiavi pubblica e privata scritte nello script appartengono al nostro indirizzo, in modo da poter controllare utxo di due indirizzi diversi.
Guardando il codice sorgente possiamo vedere cosa è successo:
C'è un altro problema qui, ovvero una chiave privata corrisponde a una chiave pubblica, quindi perché l'indirizzo di commit generato è diverso dal nostro indirizzo? Qui puoi vederlo dal codice sorgente
In altre parole, la nostra chiave privata adatterà la chiave pubblica secondo un ISSUE_PUBKEY, che è anche una caratteristica dell'indirizzo P 2 TR.
2、minter uxo
Durante il processo di rivelazione, utilizziamo diversi utxo come input, ma in realtà la chiave di crittografia è la stessa, ovvero la chiave privata del deployer. Ma nella fase di minter, tutti possono utilizzare questi utxo come input, come si fa?
Immagino che questa parte sia l'abilità di OP_CAT menzionata prima, ovvero l'abilità dei contratti intelligenti. Ogni minter è un contratto intelligente. Tuttavia, il codice sorgente di questa parte non è stato reso pubblico al momento e non conosciamo ancora l’implementazione specifica.
Stato della transazione (V2)
Nella coniazione viene preservato anche lo stato. Questo stato esiste in due posti: uno è nell'OP_RETURN dell'output della transazione e l'altro è archiviato nello smart contract, che è il Minter e il Token menzionati sopra.
Ciò che è memorizzato in OP_RETURN è l'hash dello stato di output della transazione corrente e i rimanenti tempi di conio del token sono memorizzati nel contratto. Dopo ogni conio, il numero di coni del nuovo conio generato sarà pari al numero rimanente di coni diviso per due. Rappresentato con un diagramma:
Alla fine del gioco, il numero rimanente di tutti i Minter è 0.
Tornando all'immagine originale, oltre a Minter è uno smart contract, il Token generato è anche uno smart contract, ovvero CAT 20. CAT 20 ha due stati base: quantità e indirizzo del proprietario del token. Puoi vedere che a differenza del precedente BRC 20 o iscrizione, il tuo CAT 20 non si trova sull'UTXO del tuo indirizzo.
Trasferire
Durante il trasferimento, il numero di token di input e output nella transazione deve essere coerente. Naturalmente, possono esserci più token diversi nella stessa transazione, purché i numeri di input e output dei diversi token siano coerenti.
Bruciare
Se vuoi masterizzare il Token, devi solo trasferire il Token a un indirizzo normale.
Riassumere
Si può vedere che tutte le operazioni sono costruite dagli utenti stessi, il che è molto flessibile, quindi è necessario fare molta logica di verifica nella parte contrattuale. Alcune delle vulnerabilità finora esposte sono dovute anche a negligenza nella logica di verifica.
Un tale progetto può avere alcuni vantaggi:
Se desideri trovare lo stato di detenzione di tutti i token, devi solo controllare l'utxo del token e non è necessario continuare la ricerca.
Se vuoi verificare la situazione attuale del conio, puoi cercare le transazioni con cat in OP_RETURN.
ZAN è qui per avere l'acqua senza soglia!
Suggerimento: puoi ricevere un token testnet gratuito da 0,01 ETH ogni 24 ore per supportarti nell'esperienza e nel testare progetti Web3 nell'ecosistema Ethereum. Fai clic per riceverlo ora: https://zan.top/faucet?chInfo=ch_WZ
Presto saranno supportate altre catene pubbliche ~
Questo articolo è stato scritto da Yeezo (account X @GaoYeezo 75065) del team ZAN (account X @zan_team)