Cardano-db-sync: Extraño desajuste entre la tabla de recompensas y la tabla de bloques

Esto es diferente de #361. Mirando el addr_id desde arriba:

cexplorer=# select * from delegation where addr_id = 92628 ;
 id | addr_id | cert_index | pool_hash_id | active_epoch_no | tx_id 
----+---------+------------+--------------+-----------------+-------
(0 rows)

Eso significa que este addr_id debe ser la dirección de recompensa para una actualización del grupo que es trivial de confirmar:

cexplorer=# select id, hash_id, pledge, margin, fixed_cost, active_epoch_no, reward_addr_id
              from pool_update where reward_addr_id = 92628 ;
  id  | hash_id | pledge | margin | fixed_cost | active_epoch_no | reward_addr_id 
------+---------+--------+--------+------------+-----------------+----------------
 4621 |    1245 |      0 |      1 |  340000000 |             218 |          92628
 4622 |    1246 |      0 |      1 |  340000000 |             218 |          92628
 4623 |    1247 |      0 |      1 |  340000000 |             218 |          92628
 4624 |    1248 |      0 |      1 |  340000000 |             218 |          92628
 4625 |    1249 |      0 |      1 |  340000000 |             218 |          92628
 4626 |    1250 |      0 |      1 |  340000000 |             218 |          92628
 5683 |    1245 |      0 |      1 |  340000000 |             224 |          92628
 5684 |    1246 |      0 |      1 |  340000000 |             224 |          92628
 5685 |    1247 |      0 |      1 |  340000000 |             224 |          92628
(9 rows)

Eso significa que esta dirección es la dirección de recompensa para varios grupos diferentes. Este debe ser el problema.

Esto es complicado. Supuse en mi cabeza que un solo stake_address solo podía delegar a un solo grupo. Si bien eso es cierto, se puede usar un solo stake_address como dirección de recompensa para más de un grupo.

En realidad es más complicado que eso. Si se usa stake_address como dirección de recompensa para dos grupos, el monto de la recompensa será la suma de las recompensas de cada grupo. Dado lo que tengo actualmente, no estoy seguro de que este huevo se pueda descifrar.

Esto no es solo complicado, es una completa lata de gusanos.

Después de conversar en Slack interno de IOHK con @JaredCorduan , me di cuenta de que el tratamiento de db-sync de los datos en cadena no era completamente correcto y que es posible que algunos SPO no hayan configurado sus grupos correctamente.

En primer lugar, si un grupo está registrado con una dirección de participación/recompensa que nunca se ha registrado como una dirección de participación, entonces, de acuerdo con el punto 3 de la sección 3.3.4 de las especificaciones de diseño de Shelley :

Si la dirección de la recompensa no está registrada, el operador del grupo de participación no podrá recibir recompensas. En ese caso, cualquier recompensa que se les deba se devuelve a las reservas (pero los miembros del grupo de apuestas seguirán recibiendo sus recompensas habituales).

En segundo lugar, si dos o más grupos están registrados con la misma dirección de participación/recompensa y dos o más grupos obtienen recompensas, entonces solo las recompensas para el primer grupo (¿cómo se determina "primero"?) van a la dirección y el resto va a las reservas/tesorería. Todavía no he encontrado la documentación adecuada sobre esto.

@erikd lo que te dije ayer fue incorrecto, disculpas. Revisé tanto la especificación como la implementación hoy, que están de acuerdo y funcionan de la siguiente manera.

Las cuentas de recompensa en los certificados del pool de apuestas:

• es necesario estar registrado
• NO necesita ser delegado

Además, si dos grupos enumeran una cuenta de recompensa común, la cuenta obtiene la suma de las recompensas.

Actualmente parece que la solución para esto está en una biblioteca de nivel inferior. @JaredCorduan lo está investigando.

No estoy seguro de lo que está pasando aquí. Las cosas han cambiado.

> select * from pool_hash
      where pool_hash.hash_raw = '\x964d8d35d91603e0dcfbc64891ee8ffeba0e503ca96bf627bc8bcb55' ;
  id  |                          hash_raw                          |                           view                           
------+------------------------------------------------------------+----------------------------------------------------------
 4626 | \x964d8d35d91603e0dcfbc64891ee8ffeba0e503ca96bf627bc8bcb55 | pool1jexc6dwezcp7ph8mceyfrm50l6aqu5pu494lvfau309422t9c6z

pero:

> select reward.* from pool_hash
      inner join reward on reward.pool_id = pool_hash.id
      where pool_hash.hash_raw = '\x964d8d35d91603e0dcfbc64891ee8ffeba0e503ca96bf627bc8bcb55' ;
 id | addr_id | amount | epoch_no | pool_id | block_id | type 
----+---------+--------+----------+---------+----------+------
(0 rows)

Estas consultas se ejecutaron en una base de datos que ejecutaba master en la confirmación f7ee30a245131255f816d6952ef6f0b938e61b94

Ah, pero la consulta de la tabla de recompensas (que devuelve cero entradas) es correcta:

> select block.block_no, slot_leader.pool_hash_id
              from block inner join slot_leader on block.slot_leader_id = slot_leader.id
              where pool_hash_id = 4626 ;
 block_no | pool_hash_id 
----------+--------------
(0 rows)

Por lo tanto, el extraño desajuste se ha ido y este ticket se puede cerrar.