Cardano-db-sync: Ketidakcocokan yang aneh antara tabel hadiah dan tabel blok

Ini berbeda dari #361. Melihat addr_id dari atas:

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

Itu berarti addr_id ini harus menjadi alamat hadiah untuk pembaruan kumpulan yang sepele untuk dikonfirmasi:

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)

Itu berarti alamat ini adalah alamat hadiah untuk sejumlah kumpulan yang berbeda. Ini harus menjadi masalah.

Ini rumit. Saya memiliki asumsi di kepala saya bahwa satu stake_address hanya dapat didelegasikan ke satu kumpulan. Meskipun itu benar, satu stake_address dapat digunakan sebagai alamat hadiah untuk lebih dari satu kumpulan.

Ini sebenarnya lebih rumit dari itu. Jika stake_address digunakan sebagai alamat hadiah untuk dua kumpulan, jumlah hadiah akan menjadi jumlah hadiah untuk setiap kumpulan. Mengingat apa yang saya miliki saat ini, saya tidak yakin telur ini dapat diurai.

Ini bukan hanya rumit, ini adalah kaleng cacing yang lengkap.

Setelah mengobrol di Slack internal IOHK dengan @JaredCorduan, saya menyadari bahwa perlakuan db-sync terhadap data on-chain tidak sepenuhnya benar dan bahwa beberapa SPO mungkin tidak menyiapkan kumpulan mereka dengan benar.

Pertama, jika kumpulan terdaftar dengan alamat pasak/hadiah yang belum pernah terdaftar sebagai alamat pasak, maka menurut poin 3 atau bagian 3.3.4 dari Spesifikasi Desain Shelley :

Jika alamat hadiah tidak terdaftar, operator kumpulan pasak tidak akan dapat menerima hadiah. Dalam hal ini, hadiah apa pun yang seharusnya jatuh tempo malah dikirim kembali ke cadangan (tetapi anggota kelompok pasak masih akan mendapatkan hadiah seperti biasanya).

Kedua, jika dua atau lebih kumpulan terdaftar dengan alamat taruhan/hadiah yang sama dan dua atau lebih kumpulan mendapatkan hadiah, maka hanya hadiah untuk kumpulan pertama (bagaimana ditentukan "pertama"?) yang pergi ke alamat dan sisanya masuk ke cadangan/bendahara. Saya belum menemukan dokumentasi yang tepat tentang ini.

@erikd apa yang saya katakan kemarin salah, maaf. Saya memeriksa spesifikasi dan implementasi hari ini, yang setuju dan berfungsi sebagai berikut.

Akun hadiah di sertifikat kumpulan pasak:

• perlu didaftarkan
• TIDAK perlu didelegasikan

Selain itu, jika dua kumpulan mencantumkan akun hadiah umum, akun tersebut mendapatkan jumlah hadiah.

Saat ini sepertinya perbaikan untuk ini ada di perpustakaan tingkat yang lebih rendah. @JaredCorduan sedang menyelidikinya.

Tidak yakin apa yang terjadi di sini. Hal-hal telah berubah.

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

tetapi:

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

Kueri ini dijalankan terhadap database yang menjalankan master pada commit f7ee30a245131255f816d6952ef6f0b938e61b94

Ah, tetapi kueri tabel hadiah (yang mengembalikan nol entri) benar:

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

Jadi ketidakcocokan aneh hilang dan tiket ini bisa ditutup.