Value of largeRequestsTimeout is set via --large-requests-timeout parameter when starting nimbus_beacon_node in trustedNodeSync mode.

[cmd0s]

Problem

In the nimbus_beacon_node operating in trustedNodeSync mode, the largeRequestsTimeout variable is currently hardcoded to 120 seconds. Before August 12, 2024, this value was 90 seconds. Despite the increase to 120 seconds, it remains insufficient for slower internet connections, such as 16 Mbps download speeds. This results in the nimbus_beacon_node failing to complete trustedNodeSync with the server due to timeouts. Increasing this timeout resolves the issue and allows synchronization to succeed.

---

Solution

Instead of proposing another fixed increase to the largeRequestsTimeout, this Pull Request introduces the ability to configure this value via a command-line parameter when starting nimbus_beacon_node.

• By default, if the parameter is not provided, the value remains at 120 seconds, ensuring backward compatibility.
• Optionally, users can specify the timeout using the --large-requests-timeout parameter (e.g., --large-requests-timeout=300) to set largeRequestsTimeout to 300 seconds.

This approach provides flexibility for various network conditions without requiring code changes or recompilation.

---

Additional Information

I lead the Web3Pi.io project, which enables users to easily and automatically set up a full Ethereum node on Raspberry Pi devices. This setup includes both execution and consensus clients, with Nimbus as the default consensus client.

Our users span many countries, sharing identical hardware and software configurations but differing in internet speeds. Users with slower connections have reported issues with trustedNodeSync, which I traced to the hardcoded timeout value causing synchronization failures. Increasing largeRequestsTimeout resolves the issue but requires editing the code and recompiling from source, which is impractical for many users.

The hardcoded timeout of 120 seconds is a limiting factor for some of my clients and prevents successful synchronization in suboptimal network conditions. Allowing this timeout to be configurable provides a scalable solution to this issue.

---

Request

I kindly request that this Pull Request be accepted to allow users to set largeRequestsTimeout via a parameter. Alternatively, I propose revisiting the hardcoded value and increasing it further. However, the configurable parameter approach is more flexible and better suited for diverse use cases.

Thank you for your consideration!