Poniendo a prueba la afirmación de Rayls Sovereign sobre una tarifa base cero
Respuesta breve
Quería saber si la configuración documentada de Rayls Sovereign sin gas mantiene la tarifa base en cero indefinidamente. Según el cálculo estándar de EIP-1559 y los parámetros probados aquí, un bloque padre por encima del objetivo hace que la tarifa base del bloque hijo sea de 1 wei, y los bloques vacíos posteriores no la devuelven a cero. Una transacción con precio cero falla entonces el requisito de tarifa base. No he comprobado que Sovereign en producción utilice ese cálculo y ese conjunto de parámetros.
El código de ejecución de Axyl añade un detalle importante. La ruta de producción para resolver la tarifa llama a "compute_next_base_fee" cuando EIP-1559 está activo. Esa función llama a "calc_next_block_base_fee" y limita el resultado a un mínimo configurable mediante ".max(self.min_base_fee)". El envoltorio de la especificación de cadena establece por defecto este mínimo en "MIN_RAYLS_PROTOCOL_BASE_FEE", aunque su constructor permite usar otro valor.
La documentación de Sovereign indica que el modo sin gas usa un mínimo de cero, pero aún no he rastreado ese ajuste hasta la configuración de producción ni he verificado la implementación de la función de cálculo subyacente en esta ruta de código. Una medición de la cadena pública realizada por un lector sigue apuntando en contra de la regla básica por bloque: la tarifa se mantuvo exactamente en 48 gwei durante 300 bloques casi vacíos. Mis propias pruebas abarcan la especificación y los vectores publicados de la biblioteca Alloy, no una cadena Axyl en funcionamiento.
Qué intentaba averiguar
Muchas instituciones quieren un libro mayor donde transferir un token no cueste nada. Las transacciones gratuitas eliminan la necesidad de financiar las carteras de cada empleado con un activo para pagar tarifas. También eliminan la defensa habitual contra el spam: el precio. Por tanto, una cadena sin gas debe explicar cómo sigue sin cobrar gas y cómo sigue siendo utilizable.
Rayls Sovereign, el libro mayor gestionado por instituciones, ofrece un modo sin gas. La página de arquitectura (modificada el 22 de octubre de 2026) indica que el modo se establece en el génesis y no se puede cambiar después. Explica el motivo en una frase: dado que el cambio de la tarifa base de EIP-1559 es proporcional a la tarifa base del bloque padre, una tarifa de génesis de cero y un mínimo de cero «mantienen la tarifa base en cero indefinidamente».
Se trata de una afirmación matemática, así que intenté comprobar las matemáticas.
La frase se apoya en la palabra «proporcional». Consulté la especificación para comprobar si la proporcionalidad era toda la regla.
El código de Axyl muestra por qué importa el mínimo configurado. En "compute_next_base_fee", la tarifa actual se obtiene del encabezado del bloque padre, o se usa "self.min_base_fee" como valor alternativo si el bloque padre no tiene una tarifa base. Cuando EIP-1559 está activo, el código llama a "calc_next_block_base_fee" y luego aplica ".max(self.min_base_fee)". Por consiguiente, un mínimo de cero no impide por sí solo que el cálculo devuelva 1 wei. Que esto ocurra depende del cálculo subyacente y de sus parámetros. Por tanto, la explicación de la documentación sobre el mínimo de cero debe evaluarse teniendo en cuenta tanto la función de cálculo como la configuración real del modo sin gas.
Dónde se complicó el análisis
Hay que conciliar tres afirmaciones de Rayls sobre las tarifas base con la implementación. Las Especificaciones Técnicas de Axyl (25 de agosto de 2026) indican que las tarifas base se recalculan por bloque según la regla EIP-1559, con parámetros recalibrados en cada época. La descripción general del repositorio Axyl ("doc/index.md") indica que las tarifas base permanecen constantes dentro de una época y se ajustan en los límites entre épocas. La página Why Rayls? (24 de agosto de 2026) indica que las tarifas están vinculadas al USDC.
El código añade una cuarta prueba: cuando EIP-1559 está activo, "resolve_base_fee" llama a "RaylsChainSpec::compute_next_base_fee", que calcula una tarifa para el siguiente bloque y aplica un mínimo configurable. Esto confirma que existe una ruta de cálculo por bloque, pero no determina por sí solo si la lógica de épocas, un mínimo configurado u otro ajuste determina la tarifa en una red concreta. La configuración sin gas de Sovereign debe rastrearse por separado.
Las actualizaciones por bloque y las actualizaciones constantes dentro de una época deben conciliarse si describen el mismo modo y versión. Un objetivo de precios denominado en USDC podría coexistir con cualquiera de las dos. El envoltorio inspeccionado por sí solo no establece cómo interactúan estas políticas en Sovereign sin gas.
Qué dice la especificación
EIP-1559 calcula la siguiente tarifa base a partir del bloque padre. El objetivo de gas es el límite de gas del bloque dividido por un multiplicador de elasticidad de 2. Si el bloque padre usó exactamente el objetivo, la tarifa se mantiene. Si usó menos, la tarifa disminuye en una cantidad igual a la tarifa del bloque padre multiplicada por el déficit de uso, dividida por el objetivo y por 8. Si usó más, la tarifa aumenta según la misma expresión, con un mínimo: el aumento es de al menos 1 wei. La disminución no tiene ese mínimo. Una transacción solo es válida si su tarifa máxima por unidad de gas es al menos igual a la tarifa base del bloque.
Así que «proporcional» describe la disminución. El aumento tiene un mínimo de un wei que no depende de la tarifa del bloque padre, y precisamente ese mínimo se aplica cuando la tarifa del bloque padre es cero.
Qué probé
Transcribí la regla de actualización de la especificación a un breve script y lo ejecuté desde una tarifa base de cero, usando un límite de gas ilustrativo de 100 millones. Los bloques que usan como máximo el objetivo de 50 millones mantienen la tarifa en 0. Un bloque que usa los 100 millones completos la eleva a 1 wei. Después, 1,000 bloques vacíos la dejan en 1 wei, porque la disminución de una tarifa de 1 wei se redondea a cero. Una transacción con precio cero cumple la condición de precio de la tarifa base cuando esta es 0 y no la cumple cuando es 1 wei. Esta comparación no prueba los demás requisitos de validez. Desde 1 wei, unos 85 bloques consecutivos con uso máximo elevan el costo total de una transferencia de 21,000 unidades de gas por encima de un gwei.
Después comparé el script con el código. El README de Axyl indica que la capa de ejecución está basada en reth y alloy. En alloy-eips 2.5.0 (docs.rs, publicado el 23 de septiembre de 2026 y vinculado en Sources con su versión fijada), calc_next_block_base_fee suma el aumento en las líneas 123 a 131 con un comentario que dice «Ensure a minimum increase of 1». La prueba de la propia biblioteca, calculate_base_fee_success, en las líneas 207 a 237, incluye una tarifa base de 0 que, con un uso de gas superior al objetivo, produce 1; luego, 1 produce 2 y 2 produce 3. Los diez vectores de esa prueba aparecen en la tabla siguiente y en el script, que verifica cada uno y se ejecuta correctamente.
alloy-eips 2.5.0, src/eip1559/helpers.rs, prueba calculate_base_fee_success (elasticidad 2, denominador 8)
# tarifa base del bloque padre gas usado límite de gas objetivo siguiente tarifa base rama
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 disminución
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
Una entrada del registro de cambios afecta a esta función. Las notas de la versión de alloy incluyen «fix(eip1559): prevent divide-by-zero in next base fee calculation» (solicitud de incorporación de cambios 3951) en v2.0.5, publicada el 18 de mayo de 2026. Las notas de v2.5.0, fechadas el 23 de septiembre de 2026, no mencionan cambios en la tarifa base, y el código fuente de 2.5.0 incluye la corrección. La solicitud de incorporación de cambios la describe como una protección preventiva. En el código fuente consiste en dos retornos anticipados que devuelven la tarifa base del bloque padre sin modificar cuando el multiplicador de elasticidad o el denominador del cambio son cero, o cuando el límite de gas es inferior a la elasticidad, de modo que el objetivo se redondea a cero, además de tres pruebas de regresión en las líneas 367 a 387. No modifica las ramas de aumento ni de disminución, así que se mantiene el mínimo de un wei.
Ninguno de los diez vectores activa la protección, porque usan una elasticidad de 2, un denominador de 8 y límites de gas de al menos 2,000,000; el mismo módulo de pruebas repite las entradas 0, 1 y 2 con otros cuatro conjuntos de parámetros, que dan 1, 2 y 3 en cada caso. Mi script no contempla un caso con parámetros cero y produciría un error de división si el objetivo fuera cero, mientras que la biblioteca devuelve la tarifa del bloque padre.
Estos resultados tienen tres limitaciones. Primero, inspeccioné la ruta de producción de Axyl para resolver la tarifa y el envoltorio de la especificación de cadena, pero no he verificado la implementación completa de "calc_next_block_base_fee" ni he rastreado la configuración sin gas hasta el código que construye la especificación de cadena de producción. Segundo, el límite de gas de 100 millones de mi simulación es ilustrativo: no pude determinar el límite de gas de bloque de Sovereign ni confirmar los parámetros EIP-1559 configurados. Tercero, no he ejecutado el cálculo en un nodo Axyl activo ni he verificado el comportamiento de un libro mayor Sovereign sin gas en funcionamiento
Qué aporta la cadena pública
Un lector ejecutó un script de solo lectura mío contra el RPC de la cadena pública Rayls (ID de cadena 72957, versión del cliente 1.4.1); fue una única ejecución el 24 de octubre de 2026 a las 2:10 a. m. UTC. La cadena pública no es un libro mayor Sovereign sin gas, así que el resultado es pertinente para la lógica de tarifas de Axyl y no dice nada directamente sobre el modo sin gas.
En 300 bloques, la tarifa base se mantuvo exactamente en 48 gwei, incluso al cruzar el límite entre las épocas 176 y 177. El bloque con más actividad usó 113,967 unidades de gas de un límite de 500,000,000, por lo que todos los bloques quedaron muy por debajo del objetivo de 250,000,000 si el multiplicador de elasticidad es 2. Según una aproximación de bloques vacíos que comienza en 48 gwei, con elasticidad 2 y denominador 8, la regla estándar cae por debajo de 1 gwei después de 29 actualizaciones y finalmente se estabiliza en 7 wei. Esta aproximación no reproduce la secuencia real de consumo de gas del lector. Si los registros de bloques consecutivos proporcionados son precisos, son incompatibles con la actualización estándar por bloque con elasticidad 2 y denominador 8.
Varios mecanismos podrían producir una tarifa constante, entre ellos una actualización basada en épocas, un mínimo configurado u otra política personalizada. Una protección de biblioteca solo es pertinente si Axyl invoca esa función auxiliar con parámetros que la activen; no he confirmado ninguna de las dos cosas. Estas posibilidades no son exhaustivas. La constancia durante una época por sí sola mantendría el cero dentro de esa época, pero no demostraría que persiste al cruzar el límite entre épocas. Por lo tanto, la secuencia observada no permite identificar el mecanismo de la cadena pública ni determinar el comportamiento sin gas de Sovereign.
El límite de gas que pude encontrar
El único límite de gas que mencionan los documentos de Sovereign corresponde a una transacción. El código de ejecución también muestra que el límite de gas del siguiente bloque se toma del encabezado canónico del bloque padre, mientras que la tarifa base se resuelve por separado mediante "gas::resolve_base_fee". Esto significa que el límite de gas del bloque y el cálculo de la tarifa son entradas distintas para la construcción del bloque.
El límite fijo de gas de transacción de 5,000,000 del Backend no debe tratarse como el límite de gas del bloque ni usarse para inferir el objetivo de gas de EIP-1559. La página Integrating Rayls Sovereign (modificada el 6 de octubre de 2026) indica que el Backend opcional crea cada transacción con un límite de gas fijo de 5,000,000 y obtiene el precio del gas del RPC de la cadena. Ni esa página ni la página de arquitectura indican el límite de gas del bloque ni el multiplicador de elasticidad.
El detalle del Backend sigue siendo importante. Una transacción del Backend solicita el precio del gas a la cadena, por lo que sigue la tarifa vaya donde vaya. Se aplican entonces dos reglas estándar de validez. Esta es mi interpretación de las reglas habituales; ninguna página de Rayls las menciona. Primero, la tarifa máxima por unidad de gas de la transacción debe ser al menos igual a la tarifa base del bloque, por lo que una transacción con precio cero falla directamente en cuanto la tarifa base es de 1 wei, sea cual sea el saldo del remitente.
Segundo, el saldo del remitente debe cubrir el costo inicial, que equivale al límite de gas multiplicado por la tarifa máxima por unidad de gas, más cualquier valor transferido. Para el límite de gas de 5,000,000 del Backend a 1 wei, eso supone al menos 5,000,000 wei antes de transferir valor alguno, cantidad que una cuenta con saldo cero no puede cubrir ni siquiera con una transacción cuyo precio sea correcto. Besu documenta la desactivación de una comprobación del saldo en el grupo de transacciones para la configuración de gas gratuito. Ese ajuste de admisión no demuestra por sí mismo que la ejecución permita una transacción con tarifa positiva que, de otro modo, sería inasequible. No pude determinar si Axyl modifica alguna de estas capas.
Cómo resuelve Besu el mismo problema
La guía de gas gratuito de Besu (consultada el 25 de octubre de 2026) trata el funcionamiento sin gas como una configuración. Para una red que utilice London o una versión posterior, indica que el operador también debe habilitar zeroBaseFee en cada nodo, establecer el precio mínimo del gas en cero y desactivar la comprobación del saldo del grupo de transacciones para que se acepten remitentes sin saldo. Explica el motivo: London introdujo una tarifa base distinta de cero, lo que normalmente significa que las transacciones necesitan gas.
La diferencia.
Besu desactiva la tarifa base con un interruptor explícito e indica los demás ajustes que deben coincidir. La página de Rayls se basa en la aritmética y en un parámetro de tarifa mínima.
Por qué importa.
Ambas configuraciones y fórmulas se pueden probar. Besu menciona un interruptor explícito para el gas gratuito; la explicación de Rayls que revisé no identifica el comportamiento adicional necesario para mantener el cero con una carga superior al objetivo.
La contrapartida:
Besu requiere que todos los nodos tengan una configuración idéntica, y su guía advierte que un nodo con un precio mínimo del gas más alto descarta silenciosamente las transacciones con precio cero.
Rayls documenta el modo sin gas como una configuración fija desde el génesis. No se ha verificado si su implementación mantiene el cero bajo carga ni al cruzar los límites entre épocas.
Qué cambia en la práctica.
Un operador de Besu revisa una breve lista de comprobación. Un operador de Rayls debería inspeccionar el código de tarifas aplicable y probar una configuración sin gas registrada con una carga superior al objetivo y al cruzar un límite entre épocas antes de prometer que el gas será gratuito de forma permanente
Conclusión
El envoltorio inspeccionado aplica un mínimo a la tarifa calculada; establecer ese mínimo en cero no suprime un resultado positivo. EIP-1559 estándar produce un resultado de ese tipo después de un bloque padre con una carga superior al objetivo. Por lo tanto, la explicación de Rayls de que el cero se mantendrá para siempre requiere una justificación adicional de implementación o configuración. No se ha verificado si Sovereign en producción la proporciona. Para completar la comprobación se necesita una revisión fijada del código fuente, la función auxiliar y la configuración aplicables, y pruebas con una carga superior al objetivo y al cruzar un límite entre épocas.