Introdução
Em 2024, a Solana emergiu de forma dramática, com seu Total Value Locked (TVL) saltando de um bilhão de dólares no início do ano para quase cinco bilhões de dólares, tornando-se a quarta maior blockchain pública.
Comparada ao Ethereum, a Solana oferece aos usuários uma experiência superior com maior velocidade e menor custo. 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 para análise de transações na Solana e tutoriais para escrever contratos inteligentes na Solana.
Como primeiro artigo desta série, este texto aprofundará os conceitos-chave da rede Solana, incluindo seus mecanismos de funcionamento, 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 geralmente 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 inteiramente novos, a Solana optou por aproveitar ao máximo as tecnologias avançadas existentes. A máquina virtual eBPF (extended Berkeley Packet Filter), inicialmente projetada para expandir as funcionalidades do kernel Linux, foi escolhida pela Solana para servir como seu ambiente de execução subjacente.
Então, que 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 possui 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. Como 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 de "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), 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 possui um "Proprietário". Por exemplo, o proprietário de todas as contas de "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 realiza 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 de "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 Contas
Na blockchain Solana, cada conta precisa manter um certo número de Lamports como saldo mínimo, conhecido como aluguel. Ao contrário do aluguel na vida real, o aluguel na Solana é recuperável. Para garantir que os dados de uma conta estejam disponíveis na cadeia, 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.
Como 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 Sim.
Você pode estar confuso porque 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 desta 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 verificar que ela está 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 de "carteira" delega as atualizações do programa ao BPF Loader. Antes de atualizar, o BPF Loader verifica se o delegante é 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 existe 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. Note 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 analisar 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, como 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 nenhuma conta que grave no mesmo estado.
O Recent Blockhash atua como um carimbo de data/hora para a transação. Se o blockhash de uma transação for 150 blocos mais antigo 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, como ilustrado abaixo.
O primeiro campo, Program ID Index, especifica o destinatário 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 conta, 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 por completo. 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 blockhash recente 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, dois Native Programs e contas Sysvar também foram incluídos.
Como é uma transação simples de criação de programa, ela contém apenas duas instruções. O destinatário da primeira instrução é o System Program, responsável por criar a conta do programa. O destinatário 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 favoritas.
