Testando a afirmação de taxa-base zero da Rayls Sovereign em relação ao EIP-1559
Resposta breve
Eu queria saber se a configuração sem gás documentada da Rayls Sovereign mantém a taxa-base em zero indefinidamente. De acordo com o cálculo padrão do EIP-1559 e os parâmetros testados aqui, um bloco pai acima do alvo faz a taxa-base do bloco filho passar para 1 wei, e blocos vazios subsequentes não a reduzem a zero. Uma transação com preço zero falha, então, no requisito da taxa-base. Não confirmei que a versão de produção da Sovereign use esse cálculo e esse conjunto de parâmetros.
O código de execução do Axyl acrescenta um detalhe importante. O caminho de resolução de taxas de produção chama "compute_next_base_fee" quando o EIP-1559 está ativo. Essa função chama "calc_next_block_base_fee" e limita o resultado a um mínimo configurável usando ".max(self.min_base_fee)". Por padrão, o wrapper da especificação da cadeia define esse piso como "MIN_RAYLS_PROTOCOL_BASE_FEE", embora o builder permita outro valor.
A documentação do Sovereign diz que o modo sem gás usa um piso zero, mas ainda não rastreei essa configuração até a configuração de produção nem verifiquei a implementação da função de cálculo subjacente neste caminho de código. Uma medição da cadeia pública feita por um leitor ainda aponta para algo diferente da regra simples por bloco: a taxa permaneceu exatamente em 48 gwei ao longo de 300 blocos quase vazios. Meus próprios testes abrangem a especificação e os vetores publicados pela biblioteca Alloy, não uma cadeia Axyl em funcionamento.
O que eu estava tentando descobrir
Muitas instituições querem um livro-razão em que transferir um token não custe nada. Transações gratuitas eliminam a necessidade de abastecer a carteira de cada funcionário com um ativo usado para pagar taxas. Também eliminam a defesa habitual contra spam: o preço. Portanto, uma cadeia sem gás precisa explicar como continua sem gás e como permanece utilizável.
Rayls Sovereign, o livro-razão operado por instituições, oferece um modo sem gás. A página de arquitetura (modificada em 22 de outubro de 2026) diz que o modo é definido na gênese e não pode ser alterado depois. A justificativa é dada em uma frase: como a variação da taxa-base do EIP-1559 é proporcional à taxa-base do bloco pai, uma taxa zero na gênese e um piso zero "mantêm a taxa-base em zero indefinidamente."
Essa é uma afirmação matemática, então tentei conferir a matemática.
A frase se apoia na palavra proporcional. Consultei a especificação para verificar se proporcional descreve a regra inteira.
O código do Axyl mostra por que o piso configurado importa. Em "compute_next_base_fee", a taxa atual é obtida do cabeçalho do bloco pai, com fallback para "self.min_base_fee" se o bloco pai não tiver taxa-base. Quando o EIP-1559 está ativo, o código chama "calc_next_block_base_fee" e, em seguida, aplica ".max(self.min_base_fee)". Consequentemente, um mínimo igual a zero não impede, por si só, que o cálculo retorne 1 wei. Isso depende do cálculo subjacente e de seus parâmetros. Portanto, a explicação da documentação sobre o piso zero precisa ser avaliada considerando tanto a função de cálculo quanto a configuração real do modo sem gás.
Onde a investigação se complicou
Três afirmações da Rayls sobre taxas-base precisam ser conciliadas com a implementação. As Especificações Técnicas do Axyl (25 de agosto de 2026) dizem que as taxas-base são recalculadas por bloco segundo a regra EIP-1559, com seus parâmetros recalibrados a cada época. A visão geral do repositório Axyl ("doc/index.md") diz que as taxas-base permanecem constantes durante uma época e são ajustadas nos limites entre épocas. A página Why Rayls? (24 de agosto de 2026) diz que as taxas estão indexadas ao USDC.
O código acrescenta uma quarta evidência: quando o EIP-1559 está ativo, "resolve_base_fee" chama "RaylsChainSpec::compute_next_base_fee", que calcula a taxa do próximo bloco e aplica um piso mínimo configurável. Isso confirma que existe um caminho de cálculo por bloco, mas não estabelece, por si só, se a lógica por época, um piso configurado ou outra opção determina a taxa em uma rede específica. A configuração sem gás do Sovereign precisa ser rastreada separadamente.
A atualização por bloco e a atualização constante dentro da época precisam ser conciliadas se descrevem o mesmo modo e versão. Um objetivo de precificação em USDC poderia coexistir com qualquer uma delas. O wrapper analisado, por si só, não estabelece como essas políticas interagem no modo sem gás do Sovereign.
O que diz a especificação
O EIP-1559 calcula a próxima taxa-base a partir do bloco pai. O alvo de gás é o limite de gás do bloco dividido por um multiplicador de elasticidade de 2. Se o bloco pai usou exatamente o alvo, a taxa permanece igual. Se usou menos, a taxa diminui pelo produto da taxa do bloco pai pela diferença em relação ao alvo, dividido pelo alvo e por 8. Se usou mais, a taxa aumenta pela mesma expressão, com um limite mínimo: o aumento é de pelo menos 1 wei. A diminuição não tem esse limite. Uma transação só é válida se sua taxa máxima por gás for pelo menos igual à taxa-base do bloco.
Portanto, proporcional descreve a diminuição. O aumento tem um mínimo de um wei que não depende da taxa do bloco pai, e é exatamente nesse caso que esse mínimo se aplica: quando a taxa do bloco pai é zero.
O que testei
Transcrevi a regra de atualização da especificação para um script curto e o executei a partir de uma taxa-base zero, usando um limite de gás ilustrativo de 100 milhões. Blocos que usam até o alvo de 50 milhões mantêm a taxa em 0. Um bloco que usa os 100 milhões completos eleva a taxa para 1 wei. Depois disso, 1.000 blocos vazios mantêm a taxa em 1 wei, porque a diminuição aplicada a uma taxa de 1 wei arredonda para zero. Uma transação com preço zero satisfaz a condição de preço da taxa-base quando esta é 0 e falha quando ela é 1 wei. Essa comparação não testa os outros requisitos de validade da transação. A partir de 1 wei, cerca de 85 blocos consecutivos com utilização máxima elevam o custo de uma transferência de 21.000 unidades de gás para mais de um gwei no total.
Depois comparei o script com o código. O README do Axyl diz que a camada de execução é construída sobre reth e alloy. No alloy-eips 2.5.0 (docs.rs, publicado em 23 de setembro de 2026, vinculado em Sources na versão fixada), calc_next_block_base_fee adiciona o aumento nas linhas 123 a 131, com um comentário que diz "Ensure a minimum increase of 1." O próprio teste da biblioteca, calculate_base_fee_success, nas linhas 207 a 237, inclui uma taxa-base de 0 que, com uso de gás acima do alvo, resulta em 1; depois, 1 resulta em 2 e 2 resulta em 3. Todos os dez vetores desse teste estão na tabela abaixo e no script, que verifica cada um deles e é aprovado.
alloy-eips 2.5.0, src/eip1559/helpers.rs, teste calculate_base_fee_success (elasticidade 2, denominador 8)
# taxa-base do bloco pai gás usado limite de gás alvo próxima taxa-base ramo
0 1,000,000,000 10,000,000 10,000,000 5,000,000 1,125,000,000 aumento
1 1,000,000,000 10,000,000 12,000,000 6,000,000 1,083,333,333 aumento
2 1,000,000,000 10,000,000 14,000,000 7,000,000 1,053,571,428 aumento
3 1,072,671,875 9,000,000 10,000,000 5,000,000 1,179,939,062 aumento
4 1,059,263,476 10,001,000 14,000,000 7,000,000 1,116,028,649 aumento
5 1,049,238,967 0 2,000,000 1,000,000 918,084,097 diminuição
6 1,049,238,967 10,000,000 18,000,000 9,000,000 1,063,811,730 aumento
7 0 10,000,000 18,000,000 9,000,000 1 aumento
8 1 10,000,000 18,000,000 9,000,000 2 aumento
9 2 10,000,000 18,000,000 9,000,000 3 aumento
Uma entrada do changelog afeta esta função. As notas de lançamento do alloy listam "fix(eip1559): prevent divide-by-zero in next base fee calculation" (pull request 3951) em v2.0.5, lançado em 18 de maio de 2026. As notas da v2.5.0, datadas de 23 de setembro de 2026, não listam nenhuma alteração na taxa-base, e o código-fonte da 2.5.0 inclui a correção. O pull request a descreve como uma verificação defensiva. No código-fonte, ela consiste em dois retornos antecipados que devolvem a taxa-base do bloco pai sem alterações quando o multiplicador de elasticidade ou o denominador da variação é zero, ou quando o limite de gás é inferior à elasticidade, de modo que o alvo arredonda para zero, além de três testes de regressão nas linhas 367 a 387. Ela não altera os ramos de aumento nem de diminuição, portanto o limite mínimo de um wei continua valendo.
Nenhum dos dez vetores aciona a verificação, porque usam elasticidade 2, denominador 8 e limites de gás de pelo menos 2.000.000; o mesmo módulo de testes repete as entradas 0, 1 e 2 sob outros quatro conjuntos de parâmetros, resultando em 1, 2 e 3 em cada um. Meu script não inclui um caso com parâmetro zero e geraria um erro de divisão se o alvo fosse zero, situação em que a biblioteca devolve a taxa do bloco pai.
Há três limitações para estes resultados. Primeiro, examinei o caminho de resolução de taxas de produção do Axyl e o wrapper da especificação da cadeia, mas não verifiquei a implementação completa de "calc_next_block_base_fee" nem rastreei a configuração sem gás até o código que constrói a especificação da cadeia de produção. Segundo, o limite de gás de 100 milhões da minha simulação é ilustrativo: não consegui determinar o limite de gás dos blocos do Sovereign nem confirmar os parâmetros EIP-1559 configurados. Terceiro, não executei o cálculo em um nó Axyl ativo nem verifiquei o comportamento de um livro-razão Sovereign sem gás em funcionamento
O que a cadeia pública acrescenta
Um leitor executou um script meu, somente de leitura, contra o RPC da cadeia pública Rayls (ID da cadeia 72957, versão do cliente 1.4.1); foi uma única execução em 24 de outubro de 2026, às 2h10 UTC. A cadeia pública não é um livro-razão Sovereign sem gás, portanto o resultado é relevante para a lógica de taxas do Axyl e não diz nada diretamente sobre o modo sem gás.
Ao longo de 300 blocos, a taxa-base permaneceu exatamente em 48 gwei, inclusive na transição entre as épocas 176 e 177. O bloco mais movimentado usou 113.967 de gás, de um limite de 500.000.000, portanto todos os blocos ficaram bem abaixo do alvo de 250.000.000, se o multiplicador de elasticidade for 2. Para uma aproximação com blocos vazios, partindo de 48 gwei, usando elasticidade 2 e denominador 8, a regra padrão cai para menos de 1 gwei após 29 atualizações e acaba se estabilizando em 7 wei. Essa aproximação não reproduz a sequência real de uso de gás do leitor. Se os registros fornecidos de blocos consecutivos estiverem corretos, são incompatíveis com a atualização padrão por bloco usando elasticidade 2 e denominador 8.
Vários mecanismos poderiam produzir uma taxa constante, incluindo atualização por época, um mínimo configurado ou outra política personalizada. Uma proteção da biblioteca só é relevante se o Axyl chamar esse auxiliar com parâmetros que a acionem; não estabeleci nenhuma dessas condições. Essas possibilidades não são exaustivas. A constância dentro de uma época, por si só, preservaria o zero durante essa época, mas não demonstraria sua persistência na transição entre épocas. Portanto, a sequência observada não identifica o mecanismo da cadeia pública nem determina o comportamento sem gás do Sovereign.
O limite de gás que consegui encontrar
O único limite de gás indicado na documentação do Sovereign se refere a uma transação. O código de execução também mostra que o limite de gás do próximo bloco é obtido do cabeçalho canônico do bloco pai, enquanto a taxa-base é resolvida separadamente por meio de "gas::resolve_base_fee". Isso significa que o limite de gás do bloco e o cálculo da taxa são entradas distintas na construção do bloco.
O limite fixo de gás de transação do Backend, de 5.000.000, não deve ser tratado como o limite de gás do bloco nem usado para inferir o alvo de gás do EIP-1559. A página Integrating Rayls Sovereign (modificada em 6 de outubro de 2026) diz que o Backend opcional cria cada transação com um limite fixo de gás de 5.000.000 e obtém o preço do gás do RPC da cadeia. Nem essa página nem a página de arquitetura informam o limite de gás do bloco ou o multiplicador de elasticidade.
O detalhe do Backend ainda importa. Uma transação do Backend consulta o preço do gás na cadeia, então acompanha a taxa, seja qual for o seu valor. Aplicam-se, então, duas regras padrão de validade. Esta é a minha interpretação das regras usuais; nenhuma página da Rayls as declara. Primeiro, a taxa máxima por gás da transação precisa ser pelo menos igual à taxa-base do bloco, portanto uma transação com preço zero falha imediatamente assim que a taxa-base chega a 1 wei, independentemente do saldo do remetente.
Segundo, o saldo do remetente precisa cobrir o custo antecipado, que corresponde ao limite de gás multiplicado pela taxa máxima por gás, mais qualquer valor transferido. Para o limite de gás de 5.000.000 do Backend, a 1 wei, isso significa pelo menos 5.000.000 wei antes de qualquer transferência, valor que uma conta sem saldo não consegue cobrir, mesmo com uma transação corretamente precificada. A documentação do Besu explica como desativar uma verificação de saldo do pool de transações na configuração de gás gratuito. Essa configuração de admissão não demonstra, por si só, que a execução permite uma transação com taxa positiva que, de outra forma, seria inacessível. Não determinei se o Axyl modifica alguma dessas camadas.
Como o Besu resolve o mesmo problema
O guia de gás gratuito do Besu (consultado em 25 de outubro de 2026) trata a ausência de taxas como uma configuração. Para uma rede que use London ou uma versão posterior, diz que o operador também precisa ativar zeroBaseFee em cada nó, definir o preço mínimo do gás como zero e desativar a verificação de saldo do pool de transações para que remetentes sem saldo sejam aceitos. O guia explica o motivo: London introduziu uma taxa-base diferente de zero, o que normalmente significa que as transações precisam de gás.
A diferença.
O Besu desativa a taxa-base por meio de uma opção explícita e lista as outras configurações que precisam estar alinhadas. A página da Rayls se baseia na aritmética e em um parâmetro de piso.
Por que isso importa.
Ambas as configurações e fórmulas podem ser testadas. O Besu indica uma opção explícita para gás gratuito; a explicação analisada da Rayls não identifica o comportamento adicional necessário para manter a taxa em zero sob carga acima do alvo.
A desvantagem:
O Besu exige que todos os nós sejam configurados de forma idêntica, e seu guia alerta que um nó com preço mínimo do gás mais alto descarta silenciosamente transações com preço zero.
A Rayls documenta o modo sem gás como fixado na gênese. Ainda não foi verificado se sua implementação mantém a taxa em zero sob carga e durante as transições entre épocas.
O que muda na prática.
Um operador do Besu verifica uma lista curta. Um operador da Rayls deve inspecionar o código de taxas aplicável e testar uma configuração sem gás registrada sob carga acima do alvo e durante uma transição entre épocas antes de prometer ausência permanente de taxas
Conclusão
O wrapper analisado aplica um mínimo à taxa calculada; definir esse mínimo como zero não suprime um resultado positivo. O EIP-1559 padrão produz um resultado desse tipo após um bloco pai cuja utilização fica acima do alvo. Portanto, a explicação de que a taxa da Rayls permanece em zero para sempre exige uma justificativa adicional de implementação ou configuração. Ainda não foi verificado se a produção do Sovereign a fornece. Para concluir a verificação, são necessários uma revisão específica do código-fonte, o auxiliar e a configuração aplicáveis, além de testes sob carga acima do alvo e durante uma transição entre épocas.