Pontos-chave do Runtime Sealevel
Sealevel é o runtime paralelo da Solana para programas on-chain: ele agenda trabalho a partir do acesso declarado a contas, mede o compute e mantém a lógica do programa separada do estado durável.
//
Busque em todas as páginas da documentação
Sealevel é o runtime paralelo da Solana para programas on-chain: ele agenda trabalho a partir do acesso declarado a contas, mede o compute e mantém a lógica do programa separada do estado durável.
Esta página é o mapa conceitual para Programas & Runtime Sealevel - bytecode executável, o ponto de entrada do SVM, locks de conta, concorrência, orçamentos de compute e loaders no Agave 4.1.1.
Um programa na Solana é uma conta executável: seus dados são bytecode que o runtime tem permissão para executar, não registros de aplicação que você muta instrução por instrução.
O estado durável vive em outras contas que o programa possui (ou pode ler). O binário não embuti um banco de dados crescente de usuários, saldos ou mapeamentos.
Você escreve a lógica em Rust (ou outra linguagem suportada), compila para sBPF (Solana BPF) e faz o deploy do objeto compartilhado para os validadores carregarem.
O SVM (Solana Virtual Machine) nos validadores Agave executa esse sBPF, impõe regras de propriedade, mede o compute e atende chamadas de sistema (syscalls).
Uma instrução nomeia um ID de programa, uma lista de contas e uma fatia opaca de bytes de dados da instrução (instruction-data).
O ponto de entrada do programa é a única função que o runtime chama para cada instrução para aquele programa.
Na forma nativa, o ponto de entrada recebe aproximadamente program_id, uma fatia de valores AccountInfo e os dados da instrução. A macro #[program] do Anchor gera esse ponto de entrada e faz o dispatch para seus handlers com base em um discriminador de 8 bytes.
Toda instrução deve declarar AccountMeta para cada conta que o runtime irá acessar: chave pública, is_signer e is_writable.
Essas flags são solicitações de lock que o Sealevel usa antes de qualquer bytecode ser executado, não dicas opcionais do lado do cliente.
A execução começa fora do seu programa: uma transação é montada com uma ou mais instruções, cada uma listando o ID do programa, contas e dados, então é assinada e submetida com um blockhash recente.
O runtime valida assinaturas, saldo do pagador da taxa (fee payer) e que cada conta que aparece em qualquer instrução está presente na lista de contas da transação com flags de metadados consistentes.
Antes do agendamento, o Sealevel deriva locks desses metadados: uma conta gravável precisa de um lock de escrita exclusivo; uma conta somente leitura (readonly) precisa de um lock de leitura compartilhado.
Múltiplas transações podem manter locks de leitura na mesma conta concorrentemente.
Um lock de escrita exclui outros escritores e leitores naquela mesma conta durante a duração do trabalho conflitante.
Essa regra produz o comportamento central de agendamento: transações cujos conjuntos de contas bloqueadas não entram em conflito podem ser executadas em paralelo; sobreposições de escrita-escrita e escrita-leitura devem serializar.
Chaves de conta:
A = PDA de posição de Alice (gravável nas txs de Alice)
B = PDA de posição de Bob (gravável nas txs de Bob)
G = Cofre global (gravável quando qualquer um o toca)
C = Config (somente leitura em ambos os designs)
Locks disjuntos - podem executar concorrentemente:
Tx1: write(A), read(C)
Tx2: write(B), read(C)
-> locks: A exclusivo, B exclusivo, C compartilhado -> sem conflito
Locks sobrepostos - devem serializar:
Tx3: write(G), write(A), read(C)
Tx4: write(G), write(B), read(C)
-> ambos precisam de G exclusivo -> Tx3 e Tx4 não podem executar em paraleloDentro de uma transação agendada, as instruções executam em ordem; dentro de uma instrução, o SVM carrega o programa, chama o ponto de entrada e passa apenas as contas que essa instrução listou.
Seu handler pode ler dados de conta, escrever apenas contas que possui (e que foram marcadas como graváveis), transferir lamports sob as regras usuais e emitir CPIs (Cross-Program Invocations) para outros programas - mas cada conta que um CPI necessita já deve estar no conjunto declarado da transação.
Enquanto o ponto de entrada executa, o runtime mede as unidades de compute (CU). Syscalls, logging, desserialização e aritmética consomem do orçamento em nível de transação.
Na Solana moderna (incluindo Agave 4.1.1), o orçamento de compute padrão da transação é de aproximadamente 1.400.000 CU, a menos que uma instrução Compute Budget aumente (ou diminua) o limite dentro dos limites do protocolo.
Se qualquer caminho exceder o orçamento restante, a transação falha e as alterações de estado dessa transação não são confirmadas (commit).
CU mede o trabalho permitido; taxas de prioridade (priority fees) influenciam a inclusão sob carga - são controles relacionados, mas com trabalhos diferentes.
Após o sucesso, as atualizações de conta são confirmadas sob os locks já mantidos; transações falhas liberam os locks sem aplicar essas escritas.
Upgrades ficam ao lado da execução, não dentro do estado da aplicação. Com o BPF Upgradeable Loader, a conta do ID do programa aponta para uma conta ProgramData que contém o bytecode.
Uma autoridade de upgrade (upgrade authority) (se definida) pode fazer deploy de um novo .so no ProgramData; limpar essa autoridade congela o caminho de upgrade do loader.
Como os programas são stateless, upgrades trocam a lógica sem migrar o armazenamento do binário - as contas de dados permanecem, então o novo código deve permanecer compatível com o layout ou enviar uma migração explícita.
A decisão de design de maior alavancagem sob Sealevel é o que você marca como gravável (writable).
Uma única conta gravável global - uma configuração "mutex", um ledger compartilhado, um contador global que cada usuário deve tocar - força toda transação concorrente a um único arquivo, não importa quão eficiente seja o sBPF.
Fragmentar (sharding) o estado para que cada usuário (ou cada ordem, posição ou sessão) tenha seu próprio PDA mantém a maioria das transações em chaves disjuntas para que o agendador possa executá-las juntas.
| Design | Contas graváveis por ação do usuário | Paralelismo sob carga | Quando se encaixa | Custo de errar |
|---|---|---|---|---|
| PDAs por usuário / por entidade | Geralmente o PDA desse usuário (+ contas de token conforme necessário) | Alto - usuários diferentes raramente bloqueiam as mesmas chaves | Perfis de usuário, posições, inventários, sessões | Um pouco mais de contas para passar e criar |
| Tabelas fragmentadas (muitos PDAs por chave de fragmento) | Um PDA de fragmento entre muitos | Alto se a carga se espalha entre os fragmentos | Índices de alto throughput, livros de ofertas (order books), filas | Chaves de fragmento "quentes" ainda serializam essa fatia de tráfego |
| Configuração global (somente leitura no caminho quente) | Nenhuma para configuração se apenas leitura | Leitores compartilham o lock da configuração | Parâmetros, taxas de transação, flags de funcionalidade | Marcar a configuração como gravável em toda transação impede o paralelismo |
| Conta mutex global (sempre gravável) | A mesma conta global para todos | Baixo - essencialmente sequencial naquela chave | Operações administrativas raras, invariantes globais verdadeiras que devem serializar | Teto de throughput igual a um escritor por vez |
| Híbrido: caminho quente fragmentado, caminho frio global | PDA do usuário no caminho quente; global apenas em admin/liquidação | Caminho quente escala; caminho administrativo serializa intencionalmente | Mercados que liquidam contra um cofre compartilhado em uma agenda | Colocar acidentalmente o cofre no caminho quente |
Prefira somente leitura (readonly) sempre que você não estiver mutando: um PDA de configuração compartilhado marcado como somente leitura permite que muitas transações mantenham locks de leitura concorrentes.
Mantenha os conjuntos graváveis (writable) mínimos e previsíveis para que os clientes possam construir listas de contas e o grafo de locks permaneça esparso.
Observe as CUs da mesma forma que observa os locks: desserialização de contas grandes, logging verboso com msg! e loops ilimitados queimam orçamento e podem empurrar caminhos comuns em direção ao teto padrão de ~1.400.000 CU.
Solicite um limite maior com uma instrução Compute Budget quando a simulação mostrar que você precisa; ainda assim, otimize o caminho quente para não pagar taxa de prioridade por desperdício.
Pense nos loaders em produção: retenha a autoridade de upgrade apenas enquanto precisar dela, use builds verificáveis e trate upgrades de ProgramData como um processo de controle de mudanças - o comprometimento da autoridade é um risco de reescrita completa do código.
Ao testar em stacks alinhados ao Agave 4.1.1 (CLI 3.0.10, Anchor 0.32.1, LiteSVM 0.6.x, Surfpool 0.12.0), exercite os casos de CU e contas com contenção antes que o tráfego da mainnet o faça.
signer/writable antes do início da execução.Compute Budget.is_writable é opcional se meu código só escreve às vezes." As flags de metadados definem locks e autorização para escritas; subdeclarar contas graváveis ou ausentes falha em tempo de execução ou impede mutações pretendidas.upgradeable loader troca o bytecode no ProgramData; as contas de dados existentes permanecem como estão, a menos que você envie lógica de migração.Uma conta executável cujos dados são bytecode sBPF que o SVM pode executar. É invocado por instruções que nomeiam seu ID de programa e passam contas mais dados da instrução.
Em contas de dados pertencentes ao seu programa (frequentemente PDAs). O programa lê e escreve essas contas quando elas são passadas e marcadas apropriadamente.
O ID do programa, uma fatia de AccountInfo para as contas listadas na instrução e os bytes dos dados da instrução. Frameworks como Anchor 0.32.1 geram este ponto de entrada e fazem dispatch para handlers tipados.
Essas flags AccountMeta dizem ao runtime quem autorizou a transação e quais contas precisam de locks de escrita exclusivos versus locks de leitura compartilhados. Flags incorretas causam falhas ou falta de privilégios de escrita.
Quando os locks necessários não entram em conflito - tipicamente quando elas acessam conjuntos graváveis disjuntos e quaisquer contas compartilhadas são somente leitura para todos os leitores concorrentes. Veja Execução Paralela Sealevel.
Escrita-escrita na mesma conta e escrita-leitura na mesma conta. Dois leitores puros da mesma conta não precisam serializar entre si. Detalhes em Locks de Conta & Conflitos.
Na Solana moderna, incluindo Agave 4.1.1, planeje em torno de um orçamento de compute padrão de transação de aproximadamente 1.400.000 CU, a menos que instruções Compute Budget definam um limite diferente dentro dos limites do protocolo.
A transação falha com um erro de orçamento de compute e não confirma as alterações de estado dessa transação. Simule, meça os logs (consumed) e otimize ou solicite um limite maior. Veja Unidades de Compute & Orçamentos.
Você compila Rust para sBPF com a toolchain Solana/Agave (cargo build-sbf / build do Anchor). Os validadores executam esse bytecode no SVM sob as regras de agendamento e medição do Sealevel. Veja O SVM & sBPF.
O BPF Upgradeable Loader mantém uma conta de programa que aponta para ProgramData contendo o bytecode. Uma autoridade de upgrade pode fazer deploy de novo bytecode; remover a autoridade congela esse caminho de upgrade.
Não. Endereços de PDA derivam do ID do programa e das sementes (seeds). O ID do programa permanece o mesmo entre upgrades do mesmo programa implantado; apenas o bytecode em ProgramData muda.
Dê a cada ator ou entidade independente sua própria conta gravável (comumente um PDA), mantenha contas globais somente leitura em caminhos quentes e evite uma única conta gravável que todos os usuários devam tocar.
Não para escritas arbitrárias de dados - apenas o programa proprietário pode modificar os dados de uma conta. Outros programas interagem via CPI para o proprietário (por exemplo, SPL Token) com as contas e signers corretos.
CPIs consomem CU do mesmo orçamento da transação. Chamadas aninhadas ainda consomem do pool compartilhado; pilhas de CPI profundas ou pesadas precisam de orçamento e simulação.
A latência de confirmação pode mudar, mas o modelo mental do programa - contas declaradas, locks, executáveis stateless, medição de CU - permanece Sealevel como descrito aqui.
ProgramDataVersões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 e LiteSVM 0.6.x.
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026