Solana tem como alvo 9 de setembro para a Transaction v1, um novo formato que aumenta o tamanho máximo de transação serializada de 1.232 bytes para 4.096 bytes.
O aumento oferece aos desenvolvedores cerca de 3,3 vezes mais espaço para transações. O roadmap oficial da Solana afirma que a capacidade adicional pode acomodar provas de conhecimento zero (zero-knowledge proofs), grandes operações de múltiplas assinaturas, lotes e alguns esquemas de assinatura on-chain.
Operações grandes tinham que ser divididas em várias transações anteriormente, quando suas instruções, assinaturas e informações de conta excediam o limite de 1.232 bytes. Esse processo adicionava complexidade, pois uma transação poderia ser bem-sucedida enquanto outra etapa falhava.
A Transaction v1 poderia permitir que os desenvolvedores combinassem mais dessas instruções em uma única operação atômica. Ou cada instrução é bem-sucedida, ou a transação inteira falha. O modelo poderia beneficiar rotas de negociação, transferências confidenciais, operações cross-chain e aplicações que processam provas criptográficas complexas.
A atualização não eleva o limite da Solana de 64 contas referenciadas por transação. As aplicações podem incluir mais dados e instruções, mas não podem interagir automaticamente com mais contas.
A Transaction v1 é opcional. Carteiras e aplicações podem continuar a enviar transações legadas e v0 sob o limite existente de 1.232 bytes. Os utilizadores não precisam migrar tokens, trocar SOL ou completar uma reivindicação antes da ativação.
Os desenvolvedores devem adotar deliberadamente o novo formato para aceder à sua maior capacidade. A documentação da Solana identifica três formatos suportados: legado, v0 e v1. Cada formato organiza os endereços de conta e os limites de recursos de forma diferente.
O formato v0 usa Tabelas de Pesquisa de Endereços, ou ALTs, para representar endereços de conta através 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 compensação. A V1 oferece um envelope geral maior, mas as aplicações que dependem fortemente de tabelas de pesquisa 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.
O principal risco de compatibilidade aplica-se aos serviços que leem blocos e transações. Os provedores de chamadas de procedimento remoto (RPC) devem definir a versão máxima de transação suportada para um. Caso contrário, as solicitações podem falhar ao encontrar uma transação v1.
Indexadores, exploradores e serviços de análise também devem alterar a forma como recuperam os limites de recursos. Transações legadas e v0 colocam os limites de computação e as 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 poderiam, portanto, exibir informações incorretas. Por exemplo, um explorador pode mostrar uma taxa de prioridade zero, mesmo que o utilizador tenha pago uma. Patrocinadores de taxas e aplicações que verificam os limites de transação devem ler a nova configuração em vez de digitalizar instruções antigas.
As aplicações que enviam transações v1 devem definir explicitamente os limites de unidade de computação e dados carregados, pois ambos assumem zero por padrão. 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.
O vice-presidente de Tecnologia da Solana Foundation, Jacob Creech, identificou 9 de setembro como a data planeada para a mainnet. Como o crypto.news relatou anteriormente, a atualização está incluída no lançamento do Agave 4.2 da Anza.
No entanto, o roadmap oficial ainda rotula a funcionalidade da mainnet como “não ativada”. Também afirma que o cronograma de lançamento da Anza é “tentativo e sujeito a alterações”. A testnet e a devnet já ativaram a funcionalidade, de acordo com a última página de status da Foundation.
O aumento do tamanho provém do SIMD-0296, enquanto o SIMD-0385 define o formato v1. Jacob Creech e Andrew Fitzgerald foram coautores de ambas as propostas.
O limite 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 dos validadores. 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 Transaction v1 permanece separada das reduções de aluguel da Solana, dos alvos de slot mais curtos e do redesenho do consenso Alpenglow. Em cobertura relacionada, o crypto.news relatou que o Alpenglow visa uma finalidade de aproximadamente 150 milissegundos, com outubro permanecendo um alvo de desenvolvimento e não uma data de ativação garantida.
SOL