الانتقال إلى المحتوى
Financial Context Wiki

الذاتية الضعيفة: نقاط تحقق موثوقة ومزامنة PoS آمنة

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

آخر تحديث

لأغراض تعليمية فقط؛ لا يشكل ذلك نصيحة استثمارية أو توصية استثمارية. قد تؤدي الاستثمارات إلى خسائر.

إجابة مباشرة

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

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

على Ethereum، نقطة التحقق ذات الموضوعية الضعيفة هي epoch و block_root التي يعتبرها العميل مرساة مطلقة. يجب على المزامنة الناجحة إثبات أن المسار القانوني يحتوي على ذلك الجذر في تلك الحقبة؛ فإن عدم التطابق يعتبر فشلاً حرجًا، وليس تصويتًا لاختيار الفرع. كما تختلف نقطة التحقق ذات الموضوعية الضعيفة عن نقطة التحقق النهائية العادية: إذا صادف العقد لأول مرة تاريخين نهائيين متعارضين بدون ذاكرة سابقة، فإن قواعد النهائية وحدها لا تحدد أي تاريخ اجتماعي هو القانوني.

لا تُعمم آلية Ethereum. تبدأ عملاء الضوء CometBFT من عنوان موثوق ضمن trusting_period مهيأ وتنقل الثقة باستخدام تداخل مجموعة المدققين، والتوقيعات، وحدود الوقت، والشهود. تُعرف أبحاث Ouroboros Genesis بدلاً من ذلك قاعدة اختيار السلسلة التي تهدف إلى بدء التشغيل من كتلة الأصل الموثوقة تحت نموذج الأمان المحدد الخاص بها. لذلك، لا يعني “إثبات الحصة” وجود تنسيق نقطة تحقق واحد، أو صيغة فترة واحدة، أو إجراء بدء تشغيل واحد.

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

كيفية التحقق من تشغيل البداية ذات الذاتية الضعيفة

1. تحديد البروتوكول الدقيق ونموذج الأمان

سجّل network و chain ID وجذر الجينيسيس أو التجزئة، والتفرع النشط أو وقت التشغيل، وإصدار العميل، ونوع نقطة التفتيش، ومواصفات الإجماع. حدد ما إذا كان البروتوكول يتطلب نقطة تفتيش اجتماعية حديثة، أو رأس موثوق بالإضافة إلى مجموعة المدققين، أو سلسلة إثبات النهاية، أو مجرد الجينيسيس تحت نموذج مختلف. لا تنقل أبدًا compute_weak_subjectivity_period من Ethereum أو trusting_period من CometBFT إلى سلسلة أخرى دون قواعدها.

2. قرر ما إذا كانت الثقة الحالية ما زالت سارية

احصر آخر نقطة تحقق نهائية تم التحقق منها محليًا للعقدة، وعصرها أو ارتفاعها والوقت، ومصدر الوقت الحالي، وأي استعادة لقاعدة البيانات. احسب العمر باستخدام قواعد وبنية البروتوكول الحية، وليس تقدير تقويمي محفوظ في الذاكرة. بالنسبة لـ Ethereum، يختبر دليل المرحلة 0 current_epoch <= ws_state_epoch + ws_period؛ تقوم Electra بتغيير حساب الفترة ليعتمد على إجمالي الرصيد النشط وتقلبات الرصيد. إذا انتهت صلاحية الثقة، احصل على مرساة جديدة خارج النطاق بدلاً من المحاولة بجهد أكبر ضد النظراء غير الموثوقين.

3. الحصول على نقطة التفتيش والتحقق منها

احصل على نفس نقطة التحقق من قنوات تُدار بشكل مستقل ومن مصادر مستقلة: على سبيل المثال، عقدة تديرها بنفسك، مشغل آخر، فرق عمل متعددة من العملاء، ومستكشفون لديهم بنية تحتية متميزة. سجّل كل مصدر، ووقت الاسترجاع، والشبكة، وepoch، والجذر الكامل. خمس روابط تنسخ من مصدر واحد تعتبر نطاق فشل واحد. الأغلبية البسيطة في الرد لا تُعد بديلاً عن استقلالية المصدر أو النقل الموثق أو مراجعة الحوادث الاجتماعية.

4. اربط كل حقل نقطة تفتيش

تحقق من الشبكة وهوية البداية قبل قيمة نقطة التفتيش. حافظ على الجذر الكامل دون اختصار ورفقه بالقيمة الدقيقة للعصر أو الارتفاع، والحالة إذا لزم الأمر، وإصدار التفريع، ووقت الاستحواذ. دليل Ethereum يستخدم block_root:epoch_number؛ تهيئة CometBFT تربط أيضًا رأس موثوق ومجموعة المدققين بالإضافة إلى معلمات الثقة. الجذر الصحيح المرتبط بالسلسلة الخاطئة أو الارتفاع الخاطئ ليس مرساة صالحة.

5. فرض مسار تزامن يغلق في حالة الفشل

قم بتكوين نقطة التفتيش من خلال واجهة العميل الموثقة واحتفظ بسجلات بدء التشغيل. خلال المزامنة، اشترط أن يكون المسار القانوني عند عصر نقطة التفتيش مساويًا للقيمة المزودة block_root. يتطلب دليل Ethereum خطأً حرجًا وصفيًا وخروج العملية عند فشل التأكيد. لا تتجاهل نقطة التفتيش بصمت، ولا ترجع إلى أغلبية النظراء، ولا تستبدلها باستجابة نظير أحدث، ولا تسمح للمدقق بالتوقيع بينما تكون رؤيته للإجماع غير مؤكدة.

6. فصل الطبقات التي تم التحقق منها والتي لم يتم التحقق منها

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

7. تحديث، مراقبة، وتدريب على الاستعادة

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

أمثلة محلولة

نقطة التفتيش Ethereum مع مساحة متبقية

استخدم حالة توضيحية حيث تعطي حسابات إلكترا المرجعية المطبقة ws_period = 3,532 epochs. افترض أن current_epoch = 420,000 ونقطة الفحص التي تم التحقق منها بشكل مستقل هي checkpoint_epoch = 418,200:

checkpoint_age = 420,000 - 418,200 = 1,800 epochs.

اختبار حداثة الدليل هو 420,000 <= 418,200 + 3,532، لذا نقطة التفتيش ضمن الفترة. عند 32 slots * 12 seconds = 6.4 minutes per epoch، عمره هو 1,800 * 6.4 / 1,440 = 8 days. المساحة المتبقية هي 3,532 - 1,800 = 1,732 epochs، أو 1,732 * 6.4 / 1,440 = 7.6978 days. هذا يستخدم فترة جدول مرجعي، وليس وعد شبكة حية؛ يجب على العميل الحساب من الفورك والحالة الفعلية.

لم يتم إصلاح نقطة التفتيش المنتهية الصلاحية بواسطة المزيد من الأقران

افترض current_epoch = 500,000 وcheckpoint_epoch = 496,000 وws_period = 3,532 epochs المعمول بها:

checkpoint_age = 500,000 - 496,000 = 4,000 epochs.

لأن 500,000 > 496,000 + 3,532، نقطة التحقق قديمة بمقدار 4,000 - 3,532 = 468 epochs. عند 6.4 دقيقة لكل حقبة، هذا يتجاوز الحد بمقدار 468 * 6.4 / 60 = 49.92 hours. تحميل نفس الجذر منتهي الصلاحية من 100 أقران لا يعيد الافتراض؛ يحتاج المشغل إلى نقطة تحقق حديثة بما فيه الكفاية من قنوات موثوقة ومتآزرة.

عدد المصادر مقابل استقلال المصدر

يتلقى المشغل خمس ردود. الأربعة منها تُبلغ عن epoch = 600,000 وجذر كامل متطابق موسوم بـ root_A، في حين يُبلغ واحد عن جذر كامل مختلف موسوم بـ root_B. تُظهر التحقيقات أن المواقع الثلاثة المتفقة جميعها تستخدم وسيطاً لنفس العقدة المستضافة؛ والرابع هو عقدة المشغل نفسه. الاتفاق الظاهر هو 4 / 5 = 80%، لكنه يمثل فقط سلسلتين مستقلتين. بموجب سياسة تتطلب ثلاث مسارات إدارية وبيانية مستقلة، لم يتم بعد الموافقة على نقطة التفتيش. ويؤكد مشغل مستقل ثالث root_A، بينما يتم عزل الخدمة المخالفة، ويوضح سجل الأصل سبب القرار.

ميزانية فترة الثقة بأسلوب CometBFT

ضع في الاعتبار سلسلة مُكوّنة باستخدام unbonding_period = 21 days ومشغّل مختار trusting_period = 14 days، متسقة مع المتطلب القائل بأن تكون فترة الثقة أقصر من فترة فك الربط. يحتوي رأس موثوق مُسن 11 days على 14 - 11 = 3 days من الهامش. يترك هدف التحديث اليومي هامشًا تشغيليًا. إذا عاد العميل بعد 16 days، يكون الرأس قد تجاوز فترة الثقة بيومين ويجب استبداله من خلال بدء موثوق جديد؛ صيغ عصر Ethereum لا تقرر هذه الحالة CometBFT.

المخاطر وفشل المراجعة

  • شبكة خاطئة: قد يثبت جذر صالح من شبكة اختبار أو فورك أو نسخة مستنسخة أو جينيسيس مختلف تاريخًا خاطئًا.
  • نقطة تحقق قديمة: لا يحقق الجذر خارج الفترة المعمول بها افتراض مجموعة المدققين الحديثة.
  • صيغة فترة خاطئة: قد تغير ترقيات الفورك والأرصدة ومعدل الدوران وفك الربط ومعلمات الأمان الحد.
  • مصدر موحد: قد تشترك نقاط نهاية متعددة في عقدة أو حساب سحابي أو قاعدة بيانات أو مزود DNS أو مشغل واحد.
  • قناة توزيع مخترقة: قد يستبدل إصدار أو موقع أو حزمة أو رد DNS أو رسالة دعم خبيثة نقطة التحقق.
  • مقارنة مختصرة: قد تخفي مقارنة بادئة أو لقطة شاشة أو معرف منسق فقط اختلاف الجذر الكامل.
  • حقول غير متطابقة: الجذر الصحيح مع عصر أو ارتفاع أو حالة أو فورك أو سلسلة خاطئة ليس نقطة التحقق نفسها.
  • الرجوع إلى أغلبية النظراء: قد ترى العقدة الخاضعة لهجوم الحجب نظراء خصومًا كثيرين؛ العدد لا يتغلب على المرجع الموثوق.
  • رجوع صامت: العميل أو الغلاف الذي يتجاهل نقطة تحقق مرفوضة يبطل التحكم في الإغلاق عند الفشل.
  • تواريخ نهائية متضاربة: لا تحل عقدة جديدة فشل الإجماع لمجرد وسم الفرعين بأنهما نهائيان.
  • خطأ الساعة: يفسد الوقت المحلي الخاطئ فحوصات الفتحة والعصر والعمر وفترة الثقة والرؤوس المستقبلية.
  • التباس الحالة المتفائلة: قد تحتوي كتلة إجماع مستوردة على حمولة تنفيذ لم تتحقق بالكامل.
  • مهام مدقق مبكرة: قد يسبب التوقيع في حالة متفائلة أو غير متزامنة أو على مرجع غير مؤكد أصواتًا خاطئة أو قطعًا.
  • التباس اكتمال التاريخ: قد تحذف المزامنة وإعادة الملء حالات تاريخية حتى لو كان الرأس الحالي صالحًا.
  • تواقيع إعادة ملء غير صالحة: ما زالت الكتلة التاريخية المرتبطة بالهاش تحتاج إلى فحص توقيع المقترح المطلوب.
  • إثبات تنفيذ أو تطبيق غير كاف: لا يثبت مرجع الإجماع قيم RPC اعتباطية أو ادعاءات العقود أو الفهارس خارج السلسلة.
  • فجوة توافر البيانات: لا تضمن معرفة جذر الحالة الوصول إلى كل جسم أو Blob أو شاهد أو سجل تاريخي.
  • خطة استرداد منتهية: إذا اكتشف الانتهاء أثناء العطل، فقد لا يتوفر مصدر مستقل لنقطة التحقق.
  • الاستحواذ على التنسيق الاجتماعي: قد تشترك الحوكمة وفرق العملاء والمستكشفون والبورصات والمشغلون في الحوافز أو التبعيات.
  • تعميم خاطئ: قد يستخدم تصميم PoS آخر افتراضات أو سلاسل إثبات أو فترات ثقة أو ضمانات بدء من الجينيسيس مختلفة.

المفاهيم الخاطئة الشائعة

هل تعني الذاتية الضعيفة أن قواعد البروتوكول تكون ذاتية بعد بدء التشغيل؟

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

هل أي نقطة تحقق مكتملة تعتبر تلقائيًا نقطة تحقق تمهيدية آمنة؟

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

هل يؤدي المزامنة من الجينيسيس إلى إزالة مشكلة الهجوم بعيد المدى؟

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

هل يتحقق مزامنة نقطة التفتيش من جميع التنفيذات والحالات السابقة؟

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

هل يمكن الوثوق بنقطة التحقق المبرمجة بشكل دائم؟

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

مواضيع ذات صلة

المصادر

التنقل

ابحث في الويكي...