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が2つのプールの報酬アドレスとして使用される場合、報酬額は各プールの報酬の合計になります。 私が現在持っているものを考えると、この卵がスクランブルを解除できるかどうかはわかりません。

これはトリッキーなだけでなく、ワームの完全な缶です。

IOHKの内部Slackについて@JaredCorduanとチャットした後、 db-syncのオンチェーンデータの処理が完全に正しくなく、一部のSPOがプールを正しく設定していない可能性があることに気付きました。

まず、プールが、それ自体がステークアドレスとして登録されたことがないステーク/リワードアドレスで登録されている場合、 Shelley DesignSpecのセクション3.3.4のポイント3に従って：

報酬アドレスが登録されていない場合、ステークプールオペレーターは報酬を受け取ることができなくなります。 その場合、彼らが支払うべき報酬は代わりに準備金に送り返されます（ただし、ステークプールのメンバーは通常の報酬を受け取ります）。

次に、2つ以上のプールが同じステーク/リワードアドレスで登録され、2つ以上のプールがリワードを獲得した場合、最初の（「最初の」プールはどのように決定されますか？）プールのリワードのみがアドレスに送られ、残りはすべてに送られます準備金/財務。 これに関する適切なドキュメントはまだ見つかりません。

@erikd昨日お話ししたことが間違っていました、お詫び申し上げます。 私は今日、仕様と実装の両方をチェックしました。これらは同意し、次のように機能します。

ステークプール証明書の報酬勘定：

• 登録する必要がありますか
• 委任する必要はありません

さらに、2つのプールに共通の報酬アカウントがリストされている場合、アカウントは報酬の合計を取得します。

現在、これに対する修正は下位レベルのライブラリにあるようです。 @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)

したがって、奇妙な不一致はなくなり、このチケットを閉じることができます。