Cardano-db-sync: تم توزيع المكافآت على عنوان حصة غير مسجل

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

Mainnet ، db-sync 6.0.1 ، حصة عنوان حصة1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86

تاريخ التسجيل

SELECT stake_registration.addr_id, block.epoch_no, block.time
FROM stake_address
LEFT JOIN stake_registration ON stake_registration.addr_id = stake_address.id
LEFT JOIN tx ON tx.id = stake_registration.tx_id
LEFT JOIN block ON block.id = tx.block_id 
WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';

 addr_id | epoch_no |        time
---------+----------+---------------------
   38278 |      208 | 2020-08-01 07:45:51
   38278 |      233 | 2020-12-01 22:31:13
(2 rows)

سجل إلغاء التسجيل

SELECT stake_deregistration.addr_id, block.epoch_no, block.time
FROM stake_address
LEFT JOIN stake_deregistration ON stake_deregistration.addr_id = stake_address.id
LEFT JOIN tx ON tx.id = stake_deregistration.tx_id
LEFT JOIN block ON block.id = tx.block_id 
WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';

 addr_id | epoch_no |        time
---------+----------+---------------------
   38278 |      232 | 2020-12-01 18:25:59
(1 row)

كما نرى ، لم يتم تسجيل العنوان في نهاية حقبة 232 ، ولا ينبغي توزيع مكافآت العصر 231 على هذا العنوان ، ولكن

SELECT reward.*, block.epoch_no AS block_epoch_no, block.time
FROM reward
LEFT JOIN block ON block.id = reward.block_id 
WHERE reward.addr_id = 38278 AND reward.epoch_no = 231;

   id    | addr_id |  amount   | epoch_no | pool_id | block_id | block_epoch_no |        time
---------+---------+-----------+----------+---------+----------+----------------+---------------------
 1041508 |   38278 | 192969560 |      231 |     144 |  5023676 |            233 | 2020-12-01 21:44:51
(1 row)
bug priority high
مصدر
picture dmitrystas
👀4 👍1

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

استخدام إصدار db-sync في PR # 469. تم إدراج مكافأة عنوان الرهان \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)
picture erikd في ٨ يناير ٢٠٢١
👍2

ال 28 كومينتر

: نخيل:

نظرت إلى هذا لفترة ثم أدركت فجأة أن الاستعلام الأول لا يُظهر ما يعتقد 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 picture erikd في ١٧ ديسمبر ٢٠٢٠

erikd يوم جيد. هذه هي المشكلة الأصلية https://github.com/Emurgo/yoroi-frontend/issues/1832#issue -754776885
ربما يمكن أن تكون مفيدة

يُظهر Yoroi & Adalite جائزة 192 FAKE ADA خاطئة ولكنها في الواقع تساوي 0. يتم سحب آخر جائزتين من خلال adawallet.io (لا يستخدم db-sync)
image

وصف موجز للمشكلة في الخطوات:
1) العصر 232 . أقوم بسحب المكافآت وإلغاء تسجيل مفتاح Staking في نفس الوقت. المكافآت 0. لدي ما يكفي من ADA للرسوم
2) العصر 233 . يجب أن أتلقى أول مكافأة متبقية إذا تم تسجيل مفتاحي ولكنه ليس كذلك ، لكن Yoroi تظهر 192ADA المستلمة. يخطئ Yoroi عندما أحاول الانسحاب. المحافظ الأخرى التي لا تستخدم db-sync تظهر مكافأة 0ADA
3) العصر 233 . أفوض إلى نفس المجموعة مرة أخرى. المفتاح مسجل . المكافآت الحقيقية 0. مكافآت Yoroi 192.
4) الحقبة 234 . أتلقى المكافأة الثانية المتبقية 135ADA. رصيد المكافأة الحقيقي هو 135ADA.
يعرض Yoroi 327ADA (192 + 135). لا يمكن سحب أي مكافأة من خلال Yoroi لقد تلقيت خطأ من الخادم أثناء إرسال المعاملة.
5) الحقبة 235 . استلمت الجائزة الثالثة الاخيرة 145ADA. رصيد المكافأة الحقيقي هو 280ADA (135 + 145).
يظهر Yoroi 472ADA (192 + 135 + 145) لا يمكن سحب أي مكافأة من خلال Yoroi لقد تلقيت خطأ من الخادم أثناء إرسال المعاملة.
6) الحقبة 235 . أنا أسحب 280ADA بسلاسة من خلال adawallet.io الذي لا يستخدم db-syns ويظهر بشكل صحيح رصيد المكافآت 280ADA
7) بعد سحب المكافآت الحقيقية 280ADA (لا يزال 0ADA) ، لا يزال Yoroi يظهر رصيد المكافآت 192ADA.

IlyaSofronov picture IlyaSofronov في ١٧ ديسمبر ٢٠٢٠

لا يزال Yoroi يظهر رصيد المكافأة 192ADA.

هناك اثنين على الأقل من الاحتمالات؛

  • هناك خطأ db-sync
  • هناك خلل في Yoroi

أتعامل فقط مع db-sync . هذا يعني أنه يجب تقديم المشكلات إلي على أنها استعلامات SQL وليس كمعلومات من Yoroi.

هل stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 هو مفتاح الرهان محل الاهتمام هنا؟

erikd picture erikd في ١٧ ديسمبر ٢٠٢٠

erikd نعم مفتاح الحصة هو الرهان 1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86
لاحظ أنه ليس لدى Yoroi فقط هذه الأخطاء ولكن Adalite.io و adastat.net
هؤلاء ليس لديهم هذا الخطأ: cardanoscan.io و adawallet.io

IlyaSofronov picture IlyaSofronov في ١٨ ديسمبر ٢٠٢٠

إذا كانت بعض محافظ الإنترنت تحتوي على هذا الخطأ والبعض الآخر لا يحتوي على هذا الخطأ ، وكل ذلك يعتمد على db-sync فإن المشكلة غير مرغوب فيها للغاية في db-sync .

erikd picture erikd في ١٨ ديسمبر ٢٠٢٠

erikd لكن adawallet.io لا يستخدم db-sync ويظهر رصيد المكافأة الصحيح (0ADA) ويتيح لي سحب المكافآت الأخيرة

IlyaSofronov picture IlyaSofronov في ١٨ ديسمبر ٢٠٢٠

مرة أخرى ، يشير هذا إلى أن هذا خطأ في Yoroi ، وليس خطأ db-sync .

erikd picture erikd في ١٨ ديسمبر ٢٠٢٠

واجه Exodus هذا الخطأ أيضًا.

roccomuso picture roccomuso في ٤ يناير ٢٠٢١

هذا بالتأكيد خطأ في Cardano-db-sync وليس خطأ Yoroi نظرًا لكيفية تأثير ذلك ليس فقط على Yoroi ولكن أيضًا على العديد من المستخدمين الآخرين لـ cardano-db-sync. لا يستخدم كل من cardanoscan و adawallet مزامنة cardano-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",
}

يمكنك أن ترى أن الواجهة الخلفية الخاصة بنا تُرجع مجموع صفوف db-sync لقيمة rewards (سوف تشرح سبب حدوث هذه المشكلة لاحقًا)

يمكنك أيضًا التحقق من صحة withdrawals خلال تلخيص القيم الموجودة على cardanoscan والتي نعلم أنها لا تتأثر بهذا الخطأ.

remainingAmount هو rewards - withdrawals

سجل التسجيل للمحفظة

بالنظر إلى تاريخ مفتاح التخزين هذا ، يمكنك رؤية:

  • تم إلغاء تسجيله في العصر 232
  • تم إعادة تسجيله في العصر 233

الحالة الحالية من عقدة كاردانو

وفقًا لمثيل العقدة cardano الخاصة بي ، هذه هي القيمة الحالية داخل عنوان Staking

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

لذلك يمكنك أن ترى أنه وفقًا للعقدة ، فإن رصيد المحفظة هو العصر 235 + العصر 236 (100702 + 102078 = 202780)

فما هي القضية؟

من خلال النظر إلى cardanoscan ، يمكننا رؤية تاريخ السحب الكامل للمحفظة. دعونا نرى ما يتوافق مع كل عملية سحب:

| انسحبت الحقبة | المبلغ المسحوب | صفوف حقبة db-sync متضمنة |
| ----------------- | ------------------ | ------------ ----------------- |
| 228 | 2601.373144 | 211 ، 212 ، ... ، 225 ، 226 |
| 230 | 371.141369 | 227 ، 228 |
| 232 | 317.641570 | 229 ، 230 |
| 234 | 135.711434 | 232 |
| 235 | 145.964545 | 233 |

ومع ذلك ، يمكنك أن ترى عصر 231 في cardano-db-sync (192969560) غير مدرج في أي من هذه!

بالتأكيد ، إذا نظرت إلى ردنا الخلفي ، "remainingAmount": "193172340", وقمت بإزالة الحقبة المضمنة بالخطأ 231 ، ستحصل على 193172340 - 192969560 = 202780 وهي النتيجة المتوقعة من عقدة كاملة!

استنتاج

بناءً على التحقيق الذي أجريته ، يبدو أن cardano-db-sync يتضمن الصف 231 في نتيجة سجل المكافآت على الرغم من أنه لا ينبغي ذلك.

SebastienGllmt picture SebastienGllmt في ٤ يناير ٢٠٢١

لقد قمت بتبسيط الاستعلام الأول والتحقق من أنني أحصل على نفس النتائج (لقد فعلت ذلك).

الحالة الحالية (غير الصحيحة) من خلفيتنا

أفضل الحصول على جميع المعلومات من مصدر واحد لذلك:

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 .

لذلك أعتقد أن استنتاجك:

بناءً على التحقيق الذي أجريته ، يبدو أن cardano-db-sync يتضمن الصف 231 في نتيجة سجل المكافآت على الرغم من أنه لا ينبغي ذلك.

غير صحيح ، يجب أن يكون لعنوان الرهان هذا مكافآت مقابل الحقبة 231 .

علاوة على ذلك ، أعتقد أن تعليقك:

الحالة الحالية (غير الصحيحة) من خلفيتنا
{
"المتبقيةAmount": "193172340" ،
"المكافآت": "3765004402"،
"السحوبات": "3571832062"،
}

هو في الواقع صحيح. الفرق بين قيمة المكافآت وقيمة السحب هو رصيد المكافأة الحالي غير المسحوب.

erikd picture erikd في ٥ يناير ٢٠٢١

هو في الواقع صحيح. الفرق بين قيمة المكافآت وقيمة السحب هو رصيد المكافأة الحالي غير المسحوب.

لا يمكن أن يكون هذا هو الحال لأننا نعلم أن العقدة ترجع 202780 كرصيد المكافأة للحساب وليس 193172340

أي ، هناك مكافآت لكل حقبة ما عدا 234.

يجب أن تتوقع فقدان حقبتين:

  1. الحقبة التي أعيدت فيها المكافآت إلى الاحتياطيات لأنهم لم يكن لديهم مفتاح حصتهم المسجلة
  2. العصر الذي يمثل فجوة الحقبة الأولى بين وقت إلغاء تسجيل مفتاحهم ووقت إعادة تسجيلهم

يتوافق العصر المفقود 234 مع (2) ، وأعتقد أن 231 يتوافق مع (1) نظرًا لأن 231 يعني أنه يجب أن يكون مرئيًا في محفظة المستخدم في العصر 233 وهو بالضبط الحقبة التي نتوقع أن تكون قد خسرت لأجلها (1)

SebastienGllmt picture SebastienGllmt في ٥ يناير ٢٠٢١

يجب أن تتوقع فقدان حقبتين:

لماذا ا؟ وفقًا للعمليات على عنوان الحصة هذا:

| عملية | tx_epoch_no | active_epoch_no |
| ------------------- | --------------------- | ------- --------- |
| التسجيل | 208 | 210 |
| إلغاء التسجيل | 232 | 234 |
| التسجيل | 233 | 235 |

تم إلغاء تسجيلها فقط لفترة واحدة ( 234 ) ولم تتلق أي مكافآت عن تلك الحقبة.

لماذا سيكون هناك حقبتان بدون مكافآت؟ أنا متأكد تمامًا من أن الحالتين اللتين ذكرتهما هما في الواقع نفس الشيء ، وبالتالي لا تمر سوى فترة واحدة دون مكافأة.

erikd picture erikd في ٥ يناير ٢٠٢١

SebastienGllmt في سلاك قال:

يعد إلغاء التسجيل أمرًا خاصًا لأنه يتم على الفور ، وليس في حقبتين

إذا تم إلغاء التسجيل على الفور ، فقد حدث هذا في tx_epoch_no == 232 لذا ستفقد جميع المكافآت للعهود [231..234] ، وليس فقط مكافآت 231.

أعتقد أننا بحاجة إلى JaredCorduan في هذا الشأن.

erikd picture erikd في ٥ يناير ٢٠٢١

يتوافق تفسير

إنه أمر فلسفي إلى حد ما "عندما" يتم إلغاء تسجيل أوراق اعتماد الحصة ، لكنني سأصيغها على النحو التالي: يتم إلغاء التسجيل على الفور ، لكن المكافآت تتأخر. إذا تم إلغاء تسجيل بيانات الاعتماد في حقبة e ، فستتلقى مكافآت على حد e / e+1 (قادم من اللقطة المأخوذة على حد e-2 / e -1 ) وستحصل أيضًا تلقي مكافآت على حد e+1 / e+2 (قادم من اللقطة الملتقطة على حد e-1 / e ).

JaredCorduan picture JaredCorduan في ٥ يناير ٢٠٢١

يبدو أن لدينا بعض الالتباس مع التسمية.

من وجهة نظر dbs-ync :

  • tx_epoch_no : الفترة التي تحتوي على معاملات شهادة التسجيل / إلغاء التسجيل.
  • active_epoch_no : بشكل أساسي tx_epoch_no + 2 ، الفترة التي تصبح فيها التغييرات على عنوان الرهان نشطة.
  • epoch_no في جدول reward : الفترة الفعلية التي تم فيها ربح المكافآت.
erikd picture erikd في ٥ يناير ٢٠٢١

إذا كانت بيانات اعتماد الحصة في شهادة إلغاء تسجيل من معاملة في العصر 232 ، فلن يتم تضمينها في اللقطة التي تم التقاطها على حدود 232/233. هذا يعني أنه لن يكون جزءًا من تحديث المكافأة الذي يتم تسليمه على حدود 235/236. والتي ، وفقًا لمصطلحاتerikd ، هي المكافآت 234. علاوة على ذلك ، إذا هبطت شهادة التسجيل (إعادة) التسجيل في معاملة في العصر 233 ، فسيكون هذا هو تحديث المكافأة الوحيد الذي سيفوتها.

JaredCorduan picture JaredCorduan في ٥ يناير ٢٠٢١

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

JaredCorduan picture JaredCorduan في ٥ يناير ٢٠٢١

نظرًا لأنه يبدو أن هناك ارتباكًا ، فقد صنعت صورة تُظهر العهدين المفقودين المتوقعين (db-sync 231 و db-sync 234)

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

image

SebastienGllmt picture SebastienGllmt في ٦ يناير ٢٠٢١

لقد صنعت صورة توضح العهدين المفقودين المتوقعين (db-sync 231 و db-sync 234)

لكن المكافآت الفعلية كما ذكرت من قبل 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 ) في الوقت الحالي.

erikd picture erikd في ٦ يناير ٢٠٢١

في الرسم التخطيطي الخاص بك ، تم شطب "المكافآت التي تم تسليمها" للعصر 233 ، وأعتقد أن هذا غير صحيح وجاريد ويجب تسليم المكافآت (لأنها تستند إلى اللقطة في بداية الحقبة 231 ، وليس الحالة الحالية لـ السلسلة).

erikd picture erikd في ٦ يناير ٢٠٢١

SebastienGllmt يقول:

أعتقد أن الالتباس يأتي من حقيقة أن 231 قد لا تكون مفقودة من الناحية الفنية - فقد تكون حالة دفتر الأستاذ تعتبرها موزعة على الاحتياطيات بدلاً من المستخدم.

لكن الجدول rewards يُظهر المكافأة التي يتم توزيعها على عنوان الرهان. إذا تم توزيعه على الاحتياطيات ، فلن يكون في هذا الجدول. db-sync معلومات المكافأة هذه كخريطة من عنوان المشاركة إلى مبلغ المكافأة. الآن قد تكون حالة دفتر الأستاذ نفسها خاطئة ، ولكن هناك مساحة صغيرة جدًا للأخطاء التي تتسلل بعد استرداد الخريطة من حالة دفتر الأستاذ.

erikd picture erikd في ٦ يناير ٢٠٢١

كنت مخطئا عندما قلت:

علاوة على ذلك ، إذا هبطت شهادة (إعادة) التسجيل في معاملة في العصر 233 ، فسيكون هذا هو تحديث المكافأة الوحيد الذي سيفوتها.

في الواقع ، كان SebastienGllmt محقًا تمامًا عندما قال:

يجب أن تتوقع فقدان حقبتين:

  1. الحقبة التي أعيدت فيها المكافآت إلى الاحتياطيات لأنهم لم يكن لديهم مفتاح حصتهم المسجلة
  2. العصر الذي يمثل فجوة الحقبة الأولى بين وقت إلغاء تسجيل مفتاحهم ووقت إعادة تسجيلهم

من خلال عدم التسجيل في حدود حقبة 232/233 ، فإن بيانات اعتماد الحصة على حد سواء:

  • لا يحصل على المكافآت من التحديث المطبق على حدود 232/233 ، و
  • لم يتم تضمينه في لقطة توزيع الأسهم المأخوذة على حدود 232/233 (بحيث لا يتم توزيع المكافآت على حدود 235/236).

يمكنني تخمين كيف تبلغ مزامنة db-sync عن المكافآت التي يتم توزيعها على حدود 232/233 (وهو في الحقيقة مجرد تخمين SebastienGllmt :)) لا يمكن لحالة دفتر الأستاذ أن تعرف حتى آخر لحظة قبل حدود العصر أي أوراق الاعتماد لا تزال مسجلة. نعيد مكافآت أوراق الاعتماد غير المسجلة إلى الاحتياطيات. (انظر Figure 51: Reward Update Application في المواصفات الرسمية ). ربما لا يقوم db-sync بإزالة بيانات الاعتماد غير المسجلة.

JaredCorduan picture JaredCorduan في ٦ يناير ٢٠٢١

تبدو صورة

JaredCorduan picture JaredCorduan في ٦ يناير ٢٠٢١

حسنًا الآن لدينا شرح لهذا. يحافظ db-sync على حالة legder ويسحب مكافآت العصر باعتبارها Map StakeAddress Coin والتي يتم إدراجها في قاعدة البيانات. ومع ذلك ، تحتوي هذه الخريطة على إدخالات StakeAddress وهي غير صالحة وستسقط legder-state هذه الإدخالات بشكل فعال مما يساهم في المكافآت المكتسبة إلى الاحتياطيات.

الحل هو أيضًا سحب مجموعة StakeAddress الصالحة من حالة دفتر الأستاذ ثم تصفية Map وإسقاط جميع الإدخالات التي لا تحدث في مجموعة StakeAddress es الصالحة.

erikd picture erikd في ٦ يناير ٢٠٢١

سيكون من الرائع أن يتم وضع هذه المكافآت "الوهمية" في جدول جديد مثل "المكافآت غير الموزعة" أو شيء من هذا القبيل. سيسمح لنا ذلك بحساب ربحية المجمع بشكل صحيح

dmitrystas picture dmitrystas في ٦ يناير ٢٠٢١

dmitrystas :

سيكون من الرائع أن يتم وضع هذه المكافآت "الوهمية" في جدول جديد مثل "المكافآت غير الموزعة" أو شيء من هذا القبيل. سيسمح لنا ذلك بحساب ربحية المجمع بشكل صحيح.

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

لقد قمت بإنشاء تذكرة خاصة لهذه المشكلة.

erikd picture erikd في ٦ يناير ٢٠٢١

حسنًا ، لدي حل يقوم بتصفية المكافآت غير الصالحة من قائمة المكافآت قبل إدراجها ، وهناك بالفعل مكافأة لهذا العنوان في العصر 231 .

أنا الآن بحاجة إلى تعديل ذلك بحيث يمكن إضافة هذه المكافآت "غير الصالحة" إلى جدول منفصل.

erikd picture erikd في ٧ يناير ٢٠٢١
🚀1

استخدام إصدار db-sync في PR # 469. تم إدراج مكافأة عنوان الرهان \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)
erikd picture erikd في ٨ يناير ٢٠٢١
👍2
هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

johnalotoski picture johnalotoski  ·  15تعليقات
rhyslbw picture rhyslbw  ·  4تعليقات
erikd picture erikd  ·  10تعليقات
erikd picture erikd  ·  10تعليقات
rcmorano picture rcmorano  ·  6تعليقات