Resolvendo o problema de gás do Bitcoin (sem um fork) | Opinião

Cada plataforma de contratos inteligentes tem um ativo de taxa incorporado. Por exemplo, Ethereum (ETH) tem ETH, Solana (SOL) tem SOL, mas com Bitcoin (BTC), no entanto, as coisas complicam-se. Se deseja aplicações expressivas, geralmente acaba por adotar a economia de uma segunda rede.

Resumo

• Bitcoin não precifica computação, apenas espaço de bloco. Ao contrário do Ethereum ou Solana, o mercado de taxas do BTC é baseado em sat/vB para inclusão de transações, não na medição da execução de contratos inteligentes.
• A execução pode ocorrer off-chain enquanto a liquidação permanece no Bitcoin. Sistemas como o OpNet executam lógica de contrato numa VM Wasm, enquanto ancoram pagamentos e alterações de estado final através de transações normais de BTC.
• O BTC pode funcionar como ativo de gás sem um novo token. Ao precificar custos de execução em satoshis e liquidar interações através de transações Bitcoin, as aplicações evitam criar uma segunda economia de taxas.

Por exemplo, no Stacks, paga-se taxas em STX. Em camadas de Bitcoin estilo EVM, pode-se dizer que o BTC é o token de gás, mas geralmente é uma representação nativa de uma camada L2 com convenções semelhantes às do EVM (incluindo 18 casas decimais), e ainda assim opera-se dentro desse ambiente L2. O próprio Bitcoin já possui um mercado de taxas limpo, onde os utilizadores fazem lances por espaço de bloco em sat/vB, e os mineiros priorizam taxas mais altas.

Com isto em mente, e se uma interação de contrato inteligente pudesse ser iniciada e paga como uma transação normal de Bitcoin, com taxas em termos de BTC (sem um token de gás extra ou fork), enquanto a parte inteligente roda noutro lugar e permanece provavelmente ligada ao Bitcoin? O OpNet pretende oferecer uma resposta.

Bitcoin não mede computação (isso é um problema)

O mercado de taxas do Bitcoin é excelente numa coisa: precificar espaço de bloco. Você compete em sat/vB, os mineiros escolhem as taxas mais altas, e a rede mantém-se simples e robusta contra ataques. O que o Bitcoin não faz é executar um ambiente de execução de uso geral onde a cadeia possa medir e cobrar por computação arbitrária. O Bitcoin Script é deliberadamente sem estado e não Turing-completo, especificamente sem loops ou goto, para que cada nó possa validar scripts de forma previsível sem abrir a porta a computação ilimitada.

Por isso, a maioria das abordagens de contratos inteligentes no Bitcoin acaba por colocar a execução numa camada separada que pode medir computação e ter a sua própria economia de taxas. Uma vez que essa camada de execução separada existe, ela geralmente vem com um ativo de taxa separado (como o Stacks, que cobra taxas em STX).

Isto não é ideal, e um sistema onde se pudesse manter o pagamento na economia de taxas nativa do Bitcoin enquanto a execução ocorre noutro lado seria preferível.

A execução não é o que o Bitcoin precisa fazer

Depois de aceitar que o Bitcoin Script é intencionalmente limitado (sem estado e não projetado para computação ilimitada), começa-se a pensar em como fazer o Bitcoin liquidar os resultados e os pagamentos.

De fato, a execução pode acontecer numa máquina virtual dedicada, construída para rodar lógica de contratos inteligentes de forma determinística, enquanto o Bitcoin permanece como a camada base que carimba, ordena e precifica as interações através do seu mercado de taxas existente. No design do OpNet, a lógica do contrato é avaliada por uma VM orientada a Wasm (OP-VM), enquanto a pilha de nós mais ampla é explicitamente construída para gerir e executar contratos inteligentes usando a mecânica de transações e UTXO do Bitcoin.

Crucialmente, isto não vem acompanhado de um novo ativo de taxa. O Bitcoin não precisa medir computação para ser a moeda de gás. Precisa ser a camada de liquidação final onde tudo paga e que serve de âncora.

Como é uma chamada de contrato paga em BTC

O nosso modelo de interação segue um fluxo de simulação-antes-de-gastar, em vez de um padrão convencional de execução de contrato inteligente, com o passo final de execução a acontecer como uma transação real de Bitcoin. Primeiro, a sua aplicação chama um método de contrato em modo de simulação. Essa solicitação passa por um provedor até um nó OPNet, que executa o contrato na sua VM e devolve um CallResult (incluindo estimativas de gás/taxas) sem transmitir nada para o Bitcoin.

Se a chamada alterar o estado, você usa esse CallResult para fazer a execução. Nesse momento, a biblioteca constrói uma transação de Bitcoin, assina-a e transmite-a à rede Bitcoin. Dois pontos importantes:

• As taxas dos mineiros são nativas do Bitcoin. Você escolhe uma taxa de feeRate em sat/vB, opcionalmente adiciona uma fee de prioridade em sats, e define um limite máximo de gastos de taxa via maximumAllowedSatToSpend (o parâmetro tem esse nome literalmente).
• O destino do contrato é expresso como um endereço de contrato no estilo P2OP. A instância do contrato expõe o seu formato de endereço p2op, e as transações referenciam um “endereço de contrato p2op” como destino do contrato.

Entretanto, a medição de computação própria do OpNet ainda existe. Mas é precificada em satoshis (estimativa de GAS em SATS, reembolsos em SATS, etc.), de modo que a unidade nunca se desvia para uma economia de tokens separada.

Menos atrito, incentivos mais claros

Os utilizadores já não precisam de adotar uma segunda economia de taxas só para interagir com aplicações. No Bitcoin, as taxas já funcionam como uma espécie de leilão por espaço de bloco, precificado por byte e pago aos mineiros. Quando as chamadas de contrato são apenas transações de Bitcoin, está-se de volta a um terreno familiar (com taxas em sat/vB, movimentação na mempool e incentivos aos mineiros), sem precisar aprender um mercado separado de tokens de gás.

Além disso, as ferramentas aproveitam fluxos de trabalho padrão do Bitcoin, como o manuseio de UTXO, conexões com provedores e até assinaturas offline/cold. Os contratos vivem numa runtime Wasm e são escritos em AssemblyScript, visando uma expressividade semelhante à do Solidity, sem que o Bitcoin Script se transforme numa VM de repente.

Bitcoin como gás, sem um segundo token

A afirmação de que o BTC não pode funcionar como gás geralmente baseia-se na suposição de que a camada base deve medir computação para precificá-la. O Bitcoin não mede computação; mede espaço de bloco e liquida valor.

A solução é deixar uma máquina virtual tratar a execução de forma determinística, e depois encaminhar toda interação que altera o estado através de uma transação padrão de Bitcoin, onde as taxas são expressas em termos familiares como sat/vB e limitadas em satoshis. No nosso caso, isto é implementado ao nível do cliente através de parâmetros como feeRate e maximumAllowedSatToSpend.

Assim, talvez o BTC como gás seja realmente plausível. As taxas permanecem nativas do BTC de ponta a ponta, enquanto o runtime do contrato permanece baseado em WebAssembly (AssemblyScript → Wasm), mantendo a lógica expressiva sem alterar a moeda de taxas.

Frederic Fosco

Frederic Fosco, também conhecido como Danny Plainview, é cofundador do OP_NET e está envolvido com Bitcoin desde 2013. Lançou o OP_NET para tornar o Bitcoin nativamente programável, desbloqueando contratos inteligentes e primitives DeFi diretamente na camada 1. O seu foco é construir funcionalidades reais na cadeia, sem pontes, custodians, wrapping ou Bitcoin sintético, mantendo a autossoberania e descentralização como prioridades.