Repository navigation
Conversation
Contracts above ~20KB of Python source are currently undeployable on
TestnetBradbury via any gas value, with no documentation explaining
why - eth_estimateGas doesn't warn about it, and the failure ("gas
limit too high") gives no revert reason.
Root cause, from the community investigation in genlayer-cli#419:
Bradbury enforces a fixed 16,777,216 (2^24) gas limit per transaction
- a zksync-os runtime chain config value (DEFAULT_MAX_TX_GAS_LIMIT),
added for EIP-7825 alignment. eth_estimateGas skips this check
(simulation only), so it can return a plausible-looking estimate for
a deployment that will actually be rejected at
eth_sendRawTransaction. A transaction signed close to the boundary
can also be accepted by the RPC and still run out of gas during
execution - same ceiling, hit from the other side (confirmed via
debug_traceTransaction: an out-of-gas revert five frames deep, no
reason string).
Added a "Known Limitations" section to the main deploying.mdx
overview page, right after the Networks Overview (where Bradbury is
already introduced), covering: the exact ceiling, why eth_estimateGas
doesn't catch it, the ~730 gas/byte practical size implication
(~20KB), workarounds (split into multiple contracts; don't trust
estimateGas alone near the boundary), and that this is a runtime
config value the chain admin can raise without a fork - not
something permanently baked in.
Credited the investigation (genlayer-cli#419) rather than presenting
this as newly discovered - the binary search, the block-explorer
trace back to the exact upgrade transaction that introduced the cap,
and the debug_traceTransaction confirmation were multi-person
community work I only helped narrow down, not root-caused solo.
Verified with the real @mdx-js/mdx compiler.
✅ Deploy Preview for genlayer-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe deploying guide adds a Known Limitations section about Bradbury’s per-transaction gas ceiling. It describes gas estimation and transaction submission behavior, Python contract size considerations, workarounds, and a community investigation. ChangesBradbury gas ceiling documentation
Priority: ⚪ Not assessed Estimated code review effort: 1 (Trivial) | ~3 minutes Change: Other Merge Risk: ⚪ Minimal · up to The new guidance explains a deployment limit and its workarounds. No issue identified here prevents merging. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Documents a real, currently-undocumented deployment blocker on TestnetBradbury: Python contracts above roughly 20KB of source are undeployable via any gas value, with no explanation anywhere in the docs, and
eth_estimateGasactively misleads by returning a plausible-looking (but doomed) estimate.Background
Root-caused through a multi-person community investigation in genlayer-cli#419:
zksync-osruntime chain config value (DEFAULT_MAX_TX_GAS_LIMIT), added for EIP-7825 alignment.eth_estimateGasskips this check entirely (simulation-only), so it can return an estimate like 28–32M for a deployment that will actually be rejected ateth_sendRawTransactionwithgas limit too highand no revert reason.debug_traceTransaction: an out-of-gas revert five frames deep, no reason string (explaining why the RPC gives no useful error either way).I did not root-cause this alone — crediting it explicitly in the doc. My own contribution was a systematic binary search narrowing the exact boundary (16,777,216 accepted, 16,777,217+ rejected); a separate contributor (
eudomar500, credited in the linked issue) traced the exact upgrade transaction on the block explorer that introduced the cap and confirmed the mechanism viadebug_traceTransaction.Change
Added a "Known Limitations" section to
deploying.mdx(the main deploy overview page), right after the existing Networks Overview section where Bradbury is already introduced. Covers:eth_estimateGasdoesn't catch itTesting
Verified the file compiles with the real
@mdx-js/mdxcompiler.Summary by CodeRabbit