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

Introdução

Com o Agave 4.4, o principal cliente validador da Solana avança sobre a implementação do Alpenglow, simplificando a validação de blocos, otimizando os cálculos de recompensas de staking e reduzindo a quantidade de SOL necessária para armazenar programas e dados de contas. Essas mudanças melhoram a eficiência no dia a dia e, ao mesmo tempo, estabelecem mais bases para a execução assíncrona. A recente redução do tempo-alvo dos slots para 200 ms encurta as épocas para cerca de um dia, permitindo um ritmo ainda mais rápido de ativações de feature gates.

Principais atualizações do ciclo de lançamento do Agave 4.4

• Permissão de pagadores de taxas inválidos: uma etapa importante para viabilizar a execução assíncrona
• Redimensionamento automático de programas: reembolsa o aluguel excedente durante upgrades de programas
• Padronização de shreds: o protocolo agora exige conjuntos FEC com 32 shreds de dados e 32 de codificação
• Limpeza de stakes inativos: exclui stakes inativos dos cálculos de recompensas
• Redução do aluguel: três etapas finais previstas da redução de 90% nas garantias de estado

Permissão de pagadores de taxas inválidos

A ativação do feature gate da SIMD-0290: flexibilização da restrição do pagador de taxas deve entrar em vigor durante o ciclo de lançamento do Agave 4.4. Isso muda o que acontece quando um bloco contém uma transação cujo pagador de taxas não passa na validação, por exemplo, por não ter SOL suficiente. Antes, a inclusão dessa transação invalidava o bloco inteiro. Com as novas regras de consenso, a transação permanece no bloco e os validadores ignoram sua execução, sem fazer alterações no estado das contas.

O saldo de um pagador de taxas pode mudar à medida que transações anteriores são executadas. Portanto, exigir que todas as transações tenham um pagador de taxas válido significa que os validadores precisam executar algumas transações anteriores antes de determinar se um bloco é válido. Tratar falhas do pagador de taxas como transações ignoradas elimina essa dependência específica.

Essa é uma base para a execução assíncrona, na qual os validadores podem chegar a um acordo sobre os blocos e a ordem das transações antes de concluir a execução. A execução acontece separadamente, aplicando ao estado das contas as transações acordadas. A Solana está avançando em direção a esse modelo para permitir melhorias futuras, como tempos de bloco menores e vários proponentes de blocos simultâneos.

O Agave representa essas transações ignoradas como operações no-op: elas não executam instruções nem pagam taxas. Ainda assim, consomem capacidade do bloco de acordo com todos os seus orçamentos de recursos solicitados ou padrão, o que limita quantas delas um líder pode incluir. A implementação também preserva a capacidade do líder de filtrá-las durante a produção do bloco, embora os validadores possam aceitá-las ao reproduzir um bloco.

A SIMD-0290 se aplica especificamente a transações que usam um blockhash recente como especificador de validade. Transações com nonce durável exigem tratamento adicional, abordado separadamente pela SIMD-0297: flexibilização da restrição de transações com nonce inválidas. A mudança é totalmente retrocompatível, e todas as transações e os blocos anteriormente válidos continuam válidos.

Redimensionamento automático de programas durante upgrades

O Agave 4.4 incluirá a ativação de um feature gate para a SIMD-0433: Loader V3: definição dos dados do programa conforme o tamanho do ELF, que faz com que os upgrades de programas redimensionem automaticamente a conta que armazena o código compilado do programa.

O Loader v3 (ou seja, o loader padrão atual para implantar e atualizar programas da Solana) armazena o binário ELF compilado de um programa em uma conta ProgramData, junto com metadados como sua autoridade de upgrade. Antes, os desenvolvedores só podiam ampliar essa conta, nunca reduzi-la. Portanto, o upgrade para um binário menor deixava espaço sem uso, e o SOL necessário para manter esse espaço isento de aluguel permanecia bloqueado na conta.

Com essa mudança, a instrução Upgrade redimensiona a conta para o tamanho do cabeçalho de metadados mais o tamanho do novo ELF. Um binário menor libera os lamports excedentes para a conta de excedentes do upgrade, o destinatário designado para os fundos restantes. Um binário maior expande automaticamente a conta, eliminando a etapa separada de extensão em upgrades comuns. As contas ProgramData e de buffer já devem conter lamports suficientes para atender ao novo requisito de aluguel; caso contrário, o upgrade falhará.

Assim, os desenvolvedores que adotarem binários menores poderão recuperar SOL durante o próximo upgrade. Qualquer capacidade adicional reservada anteriormente também será removida. Para upgrades invocados por CPI, o limite de crescimento de conta de 10 KiB ainda se aplica: aumentos maiores exigem uma extensão prévia ou uma instrução de upgrade de nível superior. Antes do upgrade, os desenvolvedores devem verificar o destino da conta de excedentes para garantir que os reembolsos cheguem ao destinatário pretendido.

Essa mudança incentiva os desenvolvedores a adotar bibliotecas e frameworks mais recentes e eficientes, como o Pinocchio. Ela também reduz o espaço ocupado pelos programas no Accounts DB.

Padronização de shreds

O Agave 4.4 inclui regras mais rígidas para a propagação de blocos da Solana, conforme descrito na SIMD-0317: exigência de 32 shreds de dados + 32 shreds de codificação. Isso padroniza a estrutura usada pelos validadores para distribuir e reconstruir dados de blocos.

A Solana distribui blocos por meio do Turbine, que divide os dados dos blocos em shreds e os retransmite por camadas de validadores. Os shreds são agrupados em conjuntos de correção antecipada de erros (FEC), combinando shreds de dados com shreds de codificação que contêm informações de recuperação. Com um conjunto corretamente construído de 32 shreds de dados e 32 de codificação, um receptor consegue reconstruir os dados originais a partir de quaisquer 32 dos 64 shreds, o que ajuda a tolerar a perda de pacotes.

Cada shred também contém uma prova de Merkle que o vincula à raiz de Merkle do conjunto, autenticada pela assinatura do líder. Para um conjunto de 64 shreds, essa prova tem seis entradas, correspondentes aos seis níveis entre uma folha e a raiz. A verificação do tamanho da prova no Agave exige o tamanho esperado para essa estrutura fixa de 32:32.

Os clientes já produzem 32 shreds de dados e 32 shreds de codificação por conjunto, mas os validadores receptores historicamente aceitam configurações mais flexíveis. A SIMD-0317 elimina essa diferença ao tornar a estrutura fixa de 32:32 um requisito do protocolo. Isso simplifica a validação: um receptor pode determinar os limites válidos dos índices de shreds sem esperar que um shred de codificação revele as dimensões do conjunto.

A estrutura fixa também simplifica a detecção de equivocação, quando um líder distribui versões conflitantes dos mesmos dados. Dois shreds pertencentes ao mesmo conjunto FEC, com raízes de Merkle diferentes e assinaturas válidas do líder, fornecem evidências desse conflito. Portanto, a padronização do formato reduz a complexidade da implementação e facilita a identificação de equivocações.

Remoção de stakes inativos dos cálculos de recompensas

O ciclo de lançamento do Agave 4.4 incluirá a ativação de um feature gate para a SIMD-0599: remoção de stakes inativos das delegações de stake, que simplifica a forma como os validadores processam contas de stake inativas durante as recompensas de época particionadas no início de cada época. As contas de stake inativas podem manter uma quantidade de SOL acima do mínimo para isenção de aluguel, mas não têm stake ativo ou em ativação. O SOL dessas contas não está delegado ou concluiu totalmente a desativação.

Essas contas não recebem recompensas do protocolo, mas sua inclusão pode afetar o número de partições de distribuição de recompensas e o hash de reticulado usado para acompanhar o estado das contas. Todos os clientes validadores precisam reproduzir esse comportamento com precisão, o que adiciona complexidade desnecessária ao código crítico para o consenso.

A mudança exclui stakes que estavam inativos durante a época recompensada, mantendo os stakes em ativação, ativos e em desativação. Assim, uma conta de stake que se torna inativa no início de uma nova época ainda recebe as recompensas obtidas durante a época anterior, na qual estava em desativação.

Mais redução no aluguel

Espera-se que o Agave 4.4 traga as três ativações finais da redução gradual do aluguel da Solana. De acordo com o plano definido na SIMD-0437, o saldo mínimo exigido por byte de armazenamento da conta cai dos 6.960 lamports originais para 696 em cinco etapas (ou seja, uma redução de 90%).

Cada ativação tem seu próprio feature gate, permitindo que a rede avalie o impacto sobre a criação de contas e o crescimento do estado antes de prosseguir.

A redução desse requisito diminui o capital que desenvolvedores e usuários precisam comprometer ao criar contas de tokens, PDAs e outros estados onchain. Isso é especialmente útil para aplicações que financiam a criação de contas em nome dos usuários, como serviços de pagamento em grande escala.

Estimativas da Ghost indicam que mais de 3 milhões de SOL (~US$ 300 milhões) podem ser resgatados. Várias ferramentas foram desenvolvidas para ajudar os usuários a recuperar o SOL excedente de suas contas.

Conclusão

As principais mudanças do Agave 4.4 avançam sobre o Alpenglow e promovem melhorias há muito aguardadas nas recompensas de staking, na implantação de programas e nos custos das contas. Juntas, elas mantêm o avanço da Solana rumo a uma rede mais rápida e acessível. Em seguida, vêm o Breakpoint London e depois o Agave 4.5.

Mais recursos

• Cronograma de lançamento do Agave 4.4
• Cronograma do rastreador de feature gates
• Registro de alterações do Agave 4.4
• Pull requests do Agave 4.4