Atualização do Agave 4.3: tudo o que você precisa saber

Introdução

Com o Agave 4.3, a Solana se prepara para o que pode ser a maior atualização de protocolo de sua história. O ciclo da versão 4.3 introduzirá o Alpenglow, o aguardado novo mecanismo de consenso da Solana, culminando no "Alpenswitch": a transição coordenada da mainnet para deixar o TowerBFT.

Desde o lançamento, a arquitetura de consenso da Solana foi construída em torno do Proof of History e do TowerBFT. Os validadores votam enviando transações que são processadas e incluídas em blocos junto com transações comuns de usuários. A finalidade se acumula conforme esses votos avançam por 32 slots, proporcionando à Solana um tempo de finalidade de aproximadamente 12,8 segundos (considerando slots de 400 milissegundos).

O Proof of History (PoH) foi uma das inovações arquitetônicas que definiram a Solana no lançamento, com sua abordagem exclusiva para ordenar eventos e coordenar o tempo. Sua desativação, portanto, marca o fim de uma era e destaca o quanto o protocolo evoluiu desde as tecnologias que originalmente o diferenciavam.

O Alpenglow substitui o 'PoH + TowerBFT' pelo Votor, um protocolo no qual os validadores trocam votos fora do pipeline principal de transações. Ele agrega esses votos em certificados criptográficos. O design tem como meta uma finalidade de ~150 milissegundos.

Para usuários e aplicações que enviam transações e leem o estado de contas, há pouco ou nada a migrar. As transações e os mecanismos de taxas permanecem inalterados. Validadores e infraestruturas que consomem blocos, votos, streams ou dados de compromisso sentirão os maiores ajustes.

As transações de voto desaparecem dos blocos, confirmed e finalized efetivamente convergem, e a infraestrutura de streaming recebe novas informações para distinguir bancos concorrentes dentro do mesmo slot.

Neste artigo, veremos como o Alpenglow funciona, incluindo o que o Votor muda na produção e na finalidade dos blocos. Também abordaremos outras mudanças relevantes que chegarão durante o ciclo da versão Agave 4.3.

Lançamento em etapas: primeiro Votor, depois Rotor

O Alpenglow foi projetado em torno de dois componentes principais: o Votor, que substitui o mecanismo de votação e finalidade da Solana, e o Rotor, que reformula a propagação de blocos pela rede. Esses dois mecanismos serão lançados em etapas, começando pelo Votor.

O Agave 4.3 introduz o Votor, mas mantém o protocolo atual de propagação de blocos, o Turbine. O Rotor foi explicitamente excluído da SIMD-0326, a proposta que rege a ativação inicial do Alpenglow. Ele precisará de sua própria SIMD antes de ser implantado. O lançamento inicial muda como os validadores chegam a um consenso, mas ainda não altera como os dados dos blocos trafegam pela rede.

Votor

O Votor substitui as transações de voto e o sistema de lockouts do TowerBFT por um protocolo mais direto entre validadores. No TowerBFT, os validadores votam enviando transações que são incluídas em blocos e, com o tempo, acumulam profundidade de lockout suficiente para que um bloco seja finalizado. No Votor, os validadores trocam diretamente mensagens de voto assinadas, e o protocolo agrega essas assinaturas em certificados compactos.

Em vez de aguardar o acúmulo de votos ao longo de 32 slots, o Votor pode finalizar um bloco após uma ou duas rodadas de votação. O protocolo tem como meta uma finalidade de ~150 milissegundos, em comparação com ~12,8 segundos no TowerBFT.

O Votor tem dois caminhos simultâneos para a finalidade.

Se pelo menos 80% do stake autenticar um bloco na primeira rodada, esses votos poderão ser agregados em um Fast-Finalization Certificate, e o bloco será finalizado imediatamente. Esse é o caminho rápido do protocolo e exige apenas uma rodada de votação.

Se o limite de 80% não for atingido, um bloco ainda poderá avançar se mais de 60% do stake tiver votado para autenticá-lo. Isso produz um Notarization Certificate que permite uma segunda rodada de votação. Quando mais de 60% do stake enviar votos de finalização pelo caminho de duas rodadas, isso formará um Finalization Certificate, tornando o bloco final.

Portanto, o protocolo completo tem cinco tipos de voto: Notarization, Notarization Fallback, Skip, Skip Fallback e Final. Diferentes combinações desses votos produzem certificados de autenticação, fallback, salto ou finalização. Esses certificados funcionam como evidências criptográficas compactas de que stake suficiente concordou com o resultado de um slot.

O Votor foi projetado para continuar avançando com apenas 60% de stake honesto e responsivo, permitindo que até 20% do stake se comporte de forma adversária enquanto outros 20% estão offline ou não respondem. Essa escolha é intencional: o Alpenglow abre mão do limite bizantino tradicional de um terço dos designs BFT em troca de um modelo de resiliência 20+20, com maior tolerância a validadores inativos ou indisponíveis.

O Votor também elimina o uso do Proof of History como relógio de consenso. Em seu lugar, os validadores usam temporizadores de timeout locais. Se um validador aguardar tempo suficiente sem receber um bloco aceitável, ele poderá emitir um voto de salto e permitir que o consenso avance. Isso simplifica a relação entre a medição do tempo e o consenso em comparação com o TowerBFT.

Rotor

O Rotor não faz parte do Agave 4.3 e, atualmente, não há uma data de ativação publicada. Portanto, o Turbine continuará transportando os dados dos blocos quando o Votor for ativado. O Rotor, junto com o mecanismo de amostragem inteligente usado para selecionar seus relays, passará posteriormente por uma proposta e um lançamento separados.

É importante destacar que isso não significa que a Solana precise aguardar o Rotor para alcançar finalidade abaixo de um segundo. O lançamento atual do Alpenglow tem como meta uma finalidade de ~150 ms com o Votor no Agave 4.3, enquanto o Turbine permanece em operação. O Rotor pretende melhorar ainda mais a disseminação de blocos e tornar a arquitetura mais ampla do Alpenglow mais eficiente, mas não é um pré-requisito para o novo modelo de finalidade do Votor.

O fim das transações de voto

Uma das consequências mais visíveis do Alpenglow será o desaparecimento das transações de voto dos blocos da Solana. Os validadores pagam taxas de transação por esses votos, e a rede consome largura de banda, capacidade computacional e espaço no ledger para processá-los e armazená-los.

Historicamente, as transações de voto representaram cerca de três quartos de todas as transações registradas onchain, uma proporção que diminuiu com o aumento da capacidade dos blocos. Embora as transações de voto sejam baratas (5.000 lamports) e representem apenas uma pequena fração (~5%) do processamento total, elas aumentam a contagem bruta de transações e o tamanho do ledger da rede.

Com o Alpenglow, os validadores passam a trocar diretamente entre si mensagens de voto assinadas com BLS. O ConsensusPool do Agave acompanha os votos observados e agrega stake suficiente nos certificados usados pelo Votor para avançar ou finalizar o consenso.

Isso não significa que as evidências de participação dos validadores desapareçam do ledger. Os blocos do Alpenglow introduzem um novo rodapé de bloco com informações de consenso. Na implementação atual do Agave, BlockFooterV1 pode conter o certificado de finalização mais recente, além de notar_reward_cert e skip_reward_cert. Os certificados de recompensa incluem uma assinatura BLS agregada e um bitmap que identifica os validadores que votaram.

Os sistemas que atualmente determinam se um validador votou indexando transações do Vote Program precisarão migrar para os certificados e dados relacionados a votos do Alpenglow. Pipelines de transações existentes que apenas filtram transações de voto geralmente poderão continuar operando; após o Alpenswitch, o filtro simplesmente não terá nada para remover.

A mudança também cria uma descontinuidade nas conhecidas estatísticas de TPS da Solana. Quando o Alpenglow for ativado, as medições brutas de TPS que incluem transações de voto cairão drasticamente, mesmo que a atividade dos usuários permaneça completamente inalterada. Portanto, o TPS sem votos é a métrica relevante para comparar a atividade antes e depois do Alpenswitch. Remover as transações de voto elimina uma antiga fonte de confusão sobre o throughput real da Solana e facilitará as comparações com outras redes.

A remoção das transações de voto devolve alguma capacidade aos usuários, mas esse efeito não deve ser superestimado, pois os votos representam uma parcela relativamente pequena da carga computacional da rede.

Níveis de compromisso

O Alpenglow também elimina uma das distinções de longa data da Solana: a diferença entre os compromissos confirmed e finalized.

Hoje, as aplicações escolhem entre três níveis de compromisso. processed oferece a visão mais recente, mas não fornece nenhuma garantia para todo o cluster. confirmed significa que uma supermaioria do stake votou no bloco, o que geralmente ocorre dentro de um ou dois slots. finalized fornece finalidade determinística, mas, no TowerBFT, exige que o bloco atinja o lockout máximo de votos, criando um intervalo de aproximadamente 32 slots entre a confirmação e a finalização. Em geral, confirmed é recomendado para solicitações RPC sensíveis à latência, e finalized quando uma garantia mais forte é necessária.

Na prática, confirmed provou ser extremamente confiável: nenhum bloco da Solana confirmado de forma otimista deixou de ser finalizado posteriormente. Mas a garantia do protocolo ainda é mais fraca. Um bloco confirmado ainda não é deterministicamente final, e aplicações como bridges, exchanges e sistemas de liquidação que não podem tolerar esse risco residual historicamente precisaram aguardar por finalized.

O Alpenglow elimina essa contrapartida. Quando o Votor produz um certificado de finalização rápida ou de finalização, o bloco é final. Quando o Votor seleciona um banco finalizado como root, o validador atualiza ao mesmo tempo seu slot confirmado mais alto, sua root e sua root de supermaioria mais alta.

Para os desenvolvedores, isso significa que confirmed e finalized efetivamente apontam para o mesmo estado de consenso após o Alpenswitch. As aplicações existentes não precisam alterar sua configuração de compromisso no dia da ativação, pois a interface RPC continuará aceitando processed, confirmed e finalized, mas a diferença de latência entre os dois últimos desaparecerá.

A distinção entre os dois caminhos de finalização do Votor é invisível para consumidores comuns de RPC. Seja quando um bloco atinge o limite de 80% para finalização rápida em uma rodada ou quando é finalizado pelo caminho de duas rodadas com limite de 60%, o resultado visível externamente é o mesmo.

Vários blocos candidatos

Outra mudança importante no Alpenglow afeta provedores de RPC, indexadores e outras infraestruturas que consomem dados de validadores. Um slot não pode mais ser tratado como um identificador exclusivo de bloco.

Um slot da Solana é uma janela na qual um líder pode produzir um bloco. Um bank, por sua vez, é a representação local do estado produzido pelo validador ao executar um bloco candidato específico. Esses conceitos sempre foram distintos, e bancos concorrentes não são novidade, mas grande parte da infraestrutura de produção sempre tratou slots e blocos como sinônimos.

O Alpenglow torna essa suposição cada vez menos segura.

O Agave 4.3 amplia o Geyser (a interface do validador usada para transmitir atualizações de contas, transações, entradas e blocos) com um novo identificador: bank_id. Os novos callbacks cientes do banco, incluindo update_account_for_bank, notify_transaction_for_bank, notify_entry_for_bank e notify_block_metadata_for_bank, associam um evento ao banco específico que o produziu. As notificações de status com escopo de banco também incluem um bank_id. Os callbacks antigos permanecem disponíveis no 4.3 para compatibilidade, mas estão obsoletos e serão removidos na próxima versão principal do Agave.

O ponto importante é que bank_id identifica uma instância local de banco, não um bloco aceito globalmente. O Agave cria IDs de banco com base em um contador atômico local mantido pelo runtime do validador. Portanto, não se deve esperar que dois validadores que reproduzam o mesmo bloco atribuam a ele o mesmo bank_id. A infraestrutura deve usar (slot, bank_id) para separar streams concorrentes vindos de um único validador, mas deve usar o ID do bloco ou o blockhash ao reconciliar dados entre diferentes validadores ou conexões.

As próximas etapas do Alpenglow tornarão a existência de vários bancos para o mesmo slot uma parte normal da operação dos validadores.

O exemplo mais claro é a transferência rápida de líder, um dos componentes do Alpenglow que será lançado após a ativação inicial do Votor. Um líder pode começar a construir de forma otimista sobre o pai que espera que o consenso aceite. Se o Votor decidir que esse pai deve ser ignorado, o líder poderá trocar de pai e reconstruir durante o restante de sua janela de liderança. Internamente, isso significa substituir um banco por outro no mesmo slot. O Agave já contém o mecanismo UpdateParent necessário para representar essa troca. A transferência rápida de líder não faz parte da ativação inicial do Alpenglow no Agave 4.3 e deve ser lançada durante a versão 4.4.

A equivocação do líder pode produzir o mesmo resultado geral. Se um líder assinar e distribuir dois blocos diferentes para o mesmo slot, os validadores poderão precisar manter e analisar temporariamente ambos os candidatos. Diferentes partes da rede podem ver esses candidatos em ordens distintas porque o Votor é assíncrono e os validadores processam blocos, votos, certificados e timeouts locais à medida que chegam.

Uma mudança recente reduziu MAX_ALTERNATE_BLOCKS_PER_SLOT de 11 para 6. Portanto, um validador precisa manter no máximo sete blocos candidatos por slot. No fim, o consenso reduz esses candidatos a um único histórico. No Votor, a autenticação exige mais de 60% do stake. Dois blocos conflitantes não podem obter certificados de autenticação válidos sem que uma parcela substancial do stake vote em ambos. Com a premissa do Alpenglow de que menos de 20% do stake se comporta de forma bizantina, certificados de autenticação conflitantes são impossíveis sem violar as premissas de segurança do protocolo.

Para consumidores do Geyser, a lição prática é simples: pare de indexar estados transitórios apenas por slot. Alterações em contas, transações, entradas e metadados de blocos devem ser acompanhados por (slot, bank_id) até que o consenso identifique o banco sobrevivente. Se outro banco aparecer para o mesmo slot, seus eventos pertencerão a um estado candidato separado e não deverão sobrescrever silenciosamente os eventos do primeiro.

Tickets de admissão de validadores

Atualmente, as transações de voto são o maior custo de operação de um validador da Solana. No TowerBFT, os validadores pagam uma taxa de transação padrão sempre que enviam um voto, totalizando aproximadamente 2 SOL por época. O Alpenglow substitui as taxas de transação por uma taxa cobrada uma vez por época dos validadores admitidos no conjunto de consenso ativo, conhecida como Validator Admission Ticket (VAT).

A base para essa transição já está ativa. O registro de chaves públicas BLS, especificado na SIMD-0387, foi ativado na mainnet em julho, seguido pouco depois pelo feature gate do VAT, a SIMD-0357. O Votor usa assinaturas BLS para que assinaturas de muitos validadores possam ser agregadas em um único certificado compacto. Cada validador deve registrar uma chave pública BLS em sua conta de voto antes de participar do Alpenglow. Desde a ativação do gate do VAT, validadores sem essa chave já estão excluídos do conjunto de votação.

Antes do Alpenglow, os validadores continuam enviando transações de voto comuns e pagando as taxas associadas. Nesse estágio, o VAT funciona principalmente como um filtro de admissão. Os validadores qualificados precisam ter uma chave BLS e estar entre os 2.000 principais validadores qualificados por stake. O VAT começa quando o Alpenglow é habilitado, e as transações de voto desaparecem.

Quando o Alpenglow estiver ativo, a admissão será recalculada próximo aos limites das épocas. A conta de voto de um validador deverá conter uma chave BLS registrada e SOL suficiente para cobrir o ticket e a isenção de aluguel. Se mais de 2.000 contas se qualificarem, o sistema as classificará por stake e admitirá os validadores com mais stake. Em seguida, o sistema deduzirá o ticket diretamente da conta de voto de cada validador admitido e o enviará para a conta incineradora da Solana. Portanto, os validadores precisarão manter suas contas de voto com saldo; no sistema antigo, as taxas das transações de voto eram deduzidas da conta de identidade do validador.

As propostas originais do Alpenglow e do VAT especificavam um ticket de 1,6 SOL por época, cerca de 80% dos aproximadamente 2 SOL que um validador gastava anteriormente com transações de voto. Esse valor considerava a meta histórica da Solana de slots com 400 milissegundos. A SIMD-0525, por sua vez, ajusta o VAT de acordo com a duração do slot. O custo de admissão com slots de 200 milissegundos será de 0,8 SOL.

O VAT também muda o destino desse custo. Hoje, a taxa-base de 5.000 lamports paga por uma transação de voto é dividida em duas partes: 50% são queimados e 50% vão para o líder do bloco. Já o VAT é enviado integralmente para a conta incineradora. Porém, o objetivo mais amplo do VAT não é tornar o SOL significativamente mais deflacionário. É preservar um custo econômico para ingressar no conjunto de consenso após o fim das taxas de transações de voto.

Segurança e preparação

Substituir o protocolo de consenso de uma rede ativa é uma operação de risco excepcionalmente alto. Por isso, o Alpenglow conta com um processo de testes e migração muito mais amplo do que uma ativação comum de recurso do Agave, incluindo um cluster de testes dedicado à comunidade e um programa de recompensas por bugs.

Desde maio, operadores de validadores executam um Alpenglow Community Cluster dedicado, que cresceu para mais de 100 nós. Os operadores usam hardware real de validadores e configurações reais de rede, permitindo testar o Alpenglow em cenários de dispersão geográfica, variação de latência, diferentes configurações de software, reinicializações e erros operacionais difíceis de reproduzir em ambientes controlados.

Um de seus objetivos mais importantes tem sido testar o próprio Alpenswitch. Em vez de apenas verificar se o Votor funciona quando um cluster já está executando o Alpenglow, os operadores testaram repetidamente a transição do TowerBFT para o novo sistema de consenso.

Roger Wattenhofer

@TheWattenhofer

We just had the first successful Alpenswitch on our Alpenglow community cluster! The @solana finalization time improved 100x. Thanks to everybody participating. Watch it live: https://ag.validblocks.com/ https://ag-community-status.stakingfacilities.com/

9 de mai. de 2026, 6:59 PM

O Alpenglow também passou por uma análise adversária dedicada. Em agosto, a Anza abriu uma competição de recompensas por bugs do Alpenglow com uma premiação de até 50.000 SOL por duas semanas. Diferentemente do programa permanente do Agave, a competição se concentrou especificamente na nova stack de consenso, incluindo Votor, verificação de assinaturas e certificados BLS, admissão de validadores e o caminho de migração do TowerBFT para o Alpenglow. A participação foi expressiva. A Anza informou ter recebido mais de 300 envios e afirmou que mais de 25.000 SOL seriam distribuídos em recompensas.

O suporte ao Frankendancer termina com a chegada do Alpenglow. O Frankendancer sempre foi planejado como um cliente de transição, combinando os componentes de rede e produção de blocos do Firedancer com componentes do Agave para execução e consenso. Oferecer suporte ao novo sistema de consenso nessa arquitetura híbrida adicionaria outra carga considerável de manutenção e segurança. Por isso, a equipe do Firedancer está concentrando o desenvolvimento no cliente Firedancer completo.

A orientação compartilhada com os validadores é que nem o Frankendancer nem o Firedancer completo oferecerão suporte à breve janela de migração do TowerBFT para o Alpenglow. Portanto, operadores do Firedancer devem se preparar para fazer failover para um validador Agave antes do Alpenswitch, permanecer no Agave durante a transição e depois voltar ao Firedancer quando o cluster estiver operando normalmente com o Alpenglow.

Como o Alpenswitch realmente acontece

O Alpenglow não é ativado em todos os lugares em um horário arbitrário. Quando seu recurso é ativado, o protocolo define um limite de migração 5.000 slots depois. O TowerBFT continua operando enquanto os validadores ultrapassam esse limite e procuram um bloco confirmado com força suficiente. Em seguida, os validadores assinam com BLS o bloco gênese selecionado do Alpenglow e distribuem esses votos de gênese diretamente entre si.

A transição ocorre quando pelo menos 82% do stake assina o mesmo bloco gênese, produzindo o certificado de gênese do Alpenglow. Os validadores que recebem e verificam esse certificado desabilitam o TowerBFT após o bloco gênese e inicializam o Votor a partir do estado acordado. O certificado então se propaga pelo conjunto de validadores, levando os nós restantes para o outro lado do limite.

Esse certificado oferece aos operadores de infraestrutura uma forma prática de determinar de qual lado do Alpenswitch um cluster está.

O Agave 4.3 introduz um novo método RPC getAgGenesisCert. Antes da migração, um nó Agave 4.3 retorna null. Depois que o cluster faz a transição, ele retorna o certificado de gênese do Alpenglow, incluindo o bloco gênese e a assinatura BLS agregada. Um nó mais antigo que não oferece suporte ao método retorna Method not found. A CLI apresenta as mesmas informações por meio de: solana alpenglow-genesis-info.

Portanto, para validadores, provedores de RPC e outras infraestruturas que precisam reagir à migração, verificar a existência do certificado de gênese é melhor do que presumir que o Alpenglow foi ativado em um determinado horário.

Novas syscalls criptográficas

O Agave 4.3 também expande o conjunto de ferramentas criptográficas da SVM com novas primitivas de runtime para operações cujo custo torna sua execução direta em sBPF proibitiva.

As duas adições de destaque são o hashing SHA-512 e a exponenciação modular de inteiros grandes. Ambas são aditivas e controladas por feature gates: os programas existentes não são afetados, enquanto os programas que optarem por usá-las poderão delegar operações criptográficas computacionalmente caras a implementações nativas otimizadas dentro do runtime do validador.

Exponenciação modular de inteiros grandes

A SIMD-0529: syscall ModExp de inteiros grandes introduz sol_big_mod_exp, uma syscall para calcular:

result = (base ^ exponent) mod modulus

A exponenciação modular é uma operação fundamental para a verificação de assinaturas RSA, acumuladores criptográficos, algumas funções de atraso verificáveis e outros protocolos baseados em teoria dos números. Implementá-la com aritmética de inteiros de precisão arbitrária diretamente em um programa SVM exige muito processamento, especialmente com tamanhos comuns de chaves RSA, como 2.048, 3.072 e 4.096 bits.

A nova syscall transfere a aritmética cara para o runtime do validador. Os programas fornecem a base, o expoente e o módulo como inteiros sem sinal em little-endian e recebem o resultado na memória fornecida pelo chamador. Inicialmente, cada operando é limitado a 512 bytes, o suficiente para aceitar inteiros de até 4.096 bits.

O caso de uso mais evidente é a verificação RSA. Por exemplo, um programa que verifica uma assinatura RSA convencional pode invocar sol_big_mod_exp usando o expoente público comum 65537, em vez de implementar a própria exponenciação de inteiros grandes. A syscall se limita intencionalmente à primitiva aritmética: os programas continuam responsáveis pelo hashing, pelo padding RSA, como PKCS#1 v1.5 ou PSS, pela validação de chaves e por qualquer separação de domínio específica do protocolo.

Ela também pode executar com eficiência a redução modular de inteiros grandes. Fornecer um expoente de 1 reduz a operação a:

base mod modulus

Isso oferece aos programas uma primitiva nativa para reduzir inteiros maiores do que os tamanhos de palavra de máquina integrados à SVM, sem arcar com o custo de uma implementação genérica de inteiros grandes.

O conceito do design é semelhante ao do precompile ModExp do Ethereum introduzido pela EIP-198, e seu modelo de medição de processamento segue a fórmula de complexidade operacional da EIP-198. No entanto, ele não é compatível byte a byte com o Ethereum. A Solana disponibiliza a funcionalidade por meio de uma ABI de syscall nativa, usa entradas em little-endian e exige que o módulo seja um inteiro ímpar maior que um; módulos pares são rejeitados.

Isso torna a syscall especialmente útil para interoperabilidade sem obrigar a Solana a adotar a própria interface de precompile da EVM. Programas que verificam provas, assinaturas ou atestados baseados em premissas criptográficas no estilo do Ethereum podem reutilizar a mesma aritmética subjacente, adaptando a forma como a invocam.

SHA-512

A segunda adição é consideravelmente mais simples, mas oferece utilidade imediata.

A SIMD-0512: syscall Sha512 adiciona sol_sha512, oferecendo aos programas onchain acesso direto à função de hash SHA-512 pelo runtime do validador. Sua interface segue o padrão das syscalls sol_sha256, sol_keccak256 e sol_blake3 existentes na Solana e retorna o digest SHA-512 padrão de 64 bytes.

O SHA-512 é uma das principais primitivas usadas pelo Ed25519, o esquema de assinatura amplamente usado pela própria Solana. Tanto o Agave quanto o Firedancer já dependem internamente do SHA-512, mas, antes dessa mudança, os programas SVM não podiam acessar diretamente essa implementação otimizada. Um programa que precisasse do SHA-512 tinha que implementar o algoritmo em software.

Do ponto de vista do processamento, essa diferença é significativa. A SIMD estima que o hashing de uma entrada curta com uma implementação sBPF custa milhares de CUs, enquanto a mesma operação pela syscall custa menos de 100 CUs. sol_sha512 usa o mesmo modelo geral de custo computacional da syscall SHA-256 existente na Solana.

Em conjunto, as duas syscalls dão continuidade a uma tendência mais ampla na SVM: transferir primitivas criptográficas comuns, mas computacionalmente caras, de programas individuais para operações padronizadas e mensuradas no runtime. Os programas ainda definem o protocolo criptográfico de nível superior, mas o validador consegue executar os componentes caros com muito mais eficiência do que uma implementação sBPF.

Conclusão

A principal mudança do Agave 4.3 é o Alpenglow, que substitui o TowerBFT pelo Votor, remove as transações de voto dos blocos, reduz a finalidade de segundos para milissegundos e reformula como os validadores e a infraestrutura interagem com o consenso.

Para a maioria dos usuários e desenvolvedores de aplicações, grande parte dessa transição acontecerá de forma invisível. Para validadores, provedores de RPC, indexadores e equipes de infraestrutura, porém, o Agave 4.3 marca o início de uma grande mudança na forma como a Solana chega a um consenso.

Outros recursos

• Whitepaper do Alpenglow v1.2 (julho de 2026)
• Cronograma de lançamento do Agave 4.3
• Cronograma do rastreador de feature gates
• Registro de alterações do Agave 4.3
• Pull requests do Agave 4.3
• Atualização do Alpenglow - Solana Foundation