Solana escala o seu novo limite de transações de 4.096 bytes para uma página de memória

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

As cargas de trabalho que exigem múltiplas transações são agora concluídas com uma única chamada atómica.

O QUIC tornou o limite de 1.232 bytes inútil

A limitação original do Solana era uma precaução de rede. A rede operava com um MTU IPv6 de 1.280 bytes.

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

Em 2022, Solana adotou o QUIC como padrão para lidar com as transações. A RFC 9000 não define um tamanho máximo de fluxo, pelo que as cargas úteis maiores podem ser transmitidas sem problemas na camada de rede.

O limite de 1.232 bytes tinha-se transformado numa regra sem qualquer fundamento técnico.

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

Um componente complementar, o SIMD-0385, defio formato de mensagem v1, que contém os bytes extra. Esta combinação resolve uma restrição que os programadores têm vindo a contornar desde o lançamento da cadeia de protocolos.

A proposta prioriza 4096 bytes em vez do tamanho máximo permitido pelo QUIC, para que uma transação caiba numa única página padrão de 4 KiB da memória do validador. Nunca nenhuma transação ultrapassa o limite de uma página.

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

Para chegar ao limite de 4096 bytes, Creech e Fitzgerald analisaram a forma como os programadores utilizavam os pacotes Jito para contornar as antigas restrições:

• 50% dos pacotes enviados tinham 2048 bytes ou menos.
• 65% tinha menos de 6.144 bytes.
• 100% permaneceram com menos de 9.216 bytes.

Um limite de 4096 bytes abrange a grande maioria destas cargas de trabalho com múltiplas transações numa única chamada, mantendo-se dentro das restrições de página do hardware do validador.

As chamadas RPC não preparadas geram agora o erro -32015 no Solana

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

As provas de conhecimento zero, como as utilizadas nas Transferênciasdentda Token Extensions, geraram payloads que excederam o limite de 1.232 bytes.

Para resolver este problema, os programadores encadeavam várias chamadas ou abdicavam de transferências encriptadas atómicas. O novo limite de 4.096 bytes permite provas de conhecimento zero numa única transação.

A agregação de assinaturas BLS e as grandes configurações multisig também beneficiam desta mudança. O SIMD-0296 refere o multisig aninhado, o tipo de multisig utilizado pelas tesourarias institucionais e DAOs através de Squads, como um dos principais fatores.

Faz também referência às assinaturas únicas de Winternitz e aos esquemas BLS on-chain que funcionam sem pré-compilações.

O formato dispensa as tabelas de pesquisa de endereços (Address Lookup Tables), que a versão 0 utilizava para referenciar até 64 contas com índices curtos. As tabelas acrescentam complexidade sem qualquer vantagem, pois existem agora 64 endereços de 32 bytes em linha, que ocupam apenas 2048 bytes, muito abaixo do limite máximo.

O limite de 64 contas por transação mantém-se na Solana . As aplicações que utilizam muitas contas ainda atingirão o limite, mesmo com a resolução do problema de orçamento de bytes. rede

Os pacotes Jito permitem aos programadores combinar até cinco transações numa sequência "tudo ou nada" para resolver o problema de limitação de bytes.

A transação v1 consegue o mesmo resultado atómico numa única transação. Traz a atomicidade nativa diretamente para a camada base.

A versão 1 é opcional para os remetentes, pelo que as transações legadas e da versão 0 continuam a funcionar. Solana Foundation As notas referem que esta é uma mudança significativa 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 do Solana, irão falhar completamente ou apresentar erros.

Quando uma aplicação tenta ler uma transação ou bloco v1 sem o novo parâmetro de versão, os servidores da Solanarejeitam o pedido com um código de erro do sistema -32015.

As ferramentas que transmitem blocos ao vivo continuamente irão deparar-se com uma nova transação v1, receber uma resposta completamente em branco e ficar bloqueadas nesse ponto.

Os indexadores, ou ferramentas que registam dados de transações, mostram taxas de prioridade zero para novas transações porque estão a procurar no sítio errado.

Antes, estas taxas eram lidas numa lista específica dentro da transação. Na nova versão, esta informação é armazenada num quadro de resumo dedicado.

A Anza exige que os fornecedores de RPC atualizem para o Agave v4.2. A Helius publicou uma lista de verificação de migração detalhando o trabalho.

A transação v1 foi ativada na testnet Solana durante a época 1025, no dia 1 de setembro. A Anza agendou oficialmente a implementação na mainnet para 9 de setembro.