من أجل إنشاء أقوى شبكة من الطبقة الثانية وأكثرها أمانًا وقابلة للتشغيل البيني، تسعى Optimism Collective إلى تحقيق اللامركزية من خلال العديد من السبل المختلفة.
سيكون نظام OP Stack الآمن من الفشل بمثابة خطوة كبيرة نحو اللامركزية التكنولوجية، حيث يخلق المصدر المفتوح والتصميم المعياري لـ OP Stack مرحلة غير مسبوقة من اللامركزية الاجتماعية للنظام البيئي L2.
في هذه المقالة، سوف نستكشف مبدأ اللامركزية الاجتماعية، وكيف تمكن بنية L2 الطبقة الثانية من توسيع هذا المبدأ ليشمل تنوع الأدلة وتنوع العملاء، ونصف كيف تستفيد Optimism Collective من هذه البنية لبناء نظامها الآمن من الفشل.
"اللامركزية الاجتماعية" مستوحاة من الإثيريوم
يستفيد بروتوكول إيثريوم من اللامركزية الاجتماعية، لا سيما من خلال توفير الاختيارية في الحلول التي تمكن مجموعة واسعة من المساهمين من المشاركة في بناء شبكة لامركزية قوية.
بالنسبة لبرامج العقد، يعني هذا تنوع العملاء: كلما زاد عدد العملاء لديك، قل تأثير نقطة فشل واحدة على شبكة المدقق.
يصف مطورو Layer1 الأساسيون نموذج المساهمة هذا بأنه "بازار"، وهو صاخب وفوضوي على ما يبدو، ولكنه فعال وديناميكي للغاية. ومن خلال اعتماد نهج مفتوح جذريًا لتطوير البروتوكول، يمكن لأكبر مجموعة من المساهمين المشاركة وتحسين البروتوكول.
تتمتع Optimism Collective بموقع فريد لتنفيذ وتكرار نهج Ethereum في اللامركزية الاجتماعية: يحقق OP Stack اللامركزية الاجتماعية من خلال توفير مواصفات مفتوحة وبرامج مفتوحة المصدر بموجب ترخيص MIT، ويمكن لـ Optimism Collective تحقيق اللامركزية الاجتماعية من خلال إنشاء تكرارات فائقة السلسلة فوقها.
فهم أكثر تفصيلاً لبنية اللغة الثانية
لدى Ethereum مواصفات مفتوحة في L1، وبنية عميل معيارية تفصل بين طبقة الإجماع وطبقة التنفيذ.
يطبق OP-Stack نفس البنية على L2:
يتم تشغيل طبقة الإجماع بواسطة op-node وMagi، وهما عميلان يتبعان L1 ويصدران مدخلات التنفيذ؛
طبقة التنفيذ مدعومة بـ op-geth وop-erigon وop-reth؛
ومع ذلك، تضيف بنية L2 طبقة جديدة إلى هذه المكدس: طبقة الاختبار.
هذه هي الطبقة التي تربط بشكل آمن مخرجات L2 إلى L1. تمامًا كما يعد وجود عملاء متعددين من أفضل الممارسات لضمان الإجماع والتنفيذ على كل من L1 وL2، بالنسبة لطبقة التحقق في L2، فإن وجود طرق تصديق متعددة يمكن أن يضمن الأمان الأمثل.
على غرار الطريقة التي يتوصل بها المدققون مع عملاء مختلفين إلى توافق في الآراء، يمكن أن يُظهر نصاب الشهادات على السلسلة أنه تم التحقق من مطالبات حالة L2 بطرق مختلفة، مما يقلل بشكل كبير من احتمال حدوث أخطاء تؤدي إلى الفشل الكامل.
يوجد حاليًا ثلاثة أنواع شائعة من الأدلة: الشهادات، وإثباتات الخطأ (المعروفة أيضًا باسم أدلة الاحتيال)، وإثباتات صحة المعرفة الصفرية. يشترك الأخيران في نمط مشترك حيث يعبران عن انتقالات حالة L2 في شكل متزامن ويثبتان تنفيذها بالنظر إلى بيانات L1 وحالة L2 السابقة كمدخلات.
عزل مكونات نظام الإثبات لتحقيق تنوع الإثبات
أظهر أنه يمكن تقسيم النظام إلى مكونات مستقلة:
"برنامج" يحدد التحولات المتزامنة لحالة L2؛
"جهاز افتراضي" (VM) لتشغيل البرنامج والتحقق منه؛
"Oracle ما قبل الصورة" الذي يأخذ بيانات L1 وحالة L2 المسبقة كمدخلات؛
لا تزال العديد من براهين المعرفة الصفرية اليوم تربط هذه المكونات بإحكام، مما يؤدي إلى إنشاء ZK-EVM الذي يعمل على بيانات معاملة L1 واحدة. ومع ذلك، فإن مكدس OP يفصل بينهما لعزل التعقيد وتمكين تنوع العملاء، مما يجعل الكل أكثر قوة.
تضيف براهين الأخطاء التفاعلية ألعاب تشريح إلى آثار الآلة الافتراضية للتحقق من البراهين الموجودة على السلسلة، بينما تقوم براهين المعرفة الصفرية القائمة على الآلة الافتراضية بإثبات الحساب وطي التنفيذ وتوفير براهين الصلاحية. (راجع إثباتات المعرفة الصفرية القائمة على الآلة الافتراضية Risc0 وO(1)-Labs التي تصممها المختبرات استجابةً لطلبات Optimism ZK RFPs).
يحدد البرنامج انتقال الحالة الفعلي على أنه "العميل" والحصول على المدخلات (بيانات L1 والحالة المسبقة للمستوى الثاني) على أنه "الخادم". يعمل البرنامج بشكل مستقل عن الخادم/العميل بدون جهاز افتراضي، يشبه إلى حد كبير عقدة blockchain العادية، ويشارك في الكثير من التعليمات البرمجية.
على سبيل المثال، تم إنشاء عميل برنامج Go op عن طريق استيراد شوكة العقدة التشغيلية وEVM من op-geth، بينما يحصل الخادم على بياناته من L1 وL2 Ethereum RPCs.
نظرة عامة وظيفية على FPVM
تعد الآلة الافتراضية المقاومة للخطأ (FPVM) إحدى وحدات المكدس المقاوم للخطأ في OP Stack.
لا ينفذ هذا الجهاز الافتراضي أي شيء خاص بـ Ethereum أو L2 بخلاف توفير الواجهات الصحيحة (خاصة تلك المتعلقة بـ oracles قبل الصورة)، وعميل برنامج تدقيق الأخطاء (FPP) الذي يعمل داخل FPVM هو التعبير عن جزء تحويل حالة L2.
مع هذا الفصل، يتم الاحتفاظ بالجهاز الظاهري في الحد الأدنى: لا تؤثر التغييرات التي يتم إجراؤها على بروتوكول Ethereum (مثل إضافة أكواد تشغيل EVM) على الجهاز الظاهري.
بدلاً من ذلك، عندما يتغير البروتوكول، يمكن ببساطة تحديث FPP لاستيراد مكونات انتقال الحالة الجديدة في برنامج العقدة. وعلى غرار لعب إصدار جديد من اللعبة على نفس وحدة التحكم في اللعبة، يمكن تحديث نظام التصديق L1 للتأكيد على برامج مختلفة.
الجهاز الظاهري مسؤول عن تنفيذ التعليمات ذات المستوى المنخفض ويحتاج إلى محاكاة FPP. متطلبات الجهاز الظاهري أقل: يتم تنفيذ البرامج بشكل متزامن ويتم تحميل جميع المدخلات من خلال نفس أوراكل ما قبل الصورة، ولكن لا يزال يتعين إثبات كل هذا على سلسلة L1 EVM.
ومن أجل القيام بذلك، يمكن إثبات تعليمة واحدة فقط في كل مرة. ستعمل لعبة التنصيف على تقليل مهمة إثبات آثار التنفيذ الكاملة إلى تعليمة واحدة فقط.
قد يبدو دليل التعليمات مختلفًا لكل FPVM، ولكنه عادةً ما يبدو مشابهًا لـ Cannon، مما يثبت التعليمات على النحو التالي:
لتنفيذ هذه التعليمات، يحاكي الجهاز الظاهري شيئًا مشابهًا لدورة التعليمات لسياق الخيط: تتم قراءة التعليمات من الذاكرة، وتفسيرها، وقد تحدث بعض التغييرات في ملف التسجيل والذاكرة؛
لدعم احتياجات وقت تشغيل البرنامج الأساسية مثل أوراكل ما قبل الصورة وتخصيص الذاكرة، يدعم التنفيذ أيضًا مجموعة فرعية من استدعاءات نظام Linux. تسمح مكالمات نظام القراءة/الكتابة بالتفاعل مع أوراكل الصورة المسبقة: يكتب البرنامج التجزئة كطلب للحصول على الصورة المسبقة، ثم يقرأها في أجزاء في كل مرة؛
قام Cannon، وهو أول FPVM، بتنفيذ الجهاز الظاهري MIPS بهذه الطريقة. لمزيد من المعلومات حول الأجهزة الافتراضية، راجع الوثائق ذات الصلة ومواصفات المدفع. الواجهة بين برامج FPVM وFP موحدة وموثقة في المواصفات.
من FPVM إلى ZKVM
لا تعد إثباتات الفشل هي النوع الوحيد من إثبات انتقال الحالة، حيث تعد إثباتات صلاحية ZK خيارًا جذابًا نظرًا لقدرتها على التوصيل السريع عبر السلسلة (نظرًا لأن إثباتات صلاحية ZK لا تحتوي على ألعاب تحدي على السلسلة، فلا توجد نافذة للنزاع). من أجل دعم مكدس Ethereum المتقدم واستضافة تطبيقات العملاء المختلفة، ما زلنا بحاجة إلى فصل الجهاز الظاهري والبرنامج.
هذا هو النهج الذي اتبعه مشروع ZK RFP لإثبات أن الحد الأدنى من الجهاز الظاهري RISC-V (بواسطة Risc0) أو MIPS (بواسطة O(1) Labs) يمكنه استضافة نفس البرنامج المستخدم في دليل الفشل.
يتطلب دعم ZK-VM بعض التعديلات الطفيفة لتمكين أوراكل الصورة المسبقة من تحميل البيانات بشكل غير تفاعلي، ولكن من خلال تعميم الجهاز الظاهري، يثبت ZK أنه أكثر مقاومة للمستقبل في مواجهة تغييرات OP Stack.
فرص للمساهمين الخارجيين
يرحب OP Stack بخيارات البرامج والآلات الافتراضية الإضافية، بالإضافة إلى أنظمة إثبات مستقلة إضافية، بدءًا من البراهين وحتى براهين المعرفة الصفرية. تمامًا مثل تنوع العملاء، يعد تنوع الأدلة جهدًا جماعيًا.
تتضمن الإضافات إلى طبقة إثبات OP Stack الجارية حاليًا ما يلي:
RISC-V FPVM "Asterisc" تم تطويره بواسطة protolambda ومكتوب بلغة Go؛
برنامج Rust FP يعتمد على Magi وop-reth الذي تم إنشاؤه بواسطة المساهمين في Base وOP Labs؛
برنامج Rust ZK المبني على zeth (فرع ZK-reth) الذي صممه Risc0؛
مع تطور المدفع والبرنامج التشغيلي واللعبة المقسمة والإبداع اللامحدود لمجتمع المصادر المفتوحة، سيكون هناك العديد من الفرص الإضافية للمساهمة في المكدس من خلال عمليات تنفيذ الاختبار والمشاركة في برامج مكافآت الأخطاء.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تفسير النظام الآمن من الفشل الذي سيتم إطلاقه بواسطة OP Stack: مستوحى من Ethereum، خطوة كبيرة نحو اللامركزية التكنولوجية
المؤلف: بروتولامبادا، باحث في OP Labs
تم إعداده بواسطة: فرانك، فورسايت نيوز
من أجل إنشاء أقوى شبكة من الطبقة الثانية وأكثرها أمانًا وقابلة للتشغيل البيني، تسعى Optimism Collective إلى تحقيق اللامركزية من خلال العديد من السبل المختلفة.
سيكون نظام OP Stack الآمن من الفشل بمثابة خطوة كبيرة نحو اللامركزية التكنولوجية، حيث يخلق المصدر المفتوح والتصميم المعياري لـ OP Stack مرحلة غير مسبوقة من اللامركزية الاجتماعية للنظام البيئي L2.
في هذه المقالة، سوف نستكشف مبدأ اللامركزية الاجتماعية، وكيف تمكن بنية L2 الطبقة الثانية من توسيع هذا المبدأ ليشمل تنوع الأدلة وتنوع العملاء، ونصف كيف تستفيد Optimism Collective من هذه البنية لبناء نظامها الآمن من الفشل.
"اللامركزية الاجتماعية" مستوحاة من الإثيريوم
يستفيد بروتوكول إيثريوم من اللامركزية الاجتماعية، لا سيما من خلال توفير الاختيارية في الحلول التي تمكن مجموعة واسعة من المساهمين من المشاركة في بناء شبكة لامركزية قوية.
بالنسبة لبرامج العقد، يعني هذا تنوع العملاء: كلما زاد عدد العملاء لديك، قل تأثير نقطة فشل واحدة على شبكة المدقق.
يصف مطورو Layer1 الأساسيون نموذج المساهمة هذا بأنه "بازار"، وهو صاخب وفوضوي على ما يبدو، ولكنه فعال وديناميكي للغاية. ومن خلال اعتماد نهج مفتوح جذريًا لتطوير البروتوكول، يمكن لأكبر مجموعة من المساهمين المشاركة وتحسين البروتوكول.
تتمتع Optimism Collective بموقع فريد لتنفيذ وتكرار نهج Ethereum في اللامركزية الاجتماعية: يحقق OP Stack اللامركزية الاجتماعية من خلال توفير مواصفات مفتوحة وبرامج مفتوحة المصدر بموجب ترخيص MIT، ويمكن لـ Optimism Collective تحقيق اللامركزية الاجتماعية من خلال إنشاء تكرارات فائقة السلسلة فوقها.
فهم أكثر تفصيلاً لبنية اللغة الثانية
لدى Ethereum مواصفات مفتوحة في L1، وبنية عميل معيارية تفصل بين طبقة الإجماع وطبقة التنفيذ.
يطبق OP-Stack نفس البنية على L2:
يتم تشغيل طبقة الإجماع بواسطة op-node وMagi، وهما عميلان يتبعان L1 ويصدران مدخلات التنفيذ؛
طبقة التنفيذ مدعومة بـ op-geth وop-erigon وop-reth؛
ومع ذلك، تضيف بنية L2 طبقة جديدة إلى هذه المكدس: طبقة الاختبار.
هذه هي الطبقة التي تربط بشكل آمن مخرجات L2 إلى L1. تمامًا كما يعد وجود عملاء متعددين من أفضل الممارسات لضمان الإجماع والتنفيذ على كل من L1 وL2، بالنسبة لطبقة التحقق في L2، فإن وجود طرق تصديق متعددة يمكن أن يضمن الأمان الأمثل.
على غرار الطريقة التي يتوصل بها المدققون مع عملاء مختلفين إلى توافق في الآراء، يمكن أن يُظهر نصاب الشهادات على السلسلة أنه تم التحقق من مطالبات حالة L2 بطرق مختلفة، مما يقلل بشكل كبير من احتمال حدوث أخطاء تؤدي إلى الفشل الكامل.
يوجد حاليًا ثلاثة أنواع شائعة من الأدلة: الشهادات، وإثباتات الخطأ (المعروفة أيضًا باسم أدلة الاحتيال)، وإثباتات صحة المعرفة الصفرية. يشترك الأخيران في نمط مشترك حيث يعبران عن انتقالات حالة L2 في شكل متزامن ويثبتان تنفيذها بالنظر إلى بيانات L1 وحالة L2 السابقة كمدخلات.
عزل مكونات نظام الإثبات لتحقيق تنوع الإثبات
أظهر أنه يمكن تقسيم النظام إلى مكونات مستقلة:
لا تزال العديد من براهين المعرفة الصفرية اليوم تربط هذه المكونات بإحكام، مما يؤدي إلى إنشاء ZK-EVM الذي يعمل على بيانات معاملة L1 واحدة. ومع ذلك، فإن مكدس OP يفصل بينهما لعزل التعقيد وتمكين تنوع العملاء، مما يجعل الكل أكثر قوة.
تضيف براهين الأخطاء التفاعلية ألعاب تشريح إلى آثار الآلة الافتراضية للتحقق من البراهين الموجودة على السلسلة، بينما تقوم براهين المعرفة الصفرية القائمة على الآلة الافتراضية بإثبات الحساب وطي التنفيذ وتوفير براهين الصلاحية. (راجع إثباتات المعرفة الصفرية القائمة على الآلة الافتراضية Risc0 وO(1)-Labs التي تصممها المختبرات استجابةً لطلبات Optimism ZK RFPs).
يحدد البرنامج انتقال الحالة الفعلي على أنه "العميل" والحصول على المدخلات (بيانات L1 والحالة المسبقة للمستوى الثاني) على أنه "الخادم". يعمل البرنامج بشكل مستقل عن الخادم/العميل بدون جهاز افتراضي، يشبه إلى حد كبير عقدة blockchain العادية، ويشارك في الكثير من التعليمات البرمجية.
على سبيل المثال، تم إنشاء عميل برنامج Go op عن طريق استيراد شوكة العقدة التشغيلية وEVM من op-geth، بينما يحصل الخادم على بياناته من L1 وL2 Ethereum RPCs.
نظرة عامة وظيفية على FPVM
تعد الآلة الافتراضية المقاومة للخطأ (FPVM) إحدى وحدات المكدس المقاوم للخطأ في OP Stack.
لا ينفذ هذا الجهاز الافتراضي أي شيء خاص بـ Ethereum أو L2 بخلاف توفير الواجهات الصحيحة (خاصة تلك المتعلقة بـ oracles قبل الصورة)، وعميل برنامج تدقيق الأخطاء (FPP) الذي يعمل داخل FPVM هو التعبير عن جزء تحويل حالة L2.
مع هذا الفصل، يتم الاحتفاظ بالجهاز الظاهري في الحد الأدنى: لا تؤثر التغييرات التي يتم إجراؤها على بروتوكول Ethereum (مثل إضافة أكواد تشغيل EVM) على الجهاز الظاهري.
بدلاً من ذلك، عندما يتغير البروتوكول، يمكن ببساطة تحديث FPP لاستيراد مكونات انتقال الحالة الجديدة في برنامج العقدة. وعلى غرار لعب إصدار جديد من اللعبة على نفس وحدة التحكم في اللعبة، يمكن تحديث نظام التصديق L1 للتأكيد على برامج مختلفة.
الجهاز الظاهري مسؤول عن تنفيذ التعليمات ذات المستوى المنخفض ويحتاج إلى محاكاة FPP. متطلبات الجهاز الظاهري أقل: يتم تنفيذ البرامج بشكل متزامن ويتم تحميل جميع المدخلات من خلال نفس أوراكل ما قبل الصورة، ولكن لا يزال يتعين إثبات كل هذا على سلسلة L1 EVM.
ومن أجل القيام بذلك، يمكن إثبات تعليمة واحدة فقط في كل مرة. ستعمل لعبة التنصيف على تقليل مهمة إثبات آثار التنفيذ الكاملة إلى تعليمة واحدة فقط.
قد يبدو دليل التعليمات مختلفًا لكل FPVM، ولكنه عادةً ما يبدو مشابهًا لـ Cannon، مما يثبت التعليمات على النحو التالي:
قام Cannon، وهو أول FPVM، بتنفيذ الجهاز الظاهري MIPS بهذه الطريقة. لمزيد من المعلومات حول الأجهزة الافتراضية، راجع الوثائق ذات الصلة ومواصفات المدفع. الواجهة بين برامج FPVM وFP موحدة وموثقة في المواصفات.
من FPVM إلى ZKVM
لا تعد إثباتات الفشل هي النوع الوحيد من إثبات انتقال الحالة، حيث تعد إثباتات صلاحية ZK خيارًا جذابًا نظرًا لقدرتها على التوصيل السريع عبر السلسلة (نظرًا لأن إثباتات صلاحية ZK لا تحتوي على ألعاب تحدي على السلسلة، فلا توجد نافذة للنزاع). من أجل دعم مكدس Ethereum المتقدم واستضافة تطبيقات العملاء المختلفة، ما زلنا بحاجة إلى فصل الجهاز الظاهري والبرنامج.
هذا هو النهج الذي اتبعه مشروع ZK RFP لإثبات أن الحد الأدنى من الجهاز الظاهري RISC-V (بواسطة Risc0) أو MIPS (بواسطة O(1) Labs) يمكنه استضافة نفس البرنامج المستخدم في دليل الفشل.
يتطلب دعم ZK-VM بعض التعديلات الطفيفة لتمكين أوراكل الصورة المسبقة من تحميل البيانات بشكل غير تفاعلي، ولكن من خلال تعميم الجهاز الظاهري، يثبت ZK أنه أكثر مقاومة للمستقبل في مواجهة تغييرات OP Stack.
فرص للمساهمين الخارجيين
يرحب OP Stack بخيارات البرامج والآلات الافتراضية الإضافية، بالإضافة إلى أنظمة إثبات مستقلة إضافية، بدءًا من البراهين وحتى براهين المعرفة الصفرية. تمامًا مثل تنوع العملاء، يعد تنوع الأدلة جهدًا جماعيًا.
تتضمن الإضافات إلى طبقة إثبات OP Stack الجارية حاليًا ما يلي:
مع تطور المدفع والبرنامج التشغيلي واللعبة المقسمة والإبداع اللامحدود لمجتمع المصادر المفتوحة، سيكون هناك العديد من الفرص الإضافية للمساهمة في المكدس من خلال عمليات تنفيذ الاختبار والمشاركة في برامج مكافآت الأخطاء.