Cardano-db-sync: Exemple de solde de compte

Merci d'avoir ouvert ce sujet en mon nom ! Juste pour clarifier un peu plus - il ne s'agit pas seulement du compte en soi, mais principalement du suivi reap quelque part dans la base de données afin qu'il puisse être facilement utilisé dans le calcul du solde du compte (qui est utilisé partout, par exemple pool live taille de la mise, mise en gage en direct du pool, etc.).

@1000101 Qu'est-ce que "récolter" ? Il n'y a pas de table ou de colonne dans db-sync appelée "reap".

Le solde du compte n'est pas négligeable.

Les adresses des époques Shelley et ultérieures ont deux composants; un justificatif de paiement et un justificatif de jalonnement. L'adresse de mise (par exemple stake1uyluup0rh6r2cc7kcw8nudqz990ezf5ltagxmw3u8deukvqwq7etq ) est dérivée de cette dernière. Cependant, il est possible de construire une adresse valide qui ne contient aucun identifiant de jalonnement.

Ainsi, bien qu'il soit possible d'obtenir le solde du compte pour une adresse de mise particulière, il n'y a aucun moyen d'obtenir le solde du compte d'un portefeuille à moins que chaque adresse de ce portefeuille n'inclue le même identifiant de mise.

@1000101 Qu'est-ce que "récolter" ? Il n'y a pas de table ou de colonne dans db-sync appelée "reap".

Oh, je suis désolé de ne pas avoir suffisamment précisé cela. Ce que je voulais dire est décrit dans https://github.com/input-output-hk/cardano-db-sync/issues/474 - c'est-à-dire que ce que je dis, c'est exactement qu'il n'y a pas de colonne pour cela mais ce serait génial s'il y en aurait.

Il n'existe actuellement aucun moyen de calculer facilement le solde d'un compte, lorsque ce compte a été utilisé lors de l'inscription au pool (en tant que compte de récompense) et que le pool a ensuite été retiré, récupérant ainsi le dépôt du pool. Le "paiement" du dépôt de pool est suivi dans dbsync, mais pas son "remboursement" lorsqu'un pool est retiré.

Je suis d'accord avec ça. Il existe également de nombreux cas extrêmes que chaque "utilisateur" de cardano-db-sync devrait gérer. Adalite et Yoroi sont confus lorsqu'ils voient un compte qui était auparavant un compte de récompense d'un pool à la retraite :

De plus, AFAIK, seul cardanoscan gère correctement les récompenses restantes, et ils n'utilisent pas db-sync.

Il devrait y avoir une relation simple qui serait mise à jour de la même manière que les récompenses sont automatiquement ajoutées. Prenons l'exemple d'un pool avec plusieurs désinscriptions , car c'est en fait assez courant et il est difficile de gérer le solde des récompenses de son compte propriétaire.

Il y a 9 certificats de retraite à elle

Et 15 certificats d'immatriculation

Il existe de nombreux cas extrêmes et de vagues règles de retraite annulées par de nouveaux certificats .

@erikd , si vous insistez sur un lien suffisant entre le dépôt de 500 tx et les retraites, comment écririez-vous une requête uniquement pour les dépôts retournés de l'un de ses comptes propriétaires - e127e9e94eaa9287680e877832700a1724255e9688609497e09a6c440f ? Sinon, pouvons-nous ajouter cela explicitement à db-sync ? Disons, en tant que nouvelle table, nommée pool_refunds , avec addr_id , montant (devrait actuellement être un multiple de 500) et epoch_no - afin que cela soit géré correctement et en un seul endroit.

Actuellement, db-sync extrait les données de l'état du grand livre et les insère dans la base de données. Il ignore certaines informations, mais ne fait aucune agrégation. Ce qui est inséré dans la base de données est simplement le reflet de ce que fournit l'état du grand livre.

Regardons le pool_hash.id pertinent :

> select id, hash_raw from pool_hash
    where hash_raw = '\x9c8e59ea7004a51f953642653d70a94d066359b9dd6e6416a5430ff3' ;
  id  |                          hash_raw                          
------+------------------------------------------------------------
 5022 | \x9c8e59ea7004a51f953642653d70a94d066359b9dd6e6416a5430ff3
(1 row)

Le pool a été enregistré (jointures supplémentaires pour les mettre dans l'ordre de block_no croissant) comme suit :

> select pool_update.id, hash_id, cert_index, active_epoch_no, block.block_no, block.epoch_no
    from pool_update
      inner join tx on tx.id = pool_update.registered_tx_id
      inner join block on tx.block_id = block.id
    where pool_update.hash_id = 5022
    order by block.block_no asc; 
  id  | hash_id | cert_index | active_epoch_no | block_no | epoch_no 
------+---------+------------+-----------------+----------+----------
 5022 |    5022 |          0 |             220 |  4717004 |      218
 5023 |    5022 |          0 |             220 |  4717035 |      218
 5024 |    5022 |          0 |             220 |  4717057 |      218
 5029 |    5022 |          0 |             220 |  4717140 |      218
 5030 |    5022 |          0 |             220 |  4717146 |      218
 5031 |    5022 |          0 |             220 |  4717169 |      218
 5032 |    5022 |          0 |             220 |  4717189 |      218
 5033 |    5022 |          0 |             220 |  4717216 |      218
 5034 |    5022 |          0 |             220 |  4717234 |      218
 5035 |    5022 |          0 |             220 |  4717241 |      218
 5037 |    5022 |          0 |             220 |  4717296 |      218
 5038 |    5022 |          0 |             220 |  4717425 |      218
 5061 |    5022 |          0 |             220 |  4721000 |      218
 5080 |    5022 |          0 |             221 |  4725394 |      219
 5081 |    5022 |          0 |             221 |  4725435 |      219
(15 rows)

et radié en :

> select pool_retire.id, hash_id, cert_index, retiring_epoch, block.block_no, block.epoch_no
    from pool_retire
      inner join tx on tx.id = pool_retire.announced_tx_id
      inner join block on tx.block_id = block.id
    where hash_id = 5022
    order by block.block_no asc ; 
 id  | hash_id | cert_index | retiring_epoch | block_no | epoch_no 
-----+---------+------------+----------------+----------+----------
 180 |    5022 |          0 |            219 |  4717395 |      218
 181 |    5022 |          0 |            219 |  4717397 |      218
 182 |    5022 |          0 |            219 |  4717401 |      218
 183 |    5022 |          0 |            219 |  4717403 |      218
 184 |    5022 |          0 |            219 |  4717405 |      218
 185 |    5022 |          0 |            219 |  4717417 |      218
 186 |    5022 |          0 |            219 |  4717430 |      218
 187 |    5022 |          0 |            220 |  4725366 |      219
 188 |    5022 |          0 |            220 |  4725717 |      219
(9 rows)

Mises à jour et désinscriptions :

action   | block_no
---------+------------
register | 4717004
update   | 4717035
update   | 4717057
update   | 4717140
update   | 4717146
update   | 4717169
update   | 4717189
update   | 4717216
update   | 4717234
update   | 4717241
update   | 4717296
retire   | 4717395
retire   | 4717397
retire   | 4717401
retire   | 4717403
retire   | 4717405
retire   | 4717417
update   | 4717425
retire   | 4717430
update   | 4721000
retire   | 4725366
update   | 4725394
update   | 4725435
retire   | 4725717

À suivre ....

C'est définitivement trop douloureux dans le cou. Parler avec des personnes chargées des spécifications du grand livre pour essayer de trouver une solution.

Parlé aux ledger-specs personnes qui ont suggéré un moyen rapide et sale de truquer pour l'instant en attendant une meilleure solution.

L'idée serait d'avoir quelque chose comme un tableau pool_registration_refund contenant l'adresse de mise et le montant.

Ce serait génial!

Parlé aux ledger-specs personnes qui ont suggéré un moyen rapide et sale de truquer pour l'instant en attendant une meilleure solution.

L'idée serait d'avoir quelque chose comme un tableau pool_registration_refund contenant l'adresse de mise et le montant.

Impressionnant! Je veux dire, nous avons une solution de contournement en place pour l'instant afin que nous n'atteignions pas le solde négatif partagé par @xdzurman , mais il s'agit d'environ 100 lignes de pas si jolies: tm : SQL qui doivent être calculées pour chaque compte. Cela aiderait certainement une tonne. Merci un millier !!!