Cardano-db-sync: Incompatibilidade estranha entre a tabela de recompensas e a tabela de bloqueio

Isso é diferente de #361. Olhando para o addr_id de cima:

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

Isso significa que este addr_id deve ser o endereço de recompensa para uma atualização de pool que é trivial para confirmar:

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)

Isso significa que esse endereço é o endereço de recompensa para vários pools diferentes. Esta deve ser a questão.

Isso é complicado. Eu tinha uma suposição na minha cabeça de que um único stake_address só poderia delegar para um único pool. Embora isso seja verdade, um único stake_address pode ser usado como endereço de recompensa para mais de um pool.

Na verdade, é mais complicado do que isso. Se um stake_address for usado como endereço de recompensa para dois pools, o valor do prêmio será a soma dos prêmios de cada pool. Dado o que tenho atualmente, não tenho certeza se esse ovo pode ser desembaralhado.

Isso não é apenas complicado, é uma lata completa de vermes.

Depois de conversar no Slack interno da IOHK com @JaredCorduan , percebi que o tratamento de db-sync dos dados on-chain não estava totalmente correto e que alguns SPOs podem não ter configurado seus pools corretamente.

Em primeiro lugar, se um pool estiver registrado com um endereço de aposta/recompensa que nunca foi registrado como um endereço de aposta, então, de acordo com o ponto 3 da seção 3.3.4 do Shelley Design Spec :

Caso o endereço de recompensa não seja registrado, o operador do conjunto de apostas não poderá receber recompensas. Nesse caso, quaisquer recompensas que seriam devidas são enviadas de volta para as reservas (mas os membros do conjunto de apostas ainda receberiam suas recompensas habituais).

Em segundo lugar, se dois ou mais pools estiverem registrados com o mesmo endereço de aposta/recompensa e dois ou mais pools ganharem recompensas, então apenas as recompensas para o primeiro (como é determinado o "primeiro"?) vão para o endereço e todo o resto vai para as reservas/tesouraria. Ainda não encontrei documentação adequada sobre isso.

@erikd o que eu disse ontem estava incorreto, desculpe. Verifiquei a especificação e a implementação hoje, que concordam e funcionam da seguinte maneira.

As contas de recompensa nos certificados do conjunto de apostas:

• precisa ser registrado
• NÃO precisa ser delegado

Além disso, se dois pools listarem uma conta de recompensa comum, a conta recebe a soma das recompensas.

Atualmente, parece que a correção para isso está em uma biblioteca de nível inferior. @JaredCorduan está investigando isso.

Não tenho certeza do que está acontecendo aqui. As coisas mudaram.

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

mas:

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

Essas consultas foram executadas em um banco de dados executando master no commit f7ee30a245131255f816d6952ef6f0b938e61b94

Ah, mas a consulta da tabela de recompensas (que retorna zero entradas) está correta:

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

Assim, a incompatibilidade ímpar se foi e este ticket pode ser fechado.