Cardano-db-sync: Награды были распределены на незарегистрированный адрес доли

Созданный на 2 дек. 2020 · 28Комментарии · Источник: input-output-hk/cardano-db-sync

Mainnet, db-sync 6.0.1, адрес стейка stack1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86

история регистрации

SELECT stake_registration.addr_id, block.epoch_no, block.time
FROM stake_address
LEFT JOIN stake_registration ON stake_registration.addr_id = stake_address.id
LEFT JOIN tx ON tx.id = stake_registration.tx_id
LEFT JOIN block ON block.id = tx.block_id 
WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';

 addr_id | epoch_no |        time
---------+----------+---------------------
   38278 |      208 | 2020-08-01 07:45:51
   38278 |      233 | 2020-12-01 22:31:13
(2 rows)

история отмены регистрации

SELECT stake_deregistration.addr_id, block.epoch_no, block.time
FROM stake_address
LEFT JOIN stake_deregistration ON stake_deregistration.addr_id = stake_address.id
LEFT JOIN tx ON tx.id = stake_deregistration.tx_id
LEFT JOIN block ON block.id = tx.block_id 
WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';

 addr_id | epoch_no |        time
---------+----------+---------------------
   38278 |      232 | 2020-12-01 18:25:59
(1 row)

как мы видим, адрес не был зарегистрирован в конце эпохи 232, и награды за эпоху 231 не должны распределяться по этому адресу, а

SELECT reward.*, block.epoch_no AS block_epoch_no, block.time
FROM reward
LEFT JOIN block ON block.id = reward.block_id 
WHERE reward.addr_id = 38278 AND reward.epoch_no = 231;

   id    | addr_id |  amount   | epoch_no | pool_id | block_id | block_epoch_no |        time
---------+---------+-----------+----------+---------+----------+----------------+---------------------
 1041508 |   38278 | 192969560 |      231 |     144 |  5023676 |            233 | 2020-12-01 21:44:51
(1 row)

bug priority high

Источник

dmitrystas

👀4 👍1

Самый полезный комментарий

Использование версии db-sync в PR # 469. вознаграждение за адрес ставки \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde правильно вставлено в таблицу 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

и его также нет в таблице вознаграждений:

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)

erikd 8 янв. 2021

👍2

Все 28 Комментарий

: facepalm:

Посмотрел на это некоторое время, а затем внезапно понял, что первый запрос не показывает то, что, по мнению tx.id = stake_registration.tx_id а затем получая block.epoch_no из транзакции, вы получаете эпоху, когда происходит регистрация / отмена регистрации доли, но не тогда, когда она фактически активна .

Для большинства операций, связанных со ставкой, действия (например, регистрации, увеличение суммы ставки и т. Д.), Которые происходят в эпоху N становятся активными в эпоху N + 2 .

Это означает, что первый запрос на самом деле должен быть:

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

и второй:

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 Это все active_epoch_no столбца в stake_registration и stake_deregistration столиков , как я имею в delegation таблицы?

erikd 17 дек. 2020

@erikd Добрый день. Это оригинальная проблема https://github.com/Emurgo/yoroi-frontend/issues/1832#issue -754776885
Может быть, может быть полезно

Yoroi и Adalite показывают неверные 192 награды FAKE ADA, но на самом деле это 0. Последние 2 награды снимаются через adawallet.io (он не использует db-sync)

Краткое описание проблемы по шагам:
1) Эпоха 232 . Я одновременно снимаю награды и снимаю регистрацию ключа для ставок . Награды равны 0. У меня достаточно ADA для комиссий.
2) Эпоха 233 . Я должен получить первое оставшееся вознаграждение, если мой ключ был зарегистрирован, но это не так, но Йорой показывает полученное 192ADA. Yoroi выдает ошибку, когда я пытаюсь уйти. Другие кошельки, которые не используют db-sync, показывают вознаграждение 0ADA
3) Эпоха 233 . Я снова передаю полномочия в тот же пул. Ключ зарегистрирован . Истинные награды 0. Награды Ёрой 192.
4) Эпоха 234 . Я получаю вторую оставшуюся награду 135ADA. Истинный баланс вознаграждения составляет 135ADA.
Йорой показывает 327ADA (192 + 135). Невозможно снять вознаграждение через Ёрой. Я получил ошибку от сервера при отправке транзакции.
5) Эпоха 235 . Получаю последнюю третью награду 145ADA. Истинный баланс вознаграждения составляет 280ADA (135 + 145).
Yoroi показывает 472ADA (192 + 135 + 145) Невозможно снять вознаграждение через Yoroi. Я получил ошибку от сервера при отправке транзакции.
6) Эпоха 235 . Я снимаю 280ADA плавно через adawallet.io, который не использует db-syns и правильно показывает баланс вознаграждения 280ADA
7) После снятия истинных наград в размере 280ADA (остается 0ADA) Йорой по-прежнему показывает баланс вознаграждения 192ADA.

IlyaSofronov 17 дек. 2020

Ёрой по-прежнему показывает баланс вознаграждения 192ADA.

Есть как минимум две возможности;

есть ошибка db-sync
есть ошибка Ёрой

Я имею дело только с db-sync . Это означает, что проблемы нужно представлять мне как SQL-запросы, а не как информацию от Йороя.

stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 интересующий вас ключ ставки?

erikd 17 дек. 2020

@erikd да, ключ ставки - stack1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86
Обратите внимание, что ЭТА ОШИБКА ИМЕЕТСЯ не только у Йороя, но и у Adalite.io и adastat.net.
У них НЕТ этой ошибки: cardanoscan.io и adawallet.io

IlyaSofronov 18 дек. 2020

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

erikd 18 дек. 2020

@erikd Но adawallet.io не использует db-sync и показывает правильный баланс вознаграждения (0ADA), и это позволяет мне снимать последние вознаграждения

IlyaSofronov 18 дек. 2020

Опять же, это говорит о том, что это ошибка Yoroi, а не ошибка db-sync .

erikd 18 дек. 2020

Exodus также столкнулся с этой ошибкой.

roccomuso 4 янв. 2021

Это определенно ошибка cardano-db-sync, а не ошибка Yoroi, учитывая, как это влияет не только на Yoroi, но и на нескольких других пользователей cardano-db-sync. cardanoscan и adawallet не используют cardano-db-sync, поэтому на них это не влияет.

Какие отчеты cardano-db-sync

Вот SQL-запрос, который дает историю вознаграждений для адреса, предоставленного @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'

и дает следующий результат

 \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

Примечание : сумма этих строк составляет 3 765 004 402

Текущее (неправильное) состояние из нашего бэкэнда

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

Вы можете видеть, что наш бэкэнд возвращает сумму строк db-sync для значения rewards (позже объясню, почему это проблема)

Вы также можете проверить правильность суммы withdrawals , суммируя значения на cardanoscan, которые, как мы знаем, не затронуты этой ошибкой.

remainingAmount - это всего лишь rewards - withdrawals

История регистрации кошелька

Просматривая историю этого ключа стекинга , вы можете увидеть:

Он был снят с
Он был вновь зарегистрирован на эпоху 233

Текущее состояние от cardano-node

Согласно моему экземпляру cardano-node, это текущее значение внутри адреса стекинга.

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

Итак, вы можете видеть, что согласно узлу баланс кошелька составляет эпоху 235 + эпоху 236 (100702 + 102078 = 202780).

Так в чем же проблема?

Посмотрев на cardanoscan, мы можем увидеть полную историю вывода средств из кошелька. Посмотрим, чему соответствует каждый вывод:

| Эпоха снята | Снятая сумма | строки эпох db-sync включены |
| ----------------- | ------------------ | ------------ ----------------- |
| 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 |

ОДНАКО вы можете видеть, что эпоха 231 в cardano-db-sync (192969560) не включена ни в одну из них!

Конечно, если вы посмотрите на наш ответ бэкэнда, "remainingAmount": "193172340", и удалите ошибочно включенную эпоху 231, вы получите 193172340 - 192969560 = 202780 который является ожидаемым результатом нашего полного узла!

Заключение

Основываясь на моем исследовании, кажется, что cardano-db-sync включает строку 231 в результат истории вознаграждений, хотя этого не должно быть.

SebastienGllmt 4 янв. 2021

Я упростил первый запрос и подтвердил, что получаю те же результаты (и делал).

Текущее (неправильное) состояние из нашего бэкэнда

Я бы предпочел получать всю информацию из одного источника, поэтому:

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

а также:

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

оба согласны с вашими цифрами.

Интересно, что 3571832062 + 192969560 + 202780 - 3765004402 где 3571832062 - сумма вывода, а 3765004402 - сумма вознаграждения. Остальные значения: 202780 - это ваша цифра для баланса вознаграждения после вывода средств, а 192969560 - это вознаграждение за эпоху 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

Правильно ли это вознаграждение за эпоху 231 (которое db-sync просто выводит из состояния реестра и вставляет в базу данных без дополнительной обработки)? Давайте посмотрим на историю регистрации ставок для этого адреса ставки:

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

Обратите внимание, что как для регистрации, так и для отмены регистрации я включил tx_id (идентификатор tx, который содержал регистрацию / отмену регистрации), tx_epoch_no (эпоха, в которую был включен tx) и active_epoch_no (эпоха, в которой регистрация / отмена регистрации становится активной).

Если посмотреть на номера активных эпох, регистрация доли должна быть активна в эпохи [210 .. 233] и [235 ..] . Это соответствует фактическим наградам для этого адреса:

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)

Т.е. есть награды для каждой эпохи, кроме 234 .

Поэтому думаю ваш вывод:

Основываясь на моем исследовании, кажется, что cardano-db-sync включает строку 231 в результат истории вознаграждений, хотя этого не должно быть.

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

Кроме того, я считаю, что ваш комментарий:

Текущее (неправильное) состояние из нашего бэкэнда
{
"leftAmount": "193172340",
"награды": "3765004402",
"снятие средств": "3571832062",
}

на самом деле правильно. Разница между суммой вознаграждения и суммой вывода - это текущий невыведенный баланс вознаграждения.

erikd 5 янв. 2021

на самом деле правильно. Разница между суммой вознаграждения и суммой вывода - это текущий невыведенный баланс вознаграждения.

Этого не может быть, потому что мы знаем, что узел возвращает 202780 в качестве баланса вознаграждения для учетной записи, а не 193172340

Т.е. есть награды для каждой эпохи кроме 234.

Следует ожидать, что не будет двух эпох:

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

Отсутствующая эпоха 234 соответствует (2), и я считаю, что 231 соответствует (1), поскольку 231 означает, что она должна быть видна в кошельке пользователя в эпоху 233, которая является именно той эпохой, за которую, как мы ожидаем, была потеряна. (1)

SebastienGllmt 5 янв. 2021

Следует ожидать, что не будет двух эпох:

Почему? Согласно операциям на этой ставке адрес:

| операция | tx_epoch_no | active_epoch_no |
| ------------------- | --------------------- | ------- --------- |
| регистрация | 208 | 210 |
| снятие с регистрации | 232 | 234 |
| регистрация | 233 | 235 |

он был отменен только на одну эпоху ( 234 ) и не получил награды за эту эпоху.

Почему две эпохи без наград? Я почти уверен, что два упомянутых вами случая на самом деле одно и то же, и, следовательно, только одна эпоха проходит без награды.

erikd 5 янв. 2021

@SebastienGllmt в Slack сказал:

снятие с учета особенное тем, что происходит сразу, а не через 2 эпохи

Если отмена регистрации произойдет немедленно, это произойдет в tx_epoch_no == 232 поэтому будут потеряны все награды за эпохи [231..234] , а не только награды за 231.

Думаю, нам нужен @JaredCorduan для этого.

erikd 5 янв. 2021

Объяснение @SebastienGllmt соответствует правилам бухгалтерской книги.

Это немного философски «когда» учетные данные доли снимаются с регистрации, но я бы сказал это так: отмена регистрации происходит немедленно, но вознаграждение откладывается. Если учетные данные отменены в эпоху e , тогда он получит вознаграждение на границе e / e+1 (исходя из моментального снимка, сделанного на границе e-2 / e -1 ), а также получать награды на границе e+1 / e+2 (исходя из снимка, сделанного на границе e-1 / e ).

JaredCorduan 5 янв. 2021

Похоже, у нас некоторая путаница с номенклатурой.

Из точки зрения dbs-ync ::

tx_epoch_no : эпоха, содержащая транзакции свидетельства о регистрации / отмене регистрации.
active_epoch_no : в основном tx_epoch_no + 2 , эпоха, в которой становятся активными изменения в адресе ставки.
epoch_no в таблице reward : фактическая эпоха, в которую были получены награды.

erikd 5 янв. 2021

если учетные данные доли были в сертификате отмены регистрации транзакции в эпоху 232, то они не будут включены в моментальный снимок, сделанный на границе 232/233. это означает, что это не будет частью обновления награды, которое раздается на границе 235/236. что, по словам @erikd , составляет 234 награды. более того, если сертификат (повторной) регистрации попадет в транзакцию в эпоху 233, то это будет только обновление вознаграждения, которое он пропустит.

JaredCorduan 5 янв. 2021

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

JaredCorduan 5 янв. 2021

Поскольку кажется, что возникла путаница, я сделал изображение, на котором показаны две ожидаемые отсутствующие эпохи (db-sync 231 и db-sync 234).

Я думаю, что путаница возникает из-за того, что 231 технически может не отсутствовать - это может быть состояние бухгалтерской книги, которое просто считает, что он распределен в резервы, а не на пользователя. С точки зрения состояния бухгалтерской книги вознаграждения существуют (распределяются по резервам), но с точки зрения пользователя 231 не следует включать

SebastienGllmt 6 янв. 2021

Я сделал снимок, на котором показаны две ожидаемые отсутствующие эпохи (db-sync 231 и db-sync 234).

Но фактические награды, о которых сообщает db-sync таковы:

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)

и только эпоха 234 не имеет наград. db-sync получает содержимое этой таблицы из состояния реестра, и единственное, что добавляет db-sync - это столбец epoch_no .

Ваша диаграмма не соответствует этой таблице, поэтому ваша диаграмма, скорее всего, неверна. Также может быть ошибка в node (в частности, в вычислении баланса адресного вознаграждения), но я предпочел бы пока иметь дело только с одной переменной ( db-sync ).

erikd 6 янв. 2021

На вашей диаграмме вычеркнуты «награды доставлены» для эпохи 233, и мы с Джаредом считаем, что это неверно и что награды должны быть доставлены (потому что они основаны на снимке в начале эпохи 231, а не на текущем состоянии цепь).

erikd 6 янв. 2021

@SebastienGllmt говорит:

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

Но таблица rewards показывает вознаграждение, распределяемое по адресу ставки. Если бы он был распределен в резервы, его бы не было в этой таблице. db-sync получает эту информацию о вознаграждении в виде карты от адреса ставки до суммы вознаграждения. Само состояние реестра может быть неправильным, но после извлечения карты из состояния реестра остается очень мало места для ошибок.

erikd 6 янв. 2021

Я ошибся, когда сказал:

более того, если сертификат (повторной) регистрации попадет в транзакцию в эпоху 233, то это будет единственное обновление вознаграждения, которое он пропустит.

Фактически, @SebastienGllmt был совершенно прав, когда сказал:

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

Поскольку учетные данные доли не зарегистрированы на границе эпох 232/233, они:

не получает награды от обновления, применяемого на границе 232/233, и
не включен в снимок распределения долей, сделанный на границе 232/233 (так что он не получает награды, раздаваемые на границе 235/236).

Я могу догадаться, как db-sync сообщает о наградах, выдаваемых на границе 232/233 (что на самом деле просто предположение @SebastienGllmt :)). Состояние реестра не может знать до последнего момента перед границей эпохи, какие учетные данные все еще зарегистрированы. Вознаграждения за незарегистрированные учетные данные возвращаем в резерв. (См. Figure 51: Reward Update Application в формальной спецификации ). db-sync, вероятно, не удаляет незарегистрированные учетные данные.

JaredCorduan 6 янв. 2021

Изображение @SebastienGllmt выше выглядит великолепно, но обратите внимание, что на самом деле стрелки должны охватывать другую эпоху, чтобы учесть фазу создания блока. например, награды из снимка, сделанного на границе 230/231, фактически не раздаются до границы 233/234.

JaredCorduan 6 янв. 2021

Хорошо, теперь у нас есть объяснение этому. db-sync поддерживает состояние legder и извлекает награды эпохи как Map StakeAddress Coin которые вставляет в базу данных. Однако эта карта содержит записи StakeAddress которые недействительны, и legder-state отбрасывает эти записи, эффективно возвращая заработанные вознаграждения в резервы.

Решение состоит в том, чтобы также извлечь набор действительных StakeAddress из состояния реестра, а затем отфильтровать Map удалив все записи, которые не встречаются в наборе действительных StakeAddress es.

erikd 6 янв. 2021

Было бы здорово, если бы эти «фантомные» награды были помещены в новую таблицу типа «nondistributed_rewards» или что-то в этом роде. Это позволит правильно рассчитать доходность пула.

dmitrystas 6 янв. 2021

@dmitrystas :

Было бы здорово, если бы эти «фантомные» награды были помещены в новую таблицу типа «nondistributed_rewards» или что-то в этом роде. Это позволит правильно рассчитать доходность пула.

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

Я создал тикет специально для этого вопроса.

erikd 6 янв. 2021

Хорошо, у меня есть решение, которое отфильтровывает недопустимые вознаграждения из списка вознаграждений перед вставкой, и действительно, для этого адреса в эпоху 231 есть вознаграждение.

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

erikd 7 янв. 2021

🚀1

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

и его также нет в таблице вознаграждений:

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)

erikd 8 янв. 2021

👍2

Была ли эта страница полезной?

0 / 5 - 0 рейтинги

Смежные вопросы

Cardano db Sync занимает очень много времени, чтобы вернуть блок вилки

xdzurman · 3Комментарии

Соотнесите вознаграждения и вывод средств обратно в пул

erikd · 4Комментарии

Поддержание БД в актуальном состоянии

kzka90 · 3Комментарии

Странное несоответствие между таблицей наград и таблицей блоков

erikd · 7Комментарии

Наградной стол от нескольких ловеласов

xdzurman · 12Комментарии