أثناء عملية إنشاء كتلة Ethereum والتحقق منها، يكون المنشئ مسؤولاً عن جمع البيانات من مجمع المعاملات يتم تحديد المعاملات وفرزها، ويتم إرسال الكتل إلى مقدمي العروض من خلال آلية المزاد. يختار مقدم العرض كتلة من هذه الكتل المقدمة للتوقيع عليها واقتراحها على blockchain. وبما أن مقدم العرض، ككيان واحد، له الكلمة الأخيرة، فإن هذا يخلق خطر التواطؤ المحتمل بين مقدم العرض والباني لمراجعة الصفقة.
إحدى القيم الأساسية لـ blockchain هي مقاومتها للرقابة، أي أنه يمكن لأي شخص إجراء المعاملات دون تدخل من سلطة مركزية. تتعرض هذه الخاصية للتهديد عندما يتمكن مقدمو العروض من التحكم في المعاملات المضمنة في الكتل. - تقويض العدالة والشفافية. ويمكن استخدام هذه القوة لمعالجة ترتيب المعاملات في الكتلة للحصول على فوائد اقتصادية إضافية والتسبب في مشكلات MEV.
الحلول الحالية لمكافحة الرقابة
لمواجهة هذا التحدي، اقترح المجتمع العديد من الحلول المناهضة للرقابة - حلول الرقابة، مثل قوائم الإدراج القسري (FOCIL). في آلية FOCIL، يتم اختيار مجموعة من المدققين بشكل عشوائي لكل فترة (فترة زمنية) لتشكيل لجنة قائمة التضمين. يقوم أعضاء اللجنة هؤلاء بإنشاء قوائم إدراج محلية بناءً على وجهات نظرهم الشخصية حول mempool وبثها. يكون مقدم الطلب مسؤولاً عن جمع وتجميع هذه القوائم المحلية لتشكيل قائمة مجمعة وإدراجها في الكتلة. تضمن هذه الآلية عدالة الكتلة، لأن المدقق سيتحقق من صحة القائمة المجمعة بناءً على القائمة المحلية التي تم بثها مسبقًا، وسيتم قبول الكتل التي تتوافق مع قواعد الإجماع فقط وإضافتها إلى blockchain.
بالإضافة إلى FOCIL، ناقش المجتمع أيضًا حل المقترحات المتزامنة المتعددة (MCP). تم اقتراح هذا المفهوم لأول مرة بواسطة Max Resnick في آلية التعددية، والتي تهدف إلىتوزيع الطاقة وتقليل قدرة عقدة واحدة على مراجعة المعاملاتمن خلال تقديم العديد من مقترحي الكتل المتوازيين. في آلية التعددية، يختار كل مدقق جزءًا من المعاملات من مجمع المعاملات الخاص به لتشكيل "حزمة معاملات خاصة". يقوم هؤلاء المدققون بتوقيع وإرسال حزم المعاملات المحددة الخاصة بهم إلى مقدمي الجولة الحالية. بعد أن يستلمها مقدم العرض، يجب عليه تضمين ما لا يقل عن 2/3 من حزم المعاملات في الكتلة المقترحة. عندها فقط سيتم اعتبار الكتلة صالحة. تضمن هذه الآلية عدم تمكن مقدمي العروض من اتخاذ قرار بشأن المحتوى المحظور بمفردهم، مما يقلل من إمكانية الرقابة. ولتحفيز مقدمي العروض بشكل أكبر على تضمين المعاملات بشكل عادل، تنفذ هذه الآلية قاعدة "الإكرامية المشروطة"، حيث يحصل فقط مقدمو العروض الذين يقومون بتضمين المعاملة على حصة من إكرامية المعاملة. لا يتم منح إكرامية المعاملة تلقائيًا للمقترح الأول الذي قام بإدراج المعاملة، ولكن يتم توزيعها على جميع المقترحين الذين قاموا بالفعل بإدراج المعاملة وفقًا لشروط معينة. وهذا يزيد من تكلفة الرقابة، الأمر الذي يتطلب رشوة جميع مقدمي المعاملات المدرجة.
BRAID: تحسين تنفيذ MCP
استنادًا إلى التعددية، يُقترح أيضًا Max Resnick BRAID، وهو تطبيق MCP أكثر تعقيدًا واكتمالًا. في ندوة عقدتها Paradigm تحت عنوان "DeFi in MEV Era"، قدم ماكس BRAID. تقوم BRAID بتنفيذ MCP من خلال السماح لمقدمي العروض المتعددين باقتراح كتل على سلاسل متوازية مختلفة والاستفادة من آلية الإجماع المتزامن للحفاظ على الاتساق بين السلاسل. كل سلسلة لديها مُقترح خاص بها، ويقوم جميع المُقترحين بنشر كتلهم في وقت واحد داخل نفس الفتحة. تجمع طبقة تنفيذ الإيثريوم معاملات الكتلة التي تولدها جميع السلاسل الفرعية داخل الفتحة لتشكيل كتلة تنفيذ، وتقوم بإلغاء تكرار هذه المعاملات وفرزها وتنفيذها وفقًا لقواعد محددة مسبقًا، وبالتالي تقليل مخاطر قيام أي كيان واحد بالتلاعب بقدرات المعاملات.
لا يقدم تصميم BRAID أدوارًا إضافية، وبالتالي يتجنب التعقيد الناجم عن آلية الحوافز/العقاب، ومع ذلك، فإن تنفيذه معقد نسبيًا ويتطلب تنسيقًا متعددًا تزامن السلسلة ومعالجة البيانات.
مشاكل في آلية BRAID h3>
أشار فريق Blockchain Capital Jonahb إلى مشكلة في آلية BRAID: نموذج "الطرف المشروط" له متطلبات للسيولة، مما يؤثر على تجربة المستخدم. . هذا النموذج عبارة عن استراتيجية تسعير ديناميكية تتطلب من المستخدمين إعداد قدر معين من السيولة لضمان مقاومة المعاملات للرقابة. يحتاج المستخدمون إلى تعيين قيمتين للإكرامية (T وt) عند إرسال المعاملة. تعتمد البقشيش الفعلي النهائي المدفوع على عدد مقدمي العروض المدرجين في المعاملة.
النصيحة العليا T: تمثل الحد الأقصى للرسوم التي يرغب المستخدم في دفعها لضمان إتمام المعاملة لن تخضع للرقابة . والغرض من ذلك هو تحفيز مقدمي العروض على إدراج معاملة عندما لا يكون هناك أي مقترح آخر على استعداد لإدراجها. في النهاية، إذا كان مقدم مقترح واحد فقط على استعداد لإدراجه، فإنه يحصل على T.
النصيحة السفلية t: هذا مبلغ أقل يحدده المستخدم، طالما أن المعاملة إذا تم تضمينها من قبل مقدمي عروض متعددين في نفس الوقت، فسيحتاج المستخدم فقط إلى الدفع. سيتم تقسيمها بين عدة مقدمين. إذا كان المستخدمون لا يهتمون بمقاومة الرقابة، فيمكنهم تعيين T=t وإرسال معاملاتهم إلى مقدم عرض واحد فقط.
ومع ذلك، فإن متطلبات السيولة الإضافية هذه تزيد من تعقيد وتكلفة المشاركة في معاملات blockchain، ويحتاج المستخدمون إلى حجز مبلغ إضافي من الأموال في لحظة المعاملة فقط للتأكد من أن المعاملة مقاومة للرقابة. ويتم تجميد هذه الأموال المحجوزة حتى يتم استخدامها فعليًا.
وفي هذا الصدد اقترح يونس حلين:
< strong>إثبات سيولة ما بعد الحالة: عند إرسال معاملة، يقدم المستخدم دليلاً على أنه سيكون هناك سيولة كافية لدفع T بعد تنفيذ المعاملة (على سبيل المثال، المعاملة اللاحقة سيكون لدى المستخدمين مليون دولار من السيولة). بهذه الطريقة، حتى لو لم يكن هناك أموال كافية لدفع T قبل المعاملة، يمكن للمستخدم إثبات أنه يستطيع الدفع بعد المعاملة. التحدي الذي يواجه هذا النهج هو أن مقدم الطلب يجب أن يعرف الوضع النهائي للمعاملة قبل تنفيذها، ولكن معظم المعاملات المالية تنطوي على حالات مشتركة (مثل المعاملات المتعددة التي تتقاسم نفس رصيد الحساب)، لذلك لا يستطيع مقدم العرض الحكم بدقة على طلب المعاملة قبل أن يتم تحديد حالة ما بعد المعاملة. ويتطلب ذلك إثباتات مخصصة لكل نوع معاملة، وهو أمر أقل عملية.
تأمين الرقابة: تقديم موفري تأمين المراجعة من طرف ثالث (موفري CI) تقديم ضمان لـ T الخاص بالمستخدم . يدفع المستخدم رسومًا إضافية مقابل ذلك، حيث يتم حساب r بناءً على احتمالية خضوع المعاملة للرقابة. لا يقلل هذا الحل فقط من حاجة المستخدمين إلى إعداد كميات كبيرة من السيولة على الفور، ولكنه ينبه المستخدمين أيضًا من خلال CI إلى أن T منخفض جدًا وأن هناك خطرًا كبيرًا للرقابة. لكن إنشاء سوق بين المستخدمين ومقدمي خدمات CI يستغرق وقتًا.
آراء المجتمع حول FOCIL وBRAID
الأثير يعتقد مطور العميل Prysmterence أن الميزة المهمة لـ BRAID هي أنها لا تتطلب مشاركين إضافيين. في معظم تصميمات قائمة التضمين (IL)، بما في ذلك FOCIL، يلزم وجود مشارك إضافي، مما يضيف قيود التوقيت في الفترات الزمنية لـ Ethereum، مثل وقت إرسال IL، وعندما يتم تحديث العطاءات، ويتحقق المدقق من وقت IL. ومع ذلك، فإن حل FOCIL أبسط وأكثر مرونة في التنفيذ من BRAID.
يقدر الباحث النموذجي دان روبنسون تصميم BRAID في تحديد أولويات المعاملات بدلاً من ترك الأمر لتقدير القائد (مقترح واحد)، مما يخفف بشكل فعال من MEV. بالإضافة إلى ذلك، فإن آلية التحول المشروط في BRAID تحفز السلوك غير الرقابي، وهو ما لا ينعكس في FOCIL.
يفضل المطور FOCIL على MCP وهو يعتقد أن FOCIL يتمتع بمزايا أكثر في توفير مقاومة قوية للمقاومة وتبسيط التنفيذ. ويقدم بعض حلول التحسين لتسهيل تنفيذ FOCIL.
يعتقد الباحث في Ethereum barnabe.eth بواسطة FOCIL في بعض الجوانب، ولكننا حذرون بشأن التخلي تمامًا عن النموذج القائم على القائد، معتقدين أن هذا لم يتم الإجماع عليه بعد وأن هناك حاجة إلى مزيد من العمل لإثبات جدواه. ص>
Preview
احصل على فهم أوسع لصناعة العملات المشفرة من خلال التقارير الإعلامية، وشارك في مناقشات متعمقة مع المؤلفين والقراء الآخرين ذوي التفكير المماثل. مرحبًا بك للانضمام إلينا في مجتمع Coinlive المتنامي:https://t.me/CoinliveSG