Finalidade mais rápida da Solana já está no ar. O que muda para os usuários?

A Solana está executando o Alpenglow na mainnet desde 21 de outubro, substituindo um sistema de votação que podia levar vários segundos para finalizar um bloco por um projetado para terminar em uma fração de segundo. A Solana Foundation registra a mudança na época 1064, depois que 446 de 654 validadores certificaram um bloco gênesis.

Um usuário enviando SOL pode ver um pagamento aparecer quase instantaneamente e se perguntar o que a atualização melhorou. Uma carteira pode mostrar que uma transação foi processada antes que a rede a tenha tornado final. O Alpenglow comprime a espera pela garantia mais forte, mas o aplicativo ainda precisa enviar o pagamento, receber a resposta de um nó e decidir quando alterar sua própria exibição. Uma exchange pode impor outra espera antes de creditar uma conta.

O registro de atualização da Foundation diz que formatos de transação, programas e taxas não mudaram. Desenvolvedores que apenas enviam pagamentos e leem saldos de contas não precisam de um novo formato de transação. Aqueles que lidam com fluxos de blocos têm mais trabalho, porque a rota de um bloco proposto até um bloco acordado é diferente. A questão prática agora é quais serviços repassam essa finalidade mais rápida aos clientes e quais continuam a usar seus antigos cronogramas de confirmação.

A mudança aconteceu, mas 150 milissegundos é uma meta

O Alpenglow substituiu o TowerBFT, o antigo processo de consenso da Solana, em 21 de outubro. No sistema antigo, os validadores colocavam transações de voto onchain e um bloco acumulava votos suficientes ao longo de slots posteriores para se tornar final. O Votor, a parte ativa do Alpenglow, transporta votos diretamente entre validadores e os combina em certificados. Um bloco pode ser finalizado em uma ou duas rodadas de votação.

A Foundation usa 12,8 segundos como referência para a antiga finalidade e aproximadamente 150 milissegundos como a nova meta. Esses números descrevem uma comparação de protocolo, não duas medições feitas da mesma carteira sob condições idênticas. O relatório de preparação de 21 de outubro alertava que nós RPC sem stake poderiam saber da finalidade mais tarde do que os validadores participantes, às vezes depois que outro bloco é produzido. A latência da internet e o nó escolhido por um aplicativo somam-se ao que o usuário vê.

Uma medição externa publicada em 23 de outubro colocou a finalidade mediana em 404 milissegundos nas 24 horas anteriores, com um percentil 90 de 579 milissegundos e um percentil 99 de 765 milissegundos. Sua referência anterior era de cerca de sete segundos sob o TowerBFT. Com esses números, a mediana melhorou cerca de 17 vezes, calculado dividindo sete segundos por 0,404 segundos. A metodologia e o ponto de observação diferem da linha de base de 12,8 segundos e da meta de design de 150 milissegundos da Foundation.

O painel ao vivo da Foundation exibe uma leitura de finalidade observada mais recente em constante mudança e tendências ao longo de várias janelas de tempo. Um valor mais recente não deve ser promovido a experiência típica do cliente. A série útil inclui latência mediana e de cauda, interrupções e o tempo que diferentes provedores levam para relatar o mesmo bloco finalizado. Um único slot especialmente rápido prova que o protocolo pode atingir essa velocidade uma vez; isso diz pouco sobre o pagamento de um comerciante durante uma hora movimentada.

A distinção entre alvo e medição foi central para a questão da prontidão dos validadores antes da ativação. A mainnet desde então forneceu um certificado e vários dias de blocos mensuráveis. Uma pergunta foi respondida: os validadores de fato coordenaram a troca. Se o cliente típico de RPC vê algo próximo do alvo anunciado agora é uma questão diferente, porque a fundação e os monitores externos iniciam seus cronômetros em pontos distintos. Relatar ambos os números com esses pontos de partida permite aos leitores comparar o desempenho real sem tratar a observação mais lenta como evidência de que o design de consenso falhou.

A produção de blocos da Solana acelerou por meio de outro programa que reduziu o tempo de slot alvo de 400 para 200 milissegundos em outubro. Essa medida diz respeito à frequência com que um líder produz um bloco. A finalidade diz respeito a quando a rede concorda que um determinado bloco não pode ser revertido sob suas regras. Slots mais rápidos e finalidade mais rápida podem ambos ajudar um usuário, mas os dois números não devem ser somados nem tratados como o mesmo cronômetro.

O número anunciado depende de quais participantes recebem um bloco proposto a tempo de votar. Uma rota rápida pode certificar um bloco prontamente, enquanto uma rota alternativa acomoda comunicação mais lenta. Uma rodada lenta não implica por si só uma atualização falha: o consenso ainda deve concordar quando um validador perde uma mensagem ou a proposta de um líder compete com outra. A mediana pode melhorar drasticamente enquanto um pequeno número de slots leva mais tempo. Serviços que lidam com grandes transferências se importarão com a cauda lenta tanto quanto com o alvo principal.

Um observador público deve perguntar onde um cronômetro de finalidade começa. Começar quando um validador recebe um bloco proposto exclui o tempo que uma carteira passou transmitindo sua transação. Começar quando um comerciante toca em “cobrar” inclui um humano e vários sistemas de software. Começar quando um servidor RPC vê um certificado inclui o atraso entre os validadores e o servidor. Cada cronômetro responde a uma pergunta diferente. A medição externa de 23 de outubro é útil porque seu método e distribuição podem ser examinados separadamente da alegação de design da Fundação.

Uma carteira tem mais de um cronômetro

Imagine pagar um café com uma carteira Solana. O usuário primeiro aprova uma transação localmente. A carteira a envia por um serviço RPC, a rede a inclui em um bloco candidato e os validadores certificam esse bloco. O sistema do comerciante recebe uma atualização de status e decide se entrega o café. O Alpenglow muda o estágio de certificação, não o tempo gasto para abrir a carteira ou a política do próprio comerciante.

Muitos aplicativos já exibiam uma mensagem de sucesso antes da finalidade do TowerBFT. Eles estavam usando um nível de compromisso menos final porque a maioria dos pagamentos de varejo não espera pela garantia de consenso mais forte antes de mudar a tela. Um status finalizado mais rápido poderia permitir que um aplicativo oferecesse garantia mais forte aproximadamente na velocidade de seu status inicial anterior. A melhoria será visível apenas se o serviço atualizar sua regra de espera e seu provedor entregar o resultado prontamente.

Um depósito em exchange ilustra o limite. Uma transferência pode ser final na Solana enquanto a exchange ainda verifica o remetente, associa o endereço a uma conta, faz triagem de risco e aplica uma política interna de crédito. O novo tempo de finalidade da cadeia não pode obrigar a exchange a liberar um saldo imediatamente. Uma bridge precisa de um relé de mensagens, execução na cadeia de destino e frequentemente suas próprias salvaguardas. A liquidação entre dois sistemas, portanto, permanece mais lenta do que a finalidade da cadeia de origem isoladamente.

O relato da testnet de setembro estabeleceu a distinção antes do lançamento. Ele descreveu um novo processo de votação, não uma nova forma de assinar pagamentos comuns. Agora há um registro em mainnet para verificar. Provedores podem comparar o momento em que um cliente envia uma transação, o momento em que um validador a certifica e o momento em que sua API relata finalidade. Sem esses carimbos de tempo separados, uma alegação de pagamento de usuário em 150 milissegundos oculta quaisquer partes que não foram medidas.

A palavra “instantâneo” continuará tentadora no marketing. Um cliente em pé no balcão se importa se o comerciante recebe uma aceitação confiável antes de se virar, o que é uma medida de serviço ponta a ponta. Um trader se importa se uma plataforma atualiza saldos antes da próxima oportunidade de mercado. Ambos podem se beneficiar mesmo que a carteira nunca exiba um status de finalidade explícito. A nenhum deles deve ser prometido que toda interação é concluída em 150 milissegundos.

Um operador de ponto de venda toma duas decisões independentes. Ele escolhe quando um pagamento é suficientemente seguro para liberar mercadorias, e escolhe como lidar com uma conexão interrompida. Um certificado de consenso rápido melhora a primeira decisão, mas não faz com que um terminal offline receba uma resposta. Um processador pode enviar uma mensagem de sucesso provisória e reconciliá-la depois, ou esperar pelo status finalizado. O que importa no checkout é a política real, incluindo como envios duplicados e respostas atrasadas aparecem na tela.

Aplicações financeiras têm outras razões para distinguir velocidade de política. Um aplicativo de empréstimo pode registrar garantias quando uma transferência é processada, mas permitir empréstimos apenas após a finalização. Uma plataforma centralizada pode observar saldos finalizados enquanto aplica sua própria retenção de saques. Uma bridge deve lidar com o risco da cadeia receptora além do risco da Solana. Um certificado mais rápido cria uma oportunidade de encurtar a porção dependente da cadeia de cada fluxo de trabalho. Publicar tempos de serviço antes e depois mostraria onde os provedores usam essa oportunidade.

Menos transações no gráfico podem significar a mesma quantidade de uso

No TowerBFT, a votação dos validadores fazia parte do fluxo de transações onchain. Os validadores do Alpenglow se comunicam diretamente e colocam informações de certificação nos rodapés dos blocos, de modo que essas transações de voto não aparecem mais na contagem comum de transações por bloco. Um painel que exibia todas as transações por segundo pode cair após a mudança sem uma queda em transferências, swaps ou pagamentos feitos pelos usuários.

O cofundador da Solana, Anatoly Yakovenko, discutiu a remoção das transações de voto pouco antes da ativação, quando a mudança no TPS de destaque estava chamando atenção. Analistas que comparam o tráfego em 20 de outubro com o tráfego após 21 de outubro devem isolar as transações que não são de voto em ambos os lados. Caso contrário, uma mudança contábil parece demanda perdida. O erro inverso seria afirmar que o tráfego menor de votos por si só cria um número igual de transações úteis adicionais de usuários; capacidade ociosa e uso real são coisas diferentes.

A aritmética pode ser verificada sem inventar uma nova estimativa de throughput. Se uma contagem pré-atualização combina transações de usuários U e votos de validadores V, seu total é U + V. Depois que os votos saem do bloco, um gráfico semelhante pode mostrar aproximadamente U mesmo quando os clientes enviam a mesma quantidade de transferências. A diferença V é uma mudança no que o gráfico conta. Calcular o crescimento real exige séries comparáveis apenas de usuários, não os totais de destaque antes e depois.

Isso importa também para comentários sobre taxas e receita. As taxas de transações de voto desaparecem, enquanto os validadores passam a pagar um Validator Admission Ticket. A mecânica de taxas de transações de usuários permanece. Uma mudança na receita total de taxas ligada à categoria de votos perdida não pode simplesmente ser apresentada como uma mudança na disposição do consumidor de transacionar. Uma comparação cuidadosa separa despesas relacionadas a votos, taxas de admissão e taxas que os usuários pagam para enviar ou priorizar suas próprias transações.

Exploradores de blocos e fornecedores de dados enfrentam uma tarefa relacionada. A participação antes lida a partir de instruções do programa de votos agora precisa ser lida a partir dos certificados e dos dados do rodapé. Um fornecedor que continua a analisar o campo antigo pode mostrar votos de validadores ausentes mesmo enquanto a rede está finalizando blocos normalmente. A documentação da Solana adverte que algumas interfaces de streaming ainda não encaminham todos os itens dos metadados de certificado, o que torna a documentação do provedor parte de qualquer comparação séria de desempenho.

Um gráfico de transações por segundo é vulnerável durante uma mudança de protocolo porque frequentemente agrega categorias diferentes. Uma plataforma que afirma que a atividade de usuários caiu imediatamente após a ativação precisa da contagem apenas de usuários em ambas as datas, idealmente dividida em transferências bem-sucedidas, swaps e tentativas falhas. Transações não são pessoas únicas nem compras concluídas. Um bot pode gerar muitas instruções, e uma instrução malsucedida ainda pode aparecer em uma série de transações enviadas. Uma redução na votação de validadores não diz nada por si só sobre comerciantes aceitando Solana.

A distinção também importa para a economia da rede. O desaparecimento das taxas de voto reduz um tipo de pagamento onchain feito pelos validadores. O ticket de admissão é queimado de outra conta em um cronograma diferente. As taxas de usuários dependem do que os clientes enviam e da prioridade que pagam. Combinar os três em uma única tendência de receita obscureceria se a demanda mudou ou se a contabilidade se moveu. Categorias consistentes em ambos os lados de 21 de outubro oferecem uma base mais sólida para interpretar um gráfico de taxas.

Serviços de dados precisam seguir o bloco vencedor

Uma decisão de votação rápida não faz de todo bloco proposto o vencedor. Os fluxos de dados atualizados da Solana podem expor mais de um banco candidato para um slot, e o Agave 4.3 marca eventos com um bank_id para que os clientes possam manter os candidatos separados. Um indexador que agrupa todos os dados sob um número de slot pode acidentalmente misturar transações de candidatos concorrentes em um registro de um bloco que nunca existiu naquela forma.

A Fundação orienta os consumidores de streaming a fazer buffer pelo par de slot e identificador de banco e reter o banco que alcança a confirmação. Se eles mesclam feeds de provedores diferentes, o identificador só é significativo dentro de cada conexão; o hash do bloco é a referência entre provedores. Parte do comportamento mais frequente de múltiplos bancos é esperada no Agave 4.4, então há tempo para ajustar antes que se torne comum, mas aplicações que lidam com fluxos de blocos atuais devem se preparar agora.

A maioria dos usuários de carteiras nunca verá um identificador de banco. Um aplicativo de portfólio ou exchange que reconstrói depósitos a partir de um feed defeituoso pode mostrar um pagamento cedo demais, perder um ou atribuir uma transferência ao candidato a bloco errado. Um sistema de negociação que reage a eventos de stream antecipados precisa saber se eles pertenciam ao bloco final. O protocolo pode finalizar rapidamente enquanto os erros de um indexador ainda atrasam ou distorcem o que as pessoas veem.

As notas de migração da mainnet da Fundação dizem que os níveis de compromisso confirmed e finalized agora descrevem o mesmo estado, embora o primeiro permaneça disponível no momento e será removido em uma versão posterior. Os desenvolvedores são aconselhados a direcionar novos trabalhos para finalized e revisar as configurações de timeout ou retry ajustadas para a espera antiga. Um serviço que espera 12 segundos por hábito pode permanecer lento apesar de uma cadeia muito mais rápida.

Os fluxos de dados têm outras mudanças. A Proof of History não mais cadencia a produção de blocos da mesma forma, então as entradas de tick saem do shred stream. Um programa que lê o timestamp do Clock pode ver uma fonte diferente da anterior. Esses detalhes não são sinais de que as transações dos usuários mudaram seu formato. São pontos onde o software construído em torno do timing do ledger antigo pode precisar de trabalho antes que a nova velocidade da rede chegue à tela.

Para um indexador, o problema é mais do que um novo nome de campo. Ele pode receber o mesmo slot por duas conexões e processar transações na ordem de chegada. Se os feeds carregarem eventos de bancos concorrentes e seu banco de dados indexar registros apenas por slot, registros posteriores podem sobrescrever os anteriores ou criar uma mistura impossível. A chave slot-and-bank da orientação de migração evita isso dentro de um feed; o hash do bloco vencedor eventual reconcilia os provedores. Os clientes percebem esse trabalho apenas quando um saldo ou histórico de negociação se torna mais confiável.

A lógica de retry merece outra olhada. Um cliente que faz polling uma vez por segundo pode perder a maior parte do benefício de uma melhoria de consenso de algumas centenas de milissegundos. Outro pode enviar o mesmo pagamento novamente porque uma resposta chega após seu timeout. Clientes bem projetados distinguem uma resposta lenta de uma transação não processada e preservam identificadores entre retries. Os operadores precisam testar esses comportamentos com o novo stream de compromisso antes de prometer um tempo de checkout fixo.

Os validadores têm uma nova conta recorrente

Remover as transações de voto onchain altera os custos dos validadores. A Solana Foundation diz que votar anteriormente custava cerca de 1 SOL por epoch em taxas de transação, pagas da conta de identidade de um validador. O novo Validator Admission Ticket queima 0,8 SOL por epoch de sua conta de voto, além do mínimo isento de aluguel. O ticket comprado no início de um epoch admite o validador para o próximo.

Um validador que não mantém SOL suficiente na conta correta não pode votar ou produzir blocos no epoch seguinte e perde a oportunidade de ganhar suas recompensas ali. Enviar o valor para a antiga conta de identidade não pagará a nova taxa. Os operadores podem direcionar a receita de blocos para a conta de voto, embora a Fundação diga que essa mudança leva dois epochs e a receita de comissão pode ser insuficiente em um determinado limite.

A comparação entre aproximadamente 1 SOL e 0,8 SOL não é uma economia líquida universal. Receita, stake, custos de software, comissões e o momento de cada cobrança diferem entre validadores. O fato confiável é qual conta paga, quanto é a taxa fixa de admissão e o que acontece se ela for perdida. A concentração de longo prazo dependerá de os operadores menores conseguirem sustentar os requisitos operacionais e financeiros enquanto permanecem competitivos.

O lançamento exigia Agave 4.3.2 ou clientes compatíveis Jito-Solana ou Harmonic Salsa. Firedancer e Frankendancer não eram suportados para a migração, de acordo com a página de operadores da Fundação. A ativação do Alpenglow prova que a rede podia mudar com validadores participantes; não mostra que todos os clientes validadores alternativos estavam prontos para o mesmo dia. A diversidade de clientes continua sendo uma questão de resiliência separada.

A aprovação de governança veio antes da migração.O plano de implementação anterior descrevia o código no Agave 4.2 durante os testes, mas a instalação por si só nunca foi a mudança da mainnet. O certificado de gênese e o início do consenso no slot 459.653.000 são a evidência de ativação. Os 446 signatários do primeiro certificado representaram um evento de coordenação concreto, não uma promessa sobre a presença ou o desempenho de todos os 654 validadores a cada hora depois disso.

O ticket fixo muda a economia dos validadores de forma diferente por tamanho. Um grande operador e um pequeno pagam os mesmos 0,8 SOL para entrada, então a cobrança consome uma fração maior das recompensas brutas de um operador pequeno. Se isso afasta alguém depende do stake delegado, comissão, custos operacionais e outras receitas. A orientação aos operadores estabelece a mecânica de pagamento; não prevê quantos validadores sairão. Um acompanhamento útil seria comparar operadores independentes ativos e a concentração de stake ao longo de vários epochs.

A troca de conta pode criar uma interrupção evitável mesmo para uma operação saudável. O ticket vem da conta de voto antecipadamente, enquanto os operadores financiavam as antigas taxas de voto a partir da conta de identidade à medida que os votos eram enviados. Um validador com SOL suficiente no total, mas com a alocação errada entre as contas, pode perder a admissão. Os relatórios de uptime devem distinguir esse problema de migração de uma falha no novo protocolo de votação. São falhas operacionais separadas, com remédios diferentes.

O upgrade resolve um problema mais restrito do que os aplicativos de pagamento resolvem

O argumento da Solana para o Alpenglow é poderoso: se a finalidade chegar muito mais cedo, os serviços que precisam de liquidação irreversível podem parar de esperar por vários segundos de incerteza. As medições externas de 23 de outubro sustentam uma melhoria material na mainnet, embora sua mediana de 404 milissegundos tenha sido mais lenta do que a meta de projeto. Comerciantes e exchanges podem optar por confiar nesse status mais forte e mais rápido.

Um serviço ainda pode manter um buffer. Pode usar vários provedores de RPC, exigir triagem antifraude ou creditar um cliente somente depois que seu próprio livro-razão conciliar os depósitos. Um pagamento de baixo valor poderia ser liberado com um status processado, tornando o Alpenglow quase invisível em sua interface atual. Uma transferência grande poderia usar o status finalizado e ganhar vários segundos. O upgrade não torna um serviço cauteloso irracional; ele dá ao serviço um sinal de rede mais rápido para incluir em sua decisão.

A primeira mudança mensurável pode ser a confiabilidade da promessa por trás de uma confirmação, em vez de uma animação espetacular em uma carteira. Os usuários que já viam confirmação rápida não necessariamente sabiam se ela era reversível. Os provedores agora podem decidir se mostram ou exigem uma finalidade mais forte nessa mesma janela. Publicar o tempo desde a aprovação do cliente até a aceitação pelo comerciante esclareceria a alegação voltada ao usuário com mais clareza do que anunciar apenas o número do consenso.

A segunda parte do Alpenglow, o Rotor, ainda está planejada para uma versão posterior, sem data de ativação. O Votor mudou a votação e a finalidade; a distribuição de blocos ainda usa a antiga abordagem Turbine. O nome do pacote pode dar a impressão de que todos os componentes propostos chegaram juntos. A tabela de status atual da Fundação deixa a separação clara. Qualquer ganho de desempenho atribuído ao Rotor nos dados atuais da mainnet estaria errando a cronologia.

A distribuição de blocos continua relevante quando os dados viajam de forma desigual pela rede. Uma votação mais rápida não pode ajudar um validador a certificar uma proposta que ele não recebeu. O componente Rotor planejado abordaria um estágio diferente dos certificados do Votor. Por enquanto, observações lentas podem refletir propagação, votação, entrega por RPC público ou várias delas juntas. Registrar cada estágio diria a um operador se sua próxima melhoria pertence ao software do validador, à distribuição de dados ou à infraestrutura do cliente.

O lançamento inicial é uma amostra curta de desempenho. Versões de cliente, trabalho de migração de provedores e presença de validadores definem as condições atuais. Versões posteriores podem mudar a consistência com que serviços externos ficam sabendo dos certificados, mesmo sem outra troca de consenso. Uma semana contínua de observações em vários provedores de RPC independentes, incluindo períodos de pico, seria mais valiosa para um comerciante do que uma única demonstração rápida.

O que ainda precisa ser medido

Não há um único número de finalidade que capture a espera de cada usuário. Certificados de validadores, observações de RPC público, status de carteira e tempos de crédito de exchanges medem etapas diferentes. O painel da Fundação fornece leituras ao vivo da rede, enquanto monitores externos observam a partir de seus próprios nós. A concordância entre métodos e provedores ao longo de vários dias mostraria se os resultados rápidos se mantêm além da semana de lançamento e com que frequência a cauda lenta aparece.

O registro da mainnet já é mais forte do que uma promessa de testnet. O Alpenglow está ativo, as transações de voto deixaram os blocos e os desenvolvedores publicaram as mudanças de integração. Ainda é cedo demais para atribuir ao upgrade de consenso mais usuários de aplicativos, preços de token mais altos ou uma determinada melhoria em cada checkout. Tais alegações precisam de coortes de transações, medições de serviço antes e depois e dados comparáveis apenas de usuários.

Para uma carteira ou provedor de pagamento, a próxima decisão é concreta: usar o sinal finalizado prontamente, publicar quando o usuário o vê e manter as verificações extras que seu produto exige. A cadeia alterou uma etapa. As pessoas notarão quando o software ao seu redor mudar o restante da jornada.

O que observar

• Finalidade observada: Compare as leituras da mediana móvel e do percentil mais lento no painel da Foundation e em nós independentes, com os pontos de observação declarados.
• Tempos de carteiras e exchanges: Meça o intervalo entre a aprovação do cliente e a confirmação visível ou o saldo creditado, não apenas o certificado do validador.
• Tráfego comparável: Acompanhe as transações de usuários que não são votos antes e depois de 21 de outubro, para que as transações de voto removidas não distorçam a tendência.
• Erros de streaming: Verifique se os provedores de RPC e indexadores suportam a reconstrução de blocos com reconhecimento de banco e o status finalizado em tempo hábil.
• Admissão de validadores: Observe o financiamento da conta de voto, os validadores ativos e a diversidade de clientes suportada, à medida que a taxa de 0,8 SOL se repete a cada época.

Perguntas frequentes