:Gesichtshand:

Habe mir das eine Weile @dmitrystas denkt, dass es zeigt. Indem Sie tx.id = stake_registration.tx_id beitreten und dann block.epoch_no aus der Transaktion erhalten, erhalten Sie die Epoche, in der die Registrierung/Abmeldung des Einsatzes stattfindet, aber nicht, wenn sie tatsächlich aktiv ist .

Für die meisten Operationen im Zusammenhang mit Abstecken, Aktionen (wie Registrierungen, steigt in Höhe abgesteckt usw.) , die in der Epoche auftreten N wurde aktiv in Epoche N + 2 .

Das heißt, die erste Abfrage sollte eigentlich lauten:

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

und der zweite:

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 Passt das alles zusammen? Wäre es hilfreich, den Tabellen stake_registration und stake_deregistration eine zusätzliche Spalte active_epoch_no hinzuzufügen, wie ich die Tabelle delegation ?

@erikd Guten Tag. Das ist das ursprüngliche Problem https://github.com/Emurgo/yoroi-frontend/issues/1832#issue -754776885
Könnte vielleicht nützlich sein

Yoroi & Adalite zeigen eine falsche 192 FAKE ADA-Belohnung, aber tatsächlich ist es 0. Die letzten 2 Belohnungen werden über adawallet.io abgehoben (es verwendet kein db-sync)

Kurze Beschreibung des Problems in Schritten:
1) Epoche 232 . Ich ziehe Prämien ab und deregistriere gleichzeitig den Staking-Key . Belohnungen sind 0. Ich habe genug ADA für Gebühren
2) Epoche 233 . Ich sollte die erste verbleibende Belohnung erhalten, wenn mein Schlüssel registriert wurde, aber dies ist nicht der Fall, aber Yoroi zeigt 192ADA erhalten an. Yoroi gibt einen Fehler aus, wenn ich versuche, mich zurückzuziehen. Andere Wallets, die db-sync nicht verwenden, zeigen die Belohnung 0ADA
3) Epoche 233 . Ich delegiere wieder an denselben Pool. Schlüssel ist registriert . Wahre Belohnungen 0. Yoroi belohnt 192.
4) Epoche 234 . Ich erhalte die zweite verbleibende Belohnung 135ADA. Das wahre Belohnungsguthaben beträgt 135ADA.
Yoroi zeigt 327ADA (192+135). Ich kann keine Belohnung über Yoroi abheben. Ich habe den Fehler beim Senden der Transaktion vom Server erhalten.
5) Epoche 235 . Ich erhalte die letzte dritte Belohnung 145ADA. Das wahre Belohnungsguthaben beträgt 280ADA (135+145).
Yoroi zeigt 472ADA (192+135+145) Kann keine Belohnung über Yoroi abheben Ich habe den Fehler beim Senden der Transaktion vom Server erhalten.
6) Epoche 235 . Ich ziehe 280ADA reibungslos über adawallet.io ab, das kein db-syns verwendet und das korrekte Belohnungsguthaben 280ADA anzeigt
7) Nachdem die wahren Belohnungen von 280ADA abgezogen wurden (bleibt 0ADA) zeigt Yoroi immer noch das Belohnungsguthaben von 192ADA.

Yoroi zeigt immer noch das Belohnungsguthaben 192ADA an.

Es gibt mindestens zwei Möglichkeiten;

• es gibt einen db-sync Fehler
• es gibt einen Yoroi-Bug

Ich beschäftige mich nur mit db-sync . Das bedeutet, dass mir Probleme als SQL-Abfragen und nicht als Informationen von Yoroi präsentiert werden müssen.

Ist stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 hier der interessante Einsatzschlüssel?

@erikd ja der Stake Key ist Stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86
Beachten Sie, dass nicht nur Yoroi DEN BUG HAT, sondern auch Adalite.io und adastat.net
Diese haben diesen Fehler NICHT: cardanoscan.io und adawallet.io

Wenn einige Online-Wallets diesen Fehler haben und andere nicht und alle diese von db-sync abhängen, dann ist es sehr unwahrscheinlich, dass das Problem in db-sync .

@erikd Aber adawallet.io verwendet kein db-sync und zeigt das korrekte Belohnungsguthaben (0ADA) an und lässt mich die letzten Belohnungen abheben

Auch das deutet darauf hin, dass es sich um einen Yoroi-Fehler handelt, nicht um einen db-sync Fehler.

Exodus ist auch auf diesen Fehler gestoßen.

Dies ist definitiv ein cardano-db-sync-Fehler und kein Yoroi-Fehler, da dies nicht nur Yoroi, sondern auch mehrere andere Benutzer von cardano-db-sync betrifft. cardanoscan und adawallet verwenden beide kein cardano-db-sync, weshalb sie nicht betroffen sind.

Was cardano-db-sync meldet

Hier ist die SQL-Abfrage, die den Belohnungsverlauf für die von @IlyaSofronov bereitgestellte Adresse

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'

und liefert folgendes Ergebnis

 \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

Hinweis : Die Summe dieser Zeilen beträgt 3.765.004.402

Aktueller (falscher) Status aus unserem Backend

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

Sie können sehen, dass unser Backend die Summe der db-sync-Zeilen für den rewards zurückgibt (wir erklären später, warum dies das Problem ist).

Sie können auch überprüfen, ob der Betrag von withdrawals korrekt ist, indem Sie die Werte auf cardanoscan summieren, von dem wir wissen, dass es von diesem Fehler nicht betroffen ist.

remainingAmount ist nur rewards - withdrawals

Registrierungshistorie für das Wallet

Wenn Sie sich den Verlauf dieses Staking-Schlüssels ansehen, können Sie Folgendes sehen:

• Es wurde auf Epoche 232 abgemeldet
• Es wurde auf Epoche 233 neu registriert

Aktueller Zustand vom Cardano-Knoten

Laut meiner Cardano-Node-Instanz ist dies der aktuelle Wert innerhalb der Staking-Adresse

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

Sie können also sehen, dass das Guthaben des Wallets laut Knoten Epoche 235 + Epoche 236 beträgt (100702 + 102078 = 202780)

Was ist also das Problem?

Wenn wir uns

| Epoche zurückgezogen | Abgehobener Betrag | db-sync Epochenzeilen enthalten |
|-----------------|------------------|------------ -----------------|
| 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 |

JEDOCH können Sie die Epoche 231 in cardano-db-sync (192969560) sehen, die in keinem davon enthalten ist!

Wenn Sie sich unsere Backend-Antwort "remainingAmount": "193172340", ansehen und die fälschlicherweise enthaltene Epoche 231 entfernen, erhalten Sie 193172340 - 192969560 = 202780 was das erwartete Ergebnis von unserem Fullnode ist!

Fazit

Basierend auf meiner Untersuchung scheint cardano-db-sync die Zeile 231 in das Ergebnis des Belohnungsverlaufs aufzunehmen, obwohl dies nicht der Fall sein sollte.

Ich habe die erste Abfrage vereinfacht und bestätigt, dass ich die gleichen Ergebnisse erhalte (habe ich).

Aktueller (falscher) Status aus unserem Backend

Am liebsten hätte ich alle Informationen aus einer Hand, also:

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

und:

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

beides stimmt mit deinen Zahlen überein.

Interessanterweise ist 3571832062 + 192969560 + 202780 - 3765004402 wobei 3571832062 die Auszahlungssumme und 3765004402 die Belohnungssumme ist. Die anderen Werte sind; 202780 ist Ihre Zahl für das Prämienguthaben nach Auszahlungen und 192969560 ist die Prämie für die Epoche 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

Ist diese Belohnung für die Epoche 231 (die db-sync einfach aus dem Ledger-Zustand herauszieht und ohne zusätzliche Verarbeitung in die Datenbank einfügt) korrekt? Schauen wir uns die Pfahlregistrierungshistorie für diese Pfahladresse an:

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

Beachten Sie, dass ich sowohl für die Registrierung als auch für die Abmeldung die tx_id (die ID der Sendung, die die Registrierung/Abmeldung enthielt), tx_epoch_no (die Epoche, in der die Sendung enthalten war) angegeben habe und active_epoch_no (die Epoche, in der die An-/Abmeldung aktiv wird).

Betrachtet man die aktiven Epochennummern, sollte die Einsatzregistrierung in den Epochen [210 .. 233] und [235 ..] . Dies entspricht den tatsächlichen Belohnungen für diese 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)

Dh es gibt Belohnungen für jede Epoche außer 234 .

Daher finde ich dein Fazit:

Basierend auf meiner Untersuchung scheint cardano-db-sync die Zeile 231 in das Ergebnis des Belohnungsverlaufs aufzunehmen, obwohl dies nicht der Fall sein sollte.

falsch ist, sollte diese Einsatzadresse Belohnungen für die Epoche 231 .

Außerdem glaube ich, dass Ihr Kommentar:

Aktueller (falscher) Status aus unserem Backend
{
"verbleibender Betrag": "193172340",
"Belohnungen": "3765004402",
"Auszahlungen": "3571832062",
}

ist eigentlich richtig. Die Differenz zwischen dem Prämienwert und dem Auszahlungswert ist das aktuelle nicht abgezogene Prämienguthaben.

ist eigentlich richtig. Die Differenz zwischen dem Prämienwert und dem Auszahlungswert ist das aktuelle nicht abgezogene Prämienguthaben.

Das kann nicht der Fall sein, weil wir wissen, dass der Knoten 202780 als Belohnungssaldo für das Konto zurückgibt und nicht 193172340

Das heißt, es gibt Belohnungen für jede Epoche außer 234.

Sie sollten damit rechnen, dass zwei Epochen fehlen:

1. Die Epoche, in der die Belohnungen an die Reserven zurückgeschickt wurden, weil sie ihren Einsatzschlüssel nicht registriert hatten
2. Die Epoche, die die 1-Epochen-Lücke zwischen der Abmeldung ihres Schlüssels und der erneuten Registrierung darstellt

Die fehlende 234 Epoche entspricht (2), und ich glaube, 231 entspricht (1), da 231 bedeutet, dass sie bei Epoche 233 in der Brieftasche des Benutzers sichtbar sein sollte, was genau der Epoche entspricht, für die wir erwarten, dass sie für sie verwirkt ist (1)

Sie sollten damit rechnen, dass zwei Epochen fehlen:

Warum? Gemäß den Operationen an dieser Pfahladresse:

| Betrieb | tx_epoch_no | active_epoch_no |
|------------------|---------------------|------- ---------|
| Registrierung | 208 | 210 |
| Abmeldung | 232 | 234 |
| Registrierung | 233 | 235 |

es wurde nur für eine einzelne Epoche ( 234 ) abgemeldet und erhielt für diese Epoche keine Belohnungen.

Warum sollte es zwei Epochen ohne Belohnungen geben? Ich bin mir ziemlich sicher, dass die beiden von Ihnen erwähnten Fälle tatsächlich dasselbe sind und daher nur eine Epoche ohne Belohnung ausgeht.

@SebastienGllmt in Slack sagte:

Die Abmeldung ist insofern das Besondere, als sie sofort erfolgt, nicht in 2 Epochen

Wenn die Abmeldung sofort erfolgt, geschah dies in tx_epoch_no == 232 sodass alle Belohnungen für die Epochen [231..234] verloren gehen würden, nicht nur die Belohnungen für 231.

Ich denke, dafür brauchen wir @JaredCorduan .

Die Erklärung von @SebastienGllmt stimmt mit den Ledger-Regeln überein.

Es ist ein bisschen philosophisch, "wenn" ein Pfahl-Berechtigungsnachweis abgemeldet wird, aber ich würde es so formulieren: Die Abmeldung erfolgt sofort, aber die Belohnungen werden verzögert. Wenn ein Berechtigungsnachweis in der Epoche e abgemeldet wird, erhält er Belohnungen an der Grenze von e / e+1 (aus dem Snapshot, der an der Grenze e-2 / e -1 ) und es wird auch Belohnungen an der e+1 / e+2 Grenze erhalten (aus dem Schnappschuss, der an der e-1 / e Grenze aufgenommen wurde).

Das klingt, als hätten wir einige Verwirrung mit der Nomenklatur.

Aus dem POV von dbs-ync : :

• tx_epoch_no : die Epoche, die die Transaktionen der An-/Abmeldebescheinigung enthält.
• active_epoch_no : grundsätzlich tx_epoch_no + 2 , die Epoche, in der Änderungen der Stake-Adresse aktiv werden.
• epoch_no in reward Tabelle: die aktuelle Epoche, in der Belohnungen verdient wurden.

wenn sich die Pfahlberechtigung in einem Abmeldezertifikat von einer Transaktion in Epoche 232 befand, dann wäre sie nicht in der Momentaufnahme enthalten, die an der Grenze 232/233 erstellt wurde. Dies bedeutet, dass es nicht Teil des Belohnungsupdates wäre, das an der Grenze von 235/236 verteilt wird. was in @erikds Begriffen die 234 Belohnungen sind. Wenn das (Wieder-)Registrierungszertifikat in Epoche 233 in einer Transaktion landen würde, wäre dies außerdem die _einzige_ Belohnungsaktualisierung, die es verpassen würde.

Es ist erwähnenswert, dass Dinge wie "abgemeldet wann", "Belohnungen um" und "aktiv wann" usw. verwirrend sein können, wenn wir uns nicht wirklich klar sind. also ist mir nicht klar, wem ich nur zustimme :)

Da es Verwirrung zu geben scheint, habe ich ein Bild gemacht, das die beiden erwarteten fehlenden Epochen zeigt (db-sync 231 und db-sync 234)

Ich denke, die Verwirrung rührt von der Tatsache her, dass 231 technisch möglicherweise nicht fehlen - es könnte sein, dass der Ledger-Zustand es nur an die Reserven anstatt an den Benutzer verteilt betrachtet. Aus Sicht des Hauptbuchstatus sind die Belohnungen vorhanden (auf die Reserven verteilt), aber aus Sicht des Benutzers sollten 231 nicht enthalten sein

Ich habe ein Bild gemacht, das die beiden erwarteten fehlenden Epochen zeigt (db-sync 231 und db-sync 234)

Aber die tatsächlichen Belohnungen, wie von db-sync gemeldet, sind:

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)

und nur Epoche 234 hat keine Belohnungen. db-sync ruft den Inhalt dieser Tabelle aus dem Ledger-Zustand ab und das einzige, was db-sync hinzufügt, ist die epoch_no Spalte.

Ihr Diagramm stimmt nicht mit dieser Tabelle überein, daher ist Ihr Diagramm wahrscheinlich falsch. Möglicherweise gibt es auch einen Fehler in der node (insbesondere der Berechnung des Adressbelohnungssaldos), aber ich würde es vorziehen, vorerst nur mit einer einzigen Variablen ( db-sync ) zu arbeiten.

In Ihrem Diagramm haben Sie "Belohnungen geliefert" für Epoche 233 durchgestrichen, und sowohl Jared als auch ich denken, dass das falsch ist und dass Belohnungen geliefert werden sollten (da sie auf dem Schnappschuss zu Beginn der Epoche 231 basieren, nicht dem aktuellen Stand von Die Kette).

@SebastienGllmt sagt:

Ich denke, die Verwirrung rührt von der Tatsache her, dass 231 technisch möglicherweise nicht fehlen - es könnte sein, dass der Ledger-Zustand es nur an die Reserven anstatt an den Benutzer verteilt betrachtet.

Aber die Tabelle rewards zeigt die Belohnung, die an die Einsatzadresse verteilt wird. Wenn es an die Reserven verteilt würde, wäre es nicht in dieser Tabelle enthalten. db-sync erhält diese Prämieninformationen als Karte von der Einsatzadresse bis zum Prämienbetrag. Jetzt kann der Ledger-Status selbst falsch sein, aber es gibt nur sehr wenig Raum für Fehler, die sich einschleichen, nachdem die Karte aus dem Ledger-Status abgerufen wurde.

Ich lag falsch, als ich sagte:

außerdem wäre dies die einzige Belohnungsaktualisierung, die es verpassen würde, wenn das (Wieder-)Registrierungszertifikat in einer Transaktion in der Epoche 233 landen würde.

Tatsächlich hatte @SebastienGllmt genau Recht, als er sagte:

Sie sollten damit rechnen, dass zwei Epochen fehlen:

1. Die Epoche, in der die Belohnungen an die Reserven zurückgeschickt wurden, weil sie ihren Einsatzschlüssel nicht registriert hatten
2. Die Epoche, die die 1-Epochen-Lücke zwischen der Abmeldung ihres Schlüssels und der erneuten Registrierung darstellt

Da der Pfahlausweis nicht an der Epochengrenze 232/233 registriert ist, sind beide:

• erhält nicht die Belohnungen aus dem Update, das auf die 232/233-Grenze angewendet wird, und
• ist nicht in der Momentaufnahme der Einsatzverteilung enthalten, die an der Grenze von 232/233 erstellt wurde (damit es nicht die Belohnungen erhält, die an der Grenze von 235/236 ausgegeben werden).

Ich kann mir vorstellen, wie db-sync die Ausgabe von Belohnungen an der Grenze 232/233 @SebastienGllmt ist :) ). Der Ledger-Zustand kann bis zum letzten Moment vor der Epochengrenze nicht wissen, welche Credentials noch registriert sind. Wir geben Belohnungen für nicht registrierte Anmeldeinformationen an die Reserven zurück. (Siehe Figure 51: Reward Update Application in der formalen Spezifikation ). db-sync entfernt wahrscheinlich keine unregistrierten Anmeldeinformationen.

Das obige Bild von Blockproduktionsphase zu berücksichtigen. Beispielsweise werden die Belohnungen aus dem Schnappschuss, der an der Grenze 230/231 aufgenommen wurde, erst an der Grenze 233/234 tatsächlich ausgehändigt.

Ok jetzt haben wir eine Erklärung dafür. db-sync behält den Legder-Status bei und zieht die Epochenbelohnungen als Map StakeAddress Coin die es in die Datenbank einfügt. Diese Karte enthält jedoch StakeAddress Einträge, die nicht gültig sind und legder-state würde diese Einträge löschen und die verdienten Belohnungen effektiv wieder in die Reserven einbringen.

Die Lösung besteht darin, auch die Menge gültiger StakeAddress aus dem Hauptbuchstatus zu ziehen und dann die Map filtern und alle Einträge zu löschen, die nicht in der Menge gültiger StakeAddress .

Es wäre toll, wenn diese 'Phantom'-Belohnungen in eine neue Tabelle wie 'nondistributed_rewards' oder so ähnlich aufgenommen würden. Dadurch können wir die Poolrentabilität richtig berechnen

@dmitrystas :

Es wäre toll, wenn diese 'Phantom'-Belohnungen in eine neue Tabelle wie 'nondistributed_rewards' oder so ähnlich aufgenommen würden. Auf diese Weise können wir die Poolrentabilität korrekt berechnen.

Ich kann sehen, dass diese nicht verteilten Belohnungen (die in die Reserven zurückfließen) verwendet werden könnten, um die Rentabilität von Umfragen zu berechnen, aber ich bin mir ziemlich sicher, dass dies nicht die beste oder einfachste Methode ist, sie zu berechnen.

Ich habe speziell für dieses Problem ein Ticket erstellt.

Ok, ich habe eine Lösung, die ungültige Belohnungen aus der Belohnungsliste herausfiltert, bevor sie eingefügt werden, und tatsächlich gibt es eine Belohnung für diese Adresse in der Epoche 231 .

Ich muss das jetzt ändern, damit diese "ungültigen" Belohnungen einer separaten Tabelle hinzugefügt werden können.

Verwenden der Version von db-sync in PR #469. die Belohnung für die Einsatzadresse \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde wird korrekt in die Tabelle orphaned_rewards eingefügt:

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

und es fehlt auch in der Belohnungstabelle:

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)