Modelo de Conta Solana Explicado

O Modelo de Conta Solana armazena saldos, código de programa, detenções de tokens e estado da aplicação em contas separadas com regras explícitas de propriedade. Este guia em linguagem simples explica o modelo para leitores em geral antes de passar para os campos, tipos de contas, isenção de renda e exemplos do mundo real.

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

Se vem da Ethereum, o modelo de conta da Solana parecerá invertido no início. Essa reação é o ponto de partida correto. O modelo mental que construiu na Ethereum não se transfere facilmente, e tentar forçá-lo cria confusão a cada passo.

O modelo de conta Solana é o sistema arquitetónico pelo qual todo o estado on-chain é armazenado em unidades discretas de armazenamento chamadas contas. Cada saldo de carteira, programa, detenção de token e registo de estado de aplicação reside numa conta separada com um proprietário definido, um saldo em lamports 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 arquivo. Cada peça de dados reside num ficheiro separado chamado conta. Os programas são as aplicações que leem e escrevem esses ficheiros, mas um programa só pode modificar um ficheiro que possui. O runtime impõe essas regras de propriedade a nível de protocolo, sem exceções.

Este artigo aborda os cinco campos dentro de cada conta Solana, os cinco tipos distintos de contas, como funcionam as rendas (rent) e a isenção de renda, o que são Endereços Derivados de Programa (PDAs) e porquê existem, como as contas são criadas e fechadas, e porquê esta arquitetura torna possível o processamento paralelo de transações da Solana. Os programas Solana são escritos em Rust (ou C/C++), embora frameworks como o Anchor abstraiam grande parte do código repetitivo de gestão de contas. Este artigo aborda a base conceptual que ambos requerem.

Modelo de Conta Solana: Anatomia de uma Conta

Uma conta Solana é um espaço de armazenamento rotulado na rede que detém um saldo em lamports, uma carga útil de dados arbitrária e um conjunto de campos de metadados que definem quem é o seu proprietário e o que pode fazer. Na Solana, todos os dados, desde saldos de carteira a estado de programa a detenções 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 os cêntimos são para um dólar, exceto com nove casas decimais de precisão: 1 SOL equivale a 1.000.000.000 de lamports. Cada conta detém um saldo em lamports que financia a existência continuada 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 renda e pode ser transferido para outras contas.
• data (array de bytes): Armazenamento binário bruto. Em contas executáveis, este campo detém código de compilação BPF/SBF. Em contas de dados, detém estado de aplicação estruturado. 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 escrita sobre o campo de dados desta conta. Este é o campo mais contraintuitivo para desenvolvedores Ethereum. O seu endereço de carteira não lhe pertence a nível de protocolo; pertence ao Programa do Sistema (System Program). Um tratamento completo do campo de proprietário aparece na secção de propriedade e autoridade da conta.
• executable (bool): Uma bandeira booleana. Quando verdadeira, o campo de dados contém código de compilação do programa e a conta funciona como um programa. Quando falsa, a conta armazena estado ou detém um saldo.
• rent_epoch (u64): Um campo legado que rastreava a época em que a renda foi coletada pela última vez. A partir de 2024, a coleta de renda foi descontinuada em favor do modelo de isenção de renda por defeito. Este campo persiste na estrutura da conta, mas já não é ativamente utilizado.

Aqui está o aspeto de uma conta de carteira como estrutura de dados:

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

O campo de proprietário é um conceito a nível de protocolo: o programa que controla o acesso de escrita ao campo de dados. A autoridade é uma convenção separada armazenada dentro dos dados geridos pelo programa, como o campo de autoridade de transferência dentro de uma conta de token. Estas não são a mesma coisa; a secção de propriedade traça esta distinção precisamente.

Os Cinco Tipos de Contas Solana

A Solana tem cinco tipos distintos de contas, cada uma servindo uma função arquitetónica específica determinada pelo seu campo de proprietário e pela sua bandeira executável. O tipo não é armazenado como um campo separado; é inferido de quem é o proprietário da conta e se ela contém código executável.

Contas Propriedade do Sistema (Contas de Carteira)

Uma conta propriedade do sistema detém o saldo SOL de um utilizador e nada mais. O proprietário é sempre o Programa do Sistema (11111111111111111111111111111111), a bandeira executável é falsa, e o campo de dados está vazio. Quando partilha o seu endereço de carteira com Phantom ou Solflare, está a partilhar o endereço de uma conta propriedade do sistema. Você controla-a assinando transações com a sua chave privada, mas o Programa do Sistema é o proprietário a nível de protocolo.

Contas de Programa (Contas Executáveis)

Uma conta de programa é uma conta executável contendo código de compilação BPF/SBF. A bandeira executável é verdadeira, e o proprietário é o BPF Loader. As contas de programa são stateless por design; detêm apenas código, nunca estado. Na Ethereum, um smart contract armazena tanto o seu código como o seu estado num único endereço de contrato. Na Solana, o código reside numa conta de programa e o estado reside em contas de dados separadas, sempre armazenadas à parte.

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

Contas de Dados (Contas Propriedade de Programa)

Uma conta de dados é uma conta não executável propriedade de um programa específico que armazena o estado do programa no seu campo de dados. A bandeira executável é falsa. O proprietário é qualquer programa que criou e gere a conta. O seu saldo de token USDC, uma posição de empréstimo DeFi, um registo de metadados NFT: cada um reside na sua própria conta de dados dedicada propriedade do programa relevante.

Contas de programa nativas são programas incorporados implantados em endereços fixos durante a génese da rede. Incluem o Programa do Sistema, 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 pelos utilizadores. A sua bandeira executável é verdadeira.

As contas Sysvar são contas de leitura-apenas pré-carregadas pelo runtime Solana que dão aos programas acesso ao estado atual da rede. Pense nas contas sysvar como um quadro de anúncios governamental num tribunal: legível publicamente, mantido por uma fonte autoritária, mas nenhuma parte privada as pode modificar. O Clock sysvar em SysvarC1ock11111111111111111111111111111111 fornece o timestamp atual do bloco e o número do slot. O Rent sysvar fornece os parâmetros atuais de renda.

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

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

Os programas da Solana são sem estado. Não contêm dados próprios e cada peça de estado com que operam reside em contas de dados separadas passadas ao programa em tempo de execução.

Pense num programa da Solana como o software de processamento de transações de um banco e nas contas de dados como registos individuais de contas de clientes. O software sabe como processar depósitos e levantamentos, mas o saldo real reside no ficheiro do cliente, não dentro do próprio software. No Ethereum, o equivalente é um banco onde o software e o registo de cada cliente partilham a mesma sala fechada, com o programa e o seu estado inseparáveis num ú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 que lhes são passadas no momento da chamada. Não mantêm o seu próprio estado.
• Os programas são imutáveis após a sua implementação, a menos que o programador tenha escolhido o carregador atualizável no momento da implementação.
• Apenas o programa que possui uma conta de dados pode modificar os dados dessa conta. Qualquer utilizador pode chamar um programa, mas o acesso de escrita a qualquer conta é restrito pela propriedade.
• O sinalizador executable impõe esta distinção ao nível do protocolo e não pode ser alterado após a implementação.

Os programas da Solana são sem estado, mas o sistema Solana como um todo tem estado. O estado persiste; reside nas contas de dados. A distinção é que o estado é sempre externo ao programa, nunca incorporado nele.

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

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

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

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

Considere um cofre de segurança num banco. O banco é o proprietário do cofre e é a única entidade que pode fisicamente abrir e modificar o seu conteúdo. Você detém uma chave que lhe permite instruir o banco sobre o que fazer com o 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 programadores Ethereum:

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

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

Renda de Conta Solana e Isenção de Renda Explicadas

A renda na Solana é uma taxa de armazenamento, denominada em lamports, cobrada às contas para compensar os validadores pela manutenção do estado na blockchain. As contas que mantêm um saldo mínimo de lamports, o limiar de isenção de renda, estão permanentemente isentas de encargos de renda e nunca serão eliminadas pelo runtime.

O que é a Renda na Solana?

Os validadores têm de armazenar todo o estado ativo da conta na memória. Um número ilimitado de contas com saldo zero seria um vetor de negação de serviço contra a rede, pelo que a Solana exige que as contas mantenham um saldo mínimo de lamports como compromisso de pagamento dos custos de armazenamento. O modelo de renda original cobrava taxas por época proporcionais ao tamanho dos dados, com contas abaixo do mínimo sujeitas a recolha de lixo. Esse modelo foi descontinuado.

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

Para tornar a sua conta isenta de renda, financie-a com pelo menos o saldo mínimo de lamports para o seu tamanho de dados ao submeter a transação de criação. Com os atuais parâmetros de 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 exato atual utilizando a CLI da Solana ou o método RPC getMinimumBalanceForRentExemption:

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

A isenção de renda funciona como um depósito de segurança num espaço de arrumação. Bloqueia um saldo mínimo de lamports para garantir a existência da conta na rede. Ao contrário de uma taxa, este depósito é totalmente recuperável. Quando fecha a conta, esses lamports retornam para si.

A denominação de lamport utilizada em todos os cálculos de renda está definida na secção de anatomia da conta. Para tornar uma conta de dados isenta de renda quando o seu programa a cria, chame getMinimumBalanceForRentExemption(dataSize) no lado do cliente antes de construir a transação de criação, e depois inclua esse montante de lamports na instrução.

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

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

No Ethereum, os smart contracts juntam o seu código e estado num único endereço. Uma conta de contrato detém tanto a lógica como os dados com que opera. Na Solana, o código e o estado estão sempre em contas separadas: os programas (lógica) residem em contas executáveis, e todo o estado reside em contas de dados distintas possuídas por esses programas. Esta separação é a base arquitetónica de tudo o que a Solana faz de forma diferente.

O Bitcoin adota uma abordagem totalmente diferente, utilizando um modelo UTXO (Unspent Transaction Output). Os UTXOs são como cheques não gastos num talão de cheques: cada transação consome saídas existentes e cria novas. Não existe uma conta persistente a manter um saldo ao longo do tempo. O seu saldo é a soma das saídas não gastas associadas às suas chaves. O modelo do Bitcoin é anterior ao conceito de estado programável, razão pela qual as suas capacidades de smart contract são limitadas ao Bitcoin Script.

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

No Ethereum, as carteiras dos utilizadores são chamadas de Externally Owned Accounts (EOAs). Na Solana, o equivalente é uma conta detida pelo sistema controlada por um par de chaves; o mecanismo é semelhante, mas o campo do proprietário é explicitamente definido para o System Program em vez de ser implícito.

O que os Programadores de Ethereum Devem Desaprender

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

1. Os programas não detêm o seu próprio estado. As contas de dados detêm. Pare de procurar pelo estado no endereço do programa.
2. O proprietário da sua carteira não é você ao nível do protocolo. Você controla a conta através da assinatura; o System Program detém o campo de dados.
3. O armazenamento não é gratuito. Cada conta de dados requer um depósito de lamports para isenção de renda. Orçamente este custo ao desenhar programas que criam contas.

A separação rigorosa da Solana entre código e estado é o pré-requisito para a execução paralela, uma ligação explorada na totalidade na secção Sealevel e execução paralela.

Como o Modelo de Conta Potencia 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 escrever antes de a execução começar. O Sealevel, o runtime de Smart Contract paralelo 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 a que irá aceder, cada uma marcada como de leitura apenas ou leitura-escrita, antes de ocorrer qualquer execução.
2. O Sealevel inspeciona todas as transações pendentes no slot atual.
3. As transações que partilham pelo menos uma conta de leitura-escrita são sequenciadas. As transações que acedem a contas inteiramente diferentes são identificadas como não conflituosas.
4. As transações não conflituosas são executadas simultaneamente em vários núcleos de CPU.

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

Pense no Sealevel como um supermercado com muitas caixas de pagamento. Cada transação é um cliente com uma lista declarada de Item. Desde que dois clientes não tentem pegar no mesmo Item, eles pagam 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 aos validadores concordarem com a ordem das transações sem coordenação em tempo real. A Solana utiliza Proof of Stake (PoS) para consenso, onde os validadores investem SOL em staking para participar na 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, esta arquitetura permite ao Sealevel processar transações não conflituosas em paralelo sem esperar por confirmação em toda a rede a cada passo.

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 débito 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 DeFi, é uma conta Solana com uma estrutura de dados específica. A arquitetura abstrata descrita acima manifesta-se em três padrões que todos os utilizadores de Solana encontram.

Contas de Token SPL

Os tokens SPL, o equivalente da Solana aos tokens ERC-20 do Ethereum, são geridos pelo SPL Token Program, que detém todas as contas de token na rede. O endereço da sua carteira detém apenas SOL (lamports). Cada token que possui, seja USDC, JTO, BONK ou qualquer outro, vive na sua própria conta de token dedicada detida pelo 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 o token que esta conta detém), a chave pública da autoridade proprietária (o endereço da sua carteira, que autoriza transferências) e o Saldo de tokens atual. No Ethereum, todos os saldos ERC-20 para um determinado token vivem dentro do mapeamento interno do contrato do token. Na Solana, cada par (utilizador, token) requer a sua própria conta dedicada.

É por isso que as carteiras Solana solicitam a criação de uma conta de token ao receber um novo token pela primeira vez. Essa criação requer um depósito de lamports para isenção de renda 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 Associated Token Account (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 a sua conta USDC deve estar sem armazenar uma tabela de consulta. As ATAs são o tipo de conta de token padrão utilizado por virtualmente todas as carteiras e protocolos Solana.

As ATAs são uma aplicação da derivação de PDA. Pode ter múltiplas contas de token para a mesma emissão, mas a sua ATA é a canónica que os protocolos utilizam por defeito.

NFTs na Solana

Um NFT na Solana consiste em, pelo menos, duas contas: uma Conta de Emissão (Mint Account) detida pelo Token Program que define a oferta do token como exatamente 1, e uma Conta de Metadados (Metadata Account) detida pelo 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 vive na conta de metadados. O Saldo do token (1 NFT) é armazenado numa conta de token, idêntica a qualquer outro token SPL.

Os protocolos DeFi na Solana, incluindo exchanges descentralizadas, plataformas de empréstimo e pools de liquidez, armazenam cada Posição de utilizador, estado de pool e configuração de protocolo em contas de dados dedicadas, com PDAs detidos pelo programa a controlar os fundos em pool de forma autónoma.

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

Nota: Esta secção explica como o modelo de conta 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 dos programadores. O SOL, disponível nas principais exchanges de criptomoedas, serve como o token utilitário nativo da rede. O modelo de conta é o mecanismo principal através do qual o SOL é solicitado e utilizado na camada de rede.

O SOL é utilizado no modelo de conta através de três mecanismos distintos:

Depósitos para isenção de renda: Cada conta na Solana deve deter um saldo de lamports para existir na rede. Com milhões de contas de token, contas de dados de programas, registos de NFT e contas de estado de DeFi ativas a qualquer momento, isto cria uma procura de base persistente por SOL. Estes lamports são bloqueados em contas e 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 com cada transação.

Investir em staking de validadores: Os validadores investem em staking de SOL para participar no 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, mais protocolos DeFi, mais coleções NFT, mais lançamentos de tokens, o número de contas cresce proporcionalmente. Mais contas requerem mais SOL bloqueado em depósitos de isenção de renda.

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

Recursos Relacionados com a Arquitetura Solana

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

FAQ: Modelo de Contas da Solana

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

Na Ethereum, um Smart Contract armazena tanto o seu código como o seu estado num ú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 pertencentes a esses programas. Esta separação permite que o Sealevel execute transações não conflituantes em paralelo, o que não é possível com o modelo de estado colocado da Ethereum.

O que é a renda na Solana e como funciona?

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

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

Um PDA é um endereço de conta Solana derivado deterministicamente de um ID de programa e de um conjunto de valores semente. Não tem uma chave privada correspondente, pelo que apenas o programa que o derivou pode autorizar transações em seu nome através de Invocação Entre Programas (Cross-Program Invocation). Os PDAs dão aos programas controlo autónomo e sem confiança sobre as contas, um requisito para protocolos DeFi, custódias NFT e Contas de Token Associadas.

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

Cada transação Solana deve declarar a lista completa de contas que irá ler ou escrever antes da execução. O Sealevel, o tempo de execução de Smart Contract paralelo da Solana, utiliza essas declarações para identificar transações não conflituantes e executá-las simultaneamente em vários núcleos de CPU. Este agendamento estático só é possível porque o código e o estado residem em contas separadas e explicitamente detidas, tornando os conflitos de leitura/escrita detetáveis antes de a execução começar.

O que é o campo proprietário numa conta Solana?

O campo proprietário é 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 SPL Token. O campo proprietário é um conceito de nível de protocolo imposto pelo tempo de execução da Solana. É distinto do campo "autoridade" encontrado dentro de certas contas de dados geridas por programas, tais como contas de token.

Como é que o SOL é utilizado no modelo de conta?

O SOL é utilizado 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 renda; e os validadores que processam e armazenam o estado da conta devem investir em staking de SOL para participar no consenso. À medida que a rede cresce, a procura estrutural por SOL cresce com ela.

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

O Sealevel é o tempo de execução de Smart Contract paralelo da Solana. Pode executar múltiplas transações simultaneamente porque o modelo de conta da Solana exige que cada transação pré-declare quais as contas que irá ler ou escrever. O Sealevel utiliza essas declarações para identificar transações não conflituantes e agendá-las para serem executadas em paralelo. Sem as declarações antecipadas do modelo de conta, este 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, controlada por um par de chaves. Uma conta de programa é uma conta executável com executable = true que contém bytecode BPF/SBF compilado; é propriedade do BPF Loader e não detém qualquer estado próprio. A tabela de tipos de conta na secção Os Cinco Tipos de Contas Solana mostra as cinco variantes lado a lado.

Quantas contas pode uma transação Solana referenciar?

Uma única transação Solana pode referenciar até 64 contas nos parâmetros atuais da Mainnet, um aumento face às 32 originais através de Tabelas de Pesquisa de Endereços (Address Lookup Tables). Cada conta deve ser declarada como apenas de leitura ou de leitura-escrita antes de a execução começar. Esta declaração antecipada é o que permite ao Sealevel agendar a execução paralela sem executar as transações primeiro para detetar conflitos.

Pode uma conta Solana deter vários tokens?

Não. Cada tipo de token SPL requer a sua própria conta de token dedicada. Um endereço de carteira detém apenas SOL; cada token adicional requer uma conta de token separada ligada à carteira através do seu campo de autoridade. É por isso que as carteiras Solana solicitam a criação de uma nova conta de token ao receber um token que não possuía anteriormente, e por que essa criação custa um pequeno depósito de lamports isento de renda.

Conclusões Principais

• Cada parte do estado On-Chain na Solana reside numa 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 requerem um depósito de lamports (isenção de renda) para persistirem na rede. O depósito é recuperável quando a conta é fechada.
• Os PDAs são endereços sem chave privada, derivados de forma determinística a partir de um ID de programa e sementes, assináveis apenas pelo programa que os criou através de CPI.
• Cada transação declara a sua lista de acesso a contas antecipadamente. O Sealevel utiliza essas declarações para executar transações não conflituantes em simultâneo.

Próximos Passos

• Para especificidades de implementação, consulte a documentação de contas da Solana em docs.solana.com.
• Os programadores que estão a criar o seu primeiro programa Solana podem começar com a Anchor framework,, que abstrai grande parte do código repetitivo de gestão 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.