[sudeepdino008]

At some forks, BSC replaces the bytecode of its system contracts (0x1000, 0x1001, …). Without that, the state root diverges from the first fork block (e.g. Ramanujan, Chapel block 1,010,000).

• ParliaConfig.BlockAlloc: upgrade bytecode keyed by block number or timestamp, ported from bsc-erigon core/systemcontracts.
• bsc/chain/upgrades/chapel/<block-or-time>.json: the 19 Chapel upgrade sets, one file per fork, embedded and loaded into BlockAlloc.
• Parlia.Initialize applies the matching set via SetCode before the block's txs, so the serial, parallel and trace paths all see the new code.

[AskAlexSharov]

Reviewed the upgrade commit only, not the branch it is stacked on. One bug, one design point.

A missing parent header applies every past timestamp upgrade at once, in random order. parentTime stays 0 when chain.GetHeader returns nil, and consensuschain.Reader.GetHeader returns nil for a read error as much as for a missing header — it drops the error (h, _ := cr.blockReader.Header(...)). With parentTime == 0 the guard parentTime < numOrTime && header.Time >= numOrTime is true for every timestamp key already passed: all nine of Chapel's today. Thirteen addresses appear in more than one timestamp set — 0x1000 in seven of them — so the surviving bytecode is whichever set Go's randomised map iteration reaches last. That is a wrong state root that differs between two runs of the same node, from a transient read error on one header. parentTime is required input for the timestamp branch, so a nil parent should be an error, the way bsc-erigon takes lastBlockTime as a parameter from a caller that already holds the header. Sorting the keys before applying them removes the order dependence in the tail of this, and with it the only reason two matching entries in one block could resolve either way.

BlockAlloc map[string]any pushes both key parsing and alloc decoding to execution time. A bad key or a bad alloc in the chainspec surfaces as a block-execution error mid-sync rather than at startup, and DecodeGenesisAlloc re-marshals and re-parses the bytecode on every matching block. A typed field parsed once when the config loads turns both into a startup failure.

balance is 0x0 in all 83 entries, so applying only Code matches the data.

[domiwei]

The post-Feynman upgrade sets are applied at the wrong point in the block, and the Chapel Pasteur set is missing. Both are consensus deviations from upstream BSC and need a fix before merge; see the inline comments.

What matches upstream:

• The 19 upgrade sets match bsc-erigon's blockAlloc, and their contract code matches BSC geth.
• Block keys activate on the exact block, and time keys on the crossing parent.Time < T <= header.Time.
• Ramanujan through Plato, Kepler and Feynman are applied at block begin, as geth does.

Also inline: a nil-reader panic on an RPC path, and a stale note in bsc/PROGRESS.md.

Non-blocking, but please track it: the Prague EIP-2935 setup is missing for Parlia. Upstream sets the HistoryStorageAddress code and nonce 1 at the Prague block (geth core/systemcontracts/upgrade.go:1116-1121), and from that block on it writes the parent hash on every block (core/state_processor.go:113). This is outside the blockAlloc mechanism, but on Chapel it diverges at time 1740452880 (block 48,576,786), the same block as the Pascal set.

Non-blocking, but important: bsc/parlia has no tests for parseSystemContractUpgrades / upgradeSystemContracts. The only new test pins the key list and a digest of the data. Please add:

• a table test for block keys (block before, at and after), time keys (parent before, at and after T), one block that crosses two time keys, and the missing-parent error;
• an execution-level test for the post-Feynman application point relative to user and system txs.

The failing race-tests job (p2p/dnsdisc TestIteratorLinkUpdates) is in code that this diff does not touch.

[domiwei]

Blocker: post-Feynman upgrade sets are applied before the user transactions. Upstream applies them after the user transactions and before the system transactions.

BSC geth applies upgrades at block begin only while the parent is pre-Feynman: TryUpdateBuildInSystemContract(..., atBlockBegin=true) checks !config.IsFeynman(blockNumber, lastBlockTime) (core/systemcontracts/upgrade.go:1111-1126). Otherwise the upgrade runs from Parlia.Finalize (consensus/parlia/parlia.go:1423), after all user txs and before the system txs. bsc-erigon applies the later sets the same way, before the first system tx (execution/consensus/parlia/parlia.go:1023-1026, execution/exec3/state.go:250). It checks the block's own time instead of the parent time, so it differs from geth only at the Feynman block itself.

Affected Chapel keys and their fork blocks:

• 1711342800: block 38,876,951
• 1719986788: block 41,756,117
• 1724116996: block 43,132,201
• 1740452880: block 48,576,786
• 1744097580: block 49,791,365
• 1748243100: block 52,552,978
• 1762741500: block 71,859,053

Failing scenario: a user tx in one of these blocks calls, delegatecalls, or reads the code (EXTCODEHASH/EXTCODESIZE) of an upgraded contract, for example StakeHub 0x2002. Here it runs the new code; upstream runs the old code. Gas, receipts and the state root can then differ. The Feynman block itself and all block-keyed sets are correct, because their parent is pre-Feynman.

Context: I checked these seven Chapel blocks over public RPC. No user tx in them targets an upgraded address directly, and none emits logs from one. I could not check internal calls without trace access. So the existing Chapel history may not diverge, but the rule is still different from upstream, and any block with such a tx will diverge.

Suggested fix: keep block-begin application for sets whose parent is pre-Feynman. Apply the later sets after the last user tx and before the first system tx, or at block end when the block has no system tx. Finalize alone is too late, because here the system txs run as ordinary body txs.

[domiwei]

Blocker: the Chapel Pasteur set is missing.

chapel.json sets pasteurTime: 1784601000 (2026-07-21, already active). At that fork BSC geth replaces the code of StakeHub 0x2002 and Governor 0x2004:

• pasteurUpgrade[chapelNet] in core/systemcontracts/upgrade.go:1078-1092;
• applied at :1228-1229;
• code in core/systemcontracts/pasteur/chapel/.

This data is ported from bsc-erigon's blockAlloc, which predates Pasteur.

Failing scenario: at the first block with parent.Time < 1784601000 <= header.Time, upstream changes both code hashes and this branch does not. The state root diverges at that block, whatever transactions it contains.

Suggested fix: add bsc/chain/upgrades/chapel/1784601000.json with the two contracts from geth, and extend this key list. The parent of that block is post-Feynman, so it also falls under the timing point in bsc/parlia/parlia.go.

[domiwei]

From the first time key (1702972800) on, every call reaches this line, not only calls at fork boundaries.

Stateless witness verification passes a nil reader: execBlockStatelessly at rpc/jsonrpc/debug_execution_witness.go:2023. For a post-Kepler block that reaches this verification, the line calls a method on a nil interface and panics. The RPC server recovers the panic (rpc/service.go:229), so debug_executionWitness and eth_getWitness fail with "method handler crashed". Before this PR, Initialize did not use the reader.

Suggested fix: return an error instead of panicking when chain is nil. Then let the witness path supply the parent: result.headerByNumber already includes the parent header. Another option is to take the parent time from the caller, as bsc-erigon does with lastBlockTime.

A related point: eth_simulateV1 passes a DB-only reader (rpc/jsonrpc/eth_simulation.go:578), so from the second simulated block on it would hit "missing parent header". This is not reachable today, because Parlia's FinalizeAndAssemble still returns errNotSupported.

[domiwei]

nit: this paragraph is out of date:

• The sets now live in bsc/chain/upgrades/chapel/, not in chapel.json, which has "parlia": {}.
• "applied by bsc: apply Parlia system-contract upgrades at fork boundaries #24029" is not accurate yet: Pasteur is missing, and the post-Feynman sets run at block begin.

It would also help to list the missing Prague EIP-2935 setup here as a known gap.

[awskii]

Post-Feynman, upstream applies these upgrades in Finalize after user txs; here a user tx on a fork block runs the new code.

[awskii]

debug_executionWitness passes a nil chain reader and eth_simulateV1 can't resolve simulated parents, so both fail here.

[awskii]

Chapel Pasteur (StakeHub, Governor at 1784601000) has no upgrade set, and this key list locks the gap in.

[AskAlexSharov]

bsc/parlia/parlia.go:L211-241: shrink: the ensureParentTime closure and the parentTime/haveParentTime pair can be one lazy parent:

var parent *types.Header
...
if u.byTime {
	if header.Time < u.numOrTime {
		continue
	}
	if parent == nil {
		if parent = chain.GetHeader(header.ParentHash, number-1); parent == nil {
			return fmt.Errorf("parlia: missing parent header for block %d, cannot evaluate timestamp system-contract upgrade", number)
		}
	}
	if parent.Time >= u.numOrTime {
		continue
	}
}

net: -13 lines possible.