💻 computer science

Catching the Fly: Practical Challenges in Making Blockchain FlyClient Real

تنقل هذه الورقة بروتوكول التحقق من البلوكشين خفيف الوزن FlyClient من الجانب النظري إلى مرحلة الإنتاج عبر تقديم نموذج خصم جديد للبارامترات الاقتصادية، وتنفيذ أول مُثبت عملي لعملة Zcash، واقتراح تحسينين لتقليل أحجام الإثباتات دون الحاجة إلى تغييرات في آلية الإجماع.

المؤلفون الأصليون: Pericle Perazzo, Dario Capecchi

نُشر 2026-04-30

📖 5 دقيقة قراءة🧠 قراءة متعمّقة

CC BY 4.0

المؤلفون الأصليون: Pericle Perazzo, Dario Capecchi

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

إليك شرح لورقة البحث "Catching the Fly: Practical Challenges in Making Blockchain FlyClient Real" باستخدام لغة بسيطة وتشبيهات من الحياة اليومية.

الصورة الكبيرة: مشكلة "الخفة"

تخيل أنك تريد التحقق مما إذا كانت مكتبة ضخمة (البلوكشين) تقول الحقيقة بشأن كتاب معين بداخلها.

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

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

المساهمات الثلاث الرئيسية

قام المؤلفون بثلاثة أشياء رئيسية لتحويل هذه النظرية إلى واقع ملموس لعملة Zcash (وهي عملة مشفرة محددة).

1. طريقة جديدة لقياس "الأشرار" (نموذج الخصم)

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

الحل: قدم المؤلفون نموذج "wa-adversary".

التشبيه: بدلاً من القول، "لا يمكن للرجل السيئ بناء جدار أعلى من 10 أقدام"، يقولون "الرجل السيئ لديه 20,000 دولار فقط لإنفاقها على الطوب".
لماذا يساعد هذا: هذا يجعل من السهل حساب مدى الأمان الذي يحتاجه نظامك بالضبط. إذا كان المهاجم يحتاج إلى 20,000 دولار لكسر النظام، وكانت إعدادات الأمان الخاصة بك تكلف 13 دولاراً فقط للصيانة، فأنت تعلم أنك في أمان. ساعد هذا النموذج الجديد أيضاً في تقليص كمية البيانات المطللة لإثبات سلامة النظام، مما وفر حوالي 37% من البيانات مقارنة بالطريقة القديمة.

2. بناء "مولد الإثبات" (تنفيذ المبرهن)

المشكلة: يحتاج FlyClient إلى جانبين: المُتحقق (الجهاز الخفيف الذي يفحص الإثبات) والمُبرهن (الكمبيوتر الكامل الذي يمتلك البلوكشين بالكامل ويقوم بتوليد الإثبات). بينما كان "المتحققون" نظريين، لم يقم أحد ببناء "مبرهن" لبرنامج بلوكشين حقيقي وحي مثل Zcash.

الحل: قام المؤلفون بتوسيع برنامج Zebrad، وهو البرنامج الرسمي لـ Zcash، ليعمل كـ "مبرهن".

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

3. التخلص من الزوائد (التحسينات)

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

الحل: اختبروا طريقتين لجعل الإيصالات أصغر حجماً:

التحسين (أ): "الإثبات التراكمي" (بدون تكلفة)
- التشبيه: تخيل أنك بحاجة لإثبات أنك زرت ثلاث غرف محددة في منزل ما. الطريقة القديمة كانت تتطلب الحصول على مفتاح منفصل وخريطة منفصلة لكل غرفة. الطريقة "التراكمية" الجديدة هي الحصول على خريطة واحدة تظهر المسار الذي يربط الغرف الثلاث معاً في آن واحد.
- النتيجة: وفر هذا حوالي 9% من حجم البيانات. إنه ترقية مجانية يمكن استخدامها الآن دون تغيير قواعد البلوكشين.
التحسين (ب): "الإثبات المقطر" (يتطلب تغييراً في القواعد)
- التشبيه: كانت الإيصالات الأصلية ضخمة لأنها تتضمن "حل فك القفل" (كود يبلغ حجمه 1,344 بايت يسمى Equihash) المطلوب لإثبات أن العمل قد تم. هذا يشبه إرسال مخطط كامل الحجم لمجرد إثبات أن الباب مغلق.
- الإصلاح: اقترح المؤلفون تغيير قواعد البلوكشين لاستخدام "قفل" مختلف يتطلب فقط "مفتاحاً" صغيراً (32 بايت) بدلاً من مخطط كامل. كما قاموا بإزالة الحقول الأخرى غير الضرورية من البيانات، مع الإبقاء فقط على ما هو مطلوب للإثبات.
- النتيجة: هذا تحسن هائل. لقد قلص حجم الإثبات بنسبة 71%.
- الأثر في العالم الحقيقي: بالنسبة لـ "الجسر غير الموثوق" (نقل العملات المشفرة من سلسلة إلى أخرى)، فإن إرسال هذا الإثبات إلى عقد ذكي سيكلف حوالي 3.44 دولار بدلاً من 13.21 دولار.

ملخص النتائج

تثبت الورقة البحثية أن FlyClient جاهز للعالم الحقيقي.

الأمان: أنشأوا طريقة جديدة لقياس الأمان تعتمد على المال، وهي أسهل في الفهم وأكثر كفاءة.
الجدوى: بنوا أول "مولد إثبات" عامل لـ Zcash، مما أظهر أنه لا يبطئ الشبكة.
الكفاءة: باستخدام تحسيناتهم الجديدة، قللوا البيانات المطلوبة للتحقق من البلوكشين بشكل كبير. طريقة "الإثبات المقطر"، رغم أنها تتطلب ترقية للشبكة، تجعل عملية التحقق من البلوكشين رخيصة وسريعة للغاية، مما يجعلها قابلة للتطبيق لمحفظات الهاتف المحمول والجسور بين السلاسل (cross-chain bridges).

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

إليك ملخص تقني مفصل لورقة البحث "Catching the Fly: Practical Challenges in Making Blockchain FlyClient Real".

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

يُعد FlyClient بروتوكولاً نظرياً صُمم لتمكين التحقق فائق الخفة من سلاسل الكتل القائمة على إثبات العمل (PoW). فهو يسمح للعملاء (مثل المحافظ المحمولة، أو أجهزة إنترنت الأشياء، أو العقود الذكية) بالتحقق من صحة سلسلة الكتل بتعقيد بيانات لوغاريتمي ( $O(\log n)$ ) بدلاً من التعقيد الخطي، وذلك باستخدام أخذ عينات احتمائية من رؤوس الكتل والتزامات "مرتقى ميركل" (Merkle Mountain Range - MMR).

على الرغم من وعوده النظرية، يواجه FlyClient عوائق كبيرة أمام النشر في العالم الحقيقي:

نقص في التنفيذ الإنتاجي: لم تكن هناك أي تنفيذات موجودة لجهات الإثبات (prover implementations) لسلاسل الكتلك الرئيسية (تحديداً Zcash، التي تدعم FlyClient أصلاً عبر تحديث جذري/hard fork).
نماذج الخصوم المجردة: يعتمد نموذج الأمان الأصلي على خصم من نوع $(c, L)$ (وهو مهاجم لا يمكنه إنتاج تفرع بطول $L$ مع نسبة صلاحية $c$ ). هذا النموذج مريح رياضياً، لكنه يفتقر إلى التفسير الاقتصادي المباشر، مما يجعل من الصعب على الممارسين تهيئة أدوات التحقق بناءً على ميزانيات الهجوم في العالم الحقيقي.
عدم كفاءة حجم الإثبات: تهيمن مكونات رأس الكتلة الكبيرة (تحديداً حلول Equihash في Zcash) على أحجام الإثباتات الحالية، مما يجعل التحقق على السلسلة (on-chain verification) (مثل الجسور عبر السلاسل) مكلفاً للغاية من حيث تكاليف الغاز (gas costs).
فجوات الأداء: كان هناك نقص في البيانات التجريبية المتعلقة بالعبء الإضافي للموارد المطلوب لتشغيل مُثبت FlyClient، والمتطلبات الفعلية للنطاق الترددي والتخزين تحت ظروف شبكة متنوعة.

2. المنهجية

سد المؤلفون الفجوة بين النظرية والتطبيق من خلال ثلاث ركائز منهجية رئيسة:

أ. الصقل النظري: نموذج الخصم $w_a$

قدم المؤلفون نموذج الخصم $w_a$ ، الذي يستبدل معلمات $(c, L)$ المجردة بمعلمة واحدة ملموسة وهي: ميزانية العمل العدائي ( $w_a$ ).
يحدد هذا النموذج قدرة المهاجم بناءً على الحد الأقصى للعمل التراكمي الذي يمكنه إنتاجه في ظل ميزانية نقدية محددة (مثل تكلفة الكهرباء والأجهزة).
استخلصوا إجراءً رياضياً للتحسين لربط هذه الميزانية الاقتصادية بمعلمات البروتوكول المثلى ( $n_{det}$ و $n_{prob}$ )، مما يقلل من عدد الرؤوس التي يتم أخذ عينات منها مع الحفاظ على مستوى أمان مستهدف ( $\lambda$ ).

ب. التنفيذ: مُثبت Zcash FlyClient

قام الفريق بتوسيع Zebrad، وهو التنفيذ الرسمي لعقدة كاملة لـ Zcash بلغة Rust، ليعمل كمُثبت FlyClient.
قاموا بتنفيذ وظائف محددة لنداء الإجراءات عن بُعد (RPC) لتقديم رؤوس الكتل، وعُقد MMR، وبيانات العمل الإجمالية.
أجروا اختبارات قياس الأداء لقياس تأثير صيانة قاعدة بيانات عقدة MMR على أوقات مزامنة العقد ومتطلبات التخزين.

ج. استراتيجيات التحسين

اقترح المؤلفون وقيموا استراتيجيتين متميزتين لتقليل حجم الإثبات:

الإثباتات التراكمية (Cumulative Proofs): تحسين على مستوى البرمجيات حيث يقوم المُتحقق بتنزيل إثبات MMR واحد يغطي جميع الكتل المختارة في آن واحد، بدلاً من إثباتات فردية لكل كتلة. هذا يلغي عمليات تنزيل العُقد المتكررة دون الحاجة إلى تغييرات في الإجماع.
الإثباتات المقطرة (Distilled Proofs): تحسين على مستوى الإجماع يتطلب تحديثاً جذرياً (hard fork). يتضمن ذلك:
- استبدال خوارزمية Equihash التي تتطلب ذاكرة كبيرة (والتي تتطلب تخزين حلول بحجم 1344 بايت في الرؤوس) بخوارزمية PoW أكثر كفاءة في المساحة (مثل Ethash/RandomX) أو بنوع ذي حلول صغيرة.
- "تقطير" رؤوس الكتل لتشمل فقط الحقول الضرورية للتحقق من FlyClient (إزالة بيانات المعاملات والجذور غير الضرورية).
- "تقطير" عُقد MMR لتخزين الحقول الأساسية فقط وتجزئات (hashes) البقية.

3. المساهمات الرئيسية

نموذج الخصم الاقتصادي: يسمح تقديم نموذج الخصم $w_a$ بتهيئة أدوات التحقق في FlyClient بشكل حدسي بناءً على الميزانية. وقد ثبت أن هذا النموذج يستوفي ضمانات الأمان لنموذج $(c, L)$ الأصلي مع توفير تقليل في حجم الإثبات يصل إلى 37% من خلال اختيار المعلمات المثلى.
أول مُثبت بدرجة إنتاجية: تقدم الورقة أول تنفيذ عامل لمُثبت FlyClient لـ Zcash (مدمج في Zebrad). وتظهر أن إضافة وظائف FlyClient لها تأثير ضئيل على وقت المزامنة (عملية ترقية قاعدة بيانات العقدة تستغرق حوالي 10 ساعات لسلسلة مكونة من 3 ملايين كتلة، بينما تستغرق المزامنة الكاملة حوالي 40 ساعة).
تحسينات حجم الإثبات:
- الإثباتات التراكمية: حققت تقليلاً بنسبة 9.16% في حجم الإثبات غير التفاعلي مع عدم إجراء أي تغييرات في الإجماع.
- الإثباتات المقطرة: حققت تقليلاً هائلاً بنسبة 71.33% في حجم الإثبات غير التفاعلي، مما قلل الحجم من ~1.2 ميجابايت إلى ~320 كيلوبايت لسلسلة مكونة من 3 ملايين كتلة.

4. النتائج التجريبية

حجم الإثبات والتكلفة:
- الأساس (Baseline): يبلغ حجم إثبات FlyClient غير التفاعلي القياسي لسلسلة Zcash مكونة من 3 ملايين كتلة حوالي 1.2 ميجابايت. تمرير هذا الإثبات إلى عقد ذكي (عبر EIP-7623) يكلف حوالي 13.21 دولار أمريكي.
- تحسين التراكم (Cumulative Optimization): يقلل التكلفة إلى 12.00 دولار أمريكي (-9.16%).
- تحسين التقطير (Distilled Optimization): يقلل التكلفة إلى 3.44 دولار أمريكي (-71.33%)، مما يجعل الجسور عبر السلاسل غير الموثوقة (trustless cross-chain bridges) مجدية اقتصادياً للمعاملات الأكثر تكراراً.
العبء الإضافي للموارد:
- لا يؤدي تنفيذ مُثبت FlyClient إلى تدهور أداء العقدة بشكل كبير. الوقت اللازم لترقية قاعدة بيانات العقدة الحالية لتخزين عُقد MMR هو وقت خطي ويمكن إدارته.
- وُجد أن تمثيل "الثنائي المضغوط" (zipped binary) هو الأكثر كفاءة لنقل البيانات، مما يقلل أحجام الإثبات بشكل كبير مقارنة بتنسيقات JSON أو الثنائي الخام.
التحليل الأمني: أكد نموذج الخصم $w_a$ أن مهاجماً بميزانية تبلغ حوالي 20,000 دولار أمريكي (كافية لإنتاج حوالي 50 كتلة من العمل) لا يمكنه مهاجمة مُتحقق مهيأ بالمعلمات المثلى، حتى لو حاول المهاجم إنشاء تفرع بنسبة صلاحية أقل.

5. الأهمية

تعد هذه الورقة خطوة حاسمة نحو تصنيع (Industrialization) FlyClient.

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

في الختام، تثبت هذه الورقة أن FlyClient لم يعد مجرد مفهوم نظري، بل هو حل قابل للنشر، وآمن، ومحسن للبنية التحتية للجيل القادم من البلوكشين.