Solana ativa v1 de Transações na quarta, aumentando limite…
Formatos legados permanecem válidos, mas indexadores e exploradores devem ser atualizados para evitar leituras falhadas e exibições de taxa zero.
A Solana está mirando para quarta-feira para ativar a Transação v1, aumentando o tamanho máximo da transação de 1.232 bytes para 4.096 bytes. A mudança expande o que pode caber atomicamente na blockchain, mas também força a infraestrutura de leitura de dados a atualizar ou arriscar solicitações falhadas e exibições enganosas de taxas prioritárias.
Principais Conclusões
- Solanaestá mirando uma ativação na mainnet na quarta-feira que aumenta o tamanho máximo da transação de 1.232 bytes para 4.096 bytes através da Transação v1.
- Formatos de transação mais antigos continuam sendo suportados, então a maioria das carteiras e aplicativos pode continuar operando sem mudar, a menos que precisem do espaço extra.
- Leitores de blocos e transações que alimentam exploradores, carteiras e aplicativos de negociação precisam de suporte para a Transação v1 ou as solicitações de busca podem falhar quando o novo formato aparecer.
- Os metadados da taxa prioritária mudam na v1, o que significa que ferramentas desatualizadas podem exibir uma taxa prioritária de zero, mesmo quando um usuário pagou uma.
Transação v1 Entra em Ação: 1.232 Bytes para 4.096 Bytes
A Solana está mirando quarta-feira para aumentar seu tamanho máximo de transação de 1.232 bytes para 4.096 bytes através de um novo formato de Transação v1. Isso representa um aumento de mais de 3x na quantidade de instruções e carga de dados que podem caber em uma única transação.
A vitória prática é a atomicidade. Fluxos de trabalho que anteriormente precisavam ser divididos em várias transações podem ser cada vez mais executados em uma só, reduzindo o número de assinaturas separadas, transmissões e pontos de falha necessários para completar uma ação complexa.
O novo formato já está em funcionamento nas redes de teste e desenvolvimento da Solana. O pacote não especifica um horário exato de ativação para quarta-feira e não confirma a ativação final da mainnet além do alvo.
A mudança é definida em dois Documentos de Melhoria do Solana, SIMD-0296 e SIMD-0385, co-autores por Jacob Creech e Andrew Fitzgerald.
Execução e Óptica de Taxas: Transações Maiores, Metadados de Taxa de Prioridade Diferentes
Transações maiores expandem o espaço de design para aplicativos Solana que são pesados em instruções. Os exemplos citados do que agora pode caber mais confortavelmente em uma única transação incluem grandes provas criptográficas, pagamentos que requerem muitas aprovações (grandemultisigoperações), e algumas transferências confidenciais.
Para os traders, a implicação imediata é a redução de sequências de múltiplas transações para ações complexas. Isso é mais relevante quando a rede está congestionada e a execução parcial é cara. Uma transação ou é concluída ou não é. Dividir a mesma intenção em várias transações aumenta as chances de que uma parte falhe, seja concluída tarde ou seja processada em um regime de taxas diferente.
A questão das taxas é mais complexa. A atualização não introduz uma nova taxa por byte, mas transações maiores consomem mais largura de banda da rede. Os desenvolvedores esperam que os usuários possam precisar oferecer taxas de prioridade mais altas quando transações maiores estiverem competindo por espaço.
As taxas de prioridade são pagamentos extras opcionais que os usuários podem fazer para que uma transação seja processada mais rapidamente. O problema é que o Transaction v1 armazena informações sobre taxas de prioridade em outro lugar, o que cria um novo modo de falha para qualquer ferramenta que assume o layout antigo.
Risco de Indexador e Explorador: Leituras Falhadas e Relatos de 'Taxa Zero' Incorretos
A pressão imediata por upgrades não está nas carteiras. Os formatos de transação existentes continuarão a ser suportados, e carteiras e aplicativos não precisam mudar para v1, a menos que precisem do espaço extra.
A pressão está na infraestrutura que lê Solana. Serviços que buscam blocos e transações devem ser atualizados para reconhecer a Transação v1. Se não forem, os pedidos podem falhar ao encontrar o novo formato.
Essa falha não é apenas uma dor de cabeça operacional. Carteiras, exploradores e aplicativos de negociação frequentemente dependem desses serviços para exibir o que aconteceu na blockchain. Se o backend não conseguir interpretar v1, o sintoma visível para o usuário pode ser transações ausentes, visualizações de histórico quebradas ou relatórios de execução inconsistentes entre aplicativos que estão puxando de diferentes indexadores.
A percepção das taxas é o ponto mais crítico. Como a v1 armazena dados de taxa de prioridade em um local diferente, softwares desatualizados podem mostrar uma taxa de prioridade de zero mesmo quando uma foi paga. Durante a congestão, esse tipo de erro pode distorcer a experiência do trader, fazendo com que a execução pareça mais barata do que realmente foi, ou criando “verdades” conflitantes entre exploradores e terminais.
Lista de Verificação Pós-Ativação para Traders e Construtores
O primeiro ponto de verificação é a confirmação do horário exato de ativação na quarta-feira e se algum problema de implementação surgir imediatamente após a mudança. O pacote não inclui um timestamp finalizado.
O segundo ponto de verificação é o status da infraestrutura. Indexadores, exploradores e backends de carteiras importantes precisam confirmar o suporte à Transação v1, incluindo a interpretação correta da taxa de prioridade. A prontidão mista é o caso base quando uma mudança de formato ocorre, e é onde os traders veem exibições de taxas inconsistentes entre as ferramentas.
O terceiro ponto de verificação é a telemetria de erros em campo. Relatórios de falhas em pedidos de busca de blocos ou transações, histórico ausente ou discrepâncias repentinas nas taxas de prioridade exibidas entre exploradores e aplicativos de negociação seriam o sinal mais claro de que alguns backends ainda estão lendo a blockchain com suposições antigas.
O último ponto de verificação é comportamental, não mecânico. Uma vez que transações maiores começam a competir por espaço, o mercado descobrirá o que “pode exigir taxas de prioridade mais altas” significa na prática durante a congestão. O pacote não fornece uma estimativa numérica, apenas a expectativa direcional.
Minha Leitura: Esta é uma atualização de UX e Confiabilidade tanto quanto uma de Throughput.
O limite que importa não é se as carteiras "suportam v1." Formatos legados continuam válidos, então a maioria das interfaces parecerá boa. O verdadeiro teste é se os indexadores e exploradores que os traders confiam implicitamente conseguem analisar v1 de forma consistente, porque leituras falhadas e relatórios errôneos sem taxa são como atualizações de formato se transformam em confusão de execução.
Se as exibições de taxa de prioridade permanecerem coerentes entre as principais ferramentas após a ativação, a configuração começará a parecer estrutural em vez de orientada por narrativas: ações mais complexas podem ser realizadas atomicamente sem quebrar a visão do trader sobre custo e confirmação.
Se a ótica das taxas se fragmentar, a atualização parecerá menos como uma capacidade extra e mais como um imposto temporário de confiabilidade pago em dados ruins.
