Domine os Conceitos Básicos da Solana

Em apenas 10 minutos, entenda o mecanismo de operação, o modelo de contas e as transações da Solana, e descubra os motivos por trás de seu crescimento explosivo. (Ainda com grande potencial de valorização)

Em 2024, a Solana surgiu de forma dramática, com seu valor total bloqueado (TVL) aumentando 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 custos menores. O mecanismo de consenso baseado no “Proof of History” e o modelo de processamento assíncrono de transações oferecem aos desenvolvedores alta capacidade de transações e baixa latência, tornando-a uma plataforma preferida para vários tipos de aplicativos descentralizados.

Como o primeiro artigo desta série, este texto mergulha nos conceitos-chave dentro da rede Solana, incluindo seus mecanismos de operação, modelo de contas e transações, preparando o terreno para escrever contratos inteligentes corretos e eficientes na Solana.

eBPF: O Alicerce da Execução de Transações na Solana

Para escrever e executar contratos inteligentes, blockchains geralmente exigem uma linguagem de programação e um ambiente computacional completo.

Os contratos inteligentes no Ethereum são normalmente escritos em uma linguagem de alto nível chamada Solidity. O compilador os traduz em bytecode, que é executado na Máquina Virtual Ethereum (EVM). Em vez de desenvolver um ambiente virtual totalmente novo, a Solana optou por utilizar plenamente 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 como seu ambiente de execução subjacente.

Então, quais são as vantagens do eBPF sobre o EVM?

Diferente do EVM, que é limitado à 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 do compilador LLVM, os programas Rust podem ser diretamente compilados em bytecode eBPF.

Modelo de Contas da Solana

Os dados são armazenados na forma de contas na Solana.
Como ilustrado abaixo, todos os dados na Solana podem ser conceituados como um vasto banco de dados chave-valor. As chaves neste banco de dados são os endereços das contas. Para contas “carteira” (ou seja, contas controladas diretamente pelos usuários da Solana através de pares de chaves pública e 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 de Dados: 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 Executável: Este campo é usado para indicar se a conta é um programa. É importante notar que, ao contrário do Ethereum, 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 Proprietário: Este campo indica o proprietário da conta. Na Solana, toda conta tem um “Proprietário”. Por exemplo, o proprietário de todas as contas “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 (no entanto, 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 Programas Nativos, que são implantados em endereços fixos. À medida que a rede Solana é atualizada, esses programas predefinidos também podem ser atualizados. Eles servem como APIs e funções de biblioteca, oferecendo funcionalidades específicas dentro da rede Solana.

Dentro dos Programas Nativos, 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 Programa Nativo 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 “carteira” precisa atualizar um programa que implantou, isso é feito delegando ao programa BPF Loader, uma vez que apenas o proprietário de um programa tem autoridade direta para modificar dados.

Além dos Programas Nativos, 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 de bloco mais recente.

Aluguel de Contas

Na blockchain Solana, cada conta deve 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 em uma conta estejam disponíveis na cadeia, a conta deve manter uma quantidade adequada de Lamports. A quantidade de aluguel está relacionada 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 no final da transação, a Solana limpará os dados correspondentes da conta no processo de coleta de lixo.

Visualizando Contas no SolScan

Para entender melhor os conceitos mencionados, 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 ver primeiro que a conta foi rotulada como “Programa”. Uma parte dos Lamports foi deduzida do saldo do remetente como aluguel para esta conta, por isso o campo Saldo SOL não está vazio. Além disso, como a conta que criamos é um programa, seu campo Executável está definido como Sim. Você pode se confundir que o campo de Dados Executáveis armazena um endereço, em vez de um programa eBPF. Como mencionado anteriormente, a Solana permite atualizações de programas, e isso é implementado através de um padrão “proxy”. Como modificações diretas na conta de programa não são permitidas inicialmente, a Solana cria uma conta de dados separada para armazenar o programa eBPF, enquanto o campo de Dados na conta do programa armazena apenas o endereço dessa conta de dados.

Sempre que uma atualização do programa é necessária, apenas o campo de Dados da conta de dados precisa ser modificado. Usando o Solscan para visualizar a conta de dados, podemos ver que ela está marcada como “Conta de Dados Executáveis do Programa” e seu campo de Dados armazena o programa real.

O campo Proprietário na seção “Mais Informações” é o BPF Loader, consistente com o que foi mencionado anteriormente.

Você pode notar que o último campo de “Visão Geral” é Autoridade de Atualização, que não está presente no AccountInfo. O que isso significa?

Como mencionado anteriormente, a conta “carteira” delega as atualizações de programa ao BPF Loader. Antes de atualizar, o BPF Loader verifica se o delegador é a conta que originalmente implantou o programa. Como o Proprietário da conta do programa já está definido como BPF Loader, ele não tem espaço para armazenar essas informações. Assim, a Solana coloca isso no campo de Dados da conta de dados. É por isso que há um campo Autoridade de Atualização em “Visão Geral”, e na verdade é o endereço da carteira que implantou o programa. A imagem abaixo mostra a relação entre a conta do programa e a conta de dados. Observe que o campo de Dados 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 é um motivo chave por trás de sua velocidade de transação extremamente rápida. Agora, vamos dar uma olhada mais de perto em como as transações são projetadas na Solana.

Uma transação da Solana consiste em assinaturas e uma mensagem. Uma transação pode incluir várias assinaturas. A mensagem de uma transação é composta por quatro partes, como ilustrado abaixo.

O Cabeçalho e o Array Compacto de Endereços de Contas 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 ela pode ser escrita 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 Blockhash Recente atua como um timestamp para a transação. Se o blockhash de uma transação for 150 blocos mais antigo que o último blockhash, ele é considerado expirado e não será executado.

O Array Compacto de Instruções é 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, Índice de ID do Programa, 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 Array Compacto de Endereços de Contas 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ço de contas, conhecidos como Array Compacto de Índices de Endereço de Contas. Este array especifica todas as contas envolvidas nesta instrução.

O último campo é um array de bytes contendo os dados adicionais necessários pelo programa para processar a instrução, como argumentos de função.

É importante notar que a Solana processa todas as instruções dentro de uma transação na ordem e garante a execução atômica da transação. Isso significa que ela ou completa totalmente 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 no SolScan

Usamos outro explorador da Solana para visualizar a transação que criou a conta do programa anteriormente. Na seção “Visão Geral”, você pode ver a assinatura da transação Solana, o blockhash recente e outras informações:

Na seção “Entrada de Contas”, 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 da conta do remetente e do programa, duas contas de Programas Nativos e Sysvar também foram incluídas.

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 de Dados da conta do programa.

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 saldo 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 a capacidade de transações, 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.

Ficou com alguma dúvida?
Participe do nosso grupo no WhatsApp e tire suas dúvidas diretamente conosco! Clique aqui para entrar.