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 इंटरनल स्लैक पर चैट करने के बाद मैंने महसूस किया कि ऑन-चेन डेटा का db-sync का उपचार पूरी तरह से सही नहीं था और हो सकता है कि कुछ SPO ने अपने पूल को सही तरीके से सेट नहीं किया हो।

सबसे पहले, यदि कोई पूल एक स्टेक/इनाम पते के साथ पंजीकृत है जिसे स्वयं कभी भी स्टेक पते के रूप में पंजीकृत नहीं किया गया है, तो शेली डिज़ाइन स्पेक के खंड 3.3.4 के बिंदु 3 के अनुसार:

क्या इनाम का पता अपंजीकृत होना चाहिए, स्टेक पूल ऑपरेटर पुरस्कार प्राप्त करने में असमर्थ होगा। उस स्थिति में, कोई भी पुरस्कार जो उन्हें देय होगा, बदले में उन्हें वापस भंडार में भेज दिया जाता है (लेकिन स्टेक पूल के सदस्यों को अभी भी उनके सामान्य पुरस्कार प्राप्त होंगे)।

दूसरे, यदि दो या दो से अधिक पूल एक ही हिस्सेदारी/इनाम पते के साथ पंजीकृत हैं और दो या दो से अधिक पूल पुरस्कार अर्जित करते हैं, तो केवल पहले के लिए पुरस्कार ("पहले" कैसे निर्धारित किया जाता है?) पूल पते पर जाता है और बाकी सभी को जाता है रिजर्व / ट्रेजरी। मुझे अभी तक इस पर उचित दस्तावेज नहीं मिले हैं।

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

तो विषम बेमेल समाप्त हो गया है और यह टिकट बंद किया जा सकता है।