المؤلف الأصلي: فيتاليك بوتيرين
كارين، أخبار التنبؤ
الشكر الخاص لجاستن دريك وفرانسيسكو وهسياو- وي وانغ و @ antonttc وجيورجيوس كونستانتوبولوس.
في البداية ، كانت هناك استراتيجيتان للتوسع في خارطة طريق ETH. إحداها (انظر ورقة سابقة من عام 2015) هي “مشاركة” (تجزئة): كل عقدة تحتاج فقط إلى التحقق من صحة وتخزين مجموعة فرعية صغيرة من المعاملات ، بدلا من جميع المعاملات في السلسلة. تعمل أي شبكة نظير إلى نظير أخرى (مثل BitTorrent) بهذه الطريقة ، لذلك يمكننا بالتأكيد جعل blockchain يعمل بنفس الطريقة. والآخر هو طبقة 2 بروتوكول: ستكون هذه الشبكات موجودة أعلى مربع ETH ، مما يسمح لها بالاستفادة الكاملة من أمنها مع الاحتفاظ بمعظم البيانات والحسابات خارج السلسلة الرئيسية. طبقة 2 بروتوكول يشير إلى قنوات الدولة في عام 2015 ، والبلازما في عام 2017 ، ثم الإظهار في عام 2019. تعد عمليات التجميع أقوى من قنوات الحالة أو البلازما ، ولكنها تتطلب قدرا كبيرا من النطاق الترددي لبيانات السلسلة الداخلية. لحسن الحظ ، بحلول عام 2019 ، حلت دراسة المشاركة مشكلة التحقق من “توافر البيانات” على نطاق واسع. نتيجة لذلك ، تم دمج المسارين ، وحصلنا على خارطة طريق تتمحور حول Rollup والتي لا تزال استراتيجية توسيع نطاق ETHFANG اليوم.
The Surge، 2023 خريطة الطريق
تقترح خارطة الطريق المرتكزة على Rollup تقسيما بسيطا للعمل: تركز ورشة عمل ETH L1 على كونها طبقة أساسية قوية واللامركزية ، بينما تتولى L2 مهمة المساعدة في توسيع نطاق النظام البيئي. هذا النموذج موجود في كل مكان في المجتمع: نظام المحاكم (L1) غير موجود في السعي وراء السرعة الفائقة والكفاءة ، ولكن لحماية العقود وحقوق الملكية ، ويبني رواد الأعمال (L2) على هذا الأساس المتين لقيادة البشرية (حرفيا أو مجازيا) إلى المريخ.
هذا العام ، أسفرت خارطة الطريق المرتكزة على Rollup عن نتائج مهمة: مع إطلاق نقاط EIP-4844 ، زاد عرض النطاق الترددي للبيانات لورشة عمل ETH L1 بشكل كبير ، ودخلت العديد من مجموعات ورشة عمل ETH الافتراضية (EVM) المرحلة 1. كل L2 موجود ك “مشاركة” لها قواعدها الداخلية ومنطقها ، وتنوع وتعددية الطرق التي يتم بها تنفيذ المشاركة أصبح الآن حقيقة واقعة. ولكن كما رأينا ، هناك بعض التحديات الفريدة لاتخاذ هذا المسار. لذلك ، فإن مهمتنا الآن هي إكمال خارطة الطريق التي تركز على Rollup ومعالجة هذه المشكلات مع الحفاظ على المتانة وخاصية اللامركزية لورشة عمل ETH L1.
2، الحفاظ على اللامركزية والمتانة لـ L1؛
على الأقل بعض المستوى الثاني يورث تمامًا السمات الأساسية لإيثريوم (عديم الثقة، مفتوح، مقاوم للرقابة)؛
يجب أن يشعر Ethereum بأنه نظام بيئي موحد بدلاً من 34 سلسلة كتل مختلفة.
مثلث الخصائص المتعارضة للبلوك تشين الموسع هو فكرة تم طرحها في عام 2017، وهي تشير إلى وجود تناقض بين الخصائص الثلاثة لبلوك تشين: اللامركزية (وبشكل أكثر تحديدًا: تكلفة تشغيل العقدة المنخفضة) والقابلية للتوسع (وهي قدرة الشبكة على معالجة عدد كبير من المعاملات) والأمان (حيث يتطلب من المهاجم تدمير جزء كبير من العقد في الشبكة لجعل عملية المعاملة الواحدة تفشل).
يجدر بالذكر أن مفارقة مثلثية ليست نظرية، ولا تحتوي المشاركة التي تقدم مثلث الخطأ على دليل رياضي. إنها في الواقع تقدم حجة رياضية للتحفيز: إذا كانت العقدة (مثل الكمبيوتر المحمول للألعاب) صديقة لعمليات اللامركزية يمكنها التحقق من N معاملة في الثانية، وكان لديك سلسلة تقوم بمعالجة k*N معاملة في الثانية، فإما (أ) يمكن لكل معاملة أن تراها فقط 1/k من العقد، مما يعني أن المهاجم يحتاج فقط إلى تعطيل عدد قليل من العقد لتمرير معاملة خبيثة، أو (ب) ستصبح عقدتك أقوى، ولن تظل سلسلتك لامركزية. الهدف من هذه المقالة ليس إثبات أن كسر مفارقة المثلث غير ممكن. بالعكس، إنها تهدف إلى إظهار أن كسر مفارقة المثلث الثلاثي صعب، ويتطلب الخروج من الإطار التفكيري الضمني لهذه الحجة بشكل ما.
على مر السنين، ادعت بعض سلاسل الكتل العالية الأداء أنها حلت معضلة التناقض الثلاثي دون تغيير جذري في البنية في العادة عن طريق تحسين العقدة باستخدام تقنيات هندسة البرمجيات. هذا دائمًا ما يكون مضللاً، حيث أن تشغيل العقدة داخل السلسلة يكون أصعب بكثير من تشغيل العقدة على إثيريوم. سيستكشف هذا المقال الأسباب وراء ذلك، ولماذا توسيع إثيريوم فقط من خلال هندسة البرمجيات العميل L1 لا يكفي؟
ومع ذلك ، فإن الجمع بين عينات توافر البيانات و SNARKs يحل حقا مفارقة الثلاثي: فهو يسمح للعميل بالتحقق من أن كمية معينة من البيانات متاحة وأن عددًا معينًا من خطوات الحساب تم تنفيذها بشكل صحيح فقط عند تنزيل كمية قليلة من البيانات وتنفيذ عدد قليل جدًا من الحسابات. SNARKs هو بدون ثقة. يحتوي عينات توافر البيانات على نموذج ثقة قليل من أن. ومع ذلك ، فإنه يحتفظ بالخصائص الأساسية للسلسلة غير القابلة للتوسعة التي يمتلكها البلوكات السيئة لا يمكن أن تُقبل من قبل الشبكة حتى في حالة الهجوم بنسبة 51٪.
طريقة أخرى لحل مأزق الصعوبات الثلاثة هي هيكل البلازما، حيث يستخدم تقنيات ماهرة لتحميل مسؤولية مراقبة توافر البيانات بطريقة متوافقة للمستخدمين. في الفترة من 2017 إلى 2019، كانت هيكل البلازما محدودة جدًا من ناحية التنفيذ الآمن عندما كان لدينا دليل على الاحتيال فقط كوسيلة لتوسيع قدرات الحساب، ولكن مع انتشار SNARKs (البراهين التفاعلية الصفرية المعرفة)، أصبح هيكل البلازما أكثر قابلية للتطبيق في سياقات الاستخدام بشكل أوسع من أي وقت مضى.
في 13 مارس 2024، عندما يتم ترقية Dencun وتشغيلها، يوجد 3 blob بحجم 125 كيلوبايت تقريبًا في كل slot لسلسلة كتل Ethereum حيث يتم إنشاء slot كل 12 ثانية، أو يكون عرض النطاق الترددي المتاح لكل slot حوالي 375 كيلوبايت. في حالة نشر بيانات المعاملات مباشرةً داخل السلسلة، فإن تحويل ERC 20 يستهلك حوالي 180 بايت، لذا أقصى عدد لمعاملات النقل لـ Rollup على سلسلة كتل Ethereum هو: 375000 / 12 / 180 = 173.6 TPS
إذا قمنا بإضافة calldata لـ ETH بلوكشين (القيمة النظرية القصوى: 30 مليون غاز لكل شق / 16 غاز لكل بايت = 1،875،000 بايت لكل شق)، فسيصبح 607 TPS. باستخدام PeerDAS، قد يزداد عدد الكتل إلى 8-16، وهذا سيوفر 463-926 TPS لـ calldata.
هذا تحسين كبير لـ ETH L1 ، لكنه ليس كافيًا. نريد المزيد من التوسعية. هدفنا في المدى الأوسط هو 16 ميجابايت لكل فتحة، وإذا تم دمج تحسين ضغط بيانات Rollup، سيؤدي ذلك إلى حوالي 58000 TPS.
PeerDAS هي تنفيذ نسبيًا بسيط لـ “1 D sampling”. في شبكة إثيريوم، يكون كل blob متعدد الحقول (polynomial) من 4096 درجة في حقل رقمي أولي من 253 بت. نبث مشاركات المتعددات، حيث يحتوي كل مشاركة على 16 قيمة تقييمية من 16 إحداثيًا مجاورين من إجمالي 8192 إحداثي. في هذه القيم التقييمية 8192، يمكن استعادة أي 4096 (من بين 64 عينة محتملة حسب المعلمات المقدمة حاليا) blob.
يعمل PeerDAS عن طريق السماح لكل عميل بالاستماع إلى كميات قليلة من الشبكة الفرعية، حيث يبث الشبكة الفرعية الأولى أي عينة من blob الأولى، ويقوم بطلب أي blob آخر يحتاجه على الشبكة الفرعية الأخرى من خلال الاستفسار من الأقران في شبكة p2p العالمية (الذين سيستمعون إلى شبكات فرعية مختلفة). الإصدار الأكثر تحفظًا SubnetDAS يستخدم آلية الشبكة الفرعية فقط دون طبقة الاستفسار الإضافية. الاقتراح الحالي هو أن يستخدم العقد المشارك في تحقيق التخزين SubnetDAS، بينما يستخدم العميل الآخر (أي العميل) PeerDAS.
من النظرية ، يمكننا توسيع حجم “عينة 1 دي” إلى حد كبير: إذا زادت أقصى عدد للتجمع إلى 256 (الهدف هو 128) ، فسنتمكن من الوصول إلى الهدف 16 ميغابايت ، بينما يمكن أن تكون البيانات متاحة عينة في كل عقدة 16 عينة * 128 تجمع * كل تجمع كل عينة 512 بايت = عرض النطاق الترددي 1 ميغابايت لكل فتحة. هذا لا يزال ضمن نطاق تحملنا: هذا ممكن ولكن هذا يعني أن العميل المقيد بعرض النطاق الترددي لا يمكنه العينة. يمكننا تحسين هذا إلى حد ما عن طريق تقليل عدد التجمعات وزيادة حجم التجمع ولكن هذا سيزيد من تكلفة إعادة الإنشاء.
لذا، نود أن نتقدم خطوة إضافية ونقوم بعمل عينات ثنائية الأبعاد (2D sampling)، حيث يتم إجراء عينات عشوائية ليس فقط داخل الكتلة، ولكن أيضًا بين الكتل. باستخدام الخاصية الخطية للتعهيد KZG، يتم توسيع مجموعة الكتل في كتلة معينة من خلال مجموعة جديدة من الكتل الافتراضية، حيث يتم ترميز هذه الكتل الافتراضية بشكل متكرر لنفس المعلومات.
لذلك، نريد في النهاية القيام بمزيد من العمل، وإجراء عينات ثنائية الأبعاد، لا فقط داخل الكتلة، ولكن أيضًا بين الكتل، ويتم ذلك بشكل عشوائي. تستخدم خاصية KZG الخطية لتوسيع مجموعة الـ blob في 01928374656574839201، والتي تحتوي على قائمة جديدة من الـ blob الافتراضية التي تُشفر بتكرار نفس المعلومات.
2D العينة. المصدر: a16z crypto
الأمر الحاسم هو أن توسيع الالتزام الحسابي لا يتطلب وجود كتلة ، لذلك فإن هذا الحل صديق لبناء الكتل الموزعة في الجوهر. يحتاج عقدة البناء الفعلية للكتل فقط إلى الالتزام KZG الخاص بالكتلة ، ويمكنها الاعتماد على عينات توافر البيانات (DAS) للتحقق من توفر بيانات الكتل. عينات توافر البيانات للبعد الواحد (1 D DAS) صديقة لبناء كتلة الموزعة بطبيعتها أيضًا.
الخطوة التالية هي إكمال تنفيذ وإطلاق PeerDAS. بعد ذلك ، سنواصل زيادة عدد الكتل على PeerDAS وفي الوقت نفسه رصد الشبكة بعناية وتحسين البرامج لضمان الأمان ، وهو عمل تدريجي. في الوقت نفسه ، نأمل في وجود المزيد من العمل الأكاديمي لتنظيم PeerDAS وإصدارات DAS الأخرى وتفاعلها مع قواعد اختيار الفروع الآمنة وغيرها من المشاكل.
علاوة على ذلك ، نحتاج إلى القيام بمزيد من العمل لتحديد الإصدار المثالي من 2D DAS وإثبات خصائص السلامة الخاصة به. نأمل أيضا أن ننتقل في النهاية من KZG إلى بديل آمن كميا لا يتطلب إعدادا موثوقا به. في الوقت الحالي ، لا نعرف المرشحين الودودين لإصدارات الكتلة الموزعة. حتى استخدام تقنيات “القوة الغاشمة” باهظة الثمن ، أي استخدام STARKs العودية لتوليد إثبات صحة لإعادة بناء الصفوف والأعمدة ، لا يكفي ، لأنه في حين أن STARK من الناحية الفنية هو حجم تجزئة O (log (n) * log (log (n)) (باستخدام STIR) ، فإن STARK هو في الواقع كبير تقريبا مثل النقطة بأكملها.
رأيت طريق الواقع الطويل المتوقع:
يرجى ملاحظة أنه حتى إذا قررنا توسيع التنفيذ مباشرة في الطبقة L1، فإن هذا الاختيار موجود أيضًا. وذلك لأنه إذا كانت طبقة L1 تحتاج إلى معالجة كمية كبيرة من TPS، فإن كتلة L1 ستصبح كبيرة للغاية، وسيتمنى العميل وجود طريقة فعالة للتحقق من صحتها، وعليه سيتعين علينا استخدام تقنيات مماثلة ل Rollup (مثل ZK-EVM و DAS) في طبقة L1.
إذا تم ضغط البيانات، فإن الطلب على DAS 2D سيقل، أو على الأقل سيكون هناك وقت إستجابة أقل، إذا استخدم Plasma على نطاق واسع، فسيكون الطلب أقل بشكل إضافي. ويشكل DAS تحديًا لبروتوكولات وآليات بناء الكتل الموزعة: على الرغم من أن DAS نظريًا صديق لإعادة البناء الموزعة، إلا أن هذا يتطلب في الواقع الجمع بين اقتراحات قائمة الإدراج وآليات اختيار الـfork المحيطة به.
كل صفقة في Rollup تستهلك مساحة كبيرة من بيانات السلسلة: نقل ERC 20 يحتاج إلى حوالي 180 بايت. حتى مع عينات البيانات المتاحة بشكل مثالي ، فإن هذا يحد من قابلية توسع بروتوكول الطبقة. لكل فتحة 16 ميجابايت ، نحصل على:
16000000 / 12/180 = 7407 TPS
إذا لم نكن قادرين على حل مشكلة الجزء الناتج فحسب، بل أيضًا مشكلة المقام، وجعل كل صفقة في Rollup تستهلك أقل بيانات في داخل السلسلة، ماذا سيحدث؟
ما هو، وكيف يعمل؟
في رأيي، أفضل تفسير هو هذه الصورة التي تم التقاطها قبل عامين:
أثناء ضغط البايت الصفري، تستخدم بدلاً من كل سلسلة بايت صفر طويلة بتسعة مستويات من البايت الثنائي، لتمثيل عدد البايتات الصفرية. وبالإضافة إلى ذلك، استفدنا من خصائص المعاملات الخاصة:
التجميع التوقيعي: قمنا بالتبديل من توقيع ECDSA إلى توقيع BLS ، حيث يمكن تجميع توقيعات متعددة في توقيع واحد يمكن أن يثبت صحة جميع التوقيعات الأصلية. في المستوى الأول (L1) ، بسبب تكلفة التحقق العالية حتى بعد التجميع ، لا يتم النظر في استخدام توقيع BLS. ومع ذلك ، في بيئة L2 مثل هذه ، التي تعاني من ندرة البيانات ، فإن استخدام توقيع BLS له معنى. يوفر ERC-4337 خيار التجميع لتحقيق هذه الوظيفة.
استبدال العنوان بالمؤشرات: إذا كنا في السابق نستخدم معين العنوان، يمكننا استبدال العنوان الذي يحتوي على 20 بايت بمؤشر من 4 بايت يشير إلى موقع معين في سجل التاريخ.
تسلسل تسلسل مخصص لقيم التداول - يكون عدد أرقام قيم التداول الأكثر قلة ، على سبيل المثال ، 0.25 ETH يتم تمثيلها على أنها 250،000،000،000،000،000 وي. الرسوم الأساسية القصوى والرسوم الأولوية مشابهة. لذلك ، يمكننا استخدام تنسيق عشري مخصص لتمثيل معظم قيم العملات.
ما يتعين عمله بشكل رئيسي في المستقبل هو تنفيذ الخطة المذكورة أعلاه. التوازن الرئيسي يشمل:
يتطلب التبديل إلى توقيع BLS بذل جهد كبير ويؤدي إلى إسقاط توافق الأجهزة الموثوقة التي يمكن أن تعزز الأمان. يمكن استخدام ZK-SNARK التعبئة التي تستخدم حزمة توقيعات أخرى بدلاً من ذلك.
ضغط ديناميكي (على سبيل المثال ، باستخدام الإشارات بدلاً من العنوان) سيجعل رمز العميل معقدًا.
3、نشر الفروقات في الحالة داخل السلسلة بدلا من المعاملات، سيؤدي إلى اسقاط قابلية التدقيق وجعل العديد من البرامج (مثل مستكشف البلوكتشين) غير قادرة على العمل.
كيف يمكن التفاعل مع أجزاء الخريطة الأخرى؟
باستخدام ERC-4337 وتضمين جزء منه في L2 EVM ، يمكن تسريع نشر تكنولوجيا التجميع بشكل كبير. وضع جزء من ERC-4337 على L1 يمكن أن يسرع نشره على L2.
حتى مع استخدام تكديس 16 ميجابايت وضغط البيانات ، قد لا تكون 58,000 TPS كافية تمامًا لتلبية احتياجات الدفع للمستهلكين أو الاجتماعية اللامركزية أو أي مجال ذو عرض نطاق عالٍ ، خاصةً عند النظر في عوامل الخصوصية ، وقد يؤدي هذا إلى خفض القابلية للتوسعة بنسبة 3-8 أضعاف. بالنسبة للحالات التطبيقية ذات القيمة المرتفعة والتكلفة المنخفضة ، يعد استخدام Validium خيارًا حاليًا ، حيث يحتفظ بالبيانات خارج السلسلة ويستخدم نموذج أمان مثير للاهتمام: لا يمكن لمشغل النظام سرقة أموال المستخدمين ، ولكنه قد يتجمد مؤقتًا أو بشكل دائم أموال جميع المستخدمين. ولكن يمكننا أن نفعل أفضل من ذلك.
Plasma هو حل التحجيم، حيث ينطوي على مشغل يقوم بنشر كتلة خارج السلسلة ووضع جذور Merkle لهذه الكتل داخل السلسلة (على عكس Rollup الذي يضع كتل كاملة داخل السلسلة). بالنسبة لكل كتلة، يقوم المشغل بإرسال فرع Merkle إلى كل مستخدم لإثبات تغييرات أصوله، أو عدم حدوث أي تغييرات. يمكن للمستخدمين سحب أصولهم عن طريق تقديم فروع Merkle. من المهم أن هذا الفرع لا يحتاج إلى أن يكون بجذر الحالة الأحدث. وبالتالي، حتى في حالة عدم توفر البيانات، يمكن للمستخدمين استعادة أصولهم من خلال سحب الحالة الأحدث المتاحة لديهم. إذا قدم المستخدم فرعًا غير صالح (على سبيل المثال، سحب الأصول التي تم إرسالها بالفعل إلى شخص آخر، أو إنشاء مشغل عملات افتراضية بشكل عشوائي)، فيمكن استخدام آلية التحدي داخل السلسلة لتحديد صلاحية الأصول.
سلسلة Plasma Cash. تم وضع صفقة إنفاق العملة i في الموقع i في الشجرة. في هذا المثال، نفترض أن جميع الشجرات السابقة صالحة، نحن نعلم أن إيف تمتلك الآن العملة 1، وديفيد يمتلك العملة 4، وجورج يمتلك العملة 6.
كانت النسخة المبكرة من بلازما قادرة فقط على معالجة حالات الدفع، ولم تتمكن بشكل فعال من التوسع بشكل أكبر. ومع ذلك، إذا طلبنا من كل جذر أن يتم التحقق منه باستخدام SNARK، فإن بلازما ستصبح أقوى بكثير. يمكن تبسيط كل لعبة تحدي بشكل كبير، لأننا نستبعد معظم المسارات المحتملة التي يمكن أن يغش فيها المشغل. في الوقت نفسه، فقد فتحنا مسارات جديدة، مما يمكن بلازما من التوسع لتشمل فئات الأصول الأوسع. وأخيرًا، في حالة عدم الغش من قبل المشغل، يمكن للمستخدم سحب الأموال على الفور دون الانتظار لمدة أسبوع من فترة التحدي.
طريقة واحدة (وليست الوحيدة) لإنشاء سلسلة EVM Plasma: استخدام ZK-SNARK لبناء شجرة UTXO متوازية تعكس التغييرات في الرصيد التي تم إجراؤها بواسطة EVM وتحدد الرسم الوحيد لـ “نفس العملة” في أوقات مختلفة في التاريخ. يمكن بناء هيكل Plasma فوق ذلك.
واحد من الأفكار الرئيسية هو أن نظام بلازما لا يحتاج إلى الكمال. حتى إذا كنت تستطيع حماية مجموعة فرعية من الأصول (على سبيل المثال، العملات التي لم تتحرك فقط خلال الأسبوع الماضي)، فقد قمت بتحسين الوضع الحالي لـ EVM فائق القابلية للتوسيع (أي Validium) بشكل كبير.
الهيكل الآخر هو هيكل Plasma / Rollup المختلط مثل Intmax. تضع هذه الهياكل كمية قليلة للغاية من بيانات كل مستخدم داخل السلسلة (مثل 5 بايتات) ، مما يتيح بعض الميزات الموجودة بين Plasma و Rollup: في حالة Intmax ، يمكنك الحصول على قابلية توسعية وخصوصية عالية جدًا ، على الرغم من أنها محدودة نظريًا إلى حوالي 266667 TPS حتى في سعة 16 ميجابايت.
المهمة الرئيسية المتبقية هي نشر نظام Plasma في التطبيقات الإنتاجية الفعلية. كما هو مذكور أعلاه، فإن Plasma ليس خيارًا إما أو Validium: يمكن لأي Validium تحسين خصائصه الأمانية على الأقل إلى حد ما عن طريق دمج ميزات Plasma في آلية خروجه. يتمحور البحث حول الحصول على أفضل الخصائص لـ EVM (من متطلبات الثقة وتكلفة الغاز L1 في أسوأ الحالات وقدرتها على مقاومة هجمات الـ DoS)، بالإضافة إلى الهيكل التطبيقي البديل. علاوة على ذلك، فإن Plasma مقارنة بـ Rollup تتمتع بمستوى أعلى من التعقيد المفاهيمي، مما يتطلب حلولًا مباشرة من خلال البحث والبناء لإنشاء إطار عام أفضل.
التوازن الرئيسي في تصميم Plasma هو أنه يعتمد بشكل أكبر على المشغلين وأكثر صعوبة في البناء ، على الرغم من أن التصميم المختلط بين Plasma/Rollup عادة ما يمكن أن يتجنب هذا الضعف.
كلما كانت حلول البلازما أكثر فعالية، زادت الضغوط على L1 التي تتمتع بقدرات أداء البيانات عالية. نقل الأنشطة إلى L2 يمكن أيضًا تقليل ضغط MEV على L1.
حالياً، معظم Rollup في الواقع ليست عديم الثقة. هناك لجنة أمان، لديها القدرة على تجاوز (التفاؤلية أو الصحة) سلوك النظام البرهاني. في بعض الحالات، يمكن أن يكون نظام البرهان حتى غير مشغل، أو حتى إذا كان يعمل، فإنه يكون لديه وظيفة ‘استشارية’ فقط. أحدث Rollup تشمل: (i) بعض Rollup محددة لتطبيقات عديم الثقة، مثل Fuel؛ (ii) حتى كتابة هذا المقال، Optimism و Arbitrum هما تنفيذان للمرحلة الأولى من Rollup الكاملة EVM بدون حاجة للثقة. السبب في عدم تقدم Rollup بشكل أكبر هو القلق من وجود أخطاء في الشفرة. نحن بحاجة إلى Rollup بدون الحاجة للثقة، لذلك يجب علينا مواجهة وحل هذه المشكلة.
أولاً، دعونا نستعرض نظام “stage” المقدم في هذا النص أولاً.
المرحلة 0: يجب أن يتمكن المستخدمون من تشغيل العقدة ومزامنة السلسلة. إذا كان التحقق موثوق به بالكامل / مركزي ، فليس هذا بمشكلة.
المرحلة 1: يجب أن يكون هناك نظام إثبات (غير موثوق) لضمان قبول المعاملات الصحيحة فقط. يُسمح بوجود لجنة أمان يمكنها عكس نظام الإثبات، ولكن يجب أن يكون هناك عتبة تصويت بنسبة 75٪. بالإضافة إلى ذلك، يجب أن يكون قسم منع النصاب (26٪ +) في اللجنة خارج شركة Rollup الرئيسية. يُسمح باستخدام آلية ترقية أضعف (مثل DAO)، ولكن يجب أن يكون لديها وقت إستجابة كافٍ، حيث يمكن للمستخدمين سحب أموالهم إذا تمت الموافقة على ترقية خبيثة قبل تفعيل الأموال.
المرحلة 2: يجب أن يكون هناك نظام إثبات (غير قابل للثقة) يضمن قبول المعاملات الصالحة فقط. يسمح للجنة الأمنية بالتدخل فقط عند وجود أخطاء يمكن إثباتها في الشفرة مثل عدم تطابق نظامي إثبات متكررين أو قبول نظام إثبات لجذرين ما بعد حالة مختلفة لنفس الكتلة (أو عدم قبول أي شيء لفترة طويلة مثل أسبوع). يُسمح باستخدام آلية الترقية ولكن يجب أن يتمتع بوقت استجابة طويل.
هدفنا هو الوصول إلى المرحلة 2. التحدي الرئيسي في الوصول إلى المرحلة 2 هو الحصول على ما يكفي من الثقة لإثبات أن النظام فعليًا يستحق الثقة بما فيه الكفاية. هناك طريقتان رئيسيتان يمكن أن تنفذ بهما هذه العملية:
الرسم البياني المقرر للمثبتين معتمد على نظام إيجابي للإثبات ونظام إثبات الصحة ولجنة أمان.
بالنسبة للتحقق الرسمي، فإن العمل ضخم. نحتاج إلى إنشاء إصدار التحقق الرسمي الكامل للمثبت SNARK لـ EVM. هذا مشروع معقد للغاية، على الرغم من أننا بدأنا بالفعل في القيام به. هناك طريقة يمكن أن تبسط كثيرًا هذه المهمة: يمكننا إنشاء مثبت SNARK مُصغّر لآلة الـ RISC-V أو Cairo، ثم تنفيذ EVM في هذه الآلة الافتراضية المُصغّرة (وتثبت رسميا مطابقتها لمواصفات آلة الـ ETH الافتراضية الأخرى).
بالنسبة للإثبات المتعدد، هناك جزءان رئيسيان لم يتم الانتهاء منهما بعد. أولاً، نحتاج إلى ثقة كافية في نظامي إثبات مختلفين على الأقل، لضمان أن كل منهما آمن بما فيه الكفاية ولضمان أنه إذا كان هناك أي مشكلة في أحدهما، فإن هذه المشكلة يجب أن تكون مختلفة وغير مترابطة (بحيث لا تحدث في نفس الوقت). ثانياً، نحتاج إلى ثقة عالية جداً في اللوجيك الأساسي لنظام الإثبات المدمج. هذا الجزء يحتوي على كمية أقل من الشفرة. هناك بعض الطرق لجعلها صغيرة جداً، عن طريق تخزين الأموال في عقد آمن متعدد التوقيع (Safe multisig) الذي يعمل كموقع لأطراف العقد المختلفة، ولكن هذا سيزيد من تكلفة غاز الداخل في السلسلة. نحن بحاجة إلى إيجاد توازن ما بين الكفاءة والأمان.
يمكن تخفيض الضغط MEV على L1 عن طريق نقل النشاط إلى L2.
أحد التحديات الرئيسية التي تواجه النظام البيئي L2 اليوم هو صعوبة تنقل المستخدمين داخله. بالإضافة إلى ذلك ، غالبا ما يعيد النهج الأسهل تقديم افتراضات الثقة: التفاعل المركزي عبر السلسلة وعملاء RPC وما إلى ذلك. نحن بحاجة إلى جعل استخدام النظام البيئي L2 يبدو وكأنه استخدام نظام ETH موحد.
توجد العديد من فئات تحسين التوافق بين L2 عبر الشبكة. في النظرية ، يعد Rollup مركزًا لـ ETH مشاركة L1. ومع ذلك ، فإن النظام البيئي لـ ETH L2 الحالي لا يزال بعيدًا عن الحالة المثالية في الممارسة بسبب هذه القضايا:
1، العنوان للسلسلة المحددة: يجب أن يحتوي العنوان على معلومات السلسلة (L1، Optimism، Arbitrum …). بمجرد تحقيق هذا الأمر، يمكن تنفيذ عملية الإرسال عبر L2 ببساطة عن طريق وضع العنوان في حقل ‘إرسال’، وفي هذه الحالة يمكن للمحفظة معالجة كيفية الإرسال بشكل آلي في الخلفية (بما في ذلك استخدام بروتوكول التفاعل عبر السلاسل).
3٬ التفاعل عبر السلاسل وتبادل الغاز: يجب أن يكون هناك بروتوكول مفتوح وموحد للتعبير عن عمليات التفاعل عبر السلاسل، مثل “سأرسل 1 ETH إلى الشخص الذي أرسل إلي 0.9999 ETH (على Arbitrum)”، و"سأرسل 0.0001 ETH إلى الأشخاص الذين شاركوا في هذه المعاملة (على Optimism)". ERC-7683 هو محاولة للأولى، بينما RIP-7755 هو محاولة للثانية، على الرغم من أن نطاق تطبيق كل منهما أوسع من هذه الحالات الخاصة.
كيف يمكن للعميل الخفيف تحديث رؤية سلسلة عناوين Ethereum الخاصة به. بمجرد الحصول على سلسلة العناوين، يمكن استخدام دليل Merkle للتحقق من أي كائن حالة. بمجرد الحصول على كائن الحالة L1 الصحيح، يمكن استخدام دليل Merkle (وإذا كنت ترغب في التحقق المسبق، يمكن استخدام التوقيع) للتحقق من أي كائن حالة على L2. قام Helios بالفعل بالأول. تمديد ذلك إلى الأخير هو تحدي قياسي.
كيفية عمل محفظة Keystore
3、التكامل المتزامن: يسمح بالاستدعاء المتزامن بين L2 محددة و L1 أو بين عدة L2. وهذا يساعد في زيادة كفاءة التمويل اللامركزي بروتوكول المالي. يمكن للأولى تحقيق ذلك دون أي تنسيق عبر L2 ؛ بينما تحتاج الأخيرة إلى مشاركة الترتيب. تعتمد تقنية Rollup تلقائيًا على كل هذه التقنيات.
العنوان المحدد للسلسلة:
ERC-3770 :
ERC-7683:
RIP-7755:
تصميم نمط محفظة Scroll keystore:
هيليوس:
ERC-3668 (المعروف أحيانًا باسم قراءة CCIP):
مقترح جاستن دريك لـ “التأكيد المشترك المبني على (المشاركة المسبقة)”
تحميل L1S (RIP-7728): تحميل مسبق التحويل البرمجي / 20388
REMOTESTATICCALL في التفاؤل:
AggLayer، بما في ذلك فكرة جسر الرمز المشترك:
يواجه العديد من الأمثلة المذكورة أعلاه مشكلة متى يجب أن يتم توحيد المعايير وتوحيد المستويات التي يجب أن تتوفر فيها المعايير. إذا تم توحيد المعايير مبكرًا ، فقد يؤدي ذلك إلى تعزيز حل سيئ. إذا تم توحيد المعايير في وقت متأخر ، فقد يؤدي ذلك إلى تجزئة غير ضرورية. في بعض الحالات ، يوجد حلاً مؤقتًا بخصائص ضعيفة ولكنه أسهل تنفيذًا ، بالإضافة إلى حل نهائي صحيح ولكن يستغرق سنوات لتحقيقه.
هذه المهام ليست مشكلات فنية فقط ، بل هي أيضًا (وقد تكون في الغالب) مشكلات اجتماعية تتطلب التعاون بين L2 والمحفظة و L1.
معظم هذه المقترحات هي هياكل “طبقة أعلى”، وبالتالي لا تؤثر كثيرا على النظر في المستوى L1. استثناء واحد هو ترتيب المشاركة، الذي له تأثير كبير على القيمة القصوى القابلة للاستخراج (MEV).
إذا كانت L2 قابلة للتوسيع بشكل كبير وناجحة، ولكن L1 لا يمكنها معالجة كمية كبيرة جدًا من الحجم، فقد تواجه إثيريوم العديد من المخاطر:
1、حالة الاقتصادية لأصول ETH ستصبح أكثر عدم استقرارًا، وهذا بدوره سيؤثر على أمان الشبكة على المدى الطويل.
3، سيستغرق الوصول إلى نفس مستوى الأمان الذي يوفره L1 في L2 وقتًا طويلاً.
لهذه الأسباب، فمن القيمة الكبيرة أن نواصل توسيع L1 نفسها وضمان قدرتها على استيعاب المزيد والمزيد من الحالات الاستخدام.
أبسط طريقة للتوسع هي زيادة الحد الأقصى للغاز مباشرة. ومع ذلك ، قد يؤدي ذلك إلى ترجيح L1 نحو الهيمنة المركزية ، مما يضعف واحدة من السمات الأساسية التي جعلت ETH L1 قوية للغاية: مصداقية كطبقة أساس قوية. لا يزال هناك جدل حول مدى استدامة زيادة الحد الأقصى للغاز بسبب التنفيذ المختلف للتقنيات الأخرى التي تجعل التحقق من كتل أكبر أسهل (مثل الانتهاء التاريخي ، وعدم الحالة ، وإثبات صحة L1 EVM). شيء آخر مهم يحتاج إلى تحسين مستمر هو كفاءة برامج عميل ETH ، حيث تتفوق كفاءة اليوم بكثير على ما كانت عليه قبل خمس سنوات. ستنطوي استراتيجية زيادة الحد الأقصى للغاز الفعال على تسريع تطوير هذه التقنيات التحقق.
سيتم مناقشة هذه التحسينات بشكل أكثر تفصيلا في المقالات المستقبلية لـ Splurge.
أخيرًا، الاستراتيجية الثالثة هي Rollups الأصلية (أو المجموعات الموثوق بها) بشكل أساسي، إنشاء العديد من نسخ EVM التي تعمل بشكل متوازي، مما يؤدي إلى إنشاء نموذج يعادل ما يمكن أن يوفره Rollup، ولكن بدرجة أكبر من التكامل الأصلي في البروتوكول.
L1 التوسع له ثلاث استراتيجيات يمكن تنفيذها بشكل منفصل أو متوازي:
عندما نفهم هذه التقنيات المختلفة ، نجد أن لكل منها تضحيات مختلفة. على سبيل المثال ، توجد العديد من نقاط الضعف المشتركة بين Rollups الأصلية والعادية في الجانب التركيبي: لا يمكنك إرسال عملية واحدة لتنفيذ العمليات عبر عدة Rollups مثلما يمكنك القيام به في العقود الذكية على نفس الطبقة L1 (أو L2). زيادة الحد الأقصى للغاز ستضعف فوائد أخرى يمكن تحقيقها عن طريق تبسيط التحقق من L1 ، مثل زيادة عدد المستخدمين الذين يشغلون عقدة التحقق ، وزيادة عدد المستخدمين الذين يقومون بالرهان المنفرد. قد يزيد جعل عمليات محددة في EVM (آلة إيثريوم الافتراضية) أرخص من تعقيد EVM بشكل عام بناءً على طريقة التنفيذ.
أي خريطة طريق لتوسيع L1 تحتاج إلى الإجابة على سؤال كبير: ما هي رؤية L1 و L2 في النهاية على حدة؟ يبدو أن وضع كل المحتوى في L1 أمر مبالغ فيه: قد تشمل سيناريوهات التطبيق المحتملة مئات الآلاف من المعاملات في الثانية، وهذا سيجعل L1 غير قادر تمامًا على التحقق (ما لم نتبع نهج Rollup الأصلي). ولكننا بالفعل بحاجة إلى بعض المبادئ التوجيهية للتأكد من أننا لن نقع في مثل هذا المأزق: زيادة الحد الأقصى للغاز بمقدار 10 مرات، مما يضر باللامركزية لـ إثيريوم L1.
وجهة نظر واحدة حول تقسيم العمل بين L1 و L2
جذب المزيد من المستخدمين إلى L1 لا يعني فقط رفع القدرة التوسعية، بل يعني أيضًا تحسين جوانب أخرى من L1. هذا يعني أن المزيد من MEV سيبقى على L1 (بدلاً من أن يكون فقط مشكلة L2)، لذلك سيصبح من الضروري معالجة احتياجات MEV بشكل أكثر إلحاحًا. سيؤدي هذا إلى زيادة كبيرة في قيمة وقت الفتح السريع على L1. في الوقت نفسه، سيعتمد ذلك بشكل كبير أيضًا على سير تحقق L1 (المنحدر).