مدونة V God: فهم المحافظ وحالات التطبيق الأخرى ، الطبقة الثانية من القراءة عبر الطبقات

المؤلف: فيتاليك بوتيرين ؛ المترجم: قال بولو

في المقالة *** The Three Transitions *** ، أوضح Vitalik Buterin ، مؤسس Ethereum ، بالتفصيل "الشبكة الرئيسية (المشار إليها فيما يلي باسم L1) + الطبقة 2 المتقاطعة (المشار إليها فيما يلي باسم cross-L2) يعد دعم "" أمان المحفظة "و" الخصوصية "قيمتين مهمتين كوظائف ضرورية لمكدس النظام البيئي. لا ينبغي أن يكونا مجرد بعض المكونات الإضافية ، كما أن المحفظة المنفصلة توفر الوظائف ذات الصلة.

وأشار فيتاليك بوتيرين إلى أن هذه المقالة ستركز على مشكلة فنية رئيسية: كيفية قراءة بيانات L1 بسهولة أكبر من L2 ؛ أو قراءة بيانات L2 من L1 ؛ أو كيفية قراءة بيانات L2 بسهولة أكبر من بيانات L2 اقرأ من L2 آخر . **

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

** ما الهدف من ذلك؟ **

بمجرد أن يصبح L2 سائدًا ، سيتمكن المستخدمون من امتلاك أصول على L2s متعددة وربما L1 أيضًا.

بمجرد أن تصبح محافظ العقود الذكية سائدة ، لن يتم استخدام "المفاتيح" الشائعة الآن.

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

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

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

بالنسبة للحسابات الخارجية (EOA) ، في الواقع ، تبدأ جميع العناوين من عنوان "الإعداد المضاد".

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

△ خوارزمية حساب عنوان EIP-1014 (CREATE2).

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

إذا كان لدى المستخدم عناوين على العديد من L2s ، فإن ** فصل الأصول وبنية تخزين المفاتيح ** فقط يمكن أن يساعد المستخدمين على تغيير مفاتيحهم.

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

هناك طريقتان لتنفيذ بنية فصل تخزين الأصول والمفاتيح:

** إصدار خفيف الوزن (أي يتحقق فقط من المفاتيح المحدثة) **: تخزن كل محفظة مفتاح التحقق محليًا ، وتحتوي على وظيفة قابلة للاستدعاء للتحقق من إثبات عبر السلسلة للحالة الحالية لمخزن المفاتيح ، وتحديث التخزين المحلي المصادقة مفتاح المباراة. مطلوب استدعاء هذه الوظيفة للحصول على مفتاح المصادقة الحالي من مخزن المفاتيح عند استخدام المحفظة لأول مرة على L2.

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

** الإصدار الكامل (أي يتم فحص كل معاملة) **: تتطلب كل معاملة إثباتًا عبر سلسلة يُظهر المفتاح الحالي في مخزن المفاتيح.

• ** المزايا: ** تعقيد النظام منخفض ويتم تحديث مخزن المفاتيح بسرعة.
• ** العيوب: ** رسوم تشغيل الشبكة لمعاملة واحدة مرتفعة ، وليس من السهل التوافق مع ERC-4337. لا يدعم ERC-4337 حاليًا قراءة الكائنات القابلة للتغيير عبر العقود أثناء التحقق.

** ما هو الدليل المتقاطع؟ **

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

افترض أن مخزن المفاتيح موجود على Linea وأن المحفظة موجودة على Kakarot. يجب أن تتضمن عملية التصديق الكاملة لمفتاح المحفظة ما يلي:

• دليل على جذر حالة Linea الحالي ، مع الأخذ في الاعتبار جذر حالة Ethereum الحالي المعروف لكاكاروت.
• إثبات للمفتاح الحالي في ملف تخزين المفاتيح ، بالنظر إلى جذر حالة Linea الحالي.

هناك سؤالان رئيسيان شائكان للتنفيذ هنا: "ما نوع الدليل الذي يجب استخدامه؟ (هل هو دليل Merkle؟ أو أي شيء آخر؟)" و "كيف يتعلم L2 أقرب جذر حالة L1؟" أو ، "L1 كيف لمعرفة جذر حالة L2؟ "

إذن ، في كلتا الحالتين ، ما هي مدة التأخير بين وقوع حدث من جانب وبين أن يكون الطرف الآخر قادرًا على تقديم دليل؟

** ما هي مخططات الإثبات المتاحة لنا؟ **

هناك خمس طرق رئيسية للاختيار من بينها:

• برهان ميركل
• عام ZK-SNARKs
• شهادة لغرض خاص (على سبيل المثال ، باستخدام KZG)
• إثبات Verkle ، بين KZG و ZK-SNARKs ، مع مراعاة جهود البنية التحتية والتكلفة
• لا يوجد دليل ، يعتمد على قراءة الدولة المباشرة

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

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

في الواقع ، يكون "التجميع" ذا قيمة فقط عندما يكون للحل عدد كبير من المستخدمين. ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

** كيف تعمل البراهين ميركل؟ **

هذه المشكلة بسيطة للغاية ويمكن أن يتبعها الرسم التخطيطي في القسم السابق مباشرة. سيتضمن كل "إثبات" (بافتراض أن مستوى L2 واحدًا آخر ، والذي يعد أصعب سيناريو للتطبيق):

شوكة Merkle التي تشهد على امتلاك جذر الحالة لمخزن المفتاح L2 ، وهو أحدث جذر حالة من Ethereum المعروف لـ L2. يتم تخزين جذور الحالة التي تحتفظ بمخزن المفاتيح L2 في فتحات تخزين معروفة في عناوين معروفة (تمثل عقود L1 L2) ، لذلك يمكن أن تكون المسارات مشفرة.

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

ومع ذلك ، فإن إثباتات الحالة في Ethereum معقدة ، ولكن هناك مكتبات يمكن استخدامها للتحقق منها ، وفي حالة استخدام هذه المكتبات ، فإن الآلية ليست معقدة للغاية.

ومع ذلك ، فإن التحدي الأكبر هو التكلفة. ** أثبتت Merkle أنها طويلة جدًا ، وكانت شجرة Patricia أطول بمقدار 3.9 مرة من اللازم - أعلى بكثير من السعر الأساسي الحالي البالغ 21000 رسوم غاز لكل معاملة.

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

يمكننا حساب ما يعنيه هذا من خلال النظر إلى المقارنة بين تكلفة رسوم الغاز L1 وتكلفة رسوم الغاز L2:

في الوقت الحالي ، إذا كانت عملية إرسال بسيطة نسبيًا ، فإن التكلفة على شبكة L1 تبلغ حوالي 15 إلى 25 ضعف تكلفة L2 ، وتكلفة تبادل الرموز حوالي 20 إلى 50 ضعف تكلفة L2.

تحتوي عملية الإرسال البسيطة على كمية كبيرة من البيانات ؛ وتتطلب عملية التبادل قدرة حوسبة أعلى ، لذا فإن عملية التبادل هي معيار أفضل لتقريب تكلفة حساب L1 وحساب L2.

بوضع ما سبق معًا ، إذا افترضنا نسبة تكلفة 30x بين التكلفة الحسابية L1 والتكلفة الحسابية L2 ، يبدو أن هذا يعني أن تكلفة وضع أدلة Merkle على L2 يمكن أن تعادل حوالي خمسين معاملة منتظمة.

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

** كيف يعمل دليل ZK-SNARK؟ **

من السهل أيضًا فهم استخدام ZK-SNARKs من الناحية المفاهيمية: ما عليك سوى استبدال براهين Merkle في الرسم التخطيطي أعلاه بإثباتات ZK-SNARK التي تثبت وجود هذه البراهين من Merkle. تبلغ قيمة حساب ZK-SNARK حوالي 400000 رسوم غاز ، أي حوالي 400 بايت ؛ تتطلب المعاملة الأساسية 21000 رسوم غاز و 100 بايت.

لذلك ، من وجهة نظر الحساب ، فإن تكلفة ZK-SNARK هي 19 ضعف تكلفة المعاملة الأساسية الحالية ؛ من وجهة نظر البيانات ، فإن تكلفة ZK-SNARK هي 4 أضعاف تكلفة المعاملة الأساسية الحالية و 16 ضعفًا في المستقبل تكلفة المعاملة الأساسية.

تمثل هذه الأرقام تحسنًا كبيرًا عن براهين Merkle ، لكنها لا تزال باهظة الثمن. ** هناك طريقتان لتحسين هذا الموقف: ** (1) أدلة KZG ذات الأغراض الخاصة ، أو (2) التجميع ، على غرار تجميع ERC-4337.

** كيف يعمل دليل KZG للأغراض الخاصة؟ **

أولاً ، ملخص لكيفية عمل وعود KZG:

• [D \ _1 ... D \ _n] يمثل مجموعة من البيانات التي يتم من خلالها اشتقاق برهان KZG متعدد الحدود. *

• على وجه التحديد ، كثير الحدود P ، حيث P (w) = D \ _1 ، P (w²) = D \ _2 ... P (wⁿ) = D \ _n. w هنا هو "الجذر الموحد" ، لبعض حقول التقييم الحجم N ، القيمة wN = 1 (يتم كل هذا في الحقول المحدودة). *

• من أجل "الالتزام" بـ P ، نقوم بإنشاء نقطة منحنى بيضاوي الشكل com (P) = P₀ \ * G + P₁ \ * S₁ + ... + Pk \ * Sk. هنا:*

• G هي نقطة توليد المنحنى *

• Pi هو معامل ith لكثير الحدود P *

• Si هي النقطة ith في الإعداد الموثوق به *

• ولإثبات أن P (z) = a ، نقوم بإنشاء خارج القسمة كثير الحدود Q = (P - a) / (X - z) ، وننشئ التزام com (Q). من الممكن فقط إنشاء مثل هذا كثير الحدود إذا كانت P (z) تساوي بالفعل a. *

• للتحقق من الإثبات ، نتحقق من المعادلة Q \ * (X - z) = P - a من خلال إجراء فحص منحنى ناقص على الإثبات com (Q) والالتزام متعدد الحدود com (P): نتحقق من e (com ( س) ، كوم (س - ض))؟ = e (com (P) - com (a)، com (1)) *

تتضمن بعض الخصائص الرئيسية التي يجب معرفتها أيضًا ما يلي:

• الدليل هو قيمة com (Q) فقط ، وهي 48 بايت *

• com （P₁） + com （P₂） = com （P₁ + P₂） *

• يعني هذا أيضًا أنه يمكنك "تعديل" القيمة في عقد حالي. *

• لنفترض أننا نعلم أن D \ _i هو a حاليًا ، ونريد ضبطه على b ، والالتزام الحالي بـ D هو com (P). الوعد "P ، ولكن P (wⁱ) = b ، ولا توجد تغييرات أخرى في التقييم" ، ثم قمنا بتعيين com (new \ _P) = com (P) + (ba) \ * com (Li) ، حيث Li هو "lag Langerian كثيرة الحدود "، تساوي 1 عند wⁱ و 0 عند نقاط wj أخرى. *

• لإجراء هذه التحديثات بكفاءة ، يمكن لكل عميل أن يحسب ويخزن جميع التزامات N في لاغرانج متعدد الحدود (com (Li)). في العقد المتسلسل ، قد يكون تخزين جميع التزامات N أمرًا مبالغًا فيه ، لذلك يمكنك أن تلتزم KZG بمجموعة قيم com (L \ _i) ، لذلك كلما احتاج شخص ما إلى تحديث الشجرة في السلسلة ، يمكنه ذلك ما عليك سوى إرساله إلى Proper com (L \ _i) الذي يقدم دليلاً على صحتها. *

لذلك ، لديك بنية تحافظ على إضافة القيم إلى نهاية القائمة المتزايدة ، ولكن مع حد معين للحجم. بعد ذلك ، استخدم هذا الهيكل كهيكل بيانات لـ (1) الالتزامات بقائمة المفاتيح في كل L2 ، المخزنة على ذلك L2 والمنعكسة إلى L1 ، و (2) الالتزامات بقائمة الالتزامات لمفاتيح L2 ، المخزنة في Ethereum على L1 وعكس كل L2.

يمكن أن يكون تحديث الالتزامات جزءًا من منطق L2 الأساسي ، أو يتم تنفيذه عبر جسر الإيداع والسحب دون تغيير بروتوكول L2 الأساسي.

يتطلب الإثبات الكامل ما يلي:

1. قم بتخزين أحدث com (قائمة المفاتيح) لمخزن المفاتيح على L2.
2. إثبات KZG باستخدام com (قائمة المفاتيح) كقيمة في com (قائمة النسخ المتطابقة) ، وهي قائمة بجميع التزامات قائمة المفاتيح.
3. اصنع شهادة KZG لمفتاح المستخدم في com (قائمة المفاتيح).

في الواقع ، يمكن دمج اثنتين من إثباتات KZG أعلاه في واحد بحجم إجمالي 100 بايت فقط.

لاحظ أحد التفاصيل: نظرًا لأن قائمة المفاتيح هي قائمة ، وليست خريطة مفتاح / قيمة مثل الحالة ، فيجب تعيين مواقع قائمة المفاتيح بالترتيب. سيحتوي عقد الوعد الرئيسي على السجل الداخلي الخاص به ، مع تعيين كل مخزن مفاتيح لمعرف ، ولكل مفتاح ، سيتم تخزين التجزئة (المفتاح ، عنوان مخزن المفاتيح) بدلاً من المفتاح فقط ، لإخبار L2s الأخرى صراحةً عن أيهما keystore يشير إدخال معين إلى.

تكمن ميزة هذه التقنية في أنها تؤدي أداءً جيدًا للغاية في المستوى 2. أقصر بحوالي 4 مرات من ZK-SNARK ، أقصر بكثير من برهان Merkle. تبلغ تكلفة الحساب حوالي 119000 رسم غاز.

في L1 ، تعد قوة الحوسبة أكثر أهمية من البيانات ، لذا فإن KZG أغلى قليلاً من برهان Merkle.

** كيف تعمل أشجار الفركل؟ **

تتضمن أشجار Verkle بشكل أساسي تكديس التزامات KZG معًا: لتخزين قيم 2⁴⁸ ، يمكن إجراء التزام KZG بقائمة من قيم 2²⁴ ، كل منها في حد ذاته التزام KZG لقيم 2²⁴.

تعتبر أشجار Verkle لأشجار دولة Ethereum لأنه يمكن استخدام أشجار Verkle للاحتفاظ بخرائط قيمة المفتاح.

البراهين في أشجار Verkle أطول من براهين KZG ، ويمكن أن يصل طولها إلى مئات البايتات.

في الواقع ، يجب اعتبار أشجار Verkle مثل أشجار Merkle ، ولكنها أكثر جدوى من دون التشويش ، ولكن ثبت أن SNARKing أقل تكلفة.

الميزة العظيمة لأشجار Verkle هي أنها يمكن أن تنسق هياكل البيانات: بحيث يمكن استخدامها مباشرة مع L1 أو L2 ، لا توجد بنية تراكب ، ويتم استخدام نفس الآلية بالضبط مع L1 و L2.

بمجرد أن تصبح أجهزة الكمبيوتر الكمومية مشكلة ، أو بمجرد أن تثبت فروع Merkle فعاليتها بدرجة كافية ، يكون لأشجار Verkle استخدامات أكثر.

** البلمرة **

إذا قام N من المستخدمين بإجراء معاملات N واحتاجوا إلى إثبات مطالبات عبر سلسلة N ، فيمكننا توفير الكثير من رسوم الغاز من خلال تجميع هذه الأدلة ، مما قد يعني:

• دليل ZK-SNARK لفروع N Merkle
• شهادة KZG متعددة
• مضاد Verkle متعدد (أو مضاد متعدد ZK-SNARK)

في جميع الحالات الثلاث ، لا يكلف كل إثبات سوى بضع مئات الآلاف من رسوم الغاز.

يحتاج المطورون إلى تقديم دليل واحد من هذا القبيل على كل L2 لمستخدمي ذلك L2 ؛ وبالتالي ، لكي يكون هذا الدليل مفيدًا ، يحتاج النظام بأكمله إلى استخدام كافٍ بحيث يوجد غالبًا على الأقل عدد قليل من المعاملات.

إذا تم استخدام ZK-SNARKs ، فقد يحتاج كل مستخدم إلى إنفاق آلاف رسوم غاز L2. إذا تم استخدام KZG multi-proof ، يحتاج المدقق إلى إضافة 48 رسوم غاز إلى L2 لكل مخزن مفاتيح مستخدم في الكتلة.

ومع ذلك ، فإن هذه التكاليف أقل بكثير مما هي دون التجميع ، والذي يتضمن حتما أكثر من 10000 رسوم غاز L1 ومئات الآلاف من رسوم غاز L2 لكل مستخدم.

بالنسبة لشجرة Verkle ، يمكن للمستخدمين استخدام Verkle multi-proof مباشرةً ، ويضيف كل مستخدم حوالي 100 ~ 200 بايت ، أو يمكنك عمل ZK-SNARK متعدد الإثبات من Verkle ، وتكلفته مماثلة لـ ZK-SNARK لفرع Merkle ، لكن الدليل يبدو رخيصًا بشكل واضح.

من وجهة نظر التنفيذ ، قد يكون من الأفضل السماح للمجمّعين بتجميع البراهين عبر السلاسل عبر معيار تجريد الحساب ERC-4337. يحتوي ERC-4337 بالفعل على آلية للبناة لتجميع أجزاء من عمليات المستخدم بطريقة مخصصة. يوجد أيضًا تطبيق لتجميع توقيع BLS ، والذي يمكن أن يقلل رسوم غاز L2 بمقدار 1.5x إلى 3x.

** قراءة الحالة مباشرة **

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

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

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

ومع ذلك ، إذا لم يتضمن L2 مكالمات L1 الثابتة ، أو إذا كان مخزن المفاتيح على L2 ، فإن الإثبات مطلوب.

** كيف يتعلم L2 أحدث جذر لحالة Ethereum؟ **

تتطلب جميع المخططات المذكورة أعلاه L2 للوصول إلى أقرب جذر حالة L1 أو أقرب حالة L1 بأكملها.

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

ومع ذلك ، يفضل أن يكون لكل L2 طريقة واضحة للوصول مباشرة إلى أحدث حالة L1 كاملة أو أقرب جذر حالة L1.

يتمثل التحدي الرئيسي في تحسين طريقة تلقي L2 لأحدث جذر حالة L1 في تحقيق الأمان وزمن انتقال منخفض في نفس الوقت:

• إذا كانت L2 بطيئة في تنفيذ وظيفة القراءة المباشرة L1 ، وقراءة جذر حالة L1 النهائي فقط ، فإن التأخير عادةً ما يكون 15 دقيقة ، ولكن في بعض الحالات القصوى ، يمكن أن يكون التأخير أسابيع.
• يمكن بالتأكيد تصميم L2 لقراءة جذور حالة L1 المحدثة ، ولكن نظرًا لأن L1 يمكن أن يتعافى (والذي يحدث أثناء التسريبات غير النشطة حتى مع نهائية المقبس الفردي) ، يحتاج L2 أيضًا إلى أن يكون قادرًا على التعافي. من منظور هندسة البرمجيات ، يعد هذا تحديًا تقنيًا.
• إذا تم استخدام جسر لجلب جذور حالة L1 إلى L2 ، فإن تحديثات الأصول تستغرق وقتًا طويلاً جدًا ، وفي أفضل الأحوال ، هناك مستخدمون دائمون يدفعون مقابل التحديثات ويحافظون على تحديث النظام لأي شخص آخر.
• لا تعد Oracles حلاً مقبولاً هنا: إدارة مفتاح المحفظة هي ميزة ذات مستوى منخفض للغاية من حيث الأمان ، لذا يجب أن تعتمد على عدد قليل جدًا من البنية التحتية منخفضة المستوى بسيطة للغاية وغير موثوق بها من الناحية المشفرة.

أيضًا ، في الاتجاه المعاكس (L1 يقرأ L2):

• في Optimistic Rollup ، يستغرق جذر الحالة أسبوعًا للوصول إلى L1 بسبب التأخير في إثبات الاحتيال. في مجموعات ZK ، يستغرق الأمر الآن ساعات بسبب مزيج من وقت التحقق والقيود الاقتصادية ، على الرغم من أن التكنولوجيا المستقبلية ستقلل من ذلك.
• التأكيد المسبق (من المُسلسِل ، المُصدق ، إلخ) ليس حلاً مقبولاً لقراءة L1 L2. تعد إدارة المحفظة وظيفة ذات مستوى منخفض للغاية من حيث الأمان ، لذا يجب أن يكون مستوى أمان الاتصال من L2 إلى L1 مرتفعًا للغاية. جذر الحالة الوحيد الذي يجب أن يثق به L1 هو الذي تم قبوله باعتباره جذر الحالة النهائية من خلال عقد عقد جذر حالة L1 على L1.

بعضها بطيء بشكل غير مقبول للعمليات غير الموثوقة عبر السلاسل للعديد من حالات استخدام DeFi. ومع ذلك ، بالنسبة لحالة استخدام تحديث مفاتيح المحفظة ، فإن التأخير الأطول أكثر قبولًا - لأنه بدلاً من تأخير المعاملات ، فإنه يؤخر تغييرات المفتاح.

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

في النهاية ، فإن أفضل حل لتقليل زمن الوصول هو جعل L2 ينفذ على النحو الأمثل قراءات مباشرة لجذر حالة L1 ، حيث تحتوي كل كتلة L2 (أو سجل حساب جذر الحالة) على مؤشر لأحدث كتلة L1 ، لذلك إذا تعافى L1 ، و L2 يمكن أن يتعافى كذلك. يجب وضع عقد keystore على mainnet أو على L2 من ZK-rollup بحيث يمكن الالتزام بسرعة بـ L1.

** ما مقدار الاتصال بـ Ethereum الذي تحتاجه السلسلة الأخرى للاحتفاظ بمخزن keystore في محفظة Ethereum أو L2؟ **

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

إذا كان L3 ، أو validium ، فلا بأس من تخزين المحافظ هناك ، طالما أن المستخدمين يخزنون تخزين المفاتيح على L1 أو ZK-rollup ، فهم بحاجة حقًا إلى الوصول المباشر إلى جذر حالة Ethereum ، وهم على استعداد لتخزين محافظهم على Ethereum عند إعادة بناء ديون ، هارد فورك عندما إيثريوم هارد فورك.

تتميز مخططات ZK المبنية على جسر بخصائص تقنية جذابة ، ولكن لديها نقطة ضعف رئيسية تتمثل في أنها ليست قوية ضد هجمات 51٪ أو الهارد فورك.

حماية الخصوصية

من الناحية المثالية ، يريد المستخدمون أيضًا الخصوصية. إذا كان لدى المستخدم العديد من المحافظ التي يديرها نفس مخزن المفاتيح ، فإنهم يريدون التأكد مما يلي:

• تجنّب معرفة الجمهور بأن هذه المحافظ كلها متصلة ببعضها البعض.
• لن يعرف أولياء الأمور على التعافي الاجتماعي عنوان الوصاية.

لكن هذا يخلق مشكلة:

• لا يمكننا استخدام البراهين Merkle مباشرة لأنها لا تحافظ على الخصوصية.
• إذا استخدمنا KZG أو SNARKs ، فسيحتاج الإثبات إلى توفير نسخة معماة من مفتاح التحقق دون الكشف عن موقع مفتاح التحقق.
• إذا استخدمنا التجميع ، فيجب ألا يعرف المُجمِّع الموقع بوضوح ؛ وبدلاً من ذلك ، يجب أن يتلقى المُجمِّع أدلة عمياء وأن يكون لديه طريقة لتجميع هذه البراهين.
• لا يمكننا استخدام "إصدار خفيف" (تصديق عبر السلاسل فقط عند إعادة إدخال المفاتيح) ، لأن هذا قد يؤدي إلى تسرب الخصوصية: إذا تم تحديث العديد من المحافظ في نفس الوقت بسبب المحدث ، فعندئذٍ توقيت هذه المحافظ قد تكون المعلومات ذات الصلة. لذلك ، يجب أن نستخدم "النسخة الكاملة" (دليل متسلسل لكل معاملة).

بالنسبة إلى SNARKs ، الحل بسيط من الناحية المفاهيمية: البراهين تخفي المعلومات بشكل افتراضي ، ويحتاج المجمّعون إلى إنتاج SNARKs متكررة لإثبات SNARKs.

التحدي الرئيسي الحالي مع هذا النهج هو أن التجميع يتطلب من المُجمِّع إنشاء SNARK العودي ، وهو بطيء نوعًا ما.

بالنسبة لـ KZG ، يمكننا استخدام عدم الفهرسة للكشف عن عمل برهان KZG. ومع ذلك ، فإن التجميع الأعمى مشكلة مفتوحة تتطلب مزيدًا من الاهتمام.

ومع ذلك ، في حين أن قراءة L1 مباشرة من داخل L2 لا تحمي الخصوصية ، فإن تنفيذ وظيفة القراءة المباشرة هذه سيظل مفيدًا للغاية - ليس فقط لتقليل زمن الوصول ، ولكن للعديد من حالات الاستخدام الأخرى.