العنوان الأصلي: “التمسك ب 8192 توقيعا لكل فتحة بعد SSF: كيف ولماذا”
المقال الأصلي بقلم فيتاليك بوتيرين ، بحث ETH
التجميع الأصلي: Luccy ، BlockBeats
ملاحظة المحرر: SSF (نهائية الفتحة الواحدة) تعني نهائية الفتحة الفردية ، والتي توفر طريقة لتقليل زمن انتقال Ethereum بشكل كبير. في آلية BlockchainConsensus ، تعني النهائية أن المعاملة أو الكتلة تصبح غير قابلة للإلغاء ، مما يضمن عدم إمكانية العبث بها أو عكسها. إن تحقيق النهاية أمر ضروري لثقة وأمن أنظمة اللامركزية ، لأنه يزيل مخاطر الإنفاق المزدوج والأنشطة الخبيثة الأخرى. *
يقترح SSF أنه في آلية BlockchainConsensus ، يمكن اعتبار فترة زمنية واحدة أو وحدة زمنية واحدة “نهائية”. على عكس EthereumConsensus الأصلي ، فإنه يسمح لجميع المدققين بالمشاركة في الإقرار أو التوقيع على الفتحات ، مما يقلل من وقت تأكيد المعاملة ويحسن تجربة المستخدم الإجمالية. *
فيتاليك “يعود” يستكشف ETH البحث سبب ضرورة أن يكون لدى المدققين المشاركين توقيعان لكل فتحة بعد SSF ، أي للوصول إلى 8192 توقيعا ، ويطرح 3 فرضيات حول كيفية تحقيق هذا الهدف ، وهي التخزين الكامل ، والتخزين من مستويين ، والمشاركة التناوبية ، ويحلل كيفية التعامل مع عدد التوقيعات لكل فتحة بشكل أكثر كفاءة مع الحفاظ على أمان البروتوكول ، ويناقش مزاياها وعيوبها وتأثيرها على البروتوكول والمستخدمين. قام BlockBeats بتجميع النص الأصلي على النحو التالي:*
أحد الاختلافات الرئيسية بين Ethereum ومعظم أنظمة PoS الأخرى (مع النهاية) هو أن Ethereum تسعى جاهدة لدعم عدد كبير جدا من المدققين: لدينا حاليا 895،000 مدقق ، وهو ما يظهر تحليل قانون Zipf أنه يعادل عشرات الآلاف من الأفراد أو الكيانات المستقلة. والغرض من ذلك هو دعم اللامركزية ، وتمكين الناس العاديين من المشاركة في الرهان دون مطالبة الجميع بالتخلي عن قدرتهم على التصرف وتسليم السيطرة إلى أحد مجمعات الرهان القليلة.
ومع ذلك ، يتطلب هذا النهج من سلسلة Ethereum معالجة عدد كبير من التوقيعات لكل فتحة (حوالي 28،000 اليوم ؛ 1،790،000 بعد SSF) ، وهو حمل مرتفع للغاية. من أجل دعم هذا الحمل ، يجب تقديم عدد من التضحيات الفنية:
قد يبدو نظام تجميع التوقيع معقولا للوهلة الأولى ، لكنه في الواقع يخلق تعقيدا نظاميا يسود النظام بأكمله.
علاوة على ذلك ، لم تحقق حتى أهدافها. لا يزال الحد الأدنى لمتطلبات التخزين هو 32 ETH ، وهو بعيد المنال بالنسبة لكثير من الناس. من وجهة نظر التحليل المنطقي وحدها، لا يبدو أن الهدف من نظام يسمح للجميع بالتوقيع على كل فتحة على المدى الطويل ممكن لتوفير رهان حقيقي للأشخاص العاديين: إذا كان لدى Ethereum 500 مليون مستخدم، 10٪ منهم يشاركون في التراص، فهذا يعني 100 مليون توقيع لكل فتحة. من منظور نظرية المعلومات ، تتطلب عقوبات المعالجة في هذا التصميم ما لا يقل عن 12.5 ميغابايت من المساحة الخالية من البيانات لكل فتحة ، أي ما يعادل تقريبا هدف التجزئة الكاملة. قد يكون ذلك ممكنا ، لكن مطالبة الرهان نفسه بالاعتماد على أخذ عينات توافر البيانات يعد مكسبا كبيرا للتعقيد. وحتى ذلك الحين ، يشارك حوالي 0.6٪ فقط من سكان العالم في التخزين ، ولم يبدأ بعد في إشراك المشكلة الحسابية المتمثلة في التحقق من العديد من التوقيعات.
لذا بدلا من الاعتماد على التشفير لإنشاء رصاصات سحرية (أو رصاصات سحرية مضادة) لتحقيق عدد متزايد باستمرار من التوقيعات لكل فتحة ، أقترح تحولا فلسفيا: أولا التخلي عن هذه التوقعات. سيؤدي ذلك إلى توسيع مساحة تصميم PoS بشكل كبير والسماح بقدر كبير من التبسيط التقني ، وجعلها أكثر أمانا من خلال السماح ل Helios ب SNARKs مباشرة على EthereumConsensus ، وحل مشكلة المقاومة الكمومية من خلال جعل مخطط توقيع غير مثير للاهتمام ولكنه طويل الأمد مثل Winternitz ممكنا.
يتبنى العديد من غير EthereumBlockchain الذين يواجهون هذه المشكلة بالضبط نهجا قائما على اللجنة للأمن. خلال كل فتحة ، يختارون بشكل عشوائي مدققي N (على سبيل المثال ، N ≈ 1000) المسؤولين عن تأكيد الفتحة في النهاية. ويجدر التذكير بالسبب في أن هذا النهج غير كاف، لأنه لا يوفر المساءلة.
لفهم السبب ، دعنا نقول أن 51٪ من الهجمات وقعت. قد يكون هذا هجوما عكسيا نهائيا أو هجوما رقابيا. من أجل تنفيذ الهجوم ، لا تزال بحاجة إلى الفاعل الاقتصادي للسيطرة على غالبية الحصة للموافقة على الهجوم ، أي تشغيل البرنامج المتورط في الهجوم والمشاركة في الهجوم مع جميع المدققين الذين يتم انتخابهم في النهاية للجنة. أخذ العينات العشوائية رياضيا يضمن ذلك. ومع ذلك ، كانت العقوبات التي تلقوها بسبب ذلك ضئيلة ، حيث أن معظم المدققين الذين وافقوا على الهجوم لم يتم انتخابهم في النهاية للجنة وبالتالي لم يتم رؤيتهم.
حاليا ، تقوم Ethereum بالعكس تماما. في حالة حدوث هجوم بنسبة 51٪ ، سيتم قطع إيداع غالبية مجموعة مدقق الهجوم بالكامل. تبلغ التكلفة الحالية للهجوم حوالي 9 ملايين ETH (حوالي 20 مليار دولار) ، ويفترض أن يتم قطع مزامنة الشبكة بالطريقة الأكثر ملاءمة للمهاجم.
أعتقد أنها تكلفة عالية ، لكنها ثمن باهظ للغاية ، ويمكننا تقديم بعض التضحيات بشأن هذه القضية. حتى تكلفة الهجوم من 1-2 مليون ETH كافية تماما. بالإضافة إلى ذلك ، تنعكس مخاطر المركزية الرئيسية الموجودة حاليا في Ethereum في مكان مختلف تماما: إذا تم تخفيض الحد الأدنى لمبلغ الإيداع إلى ما يقرب من الصفر ، فلن تتضاءل قوة مجمعات التخزين واسعة النطاق.
لهذا السبب أدعو إلى حل وسط: تقديم بعض التضحيات على مسؤوليات المدقق مع الحفاظ على مبلغ إجمالي ETH قابل للقطع ، وفي المقابل يمكننا الاستمتاع بمعظم مزايا مجموعة أصغر من المدققين.
بافتراض بروتوكول إجماع تقليدي من جولتين (مثل البروتوكول المستخدم من قبل Tendermint ، والبروتوكول الذي يستخدمه SSF حتما) ، يحتاج كل مدقق مشارك إلى توقيعين لكل فتحة. نحن بحاجة إلى معالجة هذا الواقع ، وأرى أن هناك ثلاث طرق رئيسية لحل هذه المشكلة.
يحتوي Python Zen على عبارة مهمة للغاية:
يجب أن تكون هناك طريقة واحدة - ويفضل أن تكون واحدة فقط - طريقة واضحة للقيام بذلك. )
تنتهك Ethereum حاليا هذه القاعدة عندما يتعلق الأمر بجعل الرهان متساويا ، حيث نقوم في نفس الوقت بتنفيذ استراتيجيتين مختلفتين لتحقيق هذا الهدف: (i) التخزين المستقل على نطاق صغير ، و (ii) مجمعات تخزين اللامركزية باستخدام تقنية المدقق الموزع (DVT). للأسباب المذكورة أعلاه ، (i) لا يمكن دعم سوى عدد قليل من المخزنين الفرديين ، وسيكون هناك دائما العديد من الأشخاص الذين يكون الحد الأدنى لمبلغ الإيداع لديهم كبيرا جدا. ومع ذلك ، فإن Ethereum تدفع تكلفة عبء فني عالية جدا لدعم (i).
أحد الحلول الممكنة هو الاستسلام (i) وبذل قصارى جهده (ii). يمكننا زيادة الحد الأدنى لمبلغ الإيداع إلى 4096 ETH وتعيين الحد الأقصى الإجمالي للمدقق إلى 4096 (حوالي 16.7 مليون ETH). من المتوقع أن ينضم صغار المخزنين إلى مجمع DVT: من خلال توفير رأس المال أو من خلال أن يصبحوا مشغلي العقد. لمنع إساءة الاستخدام من قبل المهاجمين ، يجب أن يكون دور مشغل العقدة محدودا بعتبة الهيبة بطريقة ما ، وستتنافس المجمعات من خلال تقديم خيارات مختلفة في هذا الصدد. توفير رأس المال سيكون بدون إذن.
يمكننا أن نجعل الرهان في هذا النموذج أكثر “تسامحا” من خلال تحديد حد أقصى للعقوبة (على سبيل المثال ، 1/8 من إجمالي الإيداع المقدم). سيسمح ذلك بثقة أقل في مشغلي Node ، على الرغم من أنه يستحق التعامل بحذر بسبب المشكلات الموضحة.
لقد أنشأنا طبقتين من المخزنات: طبقة “ثقيلة” تتطلب 4096 ETH للمشاركة في تأكيد الحالة النهائي ، وطبقة “خفيفة” بدون حد أدنى من المتطلبات (لا تأخير في الإيداع والسحب ، ولا توجد نقاط ضعف في القطع) ، مضيفا طبقة ثانية من الأمان. من أجل تأكيد الحالة النهائية للكتلة ، يلزم تأكيد الحالة النهائية للطبقة الثقيلة و 50٪ على الأقل من الطبقة الخفيفة لبراهين مدقق الضوء عبر الإنترنت.
هذا التباين مفيد للرقابة ومقاومة الهجوم ، حيث يجب إتلاف كل من الطبقات الثقيلة والخفيفة حتى ينجح الهجوم. إذا كانت إحدى الطبقات تالفة والأخرى غير تالفة ، فستتوقف السلسلة ، وإذا كانت الطبقة الثقيلة تالفة ، فيمكن معاقبتها.
فائدة أخرى لهذا هو أن الطبقة الخفيفة يمكن أن تحتوي على ETH تستخدم أيضا كضمان داخل التطبيق. العيب الرئيسي هو أن الرهان يصبح أقل مساواة من خلال إنشاء فجوة بين المخزنين على نطاق صغير وكبير الحجم.
نحن نتبع نهجا مشابها لتصميم اللجنة العليا المقترح هنا: لكل فتحة ، نختار 4096 مدققا نشطا حاليا ونضبط المجموعة بعناية في كل فتحة حتى لا يزال لدينا أمان.
ومع ذلك ، فقد اتخذنا بعض خيارات المعلمات المختلفة في هذا الإطار من أجل الحصول على “قيمة مقابل المال” فيه. على وجه الخصوص ، نسمح للمدققين بالمشاركة بأرصدة عالية بشكل تعسفي ، وإذا كان لدى المدققين أكثر من قدر معين من ETH (والتي يجب أن تكون عائمة) ، فإنهم يشاركون في اللجان في كل فتحة. إذا كان لدى المدقق N<M ETH ، فسيكون لديه احتمال N / M في أي فتحة معينة للمشاركة في اللجنة.
هنا لدينا رافعة مثيرة للاهتمام لفصل “الوزن” على الغرض التحفيزي عن “الوزن” على غرض الإجماع: يجب أن تكون مكافأة كل مدقق في اللجنة هي نفسها (على الأقل للمدققين الذين يستخدمون ≤M ETH) للحفاظ على متوسط المكافأة متناسبا مع الرصيد ، ولكن لا يزال بإمكاننا حساب أوزان مدقق الإجماع في اللجنة عن طريق ترجيح ETH. هذا يضمن أن مقدار ETH اللازمة لكسر النهائي يساوي أكثر من 1/3 من إجمالي ETH في اللجنة.
يحسب التحليل التقريبي لقانون زيبف هذا المقدار من ETH على النحو التالي:
ملاحظة: من أجل إظهار البيانات المحسوبة بشكل أكثر وضوحا ، ستكون الخطوات التالية هي لقطات شاشة

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