active_epoch_no field in pool_update table is incorrect for updates

[Craphtex]

The field active_epoch_no in pool_update table is always +2 from the epoch of the transaction registering the update, while in reality it should be +2 for registrations and +3 for other updates.

PoC code for all diffs being 2

SELECT
  (active_epoch_no - epoch_no) AS epoch_diff,
  count(*)
FROM pool_update
JOIN tx          ON tx.id    = pool_update.registered_tx_id
JOIN block       ON block.id = tx.block_id
GROUP BY (active_epoch_no - epoch_no);

 epoch_diff | count 
------------+-------
          2 | 16809
(1 row)

Example of pool updates for a pool where there should be a diff of +3 in several places but the diff is recorded as +2

SELECT
  view,
  active_epoch_no,
  epoch_no,
  (active_epoch_no - epoch_no) AS diff
FROM pool_update
JOIN pool_hash   ON pool_hash.id = pool_update.hash_id
JOIN tx          ON tx.id        = pool_update.registered_tx_id
JOIN block       ON block.id     = tx.block_id
WHERE view = 'pool1kjd9ff9u5ytq4atavv2dfsg3pvxqw8d50642pzmpn386zel0ka8'
ORDER BY pool_update.id;

                           view                           | active_epoch_no | epoch_no | diff 
----------------------------------------------------------+-----------------+----------+------
 pool1kjd9ff9u5ytq4atavv2dfsg3pvxqw8d50642pzmpn386zel0ka8 |             210 |      208 |    2
 pool1kjd9ff9u5ytq4atavv2dfsg3pvxqw8d50642pzmpn386zel0ka8 |             210 |      208 |    2
 pool1kjd9ff9u5ytq4atavv2dfsg3pvxqw8d50642pzmpn386zel0ka8 |             212 |      210 |    2
 pool1kjd9ff9u5ytq4atavv2dfsg3pvxqw8d50642pzmpn386zel0ka8 |             221 |      219 |    2
 pool1kjd9ff9u5ytq4atavv2dfsg3pvxqw8d50642pzmpn386zel0ka8 |             223 |      221 |    2
 pool1kjd9ff9u5ytq4atavv2dfsg3pvxqw8d50642pzmpn386zel0ka8 |             235 |      233 |    2
 pool1kjd9ff9u5ytq4atavv2dfsg3pvxqw8d50642pzmpn386zel0ka8 |             257 |      255 |    2
(7 rows)

[MarcelKlammer]

I also stumbled over that problem today.

I've updated both TITAN pools in the current epoch (e265), active_epoch_no is 267, which is fine for the margin change of one of the pools, but the pledge change will be active next epoch already (e266).

So it should be +1 for pledge changes and +2 for parameter changes, right?

[JaredCorduan]

All the pool parameters are handled in the same way, the pledge is no different.

[MarcelKlammer]

Pledge need to be met one epoch prio to be in the snapshot. So we have one epoch transition before we need to meet the newly registered pledge. That's why it looks like a wrong active epoch. As long as it stays consistent, it is fine.

[JaredCorduan]

It can be a bit hard describing the snapshots. I made this picture recently to try to help: IntersectMBO/cardano-ledger#2282

The pledge (just like cost and margin, and all the pool parameters) is effected by the re-registration logic.

[MarcelKlammer]

So the "active_epoch_no" is not really "active", but "snapshotted" or "locked_in"

[erikd]

The intention of active_epoch_no is for it to indicate that epoch in which the new pool parameters are active.

There is currently an off-by-one bug that will be fixed in the next release.

[MarcelKlammer]

So, the fix will see the current behavior:

re-register: e265
active_epoch_no: e267

change to

re-register: e265
active_epoch_no: e268

right?