Resumo do Agave 2.0

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

‍

• Refatorações e otimizações extensas da base de código
• Recompensas de época particionadas
• Recompensando a taxa de prioridade completa aos validadores
• O novo agendador central está agora ativado por padrão
• O programa de Prova ZK ElGamal
• Obter-Sysvar Syscall
• Obter chamada de sistema de participação da época
• MoveStake e MoveLamports
• Remoção de métodos RPC obsoletos
• Renomeações de caixotes

‍

Seja você um validador, construa na plataforma ou use ativamente a Solana, esta visão geral abrangente da atualização Agave 2.0 fornecerá os insights necessários para entender e aproveitar essas últimas inovações.

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

Já não existe um único 'validador Solana'. O Agave 2.0 abraça o novo mundo multi-client da Solana e marca uma ruptura clara com o antigoRepositório do GitHub da Solana Labs. O repositório da Solana Labs será arquivado e novos pedidos de recebimento ou problemas já não serão aceites. Anteriormente, este repositório espelhava a atividade do repositório Agave. Os programadores devem migrar todas as atividades para oRepositório Anza Agave GitHubse 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.

‍

À medida que o ecossistema evolui, os operadores devem adaptar-se a executar um ou mais clientes. Após esta mudança, várias caixas estão a ser renomeadas, libertando o namespace para suportar múltiplos clientes - principalmente o Firedancer - geridos por equipas 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.

‍

‍

Caixas afetadas são:

‍

solana-validador, solana-ferramenta-ledger, solana-torre-de-vigia, solana-instalar, solana-interface-do-plugin-geyser, solana-registro-de-carga

‍

Como detalhado em nossoguia de transição anterior, a atualização 2.0 introduz várias mudanças significativas, destacando-se a remoção de vários pontos finais obsoletos e deprecados - atualizações-chave com as quais todos os desenvolvedores Solana devem estar cientes neste momento. Todos os detalhes das alterações RPC estão incluídos no final deste artigo.

Lançamento de Recursos

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

‍

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

‍

Recompensar a taxa de prioridade completa aos validadores

Este altamente antecipado eatualização econômica muito debatida está agora a ser implementada na sequência da proposta,SIMD-0096, que passou por uma votação de governança validadora em maio. A votação terminou no final da época 620, com 51,17% da participação e 77,77% votando a favor. A atualização com recurso fechado mudará fundamentalmente o tratamento da rede detaxas prioritáriasEm vez do modelo atual, que divide as taxas com 50% queimadas e 50% recompensadas para os validadores, o novo modelo alocará 100% das taxas prioritárias diretamente para os validadores.

Acima: taxas de prioridade semanal da Solana em valor USD (origem)

‍

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 computação (micro-lamports) x limite de unidade de computação

‍

No futuro, todas as taxas prioritárias serão concedidas aos produtores em bloco. Isso cria um alinhamento mais forte de incentivos e reduz a probabilidade de os validadores se envolverem em arranjos fora do protocolo para inclusão de transações, o que tem sido um problema no passado.

‍

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

‍

Recompensas de Época Particionada

Recompensas de época particionadaspretendemos distribuirrecompensas de participaçãoatravés de 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 neste processo é a necessidade de escrever atualizações de volta para o crescente número de contas de aposta ativas na rede, totalizando agora aproximadamente 1,4 milhões. \

Sob esta nova abordagem, o cálculo e distribuição da recompensa de stake no limite do epoch serão divididos em duas fases distintas:

‍

• Fase de cálculo de recompensas: Nesta fase, as recompensas do período para todas as contas de participação ativas são calculadas, e a distribuição é dividida em segmentos agendados.
• 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 monitorizar o processo, uma conta Sysvar,EpochRewards, acompanhará e verificará as distribuições de recompensas ao longo da fase de distribuição. O EpochRewards Sysvar 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 instantâneo.

Cálculo de Recompensas

Os cálculos de recompensa serão realizados no primeiro bloco da época. Uma vez calculadas, as recompensas são divididas em partes de distribuição armazenadas no banco, que serão distribuídas 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, um objetivo de 4.096 recompensas de participação será distribuído por bloco. Para se proteger contra o crescimento dramático no número de contas de participação, o número de blocos é limitado a 10% dos slots totais em um época. Somente se esse limite de bloco for alcançado, as contas por partição poderão ultrapassar a meta de 4.096.

Distribuição de Recompensas

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

‍

Como resultado, os utilizadores podem ver as recompensas creditadas nas suas contas de apostas algumas blocos mais tarde do que antes. No entanto, a experiência global permanece semelhante, uma vez que o tempo prolongado do primeiro bloco no limite do epoch anteriormente atrasava o acesso do utilizador às contas de apostas. Uma vantagem adicional desta abordagem é que as transações não relacionadas com apostas podem continuar a ser processadas sem problemas, ao contrário do que acontecia anteriormente, 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 as recompensas de participação serão distribuídas ao longo de vários blocos.

‍

O Agendador Central agora está ativado 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 flag --block-production-method central-scheduler ao iniciar um validador. Agora está ativado por padrão. A implementação anterior do agendador tinha vários problemas que poderiam afetar adversamente o desempenho. Gargalos no processamento de transações frequentemente levavam a instabilidade ou inconsistência na ordenação e priorização de transações.

‍

A nova implementação substitui o modelo anterior de quatro threads bancários independentes, cada um gerenciando sua própria priorização e processamento de transações. Nesta estrutura revisada, o agendador central é o único destinatário das transações da etapa SigVerify do TPU. Ele cria uma fila de prioridades e implanta um grafo de dependência, conhecido como prio-grafo, 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 conflitos de bloqueio aumentados. A implementação inicial do agendador central tem mostrado gerar melhores recompensas, resultando em ganhos melhorados para muitos operadores. Nosso post anterior Helius sobre a atualização Solana v1.18 cobriu extensivamentecomo funciona o agendador central.

‍

Programa de Prova ZK ElGamal

O programa ZK Token Proof, originalmente planeado para ser incluído na versão 1.17, está agora obsoleto e será substituído por um programa mais versátil e independente da aplicação.Programa de Prova ZK ElGamal. O novo programa ZK ElGamal Proof manté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 na lista de programas embutidos no endereço ZkE1Gama1Proof11111111111111111111111111111.

‍

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

Obter-Sysvar Syscall

Syscalls, ou chamadas de sistema, solicitam serviços do kernel do sistema operacional. No contexto do Solana, um Syscall permite que programas em execução na Solana Virtual Machine (SVM) interajam com recursos e serviços externos.

‍

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

‍

O syscall Get-Sysvar, inicialmente proposto emSIMD-127 pelo engenheiro da Anza Joe Caulfield, introduz uma interface Syscall unificada para acessar dados Sysvar. Essa atualização permite a recuperação de dados Sysvar anteriormente inacessíveis, incluindo SlotHashes e StakeHistory. Com essa nova interface, os desenvolvedores podem acessar fragmentos específicos de dados Sysvar, como chamadas SlotHashes::get_slot(slot) e StakeHistory::get_entry(epoch)—sem a necessidade de duplicar estruturas de dados inteiras.

‍

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

‍

A introdução do novo Syscall simplifica o processo de modificação e adição de novos Sysvars. Ele 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 do Sysvar, permitindo que os programas on-chain leiam mais informações do Sysvar sem afetar o tamanho da transação.

‍

Syscall GetEpochStake

O novoObter Epoch Stake Syscallirá introduzir uma funcionalidade muito solicitada 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 em cadeia.

‍

Atualmente, os programas não podem aceder a dados em tempo real sobre as participações delegadas a contas de voto específicas para o período atual, criando uma barreira para casos de uso como governança de validadores e mecanismos de consenso secundários. Permitir a consulta on-chain desses dados desbloqueará essas aplicações e abrirá caminho para casos de uso futuros.

‍

Com GetEpochStake, os desenvolvedores fornecem um endereço de conta de voto de 32 bytes, e o syscall retornará um inteiro u64 representando a participação ativa total atualmente delegada a essa conta de voto. Se o endereço fornecido não corresponder a uma conta de voto válida ou não existir, o Syscall 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 em SIMD-0148, ajudar os desenvolvedores permitindo a transferência de fundos entre contas com autoridades correspondentes sem o controle da autoridade sacadora.

‍

Anteriormente, os protocolos que gerenciam as apostas dos usuários enfrentaram desafios ao dividir as apostas entre vários validadores e ao redesconsiderar regularmente entre eles. Quando um protocolo divide a aposta de um usuário para desativação, ele deve financiar os lamports de isenção de aluguel para a nova conta. O protocolo não pode recuperar os lamports de isenção de aluguel ao mesclar essas contas divididas.

MoveStake: Esta instrução permite transferir a participação ativa 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 intocado em todos os cenários e as regras mínimas de delegação são mantidas para contas ativas.

‍

MoveLamports: Mova o excesso de lamports de uma conta ativa ou inativa para outra conta ativa ou inativa, onde "excesso de lamports" refere-se a lamports que não são de participação delegada nem necessários para isenção de aluguel. O MoveLamports permite tarefas de limpeza, como recuperar lamports de contas mescladas e consolidar fundos não utilizados.

‍

Para simplificar a implementação, essas mudanças não suportam a ativação ou desativação de contas nem afetam contas de participação parcialmente ativas. Essas novas instruções do programa não alteram a funcionalidade existente.

‍

Bônus: A caixa Solana-SVM

Com o lançamento do Agave 2.0 vem umnova caixa solana-svm novinha oferecendo aos desenvolvedores acesso direto aos principais componentes SVM por meio de uma API simplificada, independente da estrutura completa do validador. Isso abre o processamento de transações de alto desempenho do Solana para aplicativos além do validador, como serviços off-chain, clientes leves, canais de estado e rollups.

‍

Ao dissociar a API do resto 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 suportam a mainnet-beta do Solana para criar projetos SVM personalizados, como clientes leves, canais de estado, rollups e serviços off-chain. O núcleo dessa API é a estrutura 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 de lote de transações (fonte da imagem: Anza)

‍

Leia o mergulho profundo emNovo SVM API da Anzapara obter todos os detalhes sobre este desenvolvimento emocionante.

‍

Removido Endpoints RPC

Vários pontos de extremidade RPC Agave v1 obsoletos e descontinuados foram removidos. A equipe de desenvolvimento Helius Devrel entrou em contato com todos os clientes que usam esses pontos de extremidade. Por meio de análise interna, já identificamos um pequeno grupo de clientes que usam ativamente os seguintes pontos de extremidade, que estão programados para serem removidos:

‍

getRecentBlockhash, getConfirmedSignatureForAddresses2, getConfirmedTransaction, getConfirmedBlock, getStakeActivation, getFees

‍

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

‍

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

‍

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

‍

Mudanças quebradas no SDK incluem:

‍

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

Para operadores de validação, vários argumentos de validação obsoletos serão removidos após o lançamento do Agave v2.0. Uma lista completa desses argumentos pode ser encontradaaqui.

‍

Conclusão

A atualização Agave 2.0 marca um avanço significativo para o Solana, incorporando numerosas implementações de recursos e otimizações de tempo de execução. Este lançamento continua a empurrar os limites com novas Syscalls poderosas, funcionalidade estendida e manutenção abrangente, incluindo renomeações de pacotes, remoção de métodos RPC obsoletos e argumentos de validador simplificados. O Agave 2.0 amplia as capacidades do 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 / Leituras Adicionais

• Calendário de lançamento do Agave v2.0
• Registo de Alterações do Agave v2.0
• Versões de Lançamento Agave

Declaração de exoneração de responsabilidade:

1. Este artigo é reproduzido a partir de [gatehelius)]. Todos os direitos autorais pertencem ao autor original [Perdido]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa e eles tratarão disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipe de Aprendizado da gate. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.