Cardano-db-sync: Le dépôt après la retraite du pool devrait être dans le tableau des récompenses

Mais la table 'rewards' n'est pas la même que le changement d'adresse_enjeu... Si nous faisons cela, nous devrions également stocker dans cette table d'autres choses, comme les récompenses ITN (table 'reserve' pour le moment) par exemple

La seule autre façon d'obtenir ces dépôts avec les récompenses serait d'interroger la table de retrait du pool, si un pool connecté à cette adresse de participation a expiré à une époque donnée, et d'ajouter une valeur de 500000000 codée en dur aux récompenses si cette valeur n'a pas encore été retirés, ce qui nécessite encore une fois de calculer si les retraits ne sont pas supérieurs aux récompenses jusqu'à ce moment-là, et ainsi de suite, ce qui semble vraiment maladroit.

Cependant, je pense toujours que cela devrait être indiqué dans la base de données plus explicitement sans ces valeurs codées en dur et autres. Peut-être un autre tableau ? Ou une relation plus simple ?

Si je choisissais d'obtenir ces 500 ADA à partir de la table pool_retirement, si le pool a plusieurs propriétaires, comment pourrais-je savoir à quelle adresse de pieu ces 500 ADA ont été récompensés ?

si le pool a plusieurs propriétaires, comment puis-je savoir à quelle adresse de pieu ces 500 ADA ont été récompensés ?

le dépôt est retourné à l'adresse des récompenses (c'est toujours une pour une piscine), pas à l'adresse du propriétaire

le dépôt est retourné à l'adresse des récompenses (c'est toujours une pour une piscine), pas à l'adresse du propriétaire
C'est logique merci !

Ainsi, le dépôt d'un pool retiré sera retourné à l'adresse de récompense du pool qui est déclarée dans la table pool_update, n'est-ce pas ?

Je demande parce que j'ai l'exemple actuel qui m'embrouille:

SELECT SUM(amount) as reward, NULL as withdrawal
FROM reward
         LEFT JOIN stake_address sa on reward.addr_id = sa.id
WHERE sa.view = 'stake1u9rqg96sdsdrqshpx0x77jna40ws90drts2wks7vuy63dpqj6txws'
UNION
SELECT NULL, SUM(amount)
FROM withdrawal
         LEFT JOIN tx ON withdrawal.tx_id = tx.id
         LEFT JOIN block ON tx.block_id = block.id
         LEFT JOIN stake_address sa on withdrawal.addr_id = sa.id
WHERE sa.view = 'stake1u9rqg96sdsdrqshpx0x77jna40ws90drts2wks7vuy63dpqj6txws';

Cette requête nous donne le total des récompenses et le total des retraits d'un exemple d'adresse de mise. La différence entre ceux-ci est exactement de 500000000 lovelace. Bien sûr, cela pourrait être une coïncidence, mais c'est assez difficile à imaginer car il existe d'autres exemples comme celui-là. Supposons donc simplement qu'il s'agit d'un dépôt de pool retourné, alors cette adresse de mise doit apparaître comme adresse de récompense dans la table pool_update, n'est-ce pas ?

SELECT pool_retire.hash_id, sa.view FROM pool_retire
    LEFT JOIN pool_update pu ON pool_retire.hash_id = pu.hash_id
    LEFT JOIN stake_address sa on sa.id = pu.hash_id
WHERE sa.view = 'stake1u9rqg96sdsdrqshpx0x77jna40ws90drts2wks7vuy63dpqj6txws'

Mais cette requête ne donne aucun résultat. Ce que j'ai pu découvrir, c'est que l'adresse du pieu est un copropriétaire d'une piscine à la retraite (pool_hash_id = 8) ce qui m'a conduit à ma première question.

Je me demande juste comment je pourrais déterminer d'où viennent ces 500 ADA. Ce dépôt pourrait-il être lié à l'ITN ?

Ainsi, le dépôt d'un pool retiré sera retourné à l'adresse de récompense du pool qui est déclarée dans la table pool_update, n'est-ce pas ?

droit

Mais cette requête ne donne aucun résultat

sa.id != pu.hash_id -> sa.id = pu.reward_addr_id

Je me demande juste comment je pourrais déterminer d'où viennent ces 500 ADA. Ce dépôt pourrait-il être lié à l'ITN ?

Presque certainement pas.

Où en sommes-nous avec ce problème. On dirait qu'il y a eu un peu de va-et-vient. Voulez-vous me tenir au courant de l'état actuel des choses à ce sujet ?

Bien sûr, le problème a été un peu détourné.. Donc, rien n'a changé à propos de la question - le dépôt qui devrait revenir à l'adresse des récompenses après le retrait d'un pool n'est nulle part explicitement dans la base de données (par exemple, 500 ADA sont arrivés à l'époque 245). Mais vous devez vérifier la table de retraite de la piscine, si la piscine dont l'adresse du propriétaire est l'adresse de récompenses que vous recherchez, puis ajouter manuellement une valeur codée en dur de « 500 » aux récompenses de l'utilisateur SI ce montant de cette retraite exacte n'a pas été retiré encore. Ce qui me semble vraiment encombrant et j'ai proposé si cela pouvait aller dans le tableau des récompenses, ou ailleurs, mais explicitement.

le dépôt qui devrait revenir à l'adresse des récompenses après le retrait d'un pool n'est nulle part explicitement dans la base de données

Avez-vous un exemple d'adresse de réseau principal pour que je puisse enquêter ?

e11d227aefa4b773149170885aadba30aab3127cc611ddbc4999def61c / pieu1uywjy7h05jmhx9y3wzy94td6xz4txynuccgam0zfn800v8qq33z29

Vous avez une idée fausse sur le remboursement de l'acompte. Les remboursements de dépôt ne se retrouvent pas dans la table reward mais dans la table tx . Alors trouvons-le.

Pour l'adresse qui nous intéresse :

cexplorer=# select id, view, registered_tx_id from stake_address
               where view = 'stake1uywjy7h05jmhx9y3wzy94td6xz4txynuccgam0zfn800v8qq33z29' ;
  id  |                            view                             | registered_tx_id 
------+-------------------------------------------------------------+------------------
 2820 | stake1uywjy7h05jmhx9y3wzy94td6xz4txynuccgam0zfn800v8qq33z29 |          2420601

le champ id peut être différent selon les instances db-sync , mais le id sera utile pour cette exploration.

Un peu complexe, mais le remboursement peut être vu en utilisant :

cexplorer=# select stake_deregistration.id, stake_deregistration.addr_id, stake_deregistration.tx_id,
               tx.deposit, block.epoch_no from stake_deregistration
               inner join tx on tx.id = stake_deregistration.tx_id
               inner join block on block.id = tx.block_id
               where stake_deregistration.addr_id = 2820 ; 
 id  | addr_id |  tx_id  | deposit  | epoch_no 
-----+---------+---------+----------+----------
 730 |    2820 | 2842157 | -2000000 |      223

De même, l'enregistrement peut sembler utiliser :

cexplorer=# select stake_registration.id, stake_registration.addr_id, stake_registration.tx_id, tx.deposit,
               block.epoch_no from stake_registration inner join tx on tx.id = stake_registration.tx_id
               inner join block on block.id = tx.block_id
               where stake_registration.addr_id = 2820 ; 
  id   | addr_id |  tx_id  | deposit | epoch_no 
-------+---------+---------+---------+----------
  1649 |    2820 | 2421547 | 2000000 |      208
 86926 |    2820 | 2842177 | 2000000 |      223
(2 rows)

Je suppose que cette adresse de pieu était :

• enregistré à l'époque 208
• désenregistré à l'époque 223
• réenregistré à nouveau à l'époque 223.

Est-ce que tout cela a du sens ?

Cela a du sens pour l'enregistrement de pieu, mais je parlais de la retraite du pool. Et les 500 ADA qui devraient être retournés à l'adresse de récompense du propriétaire de la piscine.

Je ne pense toujours pas que cela remonte à l'adresse de récompense. Avez-vous un exemple d'une piscine en train d'être retirée?

La relation ou le fait qu'elle apparaisse quelque part dans la base de données est en fait ma demande de fonctionnalité, pas un bogue dans la version actuelle. Exemple de pool retiré : pool134dws3tyc7kphwl6gks26cm6l390554lns9lyatm3gkxs6dwj2z. L'adresse que j'ai envoyée plus tôt est son propriétaire

@erikd
De la spécification du

Page 21

Rappelons que les remboursements de retrait du pool de mises ne sont pas émis lorsqu'un certificat
le retrait est traité, mais à la limite d'époque pour laquelle le retrait est planifié.

Page 40

• La fonction poolRefunds est utilisée pour calculer le total des remboursements qui doivent être distribués
pour les pools de mises qui devraient se retirer. Notez que ce calcul prend un numéro de créneau correspondant au créneau de limite d'époque lorsque le calcul est effectué. Le retour
map mappe les clés de hachage de l'opérateur de pool sur les remboursements, qui seront finalement retournés au
compte de récompense enregistré.

@xdzurman Désolé pour ça :

La relation ou le fait qu'elle apparaisse quelque part dans la base de données est en fait ma demande de fonctionnalité,

Quelle est exactement la demande de fonctionnalité ?

@erikd Pour mettre le dépôt de pool (500 ADA) quelque part dans la base de données, après le retrait d'un pool. Actuellement, il ne peut pas être explicitement lié à l'adresse de récompense à laquelle il appartient.

Clôturant ceci en faveur de https://github.com/input-output-hk/cardano-db-sync/issues/474 .