---
title: "Solana Alpenglow: a maior reformulação de consenso da história do Solana"
description: "O Alpenglow substitui tanto o Proof of History quanto o Tower BFT por uma nova arquitetura de consenso que reduz a finalidade de 12,8 segundos para 150 milissegundos e elimina 75% da sobrecarga de espaço de bloco do Solana."
---

# Solana Alpenglow: a maior reformulação de consenso da história do Solana

<ImageBlock
  src="https://media.alchemy.com/solana-alpenglow-blog-header.png"
  alt="Explicação da atualização de consenso Alpenglow do Solana"
  width={1920}
  height={900}
  priority
/>

Transações do Solana levam 12,8 segundos para serem finalizadas. Depois do Alpenglow, isso cai para 150 milissegundos.

Mas a velocidade é só a superfície. O Alpenglow remove o Proof of History e o Tower BFT, os dois sistemas que definiram o consenso do Solana desde o lançamento, e os substitui por uma arquitetura mais simples que também elimina as transações de voto on-chain. Esses votos consomem atualmente ~75% do espaço de bloco do Solana. A proposta passou na governança com 98,27% de aprovação, está em testes em cluster privado agora, e o mainnet é esperado para o final de 2026.

## O que é o Alpenglow?

Alpenglow é uma substituição completa da camada de consenso do Solana. A nova arquitetura finaliza transações em 100-150 milissegundos em vez de 12,8 segundos, e ao mover a votação dos validadores para fora da chain, libera aproximadamente três quartos do espaço de bloco para transações reais de usuários.

Formalizado como [SIMD-0326](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md), o upgrade é construído em torno de dois novos protocolos:

- Votor: um novo sistema de votação e finalização que substitui o Tower BFT
- Rotor: um novo sistema de propagação de blocos que substitui o Turbine

Pense assim: o Tower BFT é como um processo de aprovação de 32 etapas, em que cada bloco sobe por camadas de confirmação. O Alpenglow reduz isso a uma ou duas rodadas rápidas. O upgrade também aposenta o Proof of History, o relógio criptográfico original do Solana. Em vez de rodar uma cadeia de hash contínua, os validadores usam um tempo de bloco fixo de 400ms com timeouts locais.

## Quem está construindo isso?

A pesquisa veio do laboratório de sistemas distribuídos do Professor Wattenhofer na ETH Zurich. A [Anza](https://www.anza.xyz/blog/alpenglow-a-new-consensus-for-solana), equipe principal por trás do [Agave validator client](/blog/preparing-for-the-agave-2-0-upgrade), está liderando a implementação. A equipe Firedancer da Jump Crypto está colaborando na compatibilidade multi-client.

## Em que ponto isso está agora?

- **Maio de 2025**: Apresentado no Solana Accelerate em Nova York
- **Setembro de 2025**: Votação de governança aprovada, 98,27% a favor, com 52% do stake total participando
- **Início de 2026**: Disponível no branch master do Agave para testes em cluster privado
- **Q3 2026**: Lançamento completo visando o Agave 4.1
- **Final de 2026**: Ativação no mainnet esperada após testes da comunidade e auditorias de segurança (ainda não está em clusters de produção em abril de 2026)

## Como o Alpenglow funciona?

Três mudanças.

### 1. Votor: como os blocos são finalizados

O sistema atual (Tower BFT) exige 32 confirmações incrementais. Cada camada adiciona um período de lockout.

O Votor substitui isso por uma ou duas rodadas de votação:

- **Caminho rápido (~100ms)**: Se 80%+ dos validadores aprovarem na primeira rodada, o bloco é final. Pronto.
- **Caminho lento (~150ms)**: Se 60-80% aprovarem na rodada um, uma segunda rodada é executada. Se 60%+ aprovarem novamente, é final.

Ambos os caminhos rodam simultaneamente. O que terminar primeiro vence.

Os validadores enviam votos como mensagens UDP leves diretamente uns aos outros, não como transações on-chain. O Votor agrupa esses votos usando [agregação de assinaturas BLS](https://en.wikipedia.org/wiki/BLS_digital_signature): milhares de assinaturas individuais comprimidas em uma única prova compacta. Somente o certificado agregado (~1.000 bytes) chega on-chain, substituindo os ~500KB de dados de voto atualmente registrados por slot.

Isso é um grande avanço. Atualmente, ~75% de todas as transações do Solana são votos de validadores. O Alpenglow os elimina completamente.

### 2. Rotor: como os dados de bloco se propagam

*Nota: o Rotor faz parte da visão mais ampla do Alpenglow, mas é lançado como um SIMD separado das mudanças centrais de consenso do Votor.*

Atualmente, o Solana usa o Turbine, uma árvore de retransmissão em múltiplas camadas com um fanout de 200 nós. Os dados de bloco passam por várias camadas. Pense nisso como um jogo de telefone sem fio.

O Rotor substitui isso por uma transmissão de único salto: o produtor de bloco envia dados para um pequeno conjunto de nós de retransmissão, e esses relays enviam para todos de uma vez. De uma corrente telefônica para uma transmissão em grupo.

Os números do [whitepaper do Alpenglow](https://www.anza.xyz/alpenglow-1-1): transmitir 1.500 shreds leva 18ms em uma banda de 1 Gb/s. Alcançar 80% do stake total precisa de apenas ~150 nós em cerca de 2ms.

### 3. Sem mais Proof of History

O Alpenglow aposenta o relógio criptográfico do Solana. Em vez disso, os validadores usam um tempo de bloco fixo de 400ms e relógios locais com timeouts:

- Bloco chega antes do timeout: aprova-o (NotarVote)
- Timeout expira sem bloco: pula-o (SkipVote)

O protocolo tolera a deriva de relógio proporcionalmente: 5% de deriva precisa apenas de uma extensão de 5% no timeout.

## Como muda o modelo de segurança?

O Alpenglow introduz um framework de tolerância a falhas "20+20":

<EmbeddedTable
  table={{
    columns: [
      { key: "scenario", width: 200, title: "Scenario", dataType: "object" },
      { key: "traditional", width: 200, title: "Traditional BFT", dataType: "object" },
      { key: "alpenglow", width: 200, title: "Alpenglow", dataType: "object" },
    ],
    data: [
      {
        scenario: { title: "Malicious validators", tooltip: "", icon: "" },
        traditional: { title: "Up to 33%", tooltip: "", icon: "" },
        alpenglow: { title: "Up to 20%", tooltip: "", icon: "" },
        id: 0,
      },
      {
        scenario: { title: "Offline validators", tooltip: "", icon: "" },
        traditional: { title: "Up to 33%", tooltip: "", icon: "" },
        alpenglow: { title: "Up to 20%", tooltip: "", icon: "" },
        id: 1,
      },
      {
        scenario: { title: "Both at once", tooltip: "", icon: "" },
        traditional: { title: "Up to 33%", tooltip: "", icon: "" },
        alpenglow: { title: "Up to 40%", tooltip: "", icon: "" },
        id: 2,
      },
    ],
  }}
/>

Por que isso funciona? Para segurança: forks conflitantes não podem alcançar quórum simultaneamente, porque 80% + 60% = 140% > 100%. Para liveness: a rede ainda finaliza através do caminho lento mesmo se 20% do stake ficar offline.

O trade-off: a tolerância Byzantine pura cai de 33% para 20%. Mas, na prática, falhas do mundo real são mistas. Alguns nós são maliciosos, outros estão apenas offline. A tolerância combinada de 40% lida com esse cenário melhor do que os 33% do BFT tradicional.

## Quais são os ganhos de desempenho?

<EmbeddedTable
  table={{
    columns: [
      { key: "metric", width: 220, title: "Metric", dataType: "object" },
      { key: "current", width: 200, title: "Current Solana", dataType: "object" },
      { key: "alpenglow", width: 200, title: "With Alpenglow", dataType: "object" },
    ],
    data: [
      {
        metric: { title: "Transaction finality", tooltip: "", icon: "" },
        current: { title: "~12.8 seconds", tooltip: "", icon: "" },
        alpenglow: { title: "100–150ms", tooltip: "", icon: "" },
        id: 0,
      },
      {
        metric: { title: "Optimistic confirmation", tooltip: "", icon: "" },
        current: { title: "500–600ms", tooltip: "", icon: "" },
        alpenglow: { title: "100–150ms (deterministic)", tooltip: "", icon: "" },
        id: 1,
      },
      {
        metric: { title: "Max theoretical TPS", tooltip: "", icon: "" },
        current: { title: "~65,000", tooltip: "", icon: "" },
        alpenglow: { title: "~107,000", tooltip: "", icon: "" },
        id: 2,
      },
      {
        metric: { title: "Vote transactions (% of block space)", tooltip: "", icon: "" },
        current: { title: "~75%", tooltip: "", icon: "" },
        alpenglow: { title: "0%", tooltip: "", icon: "" },
        id: 3,
      },
      {
        metric: { title: "Validator vote cost", tooltip: "", icon: "" },
        current: { title: "~1 SOL/day", tooltip: "", icon: "" },
        alpenglow: { title: "Eliminated", tooltip: "", icon: "" },
        id: 4,
      },
      {
        metric: { title: "Min. profitable stake", tooltip: "", icon: "" },
        current: { title: "~4,850 SOL", tooltip: "", icon: "" },
        alpenglow: { title: "~450 SOL", tooltip: "", icon: "" },
        id: 5,
      },
      {
        metric: { title: "On-chain vote data per slot", tooltip: "", icon: "" },
        current: { title: "~500KB", tooltip: "", icon: "" },
        alpenglow: { title: "~1,000 bytes", tooltip: "", icon: "" },
        id: 6,
      },
    ],
  }}
/>

Resultados de simulação mostram que 65% do stake finaliza dentro de 50ms de latência bruta da rede. Com um salto de rede unidirecional mais longo de ~70ms, a finalização pelo caminho rápido fica em torno de 120-150ms.

## O que muda para os validadores?

A economia muda:

- **As taxas de voto desaparecem.** Atualmente ~1 SOL/dia por validador. O Alpenglow move toda a votação para fora da chain.
- **Novo custo: Validator Admission Ticket (VAT).** ~0,8 SOL/dia, totalmente queimado para reduzir a inflação.
- **Limite de validadores: 2.000** (selecionados por maior stake).
- **Barreira de entrada cai ~90%.** O stake mínimo lucrativo vai de ~4.850 SOL para ~450 SOL.
- **Custos operacionais caem 20-50%** no geral.
- **Suporte a HSM.** As chaves de identidade podem residir em módulos de segurança de hardware, já que não assinam mais transações de voto de alta frequência.

## O que muda para desenvolvedores e usuários?

**Para desenvolvedores**, a maior mudança não é o número de velocidade. É que a finalização se torna uma única coisa.

Hoje, o Solana tem três níveis de compromisso: `processed`, `confirmed` (~500ms, probabilístico), e `finalized` (~12,8s, determinístico). Cada desenvolvedor faz uma escolha por funcionalidade: aceitar o risco de rollback e mostrar ao usuário um resultado rápido, ou esperar 12,8 segundos e ter certeza. O crédito de depósitos em exchanges, confirmações de bridges e engines de liquidação esperam todos por `finalized` porque até um pequeno risco de rollback é inaceitável. Tudo o mais usa `confirmed` e torce para dar certo.

O Alpenglow reduz isso a um único nível. Finalização determinística de 100-150ms em toda transação. Sem trade-offs de nível de compromisso. Sem lógica de retry para transações que desaparecem. Uma verificação, pronto.

É isso que torna novos padrões viáveis: order books on-chain podem oferecer spreads mais apertados porque os market makers sabem que o estado de sua cotação é final em 150ms. Exchanges de perpétuos podem ver custos de latência menores em leilões JIT. Bridges cross-chain eliminam o gargalo de finalização do lado do Solana. E o crédito de depósito em exchanges passa de uma espera de 13 segundos para instantâneo.

**Para usuários**, as transações confirmam rápido o suficiente para parecer instantâneas. A mudança maior é na capacidade: remover as transações de voto libera 75% do espaço de bloco, o que significa taxas mais baixas e menos congestionamento em períodos de tráfego intenso.

**Para [instituições financeiras construindo no Solana](/overviews/complete-guide-to-solana-for-financial-institutions)**, a finalização determinística em menos de um segundo fecha a lacuna com os trilhos de pagamento tradicionais. Liquidação de stablecoins, operações com tesouraria tokenizada e transferências transfronteiriças não precisam mais de um buffer de 13 segundos.

## O que ainda está por vir?

O Alpenglow também facilita a vida do [Firedancer](https://jumpcrypto.com/firedancer/), o cliente validador independente da Jump Crypto escrito em C/C++. O Firedancer melhora o desempenho de nó único; o Alpenglow redesenha como os nós chegam ao consenso. O protocolo mais simples significa menos complexidade de consenso para reimplementar em uma segunda codebase — uma vantagem prática para a diversidade multi-client.

O [SIMD-0326](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md) cobre apenas as mudanças de consenso do Votor. Três componentes do [whitepaper do Alpenglow](https://www.anza.xyz/alpenglow-1-1) ficam adiados para propostas futuras:

- Rotor (propagação de blocos), SIMD separado
- Smart Sampling (otimização de banda)
- Execução Lazy/Assíncrona

O caminho para o mainnet: lançamento do Agave 4.1 no Q3 2026, testes da comunidade e auditorias de segurança durante o Q4, ativação no mainnet no final de 2026.

## Construa no Solana com a Alchemy

O Alpenglow torna o Solana mais rápido, mas você ainda precisa de infraestrutura confiável para construir sobre ele.

A [plataforma Solana da Alchemy](https://www.alchemy.com/solana) oferece [acesso a dados de arquivo até 20x mais rápido](/blog/how-alchemy-built-the-fastest-archival-methods-on-solana) que outros provedores, streaming gRPC pela metade do preço com recuperação de reconexão de 6.000 blocos, e chamadas de métodos pesados 10x mais rápidas, como `getProgramAccounts`.

- **Smart WebSockets** que eliminam conexões perdidas, além de conexões staked para roteamento confiável de transações
- **Suporte a transações gasless** para remover atrito para os usuários finais
- **99,99% de confiabilidade** com implantação multi-região e 3-5 camadas de failover autônomo

[Solflare](https://www.alchemy.com/dapps/solflare), Robinhood, OpenSea e Circle já rodam na [infraestrutura Solana da Alchemy](/blog/solana-infrastructure). Preços pay-as-you-go, sem compromissos de longo prazo.

[Comece com um endpoint Solana RPC gratuito →](https://www.alchemy.com/solana)

## Perguntas frequentes

### O que é o Solana Alpenglow?

Alpenglow é uma substituição completa da camada de consenso do Solana que reduz a finalização de transações de 12,8 segundos para 100-150 milissegundos e elimina as transações de voto on-chain, liberando aproximadamente 75% do espaço de bloco para transações de usuários.

### O que o Alpenglow substitui na arquitetura atual do Solana?

O Alpenglow remove o Proof of History, o Tower BFT e as transações de voto on-chain, substituindo-os pelo Votor (um novo sistema de votação), pelo Rotor (um novo sistema de propagação de blocos) e por um tempo de bloco fixo de 400ms com timeouts locais.

### Quando o Alpenglow será lançado no mainnet?

O Alpenglow deve ser ativado no mainnet no final de 2026, após o lançamento do Agave 4.1 no Q3 de 2026 e os testes da comunidade e auditorias de segurança subsequentes ao longo do Q4 de 2026.

### Como o Alpenglow alcança uma finalização mais rápida?

O Votor reduz o processo atual de confirmação de 32 etapas para uma ou duas rodadas de votação: o caminho rápido finaliza em ~100ms com 80%+ de aprovação dos validadores, enquanto o caminho lento finaliza em ~150ms com 60%+ de aprovação em duas rodadas.

### Como o Alpenglow impacta os custos dos validadores?

O Alpenglow elimina o custo de ~1 SOL/dia para transações de voto on-chain e reduz o stake mínimo lucrativo de ~4.850 SOL para ~450 SOL, embora os validadores paguem uma nova taxa de Validator Admission Ticket de ~0,8 SOL/dia, que é queimada.

### Quais são os trade-offs de segurança no Alpenglow?

O Alpenglow tolera até 20% de validadores maliciosos e 20% de nós offline (ou 40% combinados), em comparação com o limite de 33% do BFT tradicional, usando um quórum de 80% para finalização pelo caminho rápido e 60% para o caminho lento, prevenindo forks conflitantes.

### Como o Alpenglow muda os níveis de compromisso para desenvolvedores?

O Alpenglow reduz os três níveis de compromisso do Solana (processed, confirmed, finalized) a uma única finalização determinística em 100-150ms, eliminando a necessidade de escolher entre velocidade e risco de rollback.

### Qual é o status atual do desenvolvimento do Alpenglow?

O Alpenglow passou na governança com 98,27% de aprovação em setembro de 2025, está disponível no branch master do Agave para testes em cluster privado desde o início de 2026, e ainda não está em clusters de produção em abril de 2026.

## Recursos principais

- [Alpenglow Whitepaper v1.0](https://www.anza.xyz/alpenglow-1-0) | [v1.1](https://www.anza.xyz/alpenglow-1-1)
- [Proposta SIMD-0326 (GitHub)](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md)
- [Blog da Anza: Alpenglow, um novo consenso para o Solana](https://www.anza.xyz/blog/alpenglow-a-new-consensus-for-solana)