Alpenglow: a grande reformulação do consenso da Solana

Insights práticos 

• O principal benefício do Alpenglow para a Solana é uma redução de 100 vezes no tempo até a finalidade da transação. Dependendo da localização geográfica do validador, esse tempo cairá de 12,8 segundos para 100–150 ms, permitindo que a Solana concorra com infraestruturas Web2 mais centralizadas e viabilizando aplicações em tempo real.
• O Alpenglow simplifica o consenso ao eliminar vários componentes legados da Solana, incluindo Proof of History, Tower BFT e a propagação de votos baseada em gossip. No lugar do Proof of History, o Alpenglow introduz um tempo de bloco fixo de 400 ms, que não equivale a ter um relógio sincronizado globalmente, para coordenar o tempo em toda a rede.
• O protocolo é estruturado em torno de dois componentes fundamentais: Rotor, um protocolo aprimorado de propagação de blocos que amplia e aperfeiçoa a arquitetura Turbine existente da Solana; e Votor, um novo mecanismo de votação que substitui Tower BFT, Proof of History e o uso de gossip para a propagação de votos.
• Toda a atividade de consenso passa a ocorrer off-chain — os certificados de voto ainda serão ancorados on-chain, substituindo as transações de voto por slot por um sistema leve de certificados BLS. Essa mudança elimina as taxas de votação como as conhecemos hoje, que historicamente têm sido o principal custo operacional dos validadores, melhorando significativamente a economia dos validadores para operadores menores. O modelo econômico exato ainda está sendo finalizado.
• O Alpenglow oferece um modelo de resiliência “20+20”: ele mantém a segurança se até 20% do stake estiver sob controle de adversários e mantém a vivacidade se outros 20% distintos do stake estiverem offline ou sem responder. Isso permite que o protocolo tolere condições de rede hostis e instáveis.
• O Votor usa um sistema de votação simultâneo em dois níveis para o consenso. No caminho de Finalização Rápida, se um bloco receber a aprovação de ≥80% do stake na primeira rodada, ele será finalizado imediatamente com um Certificado de Finalização Rápida. No caminho de Finalização Lenta, uma segunda rodada começa assim que um bloco recebe a aprovação de ≥60% do stake. Se essa rodada alcançar ≥60% de aprovação, o bloco será finalizado com um Certificado Finalizado.
• Diferentemente do Turbine, que depende de uma estrutura de árvore multicamadas com um fanout de 200, o Rotor usa um modelo de salto único no qual nós de retransmissão cuidam da disseminação de shreds. Cada shred é transmitido como um único pacote codificado para correção de apagamentos, e o design do Rotor é nativamente compatível com sistemas multicast como o DoubleZero. Observe que o Rotor provavelmente será uma SIMD separada do Votor.
• Atualmente, espera-se que o Alpenglow seja lançado na mainnet da Solana até o início do próximo ano. Uma implementação de referência do protocolo está disponível no Github.

Introdução

O algoritmo de consenso Alpenglow representa a reformulação mais significativa do protocolo principal da Solana até hoje. Com base nos avanços mais recentes da pesquisa em blockchain, ele rearquitetura profundamente a forma como o consenso é alcançado em toda a rede.

O Alpenglow é fruto do trabalho da nova divisão de pesquisa da Anza, liderada pelo professor Roger Wattenhofer, da ETH Zurich, uma das instituições de ciência da computação mais bem classificadas do mundo. Considerado uma das principais autoridades em sistemas distribuídos, o professor Wattenhofer foi coautor do artigo de 2024 Interrompendo a blockchain da Solana com uma fração mínima de stake, que revelou possíveis vulnerabilidades de vivacidade no protocolo de consenso atual da Solana. Na Anza, o professor Wattenhofer trabalha com seus ex-alunos de doutorado Kobi Sliwinski e Quentin Kniep.

A tarefa da equipe era reformular o algoritmo de consenso da Solana para torná-lo mais eficiente e comprovadamente correto, preservando sua arquitetura baseada no Turbine. O Alpenglow incorpora muitos dos avanços mais recentes na pesquisa de sistemas distribuídos, especialmente no tratamento de comportamentos adversariais da rede.

O nome Alpenglow deriva da palavra alemã Alpenglühen, que significa “brilho dos Alpes”. Refere-se à luz marcante observada nos picos das montanhas ao nascer ou ao pôr do sol e é uma referência às origens suíças do protocolo.

Quais são os benefícios do Alpenglow?

Abaixo está um resumo geral dos principais benefícios que o Alpenglow deve oferecer. Cada um deles será analisado em mais detalhes ao longo do restante do artigo.

Finalidade mais rápida

O principal benefício do Alpenglow para a Solana é uma redução de 100 vezes no tempo até a finalidade da transação, ou seja, na rapidez com que as transações dos usuários são enraizadas em uma rede blockchain. Dependendo da localização geográfica do validador, esse tempo cairá de 12,8 segundos para 100–150 ms, permitindo que a Solana concorra com infraestruturas Web2 mais centralizadas e viabilizando aplicações em tempo real.

• Finalidade atual da Solana: 12,8 segundos 
• Confirmação otimista atual da Solana: 500–600 milissegundos
• Finalidade do Alpenglow: 150 milissegundos (valor mediano)*
• Finalidade mais rápida da concorrência: 400 milissegundos (valor autodeclarado)

*varia de acordo com a geografia e a distribuição do cluster.

Fim das transações de voto

Com o Alpenglow, toda a atividade de consenso acontece off-chain. Isso reduzirá a carga sobre a unidade de processamento de transações (TPU) e o replay, que não precisarão mais processar transações de voto.

O Alpenglow também melhorará significativamente a economia para validadores menores. As taxas de transações de voto são a maior despesa operacional dos validadores. Ao eliminar essas taxas por meio da votação off-chain, os custos de participação caem drasticamente, tornando mais viável a operação de validadores menores e reduzindo a barreira de entrada para contribuir com a segurança da rede.

Outras vantagens incluem uma lógica de compromisso simplificada e um crescimento mais lento do ledger, já que as transações de voto deixam de ocupar espaço nos blocos ou aumentar o tamanho do ledger.

Essa mudança também traz o benefício adicional de eliminar a ambiguidade nas métricas de transações por segundo (TPS) da Solana. Hoje, o TPS costuma ser relatado de duas formas: TPS total, que inclui transações de voto, e TPS real, que contabiliza apenas transações que não são de voto.

Um protocolo mais enxuto

O Alpenglow simplifica o processo de alcançar consenso ao remover vários componentes legados da Solana, incluindo Proof of History, Tower BFT e o uso de gossip para a propagação de votos. Embora incorpore avanços de ponta da pesquisa moderna em blockchain, ele faz isso sem introduzir complexidade desnecessária.

O Votor e o Rotor do Alpenglow estabelecem a base para futuras atualizações, como a execução assíncrona e múltiplos líderes simultâneos (MCL), deixando a Solana bem posicionada para novos ganhos de desempenho e para a evolução do protocolo.

Qual é o mecanismo de consenso atual da Solana?

Proof of History

Proof of History (PoH) não é um algoritmo de consenso. Na verdade, é uma ferramenta que ajuda a alcançar o consenso. A confusão provavelmente surge de sua nomenclatura — “Proof of X” —, que sugere que o objeto em questão é um algoritmo de consenso para quem conhece Proof of Work e Proof of Stake. É mais útil considerá-lo um algoritmo de “pré-consenso” que simplifica o consenso por meio do processamento eficiente de transações.

Em linhas gerais, o PoH é um relógio descentralizado usado para comprovar o tempo em uma rede adversarial. De forma mais precisa, o PoH é uma função criptográfica de registro de data e hora que permite que os nós concordem sobre a ordem dos eventos sem se comunicarem entre si. Ele usa uma função hash sequencial resistente à pré-imagem para criar uma cadeia de hashes. Os líderes atribuem registros de data e hora aos blocos usando esses hashes para comprovar que determinado período passou. Como todos os hashes estão encadeados, o PoH fornece um registro histórico que comprova que os dados existiam em um momento específico. 

Essa abordagem difere da adotada por outras redes, que geralmente decidem a ordem dos blocos durante o consenso e depois adicionam os registros de data e hora. Na Solana, em vez disso, primeiro é criado um relógio verificável criptograficamente, as transações são transmitidas em relação a esse relógio e o consenso verifica o registro pré-ordenado das transações. O encadeamento de hashes torna a ordem temporal incontestável. 

Tower BFT

O Tower BFT atua depois que os shreds (ou seja, blocos parciais) são propagados para outros validadores e reproduzidos pela rede para determinar se o bloco se tornará parte do ledger. Conceitualmente, é um algoritmo de consenso semelhante ao pBFT, desenvolvido para aproveitar o relógio do Proof of History em toda a rede. Em vez de exigir uma rodada de consenso síncrona para cada slot, os validadores se comprometem antecipadamente com slots futuros com base na sequência do Proof of History que já observaram, permitindo a produção contínua de blocos.

Os validadores emitem uma transação de voto por slot, assinada por sua conta de voto. Os votos em um determinado fork geram um lockout (ou seja, um tempo limite) para esse fork. Um lockout é um período definido em slots durante o qual um validador não pode votar em outro fork. A ideia é forçar os validadores a se comprometerem com um fork e aumentar exponencialmente o lockout caso queiram trocar de fork. Cada voto carrega um contador de lockout que dobra sempre que o validador vota em um slot descendente, criando uma “torre de votos” de compromissos. Assim, se um validador votar no bloco X, ele ficará impedido de votar em qualquer fork conflitante por uma quantidade exponencialmente crescente de slots futuros (por exemplo, 1, 2, 4, 8…). A violação do lockout pode ser comprovada e punida, embora o slashing ainda não tenha chegado à mainnet.

A Solana alcança dois níveis de finalidade com o Tower BFT: confirmação otimista e finalidade determinística. 

Quando um novo bloco é produzido e ≥66% do stake vota nele, o bloco é reconhecido como parte do fork principal, ou canônico. Isso é chamado de confirmação otimista, pois o bloco recebe um nível de compromisso “confirmed” assim que uma supermaioria vota nele. A confirmação otimista foi introduzida na v1.3 do cliente Solana Labs (agora Agave) para melhorar a experiência do usuário ao tratar um bloco como finalizado antes de sua finalização formal.

Desde o bloco gênese da Solana, nenhum bloco confirmado de forma otimista jamais foi revertido. Para isso acontecer, pelo menos um terço do stake total precisaria revelar um fork conflitante depois que 66% já tivesse votado honestamente. De forma equivalente, quando a contagem de confirmação otimista de um bloco alcança ~87% do stake, um adversário precisaria que ≥20% desse mesmo stake assinasse duas vezes, um ato comprovadamente sujeito a slashing. Embora não seja uma finalidade absoluta no sentido estrito da teoria do consenso, a confirmação otimista oferece fortes garantias na prática. Esses blocos podem ser tratados como finalizados em quase todos os casos de uso — por isso, para fins práticos, a finalidade da Solana costuma ser indicada como 500–600 milissegundos.

A verdadeira finalidade determinística exige que um bloco alcance o lockout máximo na torre de votos, o que corresponde a 32 votos acumulados confirmando-o. Ou seja, o bloco precisa ter outros 32 blocos construídos sobre ele para ser considerado “finalizado” ou enraizado na rede. O tempo para um bloco alcançar a finalidade determinística é de ~12,8 segundos, considerando a exigência de 32 slots e tempos de slot de ~0,4 segundo. A finalidade determinística é alcançada quando a profundidade dos votos com lockout torna impossível uma reversão.

Quais são as limitações do mecanismo de consenso atual da Solana?

Proof of History e Tower BFT ajudaram a Solana a alcançar alto throughput e confirmações otimistas rápidas. No entanto, esse design apresenta várias limitações relacionadas a custo, latência, vivacidade e operação dos validadores.

Alto custo e sobrecarga de votação

Todo validador precisa votar continuamente em cada slot para contribuir com o consenso. Os votos são transações que interagem com o programa de votação, consomem recursos da rede e pagam taxas. 

Aproximadamente três quartos das transações na Solana são transações de voto, gerando uma sobrecarga significativa na rede e um custo real para os validadores em cada slot. Essa dependência desnecessária de votações incessantes introduz uma alta sobrecarga e custos que aumentam conforme o número de slots processados e o número de validadores no cluster. 

Latência da finalidade

Embora a confirmação otimista seja rápida, a finalidade determinística não é. ~12,8 segundos é um tempo lento em comparação com protocolos de consenso mais recentes, como o Mysticeti da Sui, que apresenta um tempo até a finalidade de ~500 ms. Isso cria problemas para aplicações, como corretoras, que exigem certeza absoluta em suas operações. Na prática, os usuários confiam em blocos confirmados. No entanto, a rede ainda precisa manter longos históricos de forks caso ocorram possíveis pequenas reorganizações antes da finalização. 

A diferença entre a confirmação otimista e a latência determinística é uma compensação: o Tower BFT favorece a vivacidade com uma curta janela para contingências de forks, ao custo de uma finalidade mais lenta. Mesmo sem qualquer tipo de ataque ou bug de consenso, a finalidade de ~12,8 segundos fica muito atrás das redes com finalidade rápida e da infraestrutura Web2 existente.

Vivacidade e tolerância a partições da rede

O Tower BFT exige que uma supermaioria dos validadores esteja online e responda para confirmar e finalizar novos blocos. O consenso pode parar se mais de um terço do stake estiver offline ou se a rede estiver gravemente particionada. A Solana ainda pode produzir blocos, priorizando a vivacidade, mas a rede pode não alcançar o limite de votos necessário para confirmar esses blocos de forma otimista. No pior caso, como ocorreu nas interrupções recentes da Solana, validadores presos à espera de votos ou incapazes de processar o fork otimista poderiam causar uma paralisação da rede que exigiria uma reinicialização coordenada.

Essa é uma limitação clássica do consenso BFT. A Solana não possui um mecanismo integrado para lidar com grandes grupos de validadores temporariamente sem resposta. Por isso, a vivacidade da Solana foi prejudicada em condições extremas, pois o protocolo não conseguia lidar de forma adequada com a queda abaixo do limite de supermaioria necessário para o consenso. O Tower BFT precisava continuar produzindo blocos com menos de 60% do stake online. Isso significa que esses blocos jamais poderiam alcançar a confirmação otimista e poderiam ser revertidos.

Complexidade operacional dos validadores

O Tower BFT exige muito dos validadores: transações de voto constantes, rede robusta, atualizações do cliente, prevenção de inadimplência e persistência do “estado da torre”. Se um validador reiniciar ou perder o estado mais recente de sua torre, ele correrá o risco de emitir um voto que viole um compromisso de lockout anterior, resultando na perda de créditos de votação.

A dependência do protocolo em relação ao hashing contínuo do Proof of History e à propagação de votos por gossip significa que os validadores trabalham intensamente para acompanhar o tempo de slot de ~400 ms da Solana. Os altos requisitos de hardware da Solana, embora diminuam com o tempo, também não são triviais. Além disso, independentemente do stake, todos os validadores precisam votar em cada slot para maximizar as recompensas, o que significa que validadores menores pagam as mesmas taxas e têm, em grande parte, a mesma carga de trabalho que os maiores. Como os slots de líder são atribuídos proporcionalmente ao stake, validadores com mais stake produzem mais blocos e, portanto, recebem uma parcela maior das taxas de voto pagas por outros validadores. Isso cria um fluxo circular de valor no qual as taxas de voto efetivamente redistribuem capital para validadores com mais stake.

Além disso, o mecanismo de consenso atual da Solana torna o replay de blocos duplicados extremamente complexo, pois os clientes precisam gerenciar vários candidatos para o mesmo slot. O sistema de certificados do Votor garante que cada slot confirme um único hash ou um salto explícito, tornando trivial o replay de blocos duplicados.

Fica evidente que o design do Tower BFT, embora inovador, gera uma complexidade operacional considerável para os validadores.

Como o Alpenglow funciona?

O Alpenglow é estruturado em torno de dois componentes principais:

• Rotor: um protocolo aprimorado de propagação de blocos, desenvolvido com base na arquitetura Turbine existente e aperfeiçoando-a.
• Votor: um novo protocolo de votação que substitui Tower BFT, a propagação de votos baseada em gossip e Proof of History na participação do consenso.

Nas próximas seções, analisaremos esses componentes em detalhes.

Rotor: nova camada de disseminação de dados

O Rotor é um protocolo aprimorado de propagação de blocos que se baseia no design do Turbine existente da Solana, com melhorias importantes em eficiência e simplicidade. Diferentemente do Turbine, que usa uma estrutura de árvore multicamadas com um fanout de 200, o Rotor usa um modelo de salto único (2δ). 

Os blocos são divididos em slices, e cada slice é então codificado em vários shreds usando códigos de correção de apagamentos Reed-Solomon. Para garantir a autenticidade dos shreds, o líder cria uma árvore de Merkle dos hashes dos shreds e assina a raiz. Cada shred inclui seu caminho nessa árvore e a assinatura do líder.

Cada shred é enviado diretamente para um nó de retransmissão. Em seguida, os retransmissores enviam seu shred para todos os nós da rede, começando pelo próximo líder. Essa abordagem de uma camada reduz a latência e simplifica o caminho de propagação. Ela também é surpreendentemente rápida:

Tanto o líder quanto os retransmissores de shreds são selecionados por amostragem ponderada por stake, o que significa que cada nó é responsável por transmitir dados proporcionalmente ao seu stake. Devido à codificação para correção de apagamentos, os nós precisam receber apenas um subconjunto dos shreds para reconstruir o slice original do bloco.

Uma diferença importante em relação ao Turbine é que o Rotor transmite apenas uma única versão codificada para correção de apagamentos de cada shred, eliminando a necessidade de enviar separadamente shreds de dados e de recuperação, como o Turbine faz. Embora a redundância (ou seja, a proporção de expansão dos dados) permaneça igual, esse design elimina comportamentos estranhos relacionados ao encaminhamento de shreds de dados e garante simplicidade no design do protocolo.

A arquitetura do Rotor também é compatível com sistemas multicast como o DoubleZero, oferecendo flexibilidade na forma como os blocos são entregues. Como a propagação de blocos consome uma largura de banda significativa — atualmente, grandes validadores chegam perto de 150.000 pacotes de saída por segundo —, o Rotor introduz um modelo no qual os retransmissores são recompensados pela distribuição de dados, alinhando os incentivos para favorecer o desempenho da rede.

O whitepaper do Alpenglow não define um mecanismo concreto para calcular ou distribuir recompensas. No entanto, observa que as recompensas do Rotor devem considerar a largura de banda consumida, e espera-se que os nós que retransmitem mais dados recebam uma parcela maior das recompensas.

O que é Blokstor?

O Blokstor é onde os nós armazenam e gerenciam os dados de blocos recebidos do Rotor. Mais formalmente, o Blokstor é uma estrutura de dados que gerencia o armazenamento de slices. Quando um shred é recebido, seu conteúdo é adicionado ao Blokstor se determinadas condições forem atendidas, incluindo:

• O Blokstor ainda não contém um shred para esses índices
• Uma assinatura válida do líder
• Um caminho válido na árvore de Merkle

O Blokstor emite um evento "Block(slot(b), hash(b) hash(parent(b)))" quando recebe o primeiro bloco completo b para slot(b). O Blokstor também pode executar procedimentos de reparo para coletar e armazenar blocos alternativos para o mesmo slot. Quando um bloco é finalizado, o Blokstor deve armazenar apenas esse bloco no slot correspondente.

Votor: novo mecanismo de votação e finalização

O Votor é o novo mecanismo de votação e finalização do Alpenglow, substituindo o Tower BFT na notarização e finalização de blocos. Ele se inspira na linha de pesquisa do Simplex para aumentar a eficiência e a simplicidade e aplica esses conceitos a um contexto de Proof of Stake. 

O Simplex demonstra que é possível alcançar um acordo bizantino eficiente em um ambiente de Proof of Stake com líderes rotativos e mensagens extremamente pequenas, desde que haja um limite superior rígido para o atraso da rede. Com base nesses insights, o Votor alcança consenso em uma ou duas rodadas.

Em linhas gerais, o Votor garante que, para cada slot, exista um certificado de salto indicando que o slot foi ignorado ou algum bloco notarizado construído sobre a cadeia canônica de blocos notarizados. Para ser notarizado, um bloco precisa ter um certificado válido. Em vez de inundar o gossip com votos, os validadores transmitem mensagens leves de voto para um conjunto de pares ponderado por stake, como uma malha de “envio direto”, em vez do gossip tradicional da Solana. Qualquer nó pode agregar essas assinaturas em um certificado usando o esquema de assinatura Boneh–Lynn–Shacham (BLS) assim que um quórum é atingido. Isso elimina a necessidade de transações de voto por slot, pois o cabeçalho do certificado agregado é o que fica ancorado on-chain.

Como funciona o mecanismo de votação do Votor?

O Votor usa um mecanismo de votação simultâneo e em níveis, dividido em dois caminhos de votação:

• Finalização Rápida: se o bloco proposto receber a aprovação de ≥80% do stake na primeira rodada de votação, ele será finalizado imediatamente e um Certificado de Finalização Rápida será produzido. Essa finalização em uma única rodada é possível porque 80% do stake está bem acima do limite de supermaioria, tornando desnecessária uma segunda rodada de votação para a finalização.
• Finalização Lenta: se a primeira rodada de votação receber a aprovação de <80% do stake, mas de pelo menos 60%, o Votor iniciará imediatamente uma segunda rodada de votação. Quando essa segunda rodada alcançar a aprovação de ≥60% do stake, um Certificado Finalizado será produzido.

Os dois caminhos são executados simultaneamente, e o primeiro a atingir seu limite finaliza o bloco. Assim que um líder termina de ingerir o bloco pai, ele pode começar a transmitir o próximo bloco enquanto os votos ainda estão sendo acumulados. Dessa forma, um bloco é produzido a cada ~400 ms, assim como garantia o antigo consenso da Solana. Esse design assegura que, se a primeira rodada não receber a aprovação de ≥80% do stake, o Votor recorra à segunda rodada de votação. Ele também garante que dois blocos conflitantes não possam alcançar a finalidade devido à sobreposição de stake.

O que é a estrutura de dados Pool do Votor?

A Pool é uma estrutura de dados mantida por cada nó que funciona como um ledger local da atividade de votação e da geração de certificados. Ela memoriza os votos recebidos para cada slot e cada nó. Quando são recebidos votos suficientes, um certificado correspondente é gerado. Quando um certificado recém-recebido ou criado pelo próprio nó é adicionado à Pool, ele é transmitido para todos os outros nós. 

Embora vários validadores possam criar certificados quase ao mesmo tempo, qualquer certificado que atenda ao limite de quórum é funcionalmente equivalente para o consenso, independentemente de quais validadores específicos estejam incluídos no conjunto de assinaturas. A única exceção é o Certificado Finalizado, pois pode haver até três certificações distintas que precisam circular. Nunca há mais de quatro certificados exclusivos de todos os tipos para um determinado slot, e cada certificado exclusivo é transmitido apenas uma vez. Essa abordagem evita spam de votos e, ao mesmo tempo, permite que qualquer nó honesto crie e compartilhe o certificado assim que a Pool indicar um quórum.

Principais conclusões

Os votos são transmitidos como pacotes UDP únicos para todos os validadores, que memorizam os votos recebidos para cada slot e cada nó. A notarização e a finalidade de um determinado bloco no Votor são definidas pelas três condições a seguir:

• Aprovação de ≥80% do stake na primeira rodada de votação.
• Aprovação de ≥60% do stake na primeira e na segunda rodada de votação.
• O validador recebe de outro validador um certificado válido informando que o bloco foi finalizado.

Fim do Proof of History

Como o Rotor propaga os dados dos blocos em um único salto e o Votor tem uma meta máxima de latência de ~150 ms — abordaremos isso com mais detalhes na próxima seção —, não há mais necessidade de um relógio descentralizado na Solana. Relógios locais simples são suficientes. O Alpenglow substitui o Proof of History por temporizadores locais de tempo limite.

Como funciona o mecanismo de tempo limite do Votor?

Na prática, o sistema de tempo limite funciona da seguinte forma:

• Janela do líder: o líder ficará responsável por uma janela de quatro slots, com Δblock ≈ 400ms por slot.
• Chegada dos dados ou tempo limite: no momento em que o bloco pai de um líder é notarizado, cada validador ativa seus tempos limite e predefine quatro prazos — um por slot — em t = now + Δtimeout + slotIndex * Δblock, onde Δblock ≈ 400ms. Observe que esses temporizadores nunca são reiniciados e funcionam como limites superiores. Se os shreds de um bloco chegarem a tempo, um voto será emitido nesse slot com uma mensagem NotarVote, e o tempo limite pendente não produzirá nenhuma ação. No entanto, se o tempo expirar antes da chegada de qualquer shred, o validador presumirá que o líder é desonesto ou inadimplente e emitirá um SkipVote.
• Certificação: um Certificado de Finalização Rápida ou Certificado Finalizado é produzido para blocos notarizados, conforme descrito acima. Um Certificado de Salto também pode ser produzido para slots ignorados.

O Alpenglow introduz um sistema no qual cada validador mede os tempos limite de forma local e independente. Portanto, a Solana não precisa de um único relógio orientado por hashes, como o Proof of History. Como as mensagens consistem em apenas um pacote UDP e o Rotor usa somente um salto, o limite de 400 ms é realista sem hashing. Os validadores não precisarão mais calcular hashes continuamente, poderão votar contra blocos sem ficarem sujeitos a lockouts, e clientes alternativos, como o Firedancer, não serão obrigados a replicar a implementação de Proof of History do cliente Agave.

Ignorando slots

Os validadores também podem ignorar um slot enviando uma mensagem SkipVote. Se ≥60% do stake emitir uma mensagem SkipVote, um Certificado de Salto será produzido e esse slot será formalmente ignorado. Os votos de salto têm o mesmo peso de recompensa que os votos de notarização, portanto não há incentivo para um validador permanecer em silêncio quando o líder se comporta de forma inadequada. Observe que isso pode mudar quando o modelo econômico do Alpenglow for finalizado.

Os validadores enviam um SkipVote para um slot sempre que determinam que não podem finalizar um bloco para esse slot. Isso pode ocorrer por atingir um tempo limite, não receber um bloco ou receber um bloco inválido ou malformado. Se o primeiro slot da janela de quatro slots de um líder acionar qualquer uma dessas condições, os validadores marcarão toda a janela como inválida. Em seguida, percorrerão os slots restantes da janela e emitirão SkipVotes para todos os slots nos quais ainda não tenham votado. Assim, toda a janela de quatro slots pode ser reduzida a uma única rodada de salto. Cada voto ainda se aplica a um slot, mas, como a maioria dos validadores faz o mesmo em uma rajada, os três slots pendentes alcançam o limite de 60% praticamente ao mesmo tempo. Isso evita que o cluster permaneça ocioso durante outros três slots vazios enquanto o tempo limite de um líder offline expira.

Obviamente, isso deixa lacunas na produção de blocos. No entanto, a cadência dos slots continua sem interrupções graças a esses certificados de salto rápidos. Isso simplifica a escolha do fork e melhora a consistência, pois um certificado de salto atua como um “bloco nulo” canônico para esse slot, fazendo com que todos os nós honestos adotem o salto como resultado. Assim, não há um fork concorrente, e os saltos não geram forks persistentes, permitindo manter o ritmo normal de produção de blocos.

Recompensas dos validadores

As recompensas dos validadores no Votor são baseadas na participação na votação e na geração de certificados. Os nós que contribuem para o consenso emitindo votos a favor (NotarVote) ou contra (SkipVote) um bloco são recompensados igualmente. Isso incentiva a participação honesta e garante que os nós votem com base em seu próprio estado, em vez de tentar prever ou acompanhar a maioria.

Até o momento, não foi especificada uma implementação exata das recompensas.

Benchmarks de desempenho e resultados de simulação do Alpenglow

Simulações da Anza mostram que o Alpenglow finaliza um bloco em aproximadamente 100-150 ms, dependendo de o bloco ser notarizado pelo caminho de finalização rápida ou pelo caminho alternativo (ou seja, finalização lenta). O caminho de finalização rápida visa uma latência de ~100 ms, enquanto o caminho de finalização lenta visa uma latência de ~150 ms.

Histograma de latência

A latência da rede estabelece um limite inferior fundamental para a comunicação em qualquer sistema distribuído. Por exemplo, se o líder estiver em Nova York e a maioria do stake estiver na Europa, a mediana da latência unidirecional para um nó enviar informações a outros nós da rede pode chegar a cerca de 200 milissegundos. A latência é menor para nós geograficamente próximos (por exemplo, no mesmo data center ou região) e significativamente maior para nós localizados no Sul Global ou em outras áreas distantes.

• Rede: Esta é a latência da rede para enviar 1 bit a outros nós pela internet
• Rotor: Quanto o Rotor é mais lento em comparação com esse limite inferior
• Notarização: Tempo necessário para receber votos notarizados de 60% do stake (também é possível realizar mais uma rodada de votação; após o recebimento, a finalização pode começar)
• Finalidade: Tempo de finalização

A finalidade geral do Alpenglow é duas vezes maior que o limite inferior. Ou seja, a sobrecarga do consenso é um multiplicador de 2 vezes sobre o piso bruto da rede. Portanto, se o salto unidirecional mais longo entre o líder e o stake da supermaioria for, por exemplo, de ~70 ms (ou seja, RTT de ~140 ms), a finalidade pelo caminho rápido deverá ficar na faixa de 120-150 ms.

O histograma de latência das simulações da Anza mostra que 65% do stake finaliza dentro de 50 ms da latência bruta da rede. Isso significa que a maioria dos validadores vota quase assim que os dados chegam.

Com o Alpenglow, as confirmações determinísticas ficam bem abaixo das de qualquer L1 concorrente, aproximando muito mais a experiência on-chain da Solana à dos serviços Web2 tradicionais.

Análise de segurança e tolerância a falhas do Alpenglow

O consenso do Alpenglow representa uma melhoria em relação ao consenso BFT tradicional, que mantém a resiliência contra adversários que controlam até 33% do stake da rede. Isso é representado como “3f + 1”. O Alpenglow reduz esse limite para 20% do stake da rede com base no limite 5f + 1 apresentado por Martin e Alvisi em Consenso bizantino rápido. Ele usa um modelo de resiliência “20+20”, no qual a segurança é dividida em duas partes:

• Falhas bizantinas ≤ 20%: A segurança é mantida se menos de 20% do stake total for controlado por validadores adversários. Isso representa uma quantia considerável, na casa dos bilhões de dólares, e seria fácil de identificar e punir. Assim, um invasor corre o risco de perder todo o seu stake, tornando esses ataques economicamente inviáveis.
• Fenômenos não maliciosos ≤ 20%: A vivacidade é mantida se, no máximo, 20% do stake total, separado do stake adversário, estiver offline, tiver falhado ou não estiver participando do consenso. Isso inclui interrupções de rede, configurações incorretas e bugs de software. Assim, a rede pode continuar finalizando blocos mesmo que uma minoria significativa de validadores não responda.

Segurança

A segurança é garantida desde que o stake adversário total seja ≤20% e não consiga impedir a participação honesta de pelo menos 60% em uma bifurcação. Essas condições garantem que qualquer limite de votos que o protocolo considere final (ou seja, caminho rápido de uma rodada ou caminho lento de duas rodadas) seja alto o suficiente para impedir que um limite conflitante seja alcançado em outra bifurcação. Se validadores adversários tentarem votar de forma contraditória (ou seja, votar em duas bifurcações diferentes ou produzir dois blocos diferentes no mesmo slot), os nós honestos acabarão recebendo suas assinaturas conflitantes. Isso é fácil de identificar e, idealmente, no futuro, resultará em infrações passíveis de punição, como slashing. 

Além disso, se um líder tentasse produzir um bloco inválido, os validadores honestos simplesmente se recusariam a votar nele. O modelo de comunicação direta para votação do Alpenglow dificulta que um agente malicioso isole ou eclipse um nó honesto em termos de stake, pois acabará sendo exposto pelos votos da maioria honesta. Na melhor das hipóteses, um líder malicioso poderia forçar o consenso a seguir seu caminho mais lento ou causar um atraso de um slot, mas não conseguiria paralisar ou fazer a cadeia divergir permanentemente.

Vivacidade

A vivacidade é garantida sob condições de sincronia parcial, desde que os limites de falhas sejam respeitados. Isso significa que, após algum atraso na rede, os validadores honestos conseguirão se comunicar e reunir ≥60% do stake em algum bloco. Se exatamente 20% do stake total estiver offline, o caminho rápido ainda poderá ser bem-sucedido se todos os nós honestos restantes votarem. Se pouco mais de 20% do stake total estiver offline, a rede usará de forma consistente o caminho de finalização lenta para uma segunda rodada de votação. A finalidade continuará garantida, embora seja mais lenta. Portanto, falhas benignas afetam principalmente o desempenho, e não a segurança.

Alta resiliência a falhas

O Alpenglow foi projetado explicitamente com alta resiliência a falhas para lidar com condições adversas de rede. Ou seja, o Alpenglow continuará seguro e operacional em cenários com 20% de stake malicioso e 20% de stake sem resposta. 

No entanto, isso não é uma solução universal para qualquer falha concebível. O Alpenglow é uma melhoria significativa para a Solana, mas não elimina totalmente o risco de paralisações ou interrupções da rede se suas premissas forem violadas. É necessário ≥60% do stake para produzir novos blocos, e ≥20% do stake agindo de forma maliciosa pode impedir o consenso ou causar uma falha. Ainda assim, dentro dos limites definidos, o Alpenglow garante segurança e vivacidade em uma ou duas rodadas de votação.

Remover a Prova de História enfraquece a segurança?

Embora seja fundamental para a operação atual da Solana, remover a Prova de História não enfraquece a segurança de maneira significativa. Como mencionado anteriormente, o limite universal de 400 ms substitui o relógio de hash da Prova de História. Mesmo que a rede enfrente atrasos significativos, a sobreposição de stake do Votor (ou seja, ≥80% em uma rodada e ≥60% + ≥60% em duas rodadas) impede que validadores honestos aprovem duas bifurcações diferentes.

No entanto, isso altera as garantias de vivacidade, pois ela depende da mensagem de sincronia — a vivacidade será mantida desde que as mensagens honestas cheguem dentro desse intervalo. A disseminação de dados em um salto do Rotor e os votos em pacote único mantêm a latência bem dentro do limite de 400 ms, mesmo sob estresse.

No geral, remover a Prova de História eliminará a dependência do processamento contínuo de hashes, removendo assim quaisquer vetores de ataque baseados na paralisação de hashes. Como mencionado acima, isso também altera as garantias de vivacidade. Porém, remover a Prova de História não enfraquece a segurança de maneira significativa.

Principais conclusões

O Alpenglow troca uma pequena redução na tolerância bizantina por finalidade determinística em menos de um segundo, tratamento resiliente de grandes interrupções benignas e identificação mais fácil de validadores maliciosos. Essas conclusões podem ser resumidas da seguinte forma:

• Dois blocos conflitantes não podem ser finalizados, a menos que ≥20% do stake assine ambos, uma ação facilmente comprovável e punível.
• A Solana continuará finalizando blocos desde que ≥60% do stake consiga se comunicar, mesmo que o restante do stake esteja offline.
• No pior caso, a finalidade recorre a uma segunda rodada de votação, com meta de latência de ~150 ms, de modo que os ataques prejudiquem a velocidade da cadeia antes de ameaçarem sua segurança.
• O custo de ultrapassar o limite bizantino de 20% é proibitivo, enquanto infrações menores são detectáveis e podem ser punidas social e economicamente assim que o slashing entrar em operação na mainnet.

Qual é o impacto do Alpenglow nos validadores?

Os custos de votação são a maior barreira de entrada para operar um validador da Solana. Não há uma quantidade mínima obrigatória de SOL para operar um validador. No entanto, o envio de transações de voto a cada slot, necessário para participar do consenso, pode custar até ~1 SOL por dia.

O Alpenglow busca substituir as transações de voto por slot por um sistema compacto de certificados que, na prática, elimina as taxas de votação como as conhecemos hoje. Cada validador transmitiria mensagens leves de voto a todos os outros nós. Qualquer nó pode agregar essas assinaturas em um certificado por meio do esquema de assinatura BLS assim que um quórum for alcançado. Com esses votos agregados por BLS, apenas o cabeçalho do certificado é registrado on-chain. Na prática, isso eliminaria o custo diário de ~1 SOL por validador. 

Como mencionado anteriormente, com o Alpenglow, cada proposta de bloco é avaliada por dois caminhos de votação simultâneos:

• Finalização rápida (uma rodada)
  • É acionada quando a contagem de votos notarizados de um determinado bloco na primeira rodada de votação atinge ≥80% do stake
  • Produz um Certificado de Finalização Rápida 
  • Tem uma meta de latência de ~100 ms
• Finalização lenta (duas rodadas)
  • É acionada quando a contagem de votos notarizados de um determinado bloco na primeira rodada de votação atinge ≥60% do stake
  • Produz um Certificado de Finalização depois que a contagem de votos notarizados da segunda rodada atinge ≥60% do stake
  • Tem uma meta de latência de ~150 ms

O Votor executa os dois caminhos simultaneamente, o que significa que ambas as contagens são atualizadas a partir do mesmo fluxo de votos da primeira rodada, de modo que o primeiro certificado a ultrapassar seu limite finaliza o bloco. O conjunto de stakes sobrepostos (ou seja, ≥60%) garante que dois blocos conflitantes nunca possam alcançar a finalidade.

As consequências operacionais desse novo design são positivas para os validadores:

Redução dos custos operacionais 

A remoção das taxas de votação reduz significativamente a barreira de entrada para possíveis validadores. Por sua vez, as taxas de votação tornavam os validadores menores mais dependentes das recompensas de inflação durante mercados de baixa. Sua remoção poderia justificar futuras discussões sobre a inflação da Solana, considerando a votação controversa da SIMD-228. Segundo a implementação do Alpenglow atualmente em discussão, essa redução diminuiria a quantidade mínima de SOL necessária para obter lucro de ~4.850 SOL (~800 mil USD) para ~450 SOL (~75 mil USD), conforme calculado com a Calculadora de lucratividade de validadores da Cogent Crypto.

Gerenciamento simplificado de chaves 

Os validadores da Solana não precisam mais assinar votos a cada slot. Isso significa que a chave de identidade do validador pode ficar em um Módulo de Segurança de Hardware (HSM) sem riscos de desempenho, reduzindo efetivamente o risco de carteiras quentes.

Redução da carga de rede no slot do líder

A agregação de um certificado por bloco substitui milhares de transações de voto individuais por época, reduzindo a carga de rede no slot do líder. 

Sem cálculos de bloqueio

A tabela de bloqueios exponenciais no estilo Tower da Solana é removida. Agora, os validadores só precisam acompanhar na memória a cadeia de certificados mais recente, reduzindo os tempos de reinicialização.

Qual é o impacto do Alpenglow nos provedores de RPC?

As consequências operacionais desse novo design são, em sua maioria, positivas para os provedores de RPC, embora algumas possam gerar preocupações de escalabilidade:

Níveis de compromisso simplificados 

Esse novo nível de finalidade eliminaria a diferença histórica entre os níveis de compromisso confirmado (ou seja, otimista) e finalizado (ou seja, enraizado). Por exemplo, isso significa que qualquer lógica de UX que aguarde dois níveis de confirmação (por exemplo, exibir um indicador de carregamento até a finalização) pode ser reduzida a uma única verificação de certificado.

Redução do tamanho do ledger

Considerando a demanda atual da Solana, o crescimento do ledger cairia cerca de três quartos devido à ausência de transações de voto. Isso também significa snapshots e arquivos menores. No entanto, considerando as metas projetadas de aumento das CUs no limite dos blocos, ainda não se sabe como isso funcionará na prática.

Gargalo de fan-out de WebSocket

Com o Alpenglow, consultar transações repetidamente deixa de fazer sentido, pois a finalidade chega em ~100-150 ms e é codificada em um único certificado. Faria mais sentido obter informações de finalidade por meio de um canal push que permanecesse aberto durante toda a execução do aplicativo, navegador ou bot e transmitisse cada novo certificado a todos os clientes inscritos. Os pontos críticos deixam de ser milhões de pequenas consultas HTTP e passam a ser centenas de milhares de sockets em tempo real.

Atualização do cache em tempo real

Qualquer cache que retenha dados de contas por mais de um quarto de segundo pode exibir dados desatualizados, pois os certificados liquidam um bloco em 100-150 ms. Caches de borda, CDNs e proxies de Camada 7 precisarão de TTLs extremamente curtos ou de hooks de limpeza cientes dos certificados.

Qual é o cronograma de desenvolvimento do Alpenglow?

O Alpenglow foi apresentado oficialmente na conferência Accelerate de Nova York no fim de maio. A próxima fase envolve a publicação de um Documento de Melhoria da Solana (SIMD) formal, que abrirá a proposta para comentários da comunidade por meio do GitHub, dos fóruns de governança da Solana e do Discord da Solana Tech.

Após o período de análise pela comunidade, a proposta seguirá para uma votação de governança on-chain pela comunidade de validadores. Paralelamente, o novo design passará por testes abrangentes para garantir desempenho e segurança.

Se todas as etapas seguirem conforme o planejado, a implantação na mainnet da Solana está prevista para o início do próximo ano.

Riscos e questões em aberto do Alpenglow

Um novo algoritmo de consenso

A transição para um novo protocolo de consenso é uma tarefa significativa, mas há precedentes importantes. O Merge da Ethereum em 2022 demonstrou que uma grande rede em operação pode mudar com sucesso seu mecanismo central de consenso, passando de Prova de Trabalho para Prova de Participação sem interromper as operações. Ou seja, ainda existem vários riscos, mas esse não é um território totalmente inexplorado.

Essa transição também exigiria guias de migração para que aplicativos, SDKs, carteiras e bots não deixassem de funcionar silenciosamente quando o Alpenglow unificar os níveis de compromisso confirmado e finalizado em uma única verificação de certificação. Qualquer código que consulte explicitamente dois níveis de compromisso ou use por padrão o nível confirmado deixará de funcionar. É necessário um esforço coordenado do ecossistema em relação à documentação, aos avisos de lint, aos métodos RPC e à arquitetura geral do código antes de o Alpenglow entrar em operação. 

Governança

O risco de governança é outro fator a considerar. A recente votação da SIMD-228 demonstra que a Solana opera como uma rede verdadeiramente descentralizada, na qual as propostas, mesmo aquelas apoiadas pelos principais desenvolvedores e por membros proeminentes da comunidade, não têm aprovação garantida. No entanto, as próximas mudanças introduzidas pelo Alpenglow, especialmente a redução dos custos de votação, são amplamente favoráveis aos validadores, sobretudo aos operadores menores. Por isso, acreditamos que a probabilidade de resistência na governança seja relativamente baixa.

Recompensas

O whitepaper do Alpenglow e os materiais relacionados publicados até agora não especificam os mecanismos exatos para recompensar a atividade de votação dos validadores nem para compensar os relays do Rotor pelo uso da largura de banda. O whitepaper também afirma claramente que o voto contraditório é punível, mas não especifica quem de fato aplica a penalidade, qual é o valor dela nem se a punição em questão é automática ou orientada pela governança. Essas omissões deixam indefinidos aspectos importantes da economia dos validadores e podem se tornar pontos de debate controverso dentro do ecossistema.

MEV

O Alpenglow também reestruturará profundamente o cenário atual de MEV na Solana. A latência continua sendo um fator determinante para MEV, pois algumas estratégias lucrativas dependem de espelhar o tráfego da TPU ou de cancelar e substituir transações em massa em determinada ordem antes que elas sejam confirmadas de forma otimista. Tudo isso ocorre dentro da janela atual de ~500-600 ms, que o Alpenglow busca reduzir para ~150 ms. À primeira vista, os líderes, especialmente os validadores que já hospedam uma infraestrutura personalizada de construção de blocos, poderão capturar uma parcela maior de MEV, enquanto os arbitradores independentes de latência podem perder sua vantagem, a menos que continuem desenvolvendo sistemas de negociação ainda mais rápidos e granulares.

Vários líderes simultâneos

O design do Alpenglow é muito mais flexível para adotar uma estrutura de vários líderes — conhecida como Multiple Concurrent Leaders (MCL) — em comparação com a arquitetura de consenso atual da Solana. Como observou Anatoly Yakovenko, um primeiro protótipo de MCL poderia envolver a inicialização de duas instâncias do Alpenglow que compartilhassem o mesmo conjunto do Rotor e liberassem todos os shreds simultaneamente. O Rotor distribuiria os fluxos paralelos, e o Votor notarizaria cada faixa. No entanto, várias questões da camada de execução começam a surgir. Especificamente,

• Como os conjuntos de escrita devem ser particionados para que os blocos de dois líderes nunca bloqueiem a mesma conta — ou, se isso ocorrer, para que a resolução do conflito seja determinística e barata?
• Como mesclar os certificados de cada faixa em uma única raiz de estado canônica sem duplicar o custo de replay?
• Que tipo de lógica de mercado de taxas se aplica quando as faixas competem por ativos?
• Que tipos de estratégias de MEV entre faixas isso permitiria?
• Um único validador com alto stake poderia dominar slots simultâneos sem limites por faixa? 

Embora o design do Alpenglow ajude a tornar o MCL um item realista do roadmap ao remover obstáculos no nível do consenso, ele continua sendo uma iniciativa promissora para o futuro até que essas questões em aberto sejam respondidas.

Conclusão

Este relatório explorou os principais componentes do Alpenglow e examinou como eles reformulam o modelo de consenso da Solana. Também analisamos as melhorias técnicas, as mudanças na economia dos validadores, os impactos no nível da rede e os benefícios para desempenho, simplicidade e escalabilidade.

O whitepaper do Alpenglow marca um ponto de virada para a Solana, não apenas no design do protocolo, mas também na filosofia de desenvolvimento. Pela primeira vez, a Solana publicou provas formais de correção para seu algoritmo de consenso, sinalizando uma mudança de sua abordagem tradicionalmente empírica e orientada pela engenharia para uma base mais rigorosa e respaldada por pesquisas. Essa evolução reflete um ecossistema em amadurecimento que continua priorizando o desempenho, agora com a disciplina adicional da verificação formal.

A descontinuação da Prova de História (PoH) representa uma mudança igualmente simbólica na identidade da rede. Embora a importância prática da PoH tenha sido muitas vezes superestimada, ela serviu por muito tempo como a inovação característica da Solana, aparecendo com destaque em materiais técnicos introdutórios e tornando-se sinônimo da marca. Sua remoção marca o fim de uma era e o início de outra. A Solana está amadurecendo.

Recursos adicionais

• Slides da apresentação do Alpenglow na Accelerate - Roger Wattenhofer
• Alpenglow: um novo consenso para a Solana - Blog da Anza
• Implementação de referência do Alpenglow - GitHub
• Whitepaper do Alpenglow - Quentin Kniep, Jakub Sliwinski, Roger Wattenhofer
• Consenso na Solana - Blog da Helius
• Escalar ou morrer na Accelerate 2025: apresentando o Alpenglow — o novo consenso da Solana - Vídeo do YouTube