test: check pool registration with a used VRF key

[mkoura]

A VRF key hash identifies the pool a block was forged by, so the ledger counts every registered one in psVRFKeyHashes and rejects a registration that reuses a key another pool holds. This registers a pool with the VRF key of a cluster pool and expects that rejection.

The rule arrived with protocol version 11
(hardforkConwayDisallowDuplicatedVRFKeys is pvMajor pv > 10), and a duplicated key is allowed below it, so the test skips there.

It is enforced against that map rather than against the registered pools, so it covers only the pools the map knows about. A pool that entered the ledger state through the genesis is not one of them: genesis staking injection fills psStakePools and records no VRF occurrence, and the map is otherwise populated only by the Conway PV11 hardfork and the Conway to Dijkstra translation. On a cluster that starts in Dijkstra at slot 0 neither runs, the map stays empty and the registration is accepted, so the test xfails on IntersectMBO/cardano-ledger#6102.

That makes the test conclusive only while the key is unclaimed: the registration its failure mode creates is itself recorded, so a run against the same instance while that pool still exists is rejected and would pass for a reason that has nothing to do with the genesis gap. POOLREAP drops the occurrence again when a pool retires, so the deregistration the test schedules puts the state back. No respin is asked for: pools that come and go are normal on a shared instance, this one has no stake and so never forges, and nothing in the suite keys anything on a VRF key hash.

It takes the VRF key of a cluster pool, which exists only on a local cluster, so it cannot be marked testnets - load_pools_data finds no node-pool* there and the lookup would raise. The leios marker selects it for the regression that starts in Dijkstra, which is the setup the xfail is about.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Shared-cluster isolation, testnet skipping, cleanup timing, and contaminated-state handling remain unresolved.

Review effort: Lite
Findings: None

What changed in this PR

Adds a Leios regression test for duplicate VRF-key pool registration, with protocol gating, known ledger-6102 handling, and cleanup.

Changes:

• Tests registration using an existing cluster pool’s VRF key.
• Handles unsupported protocol versions and expected ledger behavior.
• Cleans up unexpectedly accepted registrations.

File	Description
cardano_node_tests/​tests/​test_pools.py	Adds duplicate VRF-key registration coverage and cleanup logic.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.