> ## Documentation Index > Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Glossário Helius: Termos de Solana e Helius Definidos > Definições focadas em desenvolvedores para termos usados nos documentos da Helius e no ecossistema Solana — DAS, LaserStream, Pré-confirmações, taxas de prioridade, NFTs comprimidos, PDAs, unidades de computação, e mais. Referências rápidas para definições de termos utilizados na documentação da Helius e no Solana. Cada entrada se vincula à página ou guia de produto relevante, quando aplicável. Ir para: * [Produtos da Helius e Plataforma](#helius-products-and-platform) * [Fundamentos do Solana](#solana-fundamentals) * [Mecânica de Transações](#transaction-mechanics) * [Tokens e Ativos](#tokens-and-assets) * [Conectividade e Streaming](#connectivity-and-streaming) * [Ecossistema](#ecosystem) *** ## Produtos da Helius e Plataforma ### Autoscaling Mecanismo automático de recarga de créditos da Helius para planos em moeda fiduciária. Quando a cota mensal de créditos é esgotada, o autoscaling compra créditos adicionais até um limite definido pelo usuário, evitando que erros `429` interrompam o tráfego de produção. Planos de criptomoeda não têm autoscaling. Em vez disso, utilizam [créditos pré-pagos](/docs/pt-BR/billing/additional-credits#crypto-plans), que são comprados manualmente. Veja [Autoscaling](/docs/pt-BR/billing/additional-credits). ### Crédito A unidade que a Helius cobra pelo uso do API e streaming. Métodos RPC, chamadas DAS, e a largura de banda de streaming têm cada um um custo específico de crédito. Cada plano inclui uma cota mensal de créditos que é renovada a cada ciclo de cobrança (créditos não utilizados não são acumulados). Veja [Créditos](/docs/pt-BR/billing/credits) para a tabela completa de custos. ### DAS API Digital Asset Standard — uma especificação aberta para uma interface unificada para ativos digitais de Solana (NFTs, NFTs comprimidos, tokens fungíveis). A implementação do DAS API da Helius retorna metadados enriquecidos, propriedade e preços em uma única resposta estruturada, eliminando a necessidade de analisadores personalizados sobre dados de ativos onchain. Veja [DAS API](/docs/pt-BR/das-api). ### Dedicated Nodes Nodos RPC privados da Helius sem limites de taxa ou medição de crédito, cobrados a uma taxa fixa mensal. Eles são adequados para casos de uso restritos que necessitam de largura de banda ilimitada; a maioria das aplicações é melhor servida pelo RPC regular da Helius devido ao desempenho, failover e cobertura de recursos superiores. Veja [Dedicated Nodes](/docs/pt-BR/dedicated-nodes). ### Enhanced Transactions API de transações analisadas da Helius que decodifica transações brutas de Solana em eventos legíveis — transferências de tokens, vendas de NFT, swaps, operações de staking e mais — sem a necessidade de analisadores de instrução por programa. Veja [Enhanced Transactions](/docs/pt-BR/enhanced-transactions). ### Códigos de Erro Códigos de status HTTP padrão retornados pelas APIs da Helius, com contexto específico da Helius: * `400 Bad Request` — parâmetros inválidos ou solicitação malformada (por exemplo, formato de endereço inválido, campos obrigatórios ausentes, JSON malformado) * `401 Unauthorized` — chave de API ausente ou inválida * `403 Forbidden` — acesso negado, geralmente por restrições de IP, uma assinatura que não inclui o endpoint ou permissões insuficientes da chave de API * `404 Not Found` — nenhum dado disponível para o recurso solicitado (normal para consultas de identidade em carteiras desconhecidas) * `429 Too Many Requests` — cota de crédito esgotada, limite de taxa excedido ou limite de solicitações concorrentes atingido * `5xx` — problemas do lado da Helius; tente novamente com backoff exponencial Veja [Códigos de Erro](/docs/pt-BR/faqs/error-codes) para detalhes completos e etapas de solução de problemas. ### Gatekeeper Gateway de borda da Helius que oferece latência significativamente menor do que chamadas RPC padrão, roteando solicitações através de uma frota de proxies distribuída globalmente. Acessado substituindo `mainnet.helius-rpc.com` por `beta.helius-rpc.com` na URL do RPC. Veja [Gatekeeper](/docs/pt-BR/gatekeeper/overview) e a postagem do blog [Introducing Gatekeeper](https://www.helius.dev/blog/introducing-gatekeeper) para informações arquiteturais. ### LaserStream Serviço de streaming gRPC de alta performance da Helius para dados onchain de Solana, com replay histórico, failover multi-regional, e o conjunto de recursos mais rico entre os produtos de streaming da Helius. SDKs oficiais são enviados para JavaScript/TypeScript, Rust e Go. [WebSocket LaserStream](#laserstream-websocket) opera na mesma infraestrutura. Veja [LaserStream](/docs/pt-BR/laserstream) e a postagem do blog [LaserStream SDK performance](https://www.helius.dev/blog/laserstream-sdks) para uma análise detalhada dos benchmarks do SDK. ### LaserStream WebSocket Serviço de streaming WebSocket persistente da Helius. Ele atende tanto os métodos de WebSocket padrão do Solana quanto as extensões específicas da Helius (`transactionSubscribe` e uma `accountSubscribe` aprimorada com filtragem mais rica) em um único endpoint unificado. O LaserStream WebSocket compartilha seu backend com o gRPC [LaserStream](#laserstream). Veja [LaserStream WebSocket](/docs/pt-BR/rpc/websocket). ### Pré-confirmações Sinal de transação de menor latência da Helius. Transmite transações agendadas no momento em que o agendador de um validador se compromete a executá-las — antes de serem coletadas e desmembradas. Mais cedo do que [Entrega de Destroços](#shred-delivery) e mais cedo do que streams de compromisso processados. Entregue sobre uma assinatura WebSocket `preconfSubscribe`. Requer um plano Profissional ou superior; medido a 10 créditos por mensagem. A cobertura depende de quais validadores encaminham seu stream para a Helius, portanto, o feed não é contínuo. Veja [Pré-confirmações](/docs/pt-BR/pre-confirmations/overview) e [`preconfSubscribe`](/docs/pt-BR/pre-confirmations/preconf-subscribe). ### API de Taxa de Prioridade Endpoint de estimativa de taxas da Helius que retorna valores recomendados de taxas de prioridade com base em mercados de taxas onchain em tempo real. Permite precificação competitiva de taxas sem adivinhação ou sobrecarga durante congestionamento. Veja [API de Taxa de Prioridade](/docs/pt-BR/priority-fee-api). ### Limite de Taxa O máximo de solicitações por segundo permitido de acordo com um determinado plano da Helius. Os limites de taxa variam por nível de plano e por família de API (RPC padrão, APIs aprimoradas, streaming). Excedê-los retorna `429 Too Many Requests`. Veja [Limites de Taxa](/docs/pt-BR/billing/rate-limits). ### Remetente Serviço especializado de aterrissagem de transações da Helius, construído para traders de baixa latência, combinando taxas de prioridade, dicas de Jito e roteamento de conexão staked para maximizar as taxas de aterrissagem. Disponível em `https://sender.helius-rpc.com/fast`. Veja [Remetente](/docs/pt-BR/sending-transactions/sender). ### Entrega de Destroços Serviço da Helius para streaming de destroços brutos de Solana por UDP, entregues antes da montagem final do bloco. A Helius agrega destroços de uma rede distribuída de validadores em regiões para minimizar a variação de latência geográfica de qualquer validador individual. Útil para trading de alta frequência, arbitragem e outras aplicações de baixa latência. Destroços brutos estão disponíveis self-serve no [Helius Dashboard](https://dashboard.helius.dev/shred-delivery-seats) - \$1.000/mês por IP (\$800/mês por IP em planos Pro). Veja [Entrega de Destroços](/docs/pt-BR/shred-delivery) e o blog post [Winning the Millisecond Game: Shreds, LaserStream, and the Edge of Solana](https://www.helius.dev/blog/solana-shreds) para uma análise detalhada sobre como os destroços funcionam. ### Conexões Staked O caminho padrão de envio de transações para os planos pagos da Helius. Conexões staked roteiam transações para líderes de blocos em iminência por meio do Solana's protocol-level Stake-Weighted Quality of Service (SWQoS), que concede slots de conexão preferenciais com base na participação do validador e reduz perdas de pacotes durante congestionamentos. Os planos pagos da Helius herdam essa vantagem de taxa de aterrissagem sem que os chamadores precisem operar um validador altamente staked diretamente. Veja [Otimização de Transações](/docs/pt-BR/sending-transactions/optimizing-transactions) e o blog post [Stake-Weighted Quality of Service: Everything You Need to Know](https://www.helius.dev/blog/stake-weighted-quality-of-service-everything-you-need-to-know). ### API de Carteira API REST da Helius para consultar os saldos de uma carteira Solana, histórico de transações, transferências, identidade e fonte de financiamento — respostas estruturadas, com preços em USD, em vez de saída RPC padrão. Ele aceita SNS `.sol` e nomes de domínios ANS além de endereços. Veja [API de Carteira](/docs/pt-BR/wallet-api/overview). *** ## Fundamentos do Solana ### Conta Um contêiner que armazena dados de forma persistente no Solana, identificado por uma chave pública de 32 bytes. Todo estado onchain — saldos de usuários, código de programas, metadados de tokens — vive em contas, incluindo os próprios programas. Cada conta possui um proprietário, que é um programa autorizado a modificar seus dados ou retirar lamports, e deve manter um saldo mínimo de SOL (isenção de rendimento) para persistir. Veja a postagem do blog [The Solana Programming Model: An Introduction to Developing on Solana](https://www.helius.dev/blog/the-solana-programming-model-an-introduction-to-developing-on-solana) para uma análise mais aprofundada. ### Agave O cliente validador canônico atual do Solana, mantido pela Anza — o sucessor renomeado do cliente original do Solana Labs. Referências a lançamentos específicos do Agave (por exemplo, o limiar mínimo de stake v1.17.31 [SWQoS](#stake-weighted-quality-of-service-swqos)) normalmente fixam o comportamento a uma versão específica do cliente. [Jito-Solana](#jito) é um fork do Agave com seu engine de bloco integrado; [Firedancer](#firedancer) é uma alternativa independente baseada em C desenvolvida pela Jump Crypto. Veja a postagem do blog [Solana Virtual Machine](https://www.helius.dev/blog/solana-virtual-machine) para o modelo SVM que o Agave implementa. ### Airdrop Uma concessão de SOL ou tokens SPL para um endereço. No Devnet e no Testnet, um airdrop normalmente se refere a uma pequena quantidade de SOL de teste de uma fonte usada para financiar carteiras de desenvolvimento; no Mainnet, refere-se a distribuições em massa de tokens para titulares existentes. Airdrops no Devnet estão disponíveis via [faucet do Devnet](/docs/pt-BR/rpc/devnet-sol). ### Conta de Token Associada (ATA) Uma conta de token derivada de forma determinística que possui um token SPL específico para um determinado endereço de carteira. Cada carteira tem no máximo uma ATA por token mint, tornando as ATAs o lugar canônico para consultar o saldo de token de um usuário. Ela é derivada usando o endereço da carteira e o mint do token como sementes. ### Bloco Uma estrutura de dados contendo um conjunto de transações mais metadados essenciais — incluindo o hash do bloco e o hash do bloco anterior, formando uma cadeia imutável. Blocos são produzidos durante os slots: o [líder](#leader-leader-schedule) designado para um [slot](#slot) valida as transações recebidas, os empacota em um bloco e transmite o bloco para a rede via [Turbine](#turbine). Nem todo slot produz um bloco — se o líder não conseguir produzir um a tempo, o slot é pulado e a rede segue em frente. Uma vez que um bloco recebe uma supermaioria de votos [validador](#validator) ponderados por stake, ele é considerado confirmado (veja [Nível de Compromisso](#commitment-level)). Veja a postagem do blog [Understanding Slots, Blocks, and Epochs on Solana](https://www.helius.dev/blog/solana-slots-blocks-and-epochs) para uma análise mais aprofundada. ### Nível de Compromisso O grau de confiança de que uma transação foi incluída onchain: * `processed` — visto pelo líder atual, mas ainda não votado; ainda pode ser descartado se o bloco perder consenso (\~0,4s) * `confirmed` — ≥66% dos votos de validadores ponderados por stake no bloco; historicamente, nenhum bloco confirmado foi revertido (\~0,6s) * `finalized` — o bloco tem ≥66% de votos mais 31 blocos subsequentes construídos sobre ele (ou seja, o máximo de bloqueio do Tower BFT), tornando-o efetivamente irreversível (\~13s) `confirmed` é o padrão recomendado. Use `processed` para feedback da interface do usuário, `finalized` para operações de alto valor como depósitos em exchanges ou pontes cross-chain. Hashes de bloco obtidos em `finalized` expiram mais cedo do que aqueles de `confirmed`, encurtando a janela antes do vencimento da transação. Veja a postagem do blog [What are Solana Commitment Levels?](https://www.helius.dev/blog/solana-commitment-levels) para uma análise mais aprofundada. ### Unidades de Computação (CU) A medida de trabalho computacional realizada por uma transação no Solana, análoga ao gás no Ethereum. Cada transação especifica um limite de unidades de computação e um preço por unidade de computação (taxa de prioridade em microlamports por CU); o produto determina o custo total da taxa de prioridade. Exceder o limite falha a transação. ### CPI (Invoção entre Programas) Um mecanismo Solana que permite que um [programa](#program) onchain chame outro, passando contas e dados de instrução — o primitivo que permite a composicionabilidade do Solana. CPIs são expostos via o syscall `sol_invoke_signed`, que verifica se o chamador possui as permissões apropriadas para as contas passadas; [PDAs](#program-derived-address-pda) permitem que programas assinem em nome de contas que possuem. Um programa chamado opera dentro do orçamento de computação restante do programa chamador: se ele esgotar o orçamento ou exceder um limite definido, toda a cadeia de chamadas falha — incluindo a transação original. Veja a postagem do blog [Solana Virtual Machine](https://www.helius.dev/blog/solana-virtual-machine) para uma análise mais aprofundada. ### Época Um agrupamento de aproximadamente 432.000 slots do Solana — o intervalo organizacional de nível superior no qual o Solana atualiza seu conjunto de validadores, cronograma de líderes, delegações de stake e distribuições de recompensas. Cada epoch leva \~2 dias no alvo de slot atual. Veja a postagem do blog [Understanding Slots, Blocks, and Epochs on Solana](https://www.helius.dev/blog/solana-slots-blocks-and-epochs) para uma análise mais aprofundada. ### Firedancer Um segundo cliente [validador](#validator) independente do Solana, escrito do zero em C pela Jump Crypto. Os objetivos declarados do Firedancer são (1) documentar e padronizar o protocolo Solana por meio de uma implementação independente, (2) melhorar a diversidade de clientes (nenhum cliente controla >33% do stake), e (3) aumentar o desempenho do ecossistema. A arquitetura é modular: muitos processos Linux de propósito único chamados "tiles" (tile QUIC, tile verify, etc.) se comunicam via memória compartilhada, em contraste com o design de processo único do [Agave](#agave). Frankendancer é seu intermediário híbrido — o código de rede C de alta performance do Firedancer emparelhado com o runtime Rust e código de consenso do Agave. Veja a postagem do blog [What is Firedancer?](https://www.helius.dev/blog/what-is-firedancer) para uma análise mais aprofundada. ### Instrução A menor unidade de trabalho dentro de uma transação do Solana — uma única invocação de programa com as contas relevantes e dados. Uma transação agrupa uma ou mais instruções, executadas de forma atômica (todas têm sucesso ou todas falham juntas). Veja a postagem do blog [The Solana Programming Model: An Introduction to Developing on Solana](https://www.helius.dev/blog/the-solana-programming-model-an-introduction-to-developing-on-solana) para uma análise mais aprofundada. ### Lamport A menor unidade de SOL: 1 SOL = 1.000.000.000 lamports (10⁻⁹ SOL), nomeada em homenagem a Leslie Lamport, vencedor do Prêmio Turing por trabalho fundamental em sistemas distribuídos. Métodos RPC brutos de Solana retornam saldos e taxas em lamports; a [API de Carteira](/docs/pt-BR/wallet-api/overview) da Helius lida com a conversão automaticamente. Taxas de prioridade são denominadas em microlamports — um milionésimo de um lamport (10⁻¹⁵ SOL). ### Líder / Cronograma de Líderes O líder é o [validador](#validator) designado para propor um novo [bloco](#block) durante um determinado [slot](#slot). Os líderes são escolhidos por um cronograma aleatório ponderado por stake, calculado no início de cada [época](#epoch), para que qualquer validador possa derivar independentemente quem liderará cada slot na próxima janela de \~2-3 dias. Cada líder é designado para quatro slots consecutivos (\~1,6 segundos a \~400 ms por slot), dando-lhes uma pequena janela de produção de bloco consecutiva. Se um líder não conseguir produzir um bloco em seu slot, o slot é pulado — a rede prossegue em vez de esperar pelo bloco ausente. Serviços de envio de transações como o [Remetente](#sender) roteiam transações assinadas para o líder atual e os próximos dois líderes para maximizar a probabilidade de aterrissagem. Veja a postagem do blog [Consensus on Solana: Tower BFT and Proof of History](https://www.helius.dev/blog/consensus-on-solana) para uma análise mais aprofundada. ### Árvore de Merkle Uma estrutura de árvore criptográfica onde cada nó não folha é um hash de seus filhos, de modo que o único hash raiz compromete todo o conjunto de dados. Verificar que um dado pertence à árvore requer apenas os hashes irmãos ao longo do caminho da folha até a raiz — uma prova de Merkle — que é O(log n) dados independentemente do tamanho da árvore. Para uma árvore de profundidade-26 essa prova é de 26 hashes irmãos (\~832 bytes), que é pequeno, mas ainda por folha: este é o formato de prova usado pelos [NFTs comprimidos](#compressed-nft-cnft). [Compressão ZK](#zk-compression) substitui isso por uma [prova de validade](#validity-proof) de tamanho constante que não cresce com o conjunto de dados. Veja a postagem do blog [Cryptographic Tools 101: Hash Functions and Merkle Trees Explained](https://www.helius.dev/blog/cryptographic-tools-101-hash-functions-and-merkle-trees-explained). ### Programa Uma conta executável contendo bytecode sBPF compilado (ou seja, um contrato inteligente no Solana). Programas são sem estado — eles leem e escrevem contas de dados que possuem, e são identificados por um ID de programa (seu endereço de 32 bytes). Solana é fornecido com um conjunto de programas nativos (Sistema, Stake, Voto, etc.) incorporados ao sistema; todo o resto é um programa implantado pelo usuário. Veja a postagem do blog [The Solana Programming Model: An Introduction to Developing on Solana](https://www.helius.dev/blog/the-solana-programming-model-an-introduction-to-developing-on-solana) para uma análise mais aprofundada. ### Endereço Derivado de Programa (PDA) Um endereço determinístico derivado de um ID de programa e um conjunto de sementes. PDAs permitem que programas assinem por contas que controlam, sendo essenciais para o design de programas com estado. PDAs estão propositalmente fora da curva, portanto, não existe chave privada para eles. ### Prova de História (PoH) Primitiva de sincronização do Solana — não é um algoritmo de consenso. PoH fornece uma função de marcação de tempo criptográfica que permite que validadores concordem sobre a ordem dos eventos sem se comunicar. Implementação: uma cadeia de hash SHA-256 sequencial que é executada continuamente em um único núcleo de CPU por validador, usando a saída de cada iteração como entrada da próxima. A geração é sequencial e single-threaded; a verificação é paralelizável. PoH fornece os "tiques" que definem quando um [bloco](#block) é válido. Líderes devem publicar blocos dentro de um determinado intervalo de ticques PoH — um bloco fora do intervalo é considerado pulado. PoH é executado em paralelo ao [Tower BFT](#tower-bft), que é o mecanismo de consenso real. Veja a postagem do blog [Proof of History, Proof of Stake, and Proof of Work Explained](https://www.helius.dev/blog/proof-of-history-proof-of-stake-proof-of-work-explained) para uma análise mais aprofundada. ### Aluguel / Isenção de Aluguel O saldo de SOL que toda conta Solana deve manter para persistir onchain, escalado para o tamanho do armazenamento da conta. Contas devem ser criadas com isenção de aluguel: transações que deixariam uma conta abaixo do mínimo falham. Uma vez isentas de aluguel, as contas persistem indefinidamente sem pagamentos adicionais. ### Sealevel Engine de execução de transações paralelas do Solana. Diferente das VMs sequenciais como a EVM, o Sealevel executa várias transações simultaneamente em vários núcleos de CPU. Isso é possível porque toda transação Solana declara explicitamente quais [contas](#account) irá ler e escrever antes do início da execução, para que o agendador possa identificar lotes não conflitantes sem análise em tempo de execução. As regras de agendamento são simples: transações que acessam contas diferentes são executadas em paralelo; transações que apenas leem as mesmas contas também são executadas em paralelo (leitura não conflita); transações que escrevem nas mesmas contas são executadas de forma sequencial para evitar condições de corrida. Veja a postagem do blog [Solana Virtual Machine](https://www.helius.dev/blog/solana-virtual-machine) para uma análise mais aprofundada. ### Slot Unidade de tempo fundamental do Solana, durante a qual um validador de líder designado tem a oportunidade de produzir um bloco. Slots atualmente têm um alvo de 400ms, embora durações reais possam variar com as condições de rede. Se um líder não conseguir produzir um bloco durante seu slot, o slot é pulado — a rede prossegue para o próximo slot em vez de esperar, portanto, nem todo slot resulta em um bloco. Veja a postagem do blog [Understanding Slots, Blocks, and Epochs on Solana](https://www.helius.dev/blog/solana-slots-blocks-and-epochs) para uma análise mais aprofundada. ### SVM (Solana Virtual Machine) Toda a pilha de execução de transações do Solana — não é um interpretador de bytecode estreito. A SVM abrange o componente Banco que orquestra a execução, o agendador do Estágio de Banca, os carregadores BPF e a máquina virtual sBPF em si (uma VM baseada em registradores com 11 registradores de propósito geral e \~100 opcodes, compilada para JIT performance). Isso é distinto da EVM, que se refere inequivocamente a um único executor de bytecode. Programas Solana são compilados para sBPF, o fork Solana do Linux eBPF. Qualquer linguagem com um frontend LLVM (C, C++, Rust, Zig) pode ser direcionada ao sBPF. Exigir que transações declarem o acesso à conta com antecedência é o que libera a execução paralela do [Sealevel](#sealevel) e os mercados de taxas localizados do Solana. Veja a postagem do blog [Solana Virtual Machine](https://www.helius.dev/blog/solana-virtual-machine) para uma análise mais aprofundada. ### Tower BFT O mecanismo de consenso do Solana. O Tower BFT é um algoritmo semelhante ao pBFT que aproveita o "clock" sincronizado do [Proof of History](#proof-of-history-poh), eliminando a necessidade de uma rodada de consenso síncrona em cada slot. Validadores constroem uma "torre de votos" — uma pilha sequencial de votos onde cada novo voto dobra o período de bloqueio de todos os votos anteriores, aumentando exponencialmente o custo de perda de stake ao mudar de forks. Limites de confirmação: um bloco é **confirmado** assim que ≥2/3 dos votos ponderados por stake aterrissaram nele (≥4,6% do stake total teria que ser cortado para violar a finalidade). Um bloco é **finalizado** assim que possui votos mais 31 blocos subsequentes construídos sobre ele, o máximo de bloqueio do Tower BFT. Veja [Nível de Compromisso](#commitment-level) para orientações de uso. Veja a postagem do blog [Consensus on Solana: Tower BFT and Proof of History](https://www.helius.dev/blog/consensus-on-solana) para uma análise mais aprofundada. ### Turbine Protocolo de propagação de blocos do Solana. O líder divide cada bloco em [destroços](#shred) de tamanho MTU mais destroços de recuperação codificados em errasure em Reed-Solomon — a taxa de FEC (geralmente 32:32) permite que a rede reconstrua um bloco mesmo com \~33% de perda de pacotes. O líder então encaminha destroços através de uma árvore determinística ponderada por stake de validadores pares (semeada por shred-group por `(leader id, slot, shred index, shred type)`) em vez de transmitir o bloco completo para cada validador diretamente. A árvore (`DATA_PLANE_FANOUT = 200`) mantém a largura de banda de saída do líder aproximadamente constante, independentemente da contagem de validadores, e permite que os blocos alcancem a rede em 2–3 saltos em vez de O(n). Veja a postagem do blog [Turbine: Block Propagation on Solana](https://www.helius.dev/blog/turbine-block-propagation-on-solana). ### Validador Um nó na rede Solana que participa do consenso ao produzir blocos durante seus slots de líder designados e votar em blocos de outros validadores. Validadores são selecionados para slots de líder proporcionalmente ao seu stake ativo. *** ## Mecânica de Transações ### Tabela de Pesquisa de Endereços (ALT) Uma tabela onchain de endereços Solana que uma transação versionada pode referenciar usando um índice de 1 byte em vez de uma chave pública completa de 32 bytes, permitindo que uma única transação referencie até 256 contas. ALTs são essenciais para operações DeFi complexas que, de outra forma, excederiam os limites de tamanho de transação. ### Hash de Bloco Um hash de 32 bytes que identifica um bloco recente, incluído em toda transação Solana para provar atualidade. Hashes de bloco expiram após \~150 slots (\~1 minuto); transações com hashes de bloco expirados são rejeitadas. Clientes buscam um hash de bloco recente via [`getLatestBlockhash`](/docs/pt-BR/api-reference/rpc/http/getlatestblockhash) pouco antes de assinar. ### Taxa de Prioridade Uma gorjeta por unidade de computação paga aos validadores para dar prioridade a uma transação sobre outras, melhorando seu tempo de inclusão. As taxas de prioridade são definidas em microlamports por unidade de computação (µLamports/CU). A [API de Taxa de Prioridade](/docs/pt-BR/priority-fee-api) da Helius retorna estimativas em tempo real com base em mercados de taxas onchain recentes. ### Destroço A menor unidade de um bloco Solana. Blocos são divididos (ou seja, fragmentados) em destroços para propagação paralela através da rede de validadores via [Turbine](https://www.helius.dev/blog/turbine-block-propagation-on-solana). O acesso ao nível de destroços dá aos traders sinais onchain de ultra baixa latência, antes da montagem do bloco — embora [Pré-confirmações](#preconfirmations) cheguem ainda mais cedo, na fase de transação agendada. Veja [Destroços Brutos (UDP)](/docs/pt-BR/shred-delivery/raw-shreds) e a visão geral [Entrega de Destroços](/docs/pt-BR/shred-delivery). ### Qualidade de Serviço Ponderada por Stake (SWQoS) Um mecanismo de nível de protocolo Solana que prioriza transações de entrada para os líderes atuais e futuros com base no stake do remetente. Introduzido após a interrupção do Solana em 30 de abril de 2022 como uma medida de resistência a Sybil, o SWQoS impede que pares de baixo stake ou não stake monopolizem a largura de banda do líder durante congestionamentos. O líder expõe dois pools de conexão de entrada: \~500 conexões abertas compartilhadas entre todos os pares não stake, e \~2.000 conexões ponderadas por stake distribuídas proporcionalmente aos validadores staked — um validador com X% de stake ativo total pode enviar até X% dos pacotes ao líder. Validadores abaixo de \~15.000 SOL de stake ativo (\~1/25.000 do stake total da rede) são tratados como não stake. O limite de stake mínimo foi lançado no Agave v1.17.31. As [Conexões Staked](#staked-connections) da Helius herdam essa vantagem de taxa de aterrissagem ao rotear transações dos clientes através do maior validador do Solana, para que os chamadores se beneficiem do SWQoS sem operar um validador altamente staked diretamente. Veja a postagem do blog [Stake-Weighted Quality of Service: Everything You Need to Know](https://www.helius.dev/blog/stake-weighted-quality-of-service-everything-you-need-to-know). ### Transação Versionada Um formato mais recente de transação Solana que suporta Tabelas de Pesquisa de Endereços, permitindo que uma transação referencie até 256 contas (vs. \~35 em transações legadas). Transações versionadas são necessárias para a maioria das integrações DeFi modernas. Elas são denotadas por um byte de versão no início da transação serializada. *** ## Tokens e Ativos ### Conta Comprimida Uma conta Solana cujo dados são compromissados ao ledger via logs de transação, com apenas uma impressão digital de hash armazenada no estado do validador — em vez de os dados completos ocuparem um slot de conta tradicional nos discos do validador. Desenvolvedores podem tratar contas comprimidas como contas regulares; indexadores (como o Photon) analisam logs de transação para reconstruir o estado atual, e uma prova de conhecimento zero Groth16 de tamanho constante verifica a integridade quando contas são lidas ou modificadas via Compressão ZK. Este modelo é mais adequado para contas de dados pequenos — dados maiores (acima de \~100 bytes) tornam a compressão impraticável. ### NFT Comprimido (cNFT) Um NFT Solana representado como uma folha em uma árvore Merkle concorrente onchain em vez de sua própria conta. A árvore reside em uma conta Solana e suas transições de estado são seguras pelo ledger; o estado atual do NFT é derivado do histórico de transações por indexadores, que produzem provas de Merkle verificáveis contra a raiz onchain da árvore. Ler um cNFT, portanto, requer um indexador como o [DAS API](/docs/pt-BR/das-api) — o RPC padrão do Solana não pode retornar dados de cNFTs diretamente. Este modelo reduz os custos de mintagem em até 99% em comparação com NFTs padrão. ### Árvore Merkle Concorrente Uma variante Solana específica de uma [Árvore Merkle](#merkle-tree) projetada para permitir que vários escritores atualizem a árvore no mesmo slot sem invalidar as provas uns dos outros. A conta onchain armazena não apenas a raiz atual, mas um buffer de changelog de raízes válidas recentes e um dossel (um subconjunto em cache de nós superiores da árvore), permitindo que validadores verifiquem provas geradas contra qualquer raiz ainda na janela de buffer. Três parâmetros definem uma árvore: profundidade máxima (limita a contagem de folhas em 2^depth), tamanho do buffer (profundidade do changelog — quantas gravações podem ocorrer antes que provas de voo se tornem inválidas), e profundidade do dossel (que troca aluguel onchain por provas menores na transação). Pares válidos (profundidade, buffer) variam de (3, 8) até (30, 2048); para composicionabilidade prática mantenha `maxDepth − canopyDepth ≤ 10`. Árvores Merkle concorrentes são implementadas pelo programa SPL Account Compression e são o substrato para [NFTs comprimidos](#compressed-nft-cnft), que são mintados como folhas via Metaplex Bubblegum. Veja a postagem do blog [All You Need to Know About Compression on Solana](https://www.helius.dev/blog/all-you-need-to-know-about-compression-on-solana). ### Groth16 Um sistema de provas zk-SNARK que produz provas de tamanho constante de conhecimento zero (128 bytes na curva BN254, usando compressão de ponto) independentemente da complexidade da declaração, com verificação O(1). [Compressão ZK](#zk-compression) usa Groth16 para gerar [Provas de Validade](#validity-proof) de que uma conta comprimida pertencia a um estado conhecido em uma raiz conhecida — o pequeno tamanho da prova é o que mantém as transações de conta comprimida baratas. Veja a postagem do blog [Solana Builders: ZK Compression](https://www.helius.dev/blog/solana-builders-zk-compression). ### Conta Mint A conta onchain que define as propriedades de um token SPL — fornecimento, decimais e autoridades de mint/congelamento. O endereço da conta mint é o identificador canônico do token (seu "endereço de contrato" em termos de Ethereum). ### Token SPL Um token no Solana emitido via o Programa de Tokens da Solana Program Library (SPL). Tokens fungíveis (USDC, BONK, JUP, etc.) são tokens SPL; NFTs padrão (não comprimidos) também são tokens SPL, emitidos com suprimento 1 e 0 decimais. Tokens SPL são aproximadamente o equivalente Solana de ERC-20 e ERC-721 no Ethereum. O Token-2022 é um programa mais novo que estende essa interface com recursos opcionais como taxas de transferência e transferências confidenciais. ### Árvore de Estado A árvore Merkle que a [Compressão ZK](#zk-compression) usa para armazenar os hashes de contas comprimidas. A conta onchain retém apenas a raiz atual e metadados mínimos; os dados comprimidos reais vivem em logs de transação e são reconstruídos por indexadores como o [Photon](#photon). Programas leem ou modificam o estado comprimido passando uma [Prova de Validade](#validity-proof) de que o conteúdo reivindicado da conta faz hash para uma folha sob a raiz atual. Veja [Compressão ZK](/docs/pt-BR/api-reference/zk-compression). ### Conta de Token Uma conta onchain que mantém um saldo de um token SPL específico para um proprietário específico. Uma carteira pode possuir contas de token arbitrárias, mas a convenção é usar uma Conta de Token Associada (ATA) — uma conta de token derivada de forma determinística por par (carteira, mint) criada pelo Programa de Conta de Token Associada. ### Token-2022 (Extensões de Token) Uma variante do Programa de Token SPL que suporta extensões opcionais (por exemplo, taxas de transferência, transferências confidenciais, tokens com rendimento, tokens não transferíveis). O Token-2022 opera como um programa onchain separado, com seu próprio ID de programa, mas é projetado como um sucessor compatível com o Programa de Token clássico, para que SDKs possam, tipicamente, lidar com ambos. Mints devem ser criados sob o programa Token-2022 para usar extensões. Veja a postagem do blog [What are Token Extensions?](https://www.helius.dev/blog/what-is-token-2022). ### Prova de Validade Uma prova de conhecimento zero [Groth16](#groth16) de tamanho constante de que o conteúdo reivindicado de uma conta comprimida existia na [Árvore de Estado](#state-tree) em uma raiz específica. Programas de [Compressão ZK](#zk-compression) exigem uma prova de validade sempre que contas comprimidas são lidas ou modificadas; a prova permite que o programa verifique o estado off-chain sem que o validador armazene os dados onchain. [Photon](#photon) expõe provas de validade para chamadores via seu método RPC [`getValidityProof`](/docs/pt-BR/api-reference/zk-compression/getvalidityproof). Provas de validade são o que distingue a Compressão ZK de [NFTs comprimidos](#compressed-nft-cnft): cNFTs usam provas Merkle simples (uma lista de hashes irmãos da folha até a raiz, que cresce com a profundidade da árvore), enquanto a prova ZK de tamanho constante da Compressão ZK não revela o caminho ou o estado da árvore circundante. Veja a postagem do blog [Solana Builders: ZK Compression](https://www.helius.dev/blog/solana-builders-zk-compression). ### Compressão ZK A Compressão ZK é uma primitiva Solana desenvolvida pela Helius e Light Protocol que reduz dramaticamente os custos de armazenamento onchain comprometendo dados de conta em logs de transação no ledger e armazenando apenas uma impressão digital de hash no estado do validador. A integridade criptográfica é preservada por meio de provas de conhecimento zero Groth16 de tamanho constante geradas a partir de dados de transação indexados. Esta primitiva é distinta dos NFTs comprimidos, que usam árvores Merkle concorrentes sem provas de conhecimento zero. Veja [Compressão ZK](/docs/pt-BR/api-reference/zk-compression) e a postagem do blog [Solana Builders: ZK Compression](https://www.helius.dev/blog/solana-builders-zk-compression) para uma análise mais aprofundada. *** ## Conectividade e Streaming ### Geyser O sistema de plugins do Solana para streaming de mudanças de estado do validador — contas, transações, slots, blocos — para consumidores externos em tempo real. Validadores carregam plugins do Geyser como bibliotecas dinâmicas; o plugin recebe atualizações de estado à medida que o validador as processa, eliminando a necessidade de consultar o RPC para mudanças. O Yellowstone gRPC — o plugin Geyser dominante — expõe essas atualizações por gRPC. O [LaserStream](#laserstream) da Helius implementa a interface Yellowstone gRPC com recursos adicionais como replay histórico (até \~216.000 slots / \~24 horas) e failover multi-regional. ### gRPC gRPC é um protocolo RPC binário de propósito geral e alto desempenho (um acrônimo recursivo para "gRPC Remote Procedure Call"). Em contextos Solana, "gRPC" geralmente se refere ao Yellowstone gRPC — uma interface de streaming construída no sistema de plugins Geyser do Solana que expõe atualizações de contas e transações por gRPC. O serviço [LaserStream](/docs/pt-BR/laserstream) da Helius é construído em uma interface baseada no Yellowstone, com recursos adicionais como replay histórico, failover multi-regional e infraestrutura gerenciada. ### RPC RPC significa Remote Procedure Call, que é um padrão geral para chamar um método de servidor como se fosse uma função local. No Solana, "RPC" mais frequentemente refere-se a um nó RPC — um nó que acompanha o estado do Solana, mas não participa do consenso, especializando-se em atender solicitação de dados (ou seja, estado de conta, histórico de transações, submissão de transações) por meio de uma interface JSON-RPC. Por outro lado, validadores produzem blocos e votam neles. O serviço RPC da Helius é uma frota distribuída globalmente de nós RPC otimizada para cargas de trabalho de produção. Veja a postagem do blog [Solana Nodes — A Primer on Solana RPCs, Validators, and RPC Providers](https://www.helius.dev/blog/solana-nodes-a-primer-on-solana-rpcs-validators-and-rpc-providers) para uma análise mais aprofundada. ### Webhook Um webhook é uma solicitação HTTP POST enviada por um servidor para uma URL receptora quando um evento ao qual se está inscrito ocorre — HTTP "reverso", onde o servidor inicia a chamada. [Webhooks](/docs/pt-BR/webhooks) da Helius enviam eventos onchain de Solana (transferências, vendas de NFT, atividade de programa personalizado) para um endpoint registrado, eliminando a necessidade de polling. ### WebSocket (WSS) Um WebSocket é uma conexão TCP bidirecional persistente atualizada a partir de HTTP, usada para transmissão streaming baseada em push de dados Solana sem requisições HTTP repetidas. WSS (WebSocket Seguro) é o mesmo protocolo rodando sobre TLS, e é a variante usada para conexões de produção Solana. O [LaserStream WebSocket](/docs/pt-BR/rpc/websocket) — produto de streaming WebSocket da Helius, incluindo os métodos padrão do Solana e extensões Helius como `transactionSubscribe` — usa WSS. *** ## Ecossistema ### Anchor Anchor é uma framework Rust para construir programas Solana de forma rápida e segura. Ele lida com boilerplate como serialização de contas, validação e despacho de instrução por meio de macros procedurais, permitindo que os desenvolvedores se concentrem na lógica do programa em vez de nos detalhes de baixo nível. A maioria dos desenvolvedores Solana usa o Anchor em vez de escrever programas em Rust nativo. Veja a postagem do blog [An Introduction to Anchor: A Beginner's Guide to Building Solana Programs](https://www.helius.dev/blog/an-introduction-to-anchor-a-beginners-guide-to-building-solana-programs) para uma análise mais aprofundada. ### IDL IDL significa Interface Definition Language. Um IDL é um esquema JSON que descreve as instruções, contas e tipos de dados de um programa Solana; clientes o utilizam para construir transações e decodificar dados de programa sem rolar manualmente layouts de instrução. O Anchor gera IDLs automaticamente e os publica onchain por padrão em uma conta dedicada para descoberta pública. ### Jito Uma empresa do ecossistema Solana que opera o motor de bloco dominante da rede — uma camada de infraestrutura MEV (maximal extractable value) que aceita pacotes de transações (grupos atômicos de transações que são executados juntos ou não) e permite que pesquisadores paguem gorjetas a validadores para priorizar o aterrissamento delas. O cliente validador Jito-Solana é um fork do Agave com o motor de bloco integrado. A inclusão em pacotes requer uma gorjeta mínima de 10.000 lamports, e o Jito-Relayer retém o tráfego de entrada por \~200 ms para habilitar o leilão de pacotes fora de cadeia. O [Remetente](#sender) da Helius submete transações simultaneamente através de conexões staked e do motor de bloco Jito, tomando o caminho que aterrissa primeiro. Veja a postagem do blog [Solana MEV: An Introduction](https://www.helius.dev/blog/solana-mev-an-introduction). ### Light Protocol A equipe de protocolo Solana que co-desenvolveu a [Compressão ZK](#zk-compression) com a Helius. A Helius construiu o indexador canônico ([Photon](#photon)) e opera o RPC público; o Light Protocol constrói os programas onchain e a pilha de provas das quais o indexador depende. Veja [github.com/Lightprotocol/light-protocol](https://github.com/Lightprotocol/light-protocol). ### Photon O indexador open-source da [Compressão ZK](#zk-compression) construído pela Helius. Dados de conta comprimidos vivem em logs de transação Solana em vez do estado da conta, então validadores não os expõem via RPC padrão — o Photon analisa transações de Solana, reconstrói o estado da conta comprimida, e o serve através de uma interface JSON-RPC que espelha o RPC nativo da Solana mais métodos específicos de ZK-Compression como [`getCompressedAccount`](/docs/pt-BR/api-reference/zk-compression/getcompressedaccount) e [`getValidityProof`](/docs/pt-BR/api-reference/zk-compression/getvalidityproof). Desenvolvedores podem hospedar autonomamente de [github.com/helius-labs/photon](https://github.com/helius-labs/photon) ou usar o endpoint Helius hospedado. Veja [Compressão ZK](/docs/pt-BR/api-reference/zk-compression).