Cardano-db-sync: مثال على رصيد الحساب

شكرا لفتح هذه القضية نيابة عني! فقط للتوضيح أكثر قليلاً - لا يتعلق الأمر بالحساب في حد ذاته فحسب ، بل يتعلق بشكل أساسي بتتبع reap في مكان ما في db بحيث يمكن استخدامه بسهولة في حساب رصيد الحساب (والذي يتم استخدامه في كل مكان ، على سبيل المثال pool live حجم الحصة ، والتعهد الحي للمجمع ، وما إلى ذلك).

@ 1000101 ما هو "ريب"؟ لا يوجد جدول أو عمود في db-sync يسمى "reap".

رصيد الحساب ليس تافها.

تحتوي العناوين في Shelley والعصور اللاحقة على مكونين ؛ اعتماد الدفع وبيانات اعتماد التخزين. عنوان الرهان (على سبيل المثال stake1uyluup0rh6r2cc7kcw8nudqz990ezf5ltagxmw3u8deukvqwq7etq ) مشتق من العنوان الأحدث. ومع ذلك ، من الممكن إنشاء عنوان صالح لا يحتوي على أي بيانات اعتماد Staking.

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

@ 1000101 ما هو "ريب"؟ لا يوجد جدول أو عمود في db-sync يسمى "reap".

أوه ، أنا آسف لعدم توضيح هذا بما فيه الكفاية. ما قصدته موصوف في https://github.com/input-output-hk/cardano-db-sync/issues/474 - أي ما أقوله هو بالضبط أنه لا يوجد عمود لهذا ولكن سيكون رائعًا إذا كان هناك.

لا توجد حاليًا طريقة لحساب رصيد الحساب بسهولة ، عندما يتم استخدام هذا الحساب في تسجيل المجمع (كحساب مكافأة) وبعد ذلك تم إيقاف المجمع ، وبالتالي استعادة إيداع المجمع. يتم تتبع "الدفع" الخاص بإيداع المجمع في dbsync ، ولكن لا يتم تتبع "استرداد" عند توقف المجمع.

أنا أتفق مع هذا. هناك أيضًا العديد من حالات الحافة التي سيتعين على كل "مستخدم" لـ cardano-db-sync التعامل معها. يتم الخلط بين كل من Adalite و Yoroi عندما يرون حسابًا كان في السابق حساب مكافأة لمجموعة متقاعدين:

أيضًا ، AFAIK فقط cardanoscan يتعامل مع المكافآت المتبقية بشكل صحيح ، ولا يستخدم db-sync.

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

هناك 9 شهادات تقاعد لها

و 15 شهادة تسجيل

هناك العديد من قضايا الحافة والقواعد الغامضة لإلغاء التقاعد من قبل شهادات جديدة .

erikd ، إذا كنت تصر على اتصال كافٍ بين إيداع 500 tx وحالات التقاعد ، فكيف تكتب استعلامًا فقط عن الإيداعات المرتجعة لأحد حسابات مالكها - e127e9e94eaa9287680e877832700a1724255e9688609497e09a6c440f؟ إذا لم يكن الأمر كذلك ، فهل يمكننا إضافة هذا صراحة إلى db-sync؟ لنفترض ، كجدول جديد ، باسم 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 الذي تمت مشاركته ، ولكن هناك حوالي 100 سطر من غير جميلة: tm : SQL والتي يجب حسابها لكل حساب. هذا من شأنه أن يساعد بالتأكيد طن. شكرا ميل !!!