Cardano-db-sync: Die Einzahlung nach der Pensionierung des Pools sollte in der Belohnungstabelle enthalten sein

Aber die 'Belohnungs'-Tabelle ist nicht dasselbe wie 'stake_address change'... Wenn wir dies tun, sollten wir auch andere Dinge in dieser Tabelle speichern, wie zum Beispiel ITN-Belohnungen (derzeit 'Reserve'-Tabelle)

Die einzige andere Möglichkeit, diese Einzahlungen zusammen mit den Belohnungen zu erhalten, besteht darin, die Pool-Ruhestandstabelle abzufragen, ob ein mit dieser Einsatzadresse verbundener Pool in einer bestimmten Epoche abgelaufen ist, und den Belohnungen einen hartcodierten Wert von 500000000 hinzuzufügen, wenn dieser Wert noch nicht abgelaufen ist zurückgezogen, was wiederum eine Berechnung erfordert, wenn die Auszahlungen bis zu diesem Zeitpunkt nicht höher sind als die Belohnungen, und so weiter und so weiter, was wirklich klobig erscheint.

Ich denke jedoch immer noch, dass es in der DB expliziter angegeben werden sollte, ohne diese hartcodierten Werte und dergleichen. Vielleicht noch ein Tisch? Oder eine einfachere Beziehung?

Wenn ich mich dafür entscheiden würde, diese 500 ADA aus der Tabelle pool_retirement zu erhalten, wenn der Pool mehrere Eigentümer hat, wie würde ich dann herausfinden, an welche Pfahladresse diese 500 ADA belohnt wurden?

Wenn der Pool mehrere Eigentümer hat, wie kann ich herausfinden, an welche Pfahladresse diese 500 ADA belohnt wurden?

die Einzahlung wird an die Prämienadresse zurückerstattet (ist immer eine für einen Pool), nicht an die Eigentümeradresse

die Einzahlung wird an die Prämienadresse zurückerstattet (ist immer eine für einen Pool), nicht an die Eigentümeradresse
Das macht Sinn danke!

Die Einzahlung eines ausgeschiedenen Pools wird also an die in der Tabelle pool_update deklarierte Belohnungsadresse des Pools zurückgezahlt, oder?

Ich frage, weil ich das aktuelle Beispiel habe, das mich verwirrt:

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';

Diese Abfrage gibt uns die Gesamtprämien und die Gesamtauszahlungen einer Beispiel-Einsatzadresse. Der Unterschied zwischen denen beträgt genau 500000000 Lovelace. Sicher kann es ein Zufall sein, aber das ist ziemlich schwer vorstellbar, da es andere Beispiele dieser Art gibt. Nehmen wir also einfach an, dass dies eine zurückgegebene Pool-Einzahlung ist, dann sollte diese Einsatzadresse als Belohnungsadresse in der pool_update-Tabelle vorkommen, oder?

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'

Aber diese Abfrage führt zu keinem Ergebnis. Die Sache, die ich herausfinden konnte, ist, dass die Stake-Adresse ein Miteigentümer eines pensionierten Pools ist (pool_hash_id = 8), was mich zu meiner ersten Frage führte.

Ich frage mich nur, wie ich feststellen kann, woher diese 500 ADA kommen. Könnte diese Kaution mit dem ITN zusammenhängen?

Die Einzahlung eines ausgeschiedenen Pools wird also an die in der Tabelle pool_update deklarierte Belohnungsadresse des Pools zurückgezahlt, oder?

rechts

Aber diese Abfrage führt zu keinen Ergebnissen

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

Ich frage mich nur, wie ich feststellen kann, woher diese 500 ADA kommen. Könnte diese Kaution mit dem ITN zusammenhängen?

Mit ziemlicher Sicherheit nicht.

Wo stehen wir mit diesem Thema. Scheint ein bisschen hin und her gewesen zu sein. Möchten Sie mich über den aktuellen Stand der Dinge auf dem Laufenden halten?

Sicher, das Thema wurde ziemlich gekapert. An der Frage hat sich also nichts geändert - Einzahlung, die nach dem Ausscheiden eines Pools an die Belohnungsadresse zurückgehen soll, ist nirgendwo explizit in der DB enthalten (zB 500 ADA kam in Epoche 245). Sie müssen jedoch in der Pool-Ruhestandstabelle überprüfen, ob der Pool, dessen Besitzeradresse die gesuchte Prämienadresse ist, manuell einen hartcodierten Wert von '500' zu den Prämien des Benutzers hinzufügen, WENN dieser Betrag aus genau diesem Rücktritt nicht abgezogen wurde noch. Was mir wirklich umständlich erscheint und ich schlug vor, ob es in die Belohnungstabelle oder woanders gehen könnte, aber explizit.

Kaution, die nach dem Ausscheiden eines Pools an die Prämienadresse zurückgegeben werden soll, ist nirgendwo explizit in der DB enthalten

Haben Sie eine Beispiel-Mainnet-Adresse, die ich untersuchen kann?

e11d227aefa4b773149170885aadba30aab3127cc611ddbc4999def61c / stock1uywjy7h05jmhx9y3wzy94td6xz4txynuccgam0zfn800v8qq33z29

Sie haben eine falsche Vorstellung von der Rückerstattung der Anzahlung. Einzahlungsrückerstattungen landen nicht in der reward Tabelle, sondern in der tx Tabelle. Also finden wir es.

Für die Adresse interessieren wir uns:

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

Das Feld id kann in den Instanzen von db-sync , aber das Feld id wird für diese Untersuchung nützlich sein.

Ein bisschen komplex, aber die Rückerstattung kann wie folgt angezeigt werden:

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

In ähnlicher Weise kann die Registrierung folgendermaßen aussehen:

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)

Ich nehme an, diese Pfahladresse lautete:

• registriert in Epoche 208
• abgemeldet in Epoche 223
• in der Epoche 223 erneut registriert.

Macht das alles Sinn?

Es macht Sinn für die Registrierung von Einsätzen, aber ich habe über den Rückzug des Pools gesprochen. Und die 500 ADA, die an die Belohnungsadresse des Poolbesitzers zurückgegeben werden sollten.

Ich glaube immer noch nicht, dass es auf die Belohnungsadresse zurückgeht. Haben Sie ein Beispiel für einen Pool, der in den Ruhestand geht?

Der Zusammenhang oder die Tatsache, dass es irgendwo in der Datenbank auftauchen würde, ist eigentlich mein Wunsch nach einem Feature, kein Fehler in der aktuellen Version. Beispiel für einen stillgelegten Pool: pool134dws3tyc7kphwl6gks26cm6l390554lns9lyatm3gkxs6dwj2z. Die Adresse, die ich zuvor gesendet habe, ist ihr Besitzer

@erikd
Aus der Ledger-Spezifikation :

Seite 21

Denken Sie daran, dass die Rückerstattungen für den Ruhestand des Anteilspools nicht ausgestellt werden, wenn ein Zertifikat die
Die Stilllegung wird verarbeitet, jedoch an der Epochengrenze, für die die Stilllegung geplant ist.

Seite 40

• Die Funktion poolRefunds wird verwendet, um die zu verteilenden Gesamterstattungen zu berechnen
für Beteiligungspools, die in den Ruhestand gehen sollen. Es ist zu beachten, dass diese Berechnung eine Schlitznummer nimmt, die dem Epochengrenzschlitz entspricht, wenn die Berechnung durchgeführt wird. Die zurückgekehrte
map ordnet die Hashkeys des Poolbetreibers den Rückerstattungen zu, die letztendlich an die . zurückgegeben werden
registriertes Prämienkonto.

@xdzurman Entschuldigung:

Der Zusammenhang oder die Tatsache, dass er irgendwo in der Datenbank auftauchen würde, ist eigentlich mein Wunsch nach einem Feature,

Was genau ist die Funktionsanfrage?

@erikd Um die abzulegen , nachdem ein Pool

Schließung zugunsten von https://github.com/input-output-hk/cardano-db-sync/issues/474 .