History files `release/3.5` changed

[AskAlexSharov]

release/3.5 exec from 0 on mainnet.
With --persist.receipts --prune.include-commitment-history --snap.skip-state-snapshot-download
(i run on dev-bm-e3-ethmainnet-n0)

Changed (i see different hashes in mainnet.toml):
accounts.0-256.v (and .ef)
commitment.0-256.v (and .ef)
rcache.0-256.v (but .ef not changed)

All other history-files are not-changed.

[VBulikov]

yperbasis added Imp1 as Importance

[sudeepdino008]

This is an issue with the dao hack and attempted recovery ("sweeper") around it. v3.5 is adding some additional (harmless) entries in history, due to the way parallel execution handles this. It doesn't happen in v3.4 because it had serial execution.

block = 2,713,395
tx[0] cleans up 200 accounts (by CALL to the account, which according to EIP-161 would clear the empty accounts)
tx[13] is a similar tx later in the block

in serial execution,

• tx[0] calls tx.DomainDel; and tx[13] runs after this...it results in a no-op and IBS never calls DeleteAccount for them again => no duplicate history entry

in parallel execution:

• records VersionedWrite{SelfDestructPath: true} for tx[0] and tx[13], and so pushes nil history value.

---

• this also leads to additional entries in ef; and changes to commitment files.

• it's essentially pushing a nil value (with tx[13]) while nil was already there (on tx[0]) -- domain remains nil post-execution in both txs. Therefore it is harmless.

• Fix:

  • needs to fix parallel executor to detect conflict in this case
  • maybe need to add in DomainDel, if prevVal=nil, then skip (for AccountsDomain)

---

will check rcache too. But this doesn't look like a release blocker. cc: @yperbasis

[sudeepdino008]

the rcache issue was fixed recently in main and release/3.5 - #21662
For 0-256 range, it happens once.

the effect on eth_getBlockReceipts is that it would lead to cache miss and fallback to re-deriving rcache: #21249

[sudeepdino008]

• account/commitment: the additional entry is harmless. We should fix the issue in main and maybe cp to 3.5; but no need to regen snapshots
• rcache: the incorrect txIndex is rare and we have fallback in code to regen the receipt. I think we should regenerate this and remove the bandaid fix -- rawdb: ignore invalid receipt cache transaction indexes #21249 (ok to do in 3.6)

[sudeepdino008]

still need to regen files:

• 3.4: only rcache needed, parallel exec was not enabled there
• 3.5: is using 3.4 snapshotters; nothing to do here
• 3.6: need to fix accounts/commitment history/rcache
• regen 3.6 (rcache/receipt) snapshots - stagedsync: Fix logIndex reset and missing websocket notifications in parallel execution #22110