ستناقش هذه المقالة طرق المراسلة عبر السلسلة L2 المختلفة من منظور التجميع ، مع التركيز على الاتصال عبر السلاسل بدون ثقة. سننظر بإيجاز في نهج قراءة الحالة المباشرة ، ونهج العميل الخفيف ، وإثبات التخزين. سنغطي أيضًا آلية تجميع الإثبات ، ونقل الرسائل عبر السلاسل الموثوق بها من طرف ثالث وحلول ZK عبر السلاسل الأساسية. أخيرًا ، دعنا نلقي نظرة على كيفية قيام L2s المختلفة بتنفيذ المراسلة عبر السلاسل اليوم.
** 1. مقدمة للمراسلة عبر السلاسل **
للتواصل عبر السلاسل ، يجب أن يكون لدى جميع الأطراف (L2 و L3 وما إلى ذلك) وصول مباشر إلى أحدث جذر حالة Ethereum.
تحتوي جميع طبقات الإيداع على آلية عبر سلسلة "مضمنة" يمكن استخدامها للوصول إلى جذر حالة L1 ، والتي سيتم تمريرها إلى L2 كرسالة إيداع.
** 1 ****. 1 ** ** نوعان من الوصول إلى جذر الحالة **
** النوع 1: قراءة جذر الحالة مباشرةً ** - يمكن إجراؤه عبر كود التشغيل أو المترجم مسبقًا. ومع ذلك ، لم يتم تنفيذه حتى الآن ، لذلك لا داعي لإثبات.
يصف Brecht Devos طريقة محتملة لقراءة الحالة مباشرةً في ورقة بحثية: "... يمكننا الكشف عن عقد مترجم مسبقًا يمكنه استدعاء عقد ذكي مباشرة في السلسلة المستهدفة. هذا مترجم مسبقًا مباشرةً في سلسلة المصدر يُدرج وينفذ رمز العقد الذكي لسلسلة أخرى . وهذا يضمن أن العقود الذكية لديها دائمًا إمكانية الوصول إلى أحدث حالة متاحة بطريقة فعالة ويمكن إثباتها بسهولة. "
· تم وصفه أيضًا في طلب تقديم العروض الخاص بالتفاؤل "عن بعد ثابت استدعاء إثبات المفهوم".
** النوع 2: Proof Generation ** - أي إثبات بيان حول blockchain واحد على blockchain آخر.
"المراسلة عبر السلاسل مع البراهين" لها طريقتان:
· اتصال عبر السلاسل غير موثوق به - أي عدم وجود أطراف ثالثة موثوق بها (على سبيل المثال ، استخدام عملاء خفيفين أو إثبات التخزين). يمكن استخدام النهج غير الموثوق به لتوليد البراهين من طرف ثالث وللمشاركين في الاتصالات عبر السلاسل لإنشاء البراهين بأنفسهم.
يتم مشاركة البراهين بين مجموعات مختلفة لضمان عمليات عبر السلسلة. هذا النهج ، الذي لم تتم مناقشته كثيرًا في هذه المقالة ، موجود حاليًا في مرحلة البحث والاستكشاف ولا يعتبر حلاً قابلاً للتطبيق على نطاق واسع.
** 1 ****. 2 ** ** طريقة "المراسلة عبر السلاسل مع الدليل" **
** 1.2.1 ** ** الرسائل عبر السلاسل الخفيفة للعميل **
إثبات البيانات الموجودة على السلسلة ب
الحصول على بيانات إثبات Merkle من العقدة الكاملة للسلسلة B (عقد أرشفة أرشيفية إذا كان إثبات التخزين لحالات تاريخية معينة مطلوبًا) ؛
إرسال رأس الكتلة وبيانات الإثبات المقابلة لكتلة السلسلة B التي تحتوي على الحالة التي نريد التحقق منها لعقد المُثبِت في السلسلة A كبيانات اتصال ؛
يحسب عقد المُثبِّت قيمة تجزئة الكتلة استنادًا إلى بيانات رأس الكتلة ، ويستفسر عن العقد الذكي للعميل الخفيف في السلسلة A (يتتبع قيمة تجزئة الكتلة للسلسلة B) ، ويتحقق مما إذا كانت قيمة التجزئة صالحة ؛
يتم التحقق من بيانات الإثبات مقابل جذر حالة بايت 32 في رأس الكتلة.
· إنشاء دليل على التخزين ← إنشاء دليل zk ← الاستخدام على السلسلة
من الممكن أيضًا للكيان تجميع مجموعات متعددة من البراهين في دليل واحد (كل من إثبات التخزين وإثبات zk). هذه خطوة تحسين اختيارية ولم تتم مناقشتها بعد.
دعنا نلقي نظرة على المراحل الرئيسية الثلاثة لإثبات "سير عمل" التخزين: إنشاء إثبات التخزين ، وإنشاء دليل zk ، واستخدامه في السلسلة.
** (1) إنشاء إثبات التخزين **
· إثبات التخزين يسمح لنا باستخدام التزام سري لإثبات وجود معلومات معينة على blockchain وأنها صحيحة ؛
كان إثبات التخزين جزءًا من مساحة التشفير منذ ظهور أشجار Merkle في عام 1979. ومع ذلك ، فإن براهين تخزين الفانيليا عادة ما تكون كبيرة جدًا. يكمن الابتكار الحديث في الجمع بين إثبات التخزين والحساب الذي يمكن إثباته لإنشاء أدلة موجزة يمكن التحقق منها على السلسلة.
** لإنشاء ** إثبات التخزين ، يجب توفير كتلة معينة من البيانات ومسار Merkle أو Verkle المرتبط بها في شجرة Merkle. يتكون المسار من تجزئات الأخوة اللازمة لإعادة بناء تجزئة الجذر باستخدام نفس خوارزمية التجزئة.
** للتحقق ** من إثبات التخزين ، يمكن للمستلم استخدام البيانات المقدمة ومسار Merkle أو Verkle لإعادة حساب تجزئة الجذر. إذا تطابق تجزئة الجذر المعاد حسابها مع تجزئة جذر معروفة ، يمكن للمستلم أن يكون واثقًا من أن البيانات أصلية وجزء من مجموعة البيانات المقدمة.
** (2) إنشاء ZKP (إثبات المعرفة الصفرية) **
ومع ذلك ، فإن إثبات التخزين من نوع Ethereum يبلغ حوالي 4 كيلوبايت - كبير إلى حد ما لنشر إثبات التخزين بالكامل على السلسلة المستهدفة ، حيث سيكون التحقق من الإثبات مكلفًا للغاية. لذلك ، من المعقول استخدام ZKP (على سبيل المثال ، ZK-SNARK) للضغط ، مما يجعل الدليل أصغر وأرخص للتحقق.
** （3） A **** لفة ** ** ZKP **
بعد كسب ZKPs ، يمكن للمستخدمين في السلسلة المستهدفة فتح البراهين المكتسبة (على سبيل المثال ، الوصول إلى الحالة التاريخية عبر رؤوس الكتلة أو تجزئة الكتلة).
يمكن أن يتم Unroll على النحو التالي:
** التراكم على السلسلة: ** يتم تنفيذ العملية الكاملة لإعادة بناء رؤوس الكتل من البراهين مباشرة على blockchain. العيوب: رسوم غاز عالية ، تستهلك موارد الحوسبة ؛ المزايا: لا يوجد وقت إثبات إضافي ، زمن انتقال منخفض ، لأنه لا توجد حاجة لإنشاء أدلة خارج blockchain.
** الضغط على السلسلة: ** أزل المعلومات الزائدة أو غير الضرورية من البيانات ، أو استخدم هياكل البيانات المحسّنة لتحقيق الكفاءة في استخدام المساحة. يتم إرسال البيانات المضغوطة إلى blockchain ويمكن فك ضغطها عند الحاجة. السلبيات: قد يعني ضغط البيانات وإلغاء ضغطها حسابًا إضافيًا ، ولكن قد يكون وقت الاستجابة هذا ضئيلًا. قد يكون لخوارزمية الضغط المستخدمة تأثير سلبي على أمان البيانات ؛ الميزة: تقليل تكاليف البيانات.
** التخزين خارج السلسلة: ** قم بتخزين البيانات خارج السلسلة ، ووضع كتل بيانات محددة على السلسلة عند الطلب. هذا مناسب للحلول التي تحتاج إلى تخزين كميات كبيرة من البيانات لسبب ما (مثل عقد أرشيف Ethereum من كتلة التكوين). السلبيات: مثل الضغط على السلسلة ؛ الإيجابيات: تقليل تكاليف البيانات بشكل أكبر.
** 1 ****. 2.3 ** ** جهة خارجية موثوقة **
يجب أن يشتمل الحل الكامل عبر السلاسل أيضًا على حلول المراسلة المتقاطعة مع أطراف ثالثة موثوق بها (مثل أوراكل ، والجسور المركزية ، وما إلى ذلك).
** 1 ****. 2.4 ** ** نظام إثبات "عالمي" **
في حالة وجود آلية منصة مشتركة لإثبات التجميع ، يمكن تسريع المراسلة عن طريق تلقي تجزئات الكتلة التي يتم تسويتها داخل منصة التجميع ، وستتعامل التسوية هنا أيضًا مع الرسائل (ولكن إذا كانت هناك مشكلة في منصة التجميع ما يجب القيام به؟).
** 1 ****. 2.5 بعض المشكلات غير المعروفة في رسائل ZK **** عبر السلاسل **
هل الرسائل عبر السلاسل ممكنة بدون طرف ثالث موثوق به (والذي يمكن أن يكون كيانًا واحدًا أو كيانات متعددة)؟ ما هي آلية فعالة لتمرير الرسائل عبر السلاسل؟ بشكل عام ، بالنسبة إلى Ethereum L2 (مع الوصول المباشر إلى تجزئة الكتلة من L1) و Ethereum نفسها ، إذا كان بإمكان سلسلة واحدة تشغيل عميل خفيف وما إلى ذلك ، وهو ما يكفي للرسائل عبر السلاسل غير الموثوقة.
هل دائرة ZK المستخدمة لتوليد الإثبات عبر السلاسل متدرجة بشكل صحيح؟ في بعض الحالات ، خاصةً عندما تكون طبقة الإجماع (التي تحتاج إلى التحقق من العمليات عبر السلسلة) كبيرة جدًا ، يمكن أن تكون الدائرة المستخدمة لتمرير الرسائل عبر سلسلة ZK أكبر من التخزين التراكمي والتخزين على السلسلة ، و الحمل الحسابي كبير جدًا أيضًا. كبير. من المفترض أنه يمكن التغلب على هذه المشكلة باتباع نهج أكثر مركزية.
** 2 **** 、 مثال على حل الرسائل عبر السلاسل **
تستخدم ** Su **** ccinct Labs ** عميلاً خفيفًا للتحقق من الإجماع من سلسلة المصدر إلى طبقة إجماع السلسلة المستهدفة. الفكرة هي وجود بروتوكول عميل خفيف للتأكد من أن العقد يمكنها مزامنة رؤوس الكتلة لحالة blockchain النهائية. يستخدم ZKP لتوليد براهين إجماع.
· تُنشئ ** La **** grange Labs ** دليل حالة غير تفاعلي عبر السلاسل. يثبت لاغرانج أن الشبكة مسؤولة عن إنشاء جذر الحالة. تحتوي كل عقدة لاغرانج على جزء من المفتاح الخاص لقطعة ما ، والذي يشهد على حالة سلسلة معينة. كل جذر حالة هو جذر Verkle موقعة على العتبة والتي يمكن استخدامها للدلالة على حالة سلسلة معينة في وقت معين. جذر الحالة عام تمامًا ويمكن استخدامه في إثبات الحالة لإثبات الحالة الحالية لأي عقد أو محفظة واحدة في السلسلة.
يستخدم ** He **** rodotus ** إثبات ZKP للتخزين لتوفير عقود ذكية والوصول إلى البيانات على سلسلة طبقات Ethereum الأخرى بشكل متزامن. للتحقق من الصحة ، يستخدم رسائل L1 <> L2 الأصلية لمزامنة تجزئة الكتلة بين مجموعات Ethereum.
** = لا شيء ؛ الأساس ** (Mina، L1) يسمح للعقود الذكية على Ethereum للتحقق من صحة حالة Mina. قم بإنشاء إثبات حالة لأغراض خاصة ، ورخيصة للتحقق من Ethereum (أدلة Mina المحلية على Ethereum باهظة الثمن). يمكن للتطبيقات الافتراضية (في وقت ما في المستقبل) أن تستخدم مباشرة أداة إنشاء دليل Mina للتحقق من صحة المعاملات عبر السلاسل. = لا شيء ؛ تمتلك المؤسسة أيضًا سوق إثبات حيث يمكن للمستخدمين / المشاريع شراء / بيع براهين SNARK التي تسمح بالوصول غير الموثوق به إلى البيانات.
** Axiom **: إذا قامت Axiom بإنشاء ZKP لدفتر الأستاذ حتى الآن - لا تحتاج إلى إنشاء ZKP لكتلة معينة - يمكنها تمرير ZKP هذا إلى السلسلة (كمحول) ، أو حتى توفير الوصول إلى هذا ZKP.
** 3. رسائل متقاطعة من المستوى 2 **
إخلاء المسؤولية: لا تزال المراسلة عبر السلاسل تتطور لمعظم L2. تستند جميع التحليلات أدناه إلى معلومات مفتوحة المصدر. ومع ذلك ، قد تكون الحلول المذكورة في المقالة في مرحلة الاستكشاف والاختبار ، وقد يتبنى التجميع في النهاية طرقًا أخرى. *
** （1） **** تايكو **
تخزن Taiko تجزئة الكتلة لكل سلسلة. لكل زوج من السلاسل ، ينشر عقدين ذكيين يخزن كل منهما تجزئات الآخر. في مثال L2 ← → L1 ، في كل مرة يتم فيها إنشاء كتلة L2 على Taiko ، يتم تخزين قيم تجزئة الكتل الطرفية على L1 في عقد TaikoL2. أيضًا في حالة L1 → → L2 ، يكون وضع التشغيل هو نفسه.
يمكن الحصول على أحدث جذر Merkle معروف مخزن في السلسلة المستهدفة عن طريق استدعاء getCrossChainBlockHash (0) على عقد TaikoL1 / TaikoL2 والحصول على القيمة / الرسالة للتحقق. يمكن الحصول على تجزئة الأخوة لأحدث جذر Merkle المعروف عن طريق استدعاء طلب eth \ _getProof باستخدام RPC قياسي على "سلسلة المصدر".
بعد ذلك ، أرسلها ببساطة ليتم التحقق منها مقابل أحدث تجزئات الكتلة المعروفة المخزنة في قائمة على "السلسلة المستهدفة". سيأخذ المدقق قيمة (ورقة على شجرة Merkle) وتجزئة الأخوة لإعادة حساب جذر Merkle والتحقق من أنه يطابق الجذر المخزن في قائمة تجزئات الكتلة للسلسلة المستهدفة.
** （2） **** ستاركنت **
يستخدم Starknet إثبات التخزين للمراسلة عبر السلاسل غير الموثوقة.
** L2 → L1 بروتوكول المراسلة **
· أثناء تنفيذ صفقة Starknet ، يرسل العقد على Starknet رسالة L2 → L1.
ثم يتم إلحاق معلمات الرسالة (التي تحتوي على عقد المستلم والبيانات ذات الصلة على L1) بتحديث الحالة ذات الصلة (شجرة التخزين الرئيسية).
· يتم تخزين رسائل L2 في L1 من العقد الذكي.
· إصدار حدث على L1 (معلمات رسالة المتجر).
يمكن لعناوين المستلم على L1 الوصول إلى الرسالة واستخدامها كجزء من معاملة L1 عن طريق إعادة توفير معلمات الرسالة.
يتم تنفيذ الاتصال بين L1 و L2 من خلال عقدين ذكيين خاصين يسمى "messenger".
· بالنسبة لمعاملات التفاؤل (L2) إلى Ethereum (L1) ، من الضروري تقديم دليل Merkle للرسالة على L1 بعد كتابة جذر الحالة. بعد أن تصبح معاملة الإثبات هذه جزءًا من سلسلة L1 ، تبدأ فترة تحدي الخطأ. بعد فترة الانتظار هذه ، يمكن لأي مستخدم "إنهاء" المعاملة عن طريق بدء معاملة ثانية على Ethereum ، وإرسال رسالة إلى عقد L1 المستهدف.
· يتم تخزين الرسائل عبر السلاسل في شجرة الجذع.
** （4） Ar **** bitrum **
التذاكر القابلة لإعادة المحاولة هي الطريقة الأساسية التي يستخدمها Arbitrum لإنشاء رسائل L1 إلى L2 ، أي معاملات L1 التي تهيئ الرسائل ليتم تنفيذها على L2. يمكن تقديم Retryable على L1 مقابل رسوم ثابتة (اعتمادًا على حجم بيانات المكالمة فقط). تُستخدم شجرة الحالة الرئيسية للتواصل عبر السلاسل لتنسيقات البيانات المخصصة في العقود الذكية. يعد إرسال بطاقة قابلة لإعادة المحاولة على L1 قابلاً للفصل / غير متزامن عن التنفيذ في L2. توفر العناصر القابلة لإعادة المحاولة الذرية بين العمليات عبر السلاسل. إذا تم تقديم طلب معاملة L1 بنجاح (أي بدون العودة إلى الحالة السابقة) ، فإن تنفيذ إعادة المحاولة في المستوى 2 لديه ضمان قوي بأنه سينجح في النهاية.
يحتوي Arbitrum على جذوعين: يتم الاحتفاظ بسلسلة Nitro في شكل شجرة حالة Ethereum ، وهي شجرة Merkle. تخزن Assertion Tree حالة سلسلة Arbitrum المؤكدة على Ethereum عبر "التأكيد". القواعد التي تقدم سلسلة Arbitrum حتمية. هذا يعني أنه بالنظر إلى حالة السلسلة وبعض قيم الإدخال الجديدة ، لا يوجد سوى مخرج واحد صالح. لذلك ، إذا كانت شجرة الإثبات تحتوي على أوراق متعددة ، فيمكن أن تمثل ورقة واحدة على الأكثر حالة سلسلة صالحة.
يسمح نظام Outbox في Arbitrum بأي مكالمة عقد من L2 إلى L1 ، أي ، يتم بدء رسالة من L2 ويتم تنفيذها أخيرًا على L1. تشترك رسائل L2 إلى L1 (المعروفة أيضًا باسم "الرسائل الصادرة") في الكثير من القواسم المشتركة مع رسائل Arbitrum من L1 إلى L2 (قابلة لإعادة المحاولة) ، على الرغم من وجود بعض الاختلافات الملحوظة. جزء من الحالة L2 لسلسلة Arbitrum - أي الجزء المُصادق عليه في كل RBlock - هو جذر Merkle لجميع الرسائل من L2 إلى L1 في سجل السلسلة. بعد تأكيد RBlock المثبت (عادةً بعد حوالي أسبوع من الإثبات) ، يتم تضمين جذر Merkle في عقد Outbox ويتم نشره في L1. ثم يسمح عقد البريد الصادر للمستخدمين بتنفيذ رسائلهم.
** （5） **** مضلع zkEVM **
· يستخدم Bridge SC في zkEVM شجرة Merkle خاصة تسمى Exit Tree لكل شبكة مشاركة في الاتصال أو معاملة الأصول.
يستخدم جذور Merkle (في شجرة حالة منفصلة) ، ويمكن العثور على مخطط هندسة الجسر على جيثب.
أدى نشر zkEVM Bridge SC إلى إجراء العديد من التغييرات بناءً على عقد الإيداع Ethereum 2.0. على سبيل المثال ، تستخدم شجرة Merkle مصممة خصيصًا للإلحاق فقط ، ولكنها تستخدم نفس منطق عقد الإيداع Ethereum 2.0. الاختلافات الأخرى تتعلق بتجزئة القاعدة وعقد الأوراق.
السمة الرئيسية للعقد الذكي Polygon zkEVM Bridge هي استخدام Exit Tree و Exit Tree العالمية ، حيث يكون جذر Exit Tree العالمية هو المصدر الرئيسي لحالة الحقيقة. لذلك ، يحتوي L1 و L2 على مديرين عالميين مختلفين لجذر الخروج ، ولدى Bridge SC منطق منفصل.
** （6） S **** كرول **
· تسمح عقود Bridge المنتشرة على Ethereum و Scroll للمستخدمين بتمرير رسائل عشوائية بين L1 و L2. علاوة على بروتوكول المراسلة هذا ، قمنا أيضًا ببناء بروتوكول تجسير غير موثوق به للسماح للمستخدمين بربط أصول ERC-20 بين L1 و L2. لإرسال رسالة أو أموال من Ethereum إلى Scroll ، يقوم المستخدم باستدعاء معاملة sendMessage على عقد Bridge. ستقوم المرحلات بفهرسة هذه المعاملة على L1 وإرسالها إلى الطالب لتضمينها في كتل L2. في عقد جسر L2 ، تتشابه عملية إرسال رسالة من Scroll back إلى Ethereum.
يتم تخزين الرسائل عبر السلاسل في قوائم انتظار الرسائل العادية. يستوعب المرتب الرسائل عبر السلاسل من قائمة الانتظار هذه ويضيفها إلى السلسلة على أنها معاملات عادية.
** （7） **** عصر zksync **
إخلاء المسؤولية: المحتوى في هذا القسم يتعلق فقط بعصر zksync ، والذي قد يختلف عن الرسائل عبر السلاسل على ZK Stack ، وهو إطار معياري لبناء سلسلة ZK فائقة السيادة. *
تحتوي كل حزمة معاملة على رسالة L2-> L1 واحدة.
· لا يمكن إرسال المعاملات مباشرة من L2 إلى L1. ومع ذلك ، يمكنك إرسال رسائل بأي طول من zkSync Era إلى Ethereum ، ثم معالجة الرسائل المستلمة على Ethereum باستخدام العقد الذكي L1. يحتوي zkSync Era على وظيفة إثبات الطلب التي ستعيد معلمة منطقية تشير إلى ما إذا تم إرسال الرسالة بنجاح إلى L1. استرجع إثبات Merkle الموجود في الرسالة من خلال مراقبة Ethereum أو استخدام طريقة zks \ _getL2ToL1LogProof لواجهة برمجة تطبيقات zksync-web3.
· بالنسبة لـ L1 → L2 ، يسمح العقد الذكي zkSync Era للمرسل بطلب معاملة على Ethereum L1 وتمرير البيانات إلى zkSync Era L2.
· عقد الجسر:
4. الخلاصة
تعد الاتصالات عبر السلاسل جزءًا لا يتجزأ من التطبيقات "الضرورية" للتبني الجماعي لـ blockchain (على سبيل المثال ، محفظة الاسترداد الاجتماعي عبر السلاسل الموضحة في مقالة Vitalik). تم تصميم معظم الحلول المتقاطعة المستخدمة حاليًا من أجل L1 → → L2 لتغطية وظيفة السحب. يمكن توسيع هذه الحلول لتشمل المزيد من سلاسل الكتل. ولكن في الوقت نفسه ، يمكن تنفيذ حلول اتصالات أكثر تقدمًا عبر السلاسل ، مثل "حالة القراءة المباشرة" بدون دليل على الإطلاق أو "إثبات التخزين" بدون ثقة. بالنسبة لمعظم L2s ، لا يزال هناك مجال لتحسين الاتصال عبر السلاسل.
شاهد النسخة الأصلية
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
استكشف الاتصالات عبر السلاسل من منظور التراكمية
المؤلف: ليزا أ ، مختبرات تايكو ؛ الترجمة: Jinse Finance xiaozou
ستناقش هذه المقالة طرق المراسلة عبر السلسلة L2 المختلفة من منظور التجميع ، مع التركيز على الاتصال عبر السلاسل بدون ثقة. سننظر بإيجاز في نهج قراءة الحالة المباشرة ، ونهج العميل الخفيف ، وإثبات التخزين. سنغطي أيضًا آلية تجميع الإثبات ، ونقل الرسائل عبر السلاسل الموثوق بها من طرف ثالث وحلول ZK عبر السلاسل الأساسية. أخيرًا ، دعنا نلقي نظرة على كيفية قيام L2s المختلفة بتنفيذ المراسلة عبر السلاسل اليوم.
** 1. مقدمة للمراسلة عبر السلاسل **
للتواصل عبر السلاسل ، يجب أن يكون لدى جميع الأطراف (L2 و L3 وما إلى ذلك) وصول مباشر إلى أحدث جذر حالة Ethereum.
! [rfh0JNBHRNLMrqsfJlBNyNproUdN5eki4WaerGa.png] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-7f42fc5733-dd1a6f-7649e1 "7063980")
تحتوي جميع طبقات الإيداع على آلية عبر سلسلة "مضمنة" يمكن استخدامها للوصول إلى جذر حالة L1 ، والتي سيتم تمريرها إلى L2 كرسالة إيداع.
** 1 ****. 1 ** ** نوعان من الوصول إلى جذر الحالة **
** النوع 1: قراءة جذر الحالة مباشرةً ** - يمكن إجراؤه عبر كود التشغيل أو المترجم مسبقًا. ومع ذلك ، لم يتم تنفيذه حتى الآن ، لذلك لا داعي لإثبات.
يصف Brecht Devos طريقة محتملة لقراءة الحالة مباشرةً في ورقة بحثية: "... يمكننا الكشف عن عقد مترجم مسبقًا يمكنه استدعاء عقد ذكي مباشرة في السلسلة المستهدفة. هذا مترجم مسبقًا مباشرةً في سلسلة المصدر يُدرج وينفذ رمز العقد الذكي لسلسلة أخرى . وهذا يضمن أن العقود الذكية لديها دائمًا إمكانية الوصول إلى أحدث حالة متاحة بطريقة فعالة ويمكن إثباتها بسهولة. "
· تم وصفه أيضًا في طلب تقديم العروض الخاص بالتفاؤل "عن بعد ثابت استدعاء إثبات المفهوم".
** النوع 2: Proof Generation ** - أي إثبات بيان حول blockchain واحد على blockchain آخر.
"المراسلة عبر السلاسل مع البراهين" لها طريقتان:
· اتصال عبر السلاسل غير موثوق به - أي عدم وجود أطراف ثالثة موثوق بها (على سبيل المثال ، استخدام عملاء خفيفين أو إثبات التخزين). يمكن استخدام النهج غير الموثوق به لتوليد البراهين من طرف ثالث وللمشاركين في الاتصالات عبر السلاسل لإنشاء البراهين بأنفسهم.
يتم مشاركة البراهين بين مجموعات مختلفة لضمان عمليات عبر السلسلة. هذا النهج ، الذي لم تتم مناقشته كثيرًا في هذه المقالة ، موجود حاليًا في مرحلة البحث والاستكشاف ولا يعتبر حلاً قابلاً للتطبيق على نطاق واسع.
** 1 ****. 2 ** ** طريقة "المراسلة عبر السلاسل مع الدليل" **
** 1.2.1 ** ** الرسائل عبر السلاسل الخفيفة للعميل **
إثبات البيانات الموجودة على السلسلة ب
الحصول على بيانات إثبات Merkle من العقدة الكاملة للسلسلة B (عقد أرشفة أرشيفية إذا كان إثبات التخزين لحالات تاريخية معينة مطلوبًا) ؛
إرسال رأس الكتلة وبيانات الإثبات المقابلة لكتلة السلسلة B التي تحتوي على الحالة التي نريد التحقق منها لعقد المُثبِت في السلسلة A كبيانات اتصال ؛
يحسب عقد المُثبِّت قيمة تجزئة الكتلة استنادًا إلى بيانات رأس الكتلة ، ويستفسر عن العقد الذكي للعميل الخفيف في السلسلة A (يتتبع قيمة تجزئة الكتلة للسلسلة B) ، ويتحقق مما إذا كانت قيمة التجزئة صالحة ؛
يتم التحقق من بيانات الإثبات مقابل جذر حالة بايت 32 في رأس الكتلة.
! [52LA99e5TstU99Tn9976XZWLZBJOyVAqcP2X2FdO.png] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-bc05d73dc1-dd1a6f-7649e1 "7063981"
** 1 ****. 2.2 ** ** إثبات التخزين **
يحتوي إثبات التخزين على خيارين "لسير العمل":
· إنشاء دليل على التخزين ← استخدام على السلسلة
· إنشاء دليل على التخزين ← إنشاء دليل zk ← الاستخدام على السلسلة
من الممكن أيضًا للكيان تجميع مجموعات متعددة من البراهين في دليل واحد (كل من إثبات التخزين وإثبات zk). هذه خطوة تحسين اختيارية ولم تتم مناقشتها بعد.
دعنا نلقي نظرة على المراحل الرئيسية الثلاثة لإثبات "سير عمل" التخزين: إنشاء إثبات التخزين ، وإنشاء دليل zk ، واستخدامه في السلسلة.
** (1) إنشاء إثبات التخزين **
· إثبات التخزين يسمح لنا باستخدام التزام سري لإثبات وجود معلومات معينة على blockchain وأنها صحيحة ؛
كان إثبات التخزين جزءًا من مساحة التشفير منذ ظهور أشجار Merkle في عام 1979. ومع ذلك ، فإن براهين تخزين الفانيليا عادة ما تكون كبيرة جدًا. يكمن الابتكار الحديث في الجمع بين إثبات التخزين والحساب الذي يمكن إثباته لإنشاء أدلة موجزة يمكن التحقق منها على السلسلة.
** لإنشاء ** إثبات التخزين ، يجب توفير كتلة معينة من البيانات ومسار Merkle أو Verkle المرتبط بها في شجرة Merkle. يتكون المسار من تجزئات الأخوة اللازمة لإعادة بناء تجزئة الجذر باستخدام نفس خوارزمية التجزئة.
** للتحقق ** من إثبات التخزين ، يمكن للمستلم استخدام البيانات المقدمة ومسار Merkle أو Verkle لإعادة حساب تجزئة الجذر. إذا تطابق تجزئة الجذر المعاد حسابها مع تجزئة جذر معروفة ، يمكن للمستلم أن يكون واثقًا من أن البيانات أصلية وجزء من مجموعة البيانات المقدمة.
** (2) إنشاء ZKP (إثبات المعرفة الصفرية) **
ومع ذلك ، فإن إثبات التخزين من نوع Ethereum يبلغ حوالي 4 كيلوبايت - كبير إلى حد ما لنشر إثبات التخزين بالكامل على السلسلة المستهدفة ، حيث سيكون التحقق من الإثبات مكلفًا للغاية. لذلك ، من المعقول استخدام ZKP (على سبيل المثال ، ZK-SNARK) للضغط ، مما يجعل الدليل أصغر وأرخص للتحقق.
** （3） A **** لفة ** ** ZKP **
بعد كسب ZKPs ، يمكن للمستخدمين في السلسلة المستهدفة فتح البراهين المكتسبة (على سبيل المثال ، الوصول إلى الحالة التاريخية عبر رؤوس الكتلة أو تجزئة الكتلة).
يمكن أن يتم Unroll على النحو التالي:
** التراكم على السلسلة: ** يتم تنفيذ العملية الكاملة لإعادة بناء رؤوس الكتل من البراهين مباشرة على blockchain. العيوب: رسوم غاز عالية ، تستهلك موارد الحوسبة ؛ المزايا: لا يوجد وقت إثبات إضافي ، زمن انتقال منخفض ، لأنه لا توجد حاجة لإنشاء أدلة خارج blockchain.
** الضغط على السلسلة: ** أزل المعلومات الزائدة أو غير الضرورية من البيانات ، أو استخدم هياكل البيانات المحسّنة لتحقيق الكفاءة في استخدام المساحة. يتم إرسال البيانات المضغوطة إلى blockchain ويمكن فك ضغطها عند الحاجة. السلبيات: قد يعني ضغط البيانات وإلغاء ضغطها حسابًا إضافيًا ، ولكن قد يكون وقت الاستجابة هذا ضئيلًا. قد يكون لخوارزمية الضغط المستخدمة تأثير سلبي على أمان البيانات ؛ الميزة: تقليل تكاليف البيانات.
** التخزين خارج السلسلة: ** قم بتخزين البيانات خارج السلسلة ، ووضع كتل بيانات محددة على السلسلة عند الطلب. هذا مناسب للحلول التي تحتاج إلى تخزين كميات كبيرة من البيانات لسبب ما (مثل عقد أرشيف Ethereum من كتلة التكوين). السلبيات: مثل الضغط على السلسلة ؛ الإيجابيات: تقليل تكاليف البيانات بشكل أكبر.
** 1 ****. 2.3 ** ** جهة خارجية موثوقة **
يجب أن يشتمل الحل الكامل عبر السلاسل أيضًا على حلول المراسلة المتقاطعة مع أطراف ثالثة موثوق بها (مثل أوراكل ، والجسور المركزية ، وما إلى ذلك).
** 1 ****. 2.4 ** ** نظام إثبات "عالمي" **
في حالة وجود آلية منصة مشتركة لإثبات التجميع ، يمكن تسريع المراسلة عن طريق تلقي تجزئات الكتلة التي يتم تسويتها داخل منصة التجميع ، وستتعامل التسوية هنا أيضًا مع الرسائل (ولكن إذا كانت هناك مشكلة في منصة التجميع ما يجب القيام به؟).
** 1 ****. 2.5 بعض المشكلات غير المعروفة في رسائل ZK **** عبر السلاسل **
هل الرسائل عبر السلاسل ممكنة بدون طرف ثالث موثوق به (والذي يمكن أن يكون كيانًا واحدًا أو كيانات متعددة)؟ ما هي آلية فعالة لتمرير الرسائل عبر السلاسل؟ بشكل عام ، بالنسبة إلى Ethereum L2 (مع الوصول المباشر إلى تجزئة الكتلة من L1) و Ethereum نفسها ، إذا كان بإمكان سلسلة واحدة تشغيل عميل خفيف وما إلى ذلك ، وهو ما يكفي للرسائل عبر السلاسل غير الموثوقة.
هل دائرة ZK المستخدمة لتوليد الإثبات عبر السلاسل متدرجة بشكل صحيح؟ في بعض الحالات ، خاصةً عندما تكون طبقة الإجماع (التي تحتاج إلى التحقق من العمليات عبر السلسلة) كبيرة جدًا ، يمكن أن تكون الدائرة المستخدمة لتمرير الرسائل عبر سلسلة ZK أكبر من التخزين التراكمي والتخزين على السلسلة ، و الحمل الحسابي كبير جدًا أيضًا. كبير. من المفترض أنه يمكن التغلب على هذه المشكلة باتباع نهج أكثر مركزية.
** 2 **** 、 مثال على حل الرسائل عبر السلاسل **
تستخدم ** Su **** ccinct Labs ** عميلاً خفيفًا للتحقق من الإجماع من سلسلة المصدر إلى طبقة إجماع السلسلة المستهدفة. الفكرة هي وجود بروتوكول عميل خفيف للتأكد من أن العقد يمكنها مزامنة رؤوس الكتلة لحالة blockchain النهائية. يستخدم ZKP لتوليد براهين إجماع.
· تُنشئ ** La **** grange Labs ** دليل حالة غير تفاعلي عبر السلاسل. يثبت لاغرانج أن الشبكة مسؤولة عن إنشاء جذر الحالة. تحتوي كل عقدة لاغرانج على جزء من المفتاح الخاص لقطعة ما ، والذي يشهد على حالة سلسلة معينة. كل جذر حالة هو جذر Verkle موقعة على العتبة والتي يمكن استخدامها للدلالة على حالة سلسلة معينة في وقت معين. جذر الحالة عام تمامًا ويمكن استخدامه في إثبات الحالة لإثبات الحالة الحالية لأي عقد أو محفظة واحدة في السلسلة.
يستخدم ** He **** rodotus ** إثبات ZKP للتخزين لتوفير عقود ذكية والوصول إلى البيانات على سلسلة طبقات Ethereum الأخرى بشكل متزامن. للتحقق من الصحة ، يستخدم رسائل L1 <> L2 الأصلية لمزامنة تجزئة الكتلة بين مجموعات Ethereum.
** = لا شيء ؛ الأساس ** (Mina، L1) يسمح للعقود الذكية على Ethereum للتحقق من صحة حالة Mina. قم بإنشاء إثبات حالة لأغراض خاصة ، ورخيصة للتحقق من Ethereum (أدلة Mina المحلية على Ethereum باهظة الثمن). يمكن للتطبيقات الافتراضية (في وقت ما في المستقبل) أن تستخدم مباشرة أداة إنشاء دليل Mina للتحقق من صحة المعاملات عبر السلاسل. = لا شيء ؛ تمتلك المؤسسة أيضًا سوق إثبات حيث يمكن للمستخدمين / المشاريع شراء / بيع براهين SNARK التي تسمح بالوصول غير الموثوق به إلى البيانات.
** Axiom **: إذا قامت Axiom بإنشاء ZKP لدفتر الأستاذ حتى الآن - لا تحتاج إلى إنشاء ZKP لكتلة معينة - يمكنها تمرير ZKP هذا إلى السلسلة (كمحول) ، أو حتى توفير الوصول إلى هذا ZKP.
** 3. رسائل متقاطعة من المستوى 2 **
** （1） **** تايكو **
تخزن Taiko تجزئة الكتلة لكل سلسلة. لكل زوج من السلاسل ، ينشر عقدين ذكيين يخزن كل منهما تجزئات الآخر. في مثال L2 ← → L1 ، في كل مرة يتم فيها إنشاء كتلة L2 على Taiko ، يتم تخزين قيم تجزئة الكتل الطرفية على L1 في عقد TaikoL2. أيضًا في حالة L1 → → L2 ، يكون وضع التشغيل هو نفسه.
يمكن الحصول على أحدث جذر Merkle معروف مخزن في السلسلة المستهدفة عن طريق استدعاء getCrossChainBlockHash (0) على عقد TaikoL1 / TaikoL2 والحصول على القيمة / الرسالة للتحقق. يمكن الحصول على تجزئة الأخوة لأحدث جذر Merkle المعروف عن طريق استدعاء طلب eth \ _getProof باستخدام RPC قياسي على "سلسلة المصدر".
بعد ذلك ، أرسلها ببساطة ليتم التحقق منها مقابل أحدث تجزئات الكتلة المعروفة المخزنة في قائمة على "السلسلة المستهدفة". سيأخذ المدقق قيمة (ورقة على شجرة Merkle) وتجزئة الأخوة لإعادة حساب جذر Merkle والتحقق من أنه يطابق الجذر المخزن في قائمة تجزئات الكتلة للسلسلة المستهدفة.
** （2） **** ستاركنت **
يستخدم Starknet إثبات التخزين للمراسلة عبر السلاسل غير الموثوقة.
** L2 → L1 بروتوكول المراسلة **
· أثناء تنفيذ صفقة Starknet ، يرسل العقد على Starknet رسالة L2 → L1.
ثم يتم إلحاق معلمات الرسالة (التي تحتوي على عقد المستلم والبيانات ذات الصلة على L1) بتحديث الحالة ذات الصلة (شجرة التخزين الرئيسية).
· يتم تخزين رسائل L2 في L1 من العقد الذكي.
· إصدار حدث على L1 (معلمات رسالة المتجر).
يمكن لعناوين المستلم على L1 الوصول إلى الرسالة واستخدامها كجزء من معاملة L1 عن طريق إعادة توفير معلمات الرسالة.
· يتم تخزين الرسائل عبر السلاسل في شجرة الجذع.
** L2 → L1 **
! [iocV083teJy7HB2JCM7F1EdksuPnC6r8XMwF8fLJ.png] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-39d9625cd8-dd1a6f-7649e1 "7063982")
** L1 → L2 **
! [o3mWVnn2aX5WAAdz0RrHaFtmFcBNiYdDCwBehcAK.png] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-6ed753c5af-dd1a6f-7649e1 "7063983")
** （3） **** تفاؤل **
يتم تنفيذ الاتصال بين L1 و L2 من خلال عقدين ذكيين خاصين يسمى "messenger".
· بالنسبة لمعاملات التفاؤل (L2) إلى Ethereum (L1) ، من الضروري تقديم دليل Merkle للرسالة على L1 بعد كتابة جذر الحالة. بعد أن تصبح معاملة الإثبات هذه جزءًا من سلسلة L1 ، تبدأ فترة تحدي الخطأ. بعد فترة الانتظار هذه ، يمكن لأي مستخدم "إنهاء" المعاملة عن طريق بدء معاملة ثانية على Ethereum ، وإرسال رسالة إلى عقد L1 المستهدف.
· يتم تخزين الرسائل عبر السلاسل في شجرة الجذع.
** （4） Ar **** bitrum **
التذاكر القابلة لإعادة المحاولة هي الطريقة الأساسية التي يستخدمها Arbitrum لإنشاء رسائل L1 إلى L2 ، أي معاملات L1 التي تهيئ الرسائل ليتم تنفيذها على L2. يمكن تقديم Retryable على L1 مقابل رسوم ثابتة (اعتمادًا على حجم بيانات المكالمة فقط). تُستخدم شجرة الحالة الرئيسية للتواصل عبر السلاسل لتنسيقات البيانات المخصصة في العقود الذكية. يعد إرسال بطاقة قابلة لإعادة المحاولة على L1 قابلاً للفصل / غير متزامن عن التنفيذ في L2. توفر العناصر القابلة لإعادة المحاولة الذرية بين العمليات عبر السلاسل. إذا تم تقديم طلب معاملة L1 بنجاح (أي بدون العودة إلى الحالة السابقة) ، فإن تنفيذ إعادة المحاولة في المستوى 2 لديه ضمان قوي بأنه سينجح في النهاية.
يحتوي Arbitrum على جذوعين: يتم الاحتفاظ بسلسلة Nitro في شكل شجرة حالة Ethereum ، وهي شجرة Merkle. تخزن Assertion Tree حالة سلسلة Arbitrum المؤكدة على Ethereum عبر "التأكيد". القواعد التي تقدم سلسلة Arbitrum حتمية. هذا يعني أنه بالنظر إلى حالة السلسلة وبعض قيم الإدخال الجديدة ، لا يوجد سوى مخرج واحد صالح. لذلك ، إذا كانت شجرة الإثبات تحتوي على أوراق متعددة ، فيمكن أن تمثل ورقة واحدة على الأكثر حالة سلسلة صالحة.
يسمح نظام Outbox في Arbitrum بأي مكالمة عقد من L2 إلى L1 ، أي ، يتم بدء رسالة من L2 ويتم تنفيذها أخيرًا على L1. تشترك رسائل L2 إلى L1 (المعروفة أيضًا باسم "الرسائل الصادرة") في الكثير من القواسم المشتركة مع رسائل Arbitrum من L1 إلى L2 (قابلة لإعادة المحاولة) ، على الرغم من وجود بعض الاختلافات الملحوظة. جزء من الحالة L2 لسلسلة Arbitrum - أي الجزء المُصادق عليه في كل RBlock - هو جذر Merkle لجميع الرسائل من L2 إلى L1 في سجل السلسلة. بعد تأكيد RBlock المثبت (عادةً بعد حوالي أسبوع من الإثبات) ، يتم تضمين جذر Merkle في عقد Outbox ويتم نشره في L1. ثم يسمح عقد البريد الصادر للمستخدمين بتنفيذ رسائلهم.
** （5） **** مضلع zkEVM **
· يستخدم Bridge SC في zkEVM شجرة Merkle خاصة تسمى Exit Tree لكل شبكة مشاركة في الاتصال أو معاملة الأصول.
يستخدم جذور Merkle (في شجرة حالة منفصلة) ، ويمكن العثور على مخطط هندسة الجسر على جيثب.
أدى نشر zkEVM Bridge SC إلى إجراء العديد من التغييرات بناءً على عقد الإيداع Ethereum 2.0. على سبيل المثال ، تستخدم شجرة Merkle مصممة خصيصًا للإلحاق فقط ، ولكنها تستخدم نفس منطق عقد الإيداع Ethereum 2.0. الاختلافات الأخرى تتعلق بتجزئة القاعدة وعقد الأوراق.
السمة الرئيسية للعقد الذكي Polygon zkEVM Bridge هي استخدام Exit Tree و Exit Tree العالمية ، حيث يكون جذر Exit Tree العالمية هو المصدر الرئيسي لحالة الحقيقة. لذلك ، يحتوي L1 و L2 على مديرين عالميين مختلفين لجذر الخروج ، ولدى Bridge SC منطق منفصل.
** （6） S **** كرول **
· تسمح عقود Bridge المنتشرة على Ethereum و Scroll للمستخدمين بتمرير رسائل عشوائية بين L1 و L2. علاوة على بروتوكول المراسلة هذا ، قمنا أيضًا ببناء بروتوكول تجسير غير موثوق به للسماح للمستخدمين بربط أصول ERC-20 بين L1 و L2. لإرسال رسالة أو أموال من Ethereum إلى Scroll ، يقوم المستخدم باستدعاء معاملة sendMessage على عقد Bridge. ستقوم المرحلات بفهرسة هذه المعاملة على L1 وإرسالها إلى الطالب لتضمينها في كتل L2. في عقد جسر L2 ، تتشابه عملية إرسال رسالة من Scroll back إلى Ethereum.
يتم تخزين الرسائل عبر السلاسل في قوائم انتظار الرسائل العادية. يستوعب المرتب الرسائل عبر السلاسل من قائمة الانتظار هذه ويضيفها إلى السلسلة على أنها معاملات عادية.
** （7） **** عصر zksync **
تحتوي كل حزمة معاملة على رسالة L2-> L1 واحدة.
· لا يمكن إرسال المعاملات مباشرة من L2 إلى L1. ومع ذلك ، يمكنك إرسال رسائل بأي طول من zkSync Era إلى Ethereum ، ثم معالجة الرسائل المستلمة على Ethereum باستخدام العقد الذكي L1. يحتوي zkSync Era على وظيفة إثبات الطلب التي ستعيد معلمة منطقية تشير إلى ما إذا تم إرسال الرسالة بنجاح إلى L1. استرجع إثبات Merkle الموجود في الرسالة من خلال مراقبة Ethereum أو استخدام طريقة zks \ _getL2ToL1LogProof لواجهة برمجة تطبيقات zksync-web3.
· بالنسبة لـ L1 → L2 ، يسمح العقد الذكي zkSync Era للمرسل بطلب معاملة على Ethereum L1 وتمرير البيانات إلى zkSync Era L2.
· عقد الجسر:
4. الخلاصة
تعد الاتصالات عبر السلاسل جزءًا لا يتجزأ من التطبيقات "الضرورية" للتبني الجماعي لـ blockchain (على سبيل المثال ، محفظة الاسترداد الاجتماعي عبر السلاسل الموضحة في مقالة Vitalik). تم تصميم معظم الحلول المتقاطعة المستخدمة حاليًا من أجل L1 → → L2 لتغطية وظيفة السحب. يمكن توسيع هذه الحلول لتشمل المزيد من سلاسل الكتل. ولكن في الوقت نفسه ، يمكن تنفيذ حلول اتصالات أكثر تقدمًا عبر السلاسل ، مثل "حالة القراءة المباشرة" بدون دليل على الإطلاق أو "إثبات التخزين" بدون ثقة. بالنسبة لمعظم L2s ، لا يزال هناك مجال لتحسين الاتصال عبر السلاسل.