توسع النظام البيئي بسرعة خلال العام الماضي. يتقدم النظام البيئي التراكمي ZK-EVM ، الذي يمثله تقليديا StarkNet و Arbitrum و Optimism و Scroll ، بسرعة ، مما يحسن أمانه ، وتوفر صفحة L2beat ملخصا جيدا لحالة كل مشروع.
بالإضافة إلى ذلك ، نرى فرقا تبني سلاسل جانبية وتراكمات (على سبيل المثال ، Polygon) ، وبعض مشاريع L1 تحاول التحرك نحو التحقق من الصحة (على سبيل المثال ، Celo) ، ومحاولات جديدة تماما (على سبيل المثال ، Linea ، Zeth ...). ）。
واحدة من النتائج الحتمية لهذا هو أننا نرى مشاريع L2 تميل إلى أن تكون أكثر تجانسا (أي "isomerized"). في التشفير ، يشير "عدم التجانس" إلى التعايش أو الاختلاط بين أنواع مختلفة من الأشياء أو ذات الطبيعة المختلفة. غالبا ما يستخدم هذا المصطلح لوصف سلاسل الكتل أو البروتوكولات أو التقنيات أو الأصول المختلفة التي لها خصائص أو قواعد أو سمات مختلفة). أتوقع أن يستمر هذا الاتجاه للأسباب التالية:
في الوقت الحالي ، يتطلع عدد من مشاريع L1 المستقلة إلى الانخراط بشكل أوثق مع نظام Ethereum البيئي وربما التحول إلى مشاريع L2. قد ترغب هذه المشاريع في اتباع نهج مرحلي للانتقال. سيؤدي إجراء انتقال شامل فوري إلى تقليل قابلية الاستخدام لأن التكنولوجيا ليست جاهزة لوضع كل شيء في سيناريو تراكمي. وفي المرحلة الانتقالية الشاملة اللاحقة، قد يكون الأوان قد فات للتضحية بالزخم وجعل الأمور منطقية من الناحية العملية.
ترغب بعض المشاريع المركزية في توفير المزيد من الأمان لمستخدميها وتستكشف السبل القائمة على blockchain. في كثير من الحالات ، ربما تكون هذه المشاريع قد نظرت في "سلاسل بلوكشين الكونسورتيوم المصرح بها" في الماضي. في الواقع ، قد يحتاجون فقط إلى الوصول إلى مستوى "شبه المركزية". بالإضافة إلى ذلك ، عادة ما يكون لديهم إنتاجية عالية جدا ، مما يجعلها غير مناسبة لمخططات التجميع ، على الأقل على المدى القصير.
تريد التطبيقات غير المالية ، مثل الألعاب أو وسائل التواصل الاجتماعي ، أن تكون لامركزية ، ولكنها تحتاج فقط إلى مستوى معين من الأمان.
في حالة وسائل التواصل الاجتماعي ، هناك بالفعل أجزاء مختلفة من التطبيق يتم التعامل معها بطرق مختلفة: يجب أن تتم الأنشطة النادرة وعالية القيمة مثل تسجيل اسم المستخدم واسترداد الحساب في مخطط تراكمي ، لكن الأنشطة المتكررة والمنخفضة القيمة مثل المنشورات واستطلاعات الرأي تتطلب أمانا أقل ، وهو سعر مقبول يجب دفعه إذا فشل blockchain وتسبب في اختفاء مشاركاتك ؛ ولكن إذا تسبب فشل blockchain في فقدان حسابك ، فهذه مشكلة أكبر.
موضوع مهم هو أنه في حين أن التطبيقات والمستخدمين الموجودين حاليا على Ethereum L1 على استعداد لدفع رسوم تراكمية أصغر ولكنها لا تزال مرئية على المدى القصير ، فإن المستخدمين من العالم غير blockchain أقل استعدادا للقيام بذلك: إذا كنت قد دفعت سابقا 1 دولار ، فإن دفع 0.10 دولار أكثر قبولا ، وإذا كنت قد دفعت سابقا 0 دولار ، فمن الصعب قبوله.
ينطبق هذا على التطبيقات التي لا تزال مركزية اليوم ، بالإضافة إلى مشاريع L1 الأصغر التي غالبا ما يكون لها رسوم منخفضة للغاية عندما تكون قاعدة مستخدميها صغيرة.
السؤال الطبيعي هو: أي من هذه المقايضات المعقدة بين مخططات التجميع والصلاحية والأنظمة الأخرى معقولة لتطبيق معين؟
التراكمات مقابل الصلاحية مقابل قطع الاتصال
يمكن وصف البعد الأول للأمان وقابلية التوسع الذي سنستكشفه على النحو التالي: إذا كنت تمتلك أصلا تم إصداره على L1 ، فقم بإيداعه في L2 ثم قم بتحويله إليك ، فما مقدار الضمان الذي لديك أنه يمكنك إعادة الأصل إلى L1؟
هناك أيضا سؤال ذو صلة: ما هو خيار التكنولوجيا الذي يؤدي إلى هذا المستوى من الضمان ، وما هي المقايضات لهذا الاختيار التكنولوجي؟
يمكننا توضيح المشكلة برسم تخطيطي بسيط:
! [فيتاليك: حان الوقت لوقف المشاحنات ، لدي ما أقوله حول تعريف الطبقة 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/641c1134cde471478d058f6d0e2eaab1.jpg)
تجدر الإشارة إلى أن هذا سيناريو مبسط توجد فيه العديد من الخيارات الوسيطة. على سبيل المثال:
بين الإظهار والصلاحية: في validium ، يمكن لأي شخص إجراء دفعة على السلسلة لتغطية رسوم المعاملات ، وعند هذه النقطة سيضطر المشغل إلى تقديم بعض البيانات إلى السلسلة أو فقدان الإيداع.
بين البلازما والصلاحية: يوفر نظام البلازما ضمانات أمان تشبه التجميع مع توفر البيانات خارج السلسلة ، ولكنه يدعم فقط عددا محدودا من التطبيقات. يمكن للنظام توفير EVM كامل مع ضمانات على مستوى البلازما لأولئك الذين لا يستخدمون هذه التطبيقات الأكثر تعقيدا ، بالإضافة إلى ضمانات على مستوى الصلاحية لأولئك الذين يستخدمون هذه التطبيقات.
يمكن اعتبار هذه الخيارات الوسيطة بمثابة طيف بين الإظهار والصلاحية. ولكن ما الذي يحفز التطبيق على اختيار نقطة معينة على هذا الطيف ، بدلا من نقطة أبعد إلى اليسار أو اليمين؟ هنا ، هناك عاملان رئيسيان:
**1. تكلفة توافر البيانات الأصلية ل Ethereum ، والتي ستنخفض بمرور الوقت مع تطور التكنولوجيا. تقدم عملية الهارد فورك التالية ل Ethereum ، Dencun ، EIP-4844 (المعروف أيضا باسم "proto-danksharding") ، والذي يوفر ما يقرب من 32 كيلو بايت / ثانية من توافر البيانات على السلسلة.
ومن المتوقع أن يزداد توافر البيانات هذا تدريجيا خلال السنوات القليلة المقبلة مع طرح Danksharding الكامل، مع الهدف النهائي المتمثل في توفر البيانات حوالي 1.3 ميجابايت / ثانية. في الوقت نفسه ، ستسمح لنا التحسينات في ضغط البيانات بفعل المزيد بنفس كمية البيانات.
**2. احتياجات التطبيق الخاصة: ما مدى خطورة خسارة المستخدم من حيث التكاليف المرتفعة بالنسبة لمشكلة التطبيق؟ ** ستخسر التطبيقات المالية أكثر بسبب فشل التطبيق ؛ تتضمن الألعاب ووسائل التواصل الاجتماعي الكثير من نشاط المستخدم والأنشطة منخفضة القيمة نسبيا ، لذا فإن المقايضات الأمنية المختلفة منطقية بالنسبة لهم.
تبدو هذه المقايضة تقريبا كما يلي:
! [فيتاليك: حان الوقت لوقف المشاحنات ، لدي ما أقوله حول تعريف الطبقة 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/eb26cf8cf9fde9560ac2bdae8828a175.jpg)
نوع آخر جدير بالذكر هو التأكيدات المسبقة. التأكيد المسبق هو رسالة موقعة من قبل مجموعة من المشاركين في مجموعة تراكمية أو صلاحية تقول "لقد أثبتنا أن هذه المعاملات مضمنة في هذا الترتيب ، وأن جذر ما بعد الحالة هو هذا". قد يوقع هؤلاء المشاركون على تأكيد مسبق لا يتوافق مع الواقع ، ولكن إذا حدث ذلك ، تدمير ودائعهم.
وهذا مفيد للتطبيقات منخفضة القيمة، مثل مدفوعات المستهلكين، في حين أن التطبيقات عالية القيمة، مثل التحويلات المالية بملايين الدولارات، قد تنتظر تأكيدا "منتظما" مدعوما بسلامة أمن النظام.
يمكن اعتبار التأكيد المسبق مثالا آخر على النظام الهجين ، على غرار "هجين البلازما / الصلاحية" المذكور أعلاه ، ولكن هذه المرة بين مجموعة التحديثات (أو الصلاحية) بأمان كامل ولكن زمن انتقال مرتفع ونظام بمستوى أمان أقل ولكن زمن انتقال منخفض. ستحصل التطبيقات التي تتطلب زمن انتقال أقل على أمان أقل ، ولكن يمكن أن تتعايش في نفس النظام البيئي مثل تلك التي ترغب في تحمل زمن انتقال أعلى لتحقيق أقصى قدر من الأمان.
قراءة غير موثوقة للإيثريوم
شكل آخر من أشكال الاتصال أقل مراعاة ، ولكنه لا يزال مهما جدا ، يتعلق بقدرة النظام على قراءة Ethereum blockchain. على وجه التحديد ، يتضمن ذلك قدرة النظام على التراجع عند حدوث Ethereum. لفهم سبب قيمة ذلك ، ضع في اعتبارك السيناريو التالي:
! [فيتاليك: حان الوقت لوقف المشاحنات ، لدي ما أقوله حول تعريف الطبقة 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/4de6c8f1f9b77155639e6a286f4162a1.jpg)
لنفترض أن التراجع يحدث على بلوكشين إيثريوم، كما هو موضح في الرسم التخطيطي. قد يكون هذا انقطاعا مؤقتا في حقبة لم يتم فيها الانتهاء من blockchain بعد ؛ أو قد يكون ذلك بسبب وجود عدد كبير جدا من المدققين غير متصلين بالإنترنت ، مما يؤدي إلى فترات تسرب غير نشطة لا يمكن ل blockchain الانتهاء منها لفترة أطول من الوقت.
السيناريو الأسوأ الذي يمكن أن ينتج عن ذلك هو كما يلي: لنفترض أن الكتلة الأولى من السلسلة العلوية تقرأ بعض البيانات من الكتلة الموجودة في أقصى اليسار من سلسلة Ethereum. على سبيل المثال ، يقوم شخص ما بإيداع 100 ETH على Ethereum في السلسلة العليا. ثم تراجعت Ethereum ، لكن السلسلة العليا لم تفعل ذلك. نتيجة لذلك ، تتبع الكتل المستقبلية على السلسلة العليا بشكل صحيح الكتل الجديدة الصحيحة على Ethereum blockchain ، لكن المعاملة الخاطئة (أي إيداع 100 ETH) لا تزال موجودة في السلسلة العليا. قد تؤدي هذه الثغرة الأمنية إلى إصدار إضافي للعملات المعدنية ، مما يحول ETH المجسر على السلسلة العليا إلى احتياطيات جزئية.
هناك طريقتان لحل هذه المشكلة:
يمكن للسلسلة العليا قراءة الكتل التي تم الانتهاء منها بواسطة Ethereum فقط ، لذلك لا تحتاج أبدا إلى التراجع ؛
في حالة حدوث تراجع على Ethereum ، فقد يحدث تراجع أيضا في السلسلة العليا. كلاهما يمكن أن يمنع هذه المشكلة. الأول أسهل في التنفيذ ، ولكن إذا دخلت Ethereum فترة تسرب غير نشطة ، فقد يؤدي ذلك إلى فقدان الوظائف لفترة طويلة من الزمن. هذا الأخير أكثر صعوبة في التنفيذ ، لكنه يضمن أنه يحتوي دائما على أفضل الميزات.
لاحظ أن هناك بالفعل حالة خاصة للطريقة الأولى. إذا كان هناك هجوم بنسبة 51٪ على Ethereum ، مما أدى إلى ظهور كتلتين جديدتين غير متوافقتين في نفس الوقت ، ويبدو أن كلاهما قد تم الانتهاء منه ، فقد تختار السلسلة العليا الكتلة الخاطئة (أي الكتلة التي لا يدعمها الإجماع الاجتماعي ل Ethereum في النهاية) وتحتاج إلى التراجع للتبديل إلى الكتلة الصحيحة. يمكن القول ، ليس من الضروري كتابة التعليمات البرمجية مسبقا للتعامل مع هذا الموقف. يمكن التعامل مع هذا عن طريق عمل شوكة صلبة للسلسلة العلوية.
هناك سببان مهمان لقدرة blockchain على قراءة Ethereum دون ثقة:
أولا ، يمكن أن تقلل هذه الإمكانية من مشكلات الأمان التي ينطوي عليها ربط الرموز المميزة الصادرة على Ethereum (أو حلول الطبقة 2 الأخرى) بهذه السلسلة ؛
ثانيا، تتيح هذه الإمكانية لمحافظ تجريد الحسابات التي تستخدم بنية تخزين مفاتيح مشتركة للاحتفاظ بالأصول بشكل آمن على السلسلة.
على الرغم من الجدل ، فإن أهمية النهج الأول معترف بها على نطاق واسع. مرة أخرى ، الطريقة الثانية مهمة لأنها تعني أنه يمكنك الحصول على محفظة يمكنها بسهولة تغيير المفاتيح والاحتفاظ بالأصول على العديد من السلاسل المختلفة.
هل وجود جسر يجعل الصلاحية؟
لنفترض أن السلسلة العليا تم إطلاقها في البداية كسلسلة مستقلة ، ثم نشر شخص ما عقدا جسرا على Ethereum. عقد الجسر هو ببساطة عقد يقبل رؤوس الكتلة من السلسلة العليا ، ويتحقق من أن أي رؤوس كتلة مقدمة إليه مصحوبة بشهادة صالحة تثبت أن رأس الكتلة قد تم قبوله بإجماع السلسلة العليا ، ويضيف رأس الكتلة إلى القائمة.
يمكن للتطبيق إنشاء ميزات علاوة على ذلك ، مثل إيداع وسحب الرموز المميزة. بمجرد إنشاء مثل هذا الجسر ، هل يوفر أيا من ضمانات ضمان الأصول التي ذكرناها سابقا؟
! [فيتاليك: حان الوقت لوقف المشاحنات ، لدي ما أقوله حول تعريف الطبقة 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/f2e4d6973f59d0520636a41407c9a20a.jpg)
حتى الآن ، ليس بعد! هناك سببان لهذا:
نحن نتحقق من توقيع الكتلة ، لكننا لا نتحقق من صحة انتقال الحالة. لذلك ، إذا قمت بإيداع الأصول الصادرة على Ethereum في السلسلة العليا ، وأصبح مدقق السلسلة العليا غير أمين ، فيمكنه التوقيع على انتقال حالة غير صالح ، وبالتالي سرقة تلك الأصول ؛
السلسلة العليا لا تزال غير قابلة للقراءة Ethereum. نتيجة لذلك ، لا يمكنك إيداع أصول Ethereum الأصلية في السلسلة العليا إلا إذا كنت تعتمد على جسور أخرى (وربما غير آمنة) تابعة لجهات خارجية.
الآن ، دعنا نبني الجسر كجسر مدقق: فهو لا يتحقق من الإجماع فحسب ، بل يتحقق أيضا من صحة حالة أي كتلة جديدة محسوبة باستخدام براهين ZK-SNARK.
بمجرد اكتمال هذه الخطوة ، لن يتمكن المدققون في السلسلة العليا من سرقة أموالك. يمكنهم نشر كتلة تحتوي على بيانات غير قابلة للاستخدام ، مما يمنع الجميع من سحب الأموال ، لكن لا يمكنهم سرقة الأموال (ما لم يحاولوا الكشف عن البيانات التي تسمح للمستخدمين بسحب أموالهم من خلال المطالبة بفدية). هذا له نفس نموذج الأمان مثل الصلاحيات.
ومع ذلك ، ما زلنا لم نحل المشكلة الثانية: لا تستطيع السلسلة العليا قراءة بيانات Ethereum. من أجل تحقيق ذلك ، نحتاج إلى القيام بأحد أمرين:
ضع عقد جسر في السلسلة العليا التي تتحقق من صحة كتلة Ethereum النهائية ؛
قم بتضمين تجزئة لأحدث كتلة Ethereum في كل كتلة من السلسلة العليا ، واستخدم قواعد اختيار الشوكة لفرض رابط التجزئة. أي أن كتلة السلسلة العليا نفسها التي سيتم ربطها بكتلة Ethereum على سلسلة غير رئيسية هي سلسلة غير رئيسية. إذا كانت كتلة Ethereum المتصلة بسلسلة blockchain ذات السلسلة العليا في البداية على السلسلة الرئيسية ولكنها أصبحت لاحقا غير سلسلة رئيسية ، فيجب أن تصبح كتلة السلسلة العليا أيضا غير رئيسية.
! [فيتاليك: حان الوقت لوقف المشاحنات ، لدي ما أقوله حول تعريف الطبقة 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/5fa31bfce1306e3527691085ad238a99.jpg)
يمكن أن تكون هذه الروابط الأرجوانية روابط تجزئة أو عقود جسر تتحقق من إجماع Ethereum
هل هذا يكفي؟ في الواقع ، هذا لا يكفي ، لأن هناك بعض الحالات الصغيرة:
ماذا يحدث إذا تعرضت Ethereum لهجوم بنسبة 51٪؟
كيف تتعامل مع ترقية الهارد فورك ل Ethereum؟
كيف تتعامل مع ترقية الهارد فورك لسلسلتك؟
سيكون لهجوم بنسبة 51٪ على Ethereum عواقب مماثلة لهجوم بنسبة 51٪ على السلسلة العليا ، لكن العكس سيكون صحيحا. يمكن أن تؤدي عملية الانقسام الصلب ل Ethereum إلى إبطال جسر Ethereum داخل السلسلة العليا. الالتزام الاجتماعي ، أي إذا استعادت Ethereum كتلة نهائية ، استعادتها ، وإذا قامت Ethereum بعمل هارد فورك ، تشعبها ، هي أنظف طريقة لحل هذه المشكلة.
قد لا يحتاج مثل هذا الوعد في الواقع إلى إنفاذه فعليا: إذا وجدت هيئة الحوكمة في السلسلة العليا دليلا على هجوم محتمل أو هارد فورك ، فيمكنها تنشيط هيئة الحوكمة والانقسام الصلب فقط للسلسلة العليا إذا فشلت هيئة الحوكمة.
بالنسبة للسؤال الثالث ، فإن الإجابة الوحيدة القابلة للتطبيق هي أن يكون لديك شكل من أشكال الحوكمة على Ethereum من شأنه أن يجعل عقد الجسر على Ethereum على دراية بترقية الهارد فورك للسلسلة العليا.
ملخص: جسر التحقق ثنائي الاتجاه يكاد يكون كافيا لجعل blockchain صالحا. العنصر الرئيسي المتبقي هو الالتزام الاجتماعي بأنه إذا حدث شيء غير عادي ل Ethereum يتسبب في عدم عمل عقد الجسر بشكل صحيح ، فإن blockchain آخر سيقوم بعمل هارد فورك ردا على ذلك.
خاتمة
"التواصل مع Ethereum" له بعدان رئيسيان:
أمن عمليات السحب إلى Ethereum ؛
اقرأ أمان Ethereum.
كلاهما مهم جدا وله اعتبارات مختلفة. في كلتا الحالتين ، هناك سلسلة متصلة:
! [فيتاليك: حان الوقت لوقف المشاحنات ، لدي ما أقوله حول تعريف الطبقة 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/8c582e1b1fa730531869238da7787bbc.jpg)
لاحظ أن كل بعد يقاس بطريقتين مختلفتين (هناك في الواقع أربعة): يمكن قياس الأمن المستخرج من خلال (i) مستوى الأمان ، و (ii) عدد المستخدمين أو الاستخدام الذين يستفيدون من أعلى مستوى من الأمان ؛
يمكن قياس أمان القراءة من خلال (i) مدى سرعة الرابط في قراءة كتل Ethereum ، وعلى وجه الخصوص كيف تختلف الكتلة النهائية عن أي كتلة ، و (ii) مدى التزام الرابط عند التعامل مع حالات الحافة مثل هجمات 51٪ و hard forks.
هناك قيمة للمشروع في العديد من مجالات مساحة التصميم هذه. بالنسبة لبعض التطبيقات ، يعد المستوى العالي من الأمان والاتصال المحكم أمرا ضروريا. بالنسبة للتطبيقات الأخرى ، تكون الشروط الأكثر تساهلا مقبولة لمزيد من قابلية التوسع. في كثير من الحالات ، بدءا من الظروف الأكثر مرونة اليوم ، قد يكون الانتقال التدريجي إلى اقتران أكثر إحكاما خلال العقد المقبل هو الأمثل مع تحسن التكنولوجيا.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
فيتاليك: حان الوقت لوقف المشاحنات ، لدي ما أقوله حول تعريف الطبقة 2
العنوان الأصلي: "أنواع مختلفة من الطبقة 2s"
كلمات: فيتاليك بوتيرين
تجميع: بلوكبيتس
توسع النظام البيئي بسرعة خلال العام الماضي. يتقدم النظام البيئي التراكمي ZK-EVM ، الذي يمثله تقليديا StarkNet و Arbitrum و Optimism و Scroll ، بسرعة ، مما يحسن أمانه ، وتوفر صفحة L2beat ملخصا جيدا لحالة كل مشروع.
بالإضافة إلى ذلك ، نرى فرقا تبني سلاسل جانبية وتراكمات (على سبيل المثال ، Polygon) ، وبعض مشاريع L1 تحاول التحرك نحو التحقق من الصحة (على سبيل المثال ، Celo) ، ومحاولات جديدة تماما (على سبيل المثال ، Linea ، Zeth ...). ）。
واحدة من النتائج الحتمية لهذا هو أننا نرى مشاريع L2 تميل إلى أن تكون أكثر تجانسا (أي "isomerized"). في التشفير ، يشير "عدم التجانس" إلى التعايش أو الاختلاط بين أنواع مختلفة من الأشياء أو ذات الطبيعة المختلفة. غالبا ما يستخدم هذا المصطلح لوصف سلاسل الكتل أو البروتوكولات أو التقنيات أو الأصول المختلفة التي لها خصائص أو قواعد أو سمات مختلفة). أتوقع أن يستمر هذا الاتجاه للأسباب التالية:
في الوقت الحالي ، يتطلع عدد من مشاريع L1 المستقلة إلى الانخراط بشكل أوثق مع نظام Ethereum البيئي وربما التحول إلى مشاريع L2. قد ترغب هذه المشاريع في اتباع نهج مرحلي للانتقال. سيؤدي إجراء انتقال شامل فوري إلى تقليل قابلية الاستخدام لأن التكنولوجيا ليست جاهزة لوضع كل شيء في سيناريو تراكمي. وفي المرحلة الانتقالية الشاملة اللاحقة، قد يكون الأوان قد فات للتضحية بالزخم وجعل الأمور منطقية من الناحية العملية.
ترغب بعض المشاريع المركزية في توفير المزيد من الأمان لمستخدميها وتستكشف السبل القائمة على blockchain. في كثير من الحالات ، ربما تكون هذه المشاريع قد نظرت في "سلاسل بلوكشين الكونسورتيوم المصرح بها" في الماضي. في الواقع ، قد يحتاجون فقط إلى الوصول إلى مستوى "شبه المركزية". بالإضافة إلى ذلك ، عادة ما يكون لديهم إنتاجية عالية جدا ، مما يجعلها غير مناسبة لمخططات التجميع ، على الأقل على المدى القصير.
تريد التطبيقات غير المالية ، مثل الألعاب أو وسائل التواصل الاجتماعي ، أن تكون لامركزية ، ولكنها تحتاج فقط إلى مستوى معين من الأمان.
في حالة وسائل التواصل الاجتماعي ، هناك بالفعل أجزاء مختلفة من التطبيق يتم التعامل معها بطرق مختلفة: يجب أن تتم الأنشطة النادرة وعالية القيمة مثل تسجيل اسم المستخدم واسترداد الحساب في مخطط تراكمي ، لكن الأنشطة المتكررة والمنخفضة القيمة مثل المنشورات واستطلاعات الرأي تتطلب أمانا أقل ، وهو سعر مقبول يجب دفعه إذا فشل blockchain وتسبب في اختفاء مشاركاتك ؛ ولكن إذا تسبب فشل blockchain في فقدان حسابك ، فهذه مشكلة أكبر.
موضوع مهم هو أنه في حين أن التطبيقات والمستخدمين الموجودين حاليا على Ethereum L1 على استعداد لدفع رسوم تراكمية أصغر ولكنها لا تزال مرئية على المدى القصير ، فإن المستخدمين من العالم غير blockchain أقل استعدادا للقيام بذلك: إذا كنت قد دفعت سابقا 1 دولار ، فإن دفع 0.10 دولار أكثر قبولا ، وإذا كنت قد دفعت سابقا 0 دولار ، فمن الصعب قبوله.
ينطبق هذا على التطبيقات التي لا تزال مركزية اليوم ، بالإضافة إلى مشاريع L1 الأصغر التي غالبا ما يكون لها رسوم منخفضة للغاية عندما تكون قاعدة مستخدميها صغيرة.
السؤال الطبيعي هو: أي من هذه المقايضات المعقدة بين مخططات التجميع والصلاحية والأنظمة الأخرى معقولة لتطبيق معين؟
التراكمات مقابل الصلاحية مقابل قطع الاتصال
يمكن وصف البعد الأول للأمان وقابلية التوسع الذي سنستكشفه على النحو التالي: إذا كنت تمتلك أصلا تم إصداره على L1 ، فقم بإيداعه في L2 ثم قم بتحويله إليك ، فما مقدار الضمان الذي لديك أنه يمكنك إعادة الأصل إلى L1؟
هناك أيضا سؤال ذو صلة: ما هو خيار التكنولوجيا الذي يؤدي إلى هذا المستوى من الضمان ، وما هي المقايضات لهذا الاختيار التكنولوجي؟
يمكننا توضيح المشكلة برسم تخطيطي بسيط:
! [فيتاليك: حان الوقت لوقف المشاحنات ، لدي ما أقوله حول تعريف الطبقة 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/641c1134cde471478d058f6d0e2eaab1.jpg)
تجدر الإشارة إلى أن هذا سيناريو مبسط توجد فيه العديد من الخيارات الوسيطة. على سبيل المثال:
بين الإظهار والصلاحية: في validium ، يمكن لأي شخص إجراء دفعة على السلسلة لتغطية رسوم المعاملات ، وعند هذه النقطة سيضطر المشغل إلى تقديم بعض البيانات إلى السلسلة أو فقدان الإيداع.
بين البلازما والصلاحية: يوفر نظام البلازما ضمانات أمان تشبه التجميع مع توفر البيانات خارج السلسلة ، ولكنه يدعم فقط عددا محدودا من التطبيقات. يمكن للنظام توفير EVM كامل مع ضمانات على مستوى البلازما لأولئك الذين لا يستخدمون هذه التطبيقات الأكثر تعقيدا ، بالإضافة إلى ضمانات على مستوى الصلاحية لأولئك الذين يستخدمون هذه التطبيقات.
يمكن اعتبار هذه الخيارات الوسيطة بمثابة طيف بين الإظهار والصلاحية. ولكن ما الذي يحفز التطبيق على اختيار نقطة معينة على هذا الطيف ، بدلا من نقطة أبعد إلى اليسار أو اليمين؟ هنا ، هناك عاملان رئيسيان:
**1. تكلفة توافر البيانات الأصلية ل Ethereum ، والتي ستنخفض بمرور الوقت مع تطور التكنولوجيا. تقدم عملية الهارد فورك التالية ل Ethereum ، Dencun ، EIP-4844 (المعروف أيضا باسم "proto-danksharding") ، والذي يوفر ما يقرب من 32 كيلو بايت / ثانية من توافر البيانات على السلسلة.
ومن المتوقع أن يزداد توافر البيانات هذا تدريجيا خلال السنوات القليلة المقبلة مع طرح Danksharding الكامل، مع الهدف النهائي المتمثل في توفر البيانات حوالي 1.3 ميجابايت / ثانية. في الوقت نفسه ، ستسمح لنا التحسينات في ضغط البيانات بفعل المزيد بنفس كمية البيانات.
**2. احتياجات التطبيق الخاصة: ما مدى خطورة خسارة المستخدم من حيث التكاليف المرتفعة بالنسبة لمشكلة التطبيق؟ ** ستخسر التطبيقات المالية أكثر بسبب فشل التطبيق ؛ تتضمن الألعاب ووسائل التواصل الاجتماعي الكثير من نشاط المستخدم والأنشطة منخفضة القيمة نسبيا ، لذا فإن المقايضات الأمنية المختلفة منطقية بالنسبة لهم.
تبدو هذه المقايضة تقريبا كما يلي:
! [فيتاليك: حان الوقت لوقف المشاحنات ، لدي ما أقوله حول تعريف الطبقة 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/eb26cf8cf9fde9560ac2bdae8828a175.jpg)
نوع آخر جدير بالذكر هو التأكيدات المسبقة. التأكيد المسبق هو رسالة موقعة من قبل مجموعة من المشاركين في مجموعة تراكمية أو صلاحية تقول "لقد أثبتنا أن هذه المعاملات مضمنة في هذا الترتيب ، وأن جذر ما بعد الحالة هو هذا". قد يوقع هؤلاء المشاركون على تأكيد مسبق لا يتوافق مع الواقع ، ولكن إذا حدث ذلك ، تدمير ودائعهم.
وهذا مفيد للتطبيقات منخفضة القيمة، مثل مدفوعات المستهلكين، في حين أن التطبيقات عالية القيمة، مثل التحويلات المالية بملايين الدولارات، قد تنتظر تأكيدا "منتظما" مدعوما بسلامة أمن النظام.
يمكن اعتبار التأكيد المسبق مثالا آخر على النظام الهجين ، على غرار "هجين البلازما / الصلاحية" المذكور أعلاه ، ولكن هذه المرة بين مجموعة التحديثات (أو الصلاحية) بأمان كامل ولكن زمن انتقال مرتفع ونظام بمستوى أمان أقل ولكن زمن انتقال منخفض. ستحصل التطبيقات التي تتطلب زمن انتقال أقل على أمان أقل ، ولكن يمكن أن تتعايش في نفس النظام البيئي مثل تلك التي ترغب في تحمل زمن انتقال أعلى لتحقيق أقصى قدر من الأمان.
قراءة غير موثوقة للإيثريوم
شكل آخر من أشكال الاتصال أقل مراعاة ، ولكنه لا يزال مهما جدا ، يتعلق بقدرة النظام على قراءة Ethereum blockchain. على وجه التحديد ، يتضمن ذلك قدرة النظام على التراجع عند حدوث Ethereum. لفهم سبب قيمة ذلك ، ضع في اعتبارك السيناريو التالي:
! [فيتاليك: حان الوقت لوقف المشاحنات ، لدي ما أقوله حول تعريف الطبقة 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/4de6c8f1f9b77155639e6a286f4162a1.jpg)
لنفترض أن التراجع يحدث على بلوكشين إيثريوم، كما هو موضح في الرسم التخطيطي. قد يكون هذا انقطاعا مؤقتا في حقبة لم يتم فيها الانتهاء من blockchain بعد ؛ أو قد يكون ذلك بسبب وجود عدد كبير جدا من المدققين غير متصلين بالإنترنت ، مما يؤدي إلى فترات تسرب غير نشطة لا يمكن ل blockchain الانتهاء منها لفترة أطول من الوقت.
السيناريو الأسوأ الذي يمكن أن ينتج عن ذلك هو كما يلي: لنفترض أن الكتلة الأولى من السلسلة العلوية تقرأ بعض البيانات من الكتلة الموجودة في أقصى اليسار من سلسلة Ethereum. على سبيل المثال ، يقوم شخص ما بإيداع 100 ETH على Ethereum في السلسلة العليا. ثم تراجعت Ethereum ، لكن السلسلة العليا لم تفعل ذلك. نتيجة لذلك ، تتبع الكتل المستقبلية على السلسلة العليا بشكل صحيح الكتل الجديدة الصحيحة على Ethereum blockchain ، لكن المعاملة الخاطئة (أي إيداع 100 ETH) لا تزال موجودة في السلسلة العليا. قد تؤدي هذه الثغرة الأمنية إلى إصدار إضافي للعملات المعدنية ، مما يحول ETH المجسر على السلسلة العليا إلى احتياطيات جزئية.
هناك طريقتان لحل هذه المشكلة:
يمكن للسلسلة العليا قراءة الكتل التي تم الانتهاء منها بواسطة Ethereum فقط ، لذلك لا تحتاج أبدا إلى التراجع ؛
في حالة حدوث تراجع على Ethereum ، فقد يحدث تراجع أيضا في السلسلة العليا. كلاهما يمكن أن يمنع هذه المشكلة. الأول أسهل في التنفيذ ، ولكن إذا دخلت Ethereum فترة تسرب غير نشطة ، فقد يؤدي ذلك إلى فقدان الوظائف لفترة طويلة من الزمن. هذا الأخير أكثر صعوبة في التنفيذ ، لكنه يضمن أنه يحتوي دائما على أفضل الميزات.
لاحظ أن هناك بالفعل حالة خاصة للطريقة الأولى. إذا كان هناك هجوم بنسبة 51٪ على Ethereum ، مما أدى إلى ظهور كتلتين جديدتين غير متوافقتين في نفس الوقت ، ويبدو أن كلاهما قد تم الانتهاء منه ، فقد تختار السلسلة العليا الكتلة الخاطئة (أي الكتلة التي لا يدعمها الإجماع الاجتماعي ل Ethereum في النهاية) وتحتاج إلى التراجع للتبديل إلى الكتلة الصحيحة. يمكن القول ، ليس من الضروري كتابة التعليمات البرمجية مسبقا للتعامل مع هذا الموقف. يمكن التعامل مع هذا عن طريق عمل شوكة صلبة للسلسلة العلوية.
هناك سببان مهمان لقدرة blockchain على قراءة Ethereum دون ثقة:
أولا ، يمكن أن تقلل هذه الإمكانية من مشكلات الأمان التي ينطوي عليها ربط الرموز المميزة الصادرة على Ethereum (أو حلول الطبقة 2 الأخرى) بهذه السلسلة ؛
ثانيا، تتيح هذه الإمكانية لمحافظ تجريد الحسابات التي تستخدم بنية تخزين مفاتيح مشتركة للاحتفاظ بالأصول بشكل آمن على السلسلة.
على الرغم من الجدل ، فإن أهمية النهج الأول معترف بها على نطاق واسع. مرة أخرى ، الطريقة الثانية مهمة لأنها تعني أنه يمكنك الحصول على محفظة يمكنها بسهولة تغيير المفاتيح والاحتفاظ بالأصول على العديد من السلاسل المختلفة.
هل وجود جسر يجعل الصلاحية؟
لنفترض أن السلسلة العليا تم إطلاقها في البداية كسلسلة مستقلة ، ثم نشر شخص ما عقدا جسرا على Ethereum. عقد الجسر هو ببساطة عقد يقبل رؤوس الكتلة من السلسلة العليا ، ويتحقق من أن أي رؤوس كتلة مقدمة إليه مصحوبة بشهادة صالحة تثبت أن رأس الكتلة قد تم قبوله بإجماع السلسلة العليا ، ويضيف رأس الكتلة إلى القائمة.
يمكن للتطبيق إنشاء ميزات علاوة على ذلك ، مثل إيداع وسحب الرموز المميزة. بمجرد إنشاء مثل هذا الجسر ، هل يوفر أيا من ضمانات ضمان الأصول التي ذكرناها سابقا؟
! [فيتاليك: حان الوقت لوقف المشاحنات ، لدي ما أقوله حول تعريف الطبقة 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/f2e4d6973f59d0520636a41407c9a20a.jpg)
حتى الآن ، ليس بعد! هناك سببان لهذا:
نحن نتحقق من توقيع الكتلة ، لكننا لا نتحقق من صحة انتقال الحالة. لذلك ، إذا قمت بإيداع الأصول الصادرة على Ethereum في السلسلة العليا ، وأصبح مدقق السلسلة العليا غير أمين ، فيمكنه التوقيع على انتقال حالة غير صالح ، وبالتالي سرقة تلك الأصول ؛
السلسلة العليا لا تزال غير قابلة للقراءة Ethereum. نتيجة لذلك ، لا يمكنك إيداع أصول Ethereum الأصلية في السلسلة العليا إلا إذا كنت تعتمد على جسور أخرى (وربما غير آمنة) تابعة لجهات خارجية.
الآن ، دعنا نبني الجسر كجسر مدقق: فهو لا يتحقق من الإجماع فحسب ، بل يتحقق أيضا من صحة حالة أي كتلة جديدة محسوبة باستخدام براهين ZK-SNARK.
بمجرد اكتمال هذه الخطوة ، لن يتمكن المدققون في السلسلة العليا من سرقة أموالك. يمكنهم نشر كتلة تحتوي على بيانات غير قابلة للاستخدام ، مما يمنع الجميع من سحب الأموال ، لكن لا يمكنهم سرقة الأموال (ما لم يحاولوا الكشف عن البيانات التي تسمح للمستخدمين بسحب أموالهم من خلال المطالبة بفدية). هذا له نفس نموذج الأمان مثل الصلاحيات.
ومع ذلك ، ما زلنا لم نحل المشكلة الثانية: لا تستطيع السلسلة العليا قراءة بيانات Ethereum. من أجل تحقيق ذلك ، نحتاج إلى القيام بأحد أمرين:
ضع عقد جسر في السلسلة العليا التي تتحقق من صحة كتلة Ethereum النهائية ؛
قم بتضمين تجزئة لأحدث كتلة Ethereum في كل كتلة من السلسلة العليا ، واستخدم قواعد اختيار الشوكة لفرض رابط التجزئة. أي أن كتلة السلسلة العليا نفسها التي سيتم ربطها بكتلة Ethereum على سلسلة غير رئيسية هي سلسلة غير رئيسية. إذا كانت كتلة Ethereum المتصلة بسلسلة blockchain ذات السلسلة العليا في البداية على السلسلة الرئيسية ولكنها أصبحت لاحقا غير سلسلة رئيسية ، فيجب أن تصبح كتلة السلسلة العليا أيضا غير رئيسية.
! [فيتاليك: حان الوقت لوقف المشاحنات ، لدي ما أقوله حول تعريف الطبقة 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/5fa31bfce1306e3527691085ad238a99.jpg)
يمكن أن تكون هذه الروابط الأرجوانية روابط تجزئة أو عقود جسر تتحقق من إجماع Ethereum
هل هذا يكفي؟ في الواقع ، هذا لا يكفي ، لأن هناك بعض الحالات الصغيرة:
ماذا يحدث إذا تعرضت Ethereum لهجوم بنسبة 51٪؟
كيف تتعامل مع ترقية الهارد فورك ل Ethereum؟
كيف تتعامل مع ترقية الهارد فورك لسلسلتك؟
سيكون لهجوم بنسبة 51٪ على Ethereum عواقب مماثلة لهجوم بنسبة 51٪ على السلسلة العليا ، لكن العكس سيكون صحيحا. يمكن أن تؤدي عملية الانقسام الصلب ل Ethereum إلى إبطال جسر Ethereum داخل السلسلة العليا. الالتزام الاجتماعي ، أي إذا استعادت Ethereum كتلة نهائية ، استعادتها ، وإذا قامت Ethereum بعمل هارد فورك ، تشعبها ، هي أنظف طريقة لحل هذه المشكلة.
قد لا يحتاج مثل هذا الوعد في الواقع إلى إنفاذه فعليا: إذا وجدت هيئة الحوكمة في السلسلة العليا دليلا على هجوم محتمل أو هارد فورك ، فيمكنها تنشيط هيئة الحوكمة والانقسام الصلب فقط للسلسلة العليا إذا فشلت هيئة الحوكمة.
بالنسبة للسؤال الثالث ، فإن الإجابة الوحيدة القابلة للتطبيق هي أن يكون لديك شكل من أشكال الحوكمة على Ethereum من شأنه أن يجعل عقد الجسر على Ethereum على دراية بترقية الهارد فورك للسلسلة العليا.
ملخص: جسر التحقق ثنائي الاتجاه يكاد يكون كافيا لجعل blockchain صالحا. العنصر الرئيسي المتبقي هو الالتزام الاجتماعي بأنه إذا حدث شيء غير عادي ل Ethereum يتسبب في عدم عمل عقد الجسر بشكل صحيح ، فإن blockchain آخر سيقوم بعمل هارد فورك ردا على ذلك.
خاتمة
"التواصل مع Ethereum" له بعدان رئيسيان:
أمن عمليات السحب إلى Ethereum ؛
اقرأ أمان Ethereum.
كلاهما مهم جدا وله اعتبارات مختلفة. في كلتا الحالتين ، هناك سلسلة متصلة:
! [فيتاليك: حان الوقت لوقف المشاحنات ، لدي ما أقوله حول تعريف الطبقة 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/8c582e1b1fa730531869238da7787bbc.jpg)
لاحظ أن كل بعد يقاس بطريقتين مختلفتين (هناك في الواقع أربعة): يمكن قياس الأمن المستخرج من خلال (i) مستوى الأمان ، و (ii) عدد المستخدمين أو الاستخدام الذين يستفيدون من أعلى مستوى من الأمان ؛
يمكن قياس أمان القراءة من خلال (i) مدى سرعة الرابط في قراءة كتل Ethereum ، وعلى وجه الخصوص كيف تختلف الكتلة النهائية عن أي كتلة ، و (ii) مدى التزام الرابط عند التعامل مع حالات الحافة مثل هجمات 51٪ و hard forks.
هناك قيمة للمشروع في العديد من مجالات مساحة التصميم هذه. بالنسبة لبعض التطبيقات ، يعد المستوى العالي من الأمان والاتصال المحكم أمرا ضروريا. بالنسبة للتطبيقات الأخرى ، تكون الشروط الأكثر تساهلا مقبولة لمزيد من قابلية التوسع. في كثير من الحالات ، بدءا من الظروف الأكثر مرونة اليوم ، قد يكون الانتقال التدريجي إلى اقتران أكثر إحكاما خلال العقد المقبل هو الأمثل مع تحسن التكنولوجيا.