عندما تتحول Ethereum من تقنية تجريبية شابة إلى مجموعة تقنية ناضجة يمكنها حقًا تقديم تجربة مفتوحة وعالمية وغير مصرح بها للمستخدمين العاديين ، فإن المكدس يحتاج إلى المرور بثلاثة تحولات تكنولوجية رئيسية ، في وقت واحد تقريبًا:
تحول الحجم L2 - تم ترحيل الكل إلى المجموعات
تحول أمان المحفظة - يتم ترحيل الكل إلى محافظ العقد الذكية
تحول الخصوصية - ضمان تحويل الأموال الذي يحافظ على الخصوصية والتأكد من أن جميع الأدوات الأخرى التي يتم تطويرها (الاسترداد الاجتماعي والهوية والسمعة) تحافظ على الخصوصية
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات لـ L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-7d69f32cee-dd1a6f-62a40f)
هذا هو مثلث تحول النظام البيئي. يمكنك فقط اختيار 3 من 3.
بدون الأول ، ستفشل Ethereum لأن كل معاملة ستكلف 3.75 دولارًا (82.48 دولارًا إذا كان لدينا صعود صعودي آخر) ، وكل منتج في السوق الشامل سينسى في النهاية السلسلة ، واتخاذ حل مركزي لكل شيء.
بدون الثانية ، ستفشل Ethereum لأن المستخدمين سيكونون مترددين في تخزين أموالهم (والأصول غير المالية) وسينتقل الجميع إلى التبادلات المركزية.
بدون الثلث ، ستفشل Ethereum ، حيث ستكون جميع المعاملات (و POAPs ، وما إلى ذلك) عامة ليراها أي شخص ، وهو ما سيكون تضحية باهظة بالخصوصية للعديد من المستخدمين ، وسيتحرك الجميع للحصول على بعض البيانات المخفية على الأقل مركزية حل.
للأسباب المذكورة أعلاه ، تعتبر هذه التحولات الثلاثة حاسمة. لكنها أيضًا تمثل تحديًا بسبب التنسيق المكثف المطلوب لحلها. لا تحتاج وظائف البروتوكول إلى التحسين فحسب ، بل هناك حالات تحتاج فيها إلى إجراء تغييرات أساسية إلى حد ما على الطريقة التي نتفاعل بها مع Ethereum ، مما يتطلب تغييرات عميقة في التطبيقات والمحافظ.
ستحدث هذه التحولات الثلاثة ثورة في العلاقة بين المستخدمين والعناوين
في عالم يمتد إلى L2 ، سيكون المستخدمون موجودين في العديد من L2s. هل أنت عضو في موقع ExampleDAO الذي يعمل على التفاؤل؟ إذن لديك حساب على التفاؤل! هل تمتلك CDP في نظام ZkSync's Stablecoin؟ إذن لديك حساب على ZkSync! هل جربت بعض التطبيقات الموجودة على Kakarot؟ إذن لديك حساب على Kakarot! لقد ولت الأيام التي كان لدى المستخدمين فيها عنوان واحد فقط.
لديّ ETH في أربعة أماكن ، وفقًا لعرض Brave Wallet. نعم ، يختلف Arbitrum و Arbitrum Nova. لا تقلق ، سيصبح الأمر أكثر تعقيدًا بمرور الوقت!
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات من L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-dec7e7bb30-dd1a6f-62a40f)
تضيف محافظ العقود الذكية مزيدًا من التعقيد ، مما يجعل من الصعب الحصول على نفس العنوان على L1 ومختلف L2s. اليوم ، يستخدم معظم المستخدمين حسابات مملوكة خارجيًا تكون عناوينها في الواقع تجزئة المفتاح العام المستخدم للتحقق من التوقيع - لذلك لا شيء يتغير بين L1 و L2. ومع ذلك ، مع محافظ العقود الذكية ، يصبح الحفاظ على العنوان أكثر صعوبة. في حين تم إنجاز الكثير من العمل في محاولة جعل العناوين تجزئة من الرمز المكافئ عبر الشبكة ، ولا سيما مصانع CREATE2 و ERC-2470 المفردة ، كان من الصعب جدًا القيام بذلك بشكل مثالي. بعض L2s (مثل "النوع 4 ZK-EVMs") ليست مكافئة تمامًا لمعدات EVM ، وعادة ما تستخدم Solidity أو تجميع وسيط بدلاً من ذلك ، مما يمنع تكافؤ التجزئة. حتى لو كان لديك معادلة التجزئة ، فإن إمكانية تغيير الملكية من خلال التغييرات الرئيسية لها عواقب أخرى غير بديهية.
تتطلب الخصوصية مزيدًا من العناوين لكل مستخدم ، وقد تغير أيضًا أنواع العناوين التي نتعامل معها. إذا تم استخدام اقتراح العنوان الخاص على نطاق واسع ، فبدلاً من بضعة عناوين فقط لكل مستخدم ، أو عنوان واحد لكل L2 ، فقد يكون هناك عنوان واحد لكل معاملة. تعمل مخططات الخصوصية الأخرى ، حتى تلك الموجودة مثل Tornado Cash ، على تغيير كيفية تخزين الأصول بشكل مختلف: يتم تخزين أموال العديد من المستخدمين في نفس العقد الذكي (وبالتالي في نفس العنوان). لإرسال أموال إلى مستخدم معين ، يحتاج المستخدم إلى الاعتماد على نظام العنوان الداخلي الخاص بنظام الخصوصية.
كما رأينا ، أضعفت التحولات الثلاثة النموذج العقلي "مستخدم واحد ~ = عنوان واحد" بطرق مختلفة ، وأدت بعض هذه التأثيرات إلى تعقيد تنفيذ التحولات. اثنان من المضاعفات الخاصة هما:
إذا كنت تريد أن تدفع لشخص ما ، كيف تحصل على المعلومات لدفعها؟
إذا قام المستخدم بتخزين العديد من الأصول في أماكن مختلفة على سلاسل مختلفة ، فكيف يقومون باستبدال المفتاح والتعافي الاجتماعي؟
ثلاث انتقالات مرتبطة بالدفعات على السلسلة (والهوية)
لدي عملات معدنية في Scroll وأريد أن أدفع مقابل القهوة (إذا كانت كلمة "I" تشير إليني حرفياً بصفتي مؤلف هذا المقال ، فإن كلمة "coffee" هي بالطبع مرادف لكلمة "الشاي الأخضر"). أنت تبيع لي قهوة ، لكنك ستحصل على عملات معدنية فقط على Taiko. ماذا أفعل؟
هناك حلان أساسيان:
تسعى المحفظة المستلمة (يمكن أن تكون تاجرًا ، أو مجرد فرد عادي) إلى دعم كل L2 ، مع بعض الوظائف التلقائية لدمج الأموال بشكل غير متزامن.
يوفر المستلم L2 وعنوانه ، وتقوم محفظة المرسل تلقائيًا بتوجيه الأموال إلى الهدف L2 من خلال نوع من نظام التجسير بين L2.
بالطبع ، يمكن الجمع بين هذه الحلول: يوفر المستلم قائمة L2 التي يرغب في قبولها ، وتحسب محفظة المرسل الدفعة ، والتي قد تتضمن الإرسال المباشر (إذا كان محظوظًا) ، أو عبر مسار متصل عبر L2.
لكن هذا مجرد مثال واحد على التحدي الرئيسي الذي قدمته التحولات الثلاث: شيء بسيط مثل الدفع لشخص ما يبدأ في طلب معلومات أكثر من مجرد عنوان من 20 بايت.
لحسن الحظ ، لم يثقل التحول إلى محافظ العقود الذكية نظام العناوين كثيرًا ، ولكن لا تزال هناك بعض المشكلات الفنية التي يجب معالجتها في أجزاء أخرى من حزمة التطبيقات. تحتاج المحافظ إلى التحديث للتأكد من أنها لا ترسل فقط 21000 غاز في المعاملات ، ولكن الأهم من ذلك ضمان أن الجانب المتلقي للدفع من المحفظة لا يتتبع فقط تحويلات ETH من EOA ، ولكن أيضًا ETH المرسلة بواسطة رمز العقد الذكي. سيتعين على التطبيقات التي تعتمد على افتراض الملكية غير القابلة للتغيير للعناوين (مثل NFTs التي تحظر العقود الذكية لفرض الإتاوات) أن تجد طرقًا أخرى لتحقيق أهدافها. ستجعل محافظ العقود الذكية أيضًا بعض الأشياء أسهل - على وجه الخصوص ، إذا قبل شخص ما الرموز المميزة بخلاف ETH ERC20 ، فسيكون قادرًا على استخدام دافع ERC-4337 للدفع مقابل الغاز باستخدام هذا الرمز المميز.
من ناحية أخرى ، تمثل الخصوصية مرة أخرى تحديات كبيرة لم نتمكن من حلها بعد. لم تقدم Tornado Cash الأصلية هذه المشكلات لأنها لا تدعم التحويلات الداخلية: يمكن للمستخدمين فقط الإيداع في النظام والسحب. بمجرد أن تتمكن من إجراء عمليات نقل داخلية ، يحتاج المستخدمون إلى استخدام مخطط العناوين الداخلي لنظام الخصوصية. من الناحية العملية ، يجب أن تحتوي "رسالة الدفع" الخاصة بالمستخدم على (1) نوعًا من "إنفاق المفتاح العام" ، ووعد بسر يمكن للمستلم استخدامه للإنفاق ، و (2) يرسل المرسل رسالة مشفرة تفيد بأن يمكن للمستلم فك تشفير الطريقة لمساعدة المستلمين على اكتشاف المدفوعات.
يعتمد بروتوكول عنوان الخصوصية على مفهوم العنوان الفوقي ، والذي يعمل بالطريقة التالية: جزء من العنوان الفوقي هو نسخة معماة من مفتاح إنفاق المرسل ، والجزء الآخر هو مفتاح تشفير المرسل (على الرغم من الحد الأدنى من عمليات التنفيذ) يمكن تعيين هذا كلا المفتاحين متماثلان).
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات لـ L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-851467e64b-dd1a6f-62a40f)
الدرس الأساسي هنا هو أنه في النظام البيئي الذي يركز على الخصوصية ، سيكون لدى المستخدمين مفاتيح إنفاق عامة ومفاتيح عمومية للتشفير ، ويجب أن تحتوي "معلومات الدفع" الخاصة بالمستخدمين على كلا المفتاحين. إلى جانب الدفع ، هناك أسباب وجيهة أخرى للتوسع في هذا الاتجاه. على سبيل المثال ، إذا أردنا بريدًا إلكترونيًا مشفرًا على Ethereum ، فسيحتاج المستخدمون إلى تقديم شكل من أشكال مفتاح التشفير بشكل عام. في "عالم EOA" ، يمكننا إعادة استخدام مفاتيح الحساب لتحقيق ذلك ، ولكن في عالم من محافظ العقود الذكية الآمنة ، ربما ينبغي أن يكون لدينا وظائف أكثر وضوحًا لتحقيق ذلك. سيساعد هذا أيضًا في جعل الهويات المستندة إلى Ethereum أكثر توافقًا مع أنظمة الخصوصية اللامركزية غير Ethereum ، وأبرز مثال على ذلك هو مفاتيح PGP.
ثلاثة تحولات واسترداد المفتاح
في عالم قد يكون للمستخدم فيه عناوين متعددة ، فإن الطريقة الافتراضية لتنفيذ التغييرات الرئيسية والتعافي الاجتماعي هي جعل المستخدم يقوم بإجراءات الاسترداد على كل عنوان على حدة. يمكن القيام بذلك بنقرة واحدة: يمكن أن تحتوي المحافظ على برنامج لأداء إجراءات الاسترداد على عناوين جميع المستخدمين في وقت واحد. ومع ذلك ، حتى مع تبسيط تجربة المستخدم هذا ، هناك ثلاث مشاكل في الاسترداد الساذج متعدد العناوين:
فواتير الغاز غير الواقعية: هذا يتحدث عن نفسه.
العنوان المقابل: عنوان لم يتم نشر عقده الذكي بعد (في الواقع ، هذا يعني حسابًا لم ترسل الأموال منه بعد). كمستخدم ، لديك عدد لا حصر له من العناوين المغايرة: واحد أو أكثر في كل L2 ، بما في ذلك L2s التي لم تكن موجودة بعد ، ومجموعة مختلفة تمامًا من العناوين المضادة للوقائع اللانهائية ، المشتقة من نظام العناوين المخفي.
الخصوصية: إذا كان لدى المستخدم عن قصد العديد من العناوين لتجنب ربطها ببعضها البعض ، فمن المؤكد أنهم لا يريدون ربطها جميعًا علنًا من خلال استعادتها في نفس الوقت تقريبًا!
حل هذه المشاكل صعب. لحسن الحظ ، هناك حل أنيق إلى حد ما يعمل جيدًا: بنية تفصل بين منطق التحقق من الصحة وحيازة الأصول.
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات لـ L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-fc73c26937-dd1a6f-62a40f)
كل مستخدم لديه عقد تخزين مفاتيح موجود في مكان واحد (يمكن أن يكون الشبكة الرئيسية أو L2 محدد). بعد ذلك ، يكون لدى المستخدمين عناوين على L2s مختلفة ، حيث يكون منطق التحقق لكل عنوان هو مؤشر لعقد مخزن المفاتيح. سيتطلب الإنفاق من هذه العناوين إثباتًا في عقد مخزن المفاتيح يوضح مفتاح الإنفاق العام الحالي (أو الأحدث بشكل أكثر واقعية).
يمكن تحقيق الإثبات بعدة طرق:
قراءة وصول L1 للقراءة فقط مباشرة في L2. يمكن تعديل L2 لمنحهم طريقة لقراءة حالة L1 مباشرة. إذا كان عقد مخزن المفاتيح على L1 ، فإن هذا يعني أن العقود في L2 لها وصول "مجاني" إلى مخزن المفاتيح.
فرع ميركل. يمكن أن تثبت فروع Merkle حالات L1 إلى L2 أو L2 إلى L1 ، أو يمكنك الجمع بين الاثنين لإثبات أجزاء من حالة L2 واحدة إلى L2 أخرى. يتمثل الضعف الرئيسي في براهين Merkle في ارتفاع تكلفة الغاز نظرًا لطول الإثبات: قد يتطلب الإثبات 5 كيلو بايت ، على الرغم من أنه سيتم تقليل هذا إلى أقل من 1 كيلو بايت في المستقبل بفضل أشجار Verkle.
ZK-SNARKs. يمكنك تقليل تكاليف البيانات باستخدام ZK-SNARKs من فروع Merkle بدلاً من الفروع نفسها. يمكن بناء تقنيات التجميع خارج السلسلة (على سبيل المثال ، استنادًا إلى EIP-4337) بحيث يتحقق ZK-SNARK واحدًا من جميع براهين الحالة عبر السلسلة في كتلة واحدة.
التزام KZG. يمكن أن تقدم L2 ، أو المخططات المبنية فوقه ، نظام عنونة متسلسل يسمح بإثباتات الحالة داخل هذا النظام بطول 48 بايت فقط. مثل ZK-SNARKs ، يمكن للمخطط متعدد الإثبات أن يجمع كل هذه البراهين في برهان واحد لكل كتلة.
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات لـ L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-0f1aa0738e-dd1a6f-62a40f)
إذا أردنا تجنب القيام بإثبات لكل معاملة ، فيمكننا تنفيذ حل أكثر خفة ، ما عليك سوى القيام بإثبات متقاطع L2 عند الاسترداد. يعتمد الإنفاق من الحساب على مفتاح الإنفاق الذي يتم تخزين مفتاحه العمومي المقابل في الحساب ، لكن الاسترداد سيتطلب معاملة تنسخ المفتاح العام للإنفاق الحالي في مخزن المفاتيح. الأموال الموجودة في العنوان المضاد تكون آمنة حتى لو لم يكن مفتاحك القديم كذلك: "تنشيط" العنوان المضاد ، وتحويله إلى عقد عمل سيتطلب إجراء إثبات عبر L2 يكرر مفتاح الإنفاق العام الحالي. يصف هذا الموضوع في المنتديات الآمنة كيف يمكن أن تعمل بنية مشابهة.
لإضافة الخصوصية إلى مثل هذا المخطط ، نحتاج فقط إلى تشفير المؤشر ، ثم القيام بجميع البراهين في ZK-SNARKs:
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات لـ L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-ea22227a5e-dd1a6f-62a40f)
مع مزيد من العمل (على سبيل المثال ، استخدام هذا العمل كنقطة بداية) ، يمكننا أيضًا تجريد معظم تعقيد ZK-SNARKs وإنشاء مخطط أبسط يعتمد على KZG.
يمكن أن تصبح هذه السيناريوهات معقدة. ومع ذلك ، هناك العديد من أوجه التآزر المحتملة بين هذه البرامج. على سبيل المثال ، قد يكون مفهوم "عقد مخزن المفاتيح" أيضًا حلاً لتحدي "العنوان" المذكور في القسم السابق: إذا أردنا أن يكون لدى المستخدمين عناوين ثابتة لا تتغير عندما يقوم المستخدمون بتحديث مفاتيحهم ، فنحن من الممكن وضع عناوين التعريف السرية ومفاتيح التشفير وغيرها من المعلومات في عقد مخزن المفاتيح ، واستخدام عنوان عقد مخزن المفاتيح باعتباره "عنوان" المستخدم.
يلزم تحديث الكثير من البنية التحتية الثانوية
استخدام ENS مكلف. اليوم ، يونيو 2023 ، الأمور ليست سيئة للغاية: رسوم المعاملات ، رغم ارتفاعها ، يمكن مقارنتها برسوم مجال ENS. كلفني التسجيل في zuzalu.eth حوالي 27 دولارًا ، منها 11 دولارًا هي رسوم المعاملات. ولكن إذا كان لدينا سوق صاعدة أخرى ، فسترتفع الرسوم بشدة. حتى بدون زيادة سعر ETH ، فإن عودة رسوم الغاز إلى 200 gwei سترفع رسوم المعاملات لتسجيل النطاق إلى 104 دولارات. لذلك إذا أردنا أن يستخدم الأشخاص بالفعل ENS ، خاصةً في حالات الاستخدام مثل الوسائط الاجتماعية اللامركزية حيث يطلب المستخدمون تسجيلًا مجانيًا تقريبًا (رسوم مجال ENS ليست مشكلة نظرًا لأن هذه الأنظمة الأساسية توفر نطاقات فرعية لمستخدميها) ، فنحن بحاجة إلى تشغيل ENS على L2 .
لحسن الحظ ، فإن فريق ENS يتحرك بالفعل و ENS على L2 يحدث بالفعل! يوفر ERC-3668 (المعروف أيضًا باسم "معيار CCIP") ، جنبًا إلى جنب مع ENSIP-10 ، طريقة للتحقق تلقائيًا من نطاقات ENS الفرعية على أي L2. يتطلب معيار CCIP إعداد عقد ذكي يصف طريقة للتحقق من أدلة بيانات L2 ، ويمكن وضع أسماء النطاقات (ecc.eth لـ Optinames ، على سبيل المثال) تحت سيطرة هذا العقد. بمجرد أن يتحكم عقد CCIP في ecc.eth على L1 ، فإن الوصول إلى بعض subdomain.ecc.eth سيشمل تلقائيًا البحث عن حالة L2 الخاصة بالإثبات (مثل فرع Merkle) والتحقق منها (مثل فرع Merkle) الذي يخزن بالفعل هذا النطاق الفرعي المعين.
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات من L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-965ef16634-dd1a6f-62a40f)
يتضمن الحصول على الأدلة في الواقع الوصول إلى سلسلة من عناوين URL المخزنة في العقد ، والتي تبدو وكأنها مركزية ، على الرغم من أنني أجادل في أنها ليست كذلك في الواقع: إنه نموذج ثقة واحد من N (سيتم حظر البراهين غير الصالحة بواسطة CCIP. التحقق المنطق في وظيفة رد الاتصال بالعقد يلتقط ذلك ، طالما أن هناك عنوان URL يعرض إثباتًا صالحًا ، فلا توجد مشكلة). قد تحتوي قائمة عناوين URL هذه على عشرات عناوين URL.
إن عمل ENS CCIP هو قصة نجاح ويجب أن يُنظر إليه على أنه علامة على أن نوع الإصلاح الجذري الذي نحتاجه ممكن. لكن هناك حاجة إلى مزيد من الإصلاحات على مستوى التطبيق. تتضمن بعض الأمثلة ما يلي:
تعتمد العديد من dapps على المستخدمين لتقديم توقيعات خارج السلسلة. بالنسبة للحسابات المملوكة خارجيًا (EOAs) ، الأمر سهل. يوفر ERC-1271 طريقة موحدة لمحافظ العقود الذكية للقيام بذلك. ومع ذلك ، لا يزال العديد من dapps لا يدعم ERC-1271 ؛ فهم بحاجة إلى دعمه.
ستنتهي تطبيقات Dapps التي تستخدم "هل هذا EOA؟" للتمييز بين المستخدمين والعقود (على سبيل المثال ، لمنع عمليات النقل أو فرض الإتاوات). بشكل عام ، أنصح بعدم محاولة إيجاد حل تقني بحت ؛ مسألة معرفة ما إذا كان نقل معين للتحكم في التشفير هو نقل فائدة مفيد أمر صعب قد لا يتم حله دون اللجوء إلى بعض المجتمعات خارج السلسلة- آليات مدفوعة. حل المقبل. على الأرجح ، سيتعين على التطبيقات الاعتماد بدرجة أقل على حظر عمليات النقل وأكثر على تقنيات مثل ضريبة Harberger.
يجب تحسين كيفية تفاعل المحافظ مع مفاتيح الإنفاق والتشفير. في الوقت الحالي ، تستخدم المحافظ عادةً التوقيعات المحددة لإنشاء مفاتيح خاصة بالتطبيق: يتم توقيع رمز nonce قياسي (على سبيل المثال ، تجزئة اسم التطبيق) باستخدام المفتاح الخاص لـ EOA ، مما يؤدي إلى إنشاء رمز nonce لا يمكن إنشاؤه بدون المفتاح الخاص. القيمة الحتمية من ، لذلك فهي آمنة من الناحية الفنية. ومع ذلك ، فإن هذه التقنيات "غير شفافة" للمحفظة ، مما يمنع المحافظ من تنفيذ فحوصات أمان على مستوى واجهة المستخدم. في نظام بيئي أكثر نضجًا ، يحتاج التوقيع والتشفير والوظائف ذات الصلة إلى التعامل معها بشكل أكثر وضوحًا بواسطة المحافظ.
يجب على العملاء الخفيفين (مثل Helios) التحقق من L2 ، وليس فقط L1. اليوم ، يركز العملاء الخفيفون على التحقق من صحة رأس L1 (باستخدام بروتوكول مزامنة العميل الخفيف) ، والتحقق من صحة حالة L1 وشوكات Merkle للمعاملات الناشئة من رأس L1. غدًا ، يحتاجون أيضًا إلى التحقق من إثبات حالة L2 الناشئة من جذر الحالة المخزن في L1 (هذا الإصدار الأكثر تقدمًا ينظر في الواقع إلى التأكيد المسبق لـ L2).
تحتاج المحافظ إلى حماية الأصول والبيانات
الآن ، عمل المحفظة هو حماية الأصول. كل شيء متصل بالسلسلة ، والشيء الوحيد الذي تحتاج المحفظة إلى حمايته هو المفاتيح الخاصة التي تحمي هذه الأصول حاليًا. إذا قمت بتغيير المفاتيح ، يمكنك نشر مفتاحك الخاص السابق بأمان على الإنترنت في اليوم التالي. ومع ذلك ، في عالم البراهين الصفرية ، لم يعد هذا هو الحال: لا تحمي المحافظ بيانات اعتماد المصادقة فحسب ، بل تحمي بياناتك.
لقد رأينا العلامات الأولى لهذا العالم مع Zupass ، وهو نظام الهوية المستند إلى ZK-SNARK المستخدم في Zuzalu. يمتلك المستخدمون مفتاحًا خاصًا يستخدمونه لمصادقة النظام ، والذي يمكن استخدامه لعمل أدلة أساسية مثل "إثبات أنني مقيم في Zuzalu ، لكن لا تكشف عن أي واحد". ومع ذلك ، بدأ نظام Zupass أيضًا في إنشاء تطبيقات أخرى فوقه ، وأبرزها Stamps (إصدار Zupass من POAPs).
أحد أختام Zupass العديدة التي تثبت أنني عضو فخور في Team Cat.
الميزة الرئيسية التي تقدمها الطوابع عبر POAPs هي أن الطوابع خاصة: أنت تحتفظ بالبيانات محليًا ، وتثبت فقط الختم (أو بعض العمليات الحسابية عليه) لهم إذا كنت تريد أن يكون لديهم هذه المعلومات عنك. لكن هذا يزيد من المخاطر: إذا فقدت هذه المعلومات ، فستفقد طابعك.
بطبيعة الحال ، تتلخص مشكلة الاحتفاظ بالبيانات في مشكلة الاحتفاظ بمفتاح تشفير: يمكن لطرف ثالث (أو حتى السلسلة) الاحتفاظ بنسخة مشفرة من البيانات. يتمتع هذا بميزة ملائمة تتمثل في أن الإجراء الذي تتخذه لا يغير مفتاح التشفير ، لذلك لا يلزم أي تفاعل مع النظام الذي يحافظ على أمان مفتاح التشفير الخاص بك. ولكن حتى ذلك الحين ، إذا فقدت مفتاح التشفير ، فستفقد كل شيء. على العكس من ذلك ، إذا رأى شخص ما مفتاح التشفير الخاص بك ، فيمكنه رؤية كل شيء مشفر بهذا المفتاح.
يتمثل الحل الفعلي لـ Zupass في تشجيع الأشخاص على تخزين مفاتيحهم على أجهزة متعددة (مثل الكمبيوتر المحمول والهاتف) ، نظرًا لأن فرص فقدهم جميعًا في نفس الوقت ضئيلة. يمكننا الذهاب إلى أبعد من ذلك واستخدام مشاركة سرية لتخزين المفتاح ، وتقسيم المفتاح بين أوصياء متعددين.
هذا الاسترداد الاجتماعي عبر MPC ليس حلاً مناسبًا للمحافظ ، لأنه لا يعني فقط أن الأوصياء الحاليين ، ولكن الأوصياء السابقين قد يتواطئون لسرقة أصولك ، وهو أمر غير مقبول بدرجة عالية من المخاطر. ومع ذلك ، فإن خرق الخصوصية عادة ما يكون أقل خطورة من الخسارة الكاملة للأصول ، وإذا طلب شخص ما حالة استخدام تحافظ على الخصوصية بدرجة كبيرة ، فيمكنه قبول مخاطر خسارة أكبر من خلال عدم نسخ المفاتيح المرتبطة التي تتطلب الخصوصية- الحفاظ على الإجراءات.
لتجنب إرباك المستخدمين بنظام معقد من مسارات استرداد متعددة ، قد تحتاج المحافظ التي تدعم التعافي الاجتماعي إلى إدارة استرداد الأصول واسترداد مفتاح التشفير.
العودة إلى سؤال الهوية
يتمثل أحد الموضوعات الشائعة لهذه التغييرات في أن مفهوم "العنوان" الذي تستخدمه على السلسلة كمعرف تشفير يمثل "أنت" يجب أن يتغير جذريًا. لم تعد "الإرشادات حول كيفية التفاعل معي" مجرد عنوان ETH ؛ يجب أن تحتوي على مجموعة من العناوين المتعددة في L2s متعددة ، وعناوين التعريف السرية ، ومفاتيح التشفير ، وبيانات أخرى في شكل ما.
تتمثل إحدى طرق القيام بذلك في جعل ENS هويتك: يمكن أن يحتوي سجل ENS الخاص بك على كل هذه المعلومات ، وإذا أرسلت شخصًا ما bob.eth (أو bob.ecc.eth ، أو ...) ، فيمكنه معرفة المزيد والتعرف عليه كل الأشياء التي تدفع وتتفاعل معك ، بما في ذلك الطرق المتداخلة الأكثر تعقيدًا والتي تحافظ على الخصوصية.
** ومع ذلك ، فإن هذا النهج الذي يركز على ENS له نقطتا ضعف: **
إنه يربط أشياء كثيرة باسمك. اسمك ليس أنت ، اسمك هو مجرد واحدة من سماتك العديدة. يجب أن تكون قادرًا على تغيير اسمك دون نقل ملف تعريف هويتك بالكامل وتحديث مجموعة من السجلات في العديد من التطبيقات.
لا يمكن أن يكون لديك أسماء مضادة غير موثوق بها. تتمثل إحدى ميزات UX الرئيسية لأي blockchain في القدرة على إرسال عملات معدنية إلى الأشخاص الذين لم يتفاعلوا بعد مع السلسلة. بدون هذه الوظيفة ، هناك مشكلة الدجاجة والبيضة: يتطلب التفاعل مع السلسلة دفع رسوم المعاملات ، ودفع الرسوم يتطلب ... امتلاك عملات معدنية بالفعل. تحتوي عناوين ETH ، بما في ذلك عناوين العقود الذكية مع CREATE2 ، على هذه الميزة. اسم ENS لا يفعل ذلك ، لأنه إذا قرر اثنان من Bobs أنهما bob.ecc.eth خارج السلسلة ، فلا توجد طريقة لاختيار الشخص الذي سيحصل على الاسم.
يتمثل أحد الحلول الممكنة في وضع المزيد من الأشياء في عقد مخزن المفاتيح المذكور في الهندسة المعمارية سابقًا في هذا المنشور. يمكن أن يحتوي عقد مخزن المفاتيح على معلومات مختلفة عنك وكيفية تفاعلك معه (عبر CCIP ، وبعضها يمكن أن يكون خارج السلسلة) ، ويمكن للمستخدمين استخدام عقد مخزن المفاتيح كمعرف أساسي. لكن الأصول الفعلية التي يتلقونها سيتم تخزينها في أماكن مختلفة. لا ترتبط عقود Keystore بالأسماء ، فهي صديقة للواقع: يمكنك إنشاء عنوان لا يمكن تهيئته إلا من خلال عقد keystore مع بعض المعلمات الأولية الثابتة.
هناك فئة أخرى من الحلول تتعلق بالتخلي عن مفهوم العناوين الموجهة للمستخدم ، والذي يشبه في الروح بروتوكول الدفع بالبيتكوين. تتمثل إحدى الأفكار في الاعتماد أكثر على قنوات الاتصال المباشر بين المرسل والمستلم ؛ على سبيل المثال ، يمكن للمرسل إرسال رابط مطالبة (كعنوان URL صريح أو رمز QR) والذي يمكن للمستلم استخدام قبول المدفوعات بالطريقة التي يريدها.
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات من L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-c001dc0aa4-dd1a6f-62a40f)
سواء كان المرسل أو المستلم هو الذي يتصرف أولاً ، فإن الاعتماد بشكل أكبر على المحافظ لإنشاء معلومات دفع محدثة بشكل مباشر في الوقت الفعلي يقلل الاحتكاك. بعد قولي هذا ، تعتبر المعرفات المستمرة ملائمة (خاصة مع ENS) ، وعمليًا يعد افتراض الاتصال المباشر بين المرسل والمستقبل مشكلة صعبة للغاية ، لذلك قد ننظر إلى مجموعة من التقنيات المختلفة.
في كل هذه التصميمات ، من الأهمية بمكان الحفاظ على الأمور لامركزية ومفهومة للمستخدمين. نحن بحاجة إلى التأكد من أن المستخدمين يمكنهم الوصول بسهولة إلى أحدث طريقة عرض لأصولهم الحالية ، بالإضافة إلى المعلومات المنشورة المخصصة لهم. يجب أن تعتمد وجهات النظر هذه على الأدوات المفتوحة بدلاً من الحلول الاحتكارية. سوف يتطلب الأمر عملاً شاقًا للحفاظ على البنية التحتية للدفع الأكثر تعقيدًا من أن تصبح "برجًا تجريدًا" مبهمًا حيث يواجه المطورون صعوبة في فهم ما يجري وتكييفه مع بيئات جديدة. على الرغم من التحديات ، فإن تحقيق قابلية تطوير Ethereum وأمن المحفظة والخصوصية للمستخدمين العاديين أمر بالغ الأهمية. لا يتعلق الأمر فقط بالجدوى الفنية ، بل يتعلق بإمكانية الوصول الفعلية للمستخدم العادي. نحن بحاجة لمواجهة هذا التحدي.
شكر خاص لكل من Dan Finlay و Karl Floersch و David Hoffman وفريق Scroll و SoulWallet على ملاحظاتهم ومراجعاتهم واقتراحاتهم.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
Vitalik: التحول الضروري في Ethereum - L2 Scale وأمن المحفظة والخصوصية
عندما تتحول Ethereum من تقنية تجريبية شابة إلى مجموعة تقنية ناضجة يمكنها حقًا تقديم تجربة مفتوحة وعالمية وغير مصرح بها للمستخدمين العاديين ، فإن المكدس يحتاج إلى المرور بثلاثة تحولات تكنولوجية رئيسية ، في وقت واحد تقريبًا:
تحول الحجم L2 - تم ترحيل الكل إلى المجموعات
تحول أمان المحفظة - يتم ترحيل الكل إلى محافظ العقد الذكية
تحول الخصوصية - ضمان تحويل الأموال الذي يحافظ على الخصوصية والتأكد من أن جميع الأدوات الأخرى التي يتم تطويرها (الاسترداد الاجتماعي والهوية والسمعة) تحافظ على الخصوصية
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات لـ L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-7d69f32cee-dd1a6f-62a40f)
هذا هو مثلث تحول النظام البيئي. يمكنك فقط اختيار 3 من 3.
بدون الأول ، ستفشل Ethereum لأن كل معاملة ستكلف 3.75 دولارًا (82.48 دولارًا إذا كان لدينا صعود صعودي آخر) ، وكل منتج في السوق الشامل سينسى في النهاية السلسلة ، واتخاذ حل مركزي لكل شيء.
بدون الثانية ، ستفشل Ethereum لأن المستخدمين سيكونون مترددين في تخزين أموالهم (والأصول غير المالية) وسينتقل الجميع إلى التبادلات المركزية.
بدون الثلث ، ستفشل Ethereum ، حيث ستكون جميع المعاملات (و POAPs ، وما إلى ذلك) عامة ليراها أي شخص ، وهو ما سيكون تضحية باهظة بالخصوصية للعديد من المستخدمين ، وسيتحرك الجميع للحصول على بعض البيانات المخفية على الأقل مركزية حل.
للأسباب المذكورة أعلاه ، تعتبر هذه التحولات الثلاثة حاسمة. لكنها أيضًا تمثل تحديًا بسبب التنسيق المكثف المطلوب لحلها. لا تحتاج وظائف البروتوكول إلى التحسين فحسب ، بل هناك حالات تحتاج فيها إلى إجراء تغييرات أساسية إلى حد ما على الطريقة التي نتفاعل بها مع Ethereum ، مما يتطلب تغييرات عميقة في التطبيقات والمحافظ.
ستحدث هذه التحولات الثلاثة ثورة في العلاقة بين المستخدمين والعناوين
في عالم يمتد إلى L2 ، سيكون المستخدمون موجودين في العديد من L2s. هل أنت عضو في موقع ExampleDAO الذي يعمل على التفاؤل؟ إذن لديك حساب على التفاؤل! هل تمتلك CDP في نظام ZkSync's Stablecoin؟ إذن لديك حساب على ZkSync! هل جربت بعض التطبيقات الموجودة على Kakarot؟ إذن لديك حساب على Kakarot! لقد ولت الأيام التي كان لدى المستخدمين فيها عنوان واحد فقط.
لديّ ETH في أربعة أماكن ، وفقًا لعرض Brave Wallet. نعم ، يختلف Arbitrum و Arbitrum Nova. لا تقلق ، سيصبح الأمر أكثر تعقيدًا بمرور الوقت!
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات من L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-dec7e7bb30-dd1a6f-62a40f)
تضيف محافظ العقود الذكية مزيدًا من التعقيد ، مما يجعل من الصعب الحصول على نفس العنوان على L1 ومختلف L2s. اليوم ، يستخدم معظم المستخدمين حسابات مملوكة خارجيًا تكون عناوينها في الواقع تجزئة المفتاح العام المستخدم للتحقق من التوقيع - لذلك لا شيء يتغير بين L1 و L2. ومع ذلك ، مع محافظ العقود الذكية ، يصبح الحفاظ على العنوان أكثر صعوبة. في حين تم إنجاز الكثير من العمل في محاولة جعل العناوين تجزئة من الرمز المكافئ عبر الشبكة ، ولا سيما مصانع CREATE2 و ERC-2470 المفردة ، كان من الصعب جدًا القيام بذلك بشكل مثالي. بعض L2s (مثل "النوع 4 ZK-EVMs") ليست مكافئة تمامًا لمعدات EVM ، وعادة ما تستخدم Solidity أو تجميع وسيط بدلاً من ذلك ، مما يمنع تكافؤ التجزئة. حتى لو كان لديك معادلة التجزئة ، فإن إمكانية تغيير الملكية من خلال التغييرات الرئيسية لها عواقب أخرى غير بديهية.
تتطلب الخصوصية مزيدًا من العناوين لكل مستخدم ، وقد تغير أيضًا أنواع العناوين التي نتعامل معها. إذا تم استخدام اقتراح العنوان الخاص على نطاق واسع ، فبدلاً من بضعة عناوين فقط لكل مستخدم ، أو عنوان واحد لكل L2 ، فقد يكون هناك عنوان واحد لكل معاملة. تعمل مخططات الخصوصية الأخرى ، حتى تلك الموجودة مثل Tornado Cash ، على تغيير كيفية تخزين الأصول بشكل مختلف: يتم تخزين أموال العديد من المستخدمين في نفس العقد الذكي (وبالتالي في نفس العنوان). لإرسال أموال إلى مستخدم معين ، يحتاج المستخدم إلى الاعتماد على نظام العنوان الداخلي الخاص بنظام الخصوصية.
كما رأينا ، أضعفت التحولات الثلاثة النموذج العقلي "مستخدم واحد ~ = عنوان واحد" بطرق مختلفة ، وأدت بعض هذه التأثيرات إلى تعقيد تنفيذ التحولات. اثنان من المضاعفات الخاصة هما:
إذا كنت تريد أن تدفع لشخص ما ، كيف تحصل على المعلومات لدفعها؟
إذا قام المستخدم بتخزين العديد من الأصول في أماكن مختلفة على سلاسل مختلفة ، فكيف يقومون باستبدال المفتاح والتعافي الاجتماعي؟
ثلاث انتقالات مرتبطة بالدفعات على السلسلة (والهوية)
لدي عملات معدنية في Scroll وأريد أن أدفع مقابل القهوة (إذا كانت كلمة "I" تشير إليني حرفياً بصفتي مؤلف هذا المقال ، فإن كلمة "coffee" هي بالطبع مرادف لكلمة "الشاي الأخضر"). أنت تبيع لي قهوة ، لكنك ستحصل على عملات معدنية فقط على Taiko. ماذا أفعل؟
هناك حلان أساسيان:
تسعى المحفظة المستلمة (يمكن أن تكون تاجرًا ، أو مجرد فرد عادي) إلى دعم كل L2 ، مع بعض الوظائف التلقائية لدمج الأموال بشكل غير متزامن.
يوفر المستلم L2 وعنوانه ، وتقوم محفظة المرسل تلقائيًا بتوجيه الأموال إلى الهدف L2 من خلال نوع من نظام التجسير بين L2.
بالطبع ، يمكن الجمع بين هذه الحلول: يوفر المستلم قائمة L2 التي يرغب في قبولها ، وتحسب محفظة المرسل الدفعة ، والتي قد تتضمن الإرسال المباشر (إذا كان محظوظًا) ، أو عبر مسار متصل عبر L2.
لكن هذا مجرد مثال واحد على التحدي الرئيسي الذي قدمته التحولات الثلاث: شيء بسيط مثل الدفع لشخص ما يبدأ في طلب معلومات أكثر من مجرد عنوان من 20 بايت.
لحسن الحظ ، لم يثقل التحول إلى محافظ العقود الذكية نظام العناوين كثيرًا ، ولكن لا تزال هناك بعض المشكلات الفنية التي يجب معالجتها في أجزاء أخرى من حزمة التطبيقات. تحتاج المحافظ إلى التحديث للتأكد من أنها لا ترسل فقط 21000 غاز في المعاملات ، ولكن الأهم من ذلك ضمان أن الجانب المتلقي للدفع من المحفظة لا يتتبع فقط تحويلات ETH من EOA ، ولكن أيضًا ETH المرسلة بواسطة رمز العقد الذكي. سيتعين على التطبيقات التي تعتمد على افتراض الملكية غير القابلة للتغيير للعناوين (مثل NFTs التي تحظر العقود الذكية لفرض الإتاوات) أن تجد طرقًا أخرى لتحقيق أهدافها. ستجعل محافظ العقود الذكية أيضًا بعض الأشياء أسهل - على وجه الخصوص ، إذا قبل شخص ما الرموز المميزة بخلاف ETH ERC20 ، فسيكون قادرًا على استخدام دافع ERC-4337 للدفع مقابل الغاز باستخدام هذا الرمز المميز.
من ناحية أخرى ، تمثل الخصوصية مرة أخرى تحديات كبيرة لم نتمكن من حلها بعد. لم تقدم Tornado Cash الأصلية هذه المشكلات لأنها لا تدعم التحويلات الداخلية: يمكن للمستخدمين فقط الإيداع في النظام والسحب. بمجرد أن تتمكن من إجراء عمليات نقل داخلية ، يحتاج المستخدمون إلى استخدام مخطط العناوين الداخلي لنظام الخصوصية. من الناحية العملية ، يجب أن تحتوي "رسالة الدفع" الخاصة بالمستخدم على (1) نوعًا من "إنفاق المفتاح العام" ، ووعد بسر يمكن للمستلم استخدامه للإنفاق ، و (2) يرسل المرسل رسالة مشفرة تفيد بأن يمكن للمستلم فك تشفير الطريقة لمساعدة المستلمين على اكتشاف المدفوعات.
يعتمد بروتوكول عنوان الخصوصية على مفهوم العنوان الفوقي ، والذي يعمل بالطريقة التالية: جزء من العنوان الفوقي هو نسخة معماة من مفتاح إنفاق المرسل ، والجزء الآخر هو مفتاح تشفير المرسل (على الرغم من الحد الأدنى من عمليات التنفيذ) يمكن تعيين هذا كلا المفتاحين متماثلان).
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات لـ L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-851467e64b-dd1a6f-62a40f)
الدرس الأساسي هنا هو أنه في النظام البيئي الذي يركز على الخصوصية ، سيكون لدى المستخدمين مفاتيح إنفاق عامة ومفاتيح عمومية للتشفير ، ويجب أن تحتوي "معلومات الدفع" الخاصة بالمستخدمين على كلا المفتاحين. إلى جانب الدفع ، هناك أسباب وجيهة أخرى للتوسع في هذا الاتجاه. على سبيل المثال ، إذا أردنا بريدًا إلكترونيًا مشفرًا على Ethereum ، فسيحتاج المستخدمون إلى تقديم شكل من أشكال مفتاح التشفير بشكل عام. في "عالم EOA" ، يمكننا إعادة استخدام مفاتيح الحساب لتحقيق ذلك ، ولكن في عالم من محافظ العقود الذكية الآمنة ، ربما ينبغي أن يكون لدينا وظائف أكثر وضوحًا لتحقيق ذلك. سيساعد هذا أيضًا في جعل الهويات المستندة إلى Ethereum أكثر توافقًا مع أنظمة الخصوصية اللامركزية غير Ethereum ، وأبرز مثال على ذلك هو مفاتيح PGP.
ثلاثة تحولات واسترداد المفتاح
في عالم قد يكون للمستخدم فيه عناوين متعددة ، فإن الطريقة الافتراضية لتنفيذ التغييرات الرئيسية والتعافي الاجتماعي هي جعل المستخدم يقوم بإجراءات الاسترداد على كل عنوان على حدة. يمكن القيام بذلك بنقرة واحدة: يمكن أن تحتوي المحافظ على برنامج لأداء إجراءات الاسترداد على عناوين جميع المستخدمين في وقت واحد. ومع ذلك ، حتى مع تبسيط تجربة المستخدم هذا ، هناك ثلاث مشاكل في الاسترداد الساذج متعدد العناوين:
فواتير الغاز غير الواقعية: هذا يتحدث عن نفسه.
العنوان المقابل: عنوان لم يتم نشر عقده الذكي بعد (في الواقع ، هذا يعني حسابًا لم ترسل الأموال منه بعد). كمستخدم ، لديك عدد لا حصر له من العناوين المغايرة: واحد أو أكثر في كل L2 ، بما في ذلك L2s التي لم تكن موجودة بعد ، ومجموعة مختلفة تمامًا من العناوين المضادة للوقائع اللانهائية ، المشتقة من نظام العناوين المخفي.
الخصوصية: إذا كان لدى المستخدم عن قصد العديد من العناوين لتجنب ربطها ببعضها البعض ، فمن المؤكد أنهم لا يريدون ربطها جميعًا علنًا من خلال استعادتها في نفس الوقت تقريبًا!
حل هذه المشاكل صعب. لحسن الحظ ، هناك حل أنيق إلى حد ما يعمل جيدًا: بنية تفصل بين منطق التحقق من الصحة وحيازة الأصول.
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات لـ L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-fc73c26937-dd1a6f-62a40f)
كل مستخدم لديه عقد تخزين مفاتيح موجود في مكان واحد (يمكن أن يكون الشبكة الرئيسية أو L2 محدد). بعد ذلك ، يكون لدى المستخدمين عناوين على L2s مختلفة ، حيث يكون منطق التحقق لكل عنوان هو مؤشر لعقد مخزن المفاتيح. سيتطلب الإنفاق من هذه العناوين إثباتًا في عقد مخزن المفاتيح يوضح مفتاح الإنفاق العام الحالي (أو الأحدث بشكل أكثر واقعية).
يمكن تحقيق الإثبات بعدة طرق:
قراءة وصول L1 للقراءة فقط مباشرة في L2. يمكن تعديل L2 لمنحهم طريقة لقراءة حالة L1 مباشرة. إذا كان عقد مخزن المفاتيح على L1 ، فإن هذا يعني أن العقود في L2 لها وصول "مجاني" إلى مخزن المفاتيح.
فرع ميركل. يمكن أن تثبت فروع Merkle حالات L1 إلى L2 أو L2 إلى L1 ، أو يمكنك الجمع بين الاثنين لإثبات أجزاء من حالة L2 واحدة إلى L2 أخرى. يتمثل الضعف الرئيسي في براهين Merkle في ارتفاع تكلفة الغاز نظرًا لطول الإثبات: قد يتطلب الإثبات 5 كيلو بايت ، على الرغم من أنه سيتم تقليل هذا إلى أقل من 1 كيلو بايت في المستقبل بفضل أشجار Verkle.
ZK-SNARKs. يمكنك تقليل تكاليف البيانات باستخدام ZK-SNARKs من فروع Merkle بدلاً من الفروع نفسها. يمكن بناء تقنيات التجميع خارج السلسلة (على سبيل المثال ، استنادًا إلى EIP-4337) بحيث يتحقق ZK-SNARK واحدًا من جميع براهين الحالة عبر السلسلة في كتلة واحدة.
التزام KZG. يمكن أن تقدم L2 ، أو المخططات المبنية فوقه ، نظام عنونة متسلسل يسمح بإثباتات الحالة داخل هذا النظام بطول 48 بايت فقط. مثل ZK-SNARKs ، يمكن للمخطط متعدد الإثبات أن يجمع كل هذه البراهين في برهان واحد لكل كتلة.
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات لـ L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-0f1aa0738e-dd1a6f-62a40f)
إذا أردنا تجنب القيام بإثبات لكل معاملة ، فيمكننا تنفيذ حل أكثر خفة ، ما عليك سوى القيام بإثبات متقاطع L2 عند الاسترداد. يعتمد الإنفاق من الحساب على مفتاح الإنفاق الذي يتم تخزين مفتاحه العمومي المقابل في الحساب ، لكن الاسترداد سيتطلب معاملة تنسخ المفتاح العام للإنفاق الحالي في مخزن المفاتيح. الأموال الموجودة في العنوان المضاد تكون آمنة حتى لو لم يكن مفتاحك القديم كذلك: "تنشيط" العنوان المضاد ، وتحويله إلى عقد عمل سيتطلب إجراء إثبات عبر L2 يكرر مفتاح الإنفاق العام الحالي. يصف هذا الموضوع في المنتديات الآمنة كيف يمكن أن تعمل بنية مشابهة.
لإضافة الخصوصية إلى مثل هذا المخطط ، نحتاج فقط إلى تشفير المؤشر ، ثم القيام بجميع البراهين في ZK-SNARKs:
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات لـ L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-ea22227a5e-dd1a6f-62a40f)
مع مزيد من العمل (على سبيل المثال ، استخدام هذا العمل كنقطة بداية) ، يمكننا أيضًا تجريد معظم تعقيد ZK-SNARKs وإنشاء مخطط أبسط يعتمد على KZG.
يمكن أن تصبح هذه السيناريوهات معقدة. ومع ذلك ، هناك العديد من أوجه التآزر المحتملة بين هذه البرامج. على سبيل المثال ، قد يكون مفهوم "عقد مخزن المفاتيح" أيضًا حلاً لتحدي "العنوان" المذكور في القسم السابق: إذا أردنا أن يكون لدى المستخدمين عناوين ثابتة لا تتغير عندما يقوم المستخدمون بتحديث مفاتيحهم ، فنحن من الممكن وضع عناوين التعريف السرية ومفاتيح التشفير وغيرها من المعلومات في عقد مخزن المفاتيح ، واستخدام عنوان عقد مخزن المفاتيح باعتباره "عنوان" المستخدم.
يلزم تحديث الكثير من البنية التحتية الثانوية
استخدام ENS مكلف. اليوم ، يونيو 2023 ، الأمور ليست سيئة للغاية: رسوم المعاملات ، رغم ارتفاعها ، يمكن مقارنتها برسوم مجال ENS. كلفني التسجيل في zuzalu.eth حوالي 27 دولارًا ، منها 11 دولارًا هي رسوم المعاملات. ولكن إذا كان لدينا سوق صاعدة أخرى ، فسترتفع الرسوم بشدة. حتى بدون زيادة سعر ETH ، فإن عودة رسوم الغاز إلى 200 gwei سترفع رسوم المعاملات لتسجيل النطاق إلى 104 دولارات. لذلك إذا أردنا أن يستخدم الأشخاص بالفعل ENS ، خاصةً في حالات الاستخدام مثل الوسائط الاجتماعية اللامركزية حيث يطلب المستخدمون تسجيلًا مجانيًا تقريبًا (رسوم مجال ENS ليست مشكلة نظرًا لأن هذه الأنظمة الأساسية توفر نطاقات فرعية لمستخدميها) ، فنحن بحاجة إلى تشغيل ENS على L2 .
لحسن الحظ ، فإن فريق ENS يتحرك بالفعل و ENS على L2 يحدث بالفعل! يوفر ERC-3668 (المعروف أيضًا باسم "معيار CCIP") ، جنبًا إلى جنب مع ENSIP-10 ، طريقة للتحقق تلقائيًا من نطاقات ENS الفرعية على أي L2. يتطلب معيار CCIP إعداد عقد ذكي يصف طريقة للتحقق من أدلة بيانات L2 ، ويمكن وضع أسماء النطاقات (ecc.eth لـ Optinames ، على سبيل المثال) تحت سيطرة هذا العقد. بمجرد أن يتحكم عقد CCIP في ecc.eth على L1 ، فإن الوصول إلى بعض subdomain.ecc.eth سيشمل تلقائيًا البحث عن حالة L2 الخاصة بالإثبات (مثل فرع Merkle) والتحقق منها (مثل فرع Merkle) الذي يخزن بالفعل هذا النطاق الفرعي المعين.
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات من L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-965ef16634-dd1a6f-62a40f)
يتضمن الحصول على الأدلة في الواقع الوصول إلى سلسلة من عناوين URL المخزنة في العقد ، والتي تبدو وكأنها مركزية ، على الرغم من أنني أجادل في أنها ليست كذلك في الواقع: إنه نموذج ثقة واحد من N (سيتم حظر البراهين غير الصالحة بواسطة CCIP. التحقق المنطق في وظيفة رد الاتصال بالعقد يلتقط ذلك ، طالما أن هناك عنوان URL يعرض إثباتًا صالحًا ، فلا توجد مشكلة). قد تحتوي قائمة عناوين URL هذه على عشرات عناوين URL.
إن عمل ENS CCIP هو قصة نجاح ويجب أن يُنظر إليه على أنه علامة على أن نوع الإصلاح الجذري الذي نحتاجه ممكن. لكن هناك حاجة إلى مزيد من الإصلاحات على مستوى التطبيق. تتضمن بعض الأمثلة ما يلي:
تعتمد العديد من dapps على المستخدمين لتقديم توقيعات خارج السلسلة. بالنسبة للحسابات المملوكة خارجيًا (EOAs) ، الأمر سهل. يوفر ERC-1271 طريقة موحدة لمحافظ العقود الذكية للقيام بذلك. ومع ذلك ، لا يزال العديد من dapps لا يدعم ERC-1271 ؛ فهم بحاجة إلى دعمه.
ستنتهي تطبيقات Dapps التي تستخدم "هل هذا EOA؟" للتمييز بين المستخدمين والعقود (على سبيل المثال ، لمنع عمليات النقل أو فرض الإتاوات). بشكل عام ، أنصح بعدم محاولة إيجاد حل تقني بحت ؛ مسألة معرفة ما إذا كان نقل معين للتحكم في التشفير هو نقل فائدة مفيد أمر صعب قد لا يتم حله دون اللجوء إلى بعض المجتمعات خارج السلسلة- آليات مدفوعة. حل المقبل. على الأرجح ، سيتعين على التطبيقات الاعتماد بدرجة أقل على حظر عمليات النقل وأكثر على تقنيات مثل ضريبة Harberger.
يجب تحسين كيفية تفاعل المحافظ مع مفاتيح الإنفاق والتشفير. في الوقت الحالي ، تستخدم المحافظ عادةً التوقيعات المحددة لإنشاء مفاتيح خاصة بالتطبيق: يتم توقيع رمز nonce قياسي (على سبيل المثال ، تجزئة اسم التطبيق) باستخدام المفتاح الخاص لـ EOA ، مما يؤدي إلى إنشاء رمز nonce لا يمكن إنشاؤه بدون المفتاح الخاص. القيمة الحتمية من ، لذلك فهي آمنة من الناحية الفنية. ومع ذلك ، فإن هذه التقنيات "غير شفافة" للمحفظة ، مما يمنع المحافظ من تنفيذ فحوصات أمان على مستوى واجهة المستخدم. في نظام بيئي أكثر نضجًا ، يحتاج التوقيع والتشفير والوظائف ذات الصلة إلى التعامل معها بشكل أكثر وضوحًا بواسطة المحافظ.
يجب على العملاء الخفيفين (مثل Helios) التحقق من L2 ، وليس فقط L1. اليوم ، يركز العملاء الخفيفون على التحقق من صحة رأس L1 (باستخدام بروتوكول مزامنة العميل الخفيف) ، والتحقق من صحة حالة L1 وشوكات Merkle للمعاملات الناشئة من رأس L1. غدًا ، يحتاجون أيضًا إلى التحقق من إثبات حالة L2 الناشئة من جذر الحالة المخزن في L1 (هذا الإصدار الأكثر تقدمًا ينظر في الواقع إلى التأكيد المسبق لـ L2).
تحتاج المحافظ إلى حماية الأصول والبيانات
الآن ، عمل المحفظة هو حماية الأصول. كل شيء متصل بالسلسلة ، والشيء الوحيد الذي تحتاج المحفظة إلى حمايته هو المفاتيح الخاصة التي تحمي هذه الأصول حاليًا. إذا قمت بتغيير المفاتيح ، يمكنك نشر مفتاحك الخاص السابق بأمان على الإنترنت في اليوم التالي. ومع ذلك ، في عالم البراهين الصفرية ، لم يعد هذا هو الحال: لا تحمي المحافظ بيانات اعتماد المصادقة فحسب ، بل تحمي بياناتك.
لقد رأينا العلامات الأولى لهذا العالم مع Zupass ، وهو نظام الهوية المستند إلى ZK-SNARK المستخدم في Zuzalu. يمتلك المستخدمون مفتاحًا خاصًا يستخدمونه لمصادقة النظام ، والذي يمكن استخدامه لعمل أدلة أساسية مثل "إثبات أنني مقيم في Zuzalu ، لكن لا تكشف عن أي واحد". ومع ذلك ، بدأ نظام Zupass أيضًا في إنشاء تطبيقات أخرى فوقه ، وأبرزها Stamps (إصدار Zupass من POAPs).
أحد أختام Zupass العديدة التي تثبت أنني عضو فخور في Team Cat.
الميزة الرئيسية التي تقدمها الطوابع عبر POAPs هي أن الطوابع خاصة: أنت تحتفظ بالبيانات محليًا ، وتثبت فقط الختم (أو بعض العمليات الحسابية عليه) لهم إذا كنت تريد أن يكون لديهم هذه المعلومات عنك. لكن هذا يزيد من المخاطر: إذا فقدت هذه المعلومات ، فستفقد طابعك.
بطبيعة الحال ، تتلخص مشكلة الاحتفاظ بالبيانات في مشكلة الاحتفاظ بمفتاح تشفير: يمكن لطرف ثالث (أو حتى السلسلة) الاحتفاظ بنسخة مشفرة من البيانات. يتمتع هذا بميزة ملائمة تتمثل في أن الإجراء الذي تتخذه لا يغير مفتاح التشفير ، لذلك لا يلزم أي تفاعل مع النظام الذي يحافظ على أمان مفتاح التشفير الخاص بك. ولكن حتى ذلك الحين ، إذا فقدت مفتاح التشفير ، فستفقد كل شيء. على العكس من ذلك ، إذا رأى شخص ما مفتاح التشفير الخاص بك ، فيمكنه رؤية كل شيء مشفر بهذا المفتاح.
يتمثل الحل الفعلي لـ Zupass في تشجيع الأشخاص على تخزين مفاتيحهم على أجهزة متعددة (مثل الكمبيوتر المحمول والهاتف) ، نظرًا لأن فرص فقدهم جميعًا في نفس الوقت ضئيلة. يمكننا الذهاب إلى أبعد من ذلك واستخدام مشاركة سرية لتخزين المفتاح ، وتقسيم المفتاح بين أوصياء متعددين.
هذا الاسترداد الاجتماعي عبر MPC ليس حلاً مناسبًا للمحافظ ، لأنه لا يعني فقط أن الأوصياء الحاليين ، ولكن الأوصياء السابقين قد يتواطئون لسرقة أصولك ، وهو أمر غير مقبول بدرجة عالية من المخاطر. ومع ذلك ، فإن خرق الخصوصية عادة ما يكون أقل خطورة من الخسارة الكاملة للأصول ، وإذا طلب شخص ما حالة استخدام تحافظ على الخصوصية بدرجة كبيرة ، فيمكنه قبول مخاطر خسارة أكبر من خلال عدم نسخ المفاتيح المرتبطة التي تتطلب الخصوصية- الحفاظ على الإجراءات.
لتجنب إرباك المستخدمين بنظام معقد من مسارات استرداد متعددة ، قد تحتاج المحافظ التي تدعم التعافي الاجتماعي إلى إدارة استرداد الأصول واسترداد مفتاح التشفير.
العودة إلى سؤال الهوية
يتمثل أحد الموضوعات الشائعة لهذه التغييرات في أن مفهوم "العنوان" الذي تستخدمه على السلسلة كمعرف تشفير يمثل "أنت" يجب أن يتغير جذريًا. لم تعد "الإرشادات حول كيفية التفاعل معي" مجرد عنوان ETH ؛ يجب أن تحتوي على مجموعة من العناوين المتعددة في L2s متعددة ، وعناوين التعريف السرية ، ومفاتيح التشفير ، وبيانات أخرى في شكل ما.
تتمثل إحدى طرق القيام بذلك في جعل ENS هويتك: يمكن أن يحتوي سجل ENS الخاص بك على كل هذه المعلومات ، وإذا أرسلت شخصًا ما bob.eth (أو bob.ecc.eth ، أو ...) ، فيمكنه معرفة المزيد والتعرف عليه كل الأشياء التي تدفع وتتفاعل معك ، بما في ذلك الطرق المتداخلة الأكثر تعقيدًا والتي تحافظ على الخصوصية.
** ومع ذلك ، فإن هذا النهج الذي يركز على ENS له نقطتا ضعف: **
إنه يربط أشياء كثيرة باسمك. اسمك ليس أنت ، اسمك هو مجرد واحدة من سماتك العديدة. يجب أن تكون قادرًا على تغيير اسمك دون نقل ملف تعريف هويتك بالكامل وتحديث مجموعة من السجلات في العديد من التطبيقات.
لا يمكن أن يكون لديك أسماء مضادة غير موثوق بها. تتمثل إحدى ميزات UX الرئيسية لأي blockchain في القدرة على إرسال عملات معدنية إلى الأشخاص الذين لم يتفاعلوا بعد مع السلسلة. بدون هذه الوظيفة ، هناك مشكلة الدجاجة والبيضة: يتطلب التفاعل مع السلسلة دفع رسوم المعاملات ، ودفع الرسوم يتطلب ... امتلاك عملات معدنية بالفعل. تحتوي عناوين ETH ، بما في ذلك عناوين العقود الذكية مع CREATE2 ، على هذه الميزة. اسم ENS لا يفعل ذلك ، لأنه إذا قرر اثنان من Bobs أنهما bob.ecc.eth خارج السلسلة ، فلا توجد طريقة لاختيار الشخص الذي سيحصل على الاسم.
يتمثل أحد الحلول الممكنة في وضع المزيد من الأشياء في عقد مخزن المفاتيح المذكور في الهندسة المعمارية سابقًا في هذا المنشور. يمكن أن يحتوي عقد مخزن المفاتيح على معلومات مختلفة عنك وكيفية تفاعلك معه (عبر CCIP ، وبعضها يمكن أن يكون خارج السلسلة) ، ويمكن للمستخدمين استخدام عقد مخزن المفاتيح كمعرف أساسي. لكن الأصول الفعلية التي يتلقونها سيتم تخزينها في أماكن مختلفة. لا ترتبط عقود Keystore بالأسماء ، فهي صديقة للواقع: يمكنك إنشاء عنوان لا يمكن تهيئته إلا من خلال عقد keystore مع بعض المعلمات الأولية الثابتة.
هناك فئة أخرى من الحلول تتعلق بالتخلي عن مفهوم العناوين الموجهة للمستخدم ، والذي يشبه في الروح بروتوكول الدفع بالبيتكوين. تتمثل إحدى الأفكار في الاعتماد أكثر على قنوات الاتصال المباشر بين المرسل والمستلم ؛ على سبيل المثال ، يمكن للمرسل إرسال رابط مطالبة (كعنوان URL صريح أو رمز QR) والذي يمكن للمستلم استخدام قبول المدفوعات بالطريقة التي يريدها.
! [Vitalik: يحتاج Ethereum إلى إكمال ثلاث تحويلات من L2 والمحفظة والخصوصية] (https://img.gateio.im/social/moments-0a589b38c7-c001dc0aa4-dd1a6f-62a40f)
سواء كان المرسل أو المستلم هو الذي يتصرف أولاً ، فإن الاعتماد بشكل أكبر على المحافظ لإنشاء معلومات دفع محدثة بشكل مباشر في الوقت الفعلي يقلل الاحتكاك. بعد قولي هذا ، تعتبر المعرفات المستمرة ملائمة (خاصة مع ENS) ، وعمليًا يعد افتراض الاتصال المباشر بين المرسل والمستقبل مشكلة صعبة للغاية ، لذلك قد ننظر إلى مجموعة من التقنيات المختلفة.
في كل هذه التصميمات ، من الأهمية بمكان الحفاظ على الأمور لامركزية ومفهومة للمستخدمين. نحن بحاجة إلى التأكد من أن المستخدمين يمكنهم الوصول بسهولة إلى أحدث طريقة عرض لأصولهم الحالية ، بالإضافة إلى المعلومات المنشورة المخصصة لهم. يجب أن تعتمد وجهات النظر هذه على الأدوات المفتوحة بدلاً من الحلول الاحتكارية. سوف يتطلب الأمر عملاً شاقًا للحفاظ على البنية التحتية للدفع الأكثر تعقيدًا من أن تصبح "برجًا تجريدًا" مبهمًا حيث يواجه المطورون صعوبة في فهم ما يجري وتكييفه مع بيئات جديدة. على الرغم من التحديات ، فإن تحقيق قابلية تطوير Ethereum وأمن المحفظة والخصوصية للمستخدمين العاديين أمر بالغ الأهمية. لا يتعلق الأمر فقط بالجدوى الفنية ، بل يتعلق بإمكانية الوصول الفعلية للمستخدم العادي. نحن بحاجة لمواجهة هذا التحدي.
شكر خاص لكل من Dan Finlay و Karl Floersch و David Hoffman وفريق Scroll و SoulWallet على ملاحظاتهم ومراجعاتهم واقتراحاتهم.