إيثيريوم تستكشف FOCIL و FairFIL لتعزيز آليات مكافحة الرقابة

في عالم البلوكشين، نسمع غالبًا مصطلحًا واحدًا: "مقاومة الرقابة".

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

تخيل أنك تُطلق معاملة من محفظة imToken.

التوقيع صحيح، ورصيد الحساب كافٍ، ورسوم الغاز ليست منخفضة، لكن المعاملة لم تُسجل بعد في الكتلة، ويظل الحالة في المحافظ على "قيد الانتظار"، في حين أن معاملات أخرى برسوم مماثلة أو حتى أقل تُسجل باستمرار على السلسلة.

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

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

لفهم سبب حاجة إيثريوم إلى هذه الآليات، أولاً يجب فهم ما يحدث بعد إرسال معاملة من المحافظ.

عندما يوقّع المستخدم ويُرسل معاملة من محفظته، تدخل المعاملة عادةً أولاً إلى حوض المعاملات العام لإيثريوم، المعروف باسم ميمبول (Mempool)، والذي يعمل كمنطقة انتظار تحتوي على عدد كبير من المعاملات التي لم تُسجل بعد في كتل.

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

ال问题是 في هذه المرحلة بالضبط التي تنشأ.

بعد ترقية إيثريوم إلى آلية الحصة (PoS)، تم إدخال نظام PBS (Proposer-Builder Separation، فصل المقترح عن المُنشئ) لمنع مجمعات الرهن الكبيرة من الاستفادة من MEV (أقصى قيمة قابلة للاستخراج) وتشكيل احتكار اقتصادي. في هذا الهيكل، يتم تقسيم عملية معالجة كل معاملة إيثريوم إلى دورين:

• المُنشئ (Builder): مسؤول عن جمع المعاملات، وترتيب ترتيبها، والبحث عن فرص التسويق والتصفية، وبناء كتلة تحقق أقصى قدر ممكن من العائد؛
• المُقترح (Proposer): مسؤول عن اختيار كتلة مرشحة من بين الكتل المقدمة من الـ Builder وتقديمها إلى الشبكة؛

هذا التقسيم يوفر فوائد عملية كبيرة.

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

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

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

ولهذا السبب، بمجرد أن تختار هذه المطورين الرئيسيين تصفية انتقائية لبعض العقود الحساسة (مثل Tornado Cash) أو معاملات عناوين محددة، ستُحتجز هذه المعاملات في حالة تأخير طويل في التعبئة، بل وقد تواجه خطر "الحظر الضمني".

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

لذلك، فإن "المقاومة ضد الرقابة" التي تُناقش في إيثريوم ليست مفهومًا كبيرًا يتعلق فقط بالسياسة أو التنظيم أو العقوبات، بل هي أولاً وقبل كل شيء مشكلة تقنية محددة جدًا:

عندما تلبي معاملة قواعد البروتوكول، هل يمكن للشبكة ضمان فرصة دخولها إلى كتلة ضمن وقت معقول؟

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

لذلك، اقترح باحثو إيثريوم قوائم الإدراج، المعروفة عادةً بـ "قوائم الإدراج".

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

على سبيل المثال، يمكن فهم الكتلة كرحلة حافلة ذات مقاعد محدودة.

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

لكن لا تزال هناك مشكلتان تحتاجان إلى حل: من يُعد القائمة، وماذا يحدث إذا تعمد شخص تجاهل معاملة ما.

FOCIL و FairFIL، وهما يمتدان بالضبط في هاتين الاتجاهين.

1. FOCIL: لا تدع مُقترحًا واحدًا يُنشئ قائمة احتواء منفردًا

FOCIL (Fork-Choice Enforced Inclusion Lists) تنقل سلطة تحديد ما إذا كانت المعاملات يجب تضمينها من مُقترح واحد إلى "لجنة مدققين" تتكون من أطراف متعددة.

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

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

لذلك ميّزته أنه لا يتطلب الثقة في أن كل عضو في اللجنة يحافظ على حياده.

لكن القائمة وحدها ليست كافية؛ إذا تلقى Builder القائمة لكنه ما زال يختار عدم التنفيذ، فستصبح القائمة مجرد اقتراح غير ملزم.

لذلك، أضاف FOCIL طبقة ثانية من التصميم، مُقدّمًا قاعدة اختيار الشوكة (Fork-Choice Rule) كقيد إلزامي، بحيث تقوم العقد المسؤولة عن التصويت والتحقق في الشبكة بالتحقق الصارم من الكتل المقدمة من الـ Builder، وعند اكتشاف أي مخالفة من قبل الـ Builder لقائمة الشمول المتكاملة من قبل اللجنة، سترفض الشبكة مباشرة التصويت على هذا الكتلة.

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

2. FairFIL: لا يكفي فقط سد الثغرات، بل يجب جعل ما تم تفويته قابلاً للتحقق

إذا كان FOCIL يحظر الرقابة بشكل إجباري من خلال قواعد الإجماع، فإن FairFIL (قوائم الإدراج العادل المسبق) وآليات المساءلة تجعل سلوك الرقابة شديد التكلفة وغير مستدام من منظور اقتصادي.

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

في التشغيل الفعلي للشبكة، قد يحتاج الـ Builder إلى فترة تأخير قصيرة جدًا لتحسين ترتيب المعاملات وتحقيق أرباح MEV، ويوفر FairFIL مرونة للـ Builder ضمن قيود محددة، ولكن إذا حاول الـ Builder تمديد أي سلوك رقابي إلى الكتلة التالية، فسيبدأ البروتوكول فورًا إجراءات المساءلة.

يمكن فهم منطقه العام على ثلاث خطوات.

• أولاً، سيحدد البروتوكول مجموعة من القواعد المرجعية العامة والقابلة للتحقق لتحديد أي المعاملات في حوض المعاملات العام مؤهلة، في الظروف العادية، للدخول إلى الكتلة الحالية؛ وإذا لم تُعالج بعض المعاملات التي كانت مؤهلة للدخول إلى الكتلة وفقاً للقواعد المرجعية، فعليه أن يدرجها علناً في FairFIL؛
• بعد ذلك، سيتحقق المُصادق من أن القائمة كاملة؛ وإذا تجاهل الـ Builder معاملات مؤهلة ولم يُدرجها في القائمة، فقد يُكشف هذا السلوك ويؤثر على ما إذا كان عقد التحقق سيؤيد الكتلة أم لا؛
• أخيرًا، ستُصبح المعاملات الصالحة في FairFIL مهام يجب معالجتها بأولوية في الكتل التالية، ويمكن للمُبني التالي لا يزال تحديد موقعها الدقيق في الكتلة، لكنه لا يمكنه الاستمرار في تجاهلها؛

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

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

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

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

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

ما تحسّنه حقًا هو اليقينية في عملية تضمين الصفقات.

• أولاً، لن تعتمد معاملة تتوافق مع القواعد بالكامل على اختيار مُبنى معين: حتى لو كان المُبنى الحالي غير راغب في المعالجة، يمكن للمُتحققين الآخرين فرض متطلب تضمين على مستوى البروتوكول من خلال قائمة التضمين؛
• ثانيًا، قد تفصل تدريجيًا حقوق التضمين من حقوق ترتيب المعاملات: لا يزال بإمكان الـ Builder استخدام خوارزميات متخصصة لترتيب تسلسل المعاملات وزيادة عائدات الكتلة، ولا يزال بإمكانه التنافس حول فرص التسويق والتصفية، لكنه سيواجه قيودًا على سلطته في تحديد "من يحق له الدخول إلى السوق".

بالتالي، يمكن أن يتحول مفهوم الحياد الموثوق لإيثيريوم من قيمة تعتمد على التزام المشاركين إلى قواعد بروتوكولية تُنفَّذ تلقائيًا عبر العميل.

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

في المستقبل، قد توفر المحافظ ومتصفحات الكتل حالات معاملات أكثر تفصيلاً بناءً على ذلك.

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

ومع ذلك، فإن آلية المقاومة ضد الرقابة لا تعني أن كل معاملة ستُنفَّذ فورًا.

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

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

من حيث التقدم، ما زال EIP-7805 المتعلق بـ FOCIL في حالة مسودة حتى أغسطس 2026، لكنه تم اختياره من قبل مطوري إيثيريوم الأساسيين كـ Headliner لطبقة التوافق في ترقية Hegotá، ودخل مرحلة "مخطط للإدراج"، مما يعني أن فرق العميل وافقت على المضي قدمًا في التنفيذ والتطوير واختبارات الشبكة حوله، لكن التاريخ النهائي للإطلاق على الشبكة الرئيسية لم يُحدد بعد.

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

بشكل موضوعي، لا يمكن لإيثريوم ضمان أن جميع المُنشئين والموثوقين ومشغلي البنية التحتية يظلون محايدים إلى الأبد.

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

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

من قائمة التضمين الأولية، إلى FOCIL الذي يقيد الـ Builder من قبل لجنة موزعة، إلى FairFIL الذي يتطلب أن يمكن التحقق من سلوك التغاضي بشكل علني، من السماح لأي شخص بإرسال المعاملات، إلى ضمان أن تُرى معاملات أي شخص.

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

Worth looking forward to.