Bug do Solana v1 pode travar leitores e desativar limites de taxas

O formato de transações v1 da Solana eleva o payload máximo de 1.232 bytes para 4.096 bytes. O aumento é de cerca de 3,3 vezes. As transações legacy e v0 mantêm seus limites e comportamento atuais. Usuários e aplicações que continuarem usando esses formatos não precisarão migrar. A página de atualização ao vivo da Solana listava o v1 como inativo na mainnet em 4 de setembro. A testnet estava ativa. A devnet estava operando no epoch 1140. Um changelog da Solana publicado em 28 de agosto descreveu as transações v1 como próximas. Consumidores de RPC precisam aceitar o formato antes de ler dados v1. A adesão voluntária apenas informa ao serviço RPC qual é o formato mais alto que o cliente consegue decodificar. Ela não solicita dados v1 nem altera a forma como as transações legacy e v0 são retornadas. O v1 move os limites de compute units, os limites de dados de contas carregadas e as taxas de prioridade para um objeto, em vez de mantê-los nas instruções. Indexadores que continuarem examinando instruções podem informar um orçamento de computação zero para todas as transações v1 sem gerar um erro. A flag protobuf é true tanto para v0 quanto para v1. Um consumidor Geyser ou gRPC desatualizado pode, portanto, rotular v1 como v0 e preservar um orçamento vazio. Os consumidores precisam regenerar os stubs protobuf e verificar o campo 7 antes de ler a flag. Relayers, paymasters e outros signatários de servidor precisam atualizar suas verificações de política. Um patrocinador que examina instruções em busca de um limite de taxas talvez não consiga mais impor um limite obrigatório, porque essas instruções podem aparecer no v1, mas são executadas como no-ops. Os servidores precisam identificar o prefixo v1 e impor os limites de taxas e recursos na configuração da transação. O artigo caracteriza isso como uma falha de controle da aplicação, e não como uma falha de consenso. Afirma que o problema não é evidência de que os fundos estejam automaticamente em risco. A Solana diz que nenhum sysvar ou syscall atual expõe a configuração da mensagem v1. Programas que condicionam seu comportamento a instruções inspecionadas precisam deixar de depender dessa verificação quando o v1 entrar em operação. As versões mínimas listadas como capazes de ler o formato são 8.0.0, 3.0.0-rc.3, Rust 4.2.x, Python 0.29.0 e 1.23.0. A linha web3.js 1.x consegue ler v1 a partir da versão 1.99.0-beta.0, mas não consegue criá-lo, assiná-lo ou enviá-lo. Usuários do Yellowstone precisam de pelo menos 12.6.0, do plugin geyser 15.1.1, do cliente gRPC 12.0.0 ou 6.0.0, dependendo de sua pilha. Criar transações v1 é opcional. Equipes que as criarem precisam definir explicitamente os limites de compute units e de dados de contas carregadas, porque ambos têm valor padrão zero. Elas precisam remover instruções no-op. Precisam deixar de usar tabelas de consulta de endereços. Precisam usar base64 para payloads maiores que 1.232 bytes. O prazo imediato é um teste de compatibilidade para serviços que possam ler, indexar ou patrocinar a transação v1 de outro usuário.