db, execution: drop Bor snapshots and the Bor block-reader interface methods

[awskii]

The Bor snapshot type, its retire/merge path and the two Bor-named methods on the generic block-reader interfaces existed only to carry Heimdall data. With nothing constructing them any more, this removes them, which takes db/ off the list of packages importing polygon/. Fifth in the Polygon removal series, branched off #23492 — review the last commit only.

Changes

• delete db/snapshotsync/freezeblocks/bor_snapshots.go
• BlockRetire loses its Heimdall and bridge stores, BorStore(), borSnapshots(), the Bor prune metric and the Bor-data-not-ready backoff; NewBlockRetire drops two parameters
• BlockReader loses its borSn field, BorSnapshots() and FrozenBorBlocks(); NewBlockReader takes one snapshot set instead of two
• remove FrozenBorBlocks and BorSnapshots from dbservices.FullBlockReader, FrozenBorBlocks from the engine-facing rules.ChainHeaderReader, and BorSnapshots from snapshotsync's reader interface, along with all seven implementations
• remotedbserver.NewKvServer drops its Bor snapshot parameter
• db/rawdb: ReadChainConfig now rejects a stored bor section instead of decoding it
• execution/stagedsync: drop the Bor branches from the snapshots stage, including the synchronous-indexing exception
• db/datadir: keep removing the legacy heimdall and polygon-bridge directories, by literal name now that the DB labels are on their way out

Notes

ReadChainConfig used to rehydrate Config.Bor from the stored bor JSON. Dropping that silently would let an existing Polygon chaindata load with Bor == nil and execute under the wrong consensus rules, so it now fails with a pointer to 0xPolygon/erigon. This is the second of the three rehydration sites; txnprovider/txpool is the last and goes with chain.Config.Bor.

The heimdall and polygon-bridge datadir cleanup is deliberately kept: anyone upgrading from a Polygon datadir still wants those directories removed.

The 15 kv.Bor* tables, the HeimdallDB / PolygonBridgeDB labels and snaptype.MinBorEnum are not touched here. polygon/heimdall and polygon/bridge are their only readers and polygon/heimdall pins the snapshot enum range, so they can only go in the same PR that deletes the tree. Removing them earlier would just mean editing code that is about to disappear.

The WitnessProcessing stage stays for the same reason: it reads kv.BorWitnesses.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[AskAlexSharov]

Review of the current head. The main issue: the new ReadChainConfig rejection in db/rawdb/accessors_metadata.go is a one-sided guard — the write path and the second reader do not agree with it.

Bugs

1. Write side still produces what the read side rejects — db/rawdb/accessors_metadata.go:63

WriteChainConfig still marshals cfg.Bor into BorJSON. Any code that commits a genesis with Config.Bor != nil (e.g. polygon/tests/helper/miner.go:56) writes a bor section into kv.ConfigTable that no later read can load — rawdb.ReadChainConfig returns the new error and db/fromdb/fromdb.go:40 turns it into a panic. The process bricks its own datadir on the first write. If a stored bor section is unsupported, the write path must refuse it too, or the marshalling block should go.

2. chain.GetConfig has no guard — execution/chain/chain_db.go:29

It decodes the same kv.ConfigTable row and returns a config with Bor == nil, BorJSON != nil. txnprovider/txpool/pool_db.go:172 calls it and then initBor (pool_db.go:138) rehydrates Bor, so the txpool happily applies Bor rules while rawdb.ReadChainConfig refuses the same row for the node. polygon/bridge/snapshot_integrity.go:29 gets the Bor == nil version with no rehydration at all. The guard belongs in the shared decode step, not in one of the two readers.

3. Stale caller guard swallows the new error — execution/state/genesiswrite/genesis_write.go:200

storedCfg, storedErr := rawdb.ReadChainConfig(tx, storedHash)
if storedErr != nil && newCfg.Bor == nil {
	return newCfg, nil, storedErr
}

With a Bor genesis the condition is false, the error is dropped, and storedCfg == nil wins: it logs "Found genesis block without chain config", calls WriteChainConfig(newCfg) and skips CheckCompatible. Before this change that error path was only reachable on malformed JSON; now it is reachable for well-formed data, so the newCfg.Bor == nil half should go in the same change.

4. The kept heimdall/polygon-bridge cleanup in reset is now unreachable — db/datadir/reset/reset.go:59

erigon snapshots reset on a Polygon datadir: getChainNameFromChainData (cmd/utils/app/reset-datadir.go:175) now gets the "carries a 'bor' section" error, chainNameErr is only warned, configChainName stays unset, and resetCliAction returns "chain flag not set and chain name not found in chaindata" before r.Run(). --chain bor-mainnet does not help either — snapcfg.KnownCfg then fails with "config for chain ... is not known". The PR body says anyone upgrading from a Polygon datadir still wants those directories removed, but this copy can no longer run.

5. Bor genesis silently falls through to ethash — execution/execmodule/execmoduletester/exec_module_tester.go:430

Dropping the case opt.genesis.Config.Bor != nil arm means a Bor genesis now matches TerminalTotalDifficultyPassed or the default and gets ethash.NewFaker(). The test then passes against the wrong consensus rules instead of failing — the same failure mode the ReadChainConfig change exists to prevent. An explicit error/panic here would match the fail-loud choice made in db/rawdb.

Leftovers

• git grep erigon/polygon -- db/ still hits db/snapshotsync/freezeblocks/dump_test.go:41-42 (polygon/bor/borcfg, polygon/chain) and db/snaptype/enum_registry_test.go:27 (polygon/heimdall), so "db/ no longer imports polygon/" does not hold for the test builds — the next PR that deletes polygon/ breaks these two packages.
• Three FrozenBorBlocks implementations survive with no declaration behind them: execution/tests/blockgen/chain_makers.go:707 (non-test file), execution/protocol/rules/merge/merge_test.go:79, and execution/vm/runtime/runtime_test.go:539 (that one has the wrong signature — no align bool — so it never satisfied the interface).
• AllTypes() (db/snapshotsync/freezeblocks/block_reader.go:386) is now exactly Snapshots().Types() and has zero call sites — only declarations in db/dbservices/interfaces.go:108 and db/snapshotsync/snapshotsync.go:192 plus four implementations. BorSnapshots() was removed from those same interfaces for being unused; this one can go the same way. If it stays, slices.Clone is the idiomatic form and keeps the nil-vs-empty result unchanged.
• Stale comment at db/snapshotsync/freezeblocks/block_snapshots.go:327 still documents PruneHeimdall, which this change removes from PruneAncientBlocks.
• db/datadir/dirs.go:418 replaces dbcfg.PolygonBridgeDB/dbcfg.HeimdallDB with literals, but those constants still exist and db/datadir/dirs_test.go:57-58 still asserts against them — two sources of truth for the same directory names.

Test

The new rejection has no test. db/rawdb/accessors_metadata_test.go already covers the sibling L2 round-trip with the same Write -> Read shape, so a small TestChainConfigBorRejected would pin the error that several callers turn into a panic.

[awskii]

Ran a 4-agent review over this PR (git diff origin/main...HEAD, 41 files) and verified @AskAlexSharov's points against the current head. Three findings of my own, all minor:

• db/snapshotsync/freezeblocks/block_snapshots.go:327 — the PruneAncientBlocks comment still names PruneHeimdall, whose call this PR deletes along with the bordb import.
• db/rawdb/accessors_metadata_test.go:65 — the new test's rationale says "chain.Config has no Bor field", but chain_config.go:130 still declares Bor BorConfig and WriteChainConfig still marshals it. The premise is only true two PRs later.
• execution/tests/blockgen/chain_makers.go:707 and execution/protocol/rules/merge/merge_test.go:79 — FrozenBorBlocks implementations left with no interface requiring them and no caller.

On the review above, point by point:

Bugs 1, 2, 3 — confirmed. WriteChainConfig (accessors_metadata.go:63-69) marshals cfg.Bor into BorJSON while ReadChainConfig rejects any non-nil BorJSON; chain.GetConfig (execution/chain/chain_db.go) plain-unmarshals the same row with no guard and txnprovider/txpool/pool_db.go:145 rehydrates cc.Bor from it; genesis_write.go:200's storedErr != nil && newCfg.Bor == nil drops the new error for a Bor genesis.

The qualifier: all three are gone by the end of the series. At #23497 the cfg.Bor marshal block, Config.Bor, BorConfig and initBor no longer exist. So they break bisect at this commit and at #23495, not the merged result.

Bug 4 — confirmed, and this one is durable. getChainNameFromChainData (cmd/utils/app/reset-datadir.go:175) reads through rawdb.ReadChainConfig, so on a Polygon datadir it now returns the rejection error; chainNameErr is only warned at line 78, configChainName stays unset, and resetCliAction bails before r.Run(). The heimdall/polygon-bridge cleanup kept at db/datadir/reset/reset.go:59 is therefore unreachable for exactly the datadirs it exists to clean. Still true at the tip of the series. Needs a decision: let that helper fall back to the raw chainName field, or drop the cleanup as dead.

Bug 5 — confirmed here, evaporates later. Dropping the Config.Bor != nil arm does let a Bor genesis fall through to ethash.NewFaker(). From #23497 chain.Config has no Bor field, so the case stops being expressible.

Test gap — already closed. TestChainConfigRejectsStoredBorSection and TestChainConfigAcceptsNullBorSection are in accessors_metadata_test.go as of 06:09Z, 15 minutes after the review.