A Solana dimensiona seu novo limite de transação de 4.096 bytes para uma página de memória

A Solana está prestes a triplicar a quantidade de dados que uma única transação pode transportar em 9 de setembro. Este novo teto de 4.096 bytes cabe em uma única página de memória de 4 KiB do hardware do validador, de acordo com a proposta SIMD-0296 no GitHub.

Cargas de trabalho que exigem várias transações agora levam uma única chamada atômica para serem concluídas.

O QUIC tornou o 1,232-byte cap inútil

O limite original da Solana era uma precaução de rede. A rede operava com um MTU IPv6 de 1.280 bytes.

Isso deixou 1.232 bytes para uma carga útil de transação após a sobrecarga do protocolo, escrevem os autores do SIMD-0296. Isso faz sentido quando cada mensagem tinha que passar pelo MTU sem fragmentação.

A Solana mudou para o QUIC como sua maneira padrão de lidar com transações em 2022. O RFC 9000 não define um tamanho máximo de fluxo, então cargas úteis maiores podem passar sem problemas no nível da rede.

O limite de 1.232 bytes havia se tornado uma regra sem base técnica.

Os dois documentos foram escritos pelos engenheiros da Anza Jacob Creech e Andrew Fitzgerald. SIMD-0296 aumenta o limite de tamanho.

Um companheiro, SIMD-0385, define o formato de mensagem v1, que contém os bytes extras. O par resolve uma restrição que os desenvolvedores estavam contornando desde o lançamento da cadeia.

A proposta prefere 4.096 bytes ao maior tamanho permitido pelo QUIC para que uma transação caiba em uma única página padrão de 4 KiB de memória do validador. Nenhuma transação cruza o limite de uma página.

A gestão de memória por transação é barata. Cada transação é restrita a uma única página.

Para chegar ao limite de 4.096 bytes, Creech e Fitzgerald analisaram como os desenvolvedores usaram pacotes Jito para contornar as antigas restrições:

• 50% dos pacotes submetidos eram de 2,048 bytes ou menos.
• 65% estava sob 6,144 bytes.
• 100% permaneceu sob 9,216 bytes.

Um teto de 4.096 bytes cobre a vasta maioria dessas cargas de trabalho de múltiplas transações em uma única chamada, permanecendo dentro dos limites de página do hardware do validador.

Chamadas RPC não preparadas agora geram erro -32015 na Solana

A capacidade extra permite cargas de trabalho que excedem o limite de 1.232 bytes.

Provas de conhecimento zero, como as usadas nas Transferências Confidenciais das Extensões de Tokens, geraram payloads que excediam o limite de 1.232 bytes.

Para resolver esse problema, os desenvolvedores encadeavam várias chamadas ou abandonavam transferências criptografadas atômicas. O novo limite de 4.096 bytes acomoda provas de conhecimento zero em uma única transação.

A agregação de assinaturas BLS e configurações grandes de multisig também se beneficiam dessa mudança. O SIMD-0296 cita a multisig aninhada, o tipo de multisig usado por tesourarias institucionais e DAOs por meio do Squads, como um dos principais impulsionadores.

Ele também menciona assinaturas Winternitz de uso único e esquemas BLS on-chain que funcionam sem pré-compilações.

O formato evita as Tabelas de Busca de Endereço, que a v0 usava para referenciar até 64 contas com índices curtos. As tabelas adicionam complexidade sem retorno, pois agora há 64 endereços inline de 32 bytes, que ocupam apenas 2.048 bytes, bem abaixo do teto.

O limite de 64 contas para cada transação permanece na rede Solana. Aplicações com muitas contas ainda alcançarão o limite mesmo com o problema do orçamento de bytes resolvido.

Os bundles da Jito permitem que os desenvolvedores mesclem até cinco transações em uma sequência de tudo-ou-nada para resolver o problema de limitação de bytes.

A transação v1 alcança o mesmo resultado atômico em uma única transação. Ela traz atomicidade nativa diretamente para a camada base.

A v1 é opcional para os remetentes, então as transações legadas e v0 continuam funcionando. As notas de migração da Solana Foundation dizem que é uma mudança de ruptura para a infraestrutura que lê blocos

Se as ferramentas de dados e os exploradores de blocos não forem atualizados para a nova versão da Solana, eles congelarão completamente ou gerarão erros.

Quando um aplicativo tenta ler uma transação ou bloco v1 sem o parâmetro de nova versão, os servidores da Solana rejeitam a solicitação com o código de erro do sistema -32015.

Ferramentas que transmitem continuamente blocos ao vivo encontrarão uma nova transação v1, receberão uma resposta completamente em branco e ficarão paralisadas ali.

Indexadores, ou ferramentas que registram dados de transações, mostram taxas de prioridade zero para novas transações porque estão procurando no lugar errado.

Anteriormente, eles liam essas taxas de uma lista especial dentro da transação. Na nova versão, essa informação é mantida em sua própria caixa de resumo dedicada.

A Anza está exigindo que os provedores de RPC atualizem para o Agave v4.2. Helius emitiu uma lista de verificação de migração detalhando o trabalho.

A transação v1 foi ativada na testnet da Solana durante o epoch 1025 em 1º de setembro. A Anza agendou oficialmente a implantação na mainnet para 9 de setembro.