:चेहरे की हथेली:

थोड़ी देर के लिए इसे देखा और फिर अचानक महसूस किया कि पहली क्वेरी यह नहीं दिखाती है कि @dmitrystas क्या सोचता है कि यह दिखाता है। tx.id = stake_registration.tx_id शामिल होने और फिर लेन-देन से block.epoch_no प्राप्त करने से, आपको वह युग मिलता है जब हिस्सेदारी पंजीकरण/विपंजीकरण होता है, लेकिन तब नहीं जब यह वास्तव में सक्रिय होता है ।

स्टेकिंग से संबंधित अधिकांश कार्यों के लिए, N युग में होने वाली कार्रवाइयाँ (जैसे पंजीकरण, दांव की राशि में वृद्धि आदि) युग में सक्रिय हो जाती हैं N + 2 ।

इसका मतलब है कि पहली क्वेरी वास्तव में होनी चाहिए:

cexplorer=# SELECT stake_registration.addr_id, block.epoch_no + 2 as epoch_no, block.time FROM stake_address 
              INNER JOIN stake_registration ON stake_registration.addr_id = stake_address.id 
              INNER JOIN tx ON tx.id = stake_registration.tx_id INNER JOIN block ON block.id = tx.block_id
              WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';
addr_id | epoch_no |        time         
---------+----------+---------------------
   38266 |      210 | 2020-08-01 07:45:51
   38266 |      235 | 2020-12-01 22:31:13

और दूसरा:

cexplorer=# SELECT stake_deregistration.addr_id, block.epoch_no + 2 as epoch_no, block.time FROM stake_address
              INNER JOIN stake_deregistration ON stake_deregistration.addr_id = stake_address.id
              INNER JOIN tx ON tx.id = stake_deregistration.tx_id INNER JOIN block ON block.id = tx.block_id
              WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';
 addr_id | epoch_no |        time         
---------+----------+---------------------
   38266 |      234 | 2020-12-01 18:25:59

@dmitrystas क्या यह सब जोड़ता है? क्या यह active_epoch_no कॉलम को stake_registration और stake_deregistration टेबल में जोड़ने में मदद करेगा जैसे कि मेरे पास delegation टेबल है?

@erikd शुभ दिन। वह मूल मुद्दा है https://github.com/Emurgo/yoroi-frontend/issues/1832#issue -754776885
शायद उपयोगी हो सकता है

Yoroi और Adalite गलत 192 FAKE ADA इनाम दिखाते हैं लेकिन वास्तव में यह 0 है। अंतिम 2 पुरस्कार adawallet.io के माध्यम से वापस ले लिए जाते हैं (यह db-sync का उपयोग नहीं करता है)

चरणों में समस्या का संक्षिप्त विवरण:
१) युग २३२ । मैं एक ही समय में पुरस्कार वापस लेता हूं और स्टेकिंग कुंजी को
२) युग २३३ । यदि मेरी कुंजी पंजीकृत की गई थी, तो मुझे पहला शेष इनाम प्राप्त करना चाहिए, लेकिन ऐसा नहीं है, लेकिन योरोई दिखाता है कि 192ADA प्राप्त हुआ है। जब मैं वापस लेने का प्रयास करता हूं तो योरोई एक त्रुटि फेंकता है। अन्य वॉलेट जो डीबी-सिंक का उपयोग नहीं करते हैं वे इनाम 0ADA दिखाते हैं
३) युग २३३ । मैं फिर से उसी पूल में जाता हूं। कुंजी पंजीकृत है । सच्चा पुरस्कार 0. योरोई पुरस्कार 192।
४) युग २३४ । मुझे दूसरा शेष इनाम 135ADA मिलता है। ट्रू रिवॉर्ड बैलेंस 135ADA है।
योरोई 327ADA (192+135) दिखाता है। योरोई के माध्यम से किसी भी इनाम को वापस नहीं ले सकते हैं मुझे लेनदेन भेजते समय सर्वर से त्रुटि मिली है।
५) युग २३५ । मुझे अंतिम तीसरा इनाम 145ADA मिला है। ट्रू रिवॉर्ड बैलेंस 280ADA (135+145) है।
Yoroi दिखाता है 472ADA (192+135+145) Yoroi के माध्यम से किसी भी इनाम को वापस नहीं ले सकता है मुझे लेनदेन भेजते समय सर्वर से प्राप्त त्रुटि है।
६) युग २३५ । मैं adawallet.io के माध्यम से 280ADA को सुचारू रूप से वापस लेता हूं जो db-syns का उपयोग नहीं करता है और सही ढंग से इनाम शेष 280ADA दिखाता है
७) २८०एडीए के सच्चे पुरस्कार वापस ले लिए जाने के बाद (0एडीए रहता है) योरोई अभी भी १९२एडीए का इनाम दिखाता है।

योरोई अभी भी इनाम शेष 192ADA दिखाता है।

कम से कम दो संभावनाएं हैं;

• एक db-sync बग है
• एक योरोई बग है

मैं केवल db-sync निपटता हूं। इसका मतलब है कि समस्याओं को मुझे SQL प्रश्नों के रूप में प्रस्तुत करने की आवश्यकता है न कि योरोई की जानकारी के रूप में।

क्या stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 यहां ब्याज की हिस्सेदारी की कुंजी है?

@erikd हाँ हिस्सेदारी कुंजी है हिस्सेदारी1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86
ध्यान दें कि न केवल योरोई में वह बग है बल्कि Adalite.io और adastat.net
उनके पास वह बग नहीं है: cardanoscan.io और adawallet.io

यदि कुछ ऑनलाइन वॉलेट में यह बग है और अन्य में नहीं है, और ये सभी db-sync पर निर्भर हैं तो समस्या db-sync में होने की संभावना नहीं है।

@erikd लेकिन adawallet.io db-sync का उपयोग नहीं करता है और सही रिवॉर्ड बैलेंस (0ADA) दिखाता है और यह मुझे अंतिम पुरस्कार वापस लेने देता है

फिर से पता चलता है कि यह एक योरोई बग है, न कि db-sync बग।

एक्सोडस को भी इस बग का सामना करना पड़ा।

यह निश्चित रूप से एक कार्डानो-डीबी-सिंक बग है और योरोई बग नहीं है, यह देखते हुए कि यह न केवल योरोई बल्कि कार्डानो-डीबी-सिंक के कई अन्य उपयोगकर्ताओं को भी प्रभावित करता है। कार्डानोस्कैन और एडवालेट दोनों कार्डानो-डीबी-सिंक का उपयोग नहीं करते हैं, इसलिए वे प्रभावित नहीं होते हैं।

क्या कार्डानो-डीबी-सिंक रिपोर्ट करता है

यहाँ SQL क्वेरी है जो @IlyaSofronov . द्वारा

select stake_address.hash_raw as "stakeAddress"
      , "totalReward".*

from stake_address

left outer join (
  SELECT addr_id, amount, epoch_no
  FROM reward
) as "totalReward" on stake_address.id = "totalReward".addr_id

where encode(stake_address.hash_raw, 'hex') = 'e1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde'

और निम्नलिखित परिणाम देता है

 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 192969560 |      231
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236

नोट : इन पंक्तियों का योग 3,765,004,402 . है

हमारे बैकएंड से वर्तमान (गलत) स्थिति

{
    "remainingAmount": "193172340",
    "rewards": "3765004402",
    "withdrawals": "3571832062",
}

आप देख सकते हैं कि हमारा बैकएंड rewards मान के लिए डीबी-सिंक पंक्तियों का योग लौटाता है (यह समझाएगा कि यह समस्या बाद में क्यों है)

आप यह भी सत्यापित कर सकते हैं कि withdrawals राशि कार्डनोस्कैन पर मूल्यों को जोड़कर सही है, जिसे हम जानते हैं कि इस बग से प्रभावित नहीं है।

remainingAmount सिर्फ rewards - withdrawals

वॉलेट के लिए पंजीकरण इतिहास

इस स्टेकिंग कुंजी के इतिहास को देखकर, आप देख सकते हैं:

• इसे युग 232 . पर अपंजीकृत किया गया था
• यह युग 233 . पर फिर से पंजीकृत किया गया था

कार्डानो-नोड से वर्तमान स्थिति

मेरे कार्डानो-नोड उदाहरण के अनुसार, यह स्टेकिंग पते के अंदर का वर्तमान मूल्य है

[
    {
        "address": "stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86",
        "delegation": "pool1kkfkdces5mdcyc9dn2hgg3463jggjvw3h89nejjarkz25uavaqu",
        "rewardAccountBalance": 202780
    }
]

तो आप देख सकते हैं कि नोड के अनुसार, बटुए का संतुलन युग २३५ + युग २३६ (१००७०२ + १०२०७८ = २०२७८०) है

तो मुद्दा क्या है?

कार्डानोस्कैन को

| युग वापस ले लिया | निकाली गई राशि | डीबी-सिंक युग पंक्तियों में शामिल हैं |
|-----------------|------------------|--------------- -----------------|
| 228 | २६०१.३७३१४४ | २११, २१२, ..., २२५, २२६ |
| 230 | 371.141369 | २२७, २२८ |
| 232 | ३१७.६४१५७० | २२९, २३० |
| 234 | १३५.७११४३४ | 232 |
| 235 | 145.964545 | 233 |

फिर भी आप कार्डानो-डीबी-सिंक में युग २३१ देख सकते हैं (१९२९६९५६०) इनमें से किसी में भी शामिल नहीं है!

निश्चित रूप से, यदि आप हमारी बैकएंड प्रतिक्रिया, "remainingAmount": "193172340", और आप गलती से शामिल युग 231 को हटा देते हैं, तो आपको 193172340 - 192969560 = 202780 जो कि हमारे फुलनोड से अपेक्षित परिणाम है!

निष्कर्ष

मेरी जांच के आधार पर, ऐसा लगता है कि कार्डानो-डीबी-सिंक में इनाम इतिहास परिणाम में पंक्ति २३१ शामिल है, भले ही ऐसा नहीं होना चाहिए।

मैंने पहली क्वेरी को सरल बनाया और पुष्टि की कि मुझे वही परिणाम मिलते हैं (मैंने किया)।

हमारे बैकएंड से वर्तमान (गलत) स्थिति

मैं एक ही स्रोत से सभी जानकारी प्राप्त करना पसंद करूंगा ताकि:

cexplorer=# select sum (amount) from stake_address
        left outer join (SELECT addr_id, amount, epoch_no 
        FROM reward) as "totalReward" on stake_address.id = "totalReward".addr_id
        where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
    sum     
------------
 3765004402

तथा:

cexplorer=# select sum (amount) from withdrawal where addr_id = 38266;
    sum     
------------
 3571832062

जो दोनों आपके आंकड़ों से सहमत हैं।

दिलचस्प बात यह है कि 3571832062 + 192969560 + 202780 - 3765004402 जहां 3571832062 निकासी राशि है और 3765004402 इनाम राशि है। अन्य मूल्य हैं; 202780 जो निकासी के बाद इनाम की शेष राशि के लिए आपका आंकड़ा है और 192969560 युग के लिए पुरस्कार है 231 ।

cexplorer=# select stake_address.view as "stakeAddress", "totalReward".* from stake_address
     left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde'
     and epoch_no = 231 ;
                        stakeAddress                         | addr_id |  amount   | epoch_no 
-------------------------------------------------------------+---------+-----------+----------
 stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 |   38266 | 192969560 |      231

तो क्या उस युग के लिए इनाम 231 (जो db-sync बस लेज़र स्थिति से बाहर निकलता है और शून्य अतिरिक्त प्रसंस्करण के साथ डेटाबेस में सम्मिलित करता है) सही है? आइए उस स्टेक पते के लिए स्टेक पंजीकरण इतिहास को देखें:

cexplorer=# select stake_address.hash_raw, stake_registration.tx_id, block.epoch_no
    as tx_epoch_no, (block.epoch_no + 2) as active_epoch_no
    from stake_registration inner join stake_address on stake_registration.addr_id = stake_address.id 
    inner join tx on tx.id = stake_registration.tx_id inner join block on tx.block_id = block.id
    where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                           hash_raw                           |  tx_id  | tx_epoch_no | active_epoch_no 
--------------------------------------------------------------+---------+-------------+-----------------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde | 2449294 |         208 |             210
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde | 3103705 |         233 |             235
(2 rows)

cexplorer=# select stake_address.hash_raw, stake_deregistration.tx_id, block.epoch_no
    as tx_epoch_no, (block.epoch_no + 2) as active_epoch_no from stake_deregistration
    inner join stake_address on stake_deregistration.addr_id = stake_address.id
    inner join tx on tx.id = stake_deregistration.tx_id inner join block
    on tx.block_id = block.id
    where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                           hash_raw                           |  tx_id  | tx_epoch_no | active_epoch_no 
--------------------------------------------------------------+---------+-------------+-----------------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde | 3101670 |         232 |             234

ध्यान दें कि पंजीकरण और अपंजीकरण दोनों के लिए मैंने tx_id (tx की आईडी जिसमें पंजीकरण/विपंजीकरण शामिल है), tx_epoch_no (वह युग जिसमें tx शामिल किया गया था) और active_epoch_no (वह युग जिसमें पंजीकरण/पंजीकरण सक्रिय हो जाता है)।

सक्रिय युग संख्या को देखते हुए, दांव पंजीकरण अवधियों में सक्रिय किया जाना चाहिए था [210 .. 233] और [235 ..] । यह इस पते के लिए वास्तविक पुरस्कारों से मेल खाता है:

cexplorer=# select stake_address.hash_raw as "stakeAddress", "totalReward".* from stake_address
    left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                         stakeAddress                         | addr_id |  amount   | epoch_no 
--------------------------------------------------------------+---------+-----------+----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 192969560 |      231
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236
(25 rows)

यानी, 234 को छोड़कर हर युग के लिए पुरस्कार हैं।

इसलिए मुझे लगता है कि आपका निष्कर्ष:

मेरी जांच के आधार पर, ऐसा लगता है कि कार्डानो-डीबी-सिंक में इनाम इतिहास परिणाम में पंक्ति २३१ शामिल है, भले ही ऐसा नहीं होना चाहिए।

गलत है, उस हिस्सेदारी के पते में युग 231 लिए पुरस्कार होना चाहिए ।

इसके अलावा, मुझे विश्वास है कि आपकी टिप्पणी:

हमारे बैकएंड से वर्तमान (गलत) स्थिति
{
"शेष राशि": "193172340",
"पुरस्कार": "३७६५००४४०२",
"निकासी": "३५७१८३२०६२",
}

वास्तव में सही है। रिवॉर्ड वैल्यू और विदड्रॉल वैल्यू के बीच का अंतर मौजूदा अनवार्ड रिवॉर्ड बैलेंस है।

वास्तव में सही है। रिवॉर्ड वैल्यू और विदड्रॉल वैल्यू के बीच का अंतर मौजूदा अनवार्ड रिवॉर्ड बैलेंस है।

ऐसा नहीं हो सकता क्योंकि हम जानते हैं कि नोड 202780 को खाते के लिए इनाम की शेष राशि के रूप में लौटाता है न कि 193172340

यानी, 234 को छोड़कर हर युग के लिए पुरस्कार हैं।

आपको दो युगों के गायब होने की उम्मीद करनी चाहिए:

1. वह युग जहां पुरस्कारों को भंडार में वापस भेज दिया गया था क्योंकि उनके पास अपनी हिस्सेदारी कुंजी पंजीकृत नहीं थी
2. जब उन्होंने अपनी कुंजी को अपंजीकृत किया और जब उन्होंने फिर से पंजीकृत किया, तब के बीच 1 युग के अंतर का प्रतिनिधित्व करने वाला युग

लापता 234 युग (2) से मेल खाता है, और मेरा मानना ​​है कि २३१ से मेल खाती है (१) क्योंकि २३१ का अर्थ है कि यह २३३ युग में उपयोगकर्ता के बटुए में दिखाई देना चाहिए, जो ठीक उसी युग का है जिसकी हम उम्मीद करते हैं। (1)

आपको दो युगों के गायब होने की उम्मीद करनी चाहिए:

क्यों? इस हिस्सेदारी पते पर संचालन के अनुसार:

| ऑपरेशन | tx_epoch_no | active_epoch_no |
|-------------------|---------------------|---------- ---------|
| पंजीकरण | 208 | 210 |
| पंजीकरण रद्द | 232 | 234 |
| पंजीकरण | 233 | 235 |

इसे केवल एक युग ( 234 ) के लिए अपंजीकृत किया गया था और उस युग के लिए कोई पुरस्कार नहीं मिला था।

पुरस्कार के बिना दो युग क्यों होंगे? मुझे पूरा यकीन है कि आपने जिन दो मामलों का उल्लेख किया है, वे वास्तव में एक ही बात हैं और इसलिए केवल एक युग बिना किसी इनाम के जाता है।

स्लैक में @SebastienGllmt ने कहा:

अपंजीकरण इस मायने में खास है कि यह तुरंत हो जाता है, 2 युगों में नहीं

अगर पंजीकरण रद्द करने की प्रक्रिया तुरंत तेज हो जाती है, तो यह tx_epoch_no == 232 में हुआ, [231..234] के पुरस्कार सभी खो जाएंगे, न कि केवल 231 के लिए पुरस्कार।

मुझे लगता है कि हमें इस पर @JaredCorduan की जरूरत है।

@SebastienGllmt की व्याख्या खाता बही नियमों के अनुरूप है।

यह थोड़ा दार्शनिक है "जब" एक हिस्सेदारी क्रेडेंशियल को अपंजीकृत किया जाता है, लेकिन मैं इसे इस तरह से वाक्यांश दूंगा: डीरजिस्ट्रेशन तुरंत होता है, लेकिन पुरस्कार में देरी होती है। यदि किसी क्रेडेंशियल को युग e में डी-पंजीकृत किया जाता है, तो उसे e / e+1 सीमा ( e-2 / e -1 सीमा पर लिए गए स्नैपशॉट से आने वाले) पर पुरस्कार प्राप्त होंगे और यह भी e+1 / e+2 सीमा पर पुरस्कार प्राप्त करें ( e-1 / e सीमा पर लिए गए स्नैपशॉट से आ रहा है)।

ऐसा लगता है कि हमें नामकरण के साथ कुछ भ्रम है।

dbs-ync के पीओवी से : :

• tx_epoch_no : पंजीकरण/विपंजीकरण प्रमाणपत्र के लेन-देन वाला युग।
• active_epoch_no : मूल रूप से tx_epoch_no + 2 , वह युग जिसमें हिस्सेदारी के पते में परिवर्तन सक्रिय हो जाते हैं।
• epoch_no में reward तालिका: वास्तविक युग जिसमें पुरस्कार अर्जित किए गए थे।

यदि हिस्सेदारी क्रेडेंशियल युग 232 में लेन-देन से पंजीकरण रद्द करने के प्रमाणपत्र में था, तो इसे 232/233 सीमा पर लिए गए स्नैपशॉट में शामिल नहीं किया जाएगा। इसका मतलब है कि यह 235/236 की सीमा पर दिए गए रिवॉर्ड अपडेट का हिस्सा नहीं होगा। जो, @erikd के शब्दों में, 234 पुरस्कार है। इसके अलावा, यदि (पुनः) पंजीकरण प्रमाणपत्र युग २३३ में लेन-देन में आता है, तो यह _only_ इनाम अपडेट होगा जिससे यह छूट जाएगा।

यह ध्यान देने योग्य है कि "डी-पंजीकृत कब", "पुरस्कार पर", और "सक्रिय कब", आदि जैसी चीजें भ्रमित हो सकती हैं यदि हम वास्तव में स्पष्ट नहीं हैं। तो यह मेरे लिए स्पष्ट नहीं है कि मैं किसके साथ सहमत हूं :)

चूंकि भ्रम की स्थिति प्रतीत होती है, इसलिए मैंने एक चित्र बनाया जो दो अपेक्षित लापता युगों को दिखाता है (डीबी-सिंक २३१ और डीबी-सिंक २३४)

मुझे लगता है कि भ्रम इस तथ्य से आता है कि 231 तकनीकी रूप से गायब नहीं हो सकता है - यह खाता बही राज्य हो सकता है जो इसे उपयोगकर्ता के बजाय भंडार में वितरित करता है। लेज़र स्थिति के दृष्टिकोण से, पुरस्कार मौजूद हैं (रिज़र्व में वितरित), लेकिन उपयोगकर्ता के दृष्टिकोण से 231 को शामिल नहीं किया जाना चाहिए

मैंने एक तस्वीर बनाई जो दो अपेक्षित लापता युगों को दिखाती है (डीबी-सिंक २३१ और डीबी-सिंक २३४)

लेकिन db-sync द्वारा बताए गए वास्तविक पुरस्कार हैं:

cexplorer=# select stake_address.hash_raw as "stakeAddress", "totalReward".* from stake_address
    left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                         stakeAddress                         | addr_id |  amount   | epoch_no 
--------------------------------------------------------------+---------+-----------+----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 192969560 |      231
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236
(25 rows)

और केवल युग 234 का कोई पुरस्कार नहीं है। db-sync लेज़र-स्टेट से इस तालिका की सामग्री प्राप्त करता है और केवल db-sync जोड़ता है epoch_no कॉलम।

आपका आरेख इस तालिका से मेल नहीं खाता है, इसलिए आपका आरेख संभवतः गलत है। node (विशेष रूप से पता इनाम शेष राशि गणना) में एक बग भी हो सकता है, लेकिन मैं अभी के लिए केवल एक चर ( db-sync ) से निपटना पसंद करूंगा।

आपके आरेख में आपने युग 233 के लिए "पुरस्कार वितरित" किया है, और जेरेड और मुझे लगता है कि दोनों गलत हैं और पुरस्कार वितरित किए जाने चाहिए (क्योंकि वे युग 231 की शुरुआत में स्नैपशॉट पर आधारित हैं, न कि वर्तमान स्थिति श्रृंखला)।

@SebastienGllmt कहते हैं:

मुझे लगता है कि भ्रम इस तथ्य से आता है कि 231 तकनीकी रूप से गायब नहीं हो सकता है - यह खाता बही राज्य हो सकता है जो इसे उपयोगकर्ता के बजाय भंडार में वितरित करता है।

लेकिन rewards तालिका से पता चलता है कि इनाम को हिस्सेदारी के पते पर वितरित किया जा रहा है। यदि इसे भंडार में वितरित किया जाता, तो यह इस तालिका में नहीं होता। db-sync इस इनाम की जानकारी स्टेक पते से इनाम राशि तक के नक्शे के रूप में प्राप्त करता है। अब लेज़र स्थिति स्वयं गलत हो सकती है, लेकिन लेज़र स्थिति से नक्शा पुनर्प्राप्त करने के बाद त्रुटियों के लिए बहुत कम जगह है।

मैं गलत था जब मैंने कहा:

इसके अलावा, यदि (पुनः) पंजीकरण प्रमाणपत्र युग २३३ में एक लेन-देन में उतरा, तो यह एकमात्र इनाम अपडेट होगा जिससे यह छूट जाएगा।

वास्तव में, @SebastienGllmt बिल्कुल सही थे जब उन्होंने कहा:

आपको दो युगों के गायब होने की उम्मीद करनी चाहिए:

1. वह युग जहां पुरस्कारों को भंडार में वापस भेज दिया गया था क्योंकि उनके पास अपनी हिस्सेदारी कुंजी पंजीकृत नहीं थी
2. जब उन्होंने अपनी कुंजी को अपंजीकृत किया और जब उन्होंने फिर से पंजीकृत किया, तब के बीच 1 युग के अंतर का प्रतिनिधित्व करने वाला युग

२३२/२३३ युग सीमा पर पंजीकृत नहीं होने से, हिस्सेदारी क्रेडेंशियल दोनों:

• 232/233 सीमा पर लागू किए जा रहे अद्यतन से पुरस्कार नहीं मिलता है, और
• 232/233 सीमा पर लिए गए हिस्सेदारी वितरण स्नैपशॉट में शामिल नहीं है (ताकि इसे 235/236 सीमा पर दिए गए पुरस्कार न मिले)।

मुझे लगता है कि कैसे db-सिंक पुरस्कार रिपोर्ट कर रहा है 232/233 सीमा पर सौंप दिया जा रहा है (जो वास्तव में सिर्फ @SebastienGllmt के अनुमान :)) कर सकते हैं। लेज़र स्टेट युग सीमा से पहले अंतिम क्षण तक नहीं जान सकता है कि कौन से क्रेडेंशियल अभी भी पंजीकृत हैं। हम अपंजीकृत क्रेडेंशियल के लिए रिज़र्व को पुरस्कार लौटाते हैं। ( औपचारिक कल्पना में Figure 51: Reward Update Application देखें)। डीबी-सिंक शायद अपंजीकृत क्रेडेंशियल्स को नहीं हटा रहा है।

@SebastienGllmt की ऊपर की तस्वीर बहुत अच्छी लगती है, लेकिन ध्यान दें कि वास्तव में ब्लॉक उत्पादन चरण के लिए तीरों को एक और युग की आवश्यकता होती है। उदाहरण के लिए, 230/231 सीमा पर लिए गए स्नैपशॉट से पुरस्कार वास्तव में 233/234 सीमा तक नहीं दिए जाते हैं।

ठीक है अब हमारे पास इसका स्पष्टीकरण है। db-sync लेगडर-स्टेट को बनाए रखता है और युग के पुरस्कारों को Map StakeAddress Coin रूप में निकालता है जिसे वह डेटाबेस में सम्मिलित करता है। हालाँकि, उस मानचित्र में StakeAddress प्रविष्टियाँ हैं जो मान्य नहीं हैं और लेगडर-स्टेट इन प्रविष्टियों को प्रभावी रूप से आरक्षित में अर्जित पुरस्कारों में योगदान करने वाले को छोड़ देगा।

समाधान यह है कि वैध StakeAddress को लेज़र स्थिति से खींच लिया जाए और फिर Map को फ़िल्टर करके उन सभी प्रविष्टियों को छोड़ दिया जाए जो वैध StakeAddress es के सेट में नहीं होती हैं।

यह बहुत अच्छा होगा यदि इस 'प्रेत' पुरस्कार को 'nondistributed_rewards' या कुछ इस तरह की नई तालिका में रखा जाएगा। यह हमें पूल की लाभप्रदता की सही गणना करने की अनुमति देगा

@dmitrystas :

यह बहुत अच्छा होगा यदि इस 'प्रेत' पुरस्कार को 'nondistributed_rewards' या कुछ इस तरह की नई तालिका में रखा जाएगा। यह हमें पूल लाभप्रदता की सही गणना करने की अनुमति देगा।

मैं देख सकता हूं कि इन अवितरित पुरस्कारों (जो रिजर्व में वापस जाते हैं) का उपयोग चुनावी लाभप्रदता की गणना के लिए किया जा सकता है, लेकिन मुझे पूरा यकीन है कि यह गणना करने का सबसे अच्छा या आसान तरीका नहीं है।

मैंने इस मुद्दे के लिए विशेष रूप से एक टिकट बनाया

ठीक है, मेरे पास एक समाधान है जो डालने से पहले पुरस्कार सूची से अमान्य पुरस्कारों को फ़िल्टर करता है और वास्तव में उस पते के लिए युग 231 में इनाम है।

अब मुझे इसे संशोधित करने की आवश्यकता है ताकि इन "अमान्य" पुरस्कारों को एक अलग तालिका में जोड़ा जा सके।

पीआर #469 में db-sync के संस्करण का उपयोग करना। हिस्सेदारी पते के लिए इनाम \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde को orphaned_rewards तालिका में सही ढंग से डाला गया है:

cexplorer=# select stake_address.hash_raw, orphaned_reward.epoch_no, orphaned_reward.amount
         from orphaned_reward inner join stake_address on stake_address.id = orphaned_reward.addr_id
         where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde'; 
                           hash_raw                           | epoch_no |  amount   
--------------------------------------------------------------+----------+-----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |      231 | 192969560

और यह पुरस्कार तालिका से भी अनुपस्थित है:

cexplorer=# select stake_address.hash_raw as "stakeAddress", "totalReward".* from stake_address
    left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                         stakeAddress                         | addr_id |  amount   | epoch_no 
--------------------------------------------------------------+---------+-----------+----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |        65 |      238
(25 rows)