Cardano-db-sync: खाता शेष उदाहरण

मेरी ओर से इस मुद्दे को खोलने के लिए धन्यवाद! बस थोड़ा और स्पष्ट करने के लिए - यह केवल खाते के बारे में नहीं है, बल्कि मुख्य रूप से डीबी में कहीं भी reap को ट्रैक करने के बारे में है, इसलिए इसे आसानी से खाता शेष की गणना में उपयोग किया जा सकता है (जिसका उपयोग हर जगह किया जाता है, उदाहरण के लिए पूल लाइव हिस्सेदारी का आकार, पूल लाइव प्रतिज्ञा, आदि)।

@1000101 "रीप" क्या है? "रीप" नामक डीबी-सिंक में कोई टेबल या कॉलम नहीं है।

खाता शेष तुच्छ नहीं है।

शेली और बाद के युगों में पतों के दो घटक होते हैं; एक भुगतान क्रेडेंशियल और एक स्टेकिंग क्रेडेंशियल। हिस्सेदारी का पता (जैसे stake1uyluup0rh6r2cc7kcw8nudqz990ezf5ltagxmw3u8deukvqwq7etq ) बाद से लिया गया है। हालांकि, एक वैध पता बनाना संभव है जिसमें कोई स्टेकिंग क्रेडेंशियल नहीं है।

इसलिए जब किसी विशेष हिस्सेदारी के पते के लिए खाते की शेष राशि प्राप्त करना संभव होगा, तब तक वॉलेट का खाता शेष प्राप्त करने का कोई तरीका नहीं है जब तक कि उस बटुए में प्रत्येक पते में एक ही स्टेकिंग क्रेडेंशियल शामिल न हो।

@1000101 "रीप" क्या है? "रीप" नामक डीबी-सिंक में कोई टेबल या कॉलम नहीं है।

ओह, मुझे खेद है कि मैं इसे पर्याप्त रूप से स्पष्ट नहीं कर पाया। मेरा मतलब https://github.com/input-output-hk/cardano-db-sync/issues/474 में वर्णित है - यानी मैं जो कह रहा हूं वह ठीक है कि इसके लिए कोई कॉलम नहीं है लेकिन यह बहुत अच्छा होगा अगर वहाँ होगा।

वर्तमान में किसी खाते की शेष राशि की आसानी से गणना करने का कोई तरीका नहीं है, जब इस खाते का उपयोग पूल पंजीकरण (एक इनाम खाते के रूप में) में किया गया हो और बाद में पूल को सेवानिवृत्त कर दिया गया था, इस प्रकार पूल जमा को पुनः प्राप्त कर लिया गया था। पूल डिपॉज़िट के "भुगतान" को dbsync में ट्रैक किया जाता है, लेकिन पूल के सेवानिवृत्त होने पर इसकी "रिफंड" नहीं।

मैं इससे सहमत हु। कार्डानो-डीबी-सिंक के प्रत्येक "उपयोगकर्ता" को संभालने के लिए कई किनारे के मामले भी हैं। Adalite और Yoroi दोनों भ्रमित हैं जब वे एक खाता देखते हैं जो पहले एक सेवानिवृत्त पूल का इनाम खाता था:

साथ ही, AFAIK केवल कार्डानोस्कैन शेष पुरस्कारों को सही ढंग से संभालता है, और वे डीबी-सिंक का उपयोग नहीं करते हैं।

एक आसान संबंध होना चाहिए जो उसी तरह अपडेट किया जाएगा जैसे पुरस्कार स्वचालित रूप से जोड़े जाते हैं। आइए एक उदाहरण के रूप में कई डीरजिस्ट्रेशन के साथ एक पूल लें, क्योंकि यह वास्तव में बहुत सामान्य है और इसके मालिक खाते के इनाम की शेष राशि को संभालना कठिन है।

इसमें 9 सेवानिवृत्ति प्रमाणपत्र हैं

और 15 पंजीकरण प्रमाण पत्र

ऐसे कई मामले हैं और नए प्रमाणपत्रों द्वारा सेवानिवृत्ति के अस्पष्ट नियमों को खारिज कर दिया गया है।

@erikd , यदि आप 500 टीएक्स जमा और सेवानिवृत्ति के बीच पर्याप्त कनेक्शन पर जोर देते हैं, तो आप इसके मालिक खातों में से एक की वापसी जमा के लिए एक प्रश्न कैसे लिखेंगे - e127e9e94eaa9287680e877832700a1724255e9688609497e09a6c440f? यदि नहीं, तो क्या हम इसे स्पष्ट रूप से डीबी-सिंक में जोड़ सकते हैं? मान लें, एक नई तालिका के रूप में, जिसका नाम pool_refunds है, जिसमें addr_id , राशि (वर्तमान में 500 का गुणज होना चाहिए) और epoch_no - ताकि इसे सही ढंग से और एक ही स्थान पर संभाला जा सके।

वर्तमान में db-sync लेज़र स्थिति से डेटा निकालता है और डेटाबेस में सम्मिलित करता है। यह कुछ जानकारी को त्याग देता है, लेकिन कोई एकत्रीकरण नहीं करता है। डेटाबेस में जो डाला जाता है वह केवल एक प्रतिबिंब है कि लेज़र स्टेट क्या प्रदान करता है।

आइए प्रासंगिक pool_hash.id देखें:

> select id, hash_raw from pool_hash
    where hash_raw = '\x9c8e59ea7004a51f953642653d70a94d066359b9dd6e6416a5430ff3' ;
  id  |                          hash_raw                          
------+------------------------------------------------------------
 5022 | \x9c8e59ea7004a51f953642653d70a94d066359b9dd6e6416a5430ff3
(1 row)

पूल पंजीकृत किया गया था ( block_no आरोही क्रम में रखने के लिए अतिरिक्त जोड़) निम्नानुसार है:

> select pool_update.id, hash_id, cert_index, active_epoch_no, block.block_no, block.epoch_no
    from pool_update
      inner join tx on tx.id = pool_update.registered_tx_id
      inner join block on tx.block_id = block.id
    where pool_update.hash_id = 5022
    order by block.block_no asc; 
  id  | hash_id | cert_index | active_epoch_no | block_no | epoch_no 
------+---------+------------+-----------------+----------+----------
 5022 |    5022 |          0 |             220 |  4717004 |      218
 5023 |    5022 |          0 |             220 |  4717035 |      218
 5024 |    5022 |          0 |             220 |  4717057 |      218
 5029 |    5022 |          0 |             220 |  4717140 |      218
 5030 |    5022 |          0 |             220 |  4717146 |      218
 5031 |    5022 |          0 |             220 |  4717169 |      218
 5032 |    5022 |          0 |             220 |  4717189 |      218
 5033 |    5022 |          0 |             220 |  4717216 |      218
 5034 |    5022 |          0 |             220 |  4717234 |      218
 5035 |    5022 |          0 |             220 |  4717241 |      218
 5037 |    5022 |          0 |             220 |  4717296 |      218
 5038 |    5022 |          0 |             220 |  4717425 |      218
 5061 |    5022 |          0 |             220 |  4721000 |      218
 5080 |    5022 |          0 |             221 |  4725394 |      219
 5081 |    5022 |          0 |             221 |  4725435 |      219
(15 rows)

और इसमें अपंजीकृत:

> select pool_retire.id, hash_id, cert_index, retiring_epoch, block.block_no, block.epoch_no
    from pool_retire
      inner join tx on tx.id = pool_retire.announced_tx_id
      inner join block on tx.block_id = block.id
    where hash_id = 5022
    order by block.block_no asc ; 
 id  | hash_id | cert_index | retiring_epoch | block_no | epoch_no 
-----+---------+------------+----------------+----------+----------
 180 |    5022 |          0 |            219 |  4717395 |      218
 181 |    5022 |          0 |            219 |  4717397 |      218
 182 |    5022 |          0 |            219 |  4717401 |      218
 183 |    5022 |          0 |            219 |  4717403 |      218
 184 |    5022 |          0 |            219 |  4717405 |      218
 185 |    5022 |          0 |            219 |  4717417 |      218
 186 |    5022 |          0 |            219 |  4717430 |      218
 187 |    5022 |          0 |            220 |  4725366 |      219
 188 |    5022 |          0 |            220 |  4725717 |      219
(9 rows)

डी-इंटरलीविंग अपडेट और डीरजिस्ट्रेशन:

action   | block_no
---------+------------
register | 4717004
update   | 4717035
update   | 4717057
update   | 4717140
update   | 4717146
update   | 4717169
update   | 4717189
update   | 4717216
update   | 4717234
update   | 4717241
update   | 4717296
retire   | 4717395
retire   | 4717397
retire   | 4717401
retire   | 4717403
retire   | 4717405
retire   | 4717417
update   | 4717425
retire   | 4717430
update   | 4721000
retire   | 4725366
update   | 4725394
update   | 4725435
retire   | 4725717

जारी रहती है ....

यह निश्चित रूप से गर्दन में बहुत अधिक दर्द है। एक समाधान के साथ आने की कोशिश करने के लिए लोगों के साथ बही-खाता बात कर रहे हैं।

ledger-specs लोगों से बात की जिन्होंने बेहतर समाधान की प्रतीक्षा करते हुए इसे अभी के लिए एक त्वरित और गंदा तरीका सुझाया।

विचार यह होगा कि एक pool_registration_refund तालिका जैसा कुछ होना चाहिए जिसमें हिस्सेदारी का पता और राशि हो।

ये तो बहुत बढ़िया होगा!

ledger-specs लोगों से बात की जिन्होंने बेहतर समाधान की प्रतीक्षा करते हुए इसे अभी के लिए एक त्वरित और गंदा तरीका सुझाया।

विचार यह होगा कि एक pool_registration_refund तालिका जैसा कुछ होना चाहिए जिसमें हिस्सेदारी का पता और राशि हो।

विस्मयकारी! मेरा मतलब है, हमारे पास अभी के लिए एक वर्कअराउंड है, इसलिए हम नकारात्मक बैलेंस @xdzurman साझा नहीं करेंगे, लेकिन यह नॉट-सो- सुंदर: tm : SQL की लगभग 100 लाइनें हैं, जिनकी गणना हर खाते में की जानी है। यह निश्चित रूप से एक टन मदद करेगा। धन्यवाद एक लाख!!!