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作为两个矿池的奖励地址，则奖励金额将是每个矿池的奖励之和。 鉴于我目前拥有的东西，我不确定这个鸡蛋是否可以解读。

这不仅仅是棘手的问题，它是一个完整的蠕虫罐头。

在与@JaredCorduan在 IOHK 内部 Slack 上聊天后，我意识到db-sync对链上数据的处理并不完全正确，并且一些 SPO 可能没有正确设置他们的池。

首先，如果一个矿池注册了一个权益/奖励地址，而该地址本身从未注册为权益地址，那么根据雪莱设计规范的第 3 点和第 3.3.4 节：

如果奖励地址未注册，权益池运营商将无法获得奖励。 在这种情况下，他们应得的任何奖励都会被送回储备金（但权益池成员仍将获得他们通常的奖励）。

其次，如果两个或更多矿池注册到相同的质押/奖励地址，并且两个或更多矿池获得奖励，那么只有第一个（“第一”如何确定？）矿池的奖励进入该地址，其余所有进入储备金/国库。 我还没有找到这方面的适当文件。

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

这些查询是针对在提交f7ee30a245131255f816d6952ef6f0b938e61b94时运行master的数据库运行的

啊，但是奖励表的查询（返回零条目）是正确的：

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

所以奇怪的不匹配消失了，这张票可以关闭。