Cardano-db-sync: لم تتم إزالة الكتل اليتيمة من جدول الحظر

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

تقارير التحقق من صحة البرنامج:

All transactions for blocks in epoch 195 are present: Failed on block no 4224831: 
expected tx count of 2 but got 3

واستعلام بسيط:

select * from block where block_no = 4224831 ;

يؤدي إلى صفين حيث كان من المتوقع وجود صف واحد فقط.

# select id, slot_no, block_no,previous,tx_count,time from block where 
    block_no = 4224831 ; 
   id    | slot_no | block_no | previous | tx_count |        time         
---------+---------+----------+----------+----------+---------------------
 4265744 | 4226980 |  4224831 |  4265742 |        2 | 2020-05-29 08:58:11
 4265743 | 4226979 |  4224831 |  4265742 |        3 | 2020-05-29 08:57:51

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

يجب إزالة الكتل المعزولة مثل هذا من قاعدة البيانات ، أو تجنبها في عملية التحقق من الصحة.

bug priority high

مصدر

erikd

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

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

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

dcoutts في ٣٠ مايو ٢٠٢٠

❤2 👍1

ال 10 كومينتر

أبسط حل لهذا هو إزالة الكتل التي أصبحت يتيمة مثل هذا.

كبديل لإزالتها ، يمكننا نقلها إلى جدول منفصل orphaned_blocks ولكن بعد ذلك نحتاج إلى تحديد ما نريد فعله باستخدام tx s المرفق بهذه الكتلة. شعوري الأولي هو أنه يجب فقط تجاهلها / إزالتها.

قد يكون الحصول على جدول orphaned_block مفيدًا عندما ننتقل إلى Praos ، ولكن يمكن تنفيذه بسهولة حتى الآن عندما تدعم مزامنة db بالفعل بايرون فقط.

erikd في ٣٠ مايو ٢٠٢٠

كانت فكرتي الأولى أيضًا هي: تنظيف كتلة الأيتام ، ولكن احتفظ بها في مكان ما.

يمكن أن يصبح خيارًا للعقدة لتخزين جميع الشوكات المكتشفة بما في ذلك جميع الكتل من الذراع الجانبية المهجورة في هذا الجدول. يعد التطهير بعد خانات x أمرًا بسيطًا. التشخيص وتتبع ما حدث أسهل بكثير بعد ذلك.

gufmar في ٣٠ مايو ٢٠٢٠

السؤال حول TXs المفقودة مثير للاهتمام. كفكرة سريعة ، دون معرفة ما إذا كان ممكنًا من الناحية المشفرة وآمنًا بنسبة 100٪:

إذا اكتشفت العقدة (تمكين db-sync) إرسال الرسائل من الكتل المعزولة ، فيمكنه محاولة إعادة إدخالها في مجموعة الذاكرة الخاصة به. لا يبثها أكثر ، ولكن لا تعالجها إلا إذا حان دورها لإنتاج كتلة.
(لا ينبغي أن يكون البث ضروريًا لأن العديد من التجمعات الأخرى تكتشف الكتلة المعزولة مع TX الخاصة بها وتعيد إدخالها في مجموعة المذكرات الخاصة بهم من هذا المصدر)

إذا أرسل مالك utxo في هذه الأثناء (حتى يتم حل التفرع واكتشاف الكتل المعزولة) محاولة ثانية ، يصبح الإرسال السابق غير صالح. إذا كان tx لا يزال صالحًا بدلاً من ذلك ، فسيظهر تلقائيًا في كتلة صالحة جديدة مرة أخرى.

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

gufmar في ٣٠ مايو ٢٠٢٠

إذا اكتشفت العقدة (تمكين db-sync) إرسال الرسائل من الكتل المعزولة ، فيمكنه محاولة إعادة إدخالها في مجموعة الذاكرة الخاصة به. لا يبثها أكثر ، ولكن لا تعالجها إلا إذا حان دورها لإنتاج كتلة.

من المهم ملاحظة أن db-sync منفصل عن node ويتبع ببساطة سلسلة node .
على وجه التحديد ، لا يحتفظ db-sync بنسخته الخاصة من mempool. في الحالة التي اكتشفتها ، تم تضمين المعاملات في الكتلة المعزولة بشكل شبه مؤكد في الكتل غير المعزولة لاحقًا ، لذلك يجب أن يسقطها db-sync .

المحفظة بالطبع لها سلوك مختلف عن db-sync .

erikd في ٣٠ مايو ٢٠٢٠

إذا تمت معالجة TXs بشكل شبه مؤكد من قبل منتجي الكتل الآخرين ، فليس هناك حاجة "لإعادة حقنهم" باستخدام بعض الأدوات من db إلى mempool في العقدة.
السؤال هو ما إذا كان هذا هو الحال في جميع متغيرات الفتحة / ارتفاع معركة. إذا لم يكن السؤال التالي هو ما إذا كان من المفيد (المقصود) السماح لإحدى العقد التي تكتشف TXs غير المعالجة في كتلة معزولة ، إعادة إدراجها في مجموعة الذاكرة الخاصة به ، استنادًا إلى قاعدة بيانات db-sync

gufmar في ٣٠ مايو ٢٠٢٠

👍1

db-sync فقط لعرض ما حدث في الماضي. ستقوم العقدة نفسها بسحب المعاملات من الكتل المعزولة وإعادتها إلى مجموعة الذاكرة الخاصة بها. لا يُقصد من db-sync أن يكون جزءًا من ذلك.

ومع ذلك ، فإن الاحتفاظ بقائمة الكتلة المعزولة ضمن آخر 100 فتحة أو نحو ذلك قد يكون مفيدًا لتصحيح الأخطاء.

erikd في ٣٠ مايو ٢٠٢٠

👍1

dcoutts في ٣٠ مايو ٢٠٢٠

❤2 👍1

أوافق على أن نحافظ على db-sync نقيًا قدر الإمكان انعكاسًا لحالة السلسلة الفعلية

ومع ذلك ، فإنه من شأنه أن يبسط حياتي إلى حد كبير إذا تم تحويل جميع الكتل إلى db-sync ، ثم تم حذفها عند التراجع. بهذه الطريقة يمكنني تشغيل حذف postgres والقيام بما أريد بالبيانات.

papacarp في ١٠ يونيو ٢٠٢٠

👍1

هذا مطلوب من قبل عملاء آخرين ويقول سام إنه أمر بالغ الأهمية لأي إصدار db-sync ، بما في ذلك Testnet.

kevinhammond في ١١ يونيو ٢٠٢٠

يبدو أن عمليات التراجع عن الحالة السابقة لا تعمل بالشكل المتوقع. نرى كتلًا متعددة في قاعدة البيانات بنفس ارتفاع الكتلة. هذا مثال (على mainnet):

cexplorer = # SELECT * FROM block حيث block_no = 4224831 ؛
معرف | تجزئة | slot_no | block_no | السابق | merkel_root | slot_leader | الحجم | epoch_no | الوقت | tx_count
--------- + -------------------------------------------- ---------------------------- + --------- + ---------- + ---------- + --------------------------------------- ----------------------------- + ------------- + ------ + ---------- + --------------------- + ----------
4225044 | \ x941a71094c7b10243845a82e53dc45959d8fde5f6d87e463efe660aa9611b965 | 4226979 | 4224831 | 4225043 | \ x95549f5fcfc370eb4b24c981a6053f909bdef6418ce896828c6be18fa31ab406 | 6 | 1731 | 195 | 2020-05-29 08:57:51 | 3
4225045 | \ x275ee8b9ae441e6e32e1f7f36290e6a048722619d91195773a07b06682418209 | 4226980 | 4224831 | 4225043 | \ x6eb04497431d77657a94b0eee70dae59e7403980d4fc9d06ba5295436b8f0f54 | 7 | 1418 | 195 | 2020-05-29 08:58:11 | 2
(2 صفوف)

kevinhammond في ١١ يونيو ٢٠٢٠

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

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