CashTokens: os tokens nativos chegam ao Bitcoin Cash

Introdução e antecedentes

No final de 2008, a ideia do Bitcoin foi apresentada como “um sistema de dinheiro eletrônico peer-to-peer”; de fato, Satoshi Nakamoto intitula o documento técnico que fundamentou esse protocolo com essa frase. Nas palavras do próprio Satoshi, o dinheiro eletrônico implica pagamentos diretos entre pessoas “sem ter que passar por uma instituição financeira”, premissa que serviu de fundamento para o Bitcoin-BTC até 2017, ano em que os defensores do “Bitcoin como dinheiro em espécie” tiveram que migrar para uma rede separada chamada Bitcoin Cash (BCH) --“Bitcoin em espécie” em inglês–. Assim, o conceito de dinheiro digital é o ponto de partida de toda a tecnologia do Bitcoin, especialmente no caso do BCH, que reivindica essa qualidade como inegociável.

Esta qualidade não é incompatível com a incorporação de outros casos de uso, desde que a sua integração não coloque em risco a capacidade de usar BCH como dinheiro, ou de escalar seu sistema para que cada vez mais pessoas possam adotá-lo como tal.

Nesse sentido, o Bitcoin Cash (BCH) possui um processo para apresentar, debater e padronizar ideias chamado “CHIP” (siglas de: propostas de melhorias do dinheiro) que, de forma semelhante aos “BIP” ou “propostas de melhoria do Bitcoin” do Bitcoin-BTC, permite à comunidade discutir e avaliar a adequação de ideias a serem desenvolvidas para adicionar novas funções às aplicações, e até mesmo ao protocolo sobre o qual a moeda opera.

Uma das funções que durante anos tem sido perseguida é a possibilidade de transferir outros ativos através da blockchain do Bitcoin Cash. Ativos que no mundo das criptomoedas costumam ser denominados “tokens” ou “fichas”, muito populares em muitos ecossistemas cripto, que trazem atividade econômica extra às redes sobre as quais correm, e que, acompanhados de funções como a capacidade de implementar contratos inteligentes, podem ser trocados em exchanges descentralizados ou usados em plataformas DeFi.

Quando o BCH acabou de se independizar do BTC, houve várias propostas para incorporar tokens baseadas no conceito de “moedas coloridas”, que se refere a transações ( o envio de uma quantidade muito pequena de Bitcoin Cash, por exemplo ) que contêm metadados para transferir um token. Ditando de outra forma, consiste em utilizar as transações de BCH como veículo para outros ativos, requerendo um protocolo que possa interpretar esses metadados anexados como um token, a quantidade transferida, etc.

Esta ideia foi implementada na rede de Bitcoin Cash (BCH) através de vários protocolos, sendo o mais conhecido e duradouro o “Simple Ledger Protocol” ou “tokens SLP”.

No entanto, o modelo das “moedas coloridas” tem certas limitações, como a necessidade de executar software adicional para validar as informações que contêm, bem como esperar pelo menos 1 confirmação para considerar essas transações válidas. Devido a essas fraquezas, as “moedas coloridas” representam uma alternativa viável para enviar e receber tokens, mas sem igualar as qualidades dos pagamentos com a moeda base.

Novo padrão: um modelo melhor

No dia 15 de maio de 2023, o Bitcoin Cash (BCH) irá incorporar, através de uma atualização, entre outras novas funções, a capacidade de transferir tokens sem as limitações que impõem os protocolos de “moedas coloridas”. Esta nova função, à qual foi atribuído o identificador “CHIP-2022-02”, é chamada de “CashTokens: primitivas de tokens para Bitcoin Cash”. Em termos simples, CashTokens representa uma solução superior em comparação com o “Simple Ledger Protocol” dos tokens SLP, diferenciando-se entre outras coisas pelas seguintes características:

• A infraestrutura com suporte a “tokens SLP” exigia a execução de “nodos SLP”, ou seja, software adicional para validar as transações desse tipo a partir dos metadados incluídos nas mesmas. No caso dos CashTokens, seu suporte requer apenas um nó de Bitcoin Cash, portanto, o minerador e os operadores de nós completos podem atestar sua validade.
• As transações de tokens SLP não são compatíveis com 0-conf, portanto pode ser arriscado aceitar transações sem esperar a primeira confirmação. As transações com CashTokens são compatíveis com 0-conf, por isso é razoável considerar transações sem confirmações inferiores a 200$ como válidas.
• Embora a rede do Bitcoin Cash se baseie no modelo “UTXO”, as transações de tokens SLP são verificadas através do modelo “DAG”. As transações de CashTokens são baseadas no modelo UTXO, o que implica uma maior eficiência na validação das transações deste padrão.

Estas vantagens, entre muitas outras, permitem que os CashTokens proporcionem uma melhor experiência de utilizador, e diminuem a fricção de expandir a compatibilidade de carteiras auto-custodiais e plataformas de comércio com o envio e armazenamento de tokens. Por outro lado, as transações com CashTokens pagam taxas aos mineiros denominadas em Bitcoin Cash, pelo que a popularização eventual contribuirá para a manutenção do sistema.

CashTokens: primitivas de tokens

Na especificação técnica de CashTokens consta a expressão “Token Primitives for Bitcoin Cash” como nome formal. Esta expressão pode ser um pouco confusa para um público de língua portuguesa, dado que pode-se pensar (erroneamente) que se refere a algo “primitivo”, pouco sofisticado ou limitado na sua compatibilidade com DeFi.

No entanto, os CashTokens não são apenas compatíveis com contratos inteligentes escritos na linguagem de scripting do Bitcoin Cash, mas o termo não busca evocar simplicidade. A expressão “primitivas” neste contexto refere-se a uma função fundamental de um protocolo; uma função nativa do protocolo, pelo que uma tradução do conceito muito mais clara poderia ser “Tokens nativos para Bitcoin Cash”.

Atualização: originalmente o artigo indicava que os CashTokens (, ao contrário dos tokens SLP), não requeriam o uso de dois formatos de endereços. Foi feita uma correção devido ao fato de que os tokens nativos de Bitcoin Cash (BCH) permitem o uso de endereços <<token aware=“”>> (conscientes de tokens) que podem receber tanto BCH quanto CashTokens, e endereços em formato normal, que apenas recebem BCH. O uso de dois formatos tem o objetivo de evitar que os usuários enviem tokens para carteiras que não refletem esse tipo de ativo. Por outro lado, foi corrigida a tradução de <<token primitives=“”>> como <<tokens primitivos=“”>>. A tradução correta é <<primitivas de=“” token=“”>>, ou alternativamente, para transmitir a mesma ideia, <<tokens nativos=“”>>.</tokens></primitivas></tokens></token></token>