Do escritório da Bitcoin à cozinha da Solana

A Bitcoin dispõe de uma linguagem de script — chamada Script — deliberadamente limitada. Não é Turing-completa, não permite ciclos e admite apenas operações elementares: verificar assinaturas, controlar timelocks ou configurar esquemas multisig. Esta simplicidade contribui para tornar o seu comportamento previsível e para reduzir a superfície de execução, ainda que a segurança da Bitcoin dependa de numerosos elementos do protocolo.

A Ethereum seguiu uma via diferente: introduziu a EVM (Ethereum Virtual Machine), um ambiente Turing-completo no qual podem ser executados smart contracts. Ao nível do protocolo, as transições de estado são tratadas segundo um modelo sequencial, ainda que as implementações possam paralelizar certas tarefas internas.

A Solana respondeu ao desafio da escalabilidade com uma arquitetura radicalmente diferente: a SVM (Solana Virtual Machine) e o runtime Sealevel.

O modelo de contas da Solana (e da SVM)

Na Ethereum, um smart contract «possui» o seu estado: os dados residem no próprio contrato. Na SVM, a conceção é desacoplada:

- O código reside numa conta de programa; a sua possibilidade de atualização depende do mecanismo de implementação e da autoridade configurada
- Os dados (o estado) residem em contas separadas, controladas pelo programa

Isto permite ao Sealevel analisar antecipadamente as transações: se a transação A afeta as contas {X, Y} e a transação B as contas {Z, W}, ambas podem ser executadas em paralelo sem conflito.

Este modelo permite executar em paralelo transações que não solicitam as mesmas contas. Pode aumentar a capacidade de processamento, mas não permite, por si só, deduzir uma vantagem quantitativa face à EVM com hardware equivalente. Não foi publicado qualquer teste de desempenho específico do Bitcoin Hyper.

O que isto implica para os programadores

Os programas destinados à SVM são escritos em Rust (ou em C/C++) e compilados em bytecode eBPF. Uma framework largamente utilizada é o Anchor, que acrescenta macros e convenções para facilitar o desenvolvimento.

A documentação do Bitcoin Hyper apresenta como objetivo uma compatibilidade imediata, ou «drop-in compatibility», com o ecossistema Solana. Segundo o projeto, um programa existente poderia funcionar com adaptações limitadas, tais como a alteração do endpoint RPC e de certos parâmetros de rede. A documentação prevê igualmente uma compatibilidade com ferramentas como a CLI da Solana, o Anchor e os plugins de IDE. O grau efetivo de compatibilidade resta verificar de forma independente.

Se este nível de compatibilidade fosse alcançado, poderia reduzir a barreira à entrada para os programadores familiarizados com a Solana. Contudo, a partilha de um ambiente assente na SVM não garante, por si só, a compatibilidade dos programas, das API, dos programas de sistema, das ferramentas ou dos comportamentos do runtime. Trata-se ainda de um objetivo de conceção e não de um resultado verificado de forma independente.

O que resta ainda esclarecer

Dito isto, vários pontos devem ser assinalados com transparência:

A compatibilidade completa não foi verificada de forma independente: a devnet é seletiva e os testes públicos são limitados
Diferenças no modelo de taxas: segundo a documentação do projeto, o Bitcoin Hyper utiliza $HYPER para as taxas em vez de SOL, pelo que certas abstrações diferem
Dependências dos programas de sistema da Solana: algumas aplicações Solana apoiam-se em programas de sistema (como o Token Program oficial) que poderão não estar disponíveis sob uma forma idêntica

A afirmação de uma compatibilidade «drop-in» resta verificar. A sua avaliação exige documentação técnica pública, um acesso suficiente à devnet e testes reproduzíveis relativos aos programas, às ferramentas e às dependências do sistema.

A analogia do franchising

Pode imaginar-se a SVM como a cozinha de um restaurante em regime de franchising. A receita representa o código e o estabelecimento representa a rede sobre a qual é executado. O Bitcoin Hyper pretende propor um equipamento compatível com o da Solana, mas ainda não foi demonstrado que todos os componentes sejam idênticos nem que o resultado seja o mesmo em todos os casos.

A diferença reside no ingrediente principal: em vez de SOL como «combustível» da cozinha, seria aqui utilizado $HYPER.

A Solana Virtual Machine explicada a quem só conhece a Bitcoin