المؤلف: فيتاليك ، مؤسس Ethereum ؛ الترجمة: Jinse Finance cryptonaitive
نظرًا لتطور Ethereum من تقنية تجريبية شابة إلى مجموعة تقنية ناضجة قادرة على تقديم تجربة مفتوحة وعالمية وغير مصرح بها للمستخدمين العاديين ، فهناك ثلاثة انتقالات تكنولوجية رئيسية يجب أن تحدث في وقت واحد:
** الأول هو تحويل توسيع سعة L2 ** - يتحول الجميع إلى تقنية Rollup ؛
** ثانيًا هو تحويل أمان المحفظة ** - يبدأ الجميع في استخدام محافظ العقود الذكية ؛
** والثالث هو تحويل الخصوصية ** - ضمان توفر وظائف تحويل الأموال التي تحافظ على الخصوصية ، والتأكد من أن جميع الأدوات الأخرى التي يتم تطويرها (الاسترداد الاجتماعي ، والتحقق من الهوية ، والسمعة ، وما إلى ذلك) تحتوي على ميزات تحافظ على الخصوصية.
مثلث التحول للنظام البيئي Ethereum. يمكنك فقط اختيار الثلاثة. *
بدون العنصر الأول ، ستفشل Ethereum لأن كل معاملة تكلف 3.75 دولارًا (82.48 دولارًا أمريكيًا إذا مررنا بمسار صعودي آخر) ، وكل منتج في السوق الشامل سوف يسقط حتمًا التجارة عبر السلسلة ويتبنى حلاً مركزيًا.
بدون العنصر الثاني ، ستفشل Ethereum لأن المستخدمين لن يكونوا مستعدين لتخزين أموالهم (والأصول غير المالية) وسيتحول الجميع إلى التبادلات المركزية.
بدون العنصر الثالث ، ستفشل Ethereum لأنه بالنسبة للعديد من المستخدمين ، ستكون جميع المعاملات (و POAP وما إلى ذلك) مرئية للعامة ، وستكون التضحية بالخصوصية كبيرة جدًا وسيتجه الجميع إلى مستوى معين على الأقل من حل مركزي للبيانات المخفية.
للأسباب الموضحة أعلاه ، تعتبر هذه التحولات الثلاثة حاسمة. لكنها تمثل أيضًا تحديًا نظرًا لتعقيد التنسيق الذي ينطوي عليه الأمر. ليست وظائف البروتوكول هي فقط التي تحتاج إلى تحسين ؛ في بعض الحالات ، تحتاج الطريقة التي نتفاعل بها مع Ethereum إلى تغيير جذري وعميق ، مما يتطلب تغييرات كبيرة في التطبيقات والمحافظ.
ستعيد هذه التحولات الثلاثة بشكل أساسي تشكيل العلاقة بين المستخدمين والعناوين
في عالم من مقياس L2 ، سيكون المستخدمون موجودين على شبكات L2 متعددة. هل أنت عضو في ExampleDAO؟ exampleDAO على التفاؤل. إذن لديك حساب مع التفاؤل! هل تمتلك CDP لنظام عملة مستقرة على ZkSync؟ إذن لديك حساب على ZkSync! هل سبق لك أن جربت بعض التطبيقات الموجودة على Kakarot؟ إذن لديك حساب على Kakarot! لقد ولت الأيام التي كان لدى المستخدمين فيها عنوان واحد فقط.
! [kJxidBFR5zU5hNHQVmOs969XyFT9VZ3cDAmKwUvV.png] (https://img.gateio.im/social/moments-40baef27dd-96350c2454-dd1a6f-62a40f "7049163ereum") عرض أربعة مواضع Brave. نعم ، يختلف Arbitrum و Arbitrum Nova. لا تقلق ، ستزداد الأمور تعقيدًا بمرور الوقت! *
** تضيف محافظ العقود الذكية مزيدًا من التعقيد لأنها تجعل من الصعب الحصول على نفس العنوان على L1 وشبكات L2 المختلفة. ** يستخدم معظم المستخدمين اليوم حسابات مملوكة خارجيًا تكون عناوينها في الواقع تجزئة للمفاتيح العامة المستخدمة للتحقق من التوقيعات - لذلك لا شيء يتغير بين L1 و L2. ومع ذلك ، يصبح الاحتفاظ بالعنوان أكثر صعوبة عند استخدام محفظة عقد ذكية. بينما تم إنجاز الكثير من العمل لمحاولة جعل العناوين تجزئة من التعليمات البرمجية المكافئة عبر شبكات مختلفة ، وأهمها CREATE2 ومصنع ERC-2470 الفردي ، فمن الصعب تحقيق ذلك بشكل مثالي. بعض شبكات L2 (على سبيل المثال ، "ZK-EVM من النوع الرابع") ليست مكافئة تمامًا لأجهزة EVM ، وغالبًا ما تستخدم لغة صلبة أو لغة تجميع وسيطة بدلاً من معادلات التجزئة. حتى إذا كان من الممكن تحقيق تكافؤ التجزئة ، فإن إمكانية تغيير الملكية من خلال التغييرات الرئيسية للمحافظ تؤدي إلى عواقب أخرى أقل قابلية للتنبؤ.
** تتطلب الخصوصية المزيد من العناوين لكل مستخدم وقد تغير حتى أنواع العناوين التي نتعامل معها. ** إذا تم استخدام اقتراح العنوان المتخفي على نطاق واسع ، فقد يكون لدى المستخدمين عنوان واحد لكل معاملة بدلاً من بضعة عناوين فقط لكل مستخدم أو عنوان واحد لكل شبكة L2. تعمل مخططات الخصوصية الأخرى ، حتى تلك الموجودة مثل Tornado Cash ، على تغيير طريقة تخزين الأصول بطرق مختلفة: يتم تخزين أموال العديد من المستخدمين في نفس العقد الذكي (وبالتالي على نفس العنوان). لإرسال أموال إلى مستخدم معين ، سيحتاج المستخدم إلى الاعتماد على نظام العنونة الداخلي الخاص بنظام الخصوصية.
كما رأينا ، ** تُضعف هذه التحولات الثلاثة النموذج العقلي "لمستخدم واحد - عنوان واحد" ** بطرق مختلفة ، تؤدي بعض التأثيرات بدورها إلى زيادة تعقيد تنفيذ هذه التحولات. اثنان من القضايا المعقدة بشكل خاص هي:
** 1. إذا كنت تريد الدفع لشخص ما ، كيف ستحصل على معلومات الدفع؟ **
** 2. إذا قام المستخدمون بتخزين الأصول في مواقع مختلفة على سلاسل مختلفة ، فكيف يقومون بإجراء التغييرات الرئيسية والتعافي الاجتماعي؟ **
هذه التحولات الثلاثة والمدفوعات على السلسلة (والهوية)
أحمل الرموز المميزة في Scroll ، وأريد استخدامها لشراء القهوة (إذا كانت الحرف "I" تشير إلى Vitalik ، مؤلف هذه المقالة ، فإن كلمة "coffee" تعني بالطبع "الشاي الأخضر"). أنت تبيع القهوة على Taiko ، لكنك تقبل الرموز فقط على Taiko. ما يجب القيام به؟
هناك حلان أساسيان:
المحفظة المستلمة (التي يمكن أن تكون تاجرًا أو فردًا عاديًا) تسعى جاهدة لدعم كل L2 ولديها بعض وظائف دمج الأموال غير المتزامنة.
يقدم المدفوع لأمره معلومات L2 الخاصة به بجوار العنوان ، وتقوم محفظة المرسل تلقائيًا بتوجيه الأموال إلى L2 الهدف من خلال نوع من نظام التجسير المتقاطع L2.
بالطبع ، يمكن استخدام هذه الحلول معًا: يوفر المستفيد قائمة L2 التي يرغب في قبولها ، وتحدد محفظة المرسل طريقة الدفع ، والتي يمكن إرسالها مباشرةً (مع الحظ) ، أو الدفع عبر مسار مرتبط عبر L2.
ولكن هذا مجرد مثال واحد على التحدي الرئيسي الذي قدمته التحولات الثلاثة: ** تبدأ سلوكيات الدفع البسيطة في طلب معلومات أكثر من مجرد عنوان مكون من 20 بايتًا **.
لحسن الحظ ، لا يمثل الانتقال إلى محافظ العقود الذكية عبئًا كبيرًا على نظام العناوين ، ولكن لا تزال هناك بعض المشكلات الفنية التي يجب حلها في أجزاء أخرى من حزمة التطبيقات. تحتاج المحافظ إلى التحديث للتأكد من أنها لا ترسل فقط 21000 غاز عند إرسال المعاملات ، ولكن يجب إيلاء المزيد من الاهتمام لضمان أن الطرف المتلقي للمحفظة لا يتتبع فقط تحويلات ETH من EOA ، ولكن أيضًا تحويلات ETH من EOA كود العقد الذكي. يجب على التطبيقات التي تعتمد على الملكية الثابتة للعناوين (مثل NFTs التي تحظر العقود الذكية لفرض الإتاوات) أن تجد طرقًا أخرى لتحقيق أهدافها. ستجعل محافظ العقود الذكية أيضًا بعض الأشياء أسهل ، خاصةً إذا كان شخص ما يقبل فقط الرموز المميزة بخلاف ETH ERC20 ، فسيكون قادرًا على استخدام مسؤول دفع ERC-4337 للدفع مقابل الغاز باستخدام هذا الرمز المميز.
من ناحية أخرى ، تعد مسألة الخصوصية مرة أخرى تحديًا كبيرًا لم نحلّه بعد. لم تقدم Tornado Cash الأصلية هذه المشكلات لأنها لا تدعم التحويلات الداخلية: يمكن للمستخدمين فقط إيداع الأموال وسحبها في النظام. ومع ذلك ، بمجرد أن تصبح عمليات النقل الداخلية ممكنة ، سيحتاج المستخدمون إلى استخدام نظام العنونة الداخلي لنظام الخصوصية. من الناحية العملية ، يجب أن تحتوي "رسالة الدفع" الخاصة بالمستخدم على (1) نوعًا من "إنفاق المفتاح العام" ، وهو التزام سري يمكن للمتلقي استخدامه للإنفاق ، و (2) يمكن للمرسل إرسال رسائل مشفرة لا يستخدمها سوى المتلقي يمكن فك تشفير متلقي المساعدة يكتشف طريقة الدفع.
يعتمد بروتوكول العنوان الخفي على مفهوم العنوان الفوقي ، والذي يعمل على النحو التالي: جزء من العنوان هو مفتاح الإنفاق المخادع للمرسل ، والجزء الآخر هو المفتاح المشفر للمرسل (على الرغم من أن الحد الأدنى من التنفيذ يمكن أن يحدد كلا المفتاحين أن يكون نفسه).
نظرة عامة على مخططات عناوين التسلل المجردة القائمة على التشفير و ZK-SNARKs *
الدرس الأساسي هنا هو أنه ** في نظام بيئي صديق للخصوصية ، سيُنفق المستخدمون المفاتيح العامة والمفاتيح العامة للتشفير ، وستحتاج "معلومات الدفع" الخاصة بالمستخدمين إلى تضمين كلا المفتاحين. ** إلى جانب الدفع ، هناك أسباب وجيهة أخرى لتوسيع هذا الاتجاه. على سبيل المثال ، إذا أردنا رسائل بريد إلكتروني مشفرة تستند إلى Ethereum ، فسيحتاج المستخدمون إلى تقديم نوع من مفتاح التشفير بشكل عام. في "عالم EOA" يمكننا إعادة استخدام مفاتيح الحساب ، ولكن في عالم محافظ العقود الذكية الآمنة ، ربما ينبغي علينا توفير وظائف أكثر وضوحًا لهذا الغرض. يساعد هذا أيضًا في جعل الهويات المستندة إلى Ethereum أكثر توافقًا مع أنظمة الخصوصية اللامركزية غير Ethereum ، وخاصة مفاتيح PGP.
هذه التحولات الثلاثة واستعادة المفاتيح
في عالم يمتلك فيه كل مستخدم عناوين متعددة ، فإن الطريقة الافتراضية لتنفيذ التغييرات الرئيسية والتعافي الاجتماعي هي جعل المستخدمين يديرون عملية الاسترداد على كل عنوان على حدة. يمكن القيام بذلك بنقرة واحدة: يمكن للمحفظة توفير وظيفة برمجية لأداء عملية الاسترداد في وقت واحد على جميع عناوين المستخدم. ومع ذلك ، حتى مع هذا التبسيط لتجربة المستخدم ، هناك ثلاث مشاكل في الاسترداد متعدد العناوين:
** 1. تكلفة الغاز غير واقعية: ** هذا بديهي.
** 2. العناوين المقابلة: ** العناوين التي لم تصدر عقدًا ذكيًا بعد (في الواقع ، سيعني هذا الحسابات التي لم ترسل الأموال منها بعد). بصفتك مستخدمًا ، قد يكون لديك عدد لا حصر له من العناوين الافتراضية: واحد أو أكثر في كل L2 ، بما في ذلك L2s التي لم تكن موجودة بعد ، ومجموعة كاملة لا حصر لها من العناوين الافتراضية الناشئة عن نظام العناوين التخفي.
** 3. الخصوصية **: إذا كان المستخدم يستخدم عناوين متعددة عن قصد لتجنب ربطها ببعضها البعض ، فمن المؤكد أنه لا يريد ربطها جميعًا علنًا من خلال استعادتها في نفس الوقت تقريبًا!
حل هذه المشاكل صعب. لحسن الحظ ، هناك حل أنيق إلى حد ما يعمل بشكل جيد: ** تفصل هذه البنية بين منطق التحقق من صحة الأصول **.
كل مستخدم لديه ** عقد تخزين مفاتيح ** موجود في مكان واحد (يمكن أن يكون شبكة رئيسية أو L2 محددًا). بعد ذلك ، يكون لدى المستخدمين عناوين على L2s مختلفة ، ويكون منطق التحقق لكل عنوان مؤشرًا لعقد مخزن المفاتيح. سيتطلب إنفاق الأموال من هذه العناوين تقديم دليل على إنفاق مفتاح عام حالي (أو أكثر واقعية ، حديث جدًا) لإنفاق الأموال.
يمكن تحقيق هذا الإثبات بعدة طرق:
** وصول للقراءة فقط إلى L1 مباشرة داخل L2. ** يمكن تعديل L2 لتمكينه من قراءة حالة L1 مباشرة. إذا كان عقد مخزن المفاتيح على L1 ، فهذا يعني أن العقود في L2 لها وصول "مجاني" إلى مخزن المفاتيح.
** فروع ميركل. ** يمكن أن تثبت فروع Merkle من حالة L1 إلى L2 ، أو حالة L2 إلى L1 ، أو يمكن أن يثبت الجمع بينهما حالة جزئية من L2 إلى L2 آخر. يتمثل الضعف الرئيسي في براهين Merkle في ارتفاع تكلفة الغاز نظرًا لطول الإثبات ، والذي قد يتطلب طول إثبات يبلغ 5 كيلوبايت ، ولكن نظرًا لاستخدام أشجار Verkle ، سيتم تقليل هذا إلى <1 كيلوبايت في المستقبل.
** ZK-SNARKs. ** يمكنك تقليل تكاليف البيانات باستخدام ZK-SNARKs من فروع Merkle بدلاً من استخدام الفروع نفسها. يمكن بناء تقنيات التجميع خارج السلسلة (على سبيل المثال أعلى EIP-4337) لتمكين ZK-SNARK واحد للتحقق من جميع براهين الحالة عبر السلسلة في كتلة.
** وعد KZG. ** سواء كان L2 أو المخطط المبني عليه ، يمكن تقديم نظام عنونة متسلسل ، مما يسمح بإثبات الحالة داخل النظام ليكون 48 بايت فقط. مثل ZK-SNARKs ، يمكن لمخططات الإثبات المتعدد أن تجمع كل هذه البراهين في برهان واحد لكل كتلة.
إذا أردنا تجنب الحاجة إلى إثبات لكل معاملة ، فيمكننا تنفيذ مخطط خفيف الوزن لا يتطلب سوى الاسترداد عبر براهين L2. يعتمد الإنفاق من الحساب على مفتاح الإنفاق مع مفتاحه العام المطابق المخزن داخل الحساب ، لكن الاسترداد يتطلب معاملة لنسخ المفتاح العام للإنفاق الحالي في مخزن المفاتيح. حتى إذا لم تكن مفاتيحك القديمة آمنة ، فإن الأموال الموجودة في العنوان الافتراضي آمنة: "تنشيط" العنوان الافتراضي لتحويله إلى عقد قابل للاستخدام سيتطلب إثباتًا عبر المستوى الثاني لتكرار مفتاح الإنفاق العام الحالي. هناك سلسلة رسائل في المنتديات الآمنة تصف كيفية عمل بنية مشابهة.
** لإضافة الخصوصية إلى مثل هذا المخطط ، نحتاج فقط إلى تشفير المؤشرات والقيام بجميع البراهين داخل ZK-SNARKs **:
! [oPPxXrxZMKxPRzuumeg4QKpYKVsumDQESW4VmbCB.png] (https://img.gateio.im/social/moments-40baef27dd-1629fceb84-dd1a6f-62a40f "7049167") يمكننا أيضًا العمل كنقطة بداية (على سبيل المثال) ZK -معظم تعقيد SNARKs ، بناء مخطط مبسط يعتمد على KZG.
يمكن أن تصبح هذه السيناريوهات معقدة. الجانب الإيجابي هو أن هناك العديد من أوجه التآزر المحتملة بينهما. على سبيل المثال ، يمكن أن يكون مفهوم "عقد مخزن المفاتيح" أيضًا حلاً لـ "العنوان" المذكور في القسم السابق: إذا أردنا أن يكون لدى المستخدمين عنوان دائم لا يتغير في كل مرة يقوم فيها المستخدم بتحديث المفتاح ، يمكن وضع التسلل يتم وضع عنوان التعريف ومفتاح التشفير والمعلومات الأخرى في عقد مخزن المفاتيح ، ويتم استخدام عنوان عقد مخزن المفاتيح باعتباره "عنوان" المستخدم.
يحتاج الكثير من البنية التحتية الثانوية إلى التحديث
استخدام ENS مكلف. على الرغم من أنها ليست باهظة الثمن كما كانت من قبل في يونيو 2023 ، إلا أن رسوم المعاملات لتسجيل اسم المجال لا تزال مرتفعة نسبيًا ، وهو ما يمكن مقارنته بتكلفة اسم مجال ENS. على سبيل المثال ، يكلف التسجيل في zuzalu.eth حوالي 27 دولارًا ، منها 11 دولارًا هي رسوم المعاملات. ولكن إذا تحول السوق إلى الاتجاه الصعودي مرة أخرى ، فسوف ترتفع الرسوم. حتى إذا لم يرتفع سعر ETH ، إذا عادت رسوم الغاز إلى 200 gwei ، فإن رسوم المعاملات لتسجيل اسم النطاق ستصل إلى 104 دولارات أمريكية. لذلك إذا أردنا أن يستخدم الأشخاص بالفعل ENS ، خاصةً في حالات الاستخدام مثل الوسائط الاجتماعية اللامركزية حيث يطلب المستخدمون تسجيلًا مجانيًا تقريبًا (رسوم مجال ENS ليست مشكلة نظرًا لأن هذه الأنظمة الأساسية يمكن أن توفر للمستخدمين نطاقات فرعية) ، فنحن بحاجة إلى استخدام ENS على طبقة 2.
لحسن الحظ ، صعد فريق ENS بالفعل ويتم تنفيذ ENS على الطبقة 2! يوفر ERC-3668 (المعروف أيضًا باسم "معيار CCIP") و ENSIP-10 طريقة للتحقق تلقائيًا من نطاقات ENS الفرعية على أي طبقة 2. يتطلب معيار CCIP إعداد عقد ذكي يصف طريقة التحقق من أدلة البيانات على الطبقة 2 ، ويمكن وضع اسم المجال (ecc.eth for Optinames ، على سبيل المثال) تحت سيطرة هذا العقد. بمجرد أن يتحكم عقد CCIP في ecc.eth على L1 ، سيجد الوصول إلى نطاق فرعي معين.
. بطريقة ما قد يبدو الأمر وكأنه مركزية ، لكنني أقول إنه ليس كذلك في الواقع: إنه نموذج ثقة من 1 إلى N (يتم اكتشاف البراهين غير الصالحة من خلال منطق التحقق من الصحة في وظيفة استدعاء عقد CCIP ، طالما أن أحد عناوين URL التي ترجع إثباتًا صالحًا أمر جيد). قد تحتوي قائمة عناوين URL على عشرات عناوين URL.
** تعد جهود CCIP الخاصة بـ ENS قصة نجاح ويجب أن يُنظر إليها على أنها علامة على أن الإصلاحات الجذرية التي نحتاجها ممكنة بالفعل. ** ولكن لا يزال هناك العديد من الإصلاحات على مستوى التطبيق التي يتعين القيام بها. وهنا بعض الأمثلة:
** تعتمد العديد من DApps على المستخدمين لتقديم توقيعات خارج السلسلة. ** بالنسبة للحسابات الخارجية (EOA) ، الأمر سهل. يوفر ERC-1271 طريقة موحدة للقيام بذلك لمحافظ العقود الذكية. ومع ذلك ، لا تزال العديد من DApps لا تدعم ERC-1271 ويجب تكييفها.
** DApps التي تستخدم "هل هذا EOA؟" للتمييز بين المستخدمين والعقود (على سبيل المثال لمنع عمليات النقل أو فرض الإتاوات) ستواجه مشاكل. ** بشكل عام ، أنصح بعدم محاولة إيجاد حل تقني بحت هنا ؛ تحديد ما إذا كان نقل معين للتحكم في التشفير هو نقل ملكية مفيد يمثل مشكلة صعبة قد لا يتم حلها دون اللجوء إلى بعض خارج السلسلة مدفوعة من المجتمع آليات حل. على الأرجح ، ستعتمد التطبيقات بدرجة أقل على الوسائل التقنية لمنع عمليات النقل وستعتمد أكثر على تقنيات مثل ضريبة Harberger.
** سيحتاج تفاعل المحفظة مع الدفعات ومفاتيح التشفير إلى تحسين. ** في الوقت الحالي ، تستخدم المحافظ عادةً التوقيعات الحتمية لإنشاء مفاتيح خاصة بالتطبيق: سيؤدي التوقيع على رمز nonce قياسي (مثل تجزئة اسم التطبيق) باستخدام المفتاح الخاص لـ EOA إلى إنشاء قيمة حتمية ما لم يكن المفتاح الخاص في حيازة ، وإلا فإن القيمة لا يمكن إنشاؤها وبالتالي فهي آمنة من الناحية الفنية. ومع ذلك ، فإن هذه التقنيات "غير شفافة" للمحفظة ، مما يمنع المحافظ من تنفيذ فحوصات أمان على مستوى واجهة المستخدم. في نظام بيئي أكثر نضجًا ، سيتعين التعامل مع التوقيع والتشفير والوظائف ذات الصلة بشكل أكثر وضوحًا بواسطة المحافظ.
** سيحتاج العملاء الخفيفون (مثل هيليوس) إلى مصادقة الطبقة الثانية بدلاً من الطبقة الأولى **** فقط. ** حاليًا ، يركز العميل الخفيف على التحقق من صحة معلومات رأس الكتلة L1 (باستخدام بروتوكول مزامنة العميل الخفيف) ، والتحقق من فرع Merkle لحالة L1 والمعاملات بناءً على معلومات رأس الكتلة L1. في المستقبل ، سيحتاجون أيضًا إلى التحقق من البراهين الخاصة بحالة L2 المتجذرة في جذر الحالة المخزن في L1 (ستنظر الإصدارات الأكثر تقدمًا في الواقع في التأكيد المسبق لـ L2).
ستحتاج المحافظ إلى حماية الأصول والبيانات
تتمثل مهمة المحفظة حاليًا في حماية الأصول. يتم تخزين كل شيء في السلسلة ، كل ما تحتاجه المحفظة لحمايتها هي المفاتيح الخاصة التي تؤمن هذه الأصول حاليًا. إذا قمت بتغيير المفتاح ، يمكنك نشر المفتاح الخاص السابق بأمان على الإنترنت في اليوم التالي. ومع ذلك ، في عالم انعدام المعرفة ، لم يعد هذا هو الحال: لا تحمي المحافظ بيانات اعتماد المصادقة فحسب ، بل تحتفظ أيضًا ببياناتك.
نرى العلامات الأولى لمثل هذا العالم في Zuzalu مع Zupass ، وهو نظام هوية قائم على ZK-SNARK. يمتلك المستخدم مفتاحًا خاصًا يستخدم للمصادقة في النظام ، والذي يمكن استخدامه لإنشاء أدلة أساسية مثل "إثبات أنني مقيم في زوزالو دون الكشف عن المقيم الذي أنا فيه". بدأ نظام Zupass أيضًا في إنشاء تطبيقات أخرى فوقه ، أهمها الطوابع (إصدار Zupass من POAP).
أحد أختام Zupass العديدة الخاصة بي والتي تؤكد أنني عضو في Team Cat. *
الميزة الرئيسية للطوابع المتعلقة بـ POAP هي أنها خاصة: تحتفظ بالبيانات محليًا ، وتثبت فقط طابعًا لـ ZK (أو تقوم ببعض العمليات الحسابية على الطوابع) إذا كنت ترغب في إعطاء هذه المعلومات لشخص ما. لكن هذا يأتي أيضًا مع مخاطر إضافية: إذا فقدت تلك المعلومات ، فستفقد طوابعك.
بالطبع ، يمكن تقليل مشكلة الاحتفاظ بالبيانات إلى مشكلة الاحتفاظ بمفتاح تشفير واحد: يمكن لطرف ثالث (حتى على السلسلة) الاحتفاظ بنسخة مشفرة من البيانات. يتمتع هذا بميزة ملائمة تتمثل في أن الإجراء الذي تتخذه لا يغير مفتاح التشفير ، لذلك لا يلزم التفاعل مع النظام الذي يحتفظ بمفتاح التشفير. ولكن حتى ذلك الحين ، إذا فقدت مفتاح التشفير ، فستفقد جميع بياناتك. ** وبالتالي ، ** إذا رأى شخص ما مفتاح التشفير الخاص بك ، فسيكون قادرًا على رؤية كل شيء مشفر بهذا المفتاح. **
يتمثل الحل العملي لـ Zupass في تشجيع الأشخاص على تخزين مفاتيحهم على أجهزة متعددة (مثل الكمبيوتر المحمول والهاتف) ، نظرًا لأن فرص فقدانهم للوصول إليها جميعًا في نفس الوقت ضئيلة. يمكننا أن نخطو خطوة إلى الأمام باستخدام مشاركة المفاتيح لتقسيم تخزين المفاتيح بين أدوات حماية متعددة.
لا يعد التعافي الاجتماعي عبر MPC حلاً مناسبًا للمحافظ ، لأنه لا يعني أن الحامي الحالي فحسب ، بل قد يتواطأ أيضًا الحماة السابقون لسرقة أصولك ، وهو ما يمثل مخاطرة عالية بشكل غير مقبول. لكن خرق الخصوصية عادة ما يكون أقل خطورة من الخسارة الكاملة للأصول ، وبالنسبة لحالات الاستخدام ذات الاحتياجات العالية للخصوصية ، يمكن قبول مخاطر فقدان أكبر من خلال عدم نسخ المفاتيح المرتبطة باحتياجات الخصوصية هذه احتياطيًا.
لتجنب إرباك المستخدمين في نظام معقد من مسارات استرداد متعددة ، قد تحتاج المحافظ التي تدعم التعافي الاجتماعي إلى إدارة كلا جانبي استرداد الأصول واسترداد مفتاح التشفير.
العودة إلى الهوية
الموضوع المشترك بين هذه التغييرات هو أن مفهوم "العنوان" كتمثيل للهوية على blockchain سوف يحتاج إلى تغيير جذري. ** لن تكون "التعليمات الخاصة بكيفية التفاعل معي" مجرد عنوان ETH ؛ صريح. **
تتمثل إحدى هذه الطرق في استخدام ENS كهويتك: يمكن أن يحتوي سجل ENS الخاص بك على جميع المعلومات حول كيفية الدفع والتفاعل معك ، إذا قمت بإرسال شخص bob.eth (أو bob.ecc.eth وما إلى ذلك) ، فيمكنه الاستفسار والتعرف على كل ما يتفاعل معك ، بما في ذلك الطرق الأكثر تعقيدًا عبر المجالات ومع حماية الخصوصية.
ومع ذلك ، فإن هذا النهج المتمحور حول ENS يعاني من نقطتي ضعف:
** يربط الكثير من المحتوى باسمك. ** اسمك لا يعني كل شيء عنك ، فهو مجرد سمة من سماتك العديدة. يجب أن يكون من الممكن تغيير اسمك دون ترحيل ملف تعريف هويتك بالكامل وتحديث السجلات في العديد من التطبيقات.
** لا يمكن أن يكون لديك أسماء غير واقعية ولا تتطلب الثقة. ** الميزة الرئيسية لتجربة المستخدم في أي blockchain هي القدرة على إرسال الرموز المميزة إلى الأشخاص الذين لم يتفاعلوا مع السلسلة بعد. بدون هذه الوظيفة ، هناك معضلة: التفاعل مع السلسلة يتطلب دفع رسوم المعاملات ، ودفع رسوم المعاملات يتطلب ... امتلاك الرموز المميزة بالفعل. تحتوي عناوين ETH ، بما في ذلك عناوين العقود الذكية مع CREATE2 ، على هذه الوظيفة. أسماء ENS لا تفعل ذلك ، لأنه إذا قرر كل من Bobs خارج السلسلة أنهما bob.ecc.eth ، فلا توجد طريقة لاختيار بوب الذي سيحصل على الاسم.
أحد الحلول الممكنة هو وضع المزيد من المحتوى في عقد مخزن المفاتيح المذكور سابقًا في بنية هذه المقالة. يمكن أن يحتوي عقد مخزن المفاتيح على معلومات مختلفة عنك والتفاعلات معك (ومع CCIP ، يمكن أن تكون بعض هذه المعلومات خارج السلسلة) ، سيستخدم المستخدمون عقد مخزن المفاتيح كمعرف أساسي لهم. ومع ذلك ، سيتم تخزين الأصول التي يتلقونها بالفعل في مجموعة متنوعة من الأماكن المختلفة. تعد عقود Keystore حيادية الاسم وصديقة للاسم الافتراضي: يمكنك إنشاء عنوان لا يمكن تهيئته إلا من خلال عقد مخزن المفاتيح باستخدام معلمات أولية ثابتة معينة.
فئة أخرى من الحلول تتضمن التخلي عن فكرة العناوين التي تواجه المستخدم تمامًا ، على غرار بروتوكول الدفع الخاص بالبيتكوين. تتمثل إحدى الأفكار في الاعتماد بشكل أكبر على قنوات الاتصال المباشر بين المرسل والمستقبل ؛ على سبيل المثال ، يمكن للمرسل إرسال رابط طلب (كعنوان URL صريح أو رمز QR) ، والذي يمكن للمستلم استخدامه لإرسال أي طلب يرغب في قبوله. قسط.
سواء كان المرسل أو المستلم هو الذي يتصرف أولاً ، فإن الاعتماد أكثر على المحافظ لإنشاء معلومات دفع محدثة في الوقت الفعلي يقلل الاحتكاك. ومع ذلك ، فإن المعرفات المستمرة مريحة (خاصة مع ENS) ، بينما يعد الاعتماد في الممارسة العملية على الاتصال المباشر بين المرسل والمستقبل مشكلة صعبة للغاية ، لذلك يمكن رؤية مجموعة من التقنيات المختلفة.
في كل هذه التصميمات ، من الأهمية بمكان أن تظل لامركزية ومفهومة للمستخدمين. نحن بحاجة إلى التأكد من أن المستخدمين يمكنهم الوصول بسهولة إلى عرض محدث لأصولهم الحالية والرسائل التي تستهدفهم. يجب أن تعتمد وجهات النظر هذه على الأدوات المفتوحة بدلاً من الحلول الاحتكارية. سوف يتطلب الأمر عملاً شاقًا للحفاظ على التعقيد الأكبر للبنية التحتية للدفع من أن يصبح "برجًا للتجريد" مبهمًا يصعب فهمه والتكيف معه مع البيئات الجديدة. على الرغم من التحديات ، فإن تحقيق قابلية تطوير Ethereum وأمن المحفظة والخصوصية للمستخدمين العاديين أمر بالغ الأهمية. لا يتعلق الأمر فقط بالجدوى الفنية ، بل يتعلق بإمكانية الوصول الفعلي للمستخدم العادي. نحن بحاجة لمواجهة هذا التحدي.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
Vitalik: يحتاج النظام البيئي Ethereum إلى ثلاثة تحولات تكنولوجية
المؤلف: فيتاليك ، مؤسس Ethereum ؛ الترجمة: Jinse Finance cryptonaitive
نظرًا لتطور Ethereum من تقنية تجريبية شابة إلى مجموعة تقنية ناضجة قادرة على تقديم تجربة مفتوحة وعالمية وغير مصرح بها للمستخدمين العاديين ، فهناك ثلاثة انتقالات تكنولوجية رئيسية يجب أن تحدث في وقت واحد:
! [HNKgp8WXi33DVPqvL8nxykZF6OvcbmFH3AO6jQjv.png] (https://img.gateio.im/social/moments-40baef27dd-ad4df3840f-dd1a6f-62a40f "7049162")
بدون العنصر الأول ، ستفشل Ethereum لأن كل معاملة تكلف 3.75 دولارًا (82.48 دولارًا أمريكيًا إذا مررنا بمسار صعودي آخر) ، وكل منتج في السوق الشامل سوف يسقط حتمًا التجارة عبر السلسلة ويتبنى حلاً مركزيًا.
بدون العنصر الثاني ، ستفشل Ethereum لأن المستخدمين لن يكونوا مستعدين لتخزين أموالهم (والأصول غير المالية) وسيتحول الجميع إلى التبادلات المركزية.
بدون العنصر الثالث ، ستفشل Ethereum لأنه بالنسبة للعديد من المستخدمين ، ستكون جميع المعاملات (و POAP وما إلى ذلك) مرئية للعامة ، وستكون التضحية بالخصوصية كبيرة جدًا وسيتجه الجميع إلى مستوى معين على الأقل من حل مركزي للبيانات المخفية.
للأسباب الموضحة أعلاه ، تعتبر هذه التحولات الثلاثة حاسمة. لكنها تمثل أيضًا تحديًا نظرًا لتعقيد التنسيق الذي ينطوي عليه الأمر. ليست وظائف البروتوكول هي فقط التي تحتاج إلى تحسين ؛ في بعض الحالات ، تحتاج الطريقة التي نتفاعل بها مع Ethereum إلى تغيير جذري وعميق ، مما يتطلب تغييرات كبيرة في التطبيقات والمحافظ.
ستعيد هذه التحولات الثلاثة بشكل أساسي تشكيل العلاقة بين المستخدمين والعناوين
في عالم من مقياس L2 ، سيكون المستخدمون موجودين على شبكات L2 متعددة. هل أنت عضو في ExampleDAO؟ exampleDAO على التفاؤل. إذن لديك حساب مع التفاؤل! هل تمتلك CDP لنظام عملة مستقرة على ZkSync؟ إذن لديك حساب على ZkSync! هل سبق لك أن جربت بعض التطبيقات الموجودة على Kakarot؟ إذن لديك حساب على Kakarot! لقد ولت الأيام التي كان لدى المستخدمين فيها عنوان واحد فقط.
! [kJxidBFR5zU5hNHQVmOs969XyFT9VZ3cDAmKwUvV.png] (https://img.gateio.im/social/moments-40baef27dd-96350c2454-dd1a6f-62a40f "7049163ereum") عرض أربعة مواضع Brave. نعم ، يختلف Arbitrum و Arbitrum Nova. لا تقلق ، ستزداد الأمور تعقيدًا بمرور الوقت! *
** تضيف محافظ العقود الذكية مزيدًا من التعقيد لأنها تجعل من الصعب الحصول على نفس العنوان على L1 وشبكات L2 المختلفة. ** يستخدم معظم المستخدمين اليوم حسابات مملوكة خارجيًا تكون عناوينها في الواقع تجزئة للمفاتيح العامة المستخدمة للتحقق من التوقيعات - لذلك لا شيء يتغير بين L1 و L2. ومع ذلك ، يصبح الاحتفاظ بالعنوان أكثر صعوبة عند استخدام محفظة عقد ذكية. بينما تم إنجاز الكثير من العمل لمحاولة جعل العناوين تجزئة من التعليمات البرمجية المكافئة عبر شبكات مختلفة ، وأهمها CREATE2 ومصنع ERC-2470 الفردي ، فمن الصعب تحقيق ذلك بشكل مثالي. بعض شبكات L2 (على سبيل المثال ، "ZK-EVM من النوع الرابع") ليست مكافئة تمامًا لأجهزة EVM ، وغالبًا ما تستخدم لغة صلبة أو لغة تجميع وسيطة بدلاً من معادلات التجزئة. حتى إذا كان من الممكن تحقيق تكافؤ التجزئة ، فإن إمكانية تغيير الملكية من خلال التغييرات الرئيسية للمحافظ تؤدي إلى عواقب أخرى أقل قابلية للتنبؤ.
** تتطلب الخصوصية المزيد من العناوين لكل مستخدم وقد تغير حتى أنواع العناوين التي نتعامل معها. ** إذا تم استخدام اقتراح العنوان المتخفي على نطاق واسع ، فقد يكون لدى المستخدمين عنوان واحد لكل معاملة بدلاً من بضعة عناوين فقط لكل مستخدم أو عنوان واحد لكل شبكة L2. تعمل مخططات الخصوصية الأخرى ، حتى تلك الموجودة مثل Tornado Cash ، على تغيير طريقة تخزين الأصول بطرق مختلفة: يتم تخزين أموال العديد من المستخدمين في نفس العقد الذكي (وبالتالي على نفس العنوان). لإرسال أموال إلى مستخدم معين ، سيحتاج المستخدم إلى الاعتماد على نظام العنونة الداخلي الخاص بنظام الخصوصية.
كما رأينا ، ** تُضعف هذه التحولات الثلاثة النموذج العقلي "لمستخدم واحد - عنوان واحد" ** بطرق مختلفة ، تؤدي بعض التأثيرات بدورها إلى زيادة تعقيد تنفيذ هذه التحولات. اثنان من القضايا المعقدة بشكل خاص هي:
** 1. إذا كنت تريد الدفع لشخص ما ، كيف ستحصل على معلومات الدفع؟ **
** 2. إذا قام المستخدمون بتخزين الأصول في مواقع مختلفة على سلاسل مختلفة ، فكيف يقومون بإجراء التغييرات الرئيسية والتعافي الاجتماعي؟ **
هذه التحولات الثلاثة والمدفوعات على السلسلة (والهوية)
أحمل الرموز المميزة في Scroll ، وأريد استخدامها لشراء القهوة (إذا كانت الحرف "I" تشير إلى Vitalik ، مؤلف هذه المقالة ، فإن كلمة "coffee" تعني بالطبع "الشاي الأخضر"). أنت تبيع القهوة على Taiko ، لكنك تقبل الرموز فقط على Taiko. ما يجب القيام به؟
هناك حلان أساسيان:
المحفظة المستلمة (التي يمكن أن تكون تاجرًا أو فردًا عاديًا) تسعى جاهدة لدعم كل L2 ولديها بعض وظائف دمج الأموال غير المتزامنة.
يقدم المدفوع لأمره معلومات L2 الخاصة به بجوار العنوان ، وتقوم محفظة المرسل تلقائيًا بتوجيه الأموال إلى L2 الهدف من خلال نوع من نظام التجسير المتقاطع L2.
بالطبع ، يمكن استخدام هذه الحلول معًا: يوفر المستفيد قائمة L2 التي يرغب في قبولها ، وتحدد محفظة المرسل طريقة الدفع ، والتي يمكن إرسالها مباشرةً (مع الحظ) ، أو الدفع عبر مسار مرتبط عبر L2.
ولكن هذا مجرد مثال واحد على التحدي الرئيسي الذي قدمته التحولات الثلاثة: ** تبدأ سلوكيات الدفع البسيطة في طلب معلومات أكثر من مجرد عنوان مكون من 20 بايتًا **.
لحسن الحظ ، لا يمثل الانتقال إلى محافظ العقود الذكية عبئًا كبيرًا على نظام العناوين ، ولكن لا تزال هناك بعض المشكلات الفنية التي يجب حلها في أجزاء أخرى من حزمة التطبيقات. تحتاج المحافظ إلى التحديث للتأكد من أنها لا ترسل فقط 21000 غاز عند إرسال المعاملات ، ولكن يجب إيلاء المزيد من الاهتمام لضمان أن الطرف المتلقي للمحفظة لا يتتبع فقط تحويلات ETH من EOA ، ولكن أيضًا تحويلات ETH من EOA كود العقد الذكي. يجب على التطبيقات التي تعتمد على الملكية الثابتة للعناوين (مثل NFTs التي تحظر العقود الذكية لفرض الإتاوات) أن تجد طرقًا أخرى لتحقيق أهدافها. ستجعل محافظ العقود الذكية أيضًا بعض الأشياء أسهل ، خاصةً إذا كان شخص ما يقبل فقط الرموز المميزة بخلاف ETH ERC20 ، فسيكون قادرًا على استخدام مسؤول دفع ERC-4337 للدفع مقابل الغاز باستخدام هذا الرمز المميز.
من ناحية أخرى ، تعد مسألة الخصوصية مرة أخرى تحديًا كبيرًا لم نحلّه بعد. لم تقدم Tornado Cash الأصلية هذه المشكلات لأنها لا تدعم التحويلات الداخلية: يمكن للمستخدمين فقط إيداع الأموال وسحبها في النظام. ومع ذلك ، بمجرد أن تصبح عمليات النقل الداخلية ممكنة ، سيحتاج المستخدمون إلى استخدام نظام العنونة الداخلي لنظام الخصوصية. من الناحية العملية ، يجب أن تحتوي "رسالة الدفع" الخاصة بالمستخدم على (1) نوعًا من "إنفاق المفتاح العام" ، وهو التزام سري يمكن للمتلقي استخدامه للإنفاق ، و (2) يمكن للمرسل إرسال رسائل مشفرة لا يستخدمها سوى المتلقي يمكن فك تشفير متلقي المساعدة يكتشف طريقة الدفع.
يعتمد بروتوكول العنوان الخفي على مفهوم العنوان الفوقي ، والذي يعمل على النحو التالي: جزء من العنوان هو مفتاح الإنفاق المخادع للمرسل ، والجزء الآخر هو المفتاح المشفر للمرسل (على الرغم من أن الحد الأدنى من التنفيذ يمكن أن يحدد كلا المفتاحين أن يكون نفسه).
! [6sJaiU5VL1SN4pIHAUeM9qfHvrD0BWAscneXZrT6.png] (https://img.gateio.im/social/moments-40baef27dd-3f62ee3b95-dd1a6f-62a40f "7049164")
الدرس الأساسي هنا هو أنه ** في نظام بيئي صديق للخصوصية ، سيُنفق المستخدمون المفاتيح العامة والمفاتيح العامة للتشفير ، وستحتاج "معلومات الدفع" الخاصة بالمستخدمين إلى تضمين كلا المفتاحين. ** إلى جانب الدفع ، هناك أسباب وجيهة أخرى لتوسيع هذا الاتجاه. على سبيل المثال ، إذا أردنا رسائل بريد إلكتروني مشفرة تستند إلى Ethereum ، فسيحتاج المستخدمون إلى تقديم نوع من مفتاح التشفير بشكل عام. في "عالم EOA" يمكننا إعادة استخدام مفاتيح الحساب ، ولكن في عالم محافظ العقود الذكية الآمنة ، ربما ينبغي علينا توفير وظائف أكثر وضوحًا لهذا الغرض. يساعد هذا أيضًا في جعل الهويات المستندة إلى Ethereum أكثر توافقًا مع أنظمة الخصوصية اللامركزية غير Ethereum ، وخاصة مفاتيح PGP.
هذه التحولات الثلاثة واستعادة المفاتيح
في عالم يمتلك فيه كل مستخدم عناوين متعددة ، فإن الطريقة الافتراضية لتنفيذ التغييرات الرئيسية والتعافي الاجتماعي هي جعل المستخدمين يديرون عملية الاسترداد على كل عنوان على حدة. يمكن القيام بذلك بنقرة واحدة: يمكن للمحفظة توفير وظيفة برمجية لأداء عملية الاسترداد في وقت واحد على جميع عناوين المستخدم. ومع ذلك ، حتى مع هذا التبسيط لتجربة المستخدم ، هناك ثلاث مشاكل في الاسترداد متعدد العناوين:
** 1. تكلفة الغاز غير واقعية: ** هذا بديهي.
** 2. العناوين المقابلة: ** العناوين التي لم تصدر عقدًا ذكيًا بعد (في الواقع ، سيعني هذا الحسابات التي لم ترسل الأموال منها بعد). بصفتك مستخدمًا ، قد يكون لديك عدد لا حصر له من العناوين الافتراضية: واحد أو أكثر في كل L2 ، بما في ذلك L2s التي لم تكن موجودة بعد ، ومجموعة كاملة لا حصر لها من العناوين الافتراضية الناشئة عن نظام العناوين التخفي.
** 3. الخصوصية **: إذا كان المستخدم يستخدم عناوين متعددة عن قصد لتجنب ربطها ببعضها البعض ، فمن المؤكد أنه لا يريد ربطها جميعًا علنًا من خلال استعادتها في نفس الوقت تقريبًا!
حل هذه المشاكل صعب. لحسن الحظ ، هناك حل أنيق إلى حد ما يعمل بشكل جيد: ** تفصل هذه البنية بين منطق التحقق من صحة الأصول **.
! [ScKjjpjR83ThNPkG5Rsr6y2w1W2XE6DU5dYfKVfn.png] (https://img.gateio.im/social/moments-40baef27dd-bdefc6bec2-dd1a6f-62a40f "7049165")
كل مستخدم لديه ** عقد تخزين مفاتيح ** موجود في مكان واحد (يمكن أن يكون شبكة رئيسية أو L2 محددًا). بعد ذلك ، يكون لدى المستخدمين عناوين على L2s مختلفة ، ويكون منطق التحقق لكل عنوان مؤشرًا لعقد مخزن المفاتيح. سيتطلب إنفاق الأموال من هذه العناوين تقديم دليل على إنفاق مفتاح عام حالي (أو أكثر واقعية ، حديث جدًا) لإنفاق الأموال.
يمكن تحقيق هذا الإثبات بعدة طرق:
! [AhrxqCX1MAlnzAwzfWzbA495wGfwI94IT5Gruu5E.png] (https://img.gateio.im/social/moments-40baef27dd-7cc88c38b7-dd1a6f-62a40f "7049166")
إذا أردنا تجنب الحاجة إلى إثبات لكل معاملة ، فيمكننا تنفيذ مخطط خفيف الوزن لا يتطلب سوى الاسترداد عبر براهين L2. يعتمد الإنفاق من الحساب على مفتاح الإنفاق مع مفتاحه العام المطابق المخزن داخل الحساب ، لكن الاسترداد يتطلب معاملة لنسخ المفتاح العام للإنفاق الحالي في مخزن المفاتيح. حتى إذا لم تكن مفاتيحك القديمة آمنة ، فإن الأموال الموجودة في العنوان الافتراضي آمنة: "تنشيط" العنوان الافتراضي لتحويله إلى عقد قابل للاستخدام سيتطلب إثباتًا عبر المستوى الثاني لتكرار مفتاح الإنفاق العام الحالي. هناك سلسلة رسائل في المنتديات الآمنة تصف كيفية عمل بنية مشابهة.
** لإضافة الخصوصية إلى مثل هذا المخطط ، نحتاج فقط إلى تشفير المؤشرات والقيام بجميع البراهين داخل ZK-SNARKs **:
! [oPPxXrxZMKxPRzuumeg4QKpYKVsumDQESW4VmbCB.png] (https://img.gateio.im/social/moments-40baef27dd-1629fceb84-dd1a6f-62a40f "7049167") يمكننا أيضًا العمل كنقطة بداية (على سبيل المثال) ZK -معظم تعقيد SNARKs ، بناء مخطط مبسط يعتمد على KZG.
يمكن أن تصبح هذه السيناريوهات معقدة. الجانب الإيجابي هو أن هناك العديد من أوجه التآزر المحتملة بينهما. على سبيل المثال ، يمكن أن يكون مفهوم "عقد مخزن المفاتيح" أيضًا حلاً لـ "العنوان" المذكور في القسم السابق: إذا أردنا أن يكون لدى المستخدمين عنوان دائم لا يتغير في كل مرة يقوم فيها المستخدم بتحديث المفتاح ، يمكن وضع التسلل يتم وضع عنوان التعريف ومفتاح التشفير والمعلومات الأخرى في عقد مخزن المفاتيح ، ويتم استخدام عنوان عقد مخزن المفاتيح باعتباره "عنوان" المستخدم.
يحتاج الكثير من البنية التحتية الثانوية إلى التحديث
استخدام ENS مكلف. على الرغم من أنها ليست باهظة الثمن كما كانت من قبل في يونيو 2023 ، إلا أن رسوم المعاملات لتسجيل اسم المجال لا تزال مرتفعة نسبيًا ، وهو ما يمكن مقارنته بتكلفة اسم مجال ENS. على سبيل المثال ، يكلف التسجيل في zuzalu.eth حوالي 27 دولارًا ، منها 11 دولارًا هي رسوم المعاملات. ولكن إذا تحول السوق إلى الاتجاه الصعودي مرة أخرى ، فسوف ترتفع الرسوم. حتى إذا لم يرتفع سعر ETH ، إذا عادت رسوم الغاز إلى 200 gwei ، فإن رسوم المعاملات لتسجيل اسم النطاق ستصل إلى 104 دولارات أمريكية. لذلك إذا أردنا أن يستخدم الأشخاص بالفعل ENS ، خاصةً في حالات الاستخدام مثل الوسائط الاجتماعية اللامركزية حيث يطلب المستخدمون تسجيلًا مجانيًا تقريبًا (رسوم مجال ENS ليست مشكلة نظرًا لأن هذه الأنظمة الأساسية يمكن أن توفر للمستخدمين نطاقات فرعية) ، فنحن بحاجة إلى استخدام ENS على طبقة 2.
لحسن الحظ ، صعد فريق ENS بالفعل ويتم تنفيذ ENS على الطبقة 2! يوفر ERC-3668 (المعروف أيضًا باسم "معيار CCIP") و ENSIP-10 طريقة للتحقق تلقائيًا من نطاقات ENS الفرعية على أي طبقة 2. يتطلب معيار CCIP إعداد عقد ذكي يصف طريقة التحقق من أدلة البيانات على الطبقة 2 ، ويمكن وضع اسم المجال (ecc.eth for Optinames ، على سبيل المثال) تحت سيطرة هذا العقد. بمجرد أن يتحكم عقد CCIP في ecc.eth على L1 ، سيجد الوصول إلى نطاق فرعي معين.
. بطريقة ما قد يبدو الأمر وكأنه مركزية ، لكنني أقول إنه ليس كذلك في الواقع: إنه نموذج ثقة من 1 إلى N (يتم اكتشاف البراهين غير الصالحة من خلال منطق التحقق من الصحة في وظيفة استدعاء عقد CCIP ، طالما أن أحد عناوين URL التي ترجع إثباتًا صالحًا أمر جيد). قد تحتوي قائمة عناوين URL على عشرات عناوين URL.
** تعد جهود CCIP الخاصة بـ ENS قصة نجاح ويجب أن يُنظر إليها على أنها علامة على أن الإصلاحات الجذرية التي نحتاجها ممكنة بالفعل. ** ولكن لا يزال هناك العديد من الإصلاحات على مستوى التطبيق التي يتعين القيام بها. وهنا بعض الأمثلة:
ستحتاج المحافظ إلى حماية الأصول والبيانات
تتمثل مهمة المحفظة حاليًا في حماية الأصول. يتم تخزين كل شيء في السلسلة ، كل ما تحتاجه المحفظة لحمايتها هي المفاتيح الخاصة التي تؤمن هذه الأصول حاليًا. إذا قمت بتغيير المفتاح ، يمكنك نشر المفتاح الخاص السابق بأمان على الإنترنت في اليوم التالي. ومع ذلك ، في عالم انعدام المعرفة ، لم يعد هذا هو الحال: لا تحمي المحافظ بيانات اعتماد المصادقة فحسب ، بل تحتفظ أيضًا ببياناتك.
نرى العلامات الأولى لمثل هذا العالم في Zuzalu مع Zupass ، وهو نظام هوية قائم على ZK-SNARK. يمتلك المستخدم مفتاحًا خاصًا يستخدم للمصادقة في النظام ، والذي يمكن استخدامه لإنشاء أدلة أساسية مثل "إثبات أنني مقيم في زوزالو دون الكشف عن المقيم الذي أنا فيه". بدأ نظام Zupass أيضًا في إنشاء تطبيقات أخرى فوقه ، أهمها الطوابع (إصدار Zupass من POAP).
! [rTmfKvGj2QwLr51b1YrbOuBCUefGe49t7vosPvUd.png] (https://img.gateio.im/social/moments-40baef27dd-8d502b1cae-dd1a6f-62a40f "7049169")
الميزة الرئيسية للطوابع المتعلقة بـ POAP هي أنها خاصة: تحتفظ بالبيانات محليًا ، وتثبت فقط طابعًا لـ ZK (أو تقوم ببعض العمليات الحسابية على الطوابع) إذا كنت ترغب في إعطاء هذه المعلومات لشخص ما. لكن هذا يأتي أيضًا مع مخاطر إضافية: إذا فقدت تلك المعلومات ، فستفقد طوابعك.
بالطبع ، يمكن تقليل مشكلة الاحتفاظ بالبيانات إلى مشكلة الاحتفاظ بمفتاح تشفير واحد: يمكن لطرف ثالث (حتى على السلسلة) الاحتفاظ بنسخة مشفرة من البيانات. يتمتع هذا بميزة ملائمة تتمثل في أن الإجراء الذي تتخذه لا يغير مفتاح التشفير ، لذلك لا يلزم التفاعل مع النظام الذي يحتفظ بمفتاح التشفير. ولكن حتى ذلك الحين ، إذا فقدت مفتاح التشفير ، فستفقد جميع بياناتك. ** وبالتالي ، ** إذا رأى شخص ما مفتاح التشفير الخاص بك ، فسيكون قادرًا على رؤية كل شيء مشفر بهذا المفتاح. **
يتمثل الحل العملي لـ Zupass في تشجيع الأشخاص على تخزين مفاتيحهم على أجهزة متعددة (مثل الكمبيوتر المحمول والهاتف) ، نظرًا لأن فرص فقدانهم للوصول إليها جميعًا في نفس الوقت ضئيلة. يمكننا أن نخطو خطوة إلى الأمام باستخدام مشاركة المفاتيح لتقسيم تخزين المفاتيح بين أدوات حماية متعددة.
لا يعد التعافي الاجتماعي عبر MPC حلاً مناسبًا للمحافظ ، لأنه لا يعني أن الحامي الحالي فحسب ، بل قد يتواطأ أيضًا الحماة السابقون لسرقة أصولك ، وهو ما يمثل مخاطرة عالية بشكل غير مقبول. لكن خرق الخصوصية عادة ما يكون أقل خطورة من الخسارة الكاملة للأصول ، وبالنسبة لحالات الاستخدام ذات الاحتياجات العالية للخصوصية ، يمكن قبول مخاطر فقدان أكبر من خلال عدم نسخ المفاتيح المرتبطة باحتياجات الخصوصية هذه احتياطيًا.
لتجنب إرباك المستخدمين في نظام معقد من مسارات استرداد متعددة ، قد تحتاج المحافظ التي تدعم التعافي الاجتماعي إلى إدارة كلا جانبي استرداد الأصول واسترداد مفتاح التشفير.
العودة إلى الهوية
الموضوع المشترك بين هذه التغييرات هو أن مفهوم "العنوان" كتمثيل للهوية على blockchain سوف يحتاج إلى تغيير جذري. ** لن تكون "التعليمات الخاصة بكيفية التفاعل معي" مجرد عنوان ETH ؛ صريح. **
تتمثل إحدى هذه الطرق في استخدام ENS كهويتك: يمكن أن يحتوي سجل ENS الخاص بك على جميع المعلومات حول كيفية الدفع والتفاعل معك ، إذا قمت بإرسال شخص bob.eth (أو bob.ecc.eth وما إلى ذلك) ، فيمكنه الاستفسار والتعرف على كل ما يتفاعل معك ، بما في ذلك الطرق الأكثر تعقيدًا عبر المجالات ومع حماية الخصوصية.
ومع ذلك ، فإن هذا النهج المتمحور حول ENS يعاني من نقطتي ضعف:
أحد الحلول الممكنة هو وضع المزيد من المحتوى في عقد مخزن المفاتيح المذكور سابقًا في بنية هذه المقالة. يمكن أن يحتوي عقد مخزن المفاتيح على معلومات مختلفة عنك والتفاعلات معك (ومع CCIP ، يمكن أن تكون بعض هذه المعلومات خارج السلسلة) ، سيستخدم المستخدمون عقد مخزن المفاتيح كمعرف أساسي لهم. ومع ذلك ، سيتم تخزين الأصول التي يتلقونها بالفعل في مجموعة متنوعة من الأماكن المختلفة. تعد عقود Keystore حيادية الاسم وصديقة للاسم الافتراضي: يمكنك إنشاء عنوان لا يمكن تهيئته إلا من خلال عقد مخزن المفاتيح باستخدام معلمات أولية ثابتة معينة.
فئة أخرى من الحلول تتضمن التخلي عن فكرة العناوين التي تواجه المستخدم تمامًا ، على غرار بروتوكول الدفع الخاص بالبيتكوين. تتمثل إحدى الأفكار في الاعتماد بشكل أكبر على قنوات الاتصال المباشر بين المرسل والمستقبل ؛ على سبيل المثال ، يمكن للمرسل إرسال رابط طلب (كعنوان URL صريح أو رمز QR) ، والذي يمكن للمستلم استخدامه لإرسال أي طلب يرغب في قبوله. قسط.
! [7CuFajgloD0mIkebDCVE19hWNj4MApuZPmuEMWdH.png] (https://img.gateio.im/social/moments-40baef27dd-fad7e21255-dd1a6f-62a40f "7049170")
سواء كان المرسل أو المستلم هو الذي يتصرف أولاً ، فإن الاعتماد أكثر على المحافظ لإنشاء معلومات دفع محدثة في الوقت الفعلي يقلل الاحتكاك. ومع ذلك ، فإن المعرفات المستمرة مريحة (خاصة مع ENS) ، بينما يعد الاعتماد في الممارسة العملية على الاتصال المباشر بين المرسل والمستقبل مشكلة صعبة للغاية ، لذلك يمكن رؤية مجموعة من التقنيات المختلفة.
في كل هذه التصميمات ، من الأهمية بمكان أن تظل لامركزية ومفهومة للمستخدمين. نحن بحاجة إلى التأكد من أن المستخدمين يمكنهم الوصول بسهولة إلى عرض محدث لأصولهم الحالية والرسائل التي تستهدفهم. يجب أن تعتمد وجهات النظر هذه على الأدوات المفتوحة بدلاً من الحلول الاحتكارية. سوف يتطلب الأمر عملاً شاقًا للحفاظ على التعقيد الأكبر للبنية التحتية للدفع من أن يصبح "برجًا للتجريد" مبهمًا يصعب فهمه والتكيف معه مع البيئات الجديدة. على الرغم من التحديات ، فإن تحقيق قابلية تطوير Ethereum وأمن المحفظة والخصوصية للمستخدمين العاديين أمر بالغ الأهمية. لا يتعلق الأمر فقط بالجدوى الفنية ، بل يتعلق بإمكانية الوصول الفعلي للمستخدم العادي. نحن بحاجة لمواجهة هذا التحدي.