فيتاليك: توضيح الاختلافات بين أنواع L2 المختلفة

ستتجه مشاريع L2 بشكل متزايد نحو التغايرية.

العنوان الأصلي: 《Different types of layer 2s》

الكاتب: Vitalik Buterin

الترجمة: BlockBeats

شهد النظام البيئي توسعًا سريعًا خلال العام الماضي. تقليديًا، كان نظام ZK-EVM rollup البيئي ممثلًا بـ StarkNet وArbitrum وOptimism وScroll، وقد أحرز تقدمًا سريعًا مع تعزيز أمانه باستمرار، وتلخص صفحة L2beat حالة كل مشروع بشكل جيد.

بالإضافة إلى ذلك، رأينا بعض الفرق تبني سلاسل جانبية (sidechains) وأيضًا تبدأ في تطوير حلول rollup (مثل Polygon)، وبعض مشاريع L1 تحاول التحول نحو التحقق من الصحة (validity) (مثل Celo)، وهناك أيضًا محاولات جديدة كليًا (مثل Linea، Zeth…).

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

حاليًا، تسعى بعض مشاريع L1 المستقلة إلى الاندماج بشكل أوثق مع نظام Ethereum البيئي، وربما تتحول إلى مشاريع L2. قد ترغب هذه المشاريع في اتباع نهج انتقالي تدريجي. الانتقال الكامل والفوري سيقلل من القابلية للاستخدام، لأن التقنية ليست جاهزة بعد لوضع كل شيء في حل rollup. أما الانتقال الكامل المتأخر، فقد يضحي بالزخم ويأتي متأخرًا جدًا ليكون ذا معنى عملي.

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

التطبيقات غير المالية، مثل الألعاب أو وسائل التواصل الاجتماعي، ترغب في اللامركزية، لكنها تحتاج فقط إلى مستوى معين من الأمان.

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

موضوع مهم هو أنه على الرغم من أن التطبيقات والمستخدمين الموجودين حاليًا على Ethereum L1 مستعدون على المدى القصير لدفع رسوم rollup صغيرة ولكنها لا تزال مرئية، إلا أن المستخدمين القادمين من خارج عالم البلوكشين أقل استعدادًا للقيام بذلك: إذا كنت تدفع سابقًا 1 دولار، فدفع 0.10 دولار يصبح أكثر قبولًا، أما إذا كنت تدفع 0 دولار سابقًا، فيصعب تقبل ذلك.

ينطبق هذا على التطبيقات التي لا تزال مركزية اليوم، وكذلك على مشاريع L1 الصغيرة التي عادةً ما تكون رسومها منخفضة للغاية عندما يكون عدد مستخدميها قليلًا.

سؤال طبيعي يطرح نفسه: بالنسبة لتطبيق معين، أي من هذه التوازنات المعقدة بين حلول rollup وvalidiums (التحقق من الصحة) والأنظمة الأخرى هو الأنسب له؟

Rollups مقابل Validiums مقابل الأنظمة المنفصلة

البعد الأول للأمان وقابلية التوسع الذي سنناقشه يمكن وصفه كالتالي: إذا كان لديك أصل مُصدر على L1، ثم قمت بإيداعه في L2، ثم نقلته إلى حسابك، فما مدى الضمان الذي تحصل عليه لاستعادة الأصل إلى L1؟

هناك أيضًا سؤال ذو صلة: ما هي الخيارات التقنية التي تؤدي إلى هذا المستوى من الضمان، وما هي التوازنات المرتبطة بهذا الخيار؟

يمكننا وصف هذه المسألة من خلال رسم بياني بسيط:

من الجدير بالذكر أن هذا مخطط مبسط، وهناك العديد من الخيارات الوسيطة. على سبيل المثال:

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

بين plasma وvalidium: يوفر نظام Plasma ضمانات أمان مماثلة لـ rollup مع توفر البيانات خارج السلسلة، لكنه يدعم فقط عددًا محدودًا من التطبيقات. يمكن لنظام ما أن يوفر EVM كاملًا، ويمنح المستخدمين الذين لا يستخدمون هذه التطبيقات الأكثر تعقيدًا ضمانات بمستوى Plasma، ويمنح مستخدمي هذه التطبيقات ضمانات بمستوى validium.

يمكن اعتبار هذه الخيارات الوسيطة طيفًا بين rollup وvalidium. لكن، ما الذي يدفع التطبيقات لاختيار نقطة معينة على هذا الطيف بدلاً من نقطة أبعد إلى اليسار أو اليمين؟ هنا، هناك عاملان رئيسيان:

1. تكلفة توفر البيانات الأصلية على Ethereum، والتي ستنخفض بمرور الوقت مع تطور التقنية. التحديث القادم لـ Ethereum، Dencun، سيقدم EIP-4844 (المعروف أيضًا باسم "proto-danksharding")، والذي يوفر حوالي 32 كيلوبايت/ثانية من توفر البيانات على السلسلة.

من المتوقع أنه خلال السنوات القادمة، مع إطلاق danksharding الكامل، سيزداد توفر البيانات تدريجيًا، والهدف النهائي هو حوالي 1.3 ميغابايت/ثانية من توفر البيانات. في الوقت نفسه، ستسمح تحسينات ضغط البيانات لنا بتحقيق المزيد بنفس كمية البيانات.

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

يبدو هذا التوازن تقريبًا كما هو موضح في الرسم التالي:

نوع آخر يستحق الذكر هو التأكيدات المسبقة (pre-confirmations). التأكيدات المسبقة هي رسائل موقعة من مجموعة من المشاركين في rollup أو validium، تشير إلى "نحن نؤكد أن هذه المعاملات مدرجة بهذا الترتيب، وأن post-state root هو هذا". قد يوقع هؤلاء المشاركون على تأكيد مسبق غير مطابق للواقع، لكن إذا فعلوا ذلك، سيتم تدمير وديعتهم.

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

يمكن اعتبار التأكيدات المسبقة مثالًا آخر على نظام هجين، مشابه لـ "مزيج plasma/validium" المذكور أعلاه، لكن هذه المرة بين rollup (أو validium) ذو الأمان الكامل ولكن بزمن تأخير مرتفع، ونظام ذو مستوى أمان أقل ولكن بزمن تأخير منخفض. التطبيقات التي تحتاج إلى زمن تأخير منخفض ستحصل على أمان أقل، لكنها يمكن أن تتعايش في نفس النظام البيئي مع التطبيقات التي تفضل أمانًا أعلى مقابل زمن تأخير أعلى.

قراءة Ethereum بدون ثقة

شكل آخر أقل تناولًا ولكنه مهم جدًا من الاتصال يتعلق بقدرة النظام على قراءة بلوكشين Ethereum. تحديدًا، يشمل ذلك قدرة النظام على التراجع (rollback) إذا حدث تراجع في Ethereum. لفهم قيمة ذلك، ضع في اعتبارك السيناريو التالي:

افترض كما هو موضح في الرسم أن بلوكشين Ethereum تعرض لتراجع. قد يكون هذا انقطاعًا مؤقتًا خلال فترة لم يتم فيها التأكيد النهائي بعد؛ أو قد يكون بسبب خروج عدد كبير من المدققين عن الخدمة، مما يؤدي إلى فترة تسرب عدم النشاط حيث لا يمكن تأكيد السلسلة لفترة طويلة.

أسوأ سيناريو محتمل هو كما يلي: افترض أن أول بلوك في السلسلة العليا (top chain) يقرأ بعض البيانات من أول بلوك في سلسلة Ethereum على اليسار. على سبيل المثال، قام شخص ما بإيداع 100 ETH في السلسلة العليا عبر Ethereum. ثم حدث تراجع في Ethereum، لكن السلسلة العليا لم تتراجع. النتيجة هي أن الكتل المستقبلية للسلسلة العليا تتبع بشكل صحيح كتل Ethereum الجديدة والصحيحة، لكن المعاملة الخاطئة (إيداع 100 ETH) لا تزال موجودة في السلسلة العليا. قد يؤدي هذا الخلل إلى تضخم العملة، وتحويل ETH المربوط على السلسلة العليا إلى احتياطي جزئي فقط.

هناك طريقتان لحل هذه المشكلة:

1. يجب أن تقرأ السلسلة العليا فقط كتل Ethereum التي تم تأكيدها نهائيًا، وبالتالي لا تحتاج أبدًا إلى التراجع؛

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

لاحظ أن الطريقة الأولى لها حالة خاصة: إذا تعرضت Ethereum لهجوم 51% أدى إلى ظهور كتلتين جديدتين غير متوافقتين في نفس الوقت، وكلاهما يبدو أنه تم تأكيده نهائيًا، فقد تختار السلسلة العليا الكتلة الخاطئة (أي الكتلة التي لا يدعمها إجماع مجتمع Ethereum في النهاية)، وستحتاج إلى التراجع للانتقال إلى الكتلة الصحيحة. يمكن القول إنه لا داعي لكتابة كود لمعالجة هذه الحالة مسبقًا؛ يمكن التعامل معها من خلال هارد فورك للسلسلة العليا.

هناك سببان مهمان لقدرة البلوكشين على قراءة Ethereum بدون ثقة:

أولًا، يمكن أن تقلل هذه القدرة من المخاطر الأمنية المرتبطة بجسر الأصول المُصدرة على Ethereum (أو حلول الطبقة الثانية الأخرى) إلى هذه السلسلة؛

ثانيًا، تتيح هذه القدرة لمحافظ الحسابات المجردة (account abstraction wallets) التي تستخدم بنية تخزين مفاتيح مشتركة الاحتفاظ بالأصول على هذه السلسلة بأمان.

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

هل امتلاك جسر كافٍ ليصبح validium؟

افترض أن السلسلة العليا بدأت كسلسلة مستقلة، ثم قام شخص ما بنشر عقد جسر على Ethereum. عقد الجسر هو ببساطة عقد يقبل رؤوس كتل السلسلة العليا (block headers)، ويتحقق مما إذا كان أي رأس كتلة مقدم إليه مصحوبًا بشهادة صالحة تثبت أن رأس الكتلة تم قبوله من قبل إجماع السلسلة العليا، ويضيف رأس الكتلة إلى القائمة.

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

حتى الآن، لا! هناك سببان:

1. نحن نتحقق من توقيعات الكتل، لكننا لا نتحقق مما إذا كان تحويل الحالة صحيحًا. لذلك، إذا أودعت أصلًا مُصدرًا على Ethereum في السلسلة العليا، وأصبح المدققون في السلسلة العليا غير أمناء، يمكنهم توقيع تحويل حالة غير صالح وسرقة هذه الأصول؛

2. لا تزال السلسلة العليا غير قادرة على قراءة Ethereum. لذلك، لا يمكنك إيداع أصول Ethereum الأصلية في السلسلة العليا إلا إذا اعتمدت على جسر طرف ثالث (قد يكون غير آمن).

الآن، دعونا نبني الجسر ليكون جسر تحقق (validating bridge): لا يتحقق فقط من الإجماع، بل يتحقق أيضًا من أن أي كتلة جديدة تم حسابها باستخدام إثبات ZK-SNARK صحيحة من حيث الحالة.

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

ومع ذلك، لا نزال لم نحل المشكلة الثانية: لا تستطيع السلسلة العليا قراءة بيانات Ethereum. لتحقيق ذلك، نحتاج إلى اتباع إحدى الطريقتين:

1. وضع عقد جسر على السلسلة العليا يتحقق من كتل Ethereum التي تم تأكيدها نهائيًا؛

2. تضمين تجزئة (hash) أحدث كتلة Ethereum في كل كتلة من السلسلة العليا، واستخدام قاعدة اختيار تفرع (fork choice rule) لفرض الربط بالتجزئة. أي أن الكتل في السلسلة العليا المرتبطة بكتل Ethereum غير الرئيسية تعتبر كتلًا غير رئيسية أيضًا. إذا كانت كتلة السلسلة العليا مرتبطة بكتلة Ethereum كانت في البداية على السلسلة الرئيسية ثم أصبحت غير رئيسية، يجب أن تصبح كتلة السلسلة العليا غير رئيسية أيضًا.

يمكن أن تكون هذه الروابط البنفسجية روابط تجزئة أو عقود جسر تتحقق من إجماع Ethereum

هل هذا كافٍ؟ في الواقع، ليس كافيًا، لأن هناك بعض الحالات الطرفية الصغيرة:

1. ماذا يحدث إذا تعرضت Ethereum لهجوم 51%؟

2. كيف تتعامل مع ترقيات الهارد فورك لـ Ethereum؟

3. كيف تتعامل مع ترقيات الهارد فورك لسلسلتك؟

سيؤدي هجوم 51% على Ethereum إلى نتائج مماثلة لهجوم 51% على السلسلة العليا، ولكن بالعكس. قد يؤدي الهارد فورك في Ethereum إلى تعطيل الجسر داخل السلسلة العليا. الالتزام الاجتماعي (social commitment) بأن السلسلة العليا ستتراجع إذا تراجعت Ethereum عن كتلة تم تأكيدها نهائيًا، أو ستقوم بهارد فورك إذا قامت Ethereum بهارد فورك، هو أنظف طريقة لحل هذه المشكلة.

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

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

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

الخلاصة

هناك بعدان رئيسيان لـ "الاتصال بـ Ethereum":

1. أمان السحب إلى Ethereum؛

2. أمان قراءة Ethereum.

كلاهما مهم جدًا وله اعتبارات مختلفة. في كلتا الحالتين هناك طيف متصل:

لاحظ أن كل بعد له طريقتان مختلفتان للقياس (في الواقع هناك أربعة أبعاد): يمكن قياس أمان السحب من خلال (i) مستوى الأمان، و(ii) عدد المستخدمين أو حالات الاستخدام التي تستفيد من أعلى مستوى أمان؛

أما أمان القراءة فيمكن قياسه من خلال (i) مدى سرعة قدرة الرابط على قراءة كتل Ethereum، خاصة الفرق بين الكتل المؤكدة نهائيًا وأي كتلة، و(ii) درجة الالتزام الاجتماعي للرابط في التعامل مع الحالات الطرفية مثل هجمات 51% والهارد فورك.

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