Modelo de Conta Solana Explicado

O Modelo de Conta Solana armazena saldos, código de programa, posses de tokens e estado da aplicação em contas separadas com regras de propriedade explícitas. Este guia em linguagem simples explica o modelo para leitores gerais antes de abordar campos, tipos de conta, isenção de taxa de aluguel e exemplos do mundo real.

Detalhes de implementação, como tratamento de taxa de aluguel, limites de tamanho de conta e APIs de cliente, podem mudar. Desenvolvedores devem verificar a documentação atual da Solana e consultar os parâmetros atuais da rede antes de implantar.

Se você vem do Ethereum, o modelo de conta da Solana parecerá invertido no início. Essa reação é o ponto de partida correto. O modelo mental que você construiu no Ethereum não se transfere de forma limpa, e tentar forçá-lo cria confusão em cada etapa.

O modelo de conta Solana é o sistema arquitetônico pelo qual todo o estado na blockchain é armazenado em unidades discretas de armazenamento chamadas contas. Todo saldo de carteira, programa, posse de token e registro de estado de aplicação vive em uma conta separada com um owner definido, um saldo de lamport e regras explícitas que regem quem pode ler ou escrever nele. Nada existe na Solana fora de uma conta.

Pense na Solana como um sistema global de arquivamento. Cada pedaço de dado vive em um arquivo separado chamado conta. Programas são as aplicações que leem e escrevem nesses arquivos, mas um programa só pode modificar um arquivo que ele possui. O runtime impõe essas regras de propriedade no nível do protocolo, sem exceções.

Este artigo abrange os cinco campos dentro de cada conta Solana, os cinco tipos de conta distintos, como funcionam a taxa de aluguel (rent) e a isenção de taxa de aluguel, o que são Endereços Derivados de Programa (PDAs) e por que existem, como as contas são criadas e fechadas, e por que essa arquitetura possibilita o processamento paralelo de transações da Solana. Os programas Solana são escritos em Rust (ou C/C++), embora frameworks como Anchor abstraiam muito do código repetitivo de gerenciamento de contas. Este artigo abrange a base conceitual que ambos exigem.

Modelo de Conta Solana: Anatomia de uma Conta

Uma conta Solana é um espaço de armazenamento rotulado na rede que contém um saldo em lamports, uma carga de dados arbitrária e um conjunto de campos de metadados que definem quem a possui e o que ela pode fazer. Na Solana, todos os dados, desde saldos de carteira até estado de programa e posses de tokens, são armazenados em contas.

Lamports são a menor denominação de SOL, o token nativo da rede. Lamports são para SOL o que centavos são para um dólar, exceto com nove casas decimais de precisão: 1 SOL é igual a 1.000.000.000 lamports. Cada conta carrega um saldo de lamports que financia a existência contínua da conta na rede e representa valor transferível.

Cada conta Solana contém exatamente cinco campos:

• lamports (u64): O saldo da conta em lamports. Este campo financia a taxa de aluguel e pode ser transferido para outras contas.
• data (array de bytes): Armazenamento bruto binário. Em contas executáveis, este campo contém bytecode BPF/SBF compilado. Em contas de dados, ele contém estado estruturado da aplicação. O tamanho máximo do campo de dados é de 10 MB nos parâmetros atuais da Mainnet.
• owner (Pubkey): A chave pública de 32 bytes do programa que tem autoridade exclusiva de gravação sobre o campo de dados desta conta. Este é o campo mais contraintuitivo para desenvolvedores Ethereum. Seu endereço de carteira não é de sua propriedade no nível do protocolo; ele pertence ao System Program. O tratamento completo do campo owner aparece na seção de propriedade e autoridade de contas.
• executable (bool): Um indicador booleano. Quando verdadeiro, o campo de dados contém bytecode do programa e a conta funciona como um programa. Quando falso, a conta armazena estado ou contém um saldo.
• rent_epoch (u64): Um campo legado que rastreava a época em que a taxa de aluguel foi coletada pela última vez. A partir de 2024, a coleta de taxa de aluguel foi depreciada em favor do modelo de isenção de taxa de aluguel por padrão. Este campo persiste na struct da conta, mas não é mais ativamente usado.

Veja como uma conta de carteira se parece como uma estrutura de dados:

{
  "lamports": 1000000000,
  "data": [],
  "owner": "11111111111111111111111111111111",
  "executable": false,
  "rent_epoch": 0
}

O campo owner é um conceito de nível de protocolo: o programa que controla o acesso de gravação ao campo de dados. Autoridade é uma convenção separada armazenada dentro de dados gerenciados por programa, como o campo de autoridade de transferência dentro de uma conta de token. Estas não são a mesma coisa; a seção de propriedade traça essa distinção precisamente.

Os Cinco Tipos de Contas Solana

A Solana tem cinco tipos de conta distintos, cada um servindo uma função arquitetônica específica determinada por seu campo owner e seu indicador executable. O tipo não é armazenado como um campo separado; é inferido de quem possui a conta e se ela contém código executável.

Contas de Propriedade do Sistema (Contas de Carteira)

Uma conta de propriedade do sistema contém o saldo SOL de um usuário e nada mais. O owner é sempre o System Program (11111111111111111111111111111111), o indicador executable é false, e o campo data está vazio. Quando você compartilha seu endereço de carteira com Phantom ou Solflare, você está compartilhando o endereço de uma conta de propriedade do sistema. Você a controla assinando transações com sua chave privada, mas o System Program é o owner no nível do protocolo.

Contas de Programa (Contas Executáveis)

Uma conta de programa é uma conta executável contendo bytecode BPF/SBF compilado. O indicador executable é true, e o owner é o BPF Loader. Contas de programa são stateless por design; elas contêm apenas código, nunca estado. Na Ethereum, um Smart Contract armazena tanto seu código quanto seu estado em um único endereço de contrato. Na Solana, o código vive em uma conta de programa e o estado vive em contas de dados separadas, sempre armazenadas separadamente.

Contas de programa podem armazenar código executável, com executable = true e bytecode BPF/SBF no campo data. Contas de dados não executáveis têm executable = false e armazenam estado em vez disso.

Contas de Dados (Contas de Propriedade de Programa)

Uma conta de dados é uma conta não executável pertencente a um programa específico que armazena o estado do programa em seu campo data. O indicador executable é false. O owner é o programa que criou e gerencia a conta. Seu saldo de token USDC, uma DeFi posição de empréstimo, um registro de metadados NFT: cada um vive em sua própria conta de dados dedicada, pertencente ao programa relevante.

Contas de Programa Nativas

Contas de programa nativas são programas embutidos implantados em endereços fixos durante a gênese da rede. Eles incluem o System Program, o BPF Loader, o Vote Program e o Stake Program. Estes são programas de infraestrutura central que não podem ser substituídos ou atualizados por usuários. Seu indicador executable é true.

Contas Sysvar

Contas Sysvar são contas somente leitura pré-populadas pelo runtime Solana que dão aos programas acesso ao estado atual da rede. Pense nas contas sysvar como um quadro de avisos do governo em um fórum: legível publicamente, mantido por uma fonte autoritativa, mas nenhuma parte privada pode modificá-las. O sysvar Clock em SysvarC1ock11111111111111111111111111111111 fornece o timestamp e o número do slot do bloco atual. O sysvar Rent fornece os parâmetros de taxa de aluguel atuais.

Os programas são stateless (sem estado) na Solana. Todo o estado reside nas contas de dados que eles possuem e controlam. Essa separação entre lógica e estado é a decisão de design que torna possível tudo o mais neste artigo.

Programas vs. Contas de Dados: A Separação de Lógica e Estado

Os programas da Solana são stateless. Eles não possuem dados próprios, e cada parte do estado em que operam vive em contas de dados separadas, passadas ao programa no momento da execução.

Pense em um programa da Solana como o software de processamento de transações de um banco, e nas contas de dados como os registros de conta de clientes individuais. O software sabe como processar depósitos e retiradas, mas o saldo real vive no arquivo do cliente, não dentro do próprio software. No Ethereum, o equivalente é um banco onde o software e o registro de cada cliente compartilham a mesma sala trancada, com o programa e seu estado inseparáveis em um único endereço.

Quatro propriedades definem como os programas da Solana interagem com as contas:

• Os programas processam instruções e leem ou escrevem em contas passadas a eles no momento da chamada. Eles não mantêm seu próprio estado.
• Os programas são imutáveis uma vez implantados, a menos que o desenvolvedor tenha escolhido o loader atualizável no momento da implantação.
• Apenas o programa proprietário de uma conta de dados pode modificar o campo de dados dessa conta. Qualquer usuário pode chamar um programa, mas o acesso de gravação a qualquer conta é controlado pela propriedade (ownership).
• A flag executable reforça essa distinção no nível do protocolo e não pode ser alterada após a implantação.

Os programas da Solana são stateless, mas o sistema Solana como um todo é stateful (com estado). O estado persiste; ele vive em contas de dados. A distinção é que o estado é sempre externo ao programa, nunca empacotado dentro dele.

Essa separação tem uma consequência de desempenho. Como cada transação deve declarar quais contas lerá ou gravará antes do início da execução, o runtime Sealevel pode identificar transações que não se sobrepõem e executá-las simultaneamente. A explicação completa de como o modelo de contas permite a execução paralela segue abaixo.

Propriedade e Autoridade de Conta: Quem Controla o Quê na Solana

O campo owner (proprietário) em uma conta Solana identifica o programa que tem permissão exclusiva para modificar os dados dessa conta. Apenas esse programa, no nível do protocolo, pode escrever no campo de dados.

O campo owner armazena uma chave pública de programa de 32 bytes. Para contas de carteira, o proprietário é o System Program. Para contas de token, o proprietário é o SPL Token Program. Para contas de dados personalizadas, o proprietário é o programa que as criou. A propriedade é definida na criação da conta e aplicada pelo runtime da Solana em cada transação.

Considere um cofre em um banco. O banco é o proprietário do cofre e é a única entidade que pode abrir e modificar fisicamente seu conteúdo. Você possui uma chave que permite instruir o banco sobre o que fazer com seu cofre, mas apenas o banco toca no conteúdo. Na Solana, o programa é o banco, e você é o titular da conta com uma chave.

A distinção entre proprietário e autoridade confunde muitos desenvolvedores de Ethereum:

• Proprietário (campo do protocolo): O ID do programa que pode modificar o campo data da conta. Definido na criação da conta. Aplicado pelo runtime da Solana, não pela lógica de qualquer programa.
• Autoridade (convenção de dados): Uma chave pública armazenada dentro do campo data da conta pelo programa proprietário. Ela autoriza operações específicas dentro da lógica desse programa. Aplicada pelo próprio programa, não pelo runtime.

Para uma conta de token USDC, o Token Program é o proprietário e pode modificar o saldo armazenado no campo de dados. Sua carteira é a autoridade de transferência, uma chave pública registrada dentro do campo de dados que o Token Program verifica antes de executar uma transferência. Estas são chaves diferentes desempenhando funções diferentes. Confundi-las é um dos erros mais comuns no desenvolvimento inicial em Solana.

Aluguel (Rent) e Isenção de Aluguel em Contas Solana Explicados

O aluguel (rent) na Solana é uma taxa de armazenamento, denominada em lamports, cobrada das contas para compensar os validadores pela manutenção do estado na blockchain. As contas que mantêm um saldo mínimo em lamports, o limite de isenção de aluguel, estão permanentemente isentas de cobranças de aluguel e nunca serão expurgadas pelo runtime.

O que é Aluguel na Solana?

Os validadores devem armazenar todo o estado das contas ativas na memória. Um número ilimitado de contas com saldo zero seria um vetor de negação de serviço contra a rede, por isso a Solana exige que as contas mantenham um saldo mínimo em lamports como um compromisso com o pagamento dos custos de armazenamento. O modelo de aluguel original cobrava taxas por época (epoch) proporcionais ao tamanho dos dados, com contas abaixo do mínimo sujeitas à coleta de lixo. Esse modelo foi descontinuado.

De acordo com os parâmetros atuais da Mainnet da Solana (formalizados no SIMD-0084), todas as novas contas devem ser isentas de aluguel na criação. O campo rent_epoch na estrutura da conta é agora um campo legado.

Como Funciona a Isenção de Aluguel

Para tornar sua conta isenta de aluguel, financie-a com pelo menos o saldo mínimo em lamports para o seu tamanho de dados ao enviar a transação de criação. Nos parâmetros atuais da rede:

• Uma conta de 0 bytes (carteira): aproximadamente 890.880 lamports (~0,00089 SOL)
• Uma conta de 165 bytes (conta de token padrão): aproximadamente 2.039.280 lamports (~0,00204 SOL)
• Uma conta de dados de 1.024 bytes: aproximadamente 7.180.800 lamports (~0,00718 SOL)

Estes valores são aproximados e sujeitos a alterações nos parâmetros do runtime. Calcule o mínimo atual exato usando a CLI da Solana ou o método RPC getMinimumBalanceForRentExemption:

solana rent 0       # isenção de aluguel para uma conta de 0 bytes
solana rent 165     # isenção de aluguel para uma conta de token padrão

A isenção de aluguel funciona como um depósito de segurança em uma unidade de armazenamento. Você bloqueia um saldo mínimo em lamports para garantir a existência da conta na rede. Ao contrário de uma taxa, este depósito é totalmente recuperável. Quando você fecha a conta, esses lamports retornam para você.

A denominação lamport usada nos cálculos de aluguel é definida na seção de anatomia da conta. Para tornar uma conta de dados isenta de aluguel quando seu programa a cria, chame getMinimumBalanceForRentExemption(dataSize) no lado do cliente antes de construir a transação de criação e, em seguida, inclua essa quantidade de lamports na instrução.

Solana vs. Ethereum vs. Bitcoin: Como os Modelos de Conta se Comparam

Qual é a Diferença Entre Contas Solana e Contas Ethereum?

No Ethereum, os Smart Contracts agrupam seu código e estado em um único endereço. Uma conta de contrato detém tanto a lógica quanto os dados em que opera. Na Solana, o código e o estado estão sempre em contas separadas: os programas (lógica) vivem em contas executáveis, e todo o estado vive em contas de dados distintas de propriedade desses programas. Essa separação é a base arquitetônica de tudo o que a Solana faz de diferente.

O Bitcoin adota uma abordagem inteiramente diferente, usando um modelo UTXO (Unspent Transaction Output). As UTXOs são como cheques não descontados em um talão de cheques: cada transação consome saídas existentes e cria novas. Não há uma conta persistente mantendo um saldo ao longo do tempo. Seu saldo é a soma das saídas não gastas associadas às suas chaves. O modelo do Bitcoin precede o conceito de estado programável, e é por isso que suas capacidades de Smart Contract são limitadas ao Bitcoin Script.

Redes compatíveis com EVM, incluindo Ethereum, Polygon, BNB Chain e Avalanche C-Chain, compartilham o mesmo modelo de conta do qual a Solana se afasta. Uma comparação abrange todas elas.

No Ethereum, as carteiras dos usuários são chamadas de Contas Externamente Propriedade (EOAs). Na Solana, o equivalente é uma conta de propriedade do sistema controlada por um par de chaves; o mecanismo é semelhante, mas o campo de proprietário é explicitamente definido para o System Program em vez de ser implícito.

O que os Desenvolvedores de Ethereum Precisam Desaprender

Três mudanças de modelo mental são necessárias antes de escrever um programa Solana funcional:

1. Programas não mantêm seu próprio estado. Contas de dados sim. Pare de procurar pelo estado no endereço do programa.
2. O proprietário da sua carteira não é você no nível do protocolo. Você controla a conta assinando; o System Program é o proprietário do campo de dados.
3. O armazenamento não é gratuito. Cada conta de dados exige um depósito de lamport para isenção de aluguel. Preveja esse custo ao projetar programas que criam contas.

A separação estrita de código e estado da Solana é o pré-requisito para a execução paralela, uma conexão explorada na íntegra na seção Sealevel e execução paralela.

Como o Modelo de Conta Impulsiona a Velocidade da Solana: Sealevel e Execução Paralela

O modelo de conta da Solana permite o processamento paralelo porque cada transação deve declarar explicitamente a lista completa de contas que irá ler ou gravar antes do início da execução. O Sealevel, o tempo de execução paralela de Smart Contract da Solana, utiliza essas declarações antecipadas para identificar transações que tocam em contas diferentes e executá-las simultaneamente.

Aqui está a cadeia causal, passo a passo:

1. Uma transação Solana inclui uma lista completa de todas as contas que acessará, cada uma marcada como somente leitura ou leitura e gravação, antes de qualquer execução ocorrer.
2. O Sealevel inspeciona todas as transações pendentes no slot atual.
3. As transações que compartilham pelo menos uma conta de leitura e gravação são sequenciadas. Transações que acessam contas inteiramente diferentes são identificadas como não conflitantes.
4. Transações não conflitantes são executadas simultaneamente em vários núcleos de CPU.

A EVM do Ethereum executa transações sequencialmente contra um estado global compartilhado. Como o estado do contrato está localizado no mesmo lugar que o código do contrato, determinar conflitos de leitura/gravação exigiria a execução da transação primeiro, tornando o agendamento estático impossível antes da execução.

Pense no Sealevel como um supermercado com muitas filas de caixa. Cada transação é um comprador com uma lista declarada de Item. Contanto que dois compradores não estejam pegando o mesmo Item, eles passam pelo caixa simultaneamente. A Solana sabe antecipadamente exatamente o que cada transação precisa, porque o modelo de conta força essa declaração antecipada.

O Proof of History (PoH), inventado pelo cofundador da Solana, Anatoly Yakovenko, fornece um relógio criptográfico que permite que os validadores concordem com a ordem das transações sem coordenação em tempo real. A Solana utiliza Proof of Stake (PoS) para consenso, onde os validadores devem investir em staking SOL para participar da produção de blocos, e o PoH como uma camada de temporização. Combinado com as declarações de conta antecipadas do modelo de conta, essa arquitetura permite que o Sealevel processe transações não conflitantes em paralelo sem esperar por confirmação em toda a rede a cada etapa.

O modelo de conta não é um esquema de armazenamento isolado. É o pré-requisito para o paralelismo e é a raiz técnica da vantagem de rendimento e escalabilidade da Solana.

Exemplos do Mundo Real: Contas de Token, NFTs e DeFi na Solana

Cada ativo na Solana, um Saldo de token, um NFT, uma Posição de DeFi, é uma conta Solana com um layout de dados específico. A arquitetura abstrata descrita acima se manifesta em três padrões que todo usuário da Solana encontra.

Contas de Token SPL

Os tokens SPL, o equivalente da Solana aos tokens ERC-20 do Ethereum, são gerenciados pelo SPL Token Program, que é proprietário de todas as contas de token na rede. O endereço da sua carteira contém apenas SOL (lamports). Cada token que você possui, seja USDC, JTO, BONK ou qualquer outro, reside em sua própria conta de token dedicada, de propriedade do SPL Token Program.

O campo de dados de uma conta de token armazena três informações: o endereço de emissão (mint) do token (qual token esta conta mantém), a chave pública da autoridade proprietária (o endereço da sua carteira, que autoriza transferências) e o Saldo atual do token. No Ethereum, todos os saldos ERC-20 para um determinado token residem dentro do mapeamento interno do contrato do token. Na Solana, cada par (usuário, token) exige sua própria conta dedicada.

É por isso que as carteiras Solana solicitam que você crie uma conta de token ao receber um novo token pela primeira vez. Essa criação exige um depósito de lamport isento de aluguel de aproximadamente 0,00204 SOL para a conta padrão de 165 bytes nos parâmetros atuais da rede.

Contas de Token Associadas (ATAs)

Uma Conta de Token Associada (ATA) é uma conta de token cujo endereço é um PDA derivado deterministicamente do endereço da sua carteira e do endereço de emissão do token. Como o endereço é determinístico, qualquer protocolo pode calcular onde sua conta USDC deve estar sem armazenar uma tabela de busca. As ATAs são o tipo padrão de conta de token usado por virtualmente todas as carteiras e protocolos Solana.

As ATAs são uma aplicação da derivação de PDA. Você pode ter várias contas de token para a mesma emissão, mas sua ATA é a canônica que os protocolos usam por padrão.

NFTs na Solana

Um NFT na Solana consiste em pelo menos duas contas: uma Conta de Emissão (Mint Account) de propriedade do Token Program que define o suprimento do token como exatamente 1, e uma Conta de Metadados (Metadata Account) de propriedade do Metaplex Token Metadata Program que armazena o nome, símbolo, URI da imagem e configuração de royalties do NFT. A imagem do NFT não é armazenada na blockchain; apenas o URI que aponta para ela reside na conta de metadados. O Saldo do token (1 NFT) é armazenado em uma conta de token, idêntica a qualquer outro token SPL.

Protocolos de DeFi na Solana, incluindo exchanges descentralizadas, plataformas de empréstimo e pools de Liquidez, armazenam cada Posição do usuário, estado do pool e configuração do protocolo em contas de dados dedicadas, com PDAs de propriedade do programa controlando fundos em pool de forma autônoma.

Por que o Modelo de Conta da Solana é Importante para o SOL

Nota: Esta seção explica como o modelo de conta da Solana afeta a utilidade técnica do SOL. Nada neste artigo constitui aconselhamento financeiro ou uma recomendação de investimento.

O modelo de conta não é apenas uma preocupação do desenvolvedor. O SOL, disponível nas principais corretoras de Criptomoeda, serve como o Token utilitário nativo da rede. O modelo de conta é o mecanismo primário através do qual o SOL é demandado e usado na camada de rede.

O SOL é usado no modelo de conta por meio de três mecanismos distintos:

Depósitos de isenção de aluguel: Cada conta na Solana deve manter um Saldo em lamports para existir na rede. Com milhões de contas de token, contas de dados de programas, registros de NFT e contas de estado de DeFi ativas a qualquer momento, isso cria uma demanda base persistente por SOL. Esses lamports ficam bloqueados em contas e são removidos da circulação líquida enquanto as contas permanecerem abertas.

Taxas de transação: Cada transação que cria ou modifica contas paga uma Taxa-base em lamports. Uma parte de cada taxa é queimada sob a estrutura de taxas atual, reduzindo a Oferta circulante a cada transação.

Staking de validador: Os validadores investem em staking de SOL para participar do consenso sob o mecanismo de Proof of Stake da Solana, ganhando recompensas por validar transições de estado de conta em toda a rede.

À medida que a atividade On-Chain cresce, com mais protocolos DeFi, mais coleções NFT, mais lançamentos de tokens, o número de contas cresce proporcionalmente. Mais contas exigem mais SOL bloqueado em depósitos de isenção de aluguel.

Os lamports bloqueados em contas isentas de aluguel funcionam como depósitos de segurança mantidos pela rede: não são gastos, mas ficam comprometidos enquanto essas contas permanecerem abertas. Quando as contas são fechadas, esses lamports retornam aos seus proprietários.

Recursos Relacionados à Arquitetura da Solana

As contas de token são mais fáceis de entender junto com a Solana Program Library, enquanto a simultaneidade é explicada no guia sobre o processamento paralelo Sealevel. Os leitores podem revisar a página de preço da SOL;; usuários que avaliam produtos relacionados a staking podem revisar separadamente o SOL Earn,, incluindo seus termos e riscos atuais.

FAQ: Modelo de Conta da Solana

Qual é a diferença entre as contas da Solana e as contas da Ethereum?

Na Ethereum, um Smart Contract armazena tanto seu código quanto seu estado em um único endereço. Na Solana, o código e o estado estão sempre em contas separadas: os programas são contas executáveis sem estado, e todo o estado reside em contas de dados distintas de propriedade desses programas. Essa separação permite que o Sealevel execute transações não conflitantes em paralelo, o que não é possível com o modelo de estado colocado da Ethereum.

O que é o aluguel (rent) na Solana e como ele funciona?

O aluguel na Solana é o custo de armazenamento de dados na rede, denominado em lamports. Em vez de pagar taxas contínuas, as contas devem depositar um Saldo mínimo de lamports antecipadamente, o limite de isenção de aluguel, para evitar serem expurgadas pelo tempo de execução. O depósito é recuperável: quando a conta é fechada, os lamports retornam ao proprietário. Para uma conta de token padrão de 165 bytes, o depósito é de aproximadamente 0,00204 SOL nos parâmetros atuais da rede.

O que é um Endereço Derivado de Programa (PDA) na Solana?

Um PDA é um endereço de conta Solana derivado de forma determinística a partir de um ID de programa e um conjunto de valores de semente (seed). Ele não possui uma chave privada correspondente, portanto, apenas o programa que o derivou pode autorizar transações em seu nome via Cross-Program Invocation. Os PDAs dão aos programas controle autônomo e sem confiança sobre as contas, um requisito para protocolos DeFi, custódias (escrows) NFT e Contas de Token Associadas.

Como o modelo de conta da Solana permite o processamento paralelo?

Cada transação da Solana deve declarar a lista completa de contas que irá ler ou gravar antes da execução. O Sealevel, o tempo de execução de Smart Contract paralelo da Solana, usa essas declarações para identificar transações não conflitantes e executá-las simultaneamente em vários núcleos de CPU. Esse agendamento estático só é possível porque o código e o estado residem em contas separadas e explicitamente identificadas, tornando os conflitos de leitura/gravação detectáveis antes do início da execução.

O que é o campo "owner" (proprietário) em uma conta Solana?

O campo owner é uma chave pública de 32 bytes que identifica o programa que tem autoridade para modificar o campo de dados da conta. Para contas de carteira, o proprietário é o Programa do Sistema. Para contas de token, o proprietário é o Programa de Token SPL. O campo owner é um conceito de nível de protocolo aplicado pelo tempo de execução da Solana. Ele é distinto do campo "authority" (autoridade) encontrado dentro de certas contas de dados gerenciadas por programas, como contas de token.

Como a SOL é usada no modelo de conta?

A SOL é usada no modelo de conta através de três mecanismos: cada conta deve manter um Saldo de lamports (SOL) para existir na rede; a criação de contas requer SOL para financiar o depósito de isenção de aluguel; e os validadores que processam e armazenam o estado da conta devem investir em staking de SOL para participar do consenso. À medida que a rede cresce, a demanda estrutural por SOL cresce com ela.

O que é Sealevel e como ele se relaciona com as contas?

O Sealevel é o tempo de execução de Smart Contract paralelo da Solana. Ele pode executar várias transações simultaneamente porque o modelo de conta da Solana exige que cada transação declare previamente quais contas irá ler ou gravar. O Sealevel usa essas declarações para identificar transações não conflitantes e agendá-las para execução em paralelo. Sem as declarações antecipadas do modelo de conta, esse agendamento estático seria impossível.

Qual é a diferença entre uma conta de carteira e uma conta de programa na Solana?

Uma conta de carteira é uma conta de propriedade do sistema com um campo de dados vazio que contém apenas um Saldo de SOL, controlado por um par de chaves. Uma conta de programa é uma conta executável com executable = true que contém bytecode BPF/SBF compilado; ela pertence ao BPF Loader e não possui estado próprio. A tabela de tipos de conta na seção Cinco Tipos de Contas Solana mostra todas as cinco variantes lado a lado.

Quantas contas uma transação Solana pode referenciar?

Uma única transação Solana pode referenciar até 64 contas nos parâmetros atuais da Mainnet, valor aumentado dos 32 originais via Tabelas de Pesquisa de Endereço (Address Lookup Tables). Cada conta deve ser declarada como somente leitura ou leitura e gravação antes do início da execução. Essa declaração antecipada é o que permite ao Sealevel agendar a execução paralela sem precisar rodar as transações primeiro para detectar conflitos.

Uma conta Solana pode conter vários tokens?

Não. Cada tipo de token SPL requer sua própria conta de token dedicada. Um endereço de carteira contém apenas SOL; cada token adicional requer uma conta de token separada vinculada à carteira por meio de seu campo de autoridade. É por isso que as carteiras Solana solicitam que você crie uma nova conta de token ao receber um token que você ainda não possui, e por que essa criação custa um pequeno depósito de lamports isento de aluguel.

Principais Conclusões

• Cada parte do estado On-Chain na Solana reside em uma conta com cinco campos: lamports, data, owner, executable, rent_epoch.
• Os programas são "stateless" (sem estado). Todo o estado reside em contas de dados separadas que os programas possuem e controlam.
• As contas exigem um depósito de lamports (isenção de aluguel) para persistirem na rede. O depósito é recuperável quando a conta é fechada.
• PDAs são endereços sem chave privada, derivados de forma determinística a partir de um ID de programa e sementes (seeds), assináveis apenas pelo programa que os criou via CPI.
• Cada transação declara sua lista de acesso a contas antecipadamente. O Sealevel usa essas declarações para executar transações não conflitantes simultaneamente.

Próximos Passos

• Para detalhes de implementação, consulte a documentação de contas da Solana em docs.solana.com.
• Desenvolvedores que estão construindo seu primeiro programa Solana podem começar com o framework Anchor,, que abstrai grande parte do código repetitivo de gerenciamento de contas (os programas são escritos em Rust ou C/C++).
• Para receitas de código práticas e exemplos funcionais em JavaScript/TypeScript, o Solana Cookbook fornece material de referência prático.