> ## Content Index > Fetch the complete content index at: https://bullquill.com/llms.txt > Use this file to discover other available public pages before exploring further. # Solana Alpenglow explicado: o que o Votor muda no consenso - URL: https://bullquill.com/pt/solana-alpenglow-upgrade-explained-pt/ - Published: 2026-10-21T11:53:51.000Z - Updated: 2026-10-22T14:26:48.000Z - Description: A Solana tem previsão de substituir o TowerBFT pelo Votor, a primeira metade do Alpenglow, em 21 de outubro de 2026. Veja o que muda, quais números são regras de projeto e quais ainda são metas, e o que validadores e usuários devem acompanhar. - Author: Rowan Ashby - Tags: Crypto, Explainer, Trending, #lang-pt, #tr-solana-alpenglow-upgrade-explained ## Principais pontos - A Solana tem previsão de substituir seu consenso TowerBFT pelo Votor, a primeira metade do projeto Alpenglow, na mainnet-beta na quarta-feira, 21 de outubro de 2026\. A Anza, desenvolvedora do cliente de validador Agave, indicou a entrada em operação por volta das 14h50 UTC. - A Solana Foundation afirma que a finalidade deve cair de cerca de 12,8 segundos para uma meta de aproximadamente 150 milissegundos. A Foundation chama esse número de "uma expectativa, não uma constante". - Segundo a Anza, o Votor tolera ao mesmo tempo 20% de stake malicioso e outros 20% de stake offline. O TowerBFT tolerava menos de 33% de stake malicioso. - O Rotor, a segunda metade do Alpenglow, substituiria a camada de propagação de blocos Turbine. Ele não faz parte da troca de hoje e não tem data de lançamento. - A transição acontece em uma rede em funcionamento, sem reinicialização. Ela exige que 82% do stake assine um "certificado gênese", e apenas clientes baseados no Agave podem participar da migração. ## O que é o Alpenglow O Alpenglow é um novo protocolo de consenso para a Solana, projetado por pesquisadores da Anza. Consenso é o processo que os validadores usam para concordar sobre quais blocos são definitivos. Desde o lançamento, a rede usa o TowerBFT, um sistema de votação ligado ao Proof of History, o relógio criptográfico da Solana. No TowerBFT, os validadores enviam votos como transações comuns na blockchain. Esses votos ocupam uma grande parte do espaço dos blocos, e um bloco só é considerado definitivo depois de muitas rodadas de confirmações. O Alpenglow divide o trabalho em dois componentes. O **Votor** cuida da votação e da finalidade. O **Rotor** cuida de como os dados dos blocos circulam entre os validadores. A Anza descreve a troca de 21 de outubro como a Fase 1: o Votor entra em operação enquanto a camada de propagação Turbine existente é mantida. Os validadores aprovaram a proposta geral do Alpenglow em uma votação de governança em setembro de 2025\. O Decrypt informou que cerca de 98% dos votos foram favoráveis. A Anza apresenta a migração como a primeira do mundo a trocar motores de consenso em uma rede em funcionamento, segundo o relato do Solana Compass sobre o anúncio. A afirmação é da própria Anza, e o Bullquill não a verificou de forma independente. A empresa também descreveu o esforço como 18 meses de trabalho para uma migração que acontece em um único slot. ## Como o Votor muda o consenso A página da atualização da Solana Foundation apresenta três mudanças principais. ### Os votos saem da blockchain No Votor, os validadores enviam votos diretamente uns aos outros, em vez de enviá-los como transações. Esses votos são então agregados em certificados compactos com assinaturas BLS. As chaves BLS dos validadores foram ativadas na mainnet em 8 de julho de 2026, como preparação. Os certificados são registrados em um "rodapé" (footer) do bloco, e não como transações de voto individuais. ### Dois caminhos para a finalidade O Votor executa dois caminhos de votação ao mesmo tempo, e vale o primeiro que finalizar um bloco. No caminho rápido, um bloco é definitivo após uma rodada se pelo menos 80% do stake votar para notarizá-lo. Se esse limite não for atingido, uma segunda rodada finaliza o bloco com 60% do stake. Os mesmos limites de 60% se aplicam aos certificados de notarização e de salto (skip). A página do Alpenglow da Anza diz que a geografia influencia qual caminho vence, porque a velocidade dos votos depende de onde os validadores estão. ### O Proof of History deixa de ditar o ritmo dos blocos A Foundation diz que os ticks saem do ledger e que o carimbo de data e hora do sysvar `Clock` é definido pelo líder do bloco, dentro de certos limites. Assim, o Proof of History deixa de ditar o ritmo da produção de blocos. Separadamente, o tempo de slot foi reduzido de 400 ms para 200 ms em quatro etapas ao longo de outubro de 2026\. A Foundation ressalta que tempo de bloco e finalidade são medidas diferentes. ## Os números: parâmetros de projeto confirmados versus metas A tabela abaixo lista os principais números e indica o tipo de afirmação de cada um. "Parâmetro de projeto" significa uma regra escrita na especificação do protocolo. "Meta" significa um objetivo de desempenho que ainda não foi medido na mainnet. | Item | TowerBFT (antes) | Alpenglow / Votor (depois) | Tipo de afirmação | Fonte | | -------------------------------------- | ---------------------------------- | ----------------------------------------------------------- | ------------------------------------------ | ----------------------- | | Tempo até a finalidade | \~12,8 segundos | \~150 ms | Meta; "uma expectativa, não uma constante" | Solana Foundation | | Limite de finalidade do caminho rápido | n/a | 80% do stake, uma rodada | Parâmetro de projeto | Solana Foundation, Anza | | Limite de finalidade do caminho lento | n/a | 60% do stake, duas rodadas | Parâmetro de projeto | Solana Foundation, Anza | | Tolerância a falhas | Menos de 33% de stake malicioso | 20% malicioso + 20% offline, simultaneamente | Afirmação de projeto da Anza | Anza | | Custo de votação do validador | \~1 SOL por época em taxas de voto | Validator Admission Ticket de 0,8 SOL por época, queimado | Regra do protocolo | Solana Foundation | | Limite do certificado de migração | n/a | 82% do stake | Especificação (SIMD-0384) | SIMD-0384 | | Tempo de bloco (slot) | 400 ms | 200 ms (reduzido em outubro de 2026, separado do Alpenglow) | Concluído | Solana Foundation | Dados referentes ao momento da pesquisa deste artigo, em 21 de outubro de 2026, com base nas fontes listadas abaixo. Se a meta for atingida, a queda de 12,8 segundos para 150 milissegundos tornaria a finalidade cerca de 85 vezes mais rápida. Em maio de 2026, o economista-chefe da Anza, Max Resnick, disse ao Decrypt que o tempo até a finalidade "caiu \~100 vezes" quando os clusters de teste passaram do TowerBFT para o Alpenglow. Nenhum dos dois números foi medido ainda sob a carga total da mainnet. ## Como a troca deve acontecer O procedimento de migração está definido no SIMD-0384, escrito por Kobi Sliwinski, Ashwin Sekar e Carl Lin, da Anza. A página da Solana Foundation e a especificação descrevem a seguinte sequência: 1. **Feature gate.** O recurso Alpenglow é ativado no início da época 1064\. A Anza diz que "nada migra imediatamente". O TowerBFT continua funcionando nos primeiros 5.000 slots da época. 2. **Blocos só de votos.** Depois desses 5.000 slots, os blocos podem conter apenas votos de validadores. As transações dos usuários ficam pausadas nessa janela. A Foundation situa a tomada do consenso no slot 459.653.000. 3. **Certificado gênese.** Os validadores escolhem um bloco recente como ponto de partida, ou "bloco gênese", do Alpenglow e assinam votos BLS para ele. Quando pelo menos 82% do stake tiver assinado, forma-se um certificado gênese. 4. **Reversão e transição.** Os validadores descartam os blocos só de votos posteriores ao bloco gênese, passam o consenso ao Votor e retomam as transações dos usuários. O SIMD-0384 diz que o efeito sobre as transações dos usuários é, "na melhor das hipóteses, de apenas um slot além do slot-limite da migração". A Anza espera que a transição leve centenas de milissegundos. ### O horário é uma estimativa Os horários divulgados não coincidem. A Solana Foundation estima que a época 1064 começa por volta das 13h20 UTC. O anúncio da Anza, segundo o Solana Compass, indica cerca de 14h50 UTC para a entrada em operação. O Solana Compass observou que a Anza não esclareceu se 14h50 UTC se refere à ativação do feature gate ou à transição. Os limites de época dependem da velocidade de produção dos slots, então o momento exato pode mudar. A página do Alpenglow da Anza também diz que a migração da mainnet "será anunciada" depois que seu período de observação confirmar os testes anteriores. Quando este artigo foi escrito, o Bullquill não havia encontrado confirmação pública de que o certificado gênese da mainnet tivesse se formado. A própria data também mudou. No fim de setembro, relatos indicavam que a ativação poderia ocorrer em 28 de setembro. O cofundador da Solana Anatoly Yakovenko e o chefe de pesquisa da Anza Roger Wattenhofer contestaram esses relatos no X, segundo o KuCoin News. A testnet migrou então em 24 de setembro e a devnet em 25 de setembro, antes de a data de 21 de outubro ser definida. ## O que os validadores precisam ter pronto - **Cliente.** A Solana Foundation diz que os validadores precisam rodar a v4.3.2 do Agave, do Jito-Solana ou do Harmonic Salsa antes da época 1064\. Firedancer e Frankendancer não são suportados durante a migração. - **Saldo da vote account.** Os validadores precisam manter pelo menos 0,8 SOL acima do mínimo isento de aluguel (rent-exempt) na vote account (não na identity account) para pagar o Validator Admission Ticket. O primeiro ticket é cobrado no início da época 1064 e cobre a época 1065\. Um validador que não puder pagar não vota nem produz blocos na época seguinte. - **Stake fora dos clientes suportados.** Em 13 de outubro, o Solana Compass contou cerca de 15,8% do stake entre os 500 principais validadores em clientes da família Firedancer. Pelas contas dele, isso deixa cerca de 84% em clientes suportados, pouco acima do limite gênese de 82%. Esse retrato tem uma semana, e os operadores podem ter trocado de cliente desde então. - **Jito BAM.** Segundo a leitura do Solana Compass sobre o changelog da Jito, a Jito informou que os nós BAM da mainnet entrariam em modo de manutenção antes da ativação e desaconselhou rodar FireBAM ou FrankenBAM durante a transição. ## O que desenvolvedores e usuários vão notar - **Contagens de transações menores que não refletem menos atividade.** Os votos saem dos blocos, então os painéis que contam todas as transações vão mostrar uma queda acentuada. Nos dados de 10 a 12 de outubro citados pelo Solana Compass, os votos tiveram média de cerca de 3.060 por segundo, contra cerca de 1.780 transações de usuários por segundo. A Foundation chama isso de "uma mudança contábil". - **Níveis de commitment.** `processed`, `confirmed` e `finalized` continuam existindo, e nenhuma alteração de código é necessária no dia da ativação. Depois da ativação, `confirmed` e `finalized` descrevem o mesmo estado, e `confirmed` será removido em uma versão futura. A Foundation recomenda mudar o código para `finalized` somente depois que o Alpenglow estiver ativo. - **Como verificar se a troca aconteceu.** O método RPC `getAgGenesisCert` retorna `null` enquanto o cluster roda o TowerBFT e retorna um certificado após a migração. Nós RPC anteriores à v4.3 retornam o erro "Method not found". A Foundation recomenda condicionar a lógica específica do Alpenglow a essa chamada, e não a uma data. - **Pipelines de dados.** Um slot agora pode conter mais de um bloco candidato. A Foundation recomenda que consumidores de Geyser e gRPC armazenem os dados em buffer por slot e por `bank_id`. Para usuários comuns, a principal mudança esperada é que as transações alcancem finalidade plena e irreversível muito mais rápido. A Foundation não promete nenhuma mudança específica em taxas ou capacidade de processamento decorrente apenas do Votor. ## O que está confirmado, o que está programado e o que não foi verificado | Categoria | Itens | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Confirmado | Migrações da testnet (24 set.) e da devnet (25 set.) concluídas; chaves BLS (8 jul.) e Validator Admission Ticket (22 jul.) ativados na mainnet; tempo de slot reduzido para 200 ms; requisitos para validadores publicados. | | Programado | Ativação do recurso na mainnet na época 1064, em 21 de outubro; tomada do consenso pelo Votor no slot 459.653.000; transição rápida de líder (fast leader handoff) prevista para o Agave 4.4; remoção do nível de commitment confirmed em uma versão futura. | | Ainda sem data | Rotor (Fase 2) e suporte do Firedancer ao Alpenglow. | | Ainda não verificado na mainnet | Finalidade de \~150 ms; o comportamento da tolerância a falhas 20+20 diante de ataque ou pane reais; a duração da pausa nas transações dos usuários durante a transição. | ## O que significa O Alpenglow é a maior mudança já feita no protocolo central da Solana. Ele substitui o sistema de votação que a rede usa desde o lançamento. Se o Votor atingir suas metas, aplicações que precisam de certeza de liquidação, como pagamentos, exchanges e pontes entre blockchains, poderão considerar as transações definitivas em uma fração de segundo, em vez de esperar mais de dez segundos. A retirada dos votos dos blocos também muda a forma de medir a atividade da rede, então comparações de transações por segundo antes e depois de 21 de outubro não serão equivalentes. Há também riscos reais de execução. A transição depende de 82% do stake rodar software suportado no momento certo, o que deixa uma margem estreita, considerando a fatia de stake em clientes da família Firedancer. A diversidade de clientes diminui enquanto a migração ocorre. O modelo de tolerância a falhas é novo e só foi testado em redes de teste. O número de 150 ms vai depender da distribuição do stake e da geografia. Os pontos a acompanhar são se o certificado gênese se forma no prazo, quanto tempo dura a pausa nas transações dos usuários, como ficam os tempos de finalidade nos primeiros dias e quando Firedancer e Rotor ganham datas. ## Perguntas frequentes ### O que é a atualização Alpenglow da Solana? O Alpenglow é um novo protocolo de consenso para a Solana projetado pela Anza. Ele tem duas partes: o Votor, que cuida da votação e da finalidade, e o Rotor, que cuida da propagação de blocos. A troca na mainnet em 21 de outubro de 2026 ativa apenas o Votor. ### Quão rápida será a finalidade depois do Alpenglow? A Solana Foundation indica uma meta de cerca de 150 milissegundos, contra cerca de 12,8 segundos no TowerBFT. Ela descreve os 150 ms como uma expectativa, e não uma constante, porque o número depende da distribuição do stake e da geografia. ### O que significa tolerância a falhas 20+20? A Anza afirma que o Votor consegue continuar funcionando com até 20% do stake agindo de forma maliciosa e outros 20% offline ao mesmo tempo. O TowerBFT tolerava menos de 33% de stake malicioso. ### Quando o Rotor entra em operação? O Rotor, que substituiria a camada de propagação Turbine, está planejado para uma versão posterior, depois da adoção do Votor. Nem a Anza nem a Solana Foundation definiram uma data ainda. ### Como os desenvolvedores podem verificar se o Alpenglow está ativo? O método RPC getAgGenesisCert retorna null enquanto a rede roda o TowerBFT e retorna um certificado após a migração. A Solana Foundation recomenda condicionar a lógica específica do Alpenglow a essa chamada, e não a uma data. ## Fontes - [Solana Foundation: Alpenglow upgrade page](https://solana.com/upgrades/alpenglow?ref=bullquill.com) - [Anza: Alpenglow](https://anza.xyz/alpenglow?ref=bullquill.com) - [SIMD-0384: Alpenglow migration (Solana Improvement Documents)](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0384-alpenglow-migration.md?ref=bullquill.com) - [Solana Compass: Anza sets Alpenglow mainnet date](https://solanacompass.com/news/anza-sets-alpenglow-mainnet-date-solanas-consensus-switch-is-scheduled-for-october-21-at-about-1450-utc?ref=bullquill.com) - [Decrypt: Solana Alpenglow upgrade begins testing ahead of full rollout](https://decrypt.co/367470/solana-alpenglow-upgrade-begins-testing-ahead-full-rollout?ref=bullquill.com) - [KuCoin News: Solana developers deny Alpenglow mainnet activation on September 28](https://www.kucoin.com/news/flash/solana-developers-deny-alpenglow-mainnet-activation-on-september-28?ref=bullquill.com) - [Jito BAM changelog, September 23 to October 9](https://bam.dev/blog/bam-changelog-sept-23-oct-9/?ref=bullquill.com) Este artigo é apenas informativo e não constitui recomendação de investimento.