ريستون: إنها ليست بلازما بل متغير أوبتيميوم

المؤلف: فاوست ، المهوس web3 ***

في الآونة الأخيرة ، أصبح مشروع يسمى Redstone موضوعا ساخنا. ** تم إصدار منشأة Layer2 هذه التي أطلقها فريق Lattice رسميا في 15 نوفمبر وتم إطلاقها الآن على شبكة الاختبار. ومن المثير للاهتمام ، يدعي فريق Lattice أن "Redstone عبارة عن سلسلة Alt-DA مستوحاة من البلازما".

قبل يوم واحد فقط من إصدار Redstone ، نشر Vitalik مقالة "ألعاب الخروج من صلاحية EVM: عودة البلازما" ، حيث استعرض بإيجاز الحل التقني "Plasma" الذي اختفى من نظام Ethereum البيئي ، وأشار إلى أنه يمكن تقديم إثباتات الصلاحية (الخلط بينها وبين ZK Proof) لحل مشكلة البلازما.

في هذا الصدد ، يعتقد العديد من الأصدقاء أن فيتاليك نشر هذا المقال من أجل منح Redstone منصة ، وحتى في مجتمع Web3 المهوس ، يقول بعض الناس أن Vitalik لم يستثمر في Redstone. إلى جانب غليان "نزاع تعريف طبقة Ethereum 2" في الشائعات السابقة ، كان يعتقد على نطاق واسع أن "إحياء البلازما" التالي سيتم تشغيله ، وقد يتم قمع حلول DA خارج النظام البيئي Ethereum مثل Celestia ، لأن البلازما ليس لديها متطلبات صارمة ل DA. **

ومع ذلك ، وفقا لبحث مؤلف هذا المقال ، فإن Redstone لا يتناسب مع الإطار العام لمحلول البلازما ، وادعائه بأنه "مستوحى من البلازما" لديه إمكانية فرك حرارة مقال Vitalik ، بدلا من أن Vitalik يريد حقا الوقوف لصالح Redstone. بالإضافة إلى ذلك ، يشبه تحدي Redstone DA مشروع Layer 2 Metis الذي تم إطلاقه في أبريل 2022 ، باستثناء أن ترتيب تحديث Stateroot ونشر بيانات DA مختلف.

لذا ، فإن الوضع الحقيقي هو أنك ربما تكون قد "أفرطت في تفسير" ريدستون. فيما يلي سبب بسيط لشرح كيفية عمل البلازما ، ولماذا ليست صديقة للعقود الذكية و Defi ، وما هو Redstone بالضبط. **

****البلازما: سحب عاجل في حالة هجوم حجب البيانات ****

يمكن إرجاع تاريخ البلازما إلى طفرة Ethereum IC0 في عام 2017 ، عندما انفجر الطلب على المعاملات لمستخدمي Ethereum وطغى ETH مع TPS المنخفض. في هذا المنعطف ، تم إصدار أقدم نسخة نظرية من البلازما ، والتي اقترحت مخطط تحجيم الطبقة 2 الذي يمكنه التعامل مع "جميع السيناريوهات المالية تقريبا في العالم".

ببساطة ، البلازما هو حل تحجيم ينشر فقط رأس كتلة الطبقة 2 / جذر Merkle إلى الطبقة 1 ، ويتم نشر جزء البيانات خارج رأس الكتلة / جذر Merkle (بيانات DA) خارج السلسلة فقط. ** إذا كان Merkle Root المنشور بواسطة جهاز تسلسل / مشغل البلازما على L1 مرتبطا بمعاملة غير صالحة (على سبيل المثال ، خطأ في التوقيع الرقمي) ، فيمكن للمستخدم تقديم شهادة احتيال لإثبات أن الجذر المقدم من جهاز التسلسل مرتبط بمعاملة غير صالحة.

تكمن المشكلة في أنه من أجل إصدار أدلة على الاحتيال ، من الضروري التأكد من عدم حجب بيانات DA ، لكن البلازما ليس لديها متطلبات صارمة لطبقة DA ولا يمكنها ضمان أن المستخدمين أو عقد L2 يمكنهم تلقي البيانات. إذا أطلق جهاز التسلسل هجوم حجب البيانات (المعروف أيضا باسم مشكلة توفر البيانات) في وقت معين ، ونشر فقط رأس كتلة جديد / جذر Merkle ، لكنه لم ينشر نص الكتلة المقابل ، مما يجعل من المستحيل التحقق مما إذا كان رأس / جذر الكتلة صالحا ، يمكن للمستخدم فقط الافتراضي لجهاز التسلسل على أنه "ميؤوس منه" وسحب الأصول من الطبقة 2 إلى الطبقة 1 من خلال آلية خروج الطوارئ تسمى "لعبة الخروج".

تتطلب هذه الخطوة من المستخدم تقديم إثبات Merkle لإثبات أن لديه كمية مقابلة من الأصول على L2 ، والتي يمكن أن نسميها "إثبات الأصول". ومن المثير للاهتمام ، أن لعبة خروج البلازما ليست هي نفسها وضع Escape Pod الخاص ب ZK Rollup ، حيث يجب على مستخدمي ZK Rollup تقديم دليل Merkle يتوافق مع أحدث Stateroot صالح ، بينما يمكن لمستخدمي البلازما إرسال إثبات يتوافق مع Merkle Root منذ وقت طويل.

لماذا تم تصميمه بهذه الطريقة؟ كل ما في الأمر أن Stateroot المقدم من ZK Rollup سيتم وضعه على الفور في الحكم من خلال العقد على الطبقة 1 (لتحديد ما إذا كان إثبات الصلاحية صالحا). إذا كان Stateroot المقدم حديثا صالحا وشرعيا ، فيجب على المستخدم تقديم دليل Merkle المقابل ل Stateroot الصالح كدليل على الأصول.

ومع ذلك ، فإن Merkle Root المقدم من جهاز تسلسل البلازما ، لا يمكن لعقد Layer1 الحكم على ما إذا كان صالحا أم لا ، ويمكنه فقط السماح لعقدة L2 بأخذ زمام المبادرة للتحدي لاستبعاد الجذر غير الصالح ، لذلك ستكون هناك آلية تحدي ، مما يجعل تشغيل Plasma و Zk Rollup مختلفا تماما. **

لنفترض أن جهاز التسلسل قد أصدر للتو Merkle Root 101 غير صالح وأطلق هجوم حجب البيانات ، بحيث لا تستطيع عقدة L2 إثبات أن الجذر 101 غير صالح ، ثم يمكن للمستخدم إرسال دليل merkle المقابل لجذر 100 أو جذر سابق وسحب أصوله.

بالطبع ، هناك مشكلة تحتاج إلى حل هنا ، أي أنه يجوز للمستخدم إرسال شهادة أصل تتوافق مع الجذر 30 أو ما قبله ، وطلب سحب الأصل إلى الطبقة 1 ، ولكن قد تتغير حالة الأصل لهذا الشخص بعد إصدار الجذر 30. بمعنى آخر ، يقدم إثباتا قديما للأصول ، وهو هجوم نموذجي مزدوج الإنفاق / الإنفاق المزدوج. **

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

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

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

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

** لكن البلازما لا تزال تعاني من خطأ فادح **: طالما أن جهاز التسلسل يبدأ في حجب البيانات ، يتعين على الأشخاص الاعتماد على عمليات السحب الطارئة (المعروفة أيضا باسم لعبة الخروج) لضمان سلامة الأصول ، وإذا انسحب عدد كبير من المستخدمين بشكل جماعي في فترة زمنية قصيرة ، فمن السهل التعامل مع الطبقة 1 ؛

لنفترض أن شخصا ما أعاد شحن 100 ETH إلى تجمع LP الخاص ب DEX ، ثم فشل جهاز تسلسل البلازما أو فعل الشر ، ويحتاج الناس إلى الانسحاب بشكل عاجل ، في هذا الوقت ، لا يزال 100 ETH الخاص بالمستخدم خاضعا لعقد DEX ، من يجب أن يذكر هذه الأصول للطبقة 1 في هذا الوقت؟

أفضل طريقة للقيام بذلك هي السماح للمستخدمين باسترداد أصولهم من تجمع DEX أولا ، ثم السماح للمستخدمين بسحب أموالهم إلى L1 بأنفسهم ، ولكن المشكلة هي أن جهاز تسلسل البلازما معطل / قابل للتلف ، ولا يمكن للمستخدمين استرداد أصولهم. ولكن ألن يكون الأمر فظيعا إذا سمحنا لمالك عقد DEX بإحضار الأصول التي يسيطر عليها العقد إلى L1 ، والتي من الواضح أنها أعطت مالك العقد ملكية الأصول ، ويمكنه رفع هذه الأصول إلى L1 في أي وقت والهروب؟

لذا في النهاية ، فإن كيفية التعامل مع هذه "الممتلكات العامة" التي تدعمها عقود Defi هي رعد كبير. ** إذا اتبعت الإجماع الاجتماعي ، يبدو أنه لا بأس من إعادة بناء عقد مرآة على الطبقة 1 يعكس عقد defi على الطبقة 2 ، لكن هذا سيؤدي إلى مشكلة كبيرة ، ويزيد من تكلفة الفرصة البديلة ، ومن سيصوت على التخلص من عقد المرآة سيكون أيضا مشكلة كبيرة. هذا ينطوي في الواقع على مشكلة توزيع السلطة العامة ، والتي تحدث عنها Xiangma سابقا في مقابلة ** "من الصعب على السلاسل العامة عالية الأداء القيام بأشياء جديدة ، والعقود الذكية تنطوي على توزيع الطاقة **.

بالطبع ، يشير فيتاليك أيضا إلى ذلك في مقالته الأخيرة "ألعاب الخروج من صلاحية EVM: عودة البلازما" ، ويسلط الضوء على هذا كأحد العوامل التي تجعل البلازما غير صديقة للعقود الذكية. ** في الماضي ، استخدمت متغيرات البلازما المعروفة مثل Plasma MVP و Plasma Cash UTXO أو نماذج مماثلة لتحل محل نموذج عنوان حساب Ethereum ، ولم تدعم العقود الذكية ، والتي يمكن أن تتجنب مشكلة "توزيع ملكية الأصول" المذكورة أعلاه ، على الرغم من أن ملكية كل UTXO تنتمي إلى المستخدم ، إلا أن UTXO نفسها بها العديد من العيوب وليست صديقة للعقود الذكية. لذلك ، فإن حل البلازما هو الأنسب للدفع البسيط أو تبادل دفتر الطلبات.

في وقت لاحق ، مع شعبية ZK Rollup ، انسحبت البلازما نفسها أيضا من مرحلة التاريخ ، لأن Rollup لم يكن لديها مشكلة الاحتفاظ ببيانات البلازما. إذا أطلق جهاز التسلسل الخاص ب ZK Rollup هجوما لحجب البيانات وأرسل Stateroot فقط إلى سلسلة ETH بدون بيانات DA ، الحكم على هذا الجذر بأنه غير صالح ورفضه بموجب عقد Verifier على L1. لذلك ، يجب أن تكون بيانات DA المقابلة لجذر الحالة القانوني ل ZK Rollup متاحة على سلسلة ETH. بهذه الطريقة ، لا يوجد "نشر رأس الكتلة أو جذر merkle فقط ، ولكن ليس نص الكتلة المقابل" ، أي أنه يمكن حل مشكلة توفر البيانات / هجوم حجب البيانات. **

في الوقت نفسه ، تتوفر بيانات DA السابقة ل Rollups على Ethereum ، ويمكن لأي شخص بدء عقد الطبقة 2 من خلال تاريخ سلسلة ETH ، مما يقلل بشكل كبير من صعوبة مخططات التسلسل اللامركزية أو حتى بدون إذن. في المقابل ، لا تحتوي البلازما على متطلبات صارمة ل DA ، ومن الصعب تنفيذ جهاز تسلسل لامركزي (لتنفيذ جهاز تسلسل لامركزي قابل للاستبدال ، يجب عليك أولا التأكد من أن جميع عقد L2 تتعرف على نفس الكتلة ، مما يطرح متطلبات لتنفيذ DA).

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

في نهاية اليوم ، يحتوي جهاز تسلسل ZK Rollup على مساحة عمل أصغر بكثير من البلازما - يمكنه في أحسن الأحوال إيقاف تحديثات Stateroot ، أو أن يكون مكافئا للتوقف على مستوى UX ، أو رفض طلبات مستخدم معينة ، والمعروفة بالعامية باسم الرقابة على المعاملات. في الوقت نفسه ، إذا فشل جهاز التسلسل في مخطط Rollup ، فسيكون من الأسهل على العقد الأخرى استبداله. ** من الناحية المثالية ، يمكن تقليل احتمالية تشغيل وضع لعبة الخروج في البلازما إلى 0 (تسمى جراب الهروب في ZK Rollup).

(يوضح عمود فشل مقدم العرض في L2BEAT كيف يمكن لكل حل L2 التعامل مع حالات فشل جهاز التسلسل ، وغالبا ما يشير الوضع الذاتي إلى العقد الأخرى التي يمكن أن تحل محل جهاز التسلسل المعطل حاليا) **

اليوم ، لا توجد فرق تقريبا في نظام Ethereum البيئي لا تزال متمسكة بمسار البلازما ، وجميع مشاريع البلازما تقريبا ولدت ميتة.

(يشرح فيتاليك سبب تفوق ZK Rollup على البلازما ، مع ذكر عملية التسلسل بدون إذن ومشكلات DA)

ما هو ريدستون: إنها ليست بلازما ، إنها نوع مختلف من Optimium ****

شرحنا أعلاه بإيجاز البلازما وأسباب استبدالها ب Rollup ، وبالنسبة ل Redstone ، يجب أن تكون قد رأيت أيضا الفرق بينها وبين البلازما: يمكن ل Redstone حل مشكلة هجمات الاحتفاظ بالبيانات ، ** على سبيل المثال ، لن تصدر على الفور جذر حالة جديد ، ولكنها تنشر أولا بيانات DA الأصلية خارج السلسلة ، ثم تنشر تجزئة البيانات لبيانات DA على سلسلة ETH كالتزام بيانات اعتماد مرتبط ، قائلة إنها نشرت البيانات الكاملة المقابلة ل datahash خارج السلسلة.

(تفسير ريدستون الرسمي لخطتها الخاصة لمنع هجمات حجب البيانات) **

يمكن لأي شخص أن يتحدى جهاز التسلسل الخاص ب Redstone ليقول إنه لا ينشر البيانات الأولية لتجزئة البيانات هذه خارج السلسلة. في هذه المرحلة ، يحتاج جهاز التسلسل إلى نشر البيانات المقابلة لتجزئة البيانات على السلسلة لمواجهة تحدي السائل. ** إذا لم ينشر جهاز التسلسل بيانات عن سلسلة ETH في الوقت المناسب بعد الطعن فيه ، اعتبار datahash / الالتزام المنشور مسبقا غير صالح.

إذا استجاب جهاز التسلسل لطلب المستأنف في الوقت المناسب ، فيمكن للمنافس الحصول على بيانات DA الأصلية المقابلة لتجزئة البيانات في الوقت المناسب. في النهاية ، يمكن لجميع عقد L2 الحصول على بيانات DA المطلوبة لحل مشكلة هجمات الاحتفاظ بالبيانات. بالطبع ، يحتاج المنافس نفسه إلى دفع رسوم تساوي تقريبا تكلفة جهاز التسلسل الذي ينشر بيانات DA الخام على سلسلة ETH ، من أجل منع المنافسين الضارين من تحدي جهاز التسلسل دون أي تكلفة والتسبب في تكبد الأخير خسائر.

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

نظرا لأن Redstone ينشر بيانات DA أولا ، ثم ينشر Stateroot الصالح المقابل ، فإنه يحل بشكل مباشر مشكلة هجمات حجب البيانات (ينشر جهاز التسلسل الجذر فقط وليس بيانات DA).

من الواضح أن هذا النموذج يختلف عن Optimium العادي (OP Rollup of DA بدون Ethereum ، مثل Arbitrum Nova) ، يعتمد Optimium بشكل عام على لجان DAC خارج السلسلة لضمان توفر البيانات ، ويقدم DAC txn متعدد Sig إلى السلسلة من حين لآخر ، وسيتم تعيين عقد Rollup على الطبقة 1 افتراضيا إلى جهاز التسلسل الذي أصدر أحدث دفعة من بيانات DA خارج السلسلة بعد تلقي multi-Sig txn.

(图源:L2beat)

في حين أن Metis و Arbitrum Nova يقدمان Stateroot و datahash في نفس الوقت ، إذا اعتقد شخص ما أن جهاز التسلسل يحجب بيانات DA ، فسيحاول إطلاق تحد ، وسيرسل جهاز التسلسل بيانات DA المقابلة لتجزئة البيانات إلى السلسلة.

لذلك ، فإن الاختلاف الرئيسي بين Redstone و Metis هو: الأول ينشر datahash أولا وينتظر نهاية فترة تحدي DA قبل إصدار stateroot ، بينما ينشر Metis كلا من stateroot و datahash ، وإذا بدأ شخص ما تحديا ، يتم تحميل بيانات DA إلى السلسلة. ** من الواضح أن حل Redstone أكثر أمانا ** ، لأنه بموجب مخطط Metis ، إذا لم يستجب جهاز التسلسل لطلب المنافس للحصول على بيانات DA ، فلا يمكن حل مشكلة هجوم حجب البيانات بسرعة ، والطريقة الوحيدة للاعتماد على عمليات السحب الطارئة والإجماع الاجتماعي هي السماح للعقد الأخرى بتولي جهاز التسلسل الحالي ؛

ومع ذلك ، في حالة Redstone ، إذا شارك جهاز التسلسل في حجب البيانات ، فإن جذر الحالة الذي تم إصداره يعتبر غير صالح بشكل مباشر ، وبالتالي فإن بيانات stateroot و DA مرتبطة ، مما يسمح ل Redstone بالحصول على ضمانات DA الأقرب إلى Rollup ، وهو في الأساس متغير Optimium متفوق من Arbitrum Nova و Metis.

شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
  • أعجبني
  • تعليق
  • إعادة النشر
  • مشاركة
تعليق
0/400
لا توجد تعليقات
  • تثبيت