Cardano-db-sync: Пример баланса счета

Спасибо, что открыли эту тему от моего имени! Просто чтобы уточнить немного больше - речь идет не только об учетной записи как таковой, но в основном об отслеживании reap где-то в базе данных, чтобы его можно было легко использовать для расчета баланса учетной записи (который используется везде, например, в пуле размер ставки, залог живого пула и т. д.).

@ 1000101 Что такое «пожинать»? В db-sync нет таблицы или столбца, называемого «пожинать».

Баланс счета не является тривиальным.

Адреса Шелли и более поздних эпох состоят из двух компонентов; учетные данные для оплаты и учетные данные для ставок. Адрес доли (например, stake1uyluup0rh6r2cc7kcw8nudqz990ezf5ltagxmw3u8deukvqwq7etq ) получен из более позднего. Однако можно создать действительный адрес, который не содержит учетных данных для ставок.

Таким образом, хотя можно было бы получить баланс учетной записи для определенного адреса для ставок, нет никакого способа получить баланс учетной записи кошелька, если каждый адрес в этом кошельке не включает одни и те же учетные данные для ставок.

@ 1000101 Что такое «пожинать»? В db-sync нет таблицы или столбца, называемого «пожинать».

О, извините, что недостаточно разъяснил это. То, что я имел в виду, описано в https://github.com/input-output-hk/cardano-db-sync/issues/474 - т.е. я говорю именно о том, что для этого нет столбца, но было бы здорово если бы было.

В настоящее время нет способа легко вычислить баланс учетной записи, когда эта учетная запись использовалась при регистрации пула (в качестве учетной записи вознаграждения), а затем пул был удален, таким образом восстанавливая депозит пула. «Выплата» депозита пула отслеживается в dbsync, но не его «возврат» при удалении пула.

Я согласен с этим. Есть также множество пограничных случаев, с которыми должен справиться каждый «пользователь» cardano-db-sync. И Адалит, и Ёрой сбиты с толку, когда видят учетную запись, которая ранее была учетной записью вознаграждения пенсионного пула:

Кроме того, AFAIK только cardanoscan правильно обрабатывает оставшиеся вознаграждения и не использует db-sync.

Должна быть простая связь, которая будет обновляться так же, как автоматически добавляются награды. Давайте возьмем в качестве примера пул с несколькими отменами регистрации , поскольку это довольно распространенное явление, и трудно справиться с балансом вознаграждения его учетной записи владельца.

К нему 9 пенсионных удостоверений.

И 15 регистрационных удостоверений

Есть многочисленные крайние случаи и расплывчатые правила выхода на пенсию, отменяющие новые сертификаты .

@erikd , если вы настаиваете на достаточной связи между депозитом в 500 транзакций и выходом на пенсию, как бы вы написали запрос только для возвращенных депозитов одной из его учетных записей владельцев - e127e9e94eaa9287680e877832700a1724255e9688609497e09a6c440f? Если нет, можем ли мы добавить это явно в db-sync? Скажем, в качестве новой таблицы с именем pool_refunds , с addr_id , суммой (в настоящее время должно быть кратно 500) и epoch_no — чтобы это обрабатывалось правильно и в одном месте.

В настоящее время db-sync извлекает данные из реестра и вставляет их в базу данных. Он отбрасывает некоторую информацию, но не выполняет никаких агрегаций. То, что вставляется в базу данных, является просто отражением того, что обеспечивает состояние реестра.

Давайте посмотрим на соответствующий pool_hash.id :

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

Пул был зарегистрирован (дополнительные объединения, чтобы расположить их в порядке возрастания block_no ) следующим образом:

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

и снят с регистрации в:

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

Удаление обновлений и снятие с регистрации:

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

Продолжение следует ....

Это определенно слишком много боли в шее. Разговор со специалистами по бухгалтерским книгам, чтобы попытаться найти решение.

Поговорил с ledger-specs людьми, которые предложили быстрый и грязный способ подделать его на данный момент, ожидая лучшего решения.

Идея заключалась бы в том, чтобы иметь что-то вроде таблицы pool_registration_refund , содержащей адрес ставки и сумму.

Было бы здорово!

Поговорил с ledger-specs людьми, которые предложили быстрый и грязный способ подделать его на данный момент, ожидая лучшего решения.

Идея заключалась бы в том, чтобы иметь что-то вроде таблицы pool_registration_refund , содержащей адрес ставки и сумму.

Потрясающий! Я имею в виду, что на данный момент у нас есть обходной путь, поэтому мы не достигнем отрицательного баланса, которым поделился @xdzurman , но это около 100 строк не очень красивого: tm : SQL, которые должны быть вычислены для каждой учетной записи. Это определенно помогло бы тонне. Миллион спасибо!!!