! [البابا فيتالينك الأول يعيد تعريف L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-17bf55f5b7-dd1a6f-69ad2a.webp)
شكر خاص لكارل فلورش على التعليقات والمراجعة *
توسع النظام البيئي Ethereum Layer 2 بسرعة خلال العام الماضي. حقق النظام البيئي ZK-EVM Rollup ، الذي يمثله StarkNet و Arbitrum و Optimism و Scroll ، خطوات كبيرة في تحسين الأمان ، وتوفر صفحة L2beat ملخصا جيدا لحالة كل مشروع. بالإضافة إلى ذلك ، رأينا بعض الفرق التي تبني سلاسل جانبية تبدأ في إنشاء Rollups (Polygon) ، وبعض مشاريع الطبقة 1 تحاول الانتقال إلى التحقق من الصحة (Celo) ، وتبذل جهودا جديدة (Linea ، Zeth ، إلخ).
نتيجة لذلك ، أصبحت مشاريع الطبقة 2 أكثر تجانسا. أتوقع أن يستمر هذا الاتجاه للأسباب التالية:
تسعى بعض مشاريع الطبقة 1 المستقلة حاليا إلى الاقتراب من النظام البيئي ل Ethereum وربما تصبح الطبقة 2. ** قد تتطلب هذه المشاريع انتقالا تدريجيا. سيؤدي التبديل الآن إلى انخفاض في قابلية الاستخدام لأن التكنولوجيا ليست جاهزة لوضع كل شيء في مجموعة التحديثات ؛ لكن التبديل بعد فوات الأوان يمكن أن يكلف الزخم وقد فات الأوان بحيث لا يكون له أي معنى.
ترغب بعض المشاريع المركزية في تزويد المستخدمين بمزيد من الضمانات الأمنية وتستكشف السبل القائمة على blockchain. في كثير من الحالات ، قد تستكشف هذه المشاريع سابقا "سلاسل الكونسورتيوم المصرح بها". في الواقع ، قد يحتاجون فقط إلى مستوى "الطبقة الوسطى" من اللامركزية. بالإضافة إلى ذلك ، غالبا ما يكون لديهم إنتاجية عالية جدا ، مما يجعلها غير مناسبة حتى لعمليات التجميع ، على الأقل على المدى القصير.
تريد التطبيقات غير المالية ، مثل الألعاب أو وسائل التواصل الاجتماعي ، أن تكون لامركزية ، ولكنها تحتاج فقط إلى "طبقة متوسطة" من الأمان. وسائل التواصل الاجتماعي ، على سبيل المثال ، تتضمن في الواقع أجزاء مختلفة من التطبيق يتم التعامل معها بشكل مختلف: يجب أن تتم الأنشطة منخفضة التردد وعالية القيمة مثل تسجيل اسم المستخدم واسترداد الحساب على مجموعة التحديثات. تتطلب الأنشطة عالية التردد ومنخفضة القيمة مثل النشر والاقتراع أمانا أقل. إذا اختفت مشاركتك بسبب فشل سلسلة ، فهذا سعر مقبول ؛ ولكن إذا تسبب فشل السلسلة في فقدان حسابك ، فهذه مشكلة كبيرة.
هناك مشكلة مهمة تتمثل في أن دفع رسوم تراكمية أصغر ، ولكنها لا تزال مرئية ، مقبول لتطبيقات ومستخدمي Ethereum Layer 1 في الوقت الحالي ، ولكن ليس للمستخدمين خارج عالم blockchain: إذا كنت قد دفعت سابقا دولارا واحدا ، فإن دفع 0.10 دولار أكثر قبولا ؛ ولكن إذا كنت قد دفعت سابقا 0 دولار ، فإن دفع 0.10 دولار أمر غير مقبول. ينطبق هذا على كل من التطبيقات المركزية الحالية وعلى مشاريع الطبقة 1 الأصغر ، والتي غالبا ما يكون لها رسوم منخفضة للغاية مع قاعدة مستخدمين صغيرة.
السؤال الذي يطرح نفسه هو: أي من هذه المقايضات المعقدة بين عمليات التجميع والصلاحية والأنظمة الأخرى معقولة لتطبيق معين؟
التراكمات 、الصلاحيات、قطع الاتصال
يمكن وصف البعد الأول للأمان والحجم الذي سنستكشفه على النحو التالي: إذا كنت تمتلك أصلا تم إصداره في الطبقة 1 ثم أودعه في الطبقة 2 ثم تم تحويله إلى حسابك ، فهل يمكنك التأكد من أنه يمكنك إعادة هذا الأصل إلى الطبقة 1؟ **
في الوقت نفسه ، هناك سؤال مماثل: ما هي الخيارات التكنولوجية التي تؤدي إلى هذا الضمان ، وما هي المقايضات وراء هذه الخيارات التكنولوجية؟ **
يمكننا ببساطة وصف المشكلة باستخدام جدول:
! [البابا فيتالينك الأول يعيد تعريف L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-144dab5eab-dd1a6f-69ad2a.webp)
تجدر الإشارة إلى أن هذه بنية مبسطة وهناك الكثير من العناصر الوسيطة للاختيار من بينها. على سبيل المثال:
بين Rollup و Validium: نوع من الصلاحية يسمح لأي شخص بإجراء مدفوعات على السلسلة لتغطية رسوم المعاملات ، وعند هذه النقطة سيضطر المشغل إلى تقديم بعض البيانات إلى السلسلة أو فقدان الإيداع.
بين البلازما و Validium: يوفر نظام البلازما ضمانات أمان تشبه التجميع وتوافر البيانات خارج السلسلة (DA) ، ولكنه يدعم فقط عددا محدودا من التطبيقات. يمكن للنظام توفير EVM كامل وتوفير ضمانات على مستوى البلازما للمستخدمين الذين لا يستخدمون تلك التطبيقات الأكثر تعقيدا ، وضمانات على مستوى الصلاحية للمستخدمين الذين يستخدمون هذه التطبيقات.
يمكن اعتبار هذه الخيارات الوسيطة مجموعة من التقنيات بين عمليات التجميع والصلاحيات. ولكن ما الذي يحفز التطبيق على اختيار نقطة معينة على النسب ، بدلا من أقصى اليسار أو أقصى اليمين؟ هناك عاملان رئيسيان هنا:
ستنخفض تكلفة توفر البيانات على Ethereum نفسها تدريجيا مع تحسن التكنولوجيا. قدمت عملية الهارد فورك التالية ل Ethereum ، Dencun ، EIP-4844 (المعروف أيضا باسم "proto-danksharding") ، والذي يوفر DA على السلسلة يبلغ حوالي 32 كيلو بايت / ثانية. على مدى السنوات القليلة المقبلة ، من المتوقع أن يزداد هذا الرقم تدريجيا مع طرح danksharding الكامل ، ليصل في النهاية إلى هدف DA البالغ حوالي 1.3 ميجابايت / ثانية. في الوقت نفسه ، ستسمح لنا التحسينات في ضغط البيانات بفعل المزيد بنفس كمية البيانات.
احتياجات التطبيق نفسه: كم يخسر المستخدم بسبب ارتفاع الرسوم مقارنة بمشاكل التطبيق؟ ** التطبيقات المالية تفقد أكثر بسبب فشل التطبيق ؛ تتضمن الألعاب ووسائل التواصل الاجتماعي قدرا كبيرا من النشاط لكل مستخدم وقيمة النشاط منخفضة نسبيا ، وبالتالي فإن المفاضلة بين الأمان تختلف بالنسبة لهم.
تبدو هذه المقايضة كما يلي:
! [البابا فيتالينك الأول يعيد تعريف L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d6d63d0742-dd1a6f-69ad2a.webp)
ضمان جزئي آخر جدير بالذكر هو التأكيدات المسبقة. التأكيد المسبق هو رسالة موقعة من بعض المشاركين في مجموعة التحديثات أو الصلاحية تقول "لقد أثبتنا أن هذه المعاملات مدرجة في هذا الترتيب ، وأن جذر ما بعد الحالة هو هذا". قد يوقع هؤلاء المشاركون على تأكيد مسبق لا يتوافق مع الوضع الفعلي في وقت لاحق ؛ ولكن إذا فعلوا ذلك ، فإنهم يحرقون وديعة. هذا مفيد للتطبيقات منخفضة القيمة مثل مدفوعات المستهلك ، في حين أن التطبيقات عالية القيمة مثل التحويلات المالية بملايين الدولارات قد تنتظر تأكيدا "منتظما" من الدعم الأمني الكامل للنظام.
يمكن اعتبار التحقق المسبق مثالا آخر على النظام الهجين ، على غرار "نظام Plasma / Validium الهجين" المذكور أعلاه ، ولكن هذه المرة بين Rollup (أو Validium) بأمان كامل ولكن زمن انتقال مرتفع ونظام بمستوى أمان أقل ولكن زمن انتقال أقل. تحصل التطبيقات التي تتطلب زمن انتقال أقل على أمان أقل ، ولكن يمكن أن تتعايش في نفس النظام البيئي مثل التطبيقات التي تتطلب زمن انتقال أعلى مقابل أقصى قدر من الأمان.
اقرأ إيثريوم بدون إذن
شكل آخر أقل مراعاة ، ولكنه لا يزال مهما للغاية ، يتعلق بقدرة النظام على قراءة Ethereum blockchain. على وجه الخصوص ، يتضمن ذلك القدرة على التراجع عندما تحتاج Ethereum إلى التراجع. لفهم سبب قيمة ذلك ، ضع في اعتبارك السيناريو التالي:
! [البابا فيتالينك الأول يعيد تعريف L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-ccbb1fb3ee-dd1a6f-69ad2a.webp)
لنفترض ، كما هو موضح في الرسم البياني ، حدوث تراجع على سلسلة Ethereum. قد يكون هذا فشلا مؤقتا في حقبة لم يتم فيها الانتهاء من السلسلة ، أو قد يكون أن الشبكة كانت غير نشطة وكان عدد كبير جدا من المدققين غير متصلين بالإنترنت ولم يتم الانتهاء من السلسلة لفترة طويلة من الزمن.
السيناريو الأسوأ الذي يمكن أن يؤدي إليه هذا هو كما يلي. لنفترض أن الكتلة الأولى من السلسلة العلوية تقرأ بعض البيانات من الكتلة الموجودة في أقصى اليسار من سلسلة Ethereum. على سبيل المثال ، يقوم شخص ما بإيداع 100 ETH على Ethereum في السلسلة العليا. بعد ذلك ، يحدث التراجع مع Ethereum. ومع ذلك ، لا يوجد تراجع عن السلسلة العليا. نتيجة لذلك ، اتبعت الكتلة المستقبلية للسلسلة العليا بشكل صحيح الكتلة الجديدة لسلسلة Ethereum الصحيحة الجديدة ، ولكن الآن لا تزال نتيجة السلسلة القديمة الخاطئة (أي إيداع 100 ETH) موجودة في السلسلة العليا. قد تسمح هذه الثغرة الأمنية بإنشاء عملة تحول ETH الجسور على السلسلة العليا إلى احتياطي جزئي.
هناك طريقتان لحل هذه المشكلة:
يمكن للسلسلة العليا قراءة كتل Ethereum التي تم الانتهاء منها فقط ، لذلك ليست هناك حاجة لعملية التراجع. **
في حالة حدوث تراجع على Ethereum ، يمكن للسلسلة العليا أيضا التراجع. **
كلاهما يمكن أن يمنع هذا من الحدوث. الأول أسهل في التنفيذ ، لكنه قد يؤدي إلى فقدان الوظائف لفترة طويلة إذا دخلت Ethereum فترة من عدم النشاط. هذا الأخير أكثر صعوبة في التنفيذ ، لكنه يضمن دائما الوظائف المثلى.
من المهم ملاحظة أن هناك حالة خاصة في الطريقة الأولى (1). إذا أدى هجوم بنسبة 51٪ إلى إنشاء كتلتين غير متوافقتين على Ethereum ، وظهرت كلتا الكتلتين نهائيتين في نفس الوقت ، فقد تختار السلسلة العليا الكتلة الخاطئة (أي الكتلة التي لا يدعمها إجماع مجتمع Ethereum في النهاية) ويجب التراجع عنها للتبديل إلى الكتلة الصحيحة. يمكن القول ، ليست هناك حاجة لكتابة التعليمات البرمجية في وقت مبكر للتعامل مع هذا الموقف. يمكنه التعامل مع هذا عن طريق القيام بشوكة صلبة للسلسلة العليا.
تعد قدرة السلاسل على قراءة البيانات على Ethereum بدون إذن ذات قيمة للأسباب التالية:
تقليل مشكلات الأمان التي ينطوي عليها إصدار الرموز المميزة عبر السلسلة على Ethereum (أو طبقة 2 أخرى) إلى تلك السلسلة.
يسمح لمحافظ تجريد الحساب باستخدام هيكل تخزين مفتاح مشترك للاحتفاظ بالأصول بشكل آمن على السلسلة.
السبب الأول مهم ، على الرغم من أن هذه الأهمية قد تكون معترف بها بالفعل على نطاق واسع. والسبب الثاني لا يقل أهمية ، لأنه يعني أنه يمكنك الحصول على محفظة ، وتغيير المفاتيح بسهولة ، والاحتفاظ بالأصول على العديد من السلاسل المختلفة.
هل وجود جسر يجعل السلسلة صالحة؟
لنفترض أن السلسلة العليا تبدأ كسلسلة واحدة ، ثم يضع شخص ما عقدا عبر السلسلة على Ethereum. العقد عبر السلسلة هو ببساطة عقد يقبل رأس الكتلة للسلسلة العليا ، ويتحقق من أن أي رأس يتم إرساله إليه يأتي مع شهادة صالحة تشير إلى أنه مقبول بإجماع السلسلة العليا ويضيف هذا الرأس إلى القائمة. يمكن بناء التطبيقات فوق ذلك لتمكين ميزات مثل إيداع وسحب الرموز المميزة. بمجرد إنشاء هذا الجسر ، هل يوفر أيا من ضمانات ضمان الأصول التي ذكرناها سابقا؟
! [البابا فيتالينك الأول يعيد تعريف L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-77802047aa-dd1a6f-69ad2a.webp)
حتى الآن ، ليس بعد! هناك سببان لهذا:
نحن نتحقق من توقيع الكتلة ، لكننا لا نتحقق من أن انتقال الحالة غير صحيح. لذلك ، إذا قمت بإصدار أصول على Ethereum تم إيداعها في السلسلة العليا ، وكان مدققو السلسلة العليا محتالين ، فيمكنهم التوقيع على انتقال حالة غير صالح وسرقة تلك الأصول.
لا توجد حتى الآن طريقة للسلسلة العليا لقراءة بيانات Ethereum. نتيجة لذلك ، لا يمكنك حتى إيداع أصول Ethereum الأصلية في السلسلة العليا دون الاعتماد على جسور أخرى (وربما غير آمنة) تابعة لجهات خارجية.
الآن ، دعنا نجعل الجسر جسرا للتحقق من الصحة: فهو لا يتحقق فقط من الإجماع ، ولكن أيضا ZK-SNARK الذي يثبت أن حالة أي كتلة جديدة يتم حسابها بشكل صحيح.
بمجرد الانتهاء من ذلك ، لم يعد بإمكان مدققي السلسلة العليا سرقة أموالك. يمكنهم نشر كتلة تحتوي على بيانات غير قابلة للاستخدام ، مما يمنع الجميع من الخروج ، لكن لا يمكنهم سرقتها (إلا إذا حاولوا انتزاع فدية للمستخدمين مقابل تسريب البيانات التي تسمح لهم بالخروج). هذا هو نفس نموذج الأمان مثل الصلاحيات.
ومع ذلك ، ما زلنا لم نحل المشكلة الثانية: لا يمكن للسلسلة العليا قراءة Ethereum.
للقيام بذلك ، نحتاج إلى القيام بأحد أمرين:
ضع العقد عبر السلسلة الذي يتحقق من صحة كتلة Ethereum النهائية داخل السلسلة العليا.
اجعل كل كتلة في السلسلة العلوية تحتوي على تجزئة أحدث كتلة Ethereum ، ولديك قاعدة اختيار شوكة تفرض رابط التجزئة. أي أن كتلة السلسلة العليا المرتبطة بكتلة Ethereum غير الموجودة في السلسلة الأساسية هي نفسها غير أساسية ، وإذا كانت سلسلة blockchain ذات السلسلة العليا متصلة بكتلة Ethereum التي كانت أساسية في البداية ، ولكنها أصبحت فيما بعد غير أساسية ، فيجب أن تصبح كتلة السلسلة العليا أيضا غير أساسية.
! [البابا فيتالينك الأول يعيد تعريف L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-7340ab7dba-dd1a6f-69ad2a.webp)
يمكن أن يكون الرابط الأرجواني في الرسم البياني إما رابط تجزئة أو عقد جسر يتحقق من إجماع Ethereum.
هل هذا يكفي؟ كما اتضح ، لم يكن ذلك كافيا ، لأن هناك بعض الحالات الخاصة الصغيرة:
ماذا يحدث إذا تعرضت Ethereum للهجوم بنسبة 51٪؟ **
كيف تتعامل مع ترقية شوكة Ethereum الصلبة؟ **
كيف تتعامل مع ترقية الهارد فورك للسلسلة العليا؟**
سيكون لهجوم Ethereum بنسبة 51٪ عواقب مماثلة لهجوم السلسلة العليا بنسبة 51٪ ، ولكن في الاتجاه المعاكس. قد تؤدي عملية الانقسام الصلب ل Ethereum إلى جعل جسر Ethereum داخل السلسلة العليا غير صالح. الحل الأنظف لهذه المشكلة هو الوعد بأنه إذا تراجعت Ethereum عن كتلة نهائية ، فإن السلسلة العليا ستتراجع أيضا ، وإذا قامت Ethereum بعمل شوكة صلبة ، فستقوم السلسلة العليا أيضا بعمل شوكة صلبة. قد لا يحتاج مثل هذا الوعد أبدا إلى تنفيذه فعليا: يمكنك تنشيط آلية حوكمة على السلسلة العليا وإذا رأت دليلا على هجوم محتمل أو هارد فورك ، ولا تقوم بعمل هارد فورك على السلسلة العليا إلا إذا فشلت آلية الحوكمة.
الإجابة الوحيدة القابلة للتطبيق على السؤال (3) هي أن وجود شكل من أشكال آلية الحوكمة على Ethereum سيجعل عقد الجسر على Ethereum على دراية بترقية الهارد فورك للسلسلة العليا.
ملخص: جسر التحقق ثنائي الاتجاه يكفي تقريبا لجعل السلسلة صالحة. المشكلة الرئيسية المتبقية هي أن السلسلة الأخرى ستقدم التزاما اجتماعيا بالانقسام الصلب عندما يحدث شيء ما ل Ethereum يتسبب في عدم عمل الجسر.
خاتمة
هناك بعدان رئيسيان ل "الاتصال ب Ethereum":
** أمن عمليات السحب إلى Ethereum **
** أمن قراءة بيانات Ethereum **
كلا البعدين مهمان ولهما اعتبارات مختلفة. في كلتا الحالتين ، يوجد نسب:
! [البابا فيتالينك الأول يعيد تعريف L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-be23ca98bb-dd1a6f-69ad2a.webp)
لاحظ أن كل بعد يتم قياسه بطريقتين مختلفتين (إذن هناك بالفعل أربعة أبعاد؟). ): يمكن قياس أمان الاستخراج من خلال (i) مستوى الأمان و (ii) النسبة المئوية للمستخدمين أو حالات الاستخدام التي تستفيد من أعلى مستوى من الأمان ، بينما يمكن قياس أمان القراءة من خلال (i) قدرة الرابط على قراءة كتل Ethereum بسرعة ، وتحديدا الفرق بين الكتلة التي تم الانتهاء منها وأي كتلة ، و (ii) قوة الالتزام الاجتماعي للرابط عند التعامل مع حالات الحافة مثل هجمات 51٪ و hard forks.
هناك العديد من المشاريع التي لها قيمة في مساحة التصميم هذه. بالنسبة لبعض التطبيقات ، يعد الأمان العالي والاتصال المحكم مهمين. بالنسبة للتطبيقات الأخرى ، يكون بعض الاتصال الأكثر مرونة مقبولا لقابلية تطوير أعلى. في كثير من الحالات ، قد يكون من الأفضل البدء ببعض الأساليب الأكثر تساهلا اليوم والانتقال تدريجيا إلى اتصالات أكثر إحكاما خلال العقد المقبل مع تحسن التكنولوجيا.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
البابا فيتالينك الأول يعيد تعريف L2
المؤلف الأصلي | فيتاليك.إيث
! [البابا فيتالينك الأول يعيد تعريف L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-17bf55f5b7-dd1a6f-69ad2a.webp)
توسع النظام البيئي Ethereum Layer 2 بسرعة خلال العام الماضي. حقق النظام البيئي ZK-EVM Rollup ، الذي يمثله StarkNet و Arbitrum و Optimism و Scroll ، خطوات كبيرة في تحسين الأمان ، وتوفر صفحة L2beat ملخصا جيدا لحالة كل مشروع. بالإضافة إلى ذلك ، رأينا بعض الفرق التي تبني سلاسل جانبية تبدأ في إنشاء Rollups (Polygon) ، وبعض مشاريع الطبقة 1 تحاول الانتقال إلى التحقق من الصحة (Celo) ، وتبذل جهودا جديدة (Linea ، Zeth ، إلخ).
نتيجة لذلك ، أصبحت مشاريع الطبقة 2 أكثر تجانسا. أتوقع أن يستمر هذا الاتجاه للأسباب التالية:
تسعى بعض مشاريع الطبقة 1 المستقلة حاليا إلى الاقتراب من النظام البيئي ل Ethereum وربما تصبح الطبقة 2. ** قد تتطلب هذه المشاريع انتقالا تدريجيا. سيؤدي التبديل الآن إلى انخفاض في قابلية الاستخدام لأن التكنولوجيا ليست جاهزة لوضع كل شيء في مجموعة التحديثات ؛ لكن التبديل بعد فوات الأوان يمكن أن يكلف الزخم وقد فات الأوان بحيث لا يكون له أي معنى. ترغب بعض المشاريع المركزية في تزويد المستخدمين بمزيد من الضمانات الأمنية وتستكشف السبل القائمة على blockchain. في كثير من الحالات ، قد تستكشف هذه المشاريع سابقا "سلاسل الكونسورتيوم المصرح بها". في الواقع ، قد يحتاجون فقط إلى مستوى "الطبقة الوسطى" من اللامركزية. بالإضافة إلى ذلك ، غالبا ما يكون لديهم إنتاجية عالية جدا ، مما يجعلها غير مناسبة حتى لعمليات التجميع ، على الأقل على المدى القصير. تريد التطبيقات غير المالية ، مثل الألعاب أو وسائل التواصل الاجتماعي ، أن تكون لامركزية ، ولكنها تحتاج فقط إلى "طبقة متوسطة" من الأمان. وسائل التواصل الاجتماعي ، على سبيل المثال ، تتضمن في الواقع أجزاء مختلفة من التطبيق يتم التعامل معها بشكل مختلف: يجب أن تتم الأنشطة منخفضة التردد وعالية القيمة مثل تسجيل اسم المستخدم واسترداد الحساب على مجموعة التحديثات. تتطلب الأنشطة عالية التردد ومنخفضة القيمة مثل النشر والاقتراع أمانا أقل. إذا اختفت مشاركتك بسبب فشل سلسلة ، فهذا سعر مقبول ؛ ولكن إذا تسبب فشل السلسلة في فقدان حسابك ، فهذه مشكلة كبيرة.
هناك مشكلة مهمة تتمثل في أن دفع رسوم تراكمية أصغر ، ولكنها لا تزال مرئية ، مقبول لتطبيقات ومستخدمي Ethereum Layer 1 في الوقت الحالي ، ولكن ليس للمستخدمين خارج عالم blockchain: إذا كنت قد دفعت سابقا دولارا واحدا ، فإن دفع 0.10 دولار أكثر قبولا ؛ ولكن إذا كنت قد دفعت سابقا 0 دولار ، فإن دفع 0.10 دولار أمر غير مقبول. ينطبق هذا على كل من التطبيقات المركزية الحالية وعلى مشاريع الطبقة 1 الأصغر ، والتي غالبا ما يكون لها رسوم منخفضة للغاية مع قاعدة مستخدمين صغيرة.
السؤال الذي يطرح نفسه هو: أي من هذه المقايضات المعقدة بين عمليات التجميع والصلاحية والأنظمة الأخرى معقولة لتطبيق معين؟
التراكمات 、الصلاحيات、قطع الاتصال
يمكن وصف البعد الأول للأمان والحجم الذي سنستكشفه على النحو التالي: إذا كنت تمتلك أصلا تم إصداره في الطبقة 1 ثم أودعه في الطبقة 2 ثم تم تحويله إلى حسابك ، فهل يمكنك التأكد من أنه يمكنك إعادة هذا الأصل إلى الطبقة 1؟ **
في الوقت نفسه ، هناك سؤال مماثل: ما هي الخيارات التكنولوجية التي تؤدي إلى هذا الضمان ، وما هي المقايضات وراء هذه الخيارات التكنولوجية؟ **
يمكننا ببساطة وصف المشكلة باستخدام جدول:
! [البابا فيتالينك الأول يعيد تعريف L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-144dab5eab-dd1a6f-69ad2a.webp)
تجدر الإشارة إلى أن هذه بنية مبسطة وهناك الكثير من العناصر الوسيطة للاختيار من بينها. على سبيل المثال:
يمكن اعتبار هذه الخيارات الوسيطة مجموعة من التقنيات بين عمليات التجميع والصلاحيات. ولكن ما الذي يحفز التطبيق على اختيار نقطة معينة على النسب ، بدلا من أقصى اليسار أو أقصى اليمين؟ هناك عاملان رئيسيان هنا:
ستنخفض تكلفة توفر البيانات على Ethereum نفسها تدريجيا مع تحسن التكنولوجيا. قدمت عملية الهارد فورك التالية ل Ethereum ، Dencun ، EIP-4844 (المعروف أيضا باسم "proto-danksharding") ، والذي يوفر DA على السلسلة يبلغ حوالي 32 كيلو بايت / ثانية. على مدى السنوات القليلة المقبلة ، من المتوقع أن يزداد هذا الرقم تدريجيا مع طرح danksharding الكامل ، ليصل في النهاية إلى هدف DA البالغ حوالي 1.3 ميجابايت / ثانية. في الوقت نفسه ، ستسمح لنا التحسينات في ضغط البيانات بفعل المزيد بنفس كمية البيانات. احتياجات التطبيق نفسه: كم يخسر المستخدم بسبب ارتفاع الرسوم مقارنة بمشاكل التطبيق؟ ** التطبيقات المالية تفقد أكثر بسبب فشل التطبيق ؛ تتضمن الألعاب ووسائل التواصل الاجتماعي قدرا كبيرا من النشاط لكل مستخدم وقيمة النشاط منخفضة نسبيا ، وبالتالي فإن المفاضلة بين الأمان تختلف بالنسبة لهم.
تبدو هذه المقايضة كما يلي:
! [البابا فيتالينك الأول يعيد تعريف L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d6d63d0742-dd1a6f-69ad2a.webp)
ضمان جزئي آخر جدير بالذكر هو التأكيدات المسبقة. التأكيد المسبق هو رسالة موقعة من بعض المشاركين في مجموعة التحديثات أو الصلاحية تقول "لقد أثبتنا أن هذه المعاملات مدرجة في هذا الترتيب ، وأن جذر ما بعد الحالة هو هذا". قد يوقع هؤلاء المشاركون على تأكيد مسبق لا يتوافق مع الوضع الفعلي في وقت لاحق ؛ ولكن إذا فعلوا ذلك ، فإنهم يحرقون وديعة. هذا مفيد للتطبيقات منخفضة القيمة مثل مدفوعات المستهلك ، في حين أن التطبيقات عالية القيمة مثل التحويلات المالية بملايين الدولارات قد تنتظر تأكيدا "منتظما" من الدعم الأمني الكامل للنظام.
يمكن اعتبار التحقق المسبق مثالا آخر على النظام الهجين ، على غرار "نظام Plasma / Validium الهجين" المذكور أعلاه ، ولكن هذه المرة بين Rollup (أو Validium) بأمان كامل ولكن زمن انتقال مرتفع ونظام بمستوى أمان أقل ولكن زمن انتقال أقل. تحصل التطبيقات التي تتطلب زمن انتقال أقل على أمان أقل ، ولكن يمكن أن تتعايش في نفس النظام البيئي مثل التطبيقات التي تتطلب زمن انتقال أعلى مقابل أقصى قدر من الأمان.
اقرأ إيثريوم بدون إذن
شكل آخر أقل مراعاة ، ولكنه لا يزال مهما للغاية ، يتعلق بقدرة النظام على قراءة Ethereum blockchain. على وجه الخصوص ، يتضمن ذلك القدرة على التراجع عندما تحتاج Ethereum إلى التراجع. لفهم سبب قيمة ذلك ، ضع في اعتبارك السيناريو التالي:
! [البابا فيتالينك الأول يعيد تعريف L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-ccbb1fb3ee-dd1a6f-69ad2a.webp)
لنفترض ، كما هو موضح في الرسم البياني ، حدوث تراجع على سلسلة Ethereum. قد يكون هذا فشلا مؤقتا في حقبة لم يتم فيها الانتهاء من السلسلة ، أو قد يكون أن الشبكة كانت غير نشطة وكان عدد كبير جدا من المدققين غير متصلين بالإنترنت ولم يتم الانتهاء من السلسلة لفترة طويلة من الزمن.
السيناريو الأسوأ الذي يمكن أن يؤدي إليه هذا هو كما يلي. لنفترض أن الكتلة الأولى من السلسلة العلوية تقرأ بعض البيانات من الكتلة الموجودة في أقصى اليسار من سلسلة Ethereum. على سبيل المثال ، يقوم شخص ما بإيداع 100 ETH على Ethereum في السلسلة العليا. بعد ذلك ، يحدث التراجع مع Ethereum. ومع ذلك ، لا يوجد تراجع عن السلسلة العليا. نتيجة لذلك ، اتبعت الكتلة المستقبلية للسلسلة العليا بشكل صحيح الكتلة الجديدة لسلسلة Ethereum الصحيحة الجديدة ، ولكن الآن لا تزال نتيجة السلسلة القديمة الخاطئة (أي إيداع 100 ETH) موجودة في السلسلة العليا. قد تسمح هذه الثغرة الأمنية بإنشاء عملة تحول ETH الجسور على السلسلة العليا إلى احتياطي جزئي.
هناك طريقتان لحل هذه المشكلة:
يمكن للسلسلة العليا قراءة كتل Ethereum التي تم الانتهاء منها فقط ، لذلك ليست هناك حاجة لعملية التراجع. ** في حالة حدوث تراجع على Ethereum ، يمكن للسلسلة العليا أيضا التراجع. **
كلاهما يمكن أن يمنع هذا من الحدوث. الأول أسهل في التنفيذ ، لكنه قد يؤدي إلى فقدان الوظائف لفترة طويلة إذا دخلت Ethereum فترة من عدم النشاط. هذا الأخير أكثر صعوبة في التنفيذ ، لكنه يضمن دائما الوظائف المثلى.
من المهم ملاحظة أن هناك حالة خاصة في الطريقة الأولى (1). إذا أدى هجوم بنسبة 51٪ إلى إنشاء كتلتين غير متوافقتين على Ethereum ، وظهرت كلتا الكتلتين نهائيتين في نفس الوقت ، فقد تختار السلسلة العليا الكتلة الخاطئة (أي الكتلة التي لا يدعمها إجماع مجتمع Ethereum في النهاية) ويجب التراجع عنها للتبديل إلى الكتلة الصحيحة. يمكن القول ، ليست هناك حاجة لكتابة التعليمات البرمجية في وقت مبكر للتعامل مع هذا الموقف. يمكنه التعامل مع هذا عن طريق القيام بشوكة صلبة للسلسلة العليا.
تعد قدرة السلاسل على قراءة البيانات على Ethereum بدون إذن ذات قيمة للأسباب التالية:
السبب الأول مهم ، على الرغم من أن هذه الأهمية قد تكون معترف بها بالفعل على نطاق واسع. والسبب الثاني لا يقل أهمية ، لأنه يعني أنه يمكنك الحصول على محفظة ، وتغيير المفاتيح بسهولة ، والاحتفاظ بالأصول على العديد من السلاسل المختلفة.
هل وجود جسر يجعل السلسلة صالحة؟
لنفترض أن السلسلة العليا تبدأ كسلسلة واحدة ، ثم يضع شخص ما عقدا عبر السلسلة على Ethereum. العقد عبر السلسلة هو ببساطة عقد يقبل رأس الكتلة للسلسلة العليا ، ويتحقق من أن أي رأس يتم إرساله إليه يأتي مع شهادة صالحة تشير إلى أنه مقبول بإجماع السلسلة العليا ويضيف هذا الرأس إلى القائمة. يمكن بناء التطبيقات فوق ذلك لتمكين ميزات مثل إيداع وسحب الرموز المميزة. بمجرد إنشاء هذا الجسر ، هل يوفر أيا من ضمانات ضمان الأصول التي ذكرناها سابقا؟
! [البابا فيتالينك الأول يعيد تعريف L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-77802047aa-dd1a6f-69ad2a.webp)
حتى الآن ، ليس بعد! هناك سببان لهذا:
نحن نتحقق من توقيع الكتلة ، لكننا لا نتحقق من أن انتقال الحالة غير صحيح. لذلك ، إذا قمت بإصدار أصول على Ethereum تم إيداعها في السلسلة العليا ، وكان مدققو السلسلة العليا محتالين ، فيمكنهم التوقيع على انتقال حالة غير صالح وسرقة تلك الأصول.
الآن ، دعنا نجعل الجسر جسرا للتحقق من الصحة: فهو لا يتحقق فقط من الإجماع ، ولكن أيضا ZK-SNARK الذي يثبت أن حالة أي كتلة جديدة يتم حسابها بشكل صحيح.
بمجرد الانتهاء من ذلك ، لم يعد بإمكان مدققي السلسلة العليا سرقة أموالك. يمكنهم نشر كتلة تحتوي على بيانات غير قابلة للاستخدام ، مما يمنع الجميع من الخروج ، لكن لا يمكنهم سرقتها (إلا إذا حاولوا انتزاع فدية للمستخدمين مقابل تسريب البيانات التي تسمح لهم بالخروج). هذا هو نفس نموذج الأمان مثل الصلاحيات.
ومع ذلك ، ما زلنا لم نحل المشكلة الثانية: لا يمكن للسلسلة العليا قراءة Ethereum.
للقيام بذلك ، نحتاج إلى القيام بأحد أمرين:
! [البابا فيتالينك الأول يعيد تعريف L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-7340ab7dba-dd1a6f-69ad2a.webp)
يمكن أن يكون الرابط الأرجواني في الرسم البياني إما رابط تجزئة أو عقد جسر يتحقق من إجماع Ethereum.
هل هذا يكفي؟ كما اتضح ، لم يكن ذلك كافيا ، لأن هناك بعض الحالات الخاصة الصغيرة:
ماذا يحدث إذا تعرضت Ethereum للهجوم بنسبة 51٪؟ ** كيف تتعامل مع ترقية شوكة Ethereum الصلبة؟ ** كيف تتعامل مع ترقية الهارد فورك للسلسلة العليا؟**
سيكون لهجوم Ethereum بنسبة 51٪ عواقب مماثلة لهجوم السلسلة العليا بنسبة 51٪ ، ولكن في الاتجاه المعاكس. قد تؤدي عملية الانقسام الصلب ل Ethereum إلى جعل جسر Ethereum داخل السلسلة العليا غير صالح. الحل الأنظف لهذه المشكلة هو الوعد بأنه إذا تراجعت Ethereum عن كتلة نهائية ، فإن السلسلة العليا ستتراجع أيضا ، وإذا قامت Ethereum بعمل شوكة صلبة ، فستقوم السلسلة العليا أيضا بعمل شوكة صلبة. قد لا يحتاج مثل هذا الوعد أبدا إلى تنفيذه فعليا: يمكنك تنشيط آلية حوكمة على السلسلة العليا وإذا رأت دليلا على هجوم محتمل أو هارد فورك ، ولا تقوم بعمل هارد فورك على السلسلة العليا إلا إذا فشلت آلية الحوكمة.
الإجابة الوحيدة القابلة للتطبيق على السؤال (3) هي أن وجود شكل من أشكال آلية الحوكمة على Ethereum سيجعل عقد الجسر على Ethereum على دراية بترقية الهارد فورك للسلسلة العليا.
ملخص: جسر التحقق ثنائي الاتجاه يكفي تقريبا لجعل السلسلة صالحة. المشكلة الرئيسية المتبقية هي أن السلسلة الأخرى ستقدم التزاما اجتماعيا بالانقسام الصلب عندما يحدث شيء ما ل Ethereum يتسبب في عدم عمل الجسر.
خاتمة
هناك بعدان رئيسيان ل "الاتصال ب Ethereum":
** أمن عمليات السحب إلى Ethereum ** ** أمن قراءة بيانات Ethereum **
كلا البعدين مهمان ولهما اعتبارات مختلفة. في كلتا الحالتين ، يوجد نسب:
! [البابا فيتالينك الأول يعيد تعريف L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-be23ca98bb-dd1a6f-69ad2a.webp)
لاحظ أن كل بعد يتم قياسه بطريقتين مختلفتين (إذن هناك بالفعل أربعة أبعاد؟). ): يمكن قياس أمان الاستخراج من خلال (i) مستوى الأمان و (ii) النسبة المئوية للمستخدمين أو حالات الاستخدام التي تستفيد من أعلى مستوى من الأمان ، بينما يمكن قياس أمان القراءة من خلال (i) قدرة الرابط على قراءة كتل Ethereum بسرعة ، وتحديدا الفرق بين الكتلة التي تم الانتهاء منها وأي كتلة ، و (ii) قوة الالتزام الاجتماعي للرابط عند التعامل مع حالات الحافة مثل هجمات 51٪ و hard forks.
هناك العديد من المشاريع التي لها قيمة في مساحة التصميم هذه. بالنسبة لبعض التطبيقات ، يعد الأمان العالي والاتصال المحكم مهمين. بالنسبة للتطبيقات الأخرى ، يكون بعض الاتصال الأكثر مرونة مقبولا لقابلية تطوير أعلى. في كثير من الحالات ، قد يكون من الأفضل البدء ببعض الأساليب الأكثر تساهلا اليوم والانتقال تدريجيا إلى اتصالات أكثر إحكاما خلال العقد المقبل مع تحسن التكنولوجيا.