Cardano-db-sync: عدم تطابق فردي بين جدول المكافآت وجدول الكتل

تم إنشاؤها على ٢ نوفمبر ٢٠٢٠ · 7تعليقات · مصدر: input-output-hk/cardano-db-sync

هذا مشابه بشكل لا يصدق لـ # 361.

على mainnet:

cexplorer=# 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 
--------+---------+--------------+----------+---------+----------
 452424 |   92628 | 133076705980 |      222 |    1250 |  4832319
 508325 |   92628 | 126562664576 |      223 |    1250 |  4853643
(2 rows)

مما يشير إلى أن هذه المكافآت قد تم ربحها pool_id == 1250 .

ومع ذلك:

cexplorer=# 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 = 1250 ;
 block_no | pool_hash_id 
----------+--------------
(0 rows)

إذا اتضح أن هذه المشكلة ناتجة عن مشكلة مماثلة لتلك التي تم حلها في رقم 361 ، فنحن بالتأكيد بحاجة إلى التحقق من الصحة لتغطية ذلك.

مصدر

erikd

التعليق الأكثر فائدة

erikd ما قلته لكم بالأمس كان غير صحيح ، معذرة. راجعت كلاً من المواصفات والتنفيذ اليوم ، والتي تتوافق وتعمل على النحو التالي.

شهادات حسابات المكافآت في مجموعة الأسهم:

لا تحتاج إلى أن تكون مسجلة
لا تحتاج إلى تفويض

علاوة على ذلك ، إذا أدرجت مجموعتان حساب مكافأة مشتركًا ، فسيحصل الحساب على مجموع المكافآت.

JaredCorduan في ٣ نوفمبر ٢٠٢٠

🚀1 👍1

ال 7 كومينتر

هذا يختلف عن # 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)

هذا يعني أن هذا العنوان هو عنوان المكافأة لعدد من المجموعات المختلفة. يجب أن تكون هذه هي القضية.

erikd في ٣ نوفمبر ٢٠٢٠

هذا صعب. كان لدي افتراض في رأسي أن stake_address يمكن أن يفوض فقط إلى تجمع واحد. في حين أن هذا صحيح ، يمكن استخدام stake_address كعنوان مكافأة لأكثر من مجموعة واحدة.

في الواقع أكثر تعقيدًا من ذلك. إذا تم استخدام stake_address كعنوان مكافأة لمجموعتين ، فسيكون مبلغ المكافأة هو مجموع المكافآت لكل مجموعة. بالنظر إلى ما لدي حاليًا ، لست متأكدًا من إمكانية فك هذه البيضة.

erikd في ٣ نوفمبر ٢٠٢٠

هذا ليس معقدًا فحسب ، إنه علبة كاملة من الديدان.

بعد الدردشة على Slack الداخلي لـ db-sync مع JaredCorduan ، أدركت أن معالجة البيانات على السلسلة لم تكن صحيحة تمامًا وأن بعض SPO ربما لم يقموا بإعداد مجموعاتهم بشكل صحيح.

أولاً ، إذا تم تسجيل تجمع مع عنوان حصة / مكافأة لم يتم تسجيله أبدًا كعنوان حصة ، فوفقًا للنقطة 3 والقسم 3.3.4 من مواصفات تصميم Shelley :

إذا كان عنوان المكافأة غير مسجل ، فلن يتمكن مشغل تجمع الأسهم من تلقي المكافآت. في هذه الحالة ، يتم إرسال أي مكافآت مستحقة لهم بدلاً من ذلك إلى الاحتياطيات (لكن أعضاء تجمع الأسهم سيظلون يحصلون على مكافآتهم المعتادة).

ثانيًا ، إذا تم تسجيل مجموعتين أو أكثر بنفس عنوان الرهان / المكافأة وربح مجموعتان أو أكثر مكافآت ، فعندئذٍ فقط تنتقل مكافآت المجموعة الأولى (كيف يتم تحديدها "الأولى"؟) إلى العنوان وتنتقل جميع المجموعات المتبقية إلى الاحتياطيات / الخزانة. لم أجد الوثائق المناسبة حول هذا بعد.

erikd في ٣ نوفمبر ٢٠٢٠

شهادات حسابات المكافآت في مجموعة الأسهم:

لا تحتاج إلى أن تكون مسجلة
لا تحتاج إلى تفويض

علاوة على ذلك ، إذا أدرجت مجموعتان حساب مكافأة مشتركًا ، فسيحصل الحساب على مجموع المكافآت.

JaredCorduan في ٣ نوفمبر ٢٠٢٠

🚀1 👍1

يبدو حاليًا أن الإصلاح الخاص بهذا موجود في مكتبة ذات مستوى أدنى. JaredCorduan يبحث في الأمر.

erikd في ٤ نوفمبر ٢٠٢٠

👍1

غير متأكد ما يجري هنا. لقد تغيرت الأمور.

> 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

erikd في ٢٥ مارس ٢٠٢١

آه ، لكن استعلام جدول المكافآت (الذي لا يُرجع أي مدخلات) صحيح:

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

لذلك اختفى عدم التطابق الفردي ويمكن إغلاق هذه التذكرة.

erikd في ٢٥ مارس ٢٠٢١

هل كانت هذه الصفحة مفيدة؟

0 / 5 - 0 التقييمات