Cardano-db-sync: Kontostand Beispiel

Danke, dass Sie dieses Thema in meinem Namen eröffnet haben! Nur um ein bisschen mehr zu verdeutlichen - es geht nicht nur um das Konto an sich, sondern hauptsächlich darum, reap irgendwo in der Datenbank zu verfolgen, damit es leicht zur Berechnung des Kontostands verwendet werden kann (der überall verwendet wird, z. B. Pool Live Einsatzgröße, Pool-Live-Versprechen usw.).

@ 1000101 Was ist "ernten" ? Es gibt keine Tabelle oder Spalte in db-sync namens "reap".

Der Kontostand ist nicht trivial.

Adressen in der Shelley und späteren Epochen haben zwei Komponenten; einen Zahlungsnachweis und einen Staking-Nachweis. Die Stake-Adresse (z. B. stake1uyluup0rh6r2cc7kcw8nudqz990ezf5ltagxmw3u8deukvqwq7etq ) wird von letzterem abgeleitet. Es ist jedoch möglich, eine gültige Adresse zu erstellen, die keine Staking-Anmeldeinformationen enthält.

Während es also möglich wäre, den Kontostand für eine bestimmte Stake-Adresse abzurufen, gibt es keine Möglichkeit, den Kontostand einer Wallet abzurufen, es sei denn, jede Adresse in dieser Wallet enthält die gleichen Staking-Anmeldeinformationen.

@ 1000101 Was ist "ernten" ? Es gibt keine Tabelle oder Spalte in db-sync namens "reap".

Oh, tut mir leid, dass ich das nicht genug klargestellt habe. Was ich meinte, ist in https://github.com/input-output-hk/cardano-db-sync/issues/474 beschrieben - dh ich sage genau, dass es keine Spalte dafür gibt, aber es wäre großartig wenn es das geben würde.

Es gibt derzeit keine Möglichkeit, den Kontostand einfach zu berechnen, wenn dieses Konto bei der Poolregistrierung (als Prämienkonto) verwendet wurde und später der Pool stillgelegt wurde, wodurch die Pooleinlage wiedererlangt wurde. Die "Zahlung" der Pool-Einzahlung wird in dbsync nachverfolgt, aber nicht ihre "Rückerstattung", wenn ein Pool stillgelegt wird.

Ich stimme dem zu. Es gibt auch zahlreiche Grenzfälle, mit denen jeder "Benutzer" von cardano-db-sync umgehen müsste. Sowohl Adalite als auch Yoroi sind verwirrt, als sie ein Konto sehen, das zuvor ein Belohnungskonto eines stillgelegten Pools war:

Außerdem behandelt AFAIK nur cardanoscan die verbleibenden Belohnungen korrekt und sie verwenden kein db-sync.

Es sollte eine einfache Beziehung geben, die auf die gleiche Weise aktualisiert wird, wie Belohnungen automatisch hinzugefügt werden. Nehmen wir als Beispiel einen Pool mit mehreren Abmeldungen , da dies eigentlich ziemlich üblich ist und es schwierig ist, das Prämienguthaben des Eigentümerkontos zu verwalten.

Dazu gibt es 9 Rentenbescheide

Und 15 Zulassungsbescheinigungen

Es gibt zahlreiche Grenzfälle und vage Regeln des Ruhestands, die durch neue Zertifikate außer Kraft gesetzt werden .

@erikd , wenn Sie auf einer ausreichenden Verbindung zwischen der Einzahlung von 500 tx und den Pensionierungen bestehen, wie würden Sie dann eine Abfrage nur für die zurückgegebenen Einzahlungen eines seiner Eigentümerkonten schreiben - e127e9e94eaa9287680e877832700a1724255e9688609497e09a6c440f? Wenn nicht, können wir dies explizit zu db-sync hinzufügen? Nehmen wir an, als neue Tabelle mit dem Namen pool_refunds mit addr_id , Betrag (derzeit sollte ein Vielfaches von 500 sein) und epoch_no - damit dies korrekt und an einem einzigen Ort gehandhabt wird.

Derzeit extrahiert db-sync Daten aus dem Hauptbuchstatus und fügt sie in die Datenbank ein. Es verwirft einige Informationen, führt jedoch keine Aggregationen durch. Was in die Datenbank eingefügt wird, spiegelt einfach wider, was der Ledger-Status bereitstellt.

Schauen wir uns das relevante pool_hash.id an:

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

Der Pool wurde wie folgt registriert (zusätzliche Joins, um sie von block_no aufsteigend zu ordnen):

> 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)

und abgemeldet in:

> 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)

Deinterleaving-Updates und Deregistrierungen:

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

Fortsetzung folgt ....

Das ist definitiv zu viel von einem Schmerz im Nacken. Gespräche mit Ledger-Specs-Leuten, um zu versuchen, eine Lösung zu finden.

Gesprochen mit den ledger-specs Leuten, die einen schnellen und schmutzigen Weg vorgeschlagen haben, es vorerst zu verfälschen, während sie auf eine bessere Lösung warten.

Die Idee wäre, so etwas wie eine pool_registration_refund -Tabelle zu haben, die die Stake-Adresse und den Betrag enthält.

Das wäre großartig!

Gesprochen mit den ledger-specs Leuten, die einen schnellen und schmutzigen Weg vorgeschlagen haben, es vorerst zu verfälschen, während sie auf eine bessere Lösung warten.

Die Idee wäre, so etwas wie eine pool_registration_refund -Tabelle zu haben, die die Stake-Adresse und den Betrag enthält.

Genial! Ich meine, wir haben vorerst eine Problemumgehung, damit wir den von @xdzurman geteilten negativen Kontostand nicht erreichen, aber es sind ungefähr 100 Zeilen von not-so-Pretty :tm : SQL, die für jedes Konto berechnet werden müssen. Dies würde definitiv eine Tonne helfen. Tausend Dank!!!