💻 computer science

Distance-Preserving Digests: A Primitive for BFT Consensus

تقدم هذه الورقة "ملخصات حافظة للمسافة" (distance-preserving digests)، وهي وسيلة بدائية تستخدم مجموعات متجهية تبادلية بدلاً من الدوال الهاشية مقاومة التصادم لتمكين نهائية أحادية الجولة وفعالة وإجماع بيزنطي (BFT) ذو بنية شجرية قابل للتوسع، وذلك عبر السماح للمدققين بقياس عدم الاتفاق في الحالة والتحقق من الاتساق دون الحاجة إلى مزامنة كاملة للحالة.

المؤلفون الأصليون: Ryan Patrick Mercier

نُشر 2026-05-18

📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Ryan Patrick Mercier

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

تخيل مجموعة ضخمة من الناس يحاولون الاتفاق على قائمة واحدة من القواعد للعبة ما. في عالم البلوكشين والشبكات الآمنة، تُسمى هذه المجموعة "بروتوكول الإجماع" (Consensus Protocol). لعقود من الزمن، كانت الطريقة القياسية للتحقق مما إذا كان الجميع متفقين هي تشبه مقارنة قائمتين عبر تحويلهما إلى كود واحد غير قابل للكسر ("هاش" - Hash).

إليك المشكلة في تلك الطريقة القديمة: إنها تدمر التفاصيل الدقيقة.

إذا كان لدى الشخص (أ) 19 عنصرًا صحيحًا من أصل 20، وكان لدى الشخص (ب) 20 عنصرًا كاملة، فإن الطريقة القديمة تقول إن أكوادهما مختلفة تمامًا. الأمر يشبه القول بأن قائمة بها خطأ مطبعي واحد هي "خاطئة" تمامًا مثل قائمة لا تحتوي على أي عناصر على الإطلاق. ولأن النظام لا يستطيع التمييز بين "شبه مثالي" و"معطل تمامًا"، فإنه يجبر الجميع على التوقف، وإعادة إرسال قوائمهم بالكامل، والانتظار حتى يحدث تطابق مثالي قبل المضي قدمًا. هذا يجعل العملية بطيئة، ومكلفة، وتتطلب مجموعات ضخمة من الناس لتكون آمنة.

تقدم هذه الورقة أداة جديدة تسمى "الملخصات الحافظة للمسافة" (Distance-Preserving Digests). فكر في الأمر كـ "نظام مطابقة مرن" يسمح للمجموعة برؤية مدى قربهم من الاتفاق، بدلاً من مجرد السؤال "هل نحن متطابقون؟".

الفكرة الجوهرية: تشبيه "مجموع المتجهات"

بدلاً من تحويل قائمة المعاملات إلى كود واحد جامد، تقترح الورقة تحويل كل معاملة إلى سهم صغير (متجه - Vector) في مساحة ثمانية الأبعاد.

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

هذا يسمح للنظام بقياس المسافة.

المسافة = 0: الجميع لديهم نفس القائمة تمامًا.
المسافة = ضئيلة: الجميع ينقصه عنصر أو عنصران فقط (ربما بسبب اتصال إنترنت بطيء).
المسافة = ضخمة: شخص ما يكذب أو لديه قائمة مختلفة تمامًا.

ثلاثة تحسينات كبرى

تدعي الورقة أن هذا التغيير البسيط يحل ثلاث مشكلات رئيسية في تصميم البلوكشين:

1. "المسار السريع" للاتفاق

الطريقة القدة: حتى لو اتفق الجميع بشكل مثالي، يجب على النظام تشغيل ثلاث جولات بطيئة من التصويت للتأكد.
الطريقة الجديدة: نظرًا لأن النظام يمكنه رؤية أن الجميع قريبون جدًا (المسافة تقترب من الصفر)، يمكنه القول فورًا: "حسنًا، أنتم جميعًا متفقون!" وإنهاء القرار في جولة واحدة. الأمر يشبه معلمًا يرى أن الفصل جاهز بنسبة 99% فيقول: "رائع، لننتقل لما بعده"، بدلًا من الانتظار لإجراء تصويت رسمي.

2. فرق أصغر وأعمق

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

3. إصلاح فوضى الربط بين السلاسل (Cross-Chain)

الطريقة القدة: عندما يحتاج جزءان مختلفان من البلوكشين إلى التواصل مع بعضهما البعض، يتعين عليهما عادةً إرسال رسالة لكل معاملة مفردة للتحقق مما إذا كانت متطابقة. هذا يشبه فحص كل طوبة في جدارين مختلفين للتأكد من أنهما متطابقان.
الطريقة الجديدة: هم يتبادلون فقط "ملخصات المسافة" الخاصة بهم. إذا تطابقت الملخصات، فذلك رائع. وإذا لم تتطابق، يستخدم النظام "مرشح بلوم" (Bloom Filter) خاصًا (مثل قائمة مراجعة سريعة) للعثور على بالضبط الطوبات القليلة المختلفة وإصلاح تلك الطوبات فقط. هذا يقلل تكلفة الاتصال بنسبة 99% في كثير من الحالات.

كيف يعمل الأمر (العملية المكونة من مرحلتين)

تصف الورقة بروتوكولًا يسمى "بروكسيما" (Proxima) يستخدم هذه الأداة في خطوتين:

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

النتائج

تقارن الورقة هذا النظام الجديد (Proxima) مقابل المعيار الصناعي الحالي (HotStuff):

السرعة: على نواة حاسوب واحدة، بروكسيما أسرع بنحو 20 مرة (0.9 ثانية مقابل 18 ثانية) لأنه يتخطى الجولات غير الضرورية.
الكفاءة: مع وجود 100,000 مُصادق (Validator)، يرسل بروكسيما رسائل أقل بمقدار 2.2 مرة من النظام القديم.
الأمان: تثبت الرياضيات أنه طالما أن أقل من 33% من المجموعة خبيثة، فلا يمكن خداع النظام لقبول قاعدتين مختلفتين في نفس الوقت.

الخلاصة

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

ملخص تقني: الملخصات الحافظة للمسافة لبروتوكولات إجماع BFT

1. بيان المشكلة

تعتمد بروتوكولات إجماع تحمل الخطأ البيزنطي (BFT)، بما في ذلك HotStuff وPBFT وEthereum 2.0، على دوال هاش مقاومة للتصادم (مثل SHA-256) لمقارنة حالات المصدقين (Validators). وبينما هي فعالة لمنع التزوير، إلا أن هذا النهج يدمر معلومات "المسافة". فإذا اتفق اثنان من المصدقين على 19 معاملة من أصل 20، فإن قيم الهاش الخاصة بهما ستكون غير مرتبطة تمامًا، مما يجعل من المستحيل التمييز بينهما وبين مصدقين لا يتشاركون أي معاملات. يفرض هذا القصور ثلاثة قيود هيكلية على أدبيات BFT:

المزامنة الإلزامية للحالة: يجب على المصدقين مزامنة الحالة بالكامل قبل التصويت، حيث لا يمكن للهاشات قياس الاتفاق الجزئي.
عدم القدرة على قياس جودة الاتفاق: لا تستطيع البروتوكولات اكتشاف الاتفاق بالإجماع حتى تكتمل جميع جولات التصويت، مما يفرض زمن انتقال ثابت لعدة جولات حتى في الظروف المثالية.
اللجان الهرمية الكبيرة: لضمان السلامة في الإجماع ذي البنية الشجرية، يجب أن تكون المجموعات الورقية (Leaf groups) كبيرة بما يكفي (على سبيل المثال 128 مصدقًا في Ethereum) لتلبية عتبة تحمل الخطأ البيزنطي $2N/3$ بشكل مستقل، مما يحد من عمق الشجرة وقابلية التوسع.

2. المنهجية: الملخصات الحافظة للمسافة

يقدم البحث وسيطًا يُسمى الملخصات الحافظة للمسافة (Distance-Preserving Digests) لاستبدال الهاشات مقاومة التصادم في مقارنة الحالة. يتضمن البناء ما يلي:

التحويل إلى متجه (Vectorization): يتم تجزئة كل معاملة باستخدام SHA-512. ويتم تقسيم المخرجات المكونة من 64 بايت إلى 8 أجزاء.
رسم الخرائط الإحداثية (Coordinate Mapping): يُعامل كل جزء كعدد صحيح غير سالب، ويُختزل بمقدار 10,000 ثم يُقسم على 10,000 لإنتاج إحداثي في النطاق $[0, 1)$ .
الجمع التبادلي (Commutative Summation): ملخص المصدق لمجموعة من المعاملات $T$ هو مجموع المتجهات $D(T) = \sum_{tx \in T} v(tx)$ في فضاء ذي 8 أبعاد.

يمتلك هذا الوسيط ثلاث خصائص تفتقر إليها الهاشات:

المسافة النسبية: المسافة الإقليدية بين ملخصين تتناسب طرديًا مع عدد المعاملات المختلفة.
التلخيص الدقيق: المتوسط الموزون لمجموعة من الملخصات هو تمثيل دقيق للحالة الإجمالية للمجموعة، مما يسمح بتلخيص مجموعة من المصدقين في قيمة واحدة مدمجة (76 بايت) دون فقدان للمعلومات.
تحديد فرق المجموعة: عندما تختلف الملخصات، يمكن لمرشح Bloom diff للمجمع تحديد المعاملات المفقودة بالضبط من رؤية أحد المصدقين، مما يتيح المزامنة المستهدفة دون تبادل الحالة الكاملة.

3. المساهمات والتطبيقات الرئيسية

يستعرض البحث ثلاثة تطبيقات رئيسية لهذا الوسيط ضمن بروتوكول جديد يسمى Proxima:

أ. بروتوكول BFT ثنائي المرحلة (Proxima)

يعمل Proxima في مرحلتين:

المرحلة 1 (تصفية المسافة): يرسل المصدقون الملخصات ومرشحات Bloom إلى المجمع. يقوم المجمع بتجميع المصدقين ضمن عتبة مسافة معينة. إذا كان تباين المجموعة قريبًا من الصفر (مما يشير إلى اتفاق عالٍ)، يصدر البروتوكول شهادة نهائية أحادية الجولة (Fast Path). وإذا لم يكن كذلك، يقوم بدفع المعاملات المفقودة عبر Bloom diff.
المرحلة 2 (الالتزام): يوقع أعضاء المجموعة على هاش الكتلة باستخدام تواقيع BLS. وينتج المجمع توقيعًا مجمعًا.
النتيجة: على عكس HotStuff، الذي يتطلب ثلاث جولات بغض النظر عن مستوى الاتفاق، يحقق Proxima نهائية أحادية الجولة عندما يكون هناك اتفاق.

ب. الإجماع ذو البنية الشجرية مع مجموعات صغيرة

بسبب قدرة تصفية المسافة على العمل على المستوى الفردي بدلاً من اشتراط الإجماع على مستوى المجموعة، يتيح Proxima إجماعًا هرميًا بمجموعات صغيرة (مثل 10 مصدقين).

الآلية: تقوم القادة الورقية (Leaf leaders) بتصفية المصدقين البيزنطيين (البعيدين عن المرجع) وتقرير المتوسط الموزون للمصدقين الشرفاء.
النتيجة: هذا يلغي الحاجة إلى لجان كبيرة (128 مصدقًا) لضمان السلامة، مما يسمح بأشجار أكثر عمقًا (5 مستويات مقابل 2-3 مستويات) ويقلل من تعقيد الرسائل.

ج. التحقق من اتساق عبر الشظايا (Cross-Shard)

تسمح الملخصات بالتحقق بتكلفة ثابتة بين الشظايا.

الآلية: تتبادل الشظايا المتجاورة ملخصات معاملات منطقة التداخل. إذا كانت المسافة صفرًا، فإن الحالات متطابقة. وإذا كانت غير صفرية، يحدد Bloom diff المعاملات المتباعدة لتحديد الحل.
النتيجة: هذا يستبدل التنسيق لكل معاملة في بروتوكول Two-Phase Commit (2PC) أو سلاسل الإيصالات، مما يقلل من عبء العمل عبر الشظايا بنسبة 99% مقارنة بـ 2PC عند معدلات انتشار 95%.

4. النتائج والتقييم

يقيم البحث بروتوكول Proxima مقابل Hotstuff وPBFT وهيكل لجان Ethereum باستخدام محاكاة مع $N=100,000$ مصدق و30% من الأخطاء البيزنطية.

تعقيد الرسائل: يستخدم Proxima Tree أقل بـ 2.2 مرة من الرسائل مقارنة بـ HotStuff. هذه خاصية هيكلية لا تتأثر بالتوازي، ناتجة عن التنفيذ ثنائي المرحلة، والتصفية المسبقة للعقد البيزنطية، وتوجيه الشجرة بالملخصات المدمجة.
زمن الانتقال (Latency):
- النواة الواحدة (Single-Core): يحقق Proxima نهائية أحادية النواة في ~0.9 ثانية (902 مللي ثانية) مقارلة بـ ~18 ثانية لـ HotStuff. توزع البنية الشجرية تجميع BLS، مما يبقي معالجة المسار الحرج منخفضة (9.9 مللي ثانية).
- متعدد النواة (Multi-Core): بينما يقلص تجميع BLS متعدد النواة الفجوة (ينخفض HotStuff إلى ~940 مللي ثانية، وProxima Flat إلى ~220 مللي ثانية)، إلا أن الشجرة تحتفظ بالأفضلية في وقت BLS للمسار الحرج لأن العقد الورقية تعالج عددًا قليلًا جدًا من التواقيع.
عبء العمل عبر الشظايا: عند انتشار 95%، يستخدم التحقق القائم على الملخص رسائل أقل بنسبة 99% من 2PC وبنسبة 95% من النهج القائم على الإيصالات (NEAR Nightshade).
السلامة: تم إثبات السلامة بشكل مستقل عن تجميع المرحلة الأولى. لا يمكن لأقل من $N/3$ من المصدقين البيزنطيين التسبب في نهائية متضاربة. قد تستبعد المرحلة الأولى بعض المصدقين الشرفاء (خطر على حيوية النظام/Liveness)، لكن هذا محدود بموجب متباينة Hoeffding ليكون ضئيلاً للغاية ( $<10^{-9}$ عند $N$ عملية).

5. الأهمية والادعاءات

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

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

يؤكد المؤلفون أنه بينما يعد هذا الوسيط تطبيقًا معروفًا لـ Locality-Sensitive Hashing (LSH) في هياكل البيانات، فإن تطبيقه على الاتفاق البيزنطي يعد أمرًا مبتكرًا. تعتمد سلامة النظام على الافتراضات التشفيرية القياسية (تواقيع BLS وSHA-512)، حيث يعمل مرشح المسافة كآلية للحيوية والتحسين وليس كآلية للسلامة. ويخلص البحث إلى أن هذا النهج يقدم تحسينًا عامًا لأي بروتوكول BFT يقارن الحالة عبر الهاشات.