Modelo de Conta Solana: Guia Técnico

Este Guia Técnico do Modelo de Conta Solana explica os campos de runtime e as regras de acesso em que os programas se baseiam, incluindo propriedade, contas executáveis, contas de tokens, isenção de renda, Endereços Derivados de Programas, Contas de Token Associadas e Invocação entre Programas (Cross-Program Invocation).

Detalhes de implementação como a gestão de renda, limites de tamanho de conta e APIs de cliente podem mudar. Os programadores devem consultar a documentação atual da Solana e consultar os parâmetros atuais da rede antes de implementar.

Cada transação na Solana toca numa conta. Cada token que possui, cada programa que implementa, cada NFT que emite: tudo isso vive em contas. Antes de escrever uma única linha de código Solana, compreender como as contas funcionam não é um conhecimento de fundo opcional. É o pré-requisito para tudo o resto.

Pense na Solana como um armário de arquivo. Cada gaveta contém uma pasta e cada pasta tem um rótulo (o seu endereço), conteúdo (os seus dados), um carimbo de saldo e o nome de um departamento na capa indicando qual programa tem autoridade para editar o que está lá dentro. Quer seja um programador a migrar da Ethereum, um investigador a avaliar a arquitetura da Solana ou um estudante a formar o seu primeiro modelo mental de gestão de estado na blockchain, este guia cobre o quadro completo: anatomia da conta, tipos de conta, regras de propriedade, mecânica de renda, Endereços Derivados de Programas, uma comparação lado a lado com a 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 gestão de estado da blockchain Solana. Cada elemento de estado na Solana, incluindo saldos de tokens, lógica de programas, dados de utilizadores e configuração do sistema, é armazenado em contas discretas identificadas por chaves públicas únicas de 256 bits. Consulte a documentação oficial de contas da Solana) para a especificação canónica.

Cada elemento de estado na Solana vive numa conta. Os programas não armazenam os seus próprios dados; eles leem e escrevem em contas que lhes são passadas 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 arquivo mapeia diretamente a estrutura de dados: o armário é a blockchain Solana, as pastas são contas, o rótulo de cada pasta é a sua chave pública (o endereço on-chain), o conteúdo da pasta é o campo de dados, o carimbo do saldo é o campo de lamports e o carimbo do departamento na capa é o campo do proprietário (owner) que regista qual programa tem autoridade de escrita. Apenas o departamento nomeado nesse carimbo pode alterar o que está lá dentro.

Se vem da Ethereum, esta distinção é importante: os smart contracts da Ethereum armazenam o seu próprio estado internamente, enquanto os programas da Solana são stateless (sem estado). A comparação completa encontra-se numa secção dedicada abaixo.

Anatomia de uma Conta Solana

Cada conta Solana, quer armazene SOL, código de programa ou estado da aplicação, é construída a partir dos mesmos cinco campos.

Os Cinco Campos de Cada Conta Solana

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

lamports: o saldo de SOL desta conta, expresso em Lamports (a menor denominação da Solana, explicada na próxima secção). Na analogia do armário de 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 necessite. Para uma conta de programa, este campo contém bytecode BPF compilado. Para uma conta de dados, contém o estado da aplicação serializado. Os programas definem o seu próprio formato de serialização (geralmente Borsh) para ler e escrever dados estruturados neste campo. O equivalente no armário de arquivo é 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 contentor de dados.

rent_epoch: um campo legado que anteriormente rastreava o tempo de recolha de renda. Este campo está a ser descontinuado e não tem relevância operacional para contas isentas de renda (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 o seu endereço como o seu identificador na blockchain. O tamanho máximo do campo de dados para uma única conta é de 10 MB de acordo com as recentes atualizações do protocolo; verifique os limites atuais na documentação de contas da Solana,), uma vez que este 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 tem o nome de Leslie Lamport, um cientista de computação cujo trabalho em sistemas distribuídos e tolerância a falhas serve de base a grande parte da teoria moderna de computação distribuída. Os Lamports existem porque toda a aritmética on-chain, incluindo cálculos de renda, taxas de transação e saldos de conta, deve utilizar aritmética de inteiros para evitar erros de precisão de vírgula flutuante. Expressar valores em Lamports torna cada cálculo exato.

Uma Conta Solana é o mesmo que uma Carteira?

Uma conta Solana e uma carteira não são a mesma coisa. O que pensa ser a sua carteira, a aplicação Phantom ou Solflare no seu telemóvel, é software fora da blockchain que gere uma chave privada. A entidade na blockchain é uma conta de sistema que detém o seu saldo de SOL. A sua carteira controla uma conta de sistema; ela própria não é uma conta. Contas de tokens, contas de programas e contas de dados não têm equivalente em carteira: são puramente contentores de dados na blockchain que nenhuma aplicação de carteira de consumo representa diretamente.

Tipos de Contas Solana

As contas Solana dividem-se em quatro categorias, cada uma definida pelo seu programa proprietário e pela flag de executável.

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

Contas de Sistema

As contas de sistema são propriedade do Programa de Sistema, e as carteiras dos utilizadores são contas de sistema. O Programa de Sistema é o programa nativo da Solana responsável por três operações fundamentais: 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 propriedade do Programa de Sistema.

O Programa de Sistema tem um endereço bem conhecido: 11111111111111111111111111111111 (32 uns em base58). Consulte a documentação do Programa de Sistema) para o seu conjunto completo de instruções. Quando um programador cria uma conta de dados para o seu programa, invoca a instrução Create Account do Programa de Sistema, especificando o tamanho dos dados, o depósito de Lamports isento de renda e a chave pública do novo programa proprietário.

Contas de Programa

As contas de programa armazenam bytecode BPF compilado, não estado. A flag executável nestas contas está definida como true. Os programas são sem estado: quando um programa é executado, recebe uma lista de contas para ler ou escrever através da instrução da transação. Não mantém nenhum estado interno entre chamadas. Se vier do Ethereum, poderá conhecer o código executável on-chain como contratos inteligentes, mas os programas Solana funcionam de forma fundamentalmente diferente porque não transportam o seu próprio estado. As contas de programa são propriedade do programa BPF Loader. Uma vez implementada, uma conta de programa é imutável, a menos que um par de chaves de autoridade de atualização tenha sido designado durante a implementação.

Contas de Dados e Estado

As contas de dados armazenam o estado da aplicação que os programas leem e escrevem durante a execução. A flag executável nestas 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 utilizador num protocolo DeFi, metadados NFT, ou um contador de aplicação. O programa proprietário é a única entidade que pode escrever no campo de dados desta conta, uma regra abordada em detalhe na secção de propriedade.

Contas de Token e Contas de Token Associadas

As contas de token são contas de dados propriedade do programa SPL Token, cada uma detendo um saldo de um token específico para uma carteira específica. Um único endereço de carteira pode deter várias contas de token, uma para cada tipo de token que detém.

Uma Conta de Token Associada (ATA) é a conta de token canónica para um par específico [endereço de carteira, endereço de 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 de mint do token como sementes. Isto garante que cada carteira tem 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 recebe um token na sua interface de carteira, ele vai para a sua ATA para esse token.

Se uma ATA não existir para um determinado par [carteira, mint], tem de ser criada antes de os tokens poderem ser recebidos, e a criação custa um depósito de Lamport isento de renda. É 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 da SPL Associated Token Account.). Uma ATA é uma conta de token, mas nem todas as contas de token são ATAs, e a distinção é importante ao depurar programas relacionados com tokens.

Propriedade da Conta: Como Solana Controla o Acesso aos Dados

A propriedade da conta em Solana é um mecanismo de autoridade de escrita, não um conceito de propriedade de ativo.

A Regra de Propriedade

Apenas o programa proprietário da conta pode modificar o seu campo de dados. Nenhum outro programa pode escrever nele, independentemente do que o utilizador autoriza ao nível da transação. O campo proprietário em AccountInfo armazena a chave pública do programa que detém esta autoridade. Programas não proprietários podem ler o campo de dados livremente, mas a escrita requer ser o proprietário designado.

O programa System atribui a propriedade durante a criação da conta. Quando um programador cria uma conta de dados para o seu programa, a instrução Create Account define o campo proprietário com a chave pública do 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 na gestão de contas Solana. O proprietário é o programa registado no campo proprietário da conta, significando o programa que pode escrever no campo de dados. A autoridade (ou signatário) é o par de chaves que pode assinar transações para a conta.

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

Um programa DEX só pode escrever em contas que possui diretamente. Para transferir tokens da conta de um utilizador (propriedade do programa SPL Token, não do DEX), o DEX não pode escrever diretamente nessa conta. Os 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 programa Token a mover tokens em nome de um utilizador. O DEX envia uma CPI para o programa Token, fornecendo a autorização assinada pelo utilizador, e o programa Token realiza a escrita no campo de dados da conta de token do utilizador. É assim que o modelo de propriedade do programa se estende às interações entre programas. Para um guia completo, consulte o guia de Invocação Entre Programas (CPI) para programadores Solana.

Renda da Conta e Isenção de Renda

A renda Solana é um mecanismo de custo de armazenamento, não uma taxa recorrente.

O Que é Renda?

Renda é o mecanismo da Solana para precificar o armazenamento on-chain. Cada conta deve manter um saldo mínimo de SOL proporcional ao seu tamanho de dados para permanecer ativa on-chain. A correção que a maioria do conteúdo concorrente omite: a renda não é uma taxa recorrente na prática. O padrão de produção é a isenção de renda, onde depositar SOL suficiente antecipadamente para cobrir aproximadamente dois anos de armazenamento torna uma conta permanentemente isenta de qualquer dedução de renda. A esmagadora maioria das contas implementadas opera sob isenção de renda.

A isenção de renda é o padrão de produção para todas as contas Solana implementadas. O saldo mínimo para isenção de renda é aproximadamente 6.960 Lamports multiplicados pelo tamanho dos dados da conta em bytes, mais um montante 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. Estes valores são aproximados e sujeitos a alterações. Verifique os valores atuais com o comando CLI da Solana solana rent <bytes> ou com a documentação da renda Solana.). Uma alteração proposta para converter a renda num modelo de taxa de transação não foi ativada até à data de escrita; consulte a documentação atual para o estado mais recente do protocolo.

O Que Acontece Quando uma Conta Fica Sem SOL?

A criação de conta atual geralmente requer financiamento isento de renda. Os programadores devem consultar os requisitos atuais de RPC em vez de dependerem do comportamento legado de recolha de renda. Este é o comportamento que levanta preocupações sobre contas a serem "eliminadas".

Contas isentas de renda nunca são fechadas automaticamente pelo runtime. As contas de produção são sempre financiadas até ao limiar de isenção de renda, pelo que a recolha de lixo 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 Lamport. Num protocolo DeFi, por exemplo, fechar uma posição de empréstimo liberta o SOL que financiou a conta de dados dessa posição de volta para o utilizador. Este é um padrão de design de protocolo comum, não uma eliminaçã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 possua 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 a partir 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 têm chave privada correspondente. Apenas o programa proprietário pode assinar transações para contas em endereços PDA. Veja a documentação de PDAs da Solana) para a especificação completa.

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

Porque as PDAs são importantes: Custódia controlada pelo programa

A consequência de não ter uma chave privada é que apenas o programa proprietário pode autorizar transações para uma PDA. Isto permite uma custódia fidedigna controlada pelo programa: o programa detém a autoridade sobre a conta sem depender de nenhum humano para salvaguardar uma chave privada.

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

Três Casos de Uso de PDAs no Mundo Real

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

DEX contas de garantia: um programa de corretora descentralizada detém tokens numa PDA até que ambos os lados de uma troca satisfaçam as condições exigidas. Nenhuma intermediária de confiança detém uma chave privada da conta de garantia. A lógica do programa controla a libertação, e nenhum participante pode drenar os fundos fora das regras do protocolo.

Nenhum indivíduo pode fazer uma "puxada de tapete" à autoridade de mint de uma coleção NFT. A NFT autoridade de mint funciona fazendo com que os programas Metaplex controlem a mintagem através de uma PDA derivada do endereço de mint. Como não existe uma chave privada para esta PDA, as regras de mintagem da coleção são impostas apenas pelo código do programa após a implementação.

Como é que um programa armazena dados por utilizador sem manter um índice centralizado? O armazenamento de estado por utilizador usa uma PDA única derivada de [program_id, user_pubkey]. Isto produz um endereço de conta determinístico e específico do utilizador para armazenar a pontuação do jogo desse utilizador, posição de empréstimo, ou registo de Staking. O programa sabe sempre onde encontrar os dados de cada utilizador.

As funções findProgramAddress() e createProgramAddressSync() localizam endereços válidos fora da curva testando endereços candidatos com uma seed de incrementação até que um saia da curva.

Quando Deve Usar uma PDA?

Use uma PDA sempre que o seu programa precisar de controlar uma conta sem depender da chave privada de um humano. Se a autoridade da conta dever ser lógica de programa em vez de uma pessoa, use uma PDA. Esta regra cobre contas de garantia, cofres de protocolo, autoridades de mint e qualquer estado que o próprio programa deva possuir e gerir entre múltiplos utilizadores.

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 reside o estado.

Na Ethereum, os contratos inteligentes são stateful (com estado): armazenam o seu próprio estado internamente juntamente com o seu código. Um contrato Solidity mantém os seus próprios mapeamentos e variáveis de estado dentro do armazenamento do contrato, gerido pela Ethereum Virtual Machine (EVM). Na Solana, os programas são stateless (sem estado); todo o estado vive em contas externas que os programas leem e escrevem durante a execução. Onde 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 acarreta uma vantagem genuína na experiência do programador: modelo mental mais simples, sem gestão explícita de contas, menor sobrecarga cognitiva para muitos casos de uso. Um programador pode escrever e implementar um contrato ERC-20 sem pensar no dimensionamento das contas de dados, depósitos isentos de renda ou derivação de PDAs.

O modelo stateless da Solana troca essa simplicidade por paralelismo de execução e separação de preocupações. 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 conflituantes simultaneamente. Outras blockchains de Camada 1, como Aptos e Sui, adotam as suas próprias variantes de separação de estado baseada em recursos, cada uma com perfis de compensação diferentes. Nem a abordagem da Ethereum nem a da Solana são categoricamente superiores; refletem diferentes prioridades de design para diferentes cargas de trabalho.

Porque esta Arquitetura é Importante: Sealevel e Execução Paralela

Programas stateless não são uma limitação de design; 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 Solana são stateless. Segundo, como os programas não carregam estado, cada transação deve declarar todas as contas a que acederá, tanto leituras como escritas, antes de o início da execução. Terceiro, o motor de execução paralela da Solana, Sealevel, analisa estas listas de acesso a contas antes do agendamento. Quarto, as transações que acedem a conjuntos de contas não sobrepostos não têm dependências de dados umas nas outras e podem executar-se simultaneamente em múltiplos núcleos de processador. Quinto, o resultado é uma rede capaz de processar dezenas de milhares de transações por segundo.

Anatoly Yakovenko desenhou a arquitetura da Solana com o processamento paralelo de transações como um objetivo explícito, e a separação da lógica do programa do estado da conta é o que o torna possível. O modelo de conta funciona em conjunto com as 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 esta taxa de transferência, consulte o explicador sobre como o Proof of History funciona na arquitetura da Solana.

Construir com Contas: Implementação do Programador

Todas as contas com as quais um programa Solana trabalha devem ser criadas, financiadas e atribuídas a um proprietário antes que o programa possa ler ou escrever nelas.

Criar uma Conta com o System Program

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

1. from_pubkey: identificar a conta que financia a criação (o pagador)
2. new_account_pubkey: especificar o endereço da nova conta
3. lamports: calcular o montante do saldo isento de renda com base no tamanho dos dados
4. space: definir o tamanho dos dados em bytes a alocar para a conta
5. owner: especificar a chave pública do programa que possuirá e escreverá nesta conta

// Criar uma nova conta de dados usando o System Program
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 ficar isento de renda
    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 sua execução, apenas o programa em program_id pode escrever no campo de dados desta conta.

Utilizar o Anchor Framework

Muitos programas 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 obter a referência completa do framework.

// Anchor: define restrições da conta usando a macro #[derive(Accounts)]
#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,                        // cria esta conta se não existir
        payer = user,                // o utilizador paga o depósito isento de renda
        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 trata automaticamente do código repetitivo de validação de contas, verificando a propriedade e o estado de signatário antes da execução da sua lógica de instrução. Compreender o modelo de conta subjacente continua a ser necessário ao depurar erros de propriedade ou ao projetar estruturas de PDA, porque as macros do Anchor são abstrações sobre os mesmos mecanismos descritos ao longo deste artigo.

Recursos Relacionados da Arquitetura Solana

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

FAQ: Modelo de Conta Solana: Guia Técnico

O que é uma conta em Solana?

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

No Ethereum, os contratos inteligentes armazenam o seu próprio estado internamente juntamente com o seu código. Em Solana, os programas são sem estado; todo o estado reside em contas externas que os programas leem e escrevem durante a execução. Esta separação permite que o tempo de execução Sealevel da Solana detete padrões de acesso a contas não sobrepostos e execute várias transações simultaneamente, permitindo o processamento paralelo em escala.

Todas as contas de produção Solana são financiadas para o limiar de isenção de renda, tornando-as permanentemente isentas de encargos de armazenamento. A renda é o mecanismo subjacente: as contas devem manter um Saldo de SOL mínimo proporcional ao tamanho dos seus dados para permanecerem ativas na blockchain. As contas isentas de renda, aquelas financiadas acima do limiar, nunca são fechadas automaticamente pelo tempo de execução.

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 usando hashing SHA-256. Os PDAs caem da curva elíptica ed25519, pelo que não têm uma chave privada correspondente. Apenas o programa proprietário pode assinar transações para contas em endereços PDA, permitindo a custódia sem confiança controlada pelo programa para contas de custódia, autoridades de mint e armazenamento de estado por utilizador.

A criação atual de contas geralmente requer financiamento isento de renda. Os programadores devem consultar os requisitos atuais do RPC em vez de dependerem do comportamento legado de cobrança de renda. As contas de produção devidamente implantadas são sempre financiadas para o limiar de isenção de renda 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 DeFi.

Os Lamports são a menor denominação de SOL na blockchain Solana: 1 SOL equivale a 1.000.000.000 Lamports (10⁹). Nomeados em homenagem a Leslie Lamport, um 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 renda na blockchain. A denominação de montantes em Lamports evita erros de precisão de ponto flutuante que surgiriam do uso de valores fracionários de SOL na aritmética on-chain.

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 propriedade de conta (definir o campo proprietário para um programa especificado) e transferir SOL entre contas do sistema. Cada nova conta Solana começa como uma conta do sistema. Os programadores invocam a instrução Create Account do Programa do Sistema para provisionar contas de dados para os seus programas.

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

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

• Cada peça de estado em Solana reside numa conta; os programas leem e escrevem 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
• Apenas o programa proprietário pode modificar o campo de dados de uma conta; este é o principal mecanismo de controle de acesso da Solana
• As contas de produção são financiadas para o limiar de isenção de renda e nunca são coletadas automaticamente pelo tempo de execução
• Os Endereços Derivados de Programa permitem a custódia sem confiança controlada pelo programa usando endereços off-curve que não têm chave privada
• O tempo de execução Sealevel da Solana paraleliza a execução de transações analisando listas declaradas de acesso a contas entre transações não conflituantes

Pronto para construir sobre esta fundação? Continue com:

• Como funcionam os programas Solana: um guia para programadores sobre execução sem estado
• Guia do framework Anchor para construir programas Solana
• Invocação entre Programas (CPI) explicada: como os programas Solana se chamam uns aos outros
• Como funciona a Prova de Histórico na arquitetura da Solana

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