رؤية المحفظة المثالية لإيثريوم: ترقية شاملة من تجربة عبر السلاسل إلى حماية الخصوصية
تعتبر طبقة المحفظة في بنية إثيريوم التحتية أساسية، ولكن غالبًا ما يتم التقليل من شأنها من قبل الباحثين الرئيسيين والمطورين. باعتبارها نافذة المستخدم إلى عالم إثيريوم، يجب أن تتمتع المحفظة بخصائص مثل اللامركزية، ومقاومة الرقابة، والأمان، والخصوصية، حتى يتمكن المستخدمون من الاستمتاع حقًا بهذه الخصائص التي تقدمها إثيريوم وتطبيقاتها.
مؤخراً، حققت المحفظة الخاصة بإثيريوم تقدمًا ملحوظًا في تجربة المستخدم والأمان والوظائف. يهدف هذا المقال إلى مشاركة بعض أفكاري حول الخصائص التي يجب أن تتوفر في المحفظة المثالية لإثيريوم. هذه ليست قائمة شاملة، بل تعكس المزيد من ميولي كهاكر تشفير، حيث تركز على الأمان والخصوصية، وقد تكون غير شاملة بما يكفي من حيث تجربة المستخدم. ومع ذلك، أعتقد أنه بدلاً من تحسين تجربة المستخدم بناءً على الملاحظات فقط، قد يكون من الأكثر قيمة التركيز على خصائص الأمان والخصوصية.
تجربة المستخدم في عبر السلاسل L2
هناك الآن خارطة طريق تتطور بشكل متزايد لتحسين تجربة المستخدم عبر السلاسل L2، تشمل أجزاء قصيرة وطويلة الأجل. هنا سأناقش الأفكار القابلة للتنفيذ على المدى القصير.
الفكرة الأساسية هي: (1) تضمين وظيفة إرسال عبر L2، (2) عنوان محدد على السلسلة وطلب الدفع. يجب أن توفر المحفظة للمستخدم عنواناً يتبع نمط مسودة ERC.
عندما يتلقى المستخدم عنوانًا بهذا التنسيق، ما عليه سوى لصقه في حقل "المستلم" في المحفظة والنقر على "إرسال"، يجب على المحفظة معالجة الإرسال تلقائيًا:
إذا كانت هناك عملات كافية بالفعل على سلسلة الهدف، قم بالإرسال مباشرة.
كما هو مطلوب من الرموز في سلاسل أخرى، استخدم بروتوكول DEX عبر السلاسل للإرسال
إذا كان هناك أنواع مختلفة من الرموز، قم بتحويلها إلى النوع الصحيح باستخدام DEX ثم أرسل ( يحتاج تأكيد المستخدم )
في سيناريو طلب الإيداع من قبل dapp، من الممارسات المثالية توسيع واجهة برمجة تطبيقات web3، مما يسمح لـ dapp بإصدار طلبات دفع محددة للسلاسل. يجب على المحفظة توحيد طلب getAvailableBalance، وأخذ ذلك بعين الاعتبار فيما يتعلق بالسلاسل التي يتم افتراضياً تخزين أصول المستخدم عليها، لتحقيق التوازن بين الأمان وسهولة التحويل.
يمكن أيضًا وضع طلبات الدفع الخاصة بالسلسلة في رمز الاستجابة السريعة، ليتم مسحها بواسطة المحفظة المتنقلة. في سيناريوهات الدفع وجهًا لوجه أو عبر الإنترنت، يُظهر رمز الاستجابة السريعة أو استدعاء واجهة برمجة التطبيقات المرسل من قبل المستلم "أريد Z توكن من Y وحدة على X سلسلة، مع مرجع ID W"، يمكن للمحفظة اختيار الطريقة التي تلبي هذا الطلب بحرية. خيار آخر هو بروتوكول رابط المطالبة، حيث تقوم محفظة المستخدم بإنشاء رمز استجابة سريعة أو عنوان URL يحتوي على التفويض، ويتولى المستلم مسؤولية سحب الأموال.
دفع الغاز هو أيضًا موضوع ذي صلة. إذا تلقى المستخدم الأصول على L2 معين ولكن ليس لديه ETH، يجب أن تكون المحفظة قادرة على استخدام البروتوكول تلقائيًا للدفع بالغاز على السلسلة التي يمتلك فيها المستخدم ETH. إذا كانت المحفظة تتوقع أن يقوم المستخدم بإجراء المزيد من المعاملات في المستقبل على هذا L2، يمكن أيضًا استخدام DEX لإرسال كمية معينة من ETH كاحتياطي للغاز.
أمان الحساب
أعتقد أن مفتاح أمان الحساب هو حماية المستخدمين في نفس الوقت من هجمات القراصنة أو السلوكيات الخبيثة لمطوري المحفظة، بالإضافة إلى الأخطاء التي قد يرتكبها المستخدم نفسه.
الحل الذي أميل إليه منذ فترة طويلة هو استعادة اجتماعية مع التحكم في الوصول المتدرج والمحفظة متعددة التوقيعات. تحتوي حسابات المستخدمين على مستويين من المفاتيح: المفتاح الرئيسي وN من المراقبين ( حيث N=5). يمكن استخدام المفتاح الرئيسي لإجراء عمليات ذات قيمة منخفضة وغير مالية. يجب أن يقوم معظم المراقبين بتنفيذ: (1) عمليات ذات قيمة عالية، مثل إرسال جميع أموال الحساب، (2) تغيير المفتاح الرئيسي أو أي مراقب. يمكن السماح للمفتاح الرئيسي بتنفيذ عمليات ذات قيمة عالية من خلال قفل زمني عند الضرورة.
يمكن توسيع هذا التصميم الأساسي بشكل أكبر. يمكن أن تدعم آلية مفاتيح الجلسة والصلاحيات تطبيقات مختلفة لتحقيق التوازن بين الراحة والأمان. تساعد الهياكل الأكثر تعقيدًا للحراس، مثل إعداد فترات قفل زمنية متعددة عند عتبات مختلفة، في تقليل مخاطر السرقة إلى الحد الأدنى مع تعظيم معدل نجاح استعادة الحسابات الشرعية.
بالنسبة لاختيار الوصي, هناك عدة خيارات:
يمكن للمستخدمين ذوي الخبرة في التشفير اختيار مفاتيح الأصدقاء والعائلة.
الوصي المؤسسي: شركة تقدم خدمات التوقيع بشكل متخصص، تحتاج إلى تأكيد إضافي للمعلومات.
العديد من الأجهزة الشخصية ( مثل الهواتف المحمولة، وأجهزة الكمبيوتر، والمحافظ硬ية )، لكن قد يكون من الصعب على المستخدمين الجدد إعداد وإدارة.
الحل القائم على مدير كلمات المرور، يمكن نسخه احتياطيًا محليًا أو عبر السحابة، لكن الاعتماد عليها وحدها غير كافٍ لحماية جميع أصول المستخدم.
الهوية المركزية المغلفة بتقنية ZK: مثل zk-email وAnon Aadhaar، يمكن أن تحول الهوية المركزية إلى عنوان إثيريوم.
تعد الهوية المركزية المغلفة بتقنية ZK أكثر ملاءمة للمستخدمين الجدد. يجب أن توفر المحفظة واجهة مستخدم مبسطة للتكامل، مما يسمح للمستخدمين بتحديد البريد الإلكتروني كوصي، وإنشاء عنوان zk-email إثيريوم المقابل تلقائيًا. يجب أن يكون بإمكان المستخدمين المتقدمين التحقق من صحة العنوان الذي تم إنشاؤه.
بالنسبة للمستخدمين الجدد، يمكن أن توفر المحفظة خيارات بسيطة، مثل خطة 2 من 3 المستندة إلى zk-email، وتخزين المفاتيح محليًا، ونسخ احتياطي لمفاتيح المزود. مع زيادة خبرة المستخدم أو زيادة الأصول، يجب التنبيه لإضافة المزيد من الوكلاء.
إن دمج المحفظة داخل التطبيق أمر لا مفر منه، لكن يجب أن يتمكن المستخدمون من ربط جميع المحافظ معًا وإدارة التحكم في الوصول بشكل موحد. إحدى الطرق البسيطة هي اعتماد خطة طبقية، تسمح للمستخدمين بتعيين المحفظة الرئيسية كوصي على جميع المحافظ داخل التطبيق.
حماية المستخدمين من الاحتيال والتهديدات الخارجية الأخرى
بخلاف أمان الحساب، قامت المحفظة الحالية بعمل كبير في التعرف على العناوين المزيفة، والتصيد الاحتيالي، والاحتيال. لكن العديد من التدابير لا تزال بدائية، مثل الطلب الموحد للنقر على التأكيد لإرسال الرموز إلى عنوان جديد، بغض النظر عن المبلغ. يتطلب هذا تحسينات مستمرة بناءً على فئات التهديد المختلفة، ولا توجد حلول دائمة.
الخصوصية
لقد حان الوقت لأخذ خصوصية إثيريوم على محمل الجد. تقنية ZK-SNARK متقدمة للغاية، ولا تعتمد على تقنيات الخصوصية ذات الأبواب الخلفية ( مثل برك الخصوصية ) التي تنضج بشكل متزايد، والبنية التحتية من الطبقة الثانية مثل Waku و mempools ERC-4337 تستقر أيضاً بشكل تدريجي. ولكن حتى الآن، لا يزال يتعين على المستخدمين تحميل واستخدام "المحفظة الخاصة" بشكل واضح لإجراء التحويلات الخاصة، مما يزيد من عدم الراحة ويقلل من عدد المستخدمين. الحل هو دمج التحويلات الخاصة مباشرة في المحفظة.
تنفيذ بسيط هو: تقوم المحفظة بتخزين جزء من أصول المستخدم ك"رصيد خاص" في حوض الخصوصية. عند التحويل، يتم الخروج تلقائيًا من حوض الخصوصية، وعند استلام الأموال، يتم إنشاء عنوان غير مرئي تلقائيًا.
بالإضافة إلى ذلك، يمكن للمحفظة إنشاء عنوان جديد تلقائيًا لكل تطبيق يشارك فيه المستخدم. تأتي الإيداعات من حوض الخصوصية، وتذهب السحوبات مباشرة إلى حوض الخصوصية. وهذا يسمح للمستخدمين بفصل الأنشطة عبر التطبيقات المختلفة.
هذه ليست فقط طريقة طبيعية لحماية خصوصية نقل الأصول، ولكن أيضًا وسيلة لحماية خصوصية الهوية. الهوية على السلسلة موجودة بالفعل، مثل التطبيقات التي تستخدم إثبات الهوية، والدردشة المقيدة بالرموز. نأمل أن يحمي هذا النظام البيئي الخصوصية أيضًا، أي أن أنشطة المستخدم على السلسلة لا ينبغي أن تتركز في مكان واحد: يجب تخزين كل مشروع بشكل منفصل، فقط محفظة المستخدم يمكن أن ترى جميع الإثباتات في نفس الوقت. يساعد النظام البيئي الذي يدعم حسابات متعددة لكل مستخدم في تحقيق هذا الهدف، كما تفعل بروتوكولات الإثبات خارج السلسلة مثل EAS و Zupass.
هذا يمثل رؤية متوسطة المدى عملية لخصوصية إثيريوم. على الرغم من أنه يمكن إدخال بعض الميزات في L1 و L2 لجعل نقل حماية الخصوصية أكثر كفاءة وموثوقية، إلا أنه يمكن تحقيق ذلك الآن. يعتقد بعض المدافعين عن الخصوصية أن الخصوصية الكاملة فقط هي المقبولة، مثل تشفير كل EVM. قد تكون هذه النتيجة المثالية على المدى الطويل، لكن ذلك يتطلب إعادة تفكير أكثر جوهرية في نموذج البرمجة، وهو ما لم يتم الوصول إليه بعد من حيث النضج القابل للنشر. نحن بحاجة فعلاً إلى الخصوصية الافتراضية للحصول على مجموعة مجهولة كبيرة بما يكفي. ومع ذلك، فإن التركيز أولاً على التحويلات بين الحسابات (، ) الهوية والحالات ذات الصلة ( مثل إثبات الخصوصية ) هو خطوة عملية أولى، وأسهل تحقيقًا، حيث يمكن للمحفظة البدء في استخدامها الآن.
محفظة إثيريوم تحتاج أيضاً إلى أن تصبح محفظة بيانات
أي حل فعال للخصوصية سيؤدي إلى الحاجة لتخزين بيانات المستخدم خارج السلسلة، سواء للاستخدام في المدفوعات أو الهوية أو حالات الاستخدام الأخرى. أحيانًا تحتفظ بروتوكولات الخصوصية الحديثة بالبيانات المشفرة على السلسلة، باستخدام مفتاح خاص واحد لفك التشفير. وهذا ينطوي على مخاطر، لأنه إذا تم تسريب المفتاح أو أصبح الحاسوب الكمي قابلاً للتطبيق، ستصبح جميع البيانات علنية. تتطلب إثباتات خارج السلسلة بشكل أكبر تخزين البيانات خارج السلسلة.
المحفظة لا تحتاج فقط إلى تخزين صلاحيات الوصول عبر السلاسل، ولكنها تحتاج أيضًا إلى تخزين بيانات المستخدم الخاصة. العالم غير المشفر يدرك هذا الأمر بشكل متزايد. نحن بحاجة إلى بناء ضمانات قوية حول إمكانية الوصول إلى البيانات ومنع التسرب. ربما يمكننا تكديس هذه الحلول: إذا كان هناك N وصيًا، يمكن استخدام مشاركة السر M-of-N لتخزين البيانات بين هؤلاء N وصيًا. من الصعب بشكل أساسي حماية البيانات، لأنه لا يمكن سحب حصة بيانات شخص ما، لكن يجب علينا اقتراح حلول استضافة لامركزية آمنة قدر الإمكان.
الوصول الآمن إلى السلاسل
حاليًا، تعتمد المحفظة على مزودي RPC للحصول على معلومات السلسلة، وهناك ثغرتان في ذلك:
قد يقوم مزود خدمة RPC بسرقة الأموال من خلال تقديم معلومات مضللة مثل سعر السوق (.
يمكن لمزود RPC الحصول على المعلومات الخاصة بتفاعل المستخدم مع التطبيق.
في الظروف المثالية، نأمل في سد الثغرتين هاتين. يتطلب حل المشكلة الأولى معيارًا لعملاء خفيفين من L1 و L2، للتحقق مباشرة من توافق البلوكتشين. لقد نفذ Helios لـ L1 وبدأ بدعم بعض L2. لتغطية جميع L2، نحتاج إلى معيار، من خلال الحصول على جذر الحالة الأخيرة والتحقق من منطق إثبات الحالة والإيصالات عن طريق عقد التكوين الذي يمثل L2. وبهذه الطريقة، يمكن أن يكون هناك عميل خفيف عالمي، يسمح للمحفظة بالتحقق بشكل آمن من أي حالة أو حدث على L1 و L2.
بالنسبة للخصوصية، الطريقة الوحيدة الواقعية في الوقت الحالي هي تشغيل عقدة كاملة خاصة بك. لكن مع انتشار L2، أصبح من الصعب بشكل متزايد تشغيل عقدة كاملة لكل شيء. المعادل للعميل الخفيف هنا هو استرجاع المعلومات الخاصة )PIR(. يتضمن PIR الاحتفاظ بنسخ من جميع البيانات على الخوادم وإرسال طلبات مشفرة إلى الخادم من قبل العملاء. يقوم الخادم بإجراء الحسابات على جميع البيانات، ويعيد البيانات المشفرة المطلوبة للعميل، دون معرفة أي البيانات تم الوصول إليها من قبل العميل.
لضمان صدق الخادم، فإن كل عنصر من عناصر قاعدة البيانات هو في حد ذاته فرع ميركل، ويمكن للعميل استخدام عميل خفيف للتحقق.
حساب PIR يتطلب قدرًا كبيرًا من الحوسبة. تشمل الحلول:
القوة الغاشمة: قد تحسن الخوارزميات أو الأجهزة المخصصة من سرعة تشغيل PIR بشكل كاف.
تقليل متطلبات الخصوصية: مثل أن يكون هناك 1,000,000 "mixins" فقط في كل عملية بحث.
PIR عبر خوادم متعددة: استخدام خوادم متعددة، بافتراض أن 1-of-N صادق، عادةً ما تكون خوارزمية PIR أسرع.
عدم الكشف عن الهوية بدلاً من الخصوصية: إرسال الطلبات عبر شبكة مختلطة، مما يخفي المرسل بدلاً من المحتوى. ولكن هذا سيزيد من التأخير.
في بيئة إثيريوم، يعد العثور على التركيبة التقنية الصحيحة لتعظيم الخصوصية مع الحفاظ على العملية مسألة بحث مفتوحة.
![فيتاليك: رؤية المحفظة المثالية، من تجربة عبر السلاسل إلى ترقية شاملة لحماية الخصوصية])https://img-cdn.gateio.im/webp-social/moments-ab5913a80a4549d9fec805c19442956b.webp(
المحفظة المثالية لمكتبة المفاتيح
في سياق عبر السلاسل L2، هناك عملية مهمة أخرى تحتاج إلى العمل بسلاسة وهي تغيير تحقق الحساب.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 11
أعجبني
11
5
مشاركة
تعليق
0/400
OldLeekConfession
· 07-09 10:20
حماية الخصوصية جاءت احسبني واحداً
شاهد النسخة الأصليةرد0
TooScaredToSell
· 07-07 17:07
الخصوصية في البلوكتشين مهمة للغاية، هذا صحيح.
شاهد النسخة الأصليةرد0
metaverse_hermit
· 07-07 01:17
البلوكتشين الأمان الأول啦~
شاهد النسخة الأصليةرد0
GetRichLeek
· 07-07 01:09
تمت سرقة المحفظة الباردة الصغيرة ثلاث مرات بالفعل، ولا تزال لا تتعلم الدرس.
رؤية المحفظة المثالية لإثيريوم: تجربة عبر السلاسل، حماية الخصوصية وترقية الأمان
رؤية المحفظة المثالية لإيثريوم: ترقية شاملة من تجربة عبر السلاسل إلى حماية الخصوصية
تعتبر طبقة المحفظة في بنية إثيريوم التحتية أساسية، ولكن غالبًا ما يتم التقليل من شأنها من قبل الباحثين الرئيسيين والمطورين. باعتبارها نافذة المستخدم إلى عالم إثيريوم، يجب أن تتمتع المحفظة بخصائص مثل اللامركزية، ومقاومة الرقابة، والأمان، والخصوصية، حتى يتمكن المستخدمون من الاستمتاع حقًا بهذه الخصائص التي تقدمها إثيريوم وتطبيقاتها.
مؤخراً، حققت المحفظة الخاصة بإثيريوم تقدمًا ملحوظًا في تجربة المستخدم والأمان والوظائف. يهدف هذا المقال إلى مشاركة بعض أفكاري حول الخصائص التي يجب أن تتوفر في المحفظة المثالية لإثيريوم. هذه ليست قائمة شاملة، بل تعكس المزيد من ميولي كهاكر تشفير، حيث تركز على الأمان والخصوصية، وقد تكون غير شاملة بما يكفي من حيث تجربة المستخدم. ومع ذلك، أعتقد أنه بدلاً من تحسين تجربة المستخدم بناءً على الملاحظات فقط، قد يكون من الأكثر قيمة التركيز على خصائص الأمان والخصوصية.
تجربة المستخدم في عبر السلاسل L2
هناك الآن خارطة طريق تتطور بشكل متزايد لتحسين تجربة المستخدم عبر السلاسل L2، تشمل أجزاء قصيرة وطويلة الأجل. هنا سأناقش الأفكار القابلة للتنفيذ على المدى القصير.
الفكرة الأساسية هي: (1) تضمين وظيفة إرسال عبر L2، (2) عنوان محدد على السلسلة وطلب الدفع. يجب أن توفر المحفظة للمستخدم عنواناً يتبع نمط مسودة ERC.
عندما يتلقى المستخدم عنوانًا بهذا التنسيق، ما عليه سوى لصقه في حقل "المستلم" في المحفظة والنقر على "إرسال"، يجب على المحفظة معالجة الإرسال تلقائيًا:
في سيناريو طلب الإيداع من قبل dapp، من الممارسات المثالية توسيع واجهة برمجة تطبيقات web3، مما يسمح لـ dapp بإصدار طلبات دفع محددة للسلاسل. يجب على المحفظة توحيد طلب getAvailableBalance، وأخذ ذلك بعين الاعتبار فيما يتعلق بالسلاسل التي يتم افتراضياً تخزين أصول المستخدم عليها، لتحقيق التوازن بين الأمان وسهولة التحويل.
يمكن أيضًا وضع طلبات الدفع الخاصة بالسلسلة في رمز الاستجابة السريعة، ليتم مسحها بواسطة المحفظة المتنقلة. في سيناريوهات الدفع وجهًا لوجه أو عبر الإنترنت، يُظهر رمز الاستجابة السريعة أو استدعاء واجهة برمجة التطبيقات المرسل من قبل المستلم "أريد Z توكن من Y وحدة على X سلسلة، مع مرجع ID W"، يمكن للمحفظة اختيار الطريقة التي تلبي هذا الطلب بحرية. خيار آخر هو بروتوكول رابط المطالبة، حيث تقوم محفظة المستخدم بإنشاء رمز استجابة سريعة أو عنوان URL يحتوي على التفويض، ويتولى المستلم مسؤولية سحب الأموال.
دفع الغاز هو أيضًا موضوع ذي صلة. إذا تلقى المستخدم الأصول على L2 معين ولكن ليس لديه ETH، يجب أن تكون المحفظة قادرة على استخدام البروتوكول تلقائيًا للدفع بالغاز على السلسلة التي يمتلك فيها المستخدم ETH. إذا كانت المحفظة تتوقع أن يقوم المستخدم بإجراء المزيد من المعاملات في المستقبل على هذا L2، يمكن أيضًا استخدام DEX لإرسال كمية معينة من ETH كاحتياطي للغاز.
أمان الحساب
أعتقد أن مفتاح أمان الحساب هو حماية المستخدمين في نفس الوقت من هجمات القراصنة أو السلوكيات الخبيثة لمطوري المحفظة، بالإضافة إلى الأخطاء التي قد يرتكبها المستخدم نفسه.
الحل الذي أميل إليه منذ فترة طويلة هو استعادة اجتماعية مع التحكم في الوصول المتدرج والمحفظة متعددة التوقيعات. تحتوي حسابات المستخدمين على مستويين من المفاتيح: المفتاح الرئيسي وN من المراقبين ( حيث N=5). يمكن استخدام المفتاح الرئيسي لإجراء عمليات ذات قيمة منخفضة وغير مالية. يجب أن يقوم معظم المراقبين بتنفيذ: (1) عمليات ذات قيمة عالية، مثل إرسال جميع أموال الحساب، (2) تغيير المفتاح الرئيسي أو أي مراقب. يمكن السماح للمفتاح الرئيسي بتنفيذ عمليات ذات قيمة عالية من خلال قفل زمني عند الضرورة.
يمكن توسيع هذا التصميم الأساسي بشكل أكبر. يمكن أن تدعم آلية مفاتيح الجلسة والصلاحيات تطبيقات مختلفة لتحقيق التوازن بين الراحة والأمان. تساعد الهياكل الأكثر تعقيدًا للحراس، مثل إعداد فترات قفل زمنية متعددة عند عتبات مختلفة، في تقليل مخاطر السرقة إلى الحد الأدنى مع تعظيم معدل نجاح استعادة الحسابات الشرعية.
بالنسبة لاختيار الوصي, هناك عدة خيارات:
تعد الهوية المركزية المغلفة بتقنية ZK أكثر ملاءمة للمستخدمين الجدد. يجب أن توفر المحفظة واجهة مستخدم مبسطة للتكامل، مما يسمح للمستخدمين بتحديد البريد الإلكتروني كوصي، وإنشاء عنوان zk-email إثيريوم المقابل تلقائيًا. يجب أن يكون بإمكان المستخدمين المتقدمين التحقق من صحة العنوان الذي تم إنشاؤه.
بالنسبة للمستخدمين الجدد، يمكن أن توفر المحفظة خيارات بسيطة، مثل خطة 2 من 3 المستندة إلى zk-email، وتخزين المفاتيح محليًا، ونسخ احتياطي لمفاتيح المزود. مع زيادة خبرة المستخدم أو زيادة الأصول، يجب التنبيه لإضافة المزيد من الوكلاء.
إن دمج المحفظة داخل التطبيق أمر لا مفر منه، لكن يجب أن يتمكن المستخدمون من ربط جميع المحافظ معًا وإدارة التحكم في الوصول بشكل موحد. إحدى الطرق البسيطة هي اعتماد خطة طبقية، تسمح للمستخدمين بتعيين المحفظة الرئيسية كوصي على جميع المحافظ داخل التطبيق.
حماية المستخدمين من الاحتيال والتهديدات الخارجية الأخرى
بخلاف أمان الحساب، قامت المحفظة الحالية بعمل كبير في التعرف على العناوين المزيفة، والتصيد الاحتيالي، والاحتيال. لكن العديد من التدابير لا تزال بدائية، مثل الطلب الموحد للنقر على التأكيد لإرسال الرموز إلى عنوان جديد، بغض النظر عن المبلغ. يتطلب هذا تحسينات مستمرة بناءً على فئات التهديد المختلفة، ولا توجد حلول دائمة.
الخصوصية
لقد حان الوقت لأخذ خصوصية إثيريوم على محمل الجد. تقنية ZK-SNARK متقدمة للغاية، ولا تعتمد على تقنيات الخصوصية ذات الأبواب الخلفية ( مثل برك الخصوصية ) التي تنضج بشكل متزايد، والبنية التحتية من الطبقة الثانية مثل Waku و mempools ERC-4337 تستقر أيضاً بشكل تدريجي. ولكن حتى الآن، لا يزال يتعين على المستخدمين تحميل واستخدام "المحفظة الخاصة" بشكل واضح لإجراء التحويلات الخاصة، مما يزيد من عدم الراحة ويقلل من عدد المستخدمين. الحل هو دمج التحويلات الخاصة مباشرة في المحفظة.
تنفيذ بسيط هو: تقوم المحفظة بتخزين جزء من أصول المستخدم ك"رصيد خاص" في حوض الخصوصية. عند التحويل، يتم الخروج تلقائيًا من حوض الخصوصية، وعند استلام الأموال، يتم إنشاء عنوان غير مرئي تلقائيًا.
بالإضافة إلى ذلك، يمكن للمحفظة إنشاء عنوان جديد تلقائيًا لكل تطبيق يشارك فيه المستخدم. تأتي الإيداعات من حوض الخصوصية، وتذهب السحوبات مباشرة إلى حوض الخصوصية. وهذا يسمح للمستخدمين بفصل الأنشطة عبر التطبيقات المختلفة.
هذه ليست فقط طريقة طبيعية لحماية خصوصية نقل الأصول، ولكن أيضًا وسيلة لحماية خصوصية الهوية. الهوية على السلسلة موجودة بالفعل، مثل التطبيقات التي تستخدم إثبات الهوية، والدردشة المقيدة بالرموز. نأمل أن يحمي هذا النظام البيئي الخصوصية أيضًا، أي أن أنشطة المستخدم على السلسلة لا ينبغي أن تتركز في مكان واحد: يجب تخزين كل مشروع بشكل منفصل، فقط محفظة المستخدم يمكن أن ترى جميع الإثباتات في نفس الوقت. يساعد النظام البيئي الذي يدعم حسابات متعددة لكل مستخدم في تحقيق هذا الهدف، كما تفعل بروتوكولات الإثبات خارج السلسلة مثل EAS و Zupass.
هذا يمثل رؤية متوسطة المدى عملية لخصوصية إثيريوم. على الرغم من أنه يمكن إدخال بعض الميزات في L1 و L2 لجعل نقل حماية الخصوصية أكثر كفاءة وموثوقية، إلا أنه يمكن تحقيق ذلك الآن. يعتقد بعض المدافعين عن الخصوصية أن الخصوصية الكاملة فقط هي المقبولة، مثل تشفير كل EVM. قد تكون هذه النتيجة المثالية على المدى الطويل، لكن ذلك يتطلب إعادة تفكير أكثر جوهرية في نموذج البرمجة، وهو ما لم يتم الوصول إليه بعد من حيث النضج القابل للنشر. نحن بحاجة فعلاً إلى الخصوصية الافتراضية للحصول على مجموعة مجهولة كبيرة بما يكفي. ومع ذلك، فإن التركيز أولاً على التحويلات بين الحسابات (، ) الهوية والحالات ذات الصلة ( مثل إثبات الخصوصية ) هو خطوة عملية أولى، وأسهل تحقيقًا، حيث يمكن للمحفظة البدء في استخدامها الآن.
محفظة إثيريوم تحتاج أيضاً إلى أن تصبح محفظة بيانات
أي حل فعال للخصوصية سيؤدي إلى الحاجة لتخزين بيانات المستخدم خارج السلسلة، سواء للاستخدام في المدفوعات أو الهوية أو حالات الاستخدام الأخرى. أحيانًا تحتفظ بروتوكولات الخصوصية الحديثة بالبيانات المشفرة على السلسلة، باستخدام مفتاح خاص واحد لفك التشفير. وهذا ينطوي على مخاطر، لأنه إذا تم تسريب المفتاح أو أصبح الحاسوب الكمي قابلاً للتطبيق، ستصبح جميع البيانات علنية. تتطلب إثباتات خارج السلسلة بشكل أكبر تخزين البيانات خارج السلسلة.
المحفظة لا تحتاج فقط إلى تخزين صلاحيات الوصول عبر السلاسل، ولكنها تحتاج أيضًا إلى تخزين بيانات المستخدم الخاصة. العالم غير المشفر يدرك هذا الأمر بشكل متزايد. نحن بحاجة إلى بناء ضمانات قوية حول إمكانية الوصول إلى البيانات ومنع التسرب. ربما يمكننا تكديس هذه الحلول: إذا كان هناك N وصيًا، يمكن استخدام مشاركة السر M-of-N لتخزين البيانات بين هؤلاء N وصيًا. من الصعب بشكل أساسي حماية البيانات، لأنه لا يمكن سحب حصة بيانات شخص ما، لكن يجب علينا اقتراح حلول استضافة لامركزية آمنة قدر الإمكان.
الوصول الآمن إلى السلاسل
حاليًا، تعتمد المحفظة على مزودي RPC للحصول على معلومات السلسلة، وهناك ثغرتان في ذلك:
في الظروف المثالية، نأمل في سد الثغرتين هاتين. يتطلب حل المشكلة الأولى معيارًا لعملاء خفيفين من L1 و L2، للتحقق مباشرة من توافق البلوكتشين. لقد نفذ Helios لـ L1 وبدأ بدعم بعض L2. لتغطية جميع L2، نحتاج إلى معيار، من خلال الحصول على جذر الحالة الأخيرة والتحقق من منطق إثبات الحالة والإيصالات عن طريق عقد التكوين الذي يمثل L2. وبهذه الطريقة، يمكن أن يكون هناك عميل خفيف عالمي، يسمح للمحفظة بالتحقق بشكل آمن من أي حالة أو حدث على L1 و L2.
بالنسبة للخصوصية، الطريقة الوحيدة الواقعية في الوقت الحالي هي تشغيل عقدة كاملة خاصة بك. لكن مع انتشار L2، أصبح من الصعب بشكل متزايد تشغيل عقدة كاملة لكل شيء. المعادل للعميل الخفيف هنا هو استرجاع المعلومات الخاصة )PIR(. يتضمن PIR الاحتفاظ بنسخ من جميع البيانات على الخوادم وإرسال طلبات مشفرة إلى الخادم من قبل العملاء. يقوم الخادم بإجراء الحسابات على جميع البيانات، ويعيد البيانات المشفرة المطلوبة للعميل، دون معرفة أي البيانات تم الوصول إليها من قبل العميل.
لضمان صدق الخادم، فإن كل عنصر من عناصر قاعدة البيانات هو في حد ذاته فرع ميركل، ويمكن للعميل استخدام عميل خفيف للتحقق.
حساب PIR يتطلب قدرًا كبيرًا من الحوسبة. تشمل الحلول:
في بيئة إثيريوم، يعد العثور على التركيبة التقنية الصحيحة لتعظيم الخصوصية مع الحفاظ على العملية مسألة بحث مفتوحة.
![فيتاليك: رؤية المحفظة المثالية، من تجربة عبر السلاسل إلى ترقية شاملة لحماية الخصوصية])https://img-cdn.gateio.im/webp-social/moments-ab5913a80a4549d9fec805c19442956b.webp(
المحفظة المثالية لمكتبة المفاتيح
في سياق عبر السلاسل L2، هناك عملية مهمة أخرى تحتاج إلى العمل بسلاسة وهي تغيير تحقق الحساب.