glamsterdam devnet 6#4371
Merged
Merged
Conversation
* Bump nim-web3 * Use targetGasLimit of engine API PayloadAttributesV4 * deprecate '--gas-limit' * Fix conf test
* Revert BAL workaround of delegated target in CALL* opcodes * Skip bal_call_revert_insufficient_funds.json in zkevm test * Fix bal tracker position in call opcode getCode * Skip bal_call_revert_insufficient_funds.json in txpool test
tersec
reviewed
Jun 30, 2026
kdeme
reviewed
Jul 1, 2026
* - tx_packer.nim — the packer now tracks the running encoded block size (seeded with a 1 KiB header/list-prefix allowance plus the exact withdrawals size) and skips any transaction that wouldn't fit before executing it, gated on Osaka+ to match the validator. Header, receipts, gas counters, and BAL now stay consistent with the body by construction. - tx_pool.nim — the truncation loop is gone; assembleBlock instead returns an error in the (now unreachable) case an oversized block is assembled, so an inconsistent block can never be shipped. * consider gas
* fix(txpool): reset vmState before every assembleBlock forkchoiceUpdated rebuilds the payload for the same slot (same timestamp) arbitrarily many times. assembleBlock only refreshed the packing vmState when the timestamp changed, so every rebuild after the first reused the previous pack's persisted ledger (tx nonces already bumped) and its stale per-block accumulators (blobGasUsed, gas counters) which vmExecInit never resets. On the rebuild every pooled tx failed the nonce check, leaving an empty body while the header still committed to the first pack's blobGasUsed — yielding a block every other client rejects as 'blob gas used mismatch (header N, calculated 0)'. Always reset the transaction environment at the start of assembleBlock. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(txpool): rebuilding a payload at the same timestamp stays consistent Regression test for the blob-gas mismatch: assembleBlock called twice at the same timestamp must produce a block whose header blobGasUsed matches the body and that survives re-execution, instead of an empty body with a stale header. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…es (#4409) * fix(engine): preserve withdrawals for V4 (Amsterdam) payload attributes setWithdrawals only copied withdrawals for PayloadAttributes V2/V3 and emptied them for every other version via an else branch. From Amsterdam, the CL drives block building via engine_forkchoiceUpdatedV4 (PayloadAttributesV4, version V4), which fell into that else and discarded the entire withdrawals list. The built payload then had an empty withdrawals root and was rejected by consensus clients as a withdrawals-root mismatch. Observed on glamsterdam-devnet-6: every block built by a nimbus-el proposer carrying a (builder-payment) withdrawal was rejected network-wide, stalling finality. Regular validator withdrawals would be affected identically. Handle the withdrawal-bearing versions explicitly with no else branch, so the case stays exhaustive and any future Version must be handled deliberately (the else is what allowed V4 to be dropped silently). 🤖 Generated with AI assistance Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(engine): tighten setWithdrawals range to V2..V4 Use Version.V2 .. Version.V4 instead of V2..V6 so Nim's case-exhaustiveness check catches any future Version additions explicitly rather than silently folding them into the withdrawal-copy branch. 🤖 Generated with AI assistance * fix(engine): add explicit raiseAssert arm for unreachable V5/V6 PayloadAttributes V5/V6 do not exist as PayloadAttributes variants but the Nim compiler requires exhaustive case coverage. Add an explicit raiseAssert arm so the exhaustiveness check is satisfied while making the impossibility visible to future readers. 🤖 Generated with AI assistance * test(engine): regression test for V4 payload attributes preserving withdrawals Covers the setWithdrawals fix: a PayloadAttributes with targetGasLimit (Version.V4) must keep its withdrawals through payload assembly rather than dropping them via the old `else` branch. Builds a V4 attributes value with a non-empty withdrawals list, runs it through generateExecutionBundle, and asserts the assembled payload still carries the withdrawals. 🤖 Generated with AI assistance Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(test): build txpool from env.chain for V4 withdrawals regression test TestEnv has no txPool field — setupEnv creates the pool locally and only stores com/server/client/chain. Construct BeaconEngineRef from a TxPoolRef built on env.chain (mirroring setupEnv) so tests/all_tests.nim compiles. Fixes CI: undeclared field 'txPool' for type TestEnv. 🤖 Generated with AI assistance --------- Co-authored-by: lodekeeper <lodekeeper@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* builds MUST start on forkchoiceState.headBlockHash * make passing the parentHash mandatory for block building & update tests
Contributor
Author
|
@bhartnett do you have any idea why The difference is in |
Contributor
Probably because the full BAL is passed in for all engine tests but the blockchain tests only supply the BAL for some. Parallel execution only runs when the BAL is supplied.
I'll have a look. |
Contributor
Author
I see. Okay. I will merge this branch, and we can continue development and bugfix on master branch. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.