Atualização do Agave v2.2: tudo o que você precisa saber

Atualizações de destaque do ciclo de lançamento do Agave 2.2 

• Amplas otimizações de desempenho
• Aumento de 20% nos limites de bloco, de 50 milhões para 60 milhões de CUs
• Introdução do Accounts Lattice Hash (ALH)
• Verificação de assinatura Secp256r1 (adiada do ciclo de lançamento do Agave 2.1)
• Implantação e execução de programas SBPFv1, v2 e v3
• Remoção da restrição do chamador de CPI
• Loader-v4

Cada seção deste artigo é independente, facilitando a exploração dos temas mais relevantes para você. Seja você operador de validador, desenvolvedor ou usuário ativo, este guia completo do Agave 2.2 oferece os principais insights necessários para aproveitar ao máximo as melhorias mais recentes.

Disponibilização dos recursos

No momento da redação deste artigo, 19,8% do stake total está executando o Agave v2.2.*, o que indica forte apoio à adoção em toda a rede. As ativações de gates de recursos na mainnet foram temporariamente suspensas durante o período de atualização e devem ser retomadas em breve, seguindo a sequência de ativação planejada.

A maioria dos principais recursos introduzidos no Agave 2.2 está atualmente sujeita a gates e ainda não está ativa na mainnet. Eles serão habilitados progressivamente ao longo do ciclo de lançamento da versão 2.2 por meio do sistema de gates de recursos da Solana. O momento da ativação é determinado pela prioridade dos recursos e pela ordem de disponibilização nos clusters de testnet e devnet. Consulte o rastreador de gates de recursos do Agave para ver as atualizações mais recentes.

Aumento dos limites de bloco para 60 milhões de CUs

A Anza definiu uma meta ambiciosa para 2025: dobrar o espaço de bloco disponível na Solana. Como parte desse esforço, o SIMD-0256: aumentar os limites de bloco para 60 milhões está programado para ser incluído na próxima versão 2.2 da Solana, representando um aumento de 20% em relação ao limite de bloco atual.

Isso sucede uma atualização anterior que aumentou os limites de bloco de 48 milhões para 50 milhões de unidades de computação (CUs), após a qual os tempos de bloco permaneceram consistentemente abaixo da meta de 400 ms. Dados recentes mostram que os blocos atingem regularmente o limite de 50 milhões de CUs, indicando que a rede está pronta para continuar escalando.

Observação: alguns blocos aparecem como 104% cheios devido a uma constante codificada diretamente na lógica de relatórios do painel do Firedancer.

Os demais limites do protocolo permanecem inalterados nesta atualização:

• O orçamento de computação por conta e por bloco permanece em 12 milhões de CUs.
• O máximo de computação por transação permanece limitado a 1,4 milhão de CUs.
• O limite agregado de computação para transações de voto por bloco permanece em 36 milhões de CUs.
• A alocação máxima de novos dados de contas por bloco permanece limitada a 100 MB.

Aumentar os limites de bloco afeta diretamente a experiência do usuário: uma maior taxa de transferência da rede reduz as taxas medianas de transação e aumenta a probabilidade de as transações serem incluídas com sucesso durante períodos de congestionamento.

Desafios para aumentar os limites de bloco

Ao elevar a taxa de transferência, é recomendável adotar uma abordagem cuidadosa e gradual para aumentar os limites de bloco, pois dois desafios importantes precisam ser enfrentados:

1. Preparação da infraestrutura

A infraestrutura do ecossistema como um todo precisa acompanhar as otimizações do cliente principal. Especificamente, a camada de gravação não pode avançar mais rápido do que a camada de leitura (por exemplo, nós RPC, indexadores e serviços de arquivamento) sem prejudicar a experiência do usuário.

2. Propagação de blocos em tempo hábil

Outro gargalo está na entrega de blocos do nó líder para o restante do cluster. Blocos significativamente maiores podem fazer com que os tempos de distribuição excedam a meta de 400 ms, especialmente sob condições de alta carga.

Um desafio urgente é a etapa de retransmissão da Unidade de Validação de Transações (TVU), pela qual os shreds são distribuídos pelo cluster. Validadores de grande porte chegam a 150.000 pacotes de saída por segundo (PPS) devido ao agressivo fator de fanout de 200 do Turbine (ou seja, cada nó é responsável por retransmitir shreds para outros 200 nós). Se isso for tratado de forma ineficiente, poderá causar acúmulos de shreds, transferências irregulares de liderança e visões inconsistentes do estado em toda a rede.

Para resolver isso, os engenheiros da Anza estão reformulando o pipeline de distribuição de blocos. A equipe está trabalhando na transição para XDP (eXpress Data Path), que permite contornar o kernel ao expor o processamento de pacotes diretamente ao espaço do usuário. Essa abordagem elimina cópias intermediárias custosas e permite que o software do validador se comunique diretamente com a placa de interface de rede (NIC).

Accounts Lattice Hash (ALH)

O caminho da Solana para oferecer suporte a bilhões de contas exige uma abordagem mais escalável para gerar o hash do estado global das contas. O recém-introduzido Accounts Lattice Hash (ALH) substituirá os hashes de contas anteriores, baseados em Merkle, por uma alternativa mais eficiente e escalável baseada em hashing homomórfico, que permite criar um novo hash a partir de hashes existentes sem precisar recalcular tudo do zero.

Atualmente, a Solana mantém dois hashes de estado das contas:

• Epoch Accounts Hash (EAH): uma raiz de Merkle de todo o estado das contas, calculada uma vez por época.
• Accounts Delta Hash (ADH): uma raiz de Merkle das contas modificadas em um único bloco, recalculada a cada bloco.

Ambos dependem da ordenação das contas por chave pública e da construção de árvores de Merkle, o que gera desafios de desempenho e escalabilidade, especialmente à medida que o conjunto de contas cresce. O modelo de hash duplo surgiu como um meio-termo: o EAH era preciso (incluía todo o estado das contas), mas pouco frequente, enquanto o ADH era frequente, porém parcial (apenas as contas modificadas). O ideal seria que cada bloco contivesse um hash completo e atualizado de todo o estado das contas, sem o custo adicional de recalcular uma árvore de Merkle.

Como funciona o Accounts Lattice Hash

O ALH alcança esse objetivo usando uma função de hashing homomórfica que permite atualizações incrementais. Em vez de reconstruir uma árvore de Merkle a cada vez, o ALH simplesmente adiciona ou subtrai os hashes individuais das contas (LtHashes) à medida que elas são gravadas. O resultado final é um único hash de 2.048 bytes que resume o estado de todas as contas. O mais importante é que ele pode ser atualizado bloco a bloco sem precisar recalcular tudo do zero.

Essa abordagem oferece complexidade O(n), uma melhoria significativa em relação à complexidade O(n log n) das árvores de Merkle. Ela permite que cada bloco inclua um hash de todo o estado das contas sem recálculos custosos.

Integração e hashes desativados

A disponibilização abrange três SIMDs distintos, com ativações independentes dos gates de recursos correspondentes ao longo do ciclo de lançamento do Agave 2.2.

• SIMD-0215: Accounts Lattice Hash
• SIMD-0220: snapshots usam o Accounts Lattice Hash
• SIMD-0223: remove o Accounts Delta Hash

Com essas mudanças, o Accounts Lattice Hash substitui tanto o ADH quanto o EAH. O ALH será integrado ao hash do banco de cada bloco, permitindo gerar hashes do estado completo na frequência dos blocos, em vez da frequência das épocas.

Desempenho e contrapartidas

A mudança para o ALH oferece benefícios substanciais ao desempenho dos validadores ao eliminar o hashing baseado em Merkle em todos os blocos. Isso simplificará o consenso e a geração de snapshots. Por exemplo, os validadores não precisarão mais ordenar contas nem reconstruir árvores durante a finalização de blocos ou a produção de snapshots — as atualizações do ALH são simples operações aditivas.

No entanto, essa abordagem não oferece suporte a provas de inclusão ou exclusão, ao contrário das árvores de Merkle ou Verkle. Embora isso afete determinados casos de uso de verificação criptográfica, como clientes leves e a Verificação Simplificada de Pagamentos (SPV), a contrapartida é considerada válida diante dos ganhos expressivos de eficiência. Uma discussão sobre métodos alternativos para provas de inclusão pode ser encontrada aqui.

Integração com snapshots

Como o cálculo inicial do Accounts Lattice Hash é custoso, o valor do ALH agora persiste nos snapshots dos validadores e é restaurado na inicialização, quando disponível. Os snapshots refletirão o formato atualizado do ALH em vez dos Snapshot Hashes baseados em Merkle, alinhando ainda mais o modelo de armazenamento e hashing da Solana a esse novo design.

Verificação nativa de assinaturas Secp256r1

A Solana está adicionando suporte nativo à verificação de assinaturas da curva elíptica secp256r1, uma atualização essencial que permite compatibilidade on-chain com Passkeys, o padrão WebAuthn e modelos avançados de abstração de contas, incluindo autenticação de dois fatores (2FA). Esta atualização leva a autenticação sem senha, já onipresente na Web2, para o domínio da Web3, aumentando a segurança e a usabilidade dos aplicativos on-chain.

Inicialmente programado para a versão 2.1 do Agave, esse recurso foi adiado para a versão 2.2. Para mais detalhes, confira nossa análise completa da verificação de assinaturas Secp256r1 na atualização do Agave 2.1.

Bug de alinhamento da pré-compilação

Pouco depois da disponibilização inicial do Agave 2.2, foi descoberto um bug crítico na implementação dos programas pré-compilados Secp256r1 e Ed25519. O bug era acionado com a nova flag de visualização `--transaction-structure`, que expõe layouts brutos de transações sem garantir o alinhamento. As pré-compilações presumiam incorretamente um alinhamento de 2 bytes para os dados das instruções, levando a resultados de execução inconsistentes entre produtores de blocos e validadores. Isso causava divergências no hash do banco, obrigando os líderes a abortar e resultando em perda de disponibilidade. O problema, relatado pela primeira vez em 9 de abril, foi corrigido rapidamente até 11 de abril. O bug não afetou os fundos dos usuários. Mais detalhes estão disponíveis na Análise da causa raiz, publicada pouco depois.

Implantação e execução de programas SBPFv1, v2 e v3

O Solana Berkeley Packet Filter (SBPF) é uma máquina virtual personalizada, projetada para executar programas da Solana com eficiência e segurança. Ele é um fork baseado em Rust do extended Berkeley Packet Filter (eBPF), criado inicialmente para Linux. 

As atualizações do Berkeley Packet Filter (SBPF) da Solana são essenciais para melhorar o desempenho, reforçar a segurança e liberar novos recursos para desenvolvedores de aplicativos. O Agave 2.2 estabelece as bases para a manutenção de longo prazo e para melhorias de desempenho ao introduzir um sistema formal de versionamento da máquina virtual SBPF, descrito inicialmente no SIMD-0161. Essa mudança permite a implantação e a execução de programas SBPFv1 (SIMD-0166), SBPFv2 (SIMD-0173, SIMD-0174) e SBPFv3 (SIMD-0178, SIMD-0179, SIMD-0189), estabelecendo uma estrutura sustentável para evoluir o ambiente de execução de programas em etapas, sem exigir novas implantações em toda a rede.

Até agora, todas as atualizações do SBPF precisavam ser introduzidas por gates de recursos globais, o que tornava a evolução do runtime complicada e a coordenação da implantação quase impossível. O versionamento resolve isso ao desacoplar o comportamento do programa do runtime global e vinculá-lo a uma tag de versão específica de cada programa, codificada no campo e_flags do cabeçalho de arquivo Executable and Linkable Format (ELF). Essa abordagem permite o seguinte:

Comportamento explícito do runtime

Cada programa indica a arquitetura do conjunto de instruções (ou seja, uma versão do SBPF) que espera. Com base nessa versão, o runtime do programa altera seu comportamento.

Disponibilização controlada

Os gates de recursos habilitarão de forma independente a implantação e a execução de novas versões do SBPF, descontinuando gradualmente as mais antigas. Conjuntos completos de mudanças são agrupados em versões distintas do SBPF, tornando as atualizações mais simples e fáceis de gerenciar.

Descontinuação em fases

O suporte a versões mais antigas do SBPF poderá ser removido quando elas forem descontinuadas, simplificando a lógica da máquina virtual. Esse processo de descontinuação será lento, oferecendo aos desenvolvedores bastante tempo para migrar ou reimplantar seus programas e adaptá-los às versões mais recentes.

Discriminador de versão

Atualmente, o protocolo trata qualquer valor de e_flags diferente de 0x0020 como SBPF v0, o que é válido no sistema existente. No entanto, essa abordagem não é escalável para oferecer suporte a várias versões do SBPF e precisa ser atualizada.

Quando o primeiro gate de recurso que habilita uma nova versão do SBPF for ativado, o protocolo mudará a forma como interpreta e_flags e mapeará diretamente o valor para o número da versão correspondente do SBPF. Nesse sistema, 0x0000 representará o SBPF v0, 0x0001 representará o SBPF v1 e assim por diante.

Remoção da restrição do chamador de CPI

O ciclo de lançamento do Agave 2.2 inclui uma melhoria aguardada há muito tempo que remove uma restrição histórica às invocações entre programas (CPI). Atualmente, qualquer programa invocado via CPI precisa ser passado explicitamente pelo chamador como uma conta da instrução. Isso torna a construção de transações complexa e gera uma sobrecarga computacional significativa, especialmente com CPIs profundamente aninhadas. No entanto, essa restrição é puramente histórica e não é necessária para o protocolo atual.

O SIMD-0163 remove essa restrição ao permitir que instruções CPI referenciem contas de programas diretamente na lista de contas de nível superior da transação, em vez de exigir que essas contas sejam passadas recursivamente em cada nível de invocação. Essa mudança oferece os seguintes benefícios:

• Reduz drasticamente o uso de CUs ao evitar a serialização e a desserialização redundantes de contas de programas (exceto em programas loader-v3, que armazenam seus executáveis em uma conta separada), algo especialmente custoso devido ao grande tamanho desses programas (binários de ~10 MB).
• Simplifica a construção de transações ao eliminar a necessidade de passar as contas dos programas chamados por toda a pilha de instruções.
• Melhora a capacidade de composição, facilitando a criação de arquiteturas de programas modulares e profundamente aninhadas.

Compatibilidade com versões anteriores

Os programas existentes não serão afetados, a menos que queiram aproveitar essa mudança. Nesse caso, eles poderão fazer o seguinte:

Programas que codificaram estaticamente o programa chamado e precisam dele apenas como uma conta de instrução qualquer para atender à restrição imposta pelo runtime podem receber um placeholder como NativeLoader1111111111111111111111111111111, evitando o deslocamento dos índices das demais contas da instrução.

Todos os outros programas existentes, que chamam dinamicamente o que for passado em uma conta de instrução específica, precisarão ser atualizados e reimplantados para se beneficiarem da remoção da restrição.

Essa otimização não compromete a segurança. O recurso de "visibilidade atrasada" garante que os programas não possam invocar outros que tenham sido adicionados, modificados ou removidos na mesma transação.

Loader-v4

O Agave 2.2 introduz suporte ao Loader-v4, um mecanismo simplificado e mais flexível de implantação de programas, projetado para substituir o Loader-v3. Habilitado pelo SIMD-0167, o Loader-v4 simplifica o gerenciamento de contas de programas, melhora os fluxos de atualização e introduz recursos essenciais de segurança para programas ativos, especialmente aqueles que operam em ambientes de alto risco, como DeFi.

Principais recursos do Loader-v4:

Modelo de conta única: o Loader-v4 elimina a necessidade de contas proxy e buffers separados para os dados dos programas. Agora, uma única conta representa cada programa.

Modo de manutenção

Agora, os programas podem ser colocados em um "modo de manutenção" não executável sem serem encerrados permanentemente ou reimplantados. Isso preserva o endereço original do programa, permitindo que os desenvolvedores pausem a execução (por exemplo, em caso de exploração de uma vulnerabilidade) sem abrir mão do endereço.

Redimensionamento arbitrário

O Loader-v4 permite aumentar e reduzir os binários dos programas após a implantação, possibilitando uma alocação de recursos mais flexível e a recuperação de fundos bloqueados.

Uso opcional de buffers

Ao contrário do Loader-v3, que sempre exigia uma conta de buffer externa para reimplantações, o Loader-v4 torna os buffers opcionais. Agora, os programas podem ser reimplantados diretamente na conta principal do programa, reduzindo pela metade os fundos que precisam ficar bloqueados durante o upload.

Reimplantações parciais

O Loader-v3 exigia que os binários completos dos programas fossem enviados novamente a cada atualização. Em contraste, o Loader-v4 permite uploads parciais, possibilitando que os desenvolvedores apliquem patches apenas a seções específicas de um programa. Isso é especialmente útil para pequenas atualizações.

Migração simples do Loader-v3

Programas implantados com o Loader-v3 podem ser migrados para o Loader-v4 sem alterar o endereço do programa. Isso é viabilizado por uma nova instrução Migrate no Loader-v3. Essa ação atrasará a visibilidade, o que significa que o programa ficará indisponível durante o restante do slot atual.

Após a ativação do Loader-v4, um gate de recurso separado será acionado para desabilitar novas implantações no Loader-v3. Os programas existentes no Loader-v3 continuarão funcionando, mas espera-se que todas as futuras implantações usem o Loader-v4.

Ao finalizar um programa loader-v4, pode-se indicar o endereço de uma próxima versão, possivelmente formando uma lista encadeada. Isso oferece uma alternativa à reimplantação de programas e permite que as interfaces de usuário apresentem uma lista de versões finalizadas para os usuários escolherem.

Os mecanismos de gerenciamento de autoridades e encerramento de contas permanecem os mesmos no Loader-v4. Tudo isso estará disponível por meio do novo subcomando program-v4 da CLI.

Conclusão

O Agave 2.2 representa um marco significativo para o protocolo Solana, trazendo melhorias essenciais ao runtime e novos recursos que ampliam a fronteira técnica da rede. Esta versão introduz várias mudanças importantes: aumento de 20% na capacidade dos blocos, integração do Accounts Lattice Hash (ALH) para hashing de estado escalável, diversas melhorias no desenvolvimento de programas e suporte à verificação de assinaturas Secp256r1, essencial para viabilizar integrações criptográficas convencionais. Em conjunto, essas melhorias aumentam a taxa de transferência, aprimoram a experiência do desenvolvedor e ampliam a capacidade da rede de oferecer suporte a uma gama maior de aplicativos.

Seja você desenvolvedor de programas, operador de validadores ou usuário da rede, o Agave 2.2 oferece mais desempenho, flexibilidade e resiliência para a Solana.

Outros recursos

• Repositório do cliente Agave
• Cronograma de lançamento do Agave v2.2
• Registro de alterações do Agave v2.2
• Pull requests com a tag Agave v2.2