فيتاليك: دعم الحصة اللامركزية بمزيد من الحوافز المضادة للارتباط

المؤلف: فيتاليك بوتيرين، @vitalik.eth؛ تم إعداده بواسطة: Songxue، Golden Finance

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

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

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

التحقق من السلامة: هل من المرجح أن تكون الأخطاء الواردة من أدوات التحقق المختلفة في نفس "المجموعة" مرتبطة في الواقع؟

يمكننا التحقق من ذلك من خلال الجمع بين مجموعتين من البيانات: (1) بيانات المصادقة لبعض العصور الحديثة، والتي توضح أي من المدققين كان يجب أن يشهد خلال كل فترة زمنية، وأي من المدققين قاموا بالفعل بالإثبات، و (2) رسم الخرائط معرفات المدقق للبيانات المتاحة للجمهور والتي تحتوي على مجموعات من العديد من المدققين (مثل "Lido" و"Coinbase" و"Vitalik Buterin"). يمكنك التحقق هنا، هنا وهنا  تم العثور على تفريغ للملف الأول هنا تفريغ أورير.

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

نحسب أيضًا حالات الفشل الشائعة:عدد حالات الفشل الشائعة التي "يجب أن تحدث" إذا كان الفشل بالكامل نتيجة لصدفة عشوائية.

على سبيل المثال، لنفترض أن هناك 10 أدوات تحقق بحجم مجموعة 4، والمجموعات الأخرى مستقلة، وفشلت 3 أدوات تحقق: اثنان داخل المجموعة وواحد خارج المجموعة .

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

ولكن ما هو حجم الفشل الشائع "الذي يجب" أن يكون موجودًا؟ هذا سؤال فلسفي شائك. عدة طرق للإجابة:

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

احسب معدل الفشل العالمي، وقم بتربيعه، ثم اضربه في [n*(n-1)]/2 لكل مجموعة. يتم تقديم ذلك بواسطة [(3/10)^2]*6=0.54

إعادة توزيع إخفاقات كل مدقق بشكل عشوائي عبر تاريخه.

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

راجع "10216 ssfumbles" في مخرجات بايثون هذه.

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

لقد ميزت أيضًا بشكل واضح بين الأخطاء ومفقود. أحدد هذه المصطلحات على النحو التالي:

خطأ: عندما أخطأ المدقق إثبات في الفترة الحالية، ولكن أثبته بشكل صحيح في الفترة السابقة؛

غاب: عندما فاته المدقق برهانًا في العصر الحالي وفوت أيضًا برهانًا في العصر السابق.

الهدف هو التمييز بين ظاهرتين متميزتين: (1) فشل الشبكة أثناء التشغيل العادي، و(2) الفشل دون الاتصال بالإنترنت أو الفشل طويل المدى.

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

إليك نتائجي للطريقتين الأوليين لحساب حالات الفشل الشائعة المتوقعة. هنا تشير SSfumbles وSSmisses إلى الأخطاء والأخطاء باستخدام مجموعة بيانات ذات فتحة واحدة.

للنوع الأول تختلف الطرق والخطوط الفعلية بسبب استخدام مجموعة بيانات أكثر تقييدًا لتحقيق الكفاءة:

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

كيف نطبق ذلك على قواعد العقوبات؟

لقد توصلت إلى حجة بسيطة: في كل فتحة، دع p هو العدد الحالي للفتحات المفقودة مقسومًا على متوسط ​​آخر 32 فتحة.

تثبت هذه الفترة الزمنية يجب أن تكون العقوبة متناسبة مع ص.

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

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

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

الأساسية: نقطة واحدة لـ كل خطأ (أي مشابه للوضع الراهن)

basic_ss:نفسه، ولكن يحتاج إلى تضمين فتحة واحدة ليتم احتسابه على أنه خطأ.

الزائد : استخدم p المحسوبة أعلاه لمعاقبة النقطة p

extra_ss: استخدم p المحسوبة أعلاه لمعاقبة النقطة p، مما يتطلب عدم احتساب تضمينات الفتحة الفردية على أنها أخطاء

استخدم "الأساسي" "الحل، الحل الأكبر أفضل من الحل الأصغر. هناك ميزة تبلغ حوالي 1.4x (حوالي 1.2x في مجموعة البيانات ذات الفتحة الواحدة). باستخدام السيناريو "الإضافي"، تنخفض هذه القيمة إلى حوالي 1.3x (حوالي 1.1x في مجموعة البيانات ذات الفتحة الواحدة). ومن خلال العديد من التكرارات الأخرى، باستخدام مجموعات بيانات مختلفة قليلاً، أدى نظام العقوبات الزائدة بشكل موحد إلى تضييق ميزة "الرجال الكبار" على "الرجال الصغار".

ماذا يحدث؟

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

وهذا يعني: عندما يفشل مدقق كبير في إثبات التضمين، فإنه سيغير الفتحة الحالية بمفرده. معدل الفشل، والذي بدوره يزيد من العقوبات. المدققون الصغار لا يفعلون هذا.

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

مزيد من التحليل

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

• حاول العثور على مخطط المكافأة/العقوبة المثالي (ولكنه لا يزال بسيطًا حتى لا تفرط في التجهيز ولا يكون قابلاً للاستغلال) والذي يقلل من متوسط ​​ميزة المدققين الكبار على المدققين الصغار.

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

• التجميع حسب الموقع الجغرافي. وهذا يمكن أن يحدد ما إذا كانت الآلية ستحفز أيضًا اللامركزية الجغرافية.

• التجميع عبر برنامج العميل (التنفيذ والإرشاد). يمكن أن يحدد هذا ما إذا كانت الآلية تحفز أيضًا الاستخدام من قبل عدد صغير من العملاء.