المؤلف: Vitalik Buterin Compilation: Vernacular Blockchain

في مقالتي السابقة حول التحولات الثلاثة ، أوجزت بعض الأسباب الرئيسية التي تجعل من المفيد البدء بالتفكير صراحة في دعم L1 + cross-L2 وأمن المحفظة والخصوصية باعتبارها سمات أساسية ضرورية لمكدس النظام البيئي. يمكن تصميمها بشكل فردي بواسطة محفظة واحدة.

سيركز هذا المنشور بشكل مباشر أكثر على الجوانب الفنية لمشكلة فرعية معينة ، مثل: كيفية قراءة L1 بسهولة أكبر من L2 أو L2 من L1 أو L2 من L2 آخر. تعتبر معالجة هذه المشكلة أمرًا بالغ الأهمية لتمكين بنيات فصل الأصول / مخزن المفاتيح ، ولكن لديها أيضًا حالات استخدام قيّمة في مناطق أخرى ، وعلى الأخص تحسين سلاسل المكالمات عبر L2 الموثوقة ، بما في ذلك حالات الاستخدام مثل نقل الأصول بين L1 و L2. ** كتالوج هذا المقال ** ما هو الهدف؟ كيف يبدو الدليل المتقاطع؟ ما نوع مخطط الإثبات الذي يمكننا استخدامه؟ دليل ميركل ZK SNARKs شهادة KZG مخصصة دليل شجرة Verkle البلمرة قراءة الحالة المباشرة كيف يتعلم L2 أحدث جذر لحالة Ethereum؟ محافظ على سلاسل غير L2s حماية الخصوصية لخص

1. ما هو الهدف؟

بمجرد أن يصبح L2 سائدًا ، سيمتلك المستخدمون أصولًا عبر L2s متعددة ، وربما L1 أيضًا. بمجرد أن تصبح محافظ العقود الذكية (multisig أو الاسترداد الاجتماعي أو غير ذلك) سائدة ، ستتغير المفاتيح اللازمة للوصول إلى حسابات معينة بمرور الوقت ولن تكون المفاتيح القديمة بحاجة إلى أن تكون صالحة. بمجرد حدوث هذين الأمرين ، سيحتاج المستخدمون إلى طريقة لتغيير المفاتيح التي يمكنها الوصول إلى العديد من الحسابات الموجودة في العديد من الأماكن المختلفة دون إجراء عدد كبير جدًا من المعاملات. على وجه الخصوص ، نحن بحاجة إلى طريقة للتعامل مع العناوين غير الواقعية: العناوين التي لم يتم "تسجيلها" على السلسلة بأي شكل من الأشكال ، ولكنها لا تزال بحاجة إلى تلقي الأموال والاحتفاظ بها بشكل آمن. نعتمد جميعًا على العناوين المغايرة للواقع: عند استخدام Ethereum لأول مرة ، يمكنك إنشاء عنوان ETH يمكن لشخص ما استخدامه للدفع لك دون "تسجيل" العنوان على السلسلة (يتطلب هذا دفع رسوم txfee ، لذا تمتلك بالفعل بعض ETH). بالنسبة إلى EOA ، تبدأ جميع العناوين بعنوان غير واقعي. مع محافظ العقود الذكية ، لا تزال العناوين الواقعية ممكنة بفضل CREATE2 إلى حد كبير ، والذي يسمح لك بالحصول على عنوان ETH لا يمكن ملؤه إلا من خلال عقد ذكي برمز يطابق تجزئة معينة.

! [Aprx6619C0RKWypR8IvDnS15p0E7CekwuSR506Fu.png] (https://img.gateio.im/social/moments-40baef27dd-7deb37c94e-dd1a6f-62a40f "7054363")

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

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

! [lW50aExDpfi7AxsZTmeUXmvctJqoQOEall2aRroH.png] (https://img.gateio.im/social/moments-40baef27dd-c0773c167e-dd1a6f-62a40f "7054365")

هناك طريقتين لاداء ذلك:

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

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

2. كيف يبدو الإثبات عبر السلسلة؟

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

! [mFcDC57SfmM6ukDMLPTiulzhHoj3ovGykyS3erqq.png] (https://img.gateio.im/social/moments-40baef27dd-11797fe649-dd1a6f-62a40f "7054368")

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

• إثبات جذر حالة Linea الحالي ، مع الأخذ في الاعتبار جذر حالة Ethereum الحالي المعروف لكاكاروت
• إثبات للمفتاح الحالي في ملف تخزين المفاتيح ، بالنظر إلى جذر حالة Linea الحالي هناك نوعان من مشكلات التنفيذ الصعبة هنا:
• ما نوع الدليل الذي نستخدمه؟ (هل هو برهان ميركل؟ شيء آخر؟
• كيف يتعلم L2 أولاً أقرب جذر حالة L1 (Ethereum) (أو ، كما سنرى ، ربما حالة L1 الكاملة)؟ أو كيف يتعلم L1 جذور حالة L2؟ في كلتا الحالتين ، ما هي مدة التأخير بين ما يحدث في أحد الجانبين وما يمكن إثباته في الجانب الآخر؟

3. ما هي أنواع مخططات الإثبات التي يمكننا استخدامها؟

هناك خمسة خيارات رئيسية: -برهان العرجاء -العام ZK-SNARKs

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

! [QChCpk7vF9XJVLBnjaWrgsQj2V5F2W13XHrB1t3C.png] (https://img.gateio.im/social/moments-40baef27dd-c1a1fb55be-dd1a6f-62a40f "7054369")

يشير "التجميع" إلى تجميع جميع الأدلة المقدمة من المستخدمين داخل كل كتلة في إثبات ميتا واحد كبير يجمع كل البراهين. هذا ممكن مع SNARK و KZG ، ولكن ليس مع شوكات Merkle (يمكنك الجمع بين شوكات Merkle قليلاً ، ولكنها توفر لك فقط السجل (txs لكل كتلة) / السجل (إجمالي عدد ملفات تخزين المفاتيح) ، في الممارسة العملية ربما يكون 15-30٪ في المنتصف ، لذلك ربما لا يستحق السعر). يصبح التجميع مفيدًا فقط عندما يكون للسيناريو عدد كبير من المستخدمين ، لذلك من الناحية العملية ، يمكن أن يؤدي تنفيذ الإصدار 1 إلى حذف التجميع وتنفيذه في الإصدار 2.

4. كيف ستعمل براهين ميركل؟

هذا سهل: ما عليك سوى اتباع الرسم التخطيطي في القسم السابق. بتعبير أدق ، كل "دليل" (بافتراض حالة إثبات أقصى صعوبة من مستوى L2 إلى L2 آخر) سوف يحتوي على: فرع Merkle يشهد على جذر حالة L2 الذي يحتفظ بمخزن المفاتيح ، نظرًا لأحدث جذر حالة من Ethereum المعروف لـ L2. يحتفظ مخزن المفاتيح بجذر حالة L2 المخزن في فتحة تخزين معروفة في عنوان معروف (يمثل العقد الموجود على L1 L2) ، لذلك يمكن ترميز المسار عبر الشجرة. فرع Merkle يشهد على مفتاح التحقق الحالي ، بالنظر إلى جذر الحالة لـ L2 الذي يحتفظ بمخزن المفاتيح. هنا مرة أخرى ، يتم تخزين مفتاح المصادقة في فتحة تخزين معروفة في عنوان معروف ، لذلك يمكن أن يكون المسار مشفرًا. لسوء الحظ ، فإن Ethereum Proofs of State معقدة ، ولكن المكتبات موجودة للتحقق من صحتها ، وإذا كنت تستخدم هذه المكتبات ، فإن هذه الآلية ليست معقدة للغاية في التنفيذ. ** المشكلة الأكبر هي التكلفة. ** براهين Merkle طويلة جدًا ، وللأسف فإن شجرة باتريشيا أطول بحوالي 3.9 مرة من اللازم (على وجه الدقة: دليل Merkle المثالي لشجرة تحمل كائنات N يبلغ طولها 32 \ * log2 (N) بايت ، ولأن أشجار باتريشيا Ethereum لديها 16 ورقة لكل طفل ، والدليل على هذه الأشجار هو 32 \ * 15 \ * log16 (N) ~ = 125 \ * log2 (N) بايت طويلة). في حالة بها حوالي 250 مليون حساب (~ 2²⁸) ، فإن هذا يجعل كل برهان 125 \ * 28 = 3500 بايت ، أو حوالي 56000 غاز ، بالإضافة إلى التكلفة الإضافية لفك التشفير والتحقق من التجزئة. معًا ، سينتهي الاثنان بتكلفة حوالي 100000 إلى 150.000 غاز (إذا تم استخدامه لكل معاملة ، باستثناء التحقق من التوقيع) - أعلى بكثير من السعر الأساسي الحالي البالغ 21000 غاز لكل معاملة. ومع ذلك ، إذا تم التحقق من الدليل على المستوى 2 ، فإن التناقض يزداد سوءًا. يعد الحساب داخل L2 رخيصًا لأن الحساب يتم خارج السلسلة وفي نظام بيئي به عدد أقل بكثير من العقد L1. من ناحية أخرى ، يجب نشر البيانات إلى L1. لذا فإن المقارنة ليست 21 ألف غاز مقابل 15 ألف غاز ؛ إنها 21 ألف غاز L2 مقابل 100 ألف غاز L1. يمكننا حساب ما يعنيه هذا من خلال النظر إلى المقارنة بين تكلفة الغاز L1 وتكلفة الغاز L2:

! [Byb1nBD9GFmqUZfya6w68RN3uqYxZ5oP1pdQqapA.png] (https://img.gateio.im/social/moments-40baef27dd-ff1cddecd8-dd1a6f-62a40f "7054370")

حاليًا ، L1 أغلى بـ 15-25 مرة من L2 للإرسال البسيط و 20-50 مرة أكثر تكلفة لمبادلات الرموز. الإرسال البسيط هو كمية كبيرة نسبيًا من البيانات ، لكن مقدار التبادل الحسابي أكبر بكثير. لذلك ، تعتبر المقايضة معيارًا أفضل للتكلفة التقريبية لحساب L1 مقابل حساب L2. مع أخذ كل هذا في الاعتبار ، إذا افترضنا نسبة تكلفة 30x بين التكلفة الحسابية L1 والتكلفة الحسابية L2 ، يبدو أن هذا يعني أن تكلفة وضع إثبات Merkle على L2 يمكن أن تكون مساوية لـ 50 معاملة عادية. بالطبع ، يؤدي استخدام أشجار Merkle الثنائية إلى تقليل التكلفة بمعامل ~ 4 ، ولكن حتى ذلك الحين ، في معظم الحالات ، تكون التكلفة مرتفعة للغاية - إذا كنا على استعداد للتضحية بعدم التوافق مع شجرة الحالة السداسية الحالية لـ Ethereum ، فنحن نبحث عن خيارات أفضل.

5. كيف سيعمل برهان ZK-SNARK؟

من السهل أيضًا فهم استخدام ZK-SNARKs من الناحية المفاهيمية: ما عليك سوى استبدال براهين Merkle في الرسم التخطيطي أعلاه بإثباتات ZK-SNARK التي تثبت وجود هذه البراهين من Merkle. تتطلب ZK-SNARK 400000 غاز تقريبًا للحساب ، والتي تستغرق حوالي 400 بايت (مقارنة بـ: تتطلب المعاملة الأساسية 21000 غاز و 100 بايت ، والتي يمكن تقليلها إلى 25 كلمة تقريبًا بعد الضغط في المهرجان المستقبلي). لذلك ، من وجهة نظر حسابية ، فإن تكلفة ZK-SNARKs هي 19 ضعف تكلفة المعاملات الأساسية اليوم ، ومن وجهة نظر البيانات ، فإن تكلفة ZK-SNARKs هي 4 أضعاف تكلفة المعاملات الأساسية اليوم و 16 مرة تكلفة أوقات المعاملات الأساسية المستقبلية. هذه الأرقام هي تحسن كبير مقارنة بإثبات ميركل ، لكنها لا تزال باهظة الثمن. هناك طريقتان لتحسين هذا: (1) أدلة KZG ذات الأغراض الخاصة ، أو (2) التجميع ، على غرار تجميع ERC-4337 ولكن باستخدام الرياضيات الأكثر رواجًا. يمكننا دراسة كليهما في نفس الوقت.

6. كيف ستعمل براهين KZG ذات الأغراض الخاصة؟

تحذير ، هذا القسم رياضي أكثر من الأقسام الأخرى. هذا لأننا نتخطى أدوات الأغراض العامة ، ونبني بعضًا أرخص منها للأغراض الخاصة ، لذلك علينا أن نذهب "تحت غطاء المحرك" أكثر. إذا لم تكن الرياضيات العميقة هي الشيء الذي تفضله ، فانتقل مباشرة إلى القسم التالي. أولاً ، ملخص لكيفية عمل التزامات KZG: يمكننا تمثيل مجموعة من البيانات [D \ _1 ... D \ _n] باستخدام برهان KZG لكثير الحدود المشتق من البيانات: على وجه التحديد ، متعدد الحدود P ، حيث P (w) = D \ _1 ، P (w²) = D \ _2 ... P (wⁿ) = D \ _n. w هنا هو "الجذر الموحد" ، قيمة wN = 1 لبعض حجم مجال التقييم N (كل هذا يتم في حقول محدودة). للالتزام بـ P ، نقوم بإنشاء نقطة منحنى بيضاوي الشكل com (P) = P₀ \ * G + P₁ \ * S₁ + ... + Pk \ * Sk. هنا: -G هي نقطة توليد المنحنى -Pi هو معامل ith لكثير الحدود P -Si هي النقطة i في الإعداد الموثوق به لإثبات أن P (z) = a ، نقوم بإنشاء حاصل كثير الحدود Q = (P - a) / (X - z) ، وإنشاء التزام com (Q). من الممكن فقط إنشاء مثل هذا كثير الحدود إذا كانت P (z) تساوي بالفعل a. للتحقق من الإثبات ، نتحقق من المعادلة Q \ * (X - z) = P - a عن طريق إجراء فحص منحنى بيضاوي على الإثبات com (Q) والالتزام متعدد الحدود com (P): نتحقق من e (com (Q) ) ، كوم (X - z))؟ = 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) (أو التجزئة (com (L \ _i)) ، لذلك كلما يحتاج شخص ما عند تحديث شجرة السلسلة ، يمكنه ببساطة تقديم دليل على صحتها إلى com المناسب (L \ _i). لذلك لدينا هيكل يمكننا من خلاله الاستمرار في إضافة القيم إلى نهاية القائمة المتزايدة ، وإن كان ذلك مع وجود حد معين للحجم (في الواقع ، قد يكون من الممكن تحقيق مئات الملايين). ثم نستخدم هذا كهيكل بيانات خاص بنا لإدارة (1) الالتزامات بقائمة المفاتيح في كل L2 ، المخزنة على ذلك L2 والمنعكسة إلى L1 ، و (2) الالتزامات بقائمة التزام المفتاح L2 ، المخزنة على Ethereum L1 و ينعكس على كل L2. يمكن أن يكون تحديث الالتزامات جزءًا من منطق L2 الأساسي ، أو يتم تنفيذه عبر جسر الإيداع والسحب دون تغيير بروتوكول L2 الأساسي.

! [2In3vl05wne1uejML5EFsLGZefUPFuio7vwqEyHJ.png] (https://img.gateio.im/social/moments-40baef27dd-b5b508b148-dd1a6f-62a40f "7054371")

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

• يحتفظ keystore بأحدث com (قائمة المفاتيح) على L2 (48 بايت) -KZG يثبت أن com (قائمة المفاتيح) هو com (القيمة في المرآة \ _list) ، والالتزام بجميع قوائم إرسال قائمة المفاتيح (48 بايت)
• يثبت KZG أن مفتاحك موجود في com (قائمة المفاتيح) (48 بايت ، بالإضافة إلى 4 بايت للفهرس) من الممكن بالفعل دمج اثنتين من برهان KZG في واحد ، لذلك نحصل على الحجم الإجمالي 100 بايت فقط. لاحظ التفاصيل الدقيقة: نظرًا لأن قائمة المفاتيح هي قائمة وليست خريطة مفتاح / قيمة مثل الحالة ، يجب تخصيص مواضع لقائمة المفاتيح بالترتيب. سيحتوي عقد الالتزام الرئيسي على السجل الداخلي الخاص به ، مع تعيين كل مخزن مفاتيح لمعرف ، ولكل مفتاح ، سيتم تخزين التجزئة (عنوان مخزن المفاتيح) بدلاً من المفتاح فقط ، من أجل التواصل بشكل صريح مع L2s الأخرى التي يتم تخزين المفاتيح بها دخول معين يتحدث عنه. تكمن ميزة هذه التقنية في أنها تؤدي أداءً جيدًا للغاية في المستوى 2. البيانات 100 بايت ، وهي أقصر بـ 4 مرات من ZK-SNARKs وأقصر من براهين Merkle. تكلفة الحساب هي أساسًا فحص زوج واحد ، أو حوالي 119000 غاز. في L1 ، تعد البيانات أقل أهمية من الحساب ، لذلك للأسف ، تعد KZGs أغلى قليلاً من براهين Merkle.

7. كيف ستعمل شجرة Verkle؟

تتضمن أشجار Verkle بشكل أساسي تجميع التزامات KZG معًا (أو التزامات IPA ، والتي يمكن أن تكون أكثر كفاءة وتستخدم تشفيرًا أبسط): لتخزين قيم 2⁴⁸ ، فإنك تلتزم KZG بقائمة من قيم 2²⁴ ، كل منها هو في حد ذاته التزام KZG بـ 2²⁴ القيمة. تعتبر أشجار Verkle بشدة لأشجار ولاية Ethereum ، لأنه يمكن استخدام أشجار Verkle لإجراء تعيينات قيمة المفتاح ، وليس القوائم فقط (في الأساس ، يمكنك إنشاء شجرة بحجم 2²⁵⁶ ولكن تبدأ فارغة ، فقط إذا قمت بملء أجزاء معينة من شجرة عندما تحتاج بالفعل لملئها).

! [mRvhYA6NB4YbDQSuqD8YBm8I6mvsm1fdJ8wJ9OP3.png] (https://img.gateio.im/social/moments-40baef27dd-1c259f1ce7-dd1a6f-62a40f "7054372")

كيف تبدو شجرة فيكر. في الواقع ، يمكنك إعطاء كل عقدة عرض 256 == 2⁸ للأشجار القائمة على IPA و 2²⁴ للأشجار القائمة على KZG. البراهين في أشجار Verkle أطول إلى حد ما مما كانت عليه في KZG ؛ يمكن أن يصل طولها إلى مئات البايتات. يصعب أيضًا التحقق منها ، خاصة إذا حاولت تجميع العديد من البراهين في واحدة. في الواقع ، يجب اعتبار أشجار Verkle مثل أشجار Merkle ، ولكن أكثر جدوى من دون التشويش (بسبب انخفاض تكلفة البيانات) ، و SNARKing أرخص (بسبب انخفاض تكلفة الإثبات). أكبر ميزة لأشجار Verkle هي أنها يمكن أن تنسق هياكل البيانات: يمكن استخدام البراهين Verkle مباشرة لحالات L1 أو L2 ، وليس لها بنية تراكب ، وتستخدم نفس الآلية تمامًا لـ L1 و L2. بمجرد أن تصبح أجهزة الكمبيوتر الكمومية مشكلة ، أو بمجرد أن يثبت تفرّع Merkle فعاليته الكافية ، يمكن استبدال أشجار Verkle في مكانها بأشجار تجزئة ثنائية بوظائف التجزئة الملائمة لـ SNARK.

8. المجاميع

إذا احتاج N من المستخدمين الذين أجروا معاملات N (أو بشكل أكثر واقعية ، N ERC-4337 UserOperations) إلى إثبات مطالبات عبر سلسلة N ، فيمكننا توفير الكثير من المال من خلال تجميع هذه الأدلة: دمج هذه المعاملات في كتلة أو منشئ الحزمة يمكن أن يؤدي ذلك إلى إنشاء دليل يثبت كل هذه الادعاءات في نفس الوقت. قد يعني هذا:

• البراهين ZK-SNARK لفروع N Merkle
• جهاز KZG متعدد الإثبات
• مضاد Verkle متعدد (أو مضاد متعدد ZK-SNARK) في جميع الحالات الثلاث ، لا يتطلب كل دليل سوى بضع مئات الآلاف من الغاز. يحتاج المنشئ إلى إنشاء واحدة من هذه في كل L2 للمستخدمين في ذلك L2 ؛ وبالتالي ، لسهولة الإنشاء ، يجب استخدام المخطط بأكمله بشكل كافٍ بحيث يكون هناك عادةً عدد قليل من المعاملات في نفس الكتلة في تجارة L2s رئيسية متعددة . إذا تم استخدام ZK-SNARKs ، فإن التكلفة الهامشية الرئيسية هي مجرد "منطق العمل" لتمرير الأرقام بين العقود ، لذلك قد يحتاج كل مستخدم إلى عدة آلاف من غاز L2. إذا تم استخدام KZG multi-proof ، يحتاج المُثبِّت إلى إضافة 48 غازًا لكل مخزن مفاتيح يحمل L2 المستخدم داخل الكتلة ، وبالتالي فإن التكلفة الهامشية للنظام لكل مستخدم ستكون لكل L2 (ليس لكل مستخدم) ثم تمت إضافة غاز ~ 800 L1 . لكن هذه التكاليف أقل بكثير مما هي عليه بدون التجميع ، والتي تنطوي حتما على أكثر من 10000 غاز L1 ومئات الآلاف من غاز L2 لكل مستخدم. بالنسبة لأشجار Verkle ، يمكنك استخدام Verkle multi-proofs مباشرةً ، بإضافة حوالي 100-200 بايت لكل مستخدم ، أو يمكنك إنشاء ZK-SNARKs من Verkle متعدد البروفات ، والتي تكلف بشكل مشابه لـ ZK-SNARKs لفرع Merkle ، ولكن الدليل تكاليف أقل بكثير. من وجهة نظر التنفيذ ، من الأفضل للمجمّعين تجميع البراهين عبر السلاسل من خلال معيار تجريد الحساب ERC-4337. يحتوي ERC-4337 بالفعل على آلية للبناة لتجميع أجزاء من إجراءات المستخدم بطريقة مخصصة. حتى أن هناك تطبيقًا لتجميع توقيع BLS ، والذي يمكن أن يقلل تكاليف الغاز على L2 بعامل من 1.5 إلى 3 ، اعتمادًا على أشكال الضغط الأخرى المضمنة.

! [oxeYy0EtfGLg1F2UMJ3TgOJhNwBa3VbcyNHTzD1z.png] (https://img.gateio.im/social/moments-40baef27dd-28eca75ea3-dd1a6f-62a40f "7054373")

رسم تخطيطي من منشور تنفيذ محفظة BLS يوضح سير العمل للتوقيعات المجمعة لـ BLS في إصدار مبكر من ERC-4337. قد يبدو سير العمل لتجميع البراهين عبر السلسلة متشابهًا جدًا.

9. قراءة الحالة المباشرة

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

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

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

• إذا نفذت L2 وظيفة "قراءة L1 مباشرة" بطريقة كسولة ، وقراءة جذر حالة L1 النهائي فقط ، فإن التأخير عادةً ما يكون 15 دقيقة ، ولكن في الحالات القصوى لتسريبات الخمول (التي يتعين عليك تحملها) ، يمكن أن يكون التأخير أسابيع.
• يمكن بالتأكيد تصميم L2 لقراءة جذور حالة L1 المحدثة ، ولكن نظرًا لأن L1 يمكن أن يتعافى (والذي يحدث أثناء التسريبات غير النشطة حتى مع نهائية المقبس الفردي) ، يجب أن يكون L2 قادرًا على التعافي أيضًا. من وجهة نظر هندسة البرمجيات ، يعد هذا تحديًا تقنيًا ، ولكن على الأقل يتمتع Optimistic بالقدرة.
• إذا كنت تستخدم جسر إيداع لجلب جذور حالة L1 إلى L2 ، فقد يتطلب الاقتصاد البسيط وقتًا طويلاً بين تحديثات الإيداع: إذا كانت التكلفة الكاملة للإيداع 100000 غاز ، فلنفترض 1800 دولارًا في ETH ورسمًا قدره 200 gwei ، وجذور L1 تدخل L2 مرة واحدة في اليوم ، وهذا سيكلف 236 دولارًا لكل لتر في اليوم ، أو 13148 دولارًا لكل L2 سنويًا للحفاظ على النظام. تكلف ساعة التأخير 315،569 دولارًا أمريكيًا لكل L2 سنويًا. في أفضل الأحوال ، هناك تدفق مستمر من المستخدمين الأثرياء الذين نفد صبرهم والذين يدفعون مقابل تحديث النظام وتحديثه لأي شخص آخر. في أسوأ الأحوال ، سيتعين على بعض الفاعلين الإيثاريين أن يدفعوا ثمن ذلك بأنفسهم.
• "Oracles" (على الأقل التكنولوجيا التي يسميها بعض الأشخاص في DeFi "oracles") ليست حلاً مقبولاً هنا: إدارة مفتاح المحفظة هي وظيفة ذات مستوى منخفض للغاية من حيث الأمان ، لذا يجب أن تعتمد على الأكثر على عدة أ بسيطة جدًا ، بنية أساسية منخفضة المستوى لا تتطلب ثقة تشفير. أيضًا ، في الاتجاه المعاكس (يقرأ L1s كـ L2):
• في Optimistic Aggregation ، تستغرق جذور الدولة أسبوعًا للوصول إلى L1 بسبب التأخير في إثبات الاحتيال. في مجموعات ZK ، يستغرق الأمر الآن ساعات بسبب مزيج من وقت التحقق والقيود الاقتصادية ، على الرغم من أن التكنولوجيا المستقبلية ستقلل من ذلك.
• التأكيد المسبق (من منظم التسلسل ، الموثق ، إلخ) ليس حلاً مقبولاً للقراءة L1 L2. إدارة المحفظة هي وظيفة ذات مستوى منخفض للغاية من حيث الأمان ، لذا يجب أن يكون مستوى الأمان لاتصالات L2 - L1 مطلقًا: ليس من الممكن حتى دفع جذر حالة L1 خاطئ من خلال تولي مجموعة مدقق L2. جذر الحالة الوحيد الذي يجب أن يثق به L1 هو الذي تم قبوله باعتباره جذر الحالة النهائية من خلال عقد عقد جذر حالة L1 على L1. بالنسبة للعديد من حالات استخدام DeFi ، يكون بعضها بطيئًا بشكل غير مقبول لعمليات عبر السلاسل غير الموثوق بها ؛ في هذه الحالات ، تحتاج حقًا إلى جسور أسرع مع المزيد من نماذج الأمان غير الكاملة. ومع ذلك ، في حالة استخدام تحديث مفاتيح المحفظة ، فإن التأخيرات الأطول أكثر قبولًا: فبدلاً من تأخير المعاملات لساعات ، فإنك تقوم بتأخير تغييرات المفتاح. تحتاج فقط إلى الاحتفاظ بالمفتاح القديم لفترة أطول. إذا قمت بتغيير مفتاحك لأنه سُرق ، فأنت تعاني من ثغرة أمنية لفترة طويلة ، ولكن يمكن تخفيفها ، على سبيل المثال. عبر محفظة مع وظيفة التجميد. في النهاية ، أفضل حل لتقليل زمن الوصول هو جعل L2 ينفذ على النحو الأمثل قراءات مباشرة لجذر حالة L1 ، حيث تحتوي كل كتلة L2 (أو سجل حساب جذر الحالة) على مؤشر لأحدث كتلة L1 ، لذلك إذا تعافى L1 ، و L2 يمكن أن يتعافى كذلك. يجب وضع عقود Keystore على mainnet أو على L2 من ZK Rollup بحيث يمكن الالتزام بسرعة بـ L1.

! [GbGQTaEGhOoBoi5Tpp6I1A4Rx8PSFhPGoT1R87ZC.png] (https://img.gateio.im/social/moments-40baef27dd-e9c54e3e46-dd1a6f-62a40f "7054374")

يمكن أن تعتمد كتل سلسلة L2 ليس فقط على كتل L2 السابقة ، ولكن أيضًا على كتل L1. إذا تعافى L1 عبر مثل هذا الارتباط ، فسوف يتعافى L2 أيضًا. من الجدير بالذكر أن هذه هي أيضًا الطريقة التي تم بها تصور الإصدارات السابقة (pre-Dank) من التجزئة للعمل ؛ انظر هنا للحصول على الكود.

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

من المستغرب ، ليس هذا العدد الكبير. لا يحتاج الأمر إلى أن يكون تراكميًا في الواقع: إذا كان L3 أو التحقق من الصحة ، فلا بأس من الاحتفاظ بالمحفظة هناك ، طالما أنك تحتفظ بمخزن المفاتيح في L1 أو ZK rollup. ما تحتاجه حقًا هو السلسلة للوصول المباشر إلى جذر حالة Ethereum ، والتزام تقني واجتماعي لتكون على استعداد لإعادة التنظيم إذا أعادت Ethereum تنظيم ، و Hard fork إذا كان Ethereum هارد فورك. من الأسئلة البحثية المثيرة للاهتمام تحديد المدى الذي يمكن أن يكون لسلسلة ما فيه هذا الشكل من الاتصال مع سلاسل أخرى متعددة (مثل Ethereum و Zcash). يمكن القيام بذلك بسذاجة: إذا أعيد تنظيم Ethereum أو Zcash ، يمكن لسلسلتك الموافقة على إعادة التنظيم (وهارد فورك إذا كان Ethereum أو Zcash hard forks) ، لكن مشغلي العقدة ومجتمعك عادة ما يكون لديهم تبعيات تكنولوجية وسياسية مرتين. لذلك ، يمكن استخدام هذه التقنية للاتصال ببعض السلاسل الأخرى ، ولكن بتكلفة متزايدة. تتميز مخططات ZK المبنية على جسر بخصائص تقنية جذابة ، ولكن نقطة ضعفها الرئيسية هي أنها ليست قوية بنسبة 51٪ من الهجمات أو الهارد فورك. قد تكون هناك حلول أكثر ذكاءً أيضًا.

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

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

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

! [yrW7UPhndSkx5MiegIH0LVCvfbWhbBRPlfOxuDdy.png] (https://img.gateio.im/social/moments-40baef27dd-8e4f32459a-dd1a6f-62a40f "7054375")

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

13. ملخص

للحصول على محفظة استرداد اجتماعية عبر سلسلة ، فإن سير العمل الأكثر واقعية هو المحفظة التي تحتفظ بمخزن مفاتيح في مكان واحد ، ومحفظة تحتفظ بالمحافظ في العديد من المواقع ، حيث تقرأ المحفظة مخزن المفاتيح (i) لتحديث مفتاح المصادقة محليًا عرض ، أو (2) في عملية التحقق من صحة كل معاملة. العنصر الأساسي الذي يجعل هذا ممكنًا هو البراهين المتقاطعة. نحن بحاجة إلى العمل على تحسين هذه البراهين. يبدو أن ZK-SNARKs أو حلول KZG المخصصة التي تنتظر إثبات Verkle هي أفضل الخيارات. على المدى الطويل ، يعد بروتوكول التجميع (حيث تقوم الحزم بإنشاء أدلة مجمعة كجزء من إنشاء حزمة من جميع إجراءات المستخدم المرسلة من قبل المستخدمين) ضروريًا لتقليل التكاليف. من المحتمل أن يتم دمج هذا في النظام البيئي ERC-4337 ، على الرغم من أن التغييرات في ERC-4337 قد تكون مطلوبة. يجب تحسين L2 لتقليل زمن انتقال قراءة حالة L1 (أو على الأقل جذر الحالة) من داخل L2. إنه مثالي لـ L2s لقراءة حالة L1 مباشرة ، مما يوفر مساحة إثبات. لا يمكن أن تكون المحافظ على L2 فقط ، بل يمكنك أيضًا وضع محافظ على أنظمة ذات مستوى أقل من الاتصال بـ Ethereum (L3 ، أو حتى الموافقة فقط على تضمين جذر حالة Ethereum وسلسلة مفترقات مستقلة). ومع ذلك ، يجب أن يكون مخزن المفاتيح على L1 أو ZK rollup L2 عالي الأمان. يوفر استخدام L1 الكثير من التعقيد ، ولكن حتى ذلك يمكن أن يكون مكلفًا للغاية على المدى الطويل ، لذلك يجب استخدام مخزن المفاتيح في L2. سيتطلب الحفاظ على الخصوصية عملاً إضافيًا ويجعل خيارات معينة أكثر صعوبة. ولكن ربما ينبغي علينا اللجوء إلى حلول الحفاظ على الخصوصية على أي حال ، على الأقل التأكد من أن كل ما توصلنا إليه متوافق مع الحفاظ على الخصوصية.