A Solana está mirando o dia 9 de setembro para a Transação v1, um novo formato que eleva o tamanho máximo de transação serializada de 1.232 bytes para 4.096 bytes.
Resumo
- A Solana planeja aumentar o tamanho máximo de transação de 1.232 bytes para 4.096 bytes na mainnet na quarta-feira.
- A Transação v1 permanece opcional, enquanto os formatos legado e v0 continuam operando sob os limites de tamanho existentes.
- Aplicativos que leem blocos devem suportar a versão um ou correr o risco de erros ao encontrar o novo formato.
- A v1 remove as tabelas de consulta de endereço e armazena os limites de recursos diretamente nos metadados de configuração de cada transação.
- O roteiro oficial da Solana marca a ativação da mainnet como pendente, tornando o cronograma de 9 de setembro ainda potencialmente alterável.
O aumento dá aos desenvolvedores cerca de 3,3 vezes mais espaço para transações. O roteiro oficial da Solana diz que a capacidade adicional pode acomodar provas de conhecimento zero, operações de múltiplas assinaturas grandes, lotes e alguns esquemas de assinatura onchain.
Operações grandes anteriormente tinham que ser divididas em várias transações quando suas instruções, assinaturas e informações de conta excediam o teto de 1.232 bytes. Esse processo adicionava complexidade porque uma transação poderia ser bem-sucedida enquanto outra etapa falhava.
A Transação v1 poderia permitir que os desenvolvedores combinassem mais dessas instruções em uma única operação atômica. Ou todas as instruções são bem-sucedidas ou a transação inteira falha. O modelo poderia beneficiar rotas de negociação, transferências confidenciais, operações entre cadeias e aplicativos que processam provas criptográficas complexas.
A atualização não aumenta o limite da Solana de 64 contas referenciadas por transação. Os aplicativos podem incluir mais dados e instruções, mas não podem interagir automaticamente com mais contas.
As transações Solana existentes permanecerão válidas
A Transação v1 é opcional. Carteiras e aplicativos podem continuar enviando transações legadas e v0 sob o limite existente de 1.232 bytes. Os usuários não precisam migrar tokens, trocar SOL ou concluir uma reivindicação antes da ativação.
Os desenvolvedores devem adotar deliberadamente o novo formato para acessar sua maior capacidade. A documentação da Solana identifica três formatos suportados: legado, v0 e v1. Cada formato organiza endereços de conta e limites de recursos de maneira diferente.
O formato v0 usa Tabelas de Consulta de Endereço, ou ALTs, para representar endereços de conta por meio de índices compactados de um byte. A v1 remove as ALTs e coloca endereços de conta completos de 32 bytes diretamente dentro da transação.
Isso cria uma troca. A v1 fornece um envelope geral maior, mas aplicativos que dependem fortemente de tabelas de consulta podem gastar mais bytes para representar as mesmas contas. A análise técnica da Solana descobriu que 90% das transações amostradas adicionariam menos de 1.400 bytes quando convertidas de v0 para v1.
Provedores de infraestrutura devem atualizar seu software
O principal risco de compatibilidade se aplica a serviços que leem blocos e transações. Provedores de chamada de procedimento remoto devem definir sua versão máxima suportada de transação para um. Caso contrário, as solicitações podem falhar quando encontrarem uma transação v1.
Indexadores, exploradores e serviços de análise também devem mudar a forma como recuperam limites de recursos. Transações legadas e v0 colocam limites de computação e configurações de taxa de prioridade dentro das instruções ComputeBudget. A v1 os armazena em uma configuração de transação dedicada.
Serviços desatualizados podem, portanto, exibir informações incorretas. Por exemplo, um explorador pode mostrar uma taxa de prioridade zero, mesmo que o usuário tenha pago uma. Patrocinadores de taxas e aplicativos que verificam limites de transação devem ler a nova configuração em vez de escanear instruções no estilo antigo.
Aplicativos que enviam transações v1 devem definir explicitamente os limites de unidades de computação e dados carregados, pois ambos têm padrão zero. Os desenvolvedores devem testar a construção, assinatura e decodificação de transações antes de mover o tráfego de produção para o formato.
9 de setembro continua sendo uma data de ativação alvo
O vice-presidente de tecnologia da Solana Foundation, Jacob Creech, identificou 9 de setembro como a data planejada para a mainnet. Como o crypto.news noticiou anteriormente, a atualização está incluída no lançamento do Agave 4.2 da Anza.
No entanto, o roteiro oficial ainda rotula o recurso da mainnet como "não ativado". Também afirma que o cronograma de lançamento da Anza é "provisório e sujeito a alterações". Testnet e devnet já ativaram o recurso, de acordo com a página de status mais recente da Fundação.
O aumento de tamanho vem do SIMD-0296, enquanto o SIMD-0385 define o formato v1. Jacob Creech e Andrew Fitzgerald co-autoraram ambas as propostas.
O teto de 4.096 bytes foi selecionado em parte porque quatro kilobytes correspondem a um tamanho comum de página de memória usado pelo hardware do validador. Transações maiores também consumirão largura de banda adicional, embora a atualização não introduza nenhuma taxa separada cobrada por byte.
A transação v1 permanece separada das reduções de aluguel da Solana, metas de slot mais curtas e do redesenho de consenso Alpenglow. Em cobertura relacionada, o crypto.news informou que o Alpenglow visa aproximadamente 150 milissegundos de finalidade, com outubro permanecendo como meta de desenvolvimento em vez de uma data de ativação garantida.
