Agave 2.0 Resumo

O lançamento do cliente validador Agave v2.0 marca um marco significativo na jornada do Solana em direção a um ecossistema multi-cliente mais robusto. Esta atualização introduz várias melhorias críticas para aumentar o desempenho, confiabilidade e eficiência da rede. As principais mudanças nesta atualização incluem:

‍

• Refatorações extensivas no código e otimizações
• Recompensas de época particionadas
• Recompensando a taxa prioritária completa para validadores
• O novo agendador central agora está ativado por padrão
• O programa de prova ZK ElGamal
• Get-Sysvar Syscall
• Obter Chamada de Sistema de Participação Epoch
• MoveStake e MoveLamports
• Remoção de métodos RPC obsoletos
• Renomeações de caixas

Se você executa um validador, constrói na plataforma ou usa ativamente o Solana, esta visão geral abrangente da atualização Agave 2.0 irá equipá-lo com as informações necessárias para entender e aproveitar essas últimas inovações.

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

Não há mais um único 'validador Solana'. Agave 2.0 abraça o novo mundo multi-client da Solana e marca uma ruptura limpa com o antigoRepositório do GitHub da Solana Labs. O repositório da Solana Labs será arquivado e novas solicitações de recebimento ou problemas não serão mais aceitos. Anteriormente, este repositório refletia a atividade do repositório Agave. Os desenvolvedores devem migrar todas as atividades para oRepositório GitHub Anza Agavese ainda não o fizeram. OProcesso de migração da Solana Labs para Agavecomeçou em 1º de março e é publicamente rastreado no GitHub deles.

‍

Conforme o ecossistema evolui, os operadores devem se adaptar para executar um ou mais clientes. Seguindo essa mudança, várias caixas estão sendo renomeadas, limpando o espaço de nomes para suportar múltiplos clientes - especialmente o Firedancer - gerenciado por equipes de desenvolvedores independentes. As caixas mantidas pela Anza agora serão prefixadas com "agave," tornando-as facilmente identificáveis como dependências específicas da Anza dentro do ambiente multi-client.

‍

‍

As caixas afetadas são:

‍

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

‍

Como detalhado em nossoguia de transição anterior, a atualização 2.0 introduz várias mudanças críticas, especialmente a remoção de diversos endpoints obsoletos e depreciados - atualizações-chave das quais todos os desenvolvedores Solana devem estar cientes agora. Detalhes completos das mudanças RPC estão incluídos no final deste artigo.

Lançamento de recursos

No momento da redação, ~20,7% dos validadores estão executando a versão 2.0.14. As ativações do recurso gate na mainnet estão temporariamente pausadas para permitir que a adoção da versão 2.0 esteja mais alinhada com as ativações na testnet e devnet. Uma vez que o cluster da mainnet tenha adotado amplamente a versão 2.0, espera-se que as ativações do recurso gate sejam retomadas de acordo com o ordem de ativação agendada.

‍

As novas funcionalidades completas discutidas nas seções seguintes ainda não estão ativas e serão implementadas gradualmente ao longo do ciclo de vida 2.0 usando um sistema de controle de recursos. As funcionalidades são ativadas em determinados momentos com base na prioridade relativa e na ordem em que foram ativadas nos clusters de testnet e devnet.

‍

Recompensa total da taxa de prioridade aos validadores

Esta altamente antecipada eatualização econômica muito debatida está sendo implementado agora, seguindo a proposta,SIMD-0096, que passou por uma votação de governança do validador em maio. A votação foi concluída no final do época 620, com 51,17% da participação das partes interessadas e 77,77% votando a favor. A atualização gatilhada pela função mudará fundamentalmente o tratamento da redetaxas prioritárias. Em vez do modelo atual, que divide as taxas com 50% queimadas e 50% recompensadas aos validadores, o novo modelo destinará 100% das taxas de prioridade diretamente aos validadores.

Acima: taxas prioritárias semanais do Solana em valor em USD (fonte)

‍

Embora as taxas de prioridade sejam tecnicamente opcionais, elas se tornaram prática padrão à medida que a atividade econômica na Solana aumentou. Essas taxas são calculadas em micro-lamports (milionésimos de um lamport) por unidade de computação usando a fórmula:

‍

taxa de priorização = preço unitário de cálculo (micro-lamports) x limite de unidade de computação

‍

A partir de agora, todas as taxas prioritárias serão concedidas aos produtores de blocos. Isso cria uma maior alinhamento de incentivos e reduz a probabilidade de validadores se envolverem em acordos fora do protocolo para inclusão de transações, o que tem sido um problema no passado.

‍

Embora a remoção das taxas de queima aumente ligeiramente a taxa de inflação líquida do SOL, a emissão de novos tokens através de recompensas de staking tem um impacto muito mais significativo. Os leitores podem consultar nossa postagem anterior no blog da Helius sobreO cronograma de emissão e inflação da Solanapara uma análise mais detalhada dessas dinâmicas.

‍

Recompensas de Época Particionadas

Recompensas de época particionadasobjetivo de distribuirrecompensas de participaçãoem vários blocos, aliviando os problemas de desempenho ligados à concentração da distribuição de recompensas no primeiro bloco de cada nova época. O principal gargalo nesse processo é a necessidade de escrever atualizações de volta para o crescente número de contas de participação ativas na rede, que agora totaliza aproximadamente 1,4 milhão. \

Sob essa nova abordagem, o cálculo e a distribuição da recompensa de aposta no limite do época serão divididos em duas fases distintas:

‍

• Fase de cálculo de recompensas: Nesta fase, as recompensas de época para todas as contas de aposta ativas são computadas e a distribuição é dividida em partes programadas.
• Fase de distribuição de recompensas: As recompensas de época pré-calculadas para contas de apostas ativas são distribuídas de acordo.

‍

Para facilitar e monitorar o processo, uma conta do Sysvar,EpochRewards, irá acompanhar e verificar as distribuições de recompensas ao longo da fase de distribuição. O 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 de Recompensa

Os cálculos de recompensa serão realizados no primeiro bloco da época. Uma vez calculadas, as recompensas são divididas em pedaços de distribuição armazenados no banco, que serão distribuídos durante a fase de distribuição de recompensa.

‍

Para minimizar o impacto no tempo de processamento do bloco durante a fase de distribuição de recompensas e garantir que cada bloco distribua um subconjunto das recompensas de maneira determinística, uma meta de 4.096 recompensas de estaca será distribuída por bloco. Para se proteger contra o crescimento dramático do número de contas de participação, o número de blocos é limitado a 10% do total de slots em uma época. Somente se esse limite de bloco for atingido é que as contas por partição poderão ultrapassar a meta de 4.096.

Distribuição de recompensa

A distribuição da recompensa começa imediatamente após a fase de cálculo da recompensa, a partir do segundo bloco da época. As distribuições de recompensa ocorrem na parte superior do bloco antes do processamento normal da transação.

‍

Como resultado, os usuários podem ver as recompensas creditadas em suas contas de aposta alguns blocos depois do que antes. No entanto, a experiência geral continua semelhante, pois o tempo prolongado do primeiro bloco no limite do epoch anteriormente atrasava o acesso do usuário às contas de aposta. Uma vantagem adicional dessa abordagem é que as transações de não-aposta podem continuar sendo processadas sem problemas, ao contrário do que acontecia antes, quando eram bloqueadas durante a distribuição de recompensas.

‍

Devido ao número comparativamente baixo de contas de voto, aproximadamente 1.500, o mecanismo existente para distribuir recompensas de voto no primeiro bloco do limite do epoch permanecerá inalterado. Apenas recompensas de participação serão distribuídas ao longo de vários blocos.

‍

O Agendador Central Agora Está Ativo Por Padrão

Primeiramente introduzido como uma versão de recurso na atualização v1.18, o agendador central, anteriormente conhecido como “o agendador”, não estava habilitado por padrão e precisava ser habilitado pelos operadores usando a bandeira —block-production-method central-scheduler ao iniciar um validador. Agora, ele é ativado por padrão. A implementação anterior do agendador tinha vários problemas que poderiam afetar adversamente o desempenho. Estrangulamentos no processamento de transações frequentemente levam a oscilações ou inconsistências na ordenação e na priorização das transações.

‍

A nova implementação substitui o modelo anterior de quatro threads bancárias independentes, cada uma gerenciando sua própria priorização e processamento de transações. Nesta estrutura revisada, o agendador central é o único destinatário de transações da etapa SigVerify do TPU. Ele constrói uma fila de prioridades e implanta um gráfico de dependências, conhecido como prio-graph, para melhor gerenciar o processamento e a priorização de transações conflitantes. Este novo design de agendador aumenta a escalabilidade e flexibilidade, permitindo um aumento no número de threads sem as preocupações anteriores de aumentar conflitos de bloqueio. A implementação inicial do agendador central mostrou-se capaz de gerar melhores recompensas, resultando em ganhos aprimorados para muitos operadores. Nossa postagem anterior do Helius sobre a atualização Solana v1.18 cobriu extensivamente Como funciona o agendador central.

‍

Programa de Prova ZK ElGamal

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 mais versátil e independente de aplicativosPrograma de prova ZK ElGamal. O novo programa ZK ElGamal Proof retém as partes do programa ZK Token Proof que se aplicam amplamente em todos os aplicativos, como verificar a validade de uma chave pública ou o intervalo de valores criptografados dentro de um texto cifrado ElGamal. No entanto, ele omite elementos específicos do aplicativo, como a validação de prova de conhecimento zero necessária para instruções de transferência de token SPL. O novo programa ZK ElGamal Proof será incorporado à lista de programas integrados no endereço ZkE1Gama1Prova11111111111111111111111111111.

‍

Para saber mais sobre o Programa de Prova de Token ZK, leia o nossopost original no blog da Helius.

Get-Sysvar Syscall

Syscalls, ou chamadas de sistema, solicitam serviços do núcleo do sistema operacional. No contexto do Solana, uma Syscall permite que programas em execução dentro da Máquina Virtual Solana (SVM) interajam com recursos e serviços externos.

‍

Sysvars expõem informações sobre o estado do cluster, como o hash do bloco recente e as recompensas do epoch. Essas contas são populadas em endereços conhecidos. Os programas podem acessar os Sysvars através de uma conta Sysvar ou consultá-los através de um Syscall. Os programas on-chain usam muitos Sysvars para uma ampla gama de casos de uso, e certos Sysvars são essenciais para a operação da rede.

‍

A chamada de sistema Get-Sysvar, inicialmente proposta emSIMD-127 pelo engenheiro Anza Joe Caulfield, introduz uma interface Syscall unificada para acessar dados Sysvar. Esta atualização permite a recuperação de dados Sysvar anteriormente inacessíveis, incluindo SlotHashes e StakeHistory. Com esta nova interface, os desenvolvedores podem acessar fragmentos específicos de dados Sysvar—como chamando SlotHashes::get_slot(slot)eStakeHistory::get_entry(época)—sem a necessidade de duplicar estruturas de dados inteiras.

‍

A atualização também minimiza a sobrecarga ao modificar layouts de dados do Sysvar ou adicionar novos Sysvars. Anteriormente, cada novo Sysvar exigia a adição de uma Syscall correspondente, criando um relacionamento fortemente acoplado que inflava a interface Syscall ao longo do tempo e complicava a manutenção. Agora, uma única chamada de Sysvar sol_get_Sysvar servirá todas as interfaces do Sysvar, permitindo a recuperação de dados consistente e eficiente de qualquer Sysvar.

‍

A introdução do novo Syscall simplifica o processo de modificação e adição de novos Sysvars. Isso reduz significativamente a complexidade e os requisitos de manutenção da interface Syscall. Além disso, esta atualização abre caminho para expandir o acesso do programa BPF aos dados Sysvar, permitindo que programas on-chain leiam mais informações Sysvar sem afetar o tamanho da transação.

‍

GetEpochStake Syscall

O novoGetEpochStake Syscallirá introduzir um recurso altamente solicitado para recuperar a participação delegada de uma conta de voto para a época atual, fornecendo um método mais eficiente e direto para recuperar essas informações na cadeia.

‍

Atualmente, os programas não podem acessar dados em tempo real sobre a participação delegada a contas de voto específicas para a época atual, criando uma barreira para casos de uso como governança de validadores e mecanismos de consenso secundários. Permitir a consulta desses dados na cadeia desbloqueará esses aplicativos e abrirá caminho para casos de uso futuros.

‍

Com GetEpochStake, os desenvolvedores fornecem um endereço de conta de voto de 32 bytes, e a chamada do sistema retornará um inteiro u64 representando o total de apostas ativas atualmente delegadas a essa conta de voto. Se o endereço fornecido não corresponder a uma conta de voto válida ou não existir, a chamada do sistema simplesmente retornará 0.

‍

MoveStake e MoveLamports

Duas novas instruções de programa de participação,MoveStake e MoveLamports, estão sendo introduzidas para facilitar as transferências de valor entre contas de apostas. Essas instruções, propostas pela primeira vez emSIMD-0148, auxiliar os desenvolvedores, permitindo a transferência de fundos entre contas com autoridades correspondentes sem o controle da autoridade do sacador.

‍

Anteriormente, os protocolos que gerenciavam as participações dos usuários enfrentavam desafios ao dividir as apostas em vários validadores e redelegar regularmente entre eles. Quando um protocolo divide a participação de um usuário para desativação, ele deve financiar a isenção de aluguel para a nova conta. O protocolo não pode recuperar a isenção de aluguel ao fundir essas contas divididas.

MoveStake: Esta instrução permite que a participação ativa seja movida entre contas, transferindo-a 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 transferida, a conta de origem se torna inativa. O saldo isento de aluguel permanece inalterado em todos os cenários, e as regras de delegação mínima são mantidas para contas ativas.

‍

MoveLamports: Mova lamports excedentes de uma conta ativa ou inativa para outra conta ativa ou inativa, onde “lamports excedentes” se refere a lamports que não são nem apostas delegadas nem necessários para isenção de aluguel. MoveLamports permite tarefas de limpeza, como recuperar lamports de contas mescladas e consolidar fundos não utilizados.

‍

Para simplificar a implementação, estas alterações não suportam a ativação ou desativação de contas ou afetam contas parcialmente ativas. Estas 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 vem umnovo crate solana-svmoferecendo aos desenvolvedores acesso direto aos componentes principais do SVM por meio de uma API simplificada, independente do framework completo do validador. Isso abre o processamento de transações de alta performance da Solana para aplicativos além do validador, como serviços off-chain, clientes leves, canais de estado e rollups.

‍

Ao desacoplar a API do restante do tempo de execução, essa caixa elimina a necessidade de componentes como instâncias bancárias, reduzindo a sobrecarga operacional. Os desenvolvedores agora podem aproveitar os mesmos componentes robustos que oferecem suporte ao mainnet-beta da Solana para criar projetos SVM personalizados, como clientes leves, canais de estado, pacotes cumulativos e serviços off-chain. O núcleo dessa API é a struct TransactionBatchProcessor, que permite que os aplicativos processem lotes de transações Solana higienizadas com o conjunto completo de componentes Agave downstream, incluindo o BPF Loader, eBPF e máquina virtual.

‍

Acima: o processador em lote de transações (fonte da imagem: Anza)

‍

Leia o mergulho profundo emNova API SVM da Anza para obter detalhes completos sobre este desenvolvimento emocionante.

‍

Pontos de extremidade RPC removidos

Vários pontos de extremidade obsoletos e preteridos do V1 Agave RPC foram removidos. A equipe da Helius Devrel entrou em contato com todos os clientes que usam esses endpoints. Por meio da análise interna, identificamos anteriormente um pequeno grupo de clientes usando ativamente os seguintes endpoints, que são definidos para remoção:

‍

getRecentBlockhash, getConfirmedSignatureForAddresses2, getConfirmedTransaction, getConfirmedBlock, getStakeActivation, getFees

‍

Novamente, recomendamos fortemente que todos os desenvolvedores verifiquem as referências a essas chamadas e as atualizem adequadamente com as substituições sugeridas.

‍

Acima: uma lista completa de pontos finais v1 Agave RPC obsoletos e depreciados a serem removidos

‍

N.B. A abordagem alternativa para obter as informações da conta mostrada na imagem pode serencontrado aqui.

‍

As alterações que quebram o SDK incluem:

‍

• Suporte para Borsh v0.9 removido, por favor use v1 ou v0.10 (#1440)
• O traço de cópia não é mais derivadoem Aluguel e EpochSchedule; mudar para usar clone()
• Solana-SDK: símbolos obsoletos) removed
• solana-programa: símbolos obsoletos removidos

‍

Para os operadores de validação, vários argumentos de validador obsoletos serão removidos com o lançamento do Agave v2.0. Uma lista completa destes pode ser encontradaaqui.

‍

Conclusão

A atualização Agave 2.0 marca um avanço significativo para a Solana, incorporando inúmeras implementações de recursos e otimizações de tempo de execução. Esta versão continua a empurrar os limites com novas e poderosas Syscalls, funcionalidades estendidas e tarefas abrangentes, incluindo renomeações de pacotes, remoção de métodos RPC obsoletos e argumentos de validador simplificados. Agave 2.0 amplia as capacidades da Solana e aprimora seu desempenho e usabilidade. Se você é um desenvolvedor, validador ou usuário ativo, a atualização Agave 2.0 abre novas possibilidades empolgantes para todos no ecossistema Solana.

‍

Recursos adicionais / Leitura adicional

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

Aviso legal:

1. Este artigo é reproduzido de [helius)]. Todos os direitos autorais pertencem ao autor original [Lostin]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe, e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipe de aprendizado da gate. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.