chore: Review gas fee calculation and Anvil testnet config

[stubbsta]

Background

There are scenarios where the calculated value of the gas price to send with the RLN registration function call may become very large and possibly cause an overflow exception. We need to add a check for this and review our expectations of what the maximum gas price could potentially be (and how we simulate it in our tests).

Details

• GasPrice Calculation: https://github.com/waku-org/nwaku/blob/master/waku/waku_rln_relay/group_manager/on_chain/group_manager.nim#L230

  var gasPrice: int
  g.retryWrapper(gasPrice, "Failed to get gas price"):
    int(await ethRpc.provider.eth_gasPrice()) * 2

• RLN Register Function call: https://github.com/waku-org/nwaku/blob/master/waku/waku_rln_relay/group_manager/on_chain/group_manager.nim#L242

  g.retryWrapper(txHash, "Failed to register the member"):
    await wakuRlnContract
    .register(idCommitment, userMessageLimit.stuint(32), idCommitmentsToErase)
    .send(gasPrice = gasPrice)

There are 2 factors contributing to this issue:

1. The calculated value is assigned to an int64, but the type returned by the gasPrice call ( ethRpc.provider.eth_gasPrice()) is uint64
   Gas prices are not expected to ever be so large to cause an overflow.
2. The gas prices from our test environment is much larger than expected and we need to understand why.

Acceptance criteria

• check for overflow when casting from uint64 to int64
• configure test environment to be as close to realistic as possible

[stubbsta]

The overflow error was first observed during DST testing, details are here: https://www.notion.so/RLN-issues-29d8f96fb65c8041967be722d496b4c0#29d8f96fb65c8079ae97d41c27f35263

The gas price doubles each time the registration function is called and around iteration 33, this causes the overflow error.
The scenario tested here is not expected to necessarily happen in real world applications, but it has pointed out possible test net config issues.

This issue was replicated on the waku-simulator when using the latest foundry anvil release at the time (nightly-12be76ff47ae0f4fe1a18b74a47e5f0611bab5a0).
Anvil config:

          - "--host"
          - "0.0.0.0"
          - "--port"
          - "8545"
          - "--chain-id"
          - "59141"
          - "--gas-limit"
          - "1000000000000000"
          - "--gas-price"
          - "1"
          - "--balance"
          - "1000000000000000"
          - "--mnemonic"
          - "test test test test test test test test test test test junk"

It was however not observed with an older foundry release (nightly-9b73e06e1fe376738b92ae081107620291d50188).

I think the problem comes in with the Foundry implementation of the EIP-1559 gas price calculation model
Before this the gas price was calculated as a constant and afterwards it is dynamic.

When configuring specific Anvil parameters to be more representative of the Linea Sepolia testnet the overflow error was not observed:

        --gas-limit=30000000
        --gas-price=7
        --base-fee=7

The gas price still doubles for the iterations, but it gets capped and resets to the starting value every few iterations.

Edit: The above fix did not actually fix anything, I had balance set to a much lower value, resulting in there not being enough funds to a registration later in the iteration and thus the gasPrice reset because of the failed transaction.

[stubbsta]

In summary: The Foundry Anvil gas price calculation was updated from being in a constant range to being more dynamic (they introduced the EIP-1559 gas price calculation model)
@fryorcraken @jm-clius @Ivansete-status @AlbertoSoutullo How should we configure Anvil in the nwaku tests, waku-simulator environment and DST testing environment for the best test results - whether the goal is for it to be realistic or efficient?

I'm leaning towards having a testnet representative of the Linea Sepolia testnet, but I don't fully understand the implications, should we ask someone from The Status Network to weigh in here?

[stubbsta]

The issue might not be completely explained by the implementation of EIP-1559, there have since been several other updates to the Anvil fees calculation https://github.com/foundry-rs/foundry/commits/master/crates/anvil/src/eth/fees.rs. I am having a look to better understand it all.

[AlbertoSoutullo]

In summary: The Foundry Anvil gas price calculation was updated from being in a constant range to being more dynamic (they introduced the EIP-1559 gas price calculation model) @fryorcraken @jm-clius @Ivansete-status @AlbertoSoutullo How should we configure Anvil in the nwaku tests, waku-simulator environment and DST testing environment for the best test results - whether the goal is for it to be realistic or efficient?

I'm leaning towards having a testnet representative of the Linea Sepolia testnet, but I don't fully understand the implications, should we ask someone from The Status Network to weigh in here?

Honestly, I don’t think I have much to add here. We’ll follow your recommended configuration since its implications are beyond our current scope and understanding of the potential effects.

[jm-clius]

I don't think I quite understand why the gas price doubles with each registration, but presumably this is somehow related to the growth of the tree and complexity of computing the root? Still, intuitively I would expect this to be more noticeable when the tree is small and then even out as the number of registrations increases.

Nevertheless, if we understand quite well why this happens in the test environment and not on Linea Sepolia, I would change the environment to be representative rather than change the implementation (as you suggested).

[stubbsta]

@Ivansete-status This waku-simulator branch can be used to replicate the overflow error:
https://github.com/waku-org/waku-simulator/tree/debug-gasprice-overflow

The issue was observed with v0.37.0-rc.4 and I created this PR to be able to see the exact gasPrice (#3636), use this image quay.io/wakuorg/nwaku-pr:3636
This PR also checks for an overflow and then sets the price to a value below the max possible for an int64.

.env parameters:

export NWAKU_IMAGE=quay.io/wakuorg/nwaku-pr:3636
export NUM_NWAKU_NODES=1
export TRAFFIC_DELAY_SECONDS=30
export MSG_SIZE_KBYTES=10
export PRIVATE_KEY=0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80
export ETH_FROM=0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266
export RLN_RELAY_EPOCH_SEC=600
export RLN_RELAY_MSG_LIMIT=100
export RLN_CONTRACT_REPO_COMMIT=e75ac913e579ad872f54b2225eec35d1de3d98b0
export MEMBERSHIPS_TO_GENERATE=35

One nwaku node service runs the /usr/bin/wakunode generateRlnKeystore command in a loop for the MEMBERSHIPS_TO_GENERATE number of times.

After attempting the 33rd iteration of this (using the v0.37.0-rc.4 image), this error is seen:

/app/vendor/nim-chronos/chronos/internal/asyncengine.nim(150) _ZN11asyncengine4pollE
DBG 2025-11-19 07:40:08.712+00:00 Received JSON-RPC response                 topics="JSONRPC-CLIENT" tid=80 file=client.nim:192 len=4 id=8
/app/vendor/nim-chronos/chronos/internal/asyncfutures.nim(371) _ZN12asyncfutures14futureContinueE3refIN7futures26FutureBasecolonObjectType_EE
/app/vendor/nim-chronos/chronos/internal/asyncmacro.nim(542) _ZN8register83register
/app/vendor/nimbus-build-system/vendor/Nim/lib/system/integerops.nim(15) raiseOverflow
/app/vendor/nimbus-build-system/vendor/Nim/lib/system/fatal.nim(53) _ZN6system8sysFatalE8typeDescIN10exceptions14OverflowDefectEE6string
/app/vendor/nimbus-build-system/vendor/Nim/lib/system/excpt.nim(349) _ZN6system18rawWriteStackTraceE3varI3seqIN6system15StackTraceEntryEEE
/app/vendor/nimbus-build-system/vendor/Nim/lib/system/stacktraces.nim(62) _ZN11stacktraces30auxWriteStackTraceWithOverrideE3varI3seqIN6system15StackTraceEntryEEE
Error: unhandled exception: over- or underflow [OverflowDefect]
/app/apps/wakunode2/wakunode2.nim(49) wakunode2
/app/tools/rln_keystore_generator/rln_keystore_generator.nim(78) _ZN22rln_keystore_generator22doRlnKeystoreGeneratorEN22rln_keystore_generator24RlnKeystoreGeneratorConfE
/app/vendor/nim-chronos/chronos/internal/asyncfutures.nim(1839) _ZN12asyncfutures7waitForE20InternalRaisesFutureI4void5tupleIN6system9ExceptionEEE
/app/vendor/nim-chronos/chronos/internal/asyncfutures.nim(624) _ZN12asyncfutures7pollForE20InternalRaisesFutureI4void5tupleIN6system9ExceptionEEE
/app/vendor/nim-chronos/chronos/internal/asyncengine.nim(150) _ZN11asyncengine4pollE
/app/vendor/nim-chronos/chronos/internal/asyncfutures.nim(371) _ZN12asyncfutures14futureContinueE3refIN7futures26FutureBasecolonObjectType_EE
/app/vendor/nim-chronos/chronos/internal/asyncmacro.nim(542) _ZN8register83register
/app/vendor/nimbus-build-system/vendor/Nim/lib/system/integerops.nim(15) raiseOverflow
/app/vendor/nimbus-build-system/vendor/Nim/lib/system/fatal.nim(53) _ZN6system8sysFatalE8typeDescIN10exceptions14OverflowDefectEE6string
/app/vendor/nimbus-build-system/vendor/Nim/lib/system/excpt.nim(349) _ZN6system18rawWriteStackTraceE3varI3seqIN6system15StackTraceEntryEEE
/app/vendor/nimbus-build-system/vendor/Nim/lib/system/stacktraces.nim(62) _ZN11stacktraces30auxWriteStackTraceWithOverrideE3varI3seqIN6system15StackTraceEntryEEE
Error: unhandled exception: over- or underflow [OverflowDefect]

[stubbsta]

Findings so far:

• There were one or more updates in Foundry Anvil that has effected how Anvil calculates gas price.
• --disable-min-priority-fee adding this argument to the Anvil config stops the gasPrice from doubling
• Still trying to identify the exact changes in Anvil to better understand why the fee doubling occurs.

Next steps:

• Update nwaku's install Anvil script to use a fixed version instead of downloading the latest and check that this is the version installed on the local machine
• Update the Anvil config used for tests in nwaku to use the --disable-min-priority-fee config (when I run the apps/benchmarksbenchmarks.nim test it fails due to gasPrice doubling - @darshankabariya do you know which version of Anvil you used to run this?)
• We still need to handle the overflow issue as it is a possibility with the unit conversion
• The approach of doubling the current gas price to prioritise the registration transaction is likely excessive and can be improved.
  (Consider using the maxFeePerGas and maxPriorityFeePerGas from the EIP-1559 update instead of the gasPrice - depends on web3 capability)