Modelo de Conta Solana: Guia Técnico

Este Modelo de Conta Solana: Guia Técnico explica os campos de tempo de execução e as regras de acesso das quais os programas dependem, incluindo propriedade, contas executáveis, contas de token, isenção de aluguel, Endereços Derivados de Programas, Contas de Token Associadas e Invocação entre Programas.

Detalhes de implementação, como manuseio de aluguel, limites de tamanho de conta e APIs de clientes, podem mudar. Os desenvolvedores devem verificar a documentação atual da Solana e consultar os parâmetros de rede atuais antes de implementar.

Cada transação na Solana toca uma conta. Cada token que você possui, cada programa que você implementa, cada NFT que você cunha: tudo isso vive em contas. Antes de escrever uma única linha de código Solana, entender como as contas funcionam não é um conhecimento secundário opcional. É o pré-requisito para tudo o mais.

Pense na Solana como um armário de arquivos. Cada gaveta contém uma pasta, e cada pasta tem um rótulo (seu endereço), conteúdo (seus dados), um carimbo de saldo e um nome de departamento na capa indicando qual programa tem autoridade para editar o que está dentro. Seja você um desenvolvedor migrando do Ethereum, um pesquisador avaliando a arquitetura da Solana ou um estudante formando seu primeiro modelo mental de gerenciamento de estado na blockchain, este guia cobre o quadro completo: anatomia da conta, tipos de conta, regras de propriedade, mecânica de aluguel, Endereços Derivados de Programas, uma comparação lado a lado com o Ethereum e código anotado para construção na prática.

Visão Geral do Guia Técnico do Modelo de Conta Solana

O Modelo de Conta Solana é a arquitetura de armazenamento de dados e gerenciamento de estado da blockchain Solana. Cada parte do estado na Solana, incluindo saldos de tokens, lógica de programa, dados do usuário e configuração do sistema, é armazenada em contas distintas identificadas por chaves públicas exclusivas de 256 bits. Consulte a documentação oficial de conta da Solana) para a especificação canônica.

Cada parte do estado na Solana vive em uma conta. Os programas não armazenam seus próprios dados; eles leem e escrevem em contas passadas para eles durante a execução. Esta decisão arquitetônica única separa o design da Solana da maioria das outras blockchains.

A analogia do armário de arquivos mapeia-se diretamente para a estrutura de dados: o armário é a blockchain Solana, as pastas são contas, o rótulo de cada pasta é sua chave pública (o endereço on-chain), o conteúdo da pasta é o campo de dados, o carimbo de saldo é o campo lamports e o carimbo do departamento na capa é o campo do proprietário (owner), que registra qual programa tem autoridade de escrita. Somente o departamento nomeado naquele carimbo pode alterar o que está dentro.

Se você vem do Ethereum, esta distinção é importante: os contratos inteligentes do Ethereum armazenam seu próprio estado internamente, enquanto os programas da Solana são stateless (sem estado). A comparação completa está em uma seção dedicada abaixo.

Anatomia de uma Conta Solana

Cada conta Solana, seja ela de armazenamento de SOL, código de programa ou estado de aplicativo, é construída a partir dos mesmos cinco campos.

Os Cinco Campos de Cada Conta Solana

Cada conta na Solana possui exatamente cinco campos, cada um com uma função distinta. Compreender esses campos em termos simples antes de examinar o código torna os detalhes técnicos muito mais fáceis de internalizar.

lamports: o saldo de SOL desta conta, expresso em Lamports (a menor denominação da Solana, explicada na próxima seção). Na analogia do arquivo, este é o valor monetário carimbado na capa da pasta.

data: um array de bytes brutos (Vec<u8>) que armazena qualquer estado que o programa proprietário precise. Para uma conta de programa, este campo contém o bytecode BPF compilado. Para uma conta de dados, ele contém o estado serializado da aplicação. Os programas definem seu próprio formato de serialização (comumente Borsh) para ler e gravar dados estruturados neste campo. O equivalente no armário de arquivos é o conteúdo físico dentro da pasta.

owner: a chave pública do programa autorizado a modificar o campo de dados desta conta. Nenhum outro programa pode escrever nele. Este é o carimbo do departamento na capa da pasta.

executable: uma flag booleana. Quando definida como true, a conta armazena código de programa e pode ser executada. Quando false, a conta é um contêiner de dados.

rent_epoch: um campo legado que anteriormente rastreava o cronograma de coleta de aluguel (rent). Este campo está sendo descontinuado e não possui significância operacional para contas isentas de aluguel (rent-exempt), que é o padrão de produção.

Cada conta Solana é identificada por uma chave pública única de 256 bits derivada de um par de chaves ed25519, que serve tanto como seu endereço quanto como seu identificador na blockchain. O tamanho máximo do campo de dados para uma única conta é de 10 MB conforme atualizações recentes do protocolo; verifique os limites atuais na documentação de conta da Solana,), pois esse valor mudou ao longo da história da Solana.

Lamports: A Menor Unidade da Solana

Um Lamport é a menor denominação de SOL: 1 SOL equivale a 1.000.000.000 Lamports (10⁹). A unidade recebeu o nome de Leslie Lamport, um cientista da computação cujo trabalho em sistemas distribuídos e tolerância a falhas fundamenta grande parte da teoria moderna de computação distribuída. Os Lamports existem porque toda aritmética na blockchain, incluindo cálculos de aluguel, taxas de transação e saldos de contas, deve usar aritmética de inteiros para evitar erros de precisão de ponto flutuante. Expressar valores em Lamports torna cada cálculo exato.

Uma Conta Solana é a Mesma Coisa que uma Carteira?

Uma conta Solana e uma carteira não são a mesma coisa. O que você considera sua carteira, o aplicativo Phantom ou Solflare no seu telefone, é um software fora da blockchain que gerencia uma chave privada. A entidade na blockchain é uma conta de sistema que detém seu saldo de SOL. Sua carteira controla uma conta de sistema; ela não é, em si, uma conta. Contas de token, contas de programa e contas de dados não têm equivalente em carteira: são puramente contêineres de dados na blockchain que nenhum aplicativo de carteira de consumo representa diretamente.

As contas Solana enquadram-se em quatro categorias, cada uma definida pelo seu programa proprietário e pela flag executable.

1. Contas de Sistema: de propriedade do Programa de Sistema; usadas para armazenamento de SOL e carteiras de usuários
2. Contas de Programa: contas executáveis que armazenam bytecode BPF compilado
3. Contas de Dados/Estado: de propriedade de programas; armazenam estados específicos da aplicação
4. Contas de Token: contas de dados especializadas de propriedade do Programa de Token SPL (com Contas de Token Associadas como o subconjunto canônico)

Contas de Sistema

As contas de sistema são de propriedade do Programa de Sistema, e as carteiras dos usuários são contas de sistema. O Programa de Sistema é o programa nativo da Solana responsável por três operações principais: criar novas contas (alocar espaço de dados na blockchain), atribuir a propriedade da conta (definir o campo owner para um programa específico) e transferir SOL entre contas. Cada nova conta na Solana começa como uma conta de sistema de propriedade do Programa de Sistema.

O Programa de Sistema possui um endereço bem conhecido: 11111111111111111111111111111111 (32 números um em base58). Veja a documentação do Programa de Sistema) para seu conjunto completo de instruções. Quando um desenvolvedor cria uma conta de dados para seu programa, ele invoca a instrução Create Account do Programa de Sistema, especificando o tamanho dos dados, o depósito em Lamport para isenção de aluguel e a chave pública do novo programa proprietário.

Contas de Programa

Contas de programa armazenam bytecode BPF compilado, não estado. A flag executável nessas contas é definida como true. Os programas são sem estado (stateless): quando um programa é executado, ele recebe uma lista de contas para ler ou gravar via instrução de transação. Ele não mantém nenhum estado interno entre chamadas. Se você vem do Ethereum, deve conhecer o código executável on-chain como contratos inteligentes, mas os programas da Solana funcionam de maneira fundamentalmente diferente porque não carregam estado próprio. Contas de programa pertencem ao programa BPF Loader. Uma vez implantada, uma conta de programa é imutável, a menos que um keypair de autoridade de upgrade tenha sido designado durante a implantação.

Contas de Dados e de Estado

Contas de dados mantêm o estado da aplicação que os programas leem e gravam durante a execução. A flag executável nessas contas é false. O campo de dados armazena o estado definido pelo programa serializado com Borsh. Exemplos incluem a posição de empréstimo de um usuário em um protocolo DeFi, metadados de NFT ou um contador de aplicação. O programa proprietário é a única entidade que pode gravar no campo de dados desta conta, uma regra coberta em detalhes na seção de propriedade.

Contas de Token e Contas de Token Associadas

Contas de token são contas de dados de propriedade do SPL Token Program, cada uma mantendo um saldo de um token específico para uma carteira específica. Um único endereço de carteira pode conter várias contas de token, uma para cada tipo de token que possui.

Uma Conta de Token Associada (ATA) é a conta de token canônica para um par específico de [endereço da carteira, endereço do mint]. As ATAs são derivadas deterministicamente como um Endereço Derivado de Programa (PDA) usando o endereço da carteira e o endereço do mint do token como sementes. Isso garante que cada carteira tenha exatamente uma conta "oficial" por tipo de token. As ATAs são o padrão usado por carteiras como Phantom e Solflare, por exchanges e por protocolos: quando você recebe um token na interface da sua carteira, ele vai para a sua ATA daquele token.

Se uma ATA não existir para um determinado par [carteira, mint], ela deve ser criada antes que os tokens possam ser recebidos, e a criação custa um depósito de Lamports isento de aluguel. É por isso que algumas transações incluem uma pequena "taxa de criação de conta" nas interfaces de carteira. Para a especificação completa da ATA, consulte a documentação de Conta de Token Associada da SPL. Uma ATA é uma conta de token, mas nem toda conta de token é uma ATA, e a distinção é importante ao depurar programas relacionados a tokens.

Propriedade de Conta: Como a Solana Controla o Acesso a Dados

A propriedade de conta na Solana é um mecanismo de autoridade de gravação, não um conceito de propriedade de ativos.

A Regra de Propriedade

Apenas o programa proprietário da conta pode modificar seu campo de dados. Nenhum outro programa pode gravar nele, independentemente do que o usuário autorize no nível da transação. O campo owner em AccountInfo armazena a chave pública do programa que detém essa autoridade. Programas que não são proprietários podem ler o campo de dados livremente, mas a gravação exige ser o proprietário designado.

O System Program atribui a propriedade durante a criação da conta. Quando um desenvolvedor cria uma conta de dados para seu programa, a instrução Create Account define o campo owner para a chave pública de seu programa. A propriedade pode ser reatribuída, mas apenas pelo programa proprietário atual usando a instrução Assign. Nenhuma parte externa pode transferir a propriedade unilateralmente.

Proprietário vs. Autoridade: Uma Distinção Crítica

Proprietário e autoridade são dois conceitos diferentes no gerenciamento de contas da Solana. O proprietário é o programa registrado no campo owner da conta, significando o programa que pode gravar no campo de dados. A autoridade (ou signatário) é o keypair que pode assinar transações para a conta.

Considere uma conta de token como exemplo: a chave privada da sua carteira assina a transação (você é a autoridade), mas o SPL Token Program é o proprietário da sua conta de token e é a única entidade que pode modificar seu saldo de tokens no campo de dados. Você pode autorizar uma transação que move tokens, mas a gravação real no campo de dados é realizada pelo Token Program, não por você diretamente. Confundir esses dois conceitos produz a maioria dos erros de depuração de propriedade de conta para desenvolvedores novos na Solana.

Propriedade na Prática: Um Exemplo de DEX

Um programa de DEX só pode gravar em contas que possui diretamente. Para transferir tokens de uma conta de token de um usuário (de propriedade do SPL Token Program, não do DEX), o DEX não pode gravar nessa conta diretamente. Programas podem chamar outros programas dentro da mesma transação, um padrão chamado Invocação Entre Programas (CPI), permitindo que um DEX instrua o Token Program a mover tokens em nome de um usuário. O DEX envia uma CPI para o Token Program, fornecendo a autorização assinada do usuário, e o Token Program realiza a gravação no campo de dados da conta de token do usuário. É assim que o modelo de propriedade do programa se estende às interações entre programas. Para um passo a passo completo, consulte o guia de Invocação Entre Programas (CPI) para desenvolvedores Solana.

Aluguel de Conta e Isenção de Aluguel

O aluguel na Solana é um mecanismo de custo de armazenamento, não uma taxa recorrente.

O Que é Aluguel?

O aluguel é o mecanismo da Solana para precificar o armazenamento em blockchain. Cada conta deve manter um saldo mínimo de SOL proporcional ao seu tamanho de dados para permanecer ativa na rede. A correção que a maioria dos conteúdos de concorrentes ignora: o aluguel não é uma taxa recorrente na prática. O padrão de produção é a isenção de aluguel, onde depositar SOL suficiente antecipadamente para cobrir aproximadamente dois anos de armazenamento torna uma conta permanentemente isenta de qualquer dedução de aluguel. A grande maioria das contas implantadas opera sob isenção de aluguel.

A isenção de aluguel é o padrão de produção para todas as contas Solana implantadas. O saldo mínimo para isenção de aluguel é de aproximadamente 6.960 Lamports multiplicados pelo tamanho dos dados da conta em bytes, mais um valor base de aproximadamente 890.880 Lamports para uma conta de zero bytes.

Um exemplo prático: uma conta de dados de 100 bytes requer aproximadamente 890.880 + (6.960 × 100) = 1.586.880 Lamports, ou cerca de 0,00159 SOL. Esses números são aproximados e sujeitos a alterações. Verifique os valores atuais com o comando da CLI da Solana solana rent <bytes> ou na documentação de aluguel da Solana. Uma proposta de mudança para converter o aluguel em um modelo de taxa de transação não foi ativada até o momento desta publicação; consulte a documentação atual para ver o status mais recente do protocolo.

O Que Acontece Quando uma Conta Fica Sem SOL?

A criação de conta atual geralmente exige financiamento isento de aluguel. Os desenvolvedores devem consultar os requisitos de RPC atuais em vez de confiar no comportamento legado de coleta de aluguel. Este é o comportamento que gera preocupação sobre contas serem "excluídas".

Contas isentas de aluguel nunca são fechadas automaticamente pelo runtime. As contas em produção são sempre financiadas até o limite de isenção de aluguel, portanto, a coleta de lixo (garbage collection) não as afeta. Fechar contas intencionalmente é um padrão separado e deliberado: os programas podem fechar contas de dados para recuperar o depósito de Lamports. Em um protocolo DeFi, por exemplo, o fechamento de uma posição de empréstimo libera o SOL que financiou a conta de dados dessa posição de volta para o usuário. Este é um padrão comum de design de protocolo, não uma exclusão involuntária.

Endereços Derivados de Programa (PDAs) Explicados

Os Endereços Derivados de Programa resolvem um problema específico: como um programa pode controlar uma conta sem que ninguém detenha a chave privada correspondente.

O Que é um Endereço Derivado de Programa?

Um Endereço Derivado de Programa (PDA) é um endereço de conta gerado deterministicamente, derivado de um ID de programa e um ou mais valores de semente usando hashing SHA-256. Os PDAs são intencionalmente colocados fora da curva elíptica ed25519, o que significa que não possuem chave privada correspondente. Apenas o programa proprietário pode assinar transações para contas em endereços PDA. Veja a documentação de PDA da Solana para a especificação completa.

Todos os endereços de conta regulares da Solana residem na curva elíptica ed25519. As PDAs são intencionalmente colocadas fora dessa curva. A propriedade "off-curve" (fora da curva) não é um bug; é o mecanismo de design que torna uma chave privada matematicamente impossível. Nenhum humano, nenhuma carteira de hardware e nenhum sistema de gerenciamento de chaves pode produzir a chave privada para uma PDA porque tal chave não existe na curva.

Por que as PDAs Importam: Custódia Controlada por Programa

A consequência de não possuir chave privada é que apenas o programa proprietário pode autorizar transações para uma PDA. Isso permite uma custódia controlada por programa sem necessidade de confiança (trustless): o programa detém a autoridade sobre a conta sem depender de nenhum humano para salvaguardar uma chave privada.

Compare isso com contas de par de chaves regulares, onde quem detém a chave privada controla a conta. Se a chave for perdida, o acesso desaparece. Se a chave for roubada, a conta é comprometida. As PDAs removem essa dependência inteiramente. A lógica do programa é o custodiante, um código auditável em vez de uma pessoa.

Três Casos de Uso Reais de PDAs

As PDAs aparecem em três padrões recorrentes nos programas da Solana.

Contas de garantia (escrow) DEX: um programa de corretora descentralizada mantém tokens em uma PDA até que ambos os lados de um swap atendam às condições exigidas. Nenhum intermediário de confiança detém uma chave privada para a garantia. A lógica do programa controla a liberação, e nenhum participante pode drenar os fundos fora das regras do protocolo.

Nenhum indivíduo pode dar uma "puxada de tapete" na autoridade de cunhagem (mint) de uma coleção NFT. A autoridade de mint NFT funciona fazendo com que os programas da Metaplex controlem a cunhagem via uma PDA derivada do endereço de mint. Como não existe chave privada para esta PDA, as regras de cunhagem da coleção são aplicadas apenas pelo código do programa após a implantação.

Como um programa armazena dados por usuário sem manter um índice centralizado? O armazenamento de estado por usuário utiliza uma PDA exclusiva derivada de [program_id, user_pubkey]. Isso produz um endereço de conta determinístico e específico do usuário para armazenar a pontuação do jogo, a posição de empréstimo ou o registro de Staking desse usuário. O programa sempre sabe onde encontrar os dados de cada usuário.

As funções findProgramAddress() e createProgramAddressSync() localizam endereços off-curve válidos testando endereços candidatos com uma "bump seed" incremental até que um caia fora da curva.

Quando Você Deve Usar uma PDA?

Use uma PDA sempre que seu programa precisar controlar uma conta sem depender da chave privada de um humano. Se a autoridade da conta deve ser a lógica do programa em vez de uma pessoa, use uma PDA. Esta regra abrange contas de garantia, cofres de protocolo, autoridades de mint e qualquer estado que o próprio programa deva possuir e gerenciar entre vários usuários.

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

A principal diferença entre os modelos de conta da Solana e da Ethereum é onde o estado reside.

Na Ethereum, os contratos inteligentes possuem estado (são stateful): eles armazenam seu próprio estado internamente junto ao seu código. Um contrato Solidity mantém seus próprios mapeamentos e variáveis de estado dentro do armazenamento do contrato, gerenciado pela Máquina Virtual Ethereum (EVM). Na Solana, os programas não possuem estado (são stateless); todo o estado reside em contas externas que os programas leem e escrevem durante a execução. Enquanto a Ethereum executa programas na EVM, a Solana usa um runtime baseado em BPF que executa programas contra contas declaradas antecipadamente na transação.

As compensações ocorrem em ambas as direções. O modelo stateful da Ethereum traz uma vantagem genuína na experiência do desenvolvedor: modelo mental mais simples, sem gerenciamento explícito de contas e menor carga cognitiva para muitos casos de uso. Um desenvolvedor pode escrever e implantar um contrato ERC-20 sem pensar no dimensionamento da conta de dados, depósitos isentos de aluguel ou derivação de PDA.

O modelo stateless da Solana troca essa simplicidade por paralelismo de execução e separação de conceitos. As declarações de conta exigidas por cada transação são a entrada para o algoritmo de agendamento do Sealevel, que executa transações não conflitantes simultaneamente. Outras blockchains de Camada 1, como Aptos e Sui, adotam suas próprias variantes de separação de estado baseada em recursos, cada uma com diferentes perfis de compensação. Nem a abordagem da Ethereum nem a da Solana é categoricamente superior; elas refletem diferentes prioridades de design para diferentes cargas de trabalho.

Por que esta Arquitetura Importa: Sealevel e Execução Paralela

Programas stateless não são uma restrição de design; eles são o mecanismo que torna possível a execução paralela.

A cadeia causal do design do modelo de conta para o desempenho funciona da seguinte forma. Primeiro, os programas da Solana são stateless. Segundo, como os programas não carregam estado, cada transação deve declarar todas as contas que acessará, tanto para leitura quanto para escrita, antes do início da execução. Terceiro, o mecanismo de execução paralela da Solana, o Sealevel, analisa essas listas de acesso a contas antes do agendamento. Quarto, transações que acessam conjuntos de contas que não se sobrepõem não têm dependências de dados entre si e podem ser executadas simultaneamente em vários núcleos de processador. Quinto, o resultado é uma rede capaz de processar dezenas de milhares de transações por segundo.

Anatoly Yakovenko projetou a arquitetura da Solana com o processamento paralelo de transações como um objetivo explícito, e separar a lógica do programa do estado da conta é o que torna isso possível. O modelo de conta funciona em conjunto com outras inovações arquitetônicas da Solana, incluindo o Proof of History (PoH), o mecanismo de relógio criptográfico da Solana. Para entender como o PoH contribui para esse rendimento, consulte o explicador de como o Proof of History funciona na arquitetura da Solana.

Construindo com Contas: Implementação do Desenvolvedor

Cada conta com a qual um programa da Solana trabalha deve ser criada, financiada e atribuída a um proprietário antes que o programa possa ler ou escrever nela.

Criando uma Conta com o Programa do Sistema

Os programas da Solana são escritos em Rust, uma linguagem de programação de sistemas, e compilados para bytecode BPF antes da implantação. Criar uma conta na Solana segue estes passos, cada um correspondendo a um parâmetro na instrução Create Account do Programa do Sistema:

1. from_pubkey: identifica a conta que financia a criação (o pagador)
2. new_account_pubkey: especifica o endereço da nova conta
3. lamports: calcula o saldo isento de aluguel com base no tamanho dos dados
4. space: define o tamanho dos dados em bytes a serem alocados para a conta
5. owner: especifica a chave pública do programa que será proprietário e escreverá nesta conta

// Criar uma nova conta de dados usando o Programa do Sistema
let create_account_ix = system_instruction::create_account(
    &payer.pubkey(),         // from_pubkey: quem financia esta conta
    &new_account.pubkey(),   // new_account_pubkey: o endereço da conta
    rent_exempt_balance,     // lamports: o suficiente para ser isento de aluguel
    data_size as u64,        // space: bytes alocados para dados da conta
    &program_id,             // owner: o programa que controla esta conta
);

Esta instrução estabelece a propriedade da conta. Após a execução, apenas o programa em program_id pode escrever no campo de dados desta conta.

Usando o Anchor Framework

Muitos programas da Solana são construídos com o framework Anchor, que fornece macros estruturadas para definir restrições de conta e instruções de programa. Consulte a documentação do Anchor) para a referência completa do framework.

// Anchor: define account constraints using the #[derive(Accounts)] macro
#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,                        // criar esta conta se ela não existir
        payer = user,                // o usuário paga o depósito isento de aluguel
        space = 8 + MyData::LEN,    // discriminador de 8 bytes + tamanho dos dados
    )]
    pub my_account: Account<'info, MyData>,     // a nova conta de dados
    #[account(mut)]
    pub user: Signer<'info>,                    // o signatário e pagador da transação
    pub system_program: Program<'info, System>, // necessário para a criação da conta
}

O Anchor lida com o clichê de validação de conta automaticamente, verificando a propriedade e o status do signatário antes que a lógica da sua instrução seja executada. Compreender o modelo de conta subjacente continua sendo necessário ao depurar erros de propriedade ou projetar estruturas de PDA, pois as macros do Anchor são abstrações sobre a mesma mecânica descrita ao longo deste artigo.

Recursos Relacionados à Arquitetura da Solana

Desenvolvedores que buscam um caminho de implementação mais curto podem usar o guia do modelo de conta focado no desenvolvedor; as convenções do programa de tokens são abordadas na visão geral da Solana Program Library. A página de preço da SOL) e o mercado Spot SOL/USDT) referem-se ao acesso ao mercado, não à propriedade de conta ou autoridade de programa.

FAQ: Modelo de Conta da Solana: Guia Técnico

O que é uma conta na Solana?

Uma conta Solana é um contêiner de dados na blockchain identificado por uma chave pública exclusiva de 256 bits. Cada conta armazena um saldo de SOL em Lamports, um campo de dados (uma matriz de bytes contendo o estado ou bytecode do programa), um campo de proprietário (a chave pública do programa autorizado a modificar os dados) e uma flag executável que indica se a conta armazena código de programa.

Como o modelo de conta da Solana difere do modelo da Ethereum?

Na Ethereum, os contratos inteligentes armazenam seu próprio estado internamente junto com seu código. Na Solana, os programas não têm estado (stateless); todo o estado reside em contas externas que os programas leem e gravam durante a execução. Essa separação permite que o tempo de execução Sealevel da Solana detecte padrões de acesso a contas não sobrepostos e execute várias transações simultaneamente, permitindo o processamento paralelo em escala.

O que é aluguel (rent) na Solana?

Todas as contas Solana em produção são financiadas até o limite de isenção de aluguel, tornando-as permanentemente isentas de taxas de armazenamento. O aluguel é o mecanismo subjacente: as contas devem manter um saldo mínimo de SOL proporcional ao tamanho de seus dados para permanecerem ativas na blockchain. Contas isentas de aluguel, aquelas financiadas acima do limite, nunca são fechadas automaticamente pelo tempo de execução.

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

Um Endereço Derivado de Programa (PDA) é um endereço de conta gerado deterministicamente a partir de um ID de programa e valores de semente (seed) usando hashing SHA-256. Os PDAs caem fora da curva elíptica ed25519, portanto não possuem uma chave privada correspondente. Apenas o programa proprietário pode assinar transações para contas em endereços PDA, permitindo a custódia controlada pelo programa sem a necessidade de confiança para contas de garantia (escrow), autoridades de cunhagem e armazenamento de estado por usuário.

As contas Solana podem ser excluídas?

Atualmente, a criação de contas geralmente exige financiamento isento de aluguel. Os desenvolvedores devem consultar os requisitos de RPC atuais em vez de confiar no comportamento legado de coleta de aluguel. Contas de produção devidamente implantadas são sempre financiadas até o limite de isenção de aluguel e nunca são excluídas automaticamente. Os programas também podem fechar contas intencionalmente para recuperar o depósito de SOL, um padrão comum em protocolos OTK_2.

O que são Lamports?

Lamports são a menor denominação de SOL na blockchain Solana: 1 SOL equivale a 1.000.000.000 de Lamports (10⁹). Nomeados em homenagem a Leslie Lamport, pioneiro da computação distribuída, os Lamports são usados para todos os saldos de SOL, taxas de transação e cálculos de aluguel na blockchain. Denominar valores em Lamports evita erros de precisão de ponto flutuante que surgiriam do uso de valores fracionários de SOL na aritmética em blockchain.

O que é o Programa do Sistema (System Program) na Solana?

O Programa do Sistema é o programa nativo da Solana responsável por três operações principais: criar novas contas (alocando espaço de dados na blockchain), atribuir a propriedade da conta (definindo o campo do proprietário para um programa específico) e transferir SOL entre contas do sistema. Cada nova conta Solana começa como uma conta do sistema. Os desenvolvedores invocam a instrução Create Account do Programa do Sistema para provisionar contas de dados para seus programas.

Quantos tipos de contas existem na Solana?

Existem três tipos principais de contas na Solana: (1) Contas do Sistema, de propriedade do Programa do Sistema e usadas para saldos de SOL e carteiras de usuários; (2) Contas de Programa, contas executáveis que armazenam bytecode BPF compilado; (3) Contas de Dados/Estado, de propriedade de programas e que armazenam o estado específico do aplicativo. Contas de Token são um subconjunto especializado de contas de dados de propriedade do SPL Token Program.

Principais Conclusões e Próximos Passos

O modelo de conta da Solana exige mais reflexão inicial do que o modelo com estado da Ethereum, mas esse investimento cognitivo é o que torna possível a execução paralela.

• Cada parte do estado na Solana reside em uma conta; os programas leem e gravam em contas passadas durante a execução, não em armazenamento interno
• Cada conta tem cinco campos: lamports, dados, proprietário, executável e o legado rent_epoch
• Somente o programa proprietário pode modificar o campo de dados de uma conta; este é o principal mecanismo de controle de acesso da Solana
• Contas de produção são financiadas até o limite de isenção de aluguel e nunca são coletadas automaticamente pelo tempo de execução (garbage-collected)
• Endereços Derivados de Programa permitem a custódia controlada por programa sem a necessidade de confiança, usando endereços fora da curva que não possuem chave privada
• O tempo de execução Sealevel da Solana paraleliza a execução de transações analisando listas de acesso a contas declaradas em transações não conflitantes

Pronto para construir sobre esta base? Continue com:

• Como os programas Solana funcionam: um guia do desenvolvedor para execução sem estado
• Guia do framework Anchor para construção de programas Solana
• Invocação entre programas (CPI) explicada: como os programas Solana chamam uns aos outros
• Como funciona o Proof of History na arquitetura da Solana

Para as especificações de protocolo mais recentes sobre tamanhos de conta, cálculos de aluguel e comportamento de tempo de execução, consulte diretamente a documentação oficial de contas da Solana.