O que acontece com os validadores Solana que não fizerem o upgrade para o Agave 4.4.1?

A Anza deu aos operadores de nós da Solana até a epoch 1079 para instalar um patch que altera a forma como a rede contabiliza os dados de conta que uma transação carrega. Uma máquina executando uma versão mais antiga poderia permanecer online e ainda assim ficar fora de sincronia com a cadeia aceita, com consequências diferentes para validadores que ganham recompensas de staking e para serviços dos quais as carteiras dependem para obter dados atuais.

A Anza alertou os validadores antes da epoch 1079 de que os operadores executando software mais antigo corriam o risco de ficar para trás quando a rede ativasse uma nova regra. As versões compatíveis citadas foram o Agave 4.4.1 e o Firedancer v26.10.6.

O rastreador de feature gates do Agave identifica a mudança relevante como um tamanho mínimo de dados carregados para contas ProgramData do loader-v3. Sua tabela de piso de versão separa as versões usadas por redes de teste daquelas planejadas para a mainnet. Ler o cronograma exige verificar o cluster, o recurso e a epoch em conjunto.

O prazo também abrangia nós que não votam. Essas máquinas podem fornecer a carteiras e exchanges saldos, blockhashes e dados de confirmação. Um problema em uma delas pode atingir usuários que nunca delegaram SOL ou escolheram um validador.

O que a mudança faz

Um programa Solana pode usar uma conta para armazenar seus dados executáveis. Quando uma transação precisa carregar um programa, a rede contabiliza os dados associados a essa operação. Um mínimo aplicado a uma conta de dados de programa altera como o software compatível trata a transação relevante sob a nova regra.

O propósito de um feature gate é coordenar quando os participantes começam a usar uma nova regra. Os operadores podem instalar uma versão antecipadamente, enquanto a mudança efetiva da regra entra em vigor em um ponto acordado. Uma versão pode, portanto, suportar um recurso antes que esse recurso esteja ativo na mainnet.

Uma vez que o gate é ativado, uma versão mais antiga pode discordar do software atualizado sobre uma transação ou o estado produzido por um bloco. Um validador pode então parar de seguir a cadeia reconhecida pelo restante da rede, mesmo que o próprio servidor permaneça online. Esse é o significado prático do alerta da Anza sobre ser forked off.

Por que o stake por trás dos nós importa

Cem pequenos validadores e um punhado de grandes operadores não precisam representar quantidades comparáveis de stake de votação. Para a operação da rede, a questão relevante é quanto stake segue as regras compatíveis. O rastreador afirma que mudanças de piso de versão menor na mainnet normalmente seguem um limite de adoção de stake e um período de espera. Essa regra geral deve ser mantida distinta do alerta específico emitido antes da epoch 1079.

Uma verificação de adoção deve combinar informações de versão com stake ativo e, em seguida, comparar esses números com a participação na votação após o limite. Um nó que reporta a versão correta pode ainda estar se atualizando ou apresentando uma falha separada. Por outro lado, um agregado estável pode mascarar problemas em um operador menor se a maior parte do stake permanecer online e votar normalmente.

Essa diferença importa para os delegadores. Sua experiência depende do validador ao qual seu stake foi atribuído, e não de se a maioria das máquinas instalou a versão. Se um validador para de votar efetivamente, a participação perdida pode reduzir as recompensas atribuíveis a esse stake. A evidência relevante seriam os créditos de voto e os registros de recompensas das epochs afetadas.

O que usuários e exchanges notariam

Um usuário que envia SOL se importa se a transferência é aceita e atinge o nível pretendido de confirmação. Isso pode ser verificado por meio dos dados da transação e da rede. A alegação de que vários operadores perderam uma atualização não estabelece, por si só, confirmações mais lentas, uma paralisação ou uma interrupção generalizada.

Uma exchange também pode pausar depósitos ou saques enquanto monitora uma atualização, mesmo quando as transferências continuam onchain. Os saldos de seus clientes dependem de sua própria infraestrutura e de suas políticas de crédito. Uma transação que aparece onchain pode, portanto, permanecer pendente na conta de exchange de um cliente até que essa plataforma retome o processamento normal.

A comparação útil pós-atualização verificaria três coisas separadamente. Primeiro, os blocos continuaram a ser produzidos e confirmados? Segundo, a quantidade de stake votando efetivamente mudou? Terceiro, alguma exchange nomeada pausou ou retomou transferências em torno do limite? Cada resposta exige um registro diferente.

Por que o prazo da atualização também se aplicava à infraestrutura

As notas de lançamento do Agave da Anza identificam a mudança na contabilização do ProgramData como um backport. O lançamento do Firedancer inclui suporte para o mesmo recurso. Quando dois clientes processam a mesma transação após a ativação, eles precisam concordar sobre quantos dados de conta ela carrega. A regra compartilhada é o que importa no limite.

Um nó RPC sem stake pode atender uma aplicação sem contribuir com stake para os votos. Isso torna fácil para um usuário de carteira encontrar um problema local mesmo que os validadores votantes continuem produzindo blocos. Uma aplicação que lê de um endpoint atrasado pode exibir estado antigo ou retornar um erro. Comparar sua resposta com a mesma solicitação por meio de outro endpoint ajuda a identificar onde ocorreu a interrupção.

A migração do Alpenglow da Solana em outubro oferece contexto sobre como os operadores se preparam para uma mudança coordenada. Essa migração dizia respeito ao protocolo de consenso. O patch de novembro dizia respeito ao carregamento de contas. Ambos dão aos operadores uma versão a verificar, mas os efeitos devem ser avaliados em relação à regra específica que mudou.

O que tornava o prazo diferente de uma data de lançamento

A Anza publicou o Agave 4.4.1 em 5 de novembro. Seu subsequente alerta aos operadores dizia que a mudança estava planejada para a época 1079, com início estimado em torno de 13:30 UTC de 6 de novembro. A versão identificava o software de que os operadores precisavam, enquanto a época identificava quando a rede planejava começar a aplicar a regra.

Um limite de época depende do progresso da cadeia. O horário no alerta deu aos operadores uma estimativa prática, mas a transição da cadeia para a nova época era o evento importante. Os operadores não podiam tratar um horário local posterior ou uma janela rotineira de manutenção como uma extensão do cronograma.

Um lançamento pode incluir código que ainda não altera como a rede processa transações. Os operadores instalam o software primeiro, e então a rede ativa o recurso no ponto planejado. Essa sequência permite que os operadores se preparem sem que os nós apliquem imediatamente regras diferentes ao mesmo bloco.

A janela era curta mesmo para operadores que já haviam migrado para o Agave 4.4.0. O número do patch mudou em um, mas o lançamento anterior não tinha o suporte necessário para a nova regra. Uma instalação recente, portanto, não substituía a verificação da build exata.

O lançamento do Firedancer 26.10.6 suportava o mesmo recurso. Os operadores podiam usar diferentes implementações de cliente, mas ambas precisavam contar os mesmos dados de conta ao executar uma transação sob as regras ativas.

A distinção entre software e ativação já havia aparecido na cobertura do crypto.news sobre a implantação do Alpenglow na testnet. O Alpenglow mudou o consenso, enquanto o patch de novembro dizia respeito ao processamento de transações. Em ambos os casos, uma build estar disponível era um marco separado da exigência de seu comportamento pela rede.

Onde o ProgramData entra na transação

Uma transação lista as contas de que suas instruções precisam. Um validador carrega os dados associados a essas contas para executar as instruções. A rede limita a quantidade de dados de conta que uma transação pode carregar, dando aos validadores um limite para uma categoria de trabalho que realizam antes ou durante a execução.

O loader atualizável da Solana usa uma conta de programa e uma conta ProgramData separada. Esta última armazena os dados do programa executável e informações associadas para o loader. Um usuário invoca o programa sem contabilizar manualmente o tamanho desses dados executáveis. O runtime do validador cuida dessa parte.

O patch define um piso para a quantidade atribuída a uma conta ProgramData do loader-v3 quando ela é carregada. Se a contabilização antiga atribuía menos que o piso, a nova regra conta pelo menos o mínimo contra o limite de dados carregados da transação. Uma transação bem abaixo do limite pode produzir o mesmo resultado após a mudança.

A diferença importa na fronteira. Uma transação que combina várias instruções ou usa vários programas pode já carregar uma quantidade substancial de dados de conta. Se o novo mínimo colocar a quantidade combinada acima do limite, as regras antiga e nova podem produzir resultados diferentes mesmo com as mesmas instruções e o mesmo signatário.

O limite de dados carregados é distinto do orçamento de computação. A computação mede o trabalho de execução. Uma transação pode ter computação suficiente para executar as instruções e ainda assim falhar em um limite que rege quais contas ela pode carregar. Aumentar apenas a permissão de computação não altera a quantidade contada contra o limite de dados carregados.

A regra também deixa as instruções implantadas de uma aplicação no lugar. O programa pode permanecer no mesmo endereço e ter o mesmo código enquanto o validador cobra sua conta ProgramData de forma diferente. As equipes de aplicação têm motivo para reverificar transações próximas do limite mesmo que não tenham feito nenhuma implantação própria.

Como dois nós podem discordar sobre o mesmo bloco

Os validadores executam transações para verificar o estado produzido por um bloco. Se dois nós partem do mesmo estado e aplicam regras diferentes a uma dessas transações, podem chegar a resultados diferentes. Ambos não podem tratar o mesmo estado resultante como válido, a menos que a diferença seja resolvida.

Isso explica o aviso da Anza sobre nós mais antigos ficarem fora de sincronia. Um nó antigo pode permanecer online e continuar respondendo a solicitações enquanto falha em acompanhar a cadeia aceita por validadores compatíveis. Seu processo estar ativo é um teste mais fraco do que se ele está atualizado e em concordância com o cluster.

Um operador pode comparar o slot que o nó relata com uma referência independente. Um validador votante também precisa verificar que seus votos são contados na cadeia aceita. Os logs de erro podem identificar um problema ao reproduzir blocos que seria invisível em uma verificação de tempo de atividade.

O aviso descreveu a consequência da incompatibilidade. Uma avaliação após o prazo ainda precisa mostrar quais operadores estavam executando builds desatualizados e o que aconteceu com seus nós. Um instantâneo de versão coletado depois que um operador se recuperou poderia perder um breve período em que aquele validador estava fora de sincronia.

A data de ativação e o momento em que um observador percebe um problema também podem diferir. Uma regra restrita afeta apenas as transações que a exercitam. Um período sem divergência visível imediatamente após a fronteira não mostraria se um nó poderia lidar com uma transação próxima do limite afetado.

Por que uma contagem de validadores conta apenas parte da história

A importância de um validador votante depende em parte de quanto stake ele representa. Um punhado de grandes operadores pode representar mais peso de voto do que muitos menores. Uma contagem de máquinas afetadas, portanto, responde a uma pergunta diferente da porcentagem de stake ativo que continuou participando.

Nós sem stake têm um papel separado. Eles podem fornecer dados a aplicações, exchanges e carteiras ou retransmitir transações assinadas. Uma indisponibilidade em um serviço popular pode afetar muitos usuários mesmo que o serviço não contribua com nenhum stake para o consenso.

As medidas relevantes podem se mover independentemente. A produção de blocos pode continuar enquanto um provedor de RPC específico serve dados desatualizados. Um validador pode perder votos enquanto seu site voltado ao público permanece disponível. Uma exchange pode pausar depósitos em Solana enquanto a cadeia continua confirmando transferências.

A cobertura anterior do prazo do Alpenglow da Solana descreveu uma transição que exigia preparação coordenada por validadores e aplicações. O objetivo ali era finalidade mais rápida. O gate do ProgramData tem um efeito técnico mais restrito, mas os operadores ainda precisam julgar a prontidão em relação ao seu próprio lugar na rede.

O que os delegadores podem estabelecer a partir dos registros de votos e recompensas

Os delegadores têm uma questão econômica mesmo quando a rede permanece disponível. Eles querem saber se o validador que ganha recompensas em seu nome continuou a participar. Uma atualização perdida não move, por si só, o SOL delegado para fora da conta de staking, mas uma interrupção na votação pode reduzir as recompensas ganhas durante o período relevante.

O primeiro lugar a se observar é a conta de voto do validador. Comparar os créditos de voto ao longo das épocas em torno do limite pode estabelecer se sua participação mudou. Os registros de recompensas oferecem uma verificação separada do efeito para contas de staking específicas.

Uma recompensa menor não identifica, por si só, a atualização como a causa. A comissão, o desempenho anterior do validador e o status da conta de staking podem todos afetar o valor registrado. Evidências de que os votos pararam no limite e retomaram após uma mudança de cliente dariam uma explicação mais forte do que uma única recompensa menor.

Um token de staking líquido adiciona outra camada. Um pool pode distribuir seu stake entre vários validadores. Um problema em um operador pode contribuir apenas com parte da mudança nas recompensas do pool, dependendo de sua participação na delegação e da contabilidade do pool.

O staking em exchanges adiciona uma relação de serviço. A exchange pode operar seus próprios validadores ou usar outro provedor, e então creditar os clientes de acordo com seus termos. Um usuário precisaria dos registros da exchange para conectar uma mudança onchain nos votos com a recompensa creditada a uma conta individual.

O que um endpoint RPC desatualizado pode fazer com uma carteira

Muitas carteiras obtêm saldos, blockhashes e resultados de transações por meio de um endpoint RPC. Um nó que fica para trás pode relatar um saldo anterior ou falhar em retornar uma transação recente. Os usuários podem encontrar esses sintomas mesmo que outros nós estejam processando a rede normalmente.

Um blockhash pode afetar a transação antes que a rede a execute. Uma carteira que recebe um blockhash desatualizado pode construir uma transação que já não é válida no momento em que chega a um nó saudável. O sintoma é uma submissão falha, mas o motivo pode ser informação desatualizada em vez de uma mudança no saldo ou nas instruções.

A simulação depende da mesma relação. Um nó executando regras antigas pode relatar que uma transação se encaixa no limite de dados carregados, mesmo que os nós que aplicam a nova regra cheguem a um resultado diferente. Uma simulação em um nó compatível ainda pode diferir da execução final se o estado mudar entre a simulação e a inclusão.

Aplicações com vários nós atrás de um único endpoint enfrentam outra possibilidade. As requisições podem ter sucesso ou falhar dependendo de qual máquina as recebe. Um provedor precisa verificar se todo o pool está atualizado antes de atribuir um problema intermitente à cadeia.

Uma comparação entre endpoints independentes ajuda a separar essas questões. Se vários endpoints atuais concordam e um serviço difere, a discrepância pode ser local a esse serviço. Se observadores independentes também relatam uma mudança na produção de blocos ou nas confirmações, há evidência mais forte de um problema de rede.

A transição de consenso de outubro teve suas próprias mudanças de infraestrutura. A Crypto.news relatou que o Alpenglow removeu as transações de votação onchain anteriores. As equipes de aplicações tiveram que distinguir a mudança no que observavam de se os validadores conseguiam seguir o novo sistema. A regra de carregamento de contas de novembro novamente faz a resposta depender do papel do observador.

Por que o crédito da exchange pode ficar atrás da cadeia

Uma exchange pode creditar um depósito somente depois que seus sistemas reconhecem a transferência e aplicam sua política de confirmação. Uma transação onchain bem-sucedida, portanto, não determina quando o saldo interno do cliente na exchange muda.

Uma plataforma pode pausar depósitos ou saques enquanto atualiza a infraestrutura. Ela também pode continuar a receber transferências onchain enquanto sua fila de depósitos aguarda confirmação de um nó saudável. Um aviso da plataforma e um explorador de blocos podem ambos estar corretos, mesmo que um mostre uma interrupção de serviço e o outro mostre uma transferência bem-sucedida.

Para saques, um atraso pode ocorrer antes de a exchange assinar ou transmitir a transação. A ausência de um registro onchain durante esse período diz pouco sobre se a rede aceitaria a transação uma vez submetida. O status de processamento da plataforma aborda essa parte da linha do tempo.

Um relato de que várias exchanges pausaram operações ainda precisaria identificar quais serviços foram afetados e qual motivo cada uma apresentou. Um aviso de manutenção de rotina ou uma fila causada por outro problema pode cair na mesma janela de uma atualização. A coincidência é um motivo para comparar registros, não uma medida de participação da rede.

O que mostraria se os operadores perderam o patch

O rastreador de feature gates da Anza separa o piso mínimo de versão das ativações individuais. Reportagens anteriores do crypto.news sobre a implementação do Alpenglow e o piso da mainnet descreveram a mesma distinção. Uma build pode atender ao piso em um momento e carecer de uma mudança agendada para uma época posterior.

O registro pós-ativação mais útil compararia o recurso ativo, a distribuição de software e a participação dos operadores na mesma janela. O registro do recurso identifica quando a regra começou a se aplicar. O registro de software identifica quais builds estavam em serviço. Votos e blocos mostram se a rede e os operadores individuais se comportaram de forma diferente.

Slots pulados são uma observação possível. Eles também podem aumentar por motivos não relacionados ao patch, incluindo o desempenho comum dos validadores designados para liderar. Comparar várias janelas e associar os pulos aos seus líderes dá contexto à observação.

O stake inadimplente oferece uma visão diferente. O valor pode mudar quando um grande validador deixa de participar, mesmo que o número total de nós inadimplentes mal mude. A comparação precisa levar em conta os operadores que já estavam inadimplentes antes da atualização.

Os efeitos em RPC e exchanges precisam ser documentados separadamente. Esses provedores podem atender grandes números de usuários sem aparecer na comparação de stake. Seus avisos, métricas de serviço e registros de quando os nós retornaram aos slots atuais descreveriam interrupções que os dados de votação não conseguem capturar.

Por que uma implementação faseada ainda precisa de um teste de ativação

Uma versão estável do cliente pode ser implantada gradualmente antes de um novo recurso estar ativo. Isso permite que os operadores vejam se o software inicia corretamente, se sincroniza e processa transações sob as regras atuais. Também ajuda a revelar problemas de implantação antes que mais nós o utilizem.

Uma implementação bem-sucedida antes da ativação não consegue exercitar todas as consequências do recurso ativo. Uma transação próxima do limite de dados de conta carregados precisa ser testada sob ambos os conjuntos de regras para mostrar exatamente onde o resultado muda. Esse é um teste diferente de observar se o binário permanece online.

O Crypto.news relatou anteriormente que o Alpenglow visava uma abordagem diferente para a finalidade. Seus critérios de sucesso incluíam o que acontecia com a velocidade de confirmação. O patch do ProgramData é melhor avaliado por se os clientes concordam sobre transações que encontram o novo limite e se a infraestrutura permanece disponível depois que o gate é ativado.

Um rollback também muda de significado na ativação. Antes do limite, uma versão mais antiga com suporte ainda pode processar as regras já em vigor. Depois dele, retornar a uma build que carece do recurso pode trazer de volta exatamente a incompatibilidade que o operador estava tentando resolver. Um fallback precisa manter o suporte para o gate ativo.

Um operador com capacidade ociosa pode colocar um nó corrigido no ar e validá-lo antes de direcionar tráfego. Um operador menor pode ter que reiniciar seu único nó e esperar que ele se sincronize. O prazo é compartilhado, mas o tempo que os usuários passam esperando pode depender da redundância do provedor.

Por que o preço do SOL não consegue medir o efeito da atualização

O SOL pode cair ou subir nas mesmas horas em que os operadores instalam um patch. Ele é negociado contra muitas das mesmas moedas e pools de capital que outros criptoativos. Taxas, movimentos do Bitcoin e mudanças na alavancagem podem afetar o preço durante a mesma janela.

Um problema técnico pode ser relevante para a negociação se interromper transferências ou tornar uma aplicação indisponível. As evidências para essa explicação incluiriam avisos das plataformas de negociação, mudanças em depósitos ou saques, ou dados de execução onchain vinculados às contas relevantes. O preço de um token por si só não identifica esse canal.

Uma falha individual de transação também é distinta da perda de controle sobre uma conta. Uma carteira pode ter construído uma transação com informações antigas ou submetido-a através de um nó desatualizado. O usuário ainda pode controlar a conta enquanto a aplicação tem dificuldade em alcançar a rede atual.

O teste mais direto após o prazo está, portanto, no nível do serviço. Um nó de votação deve estar atualizado e registrando votos. Um serviço de RPC deve estar respondendo a solicitações da cadeia aceita. Uma exchange deve ser capaz de prestar contas sobre se e quando processou transferências submetidas em torno da mudança.

Essas evidências podem sustentar uma avaliação mesmo que o preço se mova por razões não relacionadas. Também dá aos delegadores uma forma de avaliar o desempenho do seu próprio validador sem tratar uma exigência de versão em toda a rede como uma declaração sobre os resultados de cada operador.

O que acontece quando um operador volta a ficar online

Instalar o software corrigido é uma etapa na restauração de um nó. O operador então precisa verificar se o processo alcança a cadeia aceita e a segue sob as regras atuais. Um servidor pode reiniciar com sucesso enquanto ainda está reproduzindo blocos ou retornando dados que ficam atrás da ponta.

Um nó de votação também precisa mostrar que sua participação foi retomada. Seu operador pode comparar os votos atuais com o momento em que o nó se recuperou. Um delegador que lê os dados de recompensa mais tarde pode então distinguir o ponto de recuperação do momento em que a correção foi instalada.

Um provedor de serviços pode retirar um nó corrigido da rotação até que ele tenha alcançado a ponta e passado nas verificações. O operador pode comparar o slot, o resultado de uma transação recente e o desfecho de uma simulação com uma referência separada. Um provedor que devolve o nó ao tráfego antes dessas verificações pode fazer uma atualização de software parecer completa enquanto os clientes ainda encontram dados antigos.

A linha do tempo importa ao avaliar o impacto. Um nó que divergiu e retornou dentro da mesma época pode parecer saudável em um diretório posterior. Sua participação perdida ainda pode ser relevante para o operador ou os delegadores. Uma linha do tempo pública de incidentes precisaria de detalhes suficientes para mostrar quando o serviço parou e quando a atividade normal foi retomada.

As equipes de aplicação também podem examinar transações que falharam apenas através de um backend específico. Se o reenvio através de um nó atual resolver o problema sem alteração nas instruções, o endpoint anterior torna-se uma provável fonte da falha. Se a mesma transação falhar consistentemente em nós atuais próximos ao limite de dados da conta, a própria transação pode precisar ser reconstruída.

Tal reconstrução pode envolver a redução dos dados carregados pela transação ou a separação de instruções onde a aplicação pode tolerar múltiplas transações. Dividir uma transação pode alterar suas garantias, porque instruções que deveriam ter sucesso ou falhar juntas podem deixar de fazê-lo. A mudança, portanto, pertence ao próprio design da aplicação, juntamente com seus requisitos de carregamento de contas.

As consequências para um usuário dependem de onde ocorreu a incompatibilidade. Um operador pode perder participação, um RPC pode retornar informações desatualizadas e uma aplicação pode construir uma transação que não se encaixa mais. Os dois primeiros podem ser resolvidos restaurando infraestrutura compatível, enquanto o terceiro depende da transação e da regra ativa.

Uma verificação da recuperação da Solana deve manter essas observações separadas. Deve comparar registros de votos dos operadores, registros de serviço dos provedores e resultados de execução das aplicações afetadas. Fazer isso torna possível identificar um efeito restrito mesmo que a rede tenha continuado a produzir blocos durante todo o período.

O prazo de novembro deu aos operadores uma versão nomeada e um limite de época. O registro duradouro de seu impacto virá do que os nós fizeram em torno desse limite e do serviço que conseguiram fornecer depois dele.

O que observar

• Versões compatíveis: O cronograma da Anza e as notas de versão podem estabelecer o piso da mainnet e seus equivalentes entre os clientes.
• Participação na votação: O stake ativo e os créditos de voto podem mostrar se a participação na votação mudou em torno do limite.
• Confirmações de rede: Os registros de blocos e confirmações podem mostrar se a rede continuou processando transações em torno da mudança.
• Operações de exchange: Os avisos das corretoras podem estabelecer se uma exchange pausou seus próprios depósitos ou saques de Solana.

Perguntas frequentes