CAT20: Tokenprotocolo Fractal BTC

Este artigo é apenas para compartilhamento técnico e não constitui qualquer conselho de investimento.

BTC também terá seu próprio contrato inteligente?

Recentemente, no ecossistema BTC, o Fractal BTC, após passar por vários Testnets, finalmente foi lançado na Rede principal em setembro. Uma grande característica do Fractal é a capacidade de contratos inteligentes e praticamente ao mesmo tempo do lançamento na Rede principal, também foi lançado um novo protocolo de Token denominado CAT 20. Quais são os recursos técnicos inteligentes do CAT 20? O que podemos aprender com isso?

Fractal Bitcoin

Antes de entender o CAT 20, precisamos entender brevemente o Fractal Bitcoin, cuja relação é semelhante à do ERC 20 e ETH, o protocolo CAT 20 é implantado no Fractal Bitcoin.

Fractal Bitcoin, também conhecido como fractal BTC, é uma rede de "camada 2" totalmente compatível com BTC. Em comparação com o BTC, seu tempo de confirmação do Bloco é mais rápido, levando apenas 1 minuto. Seu princípio básico é simplesmente como seu nome sugere, ou seja, a rede BTC é copiada várias cópias, e cada cadeia processará transações, e quanto mais Nó puder processar transações, mais rápida será a velocidade. No entanto, os detalhes específicos, como a forma como as diferentes cadeias comunicam entre si, não são muito claros e não existe um documento técnico oficial a que se possa referir.

Se é apenas que as transações de camada 2 são mais rápidas, não parece haver um ponto empolgante. No entanto, habilitar o Código de operação OP_CAT, que foi preterido por razões de segurança há muito tempo, em Fractal, levou as capacidades de Bitcoin da Fractal a um novo nível, e alguns dizem que OP_CAT pode dar ao BTC a capacidade de contrair inteligente, para que haja mais espaço para devaneios.

Agora, alguém implementou um protocolo semelhante ao ERC 20 no Fractal Bitcoin.

Quanto ao porquê OP_CAT é preterido e por que ele pode ser usado no Fractal Bitcoin, podemos expandi-lo mais tarde, aqui seguimos CAT 20.

CAT Protocol O seguinte conteúdo refere-se ao White Paper: Introdução | CAT Protocol ()

E repositório GitHub: GitHub - CATProtocol/cat-token-box: Um monorepo para pacotes que implementam o protocolo CAT ()

Com o suporte subjacente do OP_CAT, em breve haverá um protocolo correspondente, o Protocolo CAT. Atualmente, um protocolo que já está em execução é o protocolo CAT 20, e também foi adicionado um painel correspondente no Unisat:

Ao ver o nome CAT 20, acredito que todos também consigam entender que ele é semelhante ao ERC 20. Em comparação com o protocolo ERC 20 estabelecido, é muito conveniente para todos implantar um Token. Como o CAT 20 implementa um ciclo de vida semelhante ao ERC 20?

Implementar

Antes da implementação, os usuários precisam especificar seu próprio Endereço da Carteira e as informações básicas do Token, as informações básicas do Token são semelhantes às do ERC 20:

Existem algumas diferenças. O CAT 20 pode definir a pré-extração e limites de quantidade a cada Mint. É claro que o ERC 20 também pode alcançar essas capacidades por meio da habilidade do contrato.

Durante a fase de implantação, serão realizadas duas transações, que podem ser consideradas como duas etapas: "commit" e "reveal". Citando o gráfico oficial, a fase de implantação é a seguinte:

Na fase de 'commit', as informações básicas do Token, como o nome e o símbolo, serão escritas no script de saída da transação. O hashId da transação iniciada na fase de 'commit' servirá como identificador desse Token, usado para distingui-lo de outros Tokens.

Pode-se ver que esta transação "bc 1 pucq...ashx" corresponde ao commit do utxo. As duas transações restantes apontam para "bc 1 pszp...rehc 4", sendo que a primeira é para pagar a taxa de gás da fase "reveal" e a segunda é o troco.

Na fase "reveal", podem ser vistos dois inputs de UTXO, correspondentes às duas saídas anteriores da fase de "commit". Essa transação primeiro irá gerar um OP_RETURN, no qual será armazenado o hash do estado inicial do CAT 20. Em seguida, será gerado um Minter, que desempenhará um papel importante no processo de Mint posterior, para manter as mudanças de estado do processo de Mint.

Ao olhar para todo o processo de implementação, os passos 'commit' e 'reveal' seguem os passos comuns de submissão e revelação na cadeia de blocos, sendo uma forma comum de implementar projetos em que alguns dados só são revelados na fase de 'reveal'.

Mint

Vamos dar uma olhada em como é a negociação quando se trata de Mint Token.

Na figura acima, podem ser observadas as seguintes características do processo de Mint.

• A entrada do mint é um minter, inicialmente gerado durante a implantação.
• Cada vez que é criada uma nova moeda (mint), apenas um minter é fornecido como entrada e pode haver qualquer número de minters como saída (há alguns problemas).
• Cada operação de minting produz apenas um token (com algumas exceções)
• A ordem de saída é exigida, minter deve ser seguido por TOKEN

Ao compreender o processo de Mint, na verdade, podemos descobrir algumas situações especiais que tornam todo o processo de Mint interessante.

Por exemplo, como resultado de uma transação de mint, o minter pode ser 1, vários ou até mesmo 0. Se for definido como 1 a cada vez que é minted, o número total de minters disponíveis na rede permanecerá inalterado (1). Isso tornaria o mint congestionado, pois todos precisariam competir por esse minter. Para evitar essa situação, é necessário definir a quantidade de minters produzidos a cada vez como maior que 1. Dessa forma, o número de minters disponíveis aumentará a cada mint realizado.

No entanto, cada saída adicional do minter significa que você precisa pagar uma saída adicional do utxo. Por razões econômicas, mais pessoas ficarão felizes em definir o minter como 0, o que inevitavelmente tornará o minter deflacionário, exigindo que alguém se dedique e pague o minter adicional.

Na versão V2, por padrão, são gerados dois Minter e o estado desses dois Minter será o mais próximo possível.

Construção de negociação

Talvez alguns companheiros tenham notado um problema, que é por que pode ser usado o utxo do minter para construir transações? Para entender esse problema, é necessário analisar o código-fonte do "contrato".

1、revelar utxo

Primeiro, analisamos o processo de revelação de transações e descobrimos que ele usou o commit de saída da transação anterior como entrada. Por que podemos usar uma saída utxo que não é nosso Endereço para construir a entrada da transação?

Seguindo a lógica comum, uma Chave privada corresponde a uma Chave pública, e a Chave pública deriva um Endereço. Ao verificar se uma saída de transação não gasta (utxo) é válida, geralmente é feito comparando se a descriptografia com a Chave pública usada para assinar é consistente com a transação original. Essa lógica é escrita no script BTC. Portanto, podemos habilmente reescrever a lógica do script, usando um par de Chaves privadas e públicas que correspondem ao nosso próprio Endereço, assim podemos controlar utxos de dois Endereços diferentes.

Ao olharmos o código fonte, conseguimos entender o que aconteceu:

Aqui surge outra questão, que é uma chave privada que corresponde a uma chave pública, então por que o endereço de commit gerado é diferente do nosso endereço? Isso pode ser visto no código-fonte aqui.

Em outras palavras, a nossa Chave privada será ajustada com base em uma CHAVE_PUBKEY para ajustar a Chave pública, esta é uma característica do Endereço P2TR.

2、minter utxo

Durante o processo de revelação, usamos entradas diferentes de utxo, mas na verdade a Chave Secreta de encriptação é a mesma, ou seja, a Chave privada do implantador. Mas na fase de criador, como é que todas as pessoas podem usar esses utxo como entradas?

Esta parte é o que eu suponho ser a capacidade mencionada anteriormente do OP_CAT, ou seja, a capacidade de contrato inteligente, onde cada minter é um contrato inteligente. No entanto, o código-fonte desta parte não foi divulgado até agora, portanto, ainda não se sabe como é a implementação específica.

Estado da negociação (V2)

No minter, o estado também é mantido. Este estado existe em dois lugares: um é no OP_RETURN da transação de saída e o outro é armazenado no contrato inteligente, que é o Minter e o Token mencionados acima.

O que é armazenado em OP_RETURN é o hash do estado de saída da transação atual, e os tempos de cunhagem restantes do token serão armazenados no contrato. Após cada casa da moeda, o número de casas da moeda para a casa da moeda recém-gerada será igual ao número de hortelãs restantes dividido por dois. Representado por um diagrama:

No final, o número restante de Minter é 0.

Voltando à imagem original, para além do Minter ser um contrato inteligente, o Token gerado também é um contrato inteligente, ou seja, CAT 20. CAT 20 tem dois estados básicos: a quantidade e o Endereço do detentor do Token. Ao contrário do BRC 20 ou da inscrição anteriores, o seu CAT 20 não está na sua UTXO Endereço.

Transfer

Ao transferir, os valores de entrada e saída de tokens na construção da transação precisam ser mantidos iguais. Claro, uma transação pode conter vários tokens diferentes, desde que a quantidade de entrada e saída de cada token permaneça consistente.

Queimar

Se quiser queimar o TOKEN, basta transferi-lo para um Endereço normal.

Resumo

Pode-se ver que todas as operações são construídas pelo próprio usuário, o que lhes confere uma grande flexibilidade, portanto, é necessário realizar muita lógica de verificação na parte do contrato. Alguns dos problemas de segurança que surgiram recentemente foram devido a falhas na lógica de verificação.

Este design pode ter algumas vantagens:

• Se você quiser verificar todas as informações de posse do Token, basta verificar o utxo do token, não é necessário continuar procurando acima.
• Se você quiser verificar a situação atual do mint, você pode pesquisar as transações em que os dados OP_RETURN contêm a palavra cat.

ZAN Sem restrições para receber água!

Dica: Você pode receber 0,01 ETH de token de testnet gratuito a cada 24 horas para apoiar sua experiência e teste de projetos Web3 na rede Ethereum. Clique aqui para receber imediatamente:

Mais cadeias públicas serão suportadas em breve~

Este artigo foi escrito por Yeezo (conta X @GaoYeezo 75065) da ZAN Team (conta X @zan_team).