A proposta SIMD-0649, que pretendia uniformizar a ordenação de transações dentro dos lotes da Solana, não foi aprovada: o pedido de alteração foi encerrado em 25 de setembro de 2026 sem ser integrado. A regra obrigaria os validadores a verificar a prioridade por taxa, mas manteria nas mãos dos produtores de blocos a escolha das transações e a definição dos limites dos lotes. Sem dados sobre a dimensão atual dos lotes, ainda não é possível avaliar se a proposta tornaria a execução mais previsível.
SIMD-0649 verificaria a ordem dentro de cada lote
A Solana organiza os dados dos blocos em lotes. Pela proposta, as transações de um mesmo lote teriam de ser ordenadas da prioridade mais alta para a mais baixa, com exceção das transações isentas. Ao reproduzir um bloco, os validadores verificariam a ordem registada e rejeitariam o bloco caso a regra não fosse cumprida; não reordenariam as transações depois de o receber.
Transações com a mesma prioridade poderiam surgir em qualquer ordem, e as transações simples de voto ficariam isentas. A pontuação de prioridade proposta não corresponderia apenas à taxa definida pelo utilizador: seria calculada dividindo a recompensa recebida pelo produtor do bloco por incluir uma transação pelo custo solicitado segundo o modelo de custos antes da execução. O cálculo incluiria um multiplicador e salvaguardas no denominador, além de aritmética inteira para procurar resultados consistentes entre diferentes clientes.
Pelas regras de taxas previstas, a recompensa incluiria a taxa de prioridade e a parcela da taxa base que não é queimada. Se fosse adotada, a regra criaria um critério comum para verificar se as transações não isentas já incluídas no mesmo lote estavam ordenadas de forma consistente. Os autores disseram que isso poderia facilitar a comparação entre clientes validadores e escalonadores, mas não determinaria se uma transação deveria ter sido incluída no bloco.
Produtores manteriam o controlo sobre a inclusão e os limites dos lotes
A proposta não criaria uma fila única de prioridade para todo o slot. Os produtores continuariam a decidir quais transações incluir, a adiar algumas para lotes posteriores e a definir onde cada lote começa e termina. Assim, transações concorrentes poderiam ficar em lotes diferentes e não ser comparadas pela regra. Uma transação com prioridade superior num lote posterior não passaria automaticamente à frente das transações de um lote anterior.
O âmbito da proposta seria, portanto, mais limitado do que o de uma regra de ordenação para todo o slot, sem garantir uma execução ótima. Para evitar que os produtores enfraquecessem as verificações dividindo os lotes em grupos muito pequenos, o texto estabelecia uma dimensão mínima.
Com exceção do último, cada lote teria de abranger pelo menos dois conjuntos FEC (correção de erros direta). Cada conjunto FEC é composto por fragmentos de dados que formam o bloco; segundo a dimensão fixa prevista, dois conjuntos corresponderiam a pelo menos 64 fragmentos de dados. O último lote continuaria sujeito à verificação da ordem, mas não teria de cumprir a dimensão mínima, uma vez que o slot poderia terminar antes de estar completo.
Falta de dados sobre os lotes limita a avaliação
Num comentário de revisão de 23 de setembro, foi observado que, mesmo com uma dimensão mínima, um produtor poderia encerrar um lote quando isso ajudasse a separar transações concorrentes. O revisor pediu dados atuais sobre a dimensão dos lotes, discriminados por escalonador, cliente e condições de mercado, e sugeriu testar os efeitos de diferentes mínimos. Os comentários levantaram dúvidas sobre a aplicação prática da regra, mas não indicaram que produtores tivessem usado essa estratégia na rede principal.
A proposta afirmava que Agave e Firedancer apontam para lotes de cerca de dois conjuntos FEC. No entanto, nem o texto nem os comentários de revisão apresentaram a distribuição das dimensões dos lotes atualmente produzidos. Sem essa informação, é difícil quantificar o efeito do mínimo na produção habitual de blocos ou até que ponto limitaria a capacidade dos produtores de ajustar os limites.
Latência e taxas de prioridade continuam em debate
Uma discussão em agosto levantou uma preocupação com a latência: se os validadores tivessem de esperar que um lote estivesse completo para o verificar, a capacidade do Firedancer de reproduzir dados à medida que chegam poderia ser afetada. Uma versão revista permitiria comparar e executar as transações de forma incremental, rejeitando o bloco se uma violação da ordem surgisse mais tarde. Ainda assim, quando o volume de transações é baixo, esperar que um lote alcance o mínimo de dois conjuntos FEC poderia atrasar a transmissão. Os materiais disponíveis não incluem medições de latência.
A proposta também não impediria um produtor de favorecer as próprias transações pagando uma taxa de prioridade a si mesmo. A SIMD-0649 assinala que as taxas de prioridade são pagas ao produtor do bloco, enquanto a parcela queimada da taxa base continua a ser um custo. Por isso, a verificação da ordem dentro dos lotes não impediria, por si só, tratamento preferencial, valor máximo extraível (MEV) ou derrapagem.
A SIMD-0649 foi encerrada em 25 de setembro; qualquer avanço dependerá de novas discussões e do apoio dos programadores dos clientes. Para os operadores de mercado, continuam por esclarecer quantas transações realmente concorrentes acabam no mesmo lote e se uma dimensão mínima alteraria o comportamento dos produtores. Até haver esses dados, a proposta oferece uma forma de verificar a ordem relativa dentro de um lote, mas o seu efeito sobre a execução efetiva permanece incerto.