شكر خاص ليوآف فايس، ودان فينلي، ومارتن كوبلمان، وفرق Arbitrum، وOptimism، وPolygon، وScroll، وSoulWallet على التعليقات والمراجعة.

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

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

يوصى بالقراءة المسبقة

• وظيفة على التحولات الثلاثة
• أفكار من فريق Safe بشأن الاحتفاظ بالأصول عبر سلاسل متعددة
• لماذا نحتاج إلى اعتماد محافظ التعافي الاجتماعيعلى نطاق واسع؟
• ZK-SNARKs وبعض تطبيقات الخصوصية
• Dankrad على التزامات KZG
• أشجار فيركلي

جدول المحتويات

• ما هو الهدف؟
• كيف يبدو الدليل عبر السلسلة؟
• ما هي أنواع مخططات الإثبات التي يمكننا استخدامها؟
  • البراهين ميركل
  • ZK سناركس
  • البراهين KZG للأغراض الخاصة
  • البراهين شجرة Verkle
  • تجميع
  • قراءة الحالة المباشرة
• كيف يتعلم L2 جذر حالة Ethereum الأخير؟
• محافظ على سلاسل ليست L2s
• الحفاظ على الخصوصية
• الملخص

ما هو الهدف؟

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

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

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

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

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

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

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

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

كيف يبدو الدليل عبر السلسلة؟

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

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

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

هناك سؤالان أساسيان صعبان بشأن التنفيذ هنا:

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

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

هناك خمسة خيارات رئيسية:

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

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

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

يصبح التجميع يستحق العناء فقط عندما يكون لدى المخطط عدد كبير من المستخدمين، لذلك من الناحية الواقعية، من المقبول أن يترك تطبيق الإصدار 1 التجميع خارجًا، وينفذ ذلك للإصدار 2.

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

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

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

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

المشكلة الأكبر هي التكلفة. تعد براهين Merkle طويلة، ولسوء الحظ فإن أشجار باتريشيا أطول بمقدار 3.9 مرة تقريبًا من اللازم (على وجه التحديد: يبلغ طول إثبات Merkle المثالي في شجرة تحتوي على كائنات N 32 log2(N) بايت، ولأن أشجار باتريشيا في Ethereum تحتوي على 16 ورقة لكل طفل، فإن البراهين لهذه الأشجار 32 15 log16(N) ~= 125 log2(N) بايت طويلة). في حالة بها ما يقرب من 250 مليون (~2²⁸) حساب ، هذا يجعل كل إثبات 125 * 28 = 3500 بايت، أو حوالي 56000 غاز، بالإضافة إلى تكاليف إضافية لفك التشفير والتحقق من التجزئة.

سينتهي الأمر بتكلفة اثنين من الأدلة معًا بحوالي 100.000 إلى 150.000 غاز (لا يشمل التحقق من التوقيع إذا تم استخدام ذلك لكل معاملة) - وهو أكثر بكثير من القاعدة الحالية البالغة 21.000 غاز لكل معاملة. لكن التفاوت يزداد سوءًا إذا تم التحقق من الدليل على L2. تعتبر العمليات الحسابية داخل L2 رخيصة، لأن العمليات الحسابية تتم خارج السلسلة وفي نظام بيئي به عقد أقل بكثير من L1. ومن ناحية أخرى، يجب نشر البيانات إلى L1. وبالتالي فإن المقارنة ليست 21000 غاز مقابل 150000 غاز؛ إنه 21000 لتر غاز مقابل 100000 لتر غاز.

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

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

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

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

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

تمثل هذه الأرقام تحسينًا هائلاً مقارنةً بإثباتات ميركل، لكنها لا تزال باهظة الثمن. هناك طريقتان لتحسين هذا: (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 هنا هو "جذر الوحدة"، وهي قيمة حيث wᴺ = 1 لبعض حجم مجال التقييم N (يتم كل هذا في حقل محدود).
• "للالتزام" بـ P، نقوم بإنشاء نقطة منحنى إهليلجي com(P) = P₀ G + P₁ S₁ + … + Pₖ * Sₖ. هنا:
  • G هي نقطة المولد للمنحنى
  • Pᵢ هو معامل الدرجة الأولى لكثيرة الحدود P
  • Sᵢ هي النقطة الأولى في الإعداد الموثوق به
• لإثبات 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) , com(X - z)) ?= e(com(P) - com(a), com(1))

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

• والدليل هو فقط قيمة com(Q)، وهي 48 بايت
• كوم (P₁) + كوم (P₂) = كوم (P₁ + P₂)
• ويعني هذا أيضًا أنه يمكنك "تحرير" قيمة ما في التزام حالي. لنفترض أننا نعلم أن D_i حاليًا هو a، ونريد تعيينه على b، والالتزام الحالي بـ D هو com(P). التزام بـ "P، ولكن مع P(wⁱ) = b، ولم تتغير التقييمات الأخرى"، ثم قمنا بتعيين com(new_P) = com(P) + (ba) * com(Lᵢ)، حيث Lᵢ هو " لاغرانج متعدد الحدود" الذي يساوي 1 عند wⁱ و0 عند نقاط w الأخرى.
• لإجراء هذه التحديثات بكفاءة، يمكن حساب جميع التزامات N تجاه متعددات حدود Lagrange (com(Lᵢ)) مسبقًا وتخزينها بواسطة كل عميل. داخل عقد على السلسلة، قد يكون تخزين جميع التزامات N أكثر من اللازم، لذلك يمكنك بدلاً من ذلك الالتزام بـ KZG لمجموعة قيم com(L_i) (أو hash(com(L_i)) ، لذلك عندما يحتاج شخص ما إلى التحديث الشجرة الموجودة على السلسلة يمكنهم ببساطة تقديم com(L_i) المناسب مع إثبات صحته.

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

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

وبالتالي فإن الدليل الكامل يتطلب ما يلي:

• أحدث com (قائمة المفاتيح) على L2 الذي يحتفظ بمخزن المفاتيح (48 بايت)
• دليل KZG على أن com (قائمة المفاتيح) هي قيمة داخل com (mirror_list)، والالتزام بقائمة جميع التزامات القائمة الرئيسية (48 بايت)
• إثبات KZG لمفتاحك في com (قائمة المفاتيح) (48 بايت، بالإضافة إلى 4 بايت للفهرس)

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

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

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

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

تتضمن أشجار Verkle بشكل أساسي تكديس التزامات KZG (أو التزامات IPA ، والتي يمكن أن تكون أكثر كفاءة وتستخدم تشفيرًا أبسط) فوق بعضها البعض: لتخزين قيمتين، يمكنك الالتزام KZG بقائمة مكونة من قيمتين²⁴، كل واحدة منها بحد ذاتها هو التزام KZG بقيم 2²⁴. يتم استخدام أشجار Verkle<a href="https://notes.ethereum.org/ @vbuterin /verkle_tree_eip">بقوة تم اعتبارها مناسبة لشجرة حالة Ethereum، نظرًا لأنه يمكن استخدام أشجار Verkle للاحتفاظ بخرائط القيمة الرئيسية وليس القوائم فقط (في الأساس، يمكنك إنشاء شجرة بحجم 2²⁵⁶ لكن ابدأها فارغة، ولا تملأ سوى أجزاء محددة من الشجرة بمجرد بحاجة لملئها).

كيف تبدو شجرة فيركلي. من الناحية العملية، يمكنك إعطاء كل عقدة عرضًا قدره 256 == 2⁸ للأشجار المستندة إلى IPA، أو 2²⁴ للأشجار المستندة إلى KZG.

البراهين في أشجار Verkle أطول إلى حد ما من KZG؛ قد يصل طولها إلى بضع مئات من البايتات. كما أنه من الصعب التحقق منها، خاصة إذا حاولت تجميع العديد من الأدلة في دليل واحد.

من الناحية الواقعية، ينبغي اعتبار أشجار Verkle مثل أشجار Merkle، ولكنها أكثر قابلية للحياة بدون SNARKing (بسبب انخفاض تكاليف البيانات)، وأرخص مع SNARKing (بسبب انخفاض تكاليف الإثبات).

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

تجميع

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

هذا يمكن أن يعني:

• دليل ZK-SNARK على فروع N Merkle
• KZG متعدد الإثبات
• Verkle multi-proof (أو ZK-SNARK لـ multi-proof)

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

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

من منظور التنفيذ، ربما يكون من الأفضل أن تقوم أدوات التجميع بتجميع البراهين عبر السلسلة من خلال معيار تجريد حساب ERC-4337 . لدى ERC-4337 بالفعل آلية للمنشئين لتجميع أجزاء من عمليات المستخدم بطرق مخصصة. يوجد أيضًا <a href="https://hackmd.io/@voltrevo/BJ0QBy3zi"> تنفيذ لهذا لتجميع التوقيع BLS، والذي يمكن أن يقلل تكاليف الغاز على L2 بمقدار 1.5x إلى 3x اعتمادًا على أشكال الضغط الأخرى يتم تضمينها.

رسم تخطيطي من <a href="https://hackmd.io/@voltrevo/BJ0QBy3zi"> منشور تنفيذ محفظة BLS يوضح سير عمل التوقيعات المجمعة لـ BLS ضمن إصدار سابق من ERC-4337. من المرجح أن يبدو سير العمل لتجميع البراهين عبر السلسلة متشابهًا جدًا.

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

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

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

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

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

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

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

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

• إذا نفذت L2s وظيفة "القراءة المباشرة لـ L1" بطريقة كسولة، وقراءة فقط جذور حالة L1 النهائية، فسيكون التأخير عادةً 15 دقيقة، ولكن في الحالة القصوى من تسربات عدم النشاط (التي يتعين عليك تحملها)، قد يكون التأخير تكون عدة أسابيع.
• يمكن تصميم L2s بالتأكيد لقراءة جذور حالة L1 الأكثر حداثة، ولكن نظرًا لأن L1 يمكن أن تعود (حتى مع نهائية الفتحة الواحدة ، يمكن أن تحدث العودة أثناء تسرب عدم النشاط)، يجب أن تكون L2 قادرة على العودة أيضًا. يعد هذا تحديًا تقنيًا من منظور هندسة البرمجيات، ولكن على الأقل تمتلك شركة Optimism هذه القدرة بالفعل.
• إذا كنت تستخدم جسر الإيداع لجلب جذور حالة L1 إلى L2، فإن الجدوى الاقتصادية البسيطة قد تتطلب وقتًا طويلاً بين تحديثات الودائع: إذا كانت التكلفة الكاملة للإيداع هي 100000 غاز، ونفترض أن سعر ETH هو 1800 دولار، والرسوم عند يتم إحضار 200 جيجاوي وجذور L1 إلى L2 مرة واحدة يوميًا، وستكون التكلفة 36 دولارًا لكل L2 يوميًا، أو 13148 دولارًا لكل L2 سنويًا لصيانة النظام. مع تأخير لمدة ساعة واحدة، يصل ذلك إلى 315,569 دولارًا لكل L2 سنويًا. في أفضل الأحوال، يقوم عدد قليل من المستخدمين الأثرياء غير الصبر بتغطية رسوم التحديث والحفاظ على تحديث النظام للجميع. وفي أسوأ الحالات، سيتعين على بعض الجهات الفاعلة الإيثارية أن تدفع ثمنها بنفسها.
• "Oracles" (على الأقل، نوع التكنولوجيا التي يسميها بعض الأشخاص "Oracles") ليست حلاً مقبولاً هنا: إدارة مفاتيح المحفظة هي وظيفة منخفضة المستوى ذات أهمية أمنية كبيرة، ولذلك يجب أن تعتمد على أكثر من قطع قليلة من البنية التحتية منخفضة المستوى البسيطة جدًا وغير الموثوقة من الناحية التشفيرية.

بالإضافة إلى ذلك، في الاتجاه المعاكس (قراءة L1 L2):

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

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

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

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

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

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

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

الحفاظ على الخصوصية

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

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

وهذا يخلق بعض القضايا:

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

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

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

مع KZG، يمكننا استخدام<a href="https://notes.ethereum.org/ @vbuterin /non_index_revealing_proof">هذا العمل على براهين KZG غير الكاشفة للمؤشر (انظر أيضًا: نسخة أكثر رسمية من هذا العمل في ورقة Caulk ) كنقطة بداية. ومع ذلك، فإن تجميع البراهين العمياء يمثل مشكلة مفتوحة تتطلب المزيد من الاهتمام.

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

الملخص

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

تنصل:

1. تمت إعادة طبع هذا المقال من [فيتاليك]، جميع حقوق الطبع والنشر مملوكة للمؤلف الأصلي [فيتاليك بوتيرين]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسوف يتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء والآراء الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ أو توزيع أو سرقة المقالات المترجمة.