erigontech / erigontech/erigon

IBS 2-Cache Phase 2b: Remove BalanceIncreaseSet from serial/parallel applyUpdates path

Open
#19,705 1 comment 0 reactions 0 assignees View on GitHub
tech debt reduction
Dominant language
Go
Stars
3.6k
Forks
1.5k
Avg merge
1d 15h
Merged PRs (30d)
463

Description

Part of #19623 — Rationalize IntraBlockState to a 2-Cache Model.
Depends on #19701 (Phase 2).
Required before #19703 (Phase 4) which removes the `balanceInc` map from IBS.

## Problem

`IntraBlockState.balanceInc` tracks balance increases that arrive without a prior account read (e.g. miner reward, block reward transfers). After a tx, `ibs.BalanceIncreaseSet()` exports these as a separate `map[Address]uint256.Int` that flows through:

```
ibs.BalanceIncreaseSet()
→ txtask.BalanceIncreaseSet (exec/txtask.go:571)
→ rs.applyUpdates(... balanceIncreases ...) (state/rw_v3.go:62)
→ SharedDomains
```

The parallel path (Phase 2, #19701) derives balance changes directly from `VersionedWrites`, making this separate map redundant. But it is still consumed by the **serial path** (`exec3_serial.go:521`) and by `rs.applyUpdates`. Phase 4 (#19703) removes `balanceInc` from IBS; this phase must happen first.

## Changes

- In `StateUpdatesFromVersionedWrites` (introduced in Phase 2), ensure `BalancePath` writes for all addresses — including miner/reward addresses — are captured. These currently arrive via `AddBalance` which goes through `balanceInc` when the account doesn't exist yet.
- Remove the `balanceIncreases map[accounts.Address]uint256.Int` parameter from `rs.applyUpdates()` in `rw_v3.go`. Merge its logic into the main account update loop (balance increases for accounts not otherwise modified become a synthesized `BalancePath` `VersionedWrite`).
- Update `exec3_serial.go` to stop passing `txTask.BalanceIncreaseSet` into the apply path.
- Remove `BalanceIncreaseSet` field from `TxTask` in `exec/txtask.go`.
- Remove `ibs.BalanceIncreaseSet()` method from `IntraBlockState` (or leave as dead stub until Phase 4 removes `balanceInc` entirely).

## New feature tests

- **`TestBalanceIncreaseInVersionedWrites`** — a tx that only increases a miner balance (no prior read) produces a `BalancePath` entry in `VersionedWrites` and is correctly reflected in `StateUpdates` from `StateUpdatesFromVersionedWrites`.
- **`TestApplyUpdatesNoBalanceIncreaseParam`** — drive `rs.applyUpdates` without a separate `balanceIncreases` arg; assert domains have correct final balances for reward-only accounts.

## Regression tests

- **`TestApplyVersionedWrites`** (existing) — must pass; miner/reward balance changes must be present.
- **`TestStateUpdatesEquivalence`** (Phase 2, un-skipped) — must still pass after this change.
- Run `go test ./execution/stagedsync/...` — serial executor produces identical state roots before and after.
- Run `go test ./execution/state/...` — no failures.
- `make test-short` passes.

## Files affected

- `execution/state/rw_v3.go` — remove `balanceIncreases` param from `applyUpdates`
- `execution/exec/txtask.go` — remove `BalanceIncreaseSet` field
- `execution/stagedsync/exec3_serial.go` — stop passing `BalanceIncreaseSet`
- `execution/stagedsync/exec3_parallel.go` — any remaining `BalanceIncreaseSet` references

## Acceptance criteria

- `BalanceIncreaseSet` field removed from `TxTask`
- `applyUpdates` takes no separate `balanceIncreases` parameter
- Serial and parallel paths produce identical state roots to before
- `make test-short` passes

Contributor guide

Open the contributing guide

Research direction

Start with execution/state/rw_v3.go, execution/exec/txtask.go, and execution/stagedsync/exec3_serial.go; trace applyUpdates and the BalanceIncreaseSet references through the serial and parallel paths. Run TestBalanceIncreaseInVersionedWrites, TestApplyUpdatesNoBalanceIncreaseParam, TestApplyVersionedWrites, and TestStateUpdatesEquivalence, then run the listed package tests and make test-short. Done means the separate field and parameter are removed and state roots remain equivalent.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
backend, blockchain
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.