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

Resumo do Agave 2.0

O lançamento do cliente validador Agave v2.0 representa um marco importante na jornada da Solana rumo a um ecossistema mais robusto e com múltiplos clientes. Esta atualização apresenta várias melhorias essenciais para aumentar o desempenho, a confiabilidade e a eficiência da rede. As principais mudanças incluem:

• Ampla refatoração e otimização da base de código
• Recompensas de época particionadas
• Repasse integral da taxa de prioridade aos validadores
• O novo agendador central agora vem ativado por padrão
• O programa ZK ElGamal Proof
• Syscall Get-Sysvar
• Syscall GetEpochStake
• MoveStake e MoveLamports
• Remoção de métodos RPC obsoletos
• Renomeação de crates

Seja você operador de um validador, desenvolvedor na plataforma ou usuário ativo da Solana, esta visão geral abrangente da atualização Agave 2.0 fornecerá as informações necessárias para entender e aproveitar essas inovações recentes.

O que torna o Agave 2.0 uma atualização de versão principal?

Não existe mais um único ‘validador Solana’. O Agave 2.0 adota o novo mundo de múltiplos clientes da Solana e marca uma ruptura definitiva com o antigo repositório da Solana Labs no GitHub. O repositório da Solana Labs será arquivado e não aceitará mais novos pull requests nem issues. Anteriormente, esse repositório espelhava as atividades do repositório do Agave. Caso ainda não tenham feito isso, os desenvolvedores devem migrar todas as atividades para o repositório do Anza Agave no GitHub. O processo de migração da Solana Labs para o Agave começou em 1º de março e pode ser acompanhado publicamente no GitHub.

À medida que o ecossistema evolui, os operadores precisam se adaptar à execução de um ou mais clientes. Com essa mudança, vários crates estão sendo renomeados, liberando o namespace para dar suporte a múltiplos clientes — com destaque para o Firedancer — gerenciados por equipes independentes de desenvolvimento. Os crates mantidos pela Anza agora terão o prefixo "agave", facilitando sua identificação como dependências específicas da Anza no ambiente de múltiplos clientes.

‍Os crates afetados são: 

• solana-validator
• solana-ledger-tool
• solana-watchtower
• solana-install
• solana-geyser-plugin-interface
• solana-cargo-registry

Como detalhado em nosso guia de transição anterior, a atualização 2.0 apresenta várias mudanças incompatíveis, sobretudo a remoção de diversos endpoints obsoletos e descontinuados — atualizações importantes que todos os desenvolvedores da Solana já devem conhecer. Os detalhes completos das mudanças de RPC estão no final deste artigo.

Implementação dos recursos

No momento da publicação, ~20,7% dos validadores estão executando a versão 2.0.14. As ativações de feature gates na mainnet estão temporariamente pausadas para permitir que a adoção da v2.0 se alinhe melhor às ativações na testnet e na devnet. Quando o cluster da mainnet tiver adotado amplamente a v2.0, espera-se que as ativações de feature gates sejam retomadas de acordo com a ordem de ativação programada. 

Os novos recursos completos abordados nas próximas seções ainda não estão ativos e serão implementados gradualmente durante o ciclo de vida da versão 2.0 por meio de um sistema de feature gates. Os recursos são ativados em determinadas épocas com base na prioridade relativa e na ordem em que foram ativados nos clusters da testnet e da devnet.

Repasse integral da taxa de prioridade aos validadores

Esta atualização econômica muito aguardada e bastante debatida está sendo implementada após a proposta SIMD-0096, que passou por uma votação de governança dos validadores em maio. A votação terminou no final da época 620, com a participação de 51,17% do stake e 77,77% dos votos a favor. A atualização, controlada por feature gate, mudará radicalmente a forma como a rede processa as taxas de prioridade. Em vez do modelo atual, que queima 50% das taxas e repassa os outros 50% aos validadores, o novo modelo destinará 100% das taxas de prioridade diretamente aos validadores.

Embora as taxas de prioridade sejam tecnicamente opcionais, elas se tornaram prática padrão com o crescimento da atividade econômica na Solana. Essas taxas são calculadas em microlamports (milionésimos de um lamport) por unidade computacional usando a fórmula:

‍taxa de priorização = preço da unidade computacional (microlamports) x limite de unidades computacionais

Daqui em diante, todas as taxas de prioridade serão concedidas aos produtores de blocos. Isso cria um alinhamento de incentivos mais forte e reduz a probabilidade de validadores participarem de acordos externos ao protocolo para a inclusão de transações, algo que já foi um problema no passado.

Embora a eliminação da queima de taxas aumente ligeiramente a taxa de inflação líquida do SOL, a emissão de novos tokens por meio de recompensas de staking tem um impacto muito mais significativo. Para uma análise mais detalhada dessa dinâmica, consulte nossa publicação anterior no blog da Helius sobre o cronograma de emissão e inflação da Solana.

Recompensas de época particionadas

As recompensas de época particionadas buscam distribuir as recompensas de stake entre vários blocos, reduzindo os problemas de desempenho associados à concentração da distribuição de recompensas no primeiro bloco de cada nova época. O principal gargalo desse processo é a necessidade de gravar atualizações no número crescente de contas de stake ativas na rede, que agora totalizam aproximadamente 1,4 milhão.

Com essa nova abordagem, o cálculo e a distribuição das recompensas de stake no limite da época serão divididos em duas fases distintas:

• Fase de cálculo das recompensas: nesta fase, são calculadas as recompensas da época para todas as contas de stake ativas, e a distribuição é dividida em lotes programados.
• Fase de distribuição das recompensas: as recompensas de época pré-calculadas para as contas de stake ativas são distribuídas de acordo com a programação.

Para facilitar e monitorar o processo, uma conta Sysvar, EpochRewards, acompanhará e verificará as distribuições de recompensas durante toda a fase de distribuição. A Sysvar EpochRewards registra se a fase de distribuição de recompensas está em andamento e as informações necessárias para retomar a distribuição ao iniciar a partir de um snapshot. 

Cálculo das recompensas

Os cálculos das recompensas serão realizados no primeiro bloco da época. Após o cálculo, as recompensas serão divididas em lotes de distribuição armazenados no bank, que serão distribuídos durante a fase de distribuição das recompensas.

Para minimizar o impacto no tempo de processamento dos blocos durante a fase de distribuição das recompensas e garantir que cada bloco distribua um subconjunto das recompensas de forma determinística, a meta é distribuir 4.096 recompensas de stake por bloco. Como proteção contra um crescimento expressivo no número de contas de stake, a quantidade de blocos é limitada a 10% do total de slots em uma época. Somente se esse limite de blocos for atingido, o número de contas por partição poderá ultrapassar a meta de 4.096.

Distribuição das recompensas

A distribuição das recompensas começa imediatamente após a fase de cálculo, a partir do segundo bloco da época. As distribuições de recompensas ocorrem no início do bloco, antes do processamento normal das transações.

Como resultado, os usuários poderão ver as recompensas creditadas em suas contas de stake alguns blocos mais tarde do que antes. No entanto, a experiência geral continuará semelhante, pois o tempo prolongado do primeiro bloco no limite da época já atrasava o acesso dos usuários às contas de stake. Outro benefício dessa abordagem é que as transações não relacionadas a staking podem continuar sendo processadas sem interrupção, enquanto antes eram bloqueadas durante a distribuição das recompensas.‍

Devido ao número comparativamente baixo de contas de voto, aproximadamente 1.500, o mecanismo atual de distribuição das recompensas de voto no primeiro bloco do limite da época permanecerá inalterado. Somente as recompensas de stake serão distribuídas entre vários blocos.

O agendador central agora vem ativado por padrão

Apresentado pela primeira vez como um recurso na atualização v1.18, o agendador central, anteriormente conhecido como “the scheduler”, não vinha ativado por padrão e precisava ser habilitado pelos operadores por meio da flag --block-production-method central-scheduler ao iniciar um validador. Agora, ele vem ativado por padrão. A implementação anterior do agendador tinha vários problemas que poderiam prejudicar o desempenho. Gargalos no processamento de transações frequentemente causavam instabilidade ou inconsistência na ordenação e priorização das transações.

A implementação mais recente substitui o modelo anterior de quatro threads bancárias independentes, cada uma gerenciando sua própria priorização e seu próprio processamento de transações. Nessa estrutura revisada, o agendador central é o único destinatário das transações provenientes da etapa SigVerify da TPU. Ele cria uma fila de prioridade e utiliza um grafo de dependências, conhecido como prio-graph, para gerenciar melhor o processamento e a priorização de transações conflitantes. Esse novo design do agendador aumenta a escalabilidade e a flexibilidade, permitindo ampliar o número de threads sem as preocupações anteriores com o aumento de conflitos de bloqueio. A implementação inicial do agendador central demonstrou gerar recompensas melhores, aumentando os ganhos de muitos operadores. Nossa publicação anterior da Helius sobre a atualização Solana v1.18 explicou detalhadamente como o agendador central funciona.

Programa ZK ElGamal Proof

O programa ZK Token Proof, originalmente planejado para inclusão na versão 1.17, agora está obsoleto e será substituído por um programa ZK ElGamal Proof mais versátil e independente de aplicações. O novo programa ZK ElGamal Proof mantém as partes do programa ZK Token Proof que se aplicam amplamente a diferentes aplicações, como verificar a validade de uma chave pública ou o intervalo de valores criptografados em um texto cifrado ElGamal. No entanto, ele exclui elementos específicos de aplicações, como a validação de prova de conhecimento zero exigida para instruções de transferência de SPL Token. O novo programa ZK ElGamal Proof será incorporado à lista de programas integrados no endereço ZkE1Gama1Proof11111111111111111111111111111

Para saber mais sobre o programa ZK Token Proof, leia nosso artigo original no blog da Helius.

Syscall Get-Sysvar

Syscalls, ou chamadas de sistema, solicitam serviços ao kernel do sistema operacional. No contexto da Solana, uma Syscall permite que programas executados na Solana Virtual Machine (SVM) interajam com recursos e serviços externos. 

Sysvars expõem informações sobre o estado do cluster, como o hash de bloco recente e as recompensas da época. Essas contas são preenchidas em endereços conhecidos. Os programas podem acessar Sysvars por meio de uma conta Sysvar ou consultá-las por meio de uma Syscall. Os programas on-chain usam muitas Sysvars para diversos casos de uso, e algumas delas são essenciais para a operação da rede.

A Syscall Get-Sysvar, proposta inicialmente no SIMD-127 pelo engenheiro da Anza Joe Caulfield, apresenta uma interface unificada de Syscall para acessar dados de Sysvar. Essa atualização permite recuperar dados de Sysvar antes inacessíveis, incluindo SlotHashes e StakeHistory. Com essa nova interface, os desenvolvedores podem acessar fragmentos específicos dos dados de Sysvar — por exemplo, chamando SlotHashes::get_slot(slot) e StakeHistory::get_entry(epoch) — sem precisar duplicar estruturas de dados inteiras.

A atualização também minimiza a sobrecarga ao modificar layouts de dados de Sysvar ou adicionar novas Sysvars. Antes, cada nova Sysvar exigia a adição de uma Syscall correspondente, criando uma relação fortemente acoplada que aumentava a interface de Syscall ao longo do tempo e dificultava a manutenção. Agora, uma única Syscall sol_get_Sysvar atenderá a todas as interfaces de Sysvar, permitindo recuperar dados de qualquer Sysvar com consistência e eficiência.

A introdução da nova Syscall simplifica o processo de modificar e adicionar novas Sysvars. Ela reduz significativamente a complexidade e os requisitos de manutenção da interface de Syscall. Além disso, essa atualização abre caminho para ampliar o acesso de programas BPF aos dados de Sysvar, permitindo que programas on-chain leiam mais informações de Sysvar sem afetar o tamanho das transações.

Syscall GetEpochStake

A nova Syscall GetEpochStake apresentará um recurso muito solicitado para recuperar o stake delegado de uma conta de voto na época atual, oferecendo um método on-chain mais eficiente e direto para obter essas informações.

Atualmente, os programas não conseguem acessar dados em tempo real sobre o stake delegado a contas de voto específicas na época atual, o que cria uma barreira para casos de uso como governança de validadores e mecanismos de consenso secundários. Permitir a consulta on-chain desses dados viabilizará essas aplicações e abrirá caminho para futuros casos de uso.

Com GetEpochStake, os desenvolvedores fornecem o endereço de 32 bytes de uma conta de voto, e a syscall retorna um inteiro u64 que representa o total de stake ativo atualmente delegado a essa conta. Se o endereço fornecido não corresponder a uma conta de voto válida ou não existir, a Syscall simplesmente retornará 0.

MoveStake e MoveLamports

Duas novas instruções do programa de stake, MoveStake e MoveLamports, estão sendo introduzidas para facilitar transferências de valor entre contas de stake. Essas instruções, propostas inicialmente no SIMD-0148, ajudam os desenvolvedores ao permitir a movimentação de fundos entre contas com autoridades correspondentes sem o controle da autoridade de saque.

Anteriormente, protocolos que gerenciavam os stakes dos usuários enfrentavam dificuldades para dividi-los entre vários validadores e fazer redelegações periódicas. Quando um protocolo divide o stake de um usuário para desativá-lo, ele precisa financiar os lamports necessários para a isenção de aluguel da nova conta. O protocolo não consegue recuperar esses lamports de isenção de aluguel após mesclar as contas divididas.

MoveStake

MoveStake: esta instrução permite mover stake ativo entre contas, transferindo-o de uma conta ativa para outra ou de uma conta ativa para uma inativa, reativando assim a conta. Se toda a delegação da conta de origem for movida, essa conta se tornará inativa. O saldo isento de aluguel permanece intacto em todos os cenários, e as regras de delegação mínima são mantidas para contas ativas.

MoveLamports

MoveLamports: move lamports excedentes de uma conta ativa ou inativa para outra conta ativa ou inativa, sendo que "lamports excedentes" são lamports que não fazem parte do stake delegado nem são necessários para a isenção de aluguel. MoveLamports permite tarefas de manutenção, como recuperar lamports de contas mescladas e consolidar fundos não utilizados.

Para simplificar a implementação, essas mudanças não permitem ativar ou desativar contas nem afetam contas de stake parcialmente ativas. Essas novas instruções do programa não alteram a funcionalidade existente.

Bônus: o crate Solana-SVM

Com o lançamento do Agave 2.0, chega um crate solana-svm totalmente novo, que oferece aos desenvolvedores acesso direto aos principais componentes da SVM por meio de uma API simplificada e independente do framework completo do validador. Isso disponibiliza o processamento de transações de alto desempenho da Solana para aplicações além do validador, como serviços off-chain, clientes leves, canais de estado e rollups.

Ao desacoplar a API do restante do runtime, esse crate elimina a necessidade de componentes como instâncias de Bank, reduzindo a sobrecarga operacional. Agora, os desenvolvedores podem aproveitar os mesmos componentes robustos que sustentam a mainnet-beta da Solana para criar projetos SVM personalizados, como clientes leves, canais de estado, rollups e serviços off-chain. O núcleo dessa API é a struct TransactionBatchProcessor, que permite que aplicações processem lotes de transações Solana sanitizadas com todo o conjunto de componentes subsequentes do Agave, incluindo BPF Loader, eBPF e a máquina virtual.

Leia a análise detalhada da nova API SVM da Anza para conhecer todos os detalhes desse desenvolvimento empolgante.

Endpoints RPC removidos 

Vários endpoints RPC v1 obsoletos e descontinuados do Agave foram removidos. A equipe de DevRel da Helius entrou em contato com todos os clientes que usam esses endpoints. Por meio de uma análise interna, identificamos anteriormente um pequeno grupo de clientes que utilizava ativamente os seguintes endpoints, programados para remoção:

• getRecentBlockhash
• getConfirmedSignatureForAddresses2
• getConfirmedTransaction
• getConfirmedBlock
• getStakeActivation
• getFees

Observação: a abordagem alternativa para getAccountInfo mostrada na imagem pode ser encontrada aqui.

As mudanças incompatíveis no SDK incluem:

• Remoção do suporte ao Borsh v0.9. Use a v1 ou a v0.10 (#1440)
• O trait Copy não é mais derivado em Rent e EpochSchedule; passe a usar clone()
• solana-sdk: remoção de símbolos descontinuados) 
• solana-program: remoção de símbolos descontinuados

Para operadores de validadores, vários argumentos de validador descontinuados serão removidos com o lançamento do Agave v2.0. Uma lista completa está disponível aqui.‍

Conclusão

A atualização Agave 2.0 representa um avanço significativo para a Solana, incorporando diversas implementações de recursos e otimizações do runtime. Esta versão continua ampliando os limites com novas Syscalls poderosas, funcionalidades expandidas e uma manutenção abrangente, incluindo renomeação de crates, remoção de métodos RPC descontinuados e simplificação dos argumentos de validadores. O Agave 2.0 amplia os recursos da Solana e aprimora seu desempenho e sua usabilidade. Seja você desenvolvedor, validador ou usuário ativo, a atualização Agave 2.0 abre novas possibilidades empolgantes para todos no ecossistema da Solana.

Recursos adicionais

• Cronograma de lançamento do Agave v2.0
• Registro de alterações do Agave v2.0
• Versões do Agave