[KaloyanTanev]

Raise the --target-gas-limit default for create cluster and create dkg from 60M to 200M, and add a charon run --proposer-gas-limit flag (default 200M) that sets the gas limit in the generated proposer-config and the expected proposer preferences target gas limit, so existing clusters move to 200M too.

category: misc
ticket: none

[codecov]

Codecov Report

❌ Patch coverage is 53.33333% with 14 lines in your changes missing coverage. Please review.
✅ Project coverage is 67.58%. Comparing base (957f2dd) to head (b1665dc).

Files with missing lines	Patch %	Lines
app/proposerconfig.go	45.00%	11 Missing ⚠️
app/app.go	0.00%	2 Missing ⚠️
cmd/run.go	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4795      +/-   ##
==========================================
- Coverage   67.59%   67.58%   -0.01%     
==========================================
  Files         254      254              
  Lines       33589    33569      -20     
==========================================
- Hits        22705    22689      -16     
+ Misses      10883    10879       -4     
  Partials        1        1              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[OisinKyne]

2 might be worth it. 1 is likely ignorable no one runs the early gloas builds. 4 is a given. 3 idk so long as its fairly stable i'm happy, so i think for that, sticking as close as possible to el/cl policy will keep things in agreement

1. Existing clusters don't move to 200M, despite the description.
   • proposer-config.json is only written when it's missing (#4784 kept "never modify"), so existing nodes keep their 60M (or lock) value and their VCs keep signing it.
   • The validator API now expects the flag's 200M, so every existing node logs a gas-limit mismatch warning on every preferences submission, plus the new startup warning.
   • Either rewrite the gas limit in existing files (charon owns this value now, so that's consistent), or correct the description and tell operators to delete the file.
2. Gas limit is now node-local, but it's part of the signed ProposerPreferences message.
   • If operators end up with different values (one deletes their file, one sets the flag differently), the VC partials don't aggregate.
   • Proposer preferences then fail, which means self-built blocks on every bid path. That was the #1 failure on Sepolia.
   • The flag says "must be identical on all nodes", but unlike builder URLs nothing checks it: it isn't in the peerinfo builder-config hash or compared anywhere.
   • Fold it into that hash, or at least warn when peers differ.
3. It drops the cluster-agreed value. The lock's TargetGasLimit, which operators signed, no longer feeds the validator API's check or the VC config.
   • Per-validator gas-limit overrides from signed registrations are also no longer carried into the VC config, but pre-gloas builder registrations still use them. So the pre- and post-fork values can differ.
   • Consider defaulting to the lock value and using the flag only as an explicit override.
4. Choosing 200M is a policy decision. Default-voting 200M across all of Obol's stake is a signal to the network, not just a client default. Worth confirming it matches what the EL and CL client teams ship for Glamsterdam before it becomes the default. I haven't verified their defaults.