rpcdaemon,rulesconfig: align Bor engine selection

[JayeTurn]

Summary

• add a shared ActiveRulesName / UsesBorEngine decision in node/rulesconfig
• make rpcdaemon use that decision for local engine setup, remote engine setup, and Bor reader compatibility checks
• add a regression test covering the ValidatorContract gate

Problem

CreateRulesEngine only enables the Bor engine when the Bor config has a validator contract, but rpcdaemon was instantiating bor.NewRo whenever cc.Bor != nil. That let the RPC path drift away from the main engine factory and could enable Bor-only behavior on configs that should still behave like ethash.

Solution

Move the active consensus selection into node/rulesconfig and reuse it from rpcdaemon, so both paths apply the same Bor gate and fall back consistently when Bor support is only partially present.

[AskAlexSharov]

unfortunately we don't support bor/polygon anymore

[awskii]

Closing as overtaken by events rather than on the merits: Erigon has dropped Polygon support, tracked in #23503.

The diagnosis was right — rpcdaemon instantiated bor.NewRo whenever cc.Bor != nil while CreateRulesEngine additionally gated on the validator contract, so the two paths really could disagree. Consolidating that decision in node/rulesconfig was the correct shape.

Both sides of the mismatch are now gone: #23492 removed the Bor arm from CreateRulesEngine and the bor.NewRo construction from cmd/rpcdaemon/cli, and #23497 removes chain.Config.Bor and the BorConfig interface entirely, so there is no longer a gate to align. Sorry this sat open long enough to be outrun.

[awskii]

Reopening. I closed this on the Bor half of the mismatch; the shape you diagnosed outlived Polygon.

rpcdaemon still never consults node/rulesconfig. Both paths fall through to ethash.NewFaker() — cmd/rpcdaemon/cli/config.go:555 and :1012 — while CreateRulesEngine now checks the L2 engine registry first and panics on an unregistered one (node/rulesconfig/config.go:85-88). Same misconfiguration, opposite failure modes: loud in-node, silent L1 semantics for calls and traces in standalone rpcdaemon. ReadChainConfig restores only L2JSON and chain.Config.L2 is json:"-", so cc.L2 is nil there even for a correctly registered chain.

Your fix shape — move the active consensus selection into node/rulesconfig and reuse it from rpcdaemon — is still the right one. The gate to align is now the L2 engine registry instead of Bor's validator contract. // TODO(yperbasis): try to unify with CreateRulesEngine is still sitting at :995.

Also recorded independently by yperbasis on #22200 (2026-07-29).

[awskii]

To be concrete about where this lands now — the diff above is empty against current main. #23492 and #23497 deleted both Bor arms, so there is nothing left for this patch to change.

The defect you diagnosed did survive the removal, and it is item 1 of the gate in #22193.

What it looks like today, with Bor gone:

• cmd/rpcdaemon/cli/config.go:555 and :1012 still fall through to ethash.NewFaker()
• CreateRulesEngine now consults the L2 engine registry first and panics on an unregistered one (node/rulesconfig/config.go:85-88)
• so one misconfiguration has two failure modes: a loud panic in-node, and silent L1 semantics for calls and traces in standalone rpcdaemon
• ReadChainConfig restores only L2JSON, and chain.Config.L2 is json:"-" — so cc.L2 is nil in rpcdaemon even for a correctly registered chain. The resolver contract is part of the fix, not just the switch

Your shape holds unchanged: move the active consensus selection into node/rulesconfig and reuse it from rpcdaemon. The gate to align is the L2 engine registry rather than Bor's validator contract. // TODO(yperbasis): try to unify with CreateRulesEngine is still at :995, and yperbasis recorded the same divergence independently on #22200 (2026-07-29).

It closes standalone and blocks nothing else in that epic. Yours if you want it — say so and I will leave it alone; otherwise I will pick it up and credit the diagnosis here.