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

Это отличается от # 361. Глядя на addr_id сверху:

cexplorer=# select * from delegation where addr_id = 92628 ;
 id | addr_id | cert_index | pool_hash_id | active_epoch_no | tx_id 
----+---------+------------+--------------+-----------------+-------
(0 rows)

Это означает, что этот addr_id должен быть адресом вознаграждения за обновление пула, что тривиально для подтверждения:

cexplorer=# select id, hash_id, pledge, margin, fixed_cost, active_epoch_no, reward_addr_id
              from pool_update where reward_addr_id = 92628 ;
  id  | hash_id | pledge | margin | fixed_cost | active_epoch_no | reward_addr_id 
------+---------+--------+--------+------------+-----------------+----------------
 4621 |    1245 |      0 |      1 |  340000000 |             218 |          92628
 4622 |    1246 |      0 |      1 |  340000000 |             218 |          92628
 4623 |    1247 |      0 |      1 |  340000000 |             218 |          92628
 4624 |    1248 |      0 |      1 |  340000000 |             218 |          92628
 4625 |    1249 |      0 |      1 |  340000000 |             218 |          92628
 4626 |    1250 |      0 |      1 |  340000000 |             218 |          92628
 5683 |    1245 |      0 |      1 |  340000000 |             224 |          92628
 5684 |    1246 |      0 |      1 |  340000000 |             224 |          92628
 5685 |    1247 |      0 |      1 |  340000000 |             224 |          92628
(9 rows)

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

Это сложно. У меня в голове было предположение, что один stake_address может делегировать только одному пулу. Хотя это правда, один stake_address можно использовать в качестве адреса вознаграждения для более чем одного пула.

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

Это не просто сложно, это полная ерунда.

После разговора во внутреннем Slack IOHK с @JaredCorduan я понял, что db-sync обрабатывает внутрисетевые данные не совсем правильно и что некоторые SPO, возможно, неправильно настроили свои пулы.

Во-первых, если пул зарегистрирован с адресом доли/вознаграждения, который сам никогда не был зарегистрирован в качестве адреса доли, то в соответствии с пунктом 3 или разделом 3.3.4 спецификации Shelley Design :

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

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

@erikd то, что я сказал тебе вчера, было неверным, извини. Сегодня я проверил как спецификацию, так и реализацию, которые согласуются и работают следующим образом.

Счета вознаграждения в сертификатах пула ставок:

• нужно быть зарегистрированным
• НЕ нужно делегировать

Более того, если в двух пулах указана общая учетная запись вознаграждения, учетная запись получает сумму вознаграждений.

В настоящее время похоже, что исправление для этого находится в библиотеке более низкого уровня. @JaredCorduan изучает это.

Не уверен, что здесь происходит. Времена изменились.

> select * from pool_hash
      where pool_hash.hash_raw = '\x964d8d35d91603e0dcfbc64891ee8ffeba0e503ca96bf627bc8bcb55' ;
  id  |                          hash_raw                          |                           view                           
------+------------------------------------------------------------+----------------------------------------------------------
 4626 | \x964d8d35d91603e0dcfbc64891ee8ffeba0e503ca96bf627bc8bcb55 | pool1jexc6dwezcp7ph8mceyfrm50l6aqu5pu494lvfau309422t9c6z

но:

> select reward.* from pool_hash
      inner join reward on reward.pool_id = pool_hash.id
      where pool_hash.hash_raw = '\x964d8d35d91603e0dcfbc64891ee8ffeba0e503ca96bf627bc8bcb55' ;
 id | addr_id | amount | epoch_no | pool_id | block_id | type 
----+---------+--------+----------+---------+----------+------
(0 rows)

Эти запросы были запущены для базы данных, работающей на master при фиксации f7ee30a245131255f816d6952ef6f0b938e61b94

Ах, но запрос таблицы вознаграждений (который возвращает ноль записей) правильный:

> select block.block_no, slot_leader.pool_hash_id
              from block inner join slot_leader on block.slot_leader_id = slot_leader.id
              where pool_hash_id = 4626 ;
 block_no | pool_hash_id 
----------+--------------
(0 rows)

Таким образом, нечетное несоответствие исчезло, и этот тикет можно закрыть.