:paume faciale:

J'ai regardé cela pendant un moment, puis @dmitrystas pense qu'elle montre. En vous inscrivant sur tx.id = stake_registration.tx_id et en obtenant ensuite le block.epoch_no de la transaction, vous obtenez l'époque à laquelle l'inscription/la désinscription de la mise se produit, mais pas quand elle est réellement active .

Pour la plupart des opérations liées au jalonnement, les actions (telles que les inscriptions, les augmentations du montant misé, etc.) qui se produisent à l'époque N deviennent actives à l'époque N + 2 .

Cela signifie que la première requête devrait en fait être :

cexplorer=# SELECT stake_registration.addr_id, block.epoch_no + 2 as epoch_no, block.time FROM stake_address 
              INNER JOIN stake_registration ON stake_registration.addr_id = stake_address.id 
              INNER JOIN tx ON tx.id = stake_registration.tx_id INNER JOIN block ON block.id = tx.block_id
              WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';
addr_id | epoch_no |        time         
---------+----------+---------------------
   38266 |      210 | 2020-08-01 07:45:51
   38266 |      235 | 2020-12-01 22:31:13

et le deuxième:

cexplorer=# SELECT stake_deregistration.addr_id, block.epoch_no + 2 as epoch_no, block.time FROM stake_address
              INNER JOIN stake_deregistration ON stake_deregistration.addr_id = stake_address.id
              INNER JOIN tx ON tx.id = stake_deregistration.tx_id INNER JOIN block ON block.id = tx.block_id
              WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';
 addr_id | epoch_no |        time         
---------+----------+---------------------
   38266 |      234 | 2020-12-01 18:25:59

@dmitrystas Est-ce que tout cela s'additionne? Cela aiderait-il d'ajouter une colonne active_epoch_no supplémentaire aux tables stake_registration et stake_deregistration comme j'ai la table delegation ?

@erikd Bonne journée. C'est le problème d'origine https://github.com/Emurgo/yoroi-frontend/issues/1832#issue -754776885
Peut-être pourrait être utile

Yoroi et Adalite montrent une mauvaise récompense 192 FAKE ADA mais en réalité c'est 0. Les 2 dernières récompenses sont retirées via adawallet.io (il n'utilise pas db-sync)

Brève description du problème par étapes :
1) Epoque 232 . Je retire les récompenses et annule l'enregistrement de la clé de staking en même temps. Les récompenses sont de 0. J'ai assez d'ADA pour les frais
2) Epoque 233 . Je devrais recevoir la première récompense restante si ma clé était enregistrée mais ce n'est pas le cas, mais Yoroi montre 192ADA reçue. Yoroi renvoie une erreur lorsque j'essaie de me retirer. D'autres portefeuilles qui n'utilisent pas db-sync montrent la récompense 0ADA
3) Epoque 233 . Je délègue à nouveau au même pool. La clé est enregistrée . Vraies récompenses 0. Yoroi récompense 192.
4) Epoque 234 . Je reçois la deuxième récompense restante 135ADA. Le véritable solde de récompense est de 135ADA.
Yoroi montre 327ADA (192+135). Je ne peux retirer aucune récompense via Yoroi. J'ai reçu l'erreur du serveur lors de l'envoi de la transaction.
5) Epoque 235 . Je reçois la dernière troisième récompense 145ADA. Le véritable solde de récompense est de 280 ADA (135+145).
Yoroi montre 472ADA (192+135+145) Je ne peux retirer aucune récompense via Yoroi J'ai l'erreur reçue du serveur lors de l'envoi de la transaction.
6) Epoque 235 . Je retire 280ADA en douceur via adawallet.io qui n'utilise pas db-syns et affiche correctement le solde de récompense 280ADA
7) Après le retrait des vraies récompenses de 280ADA (reste 0ADA), Yoroi affiche toujours le solde de la récompense 192ADA.

Yoroi affiche toujours un solde de récompense 192ADA.

Il y a au moins deux possibilités ;

• il y a un db-sync bug
• il y a un bug Yoroi

Je ne traite qu'avec db-sync . Cela signifie que les problèmes doivent m'être présentés comme des requêtes SQL et non comme des informations provenant de Yoroi.

Est-ce que stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 la clé d'intérêt ici ?

@erikd oui la clé de l'enjeu est l'enjeu1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86
Notez que non seulement Yoroi A CE BOGUE mais Adalite.io et adastat.net
Ceux-ci N'ONT PAS ce bug : cardanoscan.io et adawallet.io

Si certains portefeuilles en ligne ont ce bogue et d'autres pas, et que tous dépendent de db-sync il est très peu probable que le problème soit dans db-sync .

@erikd Mais adawallet.io n'utilise pas db-sync et affiche un solde de récompense correct (0ADA) et il me permet de retirer les dernières récompenses

Encore une fois, cela suggère qu'il s'agit d'un bogue Yoroi, pas d'un bogue db-sync .

Exodus a également rencontré ce bug.

Il s'agit certainement d'un bogue cardano-db-sync et non d'un bogue Yoroi étant donné que cela affecte non seulement Yoroi, mais également plusieurs autres utilisateurs de cardano-db-sync. cardanoscan et adawallet n'utilisent pas tous les deux cardano-db-sync, c'est pourquoi ils ne sont pas affectés.

Quels rapports cardano-db-sync

Voici la requête SQL qui donne l'historique des récompenses pour l'adresse fournie par @IlyaSofronov

select stake_address.hash_raw as "stakeAddress"
      , "totalReward".*

from stake_address

left outer join (
  SELECT addr_id, amount, epoch_no
  FROM reward
) as "totalReward" on stake_address.id = "totalReward".addr_id

where encode(stake_address.hash_raw, 'hex') = 'e1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde'

et donne le résultat suivant

 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 192969560 |      231
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236

Remarque : La somme de ces lignes est 3 765 04 402

État actuel (incorrect) de notre backend

{
    "remainingAmount": "193172340",
    "rewards": "3765004402",
    "withdrawals": "3571832062",
}

Vous pouvez voir que notre backend renvoie la somme des lignes db-sync pour la rewards (nous expliquerons pourquoi c'est le problème plus tard)

Vous pouvez également vérifier que le withdrawals est correct en additionnant les valeurs sur cardanoscan qui, nous le savons, ne sont pas affectées par ce bogue.

remainingAmount est juste rewards - withdrawals

Historique d'enregistrement pour le portefeuille

En regardant l'historique de cette clé de jalonnement , vous pouvez voir :

• Il a été radié à l'époque 232
• Il a été réenregistré à l'époque 233

État actuel du cardano-node

Selon mon instance de cardano-node, il s'agit de la valeur actuelle à l'intérieur de l'adresse de jalonnement

[
    {
        "address": "stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86",
        "delegation": "pool1kkfkdces5mdcyc9dn2hgg3463jggjvw3h89nejjarkz25uavaqu",
        "rewardAccountBalance": 202780
    }
]

Vous pouvez donc voir que selon le nœud, le solde du portefeuille est l'époque 235 + l'époque 236 (100702 + 102078 = 202780)

Alors, quel est le problème ?

En regardant cardanoscan, nous pouvons voir l'historique complet des retraits du portefeuille. Voyons à quoi correspond chaque retrait :

| Epoque retirée | Montant retiré | lignes d'époque db-sync incluses |
|-----------------|------------------|------------ -----------------|
| 228 | 2601.373144 | 211, 212, ..., 225, 226 |
| 230 | 371.141369 | 227, 228 |
| 232 | 317.641570 | 229, 230 |
| 234 | 135.711434 | 232 |
| 235 | 145.964545 | 233 |

CEPENDANT, vous pouvez voir que l'époque 231 dans cardano-db-sync (192969560) n'est incluse dans aucun d'entre eux !

Effectivement, si vous regardez notre réponse backend, "remainingAmount": "193172340", et que vous supprimez l'époque 231 incluse par erreur, vous obtenez 193172340 - 192969560 = 202780 qui est le résultat attendu de notre fullnode !

Conclusion

D'après mon enquête, il semble que cardano-db-sync inclue la ligne 231 dans le résultat de l'historique des récompenses, même si cela ne devrait pas.

J'ai simplifié la première requête et validé que j'obtiens les mêmes résultats (je l'ai fait).

État actuel (incorrect) de notre backend

Je préférerais obtenir toutes les informations d'une seule source donc :

cexplorer=# select sum (amount) from stake_address
        left outer join (SELECT addr_id, amount, epoch_no 
        FROM reward) as "totalReward" on stake_address.id = "totalReward".addr_id
        where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
    sum     
------------
 3765004402

et:

cexplorer=# select sum (amount) from withdrawal where addr_id = 38266;
    sum     
------------
 3571832062

qui sont tous deux d'accord avec vos chiffres.

Fait intéressant, 3571832062 + 192969560 + 202780 - 3765004402 où 3571832062 est la somme du retrait et 3765004402 est la somme de la récompense. Les autres valeurs sont ; 202780 qui est votre chiffre pour le solde des récompenses après les retraits et 192969560 sont les récompenses pour l'époque 231 .

cexplorer=# select stake_address.view as "stakeAddress", "totalReward".* from stake_address
     left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde'
     and epoch_no = 231 ;
                        stakeAddress                         | addr_id |  amount   | epoch_no 
-------------------------------------------------------------+---------+-----------+----------
 stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 |   38266 | 192969560 |      231

Alors, cette récompense pour l'époque 231 (que db-sync sort simplement de l'état du grand livre et insère dans la base de données sans aucun traitement supplémentaire) est-elle correcte ? Regardons l'historique d'enregistrement de pieu pour cette adresse de pieu :

cexplorer=# select stake_address.hash_raw, stake_registration.tx_id, block.epoch_no
    as tx_epoch_no, (block.epoch_no + 2) as active_epoch_no
    from stake_registration inner join stake_address on stake_registration.addr_id = stake_address.id 
    inner join tx on tx.id = stake_registration.tx_id inner join block on tx.block_id = block.id
    where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                           hash_raw                           |  tx_id  | tx_epoch_no | active_epoch_no 
--------------------------------------------------------------+---------+-------------+-----------------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde | 2449294 |         208 |             210
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde | 3103705 |         233 |             235
(2 rows)

cexplorer=# select stake_address.hash_raw, stake_deregistration.tx_id, block.epoch_no
    as tx_epoch_no, (block.epoch_no + 2) as active_epoch_no from stake_deregistration
    inner join stake_address on stake_deregistration.addr_id = stake_address.id
    inner join tx on tx.id = stake_deregistration.tx_id inner join block
    on tx.block_id = block.id
    where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                           hash_raw                           |  tx_id  | tx_epoch_no | active_epoch_no 
--------------------------------------------------------------+---------+-------------+-----------------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde | 3101670 |         232 |             234

Notez que pour l'enregistrement et le désenregistrement, j'ai inclus le tx_id (l'identifiant du tx qui contenait l'enregistrement/le désenregistrement), tx_epoch_no (l'époque à laquelle le tx a été inclus) et active_epoch_no (l'époque à laquelle l'enregistrement/désenregistrement devient actif).

En regardant les numéros d'époque actifs , l'enregistrement de la mise aurait dû être actif aux époques [210 .. 233] et [235 ..] . Cela correspond aux récompenses réelles pour cette adresse :

cexplorer=# select stake_address.hash_raw as "stakeAddress", "totalReward".* from stake_address
    left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                         stakeAddress                         | addr_id |  amount   | epoch_no 
--------------------------------------------------------------+---------+-----------+----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 192969560 |      231
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236
(25 rows)

C'est-à-dire qu'il y a des récompenses pour chaque époque sauf 234 .

Par conséquent, je pense que votre conclusion:

D'après mon enquête, il semble que cardano-db-sync inclue la ligne 231 dans le résultat de l'historique des récompenses, même si cela ne devrait pas.

est incorrect, cette adresse de pieu devrait avoir des récompenses pour l'époque 231 .

De plus, je pense que votre commentaire :

État actuel (incorrect) de notre backend
{
"remainingAmount": "193172340",
"récompenses": "3765004402",
"retraits": "3571832062",
}

est en fait correct. La différence entre la valeur des récompenses et la valeur de retrait est le solde actuel des récompenses non retirées.

est en fait correct. La différence entre la valeur des récompenses et la valeur de retrait est le solde actuel des récompenses non retirées.

Cela ne peut pas être le cas car nous savons que le nœud renvoie 202780 comme solde de récompense pour le compte et non 193172340

C'est-à-dire qu'il y a des récompenses pour chaque époque sauf 234.

Vous devez vous attendre à ce que deux époques soient manquantes :

1. L'époque où les récompenses ont été renvoyées aux réserves parce qu'elles n'avaient pas enregistré leur clé de mise
2. L'époque représentant l'écart d'une époque entre le moment où ils ont désenregistré leur clé et le moment où ils se sont réenregistrés

L'époque manquante 234 correspond à (2), et je crois que 231 correspond à (1) puisque 231 signifie qu'il devrait être visible dans le portefeuille de l'utilisateur à l'époque 233 qui est précisément l'époque pour laquelle nous nous attendons à avoir été perdus (1)

Vous devez vous attendre à ce que deux époques soient manquantes :

Pourquoi? D'après les opérations sur cette adresse de pieu :

| opération | tx_epoch_no | active_epoch_no |
|-------------------|----------------------|------- ---------|
| enregistrement | 208 | 210 |
| désinscription | 232 | 234 |
| enregistrement | 233 | 235 |

il n'a été désenregistré que pour une seule époque ( 234 ) et n'a reçu aucune récompense pour cette époque.

Pourquoi y aurait-il deux époques sans récompenses ? Je suis à peu près sûr que les deux cas que vous mentionnez sont en fait la même chose et donc une seule époque va sans récompense.

@SebastienGllmt dans Slack a dit :

la désinscription est particulière en ce qu'elle a lieu tout de suite, pas en 2 époques

Si la désinscription se fait immédiatement, celle-ci s'est produite en tx_epoch_no == 232 donc les récompenses pour les époques [231..234] seraient toutes perdues, pas seulement les récompenses pour 231.

Je pense que nous avons besoin de @JaredCorduan à ce sujet.

L'explication de @SebastienGllmt est cohérente avec les règles du grand livre.

C'est un peu philosophique "quand" un justificatif de pieu est désenregistré, mais je le formulerais comme ceci : la désenregistrement a lieu immédiatement, mais les récompenses sont retardées. Si un identifiant est désenregistré à l'époque e , il recevra des récompenses sur la limite e / e+1 (provenant de l'instantané pris sur la limite e-2 / e -1 ) et il sera également recevez des récompenses sur la limite e+1 / e+2 (provenant de l'instantané pris sur la limite e-1 / e ).

Cela ressemble à une certaine confusion avec la nomenclature.

À partir du PDV de dbs-ync : :

• tx_epoch_no : l'époque contenant les transactions du certificat d'inscription/désinscription.
• active_epoch_no : en gros tx_epoch_no + 2 , l'époque à laquelle les changements d'adresse de pieu deviennent actifs.
• epoch_no dans le tableau reward : l'époque réelle à laquelle les récompenses ont été gagnées.

si les informations d'identification de pieu étaient dans un certificat de désenregistrement d'une transaction à l'époque 232, alors elles ne seraient pas incluses dans l'instantané pris sur la limite 232/233. cela signifie que cela ne ferait pas partie de la mise à jour des récompenses qui est distribuée sur la limite 235/236. ce qui, selon les termes de

il convient de noter que des choses comme "désinscrit quand", "récompenses à" et "actif quand", etc., peuvent être déroutantes si nous ne sommes pas vraiment clairs. donc ce n'est pas clair pour moi avec qui je suis d'accord :)

Comme il semble y avoir de la confusion, j'ai fait une photo qui montre les deux époques manquantes attendues (db-sync 231 et db-sync 234)

Je pense que la confusion vient du fait que 231 n'est peut-être pas techniquement manquant - il se pourrait que l'état du grand livre considère simplement qu'il est distribué dans les réserves au lieu de l'utilisateur. Du point de vue de l'état du grand livre, les récompenses existent (distribuées aux réserves), mais du point de vue de l'utilisateur 231 ne devrait pas être inclus

J'ai fait une photo qui montre les deux époques manquantes attendues (db-sync 231 et db-sync 234)

Mais les récompenses réelles rapportées par db-sync sont :

cexplorer=# select stake_address.hash_raw as "stakeAddress", "totalReward".* from stake_address
    left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                         stakeAddress                         | addr_id |  amount   | epoch_no 
--------------------------------------------------------------+---------+-----------+----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 192969560 |      231
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236
(25 rows)

et seule l'époque 234 n'a aucune récompense. db-sync obtient le contenu de cette table à partir de l'état du grand livre et la seule chose que db-sync ajoute est la colonne epoch_no .

Votre schéma ne correspond pas à ce tableau, votre schéma est donc probablement incorrect. Il peut également y avoir un bug dans le node (en particulier le calcul du solde de la récompense d'adresse) mais je préférerais ne traiter qu'une seule variable ( db-sync ) pour le moment.

Dans votre diagramme, vous avez "récompenses livrées" barré pour l'époque 233, et Jared et moi pensons que c'est incorrect et que les récompenses devraient être livrées (car elles sont basées sur l'instantané au début de l'époque 231, pas l'état actuel de la chaine).

@SebastienGllmt dit :

Je pense que la confusion vient du fait que 231 n'est peut-être pas techniquement manquant - il se pourrait que l'état du grand livre considère simplement qu'il est distribué dans les réserves au lieu de l'utilisateur.

Mais le tableau rewards montre que la récompense est distribuée à l'adresse du pieu. S'il était distribué aux réserves, il ne figurerait pas dans ce tableau. db-sync reçoit ces informations de récompense sous forme de carte de l'adresse de mise au montant de la récompense. Maintenant, l'état du grand livre lui-même peut être erroné, mais il y a très peu de place pour que des erreurs se glissent une fois la carte récupérée à partir de l'état du grand livre.

Je me suis trompé quand j'ai dit :

de plus, si le certificat de (ré)enregistrement atterrissait dans une transaction à l'époque 233, alors ce serait la seule mise à jour de récompense qu'il raterait.

En fait, @SebastienGllmt avait tout à fait raison quand il a dit :

Vous devez vous attendre à ce que deux époques soient manquantes :

1. L'époque où les récompenses ont été renvoyées aux réserves parce qu'elles n'avaient pas enregistré leur clé de mise
2. L'époque représentant l'écart d'une époque entre le moment où ils ont désenregistré leur clé et le moment où ils se sont réenregistrés

En n'étant pas enregistré sur la limite d'époque 232/233, les informations d'identification de pieu à la fois :

• n'obtient pas les récompenses de la mise à jour appliquée sur la limite 232/233, et
• n'est pas inclus dans l'instantané de distribution des mises pris sur la limite 232/233 (afin qu'il ne reçoive pas les récompenses distribuées sur la limite 235/236).

Je peux deviner comment db-sync rapporte que les récompenses sont distribuées sur la limite 232/233 (ce qui n'est vraiment que la supposition de Figure 51: Reward Update Application dans la spécification formelle ). db-sync ne supprime probablement pas les informations d'identification non enregistrées.

L'image de @SebastienGllmt ci-dessus est superbe, mais notez qu'en fait, les flèches doivent s'étendre sur une autre époque pour tenir compte de la phase de production de blocs. par exemple, les récompenses de l'instantané pris sur la frontière 230/231 ne sont réellement remises qu'à la frontière 233/234.

Ok maintenant nous avons une explication à ce sujet. db-sync maintient le legder-state et retire les récompenses de l'époque sous forme de Map StakeAddress Coin qu'il insère dans la base de données. Cependant, cette carte contient des entrées StakeAddress qui ne sont pas valides et le legder-state supprimerait ces entrées, contribuant ainsi aux récompenses gagnées dans les réserves.

La solution consiste également à extraire l'ensemble des StakeAddress valides Map supprimant toutes les entrées qui n'apparaissent pas dans l'ensemble des StakeAddress valides.

Ce serait formidable si ces récompenses « fantômes » étaient mises dans un nouveau tableau comme « nondistributed_rewards » ou quelque chose comme ça. Cela nous permettra de calculer correctement la rentabilité du pool

@dmitrystas :

Ce serait formidable si ces récompenses « fantômes » étaient mises dans un nouveau tableau comme « nondistributed_rewards » ou quelque chose comme ça. Cela nous permettra de calculer correctement la rentabilité du pool.

Je peux voir que ces récompenses non distribuées (qui retournent dans les réserves) pourraient être utilisées pour calculer la rentabilité du sondage, mais je suis à peu près sûr que ce n'est pas le meilleur ou le moyen le plus simple de le calculer.

J'ai créé un ticket spécialement pour ce problème.

D'accord, j'ai une solution qui filtre les récompenses non valides de la liste des récompenses avant d'être insérées et en effet, il y a une récompense pour cette adresse à l'époque 231 .

Je dois maintenant modifier cela afin que ces récompenses "invalides" puissent être ajoutées à un tableau séparé.

Utilisation de la version de db-sync dans PR #469. la récompense pour l'adresse de mise \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde est correctement insérée dans la table orphaned_rewards :

cexplorer=# select stake_address.hash_raw, orphaned_reward.epoch_no, orphaned_reward.amount
         from orphaned_reward inner join stake_address on stake_address.id = orphaned_reward.addr_id
         where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde'; 
                           hash_raw                           | epoch_no |  amount   
--------------------------------------------------------------+----------+-----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |      231 | 192969560

et il est également absent du tableau des récompenses :

cexplorer=# select stake_address.hash_raw as "stakeAddress", "totalReward".* from stake_address
    left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                         stakeAddress                         | addr_id |  amount   | epoch_no 
--------------------------------------------------------------+---------+-----------+----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |        65 |      238
(25 rows)