Introdução
Em 2024, a Solana emergiu de forma dramática, com seu Total Value Locked (TVL) disparando de um bilhão de USD no início do ano para quase cinco bilhões de USD, tornando-se a quarta maior blockchain pública.
Em comparação com o Ethereum, a Solana oferece aos usuários uma experiência superior com maior velocidade e menores custos. O mecanismo de consenso baseado em Proof of History e o modelo de processamento assíncrono de transações oferecem aos desenvolvedores alto throughput de transações e baixa latência, tornando-a uma plataforma favorita para todos os tipos de aplicações descentralizadas.
A BlockSec planejou especialmente a série "Solana Simplificada", cobrindo conceitos básicos da Solana, guias práticos sobre análise de transações Solana e tutoriais sobre como escrever contratos inteligentes Solana.
Como primeiro artigo desta série, este texto aprofundará os conceitos-chave da rede Solana, incluindo seus mecanismos de operação, modelo de contas e transações, estabelecendo a base para escrever contratos inteligentes corretos e eficientes na Solana.
eBPF: A Pedra Angular da Execução de Transações na Solana
Para escrever e executar contratos inteligentes, as blockchains normalmente requerem uma linguagem de programação e um ambiente computacional Turing-completo.
Os contratos inteligentes no Ethereum são geralmente escritos em uma linguagem de alto nível chamada Solidity. O compilador os traduz em bytecode, que é então executado na Ethereum Virtual Machine (EVM). Em vez de desenvolver um ambiente virtual e uma linguagem totalmente novos, a Solana optou por utilizar plenamente as tecnologias avançadas existentes. A máquina virtual eBPF (extended Berkeley Packet Filter), inicialmente projetada para expandir as funcionalidades do kernel Linux, foi selecionada pela Solana para servir como seu ambiente de execução subjacente.
Então, quais vantagens o eBPF oferece em relação à EVM?
Ao contrário da EVM, que se limita à execução interpretada, o eBPF suporta compilação Just-In-Time (JIT), permitindo que ele traduza bytecode em instruções de máquina que o processador pode executar diretamente. Essa capacidade aumenta significativamente a eficiência do programa.
Além disso, o eBPF apresenta um conjunto de instruções eficiente e uma infraestrutura madura. Os desenvolvedores podem criar contratos inteligentes usando a linguagem Rust. Aproveitando o backend eBPF do framework de compilador LLVM, os programas Rust podem ser compilados diretamente em bytecode eBPF.
O Modelo de Contas da Solana
Estrutura de Contas da Solana
Os dados são armazenados na forma de contas na Solana. Conforme ilustrado abaixo, todos os dados dentro da Solana podem ser conceitualizados como um vasto banco de dados chave-valor. As chaves neste banco de dados são os endereços das contas. Para contas do tipo "carteira" (ou seja, contas diretamente controladas por usuários da Solana por meio de pares de chaves pública-privada), esses endereços são chaves públicas geradas usando o sistema de assinatura Ed25519. Os valores no banco de dados consistem em detalhes específicos de cada conta, incluindo o saldo e outras informações relevantes.
A Solana utiliza a seguinte estrutura conhecida como AccountInfo para descrever uma conta.
O AccountInfo de cada conta contém quatro campos. Aqui está uma explicação de cada um:
-
Campo
Data: Este campo armazena os dados relacionados à conta. Se a conta for um programa (ou seja, um contrato inteligente), ele armazena o bytecode eBPF. Caso contrário, o formato dos dados é geralmente definido pelo criador da conta. -
Campo
Executable: Este campo é usado para indicar se a conta é um programa. É importante notar que, ao contrário do Ethereum, os programas na Solana podem ser atualizados. -
Campo
Lamports: Este campo registra o saldo de tokens Solana na conta. Lamports são, na verdade, a menor unidade do Token SOL (1 SOL = 1 bilhão de Lamports). -
Campo
Owner: Este campo indica o proprietário da conta. Na Solana, toda conta tem um "Owner". Por exemplo, o proprietário de todas as contas do tipo "carteira" é o System Program, uma conta especial na rede Solana responsável por funções como a criação de contas. O proprietário da conta é o único que pode modificar os dados da conta e deduzir Lamports do saldo (porém qualquer pessoa pode aumentar os Lamports transferindo fundos para a conta).
Contas Predefinidas da Solana
A Solana possui um conjunto de programas executáveis predefinidos conhecidos como Native Programs, que são implantados em endereços fixos. À medida que a rede Solana é atualizada, esses programas predefinidos também podem ser atualizados. Eles funcionam como APIs e funções de biblioteca, oferecendo funcionalidades específicas dentro da rede Solana.
Dentro dos Native Programs, um com o qual os desenvolvedores frequentemente interagem é o System Program. O System Program fornece aos desenvolvedores um conjunto de instruções, cada uma das quais executa uma tarefa independente. Por exemplo, os desenvolvedores podem usar a instrução CreateAccount para criar novas contas, ou a instrução Transfer para transferir Lamports para outras contas.
Outro Native Program comum é o programa BPF Loader. Ele é o proprietário de todas as outras contas de programa e é responsável por implantar, atualizar e executar programas personalizados. Quando uma conta do tipo "carteira" precisa atualizar um programa que implantou, isso é feito delegando ao programa BPF Loader, já que apenas o proprietário de um programa tem autoridade direta para modificar dados.
Além dos Native Programs, a Solana também oferece um conjunto de contas conhecidas como Sysvars. Essas contas fornecem aos programas na Solana informações e variáveis globais relacionadas ao estado atual da rede Solana, como o relógio atual e o hash do bloco mais recente.
Aluguel de Conta
Na blockchain Solana, cada conta deve manter um determinado número de Lamports como saldo mínimo, conhecido como aluguel (rent). Ao contrário do aluguel na vida real, o aluguel na Solana pode ser recuperado. Para garantir que os dados em uma conta estejam disponíveis na chain, a conta deve manter uma quantidade adequada de Lamports. O valor do aluguel está relacionado ao tamanho dos dados ocupados pela conta.
Qualquer transação que tente reduzir o saldo da conta abaixo do valor do aluguel falhará, a menos que reduza o saldo exatamente a zero. Reduzir o saldo a zero indica que o aluguel da conta foi recuperado e, ao final da transação, a Solana limpará os dados da conta correspondente no processo de coleta de lixo.
🧐 Visualizando Contas Solana nos Exploradores Solana
Para entender melhor os conceitos mencionados acima, usamos o projeto "Hello World" da Solana para implantar uma conta de programa, que pode ser visualizada usando o explorador de blockchain da Solana, o Solscan.
Conforme mostrado na imagem acima, podemos primeiro ver que a conta foi rotulada como "Program". Uma parte dos Lamports foi deduzida do saldo do remetente como aluguel para esta conta, portanto o campo SOL Balance não está vazio. Além disso, como a conta que criamos é um programa, seu campo Executable está definido como Yes.
Você pode ficar confuso ao ver que o campo Executable Data armazena um endereço, em vez de um programa eBPF. Como mencionado anteriormente, a Solana permite atualizações de programas, e isso é implementado por meio de um padrão de "proxy". Como modificações diretas na conta do programa não são permitidas inicialmente, a Solana cria uma conta de dados separada para armazenar o programa eBPF, enquanto o campo Data na conta do programa armazena apenas o endereço dessa conta de dados.
Sempre que uma atualização do programa for necessária, apenas o campo Data da conta de dados precisa ser modificado. Usando o Solscan para visualizar a conta de dados, podemos encontrá-la marcada como "Program Executable Data Account", e seu campo Data armazena o programa real.
O campo Owner na seção "More Info" é o BPF Loader, consistente com o que foi mencionado anteriormente.
Alguém pode notar que o último campo de "Overview" é Upgrade Authority, que não está presente no AccountInfo. O que isso significa?
Como mencionado anteriormente, a conta do tipo "carteira" delega as atualizações do programa ao BPF Loader. Antes de atualizar, o BPF Loader verifica se o delegador é a conta que originalmente implantou o programa. Como o Owner da conta do programa já está definido como BPF Loader, não há espaço para armazenar essa informação. Assim, a Solana a coloca no campo Data da conta de dados. É por isso que há um campo Upgrade Authority em "Overview", e ele é na verdade o endereço da carteira que implantou o programa.
A imagem abaixo mostra o relacionamento entre a conta do programa e a conta de dados. Observe que o campo Data da conta de dados consiste tanto no endereço da carteira quanto no código eBPF.
Transações e Instruções na Solana
Na Solana, os usuários executam programas emitindo transações. Um aspecto único da Solana é sua capacidade de executar essas transações em paralelo, o que é uma razão fundamental por trás de suas velocidades de transação extremamente rápidas. Agora vamos examinar mais de perto como as transações são projetadas na Solana.
Uma transação Solana consiste em assinaturas e uma mensagem. Uma transação pode incluir múltiplas assinaturas. A mensagem de uma transação é composta por quatro partes, conforme ilustrado abaixo.
O Header e o Compact Array of Account Addresses especificam todas as contas envolvidas em uma transação e suas características durante a transação, incluindo se a conta é um signatário e se é gravável durante a execução. Com essas informações, a Solana pode verificar as assinaturas fornecidas pelas contas signatárias e processar transações em paralelo, desde que essas transações não incluam contas que escrevam no mesmo estado.
O Recent Blockhash atua como um timestamp para a transação. Se o blockhash de uma transação for 150 blocos mais antigo do que o blockhash mais recente, ele é considerado expirado e não será executado.
O Compact Array of Instructions é a parte mais importante da transação, contendo uma ou mais instruções. Uma instrução essencialmente aciona a execução de uma rotina fornecida por uma conta de programa. Cada instrução consiste em três campos, conforme ilustrado abaixo.
O primeiro campo, Program ID Index, especifica o receptor da instrução, que é o programa on-chain que precisa processar a instrução. Em vez de armazenar um endereço de 32 bytes, esse endereço é colocado dentro do Compact Array of Account Addresses da mensagem da transação, e o campo armazena apenas um índice u8 apontando para o endereço no array.
Semelhante ao primeiro campo, o segundo campo armazena índices de endereços de contas, conhecidos como Compact Array of Account Address Indexes. Esse array especifica todas as contas envolvidas nesta instrução.
O último campo é um array de bytes contendo os dados adicionais necessários para o programa processar a instrução, como argumentos de função.
É importante notar que a Solana processa todas as instruções dentro de uma transação em ordem e garante a execução atômica da transação. Isso significa que ela é concluída completamente com todas as instruções processadas com sucesso, ou falha completamente. Não haverá uma situação em que algumas instruções sejam processadas e outras não.
🧐 Visualizando Transações Solana nos Exploradores Solana
Usamos outro explorador Solana para visualizar a transação que criou a conta de programa anteriormente. Na seção Overview, você pode ver a assinatura da transação Solana, o recent blockhash e outras informações:
Na seção Account Input, todas as contas envolvidas na transação atual são listadas, juntamente com suas características na transação. Podemos ver que, além dos endereços do remetente e da conta do programa, duas contas Native Programs e Sysvar também foram incluídas.
Por ser uma transação simples de criação de programa, ela contém apenas duas instruções. O receptor da primeira instrução é o System Program, responsável pela criação da conta do programa. O receptor da segunda instrução é o BPF Loader, que cria uma conta de dados para armazenar o código eBPF implantado e escreve seu endereço no campo Data da conta do programa.
Conclusão
Os contratos inteligentes na Solana são desenvolvidos em Rust e executados na máquina virtual eBPF. A Solana segue o modelo de contas, onde as contas on-chain precisam manter aluguel suficiente para evitar que os dados sejam removidos. Uma transação consiste em uma ou mais instruções que definem todas as contas necessárias, permitindo o processamento paralelo e aumentando o throughput enquanto reduz a latência de resposta. Essas características juntas contribuíram para o rápido desenvolvimento da Solana, tornando-a uma das blockchains preferidas.
