Cardano-db-sync: Décalage étrange entre la table des récompenses et la table des blocs

Ceci est différent de #361. En regardant le addr_id d'en haut :

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

Cela signifie que ce addr_id doit être l'adresse de récompense pour une mise à jour du pool, ce qui est trivial à confirmer :

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)

Cela signifie que cette adresse est l'adresse de récompense pour un certain nombre de pools différents. Cela doit être le problème.

C'est délicat. J'avais en tête l'hypothèse qu'un seul stake_address ne pouvait déléguer qu'à un seul pool. Bien que cela soit vrai, un seul stake_address peut être utilisé comme adresse de récompense pour plus d'un pool.

C'est en fait plus compliqué que ça. Si un stake_address est utilisé comme adresse de récompense pour deux pools, le montant de la récompense sera la somme des récompenses pour chaque pool. Compte tenu de ce que j'ai actuellement, je ne suis pas sûr que cet œuf puisse être déchiffré.

Ce n'est pas seulement délicat, c'est une boîte de Pandore complète.

Après avoir discuté sur Slack interne IOHK avec @JaredCorduan, j'ai réalisé que le traitement des données en chaîne par db-sync n'était pas tout à fait correct et que certains SPO n'avaient peut-être pas correctement configuré leurs pools.

Premièrement, si un pool est enregistré avec une adresse de mise/récompense qui elle-même n'a jamais été enregistrée comme adresse de mise, alors selon le point 3 de la section 3.3.4 de la Shelley Design Spec :

Si l'adresse de récompense n'est pas enregistrée, l'opérateur du pool de mise ne pourra pas recevoir de récompenses. Dans ce cas, toutes les récompenses qui leur seraient dues sont à la place renvoyées aux réserves (mais les membres du pool de mise obtiendraient toujours leurs récompenses habituelles).

Deuxièmement, si deux pools ou plus sont enregistrés avec la même adresse de mise/récompense et que deux pools ou plus gagnent des récompenses, seules les récompenses du premier pool (comment est-ce que le "premier" est-il déterminé ?) vont à l'adresse et tout le reste va à les réserves/trésorerie. Je n'ai pas encore trouvé de documentation appropriée à ce sujet.

@erikd ce que je vous ai dit hier était incorrect, excusez-moi. J'ai vérifié à la fois les spécifications et l'implémentation aujourd'hui, qui concordent et fonctionnent comme suit.

Les comptes de récompense dans les certificats de pool de mise :

• il faut être inscrit
• n'ont PAS besoin d'être délégués

De plus, si deux pools répertorient un compte de récompense commun, le compte reçoit la somme des récompenses.

Il semble actuellement que le correctif pour cela se trouve dans une bibliothèque de niveau inférieur. @JaredCorduan étudie la question.

Je ne sais pas ce qui se passe ici. Les choses ont changé.

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

mais:

> 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)

Ces requêtes ont été exécutées sur une base de données exécutant master au commit f7ee30a245131255f816d6952ef6f0b938e61b94

Ah, mais la requête de la table des récompenses (qui ne renvoie aucune entrée) est correcte :

> 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)

Ainsi, l'étrange décalage a disparu et ce ticket peut être fermé.