Skip to content

cp: cherry-pick batch from release/3.4 to main#20349

Merged
AskAlexSharov merged 7 commits intomainfrom
alex/cp_34_to_main_batch
Apr 6, 2026
Merged

cp: cherry-pick batch from release/3.4 to main#20349
AskAlexSharov merged 7 commits intomainfrom
alex/cp_34_to_main_batch

Conversation

@AskAlexSharov
Copy link
Copy Markdown
Collaborator

@AskAlexSharov AskAlexSharov commented Apr 6, 2026

Cherry-pick from release/3.4 to main.

Original PRs:

20 candidates checked total; 15 were already effectively on main.

AskAlexSharov and others added 4 commits April 6, 2026 14:45
…mem history reads (#20245) (#20262)

Cherry-pick of #20245 to `release/3.4`.

**Conflict resolution**: `execution/execmodule/executor.go` doesn't
exist in `release/3.4` (the `PipelineExecutor` abstraction was
introduced in `main` after the branch point). The equivalent change —
adding the `ERIGON_IN_MEM_HISTORY` env flag and wiring it to
`SetInMemHistoryReads` — was applied to
`execution/stagedsync/stageloop/stageloop.go` which is the relevant call
site in `release/3.4`.
problem: `sha.Read(h[:])` escaping to heap

- in RLP `func rlpHash` used new `sha.Sum256()` method - to prevent
heap-escaping caused by `sha.Read(h[:])` intereface-method:
```
if h, ok := sha.(*keccak.Hasher); ok {
	return h.Sum256()
}
```
- in `crypto.HashData()`: used new `keccak.Sum256()` method - which
doesn't use `sync.Pool` and doesn't alloc (`-20ns`)

```
  ┌─────────────────────────────────┬───────┬──────┬───────────┐
  │             Branch              │ ns/op │ B/op │ allocs/op │
  ├─────────────────────────────────┼───────┼──────┼───────────┤
  │ release/3.4 (pool + Read(h[:])) │ 272   │ 32   │ 1         │
  ├─────────────────────────────────┼───────┼──────┼───────────┤
  │ current (keccak.Sum256 direct)  │ 240   │ 0    │ 0         │
  └─────────────────────────────────┴───────┴──────┴───────────┘
```

---------

Co-authored-by: awskii <awskii@users.noreply.github.com>
Co-authored-by: Giulio rebuffo <giulio.rebuffo@gmail.com>
…ry (#20194)

## Summary

Backport of main commit `94a02c2bbb` to `release/3.4`, adapted for
r3.4's `*VersionedWrite` pointer map.

### The bug

`SetCode` writes three versioned entries (`CodePath`, `CodeHashPath`,
`CodeSizePath`) to `versionedWrites`, but `codeChange.revert()` only
cleaned up `CodePath` and `CodeHashPath`. The stale `CodeSizePath`
caused `GetCodeSize` to return the pre-revert value after a parent frame
reverted a child `CREATE`/`CREATE2`, making `EXTCODESIZE` report wrong
results.

**Concrete impact**: contracts checking `extcodesize(addr) > 0` after a
failed deployment see a non-zero size instead of 0, taking a different
code path and computing different gas. This produces arbitrary gas
under-counts that fail block validation with `"gas used by execution: X,
in header: Y"`.

**Observed in production**:
- Mainnet node (r3.4, build `cd4cc8e1`) stuck at block 24741565 with
`-61,560` gas diff
- Hoodi node previously exhibited similar pattern at block 2486302

### The fix

Add `CodeSizePath` cleanup to both branches of `codeChange.revert()`:
- `wasCommited == true`: `Delete(CodeSizePath)` alongside the existing
`Delete` calls
- `wasCommited == false`: restore `v.Val = len(ch.prevcode)` (r3.4 uses
`*VersionedWrite` pointers, not `UpdateVal`)

### Adaptation from main

Main uses `WriteSet.UpdateVal()` (added in the IBS 2-cache refactor
which is main-only). r3.4's `WriteSet` stores `*VersionedWrite`
pointers, so direct `v.Val = ...` assignment modifies the map entry in
place — consistent with all other `wasCommited == false` revert handlers
in r3.4's `journal.go`.

## Test plan
- [x] `make erigon` builds cleanly
- [x] `make lint` clean (0 issues)
- [ ] Mainnet node at block 24741565 unblocked after deploying this fix

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
@AskAlexSharov AskAlexSharov changed the title cp: paged writer lost amount of workers (from release/3.4) cp: cherry-pick batch from release/3.4 to main Apr 6, 2026
@AskAlexSharov AskAlexSharov enabled auto-merge April 6, 2026 09:51
@AskAlexSharov AskAlexSharov added this pull request to the merge queue Apr 6, 2026
Merged via the queue into main with commit 3229109 Apr 6, 2026
35 checks passed
@AskAlexSharov AskAlexSharov deleted the alex/cp_34_to_main_batch branch April 6, 2026 11:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants